From nobody Thu Jan 2 00:40: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 BB787120052 for ; Thu, 2 Jan 2020 00:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 roKp6E0ooWP0 for ; Thu, 2 Jan 2020 00:40:39 -0800 (PST) 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 EBA0812000F for ; Thu, 2 Jan 2020 00:40:38 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id q6so38424733wro.9 for ; Thu, 02 Jan 2020 00:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4tIGRLOnMiq+q52gtTx+LgycVX6pMTuFU6dtrvNSvA4=; b=oyylRwqkWS211l/WfXT5y3uVfsFE7lGFVKiusBtnnu5caZ5r1v5aL8KoniEN6sHnLy hHisJWC/ZnUo0m/XlCEYVuYkka4f+U078fnGJTMDYTAfBfTS0vN1cSDBth+UB6+uGjIs QE/PTaYO6BUfL0Jw5nqpTgFzEVvMrMRjAKGOMhklTzxeyWfnFGGk1vsNL+HxIIXnzEmH G7IDwJ/YecQun/qQJyIv7ICjgYzL9/kUK6F5m+muHtIFmB8f8rdSaMwyDSSyQnldkoil /AZocCLmeMaH7/EzXv9Co9v631USBga7H+pTPbRqL4OIYvCbAkJOME4Xna25ekNfFwmr ZEQA== 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=4tIGRLOnMiq+q52gtTx+LgycVX6pMTuFU6dtrvNSvA4=; b=Bf+rId9pk8HlYCptUWl6NIUoEnvIDqInwP7EgjB7yOg5YSAY5uNnT3FPQgFCqqXtte 4d6LamRl5skLX/h77ZoBzBZz9N2ho929QUcsGKiNeYO6UuzbwWi9PI4xfxCjzUTlqd1Q 5PVN2xFWYVSg5UyIxVYh7/lPxKwbXi1PMM+3QONVuA7dnxoqlRlUFdkMRynk+uQVw2Zh zmRGLs+qKmB84SaqTmaDQXeRawkwH6+qaeRrVm2fosAK26YtW5g+pyHITa1ZdSq8lf45 o/SSCzivk5MWAYVA5QERggoiUwj+de7VA6lK/odft74vA1tJOiTAFnCEY7TKXlQYaC5N 1odw== X-Gm-Message-State: APjAAAVCxNOvHtviapoChbZvS8EitHbaCO9C9hWV3tSN1RwMkH96IOcS KaDw6keteSB02hEbcVcVbtmE9kbcbXWFgd9mofnAS03Zpwg= X-Google-Smtp-Source: APXvYqzrrPcmV8fLOYu3dJ/0+KID2ZprhhnxA+EQtnxDV+V+gxyfRtrzwZA+81bLIH/O8/iD8B9F+XqY07GSOctqfDI= X-Received: by 2002:adf:f7c4:: with SMTP id a4mr78476320wrq.332.1577954437302; Thu, 02 Jan 2020 00:40:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Takahiko Kawasaki Date: Thu, 2 Jan 2020 17:40:26 +0900 Message-ID: To: Nat Sakimura Cc: John Bradley , Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="000000000000b520a9059b2425fe" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 02 Jan 2020 08:40:42 -0000 --000000000000b520a9059b2425fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Breaking backward compatibility in this part would mean that OpenID Certification given to AS implementations with request_uri support will be invalidated once they support JAR. It also would mean that test cases in the official conformance suite need to be changed in a backward-incompatible manner, which would implicitly encourage that all certified implementations should re-try to get certification. Changing the spec now might need more three to six months, but it would be worth considering what we get and lose by saving the months and breaking backward compatibility. Best Regards, Taka On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura wrote: > So, no change is OK? > > On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: > >> I also slightly prefer the merge approach. >> >> There are plusses and minuses to both. >> >> Changing again now that it is past ISEG review and backing out a Discuss >> will add another three to six months at this point, if we can get them t= o >> agree to the change. >> >> John B. >> >> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: >> >>> Correct. The WG supported the precedence approach and even merge just >>> like OIDC as it is very useful from the implementation point of view an= d >>> helps with a bunch of deployment patter. >>> >>> The push back came in from the Ben Campbell=E2=80=99s DISCUSS. >>> See >>> >>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-ac= tually-specifies-the >>> >>> I am willing to go either way as long as people agree. My slight >>> preference is to the original approach. >>> >>> Best, >>> >>> Nat Sakimura >>> >>> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell >> 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org>>= : >>> >>>> FWIW, as best I can remember the change in question came as I result o= f directorate/IESG >>>> review rather than a WG decision/discussion. Which is likely why you c= an't >>>> find the "why" anywhere in the mailing list archive. >>>> >>>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan >>>> wrote: >>>> >>>>> Well it kind of blows, doesn't it? I wasn't able to find the "why" >>>>> anywhere in the mailing list archive around the time this was changed= . >>>>> >>>>> My take on satisfying both worlds looks like this >>>>> >>>>> - allow just JAR - no other params when possible. >>>>> (which btw isn't possible to do with request_uri when enforcing >>>>> client based uri whitelist and the jwsreq 5.2.2 shows as much) >>>>> - enforce the "dupe behaviours" defined in OIDC (if response_type or >>>>> client_id is in request object it must either be missing or the same = in >>>>> regular request). >>>>> - allows merging request object and regular parameters with request >>>>> object taking precedence since it is a very useful feature when havin= g >>>>> pre-signed request object that's not one time use and clients using i= t wish >>>>> to vary state/nonce per-request. >>>>> >>>>> I wish the group reconsidered making this breaking change from OIDC's >>>>> take on request objects - allow combination of parameters from the re= quest >>>>> object with ones from regular parameters (if not present in request o= bject). >>>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>> Filip, for better or worse, I believe your assessment of the situation >>>>>> is correct. I know of one AS that didn't choose which of the two to = follow >>>>>> but rather implemented a bit of a hybrid where it basically ignores >>>>>> everything outside of the request object per JAR but also checks for= and >>>>>> enforces the presence and value of the few regular parameters (clien= t_id, >>>>>> response_type) that OIDC mandates. >>>>>> >>>>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan >>>>>> wrote: >>>>>> >>>>>>> Hello everyone, >>>>>>> >>>>>>> in an earlier thread I've posed the following question that might >>>>>>> have gotten missed, this might have consequences for the existing >>>>>>> implementations of Request Objects in OIDC implementations - its ma= king >>>>>>> pure JAR requests incompatible with OIDC Core implementations. >>>>>>> >>>>>>> draft 14 of jwsreq (JAR) introduced this language >>>>>>> >>>>>>> The client MAY send the parameters included in the request object >>>>>>>> duplicated in the query parameters as well for the backward >>>>>>>> compatibility etc. >>>>>>>> >>>>>>>> *However, the authorization server supporting thisspecification >>>>>>>> MUST only use the parameters included in the requestobject. * >>>>>>> >>>>>>> >>>>>>> Server MUST only use the parameters in the Request Object even if t= he >>>>>>>> same parameter is provided in the query parameter. The >>>>>>>> Authorization >>>>>>> >>>>>>> >>>>>>> The client MAY send the parameters included in the request object >>>>>>>> duplicated in the query parameters as well for the backward >>>>>>>> compatibility etc. >>>>>>>> >>>>>>>> *However, the authorization server supporting thisspecification >>>>>>>> MUST only use the parameters included in the requestobject. * >>>>>>> >>>>>>> >>>>>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>>>>> everything outside of the request object while OIDC Request Object = one >>>>>>> merges the two with the ones in the request object being used over = ones >>>>>>> that are sent in clear?* The OIDC language also includes sections >>>>>>> which make sure that some required arguments are still passed outsi= de of >>>>>>> the request object with the same value to make sure the request is = "valid" >>>>>>> OAuth 2.0 request (client_id, response_type), something which an ex= ample in >>>>>>> the JAR spec does not do. Not having this language means that exist= ing >>>>>>> authorization request pipelines can't simply be extended with e.g. = a >>>>>>> middleware, they need to branch their codepaths. >>>>>>> >>>>>>> Is an AS required to choose which of the two it follows? >>>>>>> >>>>>>> Thank you for clarifying this in advance. I think if either the >>>>>>> behaviour is the same as in OIDC or different this should be called= out in >>>>>>> the language to avoid confusion, especially since this already exis= ts in >>>>>>> OIDC and likely isn't going to be read in isolation, especially bec= ause the >>>>>>> Request Object is even called out to be already in place in OIDC in= the JAR >>>>>>> draft. >>>>>>> >>>>>>> Best, >>>>>>> *Filip* >>>>>>> _______________________________________________ >>>>>>> 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 prohib= ited. >>>>>> If you have received this communication in error, please notify the = sender >>>>>> immediately by e-mail and delete the message and any file attachment= s from >>>>>> your computer. Thank you.* >>>>> >>>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b520a9059b2425fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Breaking backward compatibility in this part would mean th= at OpenID Certification given to AS implementations with request_uri suppor= t will be invalidated once they support JAR. It also would mean that test c= ases in the official conformance suite need to be changed in a backward-inc= ompatible manner, which would implicitly encourage that all certified imple= mentations should re-try to get certification.

Changing the spec now= might need more three to six months, but it would be worth considering wha= t we get and lose by saving the months and breaking backward compatibility.=

Best Regards,
Taka

On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimu= ra <sakimura@gmail.com> wro= te:
So, no change is OK?=C2=A0

On Wed, Dec 11, 2019 at 10:01 PM John Bradle= y <ve7jtb@ve7jtb.= com> wrote:
I also slightly prefer the merge approach.=C2=A0

There are plusses and minuses to bo= th.=C2=A0

Changing again= now that it is past ISEG review and backing out a Discuss will add another= three to six months at this point, if we can get them to agree to the chan= ge.=C2=A0

John B.=C2=A0<= /div>

On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
Correct. The WG supported the precedence approach and even merge just = like OIDC as it is very useful from the implementation point of view and he= lps with a bunch of deployment patter.=C2=A0
<= br>
The push back came in from the Ben Campbell=E2= =80=99s DISCUSS.=C2=A0
See=C2=A0
https://bitbucket.org/Na= t/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the

I am willing to go either w= ay as long as people agree. My slight preference is to the original approac= h.=C2=A0

Best,=C2=A0

Nat Sakimura

2019= =E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell <bcampbell= =3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as best I can remember the= change in question came as I result of directorate/IESG review rathe= r than a WG decision/discussion. Which is likely why you can't find the= "why" anywhere in the mailing list archive.
On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <pa= nva.ip@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">
Well it kind of blows, doesn't it? I wasn't able t= o find the "why" anywhere in the mailing list archive around the = time this was changed.

My take on satisfying both = worlds looks like this

- allow just JAR - no other= params when possible.
=C2=A0 =C2=A0 (which btw isn't possibl= e to do with request_uri when enforcing client based uri whitelist and the = jwsreq 5.2.2 shows as much)
- enforce the "dupe behaviours&q= uot; defined in OIDC (if response_type or client_id is in request object it= must either be missing or the same in regular request).
- allows= merging request object and regular parameters with request object taking= =C2=A0precedence since it is a very useful feature when having pre-signed r= equest object that's not one time use and clients using it wish to vary= state/nonce per-request.

I wish the group reconsi= dered making this breaking change from OIDC's take on request objects -= allow combination of parameters from the request object with ones from reg= ular parameters (if not present in request object).

=
S pozdravem,
Filip Skokan


=
On= Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidenti= ty.com> wrote:
Filip, for better or worse, I b= elieve your assessment of the situation is correct. I know of one AS that d= idn't choose which of the two to follow but rather implemented a bit of= a hybrid where it basically ignores everything outside of the request obje= ct per JAR but also checks for and enforces the presence and value of the f= ew regular parameters (client_id, response_type) that OIDC mandates.

On= Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> w= rote:
Hello everyone,

in an earlier thread I've po= sed the following question that might have gotten missed, this might have c= onsequences for the existing implementations of Request Objects in OIDC imp= lementations - its making pure JAR requests incompatible with OIDC Core imp= lementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the r= equest object
duplicated in the query parameters as well for the backwar= d
compatibility etc. =C2=A0However, the authorization server supporti= ng this
specification MUST only use the parameters included in the reque= st
object.=C2=A0

Server MUST only use the = parameters in the Request Object even if the
same parameter is provided = in the query parameter.=C2=A0 The Authorization

The client MAY send the parameters included in the request objec= t
duplicated in the query parameters as well for the backward
compati= bility etc. =C2=A0However, the authorization server supporting this
s= pecification MUST only use the parameters included in the request
object= .=C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR compliant AS ignores = everything outside of the request object while OIDC Request Object one merg= es the two with the ones in the request object being used over ones that ar= e sent in clear?=C2=A0The OIDC language also includes sections which ma= ke sure that some required arguments are still passed outside of the reques= t object with the same value to make sure the request is "valid" = OAuth 2.0 request (client_id, response_type), something which an example in= the JAR spec does not do. Not having this language means that existing aut= horization request pipelines can't simply be extended with e.g. a middl= eware, they need to branch their codepaths.

Is an AS required to choose= which of the two it follows?

Thank you for clarifying this in advance.= I think if either the behaviour is the same as in OIDC or different this s= hould be called out in the language to avoid confusion, especially since th= is already exists in OIDC and likely isn't going to be read in isolatio= n, especially because the Request Object is even called out to be already i= n place in OIDC in the JAR draft.

Best,
<= /div>
Filip
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= .. Any review, use, distribution or disclosure by others is strictly prohib= ited.=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 attac= hments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any rev= iew, 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
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b520a9059b2425fe-- From nobody Thu Jan 2 07: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 5E037120024 for ; Thu, 2 Jan 2020 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-SLNG7Dw6qv for ; Thu, 2 Jan 2020 07:48:35 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5FE120091 for ; Thu, 2 Jan 2020 07:48:34 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 002FmT7K009573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jan 2020 10:48:30 -0500 From: Justin Richer Message-Id: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_42139A38-84CA-4869-A6CC-8755B4185280" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 2 Jan 2020 10:48:29 -0500 In-Reply-To: Cc: Nat Sakimura , Brian Campbell , oauth , Nat Sakimura To: Takahiko Kawasaki References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 02 Jan 2020 15:48:38 -0000 --Apple-Mail=_42139A38-84CA-4869-A6CC-8755B4185280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the nature of the backwards incompatibility is important here. = The way that things are now, using merge-with-precedence, you have the = following matrix of compatibility: New Server | Old Server | -----------+-------------+--------------+ New Client | YES | NO | Old Client | YES | YES | If you ask me, this is the right balance for a breaking change. Old = clients, where the vast majority of the code is, don=E2=80=99t have to = change. New clients can only talk to servers with the new features, = which is the ability to drop parameters from the external request. This = would apply to both OIDC and plain OAuth. I think we should follow this kind of pattern in the discussions on = OAuth 2.1, which I think JAR should be a part of/ =E2=80=94 Justin > On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki = wrote: >=20 > Breaking backward compatibility in this part would mean that OpenID = Certification given to AS implementations with request_uri support will = be invalidated once they support JAR. It also would mean that test cases = in the official conformance suite need to be changed in a = backward-incompatible manner, which would implicitly encourage that all = certified implementations should re-try to get certification. >=20 > Changing the spec now might need more three to six months, but it = would be worth considering what we get and lose by saving the months and = breaking backward compatibility. >=20 > Best Regards, > Taka >=20 > On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura > wrote: > So, no change is OK?=20 >=20 > On Wed, Dec 11, 2019 at 10:01 PM John Bradley > wrote: > I also slightly prefer the merge approach.=20 >=20 > There are plusses and minuses to both.=20 >=20 > Changing again now that it is past ISEG review and backing out a = Discuss will add another three to six months at this point, if we can = get them to agree to the change.=20 >=20 > John B.=20 >=20 > On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura > wrote: > Correct. The WG supported the precedence approach and even merge just = like OIDC as it is very useful from the implementation point of view and = helps with a bunch of deployment patter.=20 >=20 > The push back came in from the Ben Campbell=E2=80=99s DISCUSS.=20 > See=20 > = https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actua= lly-specifies-the = >=20 > I am willing to go either way as long as people agree. My slight = preference is to the original approach.=20 >=20 > Best,=20 >=20 > Nat Sakimura >=20 > 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell = >: > FWIW, as best I can remember the change in question came as I result = of directorate/IESG review rather than a WG decision/discussion. Which = is likely why you can't find the "why" anywhere in the mailing list = archive.=20 >=20 > On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan > wrote: > Well it kind of blows, doesn't it? I wasn't able to find the "why" = anywhere in the mailing list archive around the time this was changed. >=20 > My take on satisfying both worlds looks like this >=20 > - allow just JAR - no other params when possible. > (which btw isn't possible to do with request_uri when enforcing = client based uri whitelist and the jwsreq 5.2.2 shows as much) > - enforce the "dupe behaviours" defined in OIDC (if response_type or = client_id is in request object it must either be missing or the same in = regular request). > - allows merging request object and regular parameters with request = object taking precedence since it is a very useful feature when having = pre-signed request object that's not one time use and clients using it = wish to vary state/nonce per-request. >=20 > I wish the group reconsidered making this breaking change from OIDC's = take on request objects - allow combination of parameters from the = request object with ones from regular parameters (if not present in = request object). >=20 > S pozdravem, > Filip Skokan >=20 >=20 > On Wed, 28 Aug 2019 at 23:02, Brian Campbell = > wrote: > Filip, for better or worse, I believe your assessment of the situation = is correct. I know of one AS that didn't choose which of the two to = follow but rather implemented a bit of a hybrid where it basically = ignores everything outside of the request object per JAR but also checks = for and enforces the presence and value of the few regular parameters = (client_id, response_type) that OIDC mandates.=20 >=20 > On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan > wrote: > Hello everyone, >=20 > in an earlier thread I've posed the following question that might have = gotten missed, this might have consequences for the existing = implementations of Request Objects in OIDC implementations - its making = pure JAR requests incompatible with OIDC Core implementations. >=20 > draft 14 of jwsreq (JAR) introduced this language >=20 > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. However, the authorization server supporting this > specification MUST only use the parameters included in the request > object.=20 >=20 > Server MUST only use the parameters in the Request Object even if the > same parameter is provided in the query parameter. The Authorization >=20 > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. However, the authorization server supporting this > specification MUST only use the parameters included in the request > object..=20 >=20 > Nat, John, everyone - does this mean a JAR compliant AS ignores = everything outside of the request object while OIDC Request Object one = merges the two with the ones in the request object being used over ones = that are sent in clear? The OIDC language also includes sections which = make sure that some required arguments are still passed outside of the = request object with the same value to make sure the request is "valid" = OAuth 2.0 request (client_id, response_type), something which an example = in the JAR spec does not do. Not having this language means that = existing authorization request pipelines can't simply be extended with = e.g. a middleware, they need to branch their codepaths. >=20 > Is an AS required to choose which of the two it follows? >=20 > Thank you for clarifying this in advance. I think if either the = behaviour is the same as in OIDC or different this should be called out = in the language to avoid confusion, especially since this already exists = in OIDC and likely isn't going to be read in isolation, especially = because the Request Object is even called out to be already in place in = OIDC in the JAR draft. >=20 > Best, > Filip > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s)... Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_42139A38-84CA-4869-A6CC-8755B4185280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the nature of the backwards incompatibility is important here. The = way that things are now, using merge-with-precedence, you have the = following matrix of compatibility:

             New Server =  |  Old Server  |
-----------+-------------+--------------+
New Client |   =    YES    |      NO     =  |
Old Client |      YES    |   =   YES      |


If = you ask me, this is the right balance for a breaking change. Old = clients, where the vast majority of the code is, don=E2=80=99t have to = change. New clients can only talk to servers with the new features, = which is the ability to drop parameters from the external request. This = would apply to both OIDC and plain OAuth.

I think we should follow this kind of = pattern in the discussions on OAuth 2.1, which I think JAR should be a = part of/

 =E2=80=94 Justin



On Jan = 2, 2020, at 3:40 AM, Takahiko Kawasaki <taka@authlete.com> = wrote:

Breaking backward compatibility = in this part would mean that OpenID Certification given to AS = implementations with request_uri support will be invalidated once they = support JAR. It also would mean that test cases in the official = conformance suite need to be changed in a backward-incompatible manner, = which would implicitly encourage that all certified implementations = should re-try to get certification.

Changing = the spec now might need more three to six months, but it would be worth = considering what we get and lose by saving the months and breaking = backward compatibility.

Best Regards,
Taka

On Wed, Dec = 18, 2019 at 4:14 PM Nat Sakimura <sakimura@gmail.com> wrote:
So, no = change is OK? 

On Wed, Dec 11, 2019 at 10:01 PM John = Bradley <ve7jtb@ve7jtb.com> wrote:
I also = slightly prefer the merge approach. 

There are plusses and = minuses to both. 

Changing again now that it = is past ISEG review and backing out a Discuss will add another three to = six months at this point, if we can get them to agree to the = change. 

John B. 

On Tue, Dec = 10, 2019, 11:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
Correct. The WG supported the precedence = approach and even merge just like OIDC as it is very useful from the = implementation point of view and helps with a bunch of deployment = patter. 

The push back came in from = the Ben Campbell=E2=80=99s DISCUSS. 
See 
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current= -text-actually-specifies-the

I am willing to go either = way as long as people agree. My slight preference is to the original = approach. 

Best, 

Nat Sakimura

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 = Brian Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as = best I can remember the change in question came as I result of directorate/IESG review rather than a WG decision/discussion. = Which is likely why you can't find the "why" anywhere in the mailing = list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva.ip@gmail.com> wrote:
Well it kind of blows, doesn't it? I wasn't able to find the = "why" anywhere in the mailing list archive around the time this was = changed.

My = take on satisfying both worlds looks like this

- allow just JAR - no other params when = possible.
    (which btw isn't possible = to do with request_uri when enforcing client based uri whitelist and the = jwsreq 5.2.2 shows as much)
- enforce the "dupe = behaviours" defined in OIDC (if response_type or client_id is in request = object it must either be missing or the same in regular = request).
- allows merging request object and = regular parameters with request object taking precedence since it = is a very useful feature when having pre-signed request object that's = not one time use and clients using it wish to vary state/nonce = per-request.

I = wish the group reconsidered making this breaking change from OIDC's take = on request objects - allow combination of parameters from the request = object with ones from regular parameters (if not present in request = object).

S pozdravem,
Filip = Skokan


On Wed, 28 Aug 2019 at 23:02, Brian = Campbell <bcampbell@pingidentity.com> wrote:
<= div class=3D"gmail_quote">
Filip, for better or worse, I believe your assessment of the = situation is correct. I know of one AS that didn't choose which of the = two to follow but rather implemented a bit of a hybrid where it = basically ignores everything outside of the request object per JAR but = also checks for and enforces the presence and value of the few regular = parameters (client_id, response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Filip = Skokan <panva.ip@gmail.com> wrote:
Hello everyone,

in an = earlier thread I've posed the following question that might have gotten = missed, this might have consequences for the existing implementations of = Request Objects in OIDC implementations - its making pure JAR requests = incompatible with OIDC Core implementations.

draft 14 of = jwsreq (JAR) introduced this language

The client MAY send the parameters = included in the request object
duplicated in the query = parameters as well for the backward
compatibility etc. =  However, the authorization server supporting this
specification MUST only use the parameters included in the = request
object. 

Server MUST = only use the parameters in the Request Object even if the
same parameter is provided in the query parameter.  The = Authorization

The client MAY send the = parameters included in the request object
duplicated in = the query parameters as well for the backward
compatibility = etc.  However, the authorization server supporting = this
specification MUST only use the parameters included = in the request
object.. 

Nat, = John, everyone - does this mean a JAR compliant AS = ignores everything outside of the request object while OIDC Request = Object one merges the two with the ones in the request object being used = over ones that are sent in clear? The OIDC language also = includes sections which make sure that some required arguments are still = passed outside of the request object with the same value to make sure = the request is "valid" OAuth 2.0 request (client_id, response_type), = something which an example in the JAR spec does not do. Not having this = language means that existing authorization request pipelines can't = simply be extended with e.g. a middleware, they need to branch their = codepaths.

Is an AS required to choose which of the two it = follows?

Thank you for clarifying this in advance. I think = if either the behaviour is the same as in OIDC or different this should = be called out in the language to avoid confusion, especially since this = already exists in OIDC and likely isn't going to be read in isolation, = especially because the Request Object is even called out to be already = in place in OIDC in the JAR draft.

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

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

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


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

= --Apple-Mail=_42139A38-84CA-4869-A6CC-8755B4185280-- From nobody Thu Jan 2 09: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 9C5B712006F for ; Thu, 2 Jan 2020 09:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 r_RBoB8rfas8 for ; Thu, 2 Jan 2020 09:24:47 -0800 (PST) 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 96BCB120045 for ; Thu, 2 Jan 2020 09:24:46 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id p17so6337824wma.1 for ; Thu, 02 Jan 2020 09:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RGJ/1QGzXU0I6cJd1/akiXGMdhH0mKxIjpdAJBpNz1Y=; b=SZ+I6SgcEMQhnNjng2VR6YWBvi8kpDyN7nD4xduK6/qH+wYTtTu2WyiKuHmSWofx6d hJk276umExXBL6GpJI8jGURS4I0qJ6DMc9kHam7S+0Q7AHmhugRu59VEDpoRJA71f/o6 XbX1bzTMpOpl9LoSAMLSERNVE14g72Nmt1uf7akOouH75dKoR6/CBLkzTG9ROz46Kl5w JY0Re1/nnb4wXH1LTw0ptSBNyXpFrYjdxeRd5uZh6/nkNDRfkudX//xK5eBuKEPJwXy/ 7mv9tNTBigeuGXAvcD/lCg8PUnOq1GXnm+y8tcTNYSOoYO2xQP1kG7vwAa/75JB3cHyL 9Cpw== 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=RGJ/1QGzXU0I6cJd1/akiXGMdhH0mKxIjpdAJBpNz1Y=; b=GLXRzMdJx7WjyHMlbhzqGO7CpY8N/Fb3sqi8qiB41OwkUQwdxoaCKXo1+8BBplsUcY H0TdFOyZpSmo1zMceMSPIEuR//1X3gEAYdKrjnERsWvklAzHN4D5ZrhNEX5bSF+sBZiQ 0GImlu0MdtNEjf8dBkLSgKRBl0rHEEeLpKomeM98od7ksiiMHYba/sMsTMRLz1NrilFr vvzGzC1LISJGjsS/ESX+VSVRlFj9sZz5/Pq8ETxWBoFTlcRDae7XpLssZwLe4CPiN/Y6 1dbOsUzMjCaXINyhNgeAKTKfpl5af8PPCLf+qN/HUxrGLcujBe8AnPNA/bsCclYGzAcD 5k5w== X-Gm-Message-State: APjAAAVyCrCR85tIlVF2sKRIPZhxWTU4fjwd6T1PemBMZIv9x2VXvrEi Hy1denh3nNYv8En5dPz4+T/35EW5BvBSRE8N5x97PA== X-Google-Smtp-Source: APXvYqyFscBp3aSX7o/Lywif7DI5vtJYJuRK2pAHRIFVCNL5ImEUUyww6ZC0bntarEsDFHhCluluTiMvr6s+YjC0zUs= X-Received: by 2002:a05:600c:2383:: with SMTP id m3mr15897936wma.32.1577985884982; Thu, 02 Jan 2020 09:24:44 -0800 (PST) MIME-Version: 1.0 References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> In-Reply-To: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> From: Takahiko Kawasaki Date: Fri, 3 Jan 2020 02:24:33 +0900 Message-ID: To: Justin Richer Cc: Nat Sakimura , Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="00000000000022a82a059b2b78db" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 02 Jan 2020 17:24:51 -0000 --00000000000022a82a059b2b78db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Justin. Actually, I wanted to see someone write a summary about what happens in each combination from a viewpoint of both RP and AS with regard to backward compatibility (as I told you in other channel just before you posted your email ^_^). So, *(1) New Client + New Server* No problem will happen. *(2) New Client + Old Server* *[Problem 2-1]* If an authorization request contains 'request' or 'request_uri' but doesn't have old mandatory request parameters ('client_id' and 'response_type') outside the request object, the request is rejected. *[Solution 2]* New Client should include the old mandatory request parameters duplicately outside the request object. This means that New Client should always send old mandatory request parameters duplicately outside the request object if it wants to get maximum compatibility. *(3) Old Client + New Server* *[Problem 3-1]* If an authorization request contains 'request' or 'request_uri' and some "optional" request parameters are not included in the request object, AS will interpret the request differently. Imagine what happens when optional parameters such as 'scope', 'state', 'nonce', 'redirect_uri', 'response_mode', 'max_age', 'acr_values', 'code_challenge', 'code_challenge_method' and 'prompt' are not included in the request object but present outside the request object. *[Problem 3-2]* If an authorization request contains 'request' or 'request_uri' and some "mandatory" request parameters ('client_id' and 'response_type') are not included in the request object, the request is rejected. *[Solution 3]* Old Client should include all request parameters duplicately in the request object. This means that Old Client should always include all request parameters duplicately in the request object if it wants to get maximum compatibility. *(4) Old Client + Old Server* No problem will happen. - - - >From a Client's point of view, for maximum compatibility, both Old and New Clients should put mandatory request parameters outside the request object and put all request parameters duplicately inside the request object. [Problem 3-1] is difficult to detect because the authorization request is not rejected. But, if New Server requires that all request parameters outside the request object be put inside the request object duplicately, [Problem 3-1] is handled as an error and thus client developers can detect the problem. Consequently, introducing the following requirement in "FAPI Part 2, 5.2.2 , 10" to JAR seems a good compromise (as I told before) shall require that all parameters are present inside the signed request object passed in the request or request_uri parameter; instead of just saying "the authorization server supporting this specification MUST only use the parameters included in the request object." which will bring about [Problem 3-1]. That is, how about adding a rule like "if request parameters exist outside the request object, they must exist inside the request object, too."? Any thoughts? Best, Taka On Fri, Jan 3, 2020 at 12:48 AM Justin Richer wrote: > I think the nature of the backwards incompatibility is important here. Th= e > way that things are now, using merge-with-precedence, you have the > following matrix of compatibility: > > > New Server | Old Server | > -----------+-------------+--------------+ > New Client | YES | NO | > Old Client | YES | YES | > > > If you ask me, this is the right balance for a breaking change. Old > clients, where the vast majority of the code is, don=E2=80=99t have to ch= ange. New > clients can only talk to servers with the new features, which is the > ability to drop parameters from the external request. This would apply to > both OIDC and plain OAuth. > > I think we should follow this kind of pattern in the discussions on OAuth > 2.1, which I think JAR should be a part of/ > > =E2=80=94 Justin > > > > On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki wrote: > > Breaking backward compatibility in this part would mean that OpenID > Certification given to AS implementations with request_uri support will b= e > invalidated once they support JAR. It also would mean that test cases in > the official conformance suite need to be changed in a > backward-incompatible manner, which would implicitly encourage that all > certified implementations should re-try to get certification. > > Changing the spec now might need more three to six months, but it would b= e > worth considering what we get and lose by saving the months and breaking > backward compatibility. > > Best Regards, > Taka > > On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura wrote: > >> So, no change is OK? >> >> On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: >> >>> I also slightly prefer the merge approach. >>> >>> There are plusses and minuses to both. >>> >>> Changing again now that it is past ISEG review and backing out a Discus= s >>> will add another three to six months at this point, if we can get them = to >>> agree to the change. >>> >>> John B. >>> >>> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: >>> >>>> Correct. The WG supported the precedence approach and even merge just >>>> like OIDC as it is very useful from the implementation point of view a= nd >>>> helps with a bunch of deployment patter. >>>> >>>> The push back came in from the Ben Campbell=E2=80=99s DISCUSS. >>>> See >>>> >>>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-a= ctually-specifies-the >>>> >>>> I am willing to go either way as long as people agree. My slight >>>> preference is to the original approach. >>>> >>>> Best, >>>> >>>> Nat Sakimura >>>> >>>> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell >>> 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org> >>>> >: >>>> >>>>> FWIW, as best I can remember the change in question came as I result >>>>> of directorate/IESG review rather than a WG decision/discussion. >>>>> Which is likely why you can't find the "why" anywhere in the mailing = list >>>>> archive. >>>>> >>>>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan >>>>> wrote: >>>>> >>>>>> Well it kind of blows, doesn't it? I wasn't able to find the "why" >>>>>> anywhere in the mailing list archive around the time this was change= d. >>>>>> >>>>>> My take on satisfying both worlds looks like this >>>>>> >>>>>> - allow just JAR - no other params when possible. >>>>>> (which btw isn't possible to do with request_uri when enforcing >>>>>> client based uri whitelist and the jwsreq 5.2.2 shows as much) >>>>>> - enforce the "dupe behaviours" defined in OIDC (if response_type or >>>>>> client_id is in request object it must either be missing or the same= in >>>>>> regular request). >>>>>> - allows merging request object and regular parameters with request >>>>>> object taking precedence since it is a very useful feature when havi= ng >>>>>> pre-signed request object that's not one time use and clients using = it wish >>>>>> to vary state/nonce per-request. >>>>>> >>>>>> I wish the group reconsidered making this breaking change from OIDC'= s >>>>>> take on request objects - allow combination of parameters from the r= equest >>>>>> object with ones from regular parameters (if not present in request = object). >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> >>>>>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>> Filip, for better or worse, I believe your assessment of the situatio= n >>>>>>> is correct. I know of one AS that didn't choose which of the two to= follow >>>>>>> but rather implemented a bit of a hybrid where it basically ignores >>>>>>> everything outside of the request object per JAR but also checks fo= r and >>>>>>> enforces the presence and value of the few regular parameters (clie= nt_id, >>>>>>> response_type) that OIDC mandates. >>>>>>> >>>>>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan >>>>>>> wrote: >>>>>>> >>>>>>>> Hello everyone, >>>>>>>> >>>>>>>> in an earlier thread I've posed the following question that might >>>>>>>> have gotten missed, this might have consequences for the existing >>>>>>>> implementations of Request Objects in OIDC implementations - its m= aking >>>>>>>> pure JAR requests incompatible with OIDC Core implementations. >>>>>>>> >>>>>>>> draft 14 of jwsreq (JAR) introduced this language >>>>>>>> >>>>>>>> The client MAY send the parameters included in the request object >>>>>>>>> duplicated in the query parameters as well for the backward >>>>>>>>> compatibility etc. >>>>>>>>> >>>>>>>>> *However, the authorization server supporting thisspecification >>>>>>>>> MUST only use the parameters included in the requestobject. * >>>>>>>> >>>>>>>> >>>>>>>> Server MUST only use the parameters in the Request Object even if >>>>>>>>> the >>>>>>>>> same parameter is provided in the query parameter. The >>>>>>>>> Authorization >>>>>>>> >>>>>>>> >>>>>>>> The client MAY send the parameters included in the request object >>>>>>>>> duplicated in the query parameters as well for the backward >>>>>>>>> compatibility etc. >>>>>>>>> >>>>>>>>> *However, the authorization server supporting thisspecification >>>>>>>>> MUST only use the parameters included in the requestobject.. * >>>>>>>> >>>>>>>> >>>>>>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>>>>>>> everything outside of the request object while OIDC Request Object= one >>>>>>>> merges the two with the ones in the request object being used over= ones >>>>>>>> that are sent in clear?* The OIDC language also includes sections >>>>>>>> which make sure that some required arguments are still passed outs= ide of >>>>>>>> the request object with the same value to make sure the request is= "valid" >>>>>>>> OAuth 2.0 request (client_id, response_type), something which an e= xample in >>>>>>>> the JAR spec does not do. Not having this language means that exis= ting >>>>>>>> authorization request pipelines can't simply be extended with e.g.= a >>>>>>>> middleware, they need to branch their codepaths. >>>>>>>> >>>>>>>> Is an AS required to choose which of the two it follows? >>>>>>>> >>>>>>>> Thank you for clarifying this in advance. I think if either the >>>>>>>> behaviour is the same as in OIDC or different this should be calle= d out in >>>>>>>> the language to avoid confusion, especially since this already exi= sts in >>>>>>>> OIDC and likely isn't going to be read in isolation, especially be= cause the >>>>>>>> Request Object is even called out to be already in place in OIDC i= n the JAR >>>>>>>> draft. >>>>>>>> >>>>>>>> Best, >>>>>>>> *Filip* >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s)..= . Any >>>>>>> review, use, distribution or disclosure by others is strictly prohi= bited. >>>>>>> If you have received this communication in error, please notify the= sender >>>>>>> immediately by e-mail and delete the message and any file attachmen= ts from >>>>>>> your computer. Thank you.* >>>>>> >>>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly prohibi= ted.. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you.* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --00000000000022a82a059b2b78db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Justin. Actually, I wanted to see someone write= a summary about what happens in each combination from a viewpoint of both = RP and AS with regard to backward compatibility (as I told you in other cha= nnel just before you posted your email ^_^).

So,

(1) New C= lient + New Server
No problem will happen.

(2) New Client = + Old Server
[Problem 2-1] If an authorization request contai= ns 'request' or 'request_uri' but doesn't have old mand= atory request parameters ('client_id' and 'response_type') = outside the request object, the request is rejected.

[Solution 2]= New Client should include the old mandatory request parameters duplica= tely outside the request object. This means that New Client should always s= end old mandatory request parameters duplicately outside the request object= if it wants to get maximum compatibility.

(3) Old Client + New S= erver
[Problem 3-1] If an authorization request contains '= ;request' or 'request_uri' and some "optional" reques= t parameters are not included in the request object, AS will interpret the = request differently. Imagine what happens when optional parameters such as = 'scope', 'state', 'nonce', 'redirect_uri', = 'response_mode', 'max_age', 'acr_values', 'code= _challenge', 'code_challenge_method' and 'prompt' are n= ot included in the request object but present outside the request object.
[Problem 3-2] If an authorization request contains 'reques= t' or 'request_uri' and some "mandatory" request para= meters ('client_id' and 'response_type') are not included i= n the request object, the request is rejected.

[Solution 3] O= ld Client should include all request parameters duplicately in the request = object. This means that Old Client should always include all request parame= ters duplicately in the request object if it wants to get maximum compatibi= lity.

(4) Old Client + Old Server
No problem will happen.<= br>
- - -

From a Client's point of view, for maximum compati= bility, both Old and New Clients should put mandatory request parameters ou= tside the request object and put all request parameters duplicately inside = the request object.

[Problem 3-1] is difficult to detect because the= authorization request is not rejected. But, if New Server requires that al= l request parameters outside the request object be put inside the request o= bject duplicately, [Problem 3-1] is handled as an error and thus client dev= elopers can detect the problem.

Consequently, introducing the follow= ing requirement in "FAPI Part 2, 5.2.2, 10&quo= t; to JAR seems a good compromise (as I told before)

shall require that all par= ameters are present inside the signed request object passed in the request = or request_uri parameter;

instead of just saying "the = authorization server supporting this specification MUST only use the parame= ters included in the request object." which will bring about [Problem = 3-1]. That is, how about adding a rule like "if request parameters exi= st outside the request object, they must exist inside the request object, t= oo."?

Any thoughts?

Best,
Taka=


On Fri, Jan 3, 2020 at 12:48 AM Justin Richer &l= t;jricher@mit.edu> wrote:
I think the nature of the backwards incompatibility is i= mportant here. The way that things are now, using merge-with-precedence, yo= u have the following matrix of compatibility:


=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Server =C2=A0| =C2=A0Old Serve= r =C2=A0|
-----------+---------= ----+--------------+
New Client= | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0NO =C2=A0 =C2= =A0 =C2=A0|
Old Client | =C2=A0= =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0 YES =C2=A0 =C2=A0 =C2=A0|


If you ask me, this is the rig= ht balance for a breaking change. Old clients, where the vast majority of t= he code is, don=E2=80=99t have to change. New clients can only talk to serv= ers with the new features, which is the ability to drop parameters from the= external request. This would apply to both OIDC and plain OAuth.

I think we should follow this kind of pattern in the discus= sions on OAuth 2.1, which I think JAR should be a part of/

=C2=A0=E2=80=94 Justin



On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <= ;taka@authlete.com> wrote:

Breaking backward compatibilit= y in this part would mean that OpenID Certification given to AS implementat= ions with request_uri support will be invalidated once they support JAR. It= also would mean that test cases in the official conformance suite need to = be changed in a backward-incompatible manner, which would implicitly encour= age that all certified implementations should re-try to get certification.<= br>
Changing the spec now might need more three to six months, but it wo= uld be worth considering what we get and lose by saving the months and brea= king backward compatibility.

Best Regards,
Taka

On Wed, Dec 18= , 2019 at 4:14 PM Nat Sakimura <sakimura@gmail.com> wrote:
So, no change is OK?=C2= =A0

On Wed, Dec 11, 2019 at 10:01 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
=
I also = slightly prefer the merge approach.=C2=A0

There are plusses and minuses to both.=C2=A0

Changing again now that it is past ISEG re= view and backing out a Discuss will add another three to six months at this= point, if we can get them to agree to the change.=C2=A0

John B.=C2=A0

On Tue, Dec 10, 2019, 1= 1:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
Correct. The WG support= ed the precedence approach and even merge just like OIDC as it is very usef= ul from the implementation point of view and helps with a bunch of deployme= nt patter.=C2=A0

T= he push back came in from the Ben Campbell=E2=80=99s DISCUSS.=C2=A0
See=C2=A0

=
I am willing to go either way as long as people agree. My= slight preference is to the original approach.=C2=A0

Best,=C2=A0

=
Nat Sakimura

2019=E5=B9=B48=E6=9C=8829=E6=97=A5= (=E6=9C=A8) 6:56 Brian Campbell <bcampbell=3D40pingidenti= ty..com@dmarc.ietf.org>:
FWIW, as best I can remember the change in question came as I = result of directorate/IESG review rather than a WG decision/discussio= n. Which is likely why you can't find the "why" anywhere in t= he mailing list archive.

On Wed= , Aug 28, 2019 at 3:23 PM Filip Skokan <panva.ip@gmail.com> wrote= :
Well it kind = of blows, doesn't it? I wasn't able to find the "why" any= where in the mailing list archive around the time this was changed.

My take on satisfying both worlds looks like this

- allow just JAR - no other params when possible.
=C2=A0 =C2=A0 (which btw isn't possible to do with request_uri when = enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much)
- enforce the "dupe behaviours" defined in OIDC (if respo= nse_type or client_id is in request object it must either be missing or the= same in regular request).
- allows merging request object and re= gular parameters with request object taking=C2=A0precedence since it is a v= ery useful feature when having pre-signed request object that's not one= time use and clients using it wish to vary state/nonce per-request.
<= div>
I wish the group reconsidered making this breaking chang= e from OIDC's take on request objects - allow combination of parameters= from the request object with ones from regular parameters (if not present = in request object).

S pozdrave= m,
Filip Skokan


On Wed, 28 Aug 2019 at 23:02, Bria= n Campbell <bcampbell@pingidentity.com> wrote:
<= /div>
Filip, for better or worse, I believe your assessment of the si= tuation is correct. I know of one AS that didn't choose which of the tw= o to follow but rather implemented a bit of a hybrid where it basically ign= ores everything outside of the request object per JAR but also checks for a= nd enforces the presence and value of the few regular parameters (client_id= , response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Fi= lip Skokan <panva.ip@gmail.com> wrote:
Hello everyone,

=
in an earlier thread I've posed the following question that might = have gotten missed, this might have consequences for the existing implement= ations of Request Objects in OIDC implementations - its making pure JAR req= uests incompatible with OIDC Core implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
= duplicated in the query parameters as well for the backward
compatibilit= y etc. =C2=A0However, the authorization server supporting this
specif= ication MUST only use the parameters included in the request
object.=C2= =A0

Server MUST only use the parameters in the Request Object = even if the
same parameter is provided in the query parameter.=C2=A0 The= Authorization

The client MAY send the= parameters included in the request object
duplicated in the query param= eters as well for the backward
compatibility etc. =C2=A0However, the = authorization server supporting this
specification MUST only use the par= ameters included in the request
object..=C2=A0

=
Nat, John, everyone -=C2=A0does this mean a JAR compli= ant AS ignores everything outside of the request object while OIDC Request = Object one merges the two with the ones in the request object being used ov= er ones that are sent in clear?=C2=A0The OIDC language also includes se= ctions which make sure that some required arguments are still passed outsid= e of the request object with the same value to make sure the request is &qu= ot;valid" OAuth 2.0 request (client_id, response_type), something whic= h an example in the JAR spec does not do. Not having this language means th= at existing authorization request pipelines can't simply be extended wi= th e.g. a middleware, they need to branch their codepaths.

Is an AS required to choose which of the two it follows?

Thank you for clarifying this in advance. I think if either= the behaviour is the same as in OIDC or different this should be called ou= t in the language to avoid confusion, especially since this already exists = in OIDC and likely isn't going to be read in isolation, especially beca= use the Request Object is even called out to be already in place in OIDC in= the JAR draft.

Best,
Filip
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

CONFIDENTIALITY NOTICE: This email may contain confidential and= privileged material for the sole use of the intended recipient(s). Any rev= iew, 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
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--00000000000022a82a059b2b78db-- From nobody Thu Jan 2 09:35: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 A505712002F for ; Thu, 2 Jan 2020 09:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxbl-yvF8gMD for ; Thu, 2 Jan 2020 09:35:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700C5120071 for ; Thu, 2 Jan 2020 09:35:30 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 002HZPro010843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jan 2020 12:35:26 -0500 From: Justin Richer Message-Id: <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF8A91A3-1093-431A-B43F-1C43EC83C408" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 2 Jan 2020 12:35:25 -0500 In-Reply-To: Cc: Nat Sakimura , Brian Campbell , oauth , Nat Sakimura To: Takahiko Kawasaki References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 02 Jan 2020 17:35:35 -0000 --Apple-Mail=_CF8A91A3-1093-431A-B43F-1C43EC83C408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For solution [2], this is the behavior that=E2=80=99s required for OIDC = today, so I would say that=E2=80=99s the New Client behaving like an Old = Client in order to talk to an Old Server. So in reality, (2) causes the = request to be rejected, and that=E2=80=99s OK. I don=E2=80=99t think it=E2=80=99s viable to require parameters to exist = inside the request object at all times. Nor should we try to enumerate = which parameters go inside and outside at all times =E2=80=94 at least = from the JAR/OAuth level of things. I think there are too many things = that are application and deployment specific for us to make this call. = The very nature of the request object changes for people =E2=80=94 some = have a static object that=E2=80=99s deployed with clients and some have = something that the client creates at runtime for each request.=20 If the instead the New Server requires that any parameters duplicated = between the two places have to match (the OIDC method) or that in a = conflict the request object values take precedence (the merge method), = then problems 3-1 and 3-2 go away.=20 With the merge-and-precedence behavior, which is what I thought that JAR = had during WGLC, [3-1] is well-defined. The request is processed the = same way every time because this is a New Server. The client is going to = do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge = with precedence=E2=80=9D is effectively a no-op. With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen = because the required parameters aren=E2=80=99t required to be in the = request object itself. As long as the request object is valid, it = protects all parameters within it. I don=E2=80=99t think it=E2=80=99s up = to us to determine what makes sense to put in that object. Security = guidance is probably a good idea here. Solution [3] is what Old Clients already do in OIDC today, so that=E2=80=99= s what already happens and why problem space (3) isn=E2=80=99t a = problem. =E2=80=94 Justin > On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki = wrote: >=20 > Thank you, Justin. Actually, I wanted to see someone write a summary = about what happens in each combination from a viewpoint of both RP and = AS with regard to backward compatibility (as I told you in other channel = just before you posted your email ^_^). >=20 > So, >=20 > (1) New Client + New Server > No problem will happen. >=20 > (2) New Client + Old Server > [Problem 2-1] If an authorization request contains 'request' or = 'request_uri' but doesn't have old mandatory request parameters = ('client_id' and 'response_type') outside the request object, the = request is rejected. >=20 > [Solution 2] New Client should include the old mandatory request = parameters duplicately outside the request object. This means that New = Client should always send old mandatory request parameters duplicately = outside the request object if it wants to get maximum compatibility. >=20 > (3) Old Client + New Server > [Problem 3-1] If an authorization request contains 'request' or = 'request_uri' and some "optional" request parameters are not included in = the request object, AS will interpret the request differently. Imagine = what happens when optional parameters such as 'scope', 'state', 'nonce', = 'redirect_uri', 'response_mode', 'max_age', 'acr_values', = 'code_challenge', 'code_challenge_method' and 'prompt' are not included = in the request object but present outside the request object. >=20 > [Problem 3-2] If an authorization request contains 'request' or = 'request_uri' and some "mandatory" request parameters ('client_id' and = 'response_type') are not included in the request object, the request is = rejected. >=20 > [Solution 3] Old Client should include all request parameters = duplicately in the request object. This means that Old Client should = always include all request parameters duplicately in the request object = if it wants to get maximum compatibility. >=20 > (4) Old Client + Old Server > No problem will happen. >=20 > - - - >=20 > =46rom a Client's point of view, for maximum compatibility, both Old = and New Clients should put mandatory request parameters outside the = request object and put all request parameters duplicately inside the = request object. >=20 > [Problem 3-1] is difficult to detect because the authorization request = is not rejected. But, if New Server requires that all request parameters = outside the request object be put inside the request object duplicately, = [Problem 3-1] is handled as an error and thus client developers can = detect the problem. >=20 > Consequently, introducing the following requirement in "FAPI Part 2, = 5.2.2 = , 10" to JAR seems a good compromise (as I told before) >=20 > shall require that all parameters are present inside the signed = request object passed in the request or request_uri parameter; >=20 > instead of just saying "the authorization server supporting this = specification MUST only use the parameters included in the request = object." which will bring about [Problem 3-1]. That is, how about adding = a rule like "if request parameters exist outside the request object, = they must exist inside the request object, too."? >=20 > Any thoughts? >=20 > Best, > Taka >=20 >=20 > On Fri, Jan 3, 2020 at 12:48 AM Justin Richer > wrote: > I think the nature of the backwards incompatibility is important here. = The way that things are now, using merge-with-precedence, you have the = following matrix of compatibility: >=20 >=20 > New Server | Old Server | > -----------+-------------+--------------+ > New Client | YES | NO | > Old Client | YES | YES | >=20 >=20 > If you ask me, this is the right balance for a breaking change. Old = clients, where the vast majority of the code is, don=E2=80=99t have to = change. New clients can only talk to servers with the new features, = which is the ability to drop parameters from the external request. This = would apply to both OIDC and plain OAuth. >=20 > I think we should follow this kind of pattern in the discussions on = OAuth 2.1, which I think JAR should be a part of/ >=20 > =E2=80=94 Justin >=20 >=20 >=20 >> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki > wrote: >>=20 >> Breaking backward compatibility in this part would mean that OpenID = Certification given to AS implementations with request_uri support will = be invalidated once they support JAR. It also would mean that test cases = in the official conformance suite need to be changed in a = backward-incompatible manner, which would implicitly encourage that all = certified implementations should re-try to get certification. >>=20 >> Changing the spec now might need more three to six months, but it = would be worth considering what we get and lose by saving the months and = breaking backward compatibility. >>=20 >> Best Regards, >> Taka >>=20 >> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura > wrote: >> So, no change is OK?=20 >>=20 >> On Wed, Dec 11, 2019 at 10:01 PM John Bradley > wrote: >> I also slightly prefer the merge approach.=20 >>=20 >> There are plusses and minuses to both.=20 >>=20 >> Changing again now that it is past ISEG review and backing out a = Discuss will add another three to six months at this point, if we can = get them to agree to the change.=20 >>=20 >> John B.=20 >>=20 >> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura > wrote: >> Correct. The WG supported the precedence approach and even merge just = like OIDC as it is very useful from the implementation point of view and = helps with a bunch of deployment patter.=20 >>=20 >> The push back came in from the Ben Campbell=E2=80=99s DISCUSS.=20 >> See=20 >> = https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actua= lly-specifies-the = >>=20 >> I am willing to go either way as long as people agree. My slight = preference is to the original approach.=20 >>=20 >> Best,=20 >>=20 >> Nat Sakimura >>=20 >> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell = >: >> FWIW, as best I can remember the change in question came as I result = of directorate/IESG review rather than a WG decision/discussion. Which = is likely why you can't find the "why" anywhere in the mailing list = archive.=20 >>=20 >> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan > wrote: >> Well it kind of blows, doesn't it? I wasn't able to find the "why" = anywhere in the mailing list archive around the time this was changed. >>=20 >> My take on satisfying both worlds looks like this >>=20 >> - allow just JAR - no other params when possible. >> (which btw isn't possible to do with request_uri when enforcing = client based uri whitelist and the jwsreq 5.2.2 shows as much) >> - enforce the "dupe behaviours" defined in OIDC (if response_type or = client_id is in request object it must either be missing or the same in = regular request). >> - allows merging request object and regular parameters with request = object taking precedence since it is a very useful feature when having = pre-signed request object that's not one time use and clients using it = wish to vary state/nonce per-request. >>=20 >> I wish the group reconsidered making this breaking change from OIDC's = take on request objects - allow combination of parameters from the = request object with ones from regular parameters (if not present in = request object). >>=20 >> S pozdravem, >> Filip Skokan >>=20 >>=20 >> On Wed, 28 Aug 2019 at 23:02, Brian Campbell = > wrote: >> Filip, for better or worse, I believe your assessment of the = situation is correct. I know of one AS that didn't choose which of the = two to follow but rather implemented a bit of a hybrid where it = basically ignores everything outside of the request object per JAR but = also checks for and enforces the presence and value of the few regular = parameters (client_id, response_type) that OIDC mandates.=20 >>=20 >> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan > wrote: >> Hello everyone, >>=20 >> in an earlier thread I've posed the following question that might = have gotten missed, this might have consequences for the existing = implementations of Request Objects in OIDC implementations - its making = pure JAR requests incompatible with OIDC Core implementations. >>=20 >> draft 14 of jwsreq (JAR) introduced this language >>=20 >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. However, the authorization server supporting this >> specification MUST only use the parameters included in the request >> object.=20 >>=20 >> Server MUST only use the parameters in the Request Object even if the >> same parameter is provided in the query parameter. The Authorization >>=20 >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. However, the authorization server supporting this >> specification MUST only use the parameters included in the request >> object..=20 >>=20 >> Nat, John, everyone - does this mean a JAR compliant AS ignores = everything outside of the request object while OIDC Request Object one = merges the two with the ones in the request object being used over ones = that are sent in clear? The OIDC language also includes sections which = make sure that some required arguments are still passed outside of the = request object with the same value to make sure the request is "valid" = OAuth 2.0 request (client_id, response_type), something which an example = in the JAR spec does not do. Not having this language means that = existing authorization request pipelines can't simply be extended with = e.g. a middleware, they need to branch their codepaths. >>=20 >> Is an AS required to choose which of the two it follows? >>=20 >> Thank you for clarifying this in advance. I think if either the = behaviour is the same as in OIDC or different this should be called out = in the language to avoid confusion, especially since this already exists = in OIDC and likely isn't going to be read in isolation, especially = because the Request Object is even called out to be already in place in = OIDC in the JAR draft. >>=20 >> Best, >> Filip >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s)... Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_CF8A91A3-1093-431A-B43F-1C43EC83C408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
For solution [2], this is the behavior that=E2=80=99s = required for OIDC today, so I would say that=E2=80=99s the New Client = behaving like an Old Client in order to talk to an Old Server. So in = reality, (2) causes the request to be rejected, and that=E2=80=99s = OK.

I don=E2=80=99t think = it=E2=80=99s viable to require parameters to exist inside the request = object at all times. Nor should we try to enumerate which parameters go = inside and outside at all times =E2=80=94 at least from the JAR/OAuth = level of things. I think there are too many things that are application = and deployment specific for us to make this call. The very nature of the = request object changes for people =E2=80=94 some have a static object = that=E2=80=99s deployed with clients and some have something that the = client creates at runtime for each request. 

If the instead the New Server requires = that any parameters duplicated between the two places have to match (the = OIDC method) or that in a conflict the request object values take = precedence (the merge method), then problems 3-1 and 3-2 go = away. 

With= the merge-and-precedence behavior, which is what I thought that JAR had = during WGLC, [3-1] is well-defined. The request is processed the same = way every time because this is a New Server. The client is going to do = OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge = with precedence=E2=80=9D is effectively a no-op.

With the merge-and-precedence behavior, = [3-2] doesn=E2=80=99t happen because the required parameters aren=E2=80=99= t required to be in the request object itself. As long as the request = object is valid, it protects all parameters within it. I don=E2=80=99t = think it=E2=80=99s up to us to determine what makes sense to put in that = object. Security guidance is probably a good idea here.

Solution [3] is what Old = Clients already do in OIDC today, so that=E2=80=99s what already happens = and why problem space (3) isn=E2=80=99t a problem.

 =E2=80=94 = Justin

On Jan 2, 2020, at 12:24 PM, Takahiko = Kawasaki <taka@authlete.com> wrote:

Thank you, Justin. Actually, I = wanted to see someone write a summary about what happens in each = combination from a viewpoint of both RP and AS with regard to backward = compatibility (as I told you in other channel just before you posted = your email ^_^).

So,

(1) New Client + New Server
No = problem will happen.

(2) New = Client + Old Server
[Problem 2-1] If = an authorization request contains 'request' or 'request_uri' but doesn't = have old mandatory request parameters ('client_id' and 'response_type') = outside the request object, the request is rejected.

[Solution 2] New Client should include the = old mandatory request parameters duplicately outside the request object. = This means that New Client should always send old mandatory request = parameters duplicately outside the request object if it wants to get = maximum compatibility.

(3) = Old Client + New Server
[Problem = 3-1] If an authorization request contains 'request' or 'request_uri' = and some "optional" request parameters are not included in the request = object, AS will interpret the request differently. Imagine what happens = when optional parameters such as 'scope', 'state', 'nonce', = 'redirect_uri', 'response_mode', 'max_age', 'acr_values', = 'code_challenge', 'code_challenge_method' and 'prompt' are not included = in the request object but present outside the request object.

[Problem 3-2] If an = authorization request contains 'request' or 'request_uri' and some = "mandatory" request parameters ('client_id' and 'response_type') are not = included in the request object, the request is rejected.
[Solution 3] Old Client should include all = request parameters duplicately in the request object. This means that = Old Client should always include all request parameters duplicately in = the request object if it wants to get maximum compatibility.

(4) Old Client + Old = Server
No problem will happen.

- - -

=46rom a Client's point = of view, for maximum compatibility, both Old and New Clients should put = mandatory request parameters outside the request object and put all = request parameters duplicately inside the request object.

[Problem 3-1] is difficult to detect because = the authorization request is not rejected. But, if New Server requires = that all request parameters outside the request object be put inside the = request object duplicately, [Problem 3-1] is handled as an error and = thus client developers can detect the problem.

Consequently, introducing the following requirement in "FAPI = Part 2, 5.2.2, 10" to JAR seems a good = compromise (as I told before)

shall = require that all parameters are present inside the signed request object = passed in the request or request_uri parameter;

instead of just saying "the authorization server supporting = this specification MUST only use the parameters included in the request = object." which will bring about [Problem 3-1]. That is, how about adding = a rule like "if request parameters exist outside the request object, = they must exist inside the request object, too."?

Any thoughts?

Best,
Taka


On Fri, Jan = 3, 2020 at 12:48 AM Justin Richer <jricher@mit.edu> wrote:
I think the nature of the backwards = incompatibility is important here. The way that things are now, using = merge-with-precedence, you have the following matrix of = compatibility:


      =        New Server  |  Old Server =  |
-----------+-------------+--------------+
New Client |   =    YES    |      NO     =  |
Old Client |      YES    |   =   YES      |


If = you ask me, this is the right balance for a breaking change. Old = clients, where the vast majority of the code is, don=E2=80=99t have to = change. New clients can only talk to servers with the new features, = which is the ability to drop parameters from the external request. This = would apply to both OIDC and plain OAuth.

I think we should follow this kind of = pattern in the discussions on OAuth 2.1, which I think JAR should be a = part of/

 =E2=80=94 Justin



On Jan = 2, 2020, at 3:40 AM, Takahiko Kawasaki <taka@authlete.com> wrote:

Breaking backward compatibility = in this part would mean that OpenID Certification given to AS = implementations with request_uri support will be invalidated once they = support JAR. It also would mean that test cases in the official = conformance suite need to be changed in a backward-incompatible manner, = which would implicitly encourage that all certified implementations = should re-try to get certification.

Changing = the spec now might need more three to six months, but it would be worth = considering what we get and lose by saving the months and breaking = backward compatibility.

Best Regards,
Taka

On Wed, Dec = 18, 2019 at 4:14 PM Nat Sakimura <sakimura@gmail.com> wrote:
So, no = change is OK? 

On Wed, Dec 11, 2019 at 10:01 PM John = Bradley <ve7jtb@ve7jtb.com> wrote:
I also = slightly prefer the merge approach. 

There are plusses and = minuses to both. 

Changing again now that it = is past ISEG review and backing out a Discuss will add another three to = six months at this point, if we can get them to agree to the = change. 

John B. 

On Tue, Dec = 10, 2019, 11:29 PM Nat Sakimura <sakimura@gmail.com> wrote:
Correct. The WG supported the precedence = approach and even merge just like OIDC as it is very useful from the = implementation point of view and helps with a bunch of deployment = patter. 

The push back came in from = the Ben Campbell=E2=80=99s DISCUSS. 
See 
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current= -text-actually-specifies-the

I am willing to go either = way as long as people agree. My slight preference is to the original = approach. 

Best, 

Nat Sakimura

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 = Brian Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as = best I can remember the change in question came as I result of directorate/IESG review rather than a WG decision/discussion. = Which is likely why you can't find the "why" anywhere in the mailing = list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva.ip@gmail.com> wrote:
Well it kind of blows, doesn't it? I wasn't able to find the = "why" anywhere in the mailing list archive around the time this was = changed.

My = take on satisfying both worlds looks like this

- allow just JAR - no other params when = possible.
    (which btw isn't possible = to do with request_uri when enforcing client based uri whitelist and the = jwsreq 5.2.2 shows as much)
- enforce the "dupe = behaviours" defined in OIDC (if response_type or client_id is in request = object it must either be missing or the same in regular = request).
- allows merging request object and = regular parameters with request object taking precedence since it = is a very useful feature when having pre-signed request object that's = not one time use and clients using it wish to vary state/nonce = per-request.

I = wish the group reconsidered making this breaking change from OIDC's take = on request objects - allow combination of parameters from the request = object with ones from regular parameters (if not present in request = object).

S pozdravem,
Filip = Skokan


On Wed, 28 Aug 2019 at 23:02, Brian = Campbell <bcampbell@pingidentity.com> wrote:
<= div class=3D"gmail_quote">
Filip, for better or worse, I believe your assessment of the = situation is correct. I know of one AS that didn't choose which of the = two to follow but rather implemented a bit of a hybrid where it = basically ignores everything outside of the request object per JAR but = also checks for and enforces the presence and value of the few regular = parameters (client_id, response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Filip = Skokan <panva.ip@gmail.com> wrote:
Hello everyone,

in an earlier thread I've posed the = following question that might have gotten missed, this might have = consequences for the existing implementations of Request Objects in OIDC = implementations - its making pure JAR requests incompatible with OIDC = Core implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters = included in the request object
duplicated in the query = parameters as well for the backward
compatibility etc. =  However, the authorization server supporting this
specification MUST only use the parameters included in the = request
object. 

Server MUST only use the parameters = in the Request Object even if the
same parameter is = provided in the query parameter.  The = Authorization

The client MAY send the = parameters included in the request object
duplicated in = the query parameters as well for the backward
compatibility = etc.  However, the authorization server supporting = this
specification MUST only use the parameters included = in the request
object.. 

Nat, John, = everyone - does this mean a JAR compliant AS ignores = everything outside of the request object while OIDC Request Object one = merges the two with the ones in the request object being used over ones = that are sent in clear? The OIDC language also includes = sections which make sure that some required arguments are still passed = outside of the request object with the same value to make sure the = request is "valid" OAuth 2.0 request (client_id, response_type), = something which an example in the JAR spec does not do. Not having this = language means that existing authorization request pipelines can't = simply be extended with e.g. a middleware, they need to branch their = codepaths.

Is = an AS required to choose which of the two it follows?

Thank you for clarifying = this in advance. I think if either the behaviour is the same as in OIDC = or different this should be called out in the language to avoid = confusion, especially since this already exists in OIDC and likely isn't = going to be read in isolation, especially because the Request Object is = even called out to be already in place in OIDC in the JAR = draft.

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

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

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


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


= --Apple-Mail=_CF8A91A3-1093-431A-B43F-1C43EC83C408-- From nobody Thu Jan 2 13:53: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 5A0A81200A1 for ; Thu, 2 Jan 2020 13:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.397 X-Spam-Level: X-Spam-Status: No, score=-14.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI2Is9D1D9so for ; Thu, 2 Jan 2020 13:53:42 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6326120096 for ; Thu, 2 Jan 2020 13:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578002022; x=1609538022; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=g1Yw+vliNLYYlsdBfyUoiaKvPKjP7i06wzrnslgX2tI=; b=vHcSxOblHAmOSzq4GKtLKJuHkktnEQ2KA6c+2EK1o7buBjz9rNu9jnAQ k3DJOh0oHj5LPFx1lqVMiHHpeMFXhcYEX/qzI1A3DMYwIzshzUef4DJRn DFV/ZRRd29CIBhFXBquv8YVwf6FAOVHfLGDamfAPWB9lguOhbetTKSRix Q=; IronPort-SDR: QTDbFBL0ryi8u3cCR82bnpZTXDDJuF3Qqw3hnTx7GGX2GoCHV8lW0BeKXQ4EGQ4EGuFIOcb5tS X4/+3NJudO6Q== X-IronPort-AV: E=Sophos; i="5.69,388,1571702400"; d="scan'208,217"; a="10813434" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 02 Jan 2020 21:53:39 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS id 1D413281DB4; Thu, 2 Jan 2020 21:53:37 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 2 Jan 2020 21:53:37 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 2 Jan 2020 21:53:37 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 2 Jan 2020 21:53:37 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Brian Campbell , Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode Thread-Index: AQHVvPRXCtNcvfruAUeUuBSnRh/F5qfOcicAgAAnFYCAABBbgIAA40EAgABGo4CAB5qqAA== Date: Thu, 2 Jan 2020 21:53:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.118] Content-Type: multipart/alternative; boundary="_000_CC3574591DEA4EBBB603A399457DAB90amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Jan 2020 21:53:46 -0000 --_000_CC3574591DEA4EBBB603A399457DAB90amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4gYW5kIG90aGVycyB3aXRoIHNpbWlsYXIgdXNlIGNhc2VzIChGaWxpcD8pOg0KDQpUaGUg Y3VycmVudCB0ZXh0IGRvZXMgbm90IHByb2hpYml0IHlvdXIgYXBwcm9hY2gsIHByb3ZpZGVkIHlv deKAmXZlIGRvbmUgdGhlIGR1ZSBkaWxpZ2VuY2UgcmVxdWlyZWQgYnkgQkNQIDE0IHRvIGdvIGFn YWluc3QgYSBTSE9VTEQgTk9ULiBDb3VsZCB5b3UgcHJvdmlkZSBtb3JlIGRldGFpbCBvbiB0aGUg c2NlbmFyaW9zIHdoZXJlIHlvdSBoYXZlIG9wdGVkIHRvIHVzZSB0aGVzZSBpbXBsaWNpdC1iYXNl ZCBzb2x1dGlvbnM/IElzIGl0IGltcHJhY3RpY2FsIG9yIGluZmVhc2libGUgdG8gdXNlIGFuIGF1 dGhvcml6YXRpb24gY29kZS1iYXNlZCBhcHByb2FjaCBpbiB0aGVzZSBzY2VuYXJpb3M/IElmIHRo aXMgaXMgYSBwYXJ0aWN1bGFybHkgbmljaGUgdXNlIGNhc2UsIHRoZW4gaXQgbWF5IG5vdCBiZSB3 b3J0aCBpbmNsdWRpbmcgaW4gdGhlIEJDUCAodGhhdOKAmXMgYmFzaWNhbGx5IHdoYXQgU0hPVUxE IE5PVCBpcyBmb3IpLiBCdXQgaWYgaXTigJlzIG1vcmUgYnJvYWRseSBhcHBsaWNhYmxlLCB0aGVu IGl0IG1heSBiZSB3b3J0aCB0d2Vha2luZyB0aGUg4oCcdW5sZXNz4oCm4oCdIGNsYXVzZSBvZiB0 aGF0IHBhcmFncmFwaC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRl bnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPg0KRGF0ZTogU2F0dXJkYXksIERlY2VtYmVyIDI4LCAyMDE5IGF0IDk6NDcgQU0NClRvOiBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+LCBUb3JzdGVuIExvZGRl cnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPg0KQ2M6IG9h dXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtFWFRFUk5BTF0g LXNlY3VyaXR5LXRvcGljcy0xMyBhbmQgT0lEQyByZXNwb25zZSB0eXBlcyArIGZvcm1fcG9zdCBy ZXNwb25zZSBtb2RlDQoNCkkgYWdyZWUgd2l0aCBCcmlhbidzIHN1Z2dlc3RlZCB0ZXh0IGNoYW5n ZXMuDQotLSBNaWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KU2VudDogU2F0dXJkYXks IERlY2VtYmVyIDI4LCAyMDE5IDU6MzM6MjQgQU0NClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0 b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPg0KQ2M6IE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtFWFRFUk5BTF0gLXNlY3VyaXR5LXRvcGljcy0xMyBhbmQg T0lEQyByZXNwb25zZSB0eXBlcyArIGZvcm1fcG9zdCByZXNwb25zZSBtb2RlDQoNClRoZSByZXF1 aXJlbWVudCBmb3IgcmVwbGF5L2luamVjdGlvbiBwcmV2ZW50aW9uIGF0IHJlc291cmNlIHNlcnZl cnMgaXMgc3RpbGwgdGhlcmUgaW4gc2VjdGlvbiAzLjIuIFRoaXMgY2hhbmdlIG9ubHkgZHJvcHMg aXQgYXMgYSBzcGVjaWZpYyBxdWFsaWZpY2F0aW9uIG9uIHRoYXQgU0hPVUxEIE5PVCBmb3IgZmxv d3MgdGhhdCBzZW5kIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2Uu IEFuZCBpbnN0ZWFkIGZvY3VzZXMgdGhhdCBxdWFsaWZpY2F0aW9uIG9uIHRoZSBhZGRpdGlvbmFs IHJpc2tzIHRoYXQgY29tZSB3aXRoIHNlbmRpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgYXV0aG9y aXphdGlvbiByZXNwb25zZS4gVG8gbWUsIHRoaXMgZmVlbHMgbW9yZSBjb25zaXN0ZW50Lg0KDQpM b29raW5nIGFnYWluIGF0IHNlY3Rpb24gMywgSSdkIHN1Z2dlc3QgYWxzbyBtb3ZpbmcgdGhlIGZv dXJ0aCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzLjEuMiBpbnRvIHNlY3Rpb24gMy4yIHNvIHRoYXQg dGhlIGRlc2NyaXB0aW9uIG9mIHNlbmRlci1jb25zdHJhaW5lZCBpcyBpbiB0aGUgc3Vic2VjdGlv biB0aGF0IGlzIGFib3V0IHNlbmRlci1jb25zdHJhaW5pbmcuDQoNCk9uIEZyaSwgRGVjIDI3LCAy MDE5LCA1OjAwIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5u ZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3Jn Pj4gd3JvdGU6DQpZb3VyIHByb3Bvc2FsIHNvdW5kcyByZWFzb25hYmxlIG9uIGZpcnN0IHNpZ2h0 LiBCdXQgdGhpbmtpbmcgYWdhaW4sIGl0IHdvdWxkIG1lYW4gdG8ga2VlcCB0b2tlbiBpbmplY3Rp b24gcHJldmVudGlvbiBpbiBhdXRob3JpemF0aW9uIHJlc3BvbnNlcyBhIHJlcXVpcmVtZW50IHdo aWxlIGRyb3BwaW5nIHRoZSByZXF1aXJlbWVudCBmb3IgcmVwbGF5L2luamVjdGlvbiBwcmV2ZW50 aW9uIGF0IHJlc291cmNlIHNlcnZlcnMuIFRvIG1lIHRoaXMgZmVlbHMgaW5jb25zaXN0ZW50Lg0K DQoNCkFtIDI4Li4xMi4yMDE5IHVtIDAwOjAyIHNjaHJpZWIgQnJpYW4gQ2FtcGJlbGwgPGJjYW1w YmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+Og0KSSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQgaXQgc2hv dWxkIGJlIGEgcmVjb21tZW5kZWQgZmxvdy4gQnV0IHJlY29tbWVuZGluZyBhZ2FpbnN0IGl0LCBh cyB0aGUgdGV4dCBkb2VzIG5vdywgc2VlbXMgb3ZlcnJlYWNoaW5nIGFuZCB1bm5lY2Vzc2FyeS4g SSBrbm93ICpjb25zZW5zdXMqIHdhcyBwcmV2aW91c2x5IGZvdW5kIG9uIHRoZSB0ZXh0IGluIC0x MyBidXQgYmVzdCBJIGNhbiByZWNhbGwgdGhhdCBkaXNjdXNzaW9uIHdhcyBtb3N0bHkgYXJvdW5k IE5hdCBhZHZvY2F0aW5nIHRvIGFsbG93IHJvb20gZm9yIHNvbWUgZnV0dXJlIHNlbGYtaXNzdWVk IElEUCB0eXBlIGNhc2UgYW5kIHRoZSBjb252ZXJzYXRpb24ga2luZCBvZiBnb3QgaHVuZyB1cCBv biB0aGF0Lg0KDQpIZXJlJ3Mgc29tZSBwcm9wb3NlZCB0ZXh0LCB3aGljaCBJIHRoaW5rIHN0aWxs IGxhcmdlbHkgY2FwdHVyZXMgdGhlIGludGVudCBvZiB0aGUgQkNQIHdoaWxlIG5vdCBleHBsaWNp dGx5IHJlY29tbWVuZGluZyBhZ2FpbnN0IGxlZ2l0aW1hdGUgY2FzZXMgbGlrZSB0aGUgb25lIEkg YnJvdWdodCBoZXJlIG9yIE5hdCdzIG9yIHNvbWV0aGluZyBsaWtlIEpBUk0uDQoNCiAgIEluIG9y ZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1w bGljaXQNCiAgIGdyYW50IChyZXNwb25zZSB0eXBlICJ0b2tlbiIpIG9yIG90aGVyIHJlc3BvbnNl IHR5cGVzIGlzc3VpbmcNCiAgIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVz cG9uc2UsIHVubGVzcyBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uDQogICBpbiB0aGUgYXV0aG9yaXph dGlvbiByZXNwb25zZSBpcyBwcmV2ZW50ZWQgYW5kIHRoZSBhZm9yZW1lbnRpb25lZCB0b2tlbiBs ZWFrYWdlDQogICB2ZWN0b3JzIGFyZSBtaXRpZ2F0ZWQuDQoNClRoZSBkcmFmdCBhbHJlYWR5IHJl Y29tbWVuZHMgc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgZWxzZXdoZXJlIGluIHRo ZSBkb2N1bWVudC4gSXQgZG9lc24ndCBuZWVkIHRvIGJlIHJlcGVhdGVkIGFzIGEgcXVhbGlmeWlu ZyBjb25kaXRpb24gYXJvdW5kIHRoaXMgU0hPVUxEIE5PVC4NCg0KSSBhbSBhIHByb3BvbmVudCBv ZiBQb1AvSG9LL3NlbmRlci1jb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIChhcyBob3BlZnVsbHkg aXMgZXZpZGVudCBmcm9tIHNldmVyYWwgYXR0ZW1wdHMgYXQgYnJpbmdpbmcvZG9pbmcgcmVsYXRl ZCB3b3JrIGhlcmUpIGJ1dCBJIGRvIHdvcnJ5IHRoYXQgdGhlIHJlY29tbWVuZGF0aW9uIGluIHRo ZSBkcmFmdCBpcyBzdWZmaWNpZW50bHkgdW5hY2hpZXZhYmxlIHRvIHRoZSB2YXN0IG1ham9yaXR5 IHRoYXQgaXQgbWlnaHQgdW5kZXJtaW5lIHRoZSBjcmVkaWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQu IEJ1dCBJIGdldCB0aGUgYXNwaXJhdGlvbmFsIGFzcGVjdCBvZiBpdCBhbmQsIG90aGVyIHRoYW4g c29tZSBzdWdnZXN0ZWQgdHdlYWtzPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJj aCUyRm1zZyUyRm9hdXRoJTJGUkt1ak9OZWotOTJkVDVscjljTHU2aEhudzhJJmRhdGE9MDIlN0Mw MSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZmMyOGQ1MTNiMDRmNDg5YjM3MWQw OGQ3OGI5YTk0ODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM3MTMxMzY4MzQyMDk2OTIzJnNkYXRhPTNmQ0dqVE9BRDQzeFhMekZhdzNkNlZDMWtZNDNRdkJm ek53ZE5mRGNrRTAlM0QmcmVzZXJ2ZWQ9MD4sIGFtIHJlc2lnbmVkIHRvIHNlZSBpdCBzdGF5IGlu IHRoZSBkb2N1bWVudC4gQnV0IGxldCdzIGxldCB0aGF0IHJlY29tbWVuZGF0aW9uIHN0YW5kIG9u IGl0cyBvd24gaW4gdGhlIGRvY3VtZW50IGFuZCBub3QgYWxzbyB0aWUgaXQgdG8gb3RoZXIgY29u c2lkZXJhdGlvbnMuDQoNCg0KT24gRnJpLCBEZWMgMjcsIDIwMTkgYXQgMTo0MSBQTSBUb3JzdGVu IExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KQXMgQnJpYW4g c2FpZCwgd2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBzZXZlcmFsIHRpbWVzIGFuZCB0aGlzIHRleHQg Zm91bmQgY29uc2Vuc3VzLg0KDQpVc2luZyBwb3N0IHJlZHVjZXMgdGhlIGF0dGFjayBzdXJmYWNl IGJ1dCBkb2VzIG5vdCBhbGxvdyB0byBiaW5kIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGxlZ2l0 aW1hdGUgY2xpZW50LiBXZSBhcmUgcmVjb21tZW5kaW5nIHNlbmRlciBjb25zdHJhaW5lZCBhY2Nl c3MgdG9rZW5zIGluIHRoZSBCQ1AuIFNvIHJlY29tbWVuZGluZyBhIGZsb3cgdGhhdCBkb2VzIG5v dCBzdXBwb3J0IHNlbmRlciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGlzIGEgY29udHJhZGlj dGlvbi4NCg0KV2hhdCBkbyBvdGhlciBXRyBtZW1iZXJzIHRoaW5rPw0KDQoNCkFtIDI3LjEyLjIw MTkgdW0gMjE6Mjggc2NocmllYiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn Pj46DQpJIGFncmVlIHdpdGggQnJpYW4uIFBsZWFzZSB1cGRhdGUgdGhlIHRleHQgdG8gZGVzY3Jp YmUgdGhpcyBhbHJlYWR5IHNhZmUgdXNhZ2UuDQotLSBNaWtlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDI3LCAy MDE5IDExOjAzOjMwIEFNDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFtPQVVUSC1XR10gLXNlY3VyaXR5LXRvcGlj cy0xMyBhbmQgT0lEQyByZXNwb25zZSB0eXBlcyArIGZvcm1fcG9zdCByZXNwb25zZSBtb2RlDQoN CldlIGhhdmUgYS1zb21ldGltZXMgdXNlZCBzY2VuYXJpbyB3aGVyZSBhIGNsaWVudCBtYWtlcyBh biBhdXRob3JpemF0aW9uL2F1dGhlbnRpY2F0aW9uIHJlcXVlc3Qgd2l0aCBhICJ0b2tlbiBpZF90 b2tlbiIgcmVzcG9uc2UgdHlwZSBhbmQgImZvcm1fcG9zdCIgcmVzcG9uc2UgbW9kZSAobm9uY2Ug aXMgYWxzbyBzZW50IGFuZCBleGFjdCByZWRpcmVjdCBVUkkgbWF0Y2hpbmcgaXMgZG9uZSBhdCB0 aGUgQVMpLiBUaGUgYWNjZXNzIHRva2VuIGlzIG5ldmVyIGV4cG9zZWQgaW4gYW55IFVSTHMgYW5k IGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaXMgcHJldmVudGVkIGJ5IHRoZSBhdF9oYXNoIGNsYWlt IGluIHRoZSBpZCB0b2tlbi4NCg0KVGhhdCBzZWVtcyB0byBtZSBsaWtlIGEgbGVnaXRpbWF0ZSBh bmQgcmVhc29uYWJsZSB1c2FnZSBzY2VuYXJpby4gSG93ZXZlciwgaXQgd291bGQgZmFsbCBvbiB0 aGUgd3Jvbmcgc2lkZSBvZiB0aGUgU0hPVUxEIE5PVCBpbiBTZWN0aW9uIDMuMS4yIG9mIHRoZSBT ZWN1cml0eSBCQ1AtdG8tYmU8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQt aWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTMlMjNzZWN0aW9uLTMuLi4xLi4yJmRhdGE9MDIl N0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZmMyOGQ1MTNiMDRmNDg5YjM3 MWQwOGQ3OGI5YTk0ODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MTMxMzY4MzQyMDk2OTIzJnNkYXRhPW1mblF3c0dVWmd6MFBnRVpvcU9sJTJCc3N6UFl4 bmNtRmJnQmFKczRxZXgzOCUzRCZyZXNlcnZlZD0wPiwgd2hpY2ggaGFzOg0KDQogICBJbiBvcmRl ciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIGNsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxp Y2l0DQogICBncmFudCAocmVzcG9uc2UgdHlwZSAidG9rZW4iKSBvciBhbnkgb3RoZXIgcmVzcG9u c2UgdHlwZSBpc3N1aW5nDQogICBhY2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJl c3BvbnNlLCBzdWNoIGFzICJ0b2tlbiBpZF90b2tlbiINCiAgIGFuZCAiY29kZSB0b2tlbiBpZF90 b2tlbiIsIHVubGVzcyB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlDQogICBzZW5kZXItY29u c3RyYWluZWQgYW5kIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaW4gdGhlIGF1dGhvcml6YXRpb24N CiAgIHJlc3BvbnNlIGlzIHByZXZlbnRlZC4NCg0KSSBrbm93IHRoaXMgcGFydGljdWxhciB0ZXh0 IGhhcyBiZWVuIGRpc2N1c3NlZCBvdmVyIGFuZCBvdmVyIGFnYWluIHNvIEkgaGF0ZSB0byByZXZp c2l0IGl0LiBCdXQgYmFzZWQgb24gdGhlIGFmb3JlbWVudGlvbmVkIHNjZW5hcmlvIEkgdGhpbmsg bWF5YmUgaXQgc3RpbGwgZG9lc24ndCBxdWl0ZSBoaXQgdGhlIG1hcmsuIEFjY2VzcyB0b2tlbiBp bmplY3Rpb24gaXMgcHJldmVudGVkLiBUaGUgdG9rZW4gbGVha2FnZSBzY2VuYXJpb3MgbWVudGlv bmVkIGluIHRoYXQgc2VjdGlvbiBhcmUgYWxsIGF2b2lkZWQuIEFuZCB3aGlsZSBJIGtub3cgc2Vu ZGVyLWNvbnN0cmFpbmVkIGlzIHJlY29tbWVuZGVkIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQsIGl0 J3Mgbm90IHJlYWxseSBhIHJlYWxpc3RpYyBvcHRpb24gZm9yIHRoZSBtYWpvcml0eSBvZiBkZXBs b3ltZW50cy4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN0NmYzI4ZDUxM2IwNGY0ODliMzcxZDA4ZDc4YjlhOTQ4OCU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxMzEzNjgzNDIx MDY4OTEmc2RhdGE9cU82JTJCWSUyRk1vZWYwbHl4NEh3TkxWOElENURndUFlM1hqQ1F5eHR2b0Zy UG8lM0QmcmVzZXJ2ZWQ9MD4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ug YW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_CC3574591DEA4EBBB603A399457DAB90amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6390CA9C8BE05A49BEF98DB4CA2895CA@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QnJpYW4gYW5kIG90aGVycyB3aXRoIHNpbWlsYXIgdXNlIGNhc2VzIChGaWxp cD8pOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCB0ZXh0IGRvZXMgbm90IHBy b2hpYml0IHlvdXIgYXBwcm9hY2gsIHByb3ZpZGVkIHlvdeKAmXZlIGRvbmUgdGhlIGR1ZSBkaWxp Z2VuY2UgcmVxdWlyZWQgYnkgQkNQIDE0IHRvIGdvIGFnYWluc3QgYSBTSE9VTEQgTk9ULiBDb3Vs ZCB5b3UgcHJvdmlkZSBtb3JlIGRldGFpbCBvbiB0aGUgc2NlbmFyaW9zIHdoZXJlIHlvdSBoYXZl IG9wdGVkIHRvIHVzZSB0aGVzZSBpbXBsaWNpdC1iYXNlZCBzb2x1dGlvbnM/DQogSXMgaXQgaW1w cmFjdGljYWwgb3IgaW5mZWFzaWJsZSB0byB1c2UgYW4gYXV0aG9yaXphdGlvbiBjb2RlLWJhc2Vk IGFwcHJvYWNoIGluIHRoZXNlIHNjZW5hcmlvcz8gSWYgdGhpcyBpcyBhIHBhcnRpY3VsYXJseSBu aWNoZSB1c2UgY2FzZSwgdGhlbiBpdCBtYXkgbm90IGJlIHdvcnRoIGluY2x1ZGluZyBpbiB0aGUg QkNQICh0aGF04oCZcyBiYXNpY2FsbHkgd2hhdCBTSE9VTEQgTk9UIGlzIGZvcikuIEJ1dCBpZiBp dOKAmXMgbW9yZSBicm9hZGx5IGFwcGxpY2FibGUsDQogdGhlbiBpdCBtYXkgYmUgd29ydGggdHdl YWtpbmcgdGhlIOKAnHVubGVzc+KApuKAnSBjbGF1c2Ugb2YgdGhhdCBwYXJhZ3JhcGguPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ 4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBEZWNlbWJlciAyOCwg MjAxOSBhdCA5OjQ3IEFNPGJyPg0KPGI+VG86IDwvYj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7LCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVu PTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1 dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRI LVdHXSBbRVhURVJOQUxdIC1zZWN1cml0eS10b3BpY3MtMTMgYW5kIE9JREMgcmVzcG9uc2UgdHlw ZXMgJiM0MzsgZm9ybV9wb3N0IHJlc3BvbnNlIG1vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0aCBCcmlhbidzIHN1Z2dlc3RlZCB0ZXh0IGNo YW5nZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPi0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2 Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7 PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAyOCwgMjAxOSA1OjMzOjI0IEFN PGJyPg0KPGI+VG86PC9iPiBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuPTQwbG9kZGVy c3RlZHQubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAm bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGggJmx0O29hdXRoQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBbRVhURVJOQUxdIC1z ZWN1cml0eS10b3BpY3MtMTMgYW5kIE9JREMgcmVzcG9uc2UgdHlwZXMgJiM0MzsgZm9ybV9wb3N0 IHJlc3BvbnNlIG1vZGU8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVxdWlyZW1lbnQgZm9yIHJl cGxheS9pbmplY3Rpb24gcHJldmVudGlvbiBhdCByZXNvdXJjZSBzZXJ2ZXJzIGlzIHN0aWxsIHRo ZXJlIGluIHNlY3Rpb24gMy4yLiBUaGlzIGNoYW5nZSBvbmx5IGRyb3BzIGl0IGFzIGEgc3BlY2lm aWMgcXVhbGlmaWNhdGlvbiBvbiB0aGF0IFNIT1VMRCBOT1QgZm9yIGZsb3dzIHRoYXQgc2VuZCBh Y2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLg0KIEFuZCBpbnN0ZWFk IGZvY3VzZXMgdGhhdCBxdWFsaWZpY2F0aW9uIG9uIHRoZSBhZGRpdGlvbmFsIHJpc2tzIHRoYXQg Y29tZSB3aXRoIHNlbmRpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNw b25zZS4gVG8gbWUsIHRoaXMgZmVlbHMgbW9yZSBjb25zaXN0ZW50LiZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgYWdh aW4gYXQgc2VjdGlvbiAzLCBJJ2Qgc3VnZ2VzdCBhbHNvIG1vdmluZyB0aGUgZm91cnRoIHBhcmFn cmFwaCBvZiBzZWN0aW9uIDMuMS4yIGludG8gc2VjdGlvbiAzLjIgc28gdGhhdCB0aGUgZGVzY3Jp cHRpb24gb2Ygc2VuZGVyLWNvbnN0cmFpbmVkIGlzIGluIHRoZSBzdWJzZWN0aW9uIHRoYXQgaXMg YWJvdXQgc2VuZGVyLWNvbnN0cmFpbmluZy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgMjcsIDIwMTksIDU6MDAgUE0gVG9yc3RlbiBM b2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRA ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WW91ciBwcm9wb3NhbCBzb3VuZHMgcmVhc29uYWJsZSBvbiBmaXJz dCBzaWdodC4gQnV0IHRoaW5raW5nIGFnYWluLCBpdCB3b3VsZCBtZWFuIHRvIGtlZXAgdG9rZW4g aW5qZWN0aW9uIHByZXZlbnRpb24gaW4gYXV0aG9yaXphdGlvbiByZXNwb25zZXMgYSByZXF1aXJl bWVudCB3aGlsZSBkcm9wcGluZyB0aGUgcmVxdWlyZW1lbnQgZm9yIHJlcGxheS9pbmplY3Rpb24g cHJldmVudGlvbiBhdCByZXNvdXJjZSBzZXJ2ZXJzLg0KIFRvIG1lIHRoaXMgZmVlbHMgaW5jb25z aXN0ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW0gMjguLjEyLjIwMTkgdW0gMDA6MDIgc2Nocmll YiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVu dGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20g bm90IHN1Z2dlc3RpbmcgdGhhdCBpdCBzaG91bGQgYmUgYSByZWNvbW1lbmRlZCBmbG93LiBCdXQg cmVjb21tZW5kaW5nIGFnYWluc3QgaXQsIGFzIHRoZSB0ZXh0IGRvZXMgbm93LCBzZWVtcyBvdmVy cmVhY2hpbmcgYW5kIHVubmVjZXNzYXJ5LiBJIGtub3cgKmNvbnNlbnN1cyogd2FzIHByZXZpb3Vz bHkgZm91bmQgb24gdGhlIHRleHQgaW4gLTEzIGJ1dCBiZXN0IEkgY2FuIHJlY2FsbCB0aGF0IGRp c2N1c3Npb24NCiB3YXMgbW9zdGx5IGFyb3VuZCBOYXQgYWR2b2NhdGluZyB0byBhbGxvdyByb29t IGZvciBzb21lIGZ1dHVyZSBzZWxmLWlzc3VlZCBJRFAgdHlwZSBjYXNlIGFuZCB0aGUgY29udmVy c2F0aW9uIGtpbmQgb2YgZ290IGh1bmcgdXAgb24gdGhhdC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlJ3Mgc29tZSBwcm9wb3NlZCB0 ZXh0LCB3aGljaCBJIHRoaW5rIHN0aWxsIGxhcmdlbHkgY2FwdHVyZXMgdGhlIGludGVudCBvZiB0 aGUgQkNQIHdoaWxlIG5vdCBleHBsaWNpdGx5IHJlY29tbWVuZGluZyBhZ2FpbnN0IGxlZ2l0aW1h dGUgY2FzZXMgbGlrZSB0aGUgb25lIEkgYnJvdWdodCBoZXJlIG9yIE5hdCdzIG9yIHNvbWV0aGlu ZyBsaWtlIEpBUk0uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3Vlcywg Y2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQombmJzcDsgJm5ic3A7Z3Jh bnQgKHJlc3BvbnNlIHR5cGUgJnF1b3Q7dG9rZW4mcXVvdDspIG9yIG90aGVyIHJlc3BvbnNlIHR5 cGVzIGlzc3Vpbmc8YnI+DQombmJzcDsgJm5ic3A7YWNjZXNzIHRva2VucyBpbiB0aGUgYXV0aG9y aXphdGlvbiByZXNwb25zZSwgdW5sZXNzIGFjY2VzcyB0b2tlbiBpbmplY3Rpb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBp biB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBpcyBwcmV2ZW50ZWQgYW5kIHRoZSBhZm9yZW1l bnRpb25lZCB0b2tlbiBsZWFrYWdlDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB2ZWN0b3JzIGFyZSBtaXRpZ2F0ZWQuIDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg ZHJhZnQgYWxyZWFkeSByZWNvbW1lbmRzIHNlbmRlci1jb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5z IGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQuIEl0IGRvZXNuJ3QgbmVlZCB0byBiZSByZXBlYXRl ZCBhcyBhIHF1YWxpZnlpbmcgY29uZGl0aW9uIGFyb3VuZCB0aGlzIFNIT1VMRCBOT1QuDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBh IHByb3BvbmVudCBvZiBQb1AvSG9LL3NlbmRlci1jb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIChh cyBob3BlZnVsbHkgaXMgZXZpZGVudCBmcm9tIHNldmVyYWwgYXR0ZW1wdHMgYXQgYnJpbmdpbmcv ZG9pbmcgcmVsYXRlZCB3b3JrIGhlcmUpIGJ1dCBJIGRvIHdvcnJ5IHRoYXQgdGhlIHJlY29tbWVu ZGF0aW9uIGluIHRoZSBkcmFmdCBpcyBzdWZmaWNpZW50bHkgdW5hY2hpZXZhYmxlIHRvIHRoZSB2 YXN0DQogbWFqb3JpdHkgdGhhdCBpdCBtaWdodCB1bmRlcm1pbmUgdGhlIGNyZWRpYmlsaXR5IG9m IHRoZSBkb2N1bWVudC4gQnV0IEkgZ2V0IHRoZSBhc3BpcmF0aW9uYWwgYXNwZWN0IG9mIGl0IGFu ZCwgb3RoZXIgdGhhbg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZh cmNoJTJGbXNnJTJGb2F1dGglMkZSS3VqT05lai05MmRUNWxyOWNMdTZoSG53OEkmYW1wO2RhdGE9 MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZmMyOGQ1MTNiMDRmNDg5 YjM3MWQwOGQ3OGI5YTk0ODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MTMxMzY4MzQyMDk2OTIzJmFtcDtzZGF0YT0zZkNHalRPQUQ0M3hYTHpGYXczZDZW QzFrWTQzUXZCZnpOd2ROZkRja0UwJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ DQpzb21lIHN1Z2dlc3RlZCB0d2Vha3M8L2E+LCBhbSByZXNpZ25lZCB0byBzZWUgaXQgc3RheSBp biB0aGUgZG9jdW1lbnQuIEJ1dCBsZXQncyBsZXQgdGhhdCByZWNvbW1lbmRhdGlvbiBzdGFuZCBv biBpdHMgb3duIGluIHRoZSBkb2N1bWVudCBhbmQgbm90IGFsc28gdGllIGl0IHRvIG90aGVyIGNv bnNpZGVyYXRpb25zLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDI3LCAyMDE5IGF0IDE6NDEgUE0gVG9yc3RlbiBMb2Rk ZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgQnJpYW4gc2FpZCwgd2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBzZXZl cmFsIHRpbWVzIGFuZCB0aGlzIHRleHQgZm91bmQgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2luZyBwb3N0IHJlZHVjZXMg dGhlIGF0dGFjayBzdXJmYWNlIGJ1dCBkb2VzIG5vdCBhbGxvdyB0byBiaW5kIHRoZSBhY2Nlc3Mg dG9rZW4gdG8gdGhlIGxlZ2l0aW1hdGUgY2xpZW50LiBXZSBhcmUgcmVjb21tZW5kaW5nIHNlbmRl ciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGluIHRoZSBCQ1AuIFNvIHJlY29tbWVuZGluZyBh IGZsb3cgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IHNlbmRlciBjb25zdHJhaW5lZA0KIGFjY2VzcyB0 b2tlbnMgaXMgYSBjb250cmFkaWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvIG90aGVyIFdHIG1lbWJlcnMgdGhpbms/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5BbSAyNy4xMi4yMDE5IHVtIDIxOjI4IHNjaHJpZWIgTWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5JIGFncmVlIHdpdGggQnJpYW4uIFBsZWFzZSB1cGRhdGUgdGhlIHRleHQgdG8g ZGVzY3JpYmUgdGhpcyBhbHJlYWR5IHNhZmUgdXNhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPg0KPGhyIHNpemU9IjAiIHdpZHRoPSI2NSUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ4X2dtYWlsLW1fMTk2NDMxMzUwMDEzNDEyMTI4M21fMzA3MjM5NTE1NDE0OTUy OTYyMW1fNTgxNTM5ODQxOTA5NDg3NjgxbV8tOTE0MTg1Mjg1MDQ1NTUzOTUwMG1fMzgzMjMyOTY5 NTMwOTk4NTgxNGdtYWlsLW1fMjgzNDc5NTczNjA1NTY2NTEwMGRpdlJwbHlGd2RNc2ciPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gT0F1dGggJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IG9uIGJlaGFs ZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTwvc3Bhbj48YSBocmVmPSJtYWlsdG86 NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDI3LCAyMDE5IDExOjAzOjMw IEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFtPQVVU SC1XR10gLXNlY3VyaXR5LXRvcGljcy0xMyBhbmQgT0lEQyByZXNwb25zZSB0eXBlcyAmIzQzOyBm b3JtX3Bvc3QgcmVzcG9uc2UgbW9kZTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgYS1zb21l dGltZXMgdXNlZCBzY2VuYXJpbyB3aGVyZSBhIGNsaWVudCBtYWtlcyBhbiBhdXRob3JpemF0aW9u L2F1dGhlbnRpY2F0aW9uIHJlcXVlc3Qgd2l0aCBhICZxdW90O3Rva2VuIGlkX3Rva2VuJnF1b3Q7 IHJlc3BvbnNlIHR5cGUgYW5kICZxdW90O2Zvcm1fcG9zdCZxdW90OyByZXNwb25zZSBtb2RlIChu b25jZSBpcyBhbHNvIHNlbnQgYW5kIGV4YWN0IHJlZGlyZWN0IFVSSSBtYXRjaGluZyBpcyBkb25l IGF0IHRoZSBBUykuIFRoZQ0KIGFjY2VzcyB0b2tlbiBpcyBuZXZlciBleHBvc2VkIGluIGFueSBV UkxzIGFuZCBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGlzIHByZXZlbnRlZCBieSB0aGUgYXRfaGFz aCBjbGFpbSBpbiB0aGUgaWQgdG9rZW4uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzZWVtcyB0byBtZSBsaWtlIGEgbGVnaXRpbWF0 ZSBhbmQgcmVhc29uYWJsZSB1c2FnZSBzY2VuYXJpby4gSG93ZXZlciwgaXQgd291bGQgZmFsbCBv biB0aGUgd3Jvbmcgc2lkZSBvZiB0aGUgU0hPVUxEIE5PVCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mt MTMlMjNzZWN0aW9uLTMuLi4xLi4yJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQw bWljcm9zb2Z0LmNvbSU3Q2ZjMjhkNTEzYjA0ZjQ4OWIzNzFkMDhkNzhiOWE5NDg4JTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzEzMTM2ODM0MjA5NjkyMyZh bXA7c2RhdGE9bWZuUXdzR1VaZ3owUGdFWm9xT2wlMkJzc3pQWXhuY21GYmdCYUpzNHFleDM4JTNE JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpTZWN0aW9uIDMuMS4yIG9mIHRoZSBT ZWN1cml0eSBCQ1AtdG8tYmU8L2E+LCB3aGljaCBoYXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1 ZXMsIGNsaWVudHMgU0hPVUxEIE5PVCB1c2UgdGhlIGltcGxpY2l0PGJyPg0KJm5ic3A7ICZuYnNw O2dyYW50IChyZXNwb25zZSB0eXBlICZxdW90O3Rva2VuJnF1b3Q7KSBvciBhbnkgb3RoZXIgcmVz cG9uc2UgdHlwZSBpc3N1aW5nPGJyPg0KJm5ic3A7ICZuYnNwO2FjY2VzcyB0b2tlbnMgaW4gdGhl IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHN1Y2ggYXMgJnF1b3Q7dG9rZW4gaWRfdG9rZW4mcXVv dDs8YnI+DQombmJzcDsgJm5ic3A7YW5kICZxdW90O2NvZGUgdG9rZW4gaWRfdG9rZW4mcXVvdDss IHVubGVzcyB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbnMgYXJlPGJyPg0KJm5ic3A7ICZuYnNwO3Nl bmRlci1jb25zdHJhaW5lZCBhbmQgYWNjZXNzIHRva2VuIGluamVjdGlvbiBpbiB0aGUgYXV0aG9y aXphdGlvbjxicj4NCiZuYnNwOyAmbmJzcDtyZXNwb25zZSBpcyBwcmV2ZW50ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkga25vdyB0aGlz IHBhcnRpY3VsYXIgdGV4dCBoYXMgYmVlbiBkaXNjdXNzZWQgb3ZlciBhbmQgb3ZlciBhZ2FpbiBz byBJIGhhdGUgdG8gcmV2aXNpdCBpdC4gQnV0IGJhc2VkIG9uIHRoZSBhZm9yZW1lbnRpb25lZCBz Y2VuYXJpbyBJIHRoaW5rIG1heWJlIGl0IHN0aWxsIGRvZXNuJ3QgcXVpdGUgaGl0IHRoZSBtYXJr LiBBY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGlzIHByZXZlbnRlZC4gVGhlIHRva2VuIGxlYWthZ2UN CiBzY2VuYXJpb3MgbWVudGlvbmVkIGluIHRoYXQgc2VjdGlvbiBhcmUgYWxsIGF2b2lkZWQuIEFu ZCB3aGlsZSBJIGtub3cgc2VuZGVyLWNvbnN0cmFpbmVkIGlzIHJlY29tbWVuZGVkIGVsc2V3aGVy ZSBpbiB0aGUgZHJhZnQsIGl0J3Mgbm90IHJlYWxseSBhIHJlYWxpc3RpYyBvcHRpb24gZm9yIHRo ZSBtYWpvcml0eSBvZiBkZXBsb3ltZW50cy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBv ciBkaXNjbG9zdXJlDQogYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIl N0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZmMyOGQ1MTNiMDRmNDg5YjM3 MWQwOGQ3OGI5YTk0ODglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MTMxMzY4MzQyMTA2ODkxJmFtcDtzZGF0YT1xTzYlMkJZJTJGTW9lZjBseXg0SHdOTFY4 SUQ1RGd1QWUzWGpDUXl4dHZvRnJQbyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlDQogYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu LiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRp c2Nsb3N1cmUNCiBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ug YW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwv c3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CC3574591DEA4EBBB603A399457DAB90amazoncom_-- From nobody Fri Jan 3 02:34:06 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 36D0612008C for ; Fri, 3 Jan 2020 02:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OgIkZxvnExw for ; Fri, 3 Jan 2020 02:34:01 -0800 (PST) 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 D1DD812001E for ; Fri, 3 Jan 2020 02:34:00 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id z7so41888045wrl.13 for ; Fri, 03 Jan 2020 02:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oJev75c3a3ejpkbD8cZzdDZJEa7XK7rf/tzk8gcu0xk=; b=g8lbQZz3kgS8FW033xyoeWjuP7166KM6jJ3funxP+Gqbmy5mF3yoMGy3XSZQLKGLbF 2FVCjxEOpem4XGlfAN/qmcKEzxk2g89paf1n4Pwm61WRsOHdRE7SRS9Ia7u1Ze/TQBDp Y2oFy6dmo8jYiUNH1qJeiPtcKt2JdA5A8fQFvcnw+oDbZjPk43ssLi6E2LNmqiIVqzgE 4JMk/pzOrjv5iAns66TmYadbp8hc6YsRqHuQKvwuOmnNTpzA2JzrbJqo2Nteih/Yd5P0 ZgroDcZ+ahK9DeK0sIdf8Qs+F/gtzWoKGhwXotk80wjKD+ls0MSdnabk9bK/X4WjOW/9 CfPw== 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=oJev75c3a3ejpkbD8cZzdDZJEa7XK7rf/tzk8gcu0xk=; b=HsQsdJ1b40rvN309z6jVMuX1bGFoDEWr+YpmS8719nT/AYdvDRSMtywl4m7G2KUBaX zwFES012cf1ZIsr7sReQvQFpsDkw/+VyzaqunwZdLlftkrdRm3jPLgY2wfhEPiiwnZyX JDzgYhkBtUXSCcoPOWF9gGq5LMk4Vym/9TVVx3XG/uyRRjXYOyUtCaGxFvUEjUeN/kHh RjdSnb9VbFFO1pqqOoqKAH0fPn9ZKGFnjN/3/bEketfXwPIS+gvNKR9J9QdLHtsdYIl7 GoLSq+hsqRHWMmgjeae2bXNHPtz0yr09ay3l4uXBsGCSxB+J4+Ng6taCX0zwqRDJ77/j NOcg== X-Gm-Message-State: APjAAAXll9gYqDk083Qm2qzL+spvHTLLqy1t2aeq/G4IbdjI3rhnLOgL /85EQrsXZgwDuMZgsT4XMaRQYA== X-Google-Smtp-Source: APXvYqyPcCwM5r6K3SQUhsXmsligt0A6qoHbGKK/ZsaEgGm8JhYmphv3qWv/nA0MMAddiz0WFLGiGQ== X-Received: by 2002:adf:fcc4:: with SMTP id f4mr87752851wrs.247.1578047639230; Fri, 03 Jan 2020 02:33:59 -0800 (PST) Received: from p200300eb8f1a505f5c038d91bc749858.dip0.t-ipconnect.de (p200300EB8F1A505F5C038D91BC749858.dip0.t-ipconnect.de. [2003:eb:8f1a:505f:5c03:8d91:bc74:9858]) by smtp.gmail.com with ESMTPSA id t190sm11471131wmt.44.2020.01.03.02.33.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 02:33:58 -0800 (PST) From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_67004322-BA92-440D-9E32-D6974B819C24"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Fri, 3 Jan 2020 11:33:26 +0100 In-Reply-To: Cc: Mike Jones , oauth , "Richard Backman, Annabelle" To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Jan 2020 10:34:04 -0000 --Apple-Mail=_67004322-BA92-440D-9E32-D6974B819C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian,=20 I=E2=80=99m on the fence regarding your proposal.=20 What I like is it moves the focus onto leakage prevention and prevention = of injection in the authorization response, which are the direct threats = to the front channel flow. Especially token leakage prevention somehow = got lost in the process.=20 Beside this, your proposal does not change the meaning of the spec since = sender constrained access tokens are still recommended through 3.2.=20 I=E2=80=99m not sure it is worth the change now taking into account how = much energy it has cost to come up with a consensus for this piece of = text. I would encourage more WG members to share their thoughts.=20 best regards, Torsten.=20 > On 2. Jan 2020, at 22:53, Richard Backman, Annabelle = wrote: >=20 > Brian and others with similar use cases (Filip?): > =20 > The current text does not prohibit your approach, provided you=E2=80=99v= e done the due diligence required by BCP 14 to go against a SHOULD NOT. = Could you provide more detail on the scenarios where you have opted to = use these implicit-based solutions? Is it impractical or infeasible to = use an authorization code-based approach in these scenarios? If this is = a particularly niche use case, then it may not be worth including in the = BCP (that=E2=80=99s basically what SHOULD NOT is for). But if it=E2=80=99s= more broadly applicable, then it may be worth tweaking the = =E2=80=9Cunless=E2=80=A6=E2=80=9D clause of that paragraph. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Mike Jones = > Date: Saturday, December 28, 2019 at 9:47 AM > To: Brian Campbell , Torsten Lodderstedt = > Cc: oauth > Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC = response types + form_post response mode > =20 > I agree with Brian's suggested text changes. >=20 > -- Mike > From: Brian Campbell > Sent: Saturday, December 28, 2019 5:33:24 AM > To: Torsten Lodderstedt > Cc: Mike Jones ; oauth > Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC = response types + form_post response mode > =20 > The requirement for replay/injection prevention at resource servers is = still there in section 3.2. This change only drops it as a specific = qualification on that SHOULD NOT for flows that send access tokens in = the authorization response. And instead focuses that qualification on = the additional risks that come with sending access tokens in the = authorization response. To me, this feels more consistent.=20 > =20 > Looking again at section 3, I'd suggest also moving the fourth = paragraph of section 3.1.2 into section 3.2 so that the description of = sender-constrained is in the subsection that is about = sender-constraining.=20 > =20 >=20 > On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt = wrote: >> Your proposal sounds reasonable on first sight. But thinking again, = it would mean to keep token injection prevention in authorization = responses a requirement while dropping the requirement for = replay/injection prevention at resource servers. To me this feels = inconsistent. >>=20 >>=20 >>> Am 28..12.2019 um 00:02 schrieb Brian Campbell = : >>>=20 >>> I'm not suggesting that it should be a recommended flow. But = recommending against it, as the text does now, seems overreaching and = unnecessary. I know *consensus* was previously found on the text in -13 = but best I can recall that discussion was mostly around Nat advocating = to allow room for some future self-issued IDP type case and the = conversation kind of got hung up on that. >>> =20 >>> Here's some proposed text, which I think still largely captures the = intent of the BCP while not explicitly recommending against legitimate = cases like the one I brought here or Nat's or something like JARM. >>> =20 >>> In order to avoid these issues, clients SHOULD NOT use the = implicit >>> grant (response type "token") or other response types issuing >>> access tokens in the authorization response, unless access token = injection >>> in the authorization response is prevented and the aforementioned = token leakage >>> vectors are mitigated.=20 >>> =20 >>> The draft already recommends sender-constrained access tokens = elsewhere in the document. It doesn't need to be repeated as a = qualifying condition around this SHOULD NOT. >>> =20 >>> I am a proponent of PoP/HoK/sender-constrained access tokens (as = hopefully is evident from several attempts at bringing/doing related = work here) but I do worry that the recommendation in the draft is = sufficiently unachievable to the vast majority that it might undermine = the credibility of the document. But I get the aspirational aspect of it = and, other thansome suggested tweaks, am resigned to see it stay in the = document. But let's let that recommendation stand on its own in the = document and not also tie it to other considerations.=20 >>> =20 >>> =20 >>> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt = wrote: >>>> As Brian said, we have discussed this several times and this text = found consensus. >>>> =20 >>>> Using post reduces the attack surface but does not allow to bind = the access token to the legitimate client. We are recommending sender = constrained access tokens in the BCP. So recommending a flow that does = not support sender constrained access tokens is a contradiction. >>>> =20 >>>> What do other WG members think? >>>>=20 >>>>=20 >>>>> Am 27.12.2019 um 21:28 schrieb Mike Jones = : >>>>>=20 >>>>> I agree with Brian. Please update the text to describe this = already safe usage. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> From: OAuth on behalf of Brian Campbell = >>>>> Sent: Friday, December 27, 2019 11:03:30 AM >>>>> To: oauth >>>>> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC = response types + form_post response mode >>>>> =20 >>>>> We have a-sometimes used scenario where a client makes an = authorization/authentication request with a "token id_token" response = type and "form_post" response mode (nonce is also sent and exact = redirect URI matching is done at the AS). The access token is never = exposed in any URLs and access token injection is prevented by the = at_hash claim in the id token. >>>>> =20 >>>>> That seems to me like a legitimate and reasonable usage scenario. = However, it would fall on the wrong side of the SHOULD NOT in Section = 3.1.2 of the Security BCP-to-be, which has: >>>>> =20 >>>>> In order to avoid these issues, clients SHOULD NOT use the = implicit >>>>> grant (response type "token") or any other response type = issuing >>>>> access tokens in the authorization response, such as "token = id_token" >>>>> and "code token id_token", unless the issued access tokens are >>>>> sender-constrained and access token injection in the = authorization >>>>> response is prevented. >>>>> =20 >>>>> I know this particular text has been discussed over and over again = so I hate to revisit it. But based on the aforementioned scenario I = think maybe it still doesn't quite hit the mark. Access token injection = is prevented. The token leakage scenarios mentioned in that section are = all avoided. And while I know sender-constrained is recommended = elsewhere in the draft, it's not really a realistic option for the = majority of deployments. >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_67004322-BA92-440D-9E32-D6974B819C24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0yMDAxMDMxMDMzMjZaMC8GCSqGSIb3DQEJBDEiBCDgWFNNwSLxWKU3n2ytmh8wMLJ8Rxfi51B1 nVajYsZavzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAIlhcvdGGseDFwwgpUx3bBlowl2g5O2n3Zk1DdHs6SsnUDUc7zqXYE1fANLw 0J9aWjdN+qM6L4zIZ2q0MbwDYM6pXY6YZqc6IltuzL6BgJWrHjZ5jDbJ8bZcdPJMBVr4WVO1NHFd tO8DJZHZ6osKL5vx17+rRMDS4gomZajc5CGsnPqtiZNVZMjir/Ax8cadjDEE53d6lt1tGpkwhBRr KRlWs7SYq7sxDeuRPwj4d/TRXl2Q7ZDC20JQVAQxA06foqu2cw/RPYPjQRjms90+PF3VQ6fSwhw9 WbVN8yau0x3CBoK5HQwr1/VFmnhLCvJ4Z41wACRyuP7XYA4aUrcktTgAAAAAAAA= --Apple-Mail=_67004322-BA92-440D-9E32-D6974B819C24-- From nobody Fri Jan 3 13:43: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 D8D941200DB for ; Fri, 3 Jan 2020 13:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e0zzqP-nl_T for ; Fri, 3 Jan 2020 13:43:42 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10845120045 for ; Fri, 3 Jan 2020 13:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578087823; x=1609623823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J9T3xfgGDAZS9it1iKeARnOigajpAFQFXkFe8dNBHEA=; b=OFzlIMQwZp0CsiahzlHNm8DUXwFOiZXK7HvygY55w/1QF9f9JJE96XVx pviAapa58CboIBn40pdPKl0iuY1XAgLg5VtTEfFIe7l1rnyttY+k94GKp 2v+UODZe6he/Daxej/VOzunJmoe+anZdXrc4T7rSQOOPD+s+T9QOgKzv5 A=; IronPort-SDR: AxDToUGgW7tK7tJEEEM0FzE+MYJw5Pmv4JauJx8xMWRWWN7sLrUWhwsCFo0fJpxizApYiZhEbR UX9tJjMWYCQA== X-IronPort-AV: E=Sophos;i="5.69,392,1571702400"; d="scan'208";a="8305084" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 03 Jan 2020 21:43:42 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (Postfix) with ESMTPS id 917A1A2522; Fri, 3 Jan 2020 21:43:39 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 Jan 2020 21:43:38 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 Jan 2020 21:43:36 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 3 Jan 2020 21:43:36 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt , "Filip Skokan" CC: Dave Tonge , oauth , Nat Sakimura Thread-Topic: [OAUTH-WG] PAR metadata Thread-Index: AQHVv+g7xiAB+Bj4Q0q9tvboHgAv9qfUXGKAgAAMNwCABI8uAA== Date: Fri, 3 Jan 2020 21:43:36 +0000 Message-ID: <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> In-Reply-To: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] PAR 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, 03 Jan 2020 21:43:44 -0000 UEFSIGludHJvZHVjZXMgYW4gYWRkZWQgd3JpbmtsZSBmb3IgZW5jcnlwdGVkIHJlcXVlc3Qgb2Jq ZWN0czogdGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBtYXkgbm90 IGhhdmUgYWNjZXNzIHRvIHRoZSBzYW1lIGNyeXB0b2dyYXBoaWMga2V5cywgZXZlbiB0aG91Z2gg dGhleSdyZSBib3RoIHBhcnQgb2YgdGhlICJhdXRob3JpemF0aW9uIHNlcnZlci4iIFNpbmNlIHRo ZXkncmUgZGlmZmVyZW50IGVuZHBvaW50cyB3aXRoIGRpZmZlcmVudCByb2xlcywgaXQncyByZWFz b25hYmxlIHRvIHB1dCB0aGVtIGluIHNlcGFyYXRlIHRydXN0IGJvdW5kYXJpZXMuIFRoZXJlIGlz IG5vIHdheSB0byBzdXBwb3J0IHRoaXMgaXNvbGF0aW9uIHdpdGgganVzdCBhIHNpbmdsZSAiandr c191cmkiIG1ldGFkYXRhIHByb3BlcnR5Lg0KDQpUaGUgdHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBh cmU6DQoNCjEuIERlZmluZSBhIG5ldyBwYXJfandrc191cmkgbWV0YWRhdGEgcHJvcGVydHkuDQoy LiBFeHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhpcyBzZXBhcmF0aW9uIGlzIG5vdCBzdXBwb3J0ZWQu DQoNCkkgc3Ryb25nbHkgcGVyZmVyICMxIGFzIGl0IGhhcyBhIHZlcnkgbWlub3IgaW1wYWN0IG9u IGRlcGxveW1lbnRzIHRoYXQgZG9uJ3QgY2FyZSAoaS5lLiwgdGhleSBqdXN0IHNldCBwYXJfandr c191cmkgYW5kIGp3a3NfdXJpIHRvIHRoZSBzYW1lIHZhbHVlKSBhbmQgZmFpbGluZyB0byBzdXBw b3J0IHRoaXMgdHJ1c3QgYm91bmRhcnkgY3JlYXRlcyBhbiBhcnRpZmljaWFsIGxpbWl0IG9uIGlt cGxlbWVudGF0aW9uIGFyY2hpdGVjdHVyZSBhbmQgY291bGQgbGVhZCB0byBjb21wYXRpYmlsaXR5 LWJyZWFraW5nIHdvcmthcm91bmRzLg0KDQrigJMgDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu DQpBV1MgSWRlbnRpdHkNCiANCg0K77u/T24gMTIvMzEvMTksIDg6MDcgQU0sICJPQXV0aCBvbiBi ZWhhbGYgb2YgVG9yc3RlbiBMb2RkZXJzdGVkdCIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3Rl Og0KDQogICAgSGkgRmlsaXAsIA0KICAgIA0KICAgID4gT24gMzEuIERlYyAyMDE5LCBhdCAxNjoy MiwgRmlsaXAgU2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4gDQogICAg PiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgYSAqX2F1dGhfbWV0aG9kXyogbWV0YWRhdGEgZm9yIGV2 ZXJ5IGVuZHBvaW50IHRoZSBjbGllbnQgY2FsbHMgZGlyZWN0bHksIG5vbmUgb2YgdGhlIG5ldyBz cGVjcyBkZWZpbmVkIHRoZXNlIChlLmcuIGRldmljZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9y IENJQkEpLCBtZWFuaW5nIHRoZXkgYWxzbyBkaWRuJ3QgZm9sbG93IHRoZSBzY2hlbWUgZnJvbSBS RkMgODQxNCB3aGVyZSBpbnRyb3NwZWN0aW9uIGFuZCByZXZvY2F0aW9uIGdvdCBpdHMgb3duIG1l dGFkYXRhLiBJbiBtb3N0IGNhc2VzIHRoZSB1bmZvcnR1bmF0ZWx5IG5hbWVkIGB0b2tlbl9lbmRw b2ludF9hdXRoX21ldGhvZGAgYW5kIGl0cyByZWxhdGVkIG1ldGFkYXRhIGlzIHdoYXQncyB1c2Vk IGJ5IGNsaWVudHMgZm9yIGFsbCBkaXJlY3QgY2FsbHMgYW55d2F5Lg0KICAgID4gDQogICAgPiBU aGUgc2FtZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGllZCB0byBzaWduaW5nIChhbmQgZW5jcnlw dGlvbikgYWxnb3JpdGhtcyBhcyB3ZWxsLg0KICAgID4gDQogICAgPiBUaGlzIEkgZG8gbm90IGZv bGxvdywgYXV0aCBtZXRob2RzIGFuZCB0aGVpciBzaWduaW5nIGlzIGRlYWx0IHdpdGggYnkgdXNp bmcgYHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWRgIGFuZCBgdG9rZW5fZW5k cG9pbnRfYXV0aF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkYCAtIHRoZXJlJ3Mgbm8gZW5j cnlwdGlvbiBmb3IgdGhlIGBfand0YCBjbGllbnQgYXV0aCBtZXRob2RzLiANCiAgICA+IFVubGVz cyBpdCB3YXMgbWVhbnQgdG8gYWRkcmVzcyB0aGUgUmVxdWVzdCBPYmplY3Qgc2lnbmluZyBhbmQg ZW5jcnlwdGlvbiBtZXRhZGF0YSwgd2hpY2ggaXMgZGVmaW5lZCBhbmQgSUFOQSByZWdpc3RlcmVk IGJ5IE9JREMuIFBBUiBvbmx5IHJlZmVyZW5jZXMgSkFSIHNlY3Rpb24gNi4xIGFuZCA2LjIgZm9y IGRlY3J5cHRpb24vc2lnbmF0dXJlIHZhbGlkYXRpb24gYW5kIHRoZXNlIGRvIG5vdCBtZW50aW9u IHRoZSBtZXRhZGF0YSAoZS5nLiByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZykgYW55bW9yZSBz aW5jZSBkcmFmdCAwNy4NCiAgICANCiAgICBEYW1tZWQhIFlvdSBhcmUgc28gcmlnaHQuIFNvcnJ5 LCBJIGdvdCBjb25mdXNlZCBzb21laG93LiANCiAgICANCiAgICA+IA0KICAgID4gUFM6IEkgYWxz byBmb3VuZCB0aGlzIGNvbW1lbnQgcmVsYXRlZCB0byB0aGUgc2FtZSBxdWVzdGlvbiBhYm91dCBh dXRoIG1ldGFkYXRhIGJ1dCBmb3IgQ0lCQS4NCiAgICANCiAgICBUaGFua3MgZm9yIHNoYXJpbmcu IA0KICAgIA0KICAgID4gDQogICAgPiBCZXN0LA0KICAgID4gRmlsaXANCiAgICANCiAgICB0aGFu a3MsDQogICAgVG9yc3Rlbi4gDQogICAgDQogICAgPiANCiAgICA+IA0KICAgID4gT24gVHVlLCAz MSBEZWMgMjAxOSBhdCAxNTozOCwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ+IHdyb3RlOg0KICAgID4gSGkgYWxsLA0KICAgID4gDQogICAgPiBSb25hbGQganVz dCBzZW50IG1lIGFuIGVtYWlsIGFza2luZyB3aGV0aGVyIHdlIHdpbGwgZGVmaW5lIG1ldGFkYXRh IGZvciANCiAgICA+IA0KICAgID4gcHVzaGVkX2F1dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0aF9t ZXRob2RzX3N1cHBvcnRlZCBhbmQNCiAgICA+IHB1c2hlZF9hdXRob3JpemF0aW9uX2VuZHBvaW50 X2F1dGhfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZC4NCiAgICA+IA0KICAgID4gVGhlIGRy YWZ0IHJpZ2h0IG5vdyB1dGlsaXNlcyB0aGUgZXhpc3RpbmcgdG9rZW4gZW5kcG9pbnQgYXV0aGVu dGljYXRpb24gbWV0aG9kcyBzbyB0aGVyZSBpcyBiYXNpY2FsbHkgbm8gbmVlZCB0byBkZWZpbmUg YW5vdGhlciBwYXJhbWV0ZXIuIFRoZSBzYW1lIHByaW5jaXBsZSBjb3VsZCBiZSBhcHBsaWVkIHRv IHNpZ25pbmcgKGFuZCBlbmNyeXB0aW9uKSBhbGdvcml0aG1zIGFzIHdlbGwuIA0KICAgID4gDQog ICAgPiBXaGF04oCZcyB5b3VyIG9waW5pb24/DQogICAgPiANCiAgICA+IGJlc3QgcmVnYXJkcywN CiAgICA+IFRvcnN0ZW4uDQogICAgDQogICAgDQoNCg== From nobody Sat Jan 4 02:02: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 7D823120044 for ; Sat, 4 Jan 2020 02:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 aM5pAcGQXX0u for ; Sat, 4 Jan 2020 02:02:47 -0800 (PST) Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (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 7434B120019 for ; Sat, 4 Jan 2020 02:02:47 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id ngGai5mppUj2ingGaiPAEi; Sat, 04 Jan 2020 03:02:46 -0700 To: Justin Richer , Takahiko Kawasaki Cc: Brian Campbell , oauth , Nat Sakimura References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <33a1821d-9e7b-6592-0cc0-5dd2fb688e2f@connect2id.com> Date: Sat, 4 Jan 2020 12:02:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000907070602010703020806" X-CMAE-Envelope: MS4wfBEDcMswbkKKHb1wYuX/ZN3NF/aCeCXz6TXg29C4QvoQ3jKOJN3sJFx+HJHOILGzucV9XgvGPsH+L6cYXDrhpXo7gdUZkOtDqDoAnWB2NAPrk2DfiVJJ 2QO0+4vcLLiiF0kfQrXS1OcV1yYDSD6ItjQsupgJ3UB/ftLNeq3rpUbspPehURH1laZhxQhwkNUlA+1bMTpbOuMbOiLn5mva41bgfVRRjjZUa+ILBha0zfXK 3BOaZGh5cDJlG7lJQvRjaeo+xUn1v0rHCeSWBPzALDx9SDlP7QIoM00lUaFatj+WBU+QqtFj40BaWi9PGQfryw== Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 04 Jan 2020 10:02:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000907070602010703020806 Content-Type: multipart/alternative; boundary="------------25B0FB99DF8CB89AF66A6DA1" Content-Language: en-US This is a multi-part message in MIME format. --------------25B0FB99DF8CB89AF66A6DA1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Why not leave this to be an AS policy, or to be defined by specific profiles? We have had a simple AS setting which allows or prohibits parameters outside the JWT: * If parameters outside the JWT are allowed, they are merged, with the JWT-secured ones having precedence. * If parameters outside the JWT are prohibited, and any are found, an invalid_request error with message is returned. This allowed us to handle OpenID requests in applications requiring all parameters to be signed. I believe the FAPI profile also has this requirement. But there can well be applications and scenarios where some of the parameters (e.g. client_id, scope, redirect_uri) may need to be pre-signed / made invariable by some 3rd party, while leaving state and PKCE be set by the client. My concern is not so much about the backward compatibility, but that we're trying to make a decision which seems to be better left to JAR applications and profiles. Letting the AS decide on the merge or not-merge is my preference. Vladimir On 02/01/2020 19:35, Justin Richer wrote: > For solution [2], this is the behavior that=E2=80=99s required for OIDC= today, > so I would say that=E2=80=99s the New Client behaving like an Old Clien= t in > order to talk to an Old Server. So in reality, (2) causes the request > to be rejected, and that=E2=80=99s OK. > > I don=E2=80=99t think it=E2=80=99s viable to require parameters to exis= t inside the > request object at all times. Nor should we try to enumerate which > parameters go inside and outside at all times =E2=80=94 at least from t= he > JAR/OAuth level of things. I think there are too many things that are > application and deployment specific for us to make this call. The very > nature of the request object changes for people =E2=80=94 some have a s= tatic > object that=E2=80=99s deployed with clients and some have something tha= t the > client creates at runtime for each request.=C2=A0 > > If the instead the New Server requires that any parameters duplicated > between the two places have to match (the OIDC method) or that in a > conflict the request object values take precedence (the merge method), > then problems 3-1 and 3-2 go away.=C2=A0 > > With the merge-and-precedence behavior, which is what I thought that > JAR had during WGLC, [3-1] is well-defined. The request is processed > the same way every time because this is a New Server. The client is > going to do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80= =9Cmerge with precedence=E2=80=9D is > effectively a no-op. > > With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen be= cause > the required parameters aren=E2=80=99t required to be in the request ob= ject > itself. As long as the request object is valid, it protects all > parameters within it. I don=E2=80=99t think it=E2=80=99s up to us to de= termine what > makes sense to put in that object. Security guidance is probably a > good idea here. > > Solution [3] is what Old Clients already do in OIDC today, so that=E2=80= =99s > what already happens and why problem space (3) isn=E2=80=99t a problem.= > > =C2=A0=E2=80=94 Justin > >> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki > > wrote: >> >> Thank you, Justin. Actually, I wanted to see someone write a summary >> about what happens in each combination from a viewpoint of both RP >> and AS with regard to backward compatibility (as I told you in other >> channel just before you posted your email ^_^). >> >> So, >> >> *(1) New Client + New Server* >> No problem will happen. >> >> *(2) New Client + Old Server* >> *[Problem 2-1]* If an authorization request contains 'request' or >> 'request_uri' but doesn't have old mandatory request parameters >> ('client_id' and 'response_type') outside the request object, the >> request is rejected. >> >> *[Solution 2]* New Client should include the old mandatory request >> parameters duplicately outside the request object. This means that >> New Client should always send old mandatory request parameters >> duplicately outside the request object if it wants to get maximum >> compatibility. >> >> *(3) Old Client + New Server* >> *[Problem 3-1]* If an authorization request contains 'request' or >> 'request_uri' and some "optional" request parameters are not included >> in the request object, AS will interpret the request differently. >> Imagine what happens when optional parameters such as 'scope', >> 'state', 'nonce', 'redirect_uri', 'response_mode', 'max_age', >> 'acr_values', 'code_challenge', 'code_challenge_method' and 'prompt' >> are not included in the request object but present outside the >> request object. >> >> *[Problem 3-2]* If an authorization request contains 'request' or >> 'request_uri' and some "mandatory" request parameters ('client_id' >> and 'response_type') are not included in the request object, the >> request is rejected. >> >> *[Solution 3]* Old Client should include all request parameters >> duplicately in the request object. This means that Old Client should >> always include all request parameters duplicately in the request >> object if it wants to get maximum compatibility. >> >> *(4) Old Client + Old Server* >> No problem will happen. >> >> - - - >> >> From a Client's point of view, for maximum compatibility, both Old >> and New Clients should put mandatory request parameters outside the >> request object and put all request parameters duplicately inside the >> request object. >> >> [Problem 3-1] is difficult to detect because the authorization >> request is not rejected. But, if New Server requires that all request >> parameters outside the request object be put inside the request >> object duplicately, [Problem 3-1] is handled as an error and thus >> client developers can detect the problem. >> >> Consequently, introducing the following requirement in "FAPI Part 2, >> 5.2.2 >> , >> 10" to JAR seems a good compromise (as I told before) >> >> shall require that all parameters are present inside the signed >> request object passed in the request or request_uri parameter; >> >> >> instead of just saying "the authorization server supporting this >> specification MUST only use the parameters included in the request >> object." which will bring about [Problem 3-1]. That is, how about >> adding a rule like "if request parameters exist outside the request >> object, they must exist inside the request object, too."? >> >> Any thoughts? >> >> Best, >> Taka >> >> >> On Fri, Jan 3, 2020 at 12:48 AM Justin Richer > > wrote: >> >> I think the nature of the backwards incompatibility is important >> here. The way that things are now, using merge-with-precedence, >> you have the following matrix of compatibility: >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Server =C2=A0|= =C2=A0Old Server =C2=A0| >> -----------+-------------+--------------+ >> New Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0NO =C2=A0 =C2=A0 =C2=A0| >> Old Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0 = YES =C2=A0 =C2=A0 =C2=A0| >> >> >> If you ask me, this is the right balance for a breaking change. >> Old clients, where the vast majority of the code is, don=E2=80=99t= have >> to change. New clients can only talk to servers with the new >> features, which is the ability to drop parameters from the >> external request. This would apply to both OIDC and plain OAuth. >> >> I think we should follow this kind of pattern in the discussions >> on OAuth 2.1, which I think JAR should be a part of/ >> >> =C2=A0=E2=80=94 Justin >> >> >> >>> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki >> > wrote: >>> >>> Breaking backward compatibility in this part would mean that >>> OpenID Certification given to AS implementations with >>> request_uri support will be invalidated once they support JAR. >>> It also would mean that test cases in the official conformance >>> suite need to be changed in a backward-incompatible manner, >>> which would implicitly encourage that all certified >>> implementations should re-try to get certification. >>> >>> Changing the spec now might need more three to six months, but >>> it would be worth considering what we get and lose by saving the >>> months and breaking backward compatibility. >>> >>> Best Regards, >>> Taka >>> >>> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura >> > wrote: >>> >>> So, no change is OK?=C2=A0 >>> >>> On Wed, Dec 11, 2019 at 10:01 PM John Bradley >>> > wrote: >>> >>> I also slightly prefer the merge approach.=C2=A0 >>> >>> There are plusses and minuses to both.=C2=A0 >>> >>> Changing again now that it is past ISEG review and >>> backing out a Discuss will add another three to six >>> months at this point, if we can get them to agree to the >>> change.=C2=A0 >>> >>> John B.=C2=A0 >>> >>> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura >>> > wrote: >>> >>> Correct. The WG supported the precedence approach >>> and even merge just like OIDC as it is very useful >>> from the implementation point of view and helps with >>> a bunch of deployment patter.=C2=A0 >>> >>> The push back came in from the Ben Campbell=E2=80=99s= DISCUSS.=C2=A0 >>> See=C2=A0 >>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-t= he-current-text-actually-specifies-the >>> >>> I am willing to go either way as long as people >>> agree. My slight preference is to the original >>> approach.=C2=A0 >>> >>> Best,=C2=A0 >>> >>> Nat Sakimura >>> >>> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Br= ian Campbell >>> >> >: >>> >>> FWIW, as best I can remember the change in >>> question came as I result of directorate/IESG >>> review rather than a WG decision/discussion. >>> Which is likely why you can't find the "why" >>> anywhere in the mailing list archive. >>> >>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan >>> > >>> wrote: >>> >>> Well it kind of blows, doesn't it? I wasn't >>> able to find the "why" anywhere in the >>> mailing list archive around the time this >>> was changed. >>> >>> My take on satisfying both worlds looks like >>> this >>> >>> - allow just JAR - no other params when >>> possible. >>> =C2=A0 =C2=A0 (which btw isn't possible to do= with >>> request_uri when enforcing client based uri >>> whitelist and the jwsreq 5.2.2 shows as much)= >>> - enforce the "dupe behaviours" defined in >>> OIDC (if response_type or client_id is in >>> request object it must either be missing or >>> the same in regular request). >>> - allows merging request object and regular >>> parameters with request object >>> taking=C2=A0precedence since it is a very use= ful >>> feature when having pre-signed request >>> object that's not one time use and clients >>> using it wish to vary state/nonce per-request= =2E >>> >>> I wish the group reconsidered making this >>> breaking change from OIDC's take on request >>> objects - allow combination of parameters >>> from the request object with ones from >>> regular parameters (if not present in >>> request object). >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell >>> >> > wrote: >>> >>> Filip, for better or worse, I believe >>> your assessment of the situation is >>> correct. I know of one AS that didn't >>> choose which of the two to follow but >>> rather implemented a bit of a hybrid >>> where it basically ignores everything >>> outside of the request object per JAR >>> but also checks for and enforces the >>> presence and value of the few regular >>> parameters (client_id, response_type) >>> that OIDC mandates. >>> >>> On Tue, Aug 27, 2019 at 5:47 AM Filip >>> Skokan >> > wrote: >>> >>> Hello everyone, >>> >>> in an earlier thread I've posed the >>> following question that might have >>> gotten missed, this might have >>> consequences for the existing >>> implementations of Request Objects >>> in OIDC implementations - its making >>> pure JAR requests incompatible with >>> OIDC Core implementations. >>> >>> draft 14 of jwsreq (JAR) introduced >>> this language >>> >>> The client MAY send the >>> parameters included in the >>> request object >>> duplicated in the query >>> parameters as well for the backwa= rd >>> compatibility etc. =C2=A0*However= , >>> the authorization server >>> supporting this >>> specification MUST only use the >>> parameters included in the reques= t >>> object.=C2=A0* >>> >>> >>> Server MUST only use the >>> parameters in the Request Object >>> even if the >>> same parameter is provided in >>> the query parameter.=C2=A0 The >>> Authorization >>> >>> >>> The client MAY send the >>> parameters included in the >>> request object >>> duplicated in the query >>> parameters as well for the backwa= rd >>> compatibility etc. =C2=A0*However= , >>> the authorization server >>> supporting this >>> specification MUST only use the >>> parameters included in the reques= t >>> object..=C2=A0* >>> >>> >>> Nat, John, everyone -=C2=A0*does this= >>> mean a JAR compliant AS ignores >>> everything outside of the request >>> object while OIDC Request Object one >>> merges the two with the ones in the >>> request object being used over ones >>> that are sent in clear?*=C2=A0The OID= C >>> language also includes sections >>> which make sure that some required >>> arguments are still passed outside >>> of the request object with the same >>> value to make sure the request is >>> "valid" OAuth 2.0 request >>> (client_id, response_type), >>> something which an example in the >>> JAR spec does not do. Not having >>> this language means that existing >>> authorization request pipelines >>> can't simply be extended with e.g. a >>> middleware, they need to branch >>> their codepaths. >>> >>> Is an AS required to choose which of >>> the two it follows? >>> >>> Thank you for clarifying this in >>> advance. I think if either the >>> behaviour is the same as in OIDC or >>> different this should be called out >>> in the language to avoid confusion, >>> especially since this already exists >>> in OIDC and likely isn't going to be >>> read in isolation, especially >>> because the Request Object is even >>> called out to be already in place in >>> OIDC in the JAR draft. >>> >>> Best, >>> *Filip* >>> _____________________________________= __________ >>> 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.=C2=A0 If y= ou >>> have received this communication in >>> error, please notify the sender >>> immediately by e-mail and delete the >>> message and any file attachments from >>> your computer. Thank you./ >>> >>> >>> /CONFIDENTIALITY NOTICE: This email may contain >>> confidential and privileged material for the >>> sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by >>> others is strictly prohibited..=C2=A0 If you have= >>> received this communication in error, please >>> notify the sender immediately by e-mail and >>> delete the message and any file attachments from >>> your computer. Thank >>> you./____________________________________________= ___ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > --------------25B0FB99DF8CB89AF66A6DA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Why not leave this to be an AS policy, or to be defined by specific profiles?

We have had a simple AS setting which allows or prohibits parameters outside the JWT:

  • If parameters outside the JWT are allowed, they are merged, with the JWT-secured ones having precedence.

  • If parameters outside the JWT are prohibited, and any are found, an invalid_request error with message is returned.

This allowed us to handle OpenID requests in applications requiring all parameters to be signed. I believe the FAPI profile also has this requirement. But there can well be applications and scenarios where some of the parameters (e.g. client_id, scope, redirect_uri) may need to be pre-signed / made invariable by some 3rd party, while leaving state and PKCE be set by the client.

My concern is not so much about the backward compatibility, but that we're trying to make a decision which seems to be better left to JAR applications and profiles.

Letting the AS decide on the merge or not-merge is my preference.<= /p>

Vladimir

On 02/01/2020 19:35, Justin Richer wrote:
For solution [2], this is the behavior that=E2=80=99= s required for OIDC today, so I would say that=E2=80=99s the New Cl= ient behaving like an Old Client in order to talk to an Old Server. So in reality, (2) causes the request to be rejected, and that=E2= =80=99s OK.

I don=E2=80=99t think it=E2=80=99s viable to require parameters to = exist inside the request object at all times. Nor should we try to enumerate which parameters go inside and outside at all times =E2=80=94 at le= ast from the JAR/OAuth level of things. I think there are too many things that are application and deployment specific for us to make this call. The very nature of the request object changes for people =E2=80=94 some have a static object that=E2=80=99s deployed = with clients and some have something that the client creates at runtime for each request.=C2=A0

If the instead the New Server requires that any parameters duplicated between the two places have to match (the OIDC method) or that in a conflict the request object values take precedence (the merge method), then problems 3-1 and 3-2 go away.=C2=A0

With the merge-and-precedence behavior, which is what I thought that JAR had during WGLC, [3-1] is well-defined. The request is processed the same way every time because this is a New Server. The client is going to do OIDC=E2=80=99s =E2=80=9Cd= uplicate=E2=80=9D method, so =E2=80=9Cmerge with precedence=E2=80=9D is effectively= a no-op.

With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen because the required parameters aren=E2=80= =99t required to be in the request object itself. As long as the request object is valid, it protects all parameters within it. I don=E2=80= =99t think it=E2=80=99s up to us to determine what makes sense to put = in that object. Security guidance is probably a good idea here.

Solution [3] is what Old Clients already do in OIDC= today, so that=E2=80=99s what already happens and why problem spa= ce (3) isn=E2=80=99t a problem.

=C2=A0=E2=80=94 Justin

On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki <taka@authlete.com> wrote:

Thank you, Justin. Actually, = I wanted to see someone write a summary about what happens in each combination from a viewpoint of both RP and AS with regard to backward compatibility (as I told you in other channel just before you posted your email ^_^).

So,

(1) New Client + New Server
No problem will happen.

(2) New Client + Old Server
[Problem 2-1] If an authorization request contains 'request' or 'request_uri' but doesn't have old mandatory request parameters ('client_id' and 'response_type') outside the request object, the request is rejected.

[Solution 2] New Client should includ= e the old mandatory request parameters duplicately outside the request object. This means that New Client should always send old mandatory request parameters duplicately outside the request object if it wants to get maximum compatibility.

(3) Old Client + New Server
[Problem 3-1] If an authorization request contains 'request' or 'request_uri' and some "optional" request parameters are not included in the request object, AS will interpret the request differently. Imagine what happens when optional parameters such as 'scope', 'state', 'nonce', 'redirect_uri', 'response_mode', 'max_age', 'acr_values', 'code_challenge', 'code_challenge_method' and 'prompt' are not included in the request object but present outside the request object.

[Problem 3-2] If an authorization request contains 'request' or 'request_uri' and some "mandatory" request parameters ('client_id' and 'response_type') are not included in the request object, the request is rejected.

[Solution 3] Old Client should includ= e all request parameters duplicately in the request object. This means that Old Client should always include all request parameters duplicately in the request object if it wants to get maximum compatibility.

(4) Old Client + Old Server
No problem will happen.

- - -

From a Client's point of view, for maximum compatibility, both Old and New Clients should put mandatory request parameters outside the request object and put all request parameters duplicately inside the request object.

[Problem 3-1] is difficult to detect because the authorization request is not rejected. But, if New Server requires that all request parameters outside the request object be put inside the request object duplicately, [Problem 3-1] is handled as an error and thus client developers can detect the problem.
Consequently, introducing the following requirement in "FAPI Part 2, 5.2.2, 10" = to JAR seems a good compromise (as I told before)

shall require that all parameters are present inside the signed request object passed in the request or request_uri parameter;

instead of just saying "the authorization server supporting this specification MUST only use the parameters included in the request object." which will bring about [Problem 3-1]. That is, how about adding a rule like "if request parameters exist outside the request object, they must exist inside the request object, too."?

Any thoughts?

Best,
Taka


On Fri, Jan 3, 20= 20 at 12:48 AM Justin Richer <jricher@mit.edu> wrote:
= I think the nature of the backwards incompatibility is important here. The way that things are now, using merge-with-precedence, you have the following matrix of compatibility:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Se= rver =C2=A0| =C2=A0Old Server =C2=A0|
-----------+-------------+--------------+
New Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0NO =C2=A0 =C2=A0 =C2=A0|
Old Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0|= =C2=A0 =C2=A0 YES =C2=A0 =C2=A0 =C2=A0|


If you ask me, this is the right balance for a breaking change. Old clients, where the vast majority of the code is, don=E2=80= =99t have to change. New clients can only talk to servers with the new features, which is the ability to drop parameters from the external request. This would apply to both OIDC and plain OAuth.

I think we should follow this kind of pattern in the discussions on OAuth 2.1, which I think JAR should be a part of/

=C2=A0=E2=80=94 Justin



On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <taka@authlete.co= m> wrote:

Breaking backwa= rd compatibility in this part would mean that OpenID Certification given to AS implementations with request_uri support will be invalidated once they support JAR. It also would mean that test cases in the official conformance suite need to be changed in a backward-incompatible manner, which would implicitly encourage that all certified implementations should re-try to get certification.

Changing the spec now might need more three to six months, but it would be worth considering what we get and lose by saving the months and breaking backward compatibility.

Best Regards,
Taka

On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura <sakimura@gma= il.com> wrote:
So, no chan= ge is OK?=C2=A0

On Wed, Dec 11, 2019 at 10:01 PM John Bradley <ve7jtb@v= e7jtb.com> wrote:
=
I also= slightly prefer the merge approach.=C2=A0

Ther= e are plusses and minuses to both.=C2=A0

Chan= ging again now that it is past ISEG review and backing out a Discuss will add another three to six months at this point, if we can get them to agree to the change.=C2=A0

John= B.=C2=A0

On Tue, De= c 10, 2019, 11:29 PM Nat Sakimura <saki= mura@gmail.com> wrote:
Correct. The WG supported the precedence approach and even merge just like OIDC as it is very useful from the implementation point of view and helps with a bunch of deployment patter.=C2=A0
=
= The push back came in from the Ben Campbell=E2=80=99s DISC= USS.=C2=A0
= See=C2=A0
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-ac= tually-specifies-the

I am willing to go either way as long as people agree. My slight preference is to the original approach.=C2=A0<= /div>

Best,=C2=A0

Nat Sakimura

=
20= 19=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
=
FWIW, as best I can remember the change in question came as I result of director= ate/IESG review rather than a WG decision/discussion= =2E Which is likely why you can't find the "why" anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva.ip@gmail.com> wrote:
W= ell it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this was changed.
<= br class=3D"">
M= y take on satisfying both worlds looks like this
<= br class=3D"">
-= allow just JAR - no other params when possible.
=
=C2= =A0 =C2=A0 (which b= tw isn't possible to do with request_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much)
-= enforce the "dupe behaviours" defined in OIDC (if response_type or client_id is in request object it must either be missing or the same in regular request).
=
-= allows merging request object and regular parameters with request object taking=C2=A0pre= cedence since it is a very useful feature when having pre-signed request object that's not one time use and clients using it wish to vary state/nonce per-request.
<= br class=3D"">
I= wish the group reconsidered making this breaking change from OIDC's take on request objects - allow combination of parameters from the request object with ones from regular parameters (if not present in request object).

S pozdravem,
F= ilip Skokan


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <= bcampbell@pingidentity.com> wrote:
Fili= p, for better or worse, I believe your assessment of the situation is correct. I know of one AS that didn't choose which of the two to follow but rather implemented a bit of a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the presence and value of the few regular parameters (client_id, response_type) that OIDC mandates.

=
On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <= panva.ip@gmail.com> wrote:
Hello everyone,
=

in an earlier thread I've posed the following question that might have gotten missed, this might have consequences for the existing implementations= of Request Objects in OIDC implementations= - its making pure JAR requests incompatible with OIDC Core implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0Howe= ver, the authorization server supporting this
specification MUST only use the parameters included in the request
object.=C2=A0
Server MUST only use the parameters in the Request Object even if the
same parameter is provided in the query parameter.=C2=A0= The Authorization

The client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0Howe= ver, the authorization server supporting this
specification MUST only use the parameters included in the request
object..=C2=A0<= /b>
Nat, John, everyone -=C2=A0does this mean a JAR compliant AS ignores everything outside of the request object while OIDC Request Object one merges the two with the ones in the request object being used over ones that are sent in clear?=C2=A0= The OIDC language also includes sections which make sure that some required arguments are still passed outside of the request object with the same value to make sure the request is "valid" OAuth 2.0 request (client_id, response_type),= something which an example in the JAR spec does not do. Not having this language means that existing authorization request pipelines can't simply be extended with e.g. a middleware, they need to branch their codepaths.

Is an AS required to choose which of the two it follows?

Thank you for clarifying this in advance. I think if either the behaviour is the same as in OIDC or different this should be called out in the language to avoid confusion, especially since this already exists in OIDC and likely isn't going to be read in isolation, especially because the Request Object is even called out to be already in place in OIDC in the JAR draft.

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

=
CONF= IDENTIALITY NOTICE: This email may contain 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.

CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=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
--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimur= a (=3Dnat)
Chairman, OpenID Foundation
http://n= at.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.o= rg
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf= =2Eorg/mailman/listinfo/oauth



--------------25B0FB99DF8CB89AF66A6DA1-- --------------ms000907070602010703020806 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDQxMDAyNDNaMC8G CSqGSIb3DQEJBDEiBCCLFdKUvUU5m0NNuVgBzF+eDb2vg8CK/ZwnMWXSv6vLtDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAJ3APpVufyWUJW5U8Du+Tz4VGZGY2M4Q3IqbXxQ1gSZI504G aKe5tGTFJP9fh3JZDCDYhY5cFPYhiQuXdqM8fKdwbexrR79MBuIGwjw2WcKyAXWjWipfzPXS /ifoS9fqCaxT0ij0ZqbEXDz1zo37/amjTlkil6fpa0Uc933i2mSPuuFTDKj46gaRW0ETsnJH FRcsjSe8Wx5pNAX1em8zA3vIftlzX9PUot5Wai6klMzFCA+iOqzcFvPgNyiXtEsvkof90GZh 9ZypduYPCclO9vGtgJhMJ6QThi7V8spjv+MbcX6dlaqFAcjQKkhqJClOCSkYgVgkIcEMH1sA vdyER7MAAAAAAAA= --------------ms000907070602010703020806-- From nobody Sat Jan 4 02:31: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 47E321200E3 for ; Sat, 4 Jan 2020 02:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 D3Rl2IXSHMtS for ; Sat, 4 Jan 2020 02:31:35 -0800 (PST) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (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 7AFDE120019 for ; Sat, 4 Jan 2020 02:31:35 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id ngiRiYdMF45rTngiSij3VU; Sat, 04 Jan 2020 03:31:34 -0700 x-spam-cmae: v=2.3 cv=f/02+96M c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=EfNiojmyKf8bX2LcNe0A:9 a=d5jngGXNAcPPN0S0:21 a=7opJxlqbioHtsAQY:21 a=QEXdDO2ut3YA:10 a=vggBfdFIAAAA:8 a=0AOFY9oEZ10Y09P0XLwA:9 a=wcUr-LE_6hKLoQHq:21 a=pbuYuz4cc6RTaf2f:21 a=aQON9Wutubalqgp4:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com To: "Richard Backman, Annabelle" , Torsten Lodderstedt , Filip Skokan Cc: Dave Tonge , oauth , Nat Sakimura References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <943d3fdf-8b1b-486f-8046-f1c61bf4fdb3@connect2id.com> Date: Sat, 4 Jan 2020 12:31:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050104080203080004040003" X-CMAE-Envelope: MS4wfPw4Sc/3AvYhSU+ax5xVCD/LBT/4D/zmHeGowhxc4y9wbDjNnbSWGa4W2KLpKsb5RrmM+tGG+N6x1GUv2O/hLX/FLjs1DGbll5Tv/PoTjJz5JRzcd3DE pEC7+x2xroeUMKV2JdKy/o1aYJH6toi4tr9fGpX2I94/8BzhmcSfVkEOGY8LJCDUNDkXDR0DfzYZEuLoFgavqTba/ZggujSITdrm5SZZpIGwydpP0MxCWjcx GWWFlYi9FazBFk8JT8mnpY0c4Qwebk353YLJaBEfi4rM9OUlCYPDg1BXJR61D2bzM+PUES/zaEKxOxcdO1fPjWQajDlHM+zKK6UB5e/gETRyf5y+yy8aDgHy zxhyEnD373GaLJjsJZcbFY7TOKEd3g== Archived-At: Subject: Re: [OAUTH-WG] PAR 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: Sat, 04 Jan 2020 10:31:37 -0000 This is a cryptographically signed message in MIME format. --------------ms050104080203080004040003 Content-Type: multipart/alternative; boundary="------------EBB64CD768295C9F2F29650E" Content-Language: en-US This is a multi-part message in MIME format. --------------EBB64CD768295C9F2F29650E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Annabelle, We recently implemented PAR in a release. What security risks do AS users face if the clients encrypt to the same JWK set? If there are general issues with that, do they also hold for clients? Because an OP / AS can potentially issue multiple types of encrypted JWTs at separate endpoints: * Encrypted ID tokens * Encrypted UserInfo * Encrypted authZ responses (JARM) * Encrypted introspection responses I like PAR because it was so easy and straightforward to explain to client developers, and the benefits of having an authZ request submitted directly to the AS were also easily understood (no limits on the size of the request and it remaining hidden from the front-channel, the client is authenticated before user auth / consent). Vladimir On 03/01/2020 23:43, Richard Backman, Annabelle wrote: > PAR introduces an added wrinkle for encrypted request objects: the PAR = endpoint and authorization endpoint may not have access to the same crypt= ographic keys, even though they're both part of the "authorization server= =2E" Since they're different endpoints with different roles, it's reasona= ble to put them in separate trust boundaries. There is no way to support = this isolation with just a single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on deployments that = don't care (i.e., they just set par_jwks_uri and jwks_uri to the same val= ue) and failing to support this trust boundary creates an artificial limi= t on implementation architecture and could lead to compatibility-breaking= workarounds. > > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > > =EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt"= wrote: > > Hi Filip,=20 > =20 > > On 31. Dec 2019, at 16:22, Filip Skokan wrot= e: > >=20 > > I don't think we need a *_auth_method_* metadata for every endpoi= nt the client calls directly, none of the new specs defined these (e.g. d= evice authorization endpoint or CIBA), meaning they also didn't follow th= e scheme from RFC 8414 where introspection and revocation got its own met= adata. In most cases the unfortunately named `token_endpoint_auth_method`= and its related metadata is what's used by clients for all direct calls = anyway. > >=20 > > The same principle could be applied to signing (and encryption) a= lgorithms as well. > >=20 > > This I do not follow, auth methods and their signing is dealt wit= h by using `token_endpoint_auth_methods_supported` and `token_endpoint_au= th_signing_alg_values_supported` - there's no encryption for the `_jwt` c= lient auth methods.=20 > > Unless it was meant to address the Request Object signing and enc= ryption metadata, which is defined and IANA registered by OIDC. PAR only = references JAR section 6.1 and 6.2 for decryption/signature validation an= d these do not mention the metadata (e.g. request_object_signing_alg) any= more since draft 07. > =20 > Dammed! You are so right. Sorry, I got confused somehow.=20 > =20 > >=20 > > PS: I also found this comment related to the same question about = auth metadata but for CIBA. > =20 > Thanks for sharing.=20 > =20 > >=20 > > Best, > > Filip > =20 > thanks, > Torsten.=20 > =20 > >=20 > >=20 > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt wrote: > > Hi all, > >=20 > > Ronald just sent me an email asking whether we will define metada= ta for=20 > >=20 > > pushed_authorization_endpoint_auth_methods_supported and > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > >=20 > > The draft right now utilises the existing token endpoint authenti= cation methods so there is basically no need to define another parameter.= The same principle could be applied to signing (and encryption) algorith= ms as well.=20 > >=20 > > What=E2=80=99s your opinion? > >=20 > > best regards, > > Torsten. > =20 > =20 > --------------EBB64CD768295C9F2F29650E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Annabelle,

We recently implemented PAR in a release. What security risks do AS users face if the clients encrypt to the same JWK set?

If there are general issues with that, do they also hold for clients? Because an OP / AS can potentially issue multiple types of encrypted JWTs at separate endpoints:

  • Encrypted ID tokens
  • Encrypted UserInfo
  • Encrypted authZ responses (JARM)
  • Encrypted introspection responses

I like PAR because it was so easy and straightforward to explain to client developers, and the benefits of having an authZ request submitted directly to the AS were also easily understood (no limits on the size of the request and it remaining hidden from the front-channel, the client is authenticated before user auth / consent).

Vladimir

On 03/01/2020 23:43, Richard Backman, Annabelle wrote:
PAR introduces an added wrin=
kle for encrypted request objects: the PAR endpoint and authorization end=
point may not have access to the same cryptographic keys, even though the=
y're both part of the "authorization server." Since they're different end=
points with different roles, it's reasonable to put them in separate trus=
t boundaries. There is no way to support this isolation with just a singl=
e "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that do=
n't care (i.e., they just set par_jwks_uri and jwks_uri to the same value=
) and failing to support this trust boundary creates an artificial limit =
on implementation architecture and could lead to compatibility-breaking w=
orkarounds.

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

=EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:oauth-bounces@ietf.orgon=
behalfoftorsten=3D40lodderstedt.net@dmarc.ietf.org"><oauth-bounces@iet=
f.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org> wro=
te:

    Hi Filip,=20
   =20
    > On 31. Dec 2019, at 16:22, Filip Skokan <panva.ip@gmail.com><=
/a> wrote:
    >=20
    > I don't think we need a *_auth_method_* metadata for every endpo=
int the client calls directly, none of the new specs defined these (e.g. =
device authorization endpoint or CIBA), meaning they also didn't follow t=
he scheme from RFC 8414 where introspection and revocation got its own me=
tadata. In most cases the unfortunately named `token_endpoint_auth_method=
` and its related metadata is what's used by clients for all direct calls=
 anyway.
    >=20
    > The same principle could be applied to signing (and encryption) =
algorithms as well.
    >=20
    > This I do not follow, auth methods and their signing is dealt wi=
th by using `token_endpoint_auth_methods_supported` and `token_endpoint_a=
uth_signing_alg_values_supported` - there's no encryption for the `_jwt` =
client auth methods.=20
    > Unless it was meant to address the Request Object signing and en=
cryption metadata, which is defined and IANA registered by OIDC. PAR only=
 references JAR section 6.1 and 6.2 for decryption/signature validation a=
nd these do not mention the metadata (e.g. request_object_signing_alg) an=
ymore since draft 07.
   =20
    Dammed! You are so right. Sorry, I got confused somehow.=20
   =20
    >=20
    > PS: I also found this comment related to the same question about=
 auth metadata but for CIBA.
   =20
    Thanks for sharing.=20
   =20
    >=20
    > Best,
    > Filip
   =20
    thanks,
    Torsten.=20
   =20
    >=20
    >=20
    > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <torsten@=
lodderstedt.net> wrote:
    > Hi all,
    >=20
    > Ronald just sent me an email asking whether we will define metad=
ata for=20
    >=20
    > pushed_authorization_endpoint_auth_methods_supported and
    > pushed_authorization_endpoint_auth_signing_alg_values_supported.=

    >=20
    > The draft right now utilises the existing token endpoint authent=
ication methods so there is basically no need to define another parameter=
=2E The same principle could be applied to signing (and encryption) algor=
ithms as well.=20
    >=20
    > What=E2=80=99s your opinion?
    >=20
    > best regards,
    > Torsten.
   =20
   =20

--------------EBB64CD768295C9F2F29650E-- --------------ms050104080203080004040003 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDQxMDMxMzFaMC8G CSqGSIb3DQEJBDEiBCAF9jtakG/feg5W9AV4XhEioVWuLj/Q3vBIQyXTpZ2uXjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAJ0Bl0g25DTkcwP9CkmwtwllrX/drFoDKdF/LVUibZ3xXUfS piANJKyGZ3ab87Rko9FTp1aF0zdtcC0hIzhpkWLnyHPUDdEDMfDE9JxsMQvYeG41Wb+KS9M6 Lcq0M/hstkRLrBtxec6tawTl6B90zYlCg+fhc7poJZiW2BoUKsMdsmlqy1PWMcOosFx1yaOS jcHgep4eK1jwNRmkOfT1SEvINKZP51LtZfJ6mWmN3D7XEUv1Vt2tuoSq+RTdiF7d0a3n2ZmY eDPA7I3/0Vg/9gJe623CyQrZ6OkYBelJYxTxLHGTM/wTebxD0bX/OwQmiZFcplx/yT6FSvXd G9GFOa8AAAAAAAA= --------------ms050104080203080004040003-- From nobody Sun Jan 5 22:05:06 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 7D486120098 for ; Sun, 5 Jan 2020 22:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DnijGG0J05Fp for ; Sun, 5 Jan 2020 22:04:58 -0800 (PST) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564861200B1 for ; Sun, 5 Jan 2020 22:04:57 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 36A2E472EE0; Mon, 6 Jan 2020 15:04:56 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id DBB5A4E0046; Mon, 6 Jan 2020 15:04:55 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id 00664tTp000308; Mon, 6 Jan 2020 15:04:55 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id 00664tZv000302; Mon, 06 Jan 2020 15:04:55 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id 00664t2d039990; Mon, 6 Jan 2020 15:04:55 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id 00664trX039989; Mon, 6 Jan 2020 15:04:55 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id 00664tPo039984; Mon, 6 Jan 2020 15:04:55 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM01SA.cu.nri.co.jp (172.59.253.43) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 15:04:53 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (104.47.93.54) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 15:04:53 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O9LNbh/qDKZgsW2Cg/3Ag1bsJS6EXiji91DToKSrtjPwzWSgstgJH/En5N+B4YScG84gYIXEK1ExslYnDiA3eL83aWw9PmBNRBLDspxkYmjUhrheoN9DXtH/o8wvV31ii6HStxMwdj6cO/pICEGOwAVjcNv99HjO7yiBNQ1jBlWz3SO64v/yE2kAGkThrvxBO02I+U1g9DS3wsF5w6xAmFjjPXGr4qd7G6KvVjdKh0Kelfte7BI2TBLp2QziixC7B/TccbHt4jX2aH691PymQID82EsB9Bq82b7J82LpaiIEJpHblk1HmO4rKXs86oBfqhfAy47mB0xDQMvywP1iFw== 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=2GQq4p9JDdW/EC4dn/MtLIcuLuvrnn7IoZnnhmYr4HA=; b=n0piPGCzPMmod7EGqCNdp1szt/yNfW6ufvwL5qY4eArRrvTdNHMzNjrpcSQbjB4/tBw/bNUwF277jo7/3c80SX2XOrDzgiS3OZwec95QhGxT0ZHE1Sn6JihH5lJJ7ZHmBsywKnvx9L3oEslejtOmzSp280+VXo433qYNF33nWZ5bYsje7ETOlzsHuefaxCi7lCadA0JjsUZTO1upu9fveNwHQISKtuc3UTIBe63Oc2XIV/d524+9DR1cDBrX3N6mppC7JDlQq3W+70KdmudXVxi0jDVY7EvYpq3KyjGdmmsiGtlLRyl76F0bHzhnkijTIPtpecBsEv04XkpDKCFOyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cu.nri.co.jp; dmarc=pass action=none header.from=cu.nri.co.jp; dkim=pass header.d=cu.nri.co.jp; arc=none Received: from OSAPR01MB4948.jpnprd01.prod.outlook.com (20.179.179.16) by OSAPR01MB3410.jpnprd01.prod.outlook.com (20.178.101.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Mon, 6 Jan 2020 06:04:52 +0000 Received: from OSAPR01MB4948.jpnprd01.prod.outlook.com ([fe80::3c17:9069:3820:d425]) by OSAPR01MB4948.jpnprd01.prod.outlook.com ([fe80::3c17:9069:3820:d425%6]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 06:04:51 +0000 From: n-sakimura To: Justin Richer , Takahiko Kawasaki CC: Brian Campbell , oauth , Nat Sakimura Thread-Topic: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object Thread-Index: AQHVXM1E4a1MvK2kCEG05sQ/CEKgqacRDgqAgAAF9QCAAAj/AICjvtQAgACwxwCACp9YgIAXqwMAgAB3mYCAABrXgIAAAwmAgAWC+oA= Date: Mon, 6 Jan 2020 06:04:51 +0000 Message-ID: References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> In-Reply-To: <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Ver 3.40R03 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.166.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0457fc7f-ed56-4180-6460-08d7926e57fc x-ms-traffictypediagnostic: OSAPR01MB3410: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(39860400002)(396003)(376002)(199004)(365934003)(53754006)(189003)(53546011)(316002)(8676002)(6506007)(4326008)(5660300002)(30864003)(54906003)(55016002)(81166006)(81156014)(110136005)(9686003)(2906002)(33656002)(966005)(478600001)(186003)(66946007)(52536014)(7696005)(8936002)(71200400001)(76116006)(66556008)(26005)(86362001)(64756008)(66446008)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB3410; H:OSAPR01MB4948.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FIEAQZ6V7rxPmtH5I/JASm3c5geMMcziJCSuQ1fFbto4kcJb5ahaq6YYJ5b7gqRIRJQedqkHZC1G11MvOGXdRCiFc92DvGUpbjj1quAnS8F5ek04oMZI0L3dKtoYihRLQzKKKjwzqmjtmjxH1zVT8ZMiZFGfyXelaPccgt0qSkKQmFSg+k/ExQqnf7GD4I6vfar5ZmNisNpA/IlXitoeVaUUykps8WTmlSelPBAi6hgkSxg7Tk/FiCRkmXlvzFYNbWjAJQkFs3ZLjDQK+dDfB3mSfi6qXQZpJCwMVCSLw8IBaLAW9KdWVoftiMled/pgWxrJESCzx2GIDAzD0M3Mtb4KHU+WCQEmaOPquQQZbCaBHp8WaxTRs1rb5NvA4A9v9fPt0HJZbGkOwLauEK6zhNxwYv2zNXCVaD+j280exIddbSq6Qt3uH0lOVtyPP7W0Jz8ETF97Zeg4+Nijs78+lyPmVkEHr1RgwK6q/w8Cto+A6q+rlKbBODdYtNUkaiEDt6wP3qsRI8acRNhsyKJFfa7Euxvfui5TDAh4rf6e+l89W+KVtZGpLsGNgqesXT45 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_OSAPR01MB4948142CA3D6677B5D34E4CEF93C0OSAPR01MB4948jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0457fc7f-ed56-4180-6460-08d7926e57fc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 06:04:51.5021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w8eFPFAVl9Y0qqusBocFVGk8gNpQGI+ENACDewbDIegWUX6SdlscYPVA5no/gxH4q7hTvDawUdZbyU554nttHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB3410 X-OrganizationHeadersPreserved: OSAPR01MB3410.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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: Mon, 06 Jan 2020 06:05:02 -0000 --_000_OSAPR01MB4948142CA3D6677B5D34E4CEF93C0OSAPR01MB4948jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXAgdW50aWwgLTEyIChGZWIgMTMsIDIwMTcpLCBpdCB3YXMgdXNpbmcgbWVyZ2UgKyBKQVIgcHJl Y2VkZW5jZSBpZiBkdXBsaWNhdGVkLg0KQXMgb2YgLTEzIChNYXIgMzAsIDIwMTcpLCBpdCB3YXMg Y2hhbmdlZCB0aGF0IHRoZSBzZXJ2ZXIgZG9lcyBub3QgaGF2ZSB0byBkbyB0aGUgbWVyZ2UsIGF0 IGxlYXN0IGZvciBPQXV0aCBBdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gSXQgc2F5 cyBub3RoaW5nIGFib3V0IG90aGVyIHBhcmFtZXRlcnMuDQpBcyBvZiAtMTQgKEp1bCAyMSwgMjAx NyksIHRoZSB3b3JkaW5nIHdhcyBmdXJ0aGVyIHN0cmVuZ3RoZW5lZCBieSBhZGRpbmcNCg0KVGhl IEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFtZXRlcnMgaW4gdGhl IFJlcXVlc3QgT2JqZWN0IGV2ZW4gaWYgdGhlIHNhbWUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGlu IHRoZSBxdWVyeSBwYXJhbWV0ZXIuDQoNClNvLCB0aGUgZW50aXJlIDYuMyBub3cgYmVjYW1lDQo2 LjM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIw I3NlY3Rpb24tNi4zPi4gIFJlcXVlc3QgUGFyYW1ldGVyIEFzc2VtYmx5IGFuZCBWYWxpZGF0aW9u DQoNCiAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIGV4dHJhY3QgdGhlIHNldCBvZiBB dXRob3JpemF0aW9uDQoNCiAgIFJlcXVlc3QgcGFyYW1ldGVycyBmcm9tIHRoZSBSZXF1ZXN0IE9i amVjdCB2YWx1ZS4gIFRoZSBBdXRob3JpemF0aW9uDQoNCiAgIFNlcnZlciBNVVNUIG9ubHkgdXNl IHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBSZXF1ZXN0IE9iamVjdCBldmVuIGlmIHRoZQ0KDQogICBz YW1lIHBhcmFtZXRlciBpcyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1ldGVyLiAgVGhlIEF1 dGhvcml6YXRpb24NCg0KICAgU2VydmVyIHRoZW4gdmFsaWRhdGVzIHRoZSByZXF1ZXN0IGFzIHNw ZWNpZmllZCBpbiBPQXV0aCAyLjANCg0KICAgW1JGQzY3NDk8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY3NDk+XS4NCg0KSXQgc2F5cyBub3RoaW5nIG9uIHRoZSBub24tT0F1dGggcGFy YW1ldGVycyB0aGF0IGNhbWUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KTXkgdGFr ZSBvbiB0aGUgdGV4dCBpcyB0aGF0IGFsbCBPQXV0aCBBdXRob3JpemF0aW9uIFJlcXVlc3QgcGFy YW1ldGVycyBNVVNUIGJlIGluIHRoZSByZXF1ZXN0IG9iamVjdC4NCkJlaGF2aW9ycyB0b3dhcmRz IG90aGVyIHBhcmFtZXRlcnMgdGhhdCBoYXBwZW5zIHRvIGhhdmUgY29tZSB0b2dldGhlciB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qgb3V0c2lkZSBvZiByZXF1ZXN0IG9iamVjdCB3aWxs IGJlIHRyZWF0ZWQgYXMgbm9uLU9BdXRoIHBhcmFtZXRlcnMuDQoNCk5hdCBTYWtpbXVyYQ0KUmVz ZWFyY2ggRmVsbG93LCBOb211cmEgUmVzZWFyY2ggSW5zdGl0dXRlDQpFOiBuLXNha2ltdXJhQG5y aS5jby5qcA0KVDogKzgxKDkwKTYwMTM2Mjc2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBMRUFTRSBSRUFEOlRoaXMgZS1tYWlsIGlz IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4N CklmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KU2VudDogRnJpZGF5LCBK YW51YXJ5IDMsIDIwMjAgMjozNSBBTQ0KVG86IFRha2FoaWtvIEthd2FzYWtpIDx0YWthQGF1dGhs ZXRlLmNvbT4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZz47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz47IE5hdCBTYWtpbXVyYSA8 bmF0LnNha2ltdXJhQG9pZGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSldUIFNlY3Vy ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpIHZzIE9JREMgcmVxdWVzdCBvYmplY3QNCg0K Rm9yIHNvbHV0aW9uIFsyXSwgdGhpcyBpcyB0aGUgYmVoYXZpb3IgdGhhdOKAmXMgcmVxdWlyZWQg Zm9yIE9JREMgdG9kYXksIHNvIEkgd291bGQgc2F5IHRoYXTigJlzIHRoZSBOZXcgQ2xpZW50IGJl aGF2aW5nIGxpa2UgYW4gT2xkIENsaWVudCBpbiBvcmRlciB0byB0YWxrIHRvIGFuIE9sZCBTZXJ2 ZXIuIFNvIGluIHJlYWxpdHksICgyKSBjYXVzZXMgdGhlIHJlcXVlc3QgdG8gYmUgcmVqZWN0ZWQs IGFuZCB0aGF04oCZcyBPSy4NCg0KSSBkb27igJl0IHRoaW5rIGl04oCZcyB2aWFibGUgdG8gcmVx dWlyZSBwYXJhbWV0ZXJzIHRvIGV4aXN0IGluc2lkZSB0aGUgcmVxdWVzdCBvYmplY3QgYXQgYWxs IHRpbWVzLiBOb3Igc2hvdWxkIHdlIHRyeSB0byBlbnVtZXJhdGUgd2hpY2ggcGFyYW1ldGVycyBn byBpbnNpZGUgYW5kIG91dHNpZGUgYXQgYWxsIHRpbWVzIOKAlCBhdCBsZWFzdCBmcm9tIHRoZSBK QVIvT0F1dGggbGV2ZWwgb2YgdGhpbmdzLiBJIHRoaW5rIHRoZXJlIGFyZSB0b28gbWFueSB0aGlu Z3MgdGhhdCBhcmUgYXBwbGljYXRpb24gYW5kIGRlcGxveW1lbnQgc3BlY2lmaWMgZm9yIHVzIHRv IG1ha2UgdGhpcyBjYWxsLiBUaGUgdmVyeSBuYXR1cmUgb2YgdGhlIHJlcXVlc3Qgb2JqZWN0IGNo YW5nZXMgZm9yIHBlb3BsZSDigJQgc29tZSBoYXZlIGEgc3RhdGljIG9iamVjdCB0aGF04oCZcyBk ZXBsb3llZCB3aXRoIGNsaWVudHMgYW5kIHNvbWUgaGF2ZSBzb21ldGhpbmcgdGhhdCB0aGUgY2xp ZW50IGNyZWF0ZXMgYXQgcnVudGltZSBmb3IgZWFjaCByZXF1ZXN0Lg0KDQpJZiB0aGUgaW5zdGVh ZCB0aGUgTmV3IFNlcnZlciByZXF1aXJlcyB0aGF0IGFueSBwYXJhbWV0ZXJzIGR1cGxpY2F0ZWQg YmV0d2VlbiB0aGUgdHdvIHBsYWNlcyBoYXZlIHRvIG1hdGNoICh0aGUgT0lEQyBtZXRob2QpIG9y IHRoYXQgaW4gYSBjb25mbGljdCB0aGUgcmVxdWVzdCBvYmplY3QgdmFsdWVzIHRha2UgcHJlY2Vk ZW5jZSAodGhlIG1lcmdlIG1ldGhvZCksIHRoZW4gcHJvYmxlbXMgMy0xIGFuZCAzLTIgZ28gYXdh eS4NCg0KV2l0aCB0aGUgbWVyZ2UtYW5kLXByZWNlZGVuY2UgYmVoYXZpb3IsIHdoaWNoIGlzIHdo YXQgSSB0aG91Z2h0IHRoYXQgSkFSIGhhZCBkdXJpbmcgV0dMQywgWzMtMV0gaXMgd2VsbC1kZWZp bmVkLiBUaGUgcmVxdWVzdCBpcyBwcm9jZXNzZWQgdGhlIHNhbWUgd2F5IGV2ZXJ5IHRpbWUgYmVj YXVzZSB0aGlzIGlzIGEgTmV3IFNlcnZlci4gVGhlIGNsaWVudCBpcyBnb2luZyB0byBkbyBPSURD 4oCZcyDigJxkdXBsaWNhdGXigJ0gbWV0aG9kLCBzbyDigJxtZXJnZSB3aXRoIHByZWNlZGVuY2Xi gJ0gaXMgZWZmZWN0aXZlbHkgYSBuby1vcC4NCg0KV2l0aCB0aGUgbWVyZ2UtYW5kLXByZWNlZGVu Y2UgYmVoYXZpb3IsIFszLTJdIGRvZXNu4oCZdCBoYXBwZW4gYmVjYXVzZSB0aGUgcmVxdWlyZWQg cGFyYW1ldGVycyBhcmVu4oCZdCByZXF1aXJlZCB0byBiZSBpbiB0aGUgcmVxdWVzdCBvYmplY3Qg aXRzZWxmLiBBcyBsb25nIGFzIHRoZSByZXF1ZXN0IG9iamVjdCBpcyB2YWxpZCwgaXQgcHJvdGVj dHMgYWxsIHBhcmFtZXRlcnMgd2l0aGluIGl0LiBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIHVwIHRv IHVzIHRvIGRldGVybWluZSB3aGF0IG1ha2VzIHNlbnNlIHRvIHB1dCBpbiB0aGF0IG9iamVjdC4g U2VjdXJpdHkgZ3VpZGFuY2UgaXMgcHJvYmFibHkgYSBnb29kIGlkZWEgaGVyZS4NCg0KU29sdXRp b24gWzNdIGlzIHdoYXQgT2xkIENsaWVudHMgYWxyZWFkeSBkbyBpbiBPSURDIHRvZGF5LCBzbyB0 aGF04oCZcyB3aGF0IGFscmVhZHkgaGFwcGVucyBhbmQgd2h5IHByb2JsZW0gc3BhY2UgKDMpIGlz buKAmXQgYSBwcm9ibGVtLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEphbiAyLCAyMDIwLCBhdCAx MjoyNCBQTSwgVGFrYWhpa28gS2F3YXNha2kgPHRha2FAYXV0aGxldGUuY29tPG1haWx0bzp0YWth QGF1dGhsZXRlLmNvbT4+IHdyb3RlOg0KDQpUaGFuayB5b3UsIEp1c3Rpbi4gQWN0dWFsbHksIEkg d2FudGVkIHRvIHNlZSBzb21lb25lIHdyaXRlIGEgc3VtbWFyeSBhYm91dCB3aGF0IGhhcHBlbnMg aW4gZWFjaCBjb21iaW5hdGlvbiBmcm9tIGEgdmlld3BvaW50IG9mIGJvdGggUlAgYW5kIEFTIHdp dGggcmVnYXJkIHRvIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgKGFzIEkgdG9sZCB5b3UgaW4gb3Ro ZXIgY2hhbm5lbCBqdXN0IGJlZm9yZSB5b3UgcG9zdGVkIHlvdXIgZW1haWwgXl9eKS4NCg0KU28s DQoNCigxKSBOZXcgQ2xpZW50ICsgTmV3IFNlcnZlcg0KTm8gcHJvYmxlbSB3aWxsIGhhcHBlbi4N Cg0KKDIpIE5ldyBDbGllbnQgKyBPbGQgU2VydmVyDQpbUHJvYmxlbSAyLTFdIElmIGFuIGF1dGhv cml6YXRpb24gcmVxdWVzdCBjb250YWlucyAncmVxdWVzdCcgb3IgJ3JlcXVlc3RfdXJpJyBidXQg ZG9lc24ndCBoYXZlIG9sZCBtYW5kYXRvcnkgcmVxdWVzdCBwYXJhbWV0ZXJzICgnY2xpZW50X2lk JyBhbmQgJ3Jlc3BvbnNlX3R5cGUnKSBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVjdCwgdGhlIHJl cXVlc3QgaXMgcmVqZWN0ZWQuDQoNCltTb2x1dGlvbiAyXSBOZXcgQ2xpZW50IHNob3VsZCBpbmNs dWRlIHRoZSBvbGQgbWFuZGF0b3J5IHJlcXVlc3QgcGFyYW1ldGVycyBkdXBsaWNhdGVseSBvdXRz aWRlIHRoZSByZXF1ZXN0IG9iamVjdC4gVGhpcyBtZWFucyB0aGF0IE5ldyBDbGllbnQgc2hvdWxk IGFsd2F5cyBzZW5kIG9sZCBtYW5kYXRvcnkgcmVxdWVzdCBwYXJhbWV0ZXJzIGR1cGxpY2F0ZWx5 IG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0IGlmIGl0IHdhbnRzIHRvIGdldCBtYXhpbXVtIGNv bXBhdGliaWxpdHkuDQoNCigzKSBPbGQgQ2xpZW50ICsgTmV3IFNlcnZlcg0KW1Byb2JsZW0gMy0x XSBJZiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgY29udGFpbnMgJ3JlcXVlc3QnIG9yICdyZXF1 ZXN0X3VyaScgYW5kIHNvbWUgIm9wdGlvbmFsIiByZXF1ZXN0IHBhcmFtZXRlcnMgYXJlIG5vdCBp bmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBvYmplY3QsIEFTIHdpbGwgaW50ZXJwcmV0IHRoZSByZXF1 ZXN0IGRpZmZlcmVudGx5LiBJbWFnaW5lIHdoYXQgaGFwcGVucyB3aGVuIG9wdGlvbmFsIHBhcmFt ZXRlcnMgc3VjaCBhcyAnc2NvcGUnLCAnc3RhdGUnLCAnbm9uY2UnLCAncmVkaXJlY3RfdXJpJywg J3Jlc3BvbnNlX21vZGUnLCAnbWF4X2FnZScsICdhY3JfdmFsdWVzJywgJ2NvZGVfY2hhbGxlbmdl JywgJ2NvZGVfY2hhbGxlbmdlX21ldGhvZCcgYW5kICdwcm9tcHQnIGFyZSBub3QgaW5jbHVkZWQg aW4gdGhlIHJlcXVlc3Qgb2JqZWN0IGJ1dCBwcmVzZW50IG91dHNpZGUgdGhlIHJlcXVlc3Qgb2Jq ZWN0Lg0KDQpbUHJvYmxlbSAzLTJdIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBjb250YWlu cyAncmVxdWVzdCcgb3IgJ3JlcXVlc3RfdXJpJyBhbmQgc29tZSAibWFuZGF0b3J5IiByZXF1ZXN0 IHBhcmFtZXRlcnMgKCdjbGllbnRfaWQnIGFuZCAncmVzcG9uc2VfdHlwZScpIGFyZSBub3QgaW5j bHVkZWQgaW4gdGhlIHJlcXVlc3Qgb2JqZWN0LCB0aGUgcmVxdWVzdCBpcyByZWplY3RlZC4NCg0K W1NvbHV0aW9uIDNdIE9sZCBDbGllbnQgc2hvdWxkIGluY2x1ZGUgYWxsIHJlcXVlc3QgcGFyYW1l dGVycyBkdXBsaWNhdGVseSBpbiB0aGUgcmVxdWVzdCBvYmplY3QuIFRoaXMgbWVhbnMgdGhhdCBP bGQgQ2xpZW50IHNob3VsZCBhbHdheXMgaW5jbHVkZSBhbGwgcmVxdWVzdCBwYXJhbWV0ZXJzIGR1 cGxpY2F0ZWx5IGluIHRoZSByZXF1ZXN0IG9iamVjdCBpZiBpdCB3YW50cyB0byBnZXQgbWF4aW11 bSBjb21wYXRpYmlsaXR5Lg0KDQooNCkgT2xkIENsaWVudCArIE9sZCBTZXJ2ZXINCk5vIHByb2Js ZW0gd2lsbCBoYXBwZW4uDQoNCi0gLSAtDQoNCkZyb20gYSBDbGllbnQncyBwb2ludCBvZiB2aWV3 LCBmb3IgbWF4aW11bSBjb21wYXRpYmlsaXR5LCBib3RoIE9sZCBhbmQgTmV3IENsaWVudHMgc2hv dWxkIHB1dCBtYW5kYXRvcnkgcmVxdWVzdCBwYXJhbWV0ZXJzIG91dHNpZGUgdGhlIHJlcXVlc3Qg b2JqZWN0IGFuZCBwdXQgYWxsIHJlcXVlc3QgcGFyYW1ldGVycyBkdXBsaWNhdGVseSBpbnNpZGUg dGhlIHJlcXVlc3Qgb2JqZWN0Lg0KDQpbUHJvYmxlbSAzLTFdIGlzIGRpZmZpY3VsdCB0byBkZXRl Y3QgYmVjYXVzZSB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5vdCByZWplY3RlZC4gQnV0 LCBpZiBOZXcgU2VydmVyIHJlcXVpcmVzIHRoYXQgYWxsIHJlcXVlc3QgcGFyYW1ldGVycyBvdXRz aWRlIHRoZSByZXF1ZXN0IG9iamVjdCBiZSBwdXQgaW5zaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBk dXBsaWNhdGVseSwgW1Byb2JsZW0gMy0xXSBpcyBoYW5kbGVkIGFzIGFuIGVycm9yIGFuZCB0aHVz IGNsaWVudCBkZXZlbG9wZXJzIGNhbiBkZXRlY3QgdGhlIHByb2JsZW0uDQoNCkNvbnNlcXVlbnRs eSwgaW50cm9kdWNpbmcgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudCBpbiAiRkFQSSBQYXJ0IDIs IDUuMi4yPGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtZmluYW5jaWFsLWFwaS1wYXJ0 LTItSUQyLmh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXI+LCAxMCIgdG8gSkFSIHNlZW1zIGEgZ29v ZCBjb21wcm9taXNlIChhcyBJIHRvbGQgYmVmb3JlKQ0Kc2hhbGwgcmVxdWlyZSB0aGF0IGFsbCBw YXJhbWV0ZXJzIGFyZSBwcmVzZW50IGluc2lkZSB0aGUgc2lnbmVkIHJlcXVlc3Qgb2JqZWN0IHBh c3NlZCBpbiB0aGUgcmVxdWVzdCBvciByZXF1ZXN0X3VyaSBwYXJhbWV0ZXI7DQoNCmluc3RlYWQg b2YganVzdCBzYXlpbmcgInRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzdXBwb3J0aW5nIHRoaXMg c3BlY2lmaWNhdGlvbiBNVVNUIG9ubHkgdXNlIHRoZSBwYXJhbWV0ZXJzIGluY2x1ZGVkIGluIHRo ZSByZXF1ZXN0IG9iamVjdC4iIHdoaWNoIHdpbGwgYnJpbmcgYWJvdXQgW1Byb2JsZW0gMy0xXS4g VGhhdCBpcywgaG93IGFib3V0IGFkZGluZyBhIHJ1bGUgbGlrZSAiaWYgcmVxdWVzdCBwYXJhbWV0 ZXJzIGV4aXN0IG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0LCB0aGV5IG11c3QgZXhpc3QgaW5z aWRlIHRoZSByZXF1ZXN0IG9iamVjdCwgdG9vLiI/DQoNCkFueSB0aG91Z2h0cz8NCg0KQmVzdCwN ClRha2ENCg0KDQpPbiBGcmksIEphbiAzLCAyMDIwIGF0IDEyOjQ4IEFNIEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpJIHRoaW5r IHRoZSBuYXR1cmUgb2YgdGhlIGJhY2t3YXJkcyBpbmNvbXBhdGliaWxpdHkgaXMgaW1wb3J0YW50 IGhlcmUuIFRoZSB3YXkgdGhhdCB0aGluZ3MgYXJlIG5vdywgdXNpbmcgbWVyZ2Utd2l0aC1wcmVj ZWRlbmNlLCB5b3UgaGF2ZSB0aGUgZm9sbG93aW5nIG1hdHJpeCBvZiBjb21wYXRpYmlsaXR5Og0K DQoNCiAgICAgICAgICAgICBOZXcgU2VydmVyICB8ICBPbGQgU2VydmVyICB8DQotLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKw0KTmV3IENsaWVudCB8ICAgICAgWUVTICAg IHwgICAgICBOTyAgICAgIHwNCk9sZCBDbGllbnQgfCAgICAgIFlFUyAgICB8ICAgICBZRVMgICAg ICB8DQoNCg0KSWYgeW91IGFzayBtZSwgdGhpcyBpcyB0aGUgcmlnaHQgYmFsYW5jZSBmb3IgYSBi cmVha2luZyBjaGFuZ2UuIE9sZCBjbGllbnRzLCB3aGVyZSB0aGUgdmFzdCBtYWpvcml0eSBvZiB0 aGUgY29kZSBpcywgZG9u4oCZdCBoYXZlIHRvIGNoYW5nZS4gTmV3IGNsaWVudHMgY2FuIG9ubHkg dGFsayB0byBzZXJ2ZXJzIHdpdGggdGhlIG5ldyBmZWF0dXJlcywgd2hpY2ggaXMgdGhlIGFiaWxp dHkgdG8gZHJvcCBwYXJhbWV0ZXJzIGZyb20gdGhlIGV4dGVybmFsIHJlcXVlc3QuIFRoaXMgd291 bGQgYXBwbHkgdG8gYm90aCBPSURDIGFuZCBwbGFpbiBPQXV0aC4NCg0KSSB0aGluayB3ZSBzaG91 bGQgZm9sbG93IHRoaXMga2luZCBvZiBwYXR0ZXJuIGluIHRoZSBkaXNjdXNzaW9ucyBvbiBPQXV0 aCAyLjEsIHdoaWNoIEkgdGhpbmsgSkFSIHNob3VsZCBiZSBhIHBhcnQgb2YvDQoNCiDigJQgSnVz dGluDQoNCg0KDQoNCk9uIEphbiAyLCAyMDIwLCBhdCAzOjQwIEFNLCBUYWthaGlrbyBLYXdhc2Fr aSA8dGFrYUBhdXRobGV0ZS5jb208bWFpbHRvOnRha2FAYXV0aGxldGUuY29tPj4gd3JvdGU6DQoN CkJyZWFraW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaW4gdGhpcyBwYXJ0IHdvdWxkIG1lYW4g dGhhdCBPcGVuSUQgQ2VydGlmaWNhdGlvbiBnaXZlbiB0byBBUyBpbXBsZW1lbnRhdGlvbnMgd2l0 aCByZXF1ZXN0X3VyaSBzdXBwb3J0IHdpbGwgYmUgaW52YWxpZGF0ZWQgb25jZSB0aGV5IHN1cHBv cnQgSkFSLiBJdCBhbHNvIHdvdWxkIG1lYW4gdGhhdCB0ZXN0IGNhc2VzIGluIHRoZSBvZmZpY2lh bCBjb25mb3JtYW5jZSBzdWl0ZSBuZWVkIHRvIGJlIGNoYW5nZWQgaW4gYSBiYWNrd2FyZC1pbmNv bXBhdGlibGUgbWFubmVyLCB3aGljaCB3b3VsZCBpbXBsaWNpdGx5IGVuY291cmFnZSB0aGF0IGFs bCBjZXJ0aWZpZWQgaW1wbGVtZW50YXRpb25zIHNob3VsZCByZS10cnkgdG8gZ2V0IGNlcnRpZmlj YXRpb24uDQoNCkNoYW5naW5nIHRoZSBzcGVjIG5vdyBtaWdodCBuZWVkIG1vcmUgdGhyZWUgdG8g c2l4IG1vbnRocywgYnV0IGl0IHdvdWxkIGJlIHdvcnRoIGNvbnNpZGVyaW5nIHdoYXQgd2UgZ2V0 IGFuZCBsb3NlIGJ5IHNhdmluZyB0aGUgbW9udGhzIGFuZCBicmVha2luZyBiYWNrd2FyZCBjb21w YXRpYmlsaXR5Lg0KDQpCZXN0IFJlZ2FyZHMsDQpUYWthDQoNCk9uIFdlZCwgRGVjIDE4LCAyMDE5 IGF0IDQ6MTQgUE0gTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2lt dXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KU28sIG5vIGNoYW5nZSBpcyBPSz8NCg0KT24gV2VkLCBE ZWMgMTEsIDIwMTkgYXQgMTA6MDEgUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgYWxzbyBzbGlnaHRseSBwcmVmZXIg dGhlIG1lcmdlIGFwcHJvYWNoLg0KDQpUaGVyZSBhcmUgcGx1c3NlcyBhbmQgbWludXNlcyB0byBi b3RoLg0KDQpDaGFuZ2luZyBhZ2FpbiBub3cgdGhhdCBpdCBpcyBwYXN0IElTRUcgcmV2aWV3IGFu ZCBiYWNraW5nIG91dCBhIERpc2N1c3Mgd2lsbCBhZGQgYW5vdGhlciB0aHJlZSB0byBzaXggbW9u dGhzIGF0IHRoaXMgcG9pbnQsIGlmIHdlIGNhbiBnZXQgdGhlbSB0byBhZ3JlZSB0byB0aGUgY2hh bmdlLg0KDQpKb2huIEIuDQoNCk9uIFR1ZSwgRGVjIDEwLCAyMDE5LCAxMToyOSBQTSBOYXQgU2Fr aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3Jv dGU6DQpDb3JyZWN0LiBUaGUgV0cgc3VwcG9ydGVkIHRoZSBwcmVjZWRlbmNlIGFwcHJvYWNoIGFu ZCBldmVuIG1lcmdlIGp1c3QgbGlrZSBPSURDIGFzIGl0IGlzIHZlcnkgdXNlZnVsIGZyb20gdGhl IGltcGxlbWVudGF0aW9uIHBvaW50IG9mIHZpZXcgYW5kIGhlbHBzIHdpdGggYSBidW5jaCBvZiBk ZXBsb3ltZW50IHBhdHRlci4NCg0KVGhlIHB1c2ggYmFjayBjYW1lIGluIGZyb20gdGhlIEJlbiBD YW1wYmVsbOKAmXMgRElTQ1VTUy4NClNlZQ0KaHR0cHM6Ly9iaXRidWNrZXQub3JnL05hdC9vYXV0 aC1qd3NyZXEvaXNzdWVzLzcwL2JjLXRoZS1jdXJyZW50LXRleHQtYWN0dWFsbHktc3BlY2lmaWVz LXRoZQ0KDQpJIGFtIHdpbGxpbmcgdG8gZ28gZWl0aGVyIHdheSBhcyBsb25nIGFzIHBlb3BsZSBh Z3JlZS4gTXkgc2xpZ2h0IHByZWZlcmVuY2UgaXMgdG8gdGhlIG9yaWdpbmFsIGFwcHJvYWNoLg0K DQpCZXN0LA0KDQpOYXQgU2FraW11cmENCg0KMjAxOeW5tDjmnIgyOeaXpSjmnKgpIDY6NTYgQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS4uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+PjoNCkZXSVcsIGFzIGJl c3QgSSBjYW4gcmVtZW1iZXIgdGhlIGNoYW5nZSBpbiBxdWVzdGlvbiBjYW1lIGFzIEkgcmVzdWx0 IG9mIGRpcmVjdG9yYXRlL0lFU0cgcmV2aWV3IHJhdGhlciB0aGFuIGEgV0cgZGVjaXNpb24vZGlz Y3Vzc2lvbi4gV2hpY2ggaXMgbGlrZWx5IHdoeSB5b3UgY2FuJ3QgZmluZCB0aGUgIndoeSIgYW55 d2hlcmUgaW4gdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlLg0KDQpPbiBXZWQsIEF1ZyAyOCwgMjAx OSBhdCAzOjIzIFBNIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52 YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCldlbGwgaXQga2luZCBvZiBibG93cywgZG9lc24ndCBp dD8gSSB3YXNuJ3QgYWJsZSB0byBmaW5kIHRoZSAid2h5IiBhbnl3aGVyZSBpbiB0aGUgbWFpbGlu ZyBsaXN0IGFyY2hpdmUgYXJvdW5kIHRoZSB0aW1lIHRoaXMgd2FzIGNoYW5nZWQuDQoNCk15IHRh a2Ugb24gc2F0aXNmeWluZyBib3RoIHdvcmxkcyBsb29rcyBsaWtlIHRoaXMNCg0KLSBhbGxvdyBq dXN0IEpBUiAtIG5vIG90aGVyIHBhcmFtcyB3aGVuIHBvc3NpYmxlLg0KICAgICh3aGljaCBidHcg aXNuJ3QgcG9zc2libGUgdG8gZG8gd2l0aCByZXF1ZXN0X3VyaSB3aGVuIGVuZm9yY2luZyBjbGll bnQgYmFzZWQgdXJpIHdoaXRlbGlzdCBhbmQgdGhlIGp3c3JlcSA1LjIuMiBzaG93cyBhcyBtdWNo KQ0KLSBlbmZvcmNlIHRoZSAiZHVwZSBiZWhhdmlvdXJzIiBkZWZpbmVkIGluIE9JREMgKGlmIHJl c3BvbnNlX3R5cGUgb3IgY2xpZW50X2lkIGlzIGluIHJlcXVlc3Qgb2JqZWN0IGl0IG11c3QgZWl0 aGVyIGJlIG1pc3Npbmcgb3IgdGhlIHNhbWUgaW4gcmVndWxhciByZXF1ZXN0KS4NCi0gYWxsb3dz IG1lcmdpbmcgcmVxdWVzdCBvYmplY3QgYW5kIHJlZ3VsYXIgcGFyYW1ldGVycyB3aXRoIHJlcXVl c3Qgb2JqZWN0IHRha2luZyBwcmVjZWRlbmNlIHNpbmNlIGl0IGlzIGEgdmVyeSB1c2VmdWwgZmVh dHVyZSB3aGVuIGhhdmluZyBwcmUtc2lnbmVkIHJlcXVlc3Qgb2JqZWN0IHRoYXQncyBub3Qgb25l IHRpbWUgdXNlIGFuZCBjbGllbnRzIHVzaW5nIGl0IHdpc2ggdG8gdmFyeSBzdGF0ZS9ub25jZSBw ZXItcmVxdWVzdC4NCg0KSSB3aXNoIHRoZSBncm91cCByZWNvbnNpZGVyZWQgbWFraW5nIHRoaXMg YnJlYWtpbmcgY2hhbmdlIGZyb20gT0lEQydzIHRha2Ugb24gcmVxdWVzdCBvYmplY3RzIC0gYWxs b3cgY29tYmluYXRpb24gb2YgcGFyYW1ldGVycyBmcm9tIHRoZSByZXF1ZXN0IG9iamVjdCB3aXRo IG9uZXMgZnJvbSByZWd1bGFyIHBhcmFtZXRlcnMgKGlmIG5vdCBwcmVzZW50IGluIHJlcXVlc3Qg b2JqZWN0KS4NCg0KUyBwb3pkcmF2ZW0sDQpGaWxpcCBTa29rYW4NCg0KDQpPbiBXZWQsIDI4IEF1 ZyAyMDE5IGF0IDIzOjAyLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpGaWxpcCwgZm9y IGJldHRlciBvciB3b3JzZSwgSSBiZWxpZXZlIHlvdXIgYXNzZXNzbWVudCBvZiB0aGUgc2l0dWF0 aW9uIGlzIGNvcnJlY3QuIEkga25vdyBvZiBvbmUgQVMgdGhhdCBkaWRuJ3QgY2hvb3NlIHdoaWNo IG9mIHRoZSB0d28gdG8gZm9sbG93IGJ1dCByYXRoZXIgaW1wbGVtZW50ZWQgYSBiaXQgb2YgYSBo eWJyaWQgd2hlcmUgaXQgYmFzaWNhbGx5IGlnbm9yZXMgZXZlcnl0aGluZyBvdXRzaWRlIG9mIHRo ZSByZXF1ZXN0IG9iamVjdCBwZXIgSkFSIGJ1dCBhbHNvIGNoZWNrcyBmb3IgYW5kIGVuZm9yY2Vz IHRoZSBwcmVzZW5jZSBhbmQgdmFsdWUgb2YgdGhlIGZldyByZWd1bGFyIHBhcmFtZXRlcnMgKGNs aWVudF9pZCwgcmVzcG9uc2VfdHlwZSkgdGhhdCBPSURDIG1hbmRhdGVzLg0KDQpPbiBUdWUsIEF1 ZyAyNywgMjAxOSBhdCA1OjQ3IEFNIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1h aWx0bzpwYW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCkhlbGxvIGV2ZXJ5b25lLA0KDQppbiBh biBlYXJsaWVyIHRocmVhZCBJJ3ZlIHBvc2VkIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gdGhhdCBt aWdodCBoYXZlIGdvdHRlbiBtaXNzZWQsIHRoaXMgbWlnaHQgaGF2ZSBjb25zZXF1ZW5jZXMgZm9y IHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgUmVxdWVzdCBPYmplY3RzIGluIE9JREMg aW1wbGVtZW50YXRpb25zIC0gaXRzIG1ha2luZyBwdXJlIEpBUiByZXF1ZXN0cyBpbmNvbXBhdGli bGUgd2l0aCBPSURDIENvcmUgaW1wbGVtZW50YXRpb25zLg0KDQpkcmFmdCAxNCBvZiBqd3NyZXEg KEpBUikgaW50cm9kdWNlZCB0aGlzIGxhbmd1YWdlDQoNClRoZSBjbGllbnQgTUFZIHNlbmQgdGhl IHBhcmFtZXRlcnMgaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3Qgb2JqZWN0DQpkdXBsaWNhdGVkIGlu IHRoZSBxdWVyeSBwYXJhbWV0ZXJzIGFzIHdlbGwgZm9yIHRoZSBiYWNrd2FyZA0KY29tcGF0aWJp bGl0eSBldGMuICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc3VwcG9ydGluZyB0 aGlzDQpzcGVjaWZpY2F0aW9uIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFtZXRlcnMgaW5jbHVkZWQg aW4gdGhlIHJlcXVlc3QNCm9iamVjdC4NCg0KU2VydmVyIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFt ZXRlcnMgaW4gdGhlIFJlcXVlc3QgT2JqZWN0IGV2ZW4gaWYgdGhlDQpzYW1lIHBhcmFtZXRlciBp cyBwcm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1ldGVyLiAgVGhlIEF1dGhvcml6YXRpb24NCg0K VGhlIGNsaWVudCBNQVkgc2VuZCB0aGUgcGFyYW1ldGVycyBpbmNsdWRlZCBpbiB0aGUgcmVxdWVz dCBvYmplY3QNCmR1cGxpY2F0ZWQgaW4gdGhlIHF1ZXJ5IHBhcmFtZXRlcnMgYXMgd2VsbCBmb3Ig dGhlIGJhY2t3YXJkDQpjb21wYXRpYmlsaXR5IGV0Yy4gIEhvd2V2ZXIsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBzdXBwb3J0aW5nIHRoaXMNCnNwZWNpZmljYXRpb24gTVVTVCBvbmx5IHVzZSB0 aGUgcGFyYW1ldGVycyBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdA0Kb2JqZWN0Li4NCg0KTmF0LCBK b2huLCBldmVyeW9uZSAtIGRvZXMgdGhpcyBtZWFuIGEgSkFSIGNvbXBsaWFudCBBUyBpZ25vcmVz IGV2ZXJ5dGhpbmcgb3V0c2lkZSBvZiB0aGUgcmVxdWVzdCBvYmplY3Qgd2hpbGUgT0lEQyBSZXF1 ZXN0IE9iamVjdCBvbmUgbWVyZ2VzIHRoZSB0d28gd2l0aCB0aGUgb25lcyBpbiB0aGUgcmVxdWVz dCBvYmplY3QgYmVpbmcgdXNlZCBvdmVyIG9uZXMgdGhhdCBhcmUgc2VudCBpbiBjbGVhcj8gVGhl IE9JREMgbGFuZ3VhZ2UgYWxzbyBpbmNsdWRlcyBzZWN0aW9ucyB3aGljaCBtYWtlIHN1cmUgdGhh dCBzb21lIHJlcXVpcmVkIGFyZ3VtZW50cyBhcmUgc3RpbGwgcGFzc2VkIG91dHNpZGUgb2YgdGhl IHJlcXVlc3Qgb2JqZWN0IHdpdGggdGhlIHNhbWUgdmFsdWUgdG8gbWFrZSBzdXJlIHRoZSByZXF1 ZXN0IGlzICJ2YWxpZCIgT0F1dGggMi4wIHJlcXVlc3QgKGNsaWVudF9pZCwgcmVzcG9uc2VfdHlw ZSksIHNvbWV0aGluZyB3aGljaCBhbiBleGFtcGxlIGluIHRoZSBKQVIgc3BlYyBkb2VzIG5vdCBk by4gTm90IGhhdmluZyB0aGlzIGxhbmd1YWdlIG1lYW5zIHRoYXQgZXhpc3RpbmcgYXV0aG9yaXph dGlvbiByZXF1ZXN0IHBpcGVsaW5lcyBjYW4ndCBzaW1wbHkgYmUgZXh0ZW5kZWQgd2l0aCBlLmcu IGEgbWlkZGxld2FyZSwgdGhleSBuZWVkIHRvIGJyYW5jaCB0aGVpciBjb2RlcGF0aHMuDQoNCklz IGFuIEFTIHJlcXVpcmVkIHRvIGNob29zZSB3aGljaCBvZiB0aGUgdHdvIGl0IGZvbGxvd3M/DQoN ClRoYW5rIHlvdSBmb3IgY2xhcmlmeWluZyB0aGlzIGluIGFkdmFuY2UuIEkgdGhpbmsgaWYgZWl0 aGVyIHRoZSBiZWhhdmlvdXIgaXMgdGhlIHNhbWUgYXMgaW4gT0lEQyBvciBkaWZmZXJlbnQgdGhp cyBzaG91bGQgYmUgY2FsbGVkIG91dCBpbiB0aGUgbGFuZ3VhZ2UgdG8gYXZvaWQgY29uZnVzaW9u LCBlc3BlY2lhbGx5IHNpbmNlIHRoaXMgYWxyZWFkeSBleGlzdHMgaW4gT0lEQyBhbmQgbGlrZWx5 IGlzbid0IGdvaW5nIHRvIGJlIHJlYWQgaW4gaXNvbGF0aW9uLCBlc3BlY2lhbGx5IGJlY2F1c2Ug dGhlIFJlcXVlc3QgT2JqZWN0IGlzIGV2ZW4gY2FsbGVkIG91dCB0byBiZSBhbHJlYWR5IGluIHBs YWNlIGluIE9JREMgaW4gdGhlIEpBUiBkcmFmdC4NCg0KQmVzdCwNCkZpbGlwDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4uLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g VGhhbmsgeW91Ll9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQpOYXQg U2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQu c2FraW11cmEub3JnLw0KQF9uYXRfZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3Vu ZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0K --_000_OSAPR01MB4948142CA3D6677B5D34E4CEF93C0OSAPR01MB4948jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDmmI7mnJ0iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToi77yt77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk65ri444K044K344OD44KvOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K0 44K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5ri444K044K3 44OD44KvIjsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQO+8re+8syDvvLDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEg NiAwIDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIOaY juacnSI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KaDMN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuimi+WHuuOBlyAzIFwo 5paH5a2XXCkiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowbW07 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MG1tOw0KCWZvbnQt c2l6ZToxMy41cHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfjg4Pjgq8iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg5pu45byP5LuY44GNIFwo5paH5a2XXCkiOw0K CW1hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6Iu+8re+8syDjgrTjgrfjg4Pjgq8iO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowbW07DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MG1tOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfjg4Pjgq8iO30NCnNwYW4uMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk65ri444K044K344OD44KvOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi4zDQoJe21zby1zdHlsZS1uYW1lOiLopovlh7rjgZcgMyBc KOaWh+Wtl1wpIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi6KaL 5Ye644GXIDMiOw0KCWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglmb250 LXdlaWdodDpib2xkO30NCnNwYW4uSFRNTA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDmm7jlvI/k u5jjgY0gXCjmloflrZdcKSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOabuOW8j+S7mOOBjSI7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDjgrTjgrfjg4Pj gq8iO30NCnNwYW4uMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq87DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTku MjVwdCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2Ij4NCjx2OnRleHRib3ggaW5zZXQ9 IjUuODVwdCwuN3B0LDUuODVwdCwuN3B0IiAvPg0KPC9vOnNoYXBlZGVmYXVsdHM+PC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkpBIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk65ri444K044K344OD44KvIj5VcCB1bnRpbCAtMTIgKEZlYiAxMywgMjAxNyksIGl0 IHdhcyB1c2luZyBtZXJnZSAmIzQzOyBKQVIgcHJlY2VkZW5jZSBpZiBkdXBsaWNhdGVkLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+ODg+OCryI+ QXMgb2YgLTEzIChNYXIgMzAsIDIwMTcpLCBpdCB3YXMgY2hhbmdlZCB0aGF0IHRoZSBzZXJ2ZXIg ZG9lcyBub3QgaGF2ZSB0byBkbyB0aGUgbWVyZ2UsIGF0IGxlYXN0IGZvciBPQXV0aCBBdXRob3Jp emF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gSXQgc2F5cyBub3RoaW5nIGFib3V0IG90aGVyIHBh cmFtZXRlcnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri4 44K044K344OD44KvIj5BcyBvZiAtMTQgKEp1bCAyMSwgMjAxNyksIHRoZSB3b3JkaW5nIHdhcyBm dXJ0aGVyIHN0cmVuZ3RoZW5lZCBieSBhZGRpbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90OyI+VGhlIEF1dGhvcml6YXRp b24gU2VydmVyIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIFJlcXVlc3QgT2Jq ZWN0IGV2ZW4gaWYgdGhlIHNhbWUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGluIHRoZSBxdWVyeSBw YXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oua4uOOC tOOCt+ODg+OCryI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5Oua4uOOCtOOCt+ODg+OCryI+U28sIHRoZSBlbnRpcmUgNi4zIG5vdyBiZWNhbWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8aDMgc3R5bGU9Im1hcmdpbi1sZWZ0OjQ4LjBwdCI+PGEgbmFtZT0i c2VjdGlvbi02LjMiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjAjc2VjdGlvbi02LjMiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6JnF1b3Q7c2VjdGlvbi02XC4zJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDsiPjYuMzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazomcXVvdDtzZWN0aW9uLTZcLjMmcXVvdDsi Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazomcXVvdDtzZWN0aW9uLTZcLjMm cXVvdDsiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDsiPi4mbmJzcDsNCiBSZXF1ZXN0IFBhcmFtZXRlciBB c3NlbWJseSBhbmQgVmFsaWRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvaDM+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1VU1Qg ZXh0cmFjdCB0aGUgc2V0IG9mIEF1dGhvcml6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBSZXF1ZXN0IHBhcmFtZXRlcnMg ZnJvbSB0aGUgUmVxdWVzdCBPYmplY3QgdmFsdWUuJm5ic3A7IFRoZSBBdXRob3JpemF0aW9uPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgU2VydmVyIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIFJlcXVlc3QgT2Jq ZWN0IGV2ZW4gaWYgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsgc2FtZSBwYXJhbWV0ZXIgaXMgcHJvdmlkZWQgaW4gdGhlIHF1 ZXJ5IHBhcmFtZXRlci4mbmJzcDsgVGhlIEF1dGhvcml6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBTZXJ2ZXIgdGhlbiB2 YWxpZGF0ZXMgdGhlIHJlcXVlc3QgYXMgc3BlY2lmaWVkIGluIE9BdXRoIDIuMDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSIgdGl0bGU9IiZxdW90O1Ro ZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsmcXVvdDsiPlJGQzY3NDk8L2E+XS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pj gq8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrmuLjj grTjgrfjg4Pjgq8iPkl0IHNheXMgbm90aGluZyBvbiB0aGUgbm9uLU9BdXRoIHBhcmFtZXRlcnMg dGhhdCBjYW1lIHdpdGggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPk15IHRha2Ugb24g dGhlIHRleHQgaXMgdGhhdCBhbGwgT0F1dGggQXV0aG9yaXphdGlvbiBSZXF1ZXN0IHBhcmFtZXRl cnMgTVVTVCBiZSBpbiB0aGUgcmVxdWVzdCBvYmplY3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5CZWhhdmlvcnMgdG93YXJkcyBv dGhlciBwYXJhbWV0ZXJzIHRoYXQgaGFwcGVucyB0byBoYXZlIGNvbWUgdG9nZXRoZXIgd2l0aCB0 aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IG91dHNpZGUgb2YgcmVxdWVzdCBvYmplY3Qgd2lsbCBi ZSB0cmVhdGVkIGFzIG5vbi1PQXV0aCBwYXJhbWV0ZXJzLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+ODg+OCryI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlJlc2VhcmNo IEZlbGxvdywgTm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkU6 IG4tc2FraW11cmFAbnJpLmNvLmpwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VDogJiM0Mzs4MSg5MCk2 MDEzNjI3NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+UExFQVNFIFJF QUQ6VGhpcyBlLW1haWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVk IHJlY2lwaWVudCBvbmx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgZS1tYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5Oua4uOOCtOOCt+ODg+OCryI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBK YW51YXJ5IDMsIDIwMjAgMjozNSBBTTxicj4NCjxiPlRvOjwvYj4gVGFrYWhpa28gS2F3YXNha2kg Jmx0O3Rha2FAYXV0aGxldGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBvYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7OyBOYXQgU2FraW11cmEgJmx0O25hdC5zYWtpbXVyYUBv aWRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSldUIFNlY3Vy ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpIHZzIE9JREMgcmVxdWVzdCBvYmplY3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIHNvbHV0aW9uIFsyXSwg dGhpcyBpcyB0aGUgYmVoYXZpb3IgdGhhdOKAmXMgcmVxdWlyZWQgZm9yIE9JREMgdG9kYXksIHNv IEkgd291bGQgc2F5IHRoYXTigJlzIHRoZSBOZXcgQ2xpZW50IGJlaGF2aW5nIGxpa2UgYW4gT2xk IENsaWVudCBpbiBvcmRlciB0byB0YWxrIHRvIGFuIE9sZCBTZXJ2ZXIuIFNvIGluIHJlYWxpdHks ICgyKSBjYXVzZXMgdGhlIHJlcXVlc3QgdG8gYmUgcmVqZWN0ZWQsDQogYW5kIHRoYXTigJlzIE9L LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbuKAmXQgdGhp bmsgaXTigJlzIHZpYWJsZSB0byByZXF1aXJlIHBhcmFtZXRlcnMgdG8gZXhpc3QgaW5zaWRlIHRo ZSByZXF1ZXN0IG9iamVjdCBhdCBhbGwgdGltZXMuIE5vciBzaG91bGQgd2UgdHJ5IHRvIGVudW1l cmF0ZSB3aGljaCBwYXJhbWV0ZXJzIGdvIGluc2lkZSBhbmQgb3V0c2lkZSBhdCBhbGwgdGltZXMg 4oCUIGF0IGxlYXN0IGZyb20gdGhlIEpBUi9PQXV0aCBsZXZlbCBvZg0KIHRoaW5ncy4gSSB0aGlu ayB0aGVyZSBhcmUgdG9vIG1hbnkgdGhpbmdzIHRoYXQgYXJlIGFwcGxpY2F0aW9uIGFuZCBkZXBs b3ltZW50IHNwZWNpZmljIGZvciB1cyB0byBtYWtlIHRoaXMgY2FsbC4gVGhlIHZlcnkgbmF0dXJl IG9mIHRoZSByZXF1ZXN0IG9iamVjdCBjaGFuZ2VzIGZvciBwZW9wbGUg4oCUIHNvbWUgaGF2ZSBh IHN0YXRpYyBvYmplY3QgdGhhdOKAmXMgZGVwbG95ZWQgd2l0aCBjbGllbnRzIGFuZCBzb21lIGhh dmUgc29tZXRoaW5nIHRoYXQNCiB0aGUgY2xpZW50IGNyZWF0ZXMgYXQgcnVudGltZSBmb3IgZWFj aCByZXF1ZXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PklmIHRoZSBpbnN0ZWFkIHRoZSBOZXcgU2VydmVyIHJlcXVpcmVzIHRoYXQgYW55IHBhcmFtZXRl cnMgZHVwbGljYXRlZCBiZXR3ZWVuIHRoZSB0d28gcGxhY2VzIGhhdmUgdG8gbWF0Y2ggKHRoZSBP SURDIG1ldGhvZCkgb3IgdGhhdCBpbiBhIGNvbmZsaWN0IHRoZSByZXF1ZXN0IG9iamVjdCB2YWx1 ZXMgdGFrZSBwcmVjZWRlbmNlICh0aGUgbWVyZ2UgbWV0aG9kKSwgdGhlbiBwcm9ibGVtcw0KIDMt MSBhbmQgMy0yIGdvIGF3YXkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5XaXRoIHRoZSBtZXJnZS1hbmQtcHJlY2VkZW5jZSBiZWhhdmlvciwg d2hpY2ggaXMgd2hhdCBJIHRob3VnaHQgdGhhdCBKQVIgaGFkIGR1cmluZyBXR0xDLCBbMy0xXSBp cyB3ZWxsLWRlZmluZWQuIFRoZSByZXF1ZXN0IGlzIHByb2Nlc3NlZCB0aGUgc2FtZSB3YXkgZXZl cnkgdGltZSBiZWNhdXNlIHRoaXMgaXMgYSBOZXcgU2VydmVyLiBUaGUgY2xpZW50IGlzIGdvaW5n IHRvIGRvDQogT0lEQ+KAmXMg4oCcZHVwbGljYXRl4oCdIG1ldGhvZCwgc28g4oCcbWVyZ2Ugd2l0 aCBwcmVjZWRlbmNl4oCdIGlzIGVmZmVjdGl2ZWx5IGEgbm8tb3AuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaXRoIHRoZSBtZXJnZS1hbmQtcHJlY2Vk ZW5jZSBiZWhhdmlvciwgWzMtMl0gZG9lc27igJl0IGhhcHBlbiBiZWNhdXNlIHRoZSByZXF1aXJl ZCBwYXJhbWV0ZXJzIGFyZW7igJl0IHJlcXVpcmVkIHRvIGJlIGluIHRoZSByZXF1ZXN0IG9iamVj dCBpdHNlbGYuIEFzIGxvbmcgYXMgdGhlIHJlcXVlc3Qgb2JqZWN0IGlzIHZhbGlkLCBpdCBwcm90 ZWN0cyBhbGwgcGFyYW1ldGVycyB3aXRoaW4NCiBpdC4gSSBkb27igJl0IHRoaW5rIGl04oCZcyB1 cCB0byB1cyB0byBkZXRlcm1pbmUgd2hhdCBtYWtlcyBzZW5zZSB0byBwdXQgaW4gdGhhdCBvYmpl Y3QuIFNlY3VyaXR5IGd1aWRhbmNlIGlzIHByb2JhYmx5IGEgZ29vZCBpZGVhIGhlcmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Tb2x1dGlvbiBbM10g aXMgd2hhdCBPbGQgQ2xpZW50cyBhbHJlYWR5IGRvIGluIE9JREMgdG9kYXksIHNvIHRoYXTigJlz IHdoYXQgYWxyZWFkeSBoYXBwZW5zIGFuZCB3aHkgcHJvYmxlbSBzcGFjZSAoMykgaXNu4oCZdCBh IHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 4oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEph biAyLCAyMDIwLCBhdCAxMjoyNCBQTSwgVGFrYWhpa28gS2F3YXNha2kgJmx0OzxhIGhyZWY9Im1h aWx0bzp0YWthQGF1dGhsZXRlLmNvbSI+dGFrYUBhdXRobGV0ZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UsIEp1c3Rp bi4gQWN0dWFsbHksIEkgd2FudGVkIHRvIHNlZSBzb21lb25lIHdyaXRlIGEgc3VtbWFyeSBhYm91 dCB3aGF0IGhhcHBlbnMgaW4gZWFjaCBjb21iaW5hdGlvbiBmcm9tIGEgdmlld3BvaW50IG9mIGJv dGggUlAgYW5kIEFTIHdpdGggcmVnYXJkIHRvIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgKGFzIEkg dG9sZCB5b3UgaW4gb3RoZXIgY2hhbm5lbCBqdXN0DQogYmVmb3JlIHlvdSBwb3N0ZWQgeW91ciBl bWFpbCBeX14pLjxicj4NCjxicj4NClNvLDxicj4NCjxicj4NCjxiPigxKSBOZXcgQ2xpZW50ICYj NDM7IE5ldyBTZXJ2ZXI8L2I+PGJyPg0KTm8gcHJvYmxlbSB3aWxsIGhhcHBlbi48YnI+DQo8YnI+ DQo8Yj4oMikgTmV3IENsaWVudCAmIzQzOyBPbGQgU2VydmVyPC9iPjxicj4NCjxiPltQcm9ibGVt IDItMV08L2I+IElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBjb250YWlucyAncmVxdWVzdCcg b3IgJ3JlcXVlc3RfdXJpJyBidXQgZG9lc24ndCBoYXZlIG9sZCBtYW5kYXRvcnkgcmVxdWVzdCBw YXJhbWV0ZXJzICgnY2xpZW50X2lkJyBhbmQgJ3Jlc3BvbnNlX3R5cGUnKSBvdXRzaWRlIHRoZSBy ZXF1ZXN0IG9iamVjdCwgdGhlIHJlcXVlc3QgaXMgcmVqZWN0ZWQuPGJyPg0KPGJyPg0KPGI+W1Nv bHV0aW9uIDJdPC9iPiBOZXcgQ2xpZW50IHNob3VsZCBpbmNsdWRlIHRoZSBvbGQgbWFuZGF0b3J5 IHJlcXVlc3QgcGFyYW1ldGVycyBkdXBsaWNhdGVseSBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVj dC4gVGhpcyBtZWFucyB0aGF0IE5ldyBDbGllbnQgc2hvdWxkIGFsd2F5cyBzZW5kIG9sZCBtYW5k YXRvcnkgcmVxdWVzdCBwYXJhbWV0ZXJzIGR1cGxpY2F0ZWx5IG91dHNpZGUgdGhlIHJlcXVlc3Qg b2JqZWN0IGlmIGl0IHdhbnRzIHRvIGdldA0KIG1heGltdW0gY29tcGF0aWJpbGl0eS48YnI+DQo8 YnI+DQo8Yj4oMykgT2xkIENsaWVudCAmIzQzOyBOZXcgU2VydmVyPC9iPjxicj4NCjxiPltQcm9i bGVtIDMtMV08L2I+IElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBjb250YWlucyAncmVxdWVz dCcgb3IgJ3JlcXVlc3RfdXJpJyBhbmQgc29tZSAmcXVvdDtvcHRpb25hbCZxdW90OyByZXF1ZXN0 IHBhcmFtZXRlcnMgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBvYmplY3QsIEFTIHdp bGwgaW50ZXJwcmV0IHRoZSByZXF1ZXN0IGRpZmZlcmVudGx5LiBJbWFnaW5lIHdoYXQgaGFwcGVu cyB3aGVuIG9wdGlvbmFsIHBhcmFtZXRlcnMgc3VjaA0KIGFzICdzY29wZScsICdzdGF0ZScsICdu b25jZScsICdyZWRpcmVjdF91cmknLCAncmVzcG9uc2VfbW9kZScsICdtYXhfYWdlJywgJ2Fjcl92 YWx1ZXMnLCAnY29kZV9jaGFsbGVuZ2UnLCAnY29kZV9jaGFsbGVuZ2VfbWV0aG9kJyBhbmQgJ3By b21wdCcgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBvYmplY3QgYnV0IHByZXNlbnQg b3V0c2lkZSB0aGUgcmVxdWVzdCBvYmplY3QuPGJyPg0KPGJyPg0KPGI+W1Byb2JsZW0gMy0yXTwv Yj4gSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGNvbnRhaW5zICdyZXF1ZXN0JyBvciAncmVx dWVzdF91cmknIGFuZCBzb21lICZxdW90O21hbmRhdG9yeSZxdW90OyByZXF1ZXN0IHBhcmFtZXRl cnMgKCdjbGllbnRfaWQnIGFuZCAncmVzcG9uc2VfdHlwZScpIGFyZSBub3QgaW5jbHVkZWQgaW4g dGhlIHJlcXVlc3Qgb2JqZWN0LCB0aGUgcmVxdWVzdCBpcyByZWplY3RlZC48YnI+DQo8YnI+DQo8 Yj5bU29sdXRpb24gM108L2I+IE9sZCBDbGllbnQgc2hvdWxkIGluY2x1ZGUgYWxsIHJlcXVlc3Qg cGFyYW1ldGVycyBkdXBsaWNhdGVseSBpbiB0aGUgcmVxdWVzdCBvYmplY3QuIFRoaXMgbWVhbnMg dGhhdCBPbGQgQ2xpZW50IHNob3VsZCBhbHdheXMgaW5jbHVkZSBhbGwgcmVxdWVzdCBwYXJhbWV0 ZXJzIGR1cGxpY2F0ZWx5IGluIHRoZSByZXF1ZXN0IG9iamVjdCBpZiBpdCB3YW50cyB0byBnZXQg bWF4aW11bSBjb21wYXRpYmlsaXR5Ljxicj4NCjxicj4NCjxiPig0KSBPbGQgQ2xpZW50ICYjNDM7 IE9sZCBTZXJ2ZXI8L2I+PGJyPg0KTm8gcHJvYmxlbSB3aWxsIGhhcHBlbi48YnI+DQo8YnI+DQot IC0gLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpGcm9t IGEgQ2xpZW50J3MgcG9pbnQgb2YgdmlldywgZm9yIG1heGltdW0gY29tcGF0aWJpbGl0eSwgYm90 aCBPbGQgYW5kIE5ldyBDbGllbnRzIHNob3VsZCBwdXQgbWFuZGF0b3J5IHJlcXVlc3QgcGFyYW1l dGVycyBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBhbmQgcHV0IGFsbCByZXF1ZXN0IHBhcmFt ZXRlcnMgZHVwbGljYXRlbHkgaW5zaWRlIHRoZSByZXF1ZXN0IG9iamVjdC48YnI+DQo8YnI+DQpb UHJvYmxlbSAzLTFdIGlzIGRpZmZpY3VsdCB0byBkZXRlY3QgYmVjYXVzZSB0aGUgYXV0aG9yaXph dGlvbiByZXF1ZXN0IGlzIG5vdCByZWplY3RlZC4gQnV0LCBpZiBOZXcgU2VydmVyIHJlcXVpcmVz IHRoYXQgYWxsIHJlcXVlc3QgcGFyYW1ldGVycyBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBi ZSBwdXQgaW5zaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBkdXBsaWNhdGVseSwgW1Byb2JsZW0gMy0x XSBpcyBoYW5kbGVkIGFzIGFuIGVycm9yIGFuZA0KIHRodXMgY2xpZW50IGRldmVsb3BlcnMgY2Fu IGRldGVjdCB0aGUgcHJvYmxlbS48YnI+DQo8YnI+DQpDb25zZXF1ZW50bHksIGludHJvZHVjaW5n IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQgaW4gJnF1b3Q7RkFQSSBQYXJ0IDIsIDxhIGhyZWY9 Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtZmluYW5jaWFsLWFwaS1wYXJ0LTItSUQy Lmh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXIiPg0KNS4yLjI8L2E+LCAxMCZxdW90OyB0byBKQVIg c2VlbXMgYSBnb29kIGNvbXByb21pc2UgKGFzIEkgdG9sZCBiZWZvcmUpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmln aHQ6MG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zaGFsbCBy ZXF1aXJlIHRoYXQgYWxsIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQgaW5zaWRlIHRoZSBzaWduZWQg cmVxdWVzdCBvYmplY3QgcGFzc2VkIGluIHRoZSByZXF1ZXN0IG9yIHJlcXVlc3RfdXJpIHBhcmFt ZXRlcjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KaW5zdGVhZCBvZiBqdXN0IHNheWluZyAm cXVvdDt0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc3VwcG9ydGluZyB0aGlzIHNwZWNpZmljYXRp b24gTVVTVCBvbmx5IHVzZSB0aGUgcGFyYW1ldGVycyBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBv YmplY3QuJnF1b3Q7IHdoaWNoIHdpbGwgYnJpbmcgYWJvdXQgW1Byb2JsZW0gMy0xXS4gVGhhdCBp cywgaG93IGFib3V0IGFkZGluZyBhIHJ1bGUgbGlrZSAmcXVvdDtpZiByZXF1ZXN0IHBhcmFtZXRl cnMgZXhpc3Qgb3V0c2lkZSB0aGUNCiByZXF1ZXN0IG9iamVjdCwgdGhleSBtdXN0IGV4aXN0IGlu c2lkZSB0aGUgcmVxdWVzdCBvYmplY3QsIHRvby4mcXVvdDs/PGJyPg0KPGJyPg0KQW55IHRob3Vn aHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRha2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZyaSwg SmFuIDMsIDIwMjAgYXQgMTI6NDggQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHRoZSBuYXR1cmUgb2YgdGhlIGJhY2t3 YXJkcyBpbmNvbXBhdGliaWxpdHkgaXMgaW1wb3J0YW50IGhlcmUuIFRoZSB3YXkgdGhhdCB0aGlu Z3MgYXJlIG5vdywgdXNpbmcgbWVyZ2Utd2l0aC1wcmVjZWRlbmNlLCB5b3UgaGF2ZSB0aGUgZm9s bG93aW5nIG1hdHJpeCBvZiBjb21wYXRpYmlsaXR5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldyBTZXJ2ZXIgJm5ic3A7fCAmbmJzcDtPbGQgU2VydmVy ICZuYnNwO3w8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5OZXcgQ2xpZW50IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDtZRVMgJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDtOTyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9sZCBDbGllbnQgfCAmbmJzcDsgJm5i c3A7ICZuYnNwO1lFUyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IFlFUyAmbmJzcDsgJm5i c3A7ICZuYnNwO3w8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PklmIHlvdSBhc2sgbWUsIHRoaXMgaXMgdGhlIHJpZ2h0IGJhbGFuY2UgZm9yIGEgYnJlYWtpbmcg Y2hhbmdlLiBPbGQgY2xpZW50cywgd2hlcmUgdGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIGNvZGUg aXMsIGRvbuKAmXQgaGF2ZSB0byBjaGFuZ2UuIE5ldyBjbGllbnRzIGNhbiBvbmx5IHRhbGsgdG8g c2VydmVycyB3aXRoIHRoZSBuZXcgZmVhdHVyZXMsIHdoaWNoIGlzIHRoZSBhYmlsaXR5DQogdG8g ZHJvcCBwYXJhbWV0ZXJzIGZyb20gdGhlIGV4dGVybmFsIHJlcXVlc3QuIFRoaXMgd291bGQgYXBw bHkgdG8gYm90aCBPSURDIGFuZCBwbGFpbiBPQXV0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgd2Ugc2hvdWxkIGZvbGxvdyB0aGlzIGtp bmQgb2YgcGF0dGVybiBpbiB0aGUgZGlzY3Vzc2lvbnMgb24gT0F1dGggMi4xLCB3aGljaCBJIHRo aW5rIEpBUiBzaG91bGQgYmUgYSBwYXJ0IG9mLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gSmFuIDIsIDIwMjAsIGF0IDM6NDAgQU0sIFRha2FoaWtv IEthd2FzYWtpICZsdDs8YSBocmVmPSJtYWlsdG86dGFrYUBhdXRobGV0ZS5jb20iIHRhcmdldD0i X2JsYW5rIj50YWthQGF1dGhsZXRlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJyZWFraW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg aW4gdGhpcyBwYXJ0IHdvdWxkIG1lYW4gdGhhdCBPcGVuSUQgQ2VydGlmaWNhdGlvbiBnaXZlbiB0 byBBUyBpbXBsZW1lbnRhdGlvbnMgd2l0aCByZXF1ZXN0X3VyaSBzdXBwb3J0IHdpbGwgYmUgaW52 YWxpZGF0ZWQgb25jZSB0aGV5IHN1cHBvcnQgSkFSLiBJdCBhbHNvIHdvdWxkIG1lYW4gdGhhdCB0 ZXN0IGNhc2VzIGluIHRoZQ0KIG9mZmljaWFsIGNvbmZvcm1hbmNlIHN1aXRlIG5lZWQgdG8gYmUg Y2hhbmdlZCBpbiBhIGJhY2t3YXJkLWluY29tcGF0aWJsZSBtYW5uZXIsIHdoaWNoIHdvdWxkIGlt cGxpY2l0bHkgZW5jb3VyYWdlIHRoYXQgYWxsIGNlcnRpZmllZCBpbXBsZW1lbnRhdGlvbnMgc2hv dWxkIHJlLXRyeSB0byBnZXQgY2VydGlmaWNhdGlvbi48YnI+DQo8YnI+DQpDaGFuZ2luZyB0aGUg c3BlYyBub3cgbWlnaHQgbmVlZCBtb3JlIHRocmVlIHRvIHNpeCBtb250aHMsIGJ1dCBpdCB3b3Vs ZCBiZSB3b3J0aCBjb25zaWRlcmluZyB3aGF0IHdlIGdldCBhbmQgbG9zZSBieSBzYXZpbmcgdGhl IG1vbnRocyBhbmQgYnJlYWtpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eS48YnI+DQo8YnI+DQpC ZXN0IFJlZ2FyZHMsPGJyPg0KVGFrYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPk9uIFdlZCwgRGVjIDE4LCAyMDE5IGF0IDQ6MTQgUE0gTmF0IFNha2ltdXJhICZsdDs8 YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11 cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowbW0iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Tbywgbm8gY2hhbmdlIGlzIE9LPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgRGVjIDExLCAyMDE5IGF0IDEwOjAxIFBNIEpvaG4gQnJh ZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgYWxzbyBzbGlnaHRseSBwcmVmZXIgdGhlIG1lcmdlIGFwcHJvYWNoLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSBw bHVzc2VzIGFuZCBtaW51c2VzIHRvIGJvdGguJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGFuZ2luZyBhZ2FpbiBub3cgdGhhdCBpdCBpcyBw YXN0IElTRUcgcmV2aWV3IGFuZCBiYWNraW5nIG91dCBhIERpc2N1c3Mgd2lsbCBhZGQgYW5vdGhl ciB0aHJlZSB0byBzaXggbW9udGhzIGF0IHRoaXMgcG9pbnQsIGlmIHdlIGNhbiBnZXQgdGhlbSB0 byBhZ3JlZSB0byB0aGUgY2hhbmdlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Sm9obiBCLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBEZWMgMTAsIDIwMTksIDExOjI5IFBN IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1tIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db3JyZWN0LiBUaGUgV0cgc3Vw cG9ydGVkIHRoZSBwcmVjZWRlbmNlIGFwcHJvYWNoIGFuZCBldmVuIG1lcmdlIGp1c3QgbGlrZSBP SURDIGFzIGl0IGlzIHZlcnkgdXNlZnVsIGZyb20gdGhlIGltcGxlbWVudGF0aW9uIHBvaW50IG9m IHZpZXcgYW5kIGhlbHBzIHdpdGggYSBidW5jaCBvZiBkZXBsb3ltZW50IHBhdHRlci4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIHB1c2ggYmFjayBjYW1lIGluIGZyb20gdGhlIEJlbiBDYW1wYmVsbOKAmXMgRElTQ1VTUy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VlJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVm PSJodHRwczovL2JpdGJ1Y2tldC5vcmcvTmF0L29hdXRoLWp3c3JlcS9pc3N1ZXMvNzAvYmMtdGhl LWN1cnJlbnQtdGV4dC1hY3R1YWxseS1zcGVjaWZpZXMtdGhlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9iaXRidWNrZXQub3JnL05hdC9vYXV0aC1qd3NyZXEvaXNzdWVzLzcwL2JjLXRoZS1jdXJy ZW50LXRleHQtYWN0dWFsbHktc3BlY2lmaWVzLXRoZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gd2lsbGluZyB0byBnbyBlaXRoZXIgd2F5 IGFzIGxvbmcgYXMgcGVvcGxlIGFncmVlLiBNeSBzbGlnaHQgcHJlZmVyZW5jZSBpcyB0byB0aGUg b3JpZ2luYWwgYXBwcm9hY2guJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+TmF0IFNha2ltdXJhPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+MjAxOTwvc3Bhbj7lubQ8c3BhbiBsYW5n PSJFTi1VUyI+ODwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+Mjk8L3NwYW4+5pelPHNwYW4g bGFuZz0iRU4tVVMiPig8L3NwYW4+5pyoPHNwYW4gbGFuZz0iRU4tVVMiPikgNjo1NiBCcmlhbiBD YW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS4uY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAw bW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GV0lXLCBhcyBiZXN0IEkg Y2FuIHJlbWVtYmVyIHRoZSBjaGFuZ2UgaW4gcXVlc3Rpb24gY2FtZSBhcyBJIHJlc3VsdCBvZiBk aXJlY3RvcmF0ZS9JRVNHIHJldmlldyByYXRoZXIgdGhhbiBhIFdHIGRlY2lzaW9uL2Rpc2N1c3Np b24uIFdoaWNoIGlzIGxpa2VseSB3aHkgeW91IGNhbid0IGZpbmQgdGhlICZxdW90O3doeSZxdW90 OyBhbnl3aGVyZSBpbiB0aGUgbWFpbGluZyBsaXN0IGFyY2hpdmUuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEF1ZyAyOCwgMjAxOSBhdCAzOjIzIFBN IEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1t IDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1tIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlbGwgaXQga2lu ZCBvZiBibG93cywgZG9lc24ndCBpdD8gSSB3YXNuJ3QgYWJsZSB0byBmaW5kIHRoZSAmcXVvdDt3 aHkmcXVvdDsgYW55d2hlcmUgaW4gdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlIGFyb3VuZCB0aGUg dGltZSB0aGlzIHdhcyBjaGFuZ2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+TXkgdGFrZSBvbiBzYXRpc2Z5aW5nIGJvdGggd29ybGRzIGxvb2tzIGxp a2UgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ LSBhbGxvdyBqdXN0IEpBUiAtIG5vIG90aGVyIHBhcmFtcyB3aGVuIHBvc3NpYmxlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICh3aGljaCBidHcgaXNuJ3QgcG9zc2libGUgdG8g ZG8gd2l0aCByZXF1ZXN0X3VyaSB3aGVuIGVuZm9yY2luZyBjbGllbnQgYmFzZWQgdXJpIHdoaXRl bGlzdCBhbmQgdGhlIGp3c3JlcSA1LjIuMiBzaG93cyBhcyBtdWNoKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4tIGVuZm9yY2UgdGhlICZxdW90O2R1cGUgYmVoYXZpb3VycyZxdW90OyBkZWZpbmVkIGlu IE9JREMgKGlmIHJlc3BvbnNlX3R5cGUgb3IgY2xpZW50X2lkIGlzIGluIHJlcXVlc3Qgb2JqZWN0 IGl0IG11c3QgZWl0aGVyIGJlIG1pc3Npbmcgb3IgdGhlIHNhbWUgaW4gcmVndWxhciByZXF1ZXN0 KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBhbGxvd3MgbWVyZ2luZyByZXF1ZXN0IG9iamVjdCBh bmQgcmVndWxhciBwYXJhbWV0ZXJzIHdpdGggcmVxdWVzdCBvYmplY3QgdGFraW5nJm5ic3A7cHJl Y2VkZW5jZSBzaW5jZSBpdCBpcyBhIHZlcnkgdXNlZnVsIGZlYXR1cmUgd2hlbiBoYXZpbmcgcHJl LXNpZ25lZCByZXF1ZXN0IG9iamVjdCB0aGF0J3Mgbm90IG9uZSB0aW1lIHVzZSBhbmQgY2xpZW50 cyB1c2luZyBpdCB3aXNoIHRvDQogdmFyeSBzdGF0ZS9ub25jZSBwZXItcmVxdWVzdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd2lzaCB0aGUgZ3Jv dXAgcmVjb25zaWRlcmVkIG1ha2luZyB0aGlzIGJyZWFraW5nIGNoYW5nZSBmcm9tIE9JREMncyB0 YWtlIG9uIHJlcXVlc3Qgb2JqZWN0cyAtIGFsbG93IGNvbWJpbmF0aW9uIG9mIHBhcmFtZXRlcnMg ZnJvbSB0aGUgcmVxdWVzdCBvYmplY3Qgd2l0aCBvbmVzIGZyb20gcmVndWxhciBwYXJhbWV0ZXJz IChpZiBub3QgcHJlc2VudCBpbiByZXF1ZXN0IG9iamVjdCkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UyBwb3pkcmF2ZW0sPGJyPg0KPGI+Rmls aXAgU2tva2FuPC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MG1tIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9uIFdlZCwgMjggQXVnIDIwMTkgYXQgMjM6MDIsIEJyaWFuIENhbXBiZWxs ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0i X2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowbW0iPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZpbGlwLCBmb3IgYmV0dGVyIG9yIHdvcnNlLCBJ IGJlbGlldmUgeW91ciBhc3Nlc3NtZW50IG9mIHRoZSBzaXR1YXRpb24gaXMgY29ycmVjdC4gSSBr bm93IG9mIG9uZSBBUyB0aGF0IGRpZG4ndCBjaG9vc2Ugd2hpY2ggb2YgdGhlIHR3byB0byBmb2xs b3cgYnV0IHJhdGhlciBpbXBsZW1lbnRlZCBhIGJpdCBvZiBhIGh5YnJpZCB3aGVyZSBpdCBiYXNp Y2FsbHkgaWdub3JlcyBldmVyeXRoaW5nDQogb3V0c2lkZSBvZiB0aGUgcmVxdWVzdCBvYmplY3Qg cGVyIEpBUiBidXQgYWxzbyBjaGVja3MgZm9yIGFuZCBlbmZvcmNlcyB0aGUgcHJlc2VuY2UgYW5k IHZhbHVlIG9mIHRoZSBmZXcgcmVndWxhciBwYXJhbWV0ZXJzIChjbGllbnRfaWQsIHJlc3BvbnNl X3R5cGUpIHRoYXQgT0lEQyBtYW5kYXRlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9uIFR1ZSwgQXVnIDI3LCAyMDE5IGF0IDU6NDcgQU0gRmlsaXAgU2tva2Fu ICZsdDs8YSBocmVmPSJtYWlsdG86cGFudmEuaXBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cGFudmEuaXBAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkhlbGxvIGV2ZXJ5b25lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+aW4gYW4gZWFybGllciB0aHJlYWQgSSd2ZSBwb3NlZCB0aGUgZm9sbG93 aW5nIHF1ZXN0aW9uIHRoYXQgbWlnaHQgaGF2ZSBnb3R0ZW4gbWlzc2VkLCB0aGlzIG1pZ2h0IGhh dmUgY29uc2VxdWVuY2VzIGZvciB0aGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIFJlcXVl c3QgT2JqZWN0cyBpbiBPSURDIGltcGxlbWVudGF0aW9ucyAtIGl0cyBtYWtpbmcgcHVyZSBKQVIg cmVxdWVzdHMNCiBpbmNvbXBhdGlibGUgd2l0aCBPSURDIENvcmUgaW1wbGVtZW50YXRpb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZHJhZnQgMTQg b2YgandzcmVxIChKQVIpIGludHJvZHVjZWQgdGhpcyBsYW5ndWFnZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojNTAwMDUwIj5UaGUgY2xpZW50IE1BWSBzZW5kIHRoZSBwYXJhbWV0 ZXJzIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IG9iamVjdDxicj4NCmR1cGxpY2F0ZWQgaW4gdGhl IHF1ZXJ5IHBhcmFtZXRlcnMgYXMgd2VsbCBmb3IgdGhlIGJhY2t3YXJkPGJyPg0KY29tcGF0aWJp bGl0eSBldGMuICZuYnNwOzxiPkhvd2V2ZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzdXBw b3J0aW5nIHRoaXM8YnI+DQpzcGVjaWZpY2F0aW9uIE1VU1Qgb25seSB1c2UgdGhlIHBhcmFtZXRl cnMgaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3Q8YnI+DQpvYmplY3QuJm5ic3A7PC9iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5TZXJ2ZXIgTVVTVCBvbmx5IHVzZSB0aGUgcGFyYW1ldGVycyBp biB0aGUgUmVxdWVzdCBPYmplY3QgZXZlbiBpZiB0aGU8YnI+DQpzYW1lIHBhcmFtZXRlciBpcyBw cm92aWRlZCBpbiB0aGUgcXVlcnkgcGFyYW1ldGVyLiZuYnNwOyBUaGUgQXV0aG9yaXphdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1tIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+VGhlIGNsaWVu dCBNQVkgc2VuZCB0aGUgcGFyYW1ldGVycyBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBvYmplY3Q8 YnI+DQpkdXBsaWNhdGVkIGluIHRoZSBxdWVyeSBwYXJhbWV0ZXJzIGFzIHdlbGwgZm9yIHRoZSBi YWNrd2FyZDxicj4NCmNvbXBhdGliaWxpdHkgZXRjLiAmbmJzcDs8Yj5Ib3dldmVyLCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgc3VwcG9ydGluZyB0aGlzPGJyPg0Kc3BlY2lmaWNhdGlvbiBNVVNU IG9ubHkgdXNlIHRoZSBwYXJhbWV0ZXJzIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0PGJyPg0Kb2Jq ZWN0Li4mbmJzcDs8L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzUwMDA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCwgSm9obiwgZXZlcnlvbmUg LSZuYnNwOzxiPmRvZXMgdGhpcyBtZWFuIGEgSkFSIGNvbXBsaWFudCBBUyBpZ25vcmVzIGV2ZXJ5 dGhpbmcgb3V0c2lkZSBvZiB0aGUgcmVxdWVzdCBvYmplY3Qgd2hpbGUgT0lEQyBSZXF1ZXN0IE9i amVjdCBvbmUgbWVyZ2VzIHRoZSB0d28gd2l0aCB0aGUgb25lcyBpbiB0aGUgcmVxdWVzdCBvYmpl Y3QgYmVpbmcgdXNlZCBvdmVyIG9uZXMgdGhhdCBhcmUNCiBzZW50IGluIGNsZWFyPzwvYj4mbmJz cDtUaGUgT0lEQyBsYW5ndWFnZSBhbHNvIGluY2x1ZGVzIHNlY3Rpb25zIHdoaWNoIG1ha2Ugc3Vy ZSB0aGF0IHNvbWUgcmVxdWlyZWQgYXJndW1lbnRzIGFyZSBzdGlsbCBwYXNzZWQgb3V0c2lkZSBv ZiB0aGUgcmVxdWVzdCBvYmplY3Qgd2l0aCB0aGUgc2FtZSB2YWx1ZSB0byBtYWtlIHN1cmUgdGhl IHJlcXVlc3QgaXMgJnF1b3Q7dmFsaWQmcXVvdDsgT0F1dGggMi4wIHJlcXVlc3QgKGNsaWVudF9p ZCwgcmVzcG9uc2VfdHlwZSksIHNvbWV0aGluZw0KIHdoaWNoIGFuIGV4YW1wbGUgaW4gdGhlIEpB UiBzcGVjIGRvZXMgbm90IGRvLiBOb3QgaGF2aW5nIHRoaXMgbGFuZ3VhZ2UgbWVhbnMgdGhhdCBl eGlzdGluZyBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGlwZWxpbmVzIGNhbid0IHNpbXBseSBiZSBl eHRlbmRlZCB3aXRoIGUuZy4gYSBtaWRkbGV3YXJlLCB0aGV5IG5lZWQgdG8gYnJhbmNoIHRoZWly IGNvZGVwYXRocy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPklzIGFuIEFTIHJlcXVpcmVkIHRvIGNob29zZSB3aGljaCBvZiB0aGUgdHdvIGl0IGZvbGxv d3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu ayB5b3UgZm9yIGNsYXJpZnlpbmcgdGhpcyBpbiBhZHZhbmNlLiBJIHRoaW5rIGlmIGVpdGhlciB0 aGUgYmVoYXZpb3VyIGlzIHRoZSBzYW1lIGFzIGluIE9JREMgb3IgZGlmZmVyZW50IHRoaXMgc2hv dWxkIGJlIGNhbGxlZCBvdXQgaW4gdGhlIGxhbmd1YWdlIHRvIGF2b2lkIGNvbmZ1c2lvbiwgZXNw ZWNpYWxseSBzaW5jZSB0aGlzIGFscmVhZHkgZXhpc3RzIGluIE9JREMNCiBhbmQgbGlrZWx5IGlz bid0IGdvaW5nIHRvIGJlIHJlYWQgaW4gaXNvbGF0aW9uLCBlc3BlY2lhbGx5IGJlY2F1c2UgdGhl IFJlcXVlc3QgT2JqZWN0IGlzIGV2ZW4gY2FsbGVkIG91dCB0byBiZSBhbHJlYWR5IGluIHBsYWNl IGluIE9JREMgaW4gdGhlIEpBUiBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5GaWxpcDwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1tIj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow bW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MG1tIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUNCiB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4uLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBv ciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2Fn ZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMNCiBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PGI+PGk+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MG1tIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZA0KIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuDQogVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCBTYWtpbXVyYSAoPW5h dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OYXQgU2FraW11cmEgKD1u YXQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVm PSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNh a2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_OSAPR01MB4948142CA3D6677B5D34E4CEF93C0OSAPR01MB4948jpnp_-- From nobody Mon Jan 6 01:43: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 58516120115 for ; Mon, 6 Jan 2020 01:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-IFJ8yee_G9 for ; Mon, 6 Jan 2020 01:43:32 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D197B120114 for ; Mon, 6 Jan 2020 01:43:31 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id l7so13943072ybp.1 for ; Mon, 06 Jan 2020 01:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+LCX5OGn6L4K9QckvKdTWBvmRjpEhaw4JbnVgRlCN48=; b=Ax0Bno6Y2+0jEhhg8mMOG8IE7F7fwqPqelRwJcXXs2vnn5ow64cK5xKRNa26pj5Znv sZM58m02pMF+Ep6NGgcfDHybOOSWmrx5hOej8/VUo+dpQmJdCmD9G+0B2ts0i5o352dD UehrRRXp5ETApWmfAmvhIk7rm11EyO1JjT509XY0BWtTtKaKJLQRZNyRDFm0CD+OJPAS fMVb8gb/zX3g046xppQm4CRJnTWg8/0sNgPrEqtlfvlk+OpWYRPYv7TSqunvRBVIlEeq gCoHJl56B9X9oUUSbbvzf+yJOVp5gvVtdCKUu2CzPuhA0oSfShMxu4BQu+CAHVUJ5CsZ UeMA== 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=+LCX5OGn6L4K9QckvKdTWBvmRjpEhaw4JbnVgRlCN48=; b=tG58DyyooWJko1yGaaN0ICeE95Ij/St22FTL4ZPKq6HOYVQR+G+5AGX6KH/WtAQiQ/ gNMp4IIzcsABEHJU5lx5Cf2vuKBn4qOBEg9k+E7NzsNU82xrJUYRtlwx5wTtdhAa08wO WypmGTZ8RgxDMreLMsqrKXwD4IHX6ewI7S3l2Nmysjzjw+2h2hx+a82FiBOQIgbICpGS OR2khxflI2IP5saVwsaoqdJFYJwTTsCWZrMaQ9qRPiqS0Miq5IjTgD74bO81OvsIMWxi ILq22p00xvXmRescuY8PhjYT53JYNmcdcJSr0a2iOENmfsH20CdqsxTVEJjJnDCBjlK1 40NA== X-Gm-Message-State: APjAAAUm4um8H6x4iSE4cYEJMI0CKvisxo/OMpKuu38QpdB8MUtzWAZP m75IMsIzHL4H713hjYBpf14yEG/3Dr/dzpOsnA== X-Google-Smtp-Source: APXvYqxrfSkMJE+4zFRNWf8P1ahXHrt8j0JJ6NgI5wFFmJSieXxuAunlNCCOhvkxXWtp+RZAsfIAjOeeRRvwbh3VvVg= X-Received: by 2002:a25:da16:: with SMTP id n22mr63117581ybf.399.1578303810763; Mon, 06 Jan 2020 01:43:30 -0800 (PST) MIME-Version: 1.0 References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> In-Reply-To: From: Filip Skokan Date: Mon, 6 Jan 2020 10:43:19 +0100 Message-ID: To: n-sakimura Cc: Justin Richer , Takahiko Kawasaki , Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="000000000000fcfea8059b757d25" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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: Mon, 06 Jan 2020 09:43:37 -0000 --000000000000fcfea8059b757d25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think we have the separation of OAuth and non-OAuth parameters and let's please not. Even OIDC parameters are part of the OAuth parameters registry and I cannot imagine the hardship if we were to explain that to developers. With passing time I believe it should be up to the profile or application of JAR to define how to treat *recognized* parameters outside of the request object. In my personal OSS project the AS can be configured to be *strict* (jar), *lax* (oidc merge all) or *whitelist* (merge only whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir is describing. S pozdravem, *Filip Skokan* On Mon, 6 Jan 2020 at 07:05, n-sakimura wrote: > Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if > duplicated. > > As of -13 (Mar 30, 2017), it was changed that the server does not have to > do the merge, at least for OAuth Authorization request parameters. It say= s > nothing about other parameters. > > As of -14 (Jul 21, 2017), the wording was further strengthened by adding > > > > The Authorization Server MUST only use the parameters in the Request > Object even if the same parameter is provided in the query parameter. > > > > So, the entire 6.3 now became > 6.3 . > Request Parameter Assembly and Validation > > The Authorization Server MUST extract the set of Authorization > > Request parameters from the Request Object value. The Authorization > > Server MUST only use the parameters in the Request Object even if the > > same parameter is provided in the query parameter. The Authorization > > Server then validates the request as specified in OAuth 2.0 > > [RFC6749 ]. > > > > It says nothing on the non-OAuth parameters that came with the > authorization request. > > My take on the text is that all OAuth Authorization Request parameters > MUST be in the request object. > > Behaviors towards other parameters that happens to have come together wit= h > the authorization request outside of request object will be treated as > non-OAuth parameters. > > > > Nat Sakimura > > Research Fellow, Nomura Research Institute > > E: n-sakimura@nri.co.jp > > T: +81(90)60136276 > > --------------------------------------------------------- > > PLEASE READ:This e-mail is confidential and intended for the named > recipient only. > > If you are not an intended recipient, please notify the sender and delete > this e-mail. > > > > *From:* OAuth *On Behalf Of *Justin Richer > *Sent:* Friday, January 3, 2020 2:35 AM > *To:* Takahiko Kawasaki > *Cc:* Brian Campbell ; oau= th > ; Nat Sakimura > *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC > request object > > > > For solution [2], this is the behavior that=E2=80=99s required for OIDC t= oday, so > I would say that=E2=80=99s the New Client behaving like an Old Client in = order to > talk to an Old Server. So in reality, (2) causes the request to be > rejected, and that=E2=80=99s OK. > > > > I don=E2=80=99t think it=E2=80=99s viable to require parameters to exist = inside the > request object at all times. Nor should we try to enumerate which > parameters go inside and outside at all times =E2=80=94 at least from the= JAR/OAuth > level of things. I think there are too many things that are application a= nd > deployment specific for us to make this call. The very nature of the > request object changes for people =E2=80=94 some have a static object tha= t=E2=80=99s > deployed with clients and some have something that the client creates at > runtime for each request. > > > > If the instead the New Server requires that any parameters duplicated > between the two places have to match (the OIDC method) or that in a > conflict the request object values take precedence (the merge method), th= en > problems 3-1 and 3-2 go away. > > > > With the merge-and-precedence behavior, which is what I thought that JAR > had during WGLC, [3-1] is well-defined. The request is processed the same > way every time because this is a New Server. The client is going to do > OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge with= precedence=E2=80=9D is effectively a > no-op. > > > > With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen beca= use the > required parameters aren=E2=80=99t required to be in the request object i= tself. As > long as the request object is valid, it protects all parameters within it= . > I don=E2=80=99t think it=E2=80=99s up to us to determine what makes sense= to put in that > object. Security guidance is probably a good idea here. > > > > Solution [3] is what Old Clients already do in OIDC today, so that=E2=80= =99s what > already happens and why problem space (3) isn=E2=80=99t a problem. > > > > =E2=80=94 Justin > > > > On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki wrote: > > > > Thank you, Justin. Actually, I wanted to see someone write a summary abou= t > what happens in each combination from a viewpoint of both RP and AS with > regard to backward compatibility (as I told you in other channel just > before you posted your email ^_^). > > So, > > *(1) New Client + New Server* > No problem will happen. > > *(2) New Client + Old Server* > *[Problem 2-1]* If an authorization request contains 'request' or > 'request_uri' but doesn't have old mandatory request parameters > ('client_id' and 'response_type') outside the request object, the request > is rejected. > > *[Solution 2]* New Client should include the old mandatory request > parameters duplicately outside the request object. This means that New > Client should always send old mandatory request parameters duplicately > outside the request object if it wants to get maximum compatibility. > > *(3) Old Client + New Server* > *[Problem 3-1]* If an authorization request contains 'request' or > 'request_uri' and some "optional" request parameters are not included in > the request object, AS will interpret the request differently. Imagine wh= at > happens when optional parameters such as 'scope', 'state', 'nonce', > 'redirect_uri', 'response_mode', 'max_age', 'acr_values', 'code_challenge= ', > 'code_challenge_method' and 'prompt' are not included in the request obje= ct > but present outside the request object. > > *[Problem 3-2]* If an authorization request contains 'request' or > 'request_uri' and some "mandatory" request parameters ('client_id' and > 'response_type') are not included in the request object, the request is > rejected. > > *[Solution 3]* Old Client should include all request parameters > duplicately in the request object. This means that Old Client should alwa= ys > include all request parameters duplicately in the request object if it > wants to get maximum compatibility. > > *(4) Old Client + Old Server* > No problem will happen. > > - - - > > > From a Client's point of view, for maximum compatibility, both Old and Ne= w > Clients should put mandatory request parameters outside the request objec= t > and put all request parameters duplicately inside the request object. > > [Problem 3-1] is difficult to detect because the authorization request is > not rejected. But, if New Server requires that all request parameters > outside the request object be put inside the request object duplicately, > [Problem 3-1] is handled as an error and thus client developers can detec= t > the problem. > > Consequently, introducing the following requirement in "FAPI Part 2, 5.2.= 2 > , > 10" to JAR seems a good compromise (as I told before) > > shall require that all parameters are present inside the signed request > object passed in the request or request_uri parameter; > > > instead of just saying "the authorization server supporting this > specification MUST only use the parameters included in the request object= ." > which will bring about [Problem 3-1]. That is, how about adding a rule li= ke > "if request parameters exist outside the request object, they must exist > inside the request object, too."? > > Any thoughts? > > > > Best, > > Taka > > > > > > On Fri, Jan 3, 2020 at 12:48 AM Justin Richer wrote: > > I think the nature of the backwards incompatibility is important here. Th= e > way that things are now, using merge-with-precedence, you have the > following matrix of compatibility: > > > > > > New Server | Old Server | > > -----------+-------------+--------------+ > > New Client | YES | NO | > > Old Client | YES | YES | > > > > > > If you ask me, this is the right balance for a breaking change. Old > clients, where the vast majority of the code is, don=E2=80=99t have to ch= ange. New > clients can only talk to servers with the new features, which is the > ability to drop parameters from the external request. This would apply to > both OIDC and plain OAuth. > > > > I think we should follow this kind of pattern in the discussions on OAuth > 2.1, which I think JAR should be a part of/ > > > > =E2=80=94 Justin > > > > > > > > On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki wrote: > > > > Breaking backward compatibility in this part would mean that OpenID > Certification given to AS implementations with request_uri support will b= e > invalidated once they support JAR. It also would mean that test cases in > the official conformance suite need to be changed in a > backward-incompatible manner, which would implicitly encourage that all > certified implementations should re-try to get certification. > > Changing the spec now might need more three to six months, but it would b= e > worth considering what we get and lose by saving the months and breaking > backward compatibility. > > Best Regards, > Taka > > > > On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura wrote: > > So, no change is OK? > > > > On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: > > I also slightly prefer the merge approach. > > > > There are plusses and minuses to both. > > > > Changing again now that it is past ISEG review and backing out a Discuss > will add another three to six months at this point, if we can get them to > agree to the change. > > > > John B. > > > > On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: > > Correct. The WG supported the precedence approach and even merge just lik= e > OIDC as it is very useful from the implementation point of view and helps > with a bunch of deployment patter. > > > > The push back came in from the Ben Campbell=E2=80=99s DISCUSS. > > See > > > https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actu= ally-specifies-the > > > > I am willing to go either way as long as people agree. My slight > preference is to the original approach. > > > > Best, > > > > Nat Sakimura > > > > 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org>>: > > FWIW, as best I can remember the change in question came as I result of > directorate/IESG review rather than a WG decision/discussion. Which is > likely why you can't find the "why" anywhere in the mailing list archive. > > > > On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: > > Well it kind of blows, doesn't it? I wasn't able to find the "why" > anywhere in the mailing list archive around the time this was changed. > > > > My take on satisfying both worlds looks like this > > > > - allow just JAR - no other params when possible. > > (which btw isn't possible to do with request_uri when enforcing clien= t > based uri whitelist and the jwsreq 5.2.2 shows as much) > > - enforce the "dupe behaviours" defined in OIDC (if response_type or > client_id is in request object it must either be missing or the same in > regular request). > > - allows merging request object and regular parameters with request objec= t > taking precedence since it is a very useful feature when having pre-signe= d > request object that's not one time use and clients using it wish to vary > state/nonce per-request. > > > > I wish the group reconsidered making this breaking change from OIDC's tak= e > on request objects - allow combination of parameters from the request > object with ones from regular parameters (if not present in request objec= t). > > > S pozdravem, > *Filip Skokan* > > > > > > On Wed, 28 Aug 2019 at 23:02, Brian Campbell > wrote: > > Filip, for better or worse, I believe your assessment of the situation is > correct. I know of one AS that didn't choose which of the two to follow b= ut > rather implemented a bit of a hybrid where it basically ignores everythin= g > outside of the request object per JAR but also checks for and enforces th= e > presence and value of the few regular parameters (client_id, response_typ= e) > that OIDC mandates. > > > > On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote: > > Hello everyone, > > > > in an earlier thread I've posed the following question that might have > gotten missed, this might have consequences for the existing > implementations of Request Objects in OIDC implementations - its making > pure JAR requests incompatible with OIDC Core implementations. > > > > draft 14 of jwsreq (JAR) introduced this language > > > > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. > > *However, the authorization server supporting this specification MUST onl= y > use the parameters included in the request object. * > > > > Server MUST only use the parameters in the Request Object even if the > same parameter is provided in the query parameter. The Authorization > > > > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. > > *However, the authorization server supporting this specification MUST onl= y > use the parameters included in the request object.. * > > > > Nat, John, everyone - *does this mean a JAR compliant AS ignores > everything outside of the request object while OIDC Request Object one > merges the two with the ones in the request object being used over ones > that are sent in clear?* The OIDC language also includes sections which > make sure that some required arguments are still passed outside of the > request object with the same value to make sure the request is "valid" > OAuth 2.0 request (client_id, response_type), something which an example = in > the JAR spec does not do. Not having this language means that existing > authorization request pipelines can't simply be extended with e.g. a > middleware, they need to branch their codepaths. > > > > Is an AS required to choose which of the two it follows? > > > > Thank you for clarifying this in advance. I think if either the behaviour > is the same as in OIDC or different this should be called out in the > language to avoid confusion, especially since this already exists in OIDC > and likely isn't going to be read in isolation, especially because the > Request Object is even called out to be already in place in OIDC in the J= AR > draft. > > > > Best, > > *Filip* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s)... Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000fcfea8059b757d25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we have the separation of OAuth and= non-OAuth parameters and let's please not. Even OIDC parameters are pa= rt of the OAuth parameters registry=C2=A0and I can= not imagine the hardship if we were to explain that to developers.

With passing time I believe it should be up to the profile= or application of JAR to define how to treat recognized parameters = outside of the request object. In my personal OSS project the AS can be con= figured to be strict (jar), lax (oidc merge all) or whitel= ist (merge only whitelisted - code_challenge, nonce, state, ...) simila= r to what Vladimir is describing.

S pozdrave= m,
Filip Skokan


On Mon, 6 Jan 2020 at 07:05, n-sak= imura <n-sakimura@nri.co.jp&= gt; wrote:

Up until -12 (Feb 13, 2= 017), it was using merge + JAR precedence if duplicated.

As of -13 (Mar 30, 2017= ), it was changed that the server does not have to do the merge, at least f= or OAuth Authorization request parameters. It says nothing about other para= meters.

As of -14 (Jul 21, 2017= ), the wording was further strengthened by adding

=C2=A0

The Authorization Server MU= ST only use the parameters in the Request Object even if the same parameter= is provided in the query parameter.

=C2=A0

So, the entire 6.3 now = became

6.3.=C2=A0 Request Parameter Assembly and Validation

=C2=A0=C2=A0 The Authorization Server MUST extrac=
t the set of Authorization
=C2=A0=C2=A0 Request parameters from the Request =
Object value.=C2=A0 The Authorization
=C2=A0=C2=A0 Server MUST only use the parameters =
in the Request Object even if the
=C2=A0=C2=A0 same parameter is provided in the qu=
ery parameter.=C2=A0 The Authorization
=C2=A0=C2=A0 Server then validates the request as=
 specified in OAuth 2.0
=C2=A0=C2=A0 [RFC6749].

=C2=A0

It says nothing on the = non-OAuth parameters that came with the authorization request.

My take on the text is = that all OAuth Authorization Request parameters MUST be in the request obje= ct.

Behaviors towards other= parameters that happens to have come together with the authorization reque= st outside of request object will be treated as non-OAuth parameters.

=C2=A0

Nat Sakimura

Research Fellow, Nomura Research In= stitute

E: n-sakimura@nri.co.jp

T: +81(90)60136276

-----------------------------------= ----------------------

PLEASE READ:This e-mail is confident= ial and intended for the named recipient only.

If you are not an intended recipient= , please notify the sender and delete this e-mail.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Justin Richer
Sent: Friday, January 3, 2020 2:35 AM
To: Takahiko Kawasaki <taka@authlete.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >; oauth <oauth@i= etf.org>; Nat Sakimura <nat.sakimura@oidf.org>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs O= IDC request object

=C2=A0

For solution [2], this is the b= ehavior that=E2=80=99s required for OIDC today, so I would say that=E2=80= =99s the New Client behaving like an Old Client in order to talk to an Old = Server. So in reality, (2) causes the request to be rejected, and that=E2=80=99s OK.

=C2=A0

I don=E2=80=99t think it=E2=80= =99s viable to require parameters to exist inside the request object at all= times. Nor should we try to enumerate which parameters go inside and outsi= de at all times =E2=80=94 at least from the JAR/OAuth level of things. I think there are too many things that are application and deploym= ent specific for us to make this call. The very nature of the request objec= t changes for people =E2=80=94 some have a static object that=E2=80=99s dep= loyed with clients and some have something that the client creates at runtime for each request.=C2=A0=

=C2=A0

If the instead the New Server r= equires that any parameters duplicated between the two places have to match= (the OIDC method) or that in a conflict the request object values take pre= cedence (the merge method), then problems 3-1 and 3-2 go away.=C2=A0

=C2=A0

With the merge-and-precedence b= ehavior, which is what I thought that JAR had during WGLC, [3-1] is well-de= fined. The request is processed the same way every time because this is a N= ew Server. The client is going to do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge with = precedence=E2=80=9D is effectively a no-op.

=C2=A0

With the merge-and-precedence b= ehavior, [3-2] doesn=E2=80=99t happen because the required parameters aren= =E2=80=99t required to be in the request object itself. As long as the requ= est object is valid, it protects all parameters within it. I don=E2=80=99t think it=E2=80=99s up to us to determine what makes se= nse to put in that object. Security guidance is probably a good idea here.<= u>

=C2=A0

Solution [3] is what Old Client= s already do in OIDC today, so that=E2=80=99s what already happens and why = problem space (3) isn=E2=80=99t a problem.

=C2=A0

=C2=A0=E2=80=94 Justin



On Jan 2, 2020, at 12:24 PM, Ta= kahiko Kawasaki <= taka@authlete.com> wrote:

=C2=A0

Thank you, Justin. Actually, I = wanted to see someone write a summary about what happens in each combinatio= n from a viewpoint of both RP and AS with regard to backward compatibility = (as I told you in other channel just before you posted your email ^_^).

So,

(1) New Client + New Server
No problem will happen.

(2) New Client + Old Server
[Problem 2-1] If an authorization request contains 'request'= or 'request_uri' but doesn't have old mandatory request parame= ters ('client_id' and 'response_type') outside the request = object, the request is rejected.

[Solution 2] New Client should include the old mandatory request par= ameters duplicately outside the request object. This means that New Client = should always send old mandatory request parameters duplicately outside the= request object if it wants to get maximum compatibility.

(3) Old Client + New Server
[Problem 3-1] If an authorization request contains 'request'= or 'request_uri' and some "optional" request parameters = are not included in the request object, AS will interpret the request diffe= rently. Imagine what happens when optional parameters such as 'scope', 'state', 'nonce', 'redirect_uri= 9;, 'response_mode', 'max_age', 'acr_values', '= code_challenge', 'code_challenge_method' and 'prompt' a= re not included in the request object but present outside the request objec= t.

[Problem 3-2] If an authorization request contains 'request'= or 'request_uri' and some "mandatory" request parameters= ('client_id' and 'response_type') are not included in the = request object, the request is rejected.

[Solution 3] Old Client should include all request parameters duplic= ately in the request object. This means that Old Client should always inclu= de all request parameters duplicately in the request object if it wants to = get maximum compatibility.

(4) Old Client + Old Server
No problem will happen.

- - -

>From a Client's point of view, for maximum compatibility, both Old and = New Clients should put mandatory request parameters outside the request obj= ect and put all request parameters duplicately inside the request object.
[Problem 3-1] is difficult to detect because the authorization request is n= ot rejected. But, if New Server requires that all request parameters outsid= e the request object be put inside the request object duplicately, [Problem= 3-1] is handled as an error and thus client developers can detect the problem.

Consequently, introducing the following requirement in "FAPI Part 2, <= a href=3D"https://openid.net/specs/openid-financial-api-part-2-ID2.html#aut= horization-server" target=3D"_blank"> 5.2.2, 10" to JAR seems a good compromise (as I told before)

shall require that all paramete= rs are present inside the signed request object passed in the request or re= quest_uri parameter;


instead of just saying "the authorization server supporting this speci= fication MUST only use the parameters included in the request object."= which will bring about [Problem 3-1]. That is, how about adding a rule lik= e "if request parameters exist outside the request object, they must exist inside the request object, too."?

Any thoughts?

=C2=A0

Best,

Taka

=C2=A0

=C2=A0

On Fri, Jan 3, 2020 at 12:48 AM= Justin Richer <jri= cher@mit.edu> wrote:

I think the nature of the backw= ards incompatibility is important here. The way that things are now, using = merge-with-precedence, you have the following matrix of compatibility:

=C2=A0

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Server = =C2=A0| =C2=A0Old Server =C2=A0|<= /span>

-----------+-------------+--------------+

New Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0NO =C2=A0 =C2=A0 =C2=A0|=

Old Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 = =C2=A0 YES =C2=A0 =C2=A0 =C2=A0|<= /span>

=C2=A0

=C2=A0

If you ask me, this is the righ= t balance for a breaking change. Old clients, where the vast majority of th= e code is, don=E2=80=99t have to change. New clients can only talk to serve= rs with the new features, which is the ability to drop parameters from the external request. This would apply to both OID= C and plain OAuth.

=C2=A0

I think we should follow this k= ind of pattern in the discussions on OAuth 2.1, which I think JAR should be= a part of/

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

=C2=A0



On Jan 2, 2020, at 3:40 AM, Tak= ahiko Kawasaki <t= aka@authlete.com> wrote:

=C2=A0

Breaking backward compatibility= in this part would mean that OpenID Certification given to AS implementati= ons with request_uri support will be invalidated once they support JAR. It = also would mean that test cases in the official conformance suite need to be changed in a backward-incompatible m= anner, which would implicitly encourage that all certified implementations = should re-try to get certification.

Changing the spec now might need more three to six months, but it would be = worth considering what we get and lose by saving the months and breaking ba= ckward compatibility.

Best Regards,
Taka

=C2=A0

On Wed, Dec 18, 2019 at 4:14 PM= Nat Sakimura <s= akimura@gmail.com> wrote:

So, no change is OK?=C2=A0

=C2=A0

On Wed, Dec 11, 2019 at 10:01 P= M John Bradley <v= e7jtb@ve7jtb.com> wrote:

I also slightly prefer the merg= e approach.=C2=A0

=C2=A0

There are plusses and minuses t= o both.=C2=A0

=C2=A0

Changing again now that it is p= ast ISEG review and backing out a Discuss will add another three to six mon= ths at this point, if we can get them to agree to the change.=C2=A0<= u>

=C2=A0

John B.=C2=A0

=C2=A0

On Tue, Dec 10, 2019, 11:29 PM = Nat Sakimura <sa= kimura@gmail.com> wrote:

Correct. The WG supported the p= recedence approach and even merge just like OIDC as it is very useful from = the implementation point of view and helps with a bunch of deployment patte= r.=C2=A0

=C2=A0

The push back came in from the = Ben Campbell=E2=80=99s DISCUSS.=C2=A0

See=C2=A0<= /p>

=C2=A0

I am willing to go either way a= s long as people agree. My slight preference is to the original approach.= =C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat Sakimura

=C2=A0

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell &l= t;bcampbell=3D40pingidentity..com@dmarc.ietf.org>:

FWIW, as best I can remember th= e change in question came as I result of directorate/IESG review rather tha= n a WG decision/discussion. Which is likely why you can't find the &quo= t;why" anywhere in the mailing list archive.

=C2=A0

On Wed, Aug 28, 2019 at 3:23 PM= Filip Skokan <p= anva.ip@gmail.com> wrote:

Well it kind of blows, doesn= 9;t it? I wasn't able to find the "why" anywhere in the maili= ng list archive around the time this was changed.

=C2=A0

My take on satisfying both worl= ds looks like this

=C2=A0

- allow just JAR - no other par= ams when possible.

=C2=A0 =C2=A0 (which btw isn= 9;t possible to do with request_uri when enforcing client based uri whiteli= st and the jwsreq 5.2.2 shows as much)

- enforce the "dupe behavi= ours" defined in OIDC (if response_type or client_id is in request obj= ect it must either be missing or the same in regular request).

- allows merging request object= and regular parameters with request object taking=C2=A0precedence since it= is a very useful feature when having pre-signed request object that's = not one time use and clients using it wish to vary state/nonce per-request.

=C2=A0

I wish the group reconsidered m= aking this breaking change from OIDC's take on request objects - allow = combination of parameters from the request object with ones from regular pa= rameters (if not present in request object).


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Wed, 28 Aug 2019 at 23:02, B= rian Campbell <bcampbell@pingidentity.com> wrote:

Filip, for better or worse, I b= elieve your assessment of the situation is correct. I know of one AS that d= idn't choose which of the two to follow but rather implemented a bit of= a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the= presence and value of the few regular parameters (client_id, response_type= ) that OIDC mandates.

=C2=A0

On Tue, Aug 27, 2019 at 5:47 AM= Filip Skokan <p= anva.ip@gmail.com> wrote:

Hello everyone,

=C2=A0

in an earlier thread I've p= osed the following question that might have gotten missed, this might have = consequences for the existing implementations of Request Objects in OIDC im= plementations - its making pure JAR requests incompatible with OIDC Core implementations.

=C2=A0

draft 14 of jwsreq (JAR) introd= uced this language

=C2=A0

Th= e client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting th= is
specification MUST only use the parameters included in the request
object.=C2=A0

=C2=A0

Server MUST only use the parame= ters in the Request Object even if the
same parameter is provided in the query parameter.=C2=A0 The Authorization<= u>

=C2=A0

Th= e client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting th= is
specification MUST only use the parameters included in the request
object..=C2=A0

=C2=A0

Nat, John, everyone -=C2=A0d= oes this mean a JAR compliant AS ignores everything outside of the request = object while OIDC Request Object one merges the two with the ones in the re= quest object being used over ones that are sent in clear?=C2=A0The OIDC language also includes sections which mak= e sure that some required arguments are still passed outside of the request= object with the same value to make sure the request is "valid" O= Auth 2.0 request (client_id, response_type), something which an example in the JAR spec does not do. Not having this language mea= ns that existing authorization request pipelines can't simply be extend= ed with e.g. a middleware, they need to branch their codepaths.

=C2=A0

Is an AS required to choose whi= ch of the two it follows?

=C2=A0

Thank you for clarifying this i= n advance. I think if either the behaviour is the same as in OIDC or differ= ent this should be called out in the language to avoid confusion, especiall= y since this already exists in OIDC and likely isn't going to be read in isolation, especially because the= Request Object is even called out to be already in place in OIDC in the JA= R draft.

=C2=A0

Best,

Filip

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

=C2=A0

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


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

--

Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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


=C2=A0

--

Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

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

=C2=A0

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000fcfea8059b757d25-- From nobody Mon Jan 6 03:00: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 20F9B120120 for ; Mon, 6 Jan 2020 03:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Jx8Lm7jtS6PZ for ; Mon, 6 Jan 2020 03:00:29 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD0C12018D for ; Mon, 6 Jan 2020 03:00:28 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id f129so14816020wmf.2 for ; Mon, 06 Jan 2020 03:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LQUXbAuPy0m53sGNjieWXqK8icGrFwzdY0Uh2cRxa98=; b=QvkxzRX88US9F9pCQia5btD/BYKg9argWSNanzgjxn9FOSCUtcAhXYcuJ+1WcuYm6S 3q7htwnNKUlZGEeioeTTDwr3ZoTjXUPY2f+LEPWJnwzj354coYoPyRhXzH/xmt7uYvFJ bkZxD2nT5lCIU+5r4p/Edzr3ft78FCy9q73yu9Cb3+r+PJv99+rjrU8octOJZOHGr4qP OoudMyV8hXSVAVyoQiz8DY4qp/H4N7xIdPzbsAR+TzUiY7vIOiaMWd/KKAq4QdEh+v5g cMEim3XsWrYOI5DN66r+1mqmcN2miF+xpncU4Be9+ychOZDXkgHhjq7hpW0pihrwSIdA K9wQ== 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=LQUXbAuPy0m53sGNjieWXqK8icGrFwzdY0Uh2cRxa98=; b=m8W7Va7sW6zyLvivtjjV6UD3dKmQApgNJE6FX1rWmLglFFaKtFGu7JOn3MJpsJkRCT JPOnQ7O36JAboyqJIPgFZ+Imit0tpZd/XHyKeMmof50yPGJDwLrTIaJIHYWqsXSlY3QU h/beQteISHrUHuxCo48AKGPhCImD5DExg4bmP7tFTdSothr9P+psk9T0mivlMj5KzKO/ p+wRBPmvcKp39xI/c2T7kXsFQmgoB4WoURdjpbPf/MG93rvCxgQwbldD6+Z0Z7mfOSdv KiXQJDeP6yAgzx1nOaCim9vIG9NUCVWIXZt4Sm4joH10jFLTFJnBLmGCRbAy5uWrwzYD QkPQ== X-Gm-Message-State: APjAAAUsM239lrJ39E9zDwIWATKkeY+tMpAfgakjd5ysdc7k2X2wAl5W wv/gY964JB0Rw7r2ZVWUto9lSgbtzmSFIiWPT3YEqg== X-Google-Smtp-Source: APXvYqxmNUrWGq3QaGrHCEVnxCJZUGLg1fwnpX1dSDGR5a/SA01+kUCm8ZZwtAM6Nyv8hK1ueLclci6o8wRQwBkBaFM= X-Received: by 2002:a1c:5444:: with SMTP id p4mr33347112wmi.33.1578308426936; Mon, 06 Jan 2020 03:00:26 -0800 (PST) MIME-Version: 1.0 References: <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> In-Reply-To: From: Takahiko Kawasaki Date: Mon, 6 Jan 2020 20:00:15 +0900 Message-ID: To: Filip Skokan Cc: n-sakimura , Justin Richer , Brian Campbell , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="0000000000002247b8059b76914f" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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: Mon, 06 Jan 2020 11:00:34 -0000 --0000000000002247b8059b76914f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apparently, the description in the JAR spec has made some AS implementers, at least Vladimir - Connect2id and Filip - node-oidc-provider, decide to devise a workaround, and the approach (preparing a configuration switch) is attracting Taka (me) - Authlete, too. This may be a typical answer by AS implementers who face compatibility-breaking and interoperability-breaking issues, although I personally prefer to modify the specification itself to allow old/new RPs and ASes to coexist seamlessly. If the current draft is not modified any more, I will probably prepare per-AS and per-RP configuration switches. Anyway, this is feedback from AS implementers. If preparing a configuration switch is a typical answer by AS implementers, it might be good to define a new IdP metadata about JAR support (e.g. strict, lax, whitelist, as Filip showed). Rather, the existence of such metadata might be a must for the automated regular tests of conformance suite, but I'm not sure and want to consult Joseph Heenan regarding this. Best, Taka On Mon, Jan 6, 2020 at 6:43 PM Filip Skokan wrote: > I don't think we have the separation of OAuth and non-OAuth parameters an= d > let's please not. Even OIDC parameters are part of the OAuth parameters > registry > and > I cannot imagine the hardship if we were to explain that to developers. > > With passing time I believe it should be up to the profile or application > of JAR to define how to treat *recognized* parameters outside of the > request object. In my personal OSS project the AS can be configured to be > *strict* (jar), *lax* (oidc merge all) or *whitelist* (merge only > whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir > is describing. > > S pozdravem, > *Filip Skokan* > > > On Mon, 6 Jan 2020 at 07:05, n-sakimura wrote: > >> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if >> duplicated. >> >> As of -13 (Mar 30, 2017), it was changed that the server does not have t= o >> do the merge, at least for OAuth Authorization request parameters. It sa= ys >> nothing about other parameters. >> >> As of -14 (Jul 21, 2017), the wording was further strengthened by adding >> >> >> >> The Authorization Server MUST only use the parameters in the Request >> Object even if the same parameter is provided in the query parameter. >> >> >> >> So, the entire 6.3 now became >> 6.3 = . >> Request Parameter Assembly and Validation >> >> The Authorization Server MUST extract the set of Authorization >> >> Request parameters from the Request Object value. The Authorization >> >> Server MUST only use the parameters in the Request Object even if the >> >> same parameter is provided in the query parameter. The Authorization >> >> Server then validates the request as specified in OAuth 2.0 >> >> [RFC6749 ]. >> >> >> >> It says nothing on the non-OAuth parameters that came with the >> authorization request. >> >> My take on the text is that all OAuth Authorization Request parameters >> MUST be in the request object. >> >> Behaviors towards other parameters that happens to have come together >> with the authorization request outside of request object will be treated= as >> non-OAuth parameters. >> >> >> >> Nat Sakimura >> >> Research Fellow, Nomura Research Institute >> >> E: n-sakimura@nri.co.jp >> >> T: +81(90)60136276 >> >> --------------------------------------------------------- >> >> PLEASE READ:This e-mail is confidential and intended for the named >> recipient only. >> >> If you are not an intended recipient, please notify the sender and delet= e >> this e-mail. >> >> >> >> *From:* OAuth *On Behalf Of *Justin Richer >> *Sent:* Friday, January 3, 2020 2:35 AM >> *To:* Takahiko Kawasaki >> *Cc:* Brian Campbell ; >> oauth ; Nat Sakimura >> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs >> OIDC request object >> >> >> >> For solution [2], this is the behavior that=E2=80=99s required for OIDC = today, so >> I would say that=E2=80=99s the New Client behaving like an Old Client in= order to >> talk to an Old Server. So in reality, (2) causes the request to be >> rejected, and that=E2=80=99s OK. >> >> >> >> I don=E2=80=99t think it=E2=80=99s viable to require parameters to exist= inside the >> request object at all times. Nor should we try to enumerate which >> parameters go inside and outside at all times =E2=80=94 at least from th= e JAR/OAuth >> level of things. I think there are too many things that are application = and >> deployment specific for us to make this call. The very nature of the >> request object changes for people =E2=80=94 some have a static object th= at=E2=80=99s >> deployed with clients and some have something that the client creates at >> runtime for each request. >> >> >> >> If the instead the New Server requires that any parameters duplicated >> between the two places have to match (the OIDC method) or that in a >> conflict the request object values take precedence (the merge method), t= hen >> problems 3-1 and 3-2 go away. >> >> >> >> With the merge-and-precedence behavior, which is what I thought that JAR >> had during WGLC, [3-1] is well-defined. The request is processed the sam= e >> way every time because this is a New Server. The client is going to do >> OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge wit= h precedence=E2=80=9D is effectively a >> no-op. >> >> >> >> With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen bec= ause the >> required parameters aren=E2=80=99t required to be in the request object = itself. As >> long as the request object is valid, it protects all parameters within i= t. >> I don=E2=80=99t think it=E2=80=99s up to us to determine what makes sens= e to put in that >> object. Security guidance is probably a good idea here. >> >> >> >> Solution [3] is what Old Clients already do in OIDC today, so that=E2=80= =99s what >> already happens and why problem space (3) isn=E2=80=99t a problem. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki wrote= : >> >> >> >> Thank you, Justin. Actually, I wanted to see someone write a summary >> about what happens in each combination from a viewpoint of both RP and A= S >> with regard to backward compatibility (as I told you in other channel ju= st >> before you posted your email ^_^). >> >> So, >> >> *(1) New Client + New Server* >> No problem will happen. >> >> *(2) New Client + Old Server* >> *[Problem 2-1]* If an authorization request contains 'request' or >> 'request_uri' but doesn't have old mandatory request parameters >> ('client_id' and 'response_type') outside the request object, the reques= t >> is rejected. >> >> *[Solution 2]* New Client should include the old mandatory request >> parameters duplicately outside the request object. This means that New >> Client should always send old mandatory request parameters duplicately >> outside the request object if it wants to get maximum compatibility. >> >> *(3) Old Client + New Server* >> *[Problem 3-1]* If an authorization request contains 'request' or >> 'request_uri' and some "optional" request parameters are not included in >> the request object, AS will interpret the request differently. Imagine w= hat >> happens when optional parameters such as 'scope', 'state', 'nonce', >> 'redirect_uri', 'response_mode', 'max_age', 'acr_values', 'code_challeng= e', >> 'code_challenge_method' and 'prompt' are not included in the request obj= ect >> but present outside the request object. >> >> *[Problem 3-2]* If an authorization request contains 'request' or >> 'request_uri' and some "mandatory" request parameters ('client_id' and >> 'response_type') are not included in the request object, the request is >> rejected. >> >> *[Solution 3]* Old Client should include all request parameters >> duplicately in the request object. This means that Old Client should alw= ays >> include all request parameters duplicately in the request object if it >> wants to get maximum compatibility. >> >> *(4) Old Client + Old Server* >> No problem will happen. >> >> - - - >> >> >> From a Client's point of view, for maximum compatibility, both Old and >> New Clients should put mandatory request parameters outside the request >> object and put all request parameters duplicately inside the request obj= ect. >> >> [Problem 3-1] is difficult to detect because the authorization request i= s >> not rejected. But, if New Server requires that all request parameters >> outside the request object be put inside the request object duplicately, >> [Problem 3-1] is handled as an error and thus client developers can dete= ct >> the problem. >> >> Consequently, introducing the following requirement in "FAPI Part 2, >> 5.2.2 >> , >> 10" to JAR seems a good compromise (as I told before) >> >> shall require that all parameters are present inside the signed request >> object passed in the request or request_uri parameter; >> >> >> instead of just saying "the authorization server supporting this >> specification MUST only use the parameters included in the request objec= t." >> which will bring about [Problem 3-1]. That is, how about adding a rule l= ike >> "if request parameters exist outside the request object, they must exist >> inside the request object, too."? >> >> Any thoughts? >> >> >> >> Best, >> >> Taka >> >> >> >> >> >> On Fri, Jan 3, 2020 at 12:48 AM Justin Richer wrote: >> >> I think the nature of the backwards incompatibility is important here. >> The way that things are now, using merge-with-precedence, you have the >> following matrix of compatibility: >> >> >> >> >> >> New Server | Old Server | >> >> -----------+-------------+--------------+ >> >> New Client | YES | NO | >> >> Old Client | YES | YES | >> >> >> >> >> >> If you ask me, this is the right balance for a breaking change. Old >> clients, where the vast majority of the code is, don=E2=80=99t have to c= hange. New >> clients can only talk to servers with the new features, which is the >> ability to drop parameters from the external request. This would apply t= o >> both OIDC and plain OAuth. >> >> >> >> I think we should follow this kind of pattern in the discussions on OAut= h >> 2.1, which I think JAR should be a part of/ >> >> >> >> =E2=80=94 Justin >> >> >> >> >> >> >> >> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki wrote: >> >> >> >> Breaking backward compatibility in this part would mean that OpenID >> Certification given to AS implementations with request_uri support will = be >> invalidated once they support JAR. It also would mean that test cases in >> the official conformance suite need to be changed in a >> backward-incompatible manner, which would implicitly encourage that all >> certified implementations should re-try to get certification. >> >> Changing the spec now might need more three to six months, but it would >> be worth considering what we get and lose by saving the months and break= ing >> backward compatibility. >> >> Best Regards, >> Taka >> >> >> >> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura wrote: >> >> So, no change is OK? >> >> >> >> On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: >> >> I also slightly prefer the merge approach. >> >> >> >> There are plusses and minuses to both. >> >> >> >> Changing again now that it is past ISEG review and backing out a Discuss >> will add another three to six months at this point, if we can get them t= o >> agree to the change. >> >> >> >> John B. >> >> >> >> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote: >> >> Correct. The WG supported the precedence approach and even merge just >> like OIDC as it is very useful from the implementation point of view and >> helps with a bunch of deployment patter. >> >> >> >> The push back came in from the Ben Campbell=E2=80=99s DISCUSS. >> >> See >> >> >> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-act= ually-specifies-the >> >> >> >> I am willing to go either way as long as people agree. My slight >> preference is to the original approach. >> >> >> >> Best, >> >> >> >> Nat Sakimura >> >> >> >> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell > 40pingidentity..com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf.org>>: >> >> FWIW, as best I can remember the change in question came as I result of >> directorate/IESG review rather than a WG decision/discussion. Which is >> likely why you can't find the "why" anywhere in the mailing list archive= . >> >> >> >> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: >> >> Well it kind of blows, doesn't it? I wasn't able to find the "why" >> anywhere in the mailing list archive around the time this was changed. >> >> >> >> My take on satisfying both worlds looks like this >> >> >> >> - allow just JAR - no other params when possible. >> >> (which btw isn't possible to do with request_uri when enforcing >> client based uri whitelist and the jwsreq 5.2.2 shows as much) >> >> - enforce the "dupe behaviours" defined in OIDC (if response_type or >> client_id is in request object it must either be missing or the same in >> regular request). >> >> - allows merging request object and regular parameters with request >> object taking precedence since it is a very useful feature when having >> pre-signed request object that's not one time use and clients using it w= ish >> to vary state/nonce per-request. >> >> >> >> I wish the group reconsidered making this breaking change from OIDC's >> take on request objects - allow combination of parameters from the reque= st >> object with ones from regular parameters (if not present in request obje= ct). >> >> >> S pozdravem, >> *Filip Skokan* >> >> >> >> >> >> On Wed, 28 Aug 2019 at 23:02, Brian Campbell >> wrote: >> >> Filip, for better or worse, I believe your assessment of the situation i= s >> correct. I know of one AS that didn't choose which of the two to follow = but >> rather implemented a bit of a hybrid where it basically ignores everythi= ng >> outside of the request object per JAR but also checks for and enforces t= he >> presence and value of the few regular parameters (client_id, response_ty= pe) >> that OIDC mandates. >> >> >> >> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote: >> >> Hello everyone, >> >> >> >> in an earlier thread I've posed the following question that might have >> gotten missed, this might have consequences for the existing >> implementations of Request Objects in OIDC implementations - its making >> pure JAR requests incompatible with OIDC Core implementations. >> >> >> >> draft 14 of jwsreq (JAR) introduced this language >> >> >> >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. >> >> *However, the authorization server supporting this specification MUST >> only use the parameters included in the request object. * >> >> >> >> Server MUST only use the parameters in the Request Object even if the >> same parameter is provided in the query parameter. The Authorization >> >> >> >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. >> >> *However, the authorization server supporting this specification MUST >> only use the parameters included in the request object.. * >> >> >> >> Nat, John, everyone - *does this mean a JAR compliant AS ignores >> everything outside of the request object while OIDC Request Object one >> merges the two with the ones in the request object being used over ones >> that are sent in clear?* The OIDC language also includes sections which >> make sure that some required arguments are still passed outside of the >> request object with the same value to make sure the request is "valid" >> OAuth 2.0 request (client_id, response_type), something which an example= in >> the JAR spec does not do. Not having this language means that existing >> authorization request pipelines can't simply be extended with e.g. a >> middleware, they need to branch their codepaths. >> >> >> >> Is an AS required to choose which of the two it follows? >> >> >> >> Thank you for clarifying this in advance. I think if either the behaviou= r >> is the same as in OIDC or different this should be called out in the >> language to avoid confusion, especially since this already exists in OID= C >> and likely isn't going to be read in isolation, especially because the >> Request Object is even called out to be already in place in OIDC in the = JAR >> draft. >> >> >> >> Best, >> >> *Filip* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s)... Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000002247b8059b76914f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apparently, the description in the JAR spec has made some = AS implementers, at least Vladimir - Connect2id and Filip - node-oidc-provi= der, decide to devise a workaround, and the approach (preparing a configura= tion switch) is attracting Taka (me) - Authlete, too. This may be a typical= answer by AS implementers who face compatibility-breaking and interoperabi= lity-breaking issues, although I personally prefer to modify the specificat= ion itself to allow old/new RPs and ASes to coexist seamlessly.=C2=A0If the= current draft is not modified=C2=A0any more, I will probably prepare per-A= S and per-RP configuration switches. Anyway, this is feedback from AS imple= menters.

If preparing a configuration switch is a typica= l answer by AS implementers, it might be good to define a new IdP metadata = about JAR support (e.g. strict, lax, whitelist, as Filip showed). Rather, t= he existence of such metadata might be a must for the automated regular tests of conformance suite, = but I'm not sure and want to consult Joseph Heenan regarding this.

Best,
Taka

On Mon, Jan 6, 2020 at 6:43 PM Filip Skokan = <panva.ip@gmail.com> wrote:=
I don't think we have the separation of OAuth and non-OAuth para= meters and let's please not. Even OIDC parameters are part of the OAuth= parameters registry=C2=A0and I = cannot imagine the hardship if we were to explain that to developers.
=

With passing time I believe it should be up to the prof= ile or application of JAR to define how to treat recognized paramete= rs outside of the request object. In my personal OSS project the AS can be = configured to be strict (jar), lax (oidc merge all) or whi= telist (merge only whitelisted - code_challenge, nonce, state, ...) sim= ilar to what Vladimir is describing.

S pozdravem,
Filip Skokan


On Mon, 6 Jan 2= 020 at 07:05, n-sakimura <n-sakimura@nri.co.jp> wrote:

Up until -12 (Feb 13, 2= 017), it was using merge + JAR precedence if duplicated.

As of -13 (Mar 30, 2017= ), it was changed that the server does not have to do the merge, at least f= or OAuth Authorization request parameters. It says nothing about other para= meters.

As of -14 (Jul 21, 2017= ), the wording was further strengthened by adding

=C2=A0

The Authorization Server MU= ST only use the parameters in the Request Object even if the same parameter= is provided in the query parameter.

=C2=A0

So, the entire 6.3 now = became

6.3.=C2=A0 Request Parameter Assembly and Validation

=C2=A0=C2=A0 The Authorization Server MUST extrac=
t the set of Authorization
=C2=A0=C2=A0 Request parameters from the Request =
Object value.=C2=A0 The Authorization
=C2=A0=C2=A0 Server MUST only use the parameters =
in the Request Object even if the
=C2=A0=C2=A0 same parameter is provided in the qu=
ery parameter.=C2=A0 The Authorization
=C2=A0=C2=A0 Server then validates the request as=
 specified in OAuth 2.0
=C2=A0=C2=A0 [RFC6749].

=C2=A0

It says nothing on the = non-OAuth parameters that came with the authorization request.

My take on the text is = that all OAuth Authorization Request parameters MUST be in the request obje= ct.

Behaviors towards other= parameters that happens to have come together with the authorization reque= st outside of request object will be treated as non-OAuth parameters.

=C2=A0

Nat Sakimura

Research Fellow, Nomura Research In= stitute

E: n-sakimura@nri.co.jp

T: +81(90)60136276

-----------------------------------= ----------------------

PLEASE READ:This e-mail is confident= ial and intended for the named recipient only.

If you are not an intended recipient= , please notify the sender and delete this e-mail.

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Justin Richer
Sent: Friday, January 3, 2020 2:35 AM
To: Takahiko Kawasaki <taka@authlete.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >; oauth <oauth@i= etf.org>; Nat Sakimura <nat.sakimura@oidf.org>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs O= IDC request object

=C2=A0

For solution [2], this is the b= ehavior that=E2=80=99s required for OIDC today, so I would say that=E2=80= =99s the New Client behaving like an Old Client in order to talk to an Old = Server. So in reality, (2) causes the request to be rejected, and that=E2=80=99s OK.

=C2=A0

I don=E2=80=99t think it=E2=80= =99s viable to require parameters to exist inside the request object at all= times. Nor should we try to enumerate which parameters go inside and outsi= de at all times =E2=80=94 at least from the JAR/OAuth level of things. I think there are too many things that are application and deploym= ent specific for us to make this call. The very nature of the request objec= t changes for people =E2=80=94 some have a static object that=E2=80=99s dep= loyed with clients and some have something that the client creates at runtime for each request.=C2=A0=

=C2=A0

If the instead the New Server r= equires that any parameters duplicated between the two places have to match= (the OIDC method) or that in a conflict the request object values take pre= cedence (the merge method), then problems 3-1 and 3-2 go away.=C2=A0

=C2=A0

With the merge-and-precedence b= ehavior, which is what I thought that JAR had during WGLC, [3-1] is well-de= fined. The request is processed the same way every time because this is a N= ew Server. The client is going to do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge with = precedence=E2=80=9D is effectively a no-op.

=C2=A0

With the merge-and-precedence b= ehavior, [3-2] doesn=E2=80=99t happen because the required parameters aren= =E2=80=99t required to be in the request object itself. As long as the requ= est object is valid, it protects all parameters within it. I don=E2=80=99t think it=E2=80=99s up to us to determine what makes se= nse to put in that object. Security guidance is probably a good idea here.<= u>

=C2=A0

Solution [3] is what Old Client= s already do in OIDC today, so that=E2=80=99s what already happens and why = problem space (3) isn=E2=80=99t a problem.

=C2=A0

=C2=A0=E2=80=94 Justin



On Jan 2, 2020, at 12:24 PM, Ta= kahiko Kawasaki <= taka@authlete.com> wrote:

=C2=A0

Thank you, Justin. Actually, I = wanted to see someone write a summary about what happens in each combinatio= n from a viewpoint of both RP and AS with regard to backward compatibility = (as I told you in other channel just before you posted your email ^_^).

So,

(1) New Client + New Server
No problem will happen.

(2) New Client + Old Server
[Problem 2-1] If an authorization request contains 'request'= or 'request_uri' but doesn't have old mandatory request parame= ters ('client_id' and 'response_type') outside the request = object, the request is rejected.

[Solution 2] New Client should include the old mandatory request par= ameters duplicately outside the request object. This means that New Client = should always send old mandatory request parameters duplicately outside the= request object if it wants to get maximum compatibility.

(3) Old Client + New Server
[Problem 3-1] If an authorization request contains 'request'= or 'request_uri' and some "optional" request parameters = are not included in the request object, AS will interpret the request diffe= rently. Imagine what happens when optional parameters such as 'scope', 'state', 'nonce', 'redirect_uri= 9;, 'response_mode', 'max_age', 'acr_values', '= code_challenge', 'code_challenge_method' and 'prompt' a= re not included in the request object but present outside the request objec= t.

[Problem 3-2] If an authorization request contains 'request'= or 'request_uri' and some "mandatory" request parameters= ('client_id' and 'response_type') are not included in the = request object, the request is rejected.

[Solution 3] Old Client should include all request parameters duplic= ately in the request object. This means that Old Client should always inclu= de all request parameters duplicately in the request object if it wants to = get maximum compatibility.

(4) Old Client + Old Server
No problem will happen.

- - -

>From a Client's point of view, for maximum compatibility, both Old and = New Clients should put mandatory request parameters outside the request obj= ect and put all request parameters duplicately inside the request object.
[Problem 3-1] is difficult to detect because the authorization request is n= ot rejected. But, if New Server requires that all request parameters outsid= e the request object be put inside the request object duplicately, [Problem= 3-1] is handled as an error and thus client developers can detect the problem.

Consequently, introducing the following requirement in "FAPI Part 2, <= a href=3D"https://openid.net/specs/openid-financial-api-part-2-ID2.html#aut= horization-server" target=3D"_blank"> 5.2.2, 10" to JAR seems a good compromise (as I told before)

shall require that all paramete= rs are present inside the signed request object passed in the request or re= quest_uri parameter;


instead of just saying "the authorization server supporting this speci= fication MUST only use the parameters included in the request object."= which will bring about [Problem 3-1]. That is, how about adding a rule lik= e "if request parameters exist outside the request object, they must exist inside the request object, too."?

Any thoughts?

=C2=A0

Best,

Taka

=C2=A0

=C2=A0

On Fri, Jan 3, 2020 at 12:48 AM= Justin Richer <jri= cher@mit.edu> wrote:

I think the nature of the backw= ards incompatibility is important here. The way that things are now, using = merge-with-precedence, you have the following matrix of compatibility:

=C2=A0

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Server = =C2=A0| =C2=A0Old Server =C2=A0|<= /span>

-----------+-------------+--------------+

New Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0NO =C2=A0 =C2=A0 =C2=A0|=

Old Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 = =C2=A0 YES =C2=A0 =C2=A0 =C2=A0|<= /span>

=C2=A0

=C2=A0

If you ask me, this is the righ= t balance for a breaking change. Old clients, where the vast majority of th= e code is, don=E2=80=99t have to change. New clients can only talk to serve= rs with the new features, which is the ability to drop parameters from the external request. This would apply to both OID= C and plain OAuth.

=C2=A0

I think we should follow this k= ind of pattern in the discussions on OAuth 2.1, which I think JAR should be= a part of/

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

=C2=A0



On Jan 2, 2020, at 3:40 AM, Tak= ahiko Kawasaki <t= aka@authlete.com> wrote:

=C2=A0

Breaking backward compatibility= in this part would mean that OpenID Certification given to AS implementati= ons with request_uri support will be invalidated once they support JAR. It = also would mean that test cases in the official conformance suite need to be changed in a backward-incompatible m= anner, which would implicitly encourage that all certified implementations = should re-try to get certification.

Changing the spec now might need more three to six months, but it would be = worth considering what we get and lose by saving the months and breaking ba= ckward compatibility.

Best Regards,
Taka

=C2=A0

On Wed, Dec 18, 2019 at 4:14 PM= Nat Sakimura <s= akimura@gmail.com> wrote:

So, no change is OK?=C2=A0

=C2=A0

On Wed, Dec 11, 2019 at 10:01 P= M John Bradley <v= e7jtb@ve7jtb.com> wrote:

I also slightly prefer the merg= e approach.=C2=A0

=C2=A0

There are plusses and minuses t= o both.=C2=A0

=C2=A0

Changing again now that it is p= ast ISEG review and backing out a Discuss will add another three to six mon= ths at this point, if we can get them to agree to the change.=C2=A0<= u>

=C2=A0

John B.=C2=A0

=C2=A0

On Tue, Dec 10, 2019, 11:29 PM = Nat Sakimura <sa= kimura@gmail.com> wrote:

Correct. The WG supported the p= recedence approach and even merge just like OIDC as it is very useful from = the implementation point of view and helps with a bunch of deployment patte= r.=C2=A0

=C2=A0

The push back came in from the = Ben Campbell=E2=80=99s DISCUSS.=C2=A0

See=C2=A0<= /p>

=C2=A0

I am willing to go either way a= s long as people agree. My slight preference is to the original approach.= =C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat Sakimura

=C2=A0

2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell &l= t;bcampbell=3D40pingidentity..com@dmarc.ietf.org>:

FWIW, as best I can remember th= e change in question came as I result of directorate/IESG review rather tha= n a WG decision/discussion. Which is likely why you can't find the &quo= t;why" anywhere in the mailing list archive.

=C2=A0

On Wed, Aug 28, 2019 at 3:23 PM= Filip Skokan <p= anva.ip@gmail.com> wrote:

Well it kind of blows, doesn= 9;t it? I wasn't able to find the "why" anywhere in the maili= ng list archive around the time this was changed.

=C2=A0

My take on satisfying both worl= ds looks like this

=C2=A0

- allow just JAR - no other par= ams when possible.

=C2=A0 =C2=A0 (which btw isn= 9;t possible to do with request_uri when enforcing client based uri whiteli= st and the jwsreq 5.2.2 shows as much)

- enforce the "dupe behavi= ours" defined in OIDC (if response_type or client_id is in request obj= ect it must either be missing or the same in regular request).

- allows merging request object= and regular parameters with request object taking=C2=A0precedence since it= is a very useful feature when having pre-signed request object that's = not one time use and clients using it wish to vary state/nonce per-request.

=C2=A0

I wish the group reconsidered m= aking this breaking change from OIDC's take on request objects - allow = combination of parameters from the request object with ones from regular pa= rameters (if not present in request object).


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Wed, 28 Aug 2019 at 23:02, B= rian Campbell <bcampbell@pingidentity.com> wrote:

Filip, for better or worse, I b= elieve your assessment of the situation is correct. I know of one AS that d= idn't choose which of the two to follow but rather implemented a bit of= a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the= presence and value of the few regular parameters (client_id, response_type= ) that OIDC mandates.

=C2=A0

On Tue, Aug 27, 2019 at 5:47 AM= Filip Skokan <p= anva.ip@gmail.com> wrote:

Hello everyone,

=C2=A0

in an earlier thread I've p= osed the following question that might have gotten missed, this might have = consequences for the existing implementations of Request Objects in OIDC im= plementations - its making pure JAR requests incompatible with OIDC Core implementations.

=C2=A0

draft 14 of jwsreq (JAR) introd= uced this language

=C2=A0

Th= e client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting th= is
specification MUST only use the parameters included in the request
object.=C2=A0

=C2=A0

Server MUST only use the parame= ters in the Request Object even if the
same parameter is provided in the query parameter.=C2=A0 The Authorization<= u>

=C2=A0

Th= e client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. =C2=A0However, the authorization server supporting th= is
specification MUST only use the parameters included in the request
object..=C2=A0

=C2=A0

Nat, John, everyone -=C2=A0d= oes this mean a JAR compliant AS ignores everything outside of the request = object while OIDC Request Object one merges the two with the ones in the re= quest object being used over ones that are sent in clear?=C2=A0The OIDC language also includes sections which mak= e sure that some required arguments are still passed outside of the request= object with the same value to make sure the request is "valid" O= Auth 2.0 request (client_id, response_type), something which an example in the JAR spec does not do. Not having this language mea= ns that existing authorization request pipelines can't simply be extend= ed with e.g. a middleware, they need to branch their codepaths.

=C2=A0

Is an AS required to choose whi= ch of the two it follows?

=C2=A0

Thank you for clarifying this i= n advance. I think if either the behaviour is the same as in OIDC or differ= ent this should be called out in the language to avoid confusion, especiall= y since this already exists in OIDC and likely isn't going to be read in isolation, especially because the= Request Object is even called out to be already in place in OIDC in the JA= R draft.

=C2=A0

Best,

Filip

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

=C2=A0

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


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

--

Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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


=C2=A0

--

Nat Sakimura (=3Dnat)=

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

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

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

=C2=A0

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002247b8059b76914f-- From nobody Mon Jan 6 05:57: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 97D0D1200CC for ; Mon, 6 Jan 2020 05:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 w6fFVw3rhl4r for ; Mon, 6 Jan 2020 05:57:52 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450: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 1C1EE120052 for ; Mon, 6 Jan 2020 05:57:52 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id z22so46201628ljg.1 for ; Mon, 06 Jan 2020 05:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mtZgMgGgeoiq8kgGa2sI2e8ltoXstXhcL8ObqqV2Ux0=; b=buyBAFnaqdmugsY5pSVd/Vhnxhco9wDgPJdLimVYzMAkgwIl84LtyKfHp5BltZZrz7 RnxnEqQlQt88IJXkAyV15Lh1eFi7Km1+Car6YFb/AYX7xERlxzyIp/hsK8Go2WC9k87g ZwRhGr+rcTPd/r9sMXTgCUHZeU9RiHXtxvYby6tUKhGxw4wGO8VYFblVb1OJaaHewB5B g711rOjWIFoxhQ7Tikr4q15A4TywtwYtdrhXfzwMy9eS+Qt5/SjkE/a0oe1SKBC6S/ny cDbrpvBVsNum+2rn6xWYUCGeEuVaFCEigRIQnaScA4KNXtkRIJ48YO9IVl9cuIdqJDX8 Bqpg== 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=mtZgMgGgeoiq8kgGa2sI2e8ltoXstXhcL8ObqqV2Ux0=; b=DM5l/EZNKx11yA9hLPlHpUsJ2ZnASvHbyb2f7AeXFKu75E7Qn8zDdHL7ZIO2HWUXQD m0FrZsosZH4gZ3ZxG+5al6fY5obbfXduwLUbqxfyOgdHVBye7lbhlE9CsplnzzipK9xJ GDXNrNGq7dUFGqzSixb2H8NqoozAcW/W7vkMXl0jWiHZVtCIYmslTwBsYVy3BW5V3tPb 8ZSt6yS6H/NZu2YlprmShK9zfJXv/rAzdKxgl1fNXvYHZ4/oGvy4UlTnbaia1E/3tYfi gcg3gpxSleN6jSh981zoR3+AdVW6n6pOkGY0pW9HddR8um8mcpFGHfvmy4EC+qZouCDX X+vw== X-Gm-Message-State: APjAAAVgi1TfdtPUlFAQtb0wux8eL3l7zMgbDvAT7E24RR3u9nL6xjNX KCZyf0F+F3nCgkhs/g0PNx9l7GgSR6FZ0l35oRmnplAsnBX4ZiJaeVGsfKMSPDKdOONobW7mCqH XoYF8daIBotOK0Q== X-Google-Smtp-Source: APXvYqxGMSM5oF+6zWza/YsUdRXEB735cX47DRGgJns1FOJb2bsBYydLlLip8lbXGjPi/Qp5mX2PEmQQxTyP7GixPHU= X-Received: by 2002:a2e:9110:: with SMTP id m16mr60165285ljg.140.1578319070209; Mon, 06 Jan 2020 05:57:50 -0800 (PST) MIME-Version: 1.0 References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> In-Reply-To: <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> From: Brian Campbell Date: Mon, 6 Jan 2020 06:57:23 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: Torsten Lodderstedt , Filip Skokan , Dave Tonge , oauth , Nat Sakimura Content-Type: multipart/alternative; boundary="00000000000085be80059b790b7b" Archived-At: Subject: Re: [OAUTH-WG] PAR 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: Mon, 06 Jan 2020 13:57:56 -0000 --00000000000085be80059b790b7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I really struggle to see the assumption that an entity be able to use the same key to decrypt the same type of message ultimately intended for the same purpose as an artificial limit. The same general assumption underlies everything else in OAuth/OIDC (Vladimir's post points to some but not all examples of such). There's no reason for PAR to make a one-off exception. And should there be some deployment specific reason that truly requires that kind of isolation, there are certainly implementation options that aren't compatibility-breaking. And having said all that, I'm honestly a little surprised anyone is thinking much about encrypted request objects with PAR as, at least with my limited imagination, there's not really a need for it. On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle wrote: > PAR introduces an added wrinkle for encrypted request objects: the PAR > endpoint and authorization endpoint may not have access to the same > cryptographic keys, even though they're both part of the "authorization > server." Since they're different endpoints with different roles, it's > reasonable to put them in separate trust boundaries. There is no way to > support this isolation with just a single "jwks_uri" metadata property. > > The two options that I see are: > > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. > > I strongly perfer #1 as it has a very minor impact on deployments that > don't care (i.e., they just set par_jwks_uri and jwks_uri to the same > value) and failing to support this trust boundary creates an artificial > limit on implementation architecture and could lead to > compatibility-breaking workarounds. > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > =EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten=3D > 40lodderstedt.net@dmarc.ietf.org> wrote: > > Hi Filip, > > > On 31. Dec 2019, at 16:22, Filip Skokan wrote: > > > > I don't think we need a *_auth_method_* metadata for every endpoint > the client calls directly, none of the new specs defined these (e.g. devi= ce > authorization endpoint or CIBA), meaning they also didn't follow the sche= me > from RFC 8414 where introspection and revocation got its own metadata. In > most cases the unfortunately named `token_endpoint_auth_method` and its > related metadata is what's used by clients for all direct calls anyway. > > > > The same principle could be applied to signing (and encryption) > algorithms as well. > > > > This I do not follow, auth methods and their signing is dealt with > by using `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - there's no encryptio= n > for the `_jwt` client auth methods. > > Unless it was meant to address the Request Object signing and > encryption metadata, which is defined and IANA registered by OIDC. PAR on= ly > references JAR section 6.1 and 6.2 for decryption/signature validation an= d > these do not mention the metadata (e.g. request_object_signing_alg) anymo= re > since draft 07. > > Dammed! You are so right. Sorry, I got confused somehow. > > > > > PS: I also found this comment related to the same question about > auth metadata but for CIBA. > > Thanks for sharing. > > > > > Best, > > Filip > > thanks, > Torsten. > > > > > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > Ronald just sent me an email asking whether we will define metadata > for > > > > pushed_authorization_endpoint_auth_methods_supported and > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > > > > The draft right now utilises the existing token endpoint > authentication methods so there is basically no need to define another > parameter. The same principle could be applied to signing (and encryption= ) > algorithms as well. > > > > What=E2=80=99s your opinion? > > > > best regards, > > Torsten. > > > > _______________________________________________ > 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._ --00000000000085be80059b790b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I really struggle to see the assumption that an entit= y be able to use the same key to decrypt the same type of message ultimatel= y intended for the same purpose as an artificial limit. The same general a= ssumption =C2=A0 underlies everything else in OAuth/OIDC (Vladimir's po= st points to some but not all examples of such). There's no reason for = PAR to make a one-off exception. And should there be some deployment specif= ic reason that truly requires that kind of isolation, there are certainly i= mplementation options that aren't compatibility-breaking. And having sa= id all that, I'm honestly a little surprised anyone is thinking much ab= out encrypted request objects with PAR as, at least with my limited imagina= tion, there's not really a need for it.

<= br>


=C2=A0



On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
PAR introduces an added wrinkle for encryp= ted request objects: the PAR endpoint and authorization endpoint may not ha= ve access to the same cryptographic keys, even though they're both part= of the "authorization server." Since they're different endpo= ints with different roles, it's reasonable to put them in separate trus= t boundaries. There is no way to support this isolation with just a single = "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that don&= #39;t care (i.e., they just set par_jwks_uri and jwks_uri to the same value= ) and failing to support this trust boundary creates an artificial limit on= implementation architecture and could lead to compatibility-breaking worka= rounds.

=E2=80=93
Annabelle Richard Backman
AWS Identity


=EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt= " <oaut= h-bounces@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0 Hi Filip,

=C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan <panva.ip@gmail.com> wrot= e:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I don't think we need a *_auth_method_* metadata for= every endpoint the client calls directly, none of the new specs defined th= ese (e.g. device authorization endpoint or CIBA), meaning they also didn= 9;t follow the scheme from RFC 8414 where introspection and revocation got = its own metadata. In most cases the unfortunately named `token_endpoint_aut= h_method` and its related metadata is what's used by clients for all di= rect calls anyway.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The same principle could be applied to signing (and encr= yption) algorithms as well.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This I do not follow, auth methods and their signing is = dealt with by using `token_endpoint_auth_methods_supported` and `token_endp= oint_auth_signing_alg_values_supported` - there's no encryption for the= `_jwt` client auth methods.
=C2=A0 =C2=A0 > Unless it was meant to address the Request Object signin= g and encryption metadata, which is defined and IANA registered by OIDC. PA= R only references JAR section 6.1 and 6.2 for decryption/signature validati= on and these do not mention the metadata (e.g. request_object_signing_alg) = anymore since draft 07.

=C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confused somehow.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > PS: I also found this comment related to the same questi= on about auth metadata but for CIBA.

=C2=A0 =C2=A0 Thanks for sharing.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 > Filip

=C2=A0 =C2=A0 thanks,
=C2=A0 =C2=A0 Torsten.

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <torsten@lodderst= edt.net> wrote:
=C2=A0 =C2=A0 > Hi all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Ronald just sent me an email asking whether we will defi= ne metadata for
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_supported and=
=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_signing_alg_values_su= pported.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The draft right now utilises the existing token endpoint= authentication methods so there is basically no need to define another par= ameter. The same principle could be applied to signing (and encryption) alg= orithms as well.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What=E2=80=99s your opinion?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > best regards,
=C2=A0 =C2=A0 > Torsten.



_______________________________________________
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. --00000000000085be80059b790b7b-- From nobody Mon Jan 6 06:28: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 8E69A1200B8 for ; Mon, 6 Jan 2020 06:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 txYv1GzIkhVv for ; Mon, 6 Jan 2020 06:28:25 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D9712087F for ; Mon, 6 Jan 2020 06:28:25 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id t2so49815878wrr.1 for ; Mon, 06 Jan 2020 06:28:25 -0800 (PST) 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=lJbnjwBc8u76kWvLyNdUd6DVS9+r+vqXtnW5lHAIqV8=; b=Jy3frEhZYZI03qGkFWwhJHZK6shU0kJu0/Srh1Ocg3yEiY6TelXgbi/BjZT1za5jlY WvGbMxF618nTof1jBQSSw3dcvOUk933wHIZWbOnQ/PwuavbNV5+SG1lnUmAUSUa4u81c n+U2j09MoncPtVrcl2ZJ01P3wEeD0PX0ueihs= 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=lJbnjwBc8u76kWvLyNdUd6DVS9+r+vqXtnW5lHAIqV8=; b=cmElRjh3olVv0NRdvprelJex+iL/0+owYVusiZRwBqO3Mx/Hj2xd3IxnYHkWOsxFGE MrDAEDg6xFayhv444F1tKTugzpDePtDho77Wx1jaUNy9TvYGLnUC3NvKKPoX7PIkHJ7y AYN/QPwpyf/hoJaG8lbpHCMj+IWlNDk9kTO1R/Rf43ncbxua8iZbxgcOGhwWYgWL+GpQ Jv8pvahyxqogJ9e0yBFrjFyHwrxhBiSiBVWKaAunVE4IqGST4vtPGicGlAGoqXIHQggm md+Wuodgw4G0uBYdOkcakFMLlmIMUXECq3Mbzr3HJ+/sjKDkwWDdOvVWrCn/PgFhAQ30 3/TQ== X-Gm-Message-State: APjAAAX83zRcwj8RX9Tw7gyl1wBgDUNgL0ft+D9RjZHKL5VeJh11ghHy hZaC5CSpomrfuQgl7CjJAqr+tbzUZjgD9Q== X-Google-Smtp-Source: APXvYqx3yZjsuCeuvJ1AszsOC6k84v0cfIaJIDIcZCnrfvWalYdQTlwHc1MUidoFtr0c/mMVmXgQRw== X-Received: by 2002:adf:f5cb:: with SMTP id k11mr99731087wrp.71.1578320903861; Mon, 06 Jan 2020 06:28:23 -0800 (PST) Received: from [192.168.2.122] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id z123sm23469307wme.18.2020.01.06.06.28.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2020 06:28:23 -0800 (PST) From: Neil Madden Message-Id: <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_98272658-59B1-4DB8-B69E-F3E03FFC2E1E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 6 Jan 2020 14:28:21 +0000 In-Reply-To: Cc: "Richard Backman, Annabelle" , Nat Sakimura , Dave Tonge , Torsten Lodderstedt , oauth To: Brian Campbell References: <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [OAUTH-WG] PAR 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: Mon, 06 Jan 2020 14:28:28 -0000 --Apple-Mail=_98272658-59B1-4DB8-B69E-F3E03FFC2E1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed. In addition, I'm not sure why the PAR endpoint would need access to the = decryption keys at all. If you're using encrypted request objects then = the PAR endpoint receives an encrypted JWT and then later makes the same = (still encrypted) JWT available to the authorization endpoint. If the = PAR endpoint is doing any kind of decryption or validation on behalf of = the authorization endpoint then they are clearly not in separate trust = boundaries. -- Neil > On 6 Jan 2020, at 13:57, Brian Campbell = wrote: >=20 > I really struggle to see the assumption that an entity be able to use = the same key to decrypt the same type of message ultimately intended for = the same purpose as an artificial limit. The same general assumption = underlies everything else in OAuth/OIDC (Vladimir's post points to some = but not all examples of such). There's no reason for PAR to make a = one-off exception. And should there be some deployment specific reason = that truly requires that kind of isolation, there are certainly = implementation options that aren't compatibility-breaking. And having = said all that, I'm honestly a little surprised anyone is thinking much = about encrypted request objects with PAR as, at least with my limited = imagination, there's not really a need for it.=20 >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 > On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle = > wrote: > PAR introduces an added wrinkle for encrypted request objects: the PAR = endpoint and authorization endpoint may not have access to the same = cryptographic keys, even though they're both part of the "authorization = server." Since they're different endpoints with different roles, it's = reasonable to put them in separate trust boundaries. There is no way to = support this isolation with just a single "jwks_uri" metadata property. >=20 > The two options that I see are: >=20 > 1. Define a new par_jwks_uri metadata property. > 2. Explicitly state that this separation is not supported. >=20 > I strongly perfer #1 as it has a very minor impact on deployments that = don't care (i.e., they just set par_jwks_uri and jwks_uri to the same = value) and failing to support this trust boundary creates an artificial = limit on implementation architecture and could lead to = compatibility-breaking workarounds. >=20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity >=20 >=20 > =EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten = Lodderstedt" on = behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org = > wrote: >=20 > Hi Filip,=20 >=20 > > On 31. Dec 2019, at 16:22, Filip Skokan > wrote: > >=20 > > I don't think we need a *_auth_method_* metadata for every = endpoint the client calls directly, none of the new specs defined these = (e.g. device authorization endpoint or CIBA), meaning they also didn't = follow the scheme from RFC 8414 where introspection and revocation got = its own metadata. In most cases the unfortunately named = `token_endpoint_auth_method` and its related metadata is what's used by = clients for all direct calls anyway. > >=20 > > The same principle could be applied to signing (and encryption) = algorithms as well. > >=20 > > This I do not follow, auth methods and their signing is dealt = with by using `token_endpoint_auth_methods_supported` and = `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.=20 > > Unless it was meant to address the Request Object signing and = encryption metadata, which is defined and IANA registered by OIDC. PAR = only references JAR section 6.1 and 6.2 for decryption/signature = validation and these do not mention the metadata (e.g. = request_object_signing_alg) anymore since draft 07. >=20 > Dammed! You are so right. Sorry, I got confused somehow.=20 >=20 > >=20 > > PS: I also found this comment related to the same question about = auth metadata but for CIBA. >=20 > Thanks for sharing.=20 >=20 > >=20 > > Best, > > Filip >=20 > thanks, > Torsten.=20 >=20 > >=20 > >=20 > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt = > wrote: > > Hi all, > >=20 > > Ronald just sent me an email asking whether we will define = metadata for=20 > >=20 > > pushed_authorization_endpoint_auth_methods_supported and > > pushed_authorization_endpoint_auth_signing_alg_values_supported. > >=20 > > The draft right now utilises the existing token endpoint = authentication methods so there is basically no need to define another = parameter. The same principle could be applied to signing (and = encryption) algorithms as well.=20 > >=20 > > What=E2=80=99s your opinion? > >=20 > > best regards, > > Torsten. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_98272658-59B1-4DB8-B69E-F3E03FFC2E1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed.

In = addition, I'm not sure why the PAR endpoint would need access to the = decryption keys at all. If you're using encrypted request objects then = the PAR endpoint receives an encrypted JWT and then later makes the same = (still encrypted) JWT available to the authorization endpoint. If the = PAR endpoint is doing any kind of decryption or validation on behalf of = the authorization endpoint then they are clearly not in separate trust = boundaries.

-- = Neil


On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I really struggle to see the = assumption that an entity be able to use the same key to decrypt the = same type of message ultimately intended for the same purpose as an = artificial limit. The same general assumption   underlies = everything else in OAuth/OIDC (Vladimir's post points to some but not = all examples of such). There's no reason for PAR to make a one-off = exception. And should there be some deployment specific reason that = truly requires that kind of isolation, there are certainly = implementation options that aren't compatibility-breaking. And having = said all that, I'm honestly a little surprised anyone is thinking much = about encrypted request objects with PAR as, at least with my limited = imagination, there's not really a need for it.




 



On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:
PAR introduces an added wrinkle for = encrypted request objects: the PAR endpoint and authorization endpoint = may not have access to the same cryptographic keys, even though they're = both part of the "authorization server." Since they're different = endpoints with different roles, it's reasonable to put them in separate = trust boundaries. There is no way to support this isolation with just a = single "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that = don't care (i.e., they just set par_jwks_uri and jwks_uri to the same = value) and failing to support this trust boundary creates an artificial = limit on implementation architecture and could lead to = compatibility-breaking workarounds.

=E2=80=93
Annabelle Richard Backman
AWS Identity


=EF=BB=BFOn 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" = <oauth-bounces@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

    Hi Filip,

    > On 31. Dec 2019, at 16:22, Filip Skokan <panva.ip@gmail.com> wrote:
    >
    > I don't think we need a *_auth_method_* metadata for = every endpoint the client calls directly, none of the new specs defined = these (e.g. device authorization endpoint or CIBA), meaning they also = didn't follow the scheme from RFC 8414 where introspection and = revocation got its own metadata. In most cases the unfortunately named = `token_endpoint_auth_method` and its related metadata is what's used by = clients for all direct calls anyway.
    >
    > The same principle could be applied to signing (and = encryption) algorithms as well.
    >
    > This I do not follow, auth methods and their signing = is dealt with by using `token_endpoint_auth_methods_supported` and = `token_endpoint_auth_signing_alg_values_supported` - there's no = encryption for the `_jwt` client auth methods.
    > Unless it was meant to address the Request Object = signing and encryption metadata, which is defined and IANA registered by = OIDC. PAR only references JAR section 6.1 and 6.2 for = decryption/signature validation and these do not mention the metadata = (e.g. request_object_signing_alg) anymore since draft 07.

    Dammed! You are so right. Sorry, I got confused somehow. =

    >
    > PS: I also found this comment related to the same = question about auth metadata but for CIBA.

    Thanks for sharing.

    >
    > Best,
    > Filip

    thanks,
    Torsten.

    >
    >
    > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:
    > Hi all,
    >
    > Ronald just sent me an email asking whether we will = define metadata for
    >
    > pushed_authorization_endpoint_auth_methods_supported = and
    > = pushed_authorization_endpoint_auth_signing_alg_values_supported.
    >
    > The draft right now utilises the existing token = endpoint authentication methods so there is basically no need to define = another parameter. The same principle could be applied to signing (and = encryption) algorithms as well.
    >
    > What=E2=80=99s your opinion?
    >
    > best regards,
    > Torsten.



_______________________________________________
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

= --Apple-Mail=_98272658-59B1-4DB8-B69E-F3E03FFC2E1E-- From nobody Mon Jan 6 06:36: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 DC332120840 for ; Mon, 6 Jan 2020 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KuGXz_Gwy1Gr for ; Mon, 6 Jan 2020 06:35:57 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA2F12082A for ; Mon, 6 Jan 2020 06:35:57 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id ABEEF12F1D for ; Mon, 6 Jan 2020 14:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578321354; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wGxY9NEZLUJszOBGeIJN35Qi0f/uCcNL3ifKr1cNIjk=; b=cIGXBoR1TuE+tK5HrHRC/Y0109nx/fSbbo/ONQz/B2Uw8kO9nOqo5R5L0HdrxmPVk5yKaE 6Om9tzbtlRlD46Sy8qcXPZbNRA6OfRXme5CiTSVoHD4QhbeRYhxrvAT8YoLmZq/TfaPZv+ btEN8Ug7U7d2Z43ICyKvoQyjRoqkRlM= To: oauth@ietf.org References: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> From: Daniel Fett Message-ID: Date: Mon, 6 Jan 2020 15:35:53 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B1326A93687C9BCD66F2253" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578321355; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wGxY9NEZLUJszOBGeIJN35Qi0f/uCcNL3ifKr1cNIjk=; b=MFcFqCetShBQ7jiqGNqyNWnmnE+8VOK57Jns+yWOU0CQ5zvatxjx/QfAU0G9vj5m0PkCvm SDG1iyfo9UwYOu7XEgjLyo6Sd1BgScq7bgx0nSdKsh+wDp5EEruePKgTbAqJcw9Av8hpWv ttWAGmxhFjrXBxxOEQA8YN/AX7VgXys= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1578321355; a=rsa-sha256; cv=none; b=Ta0rbytCiOOmP9g3HY1UJ4Iio1IqZx7Z/C/WEt8LRAHCAsw9YgVQ/BbyMdxzEyKSxUNJoS1NKczjfu1AqfJSvNuhDPwZJXwKfg2gIF3eTnJ4SbHeiWWAmEDlyP90NaidEB+ptoFYdebXemUq1exfid/UDbZhJulHNZWyEtcknsU= 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] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jan 2020 14:36:00 -0000 This is a multi-part message in MIME format. --------------7B1326A93687C9BCD66F2253 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 27.12.19 um 23:27 schrieb Filip Skokan: > Encrypted JARM responses are in a very similar position. Access Token > value is not part of the URL and the response itself is protected. > Such response is usually only consumed by a server side application. > Same as any form_post response. The encryption of JARM does not add much if the token leaks: An attacker could just inject it into a flow on his device. This is also why sender-constraining, even if it would be possible in the "token id_token" scenario, would not help at all. > > We could go into further clarifying the client application topology to > enable these uses but i don’t think it’s worth it. Why make excuses to > keep implicit issued access tokens around in when code flow is the way > the WG has decided to go. (Here we go again...) +1 -Daniel > > Best, > Filip > >> 27. 12. 2019 v 21:41, Torsten Lodderstedt >> : >> >>  >> As Brian said, we have discussed this several times and this text >> found consensus. >> >> Using post reduces the attack surface but does not allow to bind the >> access token to the legitimate client. We are recommending sender >> constrained access tokens in the BCP. So recommending a flow that >> does not support sender constrained access tokens is a contradiction. >> >> What do other WG members think? >> >>> Am 27.12.2019 um 21:28 schrieb Mike Jones >>> : >>> >>>  >>> I agree with Brian. Please update the text to describe this already >>> safe usage. >>> >>> -- Mike >>> >>> ------------------------------------------------------------------------ >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Sent:* Friday, December 27, 2019 11:03:30 AM >>> *To:* oauth >>> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC >>> response types + form_post response mode >>>   >>> We have a-sometimes used scenario where a client makes an >>> authorization/authentication request with a "token id_token" >>> response type and "form_post" response mode (nonce is also sent and >>> exact redirect URI matching is done at the AS). The access token is >>> never exposed in any URLs and access token injection is prevented by >>> the at_hash claim in the id token. >>> >>> That seems to me like a legitimate and reasonable usage scenario. >>> However, it would fall on the wrong side of the SHOULD NOT in >>> Section 3.1.2 of the Security BCP-to-be >>> , >>> which has: >>> >>>    In order to avoid these issues, clients SHOULD NOT use the implicit >>>    grant (response type "token") or any other response type issuing >>>    access tokens in the authorization response, such as "token id_token" >>>    and "code token id_token", unless the issued access tokens are >>>    sender-constrained and access token injection in the authorization >>>    response is prevented. >>> >>> I know this particular text has been discussed over and over again >>> so I hate to revisit it. But based on the aforementioned scenario I >>> think maybe it still doesn't quite hit the mark. Access token >>> injection is prevented. The token leakage scenarios mentioned in >>> that section are all avoided. And while I know sender-constrained is >>> recommended elsewhere in the draft, it's not really a realistic >>> option for the majority of deployments. >>> >>> /CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended 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 --------------7B1326A93687C9BCD66F2253 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 27.12.19 um 23:27 schrieb Filip Skokan:
Encrypted JARM responses are in a very similar position. Access Token value is not part of the URL and the response itself is protected. Such response is usually only consumed by a server side application. Same as any form_post response.

The encryption of JARM does not add much if the token leaks: An attacker could just inject it into a flow on his device.

This is also why sender-constraining, even if it would be possible in the "token id_token" scenario, would not help at all.


We could go into further clarifying the client application topology to enable these uses but i don’t think it’s worth it. Why make excuses to keep implicit issued access tokens around in when code flow is the way the WG has decided to go. (Here we go again...)

+1

-Daniel


Best,
Filip

27. 12. 2019 v 21:41, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>:


As Brian said, we have discussed this several times and this text found consensus.

Using post reduces the attack surface but does not allow to bind the access token to the legitimate client. We are recommending sender constrained access tokens in the BCP. So recommending a flow that does not support sender constrained access tokens is a contradiction.

What do other WG members think?

Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:


I agree with Brian. Please update the text to describe this already safe usage.

-- Mike

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.

I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended 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


--------------7B1326A93687C9BCD66F2253-- From nobody Mon Jan 6 06:47: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 0DA0C12082A for ; Mon, 6 Jan 2020 06:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XMCOgdyFBg49 for ; Mon, 6 Jan 2020 06:47:24 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7B8120823 for ; Mon, 6 Jan 2020 06:47:24 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 1B36312EA5 for ; Mon, 6 Jan 2020 14:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578322042; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I1rnJEs83Kcytb7wy4R0fxVrz5IdVsvCVk/B63Nwjd8=; b=oIlsFfFRG0/bkf1IfKBAU0Fw1/23wuB0frllZCithz9vguNA/eh82/dAdYr9fFvHEFBacp tnuHPqh39qgnRdl1A1xm6+eA4muZDpLuQ6FiMQkp2K7NpMvdlRsJgn9aQZSkxcThPS2u3a SdsIvvoQz2knQnRiNZyfJ1OY164W5CA= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <7cc6f870-eeb1-f3c6-2afb-698b1ff8d422@danielfett.de> Date: Mon, 6 Jan 2020 15:47:21 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------72355B2201B776239C0C94AF" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578322042; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I1rnJEs83Kcytb7wy4R0fxVrz5IdVsvCVk/B63Nwjd8=; b=rRJKMgaNC4Ff2sp/m2aSbefgD+NbclccPBRXfSZqD0E/5n/ELP8pnS8aCVfFYretd4T01z 0etgqLM1+NZoZpVapcpp9u4lLuZwj5Z20x60SxySFmyv8Nw6UcYST7ScXnYKUvKjPhNYzN /jFAE7xEZ4YM40Hzy2C28wx50kZ/Dt0= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1578322042; a=rsa-sha256; cv=none; b=B8OIMKvzauVIPEyh+tx+8oFChIXGkruRK8EVtCHRisxF/6lG+1phUEldd6Vn5TCexbtqSnMcjxKGB5IbJXIs9DMjrkmtZxSQlQy8yYQDLMuF9xL++Jz+LafV5L5qdVNvUzRpzt6ncvtLK9kzYxKyeAQdwAzv99zzZijPKgSDMrM= 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] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jan 2020 14:47:27 -0000 This is a multi-part message in MIME format. --------------72355B2201B776239C0C94AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 03.01.20 um 11:33 schrieb Torsten Lodderstedt: > Hi Brian, > > I’m on the fence regarding your proposal. > > What I like is it moves the focus onto leakage prevention and prevention of injection in the authorization response, which are the direct threats to the front channel flow. Especially token leakage prevention somehow got lost in the process. Indeed, we should check again if leakage prevention is sufficiently emphasized in the BCP. > > Beside this, your proposal does not change the meaning of the spec since sender constrained access tokens are still recommended through 3.2. > > I’m not sure it is worth the change now taking into account how much energy it has cost to come up with a consensus for this piece of text. I would encourage more WG members to share their thoughts. I'm with Annabelle on this: These kinds of exceptions are exactly what the SHOULD NOT is for. -Daniel > > best regards, > Torsten. > >> On 2. Jan 2020, at 22:53, Richard Backman, Annabelle wrote: >> >> Brian and others with similar use cases (Filip?): >> >> The current text does not prohibit your approach, provided you’ve done the due diligence required by BCP 14 to go against a SHOULD NOT. Could you provide more detail on the scenarios where you have opted to use these implicit-based solutions? Is it impractical or infeasible to use an authorization code-based approach in these scenarios? If this is a particularly niche use case, then it may not be worth including in the BCP (that’s basically what SHOULD NOT is for). But if it’s more broadly applicable, then it may be worth tweaking the “unless…” clause of that paragraph. >> >> – >> Annabelle Richard Backman >> AWS Identity >> >> >> From: OAuth on behalf of Mike Jones >> Date: Saturday, December 28, 2019 at 9:47 AM >> To: Brian Campbell , Torsten Lodderstedt >> Cc: oauth >> Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode >> >> I agree with Brian's suggested text changes. >> >> -- Mike >> From: Brian Campbell >> Sent: Saturday, December 28, 2019 5:33:24 AM >> To: Torsten Lodderstedt >> Cc: Mike Jones ; oauth >> Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode >> >> The requirement for replay/injection prevention at resource servers is still there in section 3.2. This change only drops it as a specific qualification on that SHOULD NOT for flows that send access tokens in the authorization response. And instead focuses that qualification on the additional risks that come with sending access tokens in the authorization response. To me, this feels more consistent. >> >> Looking again at section 3, I'd suggest also moving the fourth paragraph of section 3.1.2 into section 3.2 so that the description of sender-constrained is in the subsection that is about sender-constraining. >> >> >> On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt wrote: >>> Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent. >>> >>> >>>> Am 28..12.2019 um 00:02 schrieb Brian Campbell : >>>> >>>> I'm not suggesting that it should be a recommended flow. But recommending against it, as the text does now, seems overreaching and unnecessary. I know *consensus* was previously found on the text in -13 but best I can recall that discussion was mostly around Nat advocating to allow room for some future self-issued IDP type case and the conversation kind of got hung up on that. >>>> >>>> Here's some proposed text, which I think still largely captures the intent of the BCP while not explicitly recommending against legitimate cases like the one I brought here or Nat's or something like JARM. >>>> >>>> In order to avoid these issues, clients SHOULD NOT use the implicit >>>> grant (response type "token") or other response types issuing >>>> access tokens in the authorization response, unless access token injection >>>> in the authorization response is prevented and the aforementioned token leakage >>>> vectors are mitigated. >>>> >>>> The draft already recommends sender-constrained access tokens elsewhere in the document. It doesn't need to be repeated as a qualifying condition around this SHOULD NOT. >>>> >>>> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other thansome suggested tweaks, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations. >>>> >>>> >>>> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt wrote: >>>>> As Brian said, we have discussed this several times and this text found consensus. >>>>> >>>>> Using post reduces the attack surface but does not allow to bind the access token to the legitimate client. We are recommending sender constrained access tokens in the BCP. So recommending a flow that does not support sender constrained access tokens is a contradiction. >>>>> >>>>> What do other WG members think? >>>>> >>>>> >>>>>> Am 27.12.2019 um 21:28 schrieb Mike Jones : >>>>>> >>>>>> I agree with Brian. Please update the text to describe this already safe usage. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> From: OAuth on behalf of Brian Campbell >>>>>> Sent: Friday, December 27, 2019 11:03:30 AM >>>>>> To: oauth >>>>>> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode >>>>>> >>>>>> We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token. >>>>>> >>>>>> That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has: >>>>>> >>>>>> In order to avoid these issues, clients SHOULD NOT use the implicit >>>>>> grant (response type "token") or any other response type issuing >>>>>> access tokens in the authorization response, such as "token id_token" >>>>>> and "code token id_token", unless the issued access tokens are >>>>>> sender-constrained and access token injection in the authorization >>>>>> response is prevented. >>>>>> >>>>>> I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments. >>>>>> >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------72355B2201B776239C0C94AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 03.01.20 um 11:33 schrieb Torsten Lodderstedt:
Hi Brian, 

I’m on the fence regarding your proposal. 

What I like is it moves the focus onto leakage prevention and prevention of injection in the authorization response, which are the direct threats to the front channel flow. Especially token leakage prevention somehow got lost in the process.
Indeed, we should check again if leakage prevention is sufficiently emphasized in the BCP.

Beside this, your proposal does not change the meaning of the spec since sender constrained access tokens are still recommended through 3.2. 

I’m not sure it is worth the change now taking into account how much energy it has cost to come up with a consensus for this piece of text. I would encourage more WG members to share their thoughts.

I'm with Annabelle on this: These kinds of exceptions are exactly what the SHOULD NOT is for.

-Daniel



best regards,
Torsten. 


On 2. Jan 2020, at 22:53, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Brian and others with similar use cases (Filip?):
 
The current text does not prohibit your approach, provided you’ve done the due diligence required by BCP 14 to go against a SHOULD NOT. Could you provide more detail on the scenarios where you have opted to use these implicit-based solutions? Is it impractical or infeasible to use an authorization code-based approach in these scenarios? If this is a particularly niche use case, then it may not be worth including in the BCP (that’s basically what SHOULD NOT is for). But if it’s more broadly applicable, then it may be worth tweaking the “unless…” clause of that paragraph.
 
– 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Date: Saturday, December 28, 2019 at 9:47 AM
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode
 
I agree with Brian's suggested text changes.

-- Mike
From: Brian Campbell <bcampbell@pingidentity.com>
Sent: Saturday, December 28, 2019 5:33:24 AM
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode
 
The requirement for replay/injection prevention at resource servers is still there in section 3.2. This change only drops it as a specific qualification on that SHOULD NOT for flows that send access tokens in the authorization response. And instead focuses that qualification on the additional risks that come with sending access tokens in the authorization response. To me, this feels more consistent. 
 
Looking again at section 3, I'd suggest also moving the fourth paragraph of section 3.1.2 into section 3.2 so that the description of sender-constrained is in the subsection that is about sender-constraining. 
 

On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:

Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent.



Am 28..12.2019 um 00:02 schrieb Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>:

I'm not suggesting that it should be a recommended flow. But recommending against it, as the text does now, seems overreaching and unnecessary. I know *consensus* was previously found on the text in -13 but best I can recall that discussion was mostly around Nat advocating to allow room for some future self-issued IDP type case and the conversation kind of got hung up on that.
 
Here's some proposed text, which I think still largely captures the intent of the BCP while not explicitly recommending against legitimate cases like the one I brought here or Nat's or something like JARM.
 
   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or other response types issuing
   access tokens in the authorization response, unless access token injection
   in the authorization response is prevented and the aforementioned token leakage
   vectors are mitigated. 
 
The draft already recommends sender-constrained access tokens elsewhere in the document. It doesn't need to be repeated as a qualifying condition around this SHOULD NOT.
 
I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other thansome suggested tweaks, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations. 
 
 
On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:

As Brian said, we have discussed this several times and this text found consensus.
 
Using post reduces the attack surface but does not allow to bind the access token to the legitimate client. We are recommending sender constrained access tokens in the BCP. So recommending a flow that does not support sender constrained access tokens is a contradiction.
 
What do other WG members think?



Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>:

I agree with Brian. Please update the text to describe this already safe usage.

-- Mike

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token.
 
That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:
 
   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.
 
I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments.

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

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

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


      

      

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


    

    


    

  


--------------72355B2201B776239C0C94AF--


From nobody Mon Jan  6 11:37: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 AF9651200E7 for ; Mon,  6 Jan 2020 11:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzrZZruqwQvx for ; Mon,  6 Jan 2020 11:37:50 -0800 (PST)
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 E7262120025 for ; Mon,  6 Jan 2020 11:37:49 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id x1so49816243iop.7 for ; Mon, 06 Jan 2020 11:37:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=LiWOWIpryXngcIxG6//3l0l5ISU1S6qAxa4hHSSoQCE=; b=ResJdM7jNRxrM3VtjJskIcKIc7WqdYzUqJoavoEKKxnRXByPpmehMpVf1pMBnptuXk EXkA7KLt1PDz9W7rRNlpksneM+lQxEL5jcepebmiokSnRBATz6GEBBYYwcUWGNomMV89 0JePT+hov4Rec2T2tsc5m9guqac/iocCov53MPh/HUxf6n3LZqKvZNdveL56tTWVLi2X h+Pfs0hWTM80T8keaY9GaUNwqih0O/SaZ4Ltgh+YdVPWtq7q44CNiKiyTJwrxSpdQi38 Ls7grH/B3FuBc8sU9E6KaWhziGzHdxScaLMs7LM/794bUslJCfj80sfMWYGeYskj8rvC sN4Q==
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=LiWOWIpryXngcIxG6//3l0l5ISU1S6qAxa4hHSSoQCE=; b=STYMHbHE009IC9IFXpLMwS1e9y/z3Ke3+BkG/9a/jdMDdyuU/4EwXhx1VZEE04txU5 1ERkwdwR9wslbpCP2iFVhcXIY+FShuJgCSRC3/OSOyLVzb/4AYLt5cKZMIAWE4n5O/26 E13iq3gvQUHtc/JyLRHxhG4HQWOMOPrcYCJhiQ5OOu6nRD6iwXNep2Fh7N22IskclK9I QlsRXd4zVp2h2c0794jK1YkLuYFeG2Va5yw6Jly+u+sDV/RSvT0mlDOOR3IpSMLwddQR yxy32V+48JPJbjQjhJF2TNTvaGaBEWgZ4P0nHFxgzOIpQdJ6TyhzOX4goedZR4RBVR93 hhyg==
X-Gm-Message-State: APjAAAVxOcBm79oklcdSa7bB5g9SSzFlyYq0zDKIBaM22RK5ocOLWORG io9pk9qHpPHWRE68KlSpFHU66Ka7HlHvYUAdAAbxWTvW
X-Google-Smtp-Source: APXvYqzDXCctvTz1DYQI5i4koL3Un/lHWEJtiE7bpWueerlVT+vzrEoqvfh0q3no2u2sXV1K3jgCSOTZkJnYhnlNpUM=
X-Received: by 2002:a02:c90a:: with SMTP id t10mr78990103jao.25.1578339468892;  Mon, 06 Jan 2020 11:37:48 -0800 (PST)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 6 Jan 2020 14:37:37 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000060de3b059b7dcb93"
Archived-At: 
Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 19:37:52 -0000

--00000000000060de3b059b7dcb93
Content-Type: text/plain; charset="UTF-8"

All,

This is a call for adoption for the *OAuth 2.0 Rich Authorization Requests*
document.
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/

Please, let us know if you support or object to the adoption of this
document as a working group document by Jan 20th.

Regards,
 Rifaat & Hannes

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


All,

This is a call for adoption for th=
e=C2=A0OAuth 2.0 Rich Authorization Requests document.
=C2=A0
Please, let us know if you support or=
 object to the adoption of this document as a working group document by Jan=
 20th.

Regards,
=C2=A0Rifaat &am=
p; Hannes



--00000000000060de3b059b7dcb93--


From nobody Mon Jan  6 11:46: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 83EB71200D7 for ; Mon,  6 Jan 2020 11:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 2EXlMJxfXOa2 for ; Mon,  6 Jan 2020 11:46:18 -0800 (PST)
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 3F511120025 for ; Mon,  6 Jan 2020 11:46:18 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id t8so43575920iln.4 for ; Mon, 06 Jan 2020 11:46:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z6vqmkOxzOf32u312ITcpWFNjuYLWyTL4NzpL9rNTYA=; b=LL4XDi3cL2FKKzMpPAaPm3pWYy1E5koNm6I3Y79Oi11BCvkHQzlWvMw21WQZLV3E4x ZaBUq1iq1KIzhanfVo50Xck9qhmA12cARIO9pHniaBIGQmdjcoi+LOUJCk4c/6bSO3iS /PidlH6j/pq1ag8rd1XB1Pb878BK1rHLENrvcruppU8EK5iqHFIbIC2NNpIxqR6hfahu sE+QAvlfXGUN+pI3xs7fD7P38hAFDAvWKW47Q/b9Y8/qDu9aDnRt0LzWrdSAphmfYds8 xroQi2x/hmukJr0aVOpf7IoaDbfIEtUodP/RdEaQ9Tj73oV+YxG8F6VSjVeFdejfJMuH Hdhg==
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=Z6vqmkOxzOf32u312ITcpWFNjuYLWyTL4NzpL9rNTYA=; b=CX3JZh0UTj1iYdhtmeyK3jqqHW417PypPm5ZITpaLEIP5aVKCT1QRcqVp/Idn3c6SQ /NtGqThtYlzZigt+il6TJ0SLPnjX8r15kWqH30IBHgPrsbNZCKkXU/p9R0GpB3yd4pGS cGXVjXUUacTlSvWkNBvsABJs6XxSC7m8e9vxW4+Uegrmkq/BKy1o18AgjEZ/x9SLLbdC nz7YbOGO9q4YCUZF2Yjewf2JdH2aqPPi/b+EYPLlzDTNwaHiY7TF4Fto/wLK8WWGvQUf NWcDJ8Oj/5lTzK55rewA9jXdKn6ey4DFA4wcnXGWepUxq13p95nbwvRLadGk/lUEX9W6 IbSA==
X-Gm-Message-State: APjAAAVqzcTWknRhT2EzOd73NK6bvQwisYwbgjsqj698cFcmxxxsKM0H 95xiB7n00nD9fV2fQpYaAN1GHzhSv1I=
X-Google-Smtp-Source: APXvYqwYo9K/pFQ/GLdmhpGD0aGZrAMKS6TaKt4+Jw/GPm25GNdLBtYw8pdvbaw7T1sK3lBWCQGXgw==
X-Received: by 2002:a92:4818:: with SMTP id v24mr79883120ila.96.1578339977450;  Mon, 06 Jan 2020 11:46:17 -0800 (PST)
Received: from mail-il1-f172.google.com (mail-il1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id e7sm17349618iot.71.2020.01.06.11.46.16 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 11:46:16 -0800 (PST)
Received: by mail-il1-f172.google.com with SMTP id v15so43596031iln.0 for ; Mon, 06 Jan 2020 11:46:16 -0800 (PST)
X-Received: by 2002:a92:d18a:: with SMTP id z10mr90592892ilz.48.1578339976737;  Mon, 06 Jan 2020 11:46:16 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Mon, 6 Jan 2020 11:46:05 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 19:46:21 -0000

I support the adoption of this document.

----
Aaron Parecki
aaronparecki.com


On Mon, Jan 6, 2020 at 11:38 AM Rifaat Shekh-Yusef
 wrote:
>
> All,
>
> This is a call for adoption for the OAuth 2.0 Rich Authorization Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Jan  6 11:51: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 A80861200D7 for ; Mon,  6 Jan 2020 11:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8VvETwcNw1Z for ; Mon,  6 Jan 2020 11:51:47 -0800 (PST)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3D6120025 for ; Mon,  6 Jan 2020 11:51:47 -0800 (PST)
Received: by mail-yb1-xb32.google.com with SMTP id n66so22587046ybg.0 for ; Mon, 06 Jan 2020 11:51:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=tXIbjs51MmPhX86maxLh6AwqaRlipUE4zgKjpT48rdg=; b=k4rx54XQIB2qqP1toKliEjy2U34Ef2rhorPMbAO9a6S7bhXqiyIEYS8L+0EB46Oyvp Pbl2p1bobF8+jlSES2vulEIwZoB1SiqdjubMRc0x3hLNDl3rwyQ2PFHNppRlY6DGsQaj xlbbThg4/iZiwf9PmKVYfDNI9dGESz8S/BVy1JUOfkfLkB9A5/6yV8GtRjo75Vcyn8vi G48dh3VDYIAbnGV0YKJolDg44nBMIqIK2kMLc+vbsZFLZdUE9ujoK3paogNr9Cfv5O7e X2+rKQHy4HwbPJuN3615gtqp0+tkNo3/aaWVQVHf5QrkozuOb0h4Ct4zV/vH9u0f8pT4 617A==
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=tXIbjs51MmPhX86maxLh6AwqaRlipUE4zgKjpT48rdg=; b=Ewfb5snh9pRUyx9LCgzM6IR+gQ2MRlQUAOL/vuYiON2Peu6SgzbnVU+LR4gqUuHrKI ruAwDIYmRdfEImTYYJUIXq2eRUvnny3Y/rOkkcnIhbgXbpuPU8Kv5W27PTp16o1Do5hi +iex6ncHb4NhJX0rplhk6kZStLuIrl3TT85kbXjxOHOxba7cqm/QyMSEziYBGhG+A5FP eKI7FSWpu/d4YZPJOee4DHMQW4PiYBfgc6hEl+0cxzBY2seDZo7t6zoHFUl5sUE4DYPd 6JqoNDcyhetui746Zf3oXK79RjKnf5ddqkiCy6QXEfsUKjbxb5lt72R6vyFz1V56yd0q udTw==
X-Gm-Message-State: APjAAAVdXwFT56JJO2D5R3P3sud9rN2xBuMI+5JlOHI0alhFWKwVuK6m YDpzrb9xHNJTNBWkc2mYYLdPQWwFmVOodXE9fACJMEg=
X-Google-Smtp-Source: APXvYqyfj5o0SrL4q97DmKqL/OQN1tBjOzaZXv4P8IRLkTgeoUZGNue6kAGS/+8vfiD8CAmkLnBEDbWqL59jkFUz1Cw=
X-Received: by 2002:a25:dcc3:: with SMTP id y186mr66568653ybe.351.1578340306304;  Mon, 06 Jan 2020 11:51:46 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Filip Skokan 
Date: Mon, 6 Jan 2020 20:51:35 +0100
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000004ac461059b7dfd5b"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 19:51:49 -0000

--0000000000004ac461059b7dfd5b
Content-Type: text/plain; charset="UTF-8"

I support the WG adoption of RAR.

Best,
*Filip*


On Mon, 6 Jan 2020 at 20:38, Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I support the WG adoption of RAR.

Best,
Filip


On Mon, 6 Jan 2020 at 20:3=
8, Rifaat Shekh-Yusef <rifaat.i=
etf@gmail.com> wrote:
All,

This is a call for ad=
option for the=C2=A0OAuth 2.0 Rich Authorization Requests document.<=
/div>
=C2=A0
Please, let us know if y=
ou support or object to the adoption of this document as a working group do=
cument by Jan 20th.

Regards,
=C2=
=A0Rifaat & Hannes


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000004ac461059b7dfd5b--


From nobody Mon Jan  6 12:04: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 5981B1200CE for ; Mon,  6 Jan 2020 12:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IEXjNktMeTv for ; Mon,  6 Jan 2020 12:03:57 -0800 (PST)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA47120086 for ; Mon,  6 Jan 2020 12:03:57 -0800 (PST)
Received: by mail-qv1-xf30.google.com with SMTP id t6so19584616qvs.5 for ; Mon, 06 Jan 2020 12:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=aV9EERvExjy8hLu8GNLi5+3GLtITbm5fKmAWxDNYT+E=; b=ObscSQl9i/eyqyQ47nDJdgXkxjR4+i4rxHo/EL6BYdLAlqM6mi5E8e03PaJjEpqpZx ym4rfsxWX2BuPK7nGyXM7orQyXBndnQIF+CuFLdAo06HSI/oztgYiMfClg3Hy2RY1kje xhh5R+NGlE8Me1WGr7+GUWbmmKXcbjtTYYKTLMPHVjjvLi/3xU3pWfpEuNKUtJ+bD8iM YU3wouWRWlmGVnnH1QkDoGQ+Q9P2kHpWLm3oJlncDKvcpiWZErj+a7TCYiWJ3btSWPg/ Q17uVZYnSTHaemdOHAxkwKDua+SvwM8KoJbM/fiWen+jCgXa5hiLcHhAabCgB9rY0XtJ dXNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=aV9EERvExjy8hLu8GNLi5+3GLtITbm5fKmAWxDNYT+E=; b=LaIhv/d+fX+nSGyeob8dSmF5RpNW2OQ5iyd/mOyg9i40lGIdb19ERLgNNR2BjbDiyE 4KpQ5opGkanQecfYXrqysaSCFcBb+1XLP05erUksXnQgsSplk+xqXcOrdaiRhThCCiWO FmtYlbxzZL3Id5JMQwbbTprrFd2cEJSaZQ2J9cqP3DHB1i1dhGk5xrGp3eaX/9xo+twM XDQB7bSL0X0RGpVgLHPfo3DOVoe2X64HDEc/1W0oQIx44xc5hRdTcqnttFLr0cyYfUjw Fx+mOh+3FBzKHjzJGybaQK9v+PFMVJdLoDD9PMdNNQKRLbJbTtiXMruredTeEmKIB0QY dpyQ==
X-Gm-Message-State: APjAAAWMhj1pgOsrFvawD/xP0rmk0Zf3VX8/dtBrap46+WzI0bqLtOLl 1Xn+qXKg00rvDH70fNLcqqDB8V2PdlBhwaEi
X-Google-Smtp-Source: APXvYqw5tsBYg8vR35H8LPVmI/yvIz+kK35JraVZeGenQKnIOni0m5FkjNKsyDovDDepjztkawoL+Q==
X-Received: by 2002:ad4:56a7:: with SMTP id bd7mr82387022qvb.238.1578341035877;  Mon, 06 Jan 2020 12:03:55 -0800 (PST)
Received: from [192.168.8.103] ([181.203.103.238]) by smtp.gmail.com with ESMTPSA id 124sm13297122qko.11.2020.01.06.12.03.54 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 12:03:54 -0800 (PST)
To: oauth@ietf.org
References: 
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com>
Date: Mon, 6 Jan 2020 17:03:52 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------466CAA83B822388E255169B1"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 20:03:59 -0000

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

I support adoption

On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:
> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 
>  
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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


  
    
  
  
    
I support adoption

    

    
On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef
      wrote:

    

    

      
      
All,
        


        

        
This is a call for adoption for the OAuth 2.0 Rich
            Authorization Requests document.

        
        
 

        
Please, let us know if you support or object to the
          adoption of this document as a working group document by Jan
          20th.

        

        


        

        
Regards,

        

        
 Rifaat & Hannes

        


        

      

      

      

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


    

  


--------------466CAA83B822388E255169B1--


From nobody Mon Jan  6 12:32:33 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 E0821120118 for ; Mon,  6 Jan 2020 12:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.799
X-Spam-Level: 
X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeuTNAZjW3BJ for ; Mon,  6 Jan 2020 12:32:29 -0800 (PST)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5CA120108 for ; Mon,  6 Jan 2020 12:32:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578342750; x=1609878750; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rrBDMe5W6WU1R7R2W7NaXKs1pyU5bJl+4gRO9Y8lfkI=; b=lsHksOxn3GtuQY3sMnoZWKQTOtrbWn0cmW/lRk64hwTU8LQdbz79fwEc uGPy6adR1y/Y3McfhNM8pbH/lfTySM86gJO5FZEsP40npGqv/bF9pomVu 52+MZT7/hCOgl6r3UyRpballn1GE/VmXPzahImKsGDCiOzUUxprDObVYy g=;
IronPort-SDR: bUEC8z3/kjkjHPwtz2JL7b59Z1cJxAxg9jDzlkSjkO5KgAl+E+gRmEPk3SWCp1lHPPLx6qebTT 5slEPlp6CaDA==
X-IronPort-AV: E=Sophos; i="5.69,403,1571702400"; d="scan'208,217"; a="18455120"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 06 Jan 2020 20:32:18 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (Postfix) with ESMTPS id DF408A21D2; Mon,  6 Jan 2020 20:32:17 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 6 Jan 2020 20:32:17 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 6 Jan 2020 20:32:17 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 6 Jan 2020 20:32:17 +0000
From: "Richard Backman, Annabelle" 
To: John Bradley , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
Thread-Index: AQHVxMj0Y/88besluUKmKt6PZfPUBKfeD0MA//+B0wA=
Date: Mon, 6 Jan 2020 20:32:17 +0000
Message-ID: 
References:  <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com>
In-Reply-To: <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.115]
Content-Type: multipart/alternative; boundary="_000_FF434BCCAC094F2A96D1D43D20A3BAC4amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 20:32:31 -0000

--_000_FF434BCCAC094F2A96D1D43D20A3BAC4amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFX
UyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBi
ZWhhbGYgb2YgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4NCkRhdGU6IE1vbmRheSwg
SmFudWFyeSA2LCAyMDIwIGF0IDEyOjA1IFBNDQpUbzogIm9hdXRoQGlldGYub3JnIiA8b2F1dGhA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBBZG9wdGlvbjogT0F1
dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0cw0KDQoNCkkgc3VwcG9ydCBhZG9wdGlv
bg0KT24gMS82LzIwMjAgNDozNyBQTSwgUmlmYWF0IFNoZWtoLVl1c2VmIHdyb3RlOg0KQWxsLA0K
DQpUaGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24gZm9yIHRoZSBPQXV0aCAyLjAgUmljaCBBdXRo
b3JpemF0aW9uIFJlcXVlc3RzIGRvY3VtZW50Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLw0KDQpQbGVhc2UsIGxldCB1cyBrbm93
IGlmIHlvdSBzdXBwb3J0IG9yIG9iamVjdCB0byB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu
dCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYnkgSmFuIDIwdGguDQoNClJlZ2FyZHMsDQog
UmlmYWF0ICYgSGFubmVzDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCg==

--_000_FF434BCCAC094F2A96D1D43D20A3BAC4amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy
IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv
bnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCBh
ZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hh
cmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29t
Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgNiwgMjAyMCBhdCAxMjowNSBQ
TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGll
dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBDYWxsIGZvciBB
ZG9wdGlvbjogT0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0czxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5JIHN1cHBvcnQgYWRvcHRpb248bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzYvMjAyMCA0OjM3IFBNLCBSaWZh
YXQgU2hla2gtWXVzZWYgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24gZm9yIHRoZSZuYnNwOzxi
Pk9BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRpb24gUmVxdWVzdHM8L2I+IGRvY3VtZW50LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgt
cmFyLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci88L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSwgbGV0IHVzIGtub3cgaWYg
eW91IHN1cHBvcnQgb3Igb2JqZWN0IHRvIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFz
IGEgd29ya2luZyBncm91cCBkb2N1bWVudCBieSBKYW4gMjB0aC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdCAmYW1w
OyBIYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9B
dXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_FF434BCCAC094F2A96D1D43D20A3BAC4amazoncom_--


From nobody Mon Jan  6 12:36: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 28465120118 for ; Mon,  6 Jan 2020 12:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbxG0LueCYif for ; Mon,  6 Jan 2020 12:36:04 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2B41200CE for ; Mon,  6 Jan 2020 12:36:04 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id h23so52316140ljc.8 for ; Mon, 06 Jan 2020 12:36:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lJ2P5XRLvPSu5urT4rNRvAYF7so9E/Vg9syov30Mc9I=; b=uLYvr10EigTkSoZy9Lu2NH2WXPIlVQ9ikXEEgbSrnoEAxpUNiuYWDtnEDfuU5TOj81 FHgpS4btKyznyjaO7XSSuDRCygr0qYn+c6BE9ZNrW9UWzE7IRYAUBbxEiZk4k7l9Z6dZ vRrd67LbXqsLXi1qvxhnUKHW9hbi7A8bQaVkmxshQseBx2oqNYvfIcE6UWE+SMVWx/41 dhGK/GIsPACjX2vgEHTY/Yy+lPfhgk6Km/3nFreMEK864L+lLeGlRXr/vDnuak+oi8oL ItSvte3lDgVErdX6BEa3799/TqcM0wlm83MjDVu6wUW/2ygIM12Sq0+azshU6zyFbxSf EXKQ==
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=lJ2P5XRLvPSu5urT4rNRvAYF7so9E/Vg9syov30Mc9I=; b=Gjk2YzPQ3wcCU3QU7cSsqd0wTAqv3WrHpTNYb6XKSpOKXvFxSkxrLrzfdDJL191ctQ tyUhBnwQizCDtYhUB1JEezzdod76p6XyEZ8kmaD76QsIZj0Gedjr6agNg6JfWpITZABS B+OzP83laOR2Hylv5Av8Bzp0wwmXRYBDtIySLHO6vV1WxbuiBO4tXLOpfPrFhfwVDPMU i7tSNMvdqAw8NfLHP6K9iILXuwLZCEmQ5waQCBc7S2UHK1BryzstiL+6X1zBrcItZmHF kO6slsjwg2QlUAK4qvjmlnlnOsxuuayE+66TNojx8F49OzlpoVyMr53YKwVpDSgBZGFr tCYA==
X-Gm-Message-State: APjAAAUh30iWsVDb69NllT2x7Yp9HK5y1PTSZuGXeyA4wZXhkPTZ+UGX oUwuvb1pHBVCrbxl4mB8WVgjMz0YZnyYQnlaNA7xn/GZ
X-Google-Smtp-Source: APXvYqxmFdaPuXzlU4iV27AB4n6r2vCt0Ut5uhpY8T1/AD+pQ+74jxfsmA//tdrhXv8MArog4N37hzL2qGEMy9VG+5c=
X-Received: by 2002:a2e:a486:: with SMTP id h6mr49047506lji.235.1578342962157;  Mon, 06 Jan 2020 12:36:02 -0800 (PST)
MIME-Version: 1.0
References:  <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com> 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jan 2020 12:35:50 -0800
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: John Bradley , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000097dc67059b7e9bf7"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 20:36:06 -0000

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

I support adoption
=E1=90=A7

On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle  wrote:

> I support adoption.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of John Bradley <
> ve7jtb@ve7jtb.com>
> *Date: *Monday, January 6, 2020 at 12:05 PM
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization
> Requests
>
>
>
> I support adoption
>
> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:
>
> All,
>
>
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
>
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
>
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
>
>
> 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
>

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


I support adoption
3D""=E1=90=A7
On Mon, J=
an 6, 2020 at 12:32 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wr=
ote:











I support adoption.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of John Bradley <ve7jtb@ve7jtb.com>

Date: Monday, January 6, 2020 at 12:05 PM

To: "oauth@=
ietf.org" <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorizat=
ion Requests






=C2=A0




I support adoption




On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:








All, 




=C2=A0






This is a call for adoption for the=C2=A0OAuth 2.=
0 Rich Authorization Requests document.







=C2=A0






Please, let us know if you support or object to the =
adoption of this document as a working group document by Jan 20th.






=C2=A0






Regards,






=C2=A0Rifaat & Hannes






=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




--00000000000097dc67059b7e9bf7--


From nobody Mon Jan  6 13:59: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 86F6812007A for ; Mon,  6 Jan 2020 13:59:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUaq6qUYQTzB for ; Mon,  6 Jan 2020 13:59:50 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4C0120033 for ; Mon,  6 Jan 2020 13:59:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578347990; x=1609883990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+piuaOATSEXQx7OzfBJJSnqcJGTRDxMy2BXM1im2CcE=; b=hVBtvvL9Xl9jnOnhwBawK/MBT54fLDlGLTC1SVZQ/a3K6suiHLSHsyMU kiMAXKZxjjhszBcKdWhdoHfeltq5CGWQkByoq2zDltMqihm1kZaXEXNca Ew7T8/8t9/b4QmJYrVnrSCwTPCDwwrddgLopm/Jl84i9mRWAP1a6N9jnE g=;
IronPort-SDR: 6WiaqHS0UfmiFtcCgjJqrL/AoS8gA0ES+ADOF2G9GUWFEQLgxQWT8D0KCgF2udf67cPNrb39hG /5mAirrMZpPw==
X-IronPort-AV: E=Sophos; i="5.69,403,1571702400"; d="scan'208,217"; a="11235575"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 06 Jan 2020 21:59:48 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com (Postfix) with ESMTPS id D3DD2A2226; Mon,  6 Jan 2020 21:59:46 +0000 (UTC)
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 6 Jan 2020 21:59:46 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 6 Jan 2020 21:59:45 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 6 Jan 2020 21:59:45 +0000
From: "Richard Backman, Annabelle" 
To: Neil Madden , Brian Campbell 
CC: Nat Sakimura , Dave Tonge , Torsten Lodderstedt , oauth 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
Thread-Index: AQHVv+g7xiAB+Bj4Q0q9tvboHgAv9qfUXGKAgAAMNwCABI8uAIAEutmAgAAIpoD///gDgA==
Date: Mon, 6 Jan 2020 21:59:45 +0000
Message-ID: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com>
In-Reply-To: <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.214]
Content-Type: multipart/alternative; boundary="_000_38C69B8C905F46F188BB016CF7DE2952amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re:  PAR 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: Mon, 06 Jan 2020 21:59:54 -0000

--_000_38C69B8C905F46F188BB016CF7DE2952amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGlzc3VlIGlzbuKAmXQgdGhhdCB0aGUgUEFSIGVuZHBvaW50IG5lZWRzIGFjY2VzcyB0byBv
bmUgc3BlY2lmaWMgcmVxdWVzdCBvYmplY3QgZGVjcnlwdGlvbiBrZXkgdGhhdCBjb3VsZCByZWFz
b25hYmx5IGJlIHNoYXJlZCBhY3Jvc3MgQVMgZW5kcG9pbnRzLCBidXQgdGhhdCBpdCBhY3R1YWxs
eSBuZWVkcyBhY2Nlc3MgdG8gdGhlIHByaXZhdGUga2V5cyBmb3IgYWxsIGVuY3J5cHRpb24gcHVi
bGljIGtleXMgaW4gdGhlIEpXSyBzZXQgcG9pbnRlZCB0byBieSB0aGUgQVPigJlzIGp3a3NfdXJp
IG1ldGFkYXRhIHByb3BlcnR5LiBTaW5jZSB0aGVyZSBpcyBubyB3YXkgdG8gZGVzaWduYXRlIG9u
ZSBwYXJ0aWN1bGFyIGtleSBhcyB0aGUgb25lIHRvIHVzZSBmb3IgZW5jcnlwdGluZyByZXF1ZXN0
IG9iamVjdHMsIGNsaWVudHMgbWF5IHJlYXNvbmFibHkgdXNlIGFueSBlbmNyeXB0aW9uIHB1Ymxp
YyBrZXkgaW4gdGhlIEpXSyBzZXQgdG8gZW5jcnlwdCBhIHJlcXVlc3Qgb2JqZWN0LiBBcyBvbmUg
ZXhhbXBsZSBvZiBob3cgdGhpcyBjb3VsZCBleHBvc2Ugc2Vuc2l0aXZlIGRhdGEgdG8gdGhlIFBB
UiBlbmRwb2ludCwgaWYgdGhlIFBBUiBlbmRwb2ludCBoYXMgYWxsIHRoZSBkZWNyeXB0aW9uIGtl
eXMgZm9yIHRoZSBrZXlzIGluIHRoZSBBU+KAmXMgSldLIHNldCwgaXQgd291bGQgYmUgYWJsZSB0
byBkZWNyeXB0IElEIFRva2VucyBzZW50IGluIGlkX3Rva2VuX2hpbnQgcmVxdWVzdCBwYXJhbWV0
ZXJzLiBBcyBtb3JlIGFuZCBtb3JlIHVzZSBjYXNlcyBkZXZlbG9wIGZvciBlbmNyeXB0aW5nIGJs
b2JzIGZvciB0aGUgQVMsIHRoaXMgaXNzdWUgd2lsbCBvbmx5IGdldCB3b3JzZS4NCg0KVGhlIFBB
UiBlbmRwb2ludCBjYW7igJl0IHNpbXBseSBzdGFzaCB0aGUgZW5jcnlwdGVkIHJlcXVlc3Qgb2Jq
ZWN0LCBhcyBpdCBpcyByZXF1aXJlZCB0byB2ZXJpZnkgdGhlIHJlcXVlc3QsIGFjY29yZGluZyB0
byDCpzIuMToNCg0KDQpUaGUgQVMgTVVTVCBwcm9jZXNzIHRoZSByZXF1ZXN0IGFzIGZvbGxvd3M6
DQoNCg0KDQouLi4NCg0KDQoNCjMuICBUaGUgQVMgTVVTVCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBp
biB0aGUgc2FtZSB3YXkgYXMgYXQgdGhlDQoNCiAgICAgICAgICBhdXRob3JpemF0aW9uIGVuZHBv
aW50LiAuLi4NCg0KDQpUaGlzIGxhbmd1YWdlIG5lZWRzIHRvIGJlIG1vcmUgZmxleGlibGUsIElN
SE8sIHRvIGFsbG93IGZvciBsaWdodHdlaWdodCBQQVIgZW5kcG9pbnRzIHRoYXQgbWF5IG5vdCBo
YXZlIHRoZSBpbmZvcm1hdGlvbiBvciBhdXRob3JpdHkgbmVlZGVkIHRvIHBlcmZvcm0gYWxsIHRo
ZSB2YWxpZGF0aW9uIHRoYXQgaGFwcGVucyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4g
SSBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgbW9yZSBiZWZvcmUgSSBjYW4gc2F5IGlmIGl0IHdv
dWxkIGFkZXF1YXRlbHkgYWRkcmVzcyBteSBjb25jZXJucywgYnV0IGl04oCZZCBiZSBhIGdvb2Qg
c3RhcnQgYW5kIG1ha2VzIHNlbnNlIGluIGl0cyBvd24gcmlnaHQuDQoNCkkgdGhpbmsgaXTigJlz
IHByZXR0eSByaXNreSBmb3IgdXMgdG8gYmFzZSBkZWNpc2lvbiBvbiBhbiBhc3N1bXB0aW9uIHRo
YXQgbm8gb25lIGlzIGdvaW5nIHRvIG5lZWQgb3Igd2FudCB0byBlbmNyeXB0IHB1c2hlZCByZXF1
ZXN0IG9iamVjdHMsIHBhcnRpY3VsYXJseSB3aGVuIHRoZXnigJlyZSBKV1RzLCBhbmQgSldUcyBo
YXZlIHdlbGwgZXN0YWJsaXNoZWQgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiwgYW5kIGVuY3J5cHRl
ZCBKV1RzIGFyZSBzdXBwb3J0ZWQgYnkgcGFzcy1ieS12YWx1ZSBpbiBPSURDIGFuZCBkcmFmdC1p
ZXRmLW9hdXRoLWp3c3JlcS4gQnV0IGlmIHlvdSBpbnNpc3QsIGhlcmUgYXJlIGEgZmV3IGV4YW1w
bGVzIGZvciB3aHkgc29tZW9uZSBtaWdodCB3YW50IHRvIGRvIHRoaXM6DQoNCiAgMS4gIFRoZSBy
ZXF1ZXN0IG9iamVjdCBpcyBwYXNzZWQgYnkgcmVmZXJlbmNlLCBhbmQgYWNjZXNzaWJsZSBvbiB0
aGUgcHVibGljIEludGVybmV0Lg0KICAyLiAgVGhlIHJlcXVlc3Qgb2JqZWN0IGNvbnRhaW5zIHNl
bnNpdGl2ZSB0cmFuc2FjdGlvbi1yZWxhdGVkIGRhdGEgaW4gUkFSIHBhcmFtZXRlcnMgdGhhdCB0
aGUgY2xpZW504oCZcyBhdXRoTi9hdXRoWiBzdGFjayBkb2VzbuKAmXQgbmVlZCB0byBoYXZlIGFj
Y2VzcyB0by4NCiAgMy4gIFRoZSBBUyByZXF1aXJlcyByZXF1ZXN0IG9iamVjdCBlbmNyeXB0aW9u
IHRvIG1pbmltaXplIGV4cG9zdXJlIHRvIHRoZSBob3N0ZWQgUEFSIGVuZHBvaW50IHNlcnZpY2Ug
aXQgdXNlcy4NCiAgNC4gICMyLCBidXQgdGhlIHRocmVhdCB2ZWN0b3IgaXMgZ2FwcyBpbiBlbmQt
dG8tZW5kIFRMUy4NCiAgNS4gIEFueSBvZiB0aGUgYWJvdmUsIGJ1dCB0aGUgY29uY2VybiBpcyBt
ZXNzYWdlIGludGVncml0eSwgYW5kIHRoZSBBUyByZXF1aXJlcyByZXF1ZXN0ZWQgb2JqZWN0cyB0
byBiZSBlbmNyeXB0ZWQgZm9yIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rp
b24gYW5kIGRvZXMgbm90IHN1cHBvcnQgc2lnbmVkIHJlcXVlc3Qgb2JqZWN0cy4NCg0K4oCTDQpB
bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBOZWlsIE1h
ZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSA2
LCAyMDIwIGF0IDY6MjkgQU0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVu
dGl0eS5jb20+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1h
em9uLmNvbT4sIE5hdCBTYWtpbXVyYSA8bmF0QHNha2ltdXJhLm9yZz4sIERhdmUgVG9uZ2UgPGRh
dmUudG9uZ2VAbW9uZXlodWIuY29tPiwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2Rk
ZXJzdGVkdC5uZXQ+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVU5WRVJJRklF
RCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIFBBUiBtZXRhZGF0YQ0KDQpBZ3JlZWQuDQoNCkluIGFk
ZGl0aW9uLCBJJ20gbm90IHN1cmUgd2h5IHRoZSBQQVIgZW5kcG9pbnQgd291bGQgbmVlZCBhY2Nl
c3MgdG8gdGhlIGRlY3J5cHRpb24ga2V5cyBhdCBhbGwuIElmIHlvdSdyZSB1c2luZyBlbmNyeXB0
ZWQgcmVxdWVzdCBvYmplY3RzIHRoZW4gdGhlIFBBUiBlbmRwb2ludCByZWNlaXZlcyBhbiBlbmNy
eXB0ZWQgSldUIGFuZCB0aGVuIGxhdGVyIG1ha2VzIHRoZSBzYW1lIChzdGlsbCBlbmNyeXB0ZWQp
IEpXVCBhdmFpbGFibGUgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIElmIHRoZSBQQVIg
ZW5kcG9pbnQgaXMgZG9pbmcgYW55IGtpbmQgb2YgZGVjcnlwdGlvbiBvciB2YWxpZGF0aW9uIG9u
IGJlaGFsZiBvZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0aGVuIHRoZXkgYXJlIGNsZWFy
bHkgbm90IGluIHNlcGFyYXRlIHRydXN0IGJvdW5kYXJpZXMuDQoNCi0tIE5laWwNCg0KDQoNCk9u
IDYgSmFuIDIwMjAsIGF0IDEzOjU3LCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lk
ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5
LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJIHJlYWxseSBzdHJ1Z2dsZSB0byBzZWUg
dGhlIGFzc3VtcHRpb24gdGhhdCBhbiBlbnRpdHkgYmUgYWJsZSB0byB1c2UgdGhlIHNhbWUga2V5
IHRvIGRlY3J5cHQgdGhlIHNhbWUgdHlwZSBvZiBtZXNzYWdlIHVsdGltYXRlbHkgaW50ZW5kZWQg
Zm9yIHRoZSBzYW1lIHB1cnBvc2UgYXMgYW4gYXJ0aWZpY2lhbCBsaW1pdC4gVGhlIHNhbWUgZ2Vu
ZXJhbCBhc3N1bXB0aW9uICAgdW5kZXJsaWVzIGV2ZXJ5dGhpbmcgZWxzZSBpbiBPQXV0aC9PSURD
IChWbGFkaW1pcidzIHBvc3QgcG9pbnRzIHRvIHNvbWUgYnV0IG5vdCBhbGwgZXhhbXBsZXMgb2Yg
c3VjaCkuIFRoZXJlJ3Mgbm8gcmVhc29uIGZvciBQQVIgdG8gbWFrZSBhIG9uZS1vZmYgZXhjZXB0
aW9uLiBBbmQgc2hvdWxkIHRoZXJlIGJlIHNvbWUgZGVwbG95bWVudCBzcGVjaWZpYyByZWFzb24g
dGhhdCB0cnVseSByZXF1aXJlcyB0aGF0IGtpbmQgb2YgaXNvbGF0aW9uLCB0aGVyZSBhcmUgY2Vy
dGFpbmx5IGltcGxlbWVudGF0aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgY29tcGF0aWJpbGl0eS1i
cmVha2luZy4gQW5kIGhhdmluZyBzYWlkIGFsbCB0aGF0LCBJJ20gaG9uZXN0bHkgYSBsaXR0bGUg
c3VycHJpc2VkIGFueW9uZSBpcyB0aGlua2luZyBtdWNoIGFib3V0IGVuY3J5cHRlZCByZXF1ZXN0
IG9iamVjdHMgd2l0aCBQQVIgYXMsIGF0IGxlYXN0IHdpdGggbXkgbGltaXRlZCBpbWFnaW5hdGlv
biwgdGhlcmUncyBub3QgcmVhbGx5IGEgbmVlZCBmb3IgaXQuDQoNCg0KDQoNCg0KDQoNCg0KT24g
RnJpLCBKYW4gMywgMjAyMCBhdCAyOjQzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxy
aWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBk
bWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KUEFSIGludHJvZHVjZXMgYW4gYWRkZWQgd3JpbmtsZSBm
b3IgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0czogdGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9y
aXphdGlvbiBlbmRwb2ludCBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBzYW1lIGNyeXB0b2dy
YXBoaWMga2V5cywgZXZlbiB0aG91Z2ggdGhleSdyZSBib3RoIHBhcnQgb2YgdGhlICJhdXRob3Jp
emF0aW9uIHNlcnZlci4iIFNpbmNlIHRoZXkncmUgZGlmZmVyZW50IGVuZHBvaW50cyB3aXRoIGRp
ZmZlcmVudCByb2xlcywgaXQncyByZWFzb25hYmxlIHRvIHB1dCB0aGVtIGluIHNlcGFyYXRlIHRy
dXN0IGJvdW5kYXJpZXMuIFRoZXJlIGlzIG5vIHdheSB0byBzdXBwb3J0IHRoaXMgaXNvbGF0aW9u
IHdpdGgganVzdCBhIHNpbmdsZSAiandrc191cmkiIG1ldGFkYXRhIHByb3BlcnR5Lg0KDQpUaGUg
dHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6DQoNCjEuIERlZmluZSBhIG5ldyBwYXJfandrc191
cmkgbWV0YWRhdGEgcHJvcGVydHkuDQoyLiBFeHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhpcyBzZXBh
cmF0aW9uIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCkkgc3Ryb25nbHkgcGVyZmVyICMxIGFzIGl0IGhh
cyBhIHZlcnkgbWlub3IgaW1wYWN0IG9uIGRlcGxveW1lbnRzIHRoYXQgZG9uJ3QgY2FyZSAoaS5l
LiwgdGhleSBqdXN0IHNldCBwYXJfandrc191cmkgYW5kIGp3a3NfdXJpIHRvIHRoZSBzYW1lIHZh
bHVlKSBhbmQgZmFpbGluZyB0byBzdXBwb3J0IHRoaXMgdHJ1c3QgYm91bmRhcnkgY3JlYXRlcyBh
biBhcnRpZmljaWFsIGxpbWl0IG9uIGltcGxlbWVudGF0aW9uIGFyY2hpdGVjdHVyZSBhbmQgY291
bGQgbGVhZCB0byBjb21wYXRpYmlsaXR5LWJyZWFraW5nIHdvcmthcm91bmRzLg0KDQrigJMNCkFu
bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCk9uIDEyLzMxLzE5LCA4
OjA3IEFNLCAiT0F1dGggb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQiIDxvYXV0aC1i
b3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2YgdG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2Rk
ZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KICAgIEhpIEZpbGlwLA0KDQog
ICAgPiBPbiAzMS4gRGVjIDIwMTksIGF0IDE2OjIyLCBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdt
YWlsLmNvbTxtYWlsdG86cGFudmEuaXBAZ21haWwuY29tPj4gd3JvdGU6DQogICAgPg0KICAgID4g
SSBkb24ndCB0aGluayB3ZSBuZWVkIGEgKl9hdXRoX21ldGhvZF8qIG1ldGFkYXRhIGZvciBldmVy
eSBlbmRwb2ludCB0aGUgY2xpZW50IGNhbGxzIGRpcmVjdGx5LCBub25lIG9mIHRoZSBuZXcgc3Bl
Y3MgZGVmaW5lZCB0aGVzZSAoZS5nLiBkZXZpY2UgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciBD
SUJBKSwgbWVhbmluZyB0aGV5IGFsc28gZGlkbid0IGZvbGxvdyB0aGUgc2NoZW1lIGZyb20gUkZD
IDg0MTQgd2hlcmUgaW50cm9zcGVjdGlvbiBhbmQgcmV2b2NhdGlvbiBnb3QgaXRzIG93biBtZXRh
ZGF0YS4gSW4gbW9zdCBjYXNlcyB0aGUgdW5mb3J0dW5hdGVseSBuYW1lZCBgdG9rZW5fZW5kcG9p
bnRfYXV0aF9tZXRob2RgIGFuZCBpdHMgcmVsYXRlZCBtZXRhZGF0YSBpcyB3aGF0J3MgdXNlZCBi
eSBjbGllbnRzIGZvciBhbGwgZGlyZWN0IGNhbGxzIGFueXdheS4NCiAgICA+DQogICAgPiBUaGUg
c2FtZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGllZCB0byBzaWduaW5nIChhbmQgZW5jcnlwdGlv
bikgYWxnb3JpdGhtcyBhcyB3ZWxsLg0KICAgID4NCiAgICA+IFRoaXMgSSBkbyBub3QgZm9sbG93
LCBhdXRoIG1ldGhvZHMgYW5kIHRoZWlyIHNpZ25pbmcgaXMgZGVhbHQgd2l0aCBieSB1c2luZyBg
dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZGAgYW5kIGB0b2tlbl9lbmRwb2lu
dF9hdXRoX3NpZ25pbmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWRgIC0gdGhlcmUncyBubyBlbmNyeXB0
aW9uIGZvciB0aGUgYF9qd3RgIGNsaWVudCBhdXRoIG1ldGhvZHMuDQogICAgPiBVbmxlc3MgaXQg
d2FzIG1lYW50IHRvIGFkZHJlc3MgdGhlIFJlcXVlc3QgT2JqZWN0IHNpZ25pbmcgYW5kIGVuY3J5
cHRpb24gbWV0YWRhdGEsIHdoaWNoIGlzIGRlZmluZWQgYW5kIElBTkEgcmVnaXN0ZXJlZCBieSBP
SURDLiBQQVIgb25seSByZWZlcmVuY2VzIEpBUiBzZWN0aW9uIDYuMSBhbmQgNi4yIGZvciBkZWNy
eXB0aW9uL3NpZ25hdHVyZSB2YWxpZGF0aW9uIGFuZCB0aGVzZSBkbyBub3QgbWVudGlvbiB0aGUg
bWV0YWRhdGEgKGUuZy4gcmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGcpIGFueW1vcmUgc2luY2Ug
ZHJhZnQgMDcuDQoNCiAgICBEYW1tZWQhIFlvdSBhcmUgc28gcmlnaHQuIFNvcnJ5LCBJIGdvdCBj
b25mdXNlZCBzb21laG93Lg0KDQogICAgPg0KICAgID4gUFM6IEkgYWxzbyBmb3VuZCB0aGlzIGNv
bW1lbnQgcmVsYXRlZCB0byB0aGUgc2FtZSBxdWVzdGlvbiBhYm91dCBhdXRoIG1ldGFkYXRhIGJ1
dCBmb3IgQ0lCQS4NCg0KICAgIFRoYW5rcyBmb3Igc2hhcmluZy4NCg0KICAgID4NCiAgICA+IEJl
c3QsDQogICAgPiBGaWxpcA0KDQogICAgdGhhbmtzLA0KICAgIFRvcnN0ZW4uDQoNCiAgICA+DQog
ICAgPg0KICAgID4gT24gVHVlLCAzMSBEZWMgMjAxOSBhdCAxNTozOCwgVG9yc3RlbiBMb2RkZXJz
dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu
bmV0Pj4gd3JvdGU6DQogICAgPiBIaSBhbGwsDQogICAgPg0KICAgID4gUm9uYWxkIGp1c3Qgc2Vu
dCBtZSBhbiBlbWFpbCBhc2tpbmcgd2hldGhlciB3ZSB3aWxsIGRlZmluZSBtZXRhZGF0YSBmb3IN
CiAgICA+DQogICAgPiBwdXNoZWRfYXV0aG9yaXphdGlvbl9lbmRwb2ludF9hdXRoX21ldGhvZHNf
c3VwcG9ydGVkIGFuZA0KICAgID4gcHVzaGVkX2F1dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0aF9z
aWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkLg0KICAgID4NCiAgICA+IFRoZSBkcmFmdCByaWdo
dCBub3cgdXRpbGlzZXMgdGhlIGV4aXN0aW5nIHRva2VuIGVuZHBvaW50IGF1dGhlbnRpY2F0aW9u
IG1ldGhvZHMgc28gdGhlcmUgaXMgYmFzaWNhbGx5IG5vIG5lZWQgdG8gZGVmaW5lIGFub3RoZXIg
cGFyYW1ldGVyLiBUaGUgc2FtZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGllZCB0byBzaWduaW5n
IChhbmQgZW5jcnlwdGlvbikgYWxnb3JpdGhtcyBhcyB3ZWxsLg0KICAgID4NCiAgICA+IFdoYXTi
gJlzIHlvdXIgb3Bpbmlvbj8NCiAgICA+DQogICAgPiBiZXN0IHJlZ2FyZHMsDQogICAgPiBUb3Jz
dGVuLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05G
SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh
bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg
Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg
dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t
ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0
dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ll9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo
QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_38C69B8C905F46F188BB016CF7DE2952amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWlu
Y2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh
cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K
CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47
DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT
dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g
MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0
IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTc4ODU0Mjc7DQoJbXNv
LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00MzAxMTI5MjIgNjc2
OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3
MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs
cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6
LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs
aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz
dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t
YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpc3N1ZSBpc27igJl0IHRoYXQgdGhl
IFBBUiBlbmRwb2ludCBuZWVkcyBhY2Nlc3MgdG8gb25lIHNwZWNpZmljIHJlcXVlc3Qgb2JqZWN0
IGRlY3J5cHRpb24ga2V5IHRoYXQgY291bGQgcmVhc29uYWJseSBiZSBzaGFyZWQgYWNyb3NzIEFT
IGVuZHBvaW50cywgYnV0IHRoYXQgaXQgYWN0dWFsbHkgbmVlZHMgYWNjZXNzIHRvIHRoZSBwcml2
YXRlIGtleXMgZm9yIGFsbCBlbmNyeXB0aW9uIHB1YmxpYyBrZXlzIGluDQogdGhlIEpXSyBzZXQg
cG9pbnRlZCB0byBieSB0aGUgQVPigJlzIGp3a3NfdXJpIG1ldGFkYXRhIHByb3BlcnR5LiBTaW5j
ZSB0aGVyZSBpcyBubyB3YXkgdG8gZGVzaWduYXRlIG9uZSBwYXJ0aWN1bGFyIGtleSBhcyB0aGUg
b25lIHRvIHVzZSBmb3IgZW5jcnlwdGluZyByZXF1ZXN0IG9iamVjdHMsIGNsaWVudHMgbWF5IHJl
YXNvbmFibHkgdXNlIGFueSBlbmNyeXB0aW9uIHB1YmxpYyBrZXkgaW4gdGhlIEpXSyBzZXQgdG8g
ZW5jcnlwdCBhIHJlcXVlc3QNCiBvYmplY3QuIEFzIG9uZSBleGFtcGxlIG9mIGhvdyB0aGlzIGNv
dWxkIGV4cG9zZSBzZW5zaXRpdmUgZGF0YSB0byB0aGUgUEFSIGVuZHBvaW50LCBpZiB0aGUgUEFS
IGVuZHBvaW50IGhhcyBhbGwgdGhlIGRlY3J5cHRpb24ga2V5cyBmb3IgdGhlIGtleXMgaW4gdGhl
IEFT4oCZcyBKV0sgc2V0LCBpdCB3b3VsZCBiZSBhYmxlIHRvIGRlY3J5cHQgSUQgVG9rZW5zIHNl
bnQgaW4gaWRfdG9rZW5faGludCByZXF1ZXN0IHBhcmFtZXRlcnMuIEFzIG1vcmUgYW5kDQogbW9y
ZSB1c2UgY2FzZXMgZGV2ZWxvcCBmb3IgZW5jcnlwdGluZyBibG9icyBmb3IgdGhlIEFTLCB0aGlz
IGlzc3VlIHdpbGwgb25seSBnZXQgd29yc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBQ
QVIgZW5kcG9pbnQgY2Fu4oCZdCBzaW1wbHkgc3Rhc2ggdGhlIGVuY3J5cHRlZCByZXF1ZXN0IG9i
amVjdCwgYXMgaXQgaXMgcmVxdWlyZWQgdG8gdmVyaWZ5IHRoZSByZXF1ZXN0LCBhY2NvcmRpbmcg
dG8gwqcyLjE6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+VGhlIEFTIE1VU1QgcHJvY2VzcyB0aGUgcmVxdWVzdCBhcyBmb2xsb3dzOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Li4u
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4z
LiZuYnNwOyBUaGUgQVMgTVVTVCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBpbiB0aGUgc2FtZSB3YXkg
YXMgYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO2F1dGhvcml6YXRpb24gZW5kcG9pbnQuIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBsYW5ndWFnZSBuZWVkcyB0byBiZSBt
b3JlIGZsZXhpYmxlLCBJTUhPLCB0byBhbGxvdyBmb3IgbGlnaHR3ZWlnaHQgUEFSIGVuZHBvaW50
cyB0aGF0IG1heSBub3QgaGF2ZSB0aGUgaW5mb3JtYXRpb24gb3IgYXV0aG9yaXR5IG5lZWRlZCB0
byBwZXJmb3JtIGFsbCB0aGUgdmFsaWRhdGlvbiB0aGF0IGhhcHBlbnMgYXQgdGhlIGF1dGhvcml6
YXRpb24gZW5kcG9pbnQuIEkgbmVlZCB0byB0aGluayBhYm91dA0KIHRoaXMgbW9yZSBiZWZvcmUg
SSBjYW4gc2F5IGlmIGl0IHdvdWxkIGFkZXF1YXRlbHkgYWRkcmVzcyBteSBjb25jZXJucywgYnV0
IGl04oCZZCBiZSBhIGdvb2Qgc3RhcnQgYW5kIG1ha2VzIHNlbnNlIGluIGl0cyBvd24gcmlnaHQu
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXTigJlzIHByZXR0eSByaXNreSBmb3Ig
dXMgdG8gYmFzZSBkZWNpc2lvbiBvbiBhbiBhc3N1bXB0aW9uIHRoYXQgbm8gb25lIGlzIGdvaW5n
IHRvIG5lZWQgb3Igd2FudCB0byBlbmNyeXB0IHB1c2hlZCByZXF1ZXN0IG9iamVjdHMsIHBhcnRp
Y3VsYXJseSB3aGVuIHRoZXnigJlyZSBKV1RzLCBhbmQgSldUcyBoYXZlIHdlbGwgZXN0YWJsaXNo
ZWQgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiwgYW5kIGVuY3J5cHRlZA0KIEpXVHMgYXJlIHN1cHBv
cnRlZCBieSBwYXNzLWJ5LXZhbHVlIGluIE9JREMgYW5kIGRyYWZ0LWlldGYtb2F1dGgtandzcmVx
LiBCdXQgaWYgeW91IGluc2lzdCwgaGVyZSBhcmUgYSBmZXcgZXhhbXBsZXMgZm9yIHdoeSBzb21l
b25lIG1pZ2h0IHdhbnQgdG8gZG8gdGhpczo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFy
Z2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhl
IHJlcXVlc3Qgb2JqZWN0IGlzIHBhc3NlZCBieSByZWZlcmVuY2UsIGFuZCBhY2Nlc3NpYmxlIG9u
IHRoZSBwdWJsaWMgSW50ZXJuZXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh
cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+
VGhlIHJlcXVlc3Qgb2JqZWN0IGNvbnRhaW5zIHNlbnNpdGl2ZSB0cmFuc2FjdGlvbi1yZWxhdGVk
IGRhdGEgaW4gUkFSIHBhcmFtZXRlcnMgdGhhdCB0aGUgY2xpZW504oCZcyBhdXRoTi9hdXRoWiBz
dGFjayBkb2VzbuKAmXQgbmVlZCB0byBoYXZlIGFjY2VzcyB0by48bzpwPjwvbzpwPjwvbGk+PGxp
IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0
OmwwIGxldmVsMSBsZm8xIj5UaGUgQVMgcmVxdWlyZXMgcmVxdWVzdCBvYmplY3QgZW5jcnlwdGlv
biB0byBtaW5pbWl6ZSBleHBvc3VyZSB0byB0aGUgaG9zdGVkIFBBUiBlbmRwb2ludCBzZXJ2aWNl
IGl0IHVzZXMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+IzIsIGJ1dCB0aGUg
dGhyZWF0IHZlY3RvciBpcyBnYXBzIGluIGVuZC10by1lbmQgVExTLjxvOnA+PC9vOnA+PC9saT48
bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPkFueSBvZiB0aGUgYWJvdmUsIGJ1dCB0aGUgY29uY2VybiBpcyBt
ZXNzYWdlIGludGVncml0eSwgYW5kIHRoZSBBUyByZXF1aXJlcyByZXF1ZXN0ZWQgb2JqZWN0cyB0
byBiZSBlbmNyeXB0ZWQgZm9yIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rp
b24gYW5kIGRvZXMgbm90IHN1cHBvcnQgc2lnbmVkDQogcmVxdWVzdCBvYmplY3RzLjxvOnA+PC9v
OnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOmJsYWNrIj5OZWlsIE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2Nr
LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKYW51YXJ5IDYsIDIwMjAgYXQgNjoy
OSBBTTxicj4NCjxiPlRvOiA8L2I+QnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5h
YmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBOYXQgU2FraW11cmEgJmx0
O25hdEBzYWtpbXVyYS5vcmcmZ3Q7LCBEYXZlIFRvbmdlICZsdDtkYXZlLnRvbmdlQG1vbmV5aHVi
LmNvbSZndDssIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0
Jmd0Oywgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5b
VU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIFBBUiBtZXRhZGF0YTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQuIDxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYWRkaXRpb24sIEkn
bSBub3Qgc3VyZSB3aHkgdGhlIFBBUiBlbmRwb2ludCB3b3VsZCBuZWVkIGFjY2VzcyB0byB0aGUg
ZGVjcnlwdGlvbiBrZXlzIGF0IGFsbC4gSWYgeW91J3JlIHVzaW5nIGVuY3J5cHRlZCByZXF1ZXN0
IG9iamVjdHMgdGhlbiB0aGUgUEFSIGVuZHBvaW50IHJlY2VpdmVzIGFuIGVuY3J5cHRlZCBKV1Qg
YW5kIHRoZW4gbGF0ZXIgbWFrZXMgdGhlIHNhbWUgKHN0aWxsIGVuY3J5cHRlZCkgSldUDQogYXZh
aWxhYmxlIHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBJZiB0aGUgUEFSIGVuZHBvaW50
IGlzIGRvaW5nIGFueSBraW5kIG9mIGRlY3J5cHRpb24gb3IgdmFsaWRhdGlvbiBvbiBiZWhhbGYg
b2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdGhlbiB0aGV5IGFyZSBjbGVhcmx5IG5vdCBp
biBzZXBhcmF0ZSB0cnVzdCBib3VuZGFyaWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBOZWlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYgSmFuIDIwMjAsIGF0IDEzOjU3LCBCcmlhbiBD
YW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21A
ZG1hcmMuaWV0Zi5vcmciPmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v
cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIHJlYWxseSBzdHJ1Z2dsZSB0byBzZWUgdGhlIGFzc3VtcHRpb24gdGhh
dCBhbiBlbnRpdHkgYmUgYWJsZSB0byB1c2UgdGhlIHNhbWUga2V5IHRvIGRlY3J5cHQgdGhlIHNh
bWUgdHlwZSBvZiBtZXNzYWdlIHVsdGltYXRlbHkgaW50ZW5kZWQgZm9yIHRoZSBzYW1lIHB1cnBv
c2UgYXMgYW4gYXJ0aWZpY2lhbCBsaW1pdC4gVGhlIHNhbWUgZ2VuZXJhbCBhc3N1bXB0aW9uICZu
YnNwOyB1bmRlcmxpZXMgZXZlcnl0aGluZyBlbHNlDQogaW4gT0F1dGgvT0lEQyAoVmxhZGltaXIn
cyBwb3N0IHBvaW50cyB0byBzb21lIGJ1dCBub3QgYWxsIGV4YW1wbGVzIG9mIHN1Y2gpLiBUaGVy
ZSdzIG5vIHJlYXNvbiBmb3IgUEFSIHRvIG1ha2UgYSBvbmUtb2ZmIGV4Y2VwdGlvbi4gQW5kIHNo
b3VsZCB0aGVyZSBiZSBzb21lIGRlcGxveW1lbnQgc3BlY2lmaWMgcmVhc29uIHRoYXQgdHJ1bHkg
cmVxdWlyZXMgdGhhdCBraW5kIG9mIGlzb2xhdGlvbiwgdGhlcmUgYXJlIGNlcnRhaW5seSBpbXBs
ZW1lbnRhdGlvbg0KIG9wdGlvbnMgdGhhdCBhcmVuJ3QgY29tcGF0aWJpbGl0eS1icmVha2luZy4g
QW5kIGhhdmluZyBzYWlkIGFsbCB0aGF0LCBJJ20gaG9uZXN0bHkgYSBsaXR0bGUgc3VycHJpc2Vk
IGFueW9uZSBpcyB0aGlua2luZyBtdWNoIGFib3V0IGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdHMg
d2l0aCBQQVIgYXMsIGF0IGxlYXN0IHdpdGggbXkgbGltaXRlZCBpbWFnaW5hdGlvbiwgdGhlcmUn
cyBub3QgcmVhbGx5IGEgbmVlZCBmb3IgaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAzLCAy
MDIwIGF0IDI6NDMgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxh
IGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBBUiBpbnRyb2R1
Y2VzIGFuIGFkZGVkIHdyaW5rbGUgZm9yIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdHM6IHRoZSBQ
QVIgZW5kcG9pbnQgYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgbWF5IG5vdCBoYXZlIGFjY2Vz
cyB0byB0aGUgc2FtZSBjcnlwdG9ncmFwaGljIGtleXMsIGV2ZW4gdGhvdWdoIHRoZXkncmUgYm90
aCBwYXJ0IG9mIHRoZSAmcXVvdDthdXRob3JpemF0aW9uIHNlcnZlci4mcXVvdDsgU2luY2UgdGhl
eSdyZSBkaWZmZXJlbnQNCiBlbmRwb2ludHMgd2l0aCBkaWZmZXJlbnQgcm9sZXMsIGl0J3MgcmVh
c29uYWJsZSB0byBwdXQgdGhlbSBpbiBzZXBhcmF0ZSB0cnVzdCBib3VuZGFyaWVzLiBUaGVyZSBp
cyBubyB3YXkgdG8gc3VwcG9ydCB0aGlzIGlzb2xhdGlvbiB3aXRoIGp1c3QgYSBzaW5nbGUgJnF1
b3Q7andrc191cmkmcXVvdDsgbWV0YWRhdGEgcHJvcGVydHkuPGJyPg0KPGJyPg0KVGhlIHR3byBv
cHRpb25zIHRoYXQgSSBzZWUgYXJlOjxicj4NCjxicj4NCjEuIERlZmluZSBhIG5ldyBwYXJfandr
c191cmkgbWV0YWRhdGEgcHJvcGVydHkuPGJyPg0KMi4gRXhwbGljaXRseSBzdGF0ZSB0aGF0IHRo
aXMgc2VwYXJhdGlvbiBpcyBub3Qgc3VwcG9ydGVkLjxicj4NCjxicj4NCkkgc3Ryb25nbHkgcGVy
ZmVyICMxIGFzIGl0IGhhcyBhIHZlcnkgbWlub3IgaW1wYWN0IG9uIGRlcGxveW1lbnRzIHRoYXQg
ZG9uJ3QgY2FyZSAoaS5lLiwgdGhleSBqdXN0IHNldCBwYXJfandrc191cmkgYW5kIGp3a3NfdXJp
IHRvIHRoZSBzYW1lIHZhbHVlKSBhbmQgZmFpbGluZyB0byBzdXBwb3J0IHRoaXMgdHJ1c3QgYm91
bmRhcnkgY3JlYXRlcyBhbiBhcnRpZmljaWFsIGxpbWl0IG9uIGltcGxlbWVudGF0aW9uIGFyY2hp
dGVjdHVyZSBhbmQgY291bGQNCiBsZWFkIHRvIGNvbXBhdGliaWxpdHktYnJlYWtpbmcgd29ya2Fy
b3VuZHMuPGJyPg0KPGJyPg0K4oCTIDxicj4NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnI+
DQpBV1MgSWRlbnRpdHk8YnI+DQo8YnI+DQo8YnI+DQpPbiAxMi8zMS8xOSwgODowNyBBTSwgJnF1
b3Q7T0F1dGggb24gYmVoYWxmIG9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQmcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mIHRvcnN0ZW49PGEgaHJlZj0ibWFpbHRv
OjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2Rk
ZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ow0KIHdyb3RlOjxicj4NCjxicj4NCiZu
YnNwOyAmbmJzcDsgSGkgRmlsaXAsIDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBPbiAz
MS4gRGVjIDIwMTksIGF0IDE2OjIyLCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpw
YW52YS5pcEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wYW52YS5pcEBnbWFpbC5jb208L2E+
Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAm
Z3Q7IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBhICpfYXV0aF9tZXRob2RfKiBtZXRhZGF0YSBmb3Ig
ZXZlcnkgZW5kcG9pbnQgdGhlIGNsaWVudCBjYWxscyBkaXJlY3RseSwgbm9uZSBvZiB0aGUgbmV3
IHNwZWNzIGRlZmluZWQgdGhlc2UgKGUuZy4gZGV2aWNlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQg
b3IgQ0lCQSksIG1lYW5pbmcgdGhleSBhbHNvIGRpZG4ndCBmb2xsb3cgdGhlIHNjaGVtZSBmcm9t
IFJGQyA4NDE0IHdoZXJlIGludHJvc3BlY3Rpb24NCiBhbmQgcmV2b2NhdGlvbiBnb3QgaXRzIG93
biBtZXRhZGF0YS4gSW4gbW9zdCBjYXNlcyB0aGUgdW5mb3J0dW5hdGVseSBuYW1lZCBgdG9rZW5f
ZW5kcG9pbnRfYXV0aF9tZXRob2RgIGFuZCBpdHMgcmVsYXRlZCBtZXRhZGF0YSBpcyB3aGF0J3Mg
dXNlZCBieSBjbGllbnRzIGZvciBhbGwgZGlyZWN0IGNhbGxzIGFueXdheS48YnI+DQombmJzcDsg
Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSBzYW1lIHByaW5jaXBsZSBj
b3VsZCBiZSBhcHBsaWVkIHRvIHNpZ25pbmcgKGFuZCBlbmNyeXB0aW9uKSBhbGdvcml0aG1zIGFz
IHdlbGwuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBU
aGlzIEkgZG8gbm90IGZvbGxvdywgYXV0aCBtZXRob2RzIGFuZCB0aGVpciBzaWduaW5nIGlzIGRl
YWx0IHdpdGggYnkgdXNpbmcgYHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWRg
IGFuZCBgdG9rZW5fZW5kcG9pbnRfYXV0aF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkYCAt
IHRoZXJlJ3Mgbm8gZW5jcnlwdGlvbiBmb3IgdGhlIGBfand0YCBjbGllbnQgYXV0aCBtZXRob2Rz
Lg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFVubGVzcyBpdCB3YXMgbWVhbnQgdG8gYWRkcmVz
cyB0aGUgUmVxdWVzdCBPYmplY3Qgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiBtZXRhZGF0YSwgd2hp
Y2ggaXMgZGVmaW5lZCBhbmQgSUFOQSByZWdpc3RlcmVkIGJ5IE9JREMuIFBBUiBvbmx5IHJlZmVy
ZW5jZXMgSkFSIHNlY3Rpb24gNi4xIGFuZCA2LjIgZm9yIGRlY3J5cHRpb24vc2lnbmF0dXJlIHZh
bGlkYXRpb24gYW5kIHRoZXNlIGRvIG5vdCBtZW50aW9uIHRoZSBtZXRhZGF0YSAoZS5nLg0KIHJl
cXVlc3Rfb2JqZWN0X3NpZ25pbmdfYWxnKSBhbnltb3JlIHNpbmNlIGRyYWZ0IDA3Ljxicj4NCjxi
cj4NCiZuYnNwOyAmbmJzcDsgRGFtbWVkISBZb3UgYXJlIHNvIHJpZ2h0LiBTb3JyeSwgSSBnb3Qg
Y29uZnVzZWQgc29tZWhvdy4gPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZu
YnNwOyAmbmJzcDsgJmd0OyBQUzogSSBhbHNvIGZvdW5kIHRoaXMgY29tbWVudCByZWxhdGVkIHRv
IHRoZSBzYW1lIHF1ZXN0aW9uIGFib3V0IGF1dGggbWV0YWRhdGEgYnV0IGZvciBDSUJBLjxicj4N
Cjxicj4NCiZuYnNwOyAmbmJzcDsgVGhhbmtzIGZvciBzaGFyaW5nLiA8YnI+DQo8YnI+DQombmJz
cDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJlc3QsPGJyPg0KJm5ic3A7
ICZuYnNwOyAmZ3Q7IEZpbGlwPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGFua3MsPGJyPg0K
Jm5ic3A7ICZuYnNwOyBUb3JzdGVuLiA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBPbiBUdWUsIDMx
IERlYyAyMDE5IGF0IDE1OjM4LCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWls
dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRl
cnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBIaSBhbGws
PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBSb25hbGQg
anVzdCBzZW50IG1lIGFuIGVtYWlsIGFza2luZyB3aGV0aGVyIHdlIHdpbGwgZGVmaW5lIG1ldGFk
YXRhIGZvciA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7
IHB1c2hlZF9hdXRob3JpemF0aW9uX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgYW5k
PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHB1c2hlZF9hdXRob3JpemF0aW9uX2VuZHBvaW50X2F1
dGhfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsg
PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSBkcmFmdCByaWdodCBub3cgdXRpbGlzZXMgdGhl
IGV4aXN0aW5nIHRva2VuIGVuZHBvaW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgc28gdGhlcmUg
aXMgYmFzaWNhbGx5IG5vIG5lZWQgdG8gZGVmaW5lIGFub3RoZXIgcGFyYW1ldGVyLiBUaGUgc2Ft
ZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGllZCB0byBzaWduaW5nIChhbmQgZW5jcnlwdGlvbikg
YWxnb3JpdGhtcyBhcyB3ZWxsLg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNw
OyAmbmJzcDsgJmd0OyBXaGF04oCZcyB5b3VyIG9waW5pb24/PGJyPg0KJm5ic3A7ICZuYnNwOyAm
Z3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBiZXN0IHJlZ2FyZHMsPGJyPg0KJm5ic3A7ICZu
YnNwOyAmZ3Q7IFRvcnN0ZW4uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6
IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURF
TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg
cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp
cGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi
eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls
ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwv
Yj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B
dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1
dGhAaWV0Zi5vcmc8L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_38C69B8C905F46F188BB016CF7DE2952amazoncom_--


From nobody Mon Jan  6 14:22: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 A95D9120108 for ; Mon,  6 Jan 2020 14:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-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 GTHGqbfLH8je for ; Mon,  6 Jan 2020 14:21:59 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B91120018 for ; Mon,  6 Jan 2020 14:21:59 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id w21so65851094otj.7 for ; Mon, 06 Jan 2020 14:21:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BitlGuzUsINFgNd4XQP52NIHYQsnxmm1wqrO+23lLjY=; b=rAECnsV3FGCIrgFtSKDAy0+/hYD107NcQC1xJhK6sQ6FDWL0b/dFZpD7jr4ZznwIex lbMYgJikXa1XvjJjZJMLvGJUM01+Y0ZK8L1RiQwNRzrZ9hrVW8DLeaVWouV4dKPHQYHk 6EbaEkFKch064ruo2PJ1VfoMCN/nr8gK9RSzO3FcAO299JkgH42+ZagayT14XBbCtKmP IRiHfGX8Z1qJkYDq9NZg0ipri++0PxHi4y4lpdhME5pPsL+RLUsDRjs0T0SnkhAtwJdS Hki4q7zrrvLeqMMQd7X1RfFIEJGV+YipAl67dqkBcST2+hInIhOi9UM+9WODuSUiUNAH 1x8w==
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=BitlGuzUsINFgNd4XQP52NIHYQsnxmm1wqrO+23lLjY=; b=R86KIDesEGnt4wijFyWiKkK9bPmTEj++SqNaKvJdZiRe1d5/tY14DUFW7Vj31hsGup 1465Svbuc1LUslrNZdFwDkq+L8jVUCyALu/Q9EP/Bjdu3M3Fo9glKXRcXqtySMs+k+7Q eyWfqO/oa9c9tcpS4s+1VQoFPKKiWOF5xzwrZ2atPj1dE6RtDXfyi0HDLzJO9J5zVu1R oHCVXF26XJkXqgkGM0ICua+LduQ8cr6juqI/7Ugy54ix0hk/0+jVgfvAeMonsvEoH1xi Q17KEIYzQX+CcAaUAS8PZ0eqzQMHqH5dJrLzvx5dW5UgEGMigotngTHpD8vwZoOi8RXZ 8+HA==
X-Gm-Message-State: APjAAAWlGqgdcuxkz4dlF+NoyT1FkWKUVyvx6lXuq2osYjWefdzp0uNs kxLFl0RDiNMn3pxIAAueQy6f7/Ej0W112C9zsNfrCFHrS3FLLg==
X-Google-Smtp-Source: APXvYqzmOdOGJBZdwweJ6XYz7+GqMfz5VQVUHMDQmplOiBDmUyBhGfASw8ez+9+EV3ys0RCe/VML9paJ8JPeSMIX5OY=
X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr111474470otn.13.1578349318878;  Mon, 06 Jan 2020 14:21:58 -0800 (PST)
MIME-Version: 1.0
References:  <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com>  
In-Reply-To: 
From: Jim Willeke 
Date: Mon, 6 Jan 2020 17:21:22 -0500
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000007bc19d059b8016f7"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 22:22:02 -0000

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

I support adoption.
--
-jim
Jim Willeke


On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt  wrote:

> I support adoption
> =E1=90=A7
>
> On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>
>> I support adoption.
>>
>>
>>
>> =E2=80=93
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> *From: *OAuth  on behalf of John Bradley <
>> ve7jtb@ve7jtb.com>
>> *Date: *Monday, January 6, 2020 at 12:05 PM
>> *To: *"oauth@ietf.org" 
>> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich
>> Authorization Requests
>>
>>
>>
>> I support adoption
>>
>> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:
>>
>> All,
>>
>>
>>
>> This is a call for adoption for the *OAuth 2.0 Rich Authorization
>> Requests* document.
>>
>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>
>>
>>
>> Please, let us know if you support or object to the adoption of this
>> document as a working group document by Jan 20th.
>>
>>
>>
>> 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
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I support adoption.
--
-jim
Jim Willeke

<=
/div>
O=
n Mon, Jan 6, 2020 at 3:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I support adoption
3D""=E1=90=A7

On Mon, Jan 6, 2020 at 12:32 PM Richard Backman,=
 Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:











I support adoption.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of John Bradley <ve7jtb@ve7jtb.com>

Date: Monday, January 6, 2020 at 12:05 PM

To: "oauth@=
ietf.org" <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorizat=
ion Requests






=C2=A0




I support adoption




On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:








All, 




=C2=A0






This is a call for adoption for the=C2=A0OAuth 2.=
0 Rich Authorization Requests document.







=C2=A0






Please, let us know if you support or object to the =
adoption of this document as a working group document by Jan 20th.






=C2=A0






Regards,






=C2=A0Rifaat & Hannes






=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




--0000000000007bc19d059b8016f7--


From nobody Mon Jan  6 14:22: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 DB530120018 for ; Mon,  6 Jan 2020 14:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr6BW6kO1biP for ; Mon,  6 Jan 2020 14:22:21 -0800 (PST)
Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EF612084C for ; Mon,  6 Jan 2020 14:22:21 -0800 (PST)
Received: by mail-yw1-xc33.google.com with SMTP id i190so22569247ywc.2 for ; Mon, 06 Jan 2020 14:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ISmWmBnjnP3e60Q32jKYiqCMch99wZnFXzu1TgkJ6mo=; b=m03yS4GnOmOtuzbpbIVcYksZSDULpL1TVeXyh+K8aeDH4h7coY95oD+YZhLldCqmaZ SzALz6VPLx1NjkBxUaginRMce+kPR4SaWe5r9TMyiT5WFVYriqO/QvHJALcAqsNNDSjo FE8L5lA/SFjeDj5krd2DLWwZHVCeS8yUEUO2x6/5C/cGjvWGXWA+1ELTMVeYUFI6yDnu kE1/VKTegY9jbSUWFk1wvJyicSx2oxhPVQQcrozXYgVUJ/PPr/4lTkQvcrc4oTuvBKX8 nJoU40IHjvlfR3MPSsvZHBFI114rJgns1bIuUXysggwuJXqgEQY0DP7B3IOuwzbC/LEj j2mQ==
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=ISmWmBnjnP3e60Q32jKYiqCMch99wZnFXzu1TgkJ6mo=; b=qOjA3V2p4FhV2gtK5T9VDZL7E49BbhutxsiCHvh/ReGsuLg5ezeetcS5qoVCmBid32 jCzMx0k6UjTlDyu6EtEyKRi20fhmgLHC/abEzFet9UhfXYUPUau3nc6WuVWi/H2mxr8/ q8w4TrbQFS2TkveLfzAnr0MWsD2UunuL/dnMTU6+f/Hw30VRo2iaGPQwxnd6rotsnrkD ZcgrLk1HjKzX3FBYIl9bWhGa1GMUBQmH+TZZARQXtbxjYIhVUhVA6N2sQl2lIwXhElN9 /WBIEycsmB8qlyMzpW9wWKU9Xm44KqrIKhhi0WcWJuZ3f/CR0CHtW8jj1/qJLne/pXEv rymg==
X-Gm-Message-State: APjAAAXgo6lqtLMfIgvSHPgny0hPxfIuqWKeBi6N+/7vwaCw4z0zwWW8 /tZKLBGwr6BwJ2vkbNG7r+EB2bNgke9AM+dakA==
X-Google-Smtp-Source: APXvYqzDwzPgc2TAADv4W+8d9Dm8T/1bYbWHGFBVNzBCYje99K2jRZldGQDQNMjG6aD2FQYh8eGbOQcbTkYE9b0+YEE=
X-Received: by 2002:a81:b604:: with SMTP id u4mr80402087ywh.301.1578349340297;  Mon, 06 Jan 2020 14:22:20 -0800 (PST)
MIME-Version: 1.0
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
In-Reply-To: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
From: Filip Skokan 
Date: Mon, 6 Jan 2020 23:22:09 +0100
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Neil Madden , Brian Campbell ,  Dave Tonge , oauth ,  Nat Sakimura 
Content-Type: multipart/alternative; boundary="000000000000c29085059b801774"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 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: Mon, 06 Jan 2020 22:22:24 -0000

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

We've been discussing making the following change to the language

The AS SHOULD validate the request in the same way as at the authorization
> endpoint. The AS MUST ensure that all parameters to the authorization
> request are still valid at the time when the request URI is used.
>

This would allow the PAR endpoint to simply stash the encrypted request
object instead of decrypting and validating it. All within the bounds of
"SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t always req=
uire it". This
supports "light weight PAR" implementation rather than introducing the
unnecessary complexity in the form of a second JWKS.

Best,
*Filip*


On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle  wrote:

> The issue isn=E2=80=99t that the PAR endpoint needs access to one specifi=
c request
> object decryption key that could reasonably be shared across AS endpoints=
,
> but that it actually needs access to the private keys for all encryption
> public keys in the JWK set pointed to by the AS=E2=80=99s jwks_uri metada=
ta
> property. Since there is no way to designate one particular key as the on=
e
> to use for encrypting request objects, clients may reasonably use any
> encryption public key in the JWK set to encrypt a request object. As one
> example of how this could expose sensitive data to the PAR endpoint, if t=
he
> PAR endpoint has all the decryption keys for the keys in the AS=E2=80=99s=
 JWK set,
> it would be able to decrypt ID Tokens sent in id_token_hint request
> parameters. As more and more use cases develop for encrypting blobs for t=
he
> AS, this issue will only get worse.
>
>
>
> The PAR endpoint can=E2=80=99t simply stash the encrypted request object,=
 as it is
> required to verify the request, according to =C2=A72.1:
>
>
>
> The AS MUST process the request as follows:
>
>
>
> ...
>
>
>
> 3.  The AS MUST validate the request in the same way as at the
>
>           authorization endpoint. ...
>
>
>
> This language needs to be more flexible, IMHO, to allow for lightweight
> PAR endpoints that may not have the information or authority needed to
> perform all the validation that happens at the authorization endpoint. I
> need to think about this more before I can say if it would adequately
> address my concerns, but it=E2=80=99d be a good start and makes sense in =
its own
> right.
>
>
>
> I think it=E2=80=99s pretty risky for us to base decision on an assumptio=
n that no
> one is going to need or want to encrypt pushed request objects,
> particularly when they=E2=80=99re JWTs, and JWTs have well established su=
pport for
> encryption, and encrypted JWTs are supported by pass-by-value in OIDC and
> draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for w=
hy
> someone might want to do this:
>
>    1. The request object is passed by reference, and accessible on the
>    public Internet.
>    2. The request object contains sensitive transaction-related data in
>    RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80=
=99t need to have
>    access to.
>    3. The AS requires request object encryption to minimize exposure to
>    the hosted PAR endpoint service it uses.
>    4. #2, but the threat vector is gaps in end-to-end TLS.
>    5. Any of the above, but the concern is message integrity, and the AS
>    requires requested objects to be encrypted for confidentiality and
>    integrity protection and does not support signed request objects.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Neil Madden 
> *Date: *Monday, January 6, 2020 at 6:29 AM
> *To: *Brian Campbell 
> *Cc: *"Richard Backman, Annabelle" , Nat Sakimura <
> nat@sakimura.org>, Dave Tonge , Torsten
> Lodderstedt , oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
>
>
> Agreed.
>
>
>
> In addition, I'm not sure why the PAR endpoint would need access to the
> decryption keys at all. If you're using encrypted request objects then th=
e
> PAR endpoint receives an encrypted JWT and then later makes the same (sti=
ll
> encrypted) JWT available to the authorization endpoint. If the PAR endpoi=
nt
> is doing any kind of decryption or validation on behalf of the
> authorization endpoint then they are clearly not in separate trust
> boundaries.
>
>
>
> -- Neil
>
>
>
>
>
> On 6 Jan 2020, at 13:57, Brian Campbell <
> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>
>
>
> I really struggle to see the assumption that an entity be able to use the
> same key to decrypt the same type of message ultimately intended for the
> same purpose as an artificial limit. The same general assumption
> underlies everything else in OAuth/OIDC (Vladimir's post points to some b=
ut
> not all examples of such). There's no reason for PAR to make a one-off
> exception. And should there be some deployment specific reason that truly
> requires that kind of isolation, there are certainly implementation optio=
ns
> that aren't compatibility-breaking. And having said all that, I'm honestl=
y
> a little surprised anyone is thinking much about encrypted request object=
s
> with PAR as, at least with my limited imagination, there's not really a
> need for it.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>
> PAR introduces an added wrinkle for encrypted request objects: the PAR
> endpoint and authorization endpoint may not have access to the same
> cryptographic keys, even though they're both part of the "authorization
> server." Since they're different endpoints with different roles, it's
> reasonable to put them in separate trust boundaries. There is no way to
> support this isolation with just a single "jwks_uri" metadata property.
>
> The two options that I see are:
>
> 1. Define a new par_jwks_uri metadata property.
> 2. Explicitly state that this separation is not supported.
>
> I strongly perfer #1 as it has a very minor impact on deployments that
> don't care (i.e., they just set par_jwks_uri and jwks_uri to the same
> value) and failing to support this trust boundary creates an artificial
> limit on implementation architecture and could lead to
> compatibility-breaking workarounds.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <
> oauth-bounces@ietf.org on behalf of torsten=3D
> 40lodderstedt.net@dmarc.ietf.org> wrote:
>
>     Hi Filip,
>
>     > On 31. Dec 2019, at 16:22, Filip Skokan  wrote:
>     >
>     > I don't think we need a *_auth_method_* metadata for every endpoint
> the client calls directly, none of the new specs defined these (e.g. devi=
ce
> authorization endpoint or CIBA), meaning they also didn't follow the sche=
me
> from RFC 8414 where introspection and revocation got its own metadata. In
> most cases the unfortunately named `token_endpoint_auth_method` and its
> related metadata is what's used by clients for all direct calls anyway.
>     >
>     > The same principle could be applied to signing (and encryption)
> algorithms as well.
>     >
>     > This I do not follow, auth methods and their signing is dealt with
> by using `token_endpoint_auth_methods_supported` and
> `token_endpoint_auth_signing_alg_values_supported` - there's no encryptio=
n
> for the `_jwt` client auth methods.
>     > Unless it was meant to address the Request Object signing and
> encryption metadata, which is defined and IANA registered by OIDC. PAR on=
ly
> references JAR section 6.1 and 6.2 for decryption/signature validation an=
d
> these do not mention the metadata (e.g. request_object_signing_alg) anymo=
re
> since draft 07.
>
>     Dammed! You are so right. Sorry, I got confused somehow.
>
>     >
>     > PS: I also found this comment related to the same question about
> auth metadata but for CIBA.
>
>     Thanks for sharing.
>
>     >
>     > Best,
>     > Filip
>
>     thanks,
>     Torsten.
>
>     >
>     >
>     > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>     > Hi all,
>     >
>     > Ronald just sent me an email asking whether we will define metadata
> for
>     >
>     > pushed_authorization_endpoint_auth_methods_supported and
>     > pushed_authorization_endpoint_auth_signing_alg_values_supported.
>     >
>     > The draft right now utilises the existing token endpoint
> authentication methods so there is basically no need to define another
> parameter. The same principle could be applied to signing (and encryption=
)
> algorithms as well.
>     >
>     > What=E2=80=99s your opinion?
>     >
>     > best regards,
>     > Torsten.
>
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


We've been discussing making the following=C2=A0c=
hange to the language

The AS SHOULD validate the request in the same way as at t=
he authorization endpoint. The AS MUST ensure that all parameters to the au=
thorization request are still valid at the time when the request URI is use=
d.

This would allow the PAR endpoint to=
 simply stash the encrypted request object instead of decrypting and valida=
ting it. All within the bounds of "SHOULD -=C2=A0We=E2=80=99d like you=
 to do this, but we can=E2=80=99t always require it". This supports &q=
uot;light weight PAR" implementation rather than introducing the unnec=
essary complexity in the form of a second JWKS.

Best,
Filip


On Mon, 6 Jan 2020 a=
t 23:00, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
=












The issue isn=E2=80=99t that the PAR endpoint needs =
access to one specific request object decryption key that could reasonably =
be shared across AS endpoints, but that it actually needs access to the pri=
vate keys for all encryption public keys in
 the JWK set pointed to by the AS=E2=80=99s jwks_uri metadata property. Sin=
ce there is no way to designate one particular key as the one to use for en=
crypting request objects, clients may reasonably use any encryption public =
key in the JWK set to encrypt a request
 object. As one example of how this could expose sensitive data to the PAR =
endpoint, if the PAR endpoint has all the decryption keys for the keys in t=
he AS=E2=80=99s JWK set, it would be able to decrypt ID Tokens sent in id_t=
oken_hint request parameters. As more and
 more use cases develop for encrypting blobs for the AS, this issue will on=
ly get worse.


=C2=A0


The PAR endpoint can=E2=80=99t simply stash the encr=
ypted request object, as it is required to verify the request, according to=
 =C2=A72.1:


=C2=A0


The AS MUST pr=
ocess the request as follows:


=C2=A0<=
u>


...<=
/u>


=C2=A0<=
u>


3.=C2=A0 The A=
S MUST validate the request in the same way as at the<=
/pre>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0authorization endpoint. ...


=C2=A0


This language needs to be more flexible, IMHO, to al=
low for lightweight PAR endpoints that may not have the information or auth=
ority needed to perform all the validation that happens at the authorizatio=
n endpoint. I need to think about
 this more before I can say if it would adequately address my concerns, but=
 it=E2=80=99d be a good start and makes sense in its own right.


=C2=A0


I think it=E2=80=99s pretty risky for us to base dec=
ision on an assumption that no one is going to need or want to encrypt push=
ed request objects, particularly when they=E2=80=99re JWTs, and JWTs have w=
ell established support for encryption, and encrypted
 JWTs are supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. B=
ut if you insist, here are a few examples for why someone might want to do =
this:


    

  1. The request object is passed by reference, and accessible on the =
public Internet.
  2. The request object contains se=
nsitive transaction-related data in RAR parameters that the client=E2=80=99=
s authN/authZ stack doesn=E2=80=99t need to have access to.
  3. The AS requires request object encryption to minimize exposure=
 to the hosted PAR endpoint service it uses.
  4. #2=
, but the threat vector is gaps in end-to-end TLS.
  5. Any of the above, but the concern is message integrity, and the AS requ=
ires requested objects to be encrypted for confidentiality and integrity pr=
otection and does not support signed
 request objects.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
Neil Madden <neil.madden@forge=
rock.com>

Date: Monday, January 6, 2020 at 6:29 AM

To: Brian Campbell <bcampbell@pingidentity.com>

Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Nat Sakimu=
ra <nat@sakimura.o=
rg>, Dave Tonge <dave.tonge@moneyhub.com>, Torsten Lodderstedt <torsten@lodderstedt=
.net>, oauth <oauth@ietf.org>

Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata






=C2=A0




Agreed. 




=C2=A0






In addition, I'm not sure why the PAR endpoint w=
ould need access to the decryption keys at all. If you're using encrypt=
ed request objects then the PAR endpoint receives an encrypted JWT and then=
 later makes the same (still encrypted) JWT
 available to the authorization endpoint. If the PAR endpoint is doing any =
kind of decryption or validation on behalf of the authorization endpoint th=
en they are clearly not in separate trust boundaries.






=C2=A0






-- Neil






=C2=A0















On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:=





=C2=A0








I really struggle to see the assumption that an enti=
ty be able to use the same key to decrypt the same type of message ultimate=
ly intended for the same purpose as an artificial limit. The same general a=
ssumption =C2=A0 underlies everything else
 in OAuth/OIDC (Vladimir's post points to some but not all examples of =
such). There's no reason for PAR to make a one-off exception. And shoul=
d there be some deployment specific reason that truly requires that kind of=
 isolation, there are certainly implementation
 options that aren't compatibility-breaking. And having said all that, =
I'm honestly a little surprised anyone is thinking much about encrypted=
 request objects with PAR as, at least with my limited imagination, there&#=
39;s not really a need for it.







=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Anna=
belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:






PAR introduces an added wrinkle for encrypted reques=
t objects: the PAR endpoint and authorization endpoint may not have access =
to the same cryptographic keys, even though they're both part of the &q=
uot;authorization server." Since they're different
 endpoints with different roles, it's reasonable to put them in separat=
e trust boundaries. There is no way to support this isolation with just a s=
ingle "jwks_uri" metadata property.



The two options that I see are:



1. Define a new par_jwks_uri metadata property.

2. Explicitly state that this separation is not supported.



I strongly perfer #1 as it has a very minor impact on deployments that don&=
#39;t care (i.e., they just set par_jwks_uri and jwks_uri to the same value=
) and failing to support this trust boundary creates an artificial limit on=
 implementation architecture and could
 lead to compatibility-breaking workarounds.



=E2=80=93 

Annabelle Richard Backman

AWS Identity





On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" &l=
t;oauth-bounces=
@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org>
 wrote:



=C2=A0 =C2=A0 Hi Filip, 



=C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan <panva.ip@gmail.com> wrot=
e:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > I don't think we need a *_auth_method_* metadata for=
 every endpoint the client calls directly, none of the new specs defined th=
ese (e.g. device authorization endpoint or CIBA), meaning they also didn=
9;t follow the scheme from RFC 8414 where introspection
 and revocation got its own metadata. In most cases the unfortunately named=
 `token_endpoint_auth_method` and its related metadata is what's used b=
y clients for all direct calls anyway.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The same principle could be applied to signing (and encr=
yption) algorithms as well.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This I do not follow, auth methods and their signing is =
dealt with by using `token_endpoint_auth_methods_supported` and `token_endp=
oint_auth_signing_alg_values_supported` - there's no encryption for the=
 `_jwt` client auth methods.


=C2=A0 =C2=A0 > Unless it was meant to address the Request Object signin=
g and encryption metadata, which is defined and IANA registered by OIDC. PA=
R only references JAR section 6.1 and 6.2 for decryption/signature validati=
on and these do not mention the metadata (e.g.
 request_object_signing_alg) anymore since draft 07.



=C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confused somehow. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > PS: I also found this comment related to the same questi=
on about auth metadata but for CIBA.



=C2=A0 =C2=A0 Thanks for sharing. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Best,

=C2=A0 =C2=A0 > Filip



=C2=A0 =C2=A0 thanks,

=C2=A0 =C2=A0 Torsten. 



=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <torsten@lodderst=
edt.net> wrote:

=C2=A0 =C2=A0 > Hi all,

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Ronald just sent me an email asking whether we will defi=
ne metadata for 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_supported and=


=C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_signing_alg_values_su=
pported.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > The draft right now utilises the existing token endpoint=
 authentication methods so there is basically no need to define another par=
ameter. The same principle could be applied to signing (and encryption) alg=
orithms as well.


=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > What=E2=80=99s your opinion?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > best regards,

=C2=A0 =C2=A0 > Torsten.







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








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

OAuth mailing list

OAuth@ietf.org

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








=C2=A0








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000c29085059b801774--


From nobody Mon Jan  6 14:41: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 3C10C120041 for ; Mon,  6 Jan 2020 14:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 sgwCZ7PEbkSv for ; Mon,  6 Jan 2020 14:41:17 -0800 (PST)
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 C3989120020 for ; Mon,  6 Jan 2020 14:41:17 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id t101so8359349pjb.4 for ; Mon, 06 Jan 2020 14:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AY3bA7ZneGDnKCTC35KM7bAFjpkYtgqd9hd88UlUYO8=; b=YELCY534JAZx28GTVZbIGaNnc1ANWnFRbTC9jQLtijovKL9x5ns7j/keWxh2boY2SJ cabq6UdwiHiwg1sabsgyWHrxr7WrAnWe2k0DYnVXfLkVUhp/7X5sOzpIRorfbiMTpDm1 7ldMVP60XC/FnV/7wIFqmWe6L7JZw+YZa/d7RiHgfen2dc8+gD2YLpVYpRnvjbzrcXCp gVrbDSXNZvhVgj1KrVicKzr3OKRmX1iMpL9XQR7P3hFHVfFd/kWjQH+HNIBvHnP9pHU4 8Ls3Ia8c2oybK38FWZ+N+sO5p6C3W9k4QoA9yqASsoPEXzscCOdGpa3F8PkHmMBlVEN6 3XCw==
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=AY3bA7ZneGDnKCTC35KM7bAFjpkYtgqd9hd88UlUYO8=; b=pTnEFxNf5VbGJ8mW6mpXeDd9rJzVLvJsj07+Zj4eba9iHgw0vgfz4X3KajgP+c8hxq H7pucP8zUBEln7tmx8681F6C5zFE4LjfauIK/JJ/W1gytUtvLij+vA7+esUPffqazHS6 lHHutGfNl9ZmCa5p3F+CKFJyaB6znc6ZY9Gy4dda2gq3uVxAQmXnBAW5xQH922NajBiq OGaNsJNOBVOk9VQ2vnp4+i5DoeSGAvHefmwbsarTVj/INhhzUnAvPGM585O8uPAWQAMu 2Xm876ljdJtPS7xpPcgefmVQG1+uzvnpesCufcVT/T5xu7LYqpXMA340HhAvlbZUAFPs aegQ==
X-Gm-Message-State: APjAAAVN/HahIv7HKzSmGQUOhTB9dcw5xrw71In2PckesW2maUhudhyr a/rJgRaimSDrNeb0XRHknyyXocdN88RHW1ruLmko7MPErBjCZ13Mzm459dmjA/f9y5XdKQnyDbV qV4TAo4SFcrCj/g==
X-Google-Smtp-Source: APXvYqzA3r4TxKBHo/XCbmkSqcz43rbl6vB0lZ/jq3UNJ0vcvhEUEf+LqBCF8J87EHHLhankAXFu7cfaxvzq81f/00M=
X-Received: by 2002:a17:90b:309:: with SMTP id ay9mr44081129pjb.22.1578350477041;  Mon, 06 Jan 2020 14:41:17 -0800 (PST)
MIME-Version: 1.0
References:  <8ae305f8-8f57-6d77-a7c0-5c851181319f@ve7jtb.com>   
In-Reply-To: 
From: Rob Otto 
Date: Mon, 6 Jan 2020 22:41:05 +0000
Message-ID: 
To: Jim Willeke 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000083fd33059b805bf2"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 06 Jan 2020 22:41:20 -0000

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

I support adoption

On Mon, 6 Jan 2020 at 22:22, Jim Willeke  wrote:

> I support adoption.
> --
> -jim
> Jim Willeke
>
>
> On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt  wrote:
>
>> I support adoption
>> =E1=90=A7
>>
>> On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote:
>>
>>> I support adoption.
>>>
>>>
>>>
>>> =E2=80=93
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of John Bradley <
>>> ve7jtb@ve7jtb.com>
>>> *Date: *Monday, January 6, 2020 at 12:05 PM
>>> *To: *"oauth@ietf.org" 
>>> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich
>>> Authorization Requests
>>>
>>>
>>>
>>> I support adoption
>>>
>>> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:
>>>
>>> All,
>>>
>>>
>>>
>>> This is a call for adoption for the *OAuth 2.0 Rich Authorization
>>> Requests* document.
>>>
>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>>
>>>
>>>
>>> Please, let us know if you support or object to the adoption of this
>>> document as a working group document by Jan 20th.
>>>
>>>
>>>
>>> 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
>>>
>> _______________________________________________
>> OAuth mailing 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
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

--=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._

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


I support adoption=C2=A0

On Mon, 6 Jan 202=
0 at 22:22, Jim Willeke <jim@willeke.=
com> wrote:
I support adoption.
--
-jim
J=
im Willeke


On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt =
<dick.hardt@gm=
ail.com> wrote:
I support adoption
3D""=E1=90=A7
On=
 Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle <richanna=3D40amazon.com@=
dmarc.ietf.org> wrote:











I support adoption.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of John Bradley <ve7jtb@ve7jtb.com>

Date: Monday, January 6, 2020 at 12:05 PM

To: "oauth@=
ietf.org" <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorizat=
ion Requests






=C2=A0




I support adoption




On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote:








All, 




=C2=A0






This is a call for adoption for the=C2=A0OAuth 2.=
0 Rich Authorization Requests document.







=C2=A0






Please, let us know if you support or object to the =
adoption of this document as a working group document by Jan 20th.






=C2=A0






Regards,






=C2=A0Rifaat & Hannes






=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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Rob Otto
EMEA Field CTO - Ping Identi=
ty 
+44 777 135 6092




<=
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.
--00000000000083fd33059b805bf2--


From nobody Mon Jan  6 14:50: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 B089C12004F for ; Mon,  6 Jan 2020 14:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgsVTAWb73lW for ; Mon,  6 Jan 2020 14:50:29 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA89B120041 for ; Mon,  6 Jan 2020 14:50:28 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id x1so40970297qkl.12 for ; Mon, 06 Jan 2020 14:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=HKyLT7jQzZ7F1829FDIt29PiYqHzbwy0KQVZBs8Nb64=; b=MN+/zPknYjkA6nonBZYPkikwKnovHzeSlvy+UidHms2wnpQChhmfAxPdRlH7RJMnZy Gw3TjdvUKQMzPloBod03/PPyZg8YzPpG1UnvBi7NgHaFdTvoUloP/TnDKeyLsU59zLsM TkI6Mk2p4GQKhIxQaHBpfFGg2ri3c+/Rl8zj0xnqALqfiKvOjWqgg4SePdCgkK5oxy/s Lc7qqGohFrMDKwEFIJEqyT0sOF2HxIW6nfTGfi06GzeK61uwoHzVQhUn5DOBMsEYz5mB odsyLwcQiY9Ga+rh5HDoZAy+i/Y6QTrpjLJ9ORG952Vuu8VwLqyxQAcI5758QfjK8A+C CulA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=HKyLT7jQzZ7F1829FDIt29PiYqHzbwy0KQVZBs8Nb64=; b=GCzFPuMmTCmWtzgAuwRaR9c2d1NLPeAZcq1Fgu0AULjErp7zQ4EOLTyg3zKt/oBTSk 6YxX7WKIqNE6tNrLpM9Sh4XmiTtwpFVYpUXy+Bm12wnPTxcypF2cTbEYtDXUnRWzMlPM Gd12w+3J+M+5Lt/DL31M6xaD42UTgyF6yQiRE6DoiKyAdUGrWD9gMroBykX9icRIgpdj vAheE0+UL+0ZVnRH4hU3kHWfKLauVLcjq4Tnj7WUz4NexZ4/dXeyyxOnxBOLmmrxygic MrxEBpAW4UoO0M8MZuGdB3SobCOHpXUC4thIEJwbCa1SNx/peS1kd/A71d71BXMQCfpj 5gVQ==
X-Gm-Message-State: APjAAAUzATouWK202CeMXejFfeMomJpULiPvanlNHtAzIeTooxI4oMtR NnZxPdNMM5X2eocw9vjiRAFyLsHWhgCbDS+9
X-Google-Smtp-Source: APXvYqzq4xFYj9yjeKcj6Brwrrbx5TehWdM0DCp1JZvBi4EwpABzdLPO7N0S6OUqwSvCPQRb+hbPNA==
X-Received: by 2002:ae9:e306:: with SMTP id v6mr84073777qkf.162.1578351027225;  Mon, 06 Jan 2020 14:50:27 -0800 (PST)
Received: from [192.168.8.103] ([181.203.103.238]) by smtp.gmail.com with ESMTPSA id s20sm21466593qkj.100.2020.01.06.14.50.24 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 14:50:26 -0800 (PST)
To: oauth@ietf.org
References:         <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu>  <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> 
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
Date: Mon, 6 Jan 2020 19:50:21 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5F52908AD45BE247A4282108"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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: Mon, 06 Jan 2020 22:50:34 -0000

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

My take would be that any paramater in the OAuth registy is a OAuth
paramater.

A client could duplicate those outside the request object for some sort
of backwards compatability but they will be ignored.

What we have lost is the merge capability.=C2=A0 There are some use cases=

that could use that to have a presigned object that some paramaters like
state are outside.=C2=A0=C2=A0

That was not popular with the IESG.=C2=A0

John B.

On 1/6/2020 3:04 AM, n-sakimura wrote:
>
> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if
> duplicated.
>
> As of -13 (Mar 30, 2017), it was changed that the server does not have
> to do the merge, at least for OAuth Authorization request parameters.
> It says nothing about other parameters.
>
> As of -14 (Jul 21, 2017), the wording was further strengthened by addin=
g
>
> =C2=A0
>
> The Authorization Server MUST only use the parameters in the Request
> Object even if the same parameter is provided in the query parameter.
>
> =C2=A0
>
> So, the entire 6.3 now became
>
>
>       6.3.=C2=A0
>       Request Parameter Assembly and Validation
>
> =C2=A0=C2=A0 The Authorization Server MUST extract the set of Authoriza=
tion
> =C2=A0=C2=A0 Request parameters from the Request Object value.=C2=A0 Th=
e Authorization
> =C2=A0=C2=A0 Server MUST only use the parameters in the Request Object =
even if the
> =C2=A0=C2=A0 same parameter is provided in the query parameter.=C2=A0 T=
he Authorization
> =C2=A0=C2=A0 Server then validates the request as specified in OAuth 2.=
0
> =C2=A0=C2=A0 [RFC6749 ].
>
> =C2=A0
>
> It says nothing on the non-OAuth parameters that came with the
> authorization request.
>
> My take on the text is that all OAuth Authorization Request parameters
> MUST be in the request object.
>
> Behaviors towards other parameters that happens to have come together
> with the authorization request outside of request object will be
> treated as non-OAuth parameters.
>
> =C2=A0
>
> Nat Sakimura
>
> Research Fellow, Nomura Research Institute
>
> E: n-sakimura@nri.co.jp
>
> T: +81(90)60136276
>
> ---------------------------------------------------------
>
> PLEASE READ:This e-mail is confidential and intended for the named
> recipient only.
>
> If you are not an intended recipient, please notify the sender and
> delete this e-mail.
>
> =C2=A0
>
> *From:*OAuth  *On Behalf Of *Justin Richer
> *Sent:* Friday, January 3, 2020 2:35 AM
> *To:* Takahiko Kawasaki 
> *Cc:* Brian Campbell ;
> oauth ; Nat Sakimura 
> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs
> OIDC request object
>
> =C2=A0
>
> For solution [2], this is the behavior that=E2=80=99s required for OIDC=
 today,
> so I would say that=E2=80=99s the New Client behaving like an Old Clien=
t in
> order to talk to an Old Server. So in reality, (2) causes the request
> to be rejected, and that=E2=80=99s OK.
>
> =C2=A0
>
> I don=E2=80=99t think it=E2=80=99s viable to require parameters to exis=
t inside the
> request object at all times. Nor should we try to enumerate which
> parameters go inside and outside at all times =E2=80=94 at least from t=
he
> JAR/OAuth level of things. I think there are too many things that are
> application and deployment specific for us to make this call. The very
> nature of the request object changes for people =E2=80=94 some have a s=
tatic
> object that=E2=80=99s deployed with clients and some have something tha=
t the
> client creates at runtime for each request.=C2=A0
>
> =C2=A0
>
> If the instead the New Server requires that any parameters duplicated
> between the two places have to match (the OIDC method) or that in a
> conflict the request object values take precedence (the merge method),
> then problems 3-1 and 3-2 go away.=C2=A0
>
> =C2=A0
>
> With the merge-and-precedence behavior, which is what I thought that
> JAR had during WGLC, [3-1] is well-defined. The request is processed
> the same way every time because this is a New Server. The client is
> going to do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=
=9Cmerge with precedence=E2=80=9D is
> effectively a no-op.
>
> =C2=A0
>
> With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen be=
cause
> the required parameters aren=E2=80=99t required to be in the request ob=
ject
> itself. As long as the request object is valid, it protects all
> parameters within it. I don=E2=80=99t think it=E2=80=99s up to us to de=
termine what
> makes sense to put in that object. Security guidance is probably a
> good idea here.
>
> =C2=A0
>
> Solution [3] is what Old Clients already do in OIDC today, so that=E2=80=
=99s
> what already happens and why problem space (3) isn=E2=80=99t a problem.=

>
> =C2=A0
>
> =C2=A0=E2=80=94 Justin
>
>
>
>     On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki      > wrote:
>
>     =C2=A0
>
>     Thank you, Justin. Actually, I wanted to see someone write a
>     summary about what happens in each combination from a viewpoint of
>     both RP and AS with regard to backward compatibility (as I told
>     you in other channel just before you posted your email ^_^).
>
>     So,
>
>     *(1) New Client + New Server*
>     No problem will happen.
>
>     *(2) New Client + Old Server*
>     *[Problem 2-1]* If an authorization request contains 'request' or
>     'request_uri' but doesn't have old mandatory request parameters
>     ('client_id' and 'response_type') outside the request object, the
>     request is rejected.
>
>     *[Solution 2]* New Client should include the old mandatory request
>     parameters duplicately outside the request object. This means that
>     New Client should always send old mandatory request parameters
>     duplicately outside the request object if it wants to get maximum
>     compatibility.
>
>     *(3) Old Client + New Server*
>     *[Problem 3-1]* If an authorization request contains 'request' or
>     'request_uri' and some "optional" request parameters are not
>     included in the request object, AS will interpret the request
>     differently. Imagine what happens when optional parameters such as
>     'scope', 'state', 'nonce', 'redirect_uri', 'response_mode',
>     'max_age', 'acr_values', 'code_challenge', 'code_challenge_method'
>     and 'prompt' are not included in the request object but present
>     outside the request object.
>
>     *[Problem 3-2]* If an authorization request contains 'request' or
>     'request_uri' and some "mandatory" request parameters ('client_id'
>     and 'response_type') are not included in the request object, the
>     request is rejected.
>
>     *[Solution 3]* Old Client should include all request parameters
>     duplicately in the request object. This means that Old Client
>     should always include all request parameters duplicately in the
>     request object if it wants to get maximum compatibility.
>
>     *(4) Old Client + Old Server*
>     No problem will happen.
>
>     - - -
>
>
>     From a Client's point of view, for maximum compatibility, both Old
>     and New Clients should put mandatory request parameters outside
>     the request object and put all request parameters duplicately
>     inside the request object.
>
>     [Problem 3-1] is difficult to detect because the authorization
>     request is not rejected. But, if New Server requires that all
>     request parameters outside the request object be put inside the
>     request object duplicately, [Problem 3-1] is handled as an error
>     and thus client developers can detect the problem.
>
>     Consequently, introducing the following requirement in "FAPI Part
>     2, 5.2.2
>     ,
>     10" to JAR seems a good compromise (as I told before)
>
>         shall require that all parameters are present inside the
>         signed request object passed in the request or request_uri
>         parameter;
>
>
>     instead of just saying "the authorization server supporting this
>     specification MUST only use the parameters included in the request
>     object." which will bring about [Problem 3-1]. That is, how about
>     adding a rule like "if request parameters exist outside the
>     request object, they must exist inside the request object, too."?
>
>     Any thoughts?
>
>     =C2=A0
>
>     Best,
>
>     Taka
>
>     =C2=A0
>
>     =C2=A0
>
>     On Fri, Jan 3, 2020 at 12:48 AM Justin Richer      > wrote:
>
>         I think the nature of the backwards incompatibility is
>         important here. The way that things are now, using
>         merge-with-precedence, you have the following matrix of
>         compatibility:
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New Server =C2=A0=
| =C2=A0Old Server =C2=A0|
>
>         -----------+-------------+--------------+
>
>         New Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0=
 =C2=A0NO =C2=A0 =C2=A0 =C2=A0|
>
>         Old Client | =C2=A0 =C2=A0 =C2=A0YES =C2=A0 =C2=A0| =C2=A0 =C2=A0=
 YES =C2=A0 =C2=A0 =C2=A0|
>
>         =C2=A0
>
>         =C2=A0
>
>         If you ask me, this is the right balance for a breaking
>         change. Old clients, where the vast majority of the code is,
>         don=E2=80=99t have to change. New clients can only talk to serv=
ers
>         with the new features, which is the ability to drop parameters
>         from the external request. This would apply to both OIDC and
>         plain OAuth.
>
>         =C2=A0
>
>         I think we should follow this kind of pattern in the
>         discussions on OAuth 2.1, which I think JAR should be a part of=
/
>
>         =C2=A0
>
>         =C2=A0=E2=80=94 Justin
>
>         =C2=A0
>
>         =C2=A0
>
>
>
>             On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki
>             > wrote:
>
>             =C2=A0
>
>             Breaking backward compatibility in this part would mean
>             that OpenID Certification given to AS implementations with
>             request_uri support will be invalidated once they support
>             JAR. It also would mean that test cases in the official
>             conformance suite need to be changed in a
>             backward-incompatible manner, which would implicitly
>             encourage that all certified implementations should re-try
>             to get certification.
>
>             Changing the spec now might need more three to six months,
>             but it would be worth considering what we get and lose by
>             saving the months and breaking backward compatibility.
>
>             Best Regards,
>             Taka
>
>             =C2=A0
>
>             On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura
>             > wrote:
>
>                 So, no change is OK?=C2=A0
>
>                 =C2=A0
>
>                 On Wed, Dec 11, 2019 at 10:01 PM John Bradley
>                 > wrote:
>
>                     I also slightly prefer the merge approach.=C2=A0
>
>                     =C2=A0
>
>                     There are plusses and minuses to both.=C2=A0
>
>                     =C2=A0
>
>                     Changing again now that it is past ISEG review and
>                     backing out a Discuss will add another three to
>                     six months at this point, if we can get them to
>                     agree to the change.=C2=A0
>
>                     =C2=A0
>
>                     John B.=C2=A0
>
>                     =C2=A0
>
>                     On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura
>                     >
>                     wrote:
>
>                         Correct. The WG supported the precedence
>                         approach and even merge just like OIDC as it
>                         is very useful from the implementation point
>                         of view and helps with a bunch of deployment
>                         patter.=C2=A0
>
>                         =C2=A0
>
>                         The push back came in from the Ben Campbell=E2=80=
=99s
>                         DISCUSS.=C2=A0
>
>                         See=C2=A0
>
>                         https://bitbucket.org/Nat/oauth-jwsreq/issues/7=
0/bc-the-current-text-actually-specifies-the
>
>                         =C2=A0
>
>                         I am willing to go either way as long as
>                         people agree. My slight preference is to the
>                         original approach.=C2=A0
>
>                         =C2=A0
>
>                         Best,=C2=A0
>
>                         =C2=A0
>
>                         Nat Sakimura
>
>                         =C2=A0
>
>                         2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6=
:56 Brian Campbell
>                                                  >:
>
>                             FWIW, as best I can remember the change in
>                             question came as I result of
>                             directorate/IESG review rather than a WG
>                             decision/discussion. Which is likely why
>                             you can't find the "why" anywhere in the
>                             mailing list archive.
>
>                             =C2=A0
>
>                             On Wed, Aug 28, 2019 at 3:23 PM Filip
>                             Skokan                              > wrote:
>
>                                 Well it kind of blows, doesn't it? I
>                                 wasn't able to find the "why" anywhere
>                                 in the mailing list archive around the
>                                 time this was changed.
>
>                                 =C2=A0
>
>                                 My take on satisfying both worlds
>                                 looks like this
>
>                                 =C2=A0
>
>                                 - allow just JAR - no other params
>                                 when possible.
>
>                                 =C2=A0 =C2=A0 (which btw isn't possible=
 to do
>                                 with request_uri when enforcing client
>                                 based uri whitelist and the jwsreq
>                                 5.2.2 shows as much)
>
>                                 - enforce the "dupe behaviours"
>                                 defined in OIDC (if response_type or
>                                 client_id is in request object it must
>                                 either be missing or the same in
>                                 regular request).
>
>                                 - allows merging request object and
>                                 regular parameters with request object
>                                 taking=C2=A0precedence since it is a ve=
ry
>                                 useful feature when having pre-signed
>                                 request object that's not one time use
>                                 and clients using it wish to vary
>                                 state/nonce per-request.
>
>                                 =C2=A0
>
>                                 I wish the group reconsidered making
>                                 this breaking change from OIDC's take
>                                 on request objects - allow combination
>                                 of parameters from the request object
>                                 with ones from regular parameters (if
>                                 not present in request object).
>
>
>                                 S pozdravem,
>                                 *Filip Skokan*
>
>                                 =C2=A0
>
>                                 =C2=A0
>
>                                 On Wed, 28 Aug 2019 at 23:02, Brian
>                                 Campbell                                  >
>                                 wrote:
>
>                                     Filip, for better or worse, I
>                                     believe your assessment of the
>                                     situation is correct. I know of
>                                     one AS that didn't choose which of
>                                     the two to follow but rather
>                                     implemented a bit of a hybrid
>                                     where it basically ignores
>                                     everything outside of the request
>                                     object per JAR but also checks for
>                                     and enforces the presence and
>                                     value of the few regular
>                                     parameters (client_id,
>                                     response_type) that OIDC mandates.
>
>                                     =C2=A0
>
>                                     On Tue, Aug 27, 2019 at 5:47 AM
>                                     Filip Skokan                                      > wrote:=

>
>                                         Hello everyone,
>
>                                         =C2=A0
>
>                                         in an earlier thread I've
>                                         posed the following question
>                                         that might have gotten missed,
>                                         this might have consequences
>                                         for the existing
>                                         implementations of Request
>                                         Objects in OIDC
>                                         implementations - its making
>                                         pure JAR requests incompatible
>                                         with OIDC Core implementations.=

>
>                                         =C2=A0
>
>                                         draft 14 of jwsreq (JAR)
>                                         introduced this language
>
>                                         =C2=A0
>
>                                             The client MAY send the
>                                             parameters included in the
>                                             request object
>                                             duplicated in the query
>                                             parameters as well for the
>                                             backward
>                                             compatibility etc.
>                                             =C2=A0*However, the
>                                             authorization server
>                                             supporting this
>                                             specification MUST only
>                                             use the parameters
>                                             included in the request
>                                             object.=C2=A0*
>
>                                         =C2=A0
>
>                                             Server MUST only use the
>                                             parameters in the Request
>                                             Object even if the
>                                             same parameter is provided
>                                             in the query parameter.=C2=A0=

>                                             The Authorization
>
>                                         =C2=A0
>
>                                             The client MAY send the
>                                             parameters included in the
>                                             request object
>                                             duplicated in the query
>                                             parameters as well for the
>                                             backward
>                                             compatibility etc.
>                                             =C2=A0*However, the
>                                             authorization server
>                                             supporting this
>                                             specification MUST only
>                                             use the parameters
>                                             included in the request
>                                             object..=C2=A0*
>
>                                         =C2=A0
>
>                                         Nat, John, everyone -=C2=A0*doe=
s
>                                         this mean a JAR compliant AS
>                                         ignores everything outside of
>                                         the request object while OIDC
>                                         Request Object one merges the
>                                         two with the ones in the
>                                         request object being used over
>                                         ones that are sent in
>                                         clear?*=C2=A0The OIDC language =
also
>                                         includes sections which make
>                                         sure that some required
>                                         arguments are still passed
>                                         outside of the request object
>                                         with the same value to make
>                                         sure the request is "valid"
>                                         OAuth 2.0 request (client_id,
>                                         response_type), something
>                                         which an example in the JAR
>                                         spec does not do. Not having
>                                         this language means that
>                                         existing authorization request
>                                         pipelines can't simply be
>                                         extended with e.g. a
>                                         middleware, they need to
>                                         branch their codepaths.
>
>                                         =C2=A0
>
>                                         Is an AS required to choose
>                                         which of the two it follows?
>
>                                         =C2=A0
>
>                                         Thank you for clarifying this
>                                         in advance. I think if either
>                                         the behaviour is the same as
>                                         in OIDC or different this
>                                         should be called out in the
>                                         language to avoid confusion,
>                                         especially since this already
>                                         exists in OIDC and likely
>                                         isn't going to be read in
>                                         isolation, especially because
>                                         the Request Object is even
>                                         called out to be already in
>                                         place in OIDC in the JAR draft.=

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

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

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


  
    
  
  
    
My take would be that any paramater in the OAuth registy is a
      OAuth paramater. 

    

    
A client could duplicate those outside the request object for
      some sort of backwards compatability but they will be ignored.

    
What we have lost is the merge capability.  There are some use
      cases that could use that to have a presigned object that some
      paramaters like state are outside.   

    

    
That was not popular with the IESG.  

    

    
John B.

    

    
On 1/6/2020 3:04 AM, n-sakimura wrote:

    

    

      
      
      
      

        
Up
            until -12 (Feb 13, 2017), it was using merge + JAR
            precedence if duplicated.
            

        
As
            of -13 (Mar 30, 2017), it was changed that the server does
            not have to do the merge, at least for OAuth Authorization
            request parameters. It says nothing about other parameters.
            

        
As
            of -14 (Jul 21, 2017), the wording was further strengthened
            by adding
            

        
 

        
The Authorization Server MUST only
            use the parameters in the Request Object even if the same
            parameter is provided in the query parameter.

        
 

        
So,
            the entire 6.3 now became

        
6.3. 
            Request Parameter Assembly and Validation

        
   The Authorization Server MUST extract the set of Authorization

        
   Request parameters from the Request Object value.  The Authorization

        
   Server MUST only use the parameters in the Request Object even if the

        
   same parameter is provided in the query parameter.  The Authorization

        
   Server then validates the request as specified in OAuth 2.0

        
   [RFC6749].

        
 

        
It
            says nothing on the non-OAuth parameters that came with the
            authorization request.
            

        
My
            take on the text is that all OAuth Authorization Request
            parameters MUST be in the request object.
            

        
Behaviors
            towards other parameters that happens to have come together
            with the authorization request outside of request object
            will be treated as non-OAuth parameters.
            

        
 

        

          
Nat Sakimura

          
Research Fellow, Nomura
              Research Institute

          
E: n-sakimura@nri.co.jp

          
T: +81(90)60136276

          
---------------------------------------------------------

          
PLEASE READ:This e-mail is
              confidential and intended for the named recipient only.
              

          
If you are not an intended
              recipient, please notify the sender and delete this
              e-mail.

        

        
 

        

          

            
From: OAuth <oauth-bounces@ietf.org>
                On Behalf Of Justin Richer

                Sent: Friday, January 3, 2020 2:35 AM

                To: Takahiko Kawasaki <taka@authlete.com>

                Cc: Brian Campbell
                <bcampbell=40pingidentity.com@dmarc.ietf.org>;
                oauth <oauth@ietf.org>; Nat Sakimura
                <nat.sakimura@oidf.org>

                Subject: Re: [OAUTH-WG] JWT Secured Authorization
                Request (JAR) vs OIDC request object

          

        

        
 

        

          
For solution [2], this
              is the behavior that’s required for OIDC today, so I would
              say that’s the New Client behaving like an Old Client in
              order to talk to an Old Server. So in reality, (2) causes
              the request to be rejected, and that’s OK.

        

        

          
 

        

        
I don’t think it’s
            viable to require parameters to exist inside the request
            object at all times. Nor should we try to enumerate which
            parameters go inside and outside at all times — at least
            from the JAR/OAuth level of things. I think there are too
            many things that are application and deployment specific for
            us to make this call. The very nature of the request object
            changes for people — some have a static object that’s
            deployed with clients and some have something that the
            client creates at runtime for each request. 

        

          
 

        

        

          
If the instead the New
              Server requires that any parameters duplicated between the
              two places have to match (the OIDC method) or that in a
              conflict the request object values take precedence (the
              merge method), then problems 3-1 and 3-2 go away. 

        

        

          
 

        

        

          
With the
              merge-and-precedence behavior, which is what I thought
              that JAR had during WGLC, [3-1] is well-defined. The
              request is processed the same way every time because this
              is a New Server. The client is going to do OIDC’s
              “duplicate” method, so “merge with precedence” is
              effectively a no-op.

        

        

          
 

        

        

          
With the
              merge-and-precedence behavior, [3-2] doesn’t happen
              because the required parameters aren’t required to be in
              the request object itself. As long as the request object
              is valid, it protects all parameters within it. I don’t
              think it’s up to us to determine what makes sense to put
              in that object. Security guidance is probably a good idea
              here.

        

        

          
 

        

        

          
Solution [3] is what
              Old Clients already do in OIDC today, so that’s what
              already happens and why problem space (3) isn’t a problem.

          

            
 

          

          

            
 — Justin

            

              


                  

                  

              

                

                  
On Jan 2,
                      2020, at 12:24 PM, Takahiko Kawasaki <taka@authlete.com>
                      wrote:

                

                
 

                

                  

                    
Thank you,
                        Justin. Actually, I wanted to see someone write
                        a summary about what happens in each combination
                        from a viewpoint of both RP and AS with regard
                        to backward compatibility (as I told you in
                        other channel just before you posted your email
                        ^_^).

                        

                        So,

                        

                        (1) New Client + New Server

                        No problem will happen.

                        

                        (2) New Client + Old Server

                        [Problem 2-1] If an authorization request
                        contains 'request' or 'request_uri' but doesn't
                        have old mandatory request parameters
                        ('client_id' and 'response_type') outside the
                        request object, the request is rejected.

                        

                        [Solution 2] New Client should include
                        the old mandatory request parameters duplicately
                        outside the request object. This means that New
                        Client should always send old mandatory request
                        parameters duplicately outside the request
                        object if it wants to get maximum compatibility.

                        

                        (3) Old Client + New Server

                        [Problem 3-1] If an authorization request
                        contains 'request' or 'request_uri' and some
                        "optional" request parameters are not included
                        in the request object, AS will interpret the
                        request differently. Imagine what happens when
                        optional parameters such as 'scope', 'state',
                        'nonce', 'redirect_uri', 'response_mode',
                        'max_age', 'acr_values', 'code_challenge',
                        'code_challenge_method' and 'prompt' are not
                        included in the request object but present
                        outside the request object.

                        

                        [Problem 3-2] If an authorization request
                        contains 'request' or 'request_uri' and some
                        "mandatory" request parameters ('client_id' and
                        'response_type') are not included in the request
                        object, the request is rejected.

                        

                        [Solution 3] Old Client should include
                        all request parameters duplicately in the
                        request object. This means that Old Client
                        should always include all request parameters
                        duplicately in the request object if it wants to
                        get maximum compatibility.

                        

                        (4) Old Client + Old Server

                        No problem will happen.

                        

                        - - -

                    

                      


                          From a Client's point of view, for maximum
                          compatibility, both Old and New Clients should
                          put mandatory request parameters outside the
                          request object and put all request parameters
                          duplicately inside the request object.

                          

                          [Problem 3-1] is difficult to detect because
                          the authorization request is not rejected.
                          But, if New Server requires that all request
                          parameters outside the request object be put
                          inside the request object duplicately,
                          [Problem 3-1] is handled as an error and thus
                          client developers can detect the problem.

                          

                          Consequently, introducing the following
                          requirement in "FAPI Part 2, 
                            5.2.2, 10" to JAR seems a good
                          compromise (as I told before)

                      

                        
shall
                            require that all parameters are present
                            inside the signed request object passed in
                            the request or request_uri parameter;

                      

                      


                          instead of just saying "the authorization
                          server supporting this specification MUST only
                          use the parameters included in the request
                          object." which will bring about [Problem 3-1].
                          That is, how about adding a rule like "if
                          request parameters exist outside the request
                          object, they must exist inside the request
                          object, too."?

                          

                          Any thoughts?

                      

                        
 

                      

                      

                        
Best,

                      

                      

                        
Taka

                      

                      

                        
 

                      

                    

                  

                  
 

                  

                    

                      
On Fri,
                          Jan 3, 2020 at 12:48 AM Justin Richer <jricher@mit.edu>
                          wrote:

                    

                    

                      

                        
I think
                            the nature of the backwards incompatibility
                            is important here. The way that things are
                            now, using merge-with-precedence, you have
                            the following matrix of compatibility:

                        

                          
 

                        

                        

                          
 

                        

                        

                          
             New
                              Server  |  Old Server  |

                        

                        

                          
-----------+-------------+--------------+

                        

                        

                          
New Client |    
                               YES    |      NO      |

                        

                        

                          
Old Client |    
                               YES    |     YES      |

                        

                        

                          
 

                        

                        

                          
 

                        

                        

                          
If you
                              ask me, this is the right balance for a
                              breaking change. Old clients, where the
                              vast majority of the code is, don’t have
                              to change. New clients can only talk to
                              servers with the new features, which is
                              the ability to drop parameters from the
                              external request. This would apply to both
                              OIDC and plain OAuth.

                        

                        

                          
 

                        

                        

                          
I
                              think we should follow this kind of
                              pattern in the discussions on OAuth 2.1,
                              which I think JAR should be a part of/

                        

                        

                          
 

                        

                        

                          
 —
                              Justin

                        

                        

                          
 

                        

                        

                          
 

                          

                            


                                

                                

                            

                              

                                
On
                                    Jan 2, 2020, at 3:40 AM, Takahiko
                                    Kawasaki <taka@authlete.com>
                                    wrote:

                              

                              
 

                              

                                

                                  
Breaking backward
                                      compatibility in this part would
                                      mean that OpenID Certification
                                      given to AS implementations with
                                      request_uri support will be
                                      invalidated once they support JAR.
                                      It also would mean that test cases
                                      in the official conformance suite
                                      need to be changed in a
                                      backward-incompatible manner,
                                      which would implicitly encourage
                                      that all certified implementations
                                      should re-try to get
                                      certification.

                                      

                                      Changing the spec now might need
                                      more three to six months, but it
                                      would be worth considering what we
                                      get and lose by saving the months
                                      and breaking backward
                                      compatibility.

                                      

                                      Best Regards,

                                      Taka

                                

                                
 

                                

                                  

                                    
On Wed, Dec 18,
                                        2019 at 4:14 PM Nat Sakimura
                                        <sakimura@gmail.com>
                                        wrote:

                                  

                                  

                                    

                                      
So, no change is
                                          OK? 

                                    

                                    
 

                                    

                                      

                                        
On Wed, Dec 11,
                                            2019 at 10:01 PM John
                                            Bradley <ve7jtb@ve7jtb.com>
                                            wrote:

                                      

                                      

                                        

                                          
I also
                                              slightly prefer the merge
                                              approach. 

                                          

                                            
 

                                          

                                          

                                            
There are
                                                plusses and minuses to
                                                both. 

                                          

                                          

                                            
 

                                          

                                          

                                            
Changing
                                                again now that it is
                                                past ISEG review and
                                                backing out a Discuss
                                                will add another three
                                                to six months at this
                                                point, if we can get
                                                them to agree to the
                                                change. 

                                          

                                          

                                            
 

                                          

                                          

                                            
John B. 

                                          

                                        

                                        
 

                                        

                                          

                                            
On Tue, Dec
                                                10, 2019, 11:29 PM Nat
                                                Sakimura <sakimura@gmail.com>
                                                wrote:

                                          

                                          

                                            

                                              

                                                

                                                  
Correct.
                                                      The WG supported
                                                      the precedence
                                                      approach and even
                                                      merge just like
                                                      OIDC as it is very
                                                      useful from the
                                                      implementation
                                                      point of view and
                                                      helps with a bunch
                                                      of deployment
                                                      patter. 

                                                

                                              

                                              

                                                
 

                                              

                                              

                                                
The
                                                    push back came in
                                                    from the Ben
                                                    Campbell’s DISCUSS. 

                                              

                                              

                                                
See 

                                                
                                                

                                                  
 

                                                

                                                

                                                  
I am
                                                      willing to go
                                                      either way as long
                                                      as people agree.
                                                      My slight
                                                      preference is to
                                                      the original
                                                      approach. 

                                                

                                                

                                                  
 

                                                

                                                

                                                  
Best, 

                                                

                                                

                                                  
 

                                                

                                                

                                                  
Nat
                                                      Sakimura

                                                

                                              

                                              

                                                
 

                                                

                                                  

                                                    
2019年8月29日(木)
                                                        6:56 Brian
                                                        Campbell
                                                        <bcampbell=40pingidentity..com@dmarc.ietf.org>:

                                                  

                                                

                                              

                                            

                                            

                                              

                                                

                                                  

                                                    

                                                      
FWIW,
                                                          as best I can
                                                          remember the
                                                          change in
                                                          question came
                                                          as I result of
directorate/IESG review rather than a WG decision/discussion. Which is
                                                          likely why you
                                                          can't find the
                                                          "why" anywhere
                                                          in the mailing
                                                          list archive.
                                                          

                                                    

                                                    
 

                                                    

                                                      

                                                        
On
                                                          Wed, Aug 28,
                                                          2019 at 3:23
                                                          PM Filip
                                                          Skokan <panva.ip@gmail.com>
                                                          wrote:

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          

                                                          
Well
                                                          it kind of
                                                          blows, doesn't
                                                          it? I wasn't
                                                          able to find
                                                          the "why"
                                                          anywhere in
                                                          the mailing
                                                          list archive
                                                          around the
                                                          time this was
                                                          changed.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
My
                                                          take on
                                                          satisfying
                                                          both worlds
                                                          looks like
                                                          this

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
-
                                                          allow just JAR
                                                          - no other
                                                          params when
                                                          possible.

                                                          

                                                          

                                                          
 
                                                            (which btw
                                                          isn't possible
                                                          to do with
                                                          request_uri
                                                          when enforcing
                                                          client based
                                                          uri whitelist
                                                          and the jwsreq
                                                          5.2.2 shows as
                                                          much)

                                                          

                                                          

                                                          
-
                                                          enforce the
                                                          "dupe
                                                          behaviours"
                                                          defined in
                                                          OIDC (if
                                                          response_type
                                                          or client_id
                                                          is in request
                                                          object it must
                                                          either be
                                                          missing or the
                                                          same in
                                                          regular
                                                          request).

                                                          

                                                          

                                                          
-
                                                          allows merging
                                                          request object
                                                          and regular
                                                          parameters
                                                          with request
                                                          object
                                                          taking precedence
                                                          since it is a
                                                          very useful
                                                          feature when
                                                          having
                                                          pre-signed
                                                          request object
                                                          that's not one
                                                          time use and
                                                          clients using
                                                          it wish to
                                                          vary
                                                          state/nonce
                                                          per-request.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
I
                                                          wish the group
                                                          reconsidered
                                                          making this
                                                          breaking
                                                          change from
                                                          OIDC's take on
                                                          request
                                                          objects -
                                                          allow
                                                          combination of
                                                          parameters
                                                          from the
                                                          request object
                                                          with ones from
                                                          regular
                                                          parameters (if
                                                          not present in
                                                          request
                                                          object).

                                                          

                                                          


                                                          

                                                          

                                                          

                                                          
S
                                                          pozdravem,

                                                          Filip
                                                          Skokan

                                                          

                                                          

                                                          
 

                                                        

                                                        
 

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          

                                                          
On
                                                          Wed, 28 Aug
                                                          2019 at 23:02,
                                                          Brian Campbell
                                                          <bcampbell@pingidentity.com>
                                                          wrote:

                                                          

                                                        

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
Filip,
                                                          for better or
                                                          worse, I
                                                          believe your
                                                          assessment of
                                                          the situation
                                                          is correct. I
                                                          know of one AS
                                                          that didn't
                                                          choose which
                                                          of the two to
                                                          follow but
                                                          rather
                                                          implemented a
                                                          bit of a
                                                          hybrid where
                                                          it basically
                                                          ignores
                                                          everything
                                                          outside of the
                                                          request object
                                                          per JAR but
                                                          also checks
                                                          for and
                                                          enforces the
                                                          presence and
                                                          value of the
                                                          few regular
                                                          parameters
                                                          (client_id,
                                                          response_type)
                                                          that OIDC
                                                          mandates.
                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
On
                                                          Tue, Aug 27,
                                                          2019 at 5:47
                                                          AM Filip
                                                          Skokan <panva.ip@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          

                                                          
Hello
                                                          everyone,

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
in
                                                          an earlier
                                                          thread I've
                                                          posed the
                                                          following
                                                          question that
                                                          might have
                                                          gotten missed,
                                                          this might
                                                          have
                                                          consequences
                                                          for the
                                                          existing
                                                          implementations
                                                          of Request
                                                          Objects in
                                                          OIDC
                                                          implementations
                                                          - its making
                                                          pure JAR
                                                          requests
                                                          incompatible
                                                          with OIDC Core
implementations.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
draft
                                                          14 of jwsreq
                                                          (JAR)
                                                          introduced
                                                          this language

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
The client MAY send the parameters
                                                          included in
                                                          the request
                                                          object

                                                          duplicated in
                                                          the query
                                                          parameters as
                                                          well for the
                                                          backward

                                                          compatibility
                                                          etc.  However,
                                                          the
                                                          authorization
                                                          server
                                                          supporting
                                                          this

                                                          specification
                                                          MUST only use
                                                          the parameters
                                                          included in
                                                          the request

                                                          object. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Server
                                                          MUST only use
                                                          the parameters
                                                          in the Request
                                                          Object even if
                                                          the

                                                          same parameter
                                                          is provided in
                                                          the query
                                                          parameter. 
                                                          The
                                                          Authorization

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
The client MAY send the parameters
                                                          included in
                                                          the request
                                                          object

                                                          duplicated in
                                                          the query
                                                          parameters as
                                                          well for the
                                                          backward

                                                          compatibility
                                                          etc.  However,
                                                          the
                                                          authorization
                                                          server
                                                          supporting
                                                          this

                                                          specification
                                                          MUST only use
                                                          the parameters
                                                          included in
                                                          the request

                                                          object.. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Nat,
                                                          John, everyone
                                                          - does this
                                                          mean a JAR
                                                          compliant AS
                                                          ignores
                                                          everything
                                                          outside of the
                                                          request object
                                                          while OIDC
                                                          Request Object
                                                          one merges the
                                                          two with the
                                                          ones in the
                                                          request object
                                                          being used
                                                          over ones that
                                                          are sent in
                                                          clear? The
                                                          OIDC language
                                                          also includes
                                                          sections which
                                                          make sure that
                                                          some required
                                                          arguments are
                                                          still passed
                                                          outside of the
                                                          request object
                                                          with the same
                                                          value to make
                                                          sure the
                                                          request is
                                                          "valid" OAuth
                                                          2.0 request
                                                          (client_id,
                                                          response_type),
                                                          something
                                                          which an
                                                          example in the
                                                          JAR spec does
                                                          not do. Not
                                                          having this
                                                          language means
                                                          that existing
                                                          authorization
                                                          request
                                                          pipelines
                                                          can't simply
                                                          be extended
                                                          with e.g. a
                                                          middleware,
                                                          they need to
                                                          branch their
                                                          codepaths.

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Is
                                                          an AS required
                                                          to choose
                                                          which of the
                                                          two it
                                                          follows?

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Thank
                                                          you for
                                                          clarifying
                                                          this in
                                                          advance. I
                                                          think if
                                                          either the
                                                          behaviour is
                                                          the same as in
                                                          OIDC or
                                                          different this
                                                          should be
                                                          called out in
                                                          the language
                                                          to avoid
                                                          confusion,
                                                          especially
                                                          since this
                                                          already exists
                                                          in OIDC and
                                                          likely isn't
                                                          going to be
                                                          read in
                                                          isolation,
                                                          especially
                                                          because the
                                                          Request Object
                                                          is even called
                                                          out to be
                                                          already in
                                                          place in OIDC
                                                          in the JAR
                                                          draft.

                                                          

                                                          
 

                                                          

                                                          

                                                          
Best,

                                                          

                                                          

                                                          
Filip

                                                          

                                                          

                                                          

                                                          
_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          
 

                                                          

                                                        

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          

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

                                                          

                                                        

                                                      

                                                    

                                                    


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

                                                        OAuth mailing
                                                        list

                                                        OAuth@ietf.org

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

                                                  

                                                

                                              

                                            

                                            
-- 

                                            

                                              
Nat
                                                  Sakimura (=nat)

                                              

                                                
Chairman,
                                                    OpenID Foundation

                                                    http://nat.sakimura.org/

                                                    @_nat_en

                                              

                                            

                                            
_______________________________________________

                                                OAuth mailing list

                                                OAuth@ietf.org

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

                                          

                                        

                                      

                                    

                                    


                                        

                                    

                                      
 

                                    

                                    
-- 

                                    

                                      
Nat Sakimura
                                          (=nat)

                                      

                                        
Chairman,
                                            OpenID Foundation

                                            http://nat.sakimura.org/

                                            @_nat_en

                                      

                                    

                                    
_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

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

                                  

                                

                                
_______________________________________________

                                    OAuth mailing list

                                    OAuth@ietf.org

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

                              

                            

                          

                          
 

                        

                      

                    

                  

                

              

            

            
 

          

        

      

      

      

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


    

  


--------------5F52908AD45BE247A4282108--


From nobody Tue Jan  7 01: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 BCB0112008D for ; Tue,  7 Jan 2020 01:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CfumjZpX7xKl for ; Tue,  7 Jan 2020 01:19:23 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B3612081F for ; Tue,  7 Jan 2020 01:19:22 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id z7so52959679wrl.13 for ; Tue, 07 Jan 2020 01:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=SLPVLz3zSiP9N67zHlNnAokTUQ6tIFFY75PnE+OpArk=; b=r8YIw10Dn6az4F8OfYop8yWD8A+V4LqXDtQdGUfB/nWEZNkjgY06BbXAE31sKfJwLU TBWM4Bj1I/5sGUPqqbkvupiRAHWQesvoqtLkNw23cwUqXjlyZ76wC4gL0CV+2tvw/d3W r/dvY/HQYfjaIoCqnzK2OJsGWXxazf5t8ZT/W5W3r9Tv2GavO/QT2iEFKWs8kpk/Ljsl +98LpSAe8ZYEG7kEVkrfZnKN+OWr3ubdlB08xfYI2Cwa+8sGNtJntj9JWSeAFge7RIBY heMO5MyMnNbihsd9wVfh7SHMpr4vkQrLZGzQ11oPw18im55LAXQvPMs96Oc1ztroS6NT +eWQ==
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=SLPVLz3zSiP9N67zHlNnAokTUQ6tIFFY75PnE+OpArk=; b=bcpv8+NMe/UHiYCk9HfvCALPtk/fQU49jvwM+O0JlWKHwOhzZzPVx8pTzPcn90+0au yKblFU8F6jN95U1jNHqaG/TciFmOQ++pMWM2azHyFZaVDR5tFQjaOCj7A0q3IIcGCTWG 6ksG43GkxzDnOeFB5mv55JWwpb7mtMu6Plzy+KV5v8QbMVrP+ZUoTTtt+FUlr2eiG0Pj 7u92t34Y89Kg7ohyM1TcwzWOiil0ZMD2+1FDXHKcRdCMoPoEFCIjnGNa1ocg3D/zw1o2 Lxbg+vkl4uvfByS7f9Y0Rpc8IR44kXPh5XG28sOsYyTwvvI+Q3/rTGW0spfk6ptJxUCs hW0A==
X-Gm-Message-State: APjAAAVhrOA/1Mr4YTV01NCdd6W97zRRS5bt4YC3WoJXGm1vEZ6wGAds A6c9+s0JzL/lbXbtBoDlnqDMVva/X/udG4WX
X-Google-Smtp-Source: APXvYqz5se6EOe3P8AyhnnKvbKYrNDdKQ1Vw+H5iosQ5ueLkrLgYmriOW3A/rbq+WwX7TglAzE3SFg==
X-Received: by 2002:a5d:6551:: with SMTP id z17mr113884975wrv.269.1578388760994;  Tue, 07 Jan 2020 01:19:20 -0800 (PST)
Received: from [10.30.2.24] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id m7sm25783612wma.39.2020.01.07.01.19.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 01:19:20 -0800 (PST)
Content-Type: multipart/signed; boundary=Apple-Mail-EA73AA6C-7051-429B-B30E-5C2CF6CE62EA; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Tue, 7 Jan 2020 10:19:19 +0100
Message-Id: <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
Cc: oauth@ietf.org
In-Reply-To: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
To: John Bradley 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 07 Jan 2020 09:19:27 -0000

--Apple-Mail-EA73AA6C-7051-429B-B30E-5C2CF6CE62EA
Content-Type: multipart/alternative;
	boundary=Apple-Mail-F419CA97-5AE9-4FCE-B2E2-178A61CF1211
Content-Transfer-Encoding: 7bit


--Apple-Mail-F419CA97-5AE9-4FCE-B2E2-178A61CF1211
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 06.01.2020 um 23:50 schrieb John Bradley :
>=20
> A client could duplicate those outside the request object for some sort of=
 backwards compatability but they will be ignored.
>=20
Is this used for backward compatibility with the OIDC servers?
> What we have lost is the merge capability.  There are some use cases that c=
ould use that to have a presigned object that some paramaters like state are=
 outside. =20
>=20

Is this option used in the wild? As far as I understand the main use case is=
 a 3rd party signing the request object that way entitling the client for so=
mething. I=E2=80=98m asking since in my experience any kind of entitlement b=
y a 3rd party is handled behind the scene using registries.=

--Apple-Mail-F419CA97-5AE9-4FCE-B2E2-178A61CF1211
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Am 06.01.2020 um 23:50 schrieb John Bradley &=
lt;ve7jtb@ve7jtb.com>:

A client could duplicate those outside the request obj=
ect for
      some sort of backwards compatability but they will be ignored.
Is this used for backward compatibility with the OIDC se=
rvers?

    
What we have lost is the merge capability.  There are some use
      cases that could use that to have a presigned object that some
      paramaters like state are outside.   
=

Is this option used in the wild? As far as I understand the main us=
e case is a 3rd party signing the request object that way entitling the clie=
nt for something. I=E2=80=98m asking since in my experience any kind of enti=
tlement by a 3rd party is handled behind the scene using registries.
=

--Apple-Mail-F419CA97-5AE9-4FCE-B2E2-178A61CF1211--

--Apple-Mail-EA73AA6C-7051-429B-B30E-5C2CF6CE62EA
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0
aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTA3MDkxOTE5WjAv
BgkqhkiG9w0BCQQxIgQgxjdWQK3YaJNlrtuLhWEvhyL64aWFT0FadyInkU3vmWswgb0GCSsGAQQB
gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ
MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0
aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH
21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv
IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQAaff8Z
JsHKRbBvn/L3i44BWYE66cg7c/EPAb6tKM69FCsXDDAwQHbCaCG78xLKAvPpX4WKQa4BI8v0bzgd
2koHw0RPO7lXAEAcZWUAfpRT8gPsHFrRLdPZmt6PK7rRK4zqYL1hxwI+v7jCBu56ta/uMs/hRijz
i7jsHErvsM6CdSs6PaK5IpBlj8z1hmE6vc2Y8Kp+Elvhq4mcteSjBenRXBH4RPED/Lwk4rZpMfj3
HJwIv926sKSY2UGyLaORTIc4nXNBmUqkiMY8H5SNfEYqvfqjsd0Myn1AIhv9C5M9wqfaOHClO9m2
q5crT+3x095XdYN0VWo93tBtZ1EpX3ChAAAAAAAA
--Apple-Mail-EA73AA6C-7051-429B-B30E-5C2CF6CE62EA--


From nobody Tue Jan  7 05:11: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 E7BA01200F9 for ; Tue,  7 Jan 2020 05:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 jbMS6F5FNYws for ; Tue,  7 Jan 2020 05:11:54 -0800 (PST)
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 4F4DA1200F1 for ; Tue,  7 Jan 2020 05:11:54 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id ooeGiODAFRLiQooeHimRsX; Tue, 07 Jan 2020 06:11:53 -0700
To: oauth@ietf.org
References: 
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Tue, 7 Jan 2020 15:11:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070407080909080806030906"
X-CMAE-Envelope: MS4wfExZfS61fSmusRrmbO4LnlkbdKRkO6IyOnhYlzoySmX51GVCTihFU5VbE8D54bGcsBHtJGQ8GaQkiU669g+BGpDuvja+yc15TY7tQiGdClYsPiCjW4mY colMk0es28DDYtc3MNGwM2InT/tsZYex5x6GUSCBEHXRR0zJ1CWppXem
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 13:11:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms070407080909080806030906
Content-Type: multipart/alternative;
 boundary="------------23A6FA99228A7C54AF9E3ECB"
Content-Language: en-US

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

+1 for the adoption of RAR

On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
> This is a call for adoption for the=C2=A0*OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/=C2=A0


--------------23A6FA99228A7C54AF9E3ECB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
+1 for the adoption of RAR

    

    
On 06/01/2020 21:37, Rifaat Shekh-Yuse=
f
      wrote:

    

    

      
This is a call for adoption for the=C2=A0OAuth 2.0 Rich
          Authorization Requests document.

      
    

    

  


--------------23A6FA99228A7C54AF9E3ECB--

--------------ms070407080909080806030906
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDcxMzExNTFaMC8G
CSqGSIb3DQEJBDEiBCDOieiN0e5FLRcycOEeXHf7gOFZVwAsdAlyM0GtdUhZfzBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAIEQKaB7rWKoaSdtLDl5v0NSj0kvnsMkoaxoEhlUBH4dKAc+
Eb6VoitU9hJK+ivzx9TLwWVAeuVfMY7wXpOENXGv3vSwC/TDIPTQDHzM7psPlEuwECZEnXXt
ODixlx9aHRQRJq4D9Yz2JH+dtg3JZzsZbdaqRg8hSloCS0xs+PMwN7dRv02Q2gXj+safOlrp
02UUsisuLw8CakjconWqkRHiVJigBHxW8x2O3WWS6TRVUNTmEAEuxfhKHPsGH6COxmqbQxsL
ImnDNzUyYYCu8N+H+mwrD5GNlGAzMec5OAk/fJaZl6K6L00hlmlUCcG3pn0iGlDWnEOskHy9
aTRugQUAAAAAAAA=
--------------ms070407080909080806030906--


From nobody Tue Jan  7 05:17: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 858A612088B for ; Tue,  7 Jan 2020 05:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 rd2hfqo3r2K8 for ; Tue,  7 Jan 2020 05:17:31 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D799512081B for ; Tue,  7 Jan 2020 05:17:30 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 3D2B413394 for ; Tue,  7 Jan 2020 13:17:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578403049; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P3D09B/Z2NeJel3QUZu+hDGmOVEckTCtuiBAaHFf4CY=; b=CVb8vnbObWTELSPPmRk7i+htFPryCHDkmH+SJDQqz/ntTmdV/ob4cT5aMrWta6kAAAeItE HCn51jCTXOcu/PhdNjj3Ffr9MqSAJjK9GBk4nwZsUJ7QJDbUY2iCzm/hlP/fXpkexGp8mZ DX2TlF+eXESt1FePKzmYwPArdl4huY8=
To: oauth@ietf.org
References: 
From: Daniel Fett 
Message-ID: <27441258-91ba-2ccf-549f-c7f0ca640e21@danielfett.de>
Date: Tue, 7 Jan 2020 14:17:28 +0100
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------42F358C6912511A1A7203B7C"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1578403049; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P3D09B/Z2NeJel3QUZu+hDGmOVEckTCtuiBAaHFf4CY=; b=cC8Sx2JzvFwg7K8HSifRxt7JR9gP7lAMkwPkOn2w9OwunWUlTVG/0bxYaAEysqHUgaZCME 1BFbz0h6krMoJte5wJUHRbvZFaWmTmCOp/k+XhfDdPshGT7i9Hqnti85KccW3hSXSV9UYv 0nyDwMOO+6dCDVN0fHKGGM4LfzWlIag=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1578403049; a=rsa-sha256; cv=none; b=UPfmp6IDi5CZ2lJUI905GavGtPrSCnACs+399qlAZyOMyErQrnZhlV11z7qaPGthFgU6mwAGUYVHK8ZPNMWZ/azfXDzuEK0V9TqATFA73foGG789YZ0jolIALHu5+Q1ygcHjnwhtR6j4EC42mnlstIuYcUoS9X1wOUAlXOTfEQ0=
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] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 13:17:35 -0000

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

I support the adoption.

Am 06.01.20 um 20:37 schrieb Rifaat Shekh-Yusef:
> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 
>  
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
I support the adoption.

    

    


    

    
Am 06.01.20 um 20:37 schrieb Rifaat
      Shekh-Yusef:

    

    

      
      
All,
        


        

        
This is a call for adoption for the OAuth 2.0 Rich
            Authorization Requests document.

        
        
 

        
Please, let us know if you support or object to the
          adoption of this document as a working group document by Jan
          20th.

        

        


        

        
Regards,

        

        
 Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  


--------------42F358C6912511A1A7203B7C--


From nobody Tue Jan  7 05:52: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 184CB12011A for ; Tue,  7 Jan 2020 05:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 smZ0_7kgHYEl for ; Tue,  7 Jan 2020 05:52:33 -0800 (PST)
Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (p3plsmtpa12-02.prod.phx3.secureserver.net [68.178.252.231]) (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 2B12C1200E9 for ; Tue,  7 Jan 2020 05:52:33 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id opHaiwnmHs2NwopHaiZAzI; Tue, 07 Jan 2020 06:52:32 -0700
x-spam-cmae: v=2.3 cv=JuePU/wC c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=UM_DoP-0AAAA:8 a=LS6YZpeZAAAA:8 a=vggBfdFIAAAA:8 a=DVqm7IH0AAAA:8 a=-B3230MOAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=zvdvULNK0xZ1Tri_YggA:9 a=g3h1NsT9v-OIhxyP:21 a=csjWvlk9K9UJs1uO:21 a=QEXdDO2ut3YA:10 a=Vgch6RCDSuUB2R3XadcA:9 a=EpaHqHgTW3DnIvNI:21 a=PJWGSt-UJUkvXphM:21 a=z9DqSue7_R21iJuD:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=TEVHQOIvcflanWNqQbWu:22 a=IRr2vCDBpksuBOXhfkKu:22 a=M6wP_kGduNurgptF5PJY:22 a=Z6yIbYtmj3_f4zpjOCXI:22 a=IdGyktwZ2tr74praB_5u:22 a=w1C3t2QeGrPiZgrLijVG:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
To: "Richard Backman, Annabelle" , Neil Madden , Brian Campbell 
Cc: Dave Tonge , oauth , Nat Sakimura 
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <622f3321-dcd0-b118-c2c9-10d9169b93c1@connect2id.com>
Date: Tue, 7 Jan 2020 15:52:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080802020300040501050505"
X-CMAE-Envelope: MS4wfIiiBoMpUour1+cYqnsJcgu09v76uI3KdArCD7uB2Zk5QqKl28dzjzz3HPsqW+o8FEFltygmukJHA+UE8+v5+STyG2QUpoUbSIBxvRyv9KcCWcn+6yEN nlODl0Xl116LzTy2QYRO9wrmnX4ZVIIH/r5y6Ylyu4nHLSoArKAMnKrxK7PuRquxU7V/IDprglyKHXwCxeoadzGCDjeVsX5rSe0rvB9hFBtJPbikFC8rSZ+v swNFUqg4O/8qrAl4y2YoDjg/zrJFjZIjMJ6fXplISlxHMB899dcnST5YCIreFFeIXTwr1Ogcr0OOBxXe2yEICdJB8YNq+fxGq8+aabCqVJs9lexNRAnhOGU3 aaiJzKbr
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 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: Tue, 07 Jan 2020 13:52:36 -0000

This is a cryptographically signed message in MIME format.

--------------ms080802020300040501050505
Content-Type: multipart/alternative;
 boundary="------------7B702B2CD4B1F9873969A547"
Content-Language: en-US

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

Just to comment that with a lightweight PAR (stash-only) endpoint one of
the nice benefits of PAR will be lost - to pre-validate the request
(client_id, redirect_uri, etc) as much as possible before a front-end
call is made and the user is sent to the authZ endpoint.

Vladimir

On 06/01/2020 23:59, Richard Backman, Annabelle wrote:
>
> The issue isn=E2=80=99t that the PAR endpoint needs access to one speci=
fic
> request object decryption key that could reasonably be shared across
> AS endpoints, but that it actually needs access to the private keys
> for all encryption public keys in the JWK set pointed to by the AS=E2=80=
=99s
> jwks_uri metadata property. Since there is no way to designate one
> particular key as the one to use for encrypting request objects,
> clients may reasonably use any encryption public key in the JWK set to
> encrypt a request object. As one example of how this could expose
> sensitive data to the PAR endpoint, if the PAR endpoint has all the
> decryption keys for the keys in the AS=E2=80=99s JWK set, it would be a=
ble to
> decrypt ID Tokens sent in id_token_hint request parameters. As more
> and more use cases develop for encrypting blobs for the AS, this issue
> will only get worse.
>
> =C2=A0
>
> The PAR endpoint can=E2=80=99t simply stash the encrypted request objec=
t, as
> it is required to verify the request, according to =C2=A72.1:
>
> =C2=A0
>
> The AS MUST process the request as follows:
> =C2=A0
> ...
> =C2=A0
> 3.=C2=A0 The AS MUST validate the request in the same way as at the
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorization en=
dpoint. ...
> =C2=A0
>
> This language needs to be more flexible, IMHO, to allow for
> lightweight PAR endpoints that may not have the information or
> authority needed to perform all the validation that happens at the
> authorization endpoint. I need to think about this more before I can
> say if it would adequately address my concerns, but it=E2=80=99d be a g=
ood
> start and makes sense in its own right.
>
> =C2=A0
>
> I think it=E2=80=99s pretty risky for us to base decision on an assumpt=
ion
> that no one is going to need or want to encrypt pushed request
> objects, particularly when they=E2=80=99re JWTs, and JWTs have well
> established support for encryption, and encrypted JWTs are supported
> by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you
> insist, here are a few examples for why someone might want to do this:
>
>  1. The request object is passed by reference, and accessible on the
>     public Internet.
>  2. The request object contains sensitive transaction-related data in
>     RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=
=80=99t need to
>     have access to.
>  3. The AS requires request object encryption to minimize exposure to
>     the hosted PAR endpoint service it uses.
>  4. #2, but the threat vector is gaps in end-to-end TLS.
>  5. Any of the above, but the concern is message integrity, and the AS
>     requires requested objects to be encrypted for confidentiality and
>     integrity protection and does not support signed request objects.
>
> =C2=A0
>
> =E2=80=93=C2=A0
>
> Annabelle Richard Backman
>
> AWS Identity
>
> =C2=A0
>
> =C2=A0
>
> *From: *Neil Madden 
> *Date: *Monday, January 6, 2020 at 6:29 AM
> *To: *Brian Campbell 
> *Cc: *"Richard Backman, Annabelle" , Nat Sakimura
> , Dave Tonge , Torsten
> Lodderstedt , oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
> =C2=A0
>
> Agreed.
>
> =C2=A0
>
> In addition, I'm not sure why the PAR endpoint would need access to
> the decryption keys at all. If you're using encrypted request objects
> then the PAR endpoint receives an encrypted JWT and then later makes
> the same (still encrypted) JWT available to the authorization
> endpoint. If the PAR endpoint is doing any kind of decryption or
> validation on behalf of the authorization endpoint then they are
> clearly not in separate trust boundaries.
>
> =C2=A0
>
> -- Neil
>
> =C2=A0
>
>
>
>     On 6 Jan 2020, at 13:57, Brian Campbell
>          > wrote:
>
>     =C2=A0
>
>     I really struggle to see the assumption that an entity be able to
>     use the same key to decrypt the same type of message ultimately
>     intended for the same purpose as an artificial limit. The same
>     general assumption =C2=A0 underlies everything else in OAuth/OIDC
>     (Vladimir's post points to some but not all examples of such).
>     There's no reason for PAR to make a one-off exception. And should
>     there be some deployment specific reason that truly requires that
>     kind of isolation, there are certainly implementation options that
>     aren't compatibility-breaking. And having said all that, I'm
>     honestly a little surprised anyone is thinking much about
>     encrypted request objects with PAR as, at least with my limited
>     imagination, there's not really a need for it.
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     =C2=A0
>
>     On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle
>          > wrote:
>
>         PAR introduces an added wrinkle for encrypted request objects:
>         the PAR endpoint and authorization endpoint may not have
>         access to the same cryptographic keys, even though they're
>         both part of the "authorization server." Since they're
>         different endpoints with different roles, it's reasonable to
>         put them in separate trust boundaries. There is no way to
>         support this isolation with just a single "jwks_uri" metadata
>         property.
>
>         The two options that I see are:
>
>         1. Define a new par_jwks_uri metadata property.
>         2. Explicitly state that this separation is not supported.
>
>         I strongly perfer #1 as it has a very minor impact on
>         deployments that don't care (i.e., they just set par_jwks_uri
>         and jwks_uri to the same value) and failing to support this
>         trust boundary creates an artificial limit on implementation
>         architecture and could lead to compatibility-breaking workaroun=
ds.
>
>         =E2=80=93
>         Annabelle Richard Backman
>         AWS Identity
>
>
>         On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt"
>          on
>         behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org
>         > wrote:
>
>         =C2=A0 =C2=A0 Hi Filip,
>
>         =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan
>         > wrote:
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > I don't think we need a *_auth_method_* metadat=
a for
>         every endpoint the client calls directly, none of the new
>         specs defined these (e.g. device authorization endpoint or
>         CIBA), meaning they also didn't follow the scheme from RFC
>         8414 where introspection and revocation got its own metadata.
>         In most cases the unfortunately named
>         `token_endpoint_auth_method` and its related metadata is
>         what's used by clients for all direct calls anyway.
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > The same principle could be applied to signing =
(and
>         encryption) algorithms as well.
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > This I do not follow, auth methods and their si=
gning is
>         dealt with by using `token_endpoint_auth_methods_supported`
>         and `token_endpoint_auth_signing_alg_values_supported` -
>         there's no encryption for the `_jwt` client auth methods.
>         =C2=A0 =C2=A0 > Unless it was meant to address the Request Obje=
ct
>         signing and encryption metadata, which is defined and IANA
>         registered by OIDC. PAR only references JAR section 6.1 and
>         6.2 for decryption/signature validation and these do not
>         mention the metadata (e.g. request_object_signing_alg) anymore
>         since draft 07.
>
>         =C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confused s=
omehow.
>
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > PS: I also found this comment related to the sa=
me
>         question about auth metadata but for CIBA.
>
>         =C2=A0 =C2=A0 Thanks for sharing.
>
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > Best,
>         =C2=A0 =C2=A0 > Filip
>
>         =C2=A0 =C2=A0 thanks,
>         =C2=A0 =C2=A0 Torsten.
>
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderste=
dt
>         > wrot=
e:
>         =C2=A0 =C2=A0 > Hi all,
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > Ronald just sent me an email asking whether we =
will
>         define metadata for
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_supp=
orted and
>         =C2=A0 =C2=A0 >
>         pushed_authorization_endpoint_auth_signing_alg_values_supported=
=2E
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > The draft right now utilises the existing token=
 endpoint
>         authentication methods so there is basically no need to define
>         another parameter. The same principle could be applied to
>         signing (and encryption) algorithms as well.
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > What=E2=80=99s your opinion?
>         =C2=A0 =C2=A0 >
>         =C2=A0 =C2=A0 > best regards,
>         =C2=A0 =C2=A0 > Torsten.
>
>
>
>         _______________________________________________
>         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..=C2=A0 If you have received this communication in error=
,
>     please notify the sender immediately by e-mail and delete the
>     message and any file attachments from your computer. Thank
>     you./*_______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
> =C2=A0
>


--------------7B702B2CD4B1F9873969A547
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Just to comment that with a lightweight PAR (stash-only) endpoint
      one of the nice benefits of PAR will be lost - to pre-validate the
      request (client_id, redirect_uri, etc) as much as possible before
      a front-end call is made and the user is sent to the authZ
      endpoint. 

    

    
Vladimir

    

    
On 06/01/2020 23:59, Richard Backman,
      Annabelle wrote:

    

    

      
      
      
      

        
The issue isn=E2=80=99t that the PAR endpo=
int needs
          access to one specific request object decryption key that
          could reasonably be shared across AS endpoints, but that it
          actually needs access to the private keys for all encryption
          public keys in the JWK set pointed to by the AS=E2=80=99s jwks_=
uri
          metadata property. Since there is no way to designate one
          particular key as the one to use for encrypting request
          objects, clients may reasonably use any encryption public key
          in the JWK set to encrypt a request object. As one example of
          how this could expose sensitive data to the PAR endpoint, if
          the PAR endpoint has all the decryption keys for the keys in
          the AS=E2=80=99s JWK set, it would be able to decrypt ID Tokens=
 sent
          in id_token_hint request parameters. As more and more use
          cases develop for encrypting blobs for the AS, this issue will
          only get worse.

        
=C2=A0

        
The PAR endpoint can=E2=80=99t simply stas=
h the
          encrypted request object, as it is required to verify the
          request, according to =C2=A72.1:

        
=C2=A0

        
The A=
S MUST process the request as follows:

        
=
=C2=A0

        
...

        
=
=C2=A0

        
3.=C2=
=A0 The AS MUST validate the request in the same way as at the=


        
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0authorization endpoint. ...

        
=C2=A0

        
This language needs to be more flexible,
          IMHO, to allow for lightweight PAR endpoints that may not have
          the information or authority needed to perform all the
          validation that happens at the authorization endpoint. I need
          to think about this more before I can say if it would
          adequately address my concerns, but it=E2=80=99d be a good star=
t and
          makes sense in its own right.

        
=C2=A0

        
I think it=E2=80=99s pretty risky for us t=
o base
          decision on an assumption that no one is going to need or want
          to encrypt pushed request objects, particularly when they=E2=80=
=99re
          JWTs, and JWTs have well established support for encryption,
          and encrypted JWTs are supported by pass-by-value in OIDC and
          draft-ietf-oauth-jwsreq. But if you insist, here are a few
          examples for why someone might want to do this:

        
    
          
  1. The request=

            object is passed by reference, and accessible on the public
            Internet.
    2. 
          
  2. The request=

            object contains sensitive transaction-related data in RAR
            parameters that the client=E2=80=99s authN/authZ stack doesn=E2=
=80=99t need
            to have access to.
    3. 
          
  3. The AS
            requires request object encryption to minimize exposure to
            the hosted PAR endpoint service it uses.
    4. 
          
  4. #2, but the=

            threat vector is gaps in end-to-end TLS.
    5. 
          
  5. Any of the
            above, but the concern is message integrity, and the AS
            requires requested objects to be encrypted for
            confidentiality and integrity protection and does not
            support signed request objects.
    6. 
        

        
=C2=A0

        

          
=E2=80=93=
=C2=A0

          
Annabel=
le
              Richard Backman

          
AWS
              Identity

        

        
=C2=A0

        
=C2=A0

        

          
From: <=
span
              style=3D"font-size:12.0pt;color:black">Neil Madden
              <neil.madden@forgerock.com>

              Date: Monday, January 6, 2020 at 6:29 AM

              To: Brian Campbell
              <bcampbell@pingidentity.com>

              Cc: "Richard Backman, Annabelle"
              <richanna@amazon.com>, Nat Sakimura
              <nat@sakimura.org>, Dave Tonge
              <dave.tonge@moneyhub.com>, Torsten Lodderstedt
              <torsten@lodderstedt.net>, oauth
              <oauth@ietf.org>

              Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR
              metadata

        

        

          
=C2=A0

        

        
Agreed. 

        

          
=C2=A0

        

        

          
In addition, I'm not sure why the PAR
            endpoint would need access to the decryption keys at all. If
            you're using encrypted request objects then the PAR endpoint
            receives an encrypted JWT and then later makes the same
            (still encrypted) JWT available to the authorization
            endpoint. If the PAR endpoint is doing any kind of
            decryption or validation on behalf of the authorization
            endpoint then they are clearly not in separate trust
            boundaries.

        

        

          
=C2=A0

        

        

          
-- Neil

        

        

          
=C2=A0

          

            


              

              

            

              

                
On 6 Jan 2020, at 13:57, Brian
                  Campbell <bcampbell=3D40pingidentity.c=
om@dmarc.ietf.org>
                  wrote:

              

              
=C2=A0

              

                

                  

                    
I really struggle to see the
                      assumption that an entity be able to use the same
                      key to decrypt the same type of message ultimately
                      intended for the same purpose as an artificial
                      limit. The same general assumption =C2=A0 underlies=

                      everything else in OAuth/OIDC (Vladimir's post
                      points to some but not all examples of such).
                      There's no reason for PAR to make a one-off
                      exception. And should there be some deployment
                      specific reason that truly requires that kind of
                      isolation, there are certainly implementation
                      options that aren't compatibility-breaking. And
                      having said all that, I'm honestly a little
                      surprised anyone is thinking much about encrypted
                      request objects with PAR as, at least with my
                      limited imagination, there's not really a need for
                      it.
                      

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                

                
=C2=A0

                

                  

                    
On Fri, Jan 3, 2020 at 2:43 PM=

                      Richard Backman, Annabelle <richanna=3D40amaz=
on.com@dmarc.ietf.org>
                      wrote:

                  

                  

                    
PAR introduces an added wrinkl=
e
                      for encrypted request objects: the PAR endpoint
                      and authorization endpoint may not have access to
                      the same cryptographic keys, even though they're
                      both part of the "authorization server." Since
                      they're different endpoints with different roles,
                      it's reasonable to put them in separate trust
                      boundaries. There is no way to support this
                      isolation with just a single "jwks_uri" metadata
                      property.

                      

                      The two options that I see are:

                      

                      1. Define a new par_jwks_uri metadata property.
=

                      2. Explicitly state that this separation is not
                      supported.

                      

                      I strongly perfer #1 as it has a very minor impact
                      on deployments that don't care (i.e., they just
                      set par_jwks_uri and jwks_uri to the same value)
                      and failing to support this trust boundary creates
                      an artificial limit on implementation architecture
                      and could lead to compatibility-breaking
                      workarounds.

                      

                      =E2=80=93 

                      Annabelle Richard Backman

                      AWS Identity

                      

                      

                      On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten
                      Lodderstedt" <oauth-=
bounces@ietf.org
                      on behalf of torsten=3D40lodd=
erstedt.net@dmarc.ietf.org>
                      wrote:

                      

                      =C2=A0 =C2=A0 Hi Filip, 

                      

                      =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip=
 Skokan
                      <panva.=
ip@gmail.com>
                      wrote:

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > I don't think we need a *_auth_m=
ethod_*
                      metadata for every endpoint the client calls
                      directly, none of the new specs defined these
                      (e.g. device authorization endpoint or CIBA),
                      meaning they also didn't follow the scheme from
                      RFC 8414 where introspection and revocation got
                      its own metadata. In most cases the unfortunately
                      named `token_endpoint_auth_method` and its related
                      metadata is what's used by clients for all direct
                      calls anyway.

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > The same principle could be appl=
ied to
                      signing (and encryption) algorithms as well.

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > This I do not follow, auth metho=
ds and
                      their signing is dealt with by using
                      `token_endpoint_auth_methods_supported` and
                      `token_endpoint_auth_signing_alg_values_supported`
                      - there's no encryption for the `_jwt` client auth
                      methods.
                      

                      =C2=A0 =C2=A0 > Unless it was meant to address t=
he
                      Request Object signing and encryption metadata,
                      which is defined and IANA registered by OIDC. PAR
                      only references JAR section 6.1 and 6.2 for
                      decryption/signature validation and these do not
                      mention the metadata (e.g.
                      request_object_signing_alg) anymore since draft
                      07.

                      

                      =C2=A0 =C2=A0 Dammed! You are so right. Sorry, I go=
t
                      confused somehow. 

                      

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > PS: I also found this comment re=
lated to
                      the same question about auth metadata but for
                      CIBA.

                      

                      =C2=A0 =C2=A0 Thanks for sharing. 

                      

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > Best,

                      =C2=A0 =C2=A0 > Filip

                      

                      =C2=A0 =C2=A0 thanks,

                      =C2=A0 =C2=A0 Torsten. 

                      

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, To=
rsten
                      Lodderstedt <torste=
n@lodderstedt.net>
                      wrote:

                      =C2=A0 =C2=A0 > Hi all,

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > Ronald just sent me an email ask=
ing
                      whether we will define metadata for 

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 >
                      pushed_authorization_endpoint_auth_methods_supporte=
d
                      and

                      =C2=A0 =C2=A0 >
                      pushed_authorization_endpoint_auth_signing_alg_valu=
es_supported.

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > The draft right now utilises the=
 existing
                      token endpoint authentication methods so there is
                      basically no need to define another parameter. The
                      same principle could be applied to signing (and
                      encryption) algorithms as well.
                      

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > What=E2=80=99s your opinion?
=

                      =C2=A0 =C2=A0 > 

                      =C2=A0 =C2=A0 > best regards,

                      =C2=A0 =C2=A0 > Torsten.

                      

                      

                      

                      _______________________________________________
=

                      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..=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/oa=
uth

              

            

          

          
=C2=A0

        

      

    

    

  


--------------7B702B2CD4B1F9873969A547--

--------------ms080802020300040501050505
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDcxMzUyMjlaMC8G
CSqGSIb3DQEJBDEiBCDC9iYnVWbMN4QWjweySlNZ43u10gHoUpbyKKaFsUpozzBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAFU1NG5pVY4EcFImM0yzTYnBqU0o+O5nE7KWdpVhboeworXy
6UhfZ0FCCshLj6GDUQtAsq4BiESRN0fklXMc/+Bg4VOQk3DWcnxJW41is29042rnuzTBWMvd
OarUyID43/YEl4kMR9UxbsJKN7o/1ttxAuU4El9lr2o1F0ruD2r//jwxChopU5HlqVjO9gET
dZyokCzuBzf/AbQ/nDQvDdIvtB1KFJUn+9odzWzXrn9jffjFIAyZHXPHBKCH+RpZUodYMjrL
mrom95fZrkafh3hul0OyEAqiQ9R2kRYvpQ2l9pOtt7kUjucjH7cIx1zYZXhYmalg19CMdAhA
P2DeJ4UAAAAAAAA=
--------------ms080802020300040501050505--


From nobody Tue Jan  7 05:58: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 9A32712010D for ; Tue,  7 Jan 2020 05:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 UgS_-RvDpDfv for ; Tue,  7 Jan 2020 05:58:25 -0800 (PST)
Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (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 7709E120120 for ; Tue,  7 Jan 2020 05:58:25 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id opNGik7E8n9FUopNHitjBq; Tue, 07 Jan 2020 06:58:24 -0700
x-spam-cmae: v=2.3 cv=SNc8q9nH c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=UM_DoP-0AAAA:8 a=LS6YZpeZAAAA:8 a=vggBfdFIAAAA:8 a=DVqm7IH0AAAA:8 a=-B3230MOAAAA:8 a=pGLkceISAAAA:8 a=BBoBmrX5DfzL3ZKhHt8A:9 a=MuVwZFWdJ64b3vTM:21 a=Ty4s1fouFGWNx9UI:21 a=QEXdDO2ut3YA:10 a=r_AD4E2wVIxbPAgEuloA:9 a=tgtXeDFGb3I7toZQ:21 a=P4tNvQTW8I36gEdL:21 a=jVb8tlh8HRYajJk3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=TEVHQOIvcflanWNqQbWu:22 a=IRr2vCDBpksuBOXhfkKu:22 a=M6wP_kGduNurgptF5PJY:22 a=Z6yIbYtmj3_f4zpjOCXI:22 a=IdGyktwZ2tr74praB_5u:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
To: Filip Skokan , "Richard Backman, Annabelle" 
Cc: Dave Tonge , oauth , Nat Sakimura 
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com> 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>
Date: Tue, 7 Jan 2020 15:58:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030205050400070805000602"
X-CMAE-Envelope: MS4wfJ0fCYBSZ1rLzyqyVkZuZ8CDGICBQQUHGaMbMB9Zg2dr/oEkCQ9VqIlaYOHm8qlWHaGUX1yO5uikg7N6hL2fZZRDtrgP1s7c6IXJazKJenMX1VClVwT+ DT3pCp+XyjTYuVM5o/kj+0RRaxwbb0ad/LjRCd3asM72oYjVRKdgpguuRnvDzY4e1cLNcBb44d1Jx5+SfxN+BXRQKSnalseiMc50zg6+gcp05rTLtHWKiU0D 3PDnEQtXU2qqQWAsdq1PbXA41EnXdlF8TUiEOYkDMuYnbaZVUOuAfZ3ON3CbjiJ1phZj+Xgvi2tHmHATL/5eqQ==
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 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: Tue, 07 Jan 2020 13:58:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms030205050400070805000602
Content-Type: multipart/alternative;
 boundary="------------B13116EA8C3AFD96FEC57117"
Content-Language: en-US

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

On 07/01/2020 00:22, Filip Skokan wrote:
> We've been discussing making the following=C2=A0change to the language
>
>     The AS SHOULD validate the request in the same way as at the
>     authorization endpoint. The AS MUST ensure that all parameters to
>     the authorization request are still valid at the time when the
>     request URI is used.
>
Could you expand a bit on the second sentence?

Alternative suggestion:

The AS MUST validate the request in the same way as at the authorization
endpoint, or complete the request validation at the authorization endpoin=
t.

Vladimir


> This would allow the PAR endpoint to simply stash the encrypted
> request object instead of decrypting and validating it. All within the
> bounds of "SHOULD -=C2=A0We=E2=80=99d like you to do this, but we can=E2=
=80=99t always
> require it". This supports "light weight PAR" implementation rather
> than introducing the unnecessary complexity in the form of a second JWK=
S.
>
> Best,
> *Filip*
>
>
> On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle
>  > wrote:
>
>     The issue isn=E2=80=99t that the PAR endpoint needs access to one s=
pecific
>     request object decryption key that could reasonably be shared
>     across AS endpoints, but that it actually needs access to the
>     private keys for all encryption public keys in the JWK set pointed
>     to by the AS=E2=80=99s jwks_uri metadata property. Since there is n=
o way
>     to designate one particular key as the one to use for encrypting
>     request objects, clients may reasonably use any encryption public
>     key in the JWK set to encrypt a request object. As one example of
>     how this could expose sensitive data to the PAR endpoint, if the
>     PAR endpoint has all the decryption keys for the keys in the AS=E2=80=
=99s
>     JWK set, it would be able to decrypt ID Tokens sent in
>     id_token_hint request parameters. As more and more use cases
>     develop for encrypting blobs for the AS, this issue will only get
>     worse.
>
>     =C2=A0
>
>     The PAR endpoint can=E2=80=99t simply stash the encrypted request o=
bject,
>     as it is required to verify the request, according to =C2=A72.1:
>
>     =C2=A0
>
>     The AS MUST process the request as follows:
>
>     =C2=A0
>
>     ...
>
>     =C2=A0
>
>     3.=C2=A0 The AS MUST validate the request in the same way as at the=

>
>     =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorizatio=
n endpoint. ...
>
>     =C2=A0
>
>     This language needs to be more flexible, IMHO, to allow for
>     lightweight PAR endpoints that may not have the information or
>     authority needed to perform all the validation that happens at the
>     authorization endpoint. I need to think about this more before I
>     can say if it would adequately address my concerns, but it=E2=80=99=
d be a
>     good start and makes sense in its own right.
>
>     =C2=A0
>
>     I think it=E2=80=99s pretty risky for us to base decision on an ass=
umption
>     that no one is going to need or want to encrypt pushed request
>     objects, particularly when they=E2=80=99re JWTs, and JWTs have well=

>     established support for encryption, and encrypted JWTs are
>     supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq.
>     But if you insist, here are a few examples for why someone might
>     want to do this:
>
>      1. The request object is passed by reference, and accessible on
>         the public Internet.
>      2. The request object contains sensitive transaction-related data
>         in RAR parameters that the client=E2=80=99s authN/authZ stack d=
oesn=E2=80=99t
>         need to have access to.
>      3. The AS requires request object encryption to minimize exposure
>         to the hosted PAR endpoint service it uses.
>      4. #2, but the threat vector is gaps in end-to-end TLS.
>      5. Any of the above, but the concern is message integrity, and
>         the AS requires requested objects to be encrypted for
>         confidentiality and integrity protection and does not support
>         signed request objects.
>
>     =C2=A0
>
>     =E2=80=93=C2=A0
>
>     Annabelle Richard Backman
>
>     AWS Identity
>
>     =C2=A0
>
>     =C2=A0
>
>     *From: *Neil Madden      >
>     *Date: *Monday, January 6, 2020 at 6:29 AM
>     *To: *Brian Campbell      >
>     *Cc: *"Richard Backman, Annabelle"      >, Nat Sakimura      >, Dave Tonge      >, Torsten Lodderstedt
>     >, oauth
>     >
>     *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
>     =C2=A0
>
>     Agreed.
>
>     =C2=A0
>
>     In addition, I'm not sure why the PAR endpoint would need access
>     to the decryption keys at all. If you're using encrypted request
>     objects then the PAR endpoint receives an encrypted JWT and then
>     later makes the same (still encrypted) JWT available to the
>     authorization endpoint. If the PAR endpoint is doing any kind of
>     decryption or validation on behalf of the authorization endpoint
>     then they are clearly not in separate trust boundaries.
>
>     =C2=A0
>
>     -- Neil
>
>     =C2=A0
>
>
>
>         On 6 Jan 2020, at 13:57, Brian Campbell
>                  > wrote:
>
>         =C2=A0
>
>         I really struggle to see the assumption that an entity be able
>         to use the same key to decrypt the same type of message
>         ultimately intended for the same purpose as an artificial
>         limit. The same general assumption =C2=A0 underlies everything =
else
>         in OAuth/OIDC (Vladimir's post points to some but not all
>         examples of such). There's no reason for PAR to make a one-off
>         exception. And should there be some deployment specific reason
>         that truly requires that kind of isolation, there are
>         certainly implementation options that aren't
>         compatibility-breaking. And having said all that, I'm honestly
>         a little surprised anyone is thinking much about encrypted
>         request objects with PAR as, at least with my limited
>         imagination, there's not really a need for it.
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         =C2=A0
>
>         On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle
>                  > wrote:
>
>             PAR introduces an added wrinkle for encrypted request
>             objects: the PAR endpoint and authorization endpoint may
>             not have access to the same cryptographic keys, even
>             though they're both part of the "authorization server."
>             Since they're different endpoints with different roles,
>             it's reasonable to put them in separate trust boundaries.
>             There is no way to support this isolation with just a
>             single "jwks_uri" metadata property.
>
>             The two options that I see are:
>
>             1. Define a new par_jwks_uri metadata property.
>             2. Explicitly state that this separation is not supported.
>
>             I strongly perfer #1 as it has a very minor impact on
>             deployments that don't care (i.e., they just set
>             par_jwks_uri and jwks_uri to the same value) and failing
>             to support this trust boundary creates an artificial limit
>             on implementation architecture and could lead to
>             compatibility-breaking workarounds.
>
>             =E2=80=93
>             Annabelle Richard Backman
>             AWS Identity
>
>
>             On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten
>             Lodderstedt"               on behalf of
>             torsten=3D40lodderstedt.net@dmarc.ietf.org
>             > wrote:
>
>             =C2=A0 =C2=A0 Hi Filip,
>
>             =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, Filip Skokan
>             > wrote:
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > I don't think we need a *_auth_method_* met=
adata for
>             every endpoint the client calls directly, none of the new
>             specs defined these (e.g. device authorization endpoint or
>             CIBA), meaning they also didn't follow the scheme from RFC
>             8414 where introspection and revocation got its own
>             metadata. In most cases the unfortunately named
>             `token_endpoint_auth_method` and its related metadata is
>             what's used by clients for all direct calls anyway.
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > The same principle could be applied to sign=
ing (and
>             encryption) algorithms as well.
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > This I do not follow, auth methods and thei=
r signing
>             is dealt with by using
>             `token_endpoint_auth_methods_supported` and
>             `token_endpoint_auth_signing_alg_values_supported` -
>             there's no encryption for the `_jwt` client auth methods.
>             =C2=A0 =C2=A0 > Unless it was meant to address the Request =
Object
>             signing and encryption metadata, which is defined and IANA
>             registered by OIDC. PAR only references JAR section 6.1
>             and 6.2 for decryption/signature validation and these do
>             not mention the metadata (e.g. request_object_signing_alg)
>             anymore since draft 07.
>
>             =C2=A0 =C2=A0 Dammed! You are so right. Sorry, I got confus=
ed somehow.
>
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > PS: I also found this comment related to th=
e same
>             question about auth metadata but for CIBA.
>
>             =C2=A0 =C2=A0 Thanks for sharing.
>
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > Best,
>             =C2=A0 =C2=A0 > Filip
>
>             =C2=A0 =C2=A0 thanks,
>             =C2=A0 =C2=A0 Torsten.
>
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38, Torsten Lodde=
rstedt
>             >
>             wrote:
>             =C2=A0 =C2=A0 > Hi all,
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > Ronald just sent me an email asking whether=
 we will
>             define metadata for
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > pushed_authorization_endpoint_auth_methods_=
supported and
>             =C2=A0 =C2=A0 >
>             pushed_authorization_endpoint_auth_signing_alg_values_suppo=
rted.
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > The draft right now utilises the existing t=
oken
>             endpoint authentication methods so there is basically no
>             need to define another parameter. The same principle could
>             be applied to signing (and encryption) algorithms as well.
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > What=E2=80=99s your opinion?
>             =C2=A0 =C2=A0 >
>             =C2=A0 =C2=A0 > best regards,
>             =C2=A0 =C2=A0 > Torsten.
>
>
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org 
>             https://www.ietf.org/mailman/listinfo/oauth
>


--------------B13116EA8C3AFD96FEC57117
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 07/01/2020 00:22, Filip Skokan
      wrote:

    

    

      
      

        
We've been discussing making the following=C2=A0change to th=
e
          language

        


        

        
=
The
          AS SHOULD validate the request in the same way as at the
          authorization endpoint. The AS MUST ensure that all parameters
          to the authorization request are still valid at the time when
          the request URI is used.

        

      

    

    
Could you expand a bit on the second sentence?

    
Alternative suggestion:

    
The AS MUST validate the request in the same way as at the
      authorization endpoint, or complete the request validation at the
      authorization endpoint.

    

    
Vladimir

    


    

    

      

        
This would allow the PAR endpoint to simply stash the
          encrypted request object instead of decrypting and validating
          it. All within the bounds of "SHOULD -=C2=A0We=E2=80=99d like y=
ou to do
          this, but we can=E2=80=99t always require it". This supports "l=
ight
          weight PAR" implementation rather than introducing the
          unnecessary complexity in the form of a second JWKS.

        

        

          
Best,

            Filip

        

        

      

      

      

        
On Mon, 6 Jan 2020 at 23:00=
,
          Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>
          wrote:

        

        
=

          

            

              
The issue isn=E2=80=99t that the PAR=
 endpoint
                needs access to one specific request object decryption
                key that could reasonably be shared across AS endpoints,
                but that it actually needs access to the private keys
                for all encryption public keys in the JWK set pointed to
                by the AS=E2=80=99s jwks_uri metadata property. Since the=
re is
                no way to designate one particular key as the one to use
                for encrypting request objects, clients may reasonably
                use any encryption public key in the JWK set to encrypt
                a request object. As one example of how this could
                expose sensitive data to the PAR endpoint, if the PAR
                endpoint has all the decryption keys for the keys in the
                AS=E2=80=99s JWK set, it would be able to decrypt ID Toke=
ns sent
                in id_token_hint request parameters. As more and more
                use cases develop for encrypting blobs for the AS, this
                issue will only get worse.

              
=C2=A0

              
The PAR endpoint can=E2=80=99t simpl=
y stash
                the encrypted request object, as it is required to
                verify the request, according to =C2=A72.1:

              
=C2=A0

              
The AS MUST process the request as follows:

              
=C2=A0

              
...

              
=C2=A0

              
3.=C2=A0 The AS MUST validate the request in the same way as at the

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorization endpoint. ...

              
=C2=A0

              
This language needs to be more
                flexible, IMHO, to allow for lightweight PAR endpoints
                that may not have the information or authority needed to
                perform all the validation that happens at the
                authorization endpoint. I need to think about this more
                before I can say if it would adequately address my
                concerns, but it=E2=80=99d be a good start and makes sens=
e in
                its own right.

              
=C2=A0

              
I think it=E2=80=99s pretty risky fo=
r us to
                base decision on an assumption that no one is going to
                need or want to encrypt pushed request objects,
                particularly when they=E2=80=99re JWTs, and JWTs have wel=
l
                established support for encryption, and encrypted JWTs
                are supported by pass-by-value in OIDC and
                draft-ietf-oauth-jwsreq. But if you insist, here are a
                few examples for why someone might want to do this:

              
    
                
  1. The request object is passed
                  by reference, and accessible on the public Internet.
                
  2. The request object contains
                  sensitive transaction-related data in RAR parameters
                  that the client=E2=80=99s authN/authZ stack doesn=E2=80=
=99t need to
                  have access to.
    3. 
                
  3. The AS requires request objec=
t
                  encryption to minimize exposure to the hosted PAR
                  endpoint service it uses.
    4. 
                
  4. #2, but the threat vector is
                  gaps in end-to-end TLS.
    5. 
                
  5. Any of the above, but the
                  concern is message integrity, and the AS requires
                  requested objects to be encrypted for confidentiality
                  and integrity protection and does not support signed
                  request objects.
    6. 
              

              
=C2=A0

              

                
=E2=
=80=93=C2=A0

                
Ann=
abelle
                    Richard Backman

                
AWS=

                    Identity

              

              
=C2=A0

              
=C2=A0

              

                
From: <=
/b>Neil Madden <=
neil.mad=
den@forgerock.com>

                    Date: Monday, January 6, 2020 at 6:29 AM

                    To: Brian Campbell <bcampbel=
l@pingidentity.com>

                    Cc: "Richard Backman, Annabelle" <richanna@amazon.com>=
;,
                    Nat Sakimura <nat@saki=
mura.org>,
                    Dave Tonge <dave.ton=
ge@moneyhub.com>,
                    Torsten Lodderstedt <torsten@=
lodderstedt..net>,
                    oauth <oauth@ie=
tf.org>

                    Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG]
                    PAR metadata

              

              

                
=C2=A0

              

              
Agreed. 

              

                
=C2=A0

              

              

                
In addition, I'm not sure why the
                  PAR endpoint would need access to the decryption keys
                  at all. If you're using encrypted request objects then
                  the PAR endpoint receives an encrypted JWT and then
                  later makes the same (still encrypted) JWT available
                  to the authorization endpoint. If the PAR endpoint is
                  doing any kind of decryption or validation on behalf
                  of the authorization endpoint then they are clearly
                  not in separate trust boundaries.

              

              

                
=C2=A0

              

              

                
-- Neil

              

              

                
=C2=A0

                

                  


                    

                  

                  
=

                    

                      
On 6 Jan 2020, at 13:57,
                        Brian Campbell <bcam=
pbell=3D40pingidentity.com@dmarc.ietf.org>
                        wrote:

                    

                    
=C2=A0

                    

                      

                        

                          
I really struggle to see=

                            the assumption that an entity be able to use
                            the same key to decrypt the same type of
                            message ultimately intended for the same
                            purpose as an artificial limit. The same
                            general assumption =C2=A0 underlies everythin=
g
                            else in OAuth/OIDC (Vladimir's post points
                            to some but not all examples of such).
                            There's no reason for PAR to make a one-off
                            exception. And should there be some
                            deployment specific reason that truly
                            requires that kind of isolation, there are
                            certainly implementation options that aren't
                            compatibility-breaking. And having said all
                            that, I'm honestly a little surprised anyone
                            is thinking much about encrypted request
                            objects with PAR as, at least with my
                            limited imagination, there's not really a
                            need for it.
                          

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                      

                      
=C2=A0

                      

                        

                          
On Fri, Jan 3, 2020 at
                            2:43 PM Richard Backman, Annabelle
                            <richanna=3D=
40amazon.com@dmarc.ietf.org>
                            wrote:

                        

                        

                          
PAR introduces an added
                            wrinkle for encrypted request objects: the
                            PAR endpoint and authorization endpoint may
                            not have access to the same cryptographic
                            keys, even though they're both part of the
                            "authorization server." Since they're
                            different endpoints with different roles,
                            it's reasonable to put them in separate
                            trust boundaries. There is no way to support
                            this isolation with just a single "jwks_uri"
                            metadata property.

                            

                            The two options that I see are:

                            

                            1. Define a new par_jwks_uri metadata
                            property.

                            2. Explicitly state that this separation is
                            not supported.

                            

                            I strongly perfer #1 as it has a very minor
                            impact on deployments that don't care (i.e.,
                            they just set par_jwks_uri and jwks_uri to
                            the same value) and failing to support this
                            trust boundary creates an artificial limit
                            on implementation architecture and could
                            lead to compatibility-breaking workarounds.
                            

                            =E2=80=93 

                            Annabelle Richard Backman

                            AWS Identity

                            

                            

                            On 12/31/19, 8:07 AM, "OAuth on behalf of
                            Torsten Lodderstedt" <=
oauth-bounces@ietf.org
                            on behalf of torsten=3D=
40lodderstedt.net@dmarc.ietf.org>
                            wrote:

                            

                            =C2=A0 =C2=A0 Hi Filip, 

                            

                            =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22,=
 Filip
                            Skokan <=
panva.ip@gmail.com>
                            wrote:

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > I don't think we need a
                            *_auth_method_* metadata for every endpoint
                            the client calls directly, none of the new
                            specs defined these (e.g. device
                            authorization endpoint or CIBA), meaning
                            they also didn't follow the scheme from RFC
                            8414 where introspection and revocation got
                            its own metadata. In most cases the
                            unfortunately named
                            `token_endpoint_auth_method` and its related
                            metadata is what's used by clients for all
                            direct calls anyway.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > The same principle could b=
e applied
                            to signing (and encryption) algorithms as
                            well.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > This I do not follow, auth=
 methods
                            and their signing is dealt with by using
                            `token_endpoint_auth_methods_supported` and
`token_endpoint_auth_signing_alg_values_supported` - there's no
                            encryption for the `_jwt` client auth
                            methods.
                            

                            =C2=A0 =C2=A0 > Unless it was meant to add=
ress the
                            Request Object signing and encryption
                            metadata, which is defined and IANA
                            registered by OIDC. PAR only references JAR
                            section 6.1 and 6.2 for decryption/signature
                            validation and these do not mention the
                            metadata (e.g. request_object_signing_alg)
                            anymore since draft 07.

                            

                            =C2=A0 =C2=A0 Dammed! You are so right. Sorry=
, I got
                            confused somehow. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > PS: I also found this comm=
ent
                            related to the same question about auth
                            metadata but for CIBA.

                            

                            =C2=A0 =C2=A0 Thanks for sharing. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > Best,

                            =C2=A0 =C2=A0 > Filip

                            

                            =C2=A0 =C2=A0 thanks,

                            =C2=A0 =C2=A0 Torsten. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:=
38,
                            Torsten Lodderstedt <=
torsten@lodderstedt.net>
                            wrote:

                            =C2=A0 =C2=A0 > Hi all,

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > Ronald just sent me an ema=
il asking
                            whether we will define metadata for 

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 >
                            pushed_authorization_endpoint_auth_methods_su=
pported
                            and

                            =C2=A0 =C2=A0 >
                            pushed_authorization_endpoint_auth_signing_al=
g_values_supported.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > The draft right now utilis=
es the
                            existing token endpoint authentication
                            methods so there is basically no need to
                            define another parameter. The same principle
                            could be applied to signing (and encryption)
                            algorithms as well.
                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > What=E2=80=99s your opinio=
n?

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > best regards,

                            =C2=A0 =C2=A0 > Torsten.

                            

                            

                            

_______________________________________________

                            OAuth mailing list

                            =
OAuth@ietf.org

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

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


--------------B13116EA8C3AFD96FEC57117--

--------------ms030205050400070805000602
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMDcxMzU4MjFaMC8G
CSqGSIb3DQEJBDEiBCD3cFSwWsCh71Ok9aW4Yoi+up6+0U/oGARJWPBgdzH/YjBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAHaBWCR15Q3B6iHavj7emcj/OCO4DZAuWsx0rZm9b2dXfxvz
iQZVF+/MM+l3KtWDQjMvLBNmanKI2madbN4epJKvc4Ds3Nl14JHRqtBhOWgfoDSt9aGePHOD
er3zbhRdMu/kqb4GSlGudti5gKBfSg4T/H8rDTBlY3Ny/jMflZgNsAcl2rFA9WiYAwNQq9Bi
0CebokzQz07oTszI1sj2bFao0hZtwp9BVIiWj73GO1HJUaG1Bby5C2tzfr+a80vqlphcvMBq
63sAX89ysA73y76u0b3ZkY17RQ87KHoj2rJnaqH8uARNizQA2yEHZgz3y6e90AYyqpncM62Q
YNqSJG4AAAAAAAA=
--------------ms030205050400070805000602--


From nobody Tue Jan  7 08:12: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 095AB12003E for ; Tue,  7 Jan 2020 08:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ENKYlUUu; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=e1XfZ82h
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWFXVdU-uUXf for ; Tue,  7 Jan 2020 08:12:41 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00057.outbound.protection.outlook.com [40.107.0.57]) (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 EF4D71201DE for ; Tue,  7 Jan 2020 08:12:40 -0800 (PST)
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=d/8sBW1V2xhIfuezowd2eHhYtLBPaudZl+/meLTjmBE=; b=ENKYlUUugZ/cxuQvpirP/fECWhbEbXri8A5/Ukdpt8zO/k69CZgp+9lW8g9vFmm2PpwxRbYsNrApfVSgJgTjb4C1+tl1kKOfXeKG5x7sU2/NpiccYC6me1/vBTrgvWGnliF9C/K3m+7ZSESm1YAnoGRRDrQoMmo3+Db8MusB4i4=
Received: from AM6PR08CA0009.eurprd08.prod.outlook.com (2603:10a6:20b:b2::21) by HE1PR0801MB1897.eurprd08.prod.outlook.com (2603:10a6:3:4a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 16:12:38 +0000
Received: from DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::207) by AM6PR08CA0009.outlook.office365.com (2603:10a6:20b:b2::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Tue, 7 Jan 2020 16:12:38 +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 DB5EUR03FT051.mail.protection.outlook.com (10.152.21.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Tue, 7 Jan 2020 16:12:38 +0000
Received: ("Tessian outbound 121a58c8f9bf:v40"); Tue, 07 Jan 2020 16:12:38 +0000
X-CR-MTA-TID: 64aa7808
Received: from a1983b541753.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 37627EA2-A6FC-4E98-802F-AA64D10767B5.1;  Tue, 07 Jan 2020 16:12:33 +0000
Received: from EUR03-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a1983b541753.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Jan 2020 16:12:33 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ClP+fGiQiFdPBsUQUC/WE9r/v3HDeVbag2W/edqneC28v866iBheIkcjNOjYhjLFCBeA+1i2RjGEfcPUSVhtNjP/H7ARLL0VrODe0kHMYetbmSCowSvKecIe2yUJ7il9c1ZbFWx0QOvxRKdZNVJvSetc5HDsz/yqka5ivLtkZh/w3gegCHOiRXtCTDPSXvraP9V1iOMBlnDBrdaWy87Ev9HCwEYA/S158GeDA/xpMg5MkXyHpR5L7UR8MgFoAkbNUNigLDrSPTuAsbGqYoeamOe4qoJ/ciYcSnTjYXYJGfVWDLQL03nLuiu+oUefZ1NXzdmY905AAVs7+rIv7TtImg==
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=6O7tpe5hao0nngeYHE5+UopfrZMTp49TGyW1GxJlU2w=; b=KTl7GYGQ29LFHGCL5fXggUG66CDyVecnLvYhnf+T7veKkU8QuXNsq1KoHZt/tC8286VKqrlYj0ElT+eGAs+sPE2DsYPlKEnoD+PzMOdY1V53qKI61MKQIclV+bRePGeeypMEj0m1V/4f1YDa/2sYWTdd1eNxLpsbtWVyN0mQu6k02i8BXRL3hqXMrNtVFpKzStd1BV3++a6sqkUwDyaT4mLJEoa0FXQYM0v/6kchJzg3gt8Cld+tLB27Fqfnv8wiXj0dqzBOc32X93H0IQ863P/O0pOis2XTb3BWdaJeGmQJQew9GC7W6GPTzJkPYsgD2+gePHKYmto3XJGomenl6A==
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=6O7tpe5hao0nngeYHE5+UopfrZMTp49TGyW1GxJlU2w=; b=e1XfZ82hXgepIEmxdkZcg7PZ9bNJu2av+1qV1c739uvIOb+LIS4RF/I0/cwx2jJJA+3lWbUJiTxDvoN5oBPzZHVpdCsSFE+D2jH+dvPqZL9NJk4R7iGFXTaayg5i4Fp6r/CPOaYJI7AlDH/Sw/9691YJvO1rgsqOhjDbG3tIp78=
Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB3734.eurprd08.prod.outlook.com (20.178.88.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Tue, 7 Jan 2020 16:12:22 +0000
Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 16:12:22 +0000
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Thread-Topic: Virtual Interim Meeting/Conference Call on Feb. 10th 
Thread-Index: AdXFc1pUiqrvW/6eSyWxcsIRywPmEg==
Date: Tue, 7 Jan 2020 16:12:22 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ts-tracking-id: 45e4bfa9-b810-4bb5-91f2-c32dc8df7a08.0
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [195.149.223.43]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: a7432c6c-e89f-4bf3-354a-08d7938c6a3e
X-MS-TrafficTypeDiagnostic: AM6PR08MB3734:|HE1PR0801MB1897:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:5797;OLM:5797;
x-forefront-prvs: 027578BB13
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(39860400002)(376002)(346002)(53754006)(189003)(199004)(8676002)(5660300002)(6916009)(316002)(71200400001)(8936002)(2906002)(81166006)(81156014)(86362001)(4744005)(16799955002)(52536014)(6506007)(26005)(186003)(966005)(33656002)(7696005)(66476007)(66446008)(66946007)(64756008)(66616009)(9686003)(66556008)(4743002)(76116006)(55016002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3734; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: ogSkSkzedN+BNONqpgppPrRoU3KhMhgigFEl/aADiV/ZN1XN/U3taOaJxLCRIkcJ7Yei23wTb+neoMllBpb67ixvtqikpUbrOgCqJqJt9c5OXMBohf4Gr+ojBaeNiC8N4u6md3pmVf6IjApc6Na7SOxGc9klfAwNkegxm2azJi9SOECxhJXOedRV4agVD1dMTmd1KUOOoc+09AupiyjL3pA77dz8DBDSyjK/BbsQN0m6wEuQPHttaoyPWsFEWakjLLFUu82KHwmFIa33A48apwsv0tm9yTtCLIOOZ/QmXtAMXy7T6R2cT/SKMp7a0dGxqRQGhx0U5WR76nzIxq6l5eaCc4/u/D5WsOxcrQFRHL68X3axxuv3gIZPUBF0Cv6sOhVqqMctm5wyqTB8P92lQBBRzLCzLY/uKbNbkHFa2LEGgdV0866UOnsiWFrDLU6rDVARjTaIZx4TC795e/pTaGxO1idGPOGMtrBgdrMGY6Ag2UTLB+dmdEnbjfSXd2K8Hzjwyk2fQGWF+Y4Qj4ZARkNYSybcWatfwqXAkI9sYWY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_AM6PR08MB5285824B866CCA6D12BD333FFA3F0AM6PR08MB5285eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3734
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(396003)(376002)(189003)(199004)(53754006)(40434004)(186003)(7696005)(356004)(81166006)(81156014)(966005)(8676002)(6506007)(8936002)(26005)(2906002)(33656002)(55016002)(9686003)(5660300002)(52536014)(70206006)(6916009)(316002)(70586007)(66616009)(235185007)(16799955002)(4743002)(86362001)(336012)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB1897; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: 0bcc3dbb-fe65-487f-e6e3-08d7938c60bc
X-Forefront-PRVS: 027578BB13
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: E5zuonpkP9iNOEwK5z2MV/k+8DHsqxBGvaTbMHIvhgdOCzYtUziM44cCeNFvp13/8blUXtvdzzL+RaxnPhCzwcB6yqujKzPMU8kR4IQSJrv+BV/ZKCqkzCKlp6lqtVTYSYPiHrxfxi9fW09o5wpSHglBMxBumF+zqdYm3QmloLE3rK5phdtzWXzh5KWcsk8kC92OnRMFzEiSSNs5Hf2vndSuntqC48yFqr3XMqplgx8e/Q4hiL7/MA+UopcVD3QXKTRWgnwJlO9pcGMdrb/n4G1ImX0+hWk8b6dmIdr7If0igOiAkg/tyw3klp7DjUBo/Eg+1pem/0YM1uHZ/4NgmpnPTiScHNQ9kFK+vxVBsEmkIxZJo+NRqtX6e+HiYRivTVKOi5bUxHH4isniJ4RUm36ecpneJCG4Btzbean3w/nUFObpM+GilHy+9th05LjeE9eDg50mkHB0SR/yAFVfUnROA6ThQFJoLPvJj0IKv6DNJboYROJBGjqrqOIqwxcdp/SN+L5/rqhv0XGJuwu9Nv6yGORedwEGZkrk8cLX4MWQLoZi77oiinxw72OGb6Fg
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2020 16:12:38.2670 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a7432c6c-e89f-4bf3-354a-08d7938c6a3e
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: HE1PR0801MB1897
Archived-At: 
Subject: [OAUTH-WG] Virtual Interim Meeting/Conference Call on Feb. 10th
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 16:12:51 -0000

--_002_AM6PR08MB5285824B866CCA6D12BD333FFA3F0AM6PR08MB5285eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Based on the feedback we have selected Feb, 10th at 6pm CET.
In other time zones this is: https://www.timeanddate.com/worldclock/meeting=
details.html?year=3D2020&month=3D2&day=3D10&hour=3D17&min=3D0&sec=3D0&p1=3D=
1889&p2=3D179&p3=3D137

Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm2d06208053cadb65321=
2b11cfc65eeaf
Meeting number: 648 921 722
Password: BWsAF9rT

The webex info is also attached to this email.

As mentioned in our earlier email we would like to get a better understandi=
ng of this RFC 6749 update. Ideally, we would like to hear your thoughts ab=
out the goals of this update and what changes you envision to take place. W=
e have different options and we need to figure out what the best approach i=
s to meet the expectations.

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.

--_002_AM6PR08MB5285824B866CCA6D12BD333FFA3F0AM6PR08MB5285eurp_
Content-Type: text/calendar; name="Webex_Meeting.ics"
Content-Description: Webex_Meeting.ics
Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=6778;
 creation-date="Tue, 07 Jan 2020 16:09:38 GMT";
 modification-date="Tue, 07 Jan 2020 16:09:01 GMT"
Content-Transfer-Encoding: base64

QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r
IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ
TUVaT05FDQpUWklEOkV1cm9wZS9CZXJsaW4NClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9uZWlu
Zm8tb3V0bG9vay9FdXJvcGUvQmVybGluDQpYLUxJQy1MT0NBVElPTjpFdXJvcGUvQmVybGluDQpC
RUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNFVFRPOiswMjAwDQpUWk5B
TUU6Q0VTVA0KRFRTVEFSVDoxOTcwMDMyOVQwMjAwMDANClJSVUxFOkZSRVE9WUVBUkxZO0JZTU9O
VEg9MztCWURBWT0tMVNVDQpFTkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZS
T006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClRaTkFNRTpDRVQNCkRUU1RBUlQ6MTk3MDEwMjVU
MDMwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UNCkVORDpTVEFO
REFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMTA3VDE1NTcy
N1oNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3Vw
IjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFOk1BSUxUTzpvYXV0aC1jaGFpcnNAaWV0
Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ2lzY28gV2ViZXgiOk1BSUxUTzptZXNzZW5nZXJAd2ViZXgu
Y29tDQpEVFNUQVJUO1RaSUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDIxMFQxODAwMDANCkRURU5EO1Ra
SUQ9RXVyb3BlL0JlcmxpbjoyMDIwMDIxMFQxOTAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53
ZWJleC5jb20vaWV0Zg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU3ODQxMjY0Nw0KVUlEOjIw
NDVkMzU3LWZlNzgtNDkwYS1iOTA0LTU2MGRjN2FlMzYwMg0KREVTQ1JJUFRJT046XG5cbkpPSU4g
V0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTJk
MDYyMDgwNTNjYWRiNjUzMjEyYjExY2ZjNjVlZWFmXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNv
ZGUpOiA2NDggOTIxIDcyMlxuXG5cblxuTWVldGluZyBwYXNzd29yZDogQldzQUY5clRcblxuXG5c
bkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh
bmFkYSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1
cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0ODkyMTcyMiUyMyUyMyowMSpc
blxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6
NjQ4OTIxNzIyQGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjgg
YW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQg
THluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDg5MjE3MjIu
aWV0ZkBseW5jLndlYmV4LmNvbVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFj
dCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBP
UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3Mg
YXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJl
IHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZ
b3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5n
IGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuDQpYLUFMVC1ERVNDO0ZNVFRZ
UEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBwYWRkaW5nOiAw
OyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IHdp
ZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIge1xuCWxpbmUt
aGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9udC1mYW1pbHk6
IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3JkLWJyZWFrOiBu
b3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhweDt9XG5cbi5p
bWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290ZXIge1xuCXdp
ZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kIChtYXgtZGV2aWNl
LXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAhaW1wb3J0YW50
Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAw
JSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQlt
YXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0aDogMTAwJSAh
aW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxuPC9zdHlsZT5c
blxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBtYXJnaW46IDA7
IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0eWxlPSJoZWln
aHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxpZ249ImxlZnQi
IHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRhYmxlIGJnY29s
b3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmctbGVm
dDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+
XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiID4mbmJzcDsJ
CQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG4JCQk8dGFibGU+XG4J
CQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIg
RkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUu
PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdo
dDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8
dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ4IDkyMSA3MjI8L0ZPTlQ+
XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+XG4JCQk8dGFibGU+XG4JCQkJPHRy
PlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i
YXJpYWwiPjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCTx0
YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+
TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIj
NjY2NjY2IiBGQUNFPSJhcmlhbCI+QldzQUY5clQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+XG5c
biAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsi
Pjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTx0cj5cbgkJCQk8
dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8dGFibGUgYm9yZGVyPSIw
IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3aWR0aDphdXRvO3dpZHRo
OmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0MjsgYm9yZGVyOjBweCBzb2xp
ZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDoxNjBweCFpbXBvcnRhbnQ7
Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgc3R5bGU9InBhZGRpbmc6
MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U
SUQ9bTJkMDYyMDgwNTNjYWRiNjUzMjEyYjExY2ZjNjVlZWFmIiBzdHlsZT0iY29sb3I6I0ZGRkZG
RjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Sm9pbiBtZWV0aW5nPC9h
PjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwvdGQ+XG4JCQk8L3RyPlxu
CQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiIHN0eWxlPSJmb250
LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5i
c3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iNCIgRkFD
RT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9p
biBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2
NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0
ODkyMTcyMiUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9u
Om5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0
cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk
YSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9
ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxlPSJs
aW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90
cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIg
Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3Ig
YXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjY0ODkyMTcyMkBpZXRmLndlYmV4LmNv
bSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj42NDg5MjE3MjJA
aWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9
IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5k
IGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJz
cDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRk
ICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEy
cHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcg
TWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwv
dHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250
LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFs
IDxhIGhyZWY9IiBzaXA6NjQ4OTIxNzIyLmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5bGU9InRl
eHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjY0ODkyMTcyMi5pZXRmQGx5bmMud2Vi
ZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAx
MDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5
bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0
ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7
IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxh
IGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQt
ZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxu
CQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4m
bmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxu
DQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzDQpQUklPUklUWTo1DQpDTEFT
UzpQVUJMSUMNClJFQ1VSUkVOQ0UtSUQ7VFpJRD1FdXJvcGUvQmVybGluOjIwMjAwMjEwVDE4MDAw
MA0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJ
T046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg==

--_002_AM6PR08MB5285824B866CCA6D12BD333FFA3F0AM6PR08MB5285eurp_--


From nobody Tue Jan  7 08:25: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 27C3A1200F3 for ; Tue,  7 Jan 2020 08:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-StAFNynMzB for ; Tue,  7 Jan 2020 08:25:38 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B261200E0 for ; Tue,  7 Jan 2020 08:25:37 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id u1so190740ljk.7 for ; Tue, 07 Jan 2020 08:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tV1LlRN+eXyIcnP+l8D2T+ufOnJKVw82AwzZJfqEikM=; b=avQKgjs4/FAL1bHjBfFnVJOxiBfACJCVEogoqz0d/8OryqPY58uf4wQhEyJL+5gS2G 2m5Hq67pdktJJJcqv9YkxQmKVMiRXmfMLtfus/3ZB/bn6cUalSfhoK/O3eFrY92f+sTv x7CCkvPMynvDzfaUSQ9GNuA83xCf3pWrqZRGJEUGXqdOK3RTVWWZtpxvJ3XM7lkbimm8 EV0PZW5HE9io2oRN15GWp9WxE7yzIO/iigKVwoaMqGFgBJ0TDt+1LStFCCA2MPznzpNs xt9eoKvNV4UljtOj7cxU1thQZEgqPIAkBl0j2xwTROYhkGTtfmwKzGp5YN+3owXzmjmL 9Zsg==
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=tV1LlRN+eXyIcnP+l8D2T+ufOnJKVw82AwzZJfqEikM=; b=Twu28D6wNSWPyfh+A1ZXBlRwxeruSMrpwdQ54nn+sjms7tX8W/h80jmMyq2HzknHDN zN+7TZM/AjNENMlDEpEkvfrKyp5OYaflqz5rDcpGA3GITscFZ7gh0KO5ZgZ3vNtfYLQO k31pAHb1jzueETDJCvpiE9njJBTZTYniwT20Ag91QHHVV0YhK+UVWlFqV44PBJ4ud6k3 SrO4QlE+b87+oGPqiDdtN/eNNS6os+7GBo/W81kNFyYwKFW6yiyUGs7J7vIlpKClUk3o iQtLwakY5Y99rmmhGbtbGCyfSTbCDJN/JlxaUJd7o3ZvnaeIWjvXV0h3nXqHF0ik0mtZ UDMw==
X-Gm-Message-State: APjAAAULKmQh1wHTlSqmkeuqFTE0R9/m6lUkTT8QNaZsXuGEAqZuVBmm AasyisMcz+mxyaKeppUfHwqHZ70RdwVuqXmk1Rvmopv4mE3aSn18c/FoAHpPecDG/pY++rFfZ31 I+t+b54BSFhFNiLnr
X-Google-Smtp-Source: APXvYqx6KK/x7srDh4eYSN2A9e9XXDNzMgl9PNIkDw3y34bwouJkHSlQ1OQKyYwY4tdcQwscBmlX7zMUwbAgKYoi1DQ=
X-Received: by 2002:a2e:9592:: with SMTP id w18mr201935ljh.98.1578414335944; Tue, 07 Jan 2020 08:25:35 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 7 Jan 2020 09:25:09 -0700
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000cd8f47059b8f390a"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 16:25:40 -0000

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

+1

On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov 
wrote:

> +1 for the adoption of RAR
> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> _______________________________________________
> 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._

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


+1

On Tue, Jan 7, 2020 at 6:12 AM Vlad=
imir Dzhuvinov <vladimir@conn=
ect2id.com> wrote:

 =20
   =20
 =20
  

    
+1 for the adoption of RAR

    

    
On 06/01/2020 21:37, Rifaat Shekh-Yusef
      wrote:

    

    

      
This is a call for adoption for the=C2=A0OAuth 2.0 Rich
          Authorization Requests document.

      
    

    

  


_______________________________________________

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.
--000000000000cd8f47059b8f390a--


From nobody Tue Jan  7 08:53: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 7D92212084B for ; Tue,  7 Jan 2020 08:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Trb5vJR8ltSs for ; Tue,  7 Jan 2020 08:53:14 -0800 (PST)
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 E6E02120814 for ; Tue,  7 Jan 2020 08:53:13 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id y17so171235wrh.5 for ; Tue, 07 Jan 2020 08:53:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=H/+9cJsyZ5uLF9hORcmdlmOQCKXVtyMtyEy5KUpK+Kk=; b=Fv74Ftl5EXwqI6cPy02E75Kofe/LprlNmX6mq5j1akmlJvLu6lClCJkBnvErEygp+B Rs2cBmOVCVuiwkV4dmB2dXsRLD7s/GyxyBWAxxYnT8fEOcWgsDhVs3aiVVkfLy+ifH7a Le/Gk0RqP3TNFjcWVBrvfHEFP3AONIlRIYXtI7KOaQvl1O3lN3DUHbOpiCTCLMNkAHoI ryD2mxlYbl/QiPsMs7GVVfbFO1jkYSjjFjb614gTFmcQEqbjR4pxUaQS+/n36B8bayIC 4n6IG2eIgFtTgjGtCyRi4mPWKFEB4CLLNeFPeU1BTRkxsS7GDtkqmkX+tKGHlN9RDHDD aZOw==
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=H/+9cJsyZ5uLF9hORcmdlmOQCKXVtyMtyEy5KUpK+Kk=; b=h0du3XAT2nPGANqUGh9s/HmzAmN4Wgsda4GsCaesshzsIlQz/rs9KrDOsu38V5grwN wXM3r79mDIMKKH5CE79KElJwOdGO87igHj862wKZKmur3blOhWh21AIDAZWqt4/k0mVC nY+u/z+2z6pzkmI6WgOULqXJhoIxak7Yt0PtbsNWkUMxzSJofgE6VPhS38nrIsebXXPz xuWeneAmIu39T9S9wVtenBFwiYiwy6elkObVhN+Xvi208QFs5rZKIzPfVsfZtk/A7A/h rp/lW+NPgT1YWXdul2pPbJTzELyju6xjlZKvLY4Umo2wU+v1E1q5dpYXIHNJowHqxapu WYag==
X-Gm-Message-State: APjAAAWFTceP47ZnxKBTpkfuyVYtLuLocb9ICWBb4bffhvmcQQl3vKx5 +b4747nmA1vskyUt9YvMwF92I3T5/q6XjToA
X-Google-Smtp-Source: APXvYqwpvcafsj6xg6TL8LFIbpbK9qaRzpXASFa5CJCyH1pvAeImOkHBbJHaPG/CsGTZxHYP8tjYLQ==
X-Received: by 2002:adf:e78b:: with SMTP id n11mr29572wrm.10.1578415992095; Tue, 07 Jan 2020 08:53:12 -0800 (PST)
Received: from [10.30.4.222] ([213.151.95.77]) by smtp.gmail.com with ESMTPSA id r6sm487441wrq.92.2020.01.07.08.53.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 08:53:10 -0800 (PST)
From: Torsten Lodderstedt 
Content-Type: multipart/signed; boundary="Apple-Mail=_6343735D-ACA0-4610-803B-190BACB54932"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 7 Jan 2020 17:52:30 +0100
References:   
To: oauth 
In-Reply-To: 
Message-Id: <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 16:53:25 -0000

--Apple-Mail=_6343735D-ACA0-4610-803B-190BACB54932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1

> On 7. Jan 2020, at 17:25, Brian Campbell =
 wrote:
>=20
> +1
>=20
> On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov =
 wrote:
> +1 for the adoption of RAR
>=20
> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
>> This is a call for adoption for the OAuth 2.0 Rich Authorization =
Requests document.
>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_6343735D-ACA0-4610-803B-190BACB54932
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMDcxNjUyMzBaMC8GCSqGSIb3DQEJBDEiBCBVaLbhxZcLaPf+mR7Zd/NeGs9aqn4sSBgU
V83qbCDyDDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBACRJcL3YhkvmvM9L+eDKu3hSq5yPxLo/4tuJyOKWUN/39pPhCJmhLJd32IPG
3oF52BgIjSsLDIMEqsNC0oxuujXL+DMHCi9VNvia62D7maE+nS/kvYqGmy3r/I7klOnYmtHbEOeM
yViLtI8G48GgLnjRVG4PABYwpMZVU8LWtZLb4XmwarhBLYzN8HQsF6NZCV+PJhFiXlIWJDGGiOWo
doKIM7nIgw7K4LSo05QH5cG7KYkqYUB9lib2BlLyApl0dYshSO+q2fDZUdrWlb9auhhgdbW6wdX2
4Upt+suFdau/PKBQcoo+IY+L5m7tp069AtpoxySah9vAeRCVSCqpKUIAAAAAAAA=
--Apple-Mail=_6343735D-ACA0-4610-803B-190BACB54932--


From nobody Tue Jan  7 09:10:46 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 B4CDA120815; Tue,  7 Jan 2020 09:10:40 -0800 (PST)
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.115.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157841704055.20985.16524134992128411791@ietfa.amsl.com>
Date: Tue, 07 Jan 2020 09:10:40 -0800
Archived-At: 
Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-02-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jan 2020 17:10:44 -0000

The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-02-10 from 18:00 to 19:00 Europe/Vienna.

Agenda:
As mentioned in our earlier email we would like to get a better understanding of this RFC 6749 update. Ideally, we would like to hear your thoughts about the goals of this update and what changes you envision to take place. We have different options and we need to figure out what the best approach is to meet the expectations.

Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m2d06208053cadb653212b11cfc65eeaf
Meeting number: 648 921 722
Password: BWsAF9rT


Information about remote participation:
See below


From nobody Tue Jan  7 10:31: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 938A212013C for ; Tue,  7 Jan 2020 10:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 5H2o3vqv0k1L for ; Tue,  7 Jan 2020 10:31:43 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0749D1200F5 for ; Tue,  7 Jan 2020 10:31:42 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id k14so955997otn.4 for ; Tue, 07 Jan 2020 10:31:42 -0800 (PST)
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; bh=DuiravxyNO6sNQXKePrJC/9o+bbDDTs/vmAsncgVR+A=; b=kGgV17QbJ5qCBGphnD3/0ZiCe7LQOE9xUBxvluL/z3yUeJ8ngGloeQXEQGhaAmTkD0 IWU9zDCq7PEgX5AipPoD0bBjKw0nvywdFSv21dfWhDR4kjS+i7CNA6HSM33rstwkxt5P 0PYsv8TgTHnlc7uKG+YDVoyblvJaS+QQKOtRbmh9fURqrWk6oO72vYTRMVB7pdqbSRXC v6fsGcycCudA3+nmNmd3Q695lpvoiKAxZwOjsTDpqLG5EW36Rg3ekNsw4+8kbc7/Y+0v WXMdubH6I6+O8xnCXV2NusELD3jlyulgH+Symy5XUzCWmy/phzyS+XpkVOpZOUUqn2gO 80Ww==
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=DuiravxyNO6sNQXKePrJC/9o+bbDDTs/vmAsncgVR+A=; b=s29sCIhWAH+HNscPQNj0Zk2xa9OwXDWNeImJJPKU/YfGAt/BUIzZf9zwR+Uq5UxQ34 MqrZ2ItvoHvUDJLh1iMj0XK3PJ+eT0fAzizRx90E3IzVe9vF4sKlbNQwPh2DEYykQirF WW6Fd+V+FSzgDS15uVej5bJDbXc97bp3XBj2md+iSzWWhZqZJOcwHtVVNrYnbOM5SzVM 17vLqT+noccyvh3KrJbpNYYACjGYKH8PVEfyLuG8C3bExQtV3WAVy9+YvEyMuIOkQkO6 c343Ljks7cwB40x22MBZBa3wcGD2bOTHAcPbovjm7qPsx+awmaO2YW3NSSMmus2h6sQe Dukw==
X-Gm-Message-State: APjAAAWpww/O7kxkeLlbGS/nS/XzKwIkTmNdFo6hv7P9Gwk1jh6W+kQ/ 8WIYkSRTI5pJNLUOIT9u6G7God1ZMnsfe83guUQ0OlWY
X-Google-Smtp-Source: APXvYqwFAszwu6cysX+qbcMIP2zzZuvaAygzagaZvghanFGw1fNQFUgp677zCWvQ98lhpfbJay7KlTV3rRJ9eG5FGYY=
X-Received: by 2002:a9d:53cb:: with SMTP id i11mr1221007oth.158.1578421901772;  Tue, 07 Jan 2020 10:31:41 -0800 (PST)
MIME-Version: 1.0
References:    <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net>
In-Reply-To: <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net>
From: Steinar Noem 
Date: Tue, 7 Jan 2020 19:31:31 +0100
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000c2d703059b90fcd5"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 18:31:46 -0000

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

+1

tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt :

> +1
>
> > On 7. Jan 2020, at 17:25, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
> >
> > +1
> >
> > On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> > +1 for the adoption of RAR
> >
> > On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
> >> This is a call for adoption for the OAuth 2.0 Rich Authorization
> Requests document.
> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

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


+1

tir. 7. jan. 2020 kl. 17:53 skrev Torst=
en Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>:
=
+1



> On 7. Jan 2020, at 17:25, Brian Campbell <bcampbell=3D40pingidentity.co=
m@dmarc.ietf.org> wrote:

> 

> +1

> 

> On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <vladimir@connect2id.com>=
; wrote:

> +1 for the adoption of RAR

> 

> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:

>> This is a call for adoption for the OAuth 2.0 Rich Authorization R=
equests document.

>> https://datatracker.ietf.org/d=
oc/draft-lodderstedt-oauth-rar/ 

> _______________________________________________

> 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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
<=
div style=3D"color:rgb(80,0,80)">Vennli=
g hilsen

Steinar Noem
Partner Udelt AS
Systemutv=
ikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@u=
delt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.=
udelt.no=C2=A0|=C2=A0


--000000000000c2d703059b90fcd5--


From nobody Tue Jan  7 14:54: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 D77BC1200B3 for ; Tue,  7 Jan 2020 14:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3jsTd03Zd9G for ; Tue,  7 Jan 2020 14:54:23 -0800 (PST)
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 BFDD3120025 for ; Tue,  7 Jan 2020 14:54:22 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id w1so1312789ljh.5 for ; Tue, 07 Jan 2020 14:54:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QnIKO9B36gtS37QQKieC6dLXUBTbLVnChtG5/EIYSBs=; b=AEX4i8oFeFztYCNOcP8Gwu5E5KiELqwfMVdJ0I1Wc8ve3JXaGkanQm81FvKx7WJ/YQ wYXxBC3ttWrgyPH6rpOOR3XUycMi+04n8T7xnBH27xd2bAU333Bp0DpBYm/s1sykhHXW /T4F1e8W28XIfz0QtRFoE63QXMsxbtVYKRvubDEGIIXM+v6QiDckbxjWER5c4Za40NXm 8+nzCDtBrIoISV4stv5wfVXj54z8aWpNlvgp2IYg6IzSMGrIRDlg5LrXOUt6RpSUnMAB mGssB6X72j34wfxlvH2qkYEp833/evpy6CPa+igaH1Iyw9ALG7NZ4TI0Mfpsd1M89y7A pPbQ==
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=QnIKO9B36gtS37QQKieC6dLXUBTbLVnChtG5/EIYSBs=; b=sPULt+fTM3AqLom+FKGc6z8D4/FoBjrM5siSO7xsrwOEbQl/7GgUqyo5EdYpmYxGO8 vo/EFb23WTaFYQO5WtLluTt0bwpoqZSqlByaLqQWUfcp6ObeKasp8flFvDIhSypt0J/S sk1lUT1zQmXRw3JZ/AuvaG++3owdhKmOAaA3kwGiX0QwgmUAsGkS49xA6pow7Oy5O8RV gazXeDDWlapXyfzHUvZjdLxs3eeM0dRvSWY503SSfDh/ppr4BLxlupIdpDT8nJ+9+T8m LC6dXj1/mhg5YfsrvpeJeQjtSeZHf4+/xBeSDP0ki99PJBQ9R00zL8hLw9yxxPAKnQid 1YXw==
X-Gm-Message-State: APjAAAW7FI2Tmx+lGMuE0acLHIzeAWH2kGzwSQaBF2fjTWRCHBKzxv+6 aOV0zPrQ1UvF7oIRoq9JFhmOCSJ5Klr8t6uFdsAspPS/OpVt5Jq75WVdhdwLJSK0UCIIRQeFss0 qVVpKSi2+VodnqiU8
X-Google-Smtp-Source: APXvYqxyAyZLbeBx27oCWAYEnhD/pCxgzfs7elezvnBbjUgpSiG6Q+uWfMlYYvgshTlG58yFR3a7BaLAIPq9veDZIac=
X-Received: by 2002:a2e:9592:: with SMTP id w18mr1052076ljh.98.1578437660949;  Tue, 07 Jan 2020 14:54:20 -0800 (PST)
MIME-Version: 1.0
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>  <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>
In-Reply-To: <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>
From: Brian Campbell 
Date: Tue, 7 Jan 2020 15:53:53 -0700
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: Filip Skokan ,  "Richard Backman, Annabelle" , Dave Tonge ,  oauth , Nat Sakimura 
Content-Type: multipart/alternative; boundary="00000000000014e3fa059b94a8fb"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 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: Tue, 07 Jan 2020 22:54:27 -0000

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

A little more context about that proposed wording is in a github issue at
https://github.com/oauthstuff/draft-oauth-par/issues/38, which is different
driver than allowing a PAR endpoint to stash the encrypted request object
rather than decrypting/validating it. But it's kind of the same concept at
some level too - that there are some things that can't or won't be
validated at the PAR endpoint and those then have to be validated at the
authorization endpoint.

I rather like your suggested text, Vladimir, and have mentioned it in a
comment on the aforementioned issue.


On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov 
wrote:

> On 07/01/2020 00:22, Filip Skokan wrote:
>
> We've been discussing making the following change to the language
>
> The AS SHOULD validate the request in the same way as at the authorizatio=
n
>> endpoint. The AS MUST ensure that all parameters to the authorization
>> request are still valid at the time when the request URI is used.
>>
> Could you expand a bit on the second sentence?
>
> Alternative suggestion:
>
> The AS MUST validate the request in the same way as at the authorization
> endpoint, or complete the request validation at the authorization endpoin=
t.
>
> Vladimir
>
>
> This would allow the PAR endpoint to simply stash the encrypted request
> object instead of decrypting and validating it. All within the bounds of
> "SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t always r=
equire it". This
> supports "light weight PAR" implementation rather than introducing the
> unnecessary complexity in the form of a second JWKS.
>
> Best,
> *Filip*
>
>
> On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>
>> The issue isn=E2=80=99t that the PAR endpoint needs access to one specif=
ic
>> request object decryption key that could reasonably be shared across AS
>> endpoints, but that it actually needs access to the private keys for all
>> encryption public keys in the JWK set pointed to by the AS=E2=80=99s jwk=
s_uri
>> metadata property. Since there is no way to designate one particular key=
 as
>> the one to use for encrypting request objects, clients may reasonably us=
e
>> any encryption public key in the JWK set to encrypt a request object. As
>> one example of how this could expose sensitive data to the PAR endpoint,=
 if
>> the PAR endpoint has all the decryption keys for the keys in the AS=E2=
=80=99s JWK
>> set, it would be able to decrypt ID Tokens sent in id_token_hint request
>> parameters. As more and more use cases develop for encrypting blobs for =
the
>> AS, this issue will only get worse.
>>
>>
>>
>> The PAR endpoint can=E2=80=99t simply stash the encrypted request object=
, as it
>> is required to verify the request, according to =C2=A72.1:
>>
>>
>>
>> The AS MUST process the request as follows:
>>
>>
>>
>> ...
>>
>>
>>
>> 3.  The AS MUST validate the request in the same way as at the
>>
>>           authorization endpoint. ...
>>
>>
>>
>> This language needs to be more flexible, IMHO, to allow for lightweight
>> PAR endpoints that may not have the information or authority needed to
>> perform all the validation that happens at the authorization endpoint. I
>> need to think about this more before I can say if it would adequately
>> address my concerns, but it=E2=80=99d be a good start and makes sense in=
 its own
>> right.
>>
>>
>>
>> I think it=E2=80=99s pretty risky for us to base decision on an assumpti=
on that
>> no one is going to need or want to encrypt pushed request objects,
>> particularly when they=E2=80=99re JWTs, and JWTs have well established s=
upport for
>> encryption, and encrypted JWTs are supported by pass-by-value in OIDC an=
d
>> draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for =
why
>> someone might want to do this:
>>
>>    1. The request object is passed by reference, and accessible on the
>>    public Internet.
>>    2. The request object contains sensitive transaction-related data in
>>    RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=
=80=99t need to have
>>    access to.
>>    3. The AS requires request object encryption to minimize exposure to
>>    the hosted PAR endpoint service it uses.
>>    4. #2, but the threat vector is gaps in end-to-end TLS.
>>    5. Any of the above, but the concern is message integrity, and the AS
>>    requires requested objects to be encrypted for confidentiality and
>>    integrity protection and does not support signed request objects.
>>
>>
>>
>> =E2=80=93
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> *From: *Neil Madden 
>> *Date: *Monday, January 6, 2020 at 6:29 AM
>> *To: *Brian Campbell 
>> *Cc: *"Richard Backman, Annabelle" , Nat Sakimura <
>> nat@sakimura.org>, Dave Tonge , Torsten
>> Lodderstedt >, oauth =
<
>> oauth@ietf.org>
>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>>
>>
>>
>> Agreed.
>>
>>
>>
>> In addition, I'm not sure why the PAR endpoint would need access to the
>> decryption keys at all. If you're using encrypted request objects then t=
he
>> PAR endpoint receives an encrypted JWT and then later makes the same (st=
ill
>> encrypted) JWT available to the authorization endpoint. If the PAR endpo=
int
>> is doing any kind of decryption or validation on behalf of the
>> authorization endpoint then they are clearly not in separate trust
>> boundaries.
>>
>>
>>
>> -- Neil
>>
>>
>>
>>
>>
>> On 6 Jan 2020, at 13:57, Brian Campbell <
>> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>
>>
>>
>> I really struggle to see the assumption that an entity be able to use th=
e
>> same key to decrypt the same type of message ultimately intended for the
>> same purpose as an artificial limit. The same general assumption
>> underlies everything else in OAuth/OIDC (Vladimir's post points to some =
but
>> not all examples of such). There's no reason for PAR to make a one-off
>> exception. And should there be some deployment specific reason that trul=
y
>> requires that kind of isolation, there are certainly implementation opti=
ons
>> that aren't compatibility-breaking. And having said all that, I'm honest=
ly
>> a little surprised anyone is thinking much about encrypted request objec=
ts
>> with PAR as, at least with my limited imagination, there's not really a
>> need for it.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote:
>>
>> PAR introduces an added wrinkle for encrypted request objects: the PAR
>> endpoint and authorization endpoint may not have access to the same
>> cryptographic keys, even though they're both part of the "authorization
>> server." Since they're different endpoints with different roles, it's
>> reasonable to put them in separate trust boundaries. There is no way to
>> support this isolation with just a single "jwks_uri" metadata property.
>>
>> The two options that I see are:
>>
>> 1. Define a new par_jwks_uri metadata property.
>> 2. Explicitly state that this separation is not supported.
>>
>> I strongly perfer #1 as it has a very minor impact on deployments that
>> don't care (i.e., they just set par_jwks_uri and jwks_uri to the same
>> value) and failing to support this trust boundary creates an artificial
>> limit on implementation architecture and could lead to
>> compatibility-breaking workarounds.
>>
>> =E2=80=93
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <
>> oauth-bounces@ietf.org on behalf of torsten=3D
>> 40lodderstedt.net@dmarc.ietf.org> wrote:
>>
>>     Hi Filip,
>>
>>     > On 31. Dec 2019, at 16:22, Filip Skokan  wrote=
:
>>     >
>>     > I don't think we need a *_auth_method_* metadata for every endpoin=
t
>> the client calls directly, none of the new specs defined these (e.g. dev=
ice
>> authorization endpoint or CIBA), meaning they also didn't follow the sch=
eme
>> from RFC 8414 where introspection and revocation got its own metadata. I=
n
>> most cases the unfortunately named `token_endpoint_auth_method` and its
>> related metadata is what's used by clients for all direct calls anyway.
>>     >
>>     > The same principle could be applied to signing (and encryption)
>> algorithms as well.
>>     >
>>     > This I do not follow, auth methods and their signing is dealt with
>> by using `token_endpoint_auth_methods_supported` and
>> `token_endpoint_auth_signing_alg_values_supported` - there's no encrypti=
on
>> for the `_jwt` client auth methods.
>>     > Unless it was meant to address the Request Object signing and
>> encryption metadata, which is defined and IANA registered by OIDC. PAR o=
nly
>> references JAR section 6.1 and 6.2 for decryption/signature validation a=
nd
>> these do not mention the metadata (e.g. request_object_signing_alg) anym=
ore
>> since draft 07.
>>
>>     Dammed! You are so right. Sorry, I got confused somehow.
>>
>>     >
>>     > PS: I also found this comment related to the same question about
>> auth metadata but for CIBA.
>>
>>     Thanks for sharing.
>>
>>     >
>>     > Best,
>>     > Filip
>>
>>     thanks,
>>     Torsten.
>>
>>     >
>>     >
>>     > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>     > Hi all,
>>     >
>>     > Ronald just sent me an email asking whether we will define metadat=
a
>> for
>>     >
>>     > pushed_authorization_endpoint_auth_methods_supported and
>>     > pushed_authorization_endpoint_auth_signing_alg_values_supported.
>>     >
>>     > The draft right now utilises the existing token endpoint
>> authentication methods so there is basically no need to define another
>> parameter. The same principle could be applied to signing (and encryptio=
n)
>> algorithms as well.
>>     >
>>     > What=E2=80=99s your opinion?
>>     >
>>     > 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
>

--=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._

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


A little more context about that proposed wording is =
in a github issue at https://github.com/oauthstuff/draft-oauth-p=
ar/issues/38, which is different driver than allowing a PAR endpoint to=
 stash the
          encrypted request object rather than decrypting/validating
          it. But it's kind of the same concept at some level too - tha=
t there are some things that can't or won't be validated at the PAR=
 endpoint and those then have to be validated at the authorization endpoint=
.
=C2=A0
I rather like your suggested text, Vladimi=
r, and have mentioned it in a comment on the aforementioned issue. 


On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov <vladimir@connect2id.com>=
 wrote:

 =20
   =20
 =20
  

    
On 07/01/2020 00:22, Filip Skokan
      wrote:

    

    

     =20
      

        
We've been discussing making the following=C2=A0change to =
the
          language

        


        

        
The
          AS SHOULD validate the request in the same way as at the
          authorization endpoint. The AS MUST ensure that all parameters
          to the authorization request are still valid at the time when
          the request URI is used.

        

      

    

    
Could you expand a bit on the second sentence?

    
Alternative suggestion:

    
The AS MUST validate the request in the same way as at the
      authorization endpoint, or complete the request validation at the
      authorization endpoint.

    

    
Vladimir

    


    

    

      

        
This would allow the PAR endpoint to simply stash the
          encrypted request object instead of decrypting and validating
          it. All within the bounds of "SHOULD -=C2=A0We=E2=80=99d lik=
e you to do
          this, but we can=E2=80=99t always require it". This supports=
 "light
          weight PAR" implementation rather than introducing the
          unnecessary complexity in the form of a second JWKS.

        

        

          
Best,

            Filip

        

        

      

      

      

        
On Mon, 6 Jan 2020 at 23:00,
          Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&g=
t;
          wrote:

        

        

          

            

              
The issue isn=E2=80=99t that the PAR e=
ndpoint
                needs access to one specific request object decryption
                key that could reasonably be shared across AS endpoints,
                but that it actually needs access to the private keys
                for all encryption public keys in the JWK set pointed to
                by the AS=E2=80=99s jwks_uri metadata property. Since there=
 is
                no way to designate one particular key as the one to use
                for encrypting request objects, clients may reasonably
                use any encryption public key in the JWK set to encrypt
                a request object. As one example of how this could
                expose sensitive data to the PAR endpoint, if the PAR
                endpoint has all the decryption keys for the keys in the
                AS=E2=80=99s JWK set, it would be able to decrypt ID Tokens=
 sent
                in id_token_hint request parameters. As more and more
                use cases develop for encrypting blobs for the AS, this
                issue will only get worse.

              
=C2=A0

              
The PAR endpoint can=E2=80=99t simply =
stash
                the encrypted request object, as it is required to
                verify the request, according to =C2=A72.1:

              
=C2=A0

              
=
The AS MUST process the request as follows:

              
=
=C2=A0

              
=
...

              
=
=C2=A0

              
=
3.=C2=A0 The AS MUST validate the request in the same way as at the<=
/pre>
              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0=C2=A0authorization endpoint. ...

              
=C2=A0

              
This language needs to be more
                flexible, IMHO, to allow for lightweight PAR endpoints
                that may not have the information or authority needed to
                perform all the validation that happens at the
                authorization endpoint. I need to think about this more
                before I can say if it would adequately address my
                concerns, but it=E2=80=99d be a good start and makes sense =
in
                its own right.

              
=C2=A0

              
I think it=E2=80=99s pretty risky for =
us to
                base decision on an assumption that no one is going to
                need or want to encrypt pushed request objects,
                particularly when they=E2=80=99re JWTs, and JWTs have well
                established support for encryption, and encrypted JWTs
                are supported by pass-by-value in OIDC and
                draft-ietf-oauth-jwsreq. But if you insist, here are a
                few examples for why someone might want to do this:

              
    
                
  1. The request object is passed
                  by reference, and accessible on the public Internet.
    2. 
                
  2. The request object contains
                  sensitive transaction-related data in RAR parameters
                  that the client=E2=80=99s authN/authZ stack doesn=E2=80=
=99t need to
                  have access to.
    3. 
                
  3. The AS requires request objec=
t
                  encryption to minimize exposure to the hosted PAR
                  endpoint service it uses.
    4. 
                
  4. #2, but the threat vector is
                  gaps in end-to-end TLS.
    5. 
                
  5. Any of the above, but the
                  concern is message integrity, and the AS requires
                  requested objects to be encrypted for confidentiality
                  and integrity protection and does not support signed
                  request objects.
    6. 
              

              
=C2=A0

              

                
=E2=
=80=93=C2=A0

                
Annab=
elle
                    Richard Backman

                
AWS
                    Identity

              

              
=C2=A0

              
=C2=A0

              

                
From: Neil =
Madden <n=
eil.madden@forgerock.com>

                    Date: Monday, January 6, 2020 at 6:29 AM

                    To: Brian Campbell <bcampbell@pingidentity.com>
                    Cc: "Richard Backman, Annabelle" <<=
a href=3D"mailto:richanna@amazon.com" target=3D"_blank">richanna@amazon.com=
>,
                    Nat Sakimura <nat@sakimura.org>,
                    Dave Tonge <dave.tonge@moneyhub.com>,
                    Torsten Lodderstedt <torsten@lodderstedt..net>,
                    oauth <oauth@ietf.org>

                    Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG]
                    PAR metadata

              

              

                
=C2=A0

              

              
Agreed. 

              

                
=C2=A0

              

              

                
In addition, I'm not sure why th=
e
                  PAR endpoint would need access to the decryption keys
                  at all. If you're using encrypted request objects the=
n
                  the PAR endpoint receives an encrypted JWT and then
                  later makes the same (still encrypted) JWT available
                  to the authorization endpoint. If the PAR endpoint is
                  doing any kind of decryption or validation on behalf
                  of the authorization endpoint then they are clearly
                  not in separate trust boundaries.

              

              

                
=C2=A0

              

              

                
-- Neil

              

              

                
=C2=A0

                

                  


                    

                  

                  

                    

                      
On 6 Jan 2020, at 13:57,
                        Brian Campbell <bcampbell=3D40pingidenti=
ty.com@dmarc.ietf.org>
                        wrote:

                    

                    
=C2=A0

                    

                      

                        

                          
I really struggle to see
                            the assumption that an entity be able to use
                            the same key to decrypt the same type of
                            message ultimately intended for the same
                            purpose as an artificial limit. The same
                            general assumption =C2=A0 underlies everything
                            else in OAuth/OIDC (Vladimir's post points
                            to some but not all examples of such).
                            There's no reason for PAR to make a one-off
                            exception. And should there be some
                            deployment specific reason that truly
                            requires that kind of isolation, there are
                            certainly implementation options that aren'=
t
                            compatibility-breaking. And having said all
                            that, I'm honestly a little surprised anyon=
e
                            is thinking much about encrypted request
                            objects with PAR as, at least with my
                            limited imagination, there's not really a
                            need for it.
                          

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                        

                          
=C2=A0

                        

                      

                      
=C2=A0

                      

                        

                          
On Fri, Jan 3, 2020 at
                            2:43 PM Richard Backman, Annabelle
                            <richanna=3D40amazon.com@dmarc.ietf.org>
                            wrote:

                        

                        

                          
PAR introduces an added
                            wrinkle for encrypted request objects: the
                            PAR endpoint and authorization endpoint may
                            not have access to the same cryptographic
                            keys, even though they're both part of the
                            "authorization server." Since they=
9;re
                            different endpoints with different roles,
                            it's reasonable to put them in separate
                            trust boundaries. There is no way to support
                            this isolation with just a single "jwks_ur=
i"
                            metadata property.

                            

                            The two options that I see are:

                            

                            1. Define a new par_jwks_uri metadata
                            property.

                            2. Explicitly state that this separation is
                            not supported.

                            

                            I strongly perfer #1 as it has a very minor
                            impact on deployments that don't care (i.e.=
,
                            they just set par_jwks_uri and jwks_uri to
                            the same value) and failing to support this
                            trust boundary creates an artificial limit
                            on implementation architecture and could
                            lead to compatibility-breaking workarounds.

                            

                            =E2=80=93 

                            Annabelle Richard Backman

                            AWS Identity

                            

                            

                            On 12/31/19, 8:07 AM, "OAuth on behalf of
                            Torsten Lodderstedt" <oauth-bounces@ietf.org
                            on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.=
org>
                            wrote:

                            

                            =C2=A0 =C2=A0 Hi Filip, 

                            

                            =C2=A0 =C2=A0 > On 31. Dec 2019, at 16:22, F=
ilip
                            Skokan <panva.ip@gmail.com>
                            wrote:

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > I don't think we need a
                            *_auth_method_* metadata for every endpoint
                            the client calls directly, none of the new
                            specs defined these (e.g. device
                            authorization endpoint or CIBA), meaning
                            they also didn't follow the scheme from RFC
                            8414 where introspection and revocation got
                            its own metadata. In most cases the
                            unfortunately named
                            `token_endpoint_auth_method` and its related
                            metadata is what's used by clients for all
                            direct calls anyway.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > The same principle could be =
applied
                            to signing (and encryption) algorithms as
                            well.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > This I do not follow, auth m=
ethods
                            and their signing is dealt with by using
                            `token_endpoint_auth_methods_supported` and
`token_endpoint_auth_signing_alg_values_supported` - there's no
                            encryption for the `_jwt` client auth
                            methods.
                            

                            =C2=A0 =C2=A0 > Unless it was meant to addre=
ss the
                            Request Object signing and encryption
                            metadata, which is defined and IANA
                            registered by OIDC. PAR only references JAR
                            section 6.1 and 6.2 for decryption/signature
                            validation and these do not mention the
                            metadata (e.g. request_object_signing_alg)
                            anymore since draft 07.

                            

                            =C2=A0 =C2=A0 Dammed! You are so right. Sorry, =
I got
                            confused somehow. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > PS: I also found this commen=
t
                            related to the same question about auth
                            metadata but for CIBA.

                            

                            =C2=A0 =C2=A0 Thanks for sharing. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > Best,

                            =C2=A0 =C2=A0 > Filip

                            

                            =C2=A0 =C2=A0 thanks,

                            =C2=A0 =C2=A0 Torsten. 

                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > On Tue, 31 Dec 2019 at 15:38=
,
                            Torsten Lodderstedt <torsten@lodderstedt.net>
                            wrote:

                            =C2=A0 =C2=A0 > Hi all,

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > Ronald just sent me an email=
 asking
                            whether we will define metadata for 

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 >
                            pushed_authorization_endpoint_auth_methods_supp=
orted
                            and

                            =C2=A0 =C2=A0 >
                            pushed_authorization_endpoint_auth_signing_alg_=
values_supported.

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > The draft right now utilises=
 the
                            existing token endpoint authentication
                            methods so there is basically no need to
                            define another parameter. The same principle
                            could be applied to signing (and encryption)
                            algorithms as well.
                            

                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > What=E2=80=99s your opinion?=


                            =C2=A0 =C2=A0 > 

                            =C2=A0 =C2=A0 > best regards,

                            =C2=A0 =C2=A0 > Torsten.

                            

                            

                            

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

                            https://www.ietf.org/mailman/listinfo/oauth<=
/p>
                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


_______________________________________________

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.
--00000000000014e3fa059b94a8fb--


From nobody Tue Jan  7 15:53: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 E18C1120020 for ; Tue,  7 Jan 2020 15:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 871b7ySHdF6f for ; Tue,  7 Jan 2020 15:53:37 -0800 (PST)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0: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 AFDD4120018 for ; Tue,  7 Jan 2020 15:53:37 -0800 (PST)
Received: by mail-pl1-x62c.google.com with SMTP id g6so341918plp.6 for ; Tue, 07 Jan 2020 15:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=dqk0NcjhybFEAtoB/S7ML/VuMdck4N6T6Vn/oYz1EIo=; b=uAcg3n1A3A/aY/9i4Js7eCEhsibywVSsuTSalKi9yHrPVf3uD661VMkGs4yuvRWCg6 IMoa4JJxcw6haAI6G5h46jdxEyq9GThmN8uy3vum81fxxdJ6VfP73MwE83PaUgCyHVgA 67bCstzfChx4qICOQxsXg/W8Zf/s9pHF8sMJn3bX7KgWjK7TDdKAyT8IJ6sVzU9Kmx9J sqlHlfUWv1oB3zUeM0xD7LhLB/PlLshcTBU8szgvBfYcLLqggXMjMsRiha0K/8waLhIW lAqksopoOHfPxue5+aDmdbX9aOlD+HT/g7BXI5mP31yD41QaJcc8ZnNGrNjI8GiS21AD +T6A==
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=dqk0NcjhybFEAtoB/S7ML/VuMdck4N6T6Vn/oYz1EIo=; b=P5wOXSL4WOeBg/xq5Zze87nz/q9o1R7ZH0K61JYu7o+kwIyjc4kjEErmNt/M9aGAkO au7CnulBm5d9yuszOwT4xBuoU97oI3FHMazwE4P6jKSYesfh3cMoD2YZGTtAFZWAhovw 2/C799Ee+UGoCUfV49TuJ+SRKhnIV8PPePfIGWaiHLE4u5WkjX9NzcSfwUncBkVGDgMx 4+v96V+ddSMAGj0yWz42M1ifBEy5zhkXhoipLDAT//1/Cp71ExwyIG8yXUtCpLhidCN/ PJICT7ayJ3lxW4q+Kb2AI/zvy3ofKYVsC1qw8agfgPblU111Niwpi/d/zzvJpiw1Adr3 JJkA==
X-Gm-Message-State: APjAAAVdmtrnHj4Ni4uzQSCwELSRLi1NH5YZLzPKxmIx+JBUbLxhXnm6 +sfEO65NkgeyLGilrJ6/2apEbSTqZQmuIg==
X-Google-Smtp-Source: APXvYqye3g7jmp7eGTzvKnwUnM4dDYiYCryeLJ2FvOs2H3rflWRWhqAmYlT2nuJ7XrYvTsJgNt4Dyw==
X-Received: by 2002:a17:902:8207:: with SMTP id x7mr2311627pln.286.1578441216830;  Tue, 07 Jan 2020 15:53:36 -0800 (PST)
Received: from [192.168.26.11] (fs96f9c9c7.tkyc005.ap.nuro.jp. [150.249.201.199]) by smtp.gmail.com with ESMTPSA id y6sm893365pgc.10.2020.01.07.15.53.35 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 15:53:35 -0800 (PST)
From: Joseph Heenan 
Content-Type: multipart/alternative; boundary="Apple-Mail=_20170A31-FD53-4CE4-A6E5-B75142AE5F8E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 8 Jan 2020 08:53:33 +0900
References:    <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net> 
To: oauth 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 07 Jan 2020 23:53:41 -0000

--Apple-Mail=_20170A31-FD53-4CE4-A6E5-B75142AE5F8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1

> On 8 Jan 2020, at 03:31, Steinar Noem  wrote:
>=20
> +1
>=20
> tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt =
>:
> +1
>=20
> > On 7. Jan 2020, at 17:25, Brian Campbell =
> wrote:
> >=20
> > +1
> >=20
> > On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov =
> wrote:
> > +1 for the adoption of RAR
> >=20
> > On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
> >> This is a call for adoption for the OAuth 2.0 Rich Authorization =
Requests document.
> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ =
=20
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth =

> >=20
> > CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> > 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
> Vennlig hilsen
>=20
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
> =20
> | steinar@udelt.no  | hei@udelt.no =
  | +47 955 21 620 <> | www.udelt.no =
 |=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_20170A31-FD53-4CE4-A6E5-B75142AE5F8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

+1

On 8 Jan 2020, at 03:31, Steinar Noem <steinar@udelt.no> =
wrote:

+1

tir. 7. jan. 2020 kl. 17:53 skrev Torsten =
Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>:
+1



> On 7. Jan 2020, at 17:25, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
=

> 

> +1

> 

> On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

> +1 for the adoption of RAR

> 

> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:

>> This is a call for adoption for the OAuth 2.0 Rich =
Authorization Requests document.

>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

> 

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

> OAuth mailing list

> OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 

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

=

--Apple-Mail=_20170A31-FD53-4CE4-A6E5-B75142AE5F8E--


From nobody Tue Jan  7 18:25: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 C158812007C for ; Tue,  7 Jan 2020 18:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbdeWu0vLzmU for ; Tue,  7 Jan 2020 18:25:17 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C8C1200F5 for ; Tue,  7 Jan 2020 18:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578450318; x=1609986318; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7COYEfXG+R9s22LtGds5nckxJK6UErSwubxTBilN2Ds=; b=uSfD79TCLPhiqpxnFuMlgcUSg4WMSfJWh7u3JNjWWaDUzKmmjT6P90ll /O87ExfTeh01d1BmhV7mAac3urKCaenFpFXxCiEZBeGg/oAkpR9aSVGot AtqdTJzSvWvdWv1QhfQOBfLr1i/Q8MYqBMbUSE386slD5ChniyQqVOf9W Y=;
IronPort-SDR: PqCO+gqdVKStgyVRyjc2zd/5M5zGTgP/j7XkwFnm0/SFoPNNfw8Yymi6I+/s+hOxX2Zj5wD7L/ g7U8ebYG89+g==
X-IronPort-AV: E=Sophos;i="5.69,408,1571702400"; d="scan'208,217";a="8942337"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 08 Jan 2020 02:25:05 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-98acfc19.us-east-1.amazon.com (Postfix) with ESMTPS id E8B41A2531; Wed,  8 Jan 2020 02:25:02 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 02:25:01 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 02:25:01 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 02:25:01 +0000
From: "Richard Backman, Annabelle" 
To: Brian Campbell , "Vladimir Dzhuvinov" 
CC: Filip Skokan , Dave Tonge , oauth , Nat Sakimura 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata
Thread-Index: AQHVxWKisgp8/YepBUa8k3AeCkDzNqffz+WA//+04YA=
Date: Wed, 8 Jan 2020 02:25:01 +0000
Message-ID: <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com>
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>  <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.115]
Content-Type: multipart/alternative; boundary="_000_234E2C284CF5462683D5719B176C418Bamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR 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: Wed, 08 Jan 2020 02:25:23 -0000

--_000_234E2C284CF5462683D5719B176C418Bamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayBpdOKAmXMgY2xlYXJlciBpZiB3ZSBzcGxpdCBvdXQgdGhlIHJlcXVpcmVtZW50cyBm
b3IgdGhlIFBBUiBlbmRwb2ludCBhbmQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGF1dGhvcml6
YXRpb24gZW5kcG9pbnQsIGdpdmVuIHRoYXQgdGhleSBhcmUgZWFjaCBjb3ZlcmVkIGluIGRpZmZl
cmVudCBzZWN0aW9ucyBvZiB0aGUgZG9jICgyIGFuZCA0LCByZXNwZWN0aXZlbHkpLiBXaXRoIHRo
YXQgaW4gbWluZCwgaGVyZSBhcmUgYSBjb3VwbGUgc3VnZ2VzdGlvbnM6DQoNCkZvciB0aGUgdGV4
dCBpbiBTZWN0aW9uIDIuMToNCg0KMy4gIFRoZSBBUyBNVVNUIHZhbGlkYXRlIHRoZSBwdXNoZWQg
cmVxdWVzdCBhcyBpdCB3b3VsZCBhbiBhdXRob3JpemF0aW9uDQogICAgcmVxdWVzdCBzZW50IHRv
IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBob3dldmVyIHRoZSBBUyBNQVkgb21pdA0KICAg
IHZhbGlkYXRpb24gc3RlcHMgdGhhdCBpdCBpcyB1bmFibGUgdG8gcGVyZm9ybSB3aGVuIHByb2Nl
c3NpbmcgdGhlDQogICAgcHVzaGVkIHJlcXVlc3QuDQoNCg0KQWRkaXRpb25hbCB0ZXh0IGZvciBT
ZWN0aW9uIDQgKG5vdGUgdGhhdCB0aGlzIHNlY3Rpb24gcGVydGFpbnMgdG8gdGhlIGF1dGhvcml6
YXRpb24gZW5kcG9pbnQpOg0KDQpUaGUgQVMgTVVTVCB2YWxpZGF0ZSBhdXRob3JpemF0aW9uIHJl
cXVlc3RzIGFyaXNpbmcgZnJvbSBhIHB1c2hlZCByZXF1ZXN0IGFzDQppdCB3b3VsZCBhbnkgb3Ro
ZXIgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiAgVGhlIEFTIE1BWSBvbWl0IHZhbGlkYXRpb24gc3Rl
cHMNCnRoYXQgaXQgcGVyZm9ybWVkIHdoZW4gdGhlIHJlcXVlc3Qgd2FzIHB1c2hlZCwgcHJvdmlk
ZWQgdGhhdCBpdCBjYW4gdmFsaWRhdGUNCnRoYXQgdGhlIHJlcXVlc3Qgd2FzIGEgcHVzaGVkIHJl
cXVlc3QsIGFuZCB0aGF0IHRoZSByZXF1ZXN0IGhhcyBub3QgYmVlbg0KbW9kaWZpZWQgaW4gYSB3
YXkgdGhhdCB3b3VsZCBhZmZlY3QgdGhlIG91dGNvbWUgb2YgdGhlIG9taXR0ZWQgc3RlcHMuDQoN
Cg0KVGhpcyBpcyBsb25nZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0IGFuZCB0aGUgb3RoZXIgcHJv
cG9zYWxzLCBidXQgaXQgYWRkcyBhIGZldyBpbXBvcnRhbnQgcG9pbnRzOg0KDQogICogICBUdXJu
cyB0aGUgMi4xIFNIT1VMRCBiYWNrIGludG8gYSBNVVNULCB3aXRoIGFuIGV4cGxpY2l0IGV4Y2Vw
dGlvbiBmb3IgdmFsaWRhdGlvbiB0aGF0IGNhbuKAmXQgYmUgZG9uZSB5ZXQuDQogICogICBSZWlu
Zm9yY2VzIHRoZSBmYWN0IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgc3RpbGwgbmVl
ZHMgdG8gZG8gdmFsaWRhdGlvbi4NCiAgKiAgIENsZWFybHkgc3RhdGVzIHJlcXVpcmVtZW50cyBm
b3Igd2hlbiBhbiBBUyBjYW4gdHJ1c3QgdGhhdCB2YWxpZGF0aW9uIGhhcHBlbmVkIGF0IHRoZSBQ
QVIgZW5kcG9pbnQuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50
aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5j
b21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDcsIDIwMjAgYXQgMjo1
NCBQTQ0KVG86IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQpD
YzogRmlsaXAgU2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+LCAiUmljaGFyZCBCYWNrbWFuLCBB
bm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPiwgRGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBt
b25leWh1Yi5jb20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+LCBOYXQgU2FraW11cmEgPG5hdEBz
YWtpbXVyYS5vcmc+DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0dd
IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFBBUiBtZXRhZGF0YQ0KDQpBIGxpdHRsZSBtb3JlIGNv
bnRleHQgYWJvdXQgdGhhdCBwcm9wb3NlZCB3b3JkaW5nIGlzIGluIGEgZ2l0aHViIGlzc3VlIGF0
IGh0dHBzOi8vZ2l0aHViLmNvbS9vYXV0aHN0dWZmL2RyYWZ0LW9hdXRoLXBhci9pc3N1ZXMvMzgs
IHdoaWNoIGlzIGRpZmZlcmVudCBkcml2ZXIgdGhhbiBhbGxvd2luZyBhIFBBUiBlbmRwb2ludCB0
byBzdGFzaCB0aGUgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0IHJhdGhlciB0aGFuIGRlY3J5cHRp
bmcvdmFsaWRhdGluZyBpdC4gQnV0IGl0J3Mga2luZCBvZiB0aGUgc2FtZSBjb25jZXB0IGF0IHNv
bWUgbGV2ZWwgdG9vIC0gdGhhdCB0aGVyZSBhcmUgc29tZSB0aGluZ3MgdGhhdCBjYW4ndCBvciB3
b24ndCBiZSB2YWxpZGF0ZWQgYXQgdGhlIFBBUiBlbmRwb2ludCBhbmQgdGhvc2UgdGhlbiBoYXZl
IHRvIGJlIHZhbGlkYXRlZCBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4uDQoNCkkgcmF0
aGVyIGxpa2UgeW91ciBzdWdnZXN0ZWQgdGV4dCwgVmxhZGltaXIsIGFuZCBoYXZlIG1lbnRpb25l
ZCBpdCBpbiBhIGNvbW1lbnQgb24gdGhlIGFmb3JlbWVudGlvbmVkIGlzc3VlLg0KDQoNCk9uIFR1
ZSwgSmFuIDcsIDIwMjAgYXQgNjo1OCBBTSBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KT24g
MDcvMDEvMjAyMCAwMDoyMiwgRmlsaXAgU2tva2FuIHdyb3RlOg0KV2UndmUgYmVlbiBkaXNjdXNz
aW5nIG1ha2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgbGFuZ3VhZ2UNCg0KVGhlIEFT
IFNIT1VMRCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBpbiB0aGUgc2FtZSB3YXkgYXMgYXQgdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBBUyBNVVNUIGVuc3VyZSB0aGF0IGFsbCBwYXJhbWV0
ZXJzIHRvIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgYXJlIHN0aWxsIHZhbGlkIGF0IHRoZSB0
aW1lIHdoZW4gdGhlIHJlcXVlc3QgVVJJIGlzIHVzZWQuDQoNCkNvdWxkIHlvdSBleHBhbmQgYSBi
aXQgb24gdGhlIHNlY29uZCBzZW50ZW5jZT8NCg0KQWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbjoNCg0K
VGhlIEFTIE1VU1QgdmFsaWRhdGUgdGhlIHJlcXVlc3QgaW4gdGhlIHNhbWUgd2F5IGFzIGF0IHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBvciBjb21wbGV0ZSB0aGUgcmVxdWVzdCB2YWxpZGF0
aW9uIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50Lg0KDQpWbGFkaW1pcg0KDQoNClRoaXMg
d291bGQgYWxsb3cgdGhlIFBBUiBlbmRwb2ludCB0byBzaW1wbHkgc3Rhc2ggdGhlIGVuY3J5cHRl
ZCByZXF1ZXN0IG9iamVjdCBpbnN0ZWFkIG9mIGRlY3J5cHRpbmcgYW5kIHZhbGlkYXRpbmcgaXQu
IEFsbCB3aXRoaW4gdGhlIGJvdW5kcyBvZiAiU0hPVUxEIC0gV2XigJlkIGxpa2UgeW91IHRvIGRv
IHRoaXMsIGJ1dCB3ZSBjYW7igJl0IGFsd2F5cyByZXF1aXJlIGl0Ii4gVGhpcyBzdXBwb3J0cyAi
bGlnaHQgd2VpZ2h0IFBBUiIgaW1wbGVtZW50YXRpb24gcmF0aGVyIHRoYW4gaW50cm9kdWNpbmcg
dGhlIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgaW4gdGhlIGZvcm0gb2YgYSBzZWNvbmQgSldLUy4N
Cg0KQmVzdCwNCkZpbGlwDQoNCg0KT24gTW9uLCA2IEphbiAyMDIwIGF0IDIzOjAwLCBSaWNoYXJk
IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn
PG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNClRoZSBpc3N1ZSBp
c27igJl0IHRoYXQgdGhlIFBBUiBlbmRwb2ludCBuZWVkcyBhY2Nlc3MgdG8gb25lIHNwZWNpZmlj
IHJlcXVlc3Qgb2JqZWN0IGRlY3J5cHRpb24ga2V5IHRoYXQgY291bGQgcmVhc29uYWJseSBiZSBz
aGFyZWQgYWNyb3NzIEFTIGVuZHBvaW50cywgYnV0IHRoYXQgaXQgYWN0dWFsbHkgbmVlZHMgYWNj
ZXNzIHRvIHRoZSBwcml2YXRlIGtleXMgZm9yIGFsbCBlbmNyeXB0aW9uIHB1YmxpYyBrZXlzIGlu
IHRoZSBKV0sgc2V0IHBvaW50ZWQgdG8gYnkgdGhlIEFT4oCZcyBqd2tzX3VyaSBtZXRhZGF0YSBw
cm9wZXJ0eS4gU2luY2UgdGhlcmUgaXMgbm8gd2F5IHRvIGRlc2lnbmF0ZSBvbmUgcGFydGljdWxh
ciBrZXkgYXMgdGhlIG9uZSB0byB1c2UgZm9yIGVuY3J5cHRpbmcgcmVxdWVzdCBvYmplY3RzLCBj
bGllbnRzIG1heSByZWFzb25hYmx5IHVzZSBhbnkgZW5jcnlwdGlvbiBwdWJsaWMga2V5IGluIHRo
ZSBKV0sgc2V0IHRvIGVuY3J5cHQgYSByZXF1ZXN0IG9iamVjdC4gQXMgb25lIGV4YW1wbGUgb2Yg
aG93IHRoaXMgY291bGQgZXhwb3NlIHNlbnNpdGl2ZSBkYXRhIHRvIHRoZSBQQVIgZW5kcG9pbnQs
IGlmIHRoZSBQQVIgZW5kcG9pbnQgaGFzIGFsbCB0aGUgZGVjcnlwdGlvbiBrZXlzIGZvciB0aGUg
a2V5cyBpbiB0aGUgQVPigJlzIEpXSyBzZXQsIGl0IHdvdWxkIGJlIGFibGUgdG8gZGVjcnlwdCBJ
RCBUb2tlbnMgc2VudCBpbiBpZF90b2tlbl9oaW50IHJlcXVlc3QgcGFyYW1ldGVycy4gQXMgbW9y
ZSBhbmQgbW9yZSB1c2UgY2FzZXMgZGV2ZWxvcCBmb3IgZW5jcnlwdGluZyBibG9icyBmb3IgdGhl
IEFTLCB0aGlzIGlzc3VlIHdpbGwgb25seSBnZXQgd29yc2UuDQoNClRoZSBQQVIgZW5kcG9pbnQg
Y2Fu4oCZdCBzaW1wbHkgc3Rhc2ggdGhlIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdCwgYXMgaXQg
aXMgcmVxdWlyZWQgdG8gdmVyaWZ5IHRoZSByZXF1ZXN0LCBhY2NvcmRpbmcgdG8gwqcyLjE6DQoN
Cg0KVGhlIEFTIE1VU1QgcHJvY2VzcyB0aGUgcmVxdWVzdCBhcyBmb2xsb3dzOg0KDQoNCg0KLi4u
Lg0KDQoNCg0KMy4gIFRoZSBBUyBNVVNUIHZhbGlkYXRlIHRoZSByZXF1ZXN0IGluIHRoZSBzYW1l
IHdheSBhcyBhdCB0aGUNCg0KICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIC4uLg0K
DQoNClRoaXMgbGFuZ3VhZ2UgbmVlZHMgdG8gYmUgbW9yZSBmbGV4aWJsZSwgSU1ITywgdG8gYWxs
b3cgZm9yIGxpZ2h0d2VpZ2h0IFBBUiBlbmRwb2ludHMgdGhhdCBtYXkgbm90IGhhdmUgdGhlIGlu
Zm9ybWF0aW9uIG9yIGF1dGhvcml0eSBuZWVkZWQgdG8gcGVyZm9ybSBhbGwgdGhlIHZhbGlkYXRp
b24gdGhhdCBoYXBwZW5zIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBJIG5lZWQgdG8g
dGhpbmsgYWJvdXQgdGhpcyBtb3JlIGJlZm9yZSBJIGNhbiBzYXkgaWYgaXQgd291bGQgYWRlcXVh
dGVseSBhZGRyZXNzIG15IGNvbmNlcm5zLCBidXQgaXTigJlkIGJlIGEgZ29vZCBzdGFydCBhbmQg
bWFrZXMgc2Vuc2UgaW4gaXRzIG93biByaWdodC4NCg0KSSB0aGluayBpdOKAmXMgcHJldHR5IHJp
c2t5IGZvciB1cyB0byBiYXNlIGRlY2lzaW9uIG9uIGFuIGFzc3VtcHRpb24gdGhhdCBubyBvbmUg
aXMgZ29pbmcgdG8gbmVlZCBvciB3YW50IHRvIGVuY3J5cHQgcHVzaGVkIHJlcXVlc3Qgb2JqZWN0
cywgcGFydGljdWxhcmx5IHdoZW4gdGhleeKAmXJlIEpXVHMsIGFuZCBKV1RzIGhhdmUgd2VsbCBl
c3RhYmxpc2hlZCBzdXBwb3J0IGZvciBlbmNyeXB0aW9uLCBhbmQgZW5jcnlwdGVkIEpXVHMgYXJl
IHN1cHBvcnRlZCBieSBwYXNzLWJ5LXZhbHVlIGluIE9JREMgYW5kIGRyYWZ0LWlldGYtb2F1dGgt
andzcmVxLiBCdXQgaWYgeW91IGluc2lzdCwgaGVyZSBhcmUgYSBmZXcgZXhhbXBsZXMgZm9yIHdo
eSBzb21lb25lIG1pZ2h0IHdhbnQgdG8gZG8gdGhpczoNCg0KICAxLiAgVGhlIHJlcXVlc3Qgb2Jq
ZWN0IGlzIHBhc3NlZCBieSByZWZlcmVuY2UsIGFuZCBhY2Nlc3NpYmxlIG9uIHRoZSBwdWJsaWMg
SW50ZXJuZXQuDQogIDIuICBUaGUgcmVxdWVzdCBvYmplY3QgY29udGFpbnMgc2Vuc2l0aXZlIHRy
YW5zYWN0aW9uLXJlbGF0ZWQgZGF0YSBpbiBSQVIgcGFyYW1ldGVycyB0aGF0IHRoZSBjbGllbnTi
gJlzIGF1dGhOL2F1dGhaIHN0YWNrIGRvZXNu4oCZdCBuZWVkIHRvIGhhdmUgYWNjZXNzIHRvLg0K
ICAzLiAgVGhlIEFTIHJlcXVpcmVzIHJlcXVlc3Qgb2JqZWN0IGVuY3J5cHRpb24gdG8gbWluaW1p
emUgZXhwb3N1cmUgdG8gdGhlIGhvc3RlZCBQQVIgZW5kcG9pbnQgc2VydmljZSBpdCB1c2VzLg0K
ICA0LiAgIzIsIGJ1dCB0aGUgdGhyZWF0IHZlY3RvciBpcyBnYXBzIGluIGVuZC10by1lbmQgVExT
Lg0KICA1LiAgQW55IG9mIHRoZSBhYm92ZSwgYnV0IHRoZSBjb25jZXJuIGlzIG1lc3NhZ2UgaW50
ZWdyaXR5LCBhbmQgdGhlIEFTIHJlcXVpcmVzIHJlcXVlc3RlZCBvYmplY3RzIHRvIGJlIGVuY3J5
cHRlZCBmb3IgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQgZG9l
cyBub3Qgc3VwcG9ydCBzaWduZWQgcmVxdWVzdCBvYmplY3RzLg0KDQrigJMNCkFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE5laWwgTWFkZGVuIDxuZWls
Lm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4N
CkRhdGU6IE1vbmRheSwgSmFudWFyeSA2LCAyMDIwIGF0IDY6MjkgQU0NClRvOiBCcmlhbiBDYW1w
YmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tPj4NCkNjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBh
bWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIE5hdCBTYWtpbXVyYSA8bmF0
QHNha2ltdXJhLm9yZzxtYWlsdG86bmF0QHNha2ltdXJhLm9yZz4+LCBEYXZlIFRvbmdlIDxkYXZl
LnRvbmdlQG1vbmV5aHViLmNvbTxtYWlsdG86ZGF2ZS50b25nZUBtb25leWh1Yi5jb20+PiwgVG9y
c3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC4ubmV0PG1haWx0bzp0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldD4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll
dGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gUEFS
IG1ldGFkYXRhDQoNCkFncmVlZC4NCg0KSW4gYWRkaXRpb24sIEknbSBub3Qgc3VyZSB3aHkgdGhl
IFBBUiBlbmRwb2ludCB3b3VsZCBuZWVkIGFjY2VzcyB0byB0aGUgZGVjcnlwdGlvbiBrZXlzIGF0
IGFsbC4gSWYgeW91J3JlIHVzaW5nIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdHMgdGhlbiB0aGUg
UEFSIGVuZHBvaW50IHJlY2VpdmVzIGFuIGVuY3J5cHRlZCBKV1QgYW5kIHRoZW4gbGF0ZXIgbWFr
ZXMgdGhlIHNhbWUgKHN0aWxsIGVuY3J5cHRlZCkgSldUIGF2YWlsYWJsZSB0byB0aGUgYXV0aG9y
aXphdGlvbiBlbmRwb2ludC4gSWYgdGhlIFBBUiBlbmRwb2ludCBpcyBkb2luZyBhbnkga2luZCBv
ZiBkZWNyeXB0aW9uIG9yIHZhbGlkYXRpb24gb24gYmVoYWxmIG9mIHRoZSBhdXRob3JpemF0aW9u
IGVuZHBvaW50IHRoZW4gdGhleSBhcmUgY2xlYXJseSBub3QgaW4gc2VwYXJhdGUgdHJ1c3QgYm91
bmRhcmllcy4NCg0KLS0gTmVpbA0KDQoNCk9uIDYgSmFuIDIwMjAsIGF0IDEzOjU3LCBCcmlhbiBD
YW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls
dG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K
DQpJIHJlYWxseSBzdHJ1Z2dsZSB0byBzZWUgdGhlIGFzc3VtcHRpb24gdGhhdCBhbiBlbnRpdHkg
YmUgYWJsZSB0byB1c2UgdGhlIHNhbWUga2V5IHRvIGRlY3J5cHQgdGhlIHNhbWUgdHlwZSBvZiBt
ZXNzYWdlIHVsdGltYXRlbHkgaW50ZW5kZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UgYXMgYW4gYXJ0
aWZpY2lhbCBsaW1pdC4gVGhlIHNhbWUgZ2VuZXJhbCBhc3N1bXB0aW9uICAgdW5kZXJsaWVzIGV2
ZXJ5dGhpbmcgZWxzZSBpbiBPQXV0aC9PSURDIChWbGFkaW1pcidzIHBvc3QgcG9pbnRzIHRvIHNv
bWUgYnV0IG5vdCBhbGwgZXhhbXBsZXMgb2Ygc3VjaCkuIFRoZXJlJ3Mgbm8gcmVhc29uIGZvciBQ
QVIgdG8gbWFrZSBhIG9uZS1vZmYgZXhjZXB0aW9uLiBBbmQgc2hvdWxkIHRoZXJlIGJlIHNvbWUg
ZGVwbG95bWVudCBzcGVjaWZpYyByZWFzb24gdGhhdCB0cnVseSByZXF1aXJlcyB0aGF0IGtpbmQg
b2YgaXNvbGF0aW9uLCB0aGVyZSBhcmUgY2VydGFpbmx5IGltcGxlbWVudGF0aW9uIG9wdGlvbnMg
dGhhdCBhcmVuJ3QgY29tcGF0aWJpbGl0eS1icmVha2luZy4gQW5kIGhhdmluZyBzYWlkIGFsbCB0
aGF0LCBJJ20gaG9uZXN0bHkgYSBsaXR0bGUgc3VycHJpc2VkIGFueW9uZSBpcyB0aGlua2luZyBt
dWNoIGFib3V0IGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdHMgd2l0aCBQQVIgYXMsIGF0IGxlYXN0
IHdpdGggbXkgbGltaXRlZCBpbWFnaW5hdGlvbiwgdGhlcmUncyBub3QgcmVhbGx5IGEgbmVlZCBm
b3IgaXQuDQoNCg0KDQoNCg0KDQoNCg0KT24gRnJpLCBKYW4gMywgMjAyMCBhdCAyOjQzIFBNIFJp
Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0
Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KUEFSIGlu
dHJvZHVjZXMgYW4gYWRkZWQgd3JpbmtsZSBmb3IgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0czog
dGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBtYXkgbm90IGhhdmUg
YWNjZXNzIHRvIHRoZSBzYW1lIGNyeXB0b2dyYXBoaWMga2V5cywgZXZlbiB0aG91Z2ggdGhleSdy
ZSBib3RoIHBhcnQgb2YgdGhlICJhdXRob3JpemF0aW9uIHNlcnZlci4iIFNpbmNlIHRoZXkncmUg
ZGlmZmVyZW50IGVuZHBvaW50cyB3aXRoIGRpZmZlcmVudCByb2xlcywgaXQncyByZWFzb25hYmxl
IHRvIHB1dCB0aGVtIGluIHNlcGFyYXRlIHRydXN0IGJvdW5kYXJpZXMuIFRoZXJlIGlzIG5vIHdh
eSB0byBzdXBwb3J0IHRoaXMgaXNvbGF0aW9uIHdpdGgganVzdCBhIHNpbmdsZSAiandrc191cmki
IG1ldGFkYXRhIHByb3BlcnR5Lg0KDQpUaGUgdHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6DQoN
CjEuIERlZmluZSBhIG5ldyBwYXJfandrc191cmkgbWV0YWRhdGEgcHJvcGVydHkuDQoyLiBFeHBs
aWNpdGx5IHN0YXRlIHRoYXQgdGhpcyBzZXBhcmF0aW9uIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCkkg
c3Ryb25nbHkgcGVyZmVyICMxIGFzIGl0IGhhcyBhIHZlcnkgbWlub3IgaW1wYWN0IG9uIGRlcGxv
eW1lbnRzIHRoYXQgZG9uJ3QgY2FyZSAoaS5lLiwgdGhleSBqdXN0IHNldCBwYXJfandrc191cmkg
YW5kIGp3a3NfdXJpIHRvIHRoZSBzYW1lIHZhbHVlKSBhbmQgZmFpbGluZyB0byBzdXBwb3J0IHRo
aXMgdHJ1c3QgYm91bmRhcnkgY3JlYXRlcyBhbiBhcnRpZmljaWFsIGxpbWl0IG9uIGltcGxlbWVu
dGF0aW9uIGFyY2hpdGVjdHVyZSBhbmQgY291bGQgbGVhZCB0byBjb21wYXRpYmlsaXR5LWJyZWFr
aW5nIHdvcmthcm91bmRzLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJ
ZGVudGl0eQ0KDQoNCk9uIDEyLzMxLzE5LCA4OjA3IEFNLCAiT0F1dGggb24gYmVoYWxmIG9mIFRv
cnN0ZW4gTG9kZGVyc3RlZHQiIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgdG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBk
bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3
cm90ZToNCg0KICAgIEhpIEZpbGlwLA0KDQogICAgPiBPbiAzMS4gRGVjIDIwMTksIGF0IDE2OjIy
LCBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNvbTxtYWlsdG86cGFudmEuaXBAZ21haWwu
Y29tPj4gd3JvdGU6DQogICAgPg0KICAgID4gSSBkb24ndCB0aGluayB3ZSBuZWVkIGEgKl9hdXRo
X21ldGhvZF8qIG1ldGFkYXRhIGZvciBldmVyeSBlbmRwb2ludCB0aGUgY2xpZW50IGNhbGxzIGRp
cmVjdGx5LCBub25lIG9mIHRoZSBuZXcgc3BlY3MgZGVmaW5lZCB0aGVzZSAoZS5nLiBkZXZpY2Ug
YXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciBDSUJBKSwgbWVhbmluZyB0aGV5IGFsc28gZGlkbid0
IGZvbGxvdyB0aGUgc2NoZW1lIGZyb20gUkZDIDg0MTQgd2hlcmUgaW50cm9zcGVjdGlvbiBhbmQg
cmV2b2NhdGlvbiBnb3QgaXRzIG93biBtZXRhZGF0YS4gSW4gbW9zdCBjYXNlcyB0aGUgdW5mb3J0
dW5hdGVseSBuYW1lZCBgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RgIGFuZCBpdHMgcmVsYXRl
ZCBtZXRhZGF0YSBpcyB3aGF0J3MgdXNlZCBieSBjbGllbnRzIGZvciBhbGwgZGlyZWN0IGNhbGxz
IGFueXdheS4NCiAgICA+DQogICAgPiBUaGUgc2FtZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGll
ZCB0byBzaWduaW5nIChhbmQgZW5jcnlwdGlvbikgYWxnb3JpdGhtcyBhcyB3ZWxsLg0KICAgID4N
CiAgICA+IFRoaXMgSSBkbyBub3QgZm9sbG93LCBhdXRoIG1ldGhvZHMgYW5kIHRoZWlyIHNpZ25p
bmcgaXMgZGVhbHQgd2l0aCBieSB1c2luZyBgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1
cHBvcnRlZGAgYW5kIGB0b2tlbl9lbmRwb2ludF9hdXRoX3NpZ25pbmdfYWxnX3ZhbHVlc19zdXBw
b3J0ZWRgIC0gdGhlcmUncyBubyBlbmNyeXB0aW9uIGZvciB0aGUgYF9qd3RgIGNsaWVudCBhdXRo
IG1ldGhvZHMuDQogICAgPiBVbmxlc3MgaXQgd2FzIG1lYW50IHRvIGFkZHJlc3MgdGhlIFJlcXVl
c3QgT2JqZWN0IHNpZ25pbmcgYW5kIGVuY3J5cHRpb24gbWV0YWRhdGEsIHdoaWNoIGlzIGRlZmlu
ZWQgYW5kIElBTkEgcmVnaXN0ZXJlZCBieSBPSURDLiBQQVIgb25seSByZWZlcmVuY2VzIEpBUiBz
ZWN0aW9uIDYuMSBhbmQgNi4yIGZvciBkZWNyeXB0aW9uL3NpZ25hdHVyZSB2YWxpZGF0aW9uIGFu
ZCB0aGVzZSBkbyBub3QgbWVudGlvbiB0aGUgbWV0YWRhdGEgKGUuZy4gcmVxdWVzdF9vYmplY3Rf
c2lnbmluZ19hbGcpIGFueW1vcmUgc2luY2UgZHJhZnQgMDcuDQoNCiAgICBEYW1tZWQhIFlvdSBh
cmUgc28gcmlnaHQuIFNvcnJ5LCBJIGdvdCBjb25mdXNlZCBzb21laG93Lg0KDQogICAgPg0KICAg
ID4gUFM6IEkgYWxzbyBmb3VuZCB0aGlzIGNvbW1lbnQgcmVsYXRlZCB0byB0aGUgc2FtZSBxdWVz
dGlvbiBhYm91dCBhdXRoIG1ldGFkYXRhIGJ1dCBmb3IgQ0lCQS4NCg0KICAgIFRoYW5rcyBmb3Ig
c2hhcmluZy4NCg0KICAgID4NCiAgICA+IEJlc3QsDQogICAgPiBGaWxpcA0KDQogICAgdGhhbmtz
LA0KICAgIFRvcnN0ZW4uDQoNCiAgICA+DQogICAgPg0KICAgID4gT24gVHVlLCAzMSBEZWMgMjAx
OSBhdCAxNTozOCwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8
bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQogICAgPiBIaSBhbGwsDQog
ICAgPg0KICAgID4gUm9uYWxkIGp1c3Qgc2VudCBtZSBhbiBlbWFpbCBhc2tpbmcgd2hldGhlciB3
ZSB3aWxsIGRlZmluZSBtZXRhZGF0YSBmb3INCiAgICA+DQogICAgPiBwdXNoZWRfYXV0aG9yaXph
dGlvbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIGFuZA0KICAgID4gcHVzaGVkX2F1
dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0aF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkLg0K
ICAgID4NCiAgICA+IFRoZSBkcmFmdCByaWdodCBub3cgdXRpbGlzZXMgdGhlIGV4aXN0aW5nIHRv
a2VuIGVuZHBvaW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgc28gdGhlcmUgaXMgYmFzaWNhbGx5
IG5vIG5lZWQgdG8gZGVmaW5lIGFub3RoZXIgcGFyYW1ldGVyLiBUaGUgc2FtZSBwcmluY2lwbGUg
Y291bGQgYmUgYXBwbGllZCB0byBzaWduaW5nIChhbmQgZW5jcnlwdGlvbikgYWxnb3JpdGhtcyBh
cyB3ZWxsLg0KICAgID4NCiAgICA+IFdoYXTigJlzIHlvdXIgb3Bpbmlvbj8NCiAgICA+DQogICAg
PiBiZXN0IHJlZ2FyZHMsDQogICAgPiBUb3JzdGVuLg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl
IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig
ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg
YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo=

--_000_234E2C284CF5462683D5719B176C418Bamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgMCA1IDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg
MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0K
CXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg
MTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWlu
Y2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh
cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K
CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47
DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM
aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MTgyOTI4OTsNCglt
c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc5NDY2NTc2NiAt
ODAyNTE0ODEwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3
Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt
c3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s
Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp
c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs
aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEwODE1NTk2MjQ7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOi0zODc1NTM1MzY7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MjA5NTAw
NzU0NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI5
OTA2ODM0NCAxNDIwMDY0NDg2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3
Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXtt
c28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1i
aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMg0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp
bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdOKAmXMgY2xlYXJlciBpZiB3ZSBzcGxpdCBv
dXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIFBBUiBlbmRwb2ludCBhbmQgdGhlIHJlcXVpcmVt
ZW50cyBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGdpdmVuIHRoYXQgdGhleSBhcmUg
ZWFjaCBjb3ZlcmVkIGluIGRpZmZlcmVudCBzZWN0aW9ucyBvZiB0aGUgZG9jICgyIGFuZCA0LCBy
ZXNwZWN0aXZlbHkpLiBXaXRoIHRoYXQgaW4gbWluZCwNCiBoZXJlIGFyZSBhIGNvdXBsZSBzdWdn
ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoZSB0ZXh0IGluIFNlY3Rpb24g
Mi4xOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjMuJm5ic3A7IFRoZSBBUyBNVVNUIHZhbGlk
YXRlIHRoZSBwdXNoZWQgcmVxdWVzdCBhcyBpdCB3b3VsZCBhbiBhdXRob3JpemF0aW9uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsmbmJz
cDsgcmVxdWVzdCBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBob3dldmVyIHRo
ZSBBUyBNQVkgb21pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmll
ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbGlkYXRpb24gc3RlcHMgdGhhdCBpdCBpcyB1bmFibGUg
dG8gcGVyZm9ybSB3aGVuIHByb2Nlc3NpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsmbmJzcDsgcHVzaGVkIHJlcXVlc3QuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWwgdGV4dCBmb3IgU2VjdGlvbiA0IChub3RlIHRoYXQg
dGhpcyBzZWN0aW9uIHBlcnRhaW5zIHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50KTo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDb3VyaWVyIj5UaGUgQVMgTVVTVCB2YWxpZGF0ZSBhdXRob3JpemF0aW9u
IHJlcXVlc3RzIGFyaXNpbmcgZnJvbSBhIHB1c2hlZCByZXF1ZXN0IGFzPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5pdCB3b3VsZCBhbnkgb3RoZXIgYXV0aG9y
aXphdGlvbiByZXF1ZXN0LiZuYnNwOyBUaGUgQVMgTUFZIG9taXQgdmFsaWRhdGlvbiBzdGVwczxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+dGhhdCBpdCBwZXJm
b3JtZWQgd2hlbiB0aGUgcmVxdWVzdCB3YXMgcHVzaGVkLCBwcm92aWRlZCB0aGF0IGl0IGNhbiB2
YWxpZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+dGhh
dCB0aGUgcmVxdWVzdCB3YXMgYSBwdXNoZWQgcmVxdWVzdCwgYW5kIHRoYXQgdGhlIHJlcXVlc3Qg
aGFzIG5vdCBiZWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy
Ij5tb2RpZmllZCBpbiBhIHdheSB0aGF0IHdvdWxkIGFmZmVjdCB0aGUgb3V0Y29tZSBvZiB0aGUg
b21pdHRlZCBzdGVwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBsb25nZXIgdGhhbiB0aGUg
Y3VycmVudCB0ZXh0IGFuZCB0aGUgb3RoZXIgcHJvcG9zYWxzLCBidXQgaXQgYWRkcyBhIGZldyBp
bXBvcnRhbnQgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp
biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn
aW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPlR1cm5zIHRoZSAyLjEgU0hPVUxE
IGJhY2sgaW50byBhIE1VU1QsIHdpdGggYW4gZXhwbGljaXQgZXhjZXB0aW9uIGZvciB2YWxpZGF0
aW9uIHRoYXQgY2Fu4oCZdCBiZSBkb25lIHlldC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN
c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVs
MSBsZm8zIj5SZWluZm9yY2VzIHRoZSBmYWN0IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p
bnQgc3RpbGwgbmVlZHMgdG8gZG8gdmFsaWRhdGlvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxl
dmVsMSBsZm8zIj5DbGVhcmx5IHN0YXRlcyByZXF1aXJlbWVudHMgZm9yIHdoZW4gYW4gQVMgY2Fu
IHRydXN0IHRoYXQgdmFsaWRhdGlvbiBoYXBwZW5lZCBhdCB0aGUgUEFSIGVuZHBvaW50LjxvOnA+
PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr
bWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTQwcGlu
Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2Rh
eSwgSmFudWFyeSA3LCAyMDIwIGF0IDI6NTQgUE08YnI+DQo8Yj5UbzogPC9iPlZsYWRpbWlyIER6
aHV2aW5vdiAmbHQ7dmxhZGltaXJAY29ubmVjdDJpZC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5G
aWxpcCBTa29rYW4gJmx0O3BhbnZhLmlwQGdtYWlsLmNvbSZndDssICZxdW90O1JpY2hhcmQgQmFj
a21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0OywgRGF2ZSBU
b25nZSAmbHQ7ZGF2ZS50b25nZUBtb25leWh1Yi5jb20mZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0
Zi5vcmcmZ3Q7LCBOYXQgU2FraW11cmEgJmx0O25hdEBzYWtpbXVyYS5vcmcmZ3Q7PGJyPg0KPGI+
U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJ
RUQgU0VOREVSXSBSZTogUEFSIG1ldGFkYXRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBsaXR0bGUgbW9yZSBjb250
ZXh0IGFib3V0IHRoYXQgcHJvcG9zZWQgd29yZGluZyBpcyBpbiBhIGdpdGh1YiBpc3N1ZSBhdA0K
PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL29hdXRoc3R1ZmYvZHJhZnQtb2F1dGgtcGFyL2lz
c3Vlcy8zOCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL29hdXRoc3R1ZmYv
ZHJhZnQtb2F1dGgtcGFyL2lzc3Vlcy8zODwvYT4sIHdoaWNoIGlzIGRpZmZlcmVudCBkcml2ZXIg
dGhhbiBhbGxvd2luZyBhIFBBUiBlbmRwb2ludCB0byBzdGFzaCB0aGUgZW5jcnlwdGVkIHJlcXVl
c3Qgb2JqZWN0IHJhdGhlciB0aGFuIGRlY3J5cHRpbmcvdmFsaWRhdGluZyBpdC4gQnV0IGl0J3Mg
a2luZCBvZiB0aGUgc2FtZSBjb25jZXB0IGF0IHNvbWUgbGV2ZWwgdG9vIC0gdGhhdCB0aGVyZQ0K
IGFyZSBzb21lIHRoaW5ncyB0aGF0IGNhbid0IG9yIHdvbid0IGJlIHZhbGlkYXRlZCBhdCB0aGUg
UEFSIGVuZHBvaW50IGFuZCB0aG9zZSB0aGVuIGhhdmUgdG8gYmUgdmFsaWRhdGVkIGF0IHRoZSBh
dXRob3JpemF0aW9uIGVuZHBvaW50Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByYXRoZXIgbGlrZSB5b3VyIHN1Z2dlc3RlZCB0ZXh0LCBW
bGFkaW1pciwgYW5kIGhhdmUgbWVudGlvbmVkIGl0IGluIGEgY29tbWVudCBvbiB0aGUgYWZvcmVt
ZW50aW9uZWQgaXNzdWUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gVHVlLCBKYW4gNywgMjAyMCBhdCA2OjU4IEFNIFZsYWRpbWlyIER6aHV2aW5v
diAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9i
bGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gMDcvMDEvMjAyMCAwMDoyMiwgRmlsaXAgU2tva2FuIHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UndmUgYmVl
biBkaXNjdXNzaW5nIG1ha2luZyB0aGUgZm9sbG93aW5nJm5ic3A7Y2hhbmdlIHRvIHRoZSBsYW5n
dWFnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGUgQVMgU0hPVUxEIHZhbGlkYXRlIHRoZSByZXF1ZXN0IGluIHRoZSBzYW1lIHdh
eSBhcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVGhlIEFTIE1VU1QgZW5zdXJlIHRo
YXQgYWxsIHBhcmFtZXRlcnMgdG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcmUgc3RpbGwg
dmFsaWQgYXQgdGhlIHRpbWUgd2hlbiB0aGUgcmVxdWVzdCBVUkkgaXMgdXNlZC48bzpwPjwvbzpw
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+Q291bGQgeW91
IGV4cGFuZCBhIGJpdCBvbiB0aGUgc2Vjb25kIHNlbnRlbmNlPzxvOnA+PC9vOnA+PC9wPg0KPHA+
QWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBBUyBNVVNUIHZh
bGlkYXRlIHRoZSByZXF1ZXN0IGluIHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9yaXphdGlv
biBlbmRwb2ludCwgb3IgY29tcGxldGUgdGhlIHJlcXVlc3QgdmFsaWRhdGlvbiBhdCB0aGUgYXV0
aG9yaXphdGlvbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwPlZsYWRpbWlyPG86cD48L286
cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIGFsbG93IHRoZSBQQVIgZW5kcG9pbnQgdG8gc2ltcGx5
IHN0YXNoIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3QgaW5zdGVhZCBvZiBkZWNyeXB0aW5n
IGFuZCB2YWxpZGF0aW5nIGl0LiBBbGwgd2l0aGluIHRoZSBib3VuZHMgb2YgJnF1b3Q7U0hPVUxE
IC0mbmJzcDtXZeKAmWQgbGlrZSB5b3UgdG8gZG8gdGhpcywgYnV0IHdlIGNhbuKAmXQgYWx3YXlz
IHJlcXVpcmUgaXQmcXVvdDsuIFRoaXMgc3VwcG9ydHMgJnF1b3Q7bGlnaHQgd2VpZ2h0DQogUEFS
JnF1b3Q7IGltcGxlbWVudGF0aW9uIHJhdGhlciB0aGFuIGludHJvZHVjaW5nIHRoZSB1bm5lY2Vz
c2FyeSBjb21wbGV4aXR5IGluIHRoZSBmb3JtIG9mIGEgc2Vjb25kIEpXS1MuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxicj4N
CjxiPkZpbGlwPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+T24gTW9uLCA2IEphbiAyMDIwIGF0IDIzOjAwLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi
ZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpc3N1ZSBpc27igJl0IHRoYXQgdGhlIFBBUiBl
bmRwb2ludCBuZWVkcyBhY2Nlc3MgdG8gb25lIHNwZWNpZmljIHJlcXVlc3Qgb2JqZWN0IGRlY3J5
cHRpb24ga2V5IHRoYXQgY291bGQgcmVhc29uYWJseSBiZSBzaGFyZWQgYWNyb3NzIEFTIGVuZHBv
aW50cywgYnV0IHRoYXQgaXQgYWN0dWFsbHkgbmVlZHMNCiBhY2Nlc3MgdG8gdGhlIHByaXZhdGUg
a2V5cyBmb3IgYWxsIGVuY3J5cHRpb24gcHVibGljIGtleXMgaW4gdGhlIEpXSyBzZXQgcG9pbnRl
ZCB0byBieSB0aGUgQVPigJlzIGp3a3NfdXJpIG1ldGFkYXRhIHByb3BlcnR5LiBTaW5jZSB0aGVy
ZSBpcyBubyB3YXkgdG8gZGVzaWduYXRlIG9uZSBwYXJ0aWN1bGFyIGtleSBhcyB0aGUgb25lIHRv
IHVzZSBmb3IgZW5jcnlwdGluZyByZXF1ZXN0IG9iamVjdHMsIGNsaWVudHMgbWF5IHJlYXNvbmFi
bHkgdXNlIGFueQ0KIGVuY3J5cHRpb24gcHVibGljIGtleSBpbiB0aGUgSldLIHNldCB0byBlbmNy
eXB0IGEgcmVxdWVzdCBvYmplY3QuIEFzIG9uZSBleGFtcGxlIG9mIGhvdyB0aGlzIGNvdWxkIGV4
cG9zZSBzZW5zaXRpdmUgZGF0YSB0byB0aGUgUEFSIGVuZHBvaW50LCBpZiB0aGUgUEFSIGVuZHBv
aW50IGhhcyBhbGwgdGhlIGRlY3J5cHRpb24ga2V5cyBmb3IgdGhlIGtleXMgaW4gdGhlIEFT4oCZ
cyBKV0sgc2V0LCBpdCB3b3VsZCBiZSBhYmxlIHRvIGRlY3J5cHQgSUQgVG9rZW5zDQogc2VudCBp
biBpZF90b2tlbl9oaW50IHJlcXVlc3QgcGFyYW1ldGVycy4gQXMgbW9yZSBhbmQgbW9yZSB1c2Ug
Y2FzZXMgZGV2ZWxvcCBmb3IgZW5jcnlwdGluZyBibG9icyBmb3IgdGhlIEFTLCB0aGlzIGlzc3Vl
IHdpbGwgb25seSBnZXQgd29yc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgUEFS
IGVuZHBvaW50IGNhbuKAmXQgc2ltcGx5IHN0YXNoIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmpl
Y3QsIGFzIGl0IGlzIHJlcXVpcmVkIHRvIHZlcmlmeSB0aGUgcmVxdWVzdCwgYWNjb3JkaW5nIHRv
IMKnMi4xOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+VGhlIEFTIE1VU1QgcHJvY2VzcyB0aGUgcmVxdWVzdCBhcyBmb2xsb3dzOjwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Li4u
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
My4mbmJzcDsgVGhlIEFTIE1VU1QgdmFsaWRhdGUgdGhlIHJlcXVlc3QgaW4gdGhlIHNhbWUgd2F5
IGFzIGF0IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDthdXRob3JpemF0aW9uIGVuZHBvaW50LiAuLi48L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBsYW5ndWFnZSBuZWVkcyB0byBi
ZSBtb3JlIGZsZXhpYmxlLCBJTUhPLCB0byBhbGxvdyBmb3IgbGlnaHR3ZWlnaHQgUEFSIGVuZHBv
aW50cyB0aGF0IG1heSBub3QgaGF2ZSB0aGUgaW5mb3JtYXRpb24gb3IgYXV0aG9yaXR5IG5lZWRl
ZCB0byBwZXJmb3JtIGFsbCB0aGUgdmFsaWRhdGlvbiB0aGF0IGhhcHBlbnMNCiBhdCB0aGUgYXV0
aG9yaXphdGlvbiBlbmRwb2ludC4gSSBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgbW9yZSBiZWZv
cmUgSSBjYW4gc2F5IGlmIGl0IHdvdWxkIGFkZXF1YXRlbHkgYWRkcmVzcyBteSBjb25jZXJucywg
YnV0IGl04oCZZCBiZSBhIGdvb2Qgc3RhcnQgYW5kIG1ha2VzIHNlbnNlIGluIGl0cyBvd24gcmln
aHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIGl04oCZcyBwcmV0dHkgcmlz
a3kgZm9yIHVzIHRvIGJhc2UgZGVjaXNpb24gb24gYW4gYXNzdW1wdGlvbiB0aGF0IG5vIG9uZSBp
cyBnb2luZyB0byBuZWVkIG9yIHdhbnQgdG8gZW5jcnlwdCBwdXNoZWQgcmVxdWVzdCBvYmplY3Rz
LCBwYXJ0aWN1bGFybHkgd2hlbiB0aGV54oCZcmUgSldUcywgYW5kIEpXVHMNCiBoYXZlIHdlbGwg
ZXN0YWJsaXNoZWQgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiwgYW5kIGVuY3J5cHRlZCBKV1RzIGFy
ZSBzdXBwb3J0ZWQgYnkgcGFzcy1ieS12YWx1ZSBpbiBPSURDIGFuZCBkcmFmdC1pZXRmLW9hdXRo
LWp3c3JlcS4gQnV0IGlmIHlvdSBpbnNpc3QsIGhlcmUgYXJlIGEgZmV3IGV4YW1wbGVzIGZvciB3
aHkgc29tZW9uZSBtaWdodCB3YW50IHRvIGRvIHRoaXM6PG86cD48L286cD48L3A+DQo8b2wgc3Rh
cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl
bDEgbGZvMSI+DQpUaGUgcmVxdWVzdCBvYmplY3QgaXMgcGFzc2VkIGJ5IHJlZmVyZW5jZSwgYW5k
IGFjY2Vzc2libGUgb24gdGhlIHB1YmxpYyBJbnRlcm5ldC4NCjxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NClRoZSByZXF1ZXN0
IG9iamVjdCBjb250YWlucyBzZW5zaXRpdmUgdHJhbnNhY3Rpb24tcmVsYXRlZCBkYXRhIGluIFJB
UiBwYXJhbWV0ZXJzIHRoYXQgdGhlIGNsaWVudOKAmXMgYXV0aE4vYXV0aFogc3RhY2sgZG9lc27i
gJl0IG5lZWQgdG8gaGF2ZSBhY2Nlc3MgdG8uDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpUaGUgQVMgcmVxdWlyZXMgcmVx
dWVzdCBvYmplY3QgZW5jcnlwdGlvbiB0byBtaW5pbWl6ZSBleHBvc3VyZSB0byB0aGUgaG9zdGVk
IFBBUiBlbmRwb2ludCBzZXJ2aWNlIGl0IHVzZXMuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQojMiwgYnV0IHRoZSB0aHJl
YXQgdmVjdG9yIGlzIGdhcHMgaW4gZW5kLXRvLWVuZCBUTFMuIDxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkFueSBvZiB0aGUg
YWJvdmUsIGJ1dCB0aGUgY29uY2VybiBpcyBtZXNzYWdlIGludGVncml0eSwgYW5kIHRoZSBBUyBy
ZXF1aXJlcyByZXF1ZXN0ZWQgb2JqZWN0cyB0byBiZSBlbmNyeXB0ZWQgZm9yIGNvbmZpZGVudGlh
bGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGRvZXMgbm90IHN1cHBvcnQgc2lnbmVk
IHJlcXVlc3Qgb2JqZWN0cy4NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdT
IElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xv
cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5OZWlsIE1hZGRl
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20iIHRhcmdldD0i
X2JsYW5rIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8
L2I+TW9uZGF5LCBKYW51YXJ5IDYsIDIwMjAgYXQgNjoyOSBBTTxicj4NCjxiPlRvOiA8L2I+QnJp
YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnI+
DQo8Yj5DYzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hh
bm5hQGFtYXpvbi5jb208L2E+Jmd0OywgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86
bmF0QHNha2ltdXJhLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5hdEBzYWtpbXVyYS5vcmc8L2E+Jmd0
OywgRGF2ZSBUb25nZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmUudG9uZ2VAbW9uZXlodWIuY29t
IiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZS50b25nZUBtb25leWh1Yi5jb208L2E+Jmd0OywNCiBUb3Jz
dGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u
ZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Li5uZXQ8L2E+Jmd0Oywgb2F1
dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h
dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJRUQgU0VO
REVSXSBSZTogW09BVVRILVdHXSBQQVIgbWV0YWRhdGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFncmVlZC4NCjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIGFkZGl0aW9uLCBJJ20gbm90
IHN1cmUgd2h5IHRoZSBQQVIgZW5kcG9pbnQgd291bGQgbmVlZCBhY2Nlc3MgdG8gdGhlIGRlY3J5
cHRpb24ga2V5cyBhdCBhbGwuIElmIHlvdSdyZSB1c2luZyBlbmNyeXB0ZWQgcmVxdWVzdCBvYmpl
Y3RzIHRoZW4gdGhlIFBBUiBlbmRwb2ludCByZWNlaXZlcyBhbiBlbmNyeXB0ZWQNCiBKV1QgYW5k
IHRoZW4gbGF0ZXIgbWFrZXMgdGhlIHNhbWUgKHN0aWxsIGVuY3J5cHRlZCkgSldUIGF2YWlsYWJs
ZSB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gSWYgdGhlIFBBUiBlbmRwb2ludCBpcyBk
b2luZyBhbnkga2luZCBvZiBkZWNyeXB0aW9uIG9yIHZhbGlkYXRpb24gb24gYmVoYWxmIG9mIHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRoZW4gdGhleSBhcmUgY2xlYXJseSBub3QgaW4gc2Vw
YXJhdGUgdHJ1c3QgYm91bmRhcmllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tIE5laWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+T24gNiBKYW4gMjAyMCwgYXQgMTM6NTcsIEJyaWFuIENhbXBiZWxs
ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h
cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSByZWFsbHkgc3RydWdnbGUgdG8gc2VlIHRoZSBh
c3N1bXB0aW9uIHRoYXQgYW4gZW50aXR5IGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIGtleSB0byBk
ZWNyeXB0IHRoZSBzYW1lIHR5cGUgb2YgbWVzc2FnZSB1bHRpbWF0ZWx5IGludGVuZGVkIGZvciB0
aGUgc2FtZSBwdXJwb3NlIGFzIGFuIGFydGlmaWNpYWwNCiBsaW1pdC4gVGhlIHNhbWUgZ2VuZXJh
bCBhc3N1bXB0aW9uICZuYnNwOyB1bmRlcmxpZXMgZXZlcnl0aGluZyBlbHNlIGluIE9BdXRoL09J
REMgKFZsYWRpbWlyJ3MgcG9zdCBwb2ludHMgdG8gc29tZSBidXQgbm90IGFsbCBleGFtcGxlcyBv
ZiBzdWNoKS4gVGhlcmUncyBubyByZWFzb24gZm9yIFBBUiB0byBtYWtlIGEgb25lLW9mZiBleGNl
cHRpb24uIEFuZCBzaG91bGQgdGhlcmUgYmUgc29tZSBkZXBsb3ltZW50IHNwZWNpZmljIHJlYXNv
biB0aGF0IHRydWx5DQogcmVxdWlyZXMgdGhhdCBraW5kIG9mIGlzb2xhdGlvbiwgdGhlcmUgYXJl
IGNlcnRhaW5seSBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIHRoYXQgYXJlbid0IGNvbXBhdGliaWxp
dHktYnJlYWtpbmcuIEFuZCBoYXZpbmcgc2FpZCBhbGwgdGhhdCwgSSdtIGhvbmVzdGx5IGEgbGl0
dGxlIHN1cnByaXNlZCBhbnlvbmUgaXMgdGhpbmtpbmcgbXVjaCBhYm91dCBlbmNyeXB0ZWQgcmVx
dWVzdCBvYmplY3RzIHdpdGggUEFSIGFzLCBhdCBsZWFzdCB3aXRoIG15DQogbGltaXRlZCBpbWFn
aW5hdGlvbiwgdGhlcmUncyBub3QgcmVhbGx5IGEgbmVlZCBmb3IgaXQuIDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDMsIDIwMjAgYXQgMjo0MyBQTSBSaWNoYXJkIEJh
Y2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNv
bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRm
Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+UEFSIGludHJvZHVjZXMgYW4gYWRkZWQgd3JpbmtsZSBmb3IgZW5jcnlwdGVk
IHJlcXVlc3Qgb2JqZWN0czogdGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRw
b2ludCBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBzYW1lIGNyeXB0b2dyYXBoaWMga2V5cywg
ZXZlbiB0aG91Z2ggdGhleSdyZQ0KIGJvdGggcGFydCBvZiB0aGUgJnF1b3Q7YXV0aG9yaXphdGlv
biBzZXJ2ZXIuJnF1b3Q7IFNpbmNlIHRoZXkncmUgZGlmZmVyZW50IGVuZHBvaW50cyB3aXRoIGRp
ZmZlcmVudCByb2xlcywgaXQncyByZWFzb25hYmxlIHRvIHB1dCB0aGVtIGluIHNlcGFyYXRlIHRy
dXN0IGJvdW5kYXJpZXMuIFRoZXJlIGlzIG5vIHdheSB0byBzdXBwb3J0IHRoaXMgaXNvbGF0aW9u
IHdpdGgganVzdCBhIHNpbmdsZSAmcXVvdDtqd2tzX3VyaSZxdW90OyBtZXRhZGF0YSBwcm9wZXJ0
eS48YnI+DQo8YnI+DQpUaGUgdHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6PGJyPg0KPGJyPg0K
MS4gRGVmaW5lIGEgbmV3IHBhcl9qd2tzX3VyaSBtZXRhZGF0YSBwcm9wZXJ0eS48YnI+DQoyLiBF
eHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhpcyBzZXBhcmF0aW9uIGlzIG5vdCBzdXBwb3J0ZWQuPGJy
Pg0KPGJyPg0KSSBzdHJvbmdseSBwZXJmZXIgIzEgYXMgaXQgaGFzIGEgdmVyeSBtaW5vciBpbXBh
Y3Qgb24gZGVwbG95bWVudHMgdGhhdCBkb24ndCBjYXJlIChpLmUuLCB0aGV5IGp1c3Qgc2V0IHBh
cl9qd2tzX3VyaSBhbmQgandrc191cmkgdG8gdGhlIHNhbWUgdmFsdWUpIGFuZCBmYWlsaW5nIHRv
IHN1cHBvcnQgdGhpcyB0cnVzdCBib3VuZGFyeSBjcmVhdGVzIGFuIGFydGlmaWNpYWwgbGltaXQg
b24gaW1wbGVtZW50YXRpb24gYXJjaGl0ZWN0dXJlIGFuZCBjb3VsZA0KIGxlYWQgdG8gY29tcGF0
aWJpbGl0eS1icmVha2luZyB3b3JrYXJvdW5kcy48YnI+DQo8YnI+DQrigJMgPGJyPg0KQW5uYWJl
bGxlIFJpY2hhcmQgQmFja21hbjxicj4NCkFXUyBJZGVudGl0eTxicj4NCjxicj4NCjxicj4NCk9u
IDEyLzMxLzE5LCA4OjA3IEFNLCAmcXVvdDtPQXV0aCBvbiBiZWhhbGYgb2YgVG9yc3RlbiBMb2Rk
ZXJzdGVkdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2Yg
dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7
DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBIaSBGaWxpcCwgPGJyPg0KPGJyPg0K
Jm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIDMxLiBEZWMgMjAxOSwgYXQgMTY6MjIsIEZpbGlwIFNrb2th
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0
OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSSBkb24ndCB0aGluayB3ZSBuZWVkIGEgKl9hdXRo
X21ldGhvZF8qIG1ldGFkYXRhIGZvciBldmVyeSBlbmRwb2ludCB0aGUgY2xpZW50IGNhbGxzIGRp
cmVjdGx5LCBub25lIG9mIHRoZSBuZXcgc3BlY3MgZGVmaW5lZCB0aGVzZSAoZS5nLiBkZXZpY2Ug
YXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciBDSUJBKSwgbWVhbmluZyB0aGV5IGFsc28gZGlkbid0
IGZvbGxvdyB0aGUgc2NoZW1lIGZyb20gUkZDIDg0MTQgd2hlcmUgaW50cm9zcGVjdGlvbg0KIGFu
ZCByZXZvY2F0aW9uIGdvdCBpdHMgb3duIG1ldGFkYXRhLiBJbiBtb3N0IGNhc2VzIHRoZSB1bmZv
cnR1bmF0ZWx5IG5hbWVkIGB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZGAgYW5kIGl0cyByZWxh
dGVkIG1ldGFkYXRhIGlzIHdoYXQncyB1c2VkIGJ5IGNsaWVudHMgZm9yIGFsbCBkaXJlY3QgY2Fs
bHMgYW55d2F5Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZn
dDsgVGhlIHNhbWUgcHJpbmNpcGxlIGNvdWxkIGJlIGFwcGxpZWQgdG8gc2lnbmluZyAoYW5kIGVu
Y3J5cHRpb24pIGFsZ29yaXRobXMgYXMgd2VsbC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoaXMgSSBkbyBub3QgZm9sbG93LCBhdXRoIG1ldGhvZHMg
YW5kIHRoZWlyIHNpZ25pbmcgaXMgZGVhbHQgd2l0aCBieSB1c2luZyBgdG9rZW5fZW5kcG9pbnRf
YXV0aF9tZXRob2RzX3N1cHBvcnRlZGAgYW5kIGB0b2tlbl9lbmRwb2ludF9hdXRoX3NpZ25pbmdf
YWxnX3ZhbHVlc19zdXBwb3J0ZWRgIC0gdGhlcmUncyBubyBlbmNyeXB0aW9uIGZvciB0aGUgYF9q
d3RgIGNsaWVudCBhdXRoIG1ldGhvZHMuDQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVW5sZXNz
IGl0IHdhcyBtZWFudCB0byBhZGRyZXNzIHRoZSBSZXF1ZXN0IE9iamVjdCBzaWduaW5nIGFuZCBl
bmNyeXB0aW9uIG1ldGFkYXRhLCB3aGljaCBpcyBkZWZpbmVkIGFuZCBJQU5BIHJlZ2lzdGVyZWQg
YnkgT0lEQy4gUEFSIG9ubHkgcmVmZXJlbmNlcyBKQVIgc2VjdGlvbiA2LjEgYW5kIDYuMiBmb3Ig
ZGVjcnlwdGlvbi9zaWduYXR1cmUgdmFsaWRhdGlvbiBhbmQgdGhlc2UgZG8gbm90IG1lbnRpb24g
dGhlIG1ldGFkYXRhIChlLmcuDQogcmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGcpIGFueW1vcmUg
c2luY2UgZHJhZnQgMDcuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBEYW1tZWQhIFlvdSBhcmUg
c28gcmlnaHQuIFNvcnJ5LCBJIGdvdCBjb25mdXNlZCBzb21laG93LiA8YnI+DQo8YnI+DQombmJz
cDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFBTOiBJIGFsc28gZm91bmQg
dGhpcyBjb21tZW50IHJlbGF0ZWQgdG8gdGhlIHNhbWUgcXVlc3Rpb24gYWJvdXQgYXV0aCBtZXRh
ZGF0YSBidXQgZm9yIENJQkEuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHNo
YXJpbmcuIDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7
ICZndDsgQmVzdCw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRmlsaXA8YnI+DQo8YnI+DQombmJz
cDsgJm5ic3A7IHRoYW5rcyw8YnI+DQombmJzcDsgJm5ic3A7IFRvcnN0ZW4uIDxicj4NCjxicj4N
CiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7
ICZuYnNwOyAmZ3Q7IE9uIFR1ZSwgMzEgRGVjIDIwMTkgYXQgMTU6MzgsIFRvcnN0ZW4gTG9kZGVy
c3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0
PSJfYmxhbmsiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJm5i
c3A7ICZuYnNwOyAmZ3Q7IEhpIGFsbCw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5i
c3A7ICZuYnNwOyAmZ3Q7IFJvbmFsZCBqdXN0IHNlbnQgbWUgYW4gZW1haWwgYXNraW5nIHdoZXRo
ZXIgd2Ugd2lsbCBkZWZpbmUgbWV0YWRhdGEgZm9yIDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8
YnI+DQombmJzcDsgJm5ic3A7ICZndDsgcHVzaGVkX2F1dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0
aF9tZXRob2RzX3N1cHBvcnRlZCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgcHVzaGVkX2F1
dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0aF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkLjxi
cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhlIGRyYWZ0
IHJpZ2h0IG5vdyB1dGlsaXNlcyB0aGUgZXhpc3RpbmcgdG9rZW4gZW5kcG9pbnQgYXV0aGVudGlj
YXRpb24gbWV0aG9kcyBzbyB0aGVyZSBpcyBiYXNpY2FsbHkgbm8gbmVlZCB0byBkZWZpbmUgYW5v
dGhlciBwYXJhbWV0ZXIuIFRoZSBzYW1lIHByaW5jaXBsZSBjb3VsZCBiZSBhcHBsaWVkIHRvIHNp
Z25pbmcgKGFuZCBlbmNyeXB0aW9uKSBhbGdvcml0aG1zIGFzIHdlbGwuDQo8YnI+DQombmJzcDsg
Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFdoYXTigJlzIHlvdXIgb3Bpbmlv
bj88YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGJlc3Qg
cmVnYXJkcyw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVG9yc3Rlbi48YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2Jv
cmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBO
T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk
IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g
QW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp
cyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj
b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl
bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l
bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPg0KPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_234E2C284CF5462683D5719B176C418Bamazoncom_--


From nobody Tue Jan  7 23: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 A7713120105 for ; Tue,  7 Jan 2020 23:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.347
X-Spam-Level: 
X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ti812LT9CYg for ; Tue,  7 Jan 2020 23:54:18 -0800 (PST)
Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B819120091 for ; Tue,  7 Jan 2020 23:54:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1578470057; bh=sbpRmuKs24EC3uzUqP75NETu7kSwpXPJizNYzWe25QY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KZZ3kGWaoXPRyR4cB/Cz6Liishx6SuDmeZXKdJm2DV8Vt0GDg4qtIp8QdbNNZko/3UHW7BcMyJZP7eW6N8WonHclkdYf8u8JqI/gj5jTWHt3G79xhSAYGfLywG+XlApPoS/m3vyFUYZZyaZfFTkKMYbvWS82cqqOvyXtdIBvgb13+ZBOardPopKXuE/q4ni7myRpA6Tsg+sB9G4YLanRlLRzis4iFEtACR7HAMSQ/GpISmx624rffx88sXqmTBHLjAPG2swAJtEV9bxYVVZriPoasugLC7O4h6mAbijNUZQTdSRMyUyZ9yIqIKpU7Z44O6FqlWYmmOqhGEKJPOWyGg==
X-YMail-OSG: 8IsAmekVM1ln5m2rm04AeVjXyOsAO2XBtX27Aamlz3N.HeLzP4W9GrqoQOxUZhJ uPuqK3tY5d4ET9VHcKXxlZu5R530k9BG4_7DY081l_sllRKKtJGRNjrGewTMQ2DSDfgj18l0mJ9v 5Skb0oczWQiWCpUIfY_lL_R18I3Xf2ZDYmGjL3.M8.55zzbmzDKhFeKIBmL7zwP3FVSamyXj9Zrd k.abW4zmX36LQN8zSAyVWKNZ38TQUKsxr8YAn.l0yZznCf4vL2ahaMuCYo3NTkw4Cq8xN50RtFhi FVLqMZti.I1xZruRIjOWURKWh9vRUz8i98v8O8m6WRTPojx_KQk1Z0lsDuTt4QXavuFdOF4R5gKF gI98EmrFC7UvmoAfijSSxmHykaiZQnUFrZgaQFeG9fU2ae0hZNV8hXaltHtz2Bu0dlJbINuo0zGj FoytvMjltdF2XfKtNqGPHrav7XkqzRPkRJGJR1V9GVtqs4koHk_7ncnQvPEHbraXtz7c3lArruQs 9X5su0Yq0gyOthVzvm4OeIEOioXugEQZsu1ptIyvkKEpkRkRkUZpye7_PATAxJDUi0o7AKVwctSS sn6fnXacZQaCK5I8TbWllhBHM_scJ79IPnCF17otjo9QD3O4lgKwKbjYe1Hq.5fnIzAyUdwoBnQ9 aJFYaNm1s5Q9FTxK1wJHR2k02xKYyhm.AqHmB9ZwyJa2T24ax.hKjxiEUvLbnIAQrCLs5dPBxQi8 EnGxrTgNmWEumiyT0o.FAU9jZwLY7W_pV.l2IKFTn00yTGRcBQVEJfSZ82ikiw21I0kglzAMvmkR PGSdShbM69MuuKEZvqga2vI1nUHDPrvMvcLuZ8mhbMM6ND9V3U6e3.al.QYV6Ahd_tPkpl7FGhCQ 0yNTKAgNkRBR9xe2uhvp9etUHNT1T6bmken9GFmJA8R01Pl5bsps3.uBykHZNhBNwQOFcBZ.91JY 9xYMnrjzVj.6BcmNsVRLppX7taN3z6GLousx0Z1QxmKuWMTn5byk.PQQlYOCphotBGCOxqVXfs2Z mEKpWFMaAJPhaHp6LPDyRbMnE7_wBFgJpjv95oB1ETLAjQvMrRfWfEGGiyJjwCw4Nmgw9DlHG3Xf ixDLtf6sv3GLC6og4oTqI4_0hXkKysOlGqMMXDTMzb4nfZLB26tAEvATexp.34HHpVGCT_ijZ34h nk0MawLA8BsyPcUwaGUVLvufVDJMP05zitYx5i2aopyKTRw4FsUFi5rmoq7d_96Q4VTkWQi_srmQ kkSTHsvAmKWQrgZf2V5No.749X_NTsuAutMNy81sbd045b5HLIwg6KD0aaEnq_hlIfCGNz7GStBa 7IpqteIw2HuTC5R0x4LITETH.oLOcNw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jan 2020 07:54:17 +0000
Date: Wed, 8 Jan 2020 07:54:13 +0000 (UTC)
From: kimoun905@yahoo.com
To: oauth-bounces@ietf.org
Cc: oauth@ietf.org
Message-ID: <938007346.9837064.1578470053792@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_9837063_2130274501.1578470053791"
X-Mailer: WebService/1.1.14873 YMailMini Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Archived-At: 
Subject: Re: [OAUTH-WG] Mailman privacy alert
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 07:54:20 -0000

------=_Part_9837063_2130274501.1578470053791
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20

On Wednesday, January 8, 2020, 2:52:22 PM GMT+7,  w=
rote:


An attempt was made to subscribe your address to the mailing list
oauth@ietf.org.=C2=A0 You are already subscribed to this mailing list.

Note that the list membership is not public, so it is possible that a bad
person was trying to probe the list for its membership.=C2=A0 This would be=
 a
privacy violation if we let them do this, but we didn't.

If you submitted the subscription request and forgot that you were already
subscribed to the list, then you can ignore this message.=C2=A0 If you susp=
ect that
an attempt is being made to covertly discover whether you are a member of t=
his
list, and you are worried about your privacy, then feel free to send a mess=
age
to the list administrator at oauth-owner@ietf.org. =20
------=_Part_9837063_2130274501.1578470053791
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


                

On Wednesday, January 8, 2020, 2:52:22 PM GMT+=
7, <oauth-bounces@ietf.org> wrote:


An attempt was made to =
subscribe your address to the mailing list
oauth@ietf.org.=C2=A0 You are=
 already subscribed to this mailing list.

Note that the list members=
hip is not public, so it is possible that a bad
person was trying to pro=
be the list for its membership.=C2=A0 This would be a
privacy violation =
if we let them do this, but we didn't.

If you submitted the subs=
cription request and forgot that you were already
subscribed to the list=
, then you can ignore this message.=C2=A0 If you suspect that
an attempt=
 is being made to covertly discover whether you are a member of this
lis=
t, and you are worried about your privacy, then feel free to send a message=

to the list administrator at oauth-owner@ietf.org.            
   =
        =20
------=_Part_9837063_2130274501.1578470053791--


From nobody Wed Jan  8 00:03: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 0A2141200A4 for ; Wed,  8 Jan 2020 00:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level: 
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V73vmmN5HhhX for ; Wed,  8 Jan 2020 00:03:54 -0800 (PST)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1531212007C for ; Wed,  8 Jan 2020 00:03:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1578470633; bh=2JQ97Sv9vt4uDPhDFkKT8TsV8l4lMfrtJXbWSKym5RM=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=EIksGqT6J9fosWuSKsnvrBl5eSghs+JQqD9yYpJKdwvY41Z8O52GprjCOlA5U8GlXF8/GaIxinemOFbVpiufeqZjRcoWW+7XkApjzKX/ADXpbuKHLkb6rQEAPKQDqzOyAFluCOBYty/G6NBXb9GQf74dhGCWCqudNE+CuEXA3i21J9BL2lIKT38KJm3kZq8gHDonFb99GgsJyOMjq0ZFsyDs14AkT1FmWtTAlgsNscHFriMHXRIDNZBZH4kOoOEMoHg+QSKmO7EMN0/zjeIGe+dZtjx0dNxLcS7ykg0pDKn1vyY+Qgmg0zn1oamjHleY+xYVRDenoxVbrAR4yMWteQ==
X-YMail-OSG: DD8cMN8VM1m5fLLhLC.ieHm7rfDBkAd3IBforHQULjVcTUQC2ePVt.TNvX7Rc96 d0W8C9udyBe0MIuoW.luLLzW.fAqUMCPGdg.g.4Fab_ttOitDkrU5cdl0px619YwjfDq2qpUuri6 gJ5mfWrFF5iavCHnTfoH4VbVnOh0Kl3.XW4j7Ut8Kd0Co6Lg_ja9lle0YkIxxflPZmsfOVoFGTg_ gwQwQU4UUojLfqkoesvANWPR.4BO4Qu81QhgsZgnzizedBjyxfuXcezyI0CJnwG9pkw4uXRfayv2 RXrRFJd2b7ZBD6EPrPJ7A0LKat6qwUSuc4ALhas2y5WFfSu2ZZA5fSYxsBXi5v2SdLXacSDAeeFU N6.ywOYki3QUbw2vMy0R0Wu0EDE5iPh8bGly23_1mBrfSWODj76wlgzOZu_PZaQ9P669CxDxWOYP a_wgJz6ioIFX4N4tPdph6HWJc0msKXGNukyWZVngA_ptYrS8frXY_ay0dz9QgI2jcj7xo9vEFXdD DTxzFDwJvj4z_Qnz5fGHu_GRYnxXWoRyH43UI0tcAS3sBBMXLyRbumq7QvqE0Lor.kM2nWbFF3J4 OZDBSy..EntrZrCHzo0JOvhtlbn6CuwIOxzyDnwSpPpaVdNcAklr59m6lmgkq1VvbKLGpCk8ksr9 6xDVbvDNc4I9s5W4pf24N7wbbwObycnxIWE6BqnrRpcc11ES4PW2K1JNSNRR2pN0jgMt8.fo6cs5 te8xReWwLIz7l77Bs.e7atvD1NDzkZcFz..LJeHBeFl_MS_qDxqCc9Y3IPOi99TimaIXlVmLyWA7 Y_CBlJN3CiVIdlwqlZaW_08zpFKeBYxIqcdk3aDfDP2VsUwty.CdMwcEZjaXgPSsUZvl3yNzgU9H UAdjJR1fys7IEWEcC1qm95silY6.20tiEg5..9UKirv01XPXrjMRK8bE8dU9g9B2dyzl9ybTNC8t 9yk5XDl1pYzpeiCl4XzMkJ7swPpHo2Ikn3rZDJxArS53sSFqZXjAfbEIDFVkBdXzwcQnjHPl.r74 wcXW8r50ImkdExgq_pfG1_MsGcLovp_kva_HMnxYUBu_Of3EzSC02lYin7gZmv4RuqWJa1j1z_CF GeTKLIaIxAOKdcN97r5Rv0EO_54IXkF_t3p4RTbht2xJUzgReeWaK6yVUhCZP2MnhQ2Q7OYQp3Qm iYo8p.CuqMLuJXxnWYDCfIb3I_jctXBRbI.0W3qV19cEETknwOtJ3FaWvRw0SnpvWBgyrsntwefH szPgdUYNz8DBAJrT5u3TE3v7e2E1YkQBnT70Ow_VMBw8RLz6UHPuh2W.SopL66dx0mjH5AizOwLN G4o94QEeig81Rwi0wr1ChStsm
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jan 2020 08:03:53 +0000
Date: Wed, 8 Jan 2020 08:03:53 +0000 (UTC)
From: kimoun905@yahoo.com
To: oauth-bounces@ietf.org
Cc: oauth@ietf.org
Message-ID: <780332510.9834551.1578470633300@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_9834550_1994365549.1578470633299"
X-Mailer: WebService/1.1.14873 YMailMini Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth@ietf.org mailing list reminder
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 08:03:55 -0000

------=_Part_9834550_1994365549.1578470633299
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
     On Wednesday, January 8, 2020, 2:59:06 PM GMT+7,  wrote: =20
=20
 You, or someone posing as you, has requested a password reminder for
your membership on the mailing list oauth@ietf.org.=C2=A0 You will need
this password in order to change your membership options (e.g. do you
want regular delivery or digest delivery), and having this password
makes it easier for you to unsubscribe from the mailing list.

You are subscribed with the address: kimoun905@yahoo.com

Your OAuth password is: Y-google905

To make changes to your membership options, log in and visit your
options web page:

=C2=A0 =C2=A0 https://www.ietf.org/mailman/options/oauth/kimoun905%40yahoo.=
com

You can also make such changes via email by sending a message to:

=C2=A0 =C2=A0 oauth-request@ietf.org

with the text "help" in the subject or body.=C2=A0 The automatic reply will
contain more detailed instructions.

Questions or comments?=C2=A0 Please send them to the OAuth mailing list
administrator at oauth-owner@ietf.org.
 =20
------=_Part_9834550_1994365549.1578470633299
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


                
            
            
                        
        =
                        
                    On Wednesday, January 8, 2=
020, 2:59:06 PM GMT+7,  <oauth-bounces@ietf.org> wrote:              =
  
                

                

     =
           
You, or someone posing as you, has request=
ed a password reminder for
your membership on the=
 mailing list oauth@ietf.org.  You will need
=
this password in order to change your membership options (e.g. do you
want regular delivery or digest delivery), and having =
this password
makes it easier for you to unsubscr=
ibe from the mailing list.

You are subscribed with the address: kimoun905@yahoo.com

Your OAuth password is: Y-go=
ogle905

To make change=
s to your membership options, log in and visit your
options web page:


You can also make such changes via email by sending a message to:
<=
/div>


with the text "help" in the subject or body.  The automatic reply =
will
contain more detailed instructions.

Questions or comments?  P=
lease send them to the OAuth mailing list
adminis=
trator at oauth-owner@ietf.org.
                            

------=_Part_9834550_1994365549.1578470633299--


From nobody Wed Jan  8 02:11: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 D5E2812006E for ; Wed,  8 Jan 2020 02:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aG1DQlf8zf4Y for ; Wed,  8 Jan 2020 02:11:30 -0800 (PST)
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CF0120143 for ; Wed,  8 Jan 2020 02:11:29 -0800 (PST)
Received: by mail-wm1-x341.google.com with SMTP id d73so1835629wmd.1 for ; Wed, 08 Jan 2020 02:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UxSGwvmvpBro3X3Z10sQjrZCblTRrqgS4flzBpK69Hc=; b=uidvG6bSSMuGjcly+a+LeB8O5ITzu41arcRAuVbBRLW2AvQA7FbHFVfXBOBQ1ryUUH fEKGZ2DvhizYnTLZbP3X+6Z4vRES6L+XnYKBDFXANY6ZME3ECx6ReQDlKhaBQnU4KJjY BH/hCHUlFN8U16yFxJtAavnkatwQN2rwX9605+9gRWm5A5K5X2A8JixxgCLYXF1hJ1Ux VDZSoDYrcHaQ+2JclHpEl6xBVbGdWTzsxrJELKV+ZGOL/LtefJVJUp+LQg1/ago9T25J eH7thtxZyXTW2Hb/BzRKjmBIrXkybrsiffNPqO2+ufA9fRIv8ZlUHRVOcqsGU4NHqQrL 9ctQ==
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=UxSGwvmvpBro3X3Z10sQjrZCblTRrqgS4flzBpK69Hc=; b=VEboHmw4bSklmxe8HyzeU1xdulGI7hcmliz8suNBqLBsv/EoAsuKqs5gsVAM86/Ucn jAZRrnsOUhtwJ3m9GISVFLEceVdoVcAyA+IzXLNxkPdNsJ/lgdQz5BOc2moELraLMxzT UF5Z2kwSsTLVcAvGuG9HDBpryJFXYnlb+bhCT6/hxIcQNad+344kfuhwQRNJVquOoC5P KLoleGQVvXDtuUPmwzYreIBLDq9sJ7XmPcSzR0tirX5ZsuNW+PyWoP/9n6PzmVq8m7EJ PctAXPSga4p+G++86FzXjcupcBSIgI7WE/IYz+jmHR/HN0fomSc7eCLl7ukYjKVDF1Z7 34Ww==
X-Gm-Message-State: APjAAAW4db6cv8MvbcIY3InaGA2FccUH2udG3htuTb1GVemctCBkdqWs D8D36+mLrvKibJ2nal62PLQf9g==
X-Google-Smtp-Source: APXvYqygqzPKkGK8oMFx5YCg8189O1pkDdEfhMFOgVNN8pmlQ6xo8In378ZyXZ/j/ltjfMqx4GAXZg==
X-Received: by 2002:a7b:c10f:: with SMTP id w15mr2766355wmi.69.1578478287846;  Wed, 08 Jan 2020 02:11:27 -0800 (PST)
Received: from [10.30.4.222] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id h66sm3367821wme.41.2020.01.08.02.11.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 02:11:26 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: <70997D70-0DFF-4C39-B712-F916BFB04EDF@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_D7E7095C-8696-43D8-8462-9170C6C90399"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Wed, 8 Jan 2020 11:10:39 +0100
In-Reply-To: <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com>
Cc: Brian Campbell , Vladimir Dzhuvinov , Dave Tonge , oauth , Nat Sakimura 
To: "Richard Backman, Annabelle" 
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>  <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>  <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR 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: Wed, 08 Jan 2020 10:11:33 -0000

--Apple-Mail=_D7E7095C-8696-43D8-8462-9170C6C90399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Annabelle,=20

thanks for your proposal, which reads reasonable to me.=20

I suggest to extend =E2=80=9Cand that the request has not been modified =
in a way that would affect the outcome of the omitted steps.=E2=80=9D a =
bit to also consider policy changes that may have occurred between push =
and authorization request processing.=20

"and that the request or the authorization server=E2=80=99s policy has =
not been modified in a way that would affect the outcome of the omitted =
steps."

best regards,
Torsten.=20

> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle =
 wrote:
>=20
> I think it=E2=80=99s clearer if we split out the requirements for the =
PAR endpoint and the requirements for the authorization endpoint, given =
that they are each covered in different sections of the doc (2 and 4, =
respectively). With that in mind, here are a couple suggestions:
> =20
> For the text in Section 2.1:
> =20
> 3.  The AS MUST validate the pushed request as it would an =
authorization
>=20
>     request sent to the authorization endpoint, however the AS MAY =
omit
>=20
>     validation steps that it is unable to perform when processing the
>=20
>     pushed request.
>=20
> =20
> =20
> Additional text for Section 4 (note that this section pertains to the =
authorization endpoint):
> =20
> The AS MUST validate authorization requests arising from a pushed =
request as
>=20
> it would any other authorization request.  The AS MAY omit validation =
steps
>=20
> that it performed when the request was pushed, provided that it can =
validate
>=20
> that the request was a pushed request, and that the request has not =
been
>=20
> modified in a way that would affect the outcome of the omitted steps.
>=20
> =20
> =20
> This is longer than the current text and the other proposals, but it =
adds a few important points:
> 	=E2=80=A2 Turns the 2.1 SHOULD back into a MUST, with an =
explicit exception for validation that can=E2=80=99t be done yet.
> 	=E2=80=A2 Reinforces the fact that the authorization endpoint =
still needs to do validation.
> 	=E2=80=A2 Clearly states requirements for when an AS can trust =
that validation happened at the PAR endpoint.
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: Brian Campbell 
> Date: Tuesday, January 7, 2020 at 2:54 PM
> To: Vladimir Dzhuvinov 
> Cc: Filip Skokan , "Richard Backman, Annabelle" =
, Dave Tonge , oauth =
, Nat Sakimura 
> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: =
PAR metadata
> =20
> A little more context about that proposed wording is in a github issue =
at
>>=20
>>>> 	=E2=80=A2
>>>> 	=E2=80=A2
>>>> 	=E2=80=A2
>>>> 	=E2=80=A2
>>>> 	=E2=80=A2
https://github.com/oauthstuff/draft-oauth-par/issues/38, which is =
different driver than allowing a PAR endpoint to stash the encrypted =
request object rather than decrypting/validating it. But it's kind of =
the same concept at some level too - that there are some things that =
can't or won't be validated at the PAR endpoint and those then have to =
be validated at the authorization endpoint..
=20
I rather like your suggested text, Vladimir, and have mentioned it in a =
comment on the aforementioned issue.
=20
=20
On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov =
 wrote:
On 07/01/2020 00:22, Filip Skokan wrote:
We've been discussing making the following change to the language
=20
The AS SHOULD validate the request in the same way as at the =
authorization endpoint. The AS MUST ensure that all parameters to the =
authorization request are still valid at the time when the request URI =
is used.
Could you expand a bit on the second sentence?
Alternative suggestion:
The AS MUST validate the request in the same way as at the authorization =
endpoint, or complete the request validation at the authorization =
endpoint.
Vladimir
=20
This would allow the PAR endpoint to simply stash the encrypted request =
object instead of decrypting and validating it. All within the bounds of =
"SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t always =
require it". This supports "light weight PAR" implementation rather than =
introducing the unnecessary complexity in the form of a second JWKS.

Best,
Filip
=20
=20
On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle =
 wrote:
The issue isn=E2=80=99t that the PAR endpoint needs access to one =
specific request object decryption key that could reasonably be shared =
across AS endpoints, but that it actually needs access to the private =
keys for all encryption public keys in the JWK set pointed to by the =
AS=E2=80=99s jwks_uri metadata property. Since there is no way to =
designate one particular key as the one to use for encrypting request =
objects, clients may reasonably use any encryption public key in the JWK =
set to encrypt a request object. As one example of how this could expose =
sensitive data to the PAR endpoint, if the PAR endpoint has all the =
decryption keys for the keys in the AS=E2=80=99s JWK set, it would be =
able to decrypt ID Tokens sent in id_token_hint request parameters. As =
more and more use cases develop for encrypting blobs for the AS, this =
issue will only get worse.

=20

The PAR endpoint can=E2=80=99t simply stash the encrypted request =
object, as it is required to verify the request, according to =C2=A72.1:

=20

The AS MUST process the request as follows:
=20
....
=20
3.  The AS MUST validate the request in the same way as at the
          authorization endpoint. ...
=20
This language needs to be more flexible, IMHO, to allow for lightweight =
PAR endpoints that may not have the information or authority needed to =
perform all the validation that happens at the authorization endpoint. I =
need to think about this more before I can say if it would adequately =
address my concerns, but it=E2=80=99d be a good start and makes sense in =
its own right.

=20

I think it=E2=80=99s pretty risky for us to base decision on an =
assumption that no one is going to need or want to encrypt pushed =
request objects, particularly when they=E2=80=99re JWTs, and JWTs have =
well established support for encryption, and encrypted JWTs are =
supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if =
you insist, here are a few examples for why someone might want to do =
this:

The request object is passed by reference, and accessible on the public =
Internet.
The request object contains sensitive transaction-related data in RAR =
parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80=99t =
need to have access to.
The AS requires request object encryption to minimize exposure to the =
hosted PAR endpoint service it uses.
#2, but the threat vector is gaps in end-to-end TLS.
Any of the above, but the concern is message integrity, and the AS =
requires requested objects to be encrypted for confidentiality and =
integrity protection and does not support signed request objects.
=20

=E2=80=93=20

Annabelle Richard Backman

AWS Identity

=20

=20

From: Neil Madden 
Date: Monday, January 6, 2020 at 6:29 AM
To: Brian Campbell 
Cc: "Richard Backman, Annabelle" , Nat Sakimura =
, Dave Tonge , Torsten =
Lodderstedt , oauth 
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata

=20

Agreed.

=20

In addition, I'm not sure why the PAR endpoint would need access to the =
decryption keys at all. If you're using encrypted request objects then =
the PAR endpoint receives an encrypted JWT and then later makes the same =
(still encrypted) JWT available to the authorization endpoint. If the =
PAR endpoint is doing any kind of decryption or validation on behalf of =
the authorization endpoint then they are clearly not in separate trust =
boundaries.

=20

-- Neil

=20

=20

On 6 Jan 2020, at 13:57, Brian Campbell =
 wrote:

=20

I really struggle to see the assumption that an entity be able to use =
the same key to decrypt the same type of message ultimately intended for =
the same purpose as an artificial limit. The same general assumption   =
underlies everything else in OAuth/OIDC (Vladimir's post points to some =
but not all examples of such). There's no reason for PAR to make a =
one-off exception. And should there be some deployment specific reason =
that truly requires that kind of isolation, there are certainly =
implementation options that aren't compatibility-breaking. And having =
said all that, I'm honestly a little surprised anyone is thinking much =
about encrypted request objects with PAR as, at least with my limited =
imagination, there's not really a need for it.

=20

=20

=20

=20

=20

=20

=20

=20

On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle =
 wrote:

PAR introduces an added wrinkle for encrypted request objects: the PAR =
endpoint and authorization endpoint may not have access to the same =
cryptographic keys, even though they're both part of the "authorization =
server." Since they're different endpoints with different roles, it's =
reasonable to put them in separate trust boundaries. There is no way to =
support this isolation with just a single "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that =
don't care (i.e., they just set par_jwks_uri and jwks_uri to the same =
value) and failing to support this trust boundary creates an artificial =
limit on implementation architecture and could lead to =
compatibility-breaking workarounds.

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


On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" =
 wrote:

    Hi Filip,=20

    > On 31. Dec 2019, at 16:22, Filip Skokan  =
wrote:
    >=20
    > I don't think we need a *_auth_method_* metadata for every =
endpoint the client calls directly, none of the new specs defined these =
(e.g. device authorization endpoint or CIBA), meaning they also didn't =
follow the scheme from RFC 8414 where introspection and revocation got =
its own metadata. In most cases the unfortunately named =
`token_endpoint_auth_method` and its related metadata is what's used by =
clients for all direct calls anyway.
    >=20
    > The same principle could be applied to signing (and encryption) =
algorithms as well.
    >=20
    > This I do not follow, auth methods and their signing is dealt with =
by using `token_endpoint_auth_methods_supported` and =
`token_endpoint_auth_signing_alg_values_supported` - there's no =
encryption for the `_jwt` client auth methods.=20
    > Unless it was meant to address the Request Object signing and =
encryption metadata, which is defined and IANA registered by OIDC. PAR =
only references JAR section 6.1 and 6.2 for decryption/signature =
validation and these do not mention the metadata (e.g. =
request_object_signing_alg) anymore since draft 07.

    Dammed! You are so right. Sorry, I got confused somehow.=20

    >=20
    > PS: I also found this comment related to the same question about =
auth metadata but for CIBA.

    Thanks for sharing.=20

    >=20
    > Best,
    > Filip

    thanks,
    Torsten.=20

    >=20
    >=20
    > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt =
 wrote:
    > Hi all,
    >=20
    > Ronald just sent me an email asking whether we will define =
metadata for=20
    >=20
    > pushed_authorization_endpoint_auth_methods_supported and
    > pushed_authorization_endpoint_auth_signing_alg_values_supported.
    >=20
    > The draft right now utilises the existing token endpoint =
authentication methods so there is basically no need to define another =
parameter. The same principle could be applied to signing (and =
encryption) algorithms as well.=20
    >=20
    > What=E2=80=99s your opinion?
    >=20
    > best regards,
    > Torsten.



_______________________________________________
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

CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended 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=_D7E7095C-8696-43D8-8462-9170C6C90399
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMDgxMDEwMzlaMC8GCSqGSIb3DQEJBDEiBCBdTHb1Qx9taXFs8TrjdZYRg4HFC90kGZXI
Z9D5MuTTLjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAFPos2smbqtOx03sVKrTjoRpNZQI9GFbY7DJ0SWPj2mqjP+Xq/2JsjfjL3P/
BAHPnPM0yvnpdJrk1VxdA5SIwvvTSsZFzsqo6vdNJZhhD4FPiNxE0hwZrLipNwQ8XVNysNB0Bpks
CDI/XCBDe+J0z0IYae02x//zLNkKP75RYBvGcAfO6O+Y3TEk5L92C2b2IIwLr5dCeVkGJj8czAtD
Ye1fOfwBHwkBAfnLi4vxBDVH5CQ41zhFEvYrA9+VNiJJ6dsUfLEID0OB2EvHUdM3Rz5m2jFI00xP
A9lssbShbm2UJ2WrKWxcDVBbnRdLURYNF1qbpbWTLcgUwLCpMOY+fBYAAAAAAAA=
--Apple-Mail=_D7E7095C-8696-43D8-8462-9170C6C90399--


From nobody Wed Jan  8 05:29: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 494361200F4 for ; Wed,  8 Jan 2020 05:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyC1nOSOpy51 for ; Wed,  8 Jan 2020 05:29:53 -0800 (PST)
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 072CF1200F1 for ; Wed,  8 Jan 2020 05:29:53 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id a5so2499803wmb.0 for ; Wed, 08 Jan 2020 05:29:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6xrM94oCSOXqAF4FVzRCRUwhdJywjDgzb1mJ4LpFc1U=; b=g/645ROBOfADKtnLccs+C/71sgw/J2qzKxxCaVlrUTZsOjQ/GUGVGNaFdVmBTMxlBf lkc+6bbuzz5lfQSh4HSTHxyHGK7ZmO7RFaylF6celC6F8BObMe+CG1hSX6TPOae6YRP6 sXhFzsqmrRSvJZkYRImbgne2CcCSVdFJMtzXpzNEEdYfG/YVDwfDYjp1ecZuvOMgXeUk oPhXughUhXlVE2Hd5GSXjG21u+0UoUwmRrnxQjPDjDjEnP8AjRU60mBfeS2TQUCiu0b/ MWGTg5LoZfuXj6EQ3X1c4iOB5KJpoz+cvZFQqXo1sSVxITSrnpppgXjHZzLm7fHMCwgn Rv9g==
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=6xrM94oCSOXqAF4FVzRCRUwhdJywjDgzb1mJ4LpFc1U=; b=f+vJvJgHllelrCPQvPGjny3tmjT/YvZHdyooFvQSXOh4U3+ziPLZrxDN2KHGMrmPI0 ex6kxrNQ+PftLeteMjkYzHTj9fGi8fkibIRWtUzwun9UTVmveU40VcOQAsXlWwVIVgB4 zijwz3O2Nr1QqzNbZ7EoY0KE8mI5dSP7CW5kVmxffc4H+IlFaGpSxrygQtjXzzJK14EX JNtihy+naXiL0jGxrUALTmmWegyHuNqT7VbDfdK7GorDN0aaRoZQRkicVp9GzPtC5mNp 85gmcfl7pG9ef5e10nZgmd4pDEZ0wKZYsn2Cr6RllHT4auAQ92HRNI6gu97kPwwOTzjq 7mkA==
X-Gm-Message-State: APjAAAV/4BPNCNZ4qOZPrzJoHqBFryTuXrnPRivtZFS54pY1DtSTnlcx Ec3Oq8CUzipe880aJLTyS4PxBLhhXfMw2R5t/fs=
X-Google-Smtp-Source: APXvYqxFxqfg+7a2qYJJxBRzkv9nsxDG0lI460hL046L1u+JYZp80hk9zwVsXYda4kDADZQ4ROZ32NgrV0g0iim1LF0=
X-Received: by 2002:a7b:c450:: with SMTP id l16mr3714623wmi.166.1578490191221;  Wed, 08 Jan 2020 05:29:51 -0800 (PST)
MIME-Version: 1.0
References:    <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net>  
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 8 Jan 2020 22:29:40 +0900
Message-ID: 
To: Joseph Heenan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000002119c0059ba0e3e1"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 13:29:57 -0000

--0000000000002119c0059ba0e3e1
Content-Type: text/plain; charset="UTF-8"

+1

On Wed, Jan 8, 2020 at 8:53 AM Joseph Heenan  wrote:

> +1
>
> On 8 Jan 2020, at 03:31, Steinar Noem  wrote:
>
> +1
>
> tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org <40lodderstedt.net@dmarc.ietf..org>>:
>
>> +1
>>
>> > On 7. Jan 2020, at 17:25, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote:
>> >
>> > +1
>> >
>> > On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>> > +1 for the adoption of RAR
>> >
>> > On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
>> >> This is a call for adoption for the OAuth 2.0 Rich Authorization
>> Requests document.
>> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited..
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you._______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>
> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


+1

On Wed, Jan 8, 2020 at 8:53 AM Joseph Heenan <joseph@authlete.com> wrote:
<=
/div>
+1

On 8 Ja=
n 2020, at 03:31, Steinar Noem <steinar@udelt.no> wrote:

+1

tir. 7. jan. 2020 kl. 17:53 skrev Torsten Loddersted=
t <torsten=3D40lodderstedt.net@dmarc.ietf.org>:
+1



> On 7. Jan 2020, at 17:25, Brian Campbell <bcampbell=3D40pingidentity.co=
m@dmarc.ietf.org> wrote:

> 

> +1

> 

> On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <vladimir@connect2id.com>=
; wrote:

> +1 for the adoption of RAR

> 

> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:

>> This is a call for adoption for the OAuth 2.0 Rich Authorization R=
equests document.

>> https://datatracker.ietf.org/d=
oc/draft-lodderstedt-oauth-rar/ 

> _______________________________________________

> 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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
<=
div style=3D"color:rgb(34,34,34)">|=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

_______________________________________________
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




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Found=
ation
http://nat.=
sakimura.org/
@_nat_en


--0000000000002119c0059ba0e3e1--


From nobody Wed Jan  8 06:32: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 CE9E712004C for ; Wed,  8 Jan 2020 06:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 kQGNmOjcH45C for ; Wed,  8 Jan 2020 06:32:17 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4B7120044 for ; Wed,  8 Jan 2020 06:32:17 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id i15so3785674oto.2 for ; Wed, 08 Jan 2020 06:32:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YyjDRqBUDPIpnllK8RfjaDmDf2vwaoYqF/2lCBHeH38=; b=P2AfF96JNHTjf9NAyrVOZPKtY6NuKIxH2RYLd9fhB3ouR5hwmQ3gXUgIPksfv1kICZ KEJt3aFQKwnM5HruX+1AhJMfQW3L1xTV5cYvFjauvlq8sv/22D+c0wvw1bE8Q5lK+s+i pSMgEC3KVk5kOYU29Dhg4GvksTksNOjUZU2Sw=
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=YyjDRqBUDPIpnllK8RfjaDmDf2vwaoYqF/2lCBHeH38=; b=hc8xk2BXTnOKJHpXrzaF7lxnwkBRGCbvEnjdVDFQLUWyhAHJbCXWjK0XCvhUE1f7ey ia1hXtcswR9AX6TdjTYhlMKkHY7U2npkK4/1hLzIBglny323U+MWGOBuV5+lqEsysCr4 OrdBPseBUU6d2ALy4i0WYHCjWyaof2raQXach0PYGQ1wm2i4Vs8yRHu13wuJffH+srKs 3xtO0J40fKYgdbQGnk/K2tUFqJydrCYxLdLcfS6p/agW5Gk3fkdFJajbSDVU837ad7U7 SbpeHISa0vAobj5DrHH6nBbdZB6noELR0pZ8Z3sAQHQhPraj7/gLSsuLvLr+pM1Rpp0F 3+VA==
X-Gm-Message-State: APjAAAVts4PKZzh3qr9OUQBqU4Pt2hvbnflzMMdVbQDr9mkB4RAplJry hUefNifIZ0yPRTI8/v2d6QqkaAUs8SyQqVU2Cbh2+fMu4xB+nQ==
X-Google-Smtp-Source: APXvYqzDTPoBXkdYWu6NV5Qtd7npi0R6gLjbcikK+/IOkBa3pPR/yL8qLtVx8wsJGJ9vsVBitiZaOnEna44OOEKIn+c=
X-Received: by 2002:a9d:f26:: with SMTP id 35mr4653697ott.260.1578493936473; Wed, 08 Jan 2020 06:32:16 -0800 (PST)
MIME-Version: 1.0
References:    <1F49AED7-4241-4789-9174-E3EBF0865ACB@lodderstedt.net>   
In-Reply-To: 
From: Dave Tonge 
Date: Wed, 8 Jan 2020 15:32:04 +0100
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000005d319e059ba1c248"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 14:32:20 -0000

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

+1

On Wed, 8 Jan 2020 at 14:30, Nat Sakimura  wrote:

> +1
>
> On Wed, Jan 8, 2020 at 8:53 AM Joseph Heenan  wrote:
>
>> +1
>>
>> On 8 Jan 2020, at 03:31, Steinar Noem  wrote:
>>
>> +1
>>
>> tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org <40lodderstedt.net@dmarc.ietf..org>>:
>>
>>> +1
>>>
>>> > On 7. Jan 2020, at 17:25, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote:
>>> >
>>> > +1
>>> >
>>> > On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <
>>> vladimir@connect2id.com> wrote:
>>> > +1 for the adoption of RAR
>>> >
>>> > On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
>>> >> This is a call for adoption for the OAuth 2.0 Rich Authorization
>>> Requests document.
>>> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>> > _______________________________________________
>>> > 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
>>>
>> --
>> Vennlig hilsen
>>
>> Steinar Noem
>> Partner Udelt AS
>> Systemutvikler
>>
>> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Dave Tonge
CTO
[image: Moneyhub Enterprise]

Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 =C2=A9

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

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


+1

On Wed, 8 Jan 2020 at 14:30, Nat Sakimura <=
;sakimura@gmail.com> wrote:
+=
1

On Wed, Jan 8, 2020 at 8:53 AM Joseph Heenan <joseph@authlete.com> wrote:
<=
/div>
+1

=

On 8 Jan 2020, at 03:31, Steinar Noem <steinar@udelt.no>=
; wrote:

+1

tir. 7. jan. 202=
0 kl. 17:53 skrev Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.iet=
f.org>:
+=
1



> On 7. Jan 2020, at 17:25, Brian Campbell <bcampbell=3D40pingidentity.co=
m@dmarc.ietf.org> wrote:

> 

> +1

> 

> On Tue, Jan 7, 2020 at 6:12 AM Vladimir Dzhuvinov <vladimir@connect2id.com>=
; wrote:

> +1 for the adoption of RAR

> 

> On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:

>> This is a call for adoption for the OAuth 2.0 Rich Authorization R=
equests document.

>> https://datatracker.ietf.org/d=
oc/draft-lodderstedt-oauth-rar/ 

> _______________________________________________

> 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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
<=
div style=3D"color:rgb(34,34,34)">|=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

_______________________________________________
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




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat=
_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Da=
ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl=
oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512=
0

Moneyhub =
Enterprise is a trading style of Moneyhub Financial Technology Limited whic=
h is authorised and regulated by the Financial Conduct Authority ("FCA=
").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser=
vices Register=C2=A0(FRN=C2=A0809360) at fca.=
org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &=
; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<=
/span>
Moneyhub=C2=A0Financial Technology L=
imited 2018=C2=A0=C2=A9<=
/div>

DISCLAIMER: This email (including any attachments) is subject to co=
pyright, and the information in it is confidential. Use of this email or of=
 any information in it other than by the addressee is unauthorised and unla=
wful. Whilst reasonable efforts are made to ensure that any attachments are=
 virus-free, it is the recipient's sole responsibility to scan all atta=
chments for viruses. All calls and emails to and from this company may be m=
onitored and recorded for legitimate purposes relating to this company'=
s business. Any opinions expressed in this email (or in any attachments) ar=
e those of the author and do not necessarily represent the opinions of Mone=
yhub Financial Technology Limited or of any other group company.
<=
/div>


--0000000000005d319e059ba1c248--


From nobody Wed Jan  8 12:47: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 8BCCC1208A8 for ; Wed,  8 Jan 2020 12:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.8
X-Spam-Level: 
X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgDCO5SCFBmh for ; Wed,  8 Jan 2020 12:47:04 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 725DA12089E for ; Wed,  8 Jan 2020 12:47:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578516425; x=1610052425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i0JTXVDZSO+KFOguEZpltIEMniozzC2EPnLwNcD/NmQ=; b=jCCZo1KL07YZ11ku0kye6ViRzrvY5gB7xNitQK4xZADD54NDJX9FDJRR GY9rryqzTnOG+s3Ta8YQD/RzvJiKLr242ot+LKS0DlkO4Yx5ewSVW2TaK dt6/dapN0VwlU2jM0nYft3R+1x0V84dNYkpr6uDLCBbq4rMu1kzkvFhqz Q=;
IronPort-SDR: cQldp0xX8A9suXtvrvnuiwDQXPadYVEjWyE9DyhKFpBv46XLiraIi55XJ4OAODohnhwXsQBde4 u/wvQsuYv2Sg==
X-IronPort-AV: E=Sophos;i="5.69,411,1571702400"; d="scan'208";a="12104774"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 08 Jan 2020 20:47:02 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id 26C82A22AB; Wed,  8 Jan 2020 20:46:59 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 20:46:59 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 20:46:59 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 20:46:59 +0000
From: "Richard Backman, Annabelle" 
To: Torsten Lodderstedt 
CC: Brian Campbell , Vladimir Dzhuvinov , Dave Tonge , oauth , Nat Sakimura 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR metadata
Thread-Index: AQHVxgwJzWbOpqxVSki1X5ux7pEehafgt1SA
Date: Wed, 8 Jan 2020 20:46:58 +0000
Message-ID: 
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>  <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>  <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com> <70997D70-0DFF-4C39-B712-F916BFB04EDF@lodderstedt.net>
In-Reply-To: <70997D70-0DFF-4C39-B712-F916BFB04EDF@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.109]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9062FD2FD4D14144A315149A8F81FE09@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR 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: Wed, 08 Jan 2020 20:47:13 -0000

SSBhbG1vc3QgaW5jbHVkZWQgdGV4dCB0byB0aGF0IGVmZmVjdCwgYnV0IHRob3VnaHQgaXQgd2Fz
IGdldHRpbmcgdG9vIHdvcmR5LiBIb3dldmVyIHlvdXIgc3VnZ2VzdGlvbiBpcyBzaW1wbGUgYW5k
IGNvbmNpc2UuICsxDQoNCkdpdmVuIGFsbCBvZiB0aGlzIGRpc2N1c3Npb24sIHdlIHNob3VsZCBp
bmNsdWRlIGEgc2VjdGlvbiBvbiByZXF1ZXN0IHZhbGlkYXRpb24gaW4gU2VjdXJpdHkgQ29uc2lk
ZXJhdGlvbnMsIHRvIHByb3ZpZGUgc29tZSBjb250ZXh0IG9uIHdoYXQgbWlnaHQgYmUgdmFsaWRh
dGVkIHdoZW4gYW5kIHdoZXJlLCB3aGF0IGtpbmRzIG9mIHByb2JsZW1zIGRlcGxveW1lbnRzIG5l
ZWQgdG8gY29uc2lkZXIsIGV0Yy4gSSB0aGluayB0aGlzIGlzIHVzZWZ1bCB0byBoYXZlIGluIHRo
ZSBkb2N1bWVudCwgYnV0IHdvdWxkIGJlIHRvbyBtdWNoIGNsdXR0ZXIgaW4gdGhlIG1haW4gYm9k
eS4gV2Ugc2hvdWxkIGtlZXAgdGhhdCBmb2N1c2VkIG9uIHRoZSBwcmVjaXNlIG5vcm1hdGl2ZSBy
ZXF1aXJlbWVudHMuDQoNCuKAkyANCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVu
dGl0eQ0KIA0KDQrvu79PbiAxLzgvMjAsIDI6MTEgQU0sICJUb3JzdGVuIExvZGRlcnN0ZWR0IiA8
dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBI
aSBBbm5hYmVsbGUsIA0KICAgIA0KICAgIHRoYW5rcyBmb3IgeW91ciBwcm9wb3NhbCwgd2hpY2gg
cmVhZHMgcmVhc29uYWJsZSB0byBtZS4gDQogICAgDQogICAgSSBzdWdnZXN0IHRvIGV4dGVuZCDi
gJxhbmQgdGhhdCB0aGUgcmVxdWVzdCBoYXMgbm90IGJlZW4gbW9kaWZpZWQgaW4gYSB3YXkgdGhh
dCB3b3VsZCBhZmZlY3QgdGhlIG91dGNvbWUgb2YgdGhlIG9taXR0ZWQgc3RlcHMu4oCdIGEgYml0
IHRvIGFsc28gY29uc2lkZXIgcG9saWN5IGNoYW5nZXMgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZCBi
ZXR3ZWVuIHB1c2ggYW5kIGF1dGhvcml6YXRpb24gcmVxdWVzdCBwcm9jZXNzaW5nLiANCiAgICAN
CiAgICAiYW5kIHRoYXQgdGhlIHJlcXVlc3Qgb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy4oCZ
cyBwb2xpY3kgaGFzIG5vdCBiZWVuIG1vZGlmaWVkIGluIGEgd2F5IHRoYXQgd291bGQgYWZmZWN0
IHRoZSBvdXRjb21lIG9mIHRoZSBvbWl0dGVkIHN0ZXBzLiINCiAgICANCiAgICBiZXN0IHJlZ2Fy
ZHMsDQogICAgVG9yc3Rlbi4gDQogICAgDQogICAgPiBPbiA4LiBKYW4gMjAyMCwgYXQgMDM6MjUs
IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMu
aWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiBJIHRoaW5rIGl04oCZcyBjbGVhcmVyIGlm
IHdlIHNwbGl0IG91dCB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgUEFSIGVuZHBvaW50IGFuZCB0
aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgZ2l2ZW4gdGhh
dCB0aGV5IGFyZSBlYWNoIGNvdmVyZWQgaW4gZGlmZmVyZW50IHNlY3Rpb25zIG9mIHRoZSBkb2Mg
KDIgYW5kIDQsIHJlc3BlY3RpdmVseSkuIFdpdGggdGhhdCBpbiBtaW5kLCBoZXJlIGFyZSBhIGNv
dXBsZSBzdWdnZXN0aW9uczoNCiAgICA+ICANCiAgICA+IEZvciB0aGUgdGV4dCBpbiBTZWN0aW9u
IDIuMToNCiAgICA+ICANCiAgICA+IDMuICBUaGUgQVMgTVVTVCB2YWxpZGF0ZSB0aGUgcHVzaGVk
IHJlcXVlc3QgYXMgaXQgd291bGQgYW4gYXV0aG9yaXphdGlvbg0KICAgID4gDQogICAgPiAgICAg
cmVxdWVzdCBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBob3dldmVyIHRoZSBB
UyBNQVkgb21pdA0KICAgID4gDQogICAgPiAgICAgdmFsaWRhdGlvbiBzdGVwcyB0aGF0IGl0IGlz
IHVuYWJsZSB0byBwZXJmb3JtIHdoZW4gcHJvY2Vzc2luZyB0aGUNCiAgICA+IA0KICAgID4gICAg
IHB1c2hlZCByZXF1ZXN0Lg0KICAgID4gDQogICAgPiAgDQogICAgPiAgDQogICAgPiBBZGRpdGlv
bmFsIHRleHQgZm9yIFNlY3Rpb24gNCAobm90ZSB0aGF0IHRoaXMgc2VjdGlvbiBwZXJ0YWlucyB0
byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCk6DQogICAgPiAgDQogICAgPiBUaGUgQVMgTVVT
VCB2YWxpZGF0ZSBhdXRob3JpemF0aW9uIHJlcXVlc3RzIGFyaXNpbmcgZnJvbSBhIHB1c2hlZCBy
ZXF1ZXN0IGFzDQogICAgPiANCiAgICA+IGl0IHdvdWxkIGFueSBvdGhlciBhdXRob3JpemF0aW9u
IHJlcXVlc3QuICBUaGUgQVMgTUFZIG9taXQgdmFsaWRhdGlvbiBzdGVwcw0KICAgID4gDQogICAg
PiB0aGF0IGl0IHBlcmZvcm1lZCB3aGVuIHRoZSByZXF1ZXN0IHdhcyBwdXNoZWQsIHByb3ZpZGVk
IHRoYXQgaXQgY2FuIHZhbGlkYXRlDQogICAgPiANCiAgICA+IHRoYXQgdGhlIHJlcXVlc3Qgd2Fz
IGEgcHVzaGVkIHJlcXVlc3QsIGFuZCB0aGF0IHRoZSByZXF1ZXN0IGhhcyBub3QgYmVlbg0KICAg
ID4gDQogICAgPiBtb2RpZmllZCBpbiBhIHdheSB0aGF0IHdvdWxkIGFmZmVjdCB0aGUgb3V0Y29t
ZSBvZiB0aGUgb21pdHRlZCBzdGVwcy4NCiAgICA+IA0KICAgID4gIA0KICAgID4gIA0KICAgID4g
VGhpcyBpcyBsb25nZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0IGFuZCB0aGUgb3RoZXIgcHJvcG9z
YWxzLCBidXQgaXQgYWRkcyBhIGZldyBpbXBvcnRhbnQgcG9pbnRzOg0KICAgID4gCeKAoiBUdXJu
cyB0aGUgMi4xIFNIT1VMRCBiYWNrIGludG8gYSBNVVNULCB3aXRoIGFuIGV4cGxpY2l0IGV4Y2Vw
dGlvbiBmb3IgdmFsaWRhdGlvbiB0aGF0IGNhbuKAmXQgYmUgZG9uZSB5ZXQuDQogICAgPiAJ4oCi
IFJlaW5mb3JjZXMgdGhlIGZhY3QgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBzdGls
bCBuZWVkcyB0byBkbyB2YWxpZGF0aW9uLg0KICAgID4gCeKAoiBDbGVhcmx5IHN0YXRlcyByZXF1
aXJlbWVudHMgZm9yIHdoZW4gYW4gQVMgY2FuIHRydXN0IHRoYXQgdmFsaWRhdGlvbiBoYXBwZW5l
ZCBhdCB0aGUgUEFSIGVuZHBvaW50Lg0KICAgID4gIA0KICAgID4g4oCTIA0KICAgID4gQW5uYWJl
bGxlIFJpY2hhcmQgQmFja21hbg0KICAgID4gQVdTIElkZW50aXR5DQogICAgPiAgDQogICAgPiAg
DQogICAgPiBGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv
bUBkbWFyYy5pZXRmLm9yZz4NCiAgICA+IERhdGU6IFR1ZXNkYXksIEphbnVhcnkgNywgMjAyMCBh
dCAyOjU0IFBNDQogICAgPiBUbzogVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0
MmlkLmNvbT4NCiAgICA+IENjOiBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNvbT4sICJS
aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBEYXZlIFRv
bmdlIDxkYXZlLnRvbmdlQG1vbmV5aHViLmNvbT4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4sIE5h
dCBTYWtpbXVyYSA8bmF0QHNha2ltdXJhLm9yZz4NCiAgICA+IFN1YmplY3Q6IFtVTlZFUklGSUVE
IFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogUEFSIG1ldGFk
YXRhDQogICAgPiAgDQogICAgPiBBIGxpdHRsZSBtb3JlIGNvbnRleHQgYWJvdXQgdGhhdCBwcm9w
b3NlZCB3b3JkaW5nIGlzIGluIGEgZ2l0aHViIGlzc3VlIGF0DQogICAgPj4gDQogICAgPj4+PiAJ
4oCiDQogICAgPj4+PiAJ4oCiDQogICAgPj4+PiAJ4oCiDQogICAgPj4+PiAJ4oCiDQogICAgPj4+
PiAJ4oCiDQogICAgaHR0cHM6Ly9naXRodWIuY29tL29hdXRoc3R1ZmYvZHJhZnQtb2F1dGgtcGFy
L2lzc3Vlcy8zOCwgd2hpY2ggaXMgZGlmZmVyZW50IGRyaXZlciB0aGFuIGFsbG93aW5nIGEgUEFS
IGVuZHBvaW50IHRvIHN0YXNoIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3QgcmF0aGVyIHRo
YW4gZGVjcnlwdGluZy92YWxpZGF0aW5nIGl0LiBCdXQgaXQncyBraW5kIG9mIHRoZSBzYW1lIGNv
bmNlcHQgYXQgc29tZSBsZXZlbCB0b28gLSB0aGF0IHRoZXJlIGFyZSBzb21lIHRoaW5ncyB0aGF0
IGNhbid0IG9yIHdvbid0IGJlIHZhbGlkYXRlZCBhdCB0aGUgUEFSIGVuZHBvaW50IGFuZCB0aG9z
ZSB0aGVuIGhhdmUgdG8gYmUgdmFsaWRhdGVkIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50
Li4NCiAgICAgDQogICAgSSByYXRoZXIgbGlrZSB5b3VyIHN1Z2dlc3RlZCB0ZXh0LCBWbGFkaW1p
ciwgYW5kIGhhdmUgbWVudGlvbmVkIGl0IGluIGEgY29tbWVudCBvbiB0aGUgYWZvcmVtZW50aW9u
ZWQgaXNzdWUuDQogICAgIA0KICAgICANCiAgICBPbiBUdWUsIEphbiA3LCAyMDIwIGF0IDY6NTgg
QU0gVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4gd3JvdGU6DQog
ICAgT24gMDcvMDEvMjAyMCAwMDoyMiwgRmlsaXAgU2tva2FuIHdyb3RlOg0KICAgIFdlJ3ZlIGJl
ZW4gZGlzY3Vzc2luZyBtYWtpbmcgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIGxhbmd1YWdl
DQogICAgIA0KICAgIFRoZSBBUyBTSE9VTEQgdmFsaWRhdGUgdGhlIHJlcXVlc3QgaW4gdGhlIHNh
bWUgd2F5IGFzIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgQVMgTVVTVCBlbnN1
cmUgdGhhdCBhbGwgcGFyYW1ldGVycyB0byB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFyZSBz
dGlsbCB2YWxpZCBhdCB0aGUgdGltZSB3aGVuIHRoZSByZXF1ZXN0IFVSSSBpcyB1c2VkLg0KICAg
IENvdWxkIHlvdSBleHBhbmQgYSBiaXQgb24gdGhlIHNlY29uZCBzZW50ZW5jZT8NCiAgICBBbHRl
cm5hdGl2ZSBzdWdnZXN0aW9uOg0KICAgIFRoZSBBUyBNVVNUIHZhbGlkYXRlIHRoZSByZXF1ZXN0
IGluIHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgb3IgY29t
cGxldGUgdGhlIHJlcXVlc3QgdmFsaWRhdGlvbiBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu
dC4NCiAgICBWbGFkaW1pcg0KICAgICANCiAgICBUaGlzIHdvdWxkIGFsbG93IHRoZSBQQVIgZW5k
cG9pbnQgdG8gc2ltcGx5IHN0YXNoIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3QgaW5zdGVh
ZCBvZiBkZWNyeXB0aW5nIGFuZCB2YWxpZGF0aW5nIGl0LiBBbGwgd2l0aGluIHRoZSBib3VuZHMg
b2YgIlNIT1VMRCAtIFdl4oCZZCBsaWtlIHlvdSB0byBkbyB0aGlzLCBidXQgd2UgY2Fu4oCZdCBh
bHdheXMgcmVxdWlyZSBpdCIuIFRoaXMgc3VwcG9ydHMgImxpZ2h0IHdlaWdodCBQQVIiIGltcGxl
bWVudGF0aW9uIHJhdGhlciB0aGFuIGludHJvZHVjaW5nIHRoZSB1bm5lY2Vzc2FyeSBjb21wbGV4
aXR5IGluIHRoZSBmb3JtIG9mIGEgc2Vjb25kIEpXS1MuDQogICAgDQogICAgQmVzdCwNCiAgICBG
aWxpcA0KICAgICANCiAgICAgDQogICAgT24gTW9uLCA2IEphbiAyMDIwIGF0IDIzOjAwLCBSaWNo
YXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu
b3JnPiB3cm90ZToNCiAgICBUaGUgaXNzdWUgaXNu4oCZdCB0aGF0IHRoZSBQQVIgZW5kcG9pbnQg
bmVlZHMgYWNjZXNzIHRvIG9uZSBzcGVjaWZpYyByZXF1ZXN0IG9iamVjdCBkZWNyeXB0aW9uIGtl
eSB0aGF0IGNvdWxkIHJlYXNvbmFibHkgYmUgc2hhcmVkIGFjcm9zcyBBUyBlbmRwb2ludHMsIGJ1
dCB0aGF0IGl0IGFjdHVhbGx5IG5lZWRzIGFjY2VzcyB0byB0aGUgcHJpdmF0ZSBrZXlzIGZvciBh
bGwgZW5jcnlwdGlvbiBwdWJsaWMga2V5cyBpbiB0aGUgSldLIHNldCBwb2ludGVkIHRvIGJ5IHRo
ZSBBU+KAmXMgandrc191cmkgbWV0YWRhdGEgcHJvcGVydHkuIFNpbmNlIHRoZXJlIGlzIG5vIHdh
eSB0byBkZXNpZ25hdGUgb25lIHBhcnRpY3VsYXIga2V5IGFzIHRoZSBvbmUgdG8gdXNlIGZvciBl
bmNyeXB0aW5nIHJlcXVlc3Qgb2JqZWN0cywgY2xpZW50cyBtYXkgcmVhc29uYWJseSB1c2UgYW55
IGVuY3J5cHRpb24gcHVibGljIGtleSBpbiB0aGUgSldLIHNldCB0byBlbmNyeXB0IGEgcmVxdWVz
dCBvYmplY3QuIEFzIG9uZSBleGFtcGxlIG9mIGhvdyB0aGlzIGNvdWxkIGV4cG9zZSBzZW5zaXRp
dmUgZGF0YSB0byB0aGUgUEFSIGVuZHBvaW50LCBpZiB0aGUgUEFSIGVuZHBvaW50IGhhcyBhbGwg
dGhlIGRlY3J5cHRpb24ga2V5cyBmb3IgdGhlIGtleXMgaW4gdGhlIEFT4oCZcyBKV0sgc2V0LCBp
dCB3b3VsZCBiZSBhYmxlIHRvIGRlY3J5cHQgSUQgVG9rZW5zIHNlbnQgaW4gaWRfdG9rZW5faGlu
dCByZXF1ZXN0IHBhcmFtZXRlcnMuIEFzIG1vcmUgYW5kIG1vcmUgdXNlIGNhc2VzIGRldmVsb3Ag
Zm9yIGVuY3J5cHRpbmcgYmxvYnMgZm9yIHRoZSBBUywgdGhpcyBpc3N1ZSB3aWxsIG9ubHkgZ2V0
IHdvcnNlLg0KICAgIA0KICAgICANCiAgICANCiAgICBUaGUgUEFSIGVuZHBvaW50IGNhbuKAmXQg
c2ltcGx5IHN0YXNoIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3QsIGFzIGl0IGlzIHJlcXVp
cmVkIHRvIHZlcmlmeSB0aGUgcmVxdWVzdCwgYWNjb3JkaW5nIHRvIMKnMi4xOg0KICAgIA0KICAg
ICANCiAgICANCiAgICBUaGUgQVMgTVVTVCBwcm9jZXNzIHRoZSByZXF1ZXN0IGFzIGZvbGxvd3M6
DQogICAgIA0KICAgIC4uLi4uDQogICAgIA0KICAgIDMuICBUaGUgQVMgTVVTVCB2YWxpZGF0ZSB0
aGUgcmVxdWVzdCBpbiB0aGUgc2FtZSB3YXkgYXMgYXQgdGhlDQogICAgICAgICAgICAgIGF1dGhv
cml6YXRpb24gZW5kcG9pbnQuIC4uLg0KICAgICANCiAgICBUaGlzIGxhbmd1YWdlIG5lZWRzIHRv
IGJlIG1vcmUgZmxleGlibGUsIElNSE8sIHRvIGFsbG93IGZvciBsaWdodHdlaWdodCBQQVIgZW5k
cG9pbnRzIHRoYXQgbWF5IG5vdCBoYXZlIHRoZSBpbmZvcm1hdGlvbiBvciBhdXRob3JpdHkgbmVl
ZGVkIHRvIHBlcmZvcm0gYWxsIHRoZSB2YWxpZGF0aW9uIHRoYXQgaGFwcGVucyBhdCB0aGUgYXV0
aG9yaXphdGlvbiBlbmRwb2ludC4gSSBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgbW9yZSBiZWZv
cmUgSSBjYW4gc2F5IGlmIGl0IHdvdWxkIGFkZXF1YXRlbHkgYWRkcmVzcyBteSBjb25jZXJucywg
YnV0IGl04oCZZCBiZSBhIGdvb2Qgc3RhcnQgYW5kIG1ha2VzIHNlbnNlIGluIGl0cyBvd24gcmln
aHQuDQogICAgDQogICAgIA0KICAgIA0KICAgIEkgdGhpbmsgaXTigJlzIHByZXR0eSByaXNreSBm
b3IgdXMgdG8gYmFzZSBkZWNpc2lvbiBvbiBhbiBhc3N1bXB0aW9uIHRoYXQgbm8gb25lIGlzIGdv
aW5nIHRvIG5lZWQgb3Igd2FudCB0byBlbmNyeXB0IHB1c2hlZCByZXF1ZXN0IG9iamVjdHMsIHBh
cnRpY3VsYXJseSB3aGVuIHRoZXnigJlyZSBKV1RzLCBhbmQgSldUcyBoYXZlIHdlbGwgZXN0YWJs
aXNoZWQgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiwgYW5kIGVuY3J5cHRlZCBKV1RzIGFyZSBzdXBw
b3J0ZWQgYnkgcGFzcy1ieS12YWx1ZSBpbiBPSURDIGFuZCBkcmFmdC1pZXRmLW9hdXRoLWp3c3Jl
cS4gQnV0IGlmIHlvdSBpbnNpc3QsIGhlcmUgYXJlIGEgZmV3IGV4YW1wbGVzIGZvciB3aHkgc29t
ZW9uZSBtaWdodCB3YW50IHRvIGRvIHRoaXM6DQogICAgDQogICAgVGhlIHJlcXVlc3Qgb2JqZWN0
IGlzIHBhc3NlZCBieSByZWZlcmVuY2UsIGFuZCBhY2Nlc3NpYmxlIG9uIHRoZSBwdWJsaWMgSW50
ZXJuZXQuDQogICAgVGhlIHJlcXVlc3Qgb2JqZWN0IGNvbnRhaW5zIHNlbnNpdGl2ZSB0cmFuc2Fj
dGlvbi1yZWxhdGVkIGRhdGEgaW4gUkFSIHBhcmFtZXRlcnMgdGhhdCB0aGUgY2xpZW504oCZcyBh
dXRoTi9hdXRoWiBzdGFjayBkb2VzbuKAmXQgbmVlZCB0byBoYXZlIGFjY2VzcyB0by4NCiAgICBU
aGUgQVMgcmVxdWlyZXMgcmVxdWVzdCBvYmplY3QgZW5jcnlwdGlvbiB0byBtaW5pbWl6ZSBleHBv
c3VyZSB0byB0aGUgaG9zdGVkIFBBUiBlbmRwb2ludCBzZXJ2aWNlIGl0IHVzZXMuDQogICAgIzIs
IGJ1dCB0aGUgdGhyZWF0IHZlY3RvciBpcyBnYXBzIGluIGVuZC10by1lbmQgVExTLg0KICAgIEFu
eSBvZiB0aGUgYWJvdmUsIGJ1dCB0aGUgY29uY2VybiBpcyBtZXNzYWdlIGludGVncml0eSwgYW5k
IHRoZSBBUyByZXF1aXJlcyByZXF1ZXN0ZWQgb2JqZWN0cyB0byBiZSBlbmNyeXB0ZWQgZm9yIGNv
bmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGRvZXMgbm90IHN1cHBv
cnQgc2lnbmVkIHJlcXVlc3Qgb2JqZWN0cy4NCiAgICAgDQogICAgDQogICAg4oCTIA0KICAgIA0K
ICAgIEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCiAgICANCiAgICBBV1MgSWRlbnRpdHkNCiAg
ICANCiAgICAgDQogICAgDQogICAgIA0KICAgIA0KICAgIEZyb206IE5laWwgTWFkZGVuIDxuZWls
Lm1hZGRlbkBmb3JnZXJvY2suY29tPg0KICAgIERhdGU6IE1vbmRheSwgSmFudWFyeSA2LCAyMDIw
IGF0IDY6MjkgQU0NCiAgICBUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp
dHkuY29tPg0KICAgIENjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBh
bWF6b24uY29tPiwgTmF0IFNha2ltdXJhIDxuYXRAc2FraW11cmEub3JnPiwgRGF2ZSBUb25nZSA8
ZGF2ZS50b25nZUBtb25leWh1Yi5jb20+LCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxv
ZGRlcnN0ZWR0Li5uZXQ+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQogICAgU3ViamVjdDogW1VO
VkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBQQVIgbWV0YWRhdGENCiAgICANCiAgICAg
DQogICAgDQogICAgQWdyZWVkLg0KICAgIA0KICAgICANCiAgICANCiAgICBJbiBhZGRpdGlvbiwg
SSdtIG5vdCBzdXJlIHdoeSB0aGUgUEFSIGVuZHBvaW50IHdvdWxkIG5lZWQgYWNjZXNzIHRvIHRo
ZSBkZWNyeXB0aW9uIGtleXMgYXQgYWxsLiBJZiB5b3UncmUgdXNpbmcgZW5jcnlwdGVkIHJlcXVl
c3Qgb2JqZWN0cyB0aGVuIHRoZSBQQVIgZW5kcG9pbnQgcmVjZWl2ZXMgYW4gZW5jcnlwdGVkIEpX
VCBhbmQgdGhlbiBsYXRlciBtYWtlcyB0aGUgc2FtZSAoc3RpbGwgZW5jcnlwdGVkKSBKV1QgYXZh
aWxhYmxlIHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBJZiB0aGUgUEFSIGVuZHBvaW50
IGlzIGRvaW5nIGFueSBraW5kIG9mIGRlY3J5cHRpb24gb3IgdmFsaWRhdGlvbiBvbiBiZWhhbGYg
b2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdGhlbiB0aGV5IGFyZSBjbGVhcmx5IG5vdCBp
biBzZXBhcmF0ZSB0cnVzdCBib3VuZGFyaWVzLg0KICAgIA0KICAgICANCiAgICANCiAgICAtLSBO
ZWlsDQogICAgDQogICAgIA0KICAgIA0KICAgICANCiAgICANCiAgICBPbiA2IEphbiAyMDIwLCBh
dCAxMzo1NywgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h
cmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgIA0KICAgICANCiAgICANCiAgICBJIHJlYWxseSBzdHJ1
Z2dsZSB0byBzZWUgdGhlIGFzc3VtcHRpb24gdGhhdCBhbiBlbnRpdHkgYmUgYWJsZSB0byB1c2Ug
dGhlIHNhbWUga2V5IHRvIGRlY3J5cHQgdGhlIHNhbWUgdHlwZSBvZiBtZXNzYWdlIHVsdGltYXRl
bHkgaW50ZW5kZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UgYXMgYW4gYXJ0aWZpY2lhbCBsaW1pdC4g
VGhlIHNhbWUgZ2VuZXJhbCBhc3N1bXB0aW9uICAgdW5kZXJsaWVzIGV2ZXJ5dGhpbmcgZWxzZSBp
biBPQXV0aC9PSURDIChWbGFkaW1pcidzIHBvc3QgcG9pbnRzIHRvIHNvbWUgYnV0IG5vdCBhbGwg
ZXhhbXBsZXMgb2Ygc3VjaCkuIFRoZXJlJ3Mgbm8gcmVhc29uIGZvciBQQVIgdG8gbWFrZSBhIG9u
ZS1vZmYgZXhjZXB0aW9uLiBBbmQgc2hvdWxkIHRoZXJlIGJlIHNvbWUgZGVwbG95bWVudCBzcGVj
aWZpYyByZWFzb24gdGhhdCB0cnVseSByZXF1aXJlcyB0aGF0IGtpbmQgb2YgaXNvbGF0aW9uLCB0
aGVyZSBhcmUgY2VydGFpbmx5IGltcGxlbWVudGF0aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgY29t
cGF0aWJpbGl0eS1icmVha2luZy4gQW5kIGhhdmluZyBzYWlkIGFsbCB0aGF0LCBJJ20gaG9uZXN0
bHkgYSBsaXR0bGUgc3VycHJpc2VkIGFueW9uZSBpcyB0aGlua2luZyBtdWNoIGFib3V0IGVuY3J5
cHRlZCByZXF1ZXN0IG9iamVjdHMgd2l0aCBQQVIgYXMsIGF0IGxlYXN0IHdpdGggbXkgbGltaXRl
ZCBpbWFnaW5hdGlvbiwgdGhlcmUncyBub3QgcmVhbGx5IGEgbmVlZCBmb3IgaXQuDQogICAgDQog
ICAgIA0KICAgIA0KICAgICANCiAgICANCiAgICAgDQogICAgDQogICAgIA0KICAgIA0KICAgICAN
CiAgICANCiAgICAgDQogICAgDQogICAgIA0KICAgIA0KICAgICANCiAgICANCiAgICBPbiBGcmks
IEphbiAzLCAyMDIwIGF0IDI6NDMgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hh
bm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgDQogICAgUEFSIGlu
dHJvZHVjZXMgYW4gYWRkZWQgd3JpbmtsZSBmb3IgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0czog
dGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBtYXkgbm90IGhhdmUg
YWNjZXNzIHRvIHRoZSBzYW1lIGNyeXB0b2dyYXBoaWMga2V5cywgZXZlbiB0aG91Z2ggdGhleSdy
ZSBib3RoIHBhcnQgb2YgdGhlICJhdXRob3JpemF0aW9uIHNlcnZlci4iIFNpbmNlIHRoZXkncmUg
ZGlmZmVyZW50IGVuZHBvaW50cyB3aXRoIGRpZmZlcmVudCByb2xlcywgaXQncyByZWFzb25hYmxl
IHRvIHB1dCB0aGVtIGluIHNlcGFyYXRlIHRydXN0IGJvdW5kYXJpZXMuIFRoZXJlIGlzIG5vIHdh
eSB0byBzdXBwb3J0IHRoaXMgaXNvbGF0aW9uIHdpdGgganVzdCBhIHNpbmdsZSAiandrc191cmki
IG1ldGFkYXRhIHByb3BlcnR5Lg0KICAgIA0KICAgIFRoZSB0d28gb3B0aW9ucyB0aGF0IEkgc2Vl
IGFyZToNCiAgICANCiAgICAxLiBEZWZpbmUgYSBuZXcgcGFyX2p3a3NfdXJpIG1ldGFkYXRhIHBy
b3BlcnR5Lg0KICAgIDIuIEV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGlzIHNlcGFyYXRpb24gaXMg
bm90IHN1cHBvcnRlZC4NCiAgICANCiAgICBJIHN0cm9uZ2x5IHBlcmZlciAjMSBhcyBpdCBoYXMg
YSB2ZXJ5IG1pbm9yIGltcGFjdCBvbiBkZXBsb3ltZW50cyB0aGF0IGRvbid0IGNhcmUgKGkuZS4s
IHRoZXkganVzdCBzZXQgcGFyX2p3a3NfdXJpIGFuZCBqd2tzX3VyaSB0byB0aGUgc2FtZSB2YWx1
ZSkgYW5kIGZhaWxpbmcgdG8gc3VwcG9ydCB0aGlzIHRydXN0IGJvdW5kYXJ5IGNyZWF0ZXMgYW4g
YXJ0aWZpY2lhbCBsaW1pdCBvbiBpbXBsZW1lbnRhdGlvbiBhcmNoaXRlY3R1cmUgYW5kIGNvdWxk
IGxlYWQgdG8gY29tcGF0aWJpbGl0eS1icmVha2luZyB3b3JrYXJvdW5kcy4NCiAgICANCiAgICDi
gJMgDQogICAgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KICAgIEFXUyBJZGVudGl0eQ0KICAg
IA0KICAgIA0KICAgIE9uIDEyLzMxLzE5LCA4OjA3IEFNLCAiT0F1dGggb24gYmVoYWxmIG9mIFRv
cnN0ZW4gTG9kZGVyc3RlZHQiIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0
b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICANCiAg
ICAgICAgSGkgRmlsaXAsIA0KICAgIA0KICAgICAgICA+IE9uIDMxLiBEZWMgMjAxOSwgYXQgMTY6
MjIsIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPiB3cm90ZToNCiAgICAgICAgPiAN
CiAgICAgICAgPiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgYSAqX2F1dGhfbWV0aG9kXyogbWV0YWRh
dGEgZm9yIGV2ZXJ5IGVuZHBvaW50IHRoZSBjbGllbnQgY2FsbHMgZGlyZWN0bHksIG5vbmUgb2Yg
dGhlIG5ldyBzcGVjcyBkZWZpbmVkIHRoZXNlIChlLmcuIGRldmljZSBhdXRob3JpemF0aW9uIGVu
ZHBvaW50IG9yIENJQkEpLCBtZWFuaW5nIHRoZXkgYWxzbyBkaWRuJ3QgZm9sbG93IHRoZSBzY2hl
bWUgZnJvbSBSRkMgODQxNCB3aGVyZSBpbnRyb3NwZWN0aW9uIGFuZCByZXZvY2F0aW9uIGdvdCBp
dHMgb3duIG1ldGFkYXRhLiBJbiBtb3N0IGNhc2VzIHRoZSB1bmZvcnR1bmF0ZWx5IG5hbWVkIGB0
b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZGAgYW5kIGl0cyByZWxhdGVkIG1ldGFkYXRhIGlzIHdo
YXQncyB1c2VkIGJ5IGNsaWVudHMgZm9yIGFsbCBkaXJlY3QgY2FsbHMgYW55d2F5Lg0KICAgICAg
ICA+IA0KICAgICAgICA+IFRoZSBzYW1lIHByaW5jaXBsZSBjb3VsZCBiZSBhcHBsaWVkIHRvIHNp
Z25pbmcgKGFuZCBlbmNyeXB0aW9uKSBhbGdvcml0aG1zIGFzIHdlbGwuDQogICAgICAgID4gDQog
ICAgICAgID4gVGhpcyBJIGRvIG5vdCBmb2xsb3csIGF1dGggbWV0aG9kcyBhbmQgdGhlaXIgc2ln
bmluZyBpcyBkZWFsdCB3aXRoIGJ5IHVzaW5nIGB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNf
c3VwcG9ydGVkYCBhbmQgYHRva2VuX2VuZHBvaW50X2F1dGhfc2lnbmluZ19hbGdfdmFsdWVzX3N1
cHBvcnRlZGAgLSB0aGVyZSdzIG5vIGVuY3J5cHRpb24gZm9yIHRoZSBgX2p3dGAgY2xpZW50IGF1
dGggbWV0aG9kcy4gDQogICAgICAgID4gVW5sZXNzIGl0IHdhcyBtZWFudCB0byBhZGRyZXNzIHRo
ZSBSZXF1ZXN0IE9iamVjdCBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIG1ldGFkYXRhLCB3aGljaCBp
cyBkZWZpbmVkIGFuZCBJQU5BIHJlZ2lzdGVyZWQgYnkgT0lEQy4gUEFSIG9ubHkgcmVmZXJlbmNl
cyBKQVIgc2VjdGlvbiA2LjEgYW5kIDYuMiBmb3IgZGVjcnlwdGlvbi9zaWduYXR1cmUgdmFsaWRh
dGlvbiBhbmQgdGhlc2UgZG8gbm90IG1lbnRpb24gdGhlIG1ldGFkYXRhIChlLmcuIHJlcXVlc3Rf
b2JqZWN0X3NpZ25pbmdfYWxnKSBhbnltb3JlIHNpbmNlIGRyYWZ0IDA3Lg0KICAgIA0KICAgICAg
ICBEYW1tZWQhIFlvdSBhcmUgc28gcmlnaHQuIFNvcnJ5LCBJIGdvdCBjb25mdXNlZCBzb21laG93
LiANCiAgICANCiAgICAgICAgPiANCiAgICAgICAgPiBQUzogSSBhbHNvIGZvdW5kIHRoaXMgY29t
bWVudCByZWxhdGVkIHRvIHRoZSBzYW1lIHF1ZXN0aW9uIGFib3V0IGF1dGggbWV0YWRhdGEgYnV0
IGZvciBDSUJBLg0KICAgIA0KICAgICAgICBUaGFua3MgZm9yIHNoYXJpbmcuIA0KICAgIA0KICAg
ICAgICA+IA0KICAgICAgICA+IEJlc3QsDQogICAgICAgID4gRmlsaXANCiAgICANCiAgICAgICAg
dGhhbmtzLA0KICAgICAgICBUb3JzdGVuLiANCiAgICANCiAgICAgICAgPiANCiAgICAgICAgPiAN
CiAgICAgICAgPiBPbiBUdWUsIDMxIERlYyAyMDE5IGF0IDE1OjM4LCBUb3JzdGVuIExvZGRlcnN0
ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQogICAgICAgID4gSGkgYWxsLA0K
ICAgICAgICA+IA0KICAgICAgICA+IFJvbmFsZCBqdXN0IHNlbnQgbWUgYW4gZW1haWwgYXNraW5n
IHdoZXRoZXIgd2Ugd2lsbCBkZWZpbmUgbWV0YWRhdGEgZm9yIA0KICAgICAgICA+IA0KICAgICAg
ICA+IHB1c2hlZF9hdXRob3JpemF0aW9uX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQg
YW5kDQogICAgICAgID4gcHVzaGVkX2F1dGhvcml6YXRpb25fZW5kcG9pbnRfYXV0aF9zaWduaW5n
X2FsZ192YWx1ZXNfc3VwcG9ydGVkLg0KICAgICAgICA+IA0KICAgICAgICA+IFRoZSBkcmFmdCBy
aWdodCBub3cgdXRpbGlzZXMgdGhlIGV4aXN0aW5nIHRva2VuIGVuZHBvaW50IGF1dGhlbnRpY2F0
aW9uIG1ldGhvZHMgc28gdGhlcmUgaXMgYmFzaWNhbGx5IG5vIG5lZWQgdG8gZGVmaW5lIGFub3Ro
ZXIgcGFyYW1ldGVyLiBUaGUgc2FtZSBwcmluY2lwbGUgY291bGQgYmUgYXBwbGllZCB0byBzaWdu
aW5nIChhbmQgZW5jcnlwdGlvbikgYWxnb3JpdGhtcyBhcyB3ZWxsLiANCiAgICAgICAgPiANCiAg
ICAgICAgPiBXaGF04oCZcyB5b3VyIG9waW5pb24/DQogICAgICAgID4gDQogICAgICAgID4gYmVz
dCByZWdhcmRzLA0KICAgICAgICA+IFRvcnN0ZW4uDQogICAgDQogICAgDQogICAgDQogICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBPQXV0aCBt
YWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICANCiAgICAgDQogICAgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxpc3QN
CiAgICBPQXV0aEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCiAgICANCiAgICBDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls
IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl
IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg
ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0
ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw
bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg
dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g
VGhhbmsgeW91Lg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQogICAgT0F1dGggbWFpbGluZyBsaXN0DQogICAgT0F1dGhAaWV0Zi5vcmcNCiAgICBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgDQogICAgDQoN
Cg==


From nobody Wed Jan  8 14:42: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 24DA712010C for ; Wed,  8 Jan 2020 14:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.799
X-Spam-Level: 
X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omnoIvD4t9rh for ; Wed,  8 Jan 2020 14:42:09 -0800 (PST)
Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28081200C7 for ; Wed,  8 Jan 2020 14:42:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578523329; x=1610059329; h=from:to:subject:date:message-id:mime-version; bh=bWCDw4S2CxJtRHwWnFuTpAQNWtLdv/3bhc5r9LCXjjk=; b=aAJuxc8D360sVPZu1iscG22vzLErmOfUHadn6dUmAas3iaOH+GLkvWFL KnS+YW78dulIqe7l2wLKYk7BFs1u6IBoSr2oOVZ8f+eQs1GS/ntc9Ty52 Eq94FhWVN+wVnkxFXhIgk3zIvHpG/a+uX3+eLVTUO7lh47xC1oZDVdLW7 Y=;
IronPort-SDR: BDBqJ2nDr36plgMe/ILs0NeEzuYZzxVnTPZWBo2LNAqXfBX83Kc6s4JfOZmORIRgbpTSV0CPgq +BFYY7NkKNWw==
X-IronPort-AV: E=Sophos; i="5.69,411,1571702400"; d="scan'208,217"; a="10676100"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-2225282c.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 08 Jan 2020 22:42:07 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-2225282c.us-west-2.amazon.com (Postfix) with ESMTPS id C2388A2592 for ; Wed,  8 Jan 2020 22:42:06 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 22:42:06 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 22:42:06 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 22:42:06 +0000
From: "Richard Backman, Annabelle" 
To: oauth 
Thread-Topic: pushed requests must become JWTs
Thread-Index: AQHVxnTaORGbHwf5mEa8/ZfGf3dw2Q==
Date: Wed, 8 Jan 2020 22:42:06 +0000
Message-ID: <5F125471-39B2-4CF9-B5C0-353E83BC8702@amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.18]
Content-Type: multipart/alternative; boundary="_000_5F12547139B24CF9B5C0353E83BC8702amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 22:42:11 -0000

--_000_5F12547139B24CF9B5C0353E83BC8702amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpUaGUgY3VycmVudCBkcmFmdHMgb2YgUEFSICgtMDApIGFuZCBKQVIgKC0yMCkg
cmVxdWlyZSB0aGF0IHRoZSBBUyB0cmFuc2Zvcm0gYWxsIHB1c2hlZCByZXF1ZXN0cyBpbnRvIEpX
VHMuIFRoaXMgcmVxdWlyZW1lbnQgYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZzoNCg0KICAxLiAg
UEFSIHVzZXMgdGhlIHJlcXVlc3RfdXJpIHBhcmFtZXRlciBkZWZpbmVkIGluIEpBUiB0byBjb21t
dW5pY2F0ZSB0aGUgcHVzaGVkIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQu
DQogIDIuICBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1
ZXN0X3VyaSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMjxodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjAjc2VjdGlvbi01LjI+
KQ0KICAzLiAgUmVxdWVzdCBPYmplY3QgaXMgZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5n
IGFsbCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMTxo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjAjc2Vj
dGlvbi0yLjE+KQ0KDQpUaGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1
cHBvcnQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0
IGlzIGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMg
YXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGludGVybmFsIGNvbW11bmljYXRpb25zIGJldHdlZW4g
dGhlIHR3byBBUyBlbmRwb2ludHMuIFdvcnNlLCB0aGlzIHJlc3RyaWN0aW9uIG1ha2VzIGl0IGhh
cmRlciBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gbGV2ZXJhZ2UgdmFsaWRhdGlv
biBhbmQgb3RoZXIgd29yayBwZXJmb3JtZWQgYXQgdGhlIFBBUiBlbmRwb2ludCwgYXMgdGhlIHN0
YXRlIG9yIG91dGNvbWUgb2YgdGhhdCB3b3JrIG11c3QgYmUgZm9yY2VkIGludG8gdGhlIEpXVCBm
b3JtYXQgKG9yIHJldHJpZXZlZCB2aWEgYSBzdWJzZXF1ZW50IHNlcnZpY2UgY2FsbCBvciBkYXRh
YmFzZSBsb29rdXApLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVu
dGl0eQ0KDQo=

--_000_5F12547139B24CF9B5C0353E83BC8702amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <118C78A257B1E44FA9649A9057BA18EF@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg
MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN
YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo
LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt
cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn
aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx
LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs
MA0KCXttc28tbGlzdC1pZDoxMDUwNjEwNzEzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z
by1saXN0LXRlbXBsYXRlLWlkczotMTA3MTEwNDA4OCAyMDAxNDczNTU2IDY3Njk4NjkxIDY3Njk4
NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz
O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hc2Np
aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBNaW5j
aG8iOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu
O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND
MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBhbGwsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgY3VycmVudCBkcmFmdHMg
b2YgUEFSICgtMDApIGFuZCBKQVIgKC0yMCkgcmVxdWlyZSB0aGF0IHRoZSBBUyB0cmFuc2Zvcm0g
YWxsIHB1c2hlZCByZXF1ZXN0cyBpbnRvIEpXVHMuIFRoaXMgcmVxdWlyZW1lbnQgYXJpc2VzIGZy
b20gdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdp
bi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh
cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QQVIgdXNlcyB0aGUgcmVxdWVzdF91cmkgcGFyYW1l
dGVyIGRlZmluZWQgaW4gSkFSIHRvIGNvbW11bmljYXRlIHRoZSBwdXNoZWQgcmVxdWVzdCB0byB0
aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz
cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFjY29yZGluZyB0byBK
QVIsIHRoZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHJlcXVlc3RfdXJpIE1VU1QgYmUgYSBSZXF1
ZXN0IE9iamVjdC4gKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLW9hdXRoLWp3c3JlcS0yMCNzZWN0aW9uLTUuMiI+U2VjdGlvbg0KIDUuMjwvYT4pPG86cD48
L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn
aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5SZXF1ZXN0IE9iamVjdCBpcyBkZWZpbmVkIHRvIGJlIGEgSldUIGNvbnRhaW5p
bmcgYWxsIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gKDxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMCNzZWN0
aW9uLTIuMSI+U2VjdGlvbg0KIDIuMTwvYT4pPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5UaGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50
IHRvIHN1cHBvcnQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUg
QVMuIEl0IGlzIGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBh
dm9pZHMgYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGludGVybmFsIGNvbW11bmljYXRpb25zDQog
YmV0d2VlbiB0aGUgdHdvIEFTIGVuZHBvaW50cy4gV29yc2UsIHRoaXMgcmVzdHJpY3Rpb24gbWFr
ZXMgaXQgaGFyZGVyIGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBsZXZlcmFnZSB2
YWxpZGF0aW9uIGFuZCBvdGhlciB3b3JrIHBlcmZvcm1lZCBhdCB0aGUgUEFSIGVuZHBvaW50LCBh
cyB0aGUgc3RhdGUgb3Igb3V0Y29tZSBvZiB0aGF0IHdvcmsgbXVzdCBiZSBmb3JjZWQgaW50byB0
aGUgSldUIGZvcm1hdCAob3IgcmV0cmlldmVkDQogdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNh
bGwgb3IgZGF0YWJhc2UgbG9va3VwKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCTJm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_5F12547139B24CF9B5C0353E83BC8702amazoncom_--


From nobody Wed Jan  8 14:50: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 E4D6312010C for ; Wed,  8 Jan 2020 14:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 fCMsVhtMrNht for ; Wed,  8 Jan 2020 14:50:22 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC68120072 for ; Wed,  8 Jan 2020 14:50:22 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id p17so710757wmb.0 for ; Wed, 08 Jan 2020 14:50:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=c2GD3INB5d7vOQ+CpCaDWGS0hO2W3ALgclc7Qh1rN9c=; b=g94jkKp/CW1/RGYYhM04kN5B/FKMiAjX3mmr/jGFwziMueNfFfL4Qj/B47SnjYBJjU a/RyCsZTC4+vIxYIC2jUxMYJdvyQWGNet6zReHK9VPQt0aqOzWBydXQENSSxAOom4NuE U2AMKsWdR4vnt8AkPihu4cOtba55DC35ZUqCCw8OpBVHv2xcCF1Dkr4/t09FBOFNVJeV 6ypE1WGhPUdlKepxAIDLlQLQH4KdfCcUDGMeqxrj+mBq5qySRvICKg8ux0Kl90VJ/YNy VINsIOGBs3X57wv+AbA6NS+coJfrCDRFct96SJmOLbQflJix66lEZnkSP/IX41zFiP4e ftTA==
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=c2GD3INB5d7vOQ+CpCaDWGS0hO2W3ALgclc7Qh1rN9c=; b=D2StKDj2dQAJ+eVv1NgZMH+1e7LLxJk1nQWgaaf4u2LStyJ/ezvdsg4CKjAoDXzgGa YlNAxLwRrh4Ba5AZoS8ROIu4FZKAoVUMbeG9qkT+CsH5KbdrlwH+7/mJDBpBKWYMvwyY 5ImxkqkAgPcJm45h0VTsLNFZ7KbBkOH3RFF3scVYw9FB8Du4B9l3H+Qm1sm+34/UsUa+ oCyzlIPCvDD8cPTE3mp8kTsCqOu1wpllqSWNiH9BGzcZUXEIU3j3l1DS5umx/dgZmOnh eKO4L0kbCEtLhvBQTz0z1zvopGb383VxQ1hE7yG6zFI4S/rVSuXfqPOj7eK2O1VAQk4S 2lMw==
X-Gm-Message-State: APjAAAW7Kl7hwrBQ9/yG1/hQaOwwWqYumYwNaM6M69Y6Z9AYqWKD6NN7 jebrtb1J0vzMYV9cyshO8sxoJA==
X-Google-Smtp-Source: APXvYqzuemxV08nqxgKodCk+Wehq/pqpci6hvIimkjItpBaU1EqKqzrL8L5+zfNBt+awEYX7z343lQ==
X-Received: by 2002:a1c:ded6:: with SMTP id v205mr972588wmg.86.1578523820261;  Wed, 08 Jan 2020 14:50:20 -0800 (PST)
Received: from [10.30.4.222] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id m7sm5888075wrr.40.2020.01.08.14.50.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 14:50:19 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_8EFABC67-6C97-454D-B03B-C2EB264963A4"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Wed, 8 Jan 2020 23:49:26 +0100
In-Reply-To: <5F125471-39B2-4CF9-B5C0-353E83BC8702@amazon.com>
Cc: oauth 
To: "Richard Backman, Annabelle" 
References: <5F125471-39B2-4CF9-B5C0-353E83BC8702@amazon.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 22:50:25 -0000

--Apple-Mail=_8EFABC67-6C97-454D-B03B-C2EB264963A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,=20

you are right, PAR does not require the AS to represent the request as a =
JWT-based request object. The URI is used as internal reference only. =
That why the draft states=20

"There is no need to make the
      authorization request data available to other parties via this
      URI.=E2=80=9D

This difference matters from an AS implementation perspective, it =
doesn't matter from a client's (interop) perspective.

We may add a statement to PAR saying that request_uris issued by the PAR =
mechanism (MAY) deviate from the JAR definition.=20

best regards,
Torsten. =20

> On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
 wrote:
>=20
> Hi all,
> =20
> The current drafts of PAR (-00) and JAR (-20) require that the AS =
transform all pushed requests into JWTs. This requirement arises from =
the following:
> 	=E2=80=A2 PAR uses the request_uri parameter defined in JAR to =
communicate the pushed request to the authorization endpoint.
> 	=E2=80=A2 According to JAR, the resource referenced by =
request_uri MUST be a Request Object. (Section 5.2)
> 	=E2=80=A2 Request Object is defined to be a JWT containing all =
the authorization request parameters. (Section 2.1)
> =20
> There is no need for this requirement to support interoperability, as =
this is internal to the AS. It is also inconsistent with the rest of =
JAR, which avoids attempting to define the internal communications =
between the two AS endpoints. Worse, this restriction makes it harder =
for the authorization endpoint to leverage validation and other work =
performed at the PAR endpoint, as the state or outcome of that work must =
be forced into the JWT format (or retrieved via a subsequent service =
call or database lookup).
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_8EFABC67-6C97-454D-B03B-C2EB264963A4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMDgyMjQ5MjZaMC8GCSqGSIb3DQEJBDEiBCCZSL9xHgJ2KdfsKQB3qWVMHRTTToXZ5emB
crlBdSu6nzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBACPPA5zD2lnymwFE9RNVgg6uLNZFnkM6EctebOX0N/QEtblpTvn+4nUsVuVY
wzgmmd1km55OgHgCoIeqKpkmU0Fm4JAl/oM/o+DhjGeaWOj9ZO1gx161lCMpswlhzVuwLXtJ8pY2
DlTDw3AXofXt6B1l1XWi8xY4KLcJm0GTVAZ01Ncg/H7QJC1Rc8BKSGzEBVQTKi8Urv7Vx6MsFVWr
Wm5f4FEOh2c9VD/23zGHUSeCvJ3+yRFZRUy5JDnVZQpnJU1MCLro7SVuYM35UitrVyyIR0zM/MT2
E2VLf4JLWHM9xxjKdTl1+NRIF7Ydv6AYzGyYw+eQMaI31+aZ5f/ACT8AAAAAAAA=
--Apple-Mail=_8EFABC67-6C97-454D-B03B-C2EB264963A4--


From nobody Wed Jan  8 15:47:33 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 B2275120142 for ; Wed,  8 Jan 2020 15:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpqwifKEIT2n for ; Wed,  8 Jan 2020 15:47:30 -0800 (PST)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3F3120124 for ; Wed,  8 Jan 2020 15:47:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578527251; x=1610063251; h=from:to:subject:date:message-id:mime-version; bh=DfDM2NwdDTqWdJgKDkR70LsZWnIVzEyWLhdS1ZB9oSA=; b=PsXg/bWOa0CIaq8EMzTCRTA6ahO5HJJBIuOTTnFmBd1F2ksoB09tsHKj ZC9r1VYWlOU6GAZTv5eF16wi47b0A8Emdvkj3FwsMvNi5HJoEH1hv9PVX VZ1vWcRgvLAyZZTOiHzZv+51UX4LE04t3SXCMtKXx4hjCw8G6Z+ErxAvd Q=;
IronPort-SDR: 6FWFMMeNNFJdH09ReYvAQiY0hrXcgbEw0awB5iISLGJtbibsQT+StLoFKRatqHmyM2gx53KT9y Ud7zjK2oPE7Q==
X-IronPort-AV: E=Sophos; i="5.69,411,1571702400"; d="scan'208,217"; a="17581567"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 08 Jan 2020 23:47:19 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS id 85205A26BF for ; Wed,  8 Jan 2020 23:47:18 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:47:17 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:47:17 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 23:47:17 +0000
From: "Richard Backman, Annabelle" 
To: oauth 
Thread-Topic: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVxn32ZMKwQrnvkUO4GZSyw84VLg==
Date: Wed, 8 Jan 2020 23:47:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.16]
Content-Type: multipart/alternative; boundary="_000_A936D8D0D8D74B58AFF0AE16E4C7A660amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 23:47:33 -0000

--_000_A936D8D0D8D74B58AFF0AE16E4C7A660amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhpcyBpc3N1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUg
UEFSIGRyYWZ0LCBidXQgc2luY2UgaXQgYnJvYWRseSBhcHBsaWVzIHRvIHRoZSBPQXV0aCBzcGFj
ZSBJ4oCZbSBzdGFydGluZyBhIG5ldyB0aHJlYWTigKYNCg0KU2VjdGlvbiAzLjEyIG9mIHRoZSBK
V1QgQkNQPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1i
Y3AtMDcjc2VjdGlvbi0zLjEyPiBzYXlzOiDigJxVc2UgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZl
cmVudCBraW5kcyBvZiBKV1RzLuKAnSBTZWN0aW9uIDQgb2YgdGhlIEpXVCBQcm9maWxlIGZvciBP
QXV0aCAyLjAgQWNjZXNzIFRva2VuczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3NlY3Rpb24tND4gc2F5czog4oCcQW4gYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGVsZWN0IHRvIHVzZSBkaWZmZXJlbnQga2V5cyB0byBzaWdu
IGlkX3Rva2VucyBhbmQgSldUIGFjY2VzcyB0b2tlbnMu4oCdIFRoZXNlIHN0YXRlbWVudHMgYXJl
IGNvbnNpc3RlbnQgd2l0aCBnb29kIGNyeXB0b2dyYXBoaWMgaHlnaWVuZS4gQW5kIHdl4oCZdmUg
bWFkZSBpdCBkaWZmaWN1bHQgdG8gaW1wb3NzaWJsZSBmb3IgYW4gQVMgdG8gZm9sbG93IHRoZW0u
DQoNClRoZSBBUyBoYXMgYSBzaW5nbGUgbWV0YWRhdGEgZG9jdW1lbnQgY29udGFpbmluZyBhIHNp
bmdsZSBVUkkgcmVmZXJlbmNpbmcgYSBzaW5nbGUgSldLIFNldC4gQnV0IHRoZSBBUyBoYXMgbm8g
d2F5IG9mIGluZGljYXRpbmcgdG8gY2xpZW50cyB3aGljaCBrZXlzIHRvIHVzZSBmb3Igd2hpY2gg
cHVycG9zZXMuIEZvciBleGFtcGxlLCBhbiBBUyBjYW5ub3Qgc2F5IHRoYXQgKm9ubHkgdGhlc2Uq
IGtleXMgYXJlIHRvIGJlIHVzZWQgdG8gZW5jcnlwdCBpZF90b2tlbl9oaW50IEpXVHMsIGFuZCAq
b25seSB0aGVzZSoga2V5cyBhcmUgdG8gYmUgdXNlZCB0byBlbmNyeXB0IEpBUiByZXF1ZXN0IG9i
amVjdCBKV1RzLiBGb3IgZW5jcnlwdGlvbiwgdGhlIEFTIGNvdWxkIGVuZm9yY2UgdGhhdCBsb2dp
YyBpbnRlcm5hbGx5LCBidXQgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgY2xpZW50IHRvIGRpc2Nv
dmVyIHRoaXMuIEFuZCB3aGlsZSB0aGUgQVMgbWF5IGJlIGJ1aWx0IHRvIG9ubHkgdXNlIGNlcnRh
aW4ga2V5cyBmb3Igc2lnbmluZyBJRCBUb2tlbnMgYW5kIG90aGVyIGtleXMgZm9yIHNpZ25pbmcg
SldUIGFjY2VzcyB0b2tlbnMsIGl0IGhhcyBubyB3YXkgdG8gaW5kaWNhdGUgdGhpcyB0byB0aGUg
Y2xpZW50LiBTbyBldmVuIGlmIElEIFRva2VuIGdlbmVyYXRpb24gYW5kIGFjY2VzcyB0b2tlbiBn
ZW5lcmF0aW9uIGFyZSBpc29sYXRlZCBpbiBkaWZmZXJlbnQgbWljcm9zZXJ2aWNlcyB3aXRoaW4g
dGhlIEFTLCBlYWNoIG1pY3Jvc2VydmljZSBpcyBjYXBhYmxlIG9mIGZvcmdpbmcgdGhlIG90aGVy
4oCZcyB0b2tlbnMsIGJlY2F1c2UgY29uc3VtZXJzIGNhbuKAmXQgYmUgdG9sZCB0byBkaXN0aW5n
dWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBrZXlzIGZvciB0aGUgQVMuDQoNClRoaXMgc2VlbXMgbGlr
ZSBhIHRpY2tpbmcgdGltZSBib21iIHRvIG1lLCBhcyBpdOKAmXMgYSBub24tb2J2aW91cyBzaWRl
IGVmZmVjdCBvZiBjb21iaW5pbmcgdmFyaW91cyBPQXV0aCAyLjAgZXh0ZW5zaW9ucywgYW5kIGl0
IGNhbiB1bmRlcm1pbmUgYSBsb3Qgb2Ygc29waGlzdGljYXRlZCBlZmZvcnQgdG8gZm9sbG93IHNl
Y3VyaXR5IGJlc3QgcHJhY3RpY2VzLiBJIGNhbiBzZWUgYSBjb3VwbGUgb2Ygd2F5cyB0byBhZGRy
ZXNzIHRoaXMgKGUuZy4sIG1vcmUgc29waGlzdGljYXRlZCBBUyBrZXkgbWV0YWRhdGEsIHRhZ2dp
bmcgb3Igc2ltaWxhciB1c2UgY2FzZSBpbmRpY2F0aW9uIG9uIEpXS3MpLCBidXQgYmVmb3JlIHRy
eWluZyB0byBwcm9wb3NlIHNvbWV0aGluZyBJ4oCZZCBsaWtlIHRvIGdldCBwZW9wbGXigJlzIG9w
aW5pb25zIG9uIHRoZSBwcm9ibGVtLiBJcyB0aGlzIGFscmVhZHkgbWl0aWdhdGVkIGluIG90aGVy
IHdheXM/IEhhcyB0aGUgc2hpcCBzYWlsZWQgb24gdGhpcyBmb3IgT0F1dGgsIGFuZCBub3cgd2Ug
aGF2ZSB0byBsaXZlIHdpdGggaXQ/IFNob3VsZCB0aGlzIGJlIGxlZnQgdG8gdGhlIGRlcGxveW1l
bnRzIHRoYXQgY2FyZSB0byBzb2x2ZSB3aXRoIG5vbi1pbnRlcm9wZXJhYmxlIHNvbHV0aW9ucz8g
QXJlIHRoZXJlIG90aGVyIGNsZXZlciB3YXlzIHdlIGNvdWxkIGFwcHJvYWNoIHRoaXM/IEFyZSB0
aGVyZSBvdGhlciBhbmdsZXMgdGhhdCB3ZSBuZWVkIHRvIGNvbnNpZGVyPw0KDQrigJMNCkFubmFi
ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQo=

--_000_A936D8D0D8D74B58AFF0AE16E4C7A660amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz
QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBvcmlnaW5hbGx5
IGJyb3VnaHQgdXAgdGhpcyBpc3N1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgUEFSIGRyYWZ0LCBi
dXQgc2luY2UgaXQgYnJvYWRseSBhcHBsaWVzIHRvIHRoZSBPQXV0aCBzcGFjZSBJ4oCZbSBzdGFy
dGluZyBhIG5ldyB0aHJlYWTigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h
dXRoLWp3dC1iY3AtMDcjc2VjdGlvbi0zLjEyIj5TZWN0aW9uIDMuMTIgb2YgdGhlIEpXVCBCQ1A8
L2E+IHNheXM6IOKAnFVzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpX
VHMu4oCdDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v
YXV0aC1hY2Nlc3MtdG9rZW4tand0LTAzI3NlY3Rpb24tNCI+DQpTZWN0aW9uIDQgb2YgdGhlIEpX
VCBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VuczwvYT4gc2F5czog4oCcQW4gYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGVsZWN0IHRvIHVzZSBkaWZmZXJlbnQga2V5cyB0byBzaWdu
IGlkX3Rva2VucyBhbmQgSldUIGFjY2VzcyB0b2tlbnMu4oCdIFRoZXNlIHN0YXRlbWVudHMgYXJl
IGNvbnNpc3RlbnQgd2l0aCBnb29kIGNyeXB0b2dyYXBoaWMgaHlnaWVuZS4gQW5kIHdl4oCZdmUg
bWFkZSBpdCBkaWZmaWN1bHQNCiB0byBpbXBvc3NpYmxlIGZvciBhbiBBUyB0byBmb2xsb3cgdGhl
bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBBUyBoYXMg
YSBzaW5nbGUgbWV0YWRhdGEgZG9jdW1lbnQgY29udGFpbmluZyBhIHNpbmdsZSBVUkkgcmVmZXJl
bmNpbmcgYSBzaW5nbGUgSldLIFNldC4gQnV0IHRoZSBBUyBoYXMgbm8gd2F5IG9mIGluZGljYXRp
bmcgdG8gY2xpZW50cyB3aGljaCBrZXlzIHRvIHVzZSBmb3Igd2hpY2ggcHVycG9zZXMuIEZvciBl
eGFtcGxlLCBhbiBBUyBjYW5ub3Qgc2F5DQogdGhhdCAqPGI+b25seTwvYj4gPGI+dGhlc2U8L2I+
KiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgaWRfdG9rZW5faGludCBKV1RzLCBhbmQg
KjxiPm9ubHkgdGhlc2U8L2I+KiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgSkFSIHJl
cXVlc3Qgb2JqZWN0IEpXVHMuIEZvciBlbmNyeXB0aW9uLCB0aGUgQVMgY291bGQgZW5mb3JjZSB0
aGF0IGxvZ2ljIGludGVybmFsbHksIGJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBjbGllbnQN
CiB0byBkaXNjb3ZlciB0aGlzLiBBbmQgd2hpbGUgdGhlIEFTIG1heSBiZSBidWlsdCB0byBvbmx5
IHVzZSBjZXJ0YWluIGtleXMgZm9yIHNpZ25pbmcgSUQgVG9rZW5zIGFuZCBvdGhlciBrZXlzIGZv
ciBzaWduaW5nIEpXVCBhY2Nlc3MgdG9rZW5zLCBpdCBoYXMgbm8gd2F5IHRvIGluZGljYXRlIHRo
aXMgdG8gdGhlIGNsaWVudC4gU28gZXZlbiBpZiBJRCBUb2tlbiBnZW5lcmF0aW9uIGFuZCBhY2Nl
c3MgdG9rZW4gZ2VuZXJhdGlvbiBhcmUgaXNvbGF0ZWQNCiBpbiBkaWZmZXJlbnQgbWljcm9zZXJ2
aWNlcyB3aXRoaW4gdGhlIEFTLCBlYWNoIG1pY3Jvc2VydmljZSBpcyBjYXBhYmxlIG9mIGZvcmdp
bmcgdGhlIG90aGVy4oCZcyB0b2tlbnMsIGJlY2F1c2UgY29uc3VtZXJzIGNhbuKAmXQgYmUgdG9s
ZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBrZXlzIGZvciB0aGUgQVMuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIHNlZW1zIGxpa2UgYSB0
aWNraW5nIHRpbWUgYm9tYiB0byBtZSwgYXMgaXTigJlzIGEgbm9uLW9idmlvdXMgc2lkZSBlZmZl
Y3Qgb2YgY29tYmluaW5nIHZhcmlvdXMgT0F1dGggMi4wIGV4dGVuc2lvbnMsIGFuZCBpdCBjYW4g
dW5kZXJtaW5lIGEgbG90IG9mIHNvcGhpc3RpY2F0ZWQgZWZmb3J0IHRvIGZvbGxvdyBzZWN1cml0
eSBiZXN0IHByYWN0aWNlcy4NCiBJIGNhbiBzZWUgYSBjb3VwbGUgb2Ygd2F5cyB0byBhZGRyZXNz
IHRoaXMgKGUuZy4sIG1vcmUgc29waGlzdGljYXRlZCBBUyBrZXkgbWV0YWRhdGEsIHRhZ2dpbmcg
b3Igc2ltaWxhciB1c2UgY2FzZSBpbmRpY2F0aW9uIG9uIEpXS3MpLCBidXQgYmVmb3JlIHRyeWlu
ZyB0byBwcm9wb3NlIHNvbWV0aGluZyBJ4oCZZCBsaWtlIHRvIGdldCBwZW9wbGXigJlzIG9waW5p
b25zIG9uIHRoZSBwcm9ibGVtLiBJcyB0aGlzIGFscmVhZHkgbWl0aWdhdGVkIGluIG90aGVyDQog
d2F5cz8gSGFzIHRoZSBzaGlwIHNhaWxlZCBvbiB0aGlzIGZvciBPQXV0aCwgYW5kIG5vdyB3ZSBo
YXZlIHRvIGxpdmUgd2l0aCBpdD8gU2hvdWxkIHRoaXMgYmUgbGVmdCB0byB0aGUgZGVwbG95bWVu
dHMgdGhhdCBjYXJlIHRvIHNvbHZlIHdpdGggbm9uLWludGVyb3BlcmFibGUgc29sdXRpb25zPyBB
cmUgdGhlcmUgb3RoZXIgY2xldmVyIHdheXMgd2UgY291bGQgYXBwcm9hY2ggdGhpcz8gQXJlIHRo
ZXJlIG90aGVyIGFuZ2xlcyB0aGF0IHdlIG5lZWQNCiB0byBjb25zaWRlcj88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
4oCTJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUg
UmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BV1Mg
SWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A936D8D0D8D74B58AFF0AE16E4C7A660amazoncom_--


From nobody Wed Jan  8 15:58: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 C8BE51201DE for ; Wed,  8 Jan 2020 15:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqQqRPUXo9rP for ; Wed,  8 Jan 2020 15:58:13 -0800 (PST)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517441200A3 for ; Wed,  8 Jan 2020 15:58:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578527893; x=1610063893; h=from:to:cc:subject:date:message-id:mime-version; bh=+HJIfU4eT+vL/DKhP4qPxBH1u/v4LbzK7OV7O2OyNMA=; b=TtkQgWac0kh2KAqlz3JQ/gkmOSXS3DEyWW7Z3H+5x8JDFUHzgf0ezLDH MIovciLwNYK0anYKFfKF6r/3sD6nthdXbnpDyRkAkvRUmCGAmD++9a2sz dqrVv2rI4UFdLlqKSkFxvxwNxjz8Skath6lkkgz6hLF/MhTDSK/WQIdmP A=;
IronPort-SDR: Ry/k3hWkDL7wQbTh9ZFa8MNGMJOxgv83eLwpsURHUF9JuiXKtpY/WIel5HznwtL8RNA2W/07Po 4HWeuY1fvBMw==
X-IronPort-AV: E=Sophos; i="5.69,411,1571702400"; d="scan'208,217"; a="17582574"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-538b0bfb.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 08 Jan 2020 23:58:12 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-538b0bfb.us-west-2.amazon.com (Postfix) with ESMTPS id 6C7ADA18F0; Wed,  8 Jan 2020 23:58:12 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:58:11 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:58:11 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 23:58:11 +0000
From: "Richard Backman, Annabelle" 
To: Torsten Lodderstedt 
CC: oauth 
Thread-Topic: [OAUTH-WG] PAR: pushed requests must become JWTs
Thread-Index: AQHVxn97xAQyO4nozUmjnJjGmsDmTg==
Date: Wed, 8 Jan 2020 23:58:11 +0000
Message-ID: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.16]
Content-Type: multipart/alternative; boundary="_000_8D1DD3BF97B5416AB9146867FD3553B0amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 08 Jan 2020 23:58:16 -0000

--_000_8D1DD3BF97B5416AB9146867FD3553B0amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRleHQgdG8gSkFSIHJhdGhl
ciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8gcmV0Y29uIHJ1bGVz
IGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdodHMgdGhlIHdlaXJk
bmVzcyBvZiBnaXZpbmcgUEFSIHNwZWNpYWwgdHJlYXRtZW50Lg0KDQoNCg0KV2hhdCBpZiB3ZSBj
aGFuZ2VkIHRoaXMgc2VudGVuY2UgaW4gU2VjdGlvbiA1LjIgb2YgSkFSOg0KDQpUaGUgY29udGVu
dHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVz
dA0KDQpPYmplY3QuDQoNCg0KDQpUbzoNCg0KVGhlIGNvbnRlbnRzIG9mIHRoZSByZXNvdXJjZSBy
ZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJlcXVlc3QNCg0KT2JqZWN0LCB1bmxlc3Mg
dGhlIFVSSSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbg0K
DQpTZXJ2ZXIuDQoNCg0KDQpUaGlzIHdvdWxkIGFsbG93IGZvciB1c2UgY2FzZXMgc3VjaCBhcyBh
biBBUyB0aGF0IHByb3ZpZGVzIHByZS1kZWZpbmVkIHJlcXVlc3QgVVJJcywgb3IgdmVuZHMgcmVx
dWVzdCBVUklzIHZpYSBhIGNsaWVudCBtYW5hZ2VtZW50IGNvbnNvbGUsIG9yIGJha2VzIHRoZW0g
aW50byB0aGVpciBjbGllbnQgYXBwcy4NCg0KDQoNCuKAkw0KDQpBbm5hYmVsbGUgUmljaGFyZCBC
YWNrbWFuDQoNCkFXUyBJZGVudGl0eQ0KDQoNCg0K77u/T24gMS84LzIwLCAyOjUwIFBNLCAiVG9y
c3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5v
cmc+IHdyb3RlOg0KDQoNCg0KICAgIEhpLA0KDQoNCg0KICAgIHlvdSBhcmUgcmlnaHQsIFBBUiBk
b2VzIG5vdCByZXF1aXJlIHRoZSBBUyB0byByZXByZXNlbnQgdGhlIHJlcXVlc3QgYXMgYSBKV1Qt
YmFzZWQgcmVxdWVzdCBvYmplY3QuIFRoZSBVUkkgaXMgdXNlZCBhcyBpbnRlcm5hbCByZWZlcmVu
Y2Ugb25seS4gVGhhdCB3aHkgdGhlIGRyYWZ0IHN0YXRlcw0KDQoNCg0KICAgICJUaGVyZSBpcyBu
byBuZWVkIHRvIG1ha2UgdGhlDQoNCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0
YSBhdmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpcw0KDQogICAgICAgICAgVVJJLuKA
nQ0KDQoNCg0KICAgIFRoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZyb20gYW4gQVMgaW1wbGVtZW50
YXRpb24gcGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZyb20gYSBjbGllbnQncyAoaW50
ZXJvcCkgcGVyc3BlY3RpdmUuDQoNCg0KDQogICAgV2UgbWF5IGFkZCBhIHN0YXRlbWVudCB0byBQ
QVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBieSB0aGUgUEFSIG1lY2hhbmlzbSAo
TUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9uLg0KDQoNCg0KICAgIGJlc3QgcmVn
YXJkcywNCg0KICAgIFRvcnN0ZW4uDQoNCg0KDQogICAgPiBPbiA4LiBKYW4gMjAyMCwgYXQgMjM6
NDIsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1h
cmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgPg0KDQogICAgPiBIaSBhbGwsDQoNCiAgICA+DQoN
CiAgICA+IFRoZSBjdXJyZW50IGRyYWZ0cyBvZiBQQVIgKC0wMCkgYW5kIEpBUiAoLTIwKSByZXF1
aXJlIHRoYXQgdGhlIEFTIHRyYW5zZm9ybSBhbGwgcHVzaGVkIHJlcXVlc3RzIGludG8gSldUcy4g
VGhpcyByZXF1aXJlbWVudCBhcmlzZXMgZnJvbSB0aGUgZm9sbG93aW5nOg0KDQogICAgPiAgICAg
ICAgIOKAoiBQQVIgdXNlcyB0aGUgcmVxdWVzdF91cmkgcGFyYW1ldGVyIGRlZmluZWQgaW4gSkFS
IHRvIGNvbW11bmljYXRlIHRoZSBwdXNoZWQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBl
bmRwb2ludC4NCg0KICAgID4gICAgICAgICDigKIgQWNjb3JkaW5nIHRvIEpBUiwgdGhlIHJlc291
cmNlIHJlZmVyZW5jZWQgYnkgcmVxdWVzdF91cmkgTVVTVCBiZSBhIFJlcXVlc3QgT2JqZWN0LiAo
U2VjdGlvbiA1LjIpDQoNCiAgICA+ICAgICAgICAg4oCiIFJlcXVlc3QgT2JqZWN0IGlzIGRlZmlu
ZWQgdG8gYmUgYSBKV1QgY29udGFpbmluZyBhbGwgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBw
YXJhbWV0ZXJzLiAoU2VjdGlvbiAyLjEpDQoNCiAgICA+DQoNCiAgICA+IFRoZXJlIGlzIG5vIG5l
ZWQgZm9yIHRoaXMgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5LCBhcyB0
aGlzIGlzIGludGVybmFsIHRvIHRoZSBBUy4gSXQgaXMgYWxzbyBpbmNvbnNpc3RlbnQgd2l0aCB0
aGUgcmVzdCBvZiBKQVIsIHdoaWNoIGF2b2lkcyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgaW50
ZXJuYWwgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUgdHdvIEFTIGVuZHBvaW50cy4gV29yc2Us
IHRoaXMgcmVzdHJpY3Rpb24gbWFrZXMgaXQgaGFyZGVyIGZvciB0aGUgYXV0aG9yaXphdGlvbiBl
bmRwb2ludCB0byBsZXZlcmFnZSB2YWxpZGF0aW9uIGFuZCBvdGhlciB3b3JrIHBlcmZvcm1lZCBh
dCB0aGUgUEFSIGVuZHBvaW50LCBhcyB0aGUgc3RhdGUgb3Igb3V0Y29tZSBvZiB0aGF0IHdvcmsg
bXVzdCBiZSBmb3JjZWQgaW50byB0aGUgSldUIGZvcm1hdCAob3IgcmV0cmlldmVkIHZpYSBhIHN1
YnNlcXVlbnQgc2VydmljZSBjYWxsIG9yIGRhdGFiYXNlIGxvb2t1cCkuDQoNCiAgICA+DQoNCiAg
ICA+IOKAkw0KDQogICAgPiBBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCiAgICA+IEFXUyBJ
ZGVudGl0eQ0KDQogICAgPg0KDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQogICAgPiBPQXV0aCBtYWlsaW5nIGxpc3QNCg0KICAgID4gT0F1
dGhAaWV0Zi5vcmcNCg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aA0KDQoNCg0KDQo=

--_000_8D1DD3BF97B5416AB9146867FD3553B0amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs
YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu
IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ
bGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SXQgd291bGQgYmUgbW9yZSBhcHBy
b3ByaWF0ZSB0byBhZGQgdGhlIHRleHQgdG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQgZG9lc24n
dCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8gcmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5nIHRoZSB0
ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdodHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcgUEFSIHNw
ZWNpYWwgdHJlYXRtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XaGF0IGlmIHdl
IGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBTZWN0aW9uIDUuMiBvZiBKQVI6PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgY29udGVu
dHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVz
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPk9iamVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRv
OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSB0aGUgVVJJIE1V
U1QgYmUgYSBSZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2JqZWN0LCB1bmxlc3MgdGhlIFVSSSB3YXMgcHJvdmlk
ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlcnZlci48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgd291bGQgYWxsb3cgZm9yIHVz
ZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQgcHJvdmlkZXMgcHJlLWRlZmluZWQgcmVxdWVzdCBV
UklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMgdmlhIGEgY2xpZW50IG1hbmFnZW1lbnQgY29uc29s
ZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWlyIGNsaWVudCBhcHBzLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij7igJMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7vu79PbiAxLzgvMjAsIDI6NTAg
UE0sICZxdW90O1RvcnN0ZW4gTG9kZGVyc3RlZHQmcXVvdDsgJmx0O3RvcnN0ZW49NDBsb2RkZXJz
dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSGksIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt5b3UgYXJlIHJp
Z2h0LCBQQVIgZG9lcyBub3QgcmVxdWlyZSB0aGUgQVMgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0
IGFzIGEgSldULWJhc2VkIHJlcXVlc3Qgb2JqZWN0LiBUaGUgVVJJIGlzIHVzZWQgYXMgaW50ZXJu
YWwgcmVmZXJlbmNlIG9ubHkuIFRoYXQgd2h5IHRoZSBkcmFmdCBzdGF0ZXMNCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmcXVvdDtUaGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgdGhlPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGRhdGEgYXZhaWxhYmxl
IHRvIG90aGVyIHBhcnRpZXMgdmlhIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBVUkku4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGRpZmZlcmVuY2UgbWF0dGVycyBmcm9tIGFu
IEFTIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLCBpdCBkb2Vzbid0IG1hdHRlciBmcm9tIGEg
Y2xpZW50J3MgKGludGVyb3ApIHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UgbWF5IGFkZCBhIHN0
YXRlbWVudCB0byBQQVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBieSB0aGUgUEFS
IG1lY2hhbmlzbSAoTUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9uLg0KPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO2Jlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUb3JzdGVuLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jmd0OyBPbiA4LiBKYW4gMjAyMCwgYXQgMjM6NDIsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl
ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmZ3Q7IEhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGUgY3Vy
cmVudCBkcmFmdHMgb2YgUEFSICgtMDApIGFuZCBKQVIgKC0yMCkgcmVxdWlyZSB0aGF0IHRoZSBB
UyB0cmFuc2Zvcm0gYWxsIHB1c2hlZCByZXF1ZXN0cyBpbnRvIEpXVHMuIFRoaXMgcmVxdWlyZW1l
bnQgYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKIgUEFSIHVzZXMgdGhlIHJlcXVlc3RfdXJpIHBhcmFt
ZXRlciBkZWZpbmVkIGluIEpBUiB0byBjb21tdW5pY2F0ZSB0aGUgcHVzaGVkIHJlcXVlc3QgdG8g
dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIEFjY29yZGluZyB0byBKQVIsIHRoZSByZXNvdXJjZSBy
ZWZlcmVuY2VkIGJ5IHJlcXVlc3RfdXJpIE1VU1QgYmUgYSBSZXF1ZXN0IE9iamVjdC4gKFNlY3Rp
b24gNS4yKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IOKAoiBSZXF1ZXN0IE9iamVjdCBpcyBkZWZpbmVkIHRvIGJlIGEgSldUIGNvbnRhaW5pbmcgYWxs
IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gKFNlY3Rpb24gMi4xKTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IFRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgcmVxdWlyZW1l
bnQgdG8gc3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5LCBhcyB0aGlzIGlzIGludGVybmFsIHRvIHRo
ZSBBUy4gSXQgaXMgYWxzbyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgcmVzdCBvZiBKQVIsIHdoaWNo
IGF2b2lkcyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgaW50ZXJuYWwgY29tbXVuaWNhdGlvbnMg
YmV0d2VlbiB0aGUgdHdvIEFTIGVuZHBvaW50cy4NCiBXb3JzZSwgdGhpcyByZXN0cmljdGlvbiBt
YWtlcyBpdCBoYXJkZXIgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGxldmVyYWdl
IHZhbGlkYXRpb24gYW5kIG90aGVyIHdvcmsgcGVyZm9ybWVkIGF0IHRoZSBQQVIgZW5kcG9pbnQs
IGFzIHRoZSBzdGF0ZSBvciBvdXRjb21lIG9mIHRoYXQgd29yayBtdXN0IGJlIGZvcmNlZCBpbnRv
IHRoZSBKV1QgZm9ybWF0IChvciByZXRyaWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNh
bGwNCiBvciBkYXRhYmFzZSBsb29rdXApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IOKAkyA8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZndDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQVdTIElkZW50aXR5
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT0F1dGhA
aWV0Zi5vcmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8D1DD3BF97B5416AB9146867FD3553B0amazoncom_--


From nobody Thu Jan  9 00:56: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 9F9FF120890 for ; Thu,  9 Jan 2020 00:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 dLNuqR8zFrIQ for ; Thu,  9 Jan 2020 00:56:18 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF529120885 for ; Thu,  9 Jan 2020 00:56:17 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id p17so1892374wma.1 for ; Thu, 09 Jan 2020 00:56:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UmtMIK/WgW7MEWFIVmJmjuuI7eM2dNl1ZQg/etrXeDY=; b=uLZh94bxCBQjhzo6mWELmNALPwKqiE6+HBKdbw5ZofnZQ0ij7hM7YZ5IzjbnYVpsNH 9c4RffUeaSRdbsN2SPvsPxHPp7kuuucriyVHCYSteqjk5ygMW7SZ4ZlhiSrtzJQzXMjs obZUUcdOFLyCtoy/0YlomiQ/tC7cxocodt9wU4mO4m9EdwKuq+OvzELttMlY/xFwRdsu EYnvf9mM86fP2PQsy0bIdh9m1vxzi+bkPYCYmcUtLmOPw7XftoxeE+q1/d+p/4rYJrqi PQgJqiWAd7fheWrn21nMTiJBQ+Iihk8wG1UFQy7z0pyrVCfTyOCJqioykvYPfT/idXUp cVtw==
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=UmtMIK/WgW7MEWFIVmJmjuuI7eM2dNl1ZQg/etrXeDY=; b=AT2aIk1IW/exbIUkAEWMFYX/I/f89NYAIo3DsW2oKcfMKWgqJQPJnjlbEfUgcJptvs jnnbgWFWGI4o1fITacYXE9gB32NQq3s+zbYc6U9E3BhMDaewUEP+HboM3sP/v+ZbkaZ0 nAeDO05JYJqpBh3H0HmwCA6RunrlIPVo/4b5YzRrz1M4VmXVS+cLdOJxaCrJjowhZriC 6/4AYrptURJhSD7eNnIMPxAdMXgnUiVZuWjrO+RUhuhYjj4IajsrVQUmpO1jYJwxDeEb 457f2OUDXr/mJSlx0YYFfWP6qNBoRvXIIqZ2NXpg2ktMVFHtndRF2bkqaybP+4DgKqZe mLQQ==
X-Gm-Message-State: APjAAAVOUORymBDdoSDt/XZ4Cn3cj/qvyYHoGK7eN2eyQnPW/mjvgqVz GAr9cfDOMElprCkUH2zMCueMfw==
X-Google-Smtp-Source: APXvYqwIwFWvxkhT9QLNH7jSDtUaQlOfjKpHneTmGpeOihy2rTRNfL1UE3xRIT73OZZZ7J+5ZpSmUw==
X-Received: by 2002:a1c:9cce:: with SMTP id f197mr3244891wme.133.1578560176447;  Thu, 09 Jan 2020 00:56:16 -0800 (PST)
Received: from [10.30.2.24] ([213.151.95.77]) by smtp.gmail.com with ESMTPSA id t1sm2107452wma.43.2020.01.09.00.56.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2020 00:56:15 -0800 (PST)
Content-Type: multipart/signed; boundary=Apple-Mail-A14B76CB-5EC1-4838-896E-CBDB885E6904; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Thu, 9 Jan 2020 09:56:14 +0100
Message-Id: <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com>
Cc: oauth 
In-Reply-To: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com>
To: "Richard Backman, Annabelle" 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 08:56:21 -0000

--Apple-Mail-A14B76CB-5EC1-4838-896E-CBDB885E6904
Content-Type: multipart/alternative;
	boundary=Apple-Mail-8D455CD7-8EEE-463A-BBAF-E75A2F5E27C1
Content-Transfer-Encoding: 7bit


--Apple-Mail-8D455CD7-8EEE-463A-BBAF-E75A2F5E27C1
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I would assume given the status of JAR, we don=E2=80=99t want to change it. A=
nd as I said, this difference does not impact interoperability from client p=
erspective.

> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle :
>=20
> =EF=BB=BF
> It would be more appropriate to add the text to JAR rather than PAR. It do=
esn't seem right for PAR to retcon rules in JAR. Moving the text to JAR also=
 highlights the weirdness of giving PAR special treatment.
> =20
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
> =20
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
> =20
> This would allow for use cases such as an AS that provides pre-defined req=
uest URIs, or vends request URIs via a client management console, or bakes t=
hem into their client apps.
> =20
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
> =20
> =EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt"  wrote:
> =20
>     Hi,
>    =20
>     you are right, PAR does not require the AS to represent the request as=
 a JWT-based request object. The URI is used as internal reference only. Tha=
t why the draft states
>    =20
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>   =20
>     This difference matters from an AS implementation perspective, it does=
n't matter from a client's (interop) perspective.
>   =20
>     We may add a statement to PAR saying that request_uris issued by the P=
AR mechanism (MAY) deviate from the JAR definition.
>    =20
>     best regards,
>     Torsten.=20
>    =20
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  wrote:
>     >
>     > Hi all,
>     >=20
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS tr=
ansform all pushed requests into JWTs. This requirement arises from the foll=
owing:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR t=
o communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by reque=
st_uri MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing a=
ll the authorization request parameters. (Section 2.1)
>     >=20
>     > There is no need for this requirement to support interoperability, a=
s this is internal to the AS. It is also inconsistent with the rest of JAR, w=
hich avoids attempting to define the internal communications between the two=
 AS endpoints. Worse, this restriction makes it harder for the authorization=
 endpoint to leverage validation and other work performed at the PAR endpoin=
t, as the state or outcome of that work must be forced into the JWT format (=
or retrieved via a subsequent service call or database lookup).
>     >=20
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >=20
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org
>     > https://www.ietf.org/mailman/listinfo/oauth
>   =20
>    =20

--Apple-Mail-8D455CD7-8EEE-463A-BBAF-E75A2F5E27C1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I would assume given the s=
tatus of JAR, we don=E2=80=99t want to change it. And as I said, this differ=
ence does not impact interoperability from client perspective.

Am 09.01.2020 um 00:58 schrieb Richar=
d Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

=

=EF=BB=BF









It would be more appropriate to add the text to JA=
R rather than PAR. It doesn't seem right for PAR to retcon rules in JAR. Mov=
ing the text to JAR also highlights the weirdness of giving PAR special trea=
tment.


 


What if we changed this sentence in Section 5.2 of=
 JAR:


The contents of the resource referenced by the U=
RI MUST be a Request


Object.


 


To: 


The contents of the resource referenced by the U=
RI MUST be a Request


Object, unless the URI was provided to the clie=
nt by the Authorization


Server.


 


This would allow for use cases such as an AS that p=
rovides pre-defined request URIs, or vends request URIs via a client managem=
ent console, or bakes them into their client apps.


 


=E2=80=93 


Annabelle Richard Backman


AWS Identity




 


=EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt"=
 <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:


 


    Hi, 


    


    you are right, PAR does no=
t require the AS to represent the request as a JWT-based request object. The=
 URI is used as internal reference only. That why the draft states



    


    "There is no need to make t=
he


        &n=
bsp; authorization request data available to other parties via this


        &n=
bsp; URI.=E2=80=9D


    


    This difference matters fr=
om an AS implementation perspective, it doesn't matter from a client's (inte=
rop) perspective.


    


    We may add a statement to P=
AR saying that request_uris issued by the PAR mechanism (MAY) deviate from t=
he JAR definition.



    


    best regards,

    Torsten.  


    


    > On 8. Jan 2020, at 23=
:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&g=
t; wrote:


    > 


    > Hi all,

    >  


    > The current drafts of=
 PAR (-00) and JAR (-20) require that the AS transform all pushed requests i=
nto JWTs. This requirement arises from the following:


    >     &n=
bsp;   =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to communicate the pushed request to the authorization endpoint.=



    >     &n=
bsp;   =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri MUST be a Request Object. (Section 5.2)


    >     &n=
bsp;   =E2=80=A2 Request Object is defined to be a JWT containing a=
ll the authorization request parameters. (Section 2.1)


    >  


    > There is no need for t=
his requirement to support interoperability, as this is internal to the AS. I=
t is also inconsistent with the rest of JAR, which avoids attempting to defi=
ne the internal communications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to l=
everage validation and other work performed at the PAR endpoint, as the stat=
e or outcome of that work must be forced into the JWT format (or retrieved v=
ia a subsequent service call
 or database lookup).


    >  


    > =E2=80=93 =



    > Annabelle Richard Bac=
kman


    > AWS Identity

    >  


    > _____________________=
__________________________


    > OAuth mailing list


    > OAuth@ietf.org<=
/p>

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


    


    






=

--Apple-Mail-8D455CD7-8EEE-463A-BBAF-E75A2F5E27C1--

--Apple-Mail-A14B76CB-5EC1-4838-896E-CBDB885E6904
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0
aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTA5MDg1NjE0WjAv
BgkqhkiG9w0BCQQxIgQg41np6woadko1Tejut8lZ0h53ZITWOcAUXAGN9My/LZswgb0GCSsGAQQB
gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ
MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0
aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH
21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv
IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQAo3omp
tFRwKeTsZR36uNi/dfpNhjL0mrvLlxi2v4u9ZoEoD3akAco/tlSL83/k7BEwf6ccAeW6WAsxDlCy
zkWJaFo2NQFjQWF60TNwJZ3V8USX8XsMhrpDcnJxSwJAXcVZVYLh2d0oCWaXdkyCW6JZGdQe9+nk
PEuyMFIrhrFcGho7JMmtfSs2nG20ifv/1G533jVVtIj1IdzEI3nNyBlAl7sG5T07abR9kQpaKst2
9+J59BAEyAqvbfifEAFZsOdZ3uaS7aVmTVdLlets2djhgAuJDIFfIxu8AtDcXZZGCCkJB9TFz3vd
DKIkZBrdGUEOebgSuz4nHLo7NH5porooAAAAAAAA
--Apple-Mail-A14B76CB-5EC1-4838-896E-CBDB885E6904--


From nobody Thu Jan  9 07:37: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 B05051200F9 for ; Thu,  9 Jan 2020 07:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 rLhBxvMn5-Mw for ; Thu,  9 Jan 2020 07:37:28 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733C1120073 for ; Thu,  9 Jan 2020 07:37:28 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 7E45514269 for ; Thu,  9 Jan 2020 15:37:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578584245; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yg81UZ8Kgb2ij4eIBoEWaN/1UnTNucJBmRkzZO7UkAU=; b=b3UEcDUjuB39UPYT7XQWqg2PGeICf52XooSWlrPqGG36qyTerBWApVngOCMtAVRRWYjugh NsNhZAYmXRUb6E48hHTQLeiv0f2CzneoIpt4htXtD5/kjlRZFaXRxuxV3JNmy6YNtmFwpv KPfmLGeOOTMZ3fVYX6Be6FbtXi94ra8=
To: oauth@ietf.org
References: 
From: Daniel Fett 
Message-ID: <176756e3-7392-80f9-73ed-9a8668aad4ac@danielfett.de>
Date: Thu, 9 Jan 2020 16:37:24 +0100
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A7618B9BC17289AF02537CF6"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1578584245; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yg81UZ8Kgb2ij4eIBoEWaN/1UnTNucJBmRkzZO7UkAU=; b=BMUGPJ2a/dN9KKn+OhsjJYpPF1pioLUxnwiTZX6bW2UnupsM+/4Z8AZny1FOrJidW7Ms1g vHnfQgHGWZYSctbc5HNQJzAp9vd3uobKudxPSVw/jw3txp91rCR99UGGe9X5HGECI51DSM wZBbe0l/oxppXfJkgDP+H5I1bwdCSvI=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1578584245; a=rsa-sha256; cv=none; b=CjZpXwBIhSv4zaKrbyEKza0Jl1YClMmtmy6pMKS5sVOQvypJwnm9Io1SBfbuBPV9ZZ7sctZDGTRTwibU9a6oTh+PRgIBUUW8MP78XKhSAzmAqxZI4Atb1dfaM6tJNPw9JHhRLpMdULNmHt6HIdYy+mEiercmxROHFUzKSaypxDg=
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] review draft-ietf-oauth-security-topics-13 [2/3]
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 15:37:31 -0000

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

Hi Hans,

Am 11.11.19 um 10:57 schrieb Hans Zandbelt:
>
> P17
> About the description of the mixup attack: as long as the attacker is
> able to trigger a request (by having the user click a link) and read
> the query/POST parameters on the A-AS (perhaps from the logs) he can
> execute a mixup attack by starting from the A-AS rather than the H-AS
> (as demonstrated in the OAuth 2.0 security workshop in Darmstadt
> December 2016). Perhaps this can be made more explicit.

I'm not sure if I understand your comment correctly. By definition, the
attacker can always read the parameters from A-AS. The rest of the
attack is what is currently described as "Mix-Up Without Interception",
isn't it?

-Daniel

>
> -- 
> hans.zandbelt@zmartzone.eu 
> ZmartZone IAM - www.zmartzone.eu 
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
Hi Hans,

    

    


    

    
Am 11.11.19 um 10:57 schrieb Hans
      Zandbelt:

    

    

      
      

        


          
P17

          
About the description of the mixup attack: as long as the
            attacker is able to trigger a request (by having the user
            click a link) and read the query/POST parameters on the A-AS
            (perhaps from the logs) he can execute a mixup attack by
            starting from the A-AS rather than the H-AS (as demonstrated
            in the OAuth 2.0 security workshop in Darmstadt December
            2016). Perhaps this can be made more explicit.

        

      

    

    
I'm not sure if I understand your comment correctly. By
      definition, the attacker can always read the parameters from A-AS.
      The rest of the attack is what is currently described as "Mix-Up
      Without Interception", isn't it?

    
-Daniel

    

    

      
      

      

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


    

    


    

  


--------------A7618B9BC17289AF02537CF6--


From nobody Thu Jan  9 11:33: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 884EC120144 for ; Thu,  9 Jan 2020 11:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 iiCwFe5OvAgs for ; Thu,  9 Jan 2020 11:33:24 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640118.outbound.protection.outlook.com [40.107.64.118]) (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 710D2120123 for ; Thu,  9 Jan 2020 11:33:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ShYg4MY/UBs1gdS6B1VuPSzkZDO3s058W8JCuin5yL5DZI2qkfiHZhUOlNXcMHVmYI5GQHtmMn+Et3vy43ujxTgXdrZf5YdRIS9EQiyIiwTUlmZDZlfyXt40aV/rpy2VuWVTPixGpKDF/pC03c6E8iona3lZj12PgwV7+gKYCJ/xketuQooLOibTjIUhX2Vn+XAVhJIFRrIKdboMysGfCxxSayH9GR24/Qpn4lJ2CRYz6TE2uoljk1DK7KSHpQ9Ke7rGo3vSu5VJeWCJALx9k5qMpSbLG+QI09YzdETvXuOHGh/u6tc381xy1+gcs7nno5cdPlyKuUsupj9uAk9zKg==
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=EXGhuiMFFwJIDCnk+eN/VqcaZ1VCG/5WqsspjTV7yzQ=; b=STLvaisXNxt0aakXTl5y6pgo8+s//HivqhgXUEDHFUveQ/tzD03WmEbCHsZFFm8wUgrFyPhqS7Pv07BOjgW4cjnHDCaCGmLJ/avRggTa0t2bteigYKUotqDSNjy6FNvhHB2Yr0w66H4XmJeIyW9JUO8nsu1142Fw0kYVg/TSRKB7+KMEEMqcwhWnCEN2n1zGRFVhI8firZDmsWpHXUUuT9os0FodapOcPm/GmRHdSRDkbay8kUup3mHKkQBjXYHfn3+FZZtTt0+bKPOaJ+dwR3oZgmsypkMpJbQllmRuDfA1nhUB2Be8s3y+tWvJlNGisF15o97ShFWVoOlHxtsovA==
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=EXGhuiMFFwJIDCnk+eN/VqcaZ1VCG/5WqsspjTV7yzQ=; b=iHYyiOyL+O2R7iauan02+NRLNVu3QpPmpJoY4l4hfMIh3bxpGd3VI+oH+GM7XgnNMKVNNE1xs5V0rsFGUPXyhn54uA3dwZA3Y4Hqcvs6wCpHe0kREBtBISk0sxj1n/kIXobjHeKdKeIdU9g/lxksm7FQfc//MFTNJMLPkDoUX+s=
Received: from DM6PR00MB0847.namprd00.prod.outlook.com (20.179.227.78) by DM6PR00MB0474.namprd00.prod.outlook.com (20.178.29.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2660.0; Thu, 9 Jan 2020 19:33:22 +0000
Received: from DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::2d56:644f:3f3e:8c62]) by DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::2d56:644f:3f3e:8c62%4]) with mapi id 15.20.2665.000; Thu, 9 Jan 2020 19:33:22 +0000
From: Mike Jones 
To: "Richard Backman, Annabelle" , oauth 
Thread-Topic: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVxn32ZMKwQrnvkUO4GZSyw84VLqfit3ng
Date: Thu, 9 Jan 2020 19:33:22 +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=b5b9fcc8-7583-4a6f-ba7a-0000b35e6f1a; 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-01-09T19:23:11Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.92.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 49d34014-529a-48e6-46ae-08d7953ac9ee
x-ms-traffictypediagnostic: DM6PR00MB0474:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02778BF158
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(366004)(136003)(396003)(189003)(199004)(52314003)(33656002)(76116006)(86362001)(7696005)(6506007)(478600001)(53546011)(8990500004)(8676002)(2906002)(26005)(316002)(81166006)(81156014)(5660300002)(186003)(66946007)(52536014)(8936002)(10290500003)(66574012)(110136005)(66556008)(64756008)(71200400001)(66446008)(55016002)(9686003)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0474; H:DM6PR00MB0847.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: DtG1z1oks31hxRZjmHgS5Mh6VsP+QlkPZbz1oTaDirpqgfekly7cUl0nPe0IQRpgezHF6HCcNki0+E6qGdNBelrZgSjKzZg92id3sYZ82tUyE8Df1lU5h4N0Eju4WcofSuxXp0gBFAgiidp9RXpDeJgT8trPvNzvDdeDY4rMJNsvTJZcKFg2I2b+GqGuFwyV4eG08s2vOTozHvifSxu2Kolgz9ePGroVqi/jRqi/SeHp++4cHsdNZkjtY2fDxubAzCQWPe77afOAGgMpqqQRAxiClItvUU+rc7gPB/0sBkD6RNtlAWo9cIDQ6MXh/QOK90AG6Dy6CJl0ui4PmFV7thxj+1F/LEIMBQltK1qEW77x2AmL32x4gKc487hhIcX9VlCGJ5mty0mATMrC5Wmx1VEL+8E13VR1RwEkzteG4BwWW0MefHOjIkfCfRzJBpsTHwbTpjCRgT1bUKoH3nDXfYS9ssz2nNHkLxZUk68eRI2qnBfwqkeRLRkIfnxKOEQpB/d/HA+dmmha5Vth5NEk97LB9HrRgrUlJe230R+PDtxI87IceVmRPkIzzXwS35oi
x-ms-exchange-antispam-messagedata: /mM7oMoDMPOv5YH20suJZ44jygdR6f0qVREHCLnE5Nyc9BI/yTtvzGCxsyzHvNmvSZqAYw05rwQnZm84zydlLGvEJx9EheEJ4BujyoQyFQBpAdNTTMvYaQK6GgimW4tluetWyO4l1iDIP8Nx+zvOhA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0847C099541F89C9A476B4D6F5390DM6PR00MB0847namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 49d34014-529a-48e6-46ae-08d7953ac9ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 19:33:22.3656 (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: UuNDwx6mvJlB/hjCesWM6ic0D+LArGjiodK8YVHnpsZmvjqVTSD0fL1KGUfgjuNtc64/bNwAXM6yTkz1jTbY9Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0474
Archived-At: 
Subject: Re: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 19:33:26 -0000

--_000_DM6PR00MB0847C099541F89C9A476B4D6F5390DM6PR00MB0847namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBhIGdvb2QgdGhpbmcgdG8gdGhpbmsgYWJvdXQuICBUaGFua3MgZm9yIGJyaW5naW5nIHRo
aXMgdXAsIEFubmFiZWxsZS4NCg0KT25lIHRoaW5nIHRoYXQgcGFydGlhbGx5IG1pdGlnYXRlcyB0
aGlzIGlzIHRoYXQgdGhlIOKAnHVzZeKAnSBhbmQvb3Ig4oCca2V5X29wc+KAnSBhdHRyaWJ1dGVz
IGNhbiBiZSBwcm92aWRlZC4gIFRoaXMgY2FuIGFsbG93IHNpZ25pbmcga2V5cyB0byBiZSBkaWZm
ZXJlbnRpYXRlZCBmcm9tIGVuY3J5cHRpb24ga2V5cywgZm9yIGluc3RhbmNlLg0KDQpJ4oCZbSBu
b3QgYXMgd29ycmllZCBhYm91dCBlbmNyeXB0aW9uIGtleXMgYXMgc2lnbmluZyBrZXlzLiAgSWYg
bXVsdGlwbGUga2luZHMgb2YgYXBwbGljYXRpb25zIGVuY3J5cHQgY29udGVudCB0byBhIHBhcnR5
IHVzaW5nIHRoZSBzYW1lIHB1YmxpYyBwZXItcGFydHkga2V5LCBhbmQgdGhlIGVuY3J5cHRpb24g
aXMgYmVpbmcgdXNlZCBvbmx5IHRvIGVuc3VyZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIG1lc3Nh
Z2VzLCB0aGUgY29uZmlkZW50aWFsaXR5IGlzIHN0aWxsIGFjaGlldmVkLg0KDQpPbmUgbWl0aWdh
dGlvbiBmb3Igc2lnbmluZyBrZXlzIGlzIHVzZSBvZiB0aGUg4oCcdHlw4oCdIGZpZWxkLCBhcyBk
ZXNjcmliZWQgaW4gdGhlIEpXVCBCQ1AuICBFdmVuIGlmIHRoZSBzYW1lIGtleSB3YXMgdXNlZCBh
bmQgeW91IHJlY2VpdmUgYW4gdW5leHBlY3RlZCBKV1QgdHlwZSwgeW91IHdpbGwgc3RpbGwgcmVq
ZWN0IGl0Lg0KDQpJIGJlbGlldmUgdGhlcmXigJlzIGFsc28gY2FzZXMgd2hlcmUgaXTigJlzIGZp
bmUgdG8gdXNlIHRoZSBzYW1lIHNpZ25pbmcga2V5IGZvciByZWxhdGVkIG9wZXJhdGlvbnMuICBG
b3IgaW5zdGFuY2UsIHNpZ25pbmcgYSBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBh
IFJlcXVlc3QgT2JqZWN0IHdpdGggdGhlIHNhbWUga2V5IHNlZW1zIGJvdGggbG9naWNhbCBhbmQg
c2FmZSB0byBtZS4gIChJZiBvdGhlcnMgY2FuIHRoaW5rIG9mIGFuIGF0dGFjayB0aGF0IHRoaXMg
ZW5hYmxlcywgaG93ZXZlciwgcGxlYXNlIGRvIHBvaW50IGl0IG91dC4pDQoNCldoaWNoIEkgYmVs
aWV2ZSBsZWF2ZXMgdXMgd2l0aCB0aGlzIGNhc2UgdG8gd29ycnkgYWJvdXQg4oCTIHNoYXJlZCBz
aWduaW5nIGtleXMgYnkgdW5yZWxhdGVkIGFwcGxpY2F0aW9ucyB3aGVuIOKAnHR5cOKAnSBpcyBu
b3QgdXNlZC4gIE9uZSB3YXkgdG8gbWl0aWdhdGUgdGhpcyB3b3VsZCBiZSB0byB1c2UgcGVyLWFw
cGxpY2F0aW9uIGtleSBzZXRzLiAgRm9yIGluc3RhbmNlLCB1c2luZyB2YWx1ZXMgb3RoZXIgdGhh
biDigJxqd2tzX3VyaeKAnSB0byByZWZlcmVuY2Uga2V5IHNldHMgZm9yIHBhcnRpY3VsYXIgYXBw
bGljYXRpb25zLg0KDQpBbnl3YXksIGZvciBQQVIsIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBmaW5l
IHRvIHVzZSB0aGUgc2FtZSBrZXlzIGFzIHVzZWQgZm9yIFJlcXVlc3QgT2JqZWN0cywgc28gbm8g
bmV3IGZpZWxkcyBhcmUgbmVlZGVkIGZvciBpdC4NCg0KSSBsb29rIGZvcndhcmQgdG8gZnVydGhl
ciBkaXNjdXNzaW9uIG9uIHRoZSB0b3BpYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs
ZQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDgsIDIwMjAgMzo0NyBQTQ0KVG86IG9hdXRoIDxv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gQ3J5cHRvZ3JhcGhpYyBoeWdpZW5l
IGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpDQoNCkkgb3JpZ2luYWxseSBicm91Z2h0IHVwIHRo
aXMgaXNzdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIFBBUiBkcmFmdCwgYnV0IHNpbmNlIGl0IGJy
b2FkbHkgYXBwbGllcyB0byB0aGUgT0F1dGggc3BhY2UgSeKAmW0gc3RhcnRpbmcgYSBuZXcgdGhy
ZWFk4oCmDQoNClNlY3Rpb24gMy4xMiBvZiB0aGUgSldUIEJDUDxodHRwczovL25hbTA2LnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRm
Lm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDclMjNzZWN0aW9uLTMuMTIm
ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M3M2Q1NDdjNzY4
MWY0ZWE1OWE0ODA4ZDc5NDk1MjllNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdDMSU3QzAlN0M2MzcxNDEyNDA2OTcyOTU0NDUmc2RhdGE9QWVRTHhDYW8yWlQ2NjFaSzJmRTRh
NlFLeWg4SXpPJTJCcSUyRnF6YnQ3VmxkMHMlM0QmcmVzZXJ2ZWQ9MD4gc2F5czog4oCcVXNlIGRp
ZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy7igJ0gU2VjdGlvbiA0IG9m
IHRoZSBKV1QgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnM8aHR0cHM6Ly9uYW0w
Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v
bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAz
JTIzc2VjdGlvbi00JmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t
JTdDNzNkNTQ3Yzc2ODFmNGVhNTlhNDgwOGQ3OTQ5NTI5ZTYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQxMjQwNjk3MzA1NDAyJnNkYXRhPUlTc3pUeGxI
VGJBTEluakslMkZLZ2dIOXNlWmRXOGtHWFRESFpFV0N5ZkF6YyUzRCZyZXNlcnZlZD0wPiBzYXlz
OiDigJxBbiBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZWxlY3QgdG8gdXNlIGRpZmZlcmVudCBr
ZXlzIHRvIHNpZ24gaWRfdG9rZW5zIGFuZCBKV1QgYWNjZXNzIHRva2Vucy7igJ0gVGhlc2Ugc3Rh
dGVtZW50cyBhcmUgY29uc2lzdGVudCB3aXRoIGdvb2QgY3J5cHRvZ3JhcGhpYyBoeWdpZW5lLiBB
bmQgd2XigJl2ZSBtYWRlIGl0IGRpZmZpY3VsdCB0byBpbXBvc3NpYmxlIGZvciBhbiBBUyB0byBm
b2xsb3cgdGhlbS4NCg0KVGhlIEFTIGhhcyBhIHNpbmdsZSBtZXRhZGF0YSBkb2N1bWVudCBjb250
YWluaW5nIGEgc2luZ2xlIFVSSSByZWZlcmVuY2luZyBhIHNpbmdsZSBKV0sgU2V0LiBCdXQgdGhl
IEFTIGhhcyBubyB3YXkgb2YgaW5kaWNhdGluZyB0byBjbGllbnRzIHdoaWNoIGtleXMgdG8gdXNl
IGZvciB3aGljaCBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIGFuIEFTIGNhbm5vdCBzYXkgdGhhdCAq
b25seSB0aGVzZSoga2V5cyBhcmUgdG8gYmUgdXNlZCB0byBlbmNyeXB0IGlkX3Rva2VuX2hpbnQg
SldUcywgYW5kICpvbmx5IHRoZXNlKiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgSkFS
IHJlcXVlc3Qgb2JqZWN0IEpXVHMuIEZvciBlbmNyeXB0aW9uLCB0aGUgQVMgY291bGQgZW5mb3Jj
ZSB0aGF0IGxvZ2ljIGludGVybmFsbHksIGJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBjbGll
bnQgdG8gZGlzY292ZXIgdGhpcy4gQW5kIHdoaWxlIHRoZSBBUyBtYXkgYmUgYnVpbHQgdG8gb25s
eSB1c2UgY2VydGFpbiBrZXlzIGZvciBzaWduaW5nIElEIFRva2VucyBhbmQgb3RoZXIga2V5cyBm
b3Igc2lnbmluZyBKV1QgYWNjZXNzIHRva2VucywgaXQgaGFzIG5vIHdheSB0byBpbmRpY2F0ZSB0
aGlzIHRvIHRoZSBjbGllbnQuIFNvIGV2ZW4gaWYgSUQgVG9rZW4gZ2VuZXJhdGlvbiBhbmQgYWNj
ZXNzIHRva2VuIGdlbmVyYXRpb24gYXJlIGlzb2xhdGVkIGluIGRpZmZlcmVudCBtaWNyb3NlcnZp
Y2VzIHdpdGhpbiB0aGUgQVMsIGVhY2ggbWljcm9zZXJ2aWNlIGlzIGNhcGFibGUgb2YgZm9yZ2lu
ZyB0aGUgb3RoZXLigJlzIHRva2VucywgYmVjYXVzZSBjb25zdW1lcnMgY2Fu4oCZdCBiZSB0b2xk
IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gZGlmZmVyZW50IGtleXMgZm9yIHRoZSBBUy4NCg0KVGhp
cyBzZWVtcyBsaWtlIGEgdGlja2luZyB0aW1lIGJvbWIgdG8gbWUsIGFzIGl04oCZcyBhIG5vbi1v
YnZpb3VzIHNpZGUgZWZmZWN0IG9mIGNvbWJpbmluZyB2YXJpb3VzIE9BdXRoIDIuMCBleHRlbnNp
b25zLCBhbmQgaXQgY2FuIHVuZGVybWluZSBhIGxvdCBvZiBzb3BoaXN0aWNhdGVkIGVmZm9ydCB0
byBmb2xsb3cgc2VjdXJpdHkgYmVzdCBwcmFjdGljZXMuIEkgY2FuIHNlZSBhIGNvdXBsZSBvZiB3
YXlzIHRvIGFkZHJlc3MgdGhpcyAoZS5nLiwgbW9yZSBzb3BoaXN0aWNhdGVkIEFTIGtleSBtZXRh
ZGF0YSwgdGFnZ2luZyBvciBzaW1pbGFyIHVzZSBjYXNlIGluZGljYXRpb24gb24gSldLcyksIGJ1
dCBiZWZvcmUgdHJ5aW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIEnigJlkIGxpa2UgdG8gZ2V0IHBl
b3BsZeKAmXMgb3BpbmlvbnMgb24gdGhlIHByb2JsZW0uIElzIHRoaXMgYWxyZWFkeSBtaXRpZ2F0
ZWQgaW4gb3RoZXIgd2F5cz8gSGFzIHRoZSBzaGlwIHNhaWxlZCBvbiB0aGlzIGZvciBPQXV0aCwg
YW5kIG5vdyB3ZSBoYXZlIHRvIGxpdmUgd2l0aCBpdD8gU2hvdWxkIHRoaXMgYmUgbGVmdCB0byB0
aGUgZGVwbG95bWVudHMgdGhhdCBjYXJlIHRvIHNvbHZlIHdpdGggbm9uLWludGVyb3BlcmFibGUg
c29sdXRpb25zPyBBcmUgdGhlcmUgb3RoZXIgY2xldmVyIHdheXMgd2UgY291bGQgYXBwcm9hY2gg
dGhpcz8gQXJlIHRoZXJlIG90aGVyIGFuZ2xlcyB0aGF0IHdlIG5lZWQgdG8gY29uc2lkZXI/DQoN
CuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg==

--_000_DM6PR00MB0847C099541F89C9A476B4D6F5390DM6PR00MB0847namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g
MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPlRoaXMgYSBnb29kIHRoaW5nIHRv
IHRoaW5rIGFib3V0LiZuYnNwOyBUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdXAsIEFubmFiZWxs
ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtjb2xvcjojMDAyMDYwIj5PbmUgdGhpbmcgdGhhdCBwYXJ0aWFsbHkgbWl0aWdhdGVzIHRoaXMg
aXMgdGhhdCB0aGUg4oCcdXNl4oCdIGFuZC9vciDigJxrZXlfb3Bz4oCdIGF0dHJpYnV0ZXMgY2Fu
IGJlIHByb3ZpZGVkLiZuYnNwOyBUaGlzIGNhbiBhbGxvdyBzaWduaW5nIGtleXMgdG8gYmUgZGlm
ZmVyZW50aWF0ZWQgZnJvbSBlbmNyeXB0aW9uIGtleXMsIGZvciBpbnN0YW5jZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAy
MDYwIj5J4oCZbSBub3QgYXMgd29ycmllZCBhYm91dCBlbmNyeXB0aW9uIGtleXMgYXMgc2lnbmlu
ZyBrZXlzLiZuYnNwOyBJZiBtdWx0aXBsZSBraW5kcyBvZiBhcHBsaWNhdGlvbnMgZW5jcnlwdCBj
b250ZW50IHRvIGEgcGFydHkgdXNpbmcgdGhlIHNhbWUgcHVibGljIHBlci1wYXJ0eSBrZXksIGFu
ZCB0aGUgZW5jcnlwdGlvbiBpcyBiZWluZyB1c2VkIG9ubHkNCiB0byBlbnN1cmUgY29uZmlkZW50
aWFsaXR5IG9mIHRoZSBtZXNzYWdlcywgdGhlIGNvbmZpZGVudGlhbGl0eSBpcyBzdGlsbCBhY2hp
ZXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtjb2xvcjojMDAyMDYwIj5PbmUgbWl0aWdhdGlvbiBmb3Igc2lnbmluZyBrZXlzIGlzIHVz
ZSBvZiB0aGUg4oCcdHlw4oCdIGZpZWxkLCBhcyBkZXNjcmliZWQgaW4gdGhlIEpXVCBCQ1AuJm5i
c3A7IEV2ZW4gaWYgdGhlIHNhbWUga2V5IHdhcyB1c2VkIGFuZCB5b3UgcmVjZWl2ZSBhbiB1bmV4
cGVjdGVkIEpXVCB0eXBlLCB5b3Ugd2lsbCBzdGlsbCByZWplY3QgaXQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+
SSBiZWxpZXZlIHRoZXJl4oCZcyBhbHNvIGNhc2VzIHdoZXJlIGl04oCZcyBmaW5lIHRvIHVzZSB0
aGUgc2FtZSBzaWduaW5nIGtleSBmb3IgcmVsYXRlZCBvcGVyYXRpb25zLiZuYnNwOyBGb3IgaW5z
dGFuY2UsIHNpZ25pbmcgYSBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBhIFJlcXVl
c3QgT2JqZWN0IHdpdGggdGhlIHNhbWUga2V5IHNlZW1zDQogYm90aCBsb2dpY2FsIGFuZCBzYWZl
IHRvIG1lLiZuYnNwOyAoSWYgb3RoZXJzIGNhbiB0aGluayBvZiBhbiBhdHRhY2sgdGhhdCB0aGlz
IGVuYWJsZXMsIGhvd2V2ZXIsIHBsZWFzZSBkbyBwb2ludCBpdCBvdXQuKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAi
PldoaWNoIEkgYmVsaWV2ZSBsZWF2ZXMgdXMgd2l0aCB0aGlzIGNhc2UgdG8gd29ycnkgYWJvdXQg
4oCTIHNoYXJlZCBzaWduaW5nIGtleXMgYnkgdW5yZWxhdGVkIGFwcGxpY2F0aW9ucyB3aGVuIOKA
nHR5cOKAnSBpcyBub3QgdXNlZC4mbmJzcDsgT25lIHdheSB0byBtaXRpZ2F0ZSB0aGlzIHdvdWxk
IGJlIHRvIHVzZSBwZXItYXBwbGljYXRpb24ga2V5IHNldHMuJm5ic3A7DQogRm9yIGluc3RhbmNl
LCB1c2luZyB2YWx1ZXMgb3RoZXIgdGhhbiDigJxqd2tzX3VyaeKAnSB0byByZWZlcmVuY2Uga2V5
IHNldHMgZm9yIHBhcnRpY3VsYXIgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y
OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkFueXdheSwg
Zm9yIFBBUiwgSSBiZWxpZXZlIHRoYXQgaXTigJlzIGZpbmUgdG8gdXNlIHRoZSBzYW1lIGtleXMg
YXMgdXNlZCBmb3IgUmVxdWVzdCBPYmplY3RzLCBzbyBubyBuZXcgZmllbGRzIGFyZSBuZWVkZWQg
Zm9yIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2NvbG9yOiMwMDIwNjAiPkkgbG9vayBmb3J3YXJkIHRvIGZ1cnRoZXIgZGlzY3Vzc2lv
biBvbiB0aGUgdG9waWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IE9BdXRoICZs
dDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWNoYXJk
IEJhY2ttYW4sIEFubmFiZWxsZTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkg
OCwgMjAyMCAzOjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gQ3J5cHRvZ3JhcGhpYyBoeWdpZW5l
IGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgb3JpZ2lu
YWxseSBicm91Z2h0IHVwIHRoaXMgaXNzdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIFBBUiBkcmFm
dCwgYnV0IHNpbmNlIGl0IGJyb2FkbHkgYXBwbGllcyB0byB0aGUgT0F1dGggc3BhY2UgSeKAmW0g
c3RhcnRpbmcgYSBuZXcgdGhyZWFk4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFm
dC1pZXRmLW9hdXRoLWp3dC1iY3AtMDclMjNzZWN0aW9uLTMuMTImYW1wO2RhdGE9MDIlN0MwMSU3
Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNzNkNTQ3Yzc2ODFmNGVhNTlhNDgwOGQ3
OTQ5NTI5ZTYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3
MTQxMjQwNjk3Mjk1NDQ1JmFtcDtzZGF0YT1BZVFMeENhbzJaVDY2MVpLMmZFNGE2UUt5aDhJek8l
MkJxJTJGcXpidDdWbGQwcyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+U2VjdGlvbg0KIDMuMTIgb2YgdGhl
IEpXVCBCQ1A8L2E+IHNheXM6IOKAnFVzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtp
bmRzIG9mIEpXVHMu4oCdIDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy
RmRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMyUyM3NlY3Rpb24tNCZhbXA7ZGF0
YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M3M2Q1NDdjNzY4MWY0
ZWE1OWE0ODA4ZDc5NDk1MjllNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD
MSU3QzAlN0M2MzcxNDEyNDA2OTczMDU0MDImYW1wO3NkYXRhPUlTc3pUeGxIVGJBTEluakslMkZL
Z2dIOXNlWmRXOGtHWFRESFpFV0N5ZkF6YyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+DQpTZWN0aW9uIDQg
b2YgdGhlIEpXVCBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VuczwvYT4gc2F5czog
4oCcQW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGVsZWN0IHRvIHVzZSBkaWZmZXJlbnQga2V5
cyB0byBzaWduIGlkX3Rva2VucyBhbmQgSldUIGFjY2VzcyB0b2tlbnMu4oCdIFRoZXNlIHN0YXRl
bWVudHMgYXJlIGNvbnNpc3RlbnQgd2l0aCBnb29kIGNyeXB0b2dyYXBoaWMgaHlnaWVuZS4gQW5k
IHdl4oCZdmUgbWFkZSBpdCBkaWZmaWN1bHQNCiB0byBpbXBvc3NpYmxlIGZvciBhbiBBUyB0byBm
b2xsb3cgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo
ZSBBUyBoYXMgYSBzaW5nbGUgbWV0YWRhdGEgZG9jdW1lbnQgY29udGFpbmluZyBhIHNpbmdsZSBV
UkkgcmVmZXJlbmNpbmcgYSBzaW5nbGUgSldLIFNldC4gQnV0IHRoZSBBUyBoYXMgbm8gd2F5IG9m
IGluZGljYXRpbmcgdG8gY2xpZW50cyB3aGljaCBrZXlzIHRvIHVzZSBmb3Igd2hpY2ggcHVycG9z
ZXMuIEZvciBleGFtcGxlLCBhbiBBUyBjYW5ub3Qgc2F5DQogdGhhdCAqPGI+b25seTwvYj4gPGI+
dGhlc2U8L2I+KiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgaWRfdG9rZW5faGludCBK
V1RzLCBhbmQgKjxiPm9ubHkgdGhlc2U8L2I+KiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5
cHQgSkFSIHJlcXVlc3Qgb2JqZWN0IEpXVHMuIEZvciBlbmNyeXB0aW9uLCB0aGUgQVMgY291bGQg
ZW5mb3JjZSB0aGF0IGxvZ2ljIGludGVybmFsbHksIGJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRo
ZSBjbGllbnQNCiB0byBkaXNjb3ZlciB0aGlzLiBBbmQgd2hpbGUgdGhlIEFTIG1heSBiZSBidWls
dCB0byBvbmx5IHVzZSBjZXJ0YWluIGtleXMgZm9yIHNpZ25pbmcgSUQgVG9rZW5zIGFuZCBvdGhl
ciBrZXlzIGZvciBzaWduaW5nIEpXVCBhY2Nlc3MgdG9rZW5zLCBpdCBoYXMgbm8gd2F5IHRvIGlu
ZGljYXRlIHRoaXMgdG8gdGhlIGNsaWVudC4gU28gZXZlbiBpZiBJRCBUb2tlbiBnZW5lcmF0aW9u
IGFuZCBhY2Nlc3MgdG9rZW4gZ2VuZXJhdGlvbiBhcmUgaXNvbGF0ZWQNCiBpbiBkaWZmZXJlbnQg
bWljcm9zZXJ2aWNlcyB3aXRoaW4gdGhlIEFTLCBlYWNoIG1pY3Jvc2VydmljZSBpcyBjYXBhYmxl
IG9mIGZvcmdpbmcgdGhlIG90aGVy4oCZcyB0b2tlbnMsIGJlY2F1c2UgY29uc3VtZXJzIGNhbuKA
mXQgYmUgdG9sZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBrZXlzIGZvciB0aGUg
QVMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIHNlZW1z
IGxpa2UgYSB0aWNraW5nIHRpbWUgYm9tYiB0byBtZSwgYXMgaXTigJlzIGEgbm9uLW9idmlvdXMg
c2lkZSBlZmZlY3Qgb2YgY29tYmluaW5nIHZhcmlvdXMgT0F1dGggMi4wIGV4dGVuc2lvbnMsIGFu
ZCBpdCBjYW4gdW5kZXJtaW5lIGEgbG90IG9mIHNvcGhpc3RpY2F0ZWQgZWZmb3J0IHRvIGZvbGxv
dyBzZWN1cml0eSBiZXN0IHByYWN0aWNlcy4NCiBJIGNhbiBzZWUgYSBjb3VwbGUgb2Ygd2F5cyB0
byBhZGRyZXNzIHRoaXMgKGUuZy4sIG1vcmUgc29waGlzdGljYXRlZCBBUyBrZXkgbWV0YWRhdGEs
IHRhZ2dpbmcgb3Igc2ltaWxhciB1c2UgY2FzZSBpbmRpY2F0aW9uIG9uIEpXS3MpLCBidXQgYmVm
b3JlIHRyeWluZyB0byBwcm9wb3NlIHNvbWV0aGluZyBJ4oCZZCBsaWtlIHRvIGdldCBwZW9wbGXi
gJlzIG9waW5pb25zIG9uIHRoZSBwcm9ibGVtLiBJcyB0aGlzIGFscmVhZHkgbWl0aWdhdGVkIGlu
IG90aGVyDQogd2F5cz8gSGFzIHRoZSBzaGlwIHNhaWxlZCBvbiB0aGlzIGZvciBPQXV0aCwgYW5k
IG5vdyB3ZSBoYXZlIHRvIGxpdmUgd2l0aCBpdD8gU2hvdWxkIHRoaXMgYmUgbGVmdCB0byB0aGUg
ZGVwbG95bWVudHMgdGhhdCBjYXJlIHRvIHNvbHZlIHdpdGggbm9uLWludGVyb3BlcmFibGUgc29s
dXRpb25zPyBBcmUgdGhlcmUgb3RoZXIgY2xldmVyIHdheXMgd2UgY291bGQgYXBwcm9hY2ggdGhp
cz8gQXJlIHRoZXJlIG90aGVyIGFuZ2xlcyB0aGF0IHdlIG5lZWQNCiB0byBjb25zaWRlcj88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+4oCTJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B
bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DM6PR00MB0847C099541F89C9A476B4D6F5390DM6PR00MB0847namp_--


From nobody Thu Jan  9 11:34:06 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 36DD3120271 for ; Thu,  9 Jan 2020 11:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53RTSGAZlv80 for ; Thu,  9 Jan 2020 11:33:57 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FCF1201B7 for ; Thu,  9 Jan 2020 11:33:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578598438; x=1610134438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UCXsdsg3F/Dge7erbHNBp0UIwb6sq6qYumAYkmoQw+I=; b=gr9FYkL3B6B7zcELIZqqHbEcwDt4U+Jm1Ewj33xDrv7FSXJhHBZlnn8T 0Dg0naZnaq0VoSgoa+cEPZ22dp2z62koG84nTJ0uqk030FZyHeViPncb1 WkV8yNFHwUKGP2H5EAg/fFuF1BmOlnX+ksoGFPQB3a9QOwEEuIWVhzk7t 0=;
IronPort-SDR: obqToOrY5hkqeYtF6nhzF2+7lljvF9WHvebyoHi5Qjjn/anURfa3XCi0Xm4BNogRiILIkNEXwN yCbab2ih13Mw==
X-IronPort-AV: E=Sophos;i="5.69,414,1571702400"; d="scan'208,217";a="9396919"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 09 Jan 2020 19:33:47 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 406C6A1C6F; Thu,  9 Jan 2020 19:33:44 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 9 Jan 2020 19:33:43 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 9 Jan 2020 19:33:43 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 9 Jan 2020 19:33:43 +0000
From: "Richard Backman, Annabelle" 
To: Torsten Lodderstedt , "Richard Backman, Annabelle" 
CC: oauth 
Thread-Topic: [OAUTH-WG] PAR: pushed requests must become JWTs
Thread-Index: AQHVxn97xAQyO4nozUmjnJjGmsDmTqfiCEwAgAAsAIA=
Date: Thu, 9 Jan 2020 19:33:43 +0000
Message-ID: 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
In-Reply-To: <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.52]
Content-Type: multipart/alternative; boundary="_000_D37D8F063E074C89B0B961AAF2CDAA2Famazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 19:34:04 -0000

--_000_D37D8F063E074C89B0B961AAF2CDAA2Famazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgd2UgYWRkcmVzcyB0aGlzIGluIFBBUiwgSSBzdWdnZXN0IHNvbWV0aGluZyBhbG9uZyB0aGUg
bGluZXMgb2YgdGhlIGZvbGxvd2luZzoNCg0KQXMgZGVmaW5lZCBpbiBbSkFSXSwgdGhlIHJlcXVl
c3RfdXJpIHBhcmFtZXRlciBpcyByZXF1aXJlZCB0byByZWZlcmVuY2UgYSBSZXF1ZXN0IE9iamVj
dCBKV1QuIEFuIEFTIE1BWSB2aW9sYXRlIHRoaXMgcmVxdWlyZW1lbnQgd2hlbiBpdCBpcyBnZW5l
cmF0aW5nIHJlcXVlc3QgVVJJcyBpbnRlbmRlZCBmb3IgaXRzIG93biBjb25zdW1wdGlvbiAoZS5n
LiwgVVJJcyBmb3IgcHVzaGVkIHJlcXVlc3RzKS4gVGhpcyByZXF1aXJlbWVudCBleGlzdHMgdG8g
ZW5zdXJlIGludGVyb3BlcmFiaWxpdHkgaW4gY2FzZXMgd2hlcmUgdGhlIHByb3ZpZGVyIG9mIHRo
ZSByZXF1ZXN0X3VyaSBpcyBhIHNlcGFyYXRlIGVudGl0eSBmcm9tIHRoZSBjb25zdW1lciwgc3Vj
aCBhcyB3aGVuIGEgY2xpZW50IHByb3ZpZGVzIGEgVVJJIHJlZmVyZW5jaW5nIGFuIG9iamVjdCBz
dG9yZWQgb24gdGhlIGNsaWVudOKAmXMgYmFja2VuZCBzZXJ2aWNlLiBXaGVuIHRoZSBBUyBpcyBi
b3RoIHByb3ZpZGVyIGFuZCBjb25zdW1lciwgdGhpcyBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm4g
ZG9lcyBub3QgYXBwbHkuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElk
ZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs
ZiBvZiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJj
LmlldGYub3JnPg0KRGF0ZTogVGh1cnNkYXksIEphbnVhcnkgOSwgMjAyMCBhdCAxMjo1NiBBTQ0K
VG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBk
bWFyYy5pZXRmLm9yZz4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBQQVI6IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzDQoNCkkgd291
bGQgYXNzdW1lIGdpdmVuIHRoZSBzdGF0dXMgb2YgSkFSLCB3ZSBkb27igJl0IHdhbnQgdG8gY2hh
bmdlIGl0LiBBbmQgYXMgSSBzYWlkLCB0aGlzIGRpZmZlcmVuY2UgZG9lcyBub3QgaW1wYWN0IGlu
dGVyb3BlcmFiaWxpdHkgZnJvbSBjbGllbnQgcGVyc3BlY3RpdmUuDQoNCg0KQW0gMDkuMDEuMjAy
MCB1bSAwMDo1OCBzY2hyaWViIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00
MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Og0KDQpJdCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJp
YXRlIHRvIGFkZCB0aGUgdGV4dCB0byBKQVIgcmF0aGVyIHRoYW4gUEFSLiBJdCBkb2Vzbid0IHNl
ZW0gcmlnaHQgZm9yIFBBUiB0byByZXRjb24gcnVsZXMgaW4gSkFSLiBNb3ZpbmcgdGhlIHRleHQg
dG8gSkFSIGFsc28gaGlnaGxpZ2h0cyB0aGUgd2VpcmRuZXNzIG9mIGdpdmluZyBQQVIgc3BlY2lh
bCB0cmVhdG1lbnQuDQoNCg0KDQpXaGF0IGlmIHdlIGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBT
ZWN0aW9uIDUuMiBvZiBKQVI6DQoNClRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgcmVmZXJl
bmNlZCBieSB0aGUgVVJJIE1VU1QgYmUgYSBSZXF1ZXN0DQoNCk9iamVjdC4NCg0KDQoNClRvOg0K
DQpUaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNU
IGJlIGEgUmVxdWVzdA0KDQpPYmplY3QsIHVubGVzcyB0aGUgVVJJIHdhcyBwcm92aWRlZCB0byB0
aGUgY2xpZW50IGJ5IHRoZSBBdXRob3JpemF0aW9uDQoNClNlcnZlci4NCg0KDQoNClRoaXMgd291
bGQgYWxsb3cgZm9yIHVzZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQgcHJvdmlkZXMgcHJlLWRl
ZmluZWQgcmVxdWVzdCBVUklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMgdmlhIGEgY2xpZW50IG1h
bmFnZW1lbnQgY29uc29sZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWlyIGNsaWVudCBhcHBzLg0K
DQoNCg0K4oCTDQoNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCg0KQVdTIElkZW50aXR5DQoN
Cg0KDQpPbiAxLzgvMjAsIDI6NTAgUE0sICJUb3JzdGVuIExvZGRlcnN0ZWR0IiA8dG9yc3Rlbj00
MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCg0KDQogICAgSGksDQoN
Cg0KDQogICAgeW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90IHJlcXVpcmUgdGhlIEFTIHRvIHJl
cHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCByZXF1ZXN0IG9iamVjdC4gVGhlIFVS
SSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5LiBUaGF0IHdoeSB0aGUgZHJhZnQg
c3RhdGVzDQoNCg0KDQogICAgIlRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSB0aGUNCg0KICAgICAg
ICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBkYXRhIGF2YWlsYWJsZSB0byBvdGhlciBwYXJ0aWVz
IHZpYSB0aGlzDQoNCiAgICAgICAgICBVUkku4oCdDQoNCg0KDQogICAgVGhpcyBkaWZmZXJlbmNl
IG1hdHRlcnMgZnJvbSBhbiBBUyBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgaXQgZG9lc24n
dCBtYXR0ZXIgZnJvbSBhIGNsaWVudCdzIChpbnRlcm9wKSBwZXJzcGVjdGl2ZS4NCg0KDQoNCiAg
ICBXZSBtYXkgYWRkIGEgc3RhdGVtZW50IHRvIFBBUiBzYXlpbmcgdGhhdCByZXF1ZXN0X3VyaXMg
aXNzdWVkIGJ5IHRoZSBQQVIgbWVjaGFuaXNtIChNQVkpIGRldmlhdGUgZnJvbSB0aGUgSkFSIGRl
ZmluaXRpb24uDQoNCg0KDQogICAgYmVzdCByZWdhcmRzLA0KDQogICAgVG9yc3Rlbi4NCg0KDQoN
CiAgICA+IE9uIDguIEphbiAyMDIwLCBhdCAyMzo0MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs
bGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICA+
DQoNCiAgICA+IEhpIGFsbCwNCg0KICAgID4NCg0KICAgID4gVGhlIGN1cnJlbnQgZHJhZnRzIG9m
IFBBUiAoLTAwKSBhbmQgSkFSICgtMjApIHJlcXVpcmUgdGhhdCB0aGUgQVMgdHJhbnNmb3JtIGFs
bCBwdXNoZWQgcmVxdWVzdHMgaW50byBKV1RzLiBUaGlzIHJlcXVpcmVtZW50IGFyaXNlcyBmcm9t
IHRoZSBmb2xsb3dpbmc6DQoNCiAgICA+ICAgICAgICAg4oCiIFBBUiB1c2VzIHRoZSByZXF1ZXN0
X3VyaSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBKQVIgdG8gY29tbXVuaWNhdGUgdGhlIHB1c2hlZCBy
ZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50Lg0KDQogICAgPiAgICAgICAgIOKA
oiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1ZXN0X3Vy
aSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMikNCg0KICAgID4gICAgICAg
ICDigKIgUmVxdWVzdCBPYmplY3QgaXMgZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5nIGFs
bCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSkNCg0K
ICAgID4NCg0KICAgID4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudCB0byBz
dXBwb3J0IGludGVyb3BlcmFiaWxpdHksIGFzIHRoaXMgaXMgaW50ZXJuYWwgdG8gdGhlIEFTLiBJ
dCBpcyBhbHNvIGluY29uc2lzdGVudCB3aXRoIHRoZSByZXN0IG9mIEpBUiwgd2hpY2ggYXZvaWRz
IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBpbnRlcm5hbCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVu
IHRoZSB0d28gQVMgZW5kcG9pbnRzLiBXb3JzZSwgdGhpcyByZXN0cmljdGlvbiBtYWtlcyBpdCBo
YXJkZXIgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGxldmVyYWdlIHZhbGlkYXRp
b24gYW5kIG90aGVyIHdvcmsgcGVyZm9ybWVkIGF0IHRoZSBQQVIgZW5kcG9pbnQsIGFzIHRoZSBz
dGF0ZSBvciBvdXRjb21lIG9mIHRoYXQgd29yayBtdXN0IGJlIGZvcmNlZCBpbnRvIHRoZSBKV1Qg
Zm9ybWF0IChvciByZXRyaWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNhbGwgb3IgZGF0
YWJhc2UgbG9va3VwKS4NCg0KICAgID4NCg0KICAgID4g4oCTDQoNCiAgICA+IEFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW4NCg0KICAgID4gQVdTIElkZW50aXR5DQoNCiAgICA+DQoNCiAgICA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICA+IE9B
dXRoIG1haWxpbmcgbGlzdA0KDQogICAgPiBPQXV0aEBpZXRmLm9yZw0KDQogICAgPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg==

--_000_D37D8F063E074C89B0B961AAF2CDAA2Famazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <73C9EF553ED75F4F93448778C3687832@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs
YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs
YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx
IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHdlIGFkZHJlc3Mg
dGhpcyBpbiBQQVIsIEkgc3VnZ2VzdCBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSBm
b2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+QXMgZGVmaW5lZCBpbiBbSkFSXSwgdGhlIHJlcXVlc3RfdXJp
IHBhcmFtZXRlciBpcyByZXF1aXJlZCB0byByZWZlcmVuY2UgYSBSZXF1ZXN0IE9iamVjdCBKV1Qu
IEFuIEFTIE1BWSB2aW9sYXRlIHRoaXMgcmVxdWlyZW1lbnQgd2hlbiBpdCBpcyBnZW5lcmF0aW5n
IHJlcXVlc3QgVVJJcyBpbnRlbmRlZCBmb3IgaXRzDQogb3duIGNvbnN1bXB0aW9uIChlLmcuLCBV
UklzIGZvciBwdXNoZWQgcmVxdWVzdHMpLiBUaGlzIHJlcXVpcmVtZW50IGV4aXN0cyB0byBlbnN1
cmUgaW50ZXJvcGVyYWJpbGl0eSBpbiBjYXNlcyB3aGVyZSB0aGUgcHJvdmlkZXIgb2YgdGhlIHJl
cXVlc3RfdXJpIGlzIGEgc2VwYXJhdGUgZW50aXR5IGZyb20gdGhlIGNvbnN1bWVyLCBzdWNoIGFz
IHdoZW4gYSBjbGllbnQgcHJvdmlkZXMgYSBVUkkgcmVmZXJlbmNpbmcgYW4gb2JqZWN0IHN0b3Jl
ZCBvbg0KIHRoZSBjbGllbnTigJlzIGJhY2tlbmQgc2VydmljZS4gV2hlbiB0aGUgQVMgaXMgYm90
aCBwcm92aWRlciBhbmQgY29uc3VtZXIsIHRoaXMgaW50ZXJvcGVyYWJpbGl0eSBjb25jZXJuIGRv
ZXMgbm90IGFwcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCTJm5ic3A7PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m
IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMu
aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBKYW51YXJ5IDksIDIwMjAg
YXQgMTI6NTYgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJl
bGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+Q2M6IDwvYj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDogPC9iPlJlOiBbT0FVVEgtV0ddIFBBUjogcHVzaGVkIHJlcXVlc3RzIG11c3QgYmVjb21lIEpX
VHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBhc3N1
bWUgZ2l2ZW4gdGhlIHN0YXR1cyBvZiBKQVIsIHdlIGRvbuKAmXQgd2FudCB0byBjaGFuZ2UgaXQu
IEFuZCBhcyBJIHNhaWQsIHRoaXMgZGlmZmVyZW5jZSBkb2VzIG5vdCBpbXBhY3QgaW50ZXJvcGVy
YWJpbGl0eSBmcm9tIGNsaWVudCBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFtIDA5
LjAxLjIwMjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7
cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozo8bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
SXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRleHQgdG8gSkFSIHJhdGhl
ciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8gcmV0Y29uIHJ1bGVz
IGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdodHMgdGhlIHdlaXJk
bmVzcyBvZiBnaXZpbmcgUEFSIHNwZWNpYWwgdHJlYXRtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij5XaGF0IGlmIHdlIGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBTZWN0aW9uIDUu
MiBvZiBKQVI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij5UaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhl
IFVSSSBNVVNUIGJlIGEgUmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9iamVjdC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPlRvOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgcmVm
ZXJlbmNlZCBieSB0aGUgVVJJIE1VU1QgYmUgYSBSZXF1ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T2JqZWN0LCB1bmxl
c3MgdGhlIFVSSSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlv
bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPlNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo
aXMgd291bGQgYWxsb3cgZm9yIHVzZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQgcHJvdmlkZXMg
cHJlLWRlZmluZWQgcmVxdWVzdCBVUklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMgdmlhIGEgY2xp
ZW50IG1hbmFnZW1lbnQgY29uc29sZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWlyIGNsaWVudCBh
cHBzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij7igJMgPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+T24gMS84LzIwLCAyOjUwIFBNLCAmcXVvdDtUb3JzdGVuIExvZGRl
cnN0ZWR0JnF1b3Q7ICZsdDt0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3Jn
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEhpLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90IHJlcXVp
cmUgdGhlIEFTIHRvIHJlcHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCByZXF1ZXN0
IG9iamVjdC4gVGhlIFVSSSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5LiBUaGF0
IHdoeSB0aGUgZHJhZnQgc3RhdGVzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7VGhlcmUgaXMgbm8g
bmVlZCB0byBtYWtlIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1
dGhvcml6YXRpb24gcmVxdWVzdCBkYXRhIGF2YWlsYWJsZSB0byBvdGhlciBwYXJ0aWVzIHZpYSB0
aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJLuKAnTxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7VGhpcyBkaWZmZXJlbmNlIG1hdHRlcnMgZnJvbSBhbiBBUyBpbXBsZW1lbnRhdGlvbiBwZXJz
cGVjdGl2ZSwgaXQgZG9lc24ndCBtYXR0ZXIgZnJvbSBhIGNsaWVudCdzIChpbnRlcm9wKSBwZXJz
cGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO1dlIG1heSBhZGQgYSBzdGF0ZW1lbnQgdG8gUEFSIHNheWluZyB0
aGF0IHJlcXVlc3RfdXJpcyBpc3N1ZWQgYnkgdGhlIFBBUiBtZWNoYW5pc20gKE1BWSkgZGV2aWF0
ZSBmcm9tIHRoZSBKQVIgZGVmaW5pdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiZXN0IHJlZ2FyZHMs
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsgVG9yc3Rlbi4mbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgT24gOC4gSmFuIDIwMjAsIGF0
IDIzOjQyLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9NDBhbWF6b24u
Y29tQGRtYXJjLmlldGYub3JnJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBIaSBhbGws
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgVGhlIGN1cnJlbnQgZHJhZnRzIG9mIFBBUiAoLTAw
KSBhbmQgSkFSICgtMjApIHJlcXVpcmUgdGhhdCB0aGUgQVMgdHJhbnNmb3JtIGFsbCBwdXNoZWQg
cmVxdWVzdHMgaW50byBKV1RzLiBUaGlzIHJlcXVpcmVtZW50IGFyaXNlcyBmcm9tIHRoZSBmb2xs
b3dpbmc6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz
cDsmbmJzcDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
4oCiIFBBUiB1c2VzIHRoZSByZXF1ZXN0X3VyaSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBKQVIgdG8g
Y29tbXVuaWNhdGUgdGhlIHB1c2hlZCByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBv
aW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKA
oiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1ZXN0X3Vy
aSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMik8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKIgUmVxdWVzdCBPYmplY3QgaXMg
ZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5nIGFsbCB0aGUgYXV0aG9yaXphdGlvbiByZXF1
ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBU
aGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgaW50ZXJvcGVy
YWJpbGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlzIGFsc28gaW5jb25z
aXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0ZW1wdGluZyB0byBk
ZWZpbmUgdGhlIGludGVybmFsIGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlIHR3byBBUyBlbmRw
b2ludHMuDQogV29yc2UsIHRoaXMgcmVzdHJpY3Rpb24gbWFrZXMgaXQgaGFyZGVyIGZvciB0aGUg
YXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBsZXZlcmFnZSB2YWxpZGF0aW9uIGFuZCBvdGhlciB3
b3JrIHBlcmZvcm1lZCBhdCB0aGUgUEFSIGVuZHBvaW50LCBhcyB0aGUgc3RhdGUgb3Igb3V0Y29t
ZSBvZiB0aGF0IHdvcmsgbXVzdCBiZSBmb3JjZWQgaW50byB0aGUgSldUIGZvcm1hdCAob3IgcmV0
cmlldmVkIHZpYSBhIHN1YnNlcXVlbnQgc2VydmljZSBjYWxsDQogb3IgZGF0YWJhc2UgbG9va3Vw
KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyAmZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyDigJMgPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IEFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0
OyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9BdXRoQGlldGYub3JnPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D37D8F063E074C89B0B961AAF2CDAA2Famazoncom_--


From nobody Thu Jan  9 11:47: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 B78A01207FB for ; Thu,  9 Jan 2020 11:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 q1evJCuAi5Ho for ; Thu,  9 Jan 2020 11:47:50 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5271C120047 for ; Thu,  9 Jan 2020 11:47:50 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id d139so2787305wmd.0 for ; Thu, 09 Jan 2020 11:47:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5GdRCTlzZ/aJxMmm6zlUn3ACPXxUfExOY+cXweVx7nk=; b=jX6SX57Z3RGcDco8gWlB96WsRnXb47AOJslw0GtrYo7UxaqiJTHF+A6cY3pXxsH02i ftmEDL4LuycU82t7AS9ZsfqODBiBY3jPHoeS+9eFMv/xkwMATvzKl2LYag6Z4v3IUhp6 J/6+7CKd4PymfLrlAyCYxPVDrdnn8AfibWSdZaYeS/EbN2cR+Ju2AZVMgtcbPbEpd3oi pR39LeUD5mX8rvRQ7ijSW8ERmMJFkbNiJHdxIkNbGWW+jKgaf+up8QDhwihsh0DdL8vZ YgawMteGcxh8t+vX1oLdIeKcmY6fSTxgY1e17kE//szYyBIcsDOgwdVOQJDrDgMEZqa6 FdvQ==
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=5GdRCTlzZ/aJxMmm6zlUn3ACPXxUfExOY+cXweVx7nk=; b=IEPEcKWuhrsZ1P45HuIvVaLlxBANobSee2R58wj1CgnRZGxMTZGCcsXyYmYYjYtmjE TaDlsbQDi7y/SeGiKDw3jHslFDVdpcoKHNTiwBcNlpkvtggdZ0Ok57FEm+pefaVRQQOO RYtualXMJEWNz08GlY/AcqLXIe2A4N/C7IVmAfwIJSFkhTP/FP8q5xsYGETOfFIzjlid 7kwYbRAvcSBOLHEgNqbdk3RrRMju+/VwC//E47l3VhadosmTsA17SsNoEXxPqwzbnvDs hCRmHg6CLgIzUrNx/dOP3PL+fj8jiG9XtWzhSWv0wFTeJC7u0lts4mMiszvIvFSPfPf2 XHRQ==
X-Gm-Message-State: APjAAAVhkh7SyWy/UIaJfXcXJrEqQhs+gmZsFHlfmQwyvJTGivp72Zm1 SXOQ7jfgbeNn+Nn5AqvdJHROig==
X-Google-Smtp-Source: APXvYqyUd5CM6kQdzKPJdA+XrWCB64L/iWzjm03zqWe181QtX/dEnJInUj1+OrpXXL6v29saiBW09A==
X-Received: by 2002:a05:600c:24d1:: with SMTP id 17mr6511609wmu.136.1578599268837;  Thu, 09 Jan 2020 11:47:48 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id n189sm4085854wme.33.2020.01.09.11.47.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2020 11:47:48 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Thu, 9 Jan 2020 20:47:47 +0100
Message-Id: 
References: 
Cc: oauth 
In-Reply-To: 
To: "Richard Backman, Annabelle" 
X-Mailer: iPad Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 19:47:53 -0000

--Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks for the text proposal. It works for me.

> Am 09.01.2020 um 20:34 schrieb Richard Backman, Annabelle :
>=20
> =EF=BB=BF
> If we address this in PAR, I suggest something along the lines of the foll=
owing:
> =20
> As defined in [JAR], the request_uri parameter is required to reference a R=
equest Object JWT. An AS MAY violate this requirement when it is generating r=
equest URIs intended for its own consumption (e.g., URIs for pushed requests=
). This requirement exists to ensure interoperability in cases where the pro=
vider of the request_uri is a separate entity from the consumer, such as whe=
n a client provides a URI referencing an object stored on the client=E2=80=99=
s backend service. When the AS is both provider and consumer, this interoper=
ability concern does not apply.
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: OAuth  on behalf of Torsten Lodderstedt 
> Date: Thursday, January 9, 2020 at 12:56 AM
> To: "Richard Backman, Annabelle" 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
> =20
> I would assume given the status of JAR, we don=E2=80=99t want to change it=
. And as I said, this difference does not impact interoperability from clien=
t perspective.
>=20
>=20
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle :
>=20
> It would be more appropriate to add the text to JAR rather than PAR. It do=
esn't seem right for PAR to retcon rules in JAR. Moving the text to JAR also=
 highlights the weirdness of giving PAR special treatment.
> =20
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
> =20
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
> =20
> This would allow for use cases such as an AS that provides pre-defined req=
uest URIs, or vends request URIs via a client management console, or bakes t=
hem into their client apps.
> =20
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
> =20
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  wrote:
> =20
>     Hi,
>    =20
>     you are right, PAR does not require the AS to represent the request as=
 a JWT-based request object. The URI is used as internal reference only. Tha=
t why the draft states
>    =20
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>   =20
>     This difference matters from an AS implementation perspective, it does=
n't matter from a client's (interop) perspective.
>   =20
>     We may add a statement to PAR saying that request_uris issued by the P=
AR mechanism (MAY) deviate from the JAR definition.
>    =20
>     best regards,
>     Torsten.=20
>    =20
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  wrote:
>     >
>     > Hi all,
>     >=20
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS tr=
ansform all pushed requests into JWTs. This requirement arises from the foll=
owing:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR t=
o communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by reque=
st_uri MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing a=
ll the authorization request parameters. (Section 2.1)
>     >=20
>     > There is no need for this requirement to support interoperability, a=
s this is internal to the AS. It is also inconsistent with the rest of JAR, w=
hich avoids attempting to define the internal communications between the two=
 AS endpoints. Worse, this restriction makes it harder for the authorization=
 endpoint to leverage validation and other work performed at the PAR endpoin=
t, as the state or outcome of that work must be forced into the JWT format (=
or retrieved via a subsequent service call or database lookup).
>     >=20
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >=20
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org
>     > https://www.ietf.org/mailman/listinfo/oauth
>   =20
>    =20

--Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thanks for the text propos=
al. It works for me.

Am 0=
9.01.2020 um 20:34 schrieb Richard Backman, Annabelle <richanna=3D40amazo=
n.com@dmarc.ietf.org>:

=EF=BB=BF









If we address this i=
n PAR, I suggest something along the lines of the following:


 


As defined in [JAR], the request_uri parameter is required to referen=
ce a Request Object JWT. An AS MAY violate this requirement when it is gener=
ating request URIs intended for its
 own consumption (e.g., URIs for pushed requests). This requirement exists t=
o ensure interoperability in cases where the provider of the request_uri is a=
 separate entity from the consumer, such as when a client provides a URI ref=
erencing an object stored on
 the client=E2=80=99s backend service. When the AS is both provider and cons=
umer, this interoperability concern does not apply.


 




=E2=80=93 


Annabelle Richard Backman


AWS Identity




 


 




From: OAuth <oauth-bounces@ietf.org> on behalf of Tor=
sten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>

Date: Thursday, January 9, 2020 at 12:56 AM

To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ie=
tf.org>

Cc: oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs






 






I would assume given the status of JAR, we don=E2=80=99=
t want to change it. And as I said, this difference does not impact interope=
rability from client perspective.















Am 09.01.2020 um 00:58=
 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.o=
rg>:










It would be more appropriate to add the text to JA=
R rather than PAR. It doesn't seem right for PAR to retcon rules in JAR. Mov=
ing the text to JAR also highlights the weirdness of giving PAR special trea=
tment.


 


What if we changed this sentence in Section 5.2 of=
 JAR:


The contents of the resource referenced by the U=
RI MUST be a Request


Object.


 


To: 


The contents of the resource referenced by the U=
RI MUST be a Request


Object, unless the URI was provided to the clie=
nt by the Authorization


Server.


 


This would allow for use cases such as an AS that p=
rovides pre-defined request URIs, or vends request URIs via a client managem=
ent console, or bakes them into their client apps.


 


=E2=80=93 


Annabelle Richard Backman


AWS Identity


 


On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <tors=
ten=3D40lodderstedt.net@dmarc.ietf.org> wrote:


 


    Hi, 


    


    you are right, PAR does no=
t require the AS to represent the request as a JWT-based request object. The=
 URI is used as internal reference only. That why the draft states



    


    "There is no need to make t=
he


        &n=
bsp; authorization request data available to other parties via this


        &n=
bsp; URI.=E2=80=9D


    


    This difference matters fr=
om an AS implementation perspective, it doesn't matter from a client's (inte=
rop) perspective.


    


    We may add a statement to P=
AR saying that request_uris issued by the PAR mechanism (MAY) deviate from t=
he JAR definition.



    


    best regards,

    Torsten.  


    


    > On 8. Jan 2020, at 23=
:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&g=
t; wrote:


    > 


    > Hi all,

    >  


    > The current drafts of=
 PAR (-00) and JAR (-20) require that the AS transform all pushed requests i=
nto JWTs. This requirement arises from the following:


    >     &n=
bsp;   =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to communicate the pushed request to the authorization endpoint.=



    >     &n=
bsp;   =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri MUST be a Request Object. (Section 5.2)


    >     &n=
bsp;   =E2=80=A2 Request Object is defined to be a JWT containing a=
ll the authorization request parameters. (Section 2.1)


    >  


    > There is no need for t=
his requirement to support interoperability, as this is internal to the AS. I=
t is also inconsistent with the rest of JAR, which avoids attempting to defi=
ne the internal communications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to l=
everage validation and other work performed at the PAR endpoint, as the stat=
e or outcome of that work must be forced into the JWT format (or retrieved v=
ia a subsequent service call
 or database lookup).


    >  


    > =E2=80=93 =



    > Annabelle Richard Bac=
kman


    > AWS Identity

    >  


    > _____________________=
__________________________


    > OAuth mailing list


    > OAuth@ietf.org<=
/p>

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


    


    










=

--Apple-Mail-FCC375DD-F111-4AC9-BF56-923327A9D137--


From nobody Thu Jan  9 14:37: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 B1B2A12082F for ; Thu,  9 Jan 2020 14:37:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 jtt3x8QfpCKj for ; Thu,  9 Jan 2020 14:37:43 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF411120807 for ; Thu,  9 Jan 2020 14:37:42 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id m30so6425559lfp.8 for ; Thu, 09 Jan 2020 14:37:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iyN4Ir8Z15gT+IkMEXTthZN5RLQcDK4YT1nfN40gXCA=; b=X5mkxEhIVqURHRp6kajVe3ccs+5/JLPJUFmWIYzj9CGEx2mAHxzn6faE4pRuFOeDWs kbiy/nW6AtrOfpHPdU4L2WwXU5KUk99d/7lIY52X2onk4gW6TqF8LVbqACeEw1U+4522 SbYEVqKuJziYZpzNH/cIxer2FHsCeMcdvyVfhh60FukSr6fadmH4BQ7ARMkhT6alEJIN O6EpPlXmwRbNh6pzHSkIBfrlODdCvPLiwKqcfa4SAicpiLtuuJ8glcwUO1KfoR96BP94 b/Ves54yHpbVR7yNGKA4KI91bhycaQlxTF/vHUEnnNcqmNsET/r4IRfFW1eBk1OShqii oXSg==
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=iyN4Ir8Z15gT+IkMEXTthZN5RLQcDK4YT1nfN40gXCA=; b=sXmde+xYxO7RqiSGtiZ+/fHAPGyM1IJ0Ab9pIUV3renLk2LURH2Lc5ZoVYSpS1jK0t nOXiqtyh8P6r2tBO7zE7phXqL+2vX9djFYpXJ2iNi8dUXlP+ynXhPbWUGVjJpfpDMNzm JiwLJVhVIEsR7cyxVH6ctoI5HmQHNNuRoe7wdzibOvKHYLDVhCfnKr8hWMO/VfWoW1Th CV69uCZZ6jgfjbdBs62ilhzQ026P9SvCH4NLTywCataZajJphP9OGccqTw0kNlJK1Vqp dW8ivpkjzMx7u9z/Fo0Eu7dsvXN1e0+nur+Zc9DkTyHHJhrdMncQSz+QRBjDXNZDhWdt IPkw==
X-Gm-Message-State: APjAAAVRazVIjUhtcemNxmxSdh5FEZ+qxg/Zf2CFr5102NahMCzWGcmk kV+dYGrWqupxKrdkZ5VctI55zY6MVJaxySwJn3Q2BVPJbat58kkaM+2RQhhRph7s2Nbdwc7vtTx QYctlYD0SbLG1ng==
X-Google-Smtp-Source: APXvYqy95xf+W2ILT6F6ehe8qrJ9KiYqR83GNN7TcCacqzZSNlKAhjJiADvuJ1ATsy0/wmfe+7oh+95zEAY184s2uLg=
X-Received: by 2002:ac2:4884:: with SMTP id x4mr66091lfc.92.1578609460914; Thu, 09 Jan 2020 14:37:40 -0800 (PST)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 9 Jan 2020 15:37:14 -0700
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Mike Jones ,  Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000284484059bbca8f4"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 22:37:48 -0000

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

The scenario I described in the beginning of this thread
(response_type=3Dtoken+id_token and response_mode=3Dform_post) started out =
a
bit more humbly as a way to facilitate a simple and efficient cross-domain
sign-on with id_token response type and form_post response mode. Somewhat
analogous to SAML SSO using the POST binding. All the transactional data
flows through the browser in the front channel so no additional calls from
the client/RP to the AS/OP are needed. And no short-lived-transactional
data has to be shared amongst AS nodes (or between geographic locations).
There are some nice aspects to front channel flows.

Then along came the desire to have the ability to periodically refresh the
user attributes associated with the session created off of SSO at the
client/RP so as to have fresh data on which to base access control
decisions. That was done by adding an access token into the mix, hence the
response_type=3Dtoken+id_token with response_mode=3Dform_post, and the RP u=
sing
it to periodically call the user info endpoint. Of course this isn't the
same as an ID-token-only-front-channel SSO but it still retains some of the
same benefits being a mostly front channel flow.

I don't know how niche these cases are or even how often they are actually
put into use in actual deployments. But the token+id_token and form_post
flow was fresh in my mind for unrelated reasons when I was re-reviewing the
security BCP draft, which made me think again about the SHOULD NOT wording
in Section 3.1.2. And that led me to this thread and my proposed text that
would let the SHOULD for using sender-constrained access tokens stand on
its own and adjust the qualification on the SHOULD NOT for implicit style
access tokens to focus on the issues that are particular to those flows.
This doesn't actually change the underlying meaning of the draft because
sender-constrained access tokens are still a SHOULD. But I think it would
make the draft more cohesive in terms of where and why certain
recommendations are made.







On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle <
richanna@amazon.com> wrote:

> Brian and others with similar use cases (Filip?):
>
>
>
> The current text does not prohibit your approach, provided you=E2=80=99ve=
 done the
> due diligence required by BCP 14 to go against a SHOULD NOT. Could you
> provide more detail on the scenarios where you have opted to use these
> implicit-based solutions? Is it impractical or infeasible to use an
> authorization code-based approach in these scenarios? If this is a
> particularly niche use case, then it may not be worth including in the BC=
P
> (that=E2=80=99s basically what SHOULD NOT is for). But if it=E2=80=99s mo=
re broadly
> applicable, then it may be worth tweaking the =E2=80=9Cunless=E2=80=A6=E2=
=80=9D clause of that
> paragraph.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Mike Jones
> 
> *Date: *Saturday, December 28, 2019 at 9:47 AM
> *To: *Brian Campbell , Torsten Lodderstedt
> 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
> response types + form_post response mode
>
>
>
> I agree with Brian's suggested text changes.
>
> -- Mike
> ------------------------------
>
> *From:* Brian Campbell 
> *Sent:* Saturday, December 28, 2019 5:33:24 AM
> *To:* Torsten Lodderstedt 
> *Cc:* Mike Jones ; oauth 
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
> response types + form_post response mode
>
>
>
> The requirement for replay/injection prevention at resource servers is
> still there in section 3.2. This change only drops it as a specific
> qualification on that SHOULD NOT for flows that send access tokens in the
> authorization response. And instead focuses that qualification on the
> additional risks that come with sending access tokens in the authorizatio=
n
> response. To me, this feels more consistent.
>
>
>
> Looking again at section 3, I'd suggest also moving the fourth paragraph
> of section 3.1.2 into section 3.2 so that the description of
> sender-constrained is in the subsection that is about sender-constraining=
.
>
>
>
> On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> Your proposal sounds reasonable on first sight. But thinking again, it
> would mean to keep token injection prevention in authorization responses =
a
> requirement while dropping the requirement for replay/injection preventio=
n
> at resource servers. To me this feels inconsistent.
>
>
>
> Am 28..12.2019 um 00:02 schrieb Brian Campbell  40pingidentity.com@dmarc.ietf.org>:
>
> I'm not suggesting that it should be a recommended flow. But recommending
> against it, as the text does now, seems overreaching and unnecessary. I
> know *consensus* was previously found on the text in -13 but best I can
> recall that discussion was mostly around Nat advocating to allow room for
> some future self-issued IDP type case and the conversation kind of got hu=
ng
> up on that.
>
>
>
> Here's some proposed text, which I think still largely captures the inten=
t
> of the BCP while not explicitly recommending against legitimate cases lik=
e
> the one I brought here or Nat's or something like JARM.
>
>
>
>    In order to avoid these issues, clients SHOULD NOT use the implicit
>    grant (response type "token") or other response types issuing
>    access tokens in the authorization response, unless access token
> injection
>
>    in the authorization response is prevented and the aforementioned toke=
n
> leakage
>
>    vectors are mitigated.
>
>
>
> The draft already recommends sender-constrained access tokens elsewhere i=
n
> the document. It doesn't need to be repeated as a qualifying condition
> around this SHOULD NOT.
>
>
>
> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefull=
y
> is evident from several attempts at bringing/doing related work here) but=
 I
> do worry that the recommendation in the draft is sufficiently unachievabl=
e
> to the vast majority that it might undermine the credibility of the
> document. But I get the aspirational aspect of it and, other than some
> suggested tweaks
> ,
> am resigned to see it stay in the document. But let's let that
> recommendation stand on its own in the document and not also tie it to
> other considerations.
>
>
>
>
>
> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> As Brian said, we have discussed this several times and this text found
> consensus.
>
>
>
> Using post reduces the attack surface but does not allow to bind the
> access token to the legitimate client. We are recommending sender
> constrained access tokens in the BCP. So recommending a flow that does no=
t
> support sender constrained access tokens is a contradiction.
>
>
>
> What do other WG members think?
>
>
>
> Am 27.12.2019 um 21:28 schrieb Mike Jones  40microsoft.com@dmarc.ietf.org>:
>
> I agree with Brian. Please update the text to describe this already safe
> usage.
>
> -- Mike
> ------------------------------
>
> *From:* OAuth  on behalf of Brian Campbell
> 
> *Sent:* Friday, December 27, 2019 11:03:30 AM
> *To:* oauth 
> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response
> types + form_post response mode
>
>
>
> We have a-sometimes used scenario where a client makes an
> authorization/authentication request with a "token id_token" response typ=
e
> and "form_post" response mode (nonce is also sent and exact redirect URI
> matching is done at the AS). The access token is never exposed in any URL=
s
> and access token injection is prevented by the at_hash claim in the id
> token.
>
>
>
> That seems to me like a legitimate and reasonable usage scenario. However=
,
> it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the
> Security BCP-to-be
> ,
> which has:
>
>
>
>    In order to avoid these issues, clients SHOULD NOT use the implicit
>    grant (response type "token") or any other response type issuing
>    access tokens in the authorization response, such as "token id_token"
>    and "code token id_token", unless the issued access tokens are
>    sender-constrained and access token injection in the authorization
>    response is prevented.
>
>
>
> I know this particular text has been discussed over and over again so I
> hate to revisit it. But based on the aforementioned scenario I think mayb=
e
> it still doesn't quite hit the mark. Access token injection is prevented.
> The token leakage scenarios mentioned in that section are all avoided. An=
d
> while I know sender-constrained is recommended elsewhere in the draft, it=
's
> not really a realistic option for the majority of deployments.
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>

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

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


The scenario I described in the beginning of this thr=
ead (response_type=3Dtoken+id_token and response_mode=3Dform_post) started =
out a bit more humbly as a way to facilitate a simple and efficient cross-d=
omain sign-on with id_token response type and form_post response mode. Some=
what analogous to SAML SSO using the POST binding. All the transactional da=
ta flows through the browser in the front channel so no additional calls fr=
om the client/RP to the AS/OP are needed. And no short-lived-transactional =
data has to be shared amongst AS nodes (or between geographic locations).=
=C2=A0 There are some nice aspects to front channel flows. 
<=
br>
Then along came the desire to have the ability to periodicall=
y refresh the user attributes associated with the session created off of SS=
O at the client/RP so as to have fresh data on which to base access control=
 decisions. That was done by adding an access token into the mix, hence the=
 response_type=3Dtoken+id_token with response_mode=3Dform_post, and the RP =
using it to periodically call the user info endpoint. Of course this isn=
9;t the same as an ID-token-only-front-channel  SSO but it still retains so=
me of the same benefits being a mostly front channel flow. 
<=
br>
I don't know how niche these cases are or even how often =
they are actually put into use in actual deployments. But the token+id_toke=
n and form_post flow was fresh in my mind for unrelated reasons when I was =
re-reviewing the security BCP draft, which made me think again about the  S=
HOULD NOT wording in Section 3.1.2. And that led me to this thread and my p=
roposed text that would let the SHOULD for using sender-constrained access =
tokens stand on its own and adjust the qualification on the SHOULD NOT for =
implicit style access tokens to focus on the issues that are particular to =
those flows. This doesn't actually change the underlying meaning of the=
 draft because sender-constrained access tokens are still a SHOULD. But I t=
hink it would make the draft more cohesive in terms of where and why certai=
n recommendations are made. 





 

On Thu, Jan 2, 2020 =
at 2:53 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:











Brian and others with similar use cases (Filip?):=



=C2=A0


The current text does not prohibit your approach, pr=
ovided you=E2=80=99ve done the due diligence required by BCP 14 to go again=
st a SHOULD NOT. Could you provide more detail on the scenarios where you h=
ave opted to use these implicit-based solutions?
 Is it impractical or infeasible to use an authorization code-based approac=
h in these scenarios? If this is a particularly niche use case, then it may=
 not be worth including in the BCP (that=E2=80=99s basically what SHOULD NO=
T is for). But if it=E2=80=99s more broadly applicable,
 then it may be worth tweaking the =E2=80=9Cunless=E2=80=A6=E2=80=9D clause=
 of that paragraph.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>

Date: Saturday, December 28, 2019 at 9:47 AM

To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org>

Cc: oauth <oa=
uth@ietf.org>

Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC resp=
onse types + form_post response mode






=C2=A0






I agree with Brian's sugg=
ested text changes.






-- Mike












From: Brian Campbell <bcampbell@pingidentity.com>

Sent: Saturday, December 28, 2019 5:33:24 AM

To: Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>

Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC resp=
onse types + form_post response mode





=C2=A0












The requirement for replay/injection prevention at r=
esource servers is still there in section 3.2. This change only drops it as=
 a specific qualification on that SHOULD NOT for flows that send access tok=
ens in the authorization response.
 And instead focuses that qualification on the additional risks that come w=
ith sending access tokens in the authorization response. To me, this feels =
more consistent.=C2=A0







=C2=A0






Looking again at section 3, I'd suggest also mov=
ing the fourth paragraph of section 3.1.2 into section 3.2 so that the desc=
ription of sender-constrained is in the subsection that is about sender-con=
straining.=C2=A0











=C2=A0





On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt &l=
t;torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:










Your proposal sounds reasonable on first sight. But =
thinking again, it would mean to keep token injection prevention in authori=
zation responses a requirement while dropping the requirement for replay/in=
jection prevention at resource servers.
 To me this feels inconsistent.















Am 28..12.2019 um 00:02=
 schrieb Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g=
t;:














I'm not suggesting that it should be a recommend=
ed flow. But recommending against it, as the text does now, seems overreach=
ing and unnecessary. I know *consensus* was previously found on the text in=
 -13 but best I can recall that discussion
 was mostly around Nat advocating to allow room for some future self-issued=
 IDP type case and the conversation kind of got hung up on that.







=C2=A0






Here's some proposed text, which I think still l=
argely captures the intent of the BCP while not explicitly recommending aga=
inst legitimate cases like the one I brought here or Nat's or something=
 like JARM.







=C2=A0






=C2=A0=C2=A0 In order to avoid these issues, clients=
 SHOULD NOT use the implicit

=C2=A0 =C2=A0grant (response type "token") or other response type=
s issuing

=C2=A0 =C2=A0access tokens in the authorization response, unless access tok=
en injection






=C2=A0=C2=A0 in the authorization response is preven=
ted and the aforementioned token leakage







=C2=A0=C2=A0 vectors are mitigated. 





=C2=A0






The draft already recommends sender-constrained acce=
ss tokens elsewhere in the document. It doesn't need to be repeated as =
a qualifying condition around this SHOULD NOT.







=C2=A0






I am a proponent of PoP/HoK/sender-constrained acces=
s tokens (as hopefully is evident from several attempts at bringing/doing r=
elated work here) but I do worry that the recommendation in the draft is su=
fficiently unachievable to the vast
 majority that it might undermine the credibility of the document. But I ge=
t the aspirational aspect of it and, other than

some suggested tweaks, am resigned to see it stay in the document. But =
let's let that recommendation stand on its own in the document and not =
also tie it to other considerations.=C2=A0







=C2=A0




=C2=A0






On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:










As Brian said, we have discussed this several times =
and this text found consensus.






=C2=A0






Using post reduces the attack surface but does not a=
llow to bind the access token to the legitimate client. We are recommending=
 sender constrained access tokens in the BCP. So recommending a flow that d=
oes not support sender constrained
 access tokens is a contradiction.






=C2=A0






What do other WG members think?















Am 27.12.2019 um 21:28 =
schrieb Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:<=
/u>












I agree with Brian. Please up=
date the text to describe this already safe usage.






-- Mike<=
/p>











From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com=
@dmarc.ietf.org>

Sent: Friday, December 27, 2019 11:03:30 AM

To: oauth <oauth@ietf.org>

Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response=
 types + form_post response mode





=C2=A0












We have a-sometimes used scenario where a client mak=
es an authorization/authentication request with a "token id_token"=
; response type and "form_post" response mode (nonce is also sent=
 and exact redirect URI matching is done at the AS). The
 access token is never exposed in any URLs and access token injection is pr=
evented by the at_hash claim in the id token.







=C2=A0






That seems to me like a legitimate and reasonable us=
age scenario. However, it would fall on the wrong side of the SHOULD NOT in

Section 3.1.2 of the Security BCP-to-be, which has:




=C2=A0




=C2=A0=C2=A0 In order to avoid these issues, clients=
 SHOULD NOT use the implicit

=C2=A0 =C2=A0grant (response type "token") or any other response =
type issuing

=C2=A0 =C2=A0access tokens in the authorization response, such as "tok=
en id_token"

=C2=A0 =C2=A0and "code token id_token", unless the issued access =
tokens are

=C2=A0 =C2=A0sender-constrained and access token injection in the authoriza=
tion

=C2=A0 =C2=A0response is prevented.






=C2=A0






I know this particular text has been discussed over =
and over again so I hate to revisit it. But based on the aforementioned sce=
nario I think maybe it still doesn't quite hit the mark. Access token i=
njection is prevented. The token leakage
 scenarios mentioned in that section are all avoided. And while I know send=
er-constrained is recommended elsewhere in the draft, it's not really a=
 realistic option for the majority of deployments.









CONFIDENTIALITY NOTICE: This email may contain confide=
ntial 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 communi=
cation in error, please notify the sender immediately by e-mail and delete =
the message and any file attachments from your computer. Thank you.<=
/i>




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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
















CONFIDENTIALITY NOTICE: This email may contain confide=
ntial 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 communi=
cation in error, please notify the sender immediately by e-mail and delete =
the message and any file attachments from your computer. Thank you.<=
/i>


















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













<=
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.
--000000000000284484059bbca8f4--


From nobody Thu Jan  9 15:21: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 B486E12003E for ; Thu,  9 Jan 2020 15:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 B6ucDx0SfYzV for ; Thu,  9 Jan 2020 15:21:09 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650110.outbound.protection.outlook.com [40.107.65.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 A6E1B120831 for ; Thu,  9 Jan 2020 15:21:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HroqyGfaouHpkLplchqYrbTnWPHeKaY3pLZduaOmtn650Ucc4Zuhu4VR/gSpgJfKOrwWdkWx+FEGSEtaDmdFJp/mxVY1ZspW+V24hH/GteGW/n52JsJxDNTh3CS/YIOvO2g0gGincG/uNY4z7jkOBn9WReFt4St8sCOU8uG3wCtRK0lBsNUYnydVgoKSEhPSOijx0R3KRgVbLMA6wNOdCcXyOeHdm98hUftLlUD4zh/fzzXqPEqPnR/p+wvUU0j82gWIsdn6bEQhU2pVz4MQ9bXra8LpztI3jDDNSLluzyBTW+37w4b3VFlC1AqNSiYUL5Fh/WaUR6+jJVdMaOQb6Q==
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=zeL13pAWGGUgQv6hu7k0oRa/8ugehiWUFrYtGLpLZTg=; b=AM473txollWev9x5bdmmxBS4LmaNBKI2FuLMKM+XTnuvK1KX5ZD5S16CGCRs5hQdeRmdoUj1vG7msiaPOV19APwR8UpAX+Z15x/WIz8TiTcCoGQleCtbQO+miHCbHmLl/EcbNDqx8MlfIaKWgolg7O86qgQrA4+blOuYb8kO6GSnpUOuusQwSaDibcW5Ze4P3mmIQ4FEfTx/HkU4tJZWJu6Gq175zN4GDFuTcTHe7UOiYhKXba+8ErIaCdT80T6QQFiUNJRAqoIMkYuznF0UICbnJMT6P1QhSo/ImRPA1gdFUnKJIbjqHW5L5V8N1mR5ruDxqMTHY4T2JgPLm8cFKg==
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=zeL13pAWGGUgQv6hu7k0oRa/8ugehiWUFrYtGLpLZTg=; b=QH8nZte9C0JFwOkiNOSylFfrmwQoDV5zXn3HQ0Li3VZYqvqEvPpOwkiogx23W8cuOgiqY/lHNrcyAYS7xSaUvba4+avsMf8JfQhwcqi5Ukb7RaHNzpgw5pfiMrSqj1mJXr3TnUdfbBf+cRY5EFkH27wHQ1hO+YOe3syU+h9UH5w=
Received: from DM6PR00MB0847.namprd00.prod.outlook.com (20.179.227.78) by DM6PR00MB0767.namprd00.prod.outlook.com (20.179.167.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2666.0; Thu, 9 Jan 2020 23:21:07 +0000
Received: from DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::2d56:644f:3f3e:8c62]) by DM6PR00MB0847.namprd00.prod.outlook.com ([fe80::2d56:644f:3f3e:8c62%4]) with mapi id 15.20.2665.000; Thu, 9 Jan 2020 23:21:07 +0000
From: Mike Jones 
To: Brian Campbell , "Richard Backman, Annabelle" 
CC: Torsten Lodderstedt , oauth 
Thread-Topic: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode
Thread-Index: AdXHQ3JtzqisjXJrTDeTwLHJyIkXiw==
Date: Thu, 9 Jan 2020 23:21:06 +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=6f0bebb7-d3ee-4c8e-85c8-00007c4f4db8; 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-01-09T22:55:25Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.92.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 35cc378d-05f0-4300-ff0b-08d7955a9aac
x-ms-traffictypediagnostic: DM6PR00MB0767:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 02778BF158
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(346002)(366004)(396003)(199004)(189003)(966005)(316002)(9686003)(8676002)(64756008)(71200400001)(66556008)(66476007)(66946007)(55016002)(33656002)(86362001)(66446008)(8990500004)(76116006)(53546011)(30864003)(8936002)(6506007)(52536014)(15650500001)(10290500003)(4326008)(26005)(110136005)(2906002)(66574012)(7696005)(5660300002)(81166006)(81156014)(478600001)(54906003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0767; H:DM6PR00MB0847.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5LQYJHMZ+XqZ6TOe0M3vBv/skg6VG18nqzxb+hchM6giWqXV9JNND7UC8f1DrrOuUNfFaLgZiBQVOvF+db0dEpBgE3c9b2SbiWalay3VW0ck2beBe2y7/r3P23AtpJ3+/IEAGmIM6vXox4Jl8YEZZg2pu7ecCJUXqecgr1wowgza58l4pkq+ZG4BwjxD1/bQBhQK/HtUnf0xuOs/5kxU6UwvzndxQkzlyHxeyg4E3t6VRws5l8Kaib3Vwn2DM4OcrC/oRLQVutf+HoxKpF/I2ELc0pyv62GNoMMJiVndWUXu9FODZKB3HR/CSN4dJeBQ3CUck489tn8s2+DjGvDkx8pSuOs0gqVGCtFlJP2AZOGu+2CRNDq9o7PdwwVHgpo3mkQ4opFsKuzlycbYZRhwS23RB5CSxOwiWrNKF9jZlIwVl5za6jI9cqIfZundc1UZhhWOSe2zMrUvZX/EKdwm2Pl12jrgW/aPH9uhrW/P7+kGF9+TXirbfVYLtHVY+3dJwGl+2aPRRuahTcH77lJNew==
x-ms-exchange-antispam-messagedata: bJV7f4HteJaVsS/3f4wcNtYPvO0yhLehXMUn1n9Jry6ejxRCzE29nV4SlcN94lGWQeMBObJxOO/X/u5HQnxXY5/OfwS9hfXJ37VdXWUMZ+Kjr/mDAJHkU6wHOJ8IveuVUtTN/I5Tmieh27pZtE6fww==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB084783B6C945B33DE42BE1D0F5390DM6PR00MB0847namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35cc378d-05f0-4300-ff0b-08d7955a9aac
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 23:21:06.9245 (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: Zz74SBJ/iyH02wtwXSKf7jDRDk/Ryx+Ja3YLc98Yo1Dju8Oh2gpFDmcLybWh04bOeCUsdrFSX/lzFFyxlicn0A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0767
Archived-At: 
Subject: Re: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode
X-BeenThere: oauth@ietf.org
X-Mailman-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, 09 Jan 2020 23:21:13 -0000

--_000_DM6PR00MB084783B6C945B33DE42BE1D0F5390DM6PR00MB0847namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggQnJpYW7igJlzIGFuYWx5c2lzIGFuZCBzdWdnZXN0aW9u
cy4NCg0KRllJLCBhcyBmYXIgYXMgaG93IGNvbW1vbiB0aGlzIHBhdHRlcm4gaXMsIOKAnGlkX3Rv
a2VuIHRva2Vu4oCdIHdpdGggdGhlIEZvcm0gUG9zdCBSZXNwb25zZSBNb2RlIGlzIHRoZSBkZWZh
dWx0IGZvciBNaWNyb3NvZnQgQXp1cmUgQWN0aXZlIERpcmVjdG9yeSBpZGVudGl0eSBpbnRlcmFj
dGlvbnMuICBZb3UgY2FuIHZpZXcgQWxleCBTaW1vbuKAmXMgSWRlbnRpdmVyc2UgcHJlc2VudGF0
aW9ucywgaW5jbHVkaW5nIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9YjJfTjVYc202
QzgmbGlzdD1QTHBLcTd4UmlJSGFRWnpnLWEwZkZnMDh5SDAwemZPOXc5JmluZGV4PTMsIHRvIGdl
dCBhIHNlbnNlIG9mIGhvdyBmcmVxdWVudGx5IHRoaXMgaXMgdXNlZC4gIEFzIGhlIGRlc2NyaWJl
cyBiZXR3ZWVuIDc6NDAtOToyNiBpbiB0aGlzIHByZXNlbnRhdGlvbiwgd2XigJlyZSBkb2luZyBh
cHByb3hpbWF0ZWx5IDIwIGJpbGxpb24gYXV0aGVudGljYXRpb25zIHBlciBkYXkgdXNpbmcgT0F1
dGggMi4wIHdpdGggT3BlbklEIENvbm5lY3QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEJyaWFuIENhbXBi
ZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPg0KU2VudDog
VGh1cnNkYXksIEphbnVhcnkgOSwgMjAyMCAyOjM3IFBNDQpUbzogUmljaGFyZCBCYWNrbWFuLCBB
bm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb20+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPjsgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJz
dGVkdC5uZXQ+OyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURDIHJlc3BvbnNlIHR5cGVzICsgZm9ybV9wb3N0
IHJlc3BvbnNlIG1vZGUNCg0KVGhlIHNjZW5hcmlvIEkgZGVzY3JpYmVkIGluIHRoZSBiZWdpbm5p
bmcgb2YgdGhpcyB0aHJlYWQgKHJlc3BvbnNlX3R5cGU9dG9rZW4raWRfdG9rZW4gYW5kIHJlc3Bv
bnNlX21vZGU9Zm9ybV9wb3N0KSBzdGFydGVkIG91dCBhIGJpdCBtb3JlIGh1bWJseSBhcyBhIHdh
eSB0byBmYWNpbGl0YXRlIGEgc2ltcGxlIGFuZCBlZmZpY2llbnQgY3Jvc3MtZG9tYWluIHNpZ24t
b24gd2l0aCBpZF90b2tlbiByZXNwb25zZSB0eXBlIGFuZCBmb3JtX3Bvc3QgcmVzcG9uc2UgbW9k
ZS4gU29tZXdoYXQgYW5hbG9nb3VzIHRvIFNBTUwgU1NPIHVzaW5nIHRoZSBQT1NUIGJpbmRpbmcu
IEFsbCB0aGUgdHJhbnNhY3Rpb25hbCBkYXRhIGZsb3dzIHRocm91Z2ggdGhlIGJyb3dzZXIgaW4g
dGhlIGZyb250IGNoYW5uZWwgc28gbm8gYWRkaXRpb25hbCBjYWxscyBmcm9tIHRoZSBjbGllbnQv
UlAgdG8gdGhlIEFTL09QIGFyZSBuZWVkZWQuIEFuZCBubyBzaG9ydC1saXZlZC10cmFuc2FjdGlv
bmFsIGRhdGEgaGFzIHRvIGJlIHNoYXJlZCBhbW9uZ3N0IEFTIG5vZGVzIChvciBiZXR3ZWVuIGdl
b2dyYXBoaWMgbG9jYXRpb25zKS4gIFRoZXJlIGFyZSBzb21lIG5pY2UgYXNwZWN0cyB0byBmcm9u
dCBjaGFubmVsIGZsb3dzLg0KDQpUaGVuIGFsb25nIGNhbWUgdGhlIGRlc2lyZSB0byBoYXZlIHRo
ZSBhYmlsaXR5IHRvIHBlcmlvZGljYWxseSByZWZyZXNoIHRoZSB1c2VyIGF0dHJpYnV0ZXMgYXNz
b2NpYXRlZCB3aXRoIHRoZSBzZXNzaW9uIGNyZWF0ZWQgb2ZmIG9mIFNTTyBhdCB0aGUgY2xpZW50
L1JQIHNvIGFzIHRvIGhhdmUgZnJlc2ggZGF0YSBvbiB3aGljaCB0byBiYXNlIGFjY2VzcyBjb250
cm9sIGRlY2lzaW9ucy4gVGhhdCB3YXMgZG9uZSBieSBhZGRpbmcgYW4gYWNjZXNzIHRva2VuIGlu
dG8gdGhlIG1peCwgaGVuY2UgdGhlIHJlc3BvbnNlX3R5cGU9dG9rZW4raWRfdG9rZW4gd2l0aCBy
ZXNwb25zZV9tb2RlPWZvcm1fcG9zdCwgYW5kIHRoZSBSUCB1c2luZyBpdCB0byBwZXJpb2RpY2Fs
bHkgY2FsbCB0aGUgdXNlciBpbmZvIGVuZHBvaW50LiBPZiBjb3Vyc2UgdGhpcyBpc24ndCB0aGUg
c2FtZSBhcyBhbiBJRC10b2tlbi1vbmx5LWZyb250LWNoYW5uZWwgU1NPIGJ1dCBpdCBzdGlsbCBy
ZXRhaW5zIHNvbWUgb2YgdGhlIHNhbWUgYmVuZWZpdHMgYmVpbmcgYSBtb3N0bHkgZnJvbnQgY2hh
bm5lbCBmbG93Lg0KDQpJIGRvbid0IGtub3cgaG93IG5pY2hlIHRoZXNlIGNhc2VzIGFyZSBvciBl
dmVuIGhvdyBvZnRlbiB0aGV5IGFyZSBhY3R1YWxseSBwdXQgaW50byB1c2UgaW4gYWN0dWFsIGRl
cGxveW1lbnRzLiBCdXQgdGhlIHRva2VuK2lkX3Rva2VuIGFuZCBmb3JtX3Bvc3QgZmxvdyB3YXMg
ZnJlc2ggaW4gbXkgbWluZCBmb3IgdW5yZWxhdGVkIHJlYXNvbnMgd2hlbiBJIHdhcyByZS1yZXZp
ZXdpbmcgdGhlIHNlY3VyaXR5IEJDUCBkcmFmdCwgd2hpY2ggbWFkZSBtZSB0aGluayBhZ2FpbiBh
Ym91dCB0aGUgU0hPVUxEIE5PVCB3b3JkaW5nIGluIFNlY3Rpb24gMy4xLjIuIEFuZCB0aGF0IGxl
ZCBtZSB0byB0aGlzIHRocmVhZCBhbmQgbXkgcHJvcG9zZWQgdGV4dCB0aGF0IHdvdWxkIGxldCB0
aGUgU0hPVUxEIGZvciB1c2luZyBzZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBzdGFu
ZCBvbiBpdHMgb3duIGFuZCBhZGp1c3QgdGhlIHF1YWxpZmljYXRpb24gb24gdGhlIFNIT1VMRCBO
T1QgZm9yIGltcGxpY2l0IHN0eWxlIGFjY2VzcyB0b2tlbnMgdG8gZm9jdXMgb24gdGhlIGlzc3Vl
cyB0aGF0IGFyZSBwYXJ0aWN1bGFyIHRvIHRob3NlIGZsb3dzLiBUaGlzIGRvZXNuJ3QgYWN0dWFs
bHkgY2hhbmdlIHRoZSB1bmRlcmx5aW5nIG1lYW5pbmcgb2YgdGhlIGRyYWZ0IGJlY2F1c2Ugc2Vu
ZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgYXJlIHN0aWxsIGEgU0hPVUxELiBCdXQgSSB0
aGluayBpdCB3b3VsZCBtYWtlIHRoZSBkcmFmdCBtb3JlIGNvaGVzaXZlIGluIHRlcm1zIG9mIHdo
ZXJlIGFuZCB3aHkgY2VydGFpbiByZWNvbW1lbmRhdGlvbnMgYXJlIG1hZGUuDQoNCg0KDQoNCg0K
DQoNCk9uIFRodSwgSmFuIDIsIDIwMjAgYXQgMjo1MyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFi
ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLi5jb20+PiB3
cm90ZToNCkJyaWFuIGFuZCBvdGhlcnMgd2l0aCBzaW1pbGFyIHVzZSBjYXNlcyAoRmlsaXA/KToN
Cg0KVGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBwcm9oaWJpdCB5b3VyIGFwcHJvYWNoLCBwcm92
aWRlZCB5b3XigJl2ZSBkb25lIHRoZSBkdWUgZGlsaWdlbmNlIHJlcXVpcmVkIGJ5IEJDUCAxNCB0
byBnbyBhZ2FpbnN0IGEgU0hPVUxEIE5PVC4gQ291bGQgeW91IHByb3ZpZGUgbW9yZSBkZXRhaWwg
b24gdGhlIHNjZW5hcmlvcyB3aGVyZSB5b3UgaGF2ZSBvcHRlZCB0byB1c2UgdGhlc2UgaW1wbGlj
aXQtYmFzZWQgc29sdXRpb25zPyBJcyBpdCBpbXByYWN0aWNhbCBvciBpbmZlYXNpYmxlIHRvIHVz
ZSBhbiBhdXRob3JpemF0aW9uIGNvZGUtYmFzZWQgYXBwcm9hY2ggaW4gdGhlc2Ugc2NlbmFyaW9z
PyBJZiB0aGlzIGlzIGEgcGFydGljdWxhcmx5IG5pY2hlIHVzZSBjYXNlLCB0aGVuIGl0IG1heSBu
b3QgYmUgd29ydGggaW5jbHVkaW5nIGluIHRoZSBCQ1AgKHRoYXTigJlzIGJhc2ljYWxseSB3aGF0
IFNIT1VMRCBOT1QgaXMgZm9yKS4gQnV0IGlmIGl04oCZcyBtb3JlIGJyb2FkbHkgYXBwbGljYWJs
ZSwgdGhlbiBpdCBtYXkgYmUgd29ydGggdHdlYWtpbmcgdGhlIOKAnHVubGVzc+KApuKAnSBjbGF1
c2Ugb2YgdGhhdCBwYXJhZ3JhcGguDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0K
QVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9z
b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBTYXR1cmRheSwgRGVjZW1iZXIgMjgsIDIw
MTkgYXQgOTo0NyBBTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiwgVG9yc3RlbiBMb2RkZXJz
dGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBs
b2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW0VYVEVS
TkFMXSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURDIHJlc3BvbnNlIHR5cGVzICsgZm9ybV9w
b3N0IHJlc3BvbnNlIG1vZGUNCg0KSSBhZ3JlZSB3aXRoIEJyaWFuJ3Mgc3VnZ2VzdGVkIHRleHQg
Y2hhbmdlcy4NCi0tIE1pa2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t
OiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1w
YmVsbEBwaW5naWRlbnRpdHkuY29tPj4NClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOCwgMjAx
OSA1OjMzOjI0IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0
ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0
Zi5vcmc+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls
dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW0VYVEVSTkFM
XSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURDIHJlc3BvbnNlIHR5cGVzICsgZm9ybV9wb3N0
IHJlc3BvbnNlIG1vZGUNCg0KVGhlIHJlcXVpcmVtZW50IGZvciByZXBsYXkvaW5qZWN0aW9uIHBy
ZXZlbnRpb24gYXQgcmVzb3VyY2Ugc2VydmVycyBpcyBzdGlsbCB0aGVyZSBpbiBzZWN0aW9uIDMu
Mi4gVGhpcyBjaGFuZ2Ugb25seSBkcm9wcyBpdCBhcyBhIHNwZWNpZmljIHF1YWxpZmljYXRpb24g
b24gdGhhdCBTSE9VTEQgTk9UIGZvciBmbG93cyB0aGF0IHNlbmQgYWNjZXNzIHRva2VucyBpbiB0
aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4gQW5kIGluc3RlYWQgZm9jdXNlcyB0aGF0IHF1YWxp
ZmljYXRpb24gb24gdGhlIGFkZGl0aW9uYWwgcmlza3MgdGhhdCBjb21lIHdpdGggc2VuZGluZyBh
Y2Nlc3MgdG9rZW5zIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlLiBUbyBtZSwgdGhpcyBm
ZWVscyBtb3JlIGNvbnNpc3RlbnQuDQoNCkxvb2tpbmcgYWdhaW4gYXQgc2VjdGlvbiAzLCBJJ2Qg
c3VnZ2VzdCBhbHNvIG1vdmluZyB0aGUgZm91cnRoIHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuMS4y
IGludG8gc2VjdGlvbiAzLjIgc28gdGhhdCB0aGUgZGVzY3JpcHRpb24gb2Ygc2VuZGVyLWNvbnN0
cmFpbmVkIGlzIGluIHRoZSBzdWJzZWN0aW9uIHRoYXQgaXMgYWJvdXQgc2VuZGVyLWNvbnN0cmFp
bmluZy4NCg0KT24gRnJpLCBEZWMgMjcsIDIwMTksIDU6MDAgUE0gVG9yc3RlbiBMb2RkZXJzdGVk
dCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2Rk
ZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCllvdXIgcHJvcG9zYWwgc291bmRz
IHJlYXNvbmFibGUgb24gZmlyc3Qgc2lnaHQuIEJ1dCB0aGlua2luZyBhZ2FpbiwgaXQgd291bGQg
bWVhbiB0byBrZWVwIHRva2VuIGluamVjdGlvbiBwcmV2ZW50aW9uIGluIGF1dGhvcml6YXRpb24g
cmVzcG9uc2VzIGEgcmVxdWlyZW1lbnQgd2hpbGUgZHJvcHBpbmcgdGhlIHJlcXVpcmVtZW50IGZv
ciByZXBsYXkvaW5qZWN0aW9uIHByZXZlbnRpb24gYXQgcmVzb3VyY2Ugc2VydmVycy4gVG8gbWUg
dGhpcyBmZWVscyBpbmNvbnNpc3RlbnQuDQoNCkFtIDI4Li4xMi4yMDE5IHVtIDAwOjAyIHNjaHJp
ZWIgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0
Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+Og0KSSdtIG5v
dCBzdWdnZXN0aW5nIHRoYXQgaXQgc2hvdWxkIGJlIGEgcmVjb21tZW5kZWQgZmxvdy4gQnV0IHJl
Y29tbWVuZGluZyBhZ2FpbnN0IGl0LCBhcyB0aGUgdGV4dCBkb2VzIG5vdywgc2VlbXMgb3ZlcnJl
YWNoaW5nIGFuZCB1bm5lY2Vzc2FyeS4gSSBrbm93ICpjb25zZW5zdXMqIHdhcyBwcmV2aW91c2x5
IGZvdW5kIG9uIHRoZSB0ZXh0IGluIC0xMyBidXQgYmVzdCBJIGNhbiByZWNhbGwgdGhhdCBkaXNj
dXNzaW9uIHdhcyBtb3N0bHkgYXJvdW5kIE5hdCBhZHZvY2F0aW5nIHRvIGFsbG93IHJvb20gZm9y
IHNvbWUgZnV0dXJlIHNlbGYtaXNzdWVkIElEUCB0eXBlIGNhc2UgYW5kIHRoZSBjb252ZXJzYXRp
b24ga2luZCBvZiBnb3QgaHVuZyB1cCBvbiB0aGF0Lg0KDQpIZXJlJ3Mgc29tZSBwcm9wb3NlZCB0
ZXh0LCB3aGljaCBJIHRoaW5rIHN0aWxsIGxhcmdlbHkgY2FwdHVyZXMgdGhlIGludGVudCBvZiB0
aGUgQkNQIHdoaWxlIG5vdCBleHBsaWNpdGx5IHJlY29tbWVuZGluZyBhZ2FpbnN0IGxlZ2l0aW1h
dGUgY2FzZXMgbGlrZSB0aGUgb25lIEkgYnJvdWdodCBoZXJlIG9yIE5hdCdzIG9yIHNvbWV0aGlu
ZyBsaWtlIEpBUk0uDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIHRoZXNlIGlzc3VlcywgY2xpZW50
cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQNCiAgIGdyYW50IChyZXNwb25zZSB0eXBlICJ0
b2tlbiIpIG9yIG90aGVyIHJlc3BvbnNlIHR5cGVzIGlzc3VpbmcNCiAgIGFjY2VzcyB0b2tlbnMg
aW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHVubGVzcyBhY2Nlc3MgdG9rZW4gaW5qZWN0
aW9uDQogICBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBpcyBwcmV2ZW50ZWQgYW5kIHRo
ZSBhZm9yZW1lbnRpb25lZCB0b2tlbiBsZWFrYWdlDQogICB2ZWN0b3JzIGFyZSBtaXRpZ2F0ZWQu
DQoNClRoZSBkcmFmdCBhbHJlYWR5IHJlY29tbWVuZHMgc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2Vz
cyB0b2tlbnMgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudC4gSXQgZG9lc24ndCBuZWVkIHRvIGJl
IHJlcGVhdGVkIGFzIGEgcXVhbGlmeWluZyBjb25kaXRpb24gYXJvdW5kIHRoaXMgU0hPVUxEIE5P
VC4NCg0KSSBhbSBhIHByb3BvbmVudCBvZiBQb1AvSG9LL3NlbmRlci1jb25zdHJhaW5lZCBhY2Nl
c3MgdG9rZW5zIChhcyBob3BlZnVsbHkgaXMgZXZpZGVudCBmcm9tIHNldmVyYWwgYXR0ZW1wdHMg
YXQgYnJpbmdpbmcvZG9pbmcgcmVsYXRlZCB3b3JrIGhlcmUpIGJ1dCBJIGRvIHdvcnJ5IHRoYXQg
dGhlIHJlY29tbWVuZGF0aW9uIGluIHRoZSBkcmFmdCBpcyBzdWZmaWNpZW50bHkgdW5hY2hpZXZh
YmxlIHRvIHRoZSB2YXN0IG1ham9yaXR5IHRoYXQgaXQgbWlnaHQgdW5kZXJtaW5lIHRoZSBjcmVk
aWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQuIEJ1dCBJIGdldCB0aGUgYXNwaXJhdGlvbmFsIGFzcGVj
dCBvZiBpdCBhbmQsIG90aGVyIHRoYW4gc29tZSBzdWdnZXN0ZWQgdHdlYWtzPGh0dHBzOi8vbmFt
MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1h
aWxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRm9hdXRoJTJGUkt1ak9OZWotOTJkVDVs
cjljTHU2aEhudzhJJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t
JTdDOTdjMGViMThhZTZkNGZiZDE4OTcwOGQ3OTU1NDhlZDclN0M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQyMDYyNzE5MzEzNTMyJnNkYXRhPU92QUxSZlJ6
ZmN2SWs0Tlc3bFl0bkY3bU82dWpVM2NPMU8wT0glMkZRVkhGYyUzRCZyZXNlcnZlZD0wPiwgYW0g
cmVzaWduZWQgdG8gc2VlIGl0IHN0YXkgaW4gdGhlIGRvY3VtZW50LiBCdXQgbGV0J3MgbGV0IHRo
YXQgcmVjb21tZW5kYXRpb24gc3RhbmQgb24gaXRzIG93biBpbiB0aGUgZG9jdW1lbnQgYW5kIG5v
dCBhbHNvIHRpZSBpdCB0byBvdGhlciBjb25zaWRlcmF0aW9ucy4NCg0KDQpPbiBGcmksIERlYyAy
NywgMjAxOSBhdCAxOjQxIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJz
dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmll
dGYub3JnPj4gd3JvdGU6DQpBcyBCcmlhbiBzYWlkLCB3ZSBoYXZlIGRpc2N1c3NlZCB0aGlzIHNl
dmVyYWwgdGltZXMgYW5kIHRoaXMgdGV4dCBmb3VuZCBjb25zZW5zdXMuDQoNClVzaW5nIHBvc3Qg
cmVkdWNlcyB0aGUgYXR0YWNrIHN1cmZhY2UgYnV0IGRvZXMgbm90IGFsbG93IHRvIGJpbmQgdGhl
IGFjY2VzcyB0b2tlbiB0byB0aGUgbGVnaXRpbWF0ZSBjbGllbnQuIFdlIGFyZSByZWNvbW1lbmRp
bmcgc2VuZGVyIGNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgaW4gdGhlIEJDUC4gU28gcmVjb21t
ZW5kaW5nIGEgZmxvdyB0aGF0IGRvZXMgbm90IHN1cHBvcnQgc2VuZGVyIGNvbnN0cmFpbmVkIGFj
Y2VzcyB0b2tlbnMgaXMgYSBjb250cmFkaWN0aW9uLg0KDQpXaGF0IGRvIG90aGVyIFdHIG1lbWJl
cnMgdGhpbms/DQoNCkFtIDI3LjEyLjIwMTkgdW0gMjE6Mjggc2NocmllYiBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNy
b3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj46DQpJIGFncmVlIHdpdGggQnJpYW4uIFBsZWFzZSB1
cGRhdGUgdGhlIHRleHQgdG8gZGVzY3JpYmUgdGhpcyBhbHJlYWR5IHNhZmUgdXNhZ2UuDQotLSBN
aWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogT0F1dGggPG9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh
bGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu
aWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50
OiBGcmlkYXksIERlY2VtYmVyIDI3LCAyMDE5IDExOjAzOjMwIEFNDQpUbzogb2F1dGggPG9hdXRo
QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFtP
QVVUSC1XR10gLXNlY3VyaXR5LXRvcGljcy0xMyBhbmQgT0lEQyByZXNwb25zZSB0eXBlcyArIGZv
cm1fcG9zdCByZXNwb25zZSBtb2RlDQoNCldlIGhhdmUgYS1zb21ldGltZXMgdXNlZCBzY2VuYXJp
byB3aGVyZSBhIGNsaWVudCBtYWtlcyBhbiBhdXRob3JpemF0aW9uL2F1dGhlbnRpY2F0aW9uIHJl
cXVlc3Qgd2l0aCBhICJ0b2tlbiBpZF90b2tlbiIgcmVzcG9uc2UgdHlwZSBhbmQgImZvcm1fcG9z
dCIgcmVzcG9uc2UgbW9kZSAobm9uY2UgaXMgYWxzbyBzZW50IGFuZCBleGFjdCByZWRpcmVjdCBV
UkkgbWF0Y2hpbmcgaXMgZG9uZSBhdCB0aGUgQVMpLiBUaGUgYWNjZXNzIHRva2VuIGlzIG5ldmVy
IGV4cG9zZWQgaW4gYW55IFVSTHMgYW5kIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaXMgcHJldmVu
dGVkIGJ5IHRoZSBhdF9oYXNoIGNsYWltIGluIHRoZSBpZCB0b2tlbi4NCg0KVGhhdCBzZWVtcyB0
byBtZSBsaWtlIGEgbGVnaXRpbWF0ZSBhbmQgcmVhc29uYWJsZSB1c2FnZSBzY2VuYXJpby4gSG93
ZXZlciwgaXQgd291bGQgZmFsbCBvbiB0aGUgd3Jvbmcgc2lkZSBvZiB0aGUgU0hPVUxEIE5PVCBp
biBTZWN0aW9uIDMuMS4yIG9mIHRoZSBTZWN1cml0eSBCQ1AtdG8tYmU8aHR0cHM6Ly9uYW0wNi5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMu
aWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTMlMjNz
ZWN0aW9uLTMuLi4uMS4uMiZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0
LmNvbSU3Qzk3YzBlYjE4YWU2ZDRmYmQxODk3MDhkNzk1NTQ4ZWQ3JTdDNzJmOTg4YmY4NmYxNDFh
ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE0MjA2MjcxOTMxMzUzMiZzZGF0YT1iNm1V
dlgwVzBoZjZIOGt0S2RUNHZFUWxmajdGVWpzT0lPN0lIcENmJTJGWXMlM0QmcmVzZXJ2ZWQ9MD4s
IHdoaWNoIGhhczoNCg0KICAgSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaXNzdWVzLCBjbGllbnRz
IFNIT1VMRCBOT1QgdXNlIHRoZSBpbXBsaWNpdA0KICAgZ3JhbnQgKHJlc3BvbnNlIHR5cGUgInRv
a2VuIikgb3IgYW55IG90aGVyIHJlc3BvbnNlIHR5cGUgaXNzdWluZw0KICAgYWNjZXNzIHRva2Vu
cyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgc3VjaCBhcyAidG9rZW4gaWRfdG9rZW4i
DQogICBhbmQgImNvZGUgdG9rZW4gaWRfdG9rZW4iLCB1bmxlc3MgdGhlIGlzc3VlZCBhY2Nlc3Mg
dG9rZW5zIGFyZQ0KICAgc2VuZGVyLWNvbnN0cmFpbmVkIGFuZCBhY2Nlc3MgdG9rZW4gaW5qZWN0
aW9uIGluIHRoZSBhdXRob3JpemF0aW9uDQogICByZXNwb25zZSBpcyBwcmV2ZW50ZWQuDQoNCkkg
a25vdyB0aGlzIHBhcnRpY3VsYXIgdGV4dCBoYXMgYmVlbiBkaXNjdXNzZWQgb3ZlciBhbmQgb3Zl
ciBhZ2FpbiBzbyBJIGhhdGUgdG8gcmV2aXNpdCBpdC4gQnV0IGJhc2VkIG9uIHRoZSBhZm9yZW1l
bnRpb25lZCBzY2VuYXJpbyBJIHRoaW5rIG1heWJlIGl0IHN0aWxsIGRvZXNuJ3QgcXVpdGUgaGl0
IHRoZSBtYXJrLiBBY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGlzIHByZXZlbnRlZC4gVGhlIHRva2Vu
IGxlYWthZ2Ugc2NlbmFyaW9zIG1lbnRpb25lZCBpbiB0aGF0IHNlY3Rpb24gYXJlIGFsbCBhdm9p
ZGVkLiBBbmQgd2hpbGUgSSBrbm93IHNlbmRlci1jb25zdHJhaW5lZCBpcyByZWNvbW1lbmRlZCBl
bHNld2hlcmUgaW4gdGhlIGRyYWZ0LCBpdCdzIG5vdCByZWFsbHkgYSByZWFsaXN0aWMgb3B0aW9u
IGZvciB0aGUgbWFqb3JpdHkgb2YgZGVwbG95bWVudHMuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ
Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h
dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4uIEFu
eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0
cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0
aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1t
YWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20g
eW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91
cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0
aCZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Qzk3YzBlYjE4
YWU2ZDRmYmQxODk3MDhkNzk1NTQ4ZWQ3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN0MxJTdDMCU3QzYzNzE0MjA2MjcxOTMyMzUyMyZzZGF0YT1KRXc1QkslMkZNR3pWd0tlcW1v
ZnUzU3BRMFNMem9kc1kwVzhlS1pXOVFsWDAlM0QmcmVzZXJ2ZWQ9MD4NCg0KQ09ORklERU5USUFM
SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp
bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50
KHMpLi4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhl
cnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNv
bW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs
eSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVu
dHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ
Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h
dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4uIEFu
eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0
cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp
b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h
aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5
b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg
ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv
ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywg
dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv
aGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy
b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl
bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1
dGVyLiBUaGFuayB5b3UuDQo=

--_000_DM6PR00MB084783B6C945B33DE42BE1D0F5390DM6PR00MB0847namp_
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
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6LWFwcGxlLXN5
c3RlbTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUx
OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w
aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgY29tcGxldGVseSBhZ3JlZSB3aXRoIEJy
aWFu4oCZcyBhbmFseXNpcyBhbmQgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDAyMDYwIj5GWUksIGFzIGZhciBhcyBob3cgY29tbW9uIHRoaXMgcGF0dGVybiBpcywg
4oCcaWRfdG9rZW4gdG9rZW7igJ0gd2l0aCB0aGUgRm9ybSBQb3N0IFJlc3BvbnNlIE1vZGUgaXMg
dGhlIGRlZmF1bHQgZm9yIE1pY3Jvc29mdCBBenVyZSBBY3RpdmUgRGlyZWN0b3J5IGlkZW50aXR5
IGludGVyYWN0aW9ucy4mbmJzcDsgWW91IGNhbiB2aWV3IEFsZXggU2ltb27igJlzIElkZW50aXZl
cnNlIHByZXNlbnRhdGlvbnMsDQogaW5jbHVkaW5nIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1iMl9ONVhz
bTZDOCZhbXA7bGlzdD1QTHBLcTd4UmlJSGFRWnpnLWEwZkZnMDh5SDAwemZPOXc5JmFtcDtpbmRl
eD0zIj5odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PWIyX041WHNtNkM4JmFtcDtsaXN0
PVBMcEtxN3hSaUlIYVFaemctYTBmRmcwOHlIMDB6Zk85dzkmYW1wO2luZGV4PTM8L2E+LDwvc3Bh
bj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+DQogdG8gZ2V0IGEgc2Vuc2Ugb2YgaG93IGZy
ZXF1ZW50bHkgdGhpcyBpcyB1c2VkLiAmbmJzcDtBcyBoZSBkZXNjcmliZXMgYmV0d2VlbiA3OjQw
LTk6MjYgaW4gdGhpcyBwcmVzZW50YXRpb24sIHdl4oCZcmUgZG9pbmcgYXBwcm94aW1hdGVseSAy
MCBiaWxsaW9uIGF1dGhlbnRpY2F0aW9ucyBwZXIgZGF5IHVzaW5nIE9BdXRoIDIuMCB3aXRoIE9w
ZW5JRCBDb25uZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv
bTo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRt
YXJjLmlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDks
IDIwMjAgMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg
Jmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZs
dDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBUb3JzdGVuIExvZGRlcnN0ZWR0ICZs
dDt0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gLXNlY3VyaXR5LXRvcGljcy0x
MyBhbmQgT0lEQyByZXNwb25zZSB0eXBlcyAmIzQzOyBmb3JtX3Bvc3QgcmVzcG9uc2UgbW9kZTxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzY2VuYXJpbyBJIGRlc2Ny
aWJlZCBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgdGhyZWFkIChyZXNwb25zZV90eXBlPXRva2Vu
JiM0MztpZF90b2tlbiBhbmQgcmVzcG9uc2VfbW9kZT1mb3JtX3Bvc3QpIHN0YXJ0ZWQgb3V0IGEg
Yml0IG1vcmUgaHVtYmx5IGFzIGEgd2F5IHRvIGZhY2lsaXRhdGUgYSBzaW1wbGUgYW5kIGVmZmlj
aWVudCBjcm9zcy1kb21haW4gc2lnbi1vbiB3aXRoIGlkX3Rva2VuIHJlc3BvbnNlDQogdHlwZSBh
bmQgZm9ybV9wb3N0IHJlc3BvbnNlIG1vZGUuIFNvbWV3aGF0IGFuYWxvZ291cyB0byBTQU1MIFNT
TyB1c2luZyB0aGUgUE9TVCBiaW5kaW5nLiBBbGwgdGhlIHRyYW5zYWN0aW9uYWwgZGF0YSBmbG93
cyB0aHJvdWdoIHRoZSBicm93c2VyIGluIHRoZSBmcm9udCBjaGFubmVsIHNvIG5vIGFkZGl0aW9u
YWwgY2FsbHMgZnJvbSB0aGUgY2xpZW50L1JQIHRvIHRoZSBBUy9PUCBhcmUgbmVlZGVkLiBBbmQg
bm8gc2hvcnQtbGl2ZWQtdHJhbnNhY3Rpb25hbA0KIGRhdGEgaGFzIHRvIGJlIHNoYXJlZCBhbW9u
Z3N0IEFTIG5vZGVzIChvciBiZXR3ZWVuIGdlb2dyYXBoaWMgbG9jYXRpb25zKS4mbmJzcDsgVGhl
cmUgYXJlIHNvbWUgbmljZSBhc3BlY3RzIHRvIGZyb250IGNoYW5uZWwgZmxvd3MuDQo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBhbG9u
ZyBjYW1lIHRoZSBkZXNpcmUgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byBwZXJpb2RpY2FsbHkgcmVm
cmVzaCB0aGUgdXNlciBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2Vzc2lvbiBjcmVh
dGVkIG9mZiBvZiBTU08gYXQgdGhlIGNsaWVudC9SUCBzbyBhcyB0byBoYXZlIGZyZXNoIGRhdGEg
b24gd2hpY2ggdG8gYmFzZSBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbnMuIFRoYXQgd2FzIGRvbmUN
CiBieSBhZGRpbmcgYW4gYWNjZXNzIHRva2VuIGludG8gdGhlIG1peCwgaGVuY2UgdGhlIHJlc3Bv
bnNlX3R5cGU9dG9rZW4mIzQzO2lkX3Rva2VuIHdpdGggcmVzcG9uc2VfbW9kZT1mb3JtX3Bvc3Qs
IGFuZCB0aGUgUlAgdXNpbmcgaXQgdG8gcGVyaW9kaWNhbGx5IGNhbGwgdGhlIHVzZXIgaW5mbyBl
bmRwb2ludC4gT2YgY291cnNlIHRoaXMgaXNuJ3QgdGhlIHNhbWUgYXMgYW4gSUQtdG9rZW4tb25s
eS1mcm9udC1jaGFubmVsIFNTTyBidXQgaXQgc3RpbGwgcmV0YWlucw0KIHNvbWUgb2YgdGhlIHNh
bWUgYmVuZWZpdHMgYmVpbmcgYSBtb3N0bHkgZnJvbnQgY2hhbm5lbCBmbG93LiA8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBrbm93
IGhvdyBuaWNoZSB0aGVzZSBjYXNlcyBhcmUgb3IgZXZlbiBob3cgb2Z0ZW4gdGhleSBhcmUgYWN0
dWFsbHkgcHV0IGludG8gdXNlIGluIGFjdHVhbCBkZXBsb3ltZW50cy4gQnV0IHRoZSB0b2tlbiYj
NDM7aWRfdG9rZW4gYW5kIGZvcm1fcG9zdCBmbG93IHdhcyBmcmVzaCBpbiBteSBtaW5kIGZvciB1
bnJlbGF0ZWQgcmVhc29ucyB3aGVuIEkgd2FzIHJlLXJldmlld2luZyB0aGUgc2VjdXJpdHkgQkNQ
DQogZHJhZnQsIHdoaWNoIG1hZGUgbWUgdGhpbmsgYWdhaW4gYWJvdXQgdGhlIFNIT1VMRCBOT1Qg
d29yZGluZyBpbiBTZWN0aW9uIDMuMS4yLiBBbmQgdGhhdCBsZWQgbWUgdG8gdGhpcyB0aHJlYWQg
YW5kIG15IHByb3Bvc2VkIHRleHQgdGhhdCB3b3VsZCBsZXQgdGhlIFNIT1VMRCBmb3IgdXNpbmcg
c2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgc3RhbmQgb24gaXRzIG93biBhbmQgYWRq
dXN0IHRoZSBxdWFsaWZpY2F0aW9uIG9uIHRoZSBTSE9VTEQNCiBOT1QgZm9yIGltcGxpY2l0IHN0
eWxlIGFjY2VzcyB0b2tlbnMgdG8gZm9jdXMgb24gdGhlIGlzc3VlcyB0aGF0IGFyZSBwYXJ0aWN1
bGFyIHRvIHRob3NlIGZsb3dzLiBUaGlzIGRvZXNuJ3QgYWN0dWFsbHkgY2hhbmdlIHRoZSB1bmRl
cmx5aW5nIG1lYW5pbmcgb2YgdGhlIGRyYWZ0IGJlY2F1c2Ugc2VuZGVyLWNvbnN0cmFpbmVkIGFj
Y2VzcyB0b2tlbnMgYXJlIHN0aWxsIGEgU0hPVUxELiBCdXQgSSB0aGluayBpdCB3b3VsZCBtYWtl
IHRoZSBkcmFmdA0KIG1vcmUgY29oZXNpdmUgaW4gdGVybXMgb2Ygd2hlcmUgYW5kIHdoeSBjZXJ0
YWluIHJlY29tbWVuZGF0aW9ucyBhcmUgbWFkZS4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDIsIDIw
MjAgYXQgMjo1MyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJpY2hhbm5hQGFtYXpvbi4uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9u
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJyaWFuIGFuZCBvdGhlcnMgd2l0
aCBzaW1pbGFyIHVzZSBjYXNlcyAoRmlsaXA/KTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlRoZSBjdXJyZW50IHRleHQgZG9lcyBub3QgcHJvaGliaXQgeW91ciBhcHByb2FjaCwgcHJvdmlk
ZWQgeW914oCZdmUgZG9uZSB0aGUgZHVlIGRpbGlnZW5jZSByZXF1aXJlZCBieSBCQ1AgMTQgdG8g
Z28gYWdhaW5zdCBhIFNIT1VMRCBOT1QuIENvdWxkIHlvdSBwcm92aWRlIG1vcmUgZGV0YWlsIG9u
IHRoZSBzY2VuYXJpb3MNCiB3aGVyZSB5b3UgaGF2ZSBvcHRlZCB0byB1c2UgdGhlc2UgaW1wbGlj
aXQtYmFzZWQgc29sdXRpb25zPyBJcyBpdCBpbXByYWN0aWNhbCBvciBpbmZlYXNpYmxlIHRvIHVz
ZSBhbiBhdXRob3JpemF0aW9uIGNvZGUtYmFzZWQgYXBwcm9hY2ggaW4gdGhlc2Ugc2NlbmFyaW9z
PyBJZiB0aGlzIGlzIGEgcGFydGljdWxhcmx5IG5pY2hlIHVzZSBjYXNlLCB0aGVuIGl0IG1heSBu
b3QgYmUgd29ydGggaW5jbHVkaW5nIGluIHRoZSBCQ1AgKHRoYXTigJlzIGJhc2ljYWxseQ0KIHdo
YXQgU0hPVUxEIE5PVCBpcyBmb3IpLiBCdXQgaWYgaXTigJlzIG1vcmUgYnJvYWRseSBhcHBsaWNh
YmxlLCB0aGVuIGl0IG1heSBiZSB3b3J0aCB0d2Vha2luZyB0aGUg4oCcdW5sZXNz4oCm4oCdIGNs
YXVzZSBvZiB0aGF0IHBhcmFncmFwaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJ
ZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6
Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0Ozxh
IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1
dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzICZsdDtN
aWNoYWVsLkpvbmVzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgRGVjZW1iZXIgMjgsIDIwMTkgYXQgOTo0NyBB
TTxicj4NCjxiPlRvOiA8L2I+QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2Ft
cGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tPC9hPiZndDssIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJl
Zj0ibWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8
L2I+b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVU
SC1XR10gW0VYVEVSTkFMXSAtc2VjdXJpdHktdG9waWNzLTEzIGFuZCBPSURDIHJlc3BvbnNlIHR5
cGVzICYjNDM7IGZvcm1fcG9zdCByZXNwb25zZSBtb2RlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0
aCBCcmlhbidzIHN1Z2dlc3RlZCB0ZXh0IGNoYW5nZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS0gTWlrZTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln
bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRo
PSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzE1NzMxODQ4
NzQwMTY2OTkyNjRnbWFpbC1tXy0xOTYwMzc5Njk4NjE5OTEyNTIwZ21haWwtbV8tMTkwMDQyODI4
NjQzMjg1NzgzOWdtYWlsLW1fLTIxOTQxMDk5NjIzNzI5OTc2MDlnbWFpbC1tXzQyNjI1MDUyOTAy
ODY5NTYzNTVnbWFpbC1tXy00Mjk4OTcxOTczODI5OTMzNjU3Z21haWwtbV8tNjA0MjE3NjMxOTk1
NDY5MTIzOWdtYWlsLW1fNTYyODAyMTM4MTE4NDI0NDQ1NWdtYWlsLW1fNDYxNTAwNjExMDcyNTgw
ODQyNGRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp
dHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0
Ozxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgRGVjZW1iZXIgMjgsIDIwMTkgNTozMzoyNCBB
TTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVm
PSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i
PiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7
IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt
V0ddIFtFWFRFUk5BTF0gLXNlY3VyaXR5LXRvcGljcy0xMyBhbmQgT0lEQyByZXNwb25zZSB0eXBl
cyAmIzQzOyBmb3JtX3Bvc3QgcmVzcG9uc2UgbW9kZTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U
aGUgcmVxdWlyZW1lbnQgZm9yIHJlcGxheS9pbmplY3Rpb24gcHJldmVudGlvbiBhdCByZXNvdXJj
ZSBzZXJ2ZXJzIGlzIHN0aWxsIHRoZXJlIGluIHNlY3Rpb24gMy4yLiBUaGlzIGNoYW5nZSBvbmx5
IGRyb3BzIGl0IGFzIGEgc3BlY2lmaWMgcXVhbGlmaWNhdGlvbiBvbiB0aGF0IFNIT1VMRCBOT1Qg
Zm9yIGZsb3dzDQogdGhhdCBzZW5kIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24g
cmVzcG9uc2UuIEFuZCBpbnN0ZWFkIGZvY3VzZXMgdGhhdCBxdWFsaWZpY2F0aW9uIG9uIHRoZSBh
ZGRpdGlvbmFsIHJpc2tzIHRoYXQgY29tZSB3aXRoIHNlbmRpbmcgYWNjZXNzIHRva2VucyBpbiB0
aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4gVG8gbWUsIHRoaXMgZmVlbHMgbW9yZSBjb25zaXN0
ZW50LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5Mb29raW5nIGFnYWluIGF0IHNlY3Rpb24gMywgSSdkIHN1Z2dlc3QgYWxz
byBtb3ZpbmcgdGhlIGZvdXJ0aCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzLjEuMiBpbnRvIHNlY3Rp
b24gMy4yIHNvIHRoYXQgdGhlIGRlc2NyaXB0aW9uIG9mIHNlbmRlci1jb25zdHJhaW5lZCBpcyBp
biB0aGUgc3Vic2VjdGlvbiB0aGF0DQogaXMgYWJvdXQgc2VuZGVyLWNvbnN0cmFpbmluZy4mbmJz
cDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv
bToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPk9uIEZyaSwgRGVjIDI3LCAyMDE5LCA1OjAwIFBNIFRvcnN0ZW4gTG9kZGVy
c3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0ibWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJj
LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5v
cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNv
bG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBwcm9wb3NhbCBzb3VuZHMgcmVhc29u
YWJsZSBvbiBmaXJzdCBzaWdodC4gQnV0IHRoaW5raW5nIGFnYWluLCBpdCB3b3VsZCBtZWFuIHRv
IGtlZXAgdG9rZW4gaW5qZWN0aW9uIHByZXZlbnRpb24gaW4gYXV0aG9yaXphdGlvbiByZXNwb25z
ZXMgYSByZXF1aXJlbWVudCB3aGlsZSBkcm9wcGluZyB0aGUNCiByZXF1aXJlbWVudCBmb3IgcmVw
bGF5L2luamVjdGlvbiBwcmV2ZW50aW9uIGF0IHJlc291cmNlIHNlcnZlcnMuIFRvIG1lIHRoaXMg
ZmVlbHMgaW5jb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0
b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5BbSAy
OC4uMTIuMjAxOSB1bSAwMDowMiBzY2hyaWViIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9
PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQgaXQgc2hvdWxk
IGJlIGEgcmVjb21tZW5kZWQgZmxvdy4gQnV0IHJlY29tbWVuZGluZyBhZ2FpbnN0IGl0LCBhcyB0
aGUgdGV4dCBkb2VzIG5vdywgc2VlbXMgb3ZlcnJlYWNoaW5nIGFuZCB1bm5lY2Vzc2FyeS4gSSBr
bm93ICpjb25zZW5zdXMqIHdhcyBwcmV2aW91c2x5DQogZm91bmQgb24gdGhlIHRleHQgaW4gLTEz
IGJ1dCBiZXN0IEkgY2FuIHJlY2FsbCB0aGF0IGRpc2N1c3Npb24gd2FzIG1vc3RseSBhcm91bmQg
TmF0IGFkdm9jYXRpbmcgdG8gYWxsb3cgcm9vbSBmb3Igc29tZSBmdXR1cmUgc2VsZi1pc3N1ZWQg
SURQIHR5cGUgY2FzZSBhbmQgdGhlIGNvbnZlcnNhdGlvbiBraW5kIG9mIGdvdCBodW5nIHVwIG9u
IHRoYXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkhlcmUncyBzb21lIHByb3Bvc2VkIHRleHQsIHdoaWNoIEkgdGhpbmsgc3RpbGwg
bGFyZ2VseSBjYXB0dXJlcyB0aGUgaW50ZW50IG9mIHRoZSBCQ1Agd2hpbGUgbm90IGV4cGxpY2l0
bHkgcmVjb21tZW5kaW5nIGFnYWluc3QgbGVnaXRpbWF0ZSBjYXNlcyBsaWtlIHRoZSBvbmUgSSBi
cm91Z2h0IGhlcmUgb3IgTmF0J3MNCiBvciBzb21ldGhpbmcgbGlrZSBKQVJNLiA8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu
YnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpc3N1ZXMsIGNsaWVudHMgU0hPVUxEIE5PVCB1
c2UgdGhlIGltcGxpY2l0PGJyPg0KJm5ic3A7ICZuYnNwO2dyYW50IChyZXNwb25zZSB0eXBlICZx
dW90O3Rva2VuJnF1b3Q7KSBvciBvdGhlciByZXNwb25zZSB0eXBlcyBpc3N1aW5nPGJyPg0KJm5i
c3A7ICZuYnNwO2FjY2VzcyB0b2tlbnMgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHVu
bGVzcyBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBpbiB0aGUgYXV0aG9yaXphdGlv
biByZXNwb25zZSBpcyBwcmV2ZW50ZWQgYW5kIHRoZSBhZm9yZW1lbnRpb25lZCB0b2tlbiBsZWFr
YWdlDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7Jm5ic3A7IHZlY3RvcnMgYXJlIG1pdGlnYXRlZC4NCjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IGFscmVh
ZHkgcmVjb21tZW5kcyBzZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBlbHNld2hlcmUg
aW4gdGhlIGRvY3VtZW50LiBJdCBkb2Vzbid0IG5lZWQgdG8gYmUgcmVwZWF0ZWQgYXMgYSBxdWFs
aWZ5aW5nIGNvbmRpdGlvbiBhcm91bmQgdGhpcyBTSE9VTEQgTk9ULg0KPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIGEgcHJvcG9u
ZW50IG9mIFBvUC9Ib0svc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgKGFzIGhvcGVm
dWxseSBpcyBldmlkZW50IGZyb20gc2V2ZXJhbCBhdHRlbXB0cyBhdCBicmluZ2luZy9kb2luZyBy
ZWxhdGVkIHdvcmsgaGVyZSkgYnV0IEkgZG8gd29ycnkgdGhhdCB0aGUgcmVjb21tZW5kYXRpb24N
CiBpbiB0aGUgZHJhZnQgaXMgc3VmZmljaWVudGx5IHVuYWNoaWV2YWJsZSB0byB0aGUgdmFzdCBt
YWpvcml0eSB0aGF0IGl0IG1pZ2h0IHVuZGVybWluZSB0aGUgY3JlZGliaWxpdHkgb2YgdGhlIGRv
Y3VtZW50LiBCdXQgSSBnZXQgdGhlIGFzcGlyYXRpb25hbCBhc3BlY3Qgb2YgaXQgYW5kLCBvdGhl
ciB0aGFuDQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRmLm9yZyUyRmFyY2glMkZt
c2clMkZvYXV0aCUyRlJLdWpPTmVqLTkyZFQ1bHI5Y0x1NmhIbnc4SSZhbXA7ZGF0YT0wMiU3QzAx
JTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M5N2MwZWIxOGFlNmQ0ZmJkMTg5NzA4
ZDc5NTU0OGVkNyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2
MzcxNDIwNjI3MTkzMTM1MzImYW1wO3NkYXRhPU92QUxSZlJ6ZmN2SWs0Tlc3bFl0bkY3bU82dWpV
M2NPMU8wT0glMkZRVkhGYyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0Kc29t
ZSBzdWdnZXN0ZWQgdHdlYWtzPC9hPiwgYW0gcmVzaWduZWQgdG8gc2VlIGl0IHN0YXkgaW4gdGhl
IGRvY3VtZW50LiBCdXQgbGV0J3MgbGV0IHRoYXQgcmVjb21tZW5kYXRpb24gc3RhbmQgb24gaXRz
IG93biBpbiB0aGUgZG9jdW1lbnQgYW5kIG5vdCBhbHNvIHRpZSBpdCB0byBvdGhlciBjb25zaWRl
cmF0aW9ucy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5PbiBGcmksIERlYyAyNywgMjAxOSBhdCAxOjQxIFBNIFRvcnN0ZW4gTG9k
ZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0ibWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRt
YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0
Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVu
dGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgQnJpYW4gc2FpZCwgd2UgaGF2ZSBk
aXNjdXNzZWQgdGhpcyBzZXZlcmFsIHRpbWVzIGFuZCB0aGlzIHRleHQgZm91bmQgY29uc2Vuc3Vz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+VXNpbmcgcG9zdCByZWR1Y2VzIHRoZSBhdHRhY2sgc3VyZmFjZSBidXQgZG9lcyBub3QgYWxs
b3cgdG8gYmluZCB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSBsZWdpdGltYXRlIGNsaWVudC4gV2Ug
YXJlIHJlY29tbWVuZGluZyBzZW5kZXIgY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBpbiB0aGUg
QkNQLiBTbyByZWNvbW1lbmRpbmcNCiBhIGZsb3cgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IHNlbmRl
ciBjb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGlzIGEgY29udHJhZGljdGlvbi48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgZG8g
b3RoZXIgV0cgbWVtYmVycyB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+
QW0gMjcuMTIuMjAxOSB1bSAyMToyOCBzY2hyaWViIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9u
ZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206
MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjpibGFjayI+SSBhZ3JlZSB3aXRoIEJyaWFuLiBQbGVhc2UgdXBkYXRlIHRoZSB0
ZXh0IHRvIGRlc2NyaWJlIHRoaXMgYWxyZWFkeSBzYWZlIHVzYWdlLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0tIE1pa2U8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIxIiB3aWR0
aD0iNjUlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8xNTczMTg0
ODc0MDE2Njk5MjY0Z21haWwtbV8tMTk2MDM3OTY5ODYxOTkxMjUyMGdtYWlsLW1fLTE5MDA0Mjgy
ODY0MzI4NTc4MzlnbWFpbC1tXy0yMTk0MTA5OTYyMzcyOTk3NjA5Z21haWwtbV80MjYyNTA1Mjkw
Mjg2OTU2MzU1Z21haWwtbV8tNDI5ODk3MTk3MzgyOTkzMzY1N2dtYWlsLW1fLTYwNDIxNzYzMTk5
NTQ2OTEyMzlnbWFpbC1tXzU2MjgwMjEzODExODQyNDQ0NTVnbWFpbC1tXzQ2MTUwMDYxMTA3MjU4
MDg0MjR4X2dtYWlsLW1fMTk2NDMxMzUwMDEzNDEyMTI4M21fMzA3MjM5NTE1NDE0OTUyOTYyMW1f
NTgxNTM5ODQxOTA5NDg3NjgxbV8tOTE0MTg1Mjg1MDQ1NTUzOTUwMG1fMzgzMjMyOTY5NTMwOTk4
NTgxNGdtYWlsLW1fMjgzNDc5NTczNjA1NTY2NTEwMGRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBPQXV0aCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNl
c0BpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhhbGYg
b2YgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD08L3NwYW4+PGEgaHJlZj0ibWFpbHRvOjQw
cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lk
ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZn
dDs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAyNywgMjAxOSAxMTowMzozMCBB
TTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBbT0FVVEgt
V0ddIC1zZWN1cml0eS10b3BpY3MtMTMgYW5kIE9JREMgcmVzcG9uc2UgdHlwZXMgJiM0MzsgZm9y
bV9wb3N0IHJlc3BvbnNlIG1vZGU8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgaGF2ZSBhLXNv
bWV0aW1lcyB1c2VkIHNjZW5hcmlvIHdoZXJlIGEgY2xpZW50IG1ha2VzIGFuIGF1dGhvcml6YXRp
b24vYXV0aGVudGljYXRpb24gcmVxdWVzdCB3aXRoIGEgJnF1b3Q7dG9rZW4gaWRfdG9rZW4mcXVv
dDsgcmVzcG9uc2UgdHlwZSBhbmQgJnF1b3Q7Zm9ybV9wb3N0JnF1b3Q7IHJlc3BvbnNlIG1vZGUg
KG5vbmNlIGlzIGFsc28NCiBzZW50IGFuZCBleGFjdCByZWRpcmVjdCBVUkkgbWF0Y2hpbmcgaXMg
ZG9uZSBhdCB0aGUgQVMpLiBUaGUgYWNjZXNzIHRva2VuIGlzIG5ldmVyIGV4cG9zZWQgaW4gYW55
IFVSTHMgYW5kIGFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaXMgcHJldmVudGVkIGJ5IHRoZSBhdF9o
YXNoIGNsYWltIGluIHRoZSBpZCB0b2tlbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBzZWVtcyB0byBtZSBsaWtlIGEgbGVn
aXRpbWF0ZSBhbmQgcmVhc29uYWJsZSB1c2FnZSBzY2VuYXJpby4gSG93ZXZlciwgaXQgd291bGQg
ZmFsbCBvbiB0aGUgd3Jvbmcgc2lkZSBvZiB0aGUgU0hPVUxEIE5PVCBpbg0KPGEgaHJlZj0iaHR0
cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB
JTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10
b3BpY3MtMTMlMjNzZWN0aW9uLTMuLi4uMS4uMiZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K
b25lcyU0MG1pY3Jvc29mdC5jb20lN0M5N2MwZWIxOGFlNmQ0ZmJkMTg5NzA4ZDc5NTU0OGVkNyU3
QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDIwNjI3MTkz
MTM1MzImYW1wO3NkYXRhPWI2bVV2WDBXMGhmNkg4a3RLZFQ0dkVRbGZqN0ZVanNPSU83SUhwQ2Yl
MkZZcyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KU2VjdGlvbiAzLjEuMiBv
ZiB0aGUgU2VjdXJpdHkgQkNQLXRvLWJlPC9hPiwgd2hpY2ggaGFzOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IEluIG9yZGVyIHRvIGF2b2lk
IHRoZXNlIGlzc3VlcywgY2xpZW50cyBTSE9VTEQgTk9UIHVzZSB0aGUgaW1wbGljaXQ8YnI+DQom
bmJzcDsgJm5ic3A7Z3JhbnQgKHJlc3BvbnNlIHR5cGUgJnF1b3Q7dG9rZW4mcXVvdDspIG9yIGFu
eSBvdGhlciByZXNwb25zZSB0eXBlIGlzc3Vpbmc8YnI+DQombmJzcDsgJm5ic3A7YWNjZXNzIHRv
a2VucyBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgc3VjaCBhcyAmcXVvdDt0b2tlbiBp
ZF90b2tlbiZxdW90Ozxicj4NCiZuYnNwOyAmbmJzcDthbmQgJnF1b3Q7Y29kZSB0b2tlbiBpZF90
b2tlbiZxdW90OywgdW5sZXNzIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VucyBhcmU8YnI+DQombmJz
cDsgJm5ic3A7c2VuZGVyLWNvbnN0cmFpbmVkIGFuZCBhY2Nlc3MgdG9rZW4gaW5qZWN0aW9uIGlu
IHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc3BvbnNlIGlzIHByZXZlbnRl
ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkkga25vdyB0aGlzIHBhcnRpY3VsYXIgdGV4dCBoYXMgYmVlbiBkaXNjdXNzZWQgb3ZlciBh
bmQgb3ZlciBhZ2FpbiBzbyBJIGhhdGUgdG8gcmV2aXNpdCBpdC4gQnV0IGJhc2VkIG9uIHRoZSBh
Zm9yZW1lbnRpb25lZCBzY2VuYXJpbyBJIHRoaW5rIG1heWJlIGl0IHN0aWxsIGRvZXNuJ3QgcXVp
dGUgaGl0IHRoZQ0KIG1hcmsuIEFjY2VzcyB0b2tlbiBpbmplY3Rpb24gaXMgcHJldmVudGVkLiBU
aGUgdG9rZW4gbGVha2FnZSBzY2VuYXJpb3MgbWVudGlvbmVkIGluIHRoYXQgc2VjdGlvbiBhcmUg
YWxsIGF2b2lkZWQuIEFuZCB3aGlsZSBJIGtub3cgc2VuZGVyLWNvbnN0cmFpbmVkIGlzIHJlY29t
bWVuZGVkIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQsIGl0J3Mgbm90IHJlYWxseSBhIHJlYWxpc3Rp
YyBvcHRpb24gZm9yIHRoZSBtYWpvcml0eSBvZiBkZXBsb3ltZW50cy4NCjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt
YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig
dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuLiBBbnkgcmV2aWV3LCB1
c2UsIGRpc3RyaWJ1dGlvbiBvcg0KIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g
aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg
YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy
IGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48
YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su
Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l
MkZvYXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20l
N0M5N2MwZWIxOGFlNmQ0ZmJkMTg5NzA4ZDc5NTU0OGVkNyU3QzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDIwNjI3MTkzMjM1MjMmYW1wO3NkYXRhPUpFdzVC
SyUyRk1HelZ3S2VxbW9mdTNTcFEwU0x6b2RzWTBXOGVLWlc5UWxYMCUzRCZhbXA7cmVzZXJ2ZWQ9
MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy
Pg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzU1NTU1NTtib3Jk
ZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9U
SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt
YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuLiBB
bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvcg0KIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNv
bW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs
eSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVu
dHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdp
bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg
ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv
ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4uIEFueSByZXZpZXcs
IHVzZSwgZGlzdHJpYnV0aW9uIG9yDQogZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWls
IGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91
ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTotYXBwbGUtc3lzdGVtO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx
LjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg
Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl
IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlz
dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu
LiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is
IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0
ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy
LiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_DM6PR00MB084783B6C945B33DE42BE1D0F5390DM6PR00MB0847namp_--


From nobody Thu Jan  9 16:25: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 0843112022A for ; Thu,  9 Jan 2020 16:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6A3xV1xoIdc for ; Thu,  9 Jan 2020 16:25:19 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888F21200B3 for ; Thu,  9 Jan 2020 16:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578615920; x=1610151920; h=from:to:subject:date:message-id:mime-version; bh=1mYinadEay+jOEIvA6f1QvkccnIWc9es8ICRsvuOqsI=; b=ox4dtjf3kb8t/naDBJZ76wpnOxjgxLC2yMOZyz7eB2amiV5AyVItPB8N FRFz4iHfOCj/F0Lea/qezGn9NLL7M7G7/4fZzWFdsvePEKQYGGMxA8VMO 2FVgZt2p7lShUCvgNg3BGO6qhMpOyli0d+Mxkt/Bk+XH0GM/aAbrlLL3R s=;
IronPort-SDR: ucti/Tj1PjBAMmoD4anrLo/4M7khrBz0v5ll6Wv6570xHuobRM/JiuVnIeW4qLJXvs/z8j981G pdSFVvVjTkrw==
X-IronPort-AV: E=Sophos;i="5.69,414,1571702400"; d="scan'208,217";a="9459605"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-c5104f52.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 10 Jan 2020 00:25:09 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-c5104f52.us-west-2.amazon.com (Postfix) with ESMTPS id EFB19A1BA7; Fri, 10 Jan 2020 00:25:08 +0000 (UTC)
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 00:25:08 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 00:25:08 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 10 Jan 2020 00:25:08 +0000
From: "Richard Backman, Annabelle" 
To: Mike Jones , oauth 
Thread-Topic: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVx0xpDyUIRyiBT0+iDXwQ2PYV6A==
Date: Fri, 10 Jan 2020 00:25:08 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.252]
Content-Type: multipart/alternative; boundary="_000_CDAB37280FB049A59A6C6F3794A6E1DBamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 00:25:22 -0000

--_000_CDAB37280FB049A59A6C6F3794A6E1DBamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIOKAnHR5cOKAnSBmaWVsZCBoZWxwcyBwcmV2ZW50IG1pc3JlcHJlc2VudGF0aW9uIG9mIGEg
bGVnaXRpbWF0ZWx5IGlzc3VlZCBKV1QsIGJ1dCBpdCBkb2VzbuKAmXQgYWRkcmVzcyB0aGUgaXNz
dWUgSSBhbSB0cnlpbmcgdG8gZHJhdyBhdHRlbnRpb24gdG8sIHdoaWNoIGlzIHRoYXQgdGhlIGN1
cnJlbnQgbW9kZWwgZm9yY2VzIGJyb2FkZXIgZGlzdHJpYnV0aW9uIGFuZCByZXVzZSBvZiBrZXlz
IHRoYW4gaXMgbmVjZXNzYXJ5LCByZXN1bHRpbmcgaW4gYSBncmVhdGVyIGJsYXN0IHJhZGl1cyBm
b3IgY29tcHJvbWlzZWQga2V5cyBvciBzeXN0ZW1zLg0KDQpGb3IgbWFueSBjYXNlcywgdGhpcyBp
cyBub3QgYSBzaWduaWZpY2FudCBjb25jZXJuLCBhcyB0aGUgQVMgaXMgYSBtb25vbGl0aGljIHN5
c3RlbSB3aXRoIG5vIGludGVybmFsIHRydXN0IGJvdW5kYXJpZXMuIEhvd2V2ZXIsIGluIGNhc2Vz
IHdoZXJlIHRoZSBBUyBpcyBjb21wb3NlZCBvZiBtdWx0aXBsZSBtaWNyb3NlcnZpY2VzIHBlcmZv
cm1pbmcgZGlmZmVyZW50IHRhc2tzLCB0aGUgbmVlZCB0byBzaGFyZSBrZXlzIGJldHdlZW4gZGlm
ZmVyZW50IG1pY3Jvc2VydmljZXMgdW5kZXJtaW5lcyBlZmZvcnRzIHRvIGNyZWF0ZSB0cnVzdCBi
b3VuZGFyaWVzIGJldHdlZW4gdGhlbS4gSSBnYXZlIG9uZSBleGFtcGxlIG9mIHRoaXMgaW4gbXkg
b3JpZ2luYWwgZW1haWwsIHdoZXJlIElEIFRva2VuIGdlbmVyYXRpb24gYW5kIGFjY2VzcyB0b2tl
biBnZW5lcmF0aW9uIGFyZSByZWxlZ2F0ZWQgdG8gaW5kZXBlbmRlbnQgc3lzdGVtcywgZWFjaCB3
aXRoIHNlcGFyYXRlIHByaXZhdGUga2V5cyBmb3Igc2lnbmluZyB0b2tlbnMuIFN1cHBvc2UgYSBt
YWxpY2lvdXMgcGFydHkgY29tcHJvbWlzZWQgdGhlIElEIFRva2VuIGdlbmVyYXRvciwgb3IgZ2Fp
bmVkIGFjY2VzcyB0byBpdHMgcHJpdmF0ZSBrZXksIGFuZCBpc3N1ZWQgZnJhdWR1bGVudCBhY2Nl
c3MgdG9rZW5zIHNpZ25lZCB1c2luZyB0aGF0IGtleS4gU2luY2UgdmVyaWZpZXJzIG9mIGJvdGgg
dG9rZW4gdHlwZXMgd2lsbCBsb29rIHRvIHRoZSBzYW1lIG1ldGFkYXRhIGZpbGUgYW5kIHRodXMg
dGhlIHNhbWUgSldLIHNldCwgdGhleSBoYXZlIG5vIHdheSB0byByZWNvZ25pemUgdGhhdCB0aGVz
ZSBhY2Nlc3MgdG9rZW5zIGFyZSBmcmF1ZHVsZW50Lg0KDQpOb3RlIHRoYXQgd2hpbGUg4oCcdHlw
4oCdIHdvdWxkIGhlbHAgYSB2ZXJpZmllciBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIElEIFRva2Vu
IGFuZCBhbiBhY2Nlc3MgdG9rZW4sIGl0IGRvZXMgbm90IGhlbHAgaW4gdGhpcyBjYXNlIGJlY2F1
c2UgdGhlIG1hbGljaW91cyBwYXJ0eSBpcyBnZW5lcmF0aW5nIHdlbGwtZm9ybWVkIGFjY2VzcyB0
b2tlbiBKV1RzLCBzaWduZWQgd2l0aCBhIGtleSB0aGF0IGlzIGxlZ2l0aW1hdGUgZm9yIHRoZSBB
UyBidXQgbm90IGZvciB0aGlzIHB1cnBvc2UuDQoNClRoZSBjYXNlIGZvciB0aGlzIGJlaW5nIGEg
Y29uY2VybiBvbiB0aGUgZW5jcnlwdGlvbiBzaWRlIGlzIGZ1enppZXIsIHByaW1hcmlseSBiZWNh
dXNlIHdlIHNpbXBseSBkb27igJl0IGhhdmUgbWFueSB1c2UgY2FzZXMgd2hlcmUgZGlmZmVyZW50
IGtpbmRzIG9mIGNvbnRlbnQgZ2V0cyBlbmNyeXB0ZWQgYW5kIHNlbnQgdG8gdGhlIEFTIGluIGRp
ZmZlcmVudCBjb250ZXh0cy4gSG93ZXZlciwgSSBnYXZlIG9uZSBleGFtcGxlIG9uIHRoZSBQQVIg
dGhyZWFkPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvaVZYazNF
dXNtVjRCaDktcjU4YmViZ1o2ODg4Piwgd2hlcmUgYSBQQVIgZW5kcG9pbnQgdGhhdCBkZWNyeXB0
cyByZXF1ZXN0IG9iamVjdCBKV1RzIHdpbGwgYWxzbyBiZSBhYmxlIHRvIGRlY3J5cHQgaWRfdG9r
ZW5faGludCBKV1RzLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVu
dGl0eQ0KDQoNCkZyb206IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29t
QGRtYXJjLmlldGYub3JnPg0KRGF0ZTogVGh1cnNkYXksIEphbnVhcnkgOSwgMjAyMCBhdCAxMToz
NCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5j
b20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5ERVJd
IFJFOiBDcnlwdG9ncmFwaGljIGh5Z2llbmUgYW5kIHRoZSBsaW1pdHMgb2Ygandrc191cmkNCg0K
VGhpcyBhIGdvb2QgdGhpbmcgdG8gdGhpbmsgYWJvdXQuICBUaGFua3MgZm9yIGJyaW5naW5nIHRo
aXMgdXAsIEFubmFiZWxsZS4NCg0KT25lIHRoaW5nIHRoYXQgcGFydGlhbGx5IG1pdGlnYXRlcyB0
aGlzIGlzIHRoYXQgdGhlIOKAnHVzZeKAnSBhbmQvb3Ig4oCca2V5X29wc+KAnSBhdHRyaWJ1dGVz
IGNhbiBiZSBwcm92aWRlZC4gIFRoaXMgY2FuIGFsbG93IHNpZ25pbmcga2V5cyB0byBiZSBkaWZm
ZXJlbnRpYXRlZCBmcm9tIGVuY3J5cHRpb24ga2V5cywgZm9yIGluc3RhbmNlLg0KDQpJ4oCZbSBu
b3QgYXMgd29ycmllZCBhYm91dCBlbmNyeXB0aW9uIGtleXMgYXMgc2lnbmluZyBrZXlzLiAgSWYg
bXVsdGlwbGUga2luZHMgb2YgYXBwbGljYXRpb25zIGVuY3J5cHQgY29udGVudCB0byBhIHBhcnR5
IHVzaW5nIHRoZSBzYW1lIHB1YmxpYyBwZXItcGFydHkga2V5LCBhbmQgdGhlIGVuY3J5cHRpb24g
aXMgYmVpbmcgdXNlZCBvbmx5IHRvIGVuc3VyZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIG1lc3Nh
Z2VzLCB0aGUgY29uZmlkZW50aWFsaXR5IGlzIHN0aWxsIGFjaGlldmVkLg0KDQpPbmUgbWl0aWdh
dGlvbiBmb3Igc2lnbmluZyBrZXlzIGlzIHVzZSBvZiB0aGUg4oCcdHlw4oCdIGZpZWxkLCBhcyBk
ZXNjcmliZWQgaW4gdGhlIEpXVCBCQ1AuICBFdmVuIGlmIHRoZSBzYW1lIGtleSB3YXMgdXNlZCBh
bmQgeW91IHJlY2VpdmUgYW4gdW5leHBlY3RlZCBKV1QgdHlwZSwgeW91IHdpbGwgc3RpbGwgcmVq
ZWN0IGl0Lg0KDQpJIGJlbGlldmUgdGhlcmXigJlzIGFsc28gY2FzZXMgd2hlcmUgaXTigJlzIGZp
bmUgdG8gdXNlIHRoZSBzYW1lIHNpZ25pbmcga2V5IGZvciByZWxhdGVkIG9wZXJhdGlvbnMuICBG
b3IgaW5zdGFuY2UsIHNpZ25pbmcgYSBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBh
IFJlcXVlc3QgT2JqZWN0IHdpdGggdGhlIHNhbWUga2V5IHNlZW1zIGJvdGggbG9naWNhbCBhbmQg
c2FmZSB0byBtZS4gIChJZiBvdGhlcnMgY2FuIHRoaW5rIG9mIGFuIGF0dGFjayB0aGF0IHRoaXMg
ZW5hYmxlcywgaG93ZXZlciwgcGxlYXNlIGRvIHBvaW50IGl0IG91dC4pDQoNCldoaWNoIEkgYmVs
aWV2ZSBsZWF2ZXMgdXMgd2l0aCB0aGlzIGNhc2UgdG8gd29ycnkgYWJvdXQg4oCTIHNoYXJlZCBz
aWduaW5nIGtleXMgYnkgdW5yZWxhdGVkIGFwcGxpY2F0aW9ucyB3aGVuIOKAnHR5cOKAnSBpcyBu
b3QgdXNlZC4gIE9uZSB3YXkgdG8gbWl0aWdhdGUgdGhpcyB3b3VsZCBiZSB0byB1c2UgcGVyLWFw
cGxpY2F0aW9uIGtleSBzZXRzLiAgRm9yIGluc3RhbmNlLCB1c2luZyB2YWx1ZXMgb3RoZXIgdGhh
biDigJxqd2tzX3VyaeKAnSB0byByZWZlcmVuY2Uga2V5IHNldHMgZm9yIHBhcnRpY3VsYXIgYXBw
bGljYXRpb25zLg0KDQpBbnl3YXksIGZvciBQQVIsIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBmaW5l
IHRvIHVzZSB0aGUgc2FtZSBrZXlzIGFzIHVzZWQgZm9yIFJlcXVlc3QgT2JqZWN0cywgc28gbm8g
bmV3IGZpZWxkcyBhcmUgbmVlZGVkIGZvciBpdC4NCg0KSSBsb29rIGZvcndhcmQgdG8gZnVydGhl
ciBkaXNjdXNzaW9uIG9uIHRoZSB0b3BpYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs
ZQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDgsIDIwMjAgMzo0NyBQTQ0KVG86IG9hdXRoIDxv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gQ3J5cHRvZ3JhcGhpYyBoeWdpZW5l
IGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpDQoNCkkgb3JpZ2luYWxseSBicm91Z2h0IHVwIHRo
aXMgaXNzdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIFBBUiBkcmFmdCwgYnV0IHNpbmNlIGl0IGJy
b2FkbHkgYXBwbGllcyB0byB0aGUgT0F1dGggc3BhY2UgSeKAmW0gc3RhcnRpbmcgYSBuZXcgdGhy
ZWFk4oCmDQoNClNlY3Rpb24gMy4xMiBvZiB0aGUgSldUIEJDUDxodHRwczovL25hbTA2LnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRm
Lm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDclMjNzZWN0aW9uLTMuMTIm
ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M3M2Q1NDdjNzY4
MWY0ZWE1OWE0ODA4ZDc5NDk1MjllNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdDMSU3QzAlN0M2MzcxNDEyNDA2OTcyOTU0NDUmc2RhdGE9QWVRTHhDYW8yWlQ2NjFaSzJmRTRh
NlFLeWg4SXpPJTJCcSUyRnF6YnQ3VmxkMHMlM0QmcmVzZXJ2ZWQ9MD4gc2F5czog4oCcVXNlIGRp
ZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy7igJ0gU2VjdGlvbiA0IG9m
IHRoZSBKV1QgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnM8aHR0cHM6Ly9uYW0w
Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v
bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAz
JTIzc2VjdGlvbi00JmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t
JTdDNzNkNTQ3Yzc2ODFmNGVhNTlhNDgwOGQ3OTQ5NTI5ZTYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQxMjQwNjk3MzA1NDAyJnNkYXRhPUlTc3pUeGxI
VGJBTEluakslMkZLZ2dIOXNlWmRXOGtHWFRESFpFV0N5ZkF6YyUzRCZyZXNlcnZlZD0wPiBzYXlz
OiDigJxBbiBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZWxlY3QgdG8gdXNlIGRpZmZlcmVudCBr
ZXlzIHRvIHNpZ24gaWRfdG9rZW5zIGFuZCBKV1QgYWNjZXNzIHRva2Vucy7igJ0gVGhlc2Ugc3Rh
dGVtZW50cyBhcmUgY29uc2lzdGVudCB3aXRoIGdvb2QgY3J5cHRvZ3JhcGhpYyBoeWdpZW5lLiBB
bmQgd2XigJl2ZSBtYWRlIGl0IGRpZmZpY3VsdCB0byBpbXBvc3NpYmxlIGZvciBhbiBBUyB0byBm
b2xsb3cgdGhlbS4NCg0KVGhlIEFTIGhhcyBhIHNpbmdsZSBtZXRhZGF0YSBkb2N1bWVudCBjb250
YWluaW5nIGEgc2luZ2xlIFVSSSByZWZlcmVuY2luZyBhIHNpbmdsZSBKV0sgU2V0LiBCdXQgdGhl
IEFTIGhhcyBubyB3YXkgb2YgaW5kaWNhdGluZyB0byBjbGllbnRzIHdoaWNoIGtleXMgdG8gdXNl
IGZvciB3aGljaCBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIGFuIEFTIGNhbm5vdCBzYXkgdGhhdCAq
b25seSB0aGVzZSoga2V5cyBhcmUgdG8gYmUgdXNlZCB0byBlbmNyeXB0IGlkX3Rva2VuX2hpbnQg
SldUcywgYW5kICpvbmx5IHRoZXNlKiBrZXlzIGFyZSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgSkFS
IHJlcXVlc3Qgb2JqZWN0IEpXVHMuIEZvciBlbmNyeXB0aW9uLCB0aGUgQVMgY291bGQgZW5mb3Jj
ZSB0aGF0IGxvZ2ljIGludGVybmFsbHksIGJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBjbGll
bnQgdG8gZGlzY292ZXIgdGhpcy4gQW5kIHdoaWxlIHRoZSBBUyBtYXkgYmUgYnVpbHQgdG8gb25s
eSB1c2UgY2VydGFpbiBrZXlzIGZvciBzaWduaW5nIElEIFRva2VucyBhbmQgb3RoZXIga2V5cyBm
b3Igc2lnbmluZyBKV1QgYWNjZXNzIHRva2VucywgaXQgaGFzIG5vIHdheSB0byBpbmRpY2F0ZSB0
aGlzIHRvIHRoZSBjbGllbnQuIFNvIGV2ZW4gaWYgSUQgVG9rZW4gZ2VuZXJhdGlvbiBhbmQgYWNj
ZXNzIHRva2VuIGdlbmVyYXRpb24gYXJlIGlzb2xhdGVkIGluIGRpZmZlcmVudCBtaWNyb3NlcnZp
Y2VzIHdpdGhpbiB0aGUgQVMsIGVhY2ggbWljcm9zZXJ2aWNlIGlzIGNhcGFibGUgb2YgZm9yZ2lu
ZyB0aGUgb3RoZXLigJlzIHRva2VucywgYmVjYXVzZSBjb25zdW1lcnMgY2Fu4oCZdCBiZSB0b2xk
IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gZGlmZmVyZW50IGtleXMgZm9yIHRoZSBBUy4NCg0KVGhp
cyBzZWVtcyBsaWtlIGEgdGlja2luZyB0aW1lIGJvbWIgdG8gbWUsIGFzIGl04oCZcyBhIG5vbi1v
YnZpb3VzIHNpZGUgZWZmZWN0IG9mIGNvbWJpbmluZyB2YXJpb3VzIE9BdXRoIDIuMCBleHRlbnNp
b25zLCBhbmQgaXQgY2FuIHVuZGVybWluZSBhIGxvdCBvZiBzb3BoaXN0aWNhdGVkIGVmZm9ydCB0
byBmb2xsb3cgc2VjdXJpdHkgYmVzdCBwcmFjdGljZXMuIEkgY2FuIHNlZSBhIGNvdXBsZSBvZiB3
YXlzIHRvIGFkZHJlc3MgdGhpcyAoZS5nLiwgbW9yZSBzb3BoaXN0aWNhdGVkIEFTIGtleSBtZXRh
ZGF0YSwgdGFnZ2luZyBvciBzaW1pbGFyIHVzZSBjYXNlIGluZGljYXRpb24gb24gSldLcyksIGJ1
dCBiZWZvcmUgdHJ5aW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIEnigJlkIGxpa2UgdG8gZ2V0IHBl
b3BsZeKAmXMgb3BpbmlvbnMgb24gdGhlIHByb2JsZW0uIElzIHRoaXMgYWxyZWFkeSBtaXRpZ2F0
ZWQgaW4gb3RoZXIgd2F5cz8gSGFzIHRoZSBzaGlwIHNhaWxlZCBvbiB0aGlzIGZvciBPQXV0aCwg
YW5kIG5vdyB3ZSBoYXZlIHRvIGxpdmUgd2l0aCBpdD8gU2hvdWxkIHRoaXMgYmUgbGVmdCB0byB0
aGUgZGVwbG95bWVudHMgdGhhdCBjYXJlIHRvIHNvbHZlIHdpdGggbm9uLWludGVyb3BlcmFibGUg
c29sdXRpb25zPyBBcmUgdGhlcmUgb3RoZXIgY2xldmVyIHdheXMgd2UgY291bGQgYXBwcm9hY2gg
dGhpcz8gQXJlIHRoZXJlIG90aGVyIGFuZ2xlcyB0aGF0IHdlIG5lZWQgdG8gY29uc2lkZXI/DQoN
CuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg==

--_000_CDAB37280FB049A59A6C6F3794A6E1DBamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <078CAB1C76CE4D48A994B95DB6D4027B@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h
bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu
IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0
aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg
bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5UaGUg4oCcdHlw4oCdIGZpZWxkIGhlbHBzIHByZXZlbnQgbWlzcmVwcmVzZW50
YXRpb24gb2YgYSBsZWdpdGltYXRlbHkgaXNzdWVkIEpXVCwgYnV0IGl0IGRvZXNu4oCZdCBhZGRy
ZXNzIHRoZSBpc3N1ZSBJIGFtIHRyeWluZyB0byBkcmF3IGF0dGVudGlvbiB0bywgd2hpY2ggaXMg
dGhhdCB0aGUgY3VycmVudCBtb2RlbCBmb3JjZXMgYnJvYWRlciBkaXN0cmlidXRpb24NCiBhbmQg
cmV1c2Ugb2Yga2V5cyB0aGFuIGlzIG5lY2Vzc2FyeSwgcmVzdWx0aW5nIGluIGEgZ3JlYXRlciBi
bGFzdCByYWRpdXMgZm9yIGNvbXByb21pc2VkIGtleXMgb3Igc3lzdGVtcy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciBtYW55IGNhc2VzLCB0aGlzIGlzIG5v
dCBhIHNpZ25pZmljYW50IGNvbmNlcm4sIGFzIHRoZSBBUyBpcyBhIG1vbm9saXRoaWMgc3lzdGVt
IHdpdGggbm8gaW50ZXJuYWwgdHJ1c3QgYm91bmRhcmllcy4gSG93ZXZlciwgaW4gY2FzZXMgd2hl
cmUgdGhlIEFTIGlzIGNvbXBvc2VkIG9mIG11bHRpcGxlIG1pY3Jvc2VydmljZXMgcGVyZm9ybWlu
ZyBkaWZmZXJlbnQNCiB0YXNrcywgdGhlIG5lZWQgdG8gc2hhcmUga2V5cyBiZXR3ZWVuIGRpZmZl
cmVudCBtaWNyb3NlcnZpY2VzIHVuZGVybWluZXMgZWZmb3J0cyB0byBjcmVhdGUgdHJ1c3QgYm91
bmRhcmllcyBiZXR3ZWVuIHRoZW0uIEkgZ2F2ZSBvbmUgZXhhbXBsZSBvZiB0aGlzIGluIG15IG9y
aWdpbmFsIGVtYWlsLCB3aGVyZSBJRCBUb2tlbiBnZW5lcmF0aW9uIGFuZCBhY2Nlc3MgdG9rZW4g
Z2VuZXJhdGlvbiBhcmUgcmVsZWdhdGVkIHRvIGluZGVwZW5kZW50IHN5c3RlbXMsDQogZWFjaCB3
aXRoIHNlcGFyYXRlIHByaXZhdGUga2V5cyBmb3Igc2lnbmluZyB0b2tlbnMuIFN1cHBvc2UgYSBt
YWxpY2lvdXMgcGFydHkgY29tcHJvbWlzZWQgdGhlIElEIFRva2VuIGdlbmVyYXRvciwgb3IgZ2Fp
bmVkIGFjY2VzcyB0byBpdHMgcHJpdmF0ZSBrZXksIGFuZCBpc3N1ZWQgZnJhdWR1bGVudCBhY2Nl
c3MgdG9rZW5zIHNpZ25lZCB1c2luZyB0aGF0IGtleS4gU2luY2UgdmVyaWZpZXJzIG9mIGJvdGgg
dG9rZW4gdHlwZXMgd2lsbCBsb29rDQogdG8gdGhlIHNhbWUgbWV0YWRhdGEgZmlsZSBhbmQgdGh1
cyB0aGUgc2FtZSBKV0sgc2V0LCB0aGV5IGhhdmUgbm8gd2F5IHRvIHJlY29nbml6ZSB0aGF0IHRo
ZXNlIGFjY2VzcyB0b2tlbnMgYXJlIGZyYXVkdWxlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5Ob3RlIHRoYXQgd2hpbGUg4oCcdHlw4oCdIHdvdWxkIGhlbHAg
YSB2ZXJpZmllciBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIElEIFRva2VuIGFuZCBhbiBhY2Nlc3Mg
dG9rZW4sIGl0IGRvZXMgbm90IGhlbHAgaW4gdGhpcyBjYXNlIGJlY2F1c2UgdGhlIG1hbGljaW91
cyBwYXJ0eSBpcyBnZW5lcmF0aW5nIHdlbGwtZm9ybWVkIGFjY2VzcyB0b2tlbiBKV1RzLCBzaWdu
ZWQNCiB3aXRoIGEga2V5IHRoYXQgaXMgbGVnaXRpbWF0ZSBmb3IgdGhlIEFTIGJ1dCBub3QgZm9y
IHRoaXMgcHVycG9zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PlRoZSBjYXNlIGZvciB0aGlzIGJlaW5nIGEgY29uY2VybiBvbiB0aGUgZW5jcnlwdGlvbiBzaWRl
IGlzIGZ1enppZXIsIHByaW1hcmlseSBiZWNhdXNlIHdlIHNpbXBseSBkb27igJl0IGhhdmUgbWFu
eSB1c2UgY2FzZXMgd2hlcmUgZGlmZmVyZW50IGtpbmRzIG9mIGNvbnRlbnQgZ2V0cyBlbmNyeXB0
ZWQgYW5kIHNlbnQgdG8gdGhlIEFTIGluIGRpZmZlcmVudCBjb250ZXh0cy4NCiBIb3dldmVyLCA8
YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL2lWWGsz
RXVzbVY0Qmg5LXI1OGJlYmdaNjg4OCI+DQpJIGdhdmUgb25lIGV4YW1wbGUgb24gdGhlIFBBUiB0
aHJlYWQ8L2E+LCB3aGVyZSBhIFBBUiBlbmRwb2ludCB0aGF0IGRlY3J5cHRzIHJlcXVlc3Qgb2Jq
ZWN0IEpXVHMgd2lsbCBhbHNvIGJlIGFibGUgdG8gZGVjcnlwdCBpZF90b2tlbl9oaW50IEpXVHMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj7igJMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1pa2Ug
Sm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnJmd0
Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgSmFudWFyeSA5LCAyMDIwIGF0IDExOjM0IEFN
PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAm
bHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDssIG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJRUQgU0VOREVSXSBSRTogQ3J5cHRvZ3JhcGhp
YyBoeWdpZW5lIGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2
MCI+VGhpcyBhIGdvb2QgdGhpbmcgdG8gdGhpbmsgYWJvdXQuJm5ic3A7IFRoYW5rcyBmb3IgYnJp
bmdpbmcgdGhpcyB1cCwgQW5uYWJlbGxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPk9uZSB0aGluZyB0aGF0IHBh
cnRpYWxseSBtaXRpZ2F0ZXMgdGhpcyBpcyB0aGF0IHRoZSDigJx1c2XigJ0gYW5kL29yIOKAnGtl
eV9vcHPigJ0gYXR0cmlidXRlcyBjYW4gYmUgcHJvdmlkZWQuJm5ic3A7IFRoaXMgY2FuIGFsbG93
IHNpZ25pbmcga2V5cyB0byBiZSBkaWZmZXJlbnRpYXRlZCBmcm9tIGVuY3J5cHRpb24ga2V5cywg
Zm9yIGluc3RhbmNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPknigJltIG5vdCBhcyB3b3JyaWVkIGFib3V0IGVu
Y3J5cHRpb24ga2V5cyBhcyBzaWduaW5nIGtleXMuJm5ic3A7IElmIG11bHRpcGxlIGtpbmRzIG9m
IGFwcGxpY2F0aW9ucyBlbmNyeXB0IGNvbnRlbnQgdG8gYSBwYXJ0eSB1c2luZyB0aGUgc2FtZSBw
dWJsaWMgcGVyLXBhcnR5IGtleSwgYW5kIHRoZSBlbmNyeXB0aW9uIGlzIGJlaW5nIHVzZWQgb25s
eQ0KIHRvIGVuc3VyZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIG1lc3NhZ2VzLCB0aGUgY29uZmlk
ZW50aWFsaXR5IGlzIHN0aWxsIGFjaGlldmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIw
NjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDIwNjAiPk9uZSBtaXRpZ2F0aW9u
IGZvciBzaWduaW5nIGtleXMgaXMgdXNlIG9mIHRoZSDigJx0eXDigJ0gZmllbGQsIGFzIGRlc2Ny
aWJlZCBpbiB0aGUgSldUIEJDUC4mbmJzcDsgRXZlbiBpZiB0aGUgc2FtZSBrZXkgd2FzIHVzZWQg
YW5kIHlvdSByZWNlaXZlIGFuIHVuZXhwZWN0ZWQgSldUIHR5cGUsIHlvdSB3aWxsIHN0aWxsIHJl
amVjdCBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtjb2xvcjojMDAyMDYwIj5JIGJlbGlldmUgdGhlcmXigJlzIGFsc28gY2FzZXMgd2hl
cmUgaXTigJlzIGZpbmUgdG8gdXNlIHRoZSBzYW1lIHNpZ25pbmcga2V5IGZvciByZWxhdGVkIG9w
ZXJhdGlvbnMuJm5ic3A7IEZvciBpbnN0YW5jZSwgc2lnbmluZyBhIFB1c2hlZCBBdXRob3JpemF0
aW9uIFJlcXVlc3QgYW5kIGEgUmVxdWVzdCBPYmplY3Qgd2l0aCB0aGUgc2FtZSBrZXkgc2VlbXMN
CiBib3RoIGxvZ2ljYWwgYW5kIHNhZmUgdG8gbWUuJm5ic3A7IChJZiBvdGhlcnMgY2FuIHRoaW5r
IG9mIGFuIGF0dGFjayB0aGF0IHRoaXMgZW5hYmxlcywgaG93ZXZlciwgcGxlYXNlIGRvIHBvaW50
IGl0IG91dC4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+V2hpY2ggSSBiZWxpZXZlIGxlYXZlcyB1cyB3aXRoIHRo
aXMgY2FzZSB0byB3b3JyeSBhYm91dCDigJMgc2hhcmVkIHNpZ25pbmcga2V5cyBieSB1bnJlbGF0
ZWQgYXBwbGljYXRpb25zIHdoZW4g4oCcdHlw4oCdIGlzIG5vdCB1c2VkLiZuYnNwOyBPbmUgd2F5
IHRvIG1pdGlnYXRlIHRoaXMgd291bGQgYmUgdG8gdXNlIHBlci1hcHBsaWNhdGlvbiBrZXkgc2V0
cy4mbmJzcDsNCiBGb3IgaW5zdGFuY2UsIHVzaW5nIHZhbHVlcyBvdGhlciB0aGFuIOKAnGp3a3Nf
dXJp4oCdIHRvIHJlZmVyZW5jZSBrZXkgc2V0cyBmb3IgcGFydGljdWxhciBhcHBsaWNhdGlvbnMu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Y29sb3I6IzAwMjA2MCI+QW55d2F5LCBmb3IgUEFSLCBJIGJlbGlldmUgdGhhdCBpdOKAmXMgZmlu
ZSB0byB1c2UgdGhlIHNhbWUga2V5cyBhcyB1c2VkIGZvciBSZXF1ZXN0IE9iamVjdHMsIHNvIG5v
IG5ldyBmaWVsZHMgYXJlIG5lZWRlZCBmb3IgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAw
MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMjA2MCI+SSBsb29rIGZvcndh
cmQgdG8gZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoZSB0b3BpYy48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMDAyMDYwIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5P
biBCZWhhbGYgT2YgPC9iPlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPGJyPg0KPGI+U2VudDo8
L2I+IFdlZG5lc2RheSwgSmFudWFyeSA4LCAyMDIwIDM6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IG9h
dXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdH
XSBDcnlwdG9ncmFwaGljIGh5Z2llbmUgYW5kIHRoZSBsaW1pdHMgb2Ygandrc191cmk8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+SSBvcmlnaW5hbGx5IGJyb3VnaHQgdXAgdGhpcyBpc3N1ZSBpbiB0aGUg
Y29udGV4dCBvZiB0aGUgUEFSIGRyYWZ0LCBidXQgc2luY2UgaXQgYnJvYWRseSBhcHBsaWVzIHRv
IHRoZSBPQXV0aCBzcGFjZSBJ4oCZbSBzdGFydGluZyBhIG5ldyB0aHJlYWTigKY8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz
LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0wNyUyM3NlY3Rpb24t
My4xMiZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M3
M2Q1NDdjNzY4MWY0ZWE1OWE0ODA4ZDc5NDk1MjllNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDEyNDA2OTcyOTU0NDUmYW1wO3NkYXRhPUFlUUx4Q2Fv
MlpUNjYxWksyZkU0YTZRS3loOEl6TyUyQnElMkZxemJ0N1ZsZDBzJTNEJmFtcDtyZXNlcnZlZD0w
Ij5TZWN0aW9uDQogMy4xMiBvZiB0aGUgSldUIEJDUDwvYT4gc2F5czog4oCcVXNlIGRpZmZlcmVu
dCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy7igJ0gPGEgaHJlZj0iaHR0cHM6Ly9u
YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG
dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0
LTAzJTIzc2VjdGlvbi00JmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9z
b2Z0LmNvbSU3QzczZDU0N2M3NjgxZjRlYTU5YTQ4MDhkNzk0OTUyOWU2JTdDNzJmOTg4YmY4NmYx
NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE0MTI0MDY5NzMwNTQwMiZhbXA7c2Rh
dGE9SVNzelR4bEhUYkFMSW5qSyUyRktnZ0g5c2VaZFc4a0dYVERIWkVXQ3lmQXpjJTNEJmFtcDty
ZXNlcnZlZD0wIj4NClNlY3Rpb24gNCBvZiB0aGUgSldUIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBB
Y2Nlc3MgVG9rZW5zPC9hPiBzYXlzOiDigJxBbiBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZWxl
Y3QgdG8gdXNlIGRpZmZlcmVudCBrZXlzIHRvIHNpZ24gaWRfdG9rZW5zIGFuZCBKV1QgYWNjZXNz
IHRva2Vucy7igJ0gVGhlc2Ugc3RhdGVtZW50cyBhcmUgY29uc2lzdGVudCB3aXRoIGdvb2QgY3J5
cHRvZ3JhcGhpYyBoeWdpZW5lLiBBbmQgd2XigJl2ZSBtYWRlIGl0IGRpZmZpY3VsdA0KIHRvIGlt
cG9zc2libGUgZm9yIGFuIEFTIHRvIGZvbGxvdyB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIEFTIGhhcyBhIHNpbmdsZSBtZXRhZGF0YSBkb2N1bWVu
dCBjb250YWluaW5nIGEgc2luZ2xlIFVSSSByZWZlcmVuY2luZyBhIHNpbmdsZSBKV0sgU2V0LiBC
dXQgdGhlIEFTIGhhcyBubyB3YXkgb2YgaW5kaWNhdGluZyB0byBjbGllbnRzIHdoaWNoIGtleXMg
dG8gdXNlIGZvciB3aGljaCBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIGFuIEFTIGNhbm5vdCBzYXkN
CiB0aGF0ICo8Yj5vbmx5PC9iPiA8Yj50aGVzZTwvYj4qIGtleXMgYXJlIHRvIGJlIHVzZWQgdG8g
ZW5jcnlwdCBpZF90b2tlbl9oaW50IEpXVHMsIGFuZCAqPGI+b25seSB0aGVzZTwvYj4qIGtleXMg
YXJlIHRvIGJlIHVzZWQgdG8gZW5jcnlwdCBKQVIgcmVxdWVzdCBvYmplY3QgSldUcy4gRm9yIGVu
Y3J5cHRpb24sIHRoZSBBUyBjb3VsZCBlbmZvcmNlIHRoYXQgbG9naWMgaW50ZXJuYWxseSwgYnV0
IHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIGNsaWVudA0KIHRvIGRpc2NvdmVyIHRoaXMuIEFuZCB3
aGlsZSB0aGUgQVMgbWF5IGJlIGJ1aWx0IHRvIG9ubHkgdXNlIGNlcnRhaW4ga2V5cyBmb3Igc2ln
bmluZyBJRCBUb2tlbnMgYW5kIG90aGVyIGtleXMgZm9yIHNpZ25pbmcgSldUIGFjY2VzcyB0b2tl
bnMsIGl0IGhhcyBubyB3YXkgdG8gaW5kaWNhdGUgdGhpcyB0byB0aGUgY2xpZW50LiBTbyBldmVu
IGlmIElEIFRva2VuIGdlbmVyYXRpb24gYW5kIGFjY2VzcyB0b2tlbiBnZW5lcmF0aW9uIGFyZSBp
c29sYXRlZA0KIGluIGRpZmZlcmVudCBtaWNyb3NlcnZpY2VzIHdpdGhpbiB0aGUgQVMsIGVhY2gg
bWljcm9zZXJ2aWNlIGlzIGNhcGFibGUgb2YgZm9yZ2luZyB0aGUgb3RoZXLigJlzIHRva2Vucywg
YmVjYXVzZSBjb25zdW1lcnMgY2Fu4oCZdCBiZSB0b2xkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g
ZGlmZmVyZW50IGtleXMgZm9yIHRoZSBBUy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPlRoaXMgc2VlbXMgbGlrZSBhIHRpY2tpbmcgdGltZSBib21iIHRvIG1lLCBh
cyBpdOKAmXMgYSBub24tb2J2aW91cyBzaWRlIGVmZmVjdCBvZiBjb21iaW5pbmcgdmFyaW91cyBP
QXV0aCAyLjAgZXh0ZW5zaW9ucywgYW5kIGl0IGNhbiB1bmRlcm1pbmUgYSBsb3Qgb2Ygc29waGlz
dGljYXRlZCBlZmZvcnQgdG8gZm9sbG93IHNlY3VyaXR5IGJlc3QgcHJhY3RpY2VzLg0KIEkgY2Fu
IHNlZSBhIGNvdXBsZSBvZiB3YXlzIHRvIGFkZHJlc3MgdGhpcyAoZS5nLiwgbW9yZSBzb3BoaXN0
aWNhdGVkIEFTIGtleSBtZXRhZGF0YSwgdGFnZ2luZyBvciBzaW1pbGFyIHVzZSBjYXNlIGluZGlj
YXRpb24gb24gSldLcyksIGJ1dCBiZWZvcmUgdHJ5aW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIEni
gJlkIGxpa2UgdG8gZ2V0IHBlb3BsZeKAmXMgb3BpbmlvbnMgb24gdGhlIHByb2JsZW0uIElzIHRo
aXMgYWxyZWFkeSBtaXRpZ2F0ZWQgaW4gb3RoZXINCiB3YXlzPyBIYXMgdGhlIHNoaXAgc2FpbGVk
IG9uIHRoaXMgZm9yIE9BdXRoLCBhbmQgbm93IHdlIGhhdmUgdG8gbGl2ZSB3aXRoIGl0PyBTaG91
bGQgdGhpcyBiZSBsZWZ0IHRvIHRoZSBkZXBsb3ltZW50cyB0aGF0IGNhcmUgdG8gc29sdmUgd2l0
aCBub24taW50ZXJvcGVyYWJsZSBzb2x1dGlvbnM/IEFyZSB0aGVyZSBvdGhlciBjbGV2ZXIgd2F5
cyB3ZSBjb3VsZCBhcHByb2FjaCB0aGlzPyBBcmUgdGhlcmUgb3RoZXIgYW5nbGVzIHRoYXQgd2Ug
bmVlZA0KIHRvIGNvbnNpZGVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJMmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_CDAB37280FB049A59A6C6F3794A6E1DBamazoncom_--


From nobody Thu Jan  9 17:26: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 53FA5120808 for ; Thu,  9 Jan 2020 17:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2E98em-4zhZ for ; Thu,  9 Jan 2020 17:26:01 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450: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 9D585120288 for ; Thu,  9 Jan 2020 17:26:00 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id o13so376751ljg.4 for ; Thu, 09 Jan 2020 17:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=shmL5Vs7jTOCZWkX+nvbpyFUA+C+V1kdJnbxjezbrEs=; b=A30qpRwtRh3SYeN08YXzqymqSkqSwdILYWx/18LxK0Q7q7qkmLrp6qd3nlHx0+Jfh0 l4IiAVzSvMAeL841sOCxeOZ4IywTqy53oYAKg7Jj9YeNrengNTNn6kLQOSdpapaC+lR5 6b/mF4vQUpE5/5FrEYGksI3h7cBHmuczeARdWLa/+JXXYRqyl/UFjMyqpMz7Sotj860S smSCD0NBc9sM3Efm5hMNl7d3dVl/ctq+J6RNZlwdeDof+elJ4atlzfEXwlMjKA96hr06 vjks5h98sAazuFK6yY79KN/4ANjSfzSX6hSo0GinaJQ6DOha2uD8ZPZPTTUzF1odsJcy Vunw==
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=shmL5Vs7jTOCZWkX+nvbpyFUA+C+V1kdJnbxjezbrEs=; b=bDClXE/kdRVa4CZb638W9AstT69bSj+M2fpwJ7Qrg2vaML+u62e+JjuoUlACSeb+Bv 0S0bG8Aq50ZRDjOthj1KMM1xzVfLgWhMxtEM3O2mHiv1IGmSRs9CaXzFGz0QWNz2aQa1 fAhD+mPZOQnm3qngQOUI2Nat/ZHh/yjOdtF//7iFWzalgu/b6U8O0SXiI8hVojdOv63B wot0N0tp7fU1r/lq8ivMx+RaQSQb8R/oOMj25Twj4dEpsb0sVqnL0zQ48mVo+PpDdxya 8joD+6+s3+ALYvEzbYBQO/C0myJImGb/1iNI1+4APqJlWFK7rOOTMArj4DKXjy3v73jQ KHjA==
X-Gm-Message-State: APjAAAUW/Wqy/YF4gBm9u4fNYYwumQ3ksR61DWnkJ99bSEbrDnvadKAA lYtpKtenjYnv+Suks+fVBq/6SQP953F54kSvVGtZrO0M
X-Google-Smtp-Source: APXvYqx/H9dfw5kbBlTvLX81WUHktvPmg9crJy0dheyj5v1RjrnEsCci3hSxHtOGaUNPuKmeynrukTEP8H+dqZWd4yo=
X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr637685ljo.240.1578619558724;  Thu, 09 Jan 2020 17:25:58 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 9 Jan 2020 17:25:47 -0800
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Mike Jones , oauth 
Content-Type: multipart/alternative; boundary="000000000000088a0a059bbf02e2"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 01:26:04 -0000

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

+1 to Annabelle's point

Different crypto operations should be able to use separate key pairs to
allow a separation of duties.
=E1=90=A7

On Thu, Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle  wrote:

> The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepresentation of a legi=
timately issued
> JWT, but it doesn=E2=80=99t address the issue I am trying to draw attenti=
on to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromis=
ed
> keys or systems.
>
>
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of th=
is
> in my original email, where ID Token generation and access token generati=
on
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have =
no
> way to recognize that these access tokens are fraudulent.
>
>
>
> Note that while =E2=80=9Ctyp=E2=80=9D would help a verifier distinguish b=
etween an ID
> Token and an access token, it does not help in this case because the
> malicious party is generating well-formed access token JWTs, signed with =
a
> key that is legitimate for the AS but not for this purpose.
>
>
>
> The case for this being a concern on the encryption side is fuzzier,
> primarily because we simply don=E2=80=99t have many use cases where diffe=
rent kinds
> of content gets encrypted and sent to the AS in different contexts.
> However, I gave one example on the PAR thread
> =
,
> where a PAR endpoint that decrypts request object JWTs will also be able =
to
> decrypt id_token_hint JWTs.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Mike Jones 
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" , oauth <
> oauth@ietf.org>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
>
>
> This a good thing to think about.  Thanks for bringing this up, Annabelle=
.
>
>
>
> One thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D=
 and/or =E2=80=9Ckey_ops=E2=80=9D
> attributes can be provided.  This can allow signing keys to be
> differentiated from encryption keys, for instance.
>
>
>
> I=E2=80=99m not as worried about encryption keys as signing keys.  If mul=
tiple
> kinds of applications encrypt content to a party using the same public
> per-party key, and the encryption is being used only to ensure
> confidentiality of the messages, the confidentiality is still achieved.
>
>
>
> One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D field=
, as described in
> the JWT BCP.  Even if the same key was used and you receive an unexpected
> JWT type, you will still reject it.
>
>
>
> I believe there=E2=80=99s also cases where it=E2=80=99s fine to use the s=
ame signing key
> for related operations.  For instance, signing a Pushed Authorization
> Request and a Request Object with the same key seems both logical and saf=
e
> to me.  (If others can think of an attack that this enables, however,
> please do point it out.)
>
>
>
> Which I believe leaves us with this case to worry about =E2=80=93 shared =
signing
> keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D is not used.  O=
ne way to mitigate
> this would be to use per-application key sets.  For instance, using value=
s
> other than =E2=80=9Cjwks_uri=E2=80=9D to reference key sets for particula=
r applications.
>
>
>
> Anyway, for PAR, I believe that it=E2=80=99s fine to use the same keys as=
 used for
> Request Objects, so no new fields are needed for it.
>
>
>
> I look forward to further discussion on the topic.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
>
>
>
> I originally brought up this issue in the context of the PAR draft, but
> since it broadly applies to the OAuth space I=E2=80=99m starting a new th=
read=E2=80=A6
>
>
>
> Section 3.12 of the JWT BCP
> 
> says: =E2=80=9CUse different keys for different kinds of JWTs.=E2=80=9D S=
ection 4 of the
> JWT Profile for OAuth 2.0 Access Tokens
> 
> says: =E2=80=9CAn authorization server MAY elect to use different keys to=
 sign
> id_tokens and JWT access tokens.=E2=80=9D These statements are consistent=
 with good
> cryptographic hygiene. And we=E2=80=99ve made it difficult to impossible =
for an AS
> to follow them.
>
>
>
> The AS has a single metadata document containing a single URI referencing
> a single JWK Set. But the AS has no way of indicating to clients which ke=
ys
> to use for which purposes. For example, an AS cannot say that **only*
> *these** keys are to be used to encrypt id_token_hint JWTs, and **only
> these** keys are to be used to encrypt JAR request object JWTs. For
> encryption, the AS could enforce that logic internally, but there is no w=
ay
> for the client to discover this. And while the AS may be built to only us=
e
> certain keys for signing ID Tokens and other keys for signing JWT access
> tokens, it has no way to indicate this to the client. So even if ID Token
> generation and access token generation are isolated in different
> microservices within the AS, each microservice is capable of forging the
> other=E2=80=99s tokens, because consumers can=E2=80=99t be told to distin=
guish between
> different keys for the AS.
>
>
>
> This seems like a ticking time bomb to me, as it=E2=80=99s a non-obvious =
side
> effect of combining various OAuth 2.0 extensions, and it can undermine a
> lot of sophisticated effort to follow security best practices. I can see =
a
> couple of ways to address this (e.g., more sophisticated AS key metadata,
> tagging or similar use case indication on JWKs), but before trying to
> propose something I=E2=80=99d like to get people=E2=80=99s opinions on th=
e problem. Is this
> already mitigated in other ways? Has the ship sailed on this for OAuth, a=
nd
> now we have to live with it? Should this be left to the deployments that
> care to solve with non-interoperable solutions? Are there other clever wa=
ys
> we could approach this? Are there other angles that we need to consider?
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1 to Annabelle's point

Differe=
nt crypto operations should be able to use separate=C2=A0key pairs to allow=
 a separation of duties.=C2=A0
3D""=E1=90=A7


--000000000000088a0a059bbf02e2--


From nobody Fri Jan 10 06:46: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 5D77B1200FF for ; Fri, 10 Jan 2020 06:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 q_otZjMdUZTQ for ; Fri, 10 Jan 2020 06:46:12 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CF31200F7 for ; Fri, 10 Jan 2020 06:46:11 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AEk823013703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 09:46:09 -0500
From: Justin Richer 
Message-Id: <7CC65CAE-64EC-4F42-AF23-DBB3183C13D9@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_03A913BF-1964-4F34-A5F9-EB8C310E2572"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 09:46:08 -0500
In-Reply-To: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
Cc: oauth@ietf.org
To: John Bradley 
References:         <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu>  <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu>  <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 14:46:20 -0000

--Apple-Mail=_03A913BF-1964-4F34-A5F9-EB8C310E2572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I believe the IESG was incorrect in their review and what=E2=80=99s in =
the text now is not what the WG agreed to.

Question is, what=E2=80=99s our next step, then?

 =E2=80=94 Justin

> On Jan 6, 2020, at 5:50 PM, John Bradley  wrote:
>=20
> My take would be that any paramater in the OAuth registy is a OAuth =
paramater.=20
>=20
> A client could duplicate those outside the request object for some =
sort of backwards compatability but they will be ignored.
>=20
> What we have lost is the merge capability.  There are some use cases =
that could use that to have a presigned object that some paramaters like =
state are outside.  =20
>=20
> That was not popular with the IESG. =20
>=20
> John B.
>=20
> On 1/6/2020 3:04 AM, n-sakimura wrote:
>> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if =
duplicated.
>> As of -13 (Mar 30, 2017), it was changed that the server does not =
have to do the merge, at least for OAuth Authorization request =
parameters. It says nothing about other parameters.
>> As of -14 (Jul 21, 2017), the wording was further strengthened by =
adding
>> =20
>> The Authorization Server MUST only use the parameters in the Request =
Object even if the same parameter is provided in the query parameter.
>> =20
>> So, the entire 6.3 now became
>>  <>6.3 =
.  =
Request Parameter Assembly and Validation
>>=20
>>    The Authorization Server MUST extract the set of Authorization
>>    Request parameters from the Request Object value.  The =
Authorization
>>    Server MUST only use the parameters in the Request Object even if =
the
>>    same parameter is provided in the query parameter.  The =
Authorization
>>    Server then validates the request as specified in OAuth 2.0
>>    [RFC6749 ].
>> =20
>> It says nothing on the non-OAuth parameters that came with the =
authorization request.
>> My take on the text is that all OAuth Authorization Request =
parameters MUST be in the request object.
>> Behaviors towards other parameters that happens to have come together =
with the authorization request outside of request object will be treated =
as non-OAuth parameters.
>> =20
>> Nat Sakimura
>> Research Fellow, Nomura Research Institute
>> E: n-sakimura@nri.co.jp 
>> T: +81(90)60136276
>> ---------------------------------------------------------
>> PLEASE READ:This  e-mail is confidential and intended for =
the named recipient only.
>> If you are not an intended recipient, please notify the sender and =
delete this e-mail.
>> =20
>> From: OAuth   =
On Behalf Of Justin Richer
>> Sent: Friday, January 3, 2020 2:35 AM
>> To: Takahiko Kawasaki  
>> Cc: Brian Campbell  =
; oauth =
 ; Nat Sakimura =
 
>> Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs =
OIDC request object
>> =20
>> For solution [2], this is the behavior that=E2=80=99s required for =
OIDC today, so I would say that=E2=80=99s the New Client behaving like =
an Old Client in order to talk to an Old Server. So in reality, (2) =
causes the request to be rejected, and that=E2=80=99s OK.
>> =20
>> I don=E2=80=99t think it=E2=80=99s viable to require parameters to =
exist inside the request object at all times. Nor should we try to =
enumerate which parameters go inside and outside at all times =E2=80=94 =
at least from the JAR/OAuth level of things. I think there are too many =
things that are application and deployment specific for us to make this =
call. The very nature of the request object changes for people =E2=80=94 =
some have a static object that=E2=80=99s deployed with clients and some =
have something that the client creates at runtime for each request.=20
>> =20
>> If the instead the New Server requires that any parameters duplicated =
between the two places have to match (the OIDC method) or that in a =
conflict the request object values take precedence (the merge method), =
then problems 3-1 and 3-2 go away.=20
>> =20
>> With the merge-and-precedence behavior, which is what I thought that =
JAR had during WGLC, [3-1] is well-defined. The request is processed the =
same way every time because this is a New Server. The client is going to =
do OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge =
with precedence=E2=80=9D is effectively a no-op.
>> =20
>> With the merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen =
because the required parameters aren=E2=80=99t required to be in the =
request object itself. As long as the request object is valid, it =
protects all parameters within it. I don=E2=80=99t think it=E2=80=99s up =
to us to determine what makes sense to put in that object. Security =
guidance is probably a good idea here.
>> =20
>> Solution [3] is what Old Clients already do in OIDC today, so =
that=E2=80=99s what already happens and why problem space (3) isn=E2=80=99=
t a problem.
>> =20
>>  =E2=80=94 Justin
>>=20
>>=20
>> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki > wrote:
>> =20
>> Thank you, Justin. Actually, I wanted to see someone write a summary =
about what happens in each combination from a viewpoint of both RP and =
AS with regard to backward compatibility (as I told you in other channel =
just before you posted your email ^_^).
>>=20
>> So,
>>=20
>> (1) New Client + New Server
>> No problem will happen.
>>=20
>> (2) New Client + Old Server
>> [Problem 2-1] If an authorization request contains 'request' or =
'request_uri' but doesn't have old mandatory request parameters =
('client_id' and 'response_type') outside the request object, the =
request is rejected.
>>=20
>> [Solution 2] New Client should include the old mandatory request =
parameters duplicately outside the request object. This means that New =
Client should always send old mandatory request parameters duplicately =
outside the request object if it wants to get maximum compatibility.
>>=20
>> (3) Old Client + New Server
>> [Problem 3-1] If an authorization request contains 'request' or =
'request_uri' and some "optional" request parameters are not included in =
the request object, AS will interpret the request differently. Imagine =
what happens when optional parameters such as 'scope', 'state', 'nonce', =
'redirect_uri', 'response_mode', 'max_age', 'acr_values', =
'code_challenge', 'code_challenge_method' and 'prompt' are not included =
in the request object but present outside the request object.
>>=20
>> [Problem 3-2] If an authorization request contains 'request' or =
'request_uri' and some "mandatory" request parameters ('client_id' and =
'response_type') are not included in the request object, the request is =
rejected.
>>=20
>> [Solution 3] Old Client should include all request parameters =
duplicately in the request object. This means that Old Client should =
always include all request parameters duplicately in the request object =
if it wants to get maximum compatibility.
>>=20
>> (4) Old Client + Old Server
>> No problem will happen.
>>=20
>> - - -
>>=20
>> =46rom a Client's point of view, for maximum compatibility, both Old =
and New Clients should put mandatory request parameters outside the =
request object and put all request parameters duplicately inside the =
request object.
>>=20
>> [Problem 3-1] is difficult to detect because the authorization =
request is not rejected. But, if New Server requires that all request =
parameters outside the request object be put inside the request object =
duplicately, [Problem 3-1] is handled as an error and thus client =
developers can detect the problem.
>>=20
>> Consequently, introducing the following requirement in "FAPI Part 2, =
5.2.2 =
, 10" to JAR seems a good compromise (as I told before)
>>=20
>> shall require that all parameters are present inside the signed =
request object passed in the request or request_uri parameter;
>>=20
>> instead of just saying "the authorization server supporting this =
specification MUST only use the parameters included in the request =
object." which will bring about [Problem 3-1]. That is, how about adding =
a rule like "if request parameters exist outside the request object, =
they must exist inside the request object, too."?
>>=20
>> Any thoughts?
>> =20
>> Best,
>> Taka
>> =20
>> =20
>> On Fri, Jan 3, 2020 at 12:48 AM Justin Richer > wrote:
>> I think the nature of the backwards incompatibility is important =
here. The way that things are now, using merge-with-precedence, you have =
the following matrix of compatibility:
>> =20
>> =20
>>              New Server  |  Old Server  |
>> -----------+-------------+--------------+
>> New Client |      YES    |      NO      |
>> Old Client |      YES    |     YES      |
>> =20
>> =20
>> If you ask me, this is the right balance for a breaking change. Old =
clients, where the vast majority of the code is, don=E2=80=99t have to =
change. New clients can only talk to servers with the new features, =
which is the ability to drop parameters from the external request. This =
would apply to both OIDC and plain OAuth.
>> =20
>> I think we should follow this kind of pattern in the discussions on =
OAuth 2.1, which I think JAR should be a part of/
>> =20
>>  =E2=80=94 Justin
>> =20
>> =20
>>=20
>>=20
>> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki > wrote:
>> =20
>> Breaking backward compatibility in this part would mean that OpenID =
Certification given to AS implementations with request_uri support will =
be invalidated once they support JAR. It also would mean that test cases =
in the official conformance suite need to be changed in a =
backward-incompatible manner, which would implicitly encourage that all =
certified implementations should re-try to get certification.
>>=20
>> Changing the spec now might need more three to six months, but it =
would be worth considering what we get and lose by saving the months and =
breaking backward compatibility.
>>=20
>> Best Regards,
>> Taka
>> =20
>> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura > wrote:
>> So, no change is OK?=20
>> =20
>> On Wed, Dec 11, 2019 at 10:01 PM John Bradley > wrote:
>> I also slightly prefer the merge approach.=20
>> =20
>> There are plusses and minuses to both.=20
>> =20
>> Changing again now that it is past ISEG review and backing out a =
Discuss will add another three to six months at this point, if we can =
get them to agree to the change.=20
>> =20
>> John B.=20
>> =20
>> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura > wrote:
>> Correct. The WG supported the precedence approach and even merge just =
like OIDC as it is very useful from the implementation point of view and =
helps with a bunch of deployment patter.=20
>> =20
>> The push back came in from the Ben Campbell=E2=80=99s DISCUSS.=20
>> See=20
>> =
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actua=
lly-specifies-the =

>> =20
>> I am willing to go either way as long as people agree. My slight =
preference is to the original approach.=20
>> =20
>> Best,=20
>> =20
>> Nat Sakimura
>> =20
>> 2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian Campbell =
>:
>> FWIW, as best I can remember the change in question came as I result =
of directorate/IESG review rather than a WG decision/discussion. Which =
is likely why you can't find the "why" anywhere in the mailing list =
archive.
>> =20
>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan > wrote:
>> Well it kind of blows, doesn't it? I wasn't able to find the "why" =
anywhere in the mailing list archive around the time this was changed.
>> =20
>> My take on satisfying both worlds looks like this
>> =20
>> - allow just JAR - no other params when possible.
>>     (which btw isn't possible to do with request_uri when enforcing =
client based uri whitelist and the jwsreq 5.2.2 shows as much)
>> - enforce the "dupe behaviours" defined in OIDC (if response_type or =
client_id is in request object it must either be missing or the same in =
regular request).
>> - allows merging request object and regular parameters with request =
object taking precedence since it is a very useful feature when having =
pre-signed request object that's not one time use and clients using it =
wish to vary state/nonce per-request.
>> =20
>> I wish the group reconsidered making this breaking change from OIDC's =
take on request objects - allow combination of parameters from the =
request object with ones from regular parameters (if not present in =
request object).
>>=20
>> S pozdravem,
>> Filip Skokan
>> =20
>> =20
>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell =
> wrote:
>> Filip, for better or worse, I believe your assessment of the =
situation is correct. I know of one AS that didn't choose which of the =
two to follow but rather implemented a bit of a hybrid where it =
basically ignores everything outside of the request object per JAR but =
also checks for and enforces the presence and value of the few regular =
parameters (client_id, response_type) that OIDC mandates.
>> =20
>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan > wrote:
>> Hello everyone,
>> =20
>> in an earlier thread I've posed the following question that might =
have gotten missed, this might have consequences for the existing =
implementations of Request Objects in OIDC implementations - its making =
pure JAR requests incompatible with OIDC Core implementations.
>> =20
>> draft 14 of jwsreq (JAR) introduced this language
>> =20
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object.=20
>> =20
>> Server MUST only use the parameters in the Request Object even if the
>> same parameter is provided in the query parameter.  The Authorization
>> =20
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object..=20
>> =20
>> Nat, John, everyone - does this mean a JAR compliant AS ignores =
everything outside of the request object while OIDC Request Object one =
merges the two with the ones in the request object being used over ones =
that are sent in clear? The OIDC language also includes sections which =
make sure that some required arguments are still passed outside of the =
request object with the same value to make sure the request is "valid" =
OAuth 2.0 request (client_id, response_type), something which an example =
in the JAR spec does not do. Not having this language means that =
existing authorization request pipelines can't simply be extended with =
e.g. a middleware, they need to branch their codepaths.
>> =20
>> Is an AS required to choose which of the two it follows?
>> =20
>> Thank you for clarifying this in advance. I think if either the =
behaviour is the same as in OIDC or different this should be called out =
in the language to avoid confusion, especially since this already exists =
in OIDC and likely isn't going to be read in isolation, especially =
because the Request Object is even called out to be already in place in =
OIDC in the JAR draft.
>> =20
>> Best,
>> Filip
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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

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

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


--Apple-Mail=_03A913BF-1964-4F34-A5F9-EB8C310E2572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
believe the IESG was incorrect in their review and what=E2=80=99s in the =
text now is not what the WG agreed to.

Question is, what=E2=80=99s our next =
step, then?

 =E2=80=94 Justin

On Jan =
6, 2020, at 5:50 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

My =
take would be that any paramater in the OAuth registy is a OAuth =
paramater. 
A client could duplicate those outside the request =
object for some sort of backwards compatability but they will be =
ignored.
What we have lost is the merge capability.  There =
are some use cases that could use that to have a presigned object that =
some paramaters like state are outside.   
That =
was not popular with the IESG.  
John =
B.
On 1/6/2020 3:04 AM, n-sakimura wrote:
Up until -12 (Feb 13, 2017), it =
was using merge + JAR precedence if duplicated.
As of -13 (Mar 30, 2017), it was =
changed that the server does not have to do the merge, at least for =
OAuth Authorization request parameters. It says nothing about other =
parameters.
As of -14 (Jul 21, 2017), the =
wording was further strengthened by adding
 
The Authorization Server MUST only use the =
parameters in the Request Object even if the same parameter is provided =
in the query parameter.
 
So, the entire 6.3 now became
6.3.  Request Parameter Assembly and =
Validation
   The Authorization Server MUST =
extract the set of Authorization
   Request =
parameters from the Request Object value.  The Authorization
   Server MUST only use the =
parameters in the Request Object even if the
   same parameter is provided in the =
query parameter.  The Authorization
   Server then validates the request =
as specified in OAuth 2.0
   [RFC6749].
 
It says nothing on the non-OAuth =
parameters that came with the authorization request.
My take on the text is that all =
OAuth Authorization Request parameters MUST be in the request =
object.
Behaviors towards other parameters =
that happens to have come together with the authorization request =
outside of request object will be treated as non-OAuth parameters.
 
Nat Sakimura
Research Fellow, =
Nomura Research Institute
E: n-sakimura@nri.co.jp
T: =
+81(90)60136276
---------------------------------------------------------
PLEASE READ:This e-mail is confidential and =
intended for the named recipient only.
If you are not an =
intended recipient, please notify the sender and delete this e-mail.
 
From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of Justin =
Richer
Sent: Friday, January 3, 2020 =
2:35 AM
To: Takahiko Kawasaki <taka@authlete.com>
Cc: Brian=
 Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>; =
oauth <oauth@ietf.org>; Nat Sakimura <nat.sakimura@oidf.org>
Subject: Re: [OAUTH-WG] JWT Secured =
Authorization Request (JAR) vs OIDC request object
 
For =
solution [2], this is the behavior that=E2=80=99s required for OIDC =
today, so I would say that=E2=80=99s the New Client behaving like an Old =
Client in order to talk to an Old Server. So in reality, (2) causes the =
request to be rejected, and that=E2=80=99s OK.
 
I don=E2=80=99t think it=E2=80=99s viable to =
require parameters to exist inside the request object at all times. Nor =
should we try to enumerate which parameters go inside and outside at all =
times =E2=80=94 at least from the JAR/OAuth level of things. I think =
there are too many things that are application and deployment specific =
for us to make this call. The very nature of the request object changes =
for people =E2=80=94 some have a static object that=E2=80=99s deployed =
with clients and some have something that the client creates at runtime =
for each request. 
 
If the instead the New =
Server requires that any parameters duplicated between the two places =
have to match (the OIDC method) or that in a conflict the request object =
values take precedence (the merge method), then problems 3-1 and 3-2 go =
away. 
 
With the =
merge-and-precedence behavior, which is what I thought that JAR had =
during WGLC, [3-1] is well-defined. The request is processed the same =
way every time because this is a New Server. The client is going to do =
OIDC=E2=80=99s =E2=80=9Cduplicate=E2=80=9D method, so =E2=80=9Cmerge =
with precedence=E2=80=9D is effectively a no-op.
 
With the =
merge-and-precedence behavior, [3-2] doesn=E2=80=99t happen because the =
required parameters aren=E2=80=99t required to be in the request object =
itself. As long as the request object is valid, it protects all =
parameters within it. I don=E2=80=99t think it=E2=80=99s up to us to =
determine what makes sense to put in that object. Security guidance is =
probably a good idea here.
 
Solution [3] is what Old =
Clients already do in OIDC today, so that=E2=80=99s what already happens =
and why problem space (3) isn=E2=80=99t a problem.
 
 =E2=80=94 =
Justin


On Jan 2, =
2020, at 12:24 PM, Takahiko Kawasaki <taka@authlete.com>=
 wrote:
 
Thank you, Justin. Actually, I wanted to see =
someone write a summary about what happens in each combination from a =
viewpoint of both RP and AS with regard to backward compatibility (as I =
told you in other channel just before you posted your email ^_^).

So,

(1) New Client + New Server
No problem will =
happen.

(2) New Client + Old =
Server
[Problem 2-1] If an authorization request =
contains 'request' or 'request_uri' but doesn't have old mandatory =
request parameters ('client_id' and 'response_type') outside the request =
object, the request is rejected.

[Solution 2] New Client should include =
the old mandatory request parameters duplicately outside the request =
object. This means that New Client should always send old mandatory =
request parameters duplicately outside the request object if it wants to =
get maximum compatibility.

(3) =
Old Client + New Server
[Problem =
3-1] If an =
authorization request contains 'request' or 'request_uri' and some =
"optional" request parameters are not included in the request object, AS =
will interpret the request differently. Imagine what happens when =
optional parameters such as 'scope', 'state', 'nonce', 'redirect_uri', =
'response_mode', 'max_age', 'acr_values', 'code_challenge', =
'code_challenge_method' and 'prompt' are not included in the request =
object but present outside the request object.

[Problem 3-2] If an authorization request =
contains 'request' or 'request_uri' and some "mandatory" request =
parameters ('client_id' and 'response_type') are not included in the =
request object, the request is rejected.

[Solution 3] Old Client should include =
all request parameters duplicately in the request object. This means =
that Old Client should always include all request parameters duplicately =
in the request object if it wants to get maximum compatibility.

(4) Old Client + Old =
Server
No problem will happen.

- - -

=46rom =
a Client's point of view, for maximum compatibility, both Old and New =
Clients should put mandatory request parameters outside the request =
object and put all request parameters duplicately inside the request =
object.

[Problem 3-1] is difficult to =
detect because the authorization request is not rejected. But, if New =
Server requires that all request parameters outside the request object =
be put inside the request object duplicately, [Problem 3-1] is handled =
as an error and thus client developers can detect the problem.

Consequently, introducing the following =
requirement in "FAPI Part 2, 5.2.2, 10" to JAR seems a =
good compromise (as I told before)
shall require that all parameters are present =
inside the signed request object passed in the request or request_uri =
parameter;

instead =
of just saying "the authorization server supporting this specification =
MUST only use the parameters included in the request object." which will =
bring about [Problem 3-1]. That is, how about adding a rule like "if =
request parameters exist outside the request object, they must exist =
inside the request object, too."?

Any =
thoughts?
 
Best,
Taka
 
 
On Fri, Jan 3, 2020 at =
12:48 AM Justin Richer <jricher@mit.edu> wrote:
I think the nature of the backwards =
incompatibility is important here. The way that things are now, using =
merge-with-precedence, you have the following matrix of =
compatibility:
 
 
      =
       New Server  |  Old Server =
 |
-----------+-------------+--------------+
New Client =
|      YES    |      NO   =
   |
Old Client |      YES   =
 |     YES      |
 
 
If you ask me, this is =
the right balance for a breaking change. Old clients, where the vast =
majority of the code is, don=E2=80=99t have to change. New clients can =
only talk to servers with the new features, which is the ability to drop =
parameters from the external request. This would apply to both OIDC and =
plain OAuth.
 
I think we should follow =
this kind of pattern in the discussions on OAuth 2.1, which I think JAR =
should be a part of/
 
 =E2=80=94 =
Justin
 
 


On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki =
<taka@authlete.com> wrote:
 
Breaking backward compatibility in this part =
would mean that OpenID Certification given to AS implementations with =
request_uri support will be invalidated once they support JAR. It also =
would mean that test cases in the official conformance suite need to be =
changed in a backward-incompatible manner, which would implicitly =
encourage that all certified implementations should re-try to get =
certification.

Changing the spec now might =
need more three to six months, but it would be worth considering what we =
get and lose by saving the months and breaking backward =
compatibility.

Best Regards,
Taka
 
On Wed, Dec 18, 2019 at =
4:14 PM Nat Sakimura <sakimura@gmail.com> =
wrote:
So, no change is =
OK? 
 
On Wed, Dec 11, 2019 at 10:01 PM John Bradley =
<ve7jtb@ve7jtb.com> wrote:
I also slightly prefer the merge =
approach. 
 
There are plusses and =
minuses to both. 
 
Changing again now that =
it is past ISEG review and backing out a Discuss will add another three =
to six months at this point, if we can get them to agree to the =
change. 
 
John B. 
 
On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura =
<sakimura@gmail.com> wrote:
Correct. =
The WG supported the precedence approach and even merge just like OIDC =
as it is very useful from the implementation point of view and helps =
with a bunch of deployment patter. 
 
The push back came in =
from the Ben Campbell=E2=80=99s DISCUSS. 
See 
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current=
-text-actually-specifies-the
 
I am willing to go =
either way as long as people agree. My slight preference is to the =
original approach. 
 
Best, 
 
Nat Sakimura
 
2019=E5=B9=B48=E6=9C=8829=E6=97=A5(=E6=9C=A8) 6:56 Brian =
Campbell <bcampbell=3D40pingidentity..com@dmarc.ietf.org>:
FWIW, as best I can remember the change in =
question came as I result of directorate/IESG review rather than a WG =
decision/discussion. Which is likely why you can't find the "why" =
anywhere in the mailing list archive.
 
On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan =
<panva.ip@gmail.com> wrote:
Well it =
kind of blows, doesn't it? I wasn't able to find the "why" anywhere in =
the mailing list archive around the time this was changed.
 
My take on satisfying =
both worlds looks like this
 
- allow just JAR - no =
other params when possible.
  =
  (which btw isn't possible to do with request_uri when enforcing =
client based uri whitelist and the jwsreq 5.2.2 shows as much)
- enforce the "dupe behaviours" defined in =
OIDC (if response_type or client_id is in request object it must either =
be missing or the same in regular request).
- allows merging request object and regular =
parameters with request object taking precedence since it is a very =
useful feature when having pre-signed request object that's not one time =
use and clients using it wish to vary state/nonce per-request.
 
I wish the group =
reconsidered making this breaking change from OIDC's take on request =
objects - allow combination of parameters from the request object with =
ones from regular parameters (if not present in request object).

S pozdravem,
Filip Skokan
 
 
On Wed, 28 Aug 2019 at 23:02, Brian Campbell =
<bcampbell@pingidentity.com> wrote:
Filip, for =
better or worse, I believe your assessment of the situation is correct. =
I know of one AS that didn't choose which of the two to follow but =
rather implemented a bit of a hybrid where it basically ignores =
everything outside of the request object per JAR but also checks for and =
enforces the presence and value of the few regular parameters =
(client_id, response_type) that OIDC mandates.
 
On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan =
<panva.ip@gmail.com> wrote:
Hello everyone,
 
in an earlier thread =
I've posed the following question that might have gotten missed, this =
might have consequences for the existing implementations of Request =
Objects in OIDC implementations - its making pure JAR requests =
incompatible with OIDC Core implementations.
 
draft 14 of jwsreq (JAR) =
introduced this language
 
The client =
MAY send the parameters included in the request object
duplicated in the query parameters as well for the =
backward
compatibility etc.  However, =
the authorization server supporting this
specification =
MUST only use the parameters included in the request
object. 
 
Server MUST only use the parameters in the =
Request Object even if the
same parameter is provided in =
the query parameter.  The Authorization
 
The client =
MAY send the parameters included in the request object
duplicated in the query parameters as well for the =
backward
compatibility etc.  However, =
the authorization server supporting this
specification =
MUST only use the parameters included in the request
object.. 
 
Nat, John, =
everyone - does this mean a JAR compliant AS ignores =
everything outside of the request object while OIDC Request Object one =
merges the two with the ones in the request object being used over ones =
that are sent in clear? The OIDC language also includes =
sections which make sure that some required arguments are still passed =
outside of the request object with the same value to make sure the =
request is "valid" OAuth 2.0 request (client_id, response_type), =
something which an example in the JAR spec does not do. Not having this =
language means that existing authorization request pipelines can't =
simply be extended with e.g. a middleware, they need to branch their =
codepaths.
 
Is an AS required to =
choose which of the two it follows?
 
Thank you for clarifying =
this in advance. I think if either the behaviour is the same as in OIDC =
or different this should be called out in the language to avoid =
confusion, especially since this already exists in OIDC and likely isn't =
going to be read in isolation, especially because the Request Object is =
even called out to be already in place in OIDC in the JAR draft.
 
Best,
Filip
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
=

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

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

 
-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
On Thu, =
Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wr=
ote:











The =E2=80=9Ctyp=E2=
=80=9D field helps prevent misrepresentation of a legitimately issued JWT, =
but it doesn=E2=80=99t address the issue I am trying to draw attention to, =
which is that the current model forces broader distribution
 and reuse of keys than is necessary, resulting in a greater blast radius f=
or compromised keys or systems.


=C2=A0<=
/span>


For many cases, this =
is not a significant concern, as the AS is a monolithic system with no inte=
rnal trust boundaries. However, in cases where the AS is composed of multip=
le microservices performing different
 tasks, the need to share keys between different microservices undermines e=
fforts to create trust boundaries between them. I gave one example of this =
in my original email, where ID Token generation and access token generation=
 are relegated to independent systems,
 each with separate private keys for signing tokens. Suppose a malicious pa=
rty compromised the ID Token generator, or gained access to its private key=
, and issued fraudulent access tokens signed using that key. Since verifier=
s of both token types will look
 to the same metadata file and thus the same JWK set, they have no way to r=
ecognize that these access tokens are fraudulent.


=C2=A0<=
/span>


Note that while =E2=
=80=9Ctyp=E2=80=9D would help a verifier distinguish between an ID Token an=
d an access token, it does not help in this case because the malicious part=
y is generating well-formed access token JWTs, signed
 with a key that is legitimate for the AS but not for this purpose.<=
u>


=C2=A0<=
/span>


The case for this bei=
ng a concern on the encryption side is fuzzier, primarily because we simply=
 don=E2=80=99t have many use cases where different kinds of content gets en=
crypted and sent to the AS in different contexts.
 However, 
I gave one example on the PAR thread, where a PAR endpoint that decrypt=
s request object JWTs will also be able to decrypt id_token_hint JWTs.


=C2=A0<=
/span>




=E2=80=93=C2=A0


Annabelle Richard Backman


AWS Identity




=C2=A0<=
/span>


=C2=A0<=
/span>




From: Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.=
org>

Date: Thursday, January 9, 2020 at 11:34 AM

To: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <=
oauth@ietf.org><=
br>
Subject: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limit=
s of jwks_uri






=C2=A0<=
/span>




Th=
is a good thing to think about.=C2=A0 Thanks for bringing this up, Annabell=
e.


=
=C2=A0


On=
e thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D and=
/or =E2=80=9Ckey_ops=E2=80=9D attributes can be provided.=C2=A0 This can al=
low signing keys to be differentiated from encryption keys, for instance.


=
=C2=A0


I=
=E2=80=99m not as worried about encryption keys as signing keys.=C2=A0 If m=
ultiple kinds of applications encrypt content to a party using the same pub=
lic per-party key, and the encryption is being used only
 to ensure confidentiality of the messages, the confidentiality is still ac=
hieved.


=
=C2=A0


On=
e mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D field, as=
 described in the JWT BCP.=C2=A0 Even if the same key was used and you rece=
ive an unexpected JWT type, you will still reject it.<=
/p>

=
=C2=A0


I =
believe there=E2=80=99s also cases where it=E2=80=99s fine to use the same =
signing key for related operations.=C2=A0 For instance, signing a Pushed Au=
thorization Request and a Request Object with the same key seems
 both logical and safe to me.=C2=A0 (If others can think of an attack that =
this enables, however, please do point it out.)


=
=C2=A0


Wh=
ich I believe leaves us with this case to worry about =E2=80=93 shared sign=
ing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D is not used.=
=C2=A0 One way to mitigate this would be to use per-application key sets.=
=C2=A0
 For instance, using values other than =E2=80=9Cjwks_uri=E2=80=9D to refere=
nce key sets for particular applications.


=
=C2=A0


An=
yway, for PAR, I believe that it=E2=80=99s fine to use the same keys as use=
d for Request Objects, so no new fields are needed for it.=



=
=C2=A0


I =
look forward to further discussion on the topic.


=
=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 Richard Backman, Annabelle

Sent: Wednesday, January 8, 2020 3:47 PM

To: oauth <oa=
uth@ietf.org>

Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri=







=C2=A0


I originally brought =
up this issue in the context of the PAR draft, but since it broadly applies=
 to the OAuth space I=E2=80=99m starting a new thread=E2=80=A6


=C2=A0<=
u>


S=
ection
 3.12 of the JWT BCP says: =E2=80=9CUse different keys for different ki=
nds of JWTs.=E2=80=9D 
Section 4 of the JWT Profile for OAuth 2.0 Access Tokens says: =E2=80=
=9CAn authorization server MAY elect to use different keys to sign id_token=
s and JWT access tokens.=E2=80=9D These statements are consistent with good=
 cryptographic hygiene. And we=E2=80=99ve made it difficult
 to impossible for an AS to follow them.


=C2=A0<=
u>


The AS has a single m=
etadata document containing a single URI referencing a single JWK Set. But =
the AS has no way of indicating to clients which keys to use for which purp=
oses. For example, an AS cannot say
 that *only these* keys are to be used to encrypt id_token_hi=
nt JWTs, and *only these* keys are to be used to encrypt JAR request=
 object JWTs. For encryption, the AS could enforce that logic internally, b=
ut there is no way for the client
 to discover this. And while the AS may be built to only use certain keys f=
or signing ID Tokens and other keys for signing JWT access tokens, it has n=
o way to indicate this to the client. So even if ID Token generation and ac=
cess token generation are isolated
 in different microservices within the AS, each microservice is capable of =
forging the other=E2=80=99s tokens, because consumers can=E2=80=99t be told=
 to distinguish between different keys for the AS.


=C2=A0<=
u>


This seems like a tic=
king time bomb to me, as it=E2=80=99s a non-obvious side effect of combinin=
g various OAuth 2.0 extensions, and it can undermine a lot of sophisticated=
 effort to follow security best practices.
 I can see a couple of ways to address this (e.g., more sophisticated AS ke=
y metadata, tagging or similar use case indication on JWKs), but before try=
ing to propose something I=E2=80=99d like to get people=E2=80=99s opinions =
on the problem. Is this already mitigated in other
 ways? Has the ship sailed on this for OAuth, and now we have to live with =
it? Should this be left to the deployments that care to solve with non-inte=
roperable solutions? Are there other clever ways we could approach this? Ar=
e there other angles that we need
 to consider?


=C2=A0<=
u>


=E2=80=93=C2=A0


Annabelle Richard Backman


AWS Identity


=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


<=
/blockquote>
 

_____________________________=
__________________
OAuth mailing 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=_03A913BF-1964-4F34-A5F9-EB8C310E2572--


From nobody Fri Jan 10 06: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 0C55212016E for ; Fri, 10 Jan 2020 06:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 1yeQyOkIjREd for ; Fri, 10 Jan 2020 06:48:36 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEC51200F7 for ; Fri, 10 Jan 2020 06:48:36 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AEmX5R014436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 09:48:33 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_372B2DDE-711B-41BC-846B-24A1D64672B3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 09:48:32 -0500
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef 
References: 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 14:48:39 -0000

--Apple-Mail=_372B2DDE-711B-41BC-846B-24A1D64672B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

With the comment that there=E2=80=99s going to be a lot of coordination =
between this and other components already in OAuth 2 (scope, resource, =
aud/audience, JAR stuff) and anything that might come out of TxAuth. =
Those are two of my main goals as co-author of this work.

 =E2=80=94 Justin

> On Jan 6, 2020, at 2:37 PM, Rifaat Shekh-Yusef  =
wrote:
>=20
> All,
>=20
> This is a call for adoption for the OAuth 2.0 Rich Authorization =
Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ =
=20
> =20
> Please, let us know if you support or object to the adoption of this =
document as a working group document by Jan 20th.
>=20
> Regards,
>  Rifaat & Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_372B2DDE-711B-41BC-846B-24A1D64672B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1

With =
the comment that there=E2=80=99s going to be a lot of coordination =
between this and other components already in OAuth 2 (scope, resource, =
aud/audience, JAR stuff) and anything that might come out of TxAuth. =
Those are two of my main goals as co-author of this work.

 =E2=80=94 =
Justin

=

--Apple-Mail=_372B2DDE-711B-41BC-846B-24A1D64672B3--


From nobody Fri Jan 10 06:49: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 B7FAF1200FF for ; Fri, 10 Jan 2020 06:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKtIHeUA78oR for ; Fri, 10 Jan 2020 06:49:23 -0800 (PST)
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 0E2F81200F7 for ; Fri, 10 Jan 2020 06:49:23 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a5so2305575wmb.0 for ; Fri, 10 Jan 2020 06:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=osZNMqeF9rqMJ6b8Ulf2PpBQFAmnL6BPK4tQ6u85hHk=; b=XaLbNFUGVSpJwIjQqXDaQCeB6gzPoPTQ22pGO1PhqBA3hDQz3AEkOR6x1mV+ELfyFS rL08itd/8AkYbWnEfWQ09iIKYLVU0cJXEV3NYyMQt2TSt7QDfqeyeWPEc3+Ywlg3XkBV VjchB8PongBdb2ddWPVgEUCYZy7Q3+J6BUOS4puI1pkVrfRnzcCg/pZKd+rNOWFMLMLk EMhLd3PzRacM2ILCrq7jBkQKo8nRiiPxPw2bvADpUKnA5nHjo858e4Itda0Fr5Gp8cGn 6kxGay95s2L7Os46rsB9E5tN45nXe0JiobXn2I3cR+FnnJ2GyRbOnLDTZRIIURdgAX4e r8hw==
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=osZNMqeF9rqMJ6b8Ulf2PpBQFAmnL6BPK4tQ6u85hHk=; b=f2i5CYfR2XMsCSoSFt3Ydd3gE9j4rjxBZ8A10OUPBnjAPBX+Fj6jJl/YJUu4WSw3iI MlUrnrkleonvKcKeJ/+53cq4yXRgUo48xaMbxwkSxx/wohmH3PKWyd0d4RTQhURx/lFd BdMGAfghv2AaR6IlU8VL4xjJsFZVQFXBkLS8ZYBg3OVWlBnTMYyLxshTAV+2kaNdEbEc nQFePIOehqlrDQlu84MiXnxfzlOr1zlvXGLX8QLQjsrO5ZYIlseuL31mswSq1u8908Yl okOxizNvXtmSdyPyi/4Hud/Yh98YKpN9cgKmTIrjMmJ3p41zCVgKoJWmHxm+1V0DJpTs cYlw==
X-Gm-Message-State: APjAAAVj390ok+wFi8QUT0FMboHAuQzsBoQVyT3b7QVNkUMUviW6Oaji UevBNaDrdR+zQcAkzcGNEaPR0aXdgeRfiAb4FOzrXA==
X-Google-Smtp-Source: APXvYqx0pCzPWxlbDB/z8DTShD0XxPgFPUPx2Kx7VhLFvm2/HFdP0vFHdJ/witNfRmCul/fnakfWRoMxGyqqaUdcsAE=
X-Received: by 2002:a1c:61c1:: with SMTP id v184mr4755365wmb.160.1578667761312;  Fri, 10 Jan 2020 06:49:21 -0800 (PST)
MIME-Version: 1.0
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com> <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>
In-Reply-To: <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>
From: John Bradley 
Date: Fri, 10 Jan 2020 11:49:08 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: IETF oauth WG 
Content-Type: multipart/alternative; boundary="00000000000021bc09059bca3bff"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 14:49:26 -0000

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

I haven't seen any real use of merge.   It happens with Connect as a side
effect of OAuths current requirement to have some of the parameters outside
the JAR.

Nothing stops servers from ignoring parameters outside JAR or acting on
query parameters outside the JAR if they are not in the OAuth registry.   A
server can merge but that would not be JAR compliant if they care.

If the AS returned an error for parameters values that differ between the
JAR and the query that is not required but I don't think that is
prohibited.  I need to look at that.

JAR dosen't say your server can't do something else, but that is not JAR.

Clients should be updated to have all the parameters in the JAR.  That
should be the case for most of not all clients now.

For older servers they need to continue to include the required OAuth
parameters outside.

Servers need to migrate and eventually move to returning a warning or error
when a registry parameter is outside the JAR if JAR is used.

Especially if PAR is used (I suspect that will become the prefers pattern)
then merging won't really make sense.

John B.

On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt 
wrote:

>
>
> Am 06.01.2020 um 23:50 schrieb John Bradley :
>
> A client could duplicate those outside the request object for some sort o=
f
> backwards compatability but they will be ignored.
>
> Is this used for backward compatibility with the OIDC servers?
>
> What we have lost is the merge capability.  There are some use cases that
> could use that to have a presigned object that some paramaters like state
> are outside.
>
>
> Is this option used in the wild? As far as I understand the main use case
> is a 3rd party signing the request object that way entitling the client f=
or
> something. I=E2=80=98m asking since in my experience any kind of entitlem=
ent by a
> 3rd party is handled behind the scene using registries.
>

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


I haven't seen any real use of merge.=C2=A0 =C2=A0It =
happens with Connect as a side effect of OAuths current requirement to have=
 some of the parameters outside the JAR.=C2=A0

<=
div dir=3D"auto">Nothing stops servers from ignoring parameters outside JAR=
 or acting on query parameters outside the JAR if they are not in the OAuth=
 registry.=C2=A0 =C2=A0A server can merge but that would not be JAR complia=
nt if they care.=C2=A0

I=
f the AS returned an error for parameters values that differ between the JA=
R and the query that is not required but I don't think that is prohibit=
ed.=C2=A0 I need to look at that.=C2=A0

JAR dosen't say your server can't do something else=
, but that is not JAR.=C2=A0

Clients should be updated to have all the parameters in the JAR.=C2=A0=
 That should be the case for most of not all clients now.=C2=A0 =C2=A0

For older servers they need =
to continue to include the required OAuth parameters outside.=C2=A0

Servers need to migrate and eve=
ntually move to returning a warning or error when a registry parameter is o=
utside the JAR if JAR is used.=C2=A0

Especially if PAR is used (I suspect that will become the pref=
ers pattern) then merging won't really make sense.=C2=A0

John B.=C2=A0

On Tue, Jan 7, 202=
0, 6:19 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Am 06.01.2020 um 23:50 schrieb John Bradley <ve7j=
tb@ve7jtb.com>:

=

A client could duplicate those outside the request obje=
ct for
      some sort of backwards compatability but they will be ignored.
Is this used for backward compatibility with the OIDC =
servers?

    
What we have lost is the merge capability.=C2=A0 There are some use
      cases that could use that to have a presigned object that some
      paramaters like state are outside.=C2=A0=C2=A0 

Is this option used in the wild? As far as I understand the main =
use case is a 3rd party signing the request object that way entitling the c=
lient for something. I=E2=80=98m asking since in my experience any kind of =
entitlement by a 3rd party is handled behind the scene using registries.


--00000000000021bc09059bca3bff--


From nobody Fri Jan 10 06:56: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 2AB4112009E for ; Fri, 10 Jan 2020 06:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoxQOKgvU0ER for ; Fri, 10 Jan 2020 06:56:21 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237A21200B7 for ; Fri, 10 Jan 2020 06:56:21 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AEuDqh017015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 09:56:15 -0500
From: Justin Richer 
Message-Id: <3E119888-EF1E-4462-ABC6-93313811C481@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 09:56:12 -0500
In-Reply-To: <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
Cc: Neil Madden , Brian Campbell , Dave Tonge , oauth , Nat Sakimura 
To: "Richard Backman, Annabelle" 
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re:  PAR 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, 10 Jan 2020 14:56:24 -0000

--Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I just want to add that the requirement to validate the request at PAR =
the same way as you would at the auth endpoint is something that I want =
to see relaxed, and I hope it doesn=E2=80=99t make it through to the =
final standard.=20

Also keep in mind that this is barely started as a WG document so any =
requirement is soft at best. When discussing things like this, we should =
keep this in mind by discussing the consequences of having a phrase in =
there, not behaving as if things are unchangeable.=20

 =E2=80=94 Justin

> On Jan 6, 2020, at 4:59 PM, Richard Backman, Annabelle =
 wrote:
>=20
> The issue isn=E2=80=99t that the PAR endpoint needs access to one =
specific request object decryption key that could reasonably be shared =
across AS endpoints, but that it actually needs access to the private =
keys for all encryption public keys in the JWK set pointed to by the =
AS=E2=80=99s jwks_uri metadata property. Since there is no way to =
designate one particular key as the one to use for encrypting request =
objects, clients may reasonably use any encryption public key in the JWK =
set to encrypt a request object. As one example of how this could expose =
sensitive data to the PAR endpoint, if the PAR endpoint has all the =
decryption keys for the keys in the AS=E2=80=99s JWK set, it would be =
able to decrypt ID Tokens sent in id_token_hint request parameters. As =
more and more use cases develop for encrypting blobs for the AS, this =
issue will only get worse.
> =20
> The PAR endpoint can=E2=80=99t simply stash the encrypted request =
object, as it is required to verify the request, according to =C2=A72.1:
> =20
> The AS MUST process the request as follows:
> =20
> ...
> =20
> 3.  The AS MUST validate the request in the same way as at the
>           authorization endpoint. ...
> =20
> This language needs to be more flexible, IMHO, to allow for =
lightweight PAR endpoints that may not have the information or authority =
needed to perform all the validation that happens at the authorization =
endpoint. I need to think about this more before I can say if it would =
adequately address my concerns, but it=E2=80=99d be a good start and =
makes sense in its own right.
> =20
> I think it=E2=80=99s pretty risky for us to base decision on an =
assumption that no one is going to need or want to encrypt pushed =
request objects, particularly when they=E2=80=99re JWTs, and JWTs have =
well established support for encryption, and encrypted JWTs are =
supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if =
you insist, here are a few examples for why someone might want to do =
this:
> The request object is passed by reference, and accessible on the =
public Internet.
> The request object contains sensitive transaction-related data in RAR =
parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80=99t =
need to have access to.
> The AS requires request object encryption to minimize exposure to the =
hosted PAR endpoint service it uses.
> #2, but the threat vector is gaps in end-to-end TLS.
> Any of the above, but the concern is message integrity, and the AS =
requires requested objects to be encrypted for confidentiality and =
integrity protection and does not support signed request objects.
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: Neil Madden >
> Date: Monday, January 6, 2020 at 6:29 AM
> To: Brian Campbell >
> Cc: "Richard Backman, Annabelle" >, Nat Sakimura >, Dave Tonge >, Torsten Lodderstedt =
>, oauth =
>
> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
> =20
> Agreed.=20
> =20
> In addition, I'm not sure why the PAR endpoint would need access to =
the decryption keys at all. If you're using encrypted request objects =
then the PAR endpoint receives an encrypted JWT and then later makes the =
same (still encrypted) JWT available to the authorization endpoint. If =
the PAR endpoint is doing any kind of decryption or validation on behalf =
of the authorization endpoint then they are clearly not in separate =
trust boundaries.
> =20
> -- Neil
> =20
>=20
>=20
>> On 6 Jan 2020, at 13:57, Brian Campbell =
> wrote:
>> =20
>> I really struggle to see the assumption that an entity be able to use =
the same key to decrypt the same type of message ultimately intended for =
the same purpose as an artificial limit. The same general assumption   =
underlies everything else in OAuth/OIDC (Vladimir's post points to some =
but not all examples of such). There's no reason for PAR to make a =
one-off exception. And should there be some deployment specific reason =
that truly requires that kind of isolation, there are certainly =
implementation options that aren't compatibility-breaking. And having =
said all that, I'm honestly a little surprised anyone is thinking much =
about encrypted request objects with PAR as, at least with my limited =
imagination, there's not really a need for it.
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle =
> wrote:
>>> PAR introduces an added wrinkle for encrypted request objects: the =
PAR endpoint and authorization endpoint may not have access to the same =
cryptographic keys, even though they're both part of the "authorization =
server." Since they're different endpoints with different roles, it's =
reasonable to put them in separate trust boundaries. There is no way to =
support this isolation with just a single "jwks_uri" metadata property.
>>>=20
>>> The two options that I see are:
>>>=20
>>> 1. Define a new par_jwks_uri metadata property.
>>> 2. Explicitly state that this separation is not supported.
>>>=20
>>> I strongly perfer #1 as it has a very minor impact on deployments =
that don't care (i.e., they just set par_jwks_uri and jwks_uri to the =
same value) and failing to support this trust boundary creates an =
artificial limit on implementation architecture and could lead to =
compatibility-breaking workarounds.
>>>=20
>>> =E2=80=93=20
>>> Annabelle Richard Backman
>>> AWS Identity
>>>=20
>>>=20
>>> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" =
 on behalf of =
torsten=3D40lodderstedt.net@dmarc.ietf.org =
> wrote:
>>>=20
>>>     Hi Filip,=20
>>>=20
>>>     > On 31. Dec 2019, at 16:22, Filip Skokan > wrote:
>>>     >=20
>>>     > I don't think we need a *_auth_method_* metadata for every =
endpoint the client calls directly, none of the new specs defined these =
(e.g. device authorization endpoint or CIBA), meaning they also didn't =
follow the scheme from RFC 8414 where introspection and revocation got =
its own metadata. In most cases the unfortunately named =
`token_endpoint_auth_method` and its related metadata is what's used by =
clients for all direct calls anyway.
>>>     >=20
>>>     > The same principle could be applied to signing (and =
encryption) algorithms as well.
>>>     >=20
>>>     > This I do not follow, auth methods and their signing is dealt =
with by using `token_endpoint_auth_methods_supported` and =
`token_endpoint_auth_signing_alg_values_supported` - there's no =
encryption for the `_jwt` client auth methods.=20
>>>     > Unless it was meant to address the Request Object signing and =
encryption metadata, which is defined and IANA registered by OIDC. PAR =
only references JAR section 6.1 and 6.2 for decryption/signature =
validation and these do not mention the metadata (e.g. =
request_object_signing_alg) anymore since draft 07.
>>>=20
>>>     Dammed! You are so right. Sorry, I got confused somehow.=20
>>>=20
>>>     >=20
>>>     > PS: I also found this comment related to the same question =
about auth metadata but for CIBA.
>>>=20
>>>     Thanks for sharing.=20
>>>=20
>>>     >=20
>>>     > Best,
>>>     > Filip
>>>=20
>>>     thanks,
>>>     Torsten.=20
>>>=20
>>>     >=20
>>>     >=20
>>>     > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt =
> wrote:
>>>     > Hi all,
>>>     >=20
>>>     > Ronald just sent me an email asking whether we will define =
metadata for=20
>>>     >=20
>>>     > pushed_authorization_endpoint_auth_methods_supported and
>>>     > =
pushed_authorization_endpoint_auth_signing_alg_values_supported.
>>>     >=20
>>>     > The draft right now utilises the existing token endpoint =
authentication methods so there is basically no need to define another =
parameter. The same principle could be applied to signing (and =
encryption) algorithms as well.=20
>>>     >=20
>>>     > What=E2=80=99s your opinion?
>>>     >=20
>>>     > best regards,
>>>     > Torsten.
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
>> 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=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
just want to add that the requirement to validate the request at PAR the =
same way as you would at the auth endpoint is something that I want to =
see relaxed, and I hope it doesn=E2=80=99t make it through to the final =
standard. 

Also =
keep in mind that this is barely started as a WG document so any =
requirement is soft at best. When discussing things like this, we should =
keep this in mind by discussing the consequences of having a phrase in =
there, not behaving as if things are unchangeable. 

 =E2=80=
=94 Justin

On Jan 6, 2020, at 4:59 PM, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:

The issue =
isn=E2=80=99t that the PAR endpoint needs access to one specific request =
object decryption key that could reasonably be shared across AS =
endpoints, but that it actually needs access to the private keys for all =
encryption public keys in the JWK set pointed to by the AS=E2=80=99s =
jwks_uri metadata property. Since there is no way to designate one =
particular key as the one to use for encrypting request objects, clients =
may reasonably use any encryption public key in the JWK set to encrypt a =
request object. As one example of how this could expose sensitive data =
to the PAR endpoint, if the PAR endpoint has all the decryption keys for =
the keys in the AS=E2=80=99s JWK set, it would be able to decrypt ID =
Tokens sent in id_token_hint request parameters. As more and more use =
cases develop for encrypting blobs for the AS, this issue will only get =
worse.
 
The PAR endpoint can=E2=80=99t simply stash the encrypted =
request object, as it is required to verify the request, according to =
=C2=A72.1:
 
The AS MUST process =
the request as follows:
 
...
 
3.  The AS MUST validate the =
request in the same way as at the
      =
    authorization endpoint. ...
 
This language needs to be more =
flexible, IMHO, to allow for lightweight PAR endpoints that may not have =
the information or authority needed to perform all the validation that =
happens at the authorization endpoint. I need to think about this more =
before I can say if it would adequately address my concerns, but it=E2=80=99=
d be a good start and makes sense in its own right.
 
I think =
it=E2=80=99s pretty risky for us to base decision on an assumption that =
no one is going to need or want to encrypt pushed request objects, =
particularly when they=E2=80=99re JWTs, and JWTs have well established =
support for encryption, and encrypted JWTs are supported by =
pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you insist, =
here are a few examples for why someone might want to do this:
  1. The request object is passed by reference, and =
accessible on the public Internet.
  2. The request object contains =
sensitive transaction-related data in RAR parameters that the client=E2=80=
=99s authN/authZ stack doesn=E2=80=99t need to have access to.
  3. The AS requires request object encryption to minimize =
exposure to the hosted PAR endpoint service it uses.
  4. #2, but the threat vector is gaps in end-to-end TLS.
  5. Any of the above, but the concern is message integrity, and =
the AS requires requested objects to be encrypted for confidentiality =
and integrity protection and does not support signed request =
objects.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Neil Madden <neil.madden@forgerock.com>
Date: Monday, January 6, 2020 =
at 6:29 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: "Richard Backman, =
Annabelle" <richanna@amazon.com>, Nat Sakimura <nat@sakimura.org>, Dave =
Tonge <dave.tonge@moneyhub.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, =
oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: =
[OAUTH-WG] PAR metadata
 
Agreed. 
 
In addition, I'm not sure why the PAR =
endpoint would need access to the decryption keys at all. If you're =
using encrypted request objects then the PAR endpoint receives an =
encrypted JWT and then later makes the same (still encrypted) JWT =
available to the authorization endpoint. If the PAR endpoint is doing =
any kind of decryption or validation on behalf of the authorization =
endpoint then they are clearly not in separate trust boundaries.
 
-- Neil
 


On 6 Jan 2020, at 13:57, Brian Campbell =
<bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:
 
I really =
struggle to see the assumption that an entity be able to use the same =
key to decrypt the same type of message ultimately intended for the same =
purpose as an artificial limit. The same general assumption   =
underlies everything else in OAuth/OIDC (Vladimir's post points to some =
but not all examples of such). There's no reason for PAR to make a =
one-off exception. And should there be some deployment specific reason =
that truly requires that kind of isolation, there are certainly =
implementation options that aren't compatibility-breaking. And having =
said all that, I'm honestly a little surprised anyone is thinking much =
about encrypted request objects with PAR as, at least with my limited =
imagination, there's not really a need for it.
 
 
 
 
 
 
 
 
On Fri, =
Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
PAR =
introduces an added wrinkle for encrypted request objects: the PAR =
endpoint and authorization endpoint may not have access to the same =
cryptographic keys, even though they're both part of the "authorization =
server." Since they're different endpoints with different roles, it's =
reasonable to put them in separate trust boundaries. There is no way to =
support this isolation with just a single "jwks_uri" metadata =
property.

The two options that I see =
are:

1. Define a new par_jwks_uri metadata =
property.
2. Explicitly state that this separation is not =
supported.

I strongly perfer #1 as it has a =
very minor impact on deployments that don't care (i.e., they just set =
par_jwks_uri and jwks_uri to the same value) and failing to support this =
trust boundary creates an artificial limit on implementation =
architecture and could lead to compatibility-breaking workarounds.

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


On 12/31/19, 8:07 AM, "OAuth on behalf of =
Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

    Hi Filip, 

    > On 31. Dec 2019, at 16:22, Filip Skokan =
<panva.ip@gmail.com> wrote:
    =
> 
    > I don't think we need a *_auth_method_* =
metadata for every endpoint the client calls directly, none of the new =
specs defined these (e.g. device authorization endpoint or CIBA), =
meaning they also didn't follow the scheme from RFC 8414 where =
introspection and revocation got its own metadata. In most cases the =
unfortunately named `token_endpoint_auth_method` and its related =
metadata is what's used by clients for all direct calls anyway.
    > 
  =
  > The same principle could be applied to signing (and =
encryption) algorithms as well.
    > 
  =
  > This I do not follow, auth methods and their signing is =
dealt with by using `token_endpoint_auth_methods_supported` and =
`token_endpoint_auth_signing_alg_values_supported` - there's no =
encryption for the `_jwt` client auth methods. 
  =
  > Unless it was meant to address the Request Object signing =
and encryption metadata, which is defined and IANA registered by OIDC. =
PAR only references JAR section 6.1 and 6.2 for decryption/signature =
validation and these do not mention the metadata (e.g. =
request_object_signing_alg) anymore since draft 07.

    Dammed! You are so right. Sorry, I got confused =
somehow. 

    > 
  =
  > PS: I also found this comment related to the same question =
about auth metadata but for CIBA.

  =
  Thanks for sharing. 

    > 
  =
  > Best,
    > Filip
    thanks,
    =
Torsten. 

    > 
  =
  > 
    > On Tue, 31 Dec 2019 at 15:38, Torsten =
Lodderstedt <torsten@lodderstedt.net> wrote:
  =
  > Hi all,
    > 
  =
  > Ronald just sent me an email asking whether we will define =
metadata for 
    > 
  =
  > pushed_authorization_endpoint_auth_methods_supported and
    > =
pushed_authorization_endpoint_auth_signing_alg_values_supported.
    > 
  =
  > The draft right now utilises the existing token endpoint =
authentication methods so there is basically no need to define another =
parameter. The same principle could be applied to signing (and =
encryption) algorithms as well. 
  =
  > 
    > What=E2=80=99s your opinion?
    > 
  =
  > best regards,
    > Torsten.



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

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

=

--Apple-Mail=_5BBA4C70-72A4-4ADE-85F0-E55A4B4F7923--


From nobody Fri Jan 10 07:01: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 4474E1200B7 for ; Fri, 10 Jan 2020 07:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 iveN_D4sTHZn for ; Fri, 10 Jan 2020 07:01:13 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4678B12009E for ; Fri, 10 Jan 2020 07:01:13 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AF1BnJ018671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 10:01:11 -0500
From: Justin Richer 
Message-Id: <4CEE27B7-9B64-4302-A21D-3938CB231239@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD44431C-6866-4791-9373-8484D6471F01"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 10:01:10 -0500
In-Reply-To: 
Cc: Torsten Lodderstedt , IETF oauth WG 
To: John Bradley 
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com> <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 15:01:16 -0000

--Apple-Mail=_AD44431C-6866-4791-9373-8484D6471F01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

But merge gives us the ability, which has been stated here before, to =
have a fixed core set of parameters inside the JAR and a mixed set of =
variable parameters outside the JAR.=20

What if by =E2=80=9Cmerge=E2=80=9D we really mean =E2=80=9Cyou can=E2=80=99=
t repeat things in both places but you can have fields in either=E2=80=9D.=


=E2=80=94 Justin

> On Jan 10, 2020, at 9:49 AM, John Bradley  wrote:
>=20
> I haven't seen any real use of merge.   It happens with Connect as a =
side effect of OAuths current requirement to have some of the parameters =
outside the JAR.=20
>=20
> Nothing stops servers from ignoring parameters outside JAR or acting =
on query parameters outside the JAR if they are not in the OAuth =
registry.   A server can merge but that would not be JAR compliant if =
they care.=20
>=20
> If the AS returned an error for parameters values that differ between =
the JAR and the query that is not required but I don't think that is =
prohibited.  I need to look at that.=20
>=20
> JAR dosen't say your server can't do something else, but that is not =
JAR.=20
>=20
> Clients should be updated to have all the parameters in the JAR.  That =
should be the case for most of not all clients now.  =20
>=20
> For older servers they need to continue to include the required OAuth =
parameters outside.=20
>=20
> Servers need to migrate and eventually move to returning a warning or =
error when a registry parameter is outside the JAR if JAR is used.=20
>=20
> Especially if PAR is used (I suspect that will become the prefers =
pattern) then merging won't really make sense.=20
>=20
> John B.=20
>=20
> On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt =
> wrote:
>=20
>=20
>> Am 06.01.2020 um 23:50 schrieb John Bradley >:
>>=20
>> A client could duplicate those outside the request object for some =
sort of backwards compatability but they will be ignored.
>>=20
> Is this used for backward compatibility with the OIDC servers?
>> What we have lost is the merge capability.  There are some use cases =
that could use that to have a presigned object that some paramaters like =
state are outside. =20
>>=20
>=20
> Is this option used in the wild? As far as I understand the main use =
case is a 3rd party signing the request object that way entitling the =
client for something. I=E2=80=98m asking since in my experience any kind =
of entitlement by a 3rd party is handled behind the scene using =
registries.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_AD44431C-6866-4791-9373-8484D6471F01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

But =
merge gives us the ability, which has been stated here before, to have a =
fixed core set of parameters inside the JAR and a mixed set of variable =
parameters outside the JAR. 

What if by =E2=80=9Cmerge=E2=80=9D we really mean =E2=80=9Cyou=
 can=E2=80=99t repeat things in both places but you can have fields in =
either=E2=80=9D.

=E2=80=94 Justin

On Jan 10, 2020, at 9:49 AM, =
John Bradley <ve7jtb@ve7jtb.com> wrote:

I haven't seen any real use of =
merge.   It happens with Connect as a side effect of OAuths =
current requirement to have some of the parameters outside the =
JAR. 

Nothing stops servers from ignoring parameters =
outside JAR or acting on query parameters outside the JAR if they are =
not in the OAuth registry.   A server can merge but that would =
not be JAR compliant if they care. 

If the AS =
returned an error for parameters values that differ between the JAR and =
the query that is not required but I don't think that is =
prohibited.  I need to look at that. 

JAR dosen't =
say your server can't do something else, but that is not =
JAR. 

Clients should be updated to have all the =
parameters in the JAR.  That should be the case for most of not all =
clients now.   

For older servers they =
need to continue to include the required OAuth parameters =
outside. 

Servers need to migrate and eventually move to =
returning a warning or error when a registry parameter is outside the =
JAR if JAR is used. 

Especially if PAR is used =
(I suspect that will become the prefers pattern) then merging won't =
really make sense. 

John =
B. 

On Tue, Jan 7, 2020, 6:19 AM Torsten =
Lodderstedt <torsten@lodderstedt.net> wrote:


Am 06.01.2020 um 23:50 schrieb John Bradley <ve7jtb@ve7jtb.com>:

A client could duplicate those =
outside the request object for
      some sort of backwards compatability but they will be =
ignored.
Is this used for backward =
compatibility with the OIDC servers?
What we have lost =
is the merge capability.  There are some use
      cases that could use that to have a presigned object that some
      paramaters like state are outside.   =


Is this option =
used in the wild? As far as I understand the main use case is a 3rd =
party signing the request object that way entitling the client for =
something. I=E2=80=98m asking since in my experience any kind of =
entitlement by a 3rd party is handled behind the scene using =
registries.

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

=

--Apple-Mail=_AD44431C-6866-4791-9373-8484D6471F01--


From nobody Fri Jan 10 07:51: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 13CCE120132 for ; Fri, 10 Jan 2020 07:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (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 aPT2164fjgNO for ; Fri, 10 Jan 2020 07:51:09 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBF1120900 for ; Fri, 10 Jan 2020 07:50:53 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id w15so2286695wru.4 for ; Fri, 10 Jan 2020 07:50:53 -0800 (PST)
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=CFNnyfzrJDgO6oYhw6+B9Mi1+8FPJ5+KJMjjGo4dA+A=; b=Jx9bUs1t3KSRAOqNu34hYKlmkJZOTwkc08Um+LSDL79j0BUaA5B3ix9lDH8me+gmqx sQM8dYa+DvyFGWF/2/5+uLWJxpuicKNXu0rlkMjAeGCKVhKTdu4a/siLKyEjSYFKX7cX XebxBrgBwQ0Gya9Vq83S2ZFWH8qLwhm9sXS+c=
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=CFNnyfzrJDgO6oYhw6+B9Mi1+8FPJ5+KJMjjGo4dA+A=; b=EIiSOfwsPTnR1ANtHIPGEsGZmXSlAJTCago0Q1/0LPkf97uwoIiUPdp9K1S8SJ+KDA Y4AofD5HTHhJ9f+TgE5Zslb4ilaAQbykZiAtfeVllPfy59vQnQdfo/AZI6aGe903iz9c hWhgXL03pBTF+Gm6qQ5mTPvmaSxY5PJ1FiaJYIpzvrCzQem5w1VWtfV7L1RfeEYjynts c+SFDJ12UGg8sXF+klKuGFAJtel++XtcZogkLZTEhVZ0f9Qg+taPUSfaD67dFI0us9Ey WfEl6BlYih8hSBA2h9jLK3//U22GVsROc2Gfp48fvJXYXnp9UG9g8kgck3Y1JlPLcWnx HZxA==
X-Gm-Message-State: APjAAAUokL7CAnrZXnSLABCzEfHMH2WCrWGc+kxONrLKeCgui9S8bh9d qL1lqVBHMu2cONxi5N7tsaIq/UvxC8k67g==
X-Google-Smtp-Source: APXvYqyKI7P/f4z2q2QPBQTwzpPWMggQ0UPxtdfQzilBEaSxsXE//+izAelWLXiBH+2uDJ5ifIojKw==
X-Received: by 2002:a05:6000:12ce:: with SMTP id l14mr4502888wrx.342.1578671451563;  Fri, 10 Jan 2020 07:50:51 -0800 (PST)
Received: from [192.168.1.64] (74.61.147.147.dyn.plus.net. [147.147.61.74]) by smtp.gmail.com with ESMTPSA id a5sm2633243wmb.37.2020.01.10.07.50.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 07:50:50 -0800 (PST)
From: Neil Madden 
Message-Id: <84329089-E065-421D-AD93-439C6D7E3F44@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 10 Jan 2020 15:50:48 +0000
In-Reply-To: 
Cc: Mike Jones , oauth 
To: "Richard Backman, Annabelle" 
References: 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 15:51:14 -0000

--Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This is an interesting point.

I think OAuth has historically assumed that the AS is a monolithic =
system, or at least can be treated like one by clients. I think we might =
have to revisit quite a lot if we drop this assumption and adopt a =
threat model in which the AS is itself composed of a collection of =
mutually distrusting entities. Especially as different ASes might decide =
to divide up the trust boundaries in different ways.

At least partially this feels like an internal implementation detail of =
the AS that can also be solved internally to that AS. For example, =
rather than providing microservices direct access to private keys you =
could implement a JWT-decryption-microservice that other microservices =
call. It can then check if the calling microservice is allowed to =
decrypt that type of JWT before returning the response (e.g., by =
checking the "typ" header). The same can be done for signing JWTs. Of =
course, that's not a perfect solution, but it illustrates that we don't =
necessarily need to solve these problems in the WG.

If we go down the path of separate keys, then it might be simpler to =
introduce new metadata elements to list the kids of valid key ids for a =
given purpose rather than having multiple JWK Set endpoints. e.g. =
"id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids =
the client having to fetch multiple sets of keys.

-- Neil

> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle =
 wrote:
>=20
> The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepresentation of a =
legitimately issued JWT, but it doesn=E2=80=99t address the issue I am =
trying to draw attention to, which is that the current model forces =
broader distribution and reuse of keys than is necessary, resulting in a =
greater blast radius for compromised keys or systems.
> =20
> For many cases, this is not a significant concern, as the AS is a =
monolithic system with no internal trust boundaries. However, in cases =
where the AS is composed of multiple microservices performing different =
tasks, the need to share keys between different microservices undermines =
efforts to create trust boundaries between them. I gave one example of =
this in my original email, where ID Token generation and access token =
generation are relegated to independent systems, each with separate =
private keys for signing tokens. Suppose a malicious party compromised =
the ID Token generator, or gained access to its private key, and issued =
fraudulent access tokens signed using that key. Since verifiers of both =
token types will look to the same metadata file and thus the same JWK =
set, they have no way to recognize that these access tokens are =
fraudulent.
> =20
> Note that while =E2=80=9Ctyp=E2=80=9D would help a verifier =
distinguish between an ID Token and an access token, it does not help in =
this case because the malicious party is generating well-formed access =
token JWTs, signed with a key that is legitimate for the AS but not for =
this purpose.
> =20
> The case for this being a concern on the encryption side is fuzzier, =
primarily because we simply don=E2=80=99t have many use cases where =
different kinds of content gets encrypted and sent to the AS in =
different contexts. However, I gave one example on the PAR thread =
,=
 where a PAR endpoint that decrypts request object JWTs will also be =
able to decrypt id_token_hint JWTs.
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: Mike Jones >
> Date: Thursday, January 9, 2020 at 11:34 AM
> To: "Richard Backman, Annabelle" >, oauth >
> Subject: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits =
of jwks_uri
> =20
> This a good thing to think about.  Thanks for bringing this up, =
Annabelle.
> =20
> One thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D=
 and/or =E2=80=9Ckey_ops=E2=80=9D attributes can be provided.  This can =
allow signing keys to be differentiated from encryption keys, for =
instance.
> =20
> I=E2=80=99m not as worried about encryption keys as signing keys.  If =
multiple kinds of applications encrypt content to a party using the same =
public per-party key, and the encryption is being used only to ensure =
confidentiality of the messages, the confidentiality is still achieved.
> =20
> One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D =
field, as described in the JWT BCP.  Even if the same key was used and =
you receive an unexpected JWT type, you will still reject it.
> =20
> I believe there=E2=80=99s also cases where it=E2=80=99s fine to use =
the same signing key for related operations.  For instance, signing a =
Pushed Authorization Request and a Request Object with the same key =
seems both logical and safe to me.  (If others can think of an attack =
that this enables, however, please do point it out.)
> =20
> Which I believe leaves us with this case to worry about =E2=80=93 =
shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D =
is not used.  One way to mitigate this would be to use per-application =
key sets.  For instance, using values other than =E2=80=9Cjwks_uri=E2=80=9D=
 to reference key sets for particular applications.
> =20
> Anyway, for PAR, I believe that it=E2=80=99s fine to use the same keys =
as used for Request Objects, so no new fields are needed for it.
> =20
> I look forward to further discussion on the topic.
> =20
>                                                        -- Mike
> =20
> From: OAuth > =
On Behalf Of Richard Backman, Annabelle
> Sent: Wednesday, January 8, 2020 3:47 PM
> To: oauth >
> Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
> =20
> I originally brought up this issue in the context of the PAR draft, =
but since it broadly applies to the OAuth space I=E2=80=99m starting a =
new thread=E2=80=A6
> =20
> Section 3.12 of the JWT BCP =
 says: =E2=80=9C=
Use different keys for different kinds of JWTs.=E2=80=9D Section 4 of =
the JWT Profile for OAuth 2.0 Access Tokens =
says: =E2=80=9C=
An authorization server MAY elect to use different keys to sign =
id_tokens and JWT access tokens.=E2=80=9D These statements are =
consistent with good cryptographic hygiene. And we=E2=80=99ve made it =
difficult to impossible for an AS to follow them.
> =20
> The AS has a single metadata document containing a single URI =
referencing a single JWK Set. But the AS has no way of indicating to =
clients which keys to use for which purposes. For example, an AS cannot =
say that *only these* keys are to be used to encrypt id_token_hint JWTs, =
and *only these* keys are to be used to encrypt JAR request object JWTs. =
For encryption, the AS could enforce that logic internally, but there is =
no way for the client to discover this. And while the AS may be built to =
only use certain keys for signing ID Tokens and other keys for signing =
JWT access tokens, it has no way to indicate this to the client. So even =
if ID Token generation and access token generation are isolated in =
different microservices within the AS, each microservice is capable of =
forging the other=E2=80=99s tokens, because consumers can=E2=80=99t be =
told to distinguish between different keys for the AS.
> =20
> This seems like a ticking time bomb to me, as it=E2=80=99s a =
non-obvious side effect of combining various OAuth 2.0 extensions, and =
it can undermine a lot of sophisticated effort to follow security best =
practices. I can see a couple of ways to address this (e.g., more =
sophisticated AS key metadata, tagging or similar use case indication on =
JWKs), but before trying to propose something I=E2=80=99d like to get =
people=E2=80=99s opinions on the problem. Is this already mitigated in =
other ways? Has the ship sailed on this for OAuth, and now we have to =
live with it? Should this be left to the deployments that care to solve =
with non-interoperable solutions? Are there other clever ways we could =
approach this? Are there other angles that we need to consider?
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


This is an interesting point.

I think OAuth has historically assumed =
that the AS is a monolithic system, or at least can be treated like one =
by clients. I think we might have to revisit quite a lot if we drop this =
assumption and adopt a threat model in which the AS is itself composed =
of a collection of mutually distrusting entities. Especially as =
different ASes might decide to divide up the trust boundaries in =
different ways.

At least partially this feels like an internal implementation =
detail of the AS that can also be solved internally to that AS. For =
example, rather than providing microservices direct access to private =
keys you could implement a JWT-decryption-microservice that other =
microservices call. It can then check if the calling microservice is =
allowed to decrypt that type of JWT before returning the response (e.g., =
by checking the "typ" header). The same can be done for signing JWTs. Of =
course, that's not a perfect solution, but it illustrates that we don't =
necessarily need to solve these problems in the WG.

If we go down the path =
of separate keys, then it might be simpler to introduce new metadata =
elements to list the kids of valid key ids for a given purpose rather =
than having multiple JWK Set endpoints. e.g. =
"id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids =
the client having to fetch multiple sets of keys.
-- Neil

On 10 Jan 2020, at 00:25, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:

The =E2=80=9Ctyp=E2=80=9D field =
helps prevent misrepresentation of a legitimately issued JWT, but it =
doesn=E2=80=99t address the issue I am trying to draw attention to, =
which is that the current model forces broader distribution and reuse of =
keys than is necessary, resulting in a greater blast radius for =
compromised keys or systems.
 
For many cases, =
this is not a significant concern, as the AS is a monolithic system with =
no internal trust boundaries. However, in cases where the AS is composed =
of multiple microservices performing different tasks, the need to share =
keys between different microservices undermines efforts to create trust =
boundaries between them. I gave one example of this in my original =
email, where ID Token generation and access token generation are =
relegated to independent systems, each with separate private keys for =
signing tokens. Suppose a malicious party compromised the ID Token =
generator, or gained access to its private key, and issued fraudulent =
access tokens signed using that key. Since verifiers of both token types =
will look to the same metadata file and thus the same JWK set, they have =
no way to recognize that these access tokens are fraudulent.
 
Note that while =
=E2=80=9Ctyp=E2=80=9D would help a verifier distinguish between an ID =
Token and an access token, it does not help in this case because the =
malicious party is generating well-formed access token JWTs, signed with =
a key that is legitimate for the AS but not for this purpose.
 
The case for this =
being a concern on the encryption side is fuzzier, primarily because we =
simply don=E2=80=99t have many use cases where different kinds of =
content gets encrypted and sent to the AS in different contexts. =
However, I =
gave one example on the PAR thread, where a PAR endpoint that =
decrypts request object JWTs will also be able to decrypt id_token_hint =
JWTs.
 
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
 
From: Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Thursday, January 9, =
2020 at 11:34 AM
To: "Richard Backman, =
Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] RE: =
Cryptographic hygiene and the limits of jwks_uri
 
This a good thing to think about.  Thanks for bringing =
this up, Annabelle.
 
One thing that partially mitigates this is =
that the =E2=80=9Cuse=E2=80=9D and/or =E2=80=9Ckey_ops=E2=80=9D =
attributes can be provided.  This can allow signing keys to be =
differentiated from encryption keys, for instance.
 
I=E2=80=99m not as worried about encryption keys as signing =
keys.  If multiple kinds of applications encrypt content to a party =
using the same public per-party key, and the encryption is being used =
only to ensure confidentiality of the messages, the confidentiality is =
still achieved.
 
One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=
=9D field, as described in the JWT BCP.  Even if the same key was =
used and you receive an unexpected JWT type, you will still reject =
it.
 
I believe there=E2=80=99s also cases where it=E2=80=99s fine =
to use the same signing key for related operations.  For instance, =
signing a Pushed Authorization Request and a Request Object with the =
same key seems both logical and safe to me.  (If others can think =
of an attack that this enables, however, please do point it =
out.)
 
Which I believe leaves us with this case to worry about =E2=80=93=
 shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D =
is not used.  One way to mitigate this would be to use =
per-application key sets.  For instance, using values other than =
=E2=80=9Cjwks_uri=E2=80=9D to reference key sets for particular =
applications.
 
Anyway, for PAR, I believe that it=E2=80=99s fine to use the =
same keys as used for Request Objects, so no new fields are needed for =
it.
 
I look forward to further discussion on the topic.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of Richard =
Backman, Annabelle
Sent: Wednesday, January 8, 2020 =
3:47 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Cryptographic =
hygiene and the limits of jwks_uri
 
I originally =
brought up this issue in the context of the PAR draft, but since it =
broadly applies to the OAuth space I=E2=80=99m starting a new =
thread=E2=80=A6
 
Section=
 3.12 of the JWT BCP says: =E2=80=9CUse =
different keys for different kinds of JWTs.=E2=80=9D Section 4 of the JWT Profile for OAuth 2.0 Access =
Tokenssays: =E2=80=9CAn authorization server MAY elect to use =
different keys to sign id_tokens and JWT access tokens.=E2=80=9D These =
statements are consistent with good cryptographic hygiene. And we=E2=80=99=
ve made it difficult to impossible for an AS to follow them.
 
The AS has a single metadata =
document containing a single URI referencing a single JWK Set. But the =
AS has no way of indicating to clients which keys to use for which =
purposes. For example, an AS cannot say that *only these* =
keys are to be used to encrypt id_token_hint JWTs, and *only=
 these* keys are to be used to encrypt JAR request object JWTs. For =
encryption, the AS could enforce that logic internally, but there is no =
way for the client to discover this. And while the AS may be built to =
only use certain keys for signing ID Tokens and other keys for signing =
JWT access tokens, it has no way to indicate this to the client. So even =
if ID Token generation and access token generation are isolated in =
different microservices within the AS, each microservice is capable of =
forging the other=E2=80=99s tokens, because consumers can=E2=80=99t be =
told to distinguish between different keys for the AS.
 
This seems like a ticking time =
bomb to me, as it=E2=80=99s a non-obvious side effect of combining =
various OAuth 2.0 extensions, and it can undermine a lot of =
sophisticated effort to follow security best practices. I can see a =
couple of ways to address this (e.g., more sophisticated AS key =
metadata, tagging or similar use case indication on JWKs), but before =
trying to propose something I=E2=80=99d like to get people=E2=80=99s =
opinions on the problem. Is this already mitigated in other ways? Has =
the ship sailed on this for OAuth, and now we have to live with it? =
Should this be left to the deployments that care to solve with =
non-interoperable solutions? Are there other clever ways we could =
approach this? Are there other angles that we need to =
consider?
 
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01--


From nobody Fri Jan 10 07:53: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 1DBBD12092A for ; Fri, 10 Jan 2020 07:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VIwgwwLwurD for ; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EEB1208EF for ; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id g17so2298412wro.2 for ; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LGx5Na09JK8/oYd4Ig7tWgHn+S8yC3zVvLTqx3DPVAI=; b=PUAvQsfkGau1nsY8IloVGyFl/sdNKYcWUltr5p6+Ipwi+I7eCQP0f1XCH9lGvVqMKb kUONfKgyP584T1nmuS9cG4DlDbxJtmTOyxXGYYKS304SJtF6yzsXtr5v02T6pAhu/GDR p8Tawx80wzVaWrPp4xc6cNWCmR+lFDZWpyhIK/OfcvrArbZYsPNB7iPFgRHqhXRDeIOB ZT3Ojv2k6eetbUm4/xTzr3obSytLupmEs98xsdrGJUX9OtEJQmgeFxTXQFNpkPhbSmNQ BtBstkxiktEWC07KaD3DRxsWm2eU/OIPiQ2LxX1jwkYduzJ1cVtPMIfY4FXLLhDVBZQT 4i8Q==
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=LGx5Na09JK8/oYd4Ig7tWgHn+S8yC3zVvLTqx3DPVAI=; b=fmOyRls4fYGe21ZGFU2/4YWwvkIePITWsnXIV9D7JEE/S+iloYc7SF8dW7J0lkvLpK QaWzIyecLItO8UdrORybSJbTE9NwB0/dcNGRPOg5mjUVbWzv2SjtTaD0uQAZsFsO1M4H EdFLynSZmPzq9BLaN4TCVLy+FxxH0E4+zS4DbiI0RHC5ljJvf5yoMFPM0nBhlp3oTT8+ i7n3kd2BJQQWHm01erCNx+7CIZI9jCaFI1NTkoyJdML0/prG4QkEfno3eSMJ5D2i9Dkq coOoOj3rY0fDDpl2wFDDPjM2JzS86uIlLQaYYJSZH9qwqdootbN7UEO7koj5zVpHDTKp aI9w==
X-Gm-Message-State: APjAAAUm3fuPzRekcKcbyOenkkwEp7KFtWYZfE2wmD6XCdHXadruveMQ AG8Yops/Zyh+2xtRXFR61P8romPqpE+xMTfJtXRgYw==
X-Google-Smtp-Source: APXvYqwExe3H3lRVKTwGPBx28F9iZ3H9PiZkx9bgPk8op9JjYz+z1XDWFKWxykcPBEGOlwfAoaoCh1wmKpyk8jC9FM8=
X-Received: by 2002:a5d:480b:: with SMTP id l11mr4331425wrq.129.1578671621648;  Fri, 10 Jan 2020 07:53:41 -0800 (PST)
MIME-Version: 1.0
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com> <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>  <4CEE27B7-9B64-4302-A21D-3938CB231239@mit.edu>
In-Reply-To: <4CEE27B7-9B64-4302-A21D-3938CB231239@mit.edu>
From: John Bradley 
Date: Fri, 10 Jan 2020 12:53:31 -0300
Message-ID: 
To: Justin Richer 
Cc: Torsten Lodderstedt , IETF oauth WG 
Content-Type: multipart/alternative; boundary="00000000000039d2ce059bcb21b9"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 15:53:54 -0000

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

Yes that is what it comes down to.

Is that a feature having a fixed set of parameters in the signed JAR and
some number of OAuth parameters unsigned outside the JAR, that people want
badly enough for us to pull the spec back and restart IESG review.

I think Torsten is speculating that is not a feature people use.

It was a feature that people on the IESG objected to.

If we can get concensus in the WG to pull it back, we can do it.

That is the decision we should make.

John B.

On Fri, Jan 10, 2020, 12:01 PM Justin Richer  wrote:

> But merge gives us the ability, which has been stated here before, to hav=
e
> a fixed core set of parameters inside the JAR and a mixed set of variable
> parameters outside the JAR.
>
> What if by =E2=80=9Cmerge=E2=80=9D we really mean =E2=80=9Cyou can=E2=80=
=99t repeat things in both places
> but you can have fields in either=E2=80=9D.
>
> =E2=80=94 Justin
>
> On Jan 10, 2020, at 9:49 AM, John Bradley  wrote:
>
> I haven't seen any real use of merge.   It happens with Connect as a side
> effect of OAuths current requirement to have some of the parameters outsi=
de
> the JAR.
>
> Nothing stops servers from ignoring parameters outside JAR or acting on
> query parameters outside the JAR if they are not in the OAuth registry.  =
 A
> server can merge but that would not be JAR compliant if they care.
>
> If the AS returned an error for parameters values that differ between the
> JAR and the query that is not required but I don't think that is
> prohibited.  I need to look at that.
>
> JAR dosen't say your server can't do something else, but that is not JAR.
>
> Clients should be updated to have all the parameters in the JAR.  That
> should be the case for most of not all clients now.
>
> For older servers they need to continue to include the required OAuth
> parameters outside.
>
> Servers need to migrate and eventually move to returning a warning or
> error when a registry parameter is outside the JAR if JAR is used.
>
> Especially if PAR is used (I suspect that will become the prefers pattern=
)
> then merging won't really make sense.
>
> John B.
>
> On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt 
> wrote:
>
>>
>>
>> Am 06.01.2020 um 23:50 schrieb John Bradley :
>>
>> A client could duplicate those outside the request object for some sort
>> of backwards compatability but they will be ignored.
>>
>> Is this used for backward compatibility with the OIDC servers?
>>
>> What we have lost is the merge capability.  There are some use cases tha=
t
>> could use that to have a presigned object that some paramaters like stat=
e
>> are outside.
>>
>>
>> Is this option used in the wild? As far as I understand the main use cas=
e
>> is a 3rd party signing the request object that way entitling the client =
for
>> something. I=E2=80=98m asking since in my experience any kind of entitle=
ment by a
>> 3rd party is handled behind the scene using registries.
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

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


Yes that is what it comes down to.=C2=A0

Is that a feature having a fixed set of parame=
ters in the signed JAR and some number of OAuth parameters unsigned outside=
 the JAR, that people want badly enough for us to pull the spec back and re=
start IESG review.=C2=A0

I think Torsten is speculating that is not a feature people use.=C2=A0 =C2=
=A0

It was a feature tha=
t people on the IESG objected to.=C2=A0 =C2=A0

<=
/div>
If we can get concensus in the WG to pull it back, w=
e can do it.=C2=A0=C2=A0

That is the decision we should make.=C2=A0

John B.=C2=A0=C2=A0

On Fri, Jan 10, 2020, 12:01 PM=
 Justin Richer <jricher@mit.edu&g=
t; wrote:
But merge gives us the ability, whi=
ch has been stated here before, to have a fixed core set of parameters insi=
de the JAR and a mixed set of variable parameters outside the JAR.=C2=A0
What if by =E2=80=9Cmerge=E2=80=9D we really mean =E2=80=
=9Cyou can=E2=80=99t repeat things in both places but you can have fields i=
n either=E2=80=9D.

=E2=80=94 Justin

On Jan 10, 2020, at 9:49 AM, John Bradley <=
v=
e7jtb@ve7jtb.com> wrote:

I haven'=
;t seen any real use of merge.=C2=A0 =C2=A0It happens with Connect as a sid=
e effect of OAuths current requirement to have some of the parameters outsi=
de the JAR.=C2=A0

Nothing stop=
s servers from ignoring parameters outside JAR or acting on query parameter=
s outside the JAR if they are not in the OAuth registry.=C2=A0 =C2=A0A serv=
er can merge but that would not be JAR compliant if they care.=C2=A0
<=
div dir=3D"auto">
If the AS returned an error fo=
r parameters values that differ between the JAR and the query that is not r=
equired but I don't think that is prohibited.=C2=A0 I need to look at t=
hat.=C2=A0

JAR dosen'=
;t say your server can't do something else, but that is not JAR.=C2=A0<=
/div>

Clients should be update=
d to have all the parameters in the JAR.=C2=A0 That should be the case for =
most of not all clients now.=C2=A0 =C2=A0

=

For older servers they need to continue to include the re=
quired OAuth parameters outside.=C2=A0

Servers need to migrate and eventually move to returning a w=
arning or error when a registry parameter is outside the JAR if JAR is used=
.=C2=A0

Especially if PA=
R is used (I suspect that will become the prefers pattern) then merging won=
't really make sense.=C2=A0

John B.=C2=A0

On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderst=
edt <torsten@lodderstedt.net> wrote:


Am 06.01.2020 um 23:50 schrieb John Bradl=
ey <ve7jtb@ve7jtb.com>:

A client could duplicate those out=
side the request object for
      some sort of backwards compatability but they will be ignored.
Is this used for backward compatibility with the OIDC =
servers?
What we have lo=
st is the merge capability.=C2=A0 There are some use
      cases that could use that to have a presigned object that some
      paramaters like state are outside.=C2=A0=C2=A0 

Is this option used in the wild? As far as I understand the main =
use case is a 3rd party signing the request object that way entitling the c=
lient for something. I=E2=80=98m asking since in my experience any kind of =
entitlement by a 3rd party is handled behind the scene using registries.

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



--00000000000039d2ce059bcb21b9--


From nobody Fri Jan 10 08:43: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 94D7D12025D for ; Fri, 10 Jan 2020 08:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAzJ_wQpAbuw for ; Fri, 10 Jan 2020 08:42:54 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB2812099C for ; Fri, 10 Jan 2020 08:42:52 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AGgnTA023572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 11:42:49 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer 
In-Reply-To: 
Date: Fri, 10 Jan 2020 11:42:48 -0500
Cc: Torsten Lodderstedt , Dave Tonge , oauth , Nat Sakimura 
Content-Transfer-Encoding: quoted-printable
Message-Id: <07A0FC76-3BEC-4103-81CD-520243AC8CC3@mit.edu>
References:   <50191CC6-0A19-42B4-87C2-880F53FD3C4F@lodderstedt.net> <05AB19DB-FCD2-4FAA-A470-0978E7B65354@amazon.com>  <801AFC59-B94A-4C9E-A44D-60F4EF6F4EC2@forgerock.com> <38C69B8C-905F-46F1-88BB-016CF7DE2952@amazon.com>  <3c24a635-3d48-7b86-de31-fbf8595cf15f@connect2id.com>  <234E2C28-4CF5-4626-83D5-719B176C418B@amazon.com> <70997D70-0DFF-4C39-B712-F916BFB04EDF@lodderstedt.net> 
To: "Richard Backman, Annabelle" 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR 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, 10 Jan 2020 16:42:57 -0000

+1 to this being a security consideration

 =E2=80=94 Justin

> On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle =
 wrote:
>=20
> I almost included text to that effect, but thought it was getting too =
wordy. However your suggestion is simple and concise. +1
>=20
> Given all of this discussion, we should include a section on request =
validation in Security Considerations, to provide some context on what =
might be validated when and where, what kinds of problems deployments =
need to consider, etc. I think this is useful to have in the document, =
but would be too much clutter in the main body. We should keep that =
focused on the precise normative requirements.
>=20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
>=20
>=20
> =EF=BB=BFOn 1/8/20, 2:11 AM, "Torsten Lodderstedt" =
 wrote:
>=20
>    Hi Annabelle,=20
>=20
>    thanks for your proposal, which reads reasonable to me.=20
>=20
>    I suggest to extend =E2=80=9Cand that the request has not been =
modified in a way that would affect the outcome of the omitted steps.=E2=80=
=9D a bit to also consider policy changes that may have occurred between =
push and authorization request processing.=20
>=20
>    "and that the request or the authorization server=E2=80=99s policy =
has not been modified in a way that would affect the outcome of the =
omitted steps."
>=20
>    best regards,
>    Torsten.=20
>=20
>> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle =
 wrote:
>>=20
>> I think it=E2=80=99s clearer if we split out the requirements for the =
PAR endpoint and the requirements for the authorization endpoint, given =
that they are each covered in different sections of the doc (2 and 4, =
respectively). With that in mind, here are a couple suggestions:
>>=20
>> For the text in Section 2.1:
>>=20
>> 3.  The AS MUST validate the pushed request as it would an =
authorization
>>=20
>>    request sent to the authorization endpoint, however the AS MAY =
omit
>>=20
>>    validation steps that it is unable to perform when processing the
>>=20
>>    pushed request.
>>=20
>>=20
>>=20
>> Additional text for Section 4 (note that this section pertains to the =
authorization endpoint):
>>=20
>> The AS MUST validate authorization requests arising from a pushed =
request as
>>=20
>> it would any other authorization request.  The AS MAY omit validation =
steps
>>=20
>> that it performed when the request was pushed, provided that it can =
validate
>>=20
>> that the request was a pushed request, and that the request has not =
been
>>=20
>> modified in a way that would affect the outcome of the omitted steps.
>>=20
>>=20
>>=20
>> This is longer than the current text and the other proposals, but it =
adds a few important points:
>> 	=E2=80=A2 Turns the 2.1 SHOULD back into a MUST, with an =
explicit exception for validation that can=E2=80=99t be done yet.
>> 	=E2=80=A2 Reinforces the fact that the authorization endpoint =
still needs to do validation.
>> 	=E2=80=A2 Clearly states requirements for when an AS can trust =
that validation happened at the PAR endpoint.
>>=20
>> =E2=80=93=20
>> Annabelle Richard Backman
>> AWS Identity
>>=20
>>=20
>> From: Brian Campbell 
>> Date: Tuesday, January 7, 2020 at 2:54 PM
>> To: Vladimir Dzhuvinov 
>> Cc: Filip Skokan , "Richard Backman, Annabelle" =
, Dave Tonge , oauth =
, Nat Sakimura 
>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: =
PAR metadata
>>=20
>> A little more context about that proposed wording is in a github =
issue at
>>>=20
>>>>> 	=E2=80=A2
>>>>> 	=E2=80=A2
>>>>> 	=E2=80=A2
>>>>> 	=E2=80=A2
>>>>> 	=E2=80=A2
>    https://github.com/oauthstuff/draft-oauth-par/issues/38, which is =
different driver than allowing a PAR endpoint to stash the encrypted =
request object rather than decrypting/validating it. But it's kind of =
the same concept at some level too - that there are some things that =
can't or won't be validated at the PAR endpoint and those then have to =
be validated at the authorization endpoint..
>=20
>    I rather like your suggested text, Vladimir, and have mentioned it =
in a comment on the aforementioned issue.
>=20
>=20
>    On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov =
 wrote:
>    On 07/01/2020 00:22, Filip Skokan wrote:
>    We've been discussing making the following change to the language
>=20
>    The AS SHOULD validate the request in the same way as at the =
authorization endpoint. The AS MUST ensure that all parameters to the =
authorization request are still valid at the time when the request URI =
is used.
>    Could you expand a bit on the second sentence?
>    Alternative suggestion:
>    The AS MUST validate the request in the same way as at the =
authorization endpoint, or complete the request validation at the =
authorization endpoint.
>    Vladimir
>=20
>    This would allow the PAR endpoint to simply stash the encrypted =
request object instead of decrypting and validating it. All within the =
bounds of "SHOULD - We=E2=80=99d like you to do this, but we can=E2=80=99t=
 always require it". This supports "light weight PAR" implementation =
rather than introducing the unnecessary complexity in the form of a =
second JWKS.
>=20
>    Best,
>    Filip
>=20
>=20
>    On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle =
 wrote:
>    The issue isn=E2=80=99t that the PAR endpoint needs access to one =
specific request object decryption key that could reasonably be shared =
across AS endpoints, but that it actually needs access to the private =
keys for all encryption public keys in the JWK set pointed to by the =
AS=E2=80=99s jwks_uri metadata property. Since there is no way to =
designate one particular key as the one to use for encrypting request =
objects, clients may reasonably use any encryption public key in the JWK =
set to encrypt a request object. As one example of how this could expose =
sensitive data to the PAR endpoint, if the PAR endpoint has all the =
decryption keys for the keys in the AS=E2=80=99s JWK set, it would be =
able to decrypt ID Tokens sent in id_token_hint request parameters. As =
more and more use cases develop for encrypting blobs for the AS, this =
issue will only get worse.
>=20
>=20
>=20
>    The PAR endpoint can=E2=80=99t simply stash the encrypted request =
object, as it is required to verify the request, according to =C2=A72.1:
>=20
>=20
>=20
>    The AS MUST process the request as follows:
>=20
>    .....
>=20
>    3.  The AS MUST validate the request in the same way as at the
>              authorization endpoint. ...
>=20
>    This language needs to be more flexible, IMHO, to allow for =
lightweight PAR endpoints that may not have the information or authority =
needed to perform all the validation that happens at the authorization =
endpoint. I need to think about this more before I can say if it would =
adequately address my concerns, but it=E2=80=99d be a good start and =
makes sense in its own right.
>=20
>=20
>=20
>    I think it=E2=80=99s pretty risky for us to base decision on an =
assumption that no one is going to need or want to encrypt pushed =
request objects, particularly when they=E2=80=99re JWTs, and JWTs have =
well established support for encryption, and encrypted JWTs are =
supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if =
you insist, here are a few examples for why someone might want to do =
this:
>=20
>    The request object is passed by reference, and accessible on the =
public Internet.
>    The request object contains sensitive transaction-related data in =
RAR parameters that the client=E2=80=99s authN/authZ stack doesn=E2=80=99t=
 need to have access to.
>    The AS requires request object encryption to minimize exposure to =
the hosted PAR endpoint service it uses.
>    #2, but the threat vector is gaps in end-to-end TLS.
>    Any of the above, but the concern is message integrity, and the AS =
requires requested objects to be encrypted for confidentiality and =
integrity protection and does not support signed request objects.
>=20
>=20
>    =E2=80=93=20
>=20
>    Annabelle Richard Backman
>=20
>    AWS Identity
>=20
>=20
>=20
>=20
>=20
>    From: Neil Madden 
>    Date: Monday, January 6, 2020 at 6:29 AM
>    To: Brian Campbell 
>    Cc: "Richard Backman, Annabelle" , Nat =
Sakimura , Dave Tonge , =
Torsten Lodderstedt , oauth 
>    Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>=20
>=20
>=20
>    Agreed.
>=20
>=20
>=20
>    In addition, I'm not sure why the PAR endpoint would need access to =
the decryption keys at all. If you're using encrypted request objects =
then the PAR endpoint receives an encrypted JWT and then later makes the =
same (still encrypted) JWT available to the authorization endpoint. If =
the PAR endpoint is doing any kind of decryption or validation on behalf =
of the authorization endpoint then they are clearly not in separate =
trust boundaries.
>=20
>=20
>=20
>    -- Neil
>=20
>=20
>=20
>=20
>=20
>    On 6 Jan 2020, at 13:57, Brian Campbell =
 wrote:
>=20
>=20
>=20
>    I really struggle to see the assumption that an entity be able to =
use the same key to decrypt the same type of message ultimately intended =
for the same purpose as an artificial limit. The same general assumption =
  underlies everything else in OAuth/OIDC (Vladimir's post points to =
some but not all examples of such). There's no reason for PAR to make a =
one-off exception. And should there be some deployment specific reason =
that truly requires that kind of isolation, there are certainly =
implementation options that aren't compatibility-breaking. And having =
said all that, I'm honestly a little surprised anyone is thinking much =
about encrypted request objects with PAR as, at least with my limited =
imagination, there's not really a need for it.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>    On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle =
 wrote:
>=20
>    PAR introduces an added wrinkle for encrypted request objects: the =
PAR endpoint and authorization endpoint may not have access to the same =
cryptographic keys, even though they're both part of the "authorization =
server." Since they're different endpoints with different roles, it's =
reasonable to put them in separate trust boundaries. There is no way to =
support this isolation with just a single "jwks_uri" metadata property.
>=20
>    The two options that I see are:
>=20
>    1. Define a new par_jwks_uri metadata property.
>    2. Explicitly state that this separation is not supported.
>=20
>    I strongly perfer #1 as it has a very minor impact on deployments =
that don't care (i.e., they just set par_jwks_uri and jwks_uri to the =
same value) and failing to support this trust boundary creates an =
artificial limit on implementation architecture and could lead to =
compatibility-breaking workarounds.
>=20
>    =E2=80=93=20
>    Annabelle Richard Backman
>    AWS Identity
>=20
>=20
>    On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" =
 wrote:
>=20
>        Hi Filip,=20
>=20
>> On 31. Dec 2019, at 16:22, Filip Skokan  wrote:
>>=20
>> I don't think we need a *_auth_method_* metadata for every endpoint =
the client calls directly, none of the new specs defined these (e.g. =
device authorization endpoint or CIBA), meaning they also didn't follow =
the scheme from RFC 8414 where introspection and revocation got its own =
metadata. In most cases the unfortunately named =
`token_endpoint_auth_method` and its related metadata is what's used by =
clients for all direct calls anyway.
>>=20
>> The same principle could be applied to signing (and encryption) =
algorithms as well.
>>=20
>> This I do not follow, auth methods and their signing is dealt with by =
using `token_endpoint_auth_methods_supported` and =
`token_endpoint_auth_signing_alg_values_supported` - there's no =
encryption for the `_jwt` client auth methods.=20
>> Unless it was meant to address the Request Object signing and =
encryption metadata, which is defined and IANA registered by OIDC. PAR =
only references JAR section 6.1 and 6.2 for decryption/signature =
validation and these do not mention the metadata (e.g. =
request_object_signing_alg) anymore since draft 07.
>=20
>        Dammed! You are so right. Sorry, I got confused somehow.=20
>=20
>>=20
>> PS: I also found this comment related to the same question about auth =
metadata but for CIBA.
>=20
>        Thanks for sharing.=20
>=20
>>=20
>> Best,
>> Filip
>=20
>        thanks,
>        Torsten.=20
>=20
>>=20
>>=20
>> On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt =
 wrote:
>> Hi all,
>>=20
>> Ronald just sent me an email asking whether we will define metadata =
for=20
>>=20
>> pushed_authorization_endpoint_auth_methods_supported and
>> pushed_authorization_endpoint_auth_signing_alg_values_supported.
>>=20
>> The draft right now utilises the existing token endpoint =
authentication methods so there is basically no need to define another =
parameter. The same principle could be applied to signing (and =
encryption) algorithms as well.=20
>>=20
>> What=E2=80=99s your opinion?
>>=20
>> best regards,
>> Torsten.
>=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
>    CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.
>    _______________________________________________
>    OAuth mailing list
>    OAuth@ietf.org
>    https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jan 10 09:01: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 3AD2C120A48 for ; Fri, 10 Jan 2020 09:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8CgkhHkooF8w for ; Fri, 10 Jan 2020 09:01:14 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EC8120A25 for ; Fri, 10 Jan 2020 09:01:02 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AH0vHw030069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 12:00:58 -0500
From: Justin Richer 
Message-Id: <22EC8AB0-2E11-437E-9C5B-BA354A284864@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9367772-0C5A-4488-9267-9A33FBA9FBB8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 12:00:57 -0500
In-Reply-To: <84329089-E065-421D-AD93-439C6D7E3F44@forgerock.com>
Cc: "Richard Backman, Annabelle" , Mike Jones , oauth 
To: Neil Madden 
References:  <84329089-E065-421D-AD93-439C6D7E3F44@forgerock.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 17:01:20 -0000

--Apple-Mail=_A9367772-0C5A-4488-9267-9A33FBA9FBB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I would argue that the AS being monolithic, as seen by outside parties, =
is a core assumption in OAuth 2. While there are deployments that, for =
example, split the authorization and token endpoints into different =
domains and servers, the client still sees them as a single entity.=20

I think it=E2=80=99s fair for any extension to OAuth 2 to rest on that =
assumption. Any effort to split the endpoints into parts should be seen =
as a deployment detail requiring some extra work on the deployer=E2=80=99s=
 side. For example, take PKCE: you need to communicate the client=E2=80=99=
s challenge at the authorization endpoint back to the token endpoint in =
order to verify the verifier. Or even just the authorization code =
itself. OAuth doesn=E2=80=99t tell you how to do that at all because it =
assumes that=E2=80=99s your problem to solve and it=E2=80=99s internal =
to the box drawn by the protocol.

We do have a chance with the next generation work that we=E2=80=99re =
trying to start over in TxAuth to change these assumptions, but I think =
it=E2=80=99s too late to impose that requirement on OAuth 2.

 =E2=80=94 Justin

> On Jan 10, 2020, at 10:50 AM, Neil Madden  =
wrote:
>=20
> This is an interesting point.
>=20
> I think OAuth has historically assumed that the AS is a monolithic =
system, or at least can be treated like one by clients. I think we might =
have to revisit quite a lot if we drop this assumption and adopt a =
threat model in which the AS is itself composed of a collection of =
mutually distrusting entities. Especially as different ASes might decide =
to divide up the trust boundaries in different ways.
>=20
> At least partially this feels like an internal implementation detail =
of the AS that can also be solved internally to that AS. For example, =
rather than providing microservices direct access to private keys you =
could implement a JWT-decryption-microservice that other microservices =
call. It can then check if the calling microservice is allowed to =
decrypt that type of JWT before returning the response (e.g., by =
checking the "typ" header). The same can be done for signing JWTs. Of =
course, that's not a perfect solution, but it illustrates that we don't =
necessarily need to solve these problems in the WG.
>=20
> If we go down the path of separate keys, then it might be simpler to =
introduce new metadata elements to list the kids of valid key ids for a =
given purpose rather than having multiple JWK Set endpoints. e.g. =
"id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids =
the client having to fetch multiple sets of keys.
>=20
> -- Neil
>=20
>> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle =
> wrote:
>>=20
>> The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepresentation of a =
legitimately issued JWT, but it doesn=E2=80=99t address the issue I am =
trying to draw attention to, which is that the current model forces =
broader distribution and reuse of keys than is necessary, resulting in a =
greater blast radius for compromised keys or systems.
>> =20
>> For many cases, this is not a significant concern, as the AS is a =
monolithic system with no internal trust boundaries. However, in cases =
where the AS is composed of multiple microservices performing different =
tasks, the need to share keys between different microservices undermines =
efforts to create trust boundaries between them. I gave one example of =
this in my original email, where ID Token generation and access token =
generation are relegated to independent systems, each with separate =
private keys for signing tokens. Suppose a malicious party compromised =
the ID Token generator, or gained access to its private key, and issued =
fraudulent access tokens signed using that key. Since verifiers of both =
token types will look to the same metadata file and thus the same JWK =
set, they have no way to recognize that these access tokens are =
fraudulent.
>> =20
>> Note that while =E2=80=9Ctyp=E2=80=9D would help a verifier =
distinguish between an ID Token and an access token, it does not help in =
this case because the malicious party is generating well-formed access =
token JWTs, signed with a key that is legitimate for the AS but not for =
this purpose.
>> =20
>> The case for this being a concern on the encryption side is fuzzier, =
primarily because we simply don=E2=80=99t have many use cases where =
different kinds of content gets encrypted and sent to the AS in =
different contexts. However, I gave one example on the PAR thread =
,=
 where a PAR endpoint that decrypts request object JWTs will also be =
able to decrypt id_token_hint JWTs.
>> =20
>> =E2=80=93=20
>> Annabelle Richard Backman
>> AWS Identity
>> =20
>> =20
>> From: Mike Jones >
>> Date: Thursday, January 9, 2020 at 11:34 AM
>> To: "Richard Backman, Annabelle" >, oauth >
>> Subject: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits =
of jwks_uri
>> =20
>> This a good thing to think about.  Thanks for bringing this up, =
Annabelle.
>> =20
>> One thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D=
 and/or =E2=80=9Ckey_ops=E2=80=9D attributes can be provided.  This can =
allow signing keys to be differentiated from encryption keys, for =
instance.
>> =20
>> I=E2=80=99m not as worried about encryption keys as signing keys.  If =
multiple kinds of applications encrypt content to a party using the same =
public per-party key, and the encryption is being used only to ensure =
confidentiality of the messages, the confidentiality is still achieved.
>> =20
>> One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D =
field, as described in the JWT BCP.  Even if the same key was used and =
you receive an unexpected JWT type, you will still reject it.
>> =20
>> I believe there=E2=80=99s also cases where it=E2=80=99s fine to use =
the same signing key for related operations.  For instance, signing a =
Pushed Authorization Request and a Request Object with the same key =
seems both logical and safe to me.  (If others can think of an attack =
that this enables, however, please do point it out.)
>> =20
>> Which I believe leaves us with this case to worry about =E2=80=93 =
shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D =
is not used.  One way to mitigate this would be to use per-application =
key sets.  For instance, using values other than =E2=80=9Cjwks_uri=E2=80=9D=
 to reference key sets for particular applications.
>> =20
>> Anyway, for PAR, I believe that it=E2=80=99s fine to use the same =
keys as used for Request Objects, so no new fields are needed for it.
>> =20
>> I look forward to further discussion on the topic.
>> =20
>>                                                        -- Mike
>> =20
>> From: OAuth > =
On Behalf Of Richard Backman, Annabelle
>> Sent: Wednesday, January 8, 2020 3:47 PM
>> To: oauth >
>> Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
>> =20
>> I originally brought up this issue in the context of the PAR draft, =
but since it broadly applies to the OAuth space I=E2=80=99m starting a =
new thread=E2=80=A6
>> =20
>> Section 3.12 of the JWT BCP =
 says: =E2=80=9C=
Use different keys for different kinds of JWTs.=E2=80=9D Section 4 of =
the JWT Profile for OAuth 2.0 Access Tokens =
says: =E2=80=9C=
An authorization server MAY elect to use different keys to sign =
id_tokens and JWT access tokens.=E2=80=9D These statements are =
consistent with good cryptographic hygiene. And we=E2=80=99ve made it =
difficult to impossible for an AS to follow them.
>> =20
>> The AS has a single metadata document containing a single URI =
referencing a single JWK Set. But the AS has no way of indicating to =
clients which keys to use for which purposes. For example, an AS cannot =
say that *only these* keys are to be used to encrypt id_token_hint JWTs, =
and *only these* keys are to be used to encrypt JAR request object JWTs. =
For encryption, the AS could enforce that logic internally, but there is =
no way for the client to discover this. And while the AS may be built to =
only use certain keys for signing ID Tokens and other keys for signing =
JWT access tokens, it has no way to indicate this to the client. So even =
if ID Token generation and access token generation are isolated in =
different microservices within the AS, each microservice is capable of =
forging the other=E2=80=99s tokens, because consumers can=E2=80=99t be =
told to distinguish between different keys for the AS.
>> =20
>> This seems like a ticking time bomb to me, as it=E2=80=99s a =
non-obvious side effect of combining various OAuth 2.0 extensions, and =
it can undermine a lot of sophisticated effort to follow security best =
practices. I can see a couple of ways to address this (e.g., more =
sophisticated AS key metadata, tagging or similar use case indication on =
JWKs), but before trying to propose something I=E2=80=99d like to get =
people=E2=80=99s opinions on the problem. Is this already mitigated in =
other ways? Has the ship sailed on this for OAuth, and now we have to =
live with it? Should this be left to the deployments that care to solve =
with non-interoperable solutions? Are there other clever ways we could =
approach this? Are there other angles that we need to consider?
>> =20
>> =E2=80=93=20
>> Annabelle Richard Backman
>> AWS Identity
>> =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=_A9367772-0C5A-4488-9267-9A33FBA9FBB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
would argue that the AS being monolithic, as seen by outside parties, is =
a core assumption in OAuth 2. While there are deployments that, for =
example, split the authorization and token endpoints into different =
domains and servers, the client still sees them as a single =
entity. 

I =
think it=E2=80=99s fair for any extension to OAuth 2 to rest on that =
assumption. Any effort to split the endpoints into parts should be seen =
as a deployment detail requiring some extra work on the deployer=E2=80=99s=
 side. For example, take PKCE: you need to communicate the client=E2=80=99=
s challenge at the authorization endpoint back to the token endpoint in =
order to verify the verifier. Or even just the authorization code =
itself. OAuth doesn=E2=80=99t tell you how to do that at all because it =
assumes that=E2=80=99s your problem to solve and it=E2=80=99s internal =
to the box drawn by the protocol.

We do have a chance with the next =
generation work that we=E2=80=99re trying to start over in TxAuth to =
change these assumptions, but I think it=E2=80=99s too late to impose =
that requirement on OAuth 2.

 =E2=80=94 Justin

On Jan 10, 2020, at 10:50 AM, Neil Madden <neil.madden@forgerock.com> wrote:



This =
is an interesting point.

I think OAuth has historically assumed that the AS is a =
monolithic system, or at least can be treated like one by clients. I =
think we might have to revisit quite a lot if we drop this assumption =
and adopt a threat model in which the AS is itself composed of a =
collection of mutually distrusting entities. Especially as different =
ASes might decide to divide up the trust boundaries in different =
ways.

At least =
partially this feels like an internal implementation detail of the AS =
that can also be solved internally to that AS. For example, rather than =
providing microservices direct access to private keys you could =
implement a JWT-decryption-microservice that other microservices call. =
It can then check if the calling microservice is allowed to decrypt that =
type of JWT before returning the response (e.g., by checking the "typ" =
header). The same can be done for signing JWTs. Of course, that's not a =
perfect solution, but it illustrates that we don't necessarily need to =
solve these problems in the WG.

If we go down the path of separate =
keys, then it might be simpler to introduce new metadata elements to =
list the kids of valid key ids for a given purpose rather than having =
multiple JWK Set endpoints. e.g. "id_token_hint_encryption_kids": =
["rsa-key-1", "ec-key-2"]. That avoids the client having to fetch =
multiple sets of keys.

-- Neil

On 10 Jan 2020, at 00:25, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:

The =E2=80=9Ctyp=E2=80=9D field =
helps prevent misrepresentation of a legitimately issued JWT, but it =
doesn=E2=80=99t address the issue I am trying to draw attention to, =
which is that the current model forces broader distribution and reuse of =
keys than is necessary, resulting in a greater blast radius for =
compromised keys or systems.
 
For many cases, =
this is not a significant concern, as the AS is a monolithic system with =
no internal trust boundaries. However, in cases where the AS is composed =
of multiple microservices performing different tasks, the need to share =
keys between different microservices undermines efforts to create trust =
boundaries between them. I gave one example of this in my original =
email, where ID Token generation and access token generation are =
relegated to independent systems, each with separate private keys for =
signing tokens. Suppose a malicious party compromised the ID Token =
generator, or gained access to its private key, and issued fraudulent =
access tokens signed using that key. Since verifiers of both token types =
will look to the same metadata file and thus the same JWK set, they have =
no way to recognize that these access tokens are fraudulent.
 
Note that while =
=E2=80=9Ctyp=E2=80=9D would help a verifier distinguish between an ID =
Token and an access token, it does not help in this case because the =
malicious party is generating well-formed access token JWTs, signed with =
a key that is legitimate for the AS but not for this purpose.
 
The case for this =
being a concern on the encryption side is fuzzier, primarily because we =
simply don=E2=80=99t have many use cases where different kinds of =
content gets encrypted and sent to the AS in different contexts. =
However, I =
gave one example on the PAR thread, where a PAR endpoint that =
decrypts request object JWTs will also be able to decrypt id_token_hint =
JWTs.
 
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
 
From: Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Thursday, January 9, =
2020 at 11:34 AM
To: "Richard Backman, =
Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] RE: =
Cryptographic hygiene and the limits of jwks_uri
 
This a good thing to think about.  Thanks for bringing =
this up, Annabelle.
 
One thing that partially mitigates this is =
that the =E2=80=9Cuse=E2=80=9D and/or =E2=80=9Ckey_ops=E2=80=9D =
attributes can be provided.  This can allow signing keys to be =
differentiated from encryption keys, for instance.
 
I=E2=80=99m not as worried about encryption keys as signing =
keys.  If multiple kinds of applications encrypt content to a party =
using the same public per-party key, and the encryption is being used =
only to ensure confidentiality of the messages, the confidentiality is =
still achieved.
 
One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=
=9D field, as described in the JWT BCP.  Even if the same key was =
used and you receive an unexpected JWT type, you will still reject =
it.
 
I believe there=E2=80=99s also cases where it=E2=80=99s fine =
to use the same signing key for related operations.  For instance, =
signing a Pushed Authorization Request and a Request Object with the =
same key seems both logical and safe to me.  (If others can think =
of an attack that this enables, however, please do point it =
out.)
 
Which I believe leaves us with this case to worry about =E2=80=93=
 shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D =
is not used.  One way to mitigate this would be to use =
per-application key sets.  For instance, using values other than =
=E2=80=9Cjwks_uri=E2=80=9D to reference key sets for particular =
applications.
 
Anyway, for PAR, I believe that it=E2=80=99s fine to use the =
same keys as used for Request Objects, so no new fields are needed for =
it.
 
I look forward to further discussion on the topic.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf =
Of Richard =
Backman, Annabelle
Sent: Wednesday, January 8, 2020 =
3:47 PM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Cryptographic =
hygiene and the limits of jwks_uri
 
I originally =
brought up this issue in the context of the PAR draft, but since it =
broadly applies to the OAuth space I=E2=80=99m starting a new =
thread=E2=80=A6
 
Section=
 3.12 of the JWT BCP says: =E2=80=9CUse =
different keys for different kinds of JWTs.=E2=80=9D Section 4 of the JWT Profile for OAuth 2.0 Access =
Tokenssays: =E2=80=9CAn authorization server MAY elect to use =
different keys to sign id_tokens and JWT access tokens.=E2=80=9D These =
statements are consistent with good cryptographic hygiene. And we=E2=80=99=
ve made it difficult to impossible for an AS to follow them.
 
The AS has a single metadata =
document containing a single URI referencing a single JWK Set. But the =
AS has no way of indicating to clients which keys to use for which =
purposes. For example, an AS cannot say that *only these* =
keys are to be used to encrypt id_token_hint JWTs, and *only=
 these* keys are to be used to encrypt JAR request object JWTs. For =
encryption, the AS could enforce that logic internally, but there is no =
way for the client to discover this. And while the AS may be built to =
only use certain keys for signing ID Tokens and other keys for signing =
JWT access tokens, it has no way to indicate this to the client. So even =
if ID Token generation and access token generation are isolated in =
different microservices within the AS, each microservice is capable of =
forging the other=E2=80=99s tokens, because consumers can=E2=80=99t be =
told to distinguish between different keys for the AS.
 
This seems like a ticking time =
bomb to me, as it=E2=80=99s a non-obvious side effect of combining =
various OAuth 2.0 extensions, and it can undermine a lot of =
sophisticated effort to follow security best practices. I can see a =
couple of ways to address this (e.g., more sophisticated AS key =
metadata, tagging or similar use case indication on JWKs), but before =
trying to propose something I=E2=80=99d like to get people=E2=80=99s =
opinions on the problem. Is this already mitigated in other ways? Has =
the ship sailed on this for OAuth, and now we have to live with it? =
Should this be left to the deployments that care to solve with =
non-interoperable solutions? Are there other clever ways we could =
approach this? Are there other angles that we need to =
consider?
 
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

=

--Apple-Mail=_A9367772-0C5A-4488-9267-9A33FBA9FBB8--


From nobody Fri Jan 10 09: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 E400A120AE1 for ; Fri, 10 Jan 2020 09:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7QXcPm9nQxs for ; Fri, 10 Jan 2020 09:22:56 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD44120AD1 for ; Fri, 10 Jan 2020 09:22:53 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id b15so2053961lfc.4 for ; Fri, 10 Jan 2020 09:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fu+xiW7b2c/PNERtbIsntnConQ2x5KYHYN7oaSgDfRk=; b=pPS3XGUgNjnxDW89n+kUg/qC7y2h6H+FThmDCj8MU9zZ75gIVIm27swBuw0xW7MyaM ZxWujja0RZy71WW57IVX4hlLdOUbKTOxbsFm14qKdgzv58Y616XiLLZTV5dXVnlbbkOA 2Bv7jJQDW3zFCk62IWzqEpusv69HVH/WWEBAeQETup09gbrqNngfI9+8pNldJhuwRsK6 97acGc/5ggSmfotmknAI3K2bIGHE6EahAt6IZALyrQAE2wZyFtt1ECkrfU6oEch5gGpP fLXOTUlgyAcsDTh+dP6f5Lc78w23N2MLCoaT8s5p+BSX1U6qhTL1UcWV2OQ+20jNLc8n Q27A==
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=fu+xiW7b2c/PNERtbIsntnConQ2x5KYHYN7oaSgDfRk=; b=PzG/+qEb9IjcKACFAGKrOeMpg9mFfKYX7GyGiYaJFFqq/RrxWtTGWsSpBx0FIsklyp fU6Xcr6ZUvg8Xs0KJFoUlDn9+4CnWux8t1z6qbdPYIiA03xGQRhvu8/Z81k2MBHqWIad neSxZh/UUNUs715BT28jEp22UPn+zF91yqujdjAdLeJVtyl5E/C85600ubY601brrlWG 1K1aA8Uxwh+Gk9EgdMxRbDxaC37Dn5sBYaQRH7OtjbGyyvF8QGo8m7/Uvl90cPmjg/ro 7X5tvNpIEDDAjzuDA0ikIqt6CITNwhDVQnvxRZGsUeNjliOeBRv5YvaEeepCKtPPRo6m undQ==
X-Gm-Message-State: APjAAAVFpL4aZlOw16zAryjrtShoJ8o/efCc3k3HUxoBATNk6L4aQRFg 4M89ziEpt1msMyt6O1SAVKkm1b1TIfJR/F7OIxE=
X-Google-Smtp-Source: APXvYqzyKU3/xSl350XT85oCh4H22eMkIpEeb/Y6WwbOD5gEqELWj27iX+oufZyukMBOHDc41Q2BoNhCsXqiFKC/j4I=
X-Received: by 2002:a19:4b87:: with SMTP id y129mr3195653lfa.32.1578676971481;  Fri, 10 Jan 2020 09:22:51 -0800 (PST)
MIME-Version: 1.0
References:  <84329089-E065-421D-AD93-439C6D7E3F44@forgerock.com> <22EC8AB0-2E11-437E-9C5B-BA354A284864@mit.edu>
In-Reply-To: <22EC8AB0-2E11-437E-9C5B-BA354A284864@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 09:22:39 -0800
Message-ID: 
To: Justin Richer 
Cc: Neil Madden , oauth ,  Mike Jones ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="00000000000019ae4d059bcc60d4"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 17:22:59 -0000

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

OAuth 1.0 assumed the RS and AS were a monolith.

OAuth 2.0 separated the RS and the AS. It put them in separate boxes. It
also did not define the access token, allowing an implementation to keep
them as a monolith, or allow separation of duties. There was no impact on
the client, but it was a more agile specification for implementation.

As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
Provider, and the access token is being defined. These extensions have
assumed all of this functionality is a monolith.

I'm not suggesting that we MUST make changes to existing extensions, but
design future extensions so that an implementation can separate duties if
desired.

As to the suggestion of using a JWT-decryption-microservice, another goal
would be increased resiliency of the components. If the
JWT-decryption-microservice is unavailable, the whole system is
unavailable. If there are separate keys, then a failure in one component
does not fail the entire system.

/Dick




=E1=90=A7

On Fri, Jan 10, 2020 at 9:01 AM Justin Richer  wrote:

> I would argue that the AS being monolithic, as seen by outside parties, i=
s
> a core assumption in OAuth 2. While there are deployments that, for
> example, split the authorization and token endpoints into different domai=
ns
> and servers, the client still sees them as a single entity.
>
> I think it=E2=80=99s fair for any extension to OAuth 2 to rest on that as=
sumption.
> Any effort to split the endpoints into parts should be seen as a deployme=
nt
> detail requiring some extra work on the deployer=E2=80=99s side. For exam=
ple, take
> PKCE: you need to communicate the client=E2=80=99s challenge at the autho=
rization
> endpoint back to the token endpoint in order to verify the verifier. Or
> even just the authorization code itself. OAuth doesn=E2=80=99t tell you h=
ow to do
> that at all because it assumes that=E2=80=99s your problem to solve and i=
t=E2=80=99s
> internal to the box drawn by the protocol.
>
> We do have a chance with the next generation work that we=E2=80=99re tryi=
ng to
> start over in TxAuth to change these assumptions, but I think it=E2=80=99=
s too late
> to impose that requirement on OAuth 2.
>
>  =E2=80=94 Justin
>
> On Jan 10, 2020, at 10:50 AM, Neil Madden 
> wrote:
>
> This is an interesting point.
>
> I think OAuth has historically assumed that the AS is a monolithic system=
,
> or at least can be treated like one by clients. I think we might have to
> revisit quite a lot if we drop this assumption and adopt a threat model i=
n
> which the AS is itself composed of a collection of mutually distrusting
> entities. Especially as different ASes might decide to divide up the trus=
t
> boundaries in different ways.
>
> At least partially this feels like an internal implementation detail of
> the AS that can also be solved internally to that AS. For example, rather
> than providing microservices direct access to private keys you could
> implement a JWT-decryption-microservice that other microservices call. It
> can then check if the calling microservice is allowed to decrypt that typ=
e
> of JWT before returning the response (e.g., by checking the "typ" header)=
.
> The same can be done for signing JWTs. Of course, that's not a perfect
> solution, but it illustrates that we don't necessarily need to solve thes=
e
> problems in the WG.
>
> If we go down the path of separate keys, then it might be simpler to
> introduce new metadata elements to list the kids of valid key ids for a
> given purpose rather than having multiple JWK Set endpoints. e.g.
> "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids t=
he
> client having to fetch multiple sets of keys.
>
> -- Neil
>
> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepresentation of a legi=
timately issued
> JWT, but it doesn=E2=80=99t address the issue I am trying to draw attenti=
on to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromis=
ed
> keys or systems.
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of th=
is
> in my original email, where ID Token generation and access token generati=
on
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have =
no
> way to recognize that these access tokens are fraudulent.
>
> Note that while =E2=80=9Ctyp=E2=80=9D would help a verifier distinguish b=
etween an ID
> Token and an access token, it does not help in this case because the
> malicious party is generating well-formed access token JWTs, signed with =
a
> key that is legitimate for the AS but not for this purpose.
>
> The case for this being a concern on the encryption side is fuzzier,
> primarily because we simply don=E2=80=99t have many use cases where diffe=
rent kinds
> of content gets encrypted and sent to the AS in different contexts. Howev=
er,
>  I gave one example on the PAR thread
> =
,
> where a PAR endpoint that decrypts request object JWTs will also be able =
to
> decrypt id_token_hint JWTs.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *Mike Jones 
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" , oauth <
> oauth@ietf.org>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
> This a good thing to think about.  Thanks for bringing this up, Annabelle=
.
>
> One thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D=
 and/or =E2=80=9Ckey_ops=E2=80=9D
> attributes can be provided.  This can allow signing keys to be
> differentiated from encryption keys, for instance.
>
> I=E2=80=99m not as worried about encryption keys as signing keys.  If mul=
tiple
> kinds of applications encrypt content to a party using the same public
> per-party key, and the encryption is being used only to ensure
> confidentiality of the messages, the confidentiality is still achieved.
>
> One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D field=
, as described in
> the JWT BCP.  Even if the same key was used and you receive an unexpected
> JWT type, you will still reject it.
>
> I believe there=E2=80=99s also cases where it=E2=80=99s fine to use the s=
ame signing key
> for related operations.  For instance, signing a Pushed Authorization
> Request and a Request Object with the same key seems both logical and saf=
e
> to me.  (If others can think of an attack that this enables, however,
> please do point it out.)
>
> Which I believe leaves us with this case to worry about =E2=80=93 shared =
signing
> keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D is not used.  O=
ne way to mitigate
> this would be to use per-application key sets.  For instance, using value=
s
> other than =E2=80=9Cjwks_uri=E2=80=9D to reference key sets for particula=
r applications.
>
> Anyway, for PAR, I believe that it=E2=80=99s fine to use the same keys as=
 used for
> Request Objects, so no new fields are needed for it.
>
> I look forward to further discussion on the topic.
>
>                                                        -- Mike
>
> *From:* OAuth  *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
>
> I originally brought up this issue in the context of the PAR draft, but
> since it broadly applies to the OAuth space I=E2=80=99m starting a new th=
read=E2=80=A6
>
> Section 3.12 of the JWT BCP
> 
>  says: =E2=80=9CUse different keys for different kinds of JWTs.=E2=80=9D =
Section 4 of the
> JWT Profile for OAuth 2.0 Access Tokens
> says:
> =E2=80=9CAn authorization server MAY elect to use different keys to sign =
id_tokens
> and JWT access tokens.=E2=80=9D These statements are consistent with good
> cryptographic hygiene. And we=E2=80=99ve made it difficult to impossible =
for an AS
> to follow them.
>
> The AS has a single metadata document containing a single URI referencing
> a single JWK Set. But the AS has no way of indicating to clients which ke=
ys
> to use for which purposes. For example, an AS cannot say that **only*
> *these** keys are to be used to encrypt id_token_hint JWTs, and **only
> these** keys are to be used to encrypt JAR request object JWTs. For
> encryption, the AS could enforce that logic internally, but there is no w=
ay
> for the client to discover this. And while the AS may be built to only us=
e
> certain keys for signing ID Tokens and other keys for signing JWT access
> tokens, it has no way to indicate this to the client. So even if ID Token
> generation and access token generation are isolated in different
> microservices within the AS, each microservice is capable of forging the
> other=E2=80=99s tokens, because consumers can=E2=80=99t be told to distin=
guish between
> different keys for the AS.
>
> This seems like a ticking time bomb to me, as it=E2=80=99s a non-obvious =
side
> effect of combining various OAuth 2.0 extensions, and it can undermine a
> lot of sophisticated effort to follow security best practices. I can see =
a
> couple of ways to address this (e.g., more sophisticated AS key metadata,
> tagging or similar use case indication on JWKs), but before trying to
> propose something I=E2=80=99d like to get people=E2=80=99s opinions on th=
e problem. Is this
> already mitigated in other ways? Has the ship sailed on this for OAuth, a=
nd
> now we have to live with it? Should this be left to the deployments that
> care to solve with non-interoperable solutions? Are there other clever wa=
ys
> we could approach this? Are there other angles that we need to consider?
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


OAuth 1.0 assumed the RS and AS were a monolith.

<=
/div>
OAuth 2.0 separated=C2=A0the RS and the AS. It put them in separa=
te boxes. It also did not define the access token, allowing an implementati=
on to keep them as a monolith, or allow separation=C2=A0of duties. There wa=
s no impact on the client, but it was a more agile specification for implem=
entation.=C2=A0

As OAuth 2.0 has been extended, th=
e AS is now also an OpenID Connect Provider, and the access token is being =
defined. These extensions have assumed all of this functionality is a monol=
ith.=C2=A0

I'm not suggesting that we MUST mak=
e changes to existing extensions, but design future extensions so that an i=
mplementation can separate duties if desired.

As t=
o the suggestion of using a JWT-decryption-microservice, another goal would=
 be increased resiliency of the components. If the JWT-decryption-microserv=
ice is unavailable, the whole system is unavailable. If there are separate=
=C2=A0keys, then a failure in one component does not fail the entire system=
.=C2=A0

/Dick


<=
div>

3D""=E1=90=A7

On Fri, Jan 10,=
 2020 at 9:01 AM Justin Richer <jrich=
er@mit.edu> wrote:
I would argue that the=
 AS being monolithic, as seen by outside parties, is a core assumption in O=
Auth 2. While there are deployments that, for example, split the authorizat=
ion and token endpoints into different domains and servers, the client stil=
l sees them as a single entity.=C2=A0

I think it=E2=80=
=99s fair for any extension to OAuth 2 to rest on that assumption. Any effo=
rt to split the endpoints into parts should be seen as a deployment detail =
requiring some extra work on the deployer=E2=80=99s side. For example, take=
 PKCE: you need to communicate the client=E2=80=99s challenge at the author=
ization endpoint back to the token endpoint in order to verify the verifier=
. Or even just the authorization code itself. OAuth doesn=E2=80=99t tell yo=
u how to do that at all because it assumes that=E2=80=99s your problem to s=
olve and it=E2=80=99s internal to the box drawn by the protocol.
=

We do have a chance with the next generation work that we=E2=
=80=99re trying to start over in TxAuth to change these assumptions, but I =
think it=E2=80=99s too late to impose that requirement on OAuth 2.

=C2=A0=E2=80=94 Justin

On Jan 10, 2020, at 10:50 AM, Neil Madden <neil.madden@forgerock.com<=
/a>> wrote:



This is an interesting point=
.

I think OAuth has historically assumed that the =
AS is a monolithic system, or at least can be treated like one by clients. =
I think we might have to revisit quite a lot if we drop this assumption and=
 adopt a threat model in which the AS is itself composed of a collection of=
 mutually distrusting entities. Especially as different ASes might decide t=
o divide up the trust boundaries in different ways.

At least partially this feels like an internal implementation detail of t=
he AS that can also be solved internally to that AS. For example, rather th=
an providing microservices direct access to private keys you could implemen=
t a JWT-decryption-microservice that other microservices call. It can then =
check if the calling microservice is allowed to decrypt that type of JWT be=
fore returning the response (e.g., by checking the "typ" header).=
 The same can be done for signing JWTs. Of course, that's not a perfect=
 solution, but it illustrates that we don't necessarily need to solve t=
hese problems in the WG.

If we go down the path of=
 separate keys, then it might be simpler to introduce new metadata elements=
 to list the kids of valid key ids for a given purpose rather than having m=
ultiple JWK Set endpoints. e.g. "id_token_hint_encryption_kids": =
["rsa-key-1", "ec-key-2"]. That avoids the client havin=
g to fetch multiple sets of keys.

-- Neil


The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepres=
entation of a legitimately issued JWT, but it doesn=E2=80=99t address the i=
ssue I am trying to draw attention to, which is that the current model forc=
es broader distribution and reuse of keys than is necessary, resulting in a=
 greater blast radius for compromised keys or systems.=

=C2=A0<=
/div>
For many cases, this is not a=
 significant concern, as the AS is a monolithic system with no internal tru=
st boundaries. However, in cases where the AS is composed of multiple micro=
services performing different tasks, the need to share keys between differe=
nt microservices undermines efforts to create trust boundaries between them=
. I gave one example of this in my original email, where ID Token generatio=
n and access token generation are relegated to independent systems, each wi=
th separate private keys for signing tokens. Suppose a malicious party comp=
romised the ID Token generator, or gained access to its private key, and is=
sued fraudulent access tokens signed using that key. Since verifiers of bot=
h token types will look to the same metadata file and thus the same JWK set=
, they have no way to recognize that these access tokens are fraudulent.=

=C2=
=A0
Note that w=
hile =E2=80=9Ctyp=E2=80=9D would help a verifier distinguish between an ID =
Token and an access token, it does not help in this case because the malici=
ous party is generating well-formed access token JWTs, signed with a key th=
at is legitimate for the AS but not for this purpose.<=
/div>
=C2=A0
=C2=A0=

=E2=80=93=C2=A0
AWS Identity
=C2=A0<=
u>
=C2=A0
=
From:=C2=A0Mike Jones <Michael.Jones=3D40microsoft.co=
m@dmarc.ietf.org>
Date:=C2=A0Thursday, Januar=
y 9, 2020 at 11:34 AM
To:=C2=A0"Richard Backman=
, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Sub=
ject:=C2=A0[UNVERIFIED SENDER] RE: Cryptographic hygiene a=
nd the limits of jwks_uri
=
=C2=A0
This a good thing to=
 think about.=C2=A0 Thanks for bringing this up, Annabelle.
=C2=
=A0
One thing that partially mitigates this is that the =E2=80=
=9Cuse=E2=80=9D and/or =E2=80=9Ckey_ops=E2=80=9D attributes can be provided=
.=C2=A0 This can allow signing keys to be differentiated from encryption ke=
ys, for instance.
=C2=A0
I=E2=80=99m not as worried a=
bout encryption keys as signing keys.=C2=A0 If multiple kinds of applicatio=
ns encrypt content to a party using the same public per-party key, and the =
encryption is being used only to ensure confidentiality of the messages, th=
e confidentiality is still achieved.
=
=C2=A0
One mit=
igation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D field, as desc=
ribed in the JWT BCP.=C2=A0 Even if the same key was used and you receive a=
n unexpected JWT type, you will still reject it.
=

=C2=A0
I believe there=E2=80=99s also cases where it=E2=80=99s fine to use the =
same signing key for related operations.=C2=A0 For instance, signing a Push=
ed Authorization Request and a Request Object with the same key seems both =
logical and safe to me.=C2=A0 (If others can think of an attack that this e=
nables, however, please do point it out.)
=C2=A0
Whic=
h I believe leaves us with this case to worry about =E2=80=93 shared signin=
g keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D is not used.=C2=
=A0 One way to mitigate this would be to use per-application key sets.=C2=
=A0 For instance, using values other than =E2=80=9Cjwks_uri=E2=80=9D to ref=
erence key sets for particular applications.
=C2=A0
A=
nyway, for PAR, I believe that it=E2=80=99s fine to use the same keys as us=
ed for Request Objects, so no new fields are needed for it.
=C2=
=A0
I look forward to further discussion on the topic.=

=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/div>
=C2=A0
From:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0On Behalf Of=C2=
=A0Richard Backman, Annabelle
Sent:=C2=A0=
Wednesday, January 8, 2020 3:47 PM
To:=C2=A0oauth &l=
t;oauth@ietf.org>
Subject:=
=C2=A0[OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
=C2=A0
I originally brought up this issue in=
 the context of the PAR draft, but since it broadly applies to the OAuth sp=
ace I=E2=80=99m starting a new thread=E2=80=A6
=C2=A0
Section 3.12 of the JWT BCP=C2=A0=
says: =E2=80=9CUse different keys for different kinds of JWTs.=E2=80=
=9D=C2=A0Section 4 of the JWT Profile for OAuth 2.0 Access Token=
ssays: =E2=80=9CAn authorization server MAY elect to use different keys=
 to sign id_tokens and JWT access tokens.=E2=80=9D These statements are con=
sistent with good cryptographic hygiene. And we=E2=80=99ve made it difficul=
t to impossible for an AS to follow them.
=C2=A0
The AS has a single metadata document cont=
aining a single URI referencing a single JWK Set. But the AS has no way of =
indicating to clients which keys to use for which purposes. For example, an=
 AS cannot say that *only=C2=A0these* keys are t=
o be used to encrypt id_token_hint JWTs, and *only these* keys are t=
o be used to encrypt JAR request object JWTs. For encryption, the AS could =
enforce that logic internally, but there is no way for the client to discov=
er this. And while the AS may be built to only use certain keys for signing=
 ID Tokens and other keys for signing JWT access tokens, it has no way to i=
ndicate this to the client. So even if ID Token generation and access token=
 generation are isolated in different microservices within the AS, each mic=
roservice is capable of forging the other=E2=80=99s tokens, because consume=
rs can=E2=80=99t be told to distinguish between different keys for the AS.<=
/span>
=C2=A0
This seem=
s like a ticking time bomb to me, as it=E2=80=99s a non-obvious side effect=
 of combining various OAuth 2.0 extensions, and it can undermine a lot of s=
ophisticated effort to follow security best practices. I can see a couple o=
f ways to address this (e.g., more sophisticated AS key metadata, tagging o=
r similar use case indication on JWKs), but before trying to propose someth=
ing I=E2=80=99d like to get people=E2=80=99s opinions on the problem. Is th=
is already mitigated in other ways? Has the ship sailed on this for OAuth, =
and now we have to live with it? Should this be left to the deployments tha=
t care to solve with non-interoperable solutions? Are there other clever wa=
ys we could approach this? Are there other angles that we need to consider?=

=C2=A0<=
/span>
=E2=80=93=C2=A0
Annabelle Richard Backman
AWS Identity
=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



--00000000000019ae4d059bcc60d4--


From nobody Fri Jan 10 09:58: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 D0DFC12087E for ; Fri, 10 Jan 2020 09:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCT-ZFao4KqY for ; Fri, 10 Jan 2020 09:58:55 -0800 (PST)
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 CE4DF120A52 for ; Fri, 10 Jan 2020 09:58:54 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id d16so2640188wre.10 for ; Fri, 10 Jan 2020 09:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=qImPjs2ig4dwppPO0emAANLysn8e6KWfXF6GmaCEj1o=; b=fJ+1ZUr6Q0p+rHIH9VpAA/J3jLyJw5D23OiGorJmxR16Ojke0IMqJzp9njsynfKvwd n/h+laFD4zEtTYXzcITzsMfZEeX6ffLwMjYRJaBEiGnyTZyoehQa9JXktBpT6Di3zQrE MMXuzcJYkfUV0c4Czy2XXN5DYvHTjFr26xEK5bq9xiRVl9Pd0Vob56NXw6X45af0IinC j5RL2hvWbqYXAXfkz4IMm4LKxN3QCme0L+djaTgolmtCu7fO+EHHnOrvf9gzLTb6jNcB OmKipYepmdqyJ3Q6uO3xolFR8cnYJylEiE35MfZBRFeOt/Tt+MdJBvMm1uck6a/Ev6eD JPQQ==
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=qImPjs2ig4dwppPO0emAANLysn8e6KWfXF6GmaCEj1o=; b=A0rraQ3AkUqe65mizonuoJE3hvjOVnxL2LMOGvYEZIwizLB8lEFI4Ka0DZ9WRdPm1y Kkl9DW4D1MJ6Yrek57f+8/Jkroj37rHKfbAD5MYpUx44xqT63QssPMoc0Zyz9/IBcy+D ER3O1N9g0Fh4ZMZnTnA6lhOo7lYLiwGlhw0OqlFxPeONxRw+Z/QXoY6UYIlqoTpSpwSg b1Qtr1dIRGbzeRSA2DQDhNglYhbfF7ljRE3IGa62sxHgSAxa24f4xeTfssMrYCe1pqqJ ZGvez2ThO5hceTUtExNXCEEL09Tlf4xa0XmeV3BZXmIkpdCYaR9FraZgZvjfekcKkRLm cyrg==
X-Gm-Message-State: APjAAAVi5UQsFpTiW1SPX6WVA4lSWAUTmXq8NhPWrWQZ7PUTqv4w8YCN qyRV/NYmwdZ6LbvkKv7oChL1FA==
X-Google-Smtp-Source: APXvYqybW/nT91zBpelZypQjlqbMS+l3FpmrGmL7sx0iKWij/eQWDPgETK27tH34MFg8nQFDGiaGug==
X-Received: by 2002:adf:9144:: with SMTP id j62mr4564585wrj.168.1578679133287;  Fri, 10 Jan 2020 09:58:53 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id h66sm3217355wme.41.2020.01.10.09.58.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 09:58:52 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 18:58:51 +0100
Message-Id: <5747AA1C-0732-49F3-B18F-EF6395C405C9@lodderstedt.net>
References: 
Cc: Justin Richer , oauth , "Richard Backman, Annabelle" , Mike Jones 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPad Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 17:58:57 -0000

> Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>=20
> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Provi=
der, and the access token is being defined. These extensions have assumed al=
l of this functionality is a monolith.=20
>=20
> I'm not suggesting that we MUST make changes to existing extensions, but d=
esign future extensions so that an implementation can separate duties if des=
ired.

How do you envision this to work? As you said, OAuth 2.0 is built on the ass=
umption the AS is (at least logically) a monolith. All extension were built o=
n that underlying assumption. I don=E2=80=99t see how an arbitrary extension=
 can relax that assumption and still be compatible with the rest (just revis=
it the discussion re PAR and keys).

I think we should accept this design assumption, in the same way we should a=
ccept form encoding as request format instead of JSON, for OAuth 2.0 extensi=
ons.=20

OAuth 3.0 could explicitely be developed with different architectures in min=
d.=


From nobody Fri Jan 10 10: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 11A84120AA4 for ; Fri, 10 Jan 2020 10:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu7hQaBx5dib for ; Fri, 10 Jan 2020 10:09:17 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964C3120A40 for ; Fri, 10 Jan 2020 10:09:16 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id v201so2136839lfa.11 for ; Fri, 10 Jan 2020 10:09:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ADv2eLsUofIvRp3QzLJCQzVXkROoXfK4e1Y+4mELgKs=; b=Fuo3Y0C/IpTRzKDSUx62LEHgvjWb94ZXGiuacvTg+NAMXPf9mhcMfE1/yFHbK99vXC 2wRwdgBBdfj6fA3bhNhYWzE1xjOUSQfPLyjjdXY1rVewTYwnL3WySOwLbXrJfDQv7n96 rgvMTeOFitjpHtk3DgZf+szl/TVyBPyVZWykkKAdh8mTJbOsXNaSypH2+8NBcfUzISy8 K0UEYShDIA0+6YMk87vb9ghp63YIEGYNi2Tu00jZTmYhYa0BeUS9ZevMWfi6e2gk60UW MdiWYhXQNvSVTnVM3/hql/U7BMe5TKwUW9p61Cw7vXc57fRG2et9JbF5Mbz+AemqKIGa tlMA==
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=ADv2eLsUofIvRp3QzLJCQzVXkROoXfK4e1Y+4mELgKs=; b=JtF03S9MeOqdbGGzVU+KnxzPMeyFtTXIv8AoDEfnd6zgA7rewRaNfO44H4LvBwLvZZ h3AS4jgooHQ6SpgEyciYI2IAxdITUrI/pEopPLJI38PWK9hZZJx5CKPyRA4n/RVyIKBb sIYxK2dQk8VlfgzpNEK/wgIIXACfUaxaEzmXU8lupt2giESvYEEKX8hM46oQDUBIJCUF hfneGWaclj/BukoIZEVjSfcI0v4zmDsvjZp1HCZ5820W/wXQsjp+JvXIVsyLQhEsMAgQ RLL/jiToHXdhb0vkguKNbU1EP7g1KtP8EPK/+qT1MdlOf6UJ5x7beqRKD6ozjEO0Afn9 lAUA==
X-Gm-Message-State: APjAAAUE5vcUamqokWKiA3T/95MnyvDPIa89nnmDBR3Jxp3hrBZ0rg0E LK5v4RHHvRMc3lHgLxDlm24Ddt0yDKhR9O8r1HQ=
X-Google-Smtp-Source: APXvYqwcY9g/ah2KeSh61Vd0pFmYl/RhXJYHclje8AHMxsisyEGa9mpQOUC68b0K1t4slrD53KcxDQHa5ihUA7lUHVo=
X-Received: by 2002:ac2:50cc:: with SMTP id h12mr3101741lfm.29.1578679754802;  Fri, 10 Jan 2020 10:09:14 -0800 (PST)
MIME-Version: 1.0
References:  <5747AA1C-0732-49F3-B18F-EF6395C405C9@lodderstedt.net>
In-Reply-To: <5747AA1C-0732-49F3-B18F-EF6395C405C9@lodderstedt.net>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 10:09:03 -0800
Message-ID: 
To: Torsten Lodderstedt 
Cc: Justin Richer , oauth ,  "Richard Backman, Annabelle" ,  Mike Jones 
Content-Type: multipart/alternative; boundary="000000000000ffce97059bcd0519"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:09:19 -0000

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

Perhaps I am misunderstanding what Annabelle was getting at, but having
more than one key in the metadata document would solve the the issue. IE,
extensions would define their own key instead of using the same one.

The metadata document itself was an extension.


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt 
wrote:

>
>
> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
> >
> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
> Provider, and the access token is being defined. These extensions have
> assumed all of this functionality is a monolith.
> >
> > I'm not suggesting that we MUST make changes to existing extensions, bu=
t
> design future extensions so that an implementation can separate duties if
> desired.
>
> How do you envision this to work? As you said, OAuth 2.0 is built on the
> assumption the AS is (at least logically) a monolith. All extension were
> built on that underlying assumption. I don=E2=80=99t see how an arbitrary=
 extension
> can relax that assumption and still be compatible with the rest (just
> revisit the discussion re PAR and keys).
>
> I think we should accept this design assumption, in the same way we shoul=
d
> accept form encoding as request format instead of JSON, for OAuth 2.0
> extensions.
>
> OAuth 3.0 could explicitely be developed with different architectures in
> mind.

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


Perhaps I am misunderstanding what Annabelle was getting a=
t, but having more than one key in the metadata document would solve the th=
e issue. IE, extensions would define their own key instead of using the sam=
e one.

The metadata document itself was an extension.=C2=
=A0


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt=
 <torsten@l=
odderstedt.net> wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still be compatible with the rest (just =
revisit the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions. 



OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.


--000000000000ffce97059bcd0519--


From nobody Fri Jan 10 10:13: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 78155120B27 for ; Fri, 10 Jan 2020 10:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 T5NZi12efbry for ; Fri, 10 Jan 2020 10:13:52 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450: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 C526C120B01 for ; Fri, 10 Jan 2020 10:13:51 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id q9so2985978wmj.5 for ; Fri, 10 Jan 2020 10:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=pdLhrn5gTGC3T9Kx5LpI9MnBjLShakyrkG22taxmDdU=; b=AWi4D8rILTvyruzJ72b58H2CGybI0azc/DrpqykPojMvNLrxPS4oXIWOAYCHsFFt2e X/kNll3IxzFDyHwUwyqdVMooBd9ngoZ/PamcrI0vJa5UqQvg0YH4bZcE11FZyCTBtaTw CPmNibabSBy7h8nTh/vcUT66nY7CbJDopmYQkYZKMr+j5U6TYhySCmi5ZwSm6Uo5BsoO 4f1yFaAY77Qk9T11/RKMZbA2wGRfrEl79VwAQB2ssJVib9KsvQpL51wFHl9/zc4c6dUh 09xl5E8N3hYHAM2Eeo0/Te1ArNVepCAtNCh13R9VJbRS+JeC4GvuRHJKBSmFrxPKGMi0 0M5Q==
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=pdLhrn5gTGC3T9Kx5LpI9MnBjLShakyrkG22taxmDdU=; b=J/s6jURyYYdr6M/P4SZvogtm6QG3ymtzZERBq0qwCNr9F/m04uIIh85kyFBZMEnuNa eDSfZ+XfNi961g1QUzgJi+WNzC/qka0SFYZU58o1qP+LTph6ItIX+9OSkzW4IVmPlNAt Tjh6XaDnqBmpfA2NGqw7Xyg+KuCYfZxNw1VvoW/01mV/rfAtrhP1jLxcNpN1SSuZ1iF0 0i0SVdiIGjNSROcnAFCKoe1iWef055yap2564c/haceUeL+VGKjY/6daF6shSHkmHaAo BzGNP0WEkcq3CRk+R8IZxnrQ9dmhDoyO8sE20VfAtLnUvBfjdAP6rbC/RFUdF31lDWgs Miwg==
X-Gm-Message-State: APjAAAXc6p8oDKmoGeBe05fJYcxbX28qzU3j4BJnRcPT5QNlx/zQgaCV g95MBOPVkhjyWbpQf7+bTaSaUMkDOHLpao+f
X-Google-Smtp-Source: APXvYqwHf9L7Hvu9DyU/VHiUf9Xr9iTQW0eCErD3pZlFHWpz/Nky8WAqM8NGAxuJkkbyZCfGHRHl3A==
X-Received: by 2002:a05:600c:2488:: with SMTP id 8mr5598756wms.152.1578680030379;  Fri, 10 Jan 2020 10:13:50 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id t81sm3034371wmg.6.2020.01.10.10.13.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:13:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 19:13:48 +0100
Message-Id: <8DFAF146-442E-4115-B31C-4BA1AAAABD2C@lodderstedt.net>
References: 
Cc: Justin Richer , IETF oauth WG 
In-Reply-To: 
To: John Bradley 
X-Mailer: iPad Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 18:13:53 -0000

> Am 10.01.2020 um 16:53 schrieb John Bradley :
>=20
> I think Torsten is speculating that is not a feature people use.  =20

I=E2=80=99m still trying to understand the use case for merging signed and u=
nsigned parameters. Nat once explained a use case, where a client uses param=
eters signed by a 3rd party (some =E2=80=9Ecertification authority=E2=80=9C)=
 in combination with transaction-specific parameters. Is this being done in t=
he wild?=20

PS: PAR would work with both modes.=


From nobody Fri Jan 10 10:14: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 9DFA8120B3E for ; Fri, 10 Jan 2020 10:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 XKhOZCBjWAZL for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14226120B01 for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id z7so2668981wrl.13 for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=morHIYDoEvkqmFOLmJDFnavmo9L2olSGIOUk9ZcBbYvLI6bzDih3vwHJDy9xvoxWn1 94jD6GutGh4s9VL333YwEtSzI2eCddm29525i9+MM1TAtGQ6KRUrLhqjdy7qyKBniqmu JvlL4l5xVfRKehQRjTSAPMCoHW7RT/oRVxfjj865/m0RX6iKZ8FCJShc8l5erKTTRbAL oKesku9UZ2SwKIN0gWJpLUXf0m5YVceBR3bPZgqF1hZoFq2XFEpXQPuZ8nhQef2jkTZn zz1bhXRcmgCGrC2JpXJ8eynKZqC+hbSBUuSPlgeTf48gIuqlUoxkKMEM9Jd4NMXF6YDL GZ6g==
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=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=BZ9cHBfTqUabxFT8olDvWo49Pr3kXCd+a4w8jgFN4txaCqGzSBqRn736TbmCxMBWym beQndKTxYs/UOEOaSk3XFM4RSOd8bcUITOEoQA7JX7Vgxet9TOnfHSq27cw4fJqDdxFv CX+bciH6iv8bRK6bEKX94SlaqNPpLtL0uDnnonO333rEC6C9GMsuzOG2vR6MEXjJxypT kH3raODoHrO3ROFPakzHPleeCZC4skFUpKA9FgwIcwLFCgboCcz/Wb4Hib0yJsRvvtZ/ sr2R59pOI2sIiTIDLgsbIcfFGVoT3mhAyAGl0fbVCsuUrthvbkTZ3N9er8Mt7kBBeg4s 8Z7A==
X-Gm-Message-State: APjAAAUYr3XkXc6IYioRkxxQsbS9ZJ+YqZQnmw04Q6K76buu7uQEo41U IOGQb+1+d0cWitTBDDQFd+aCufbEBVJRHMIf
X-Google-Smtp-Source: APXvYqxqsAtDv0/8CA+bthPQ+lUdmtw6Fy4ik4Uv56APZ4Di2PHWx8qLCO7BO0EqVV0isQ6yVhpc0A==
X-Received: by 2002:a5d:49cc:: with SMTP id t12mr4591741wrs.363.1578680081512;  Fri, 10 Jan 2020 10:14:41 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id s8sm2955861wrt.57.2020.01.10.10.14.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:14:40 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 19:14:39 +0100
Message-Id: <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net>
References: 
Cc: Justin Richer , oauth , "Richard Backman, Annabelle" , Mike Jones 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPad Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:14:46 -0000

--Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

You mean additional JWKS URIs, for example?

> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>=20
> =EF=BB=BF
> Perhaps I am misunderstanding what Annabelle was getting at, but having mo=
re than one key in the metadata document would solve the the issue. IE, exte=
nsions would define their own key instead of using the same one.
>=20
> The metadata document itself was an extension.=20
>=20
>=20
>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt  wrote:
>>=20
>>=20
>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>> >=20
>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Pr=
ovider, and the access token is being defined. These extensions have assumed=
 all of this functionality is a monolith.=20
>> >=20
>> > I'm not suggesting that we MUST make changes to existing extensions, bu=
t design future extensions so that an implementation can separate duties if d=
esired.
>>=20
>> How do you envision this to work? As you said, OAuth 2.0 is built on the a=
ssumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary extens=
ion can relax that assumption and still be compatible with the rest (just re=
visit the discussion re PAR and keys).
>>=20
>> I think we should accept this design assumption, in the same way we shoul=
d accept form encoding as request format instead of JSON, for OAuth 2.0 exte=
nsions.=20
>>=20
>> OAuth 3.0 could explicitely be developed with different architectures in m=
ind.

--Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


You mean additional JWKS U=
RIs, for example?

Am 10.=
01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail.com>:

=EF=BB=BF
Perhaps I am misunderstanding what Annabelle was getting at, but ha=
ving more than one key in the metadata document would solve the the issue. I=
E, extensions would define their own key instead of using the same one.
=

The metadata document itself was an extension. 


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=



> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Pr=
ovider, and the access token is being defined. These extensions have assumed=
 all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extensions, bu=
t design future extensions so that an implementation can separate duties if d=
esired.



How do you envision this to work? As you said, OAuth 2.0 is built on the ass=
umption the AS is (at least logically) a monolith. All extension were built o=
n that underlying assumption. I don=E2=80=99t see how an arbitrary extension=
 can relax that assumption and still be compatible with the rest (just revis=
it the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should a=
ccept form encoding as request format instead of JSON, for OAuth 2.0 extensi=
ons. 



OAuth 3.0 could explicitely be developed with different architectures in min=
d.


=

--Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7--


From nobody Fri Jan 10 10:15: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 12069120B27 for ; Fri, 10 Jan 2020 10:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level: 
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 hI-H6Un0VFEV for ; Fri, 10 Jan 2020 10:15:45 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69015120B01 for ; Fri, 10 Jan 2020 10:15:39 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id a13so3047616ljm.10 for ; Fri, 10 Jan 2020 10:15:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SOgatk4uJJoZMaSBkJgcX7OzbjCCLO2roUtOXToR6a4=; b=mIlr0WZymJDPpnmiXkBj96/PoczULt9oWknAikQdTkJi470JbMqEzgOvtdkCDLOIM+ i7zFVPK2vrG9vyV/jjydiU+kSn3eHTp9ay2g8DYg6ivEERIDoiLdBwdH7+uYIl8o8sS2 rp+WU1yT3oyzGPtr5aPl2NtCPNp0zodS2o5az7M3ZGfXjJkvGbNv2lcd4gF2wj7psRJN TmOzOTXiflgB2uHZ2DErEcUqhNSBwrzaHQI00QADa04QXArOfU4WoHE7ngaWTsZmrFQz UFfqTnkfp6zOGhbh0OjNuPuErcpLiuWazRNwQYo/XLYrF1ZrFXhfjkYl4f7Knac2D6ya 7ltg==
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=SOgatk4uJJoZMaSBkJgcX7OzbjCCLO2roUtOXToR6a4=; b=o9NjVOSbFucgnIu2xMXXlOvoXt7T1yjpDgfc1s9kQWzoNusYdGtyZ8+gRrDpcW0Xc7 FqTyCQV/WeGvJdN/ZVEcqAYvPpX9bV89NtqWLrzmlPuaSNRYz2t96qgLw6fR7BdqlRtP p5VSmkTtcrBGqBCai+98oXfMNsxnOAHT0K3Tqc2M0eyu2N/deEPfANWAyViy5mQcTpWf eSNYid9MA5ccWiwWn85ifD6t04OpXyOvVQTq9I90TYHkfr7SlfUkClQ6TtZ3uLijjk9v IsFfPoKmIRXd2De2Jkrv4qZMa82PgjVB9pkT/ry0F5yE1m0f0ASQ7eAF84eu6HYi1eDY BnvA==
X-Gm-Message-State: APjAAAVV2S7gNPyBFBVlU7tzoY0JHzzwIRuJlDXwsWU29Mf00ktALBmS 3qzejVmQK/QkLo02LlzhE5xDXt/ukJIzEOCg5dY=
X-Google-Smtp-Source: APXvYqyvghkBnzHgE0llA8pT8vWCc9v1pagF8o4YbG59zI2zNn5eIxr99ZYzr1Mv06IuhUohtoINcqER6KyVLfCQjnM=
X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr3456649ljk.15.1578680137612;  Fri, 10 Jan 2020 10:15:37 -0800 (PST)
MIME-Version: 1.0
References:  <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net>
In-Reply-To: <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 10:15:26 -0800
Message-ID: 
To: Torsten Lodderstedt 
Cc: Justin Richer , oauth ,  "Richard Backman, Annabelle" ,  Mike Jones 
Content-Type: multipart/alternative; boundary="000000000000d10393059bcd1c34"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:15:50 -0000

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

Yes. Thanks for clarifying.
=E1=90=A7

On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> You mean additional JWKS URIs, for example?
>
> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>
> =EF=BB=BF
> Perhaps I am misunderstanding what Annabelle was getting at, but having
> more than one key in the metadata document would solve the the issue. IE,
> extensions would define their own key instead of using the same one.
>
> The metadata document itself was an extension.
>
>
> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>>
>>
>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>> >
>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
>> Provider, and the access token is being defined. These extensions have
>> assumed all of this functionality is a monolith.
>> >
>> > I'm not suggesting that we MUST make changes to existing extensions,
>> but design future extensions so that an implementation can separate duti=
es
>> if desired.
>>
>> How do you envision this to work? As you said, OAuth 2.0 is built on the
>> assumption the AS is (at least logically) a monolith. All extension were
>> built on that underlying assumption. I don=E2=80=99t see how an arbitrar=
y extension
>> can relax that assumption and still be compatible with the rest (just
>> revisit the discussion re PAR and keys).
>>
>> I think we should accept this design assumption, in the same way we
>> should accept form encoding as request format instead of JSON, for OAuth
>> 2.0 extensions.
>>
>> OAuth 3.0 could explicitely be developed with different architectures in
>> mind.
>
>

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


Yes. Thanks for clarifying.
3D""=E1=90=A7=


=
On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
You mean additional JWKS URIs, for example?
=

Am 10.01.2020 um 19:09 schrieb Dick Hardt <=
;dick.hardt@gmail=
.com>:

=EF=BB=BF
Perhaps I am misunderstanding what Annab=
elle was getting at, but having more than one key in the metadata document =
would solve the the issue. IE, extensions would define their own key instea=
d of using the same one.

The metadata document itself wa=
s an extension.=C2=A0


On Fri, Jan 10, 2020 at 9:58 AM T=
orsten Lodderstedt <torsten@lodderstedt.net> wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still be compatible with the rest (just =
revisit the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions. 



OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.




--000000000000d10393059bcd1c34--


From nobody Fri Jan 10 10:19: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 65B45120804 for ; Fri, 10 Jan 2020 10:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tOhUhd91qUm0 for ; Fri, 10 Jan 2020 10:19:14 -0800 (PST)
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 5F726120B4B for ; Fri, 10 Jan 2020 10:19:14 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id n21so3046194ioo.10 for ; Fri, 10 Jan 2020 10:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9xs576f6d5dqZOxhha+9CBonfOK7hA9mBl3+BUxm+XU=; b=y0GtvGsGBuyfcaxiQSF7GcBaEDy2pu3eulnTsqWnPiX71MWF9c0x6SiPOzJua9Gen5 a9+ltUDTWlelyC+GnHThOwgJx6HGeZp9rKqVeDg6fpScTmgF3p2eH0B5so8dCGbMsJyC ziPQ/LX7Cgj/cu9IZ9+qxCtykkXFq2pM8iE49J/lsfbQcnPd9j077mLA5DltmLkLVQlV ZWvjoBhbE1Z44crulJq/G0KOuds4K0ET12mE14UVxCrJHwIeWpy24xJfi7LunNq1+STG ceAprsKf578Sk4dHsBqj7lJaaG5/bjYdmQBebUqyXtpEwLmZXCSzTy28K17VubDJiv/Z I+9Q==
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=9xs576f6d5dqZOxhha+9CBonfOK7hA9mBl3+BUxm+XU=; b=L/yXamT5SzSYpJ9xfWdptsDRvAR/CMiSfon0GSudiM69h8PoU2HF17lrHeLaXTgYP5 xWBSfyu7lZ8DUuv5PTEN732wXXIK2jreVPX4WdtlTEX28aUClPUTP0I+GR0ENxT2jb7j QAWCJEJaqYTQJ3QKuEhkxRhTQa3mztfoKC234pL1u05bDwv50WSZc2Y66urDtlf60Q25 arNd/JH2Dp062yDGKorwm0zRtUUCdXJZ7b7Ws23UlGG5JLXGknl4turfewwldlje7GJK THXbtn27MrhdlGF6rVFNIu0BHRYzlb7BVUlfTuhyRHq9kbyVa1ZhJGZ8vs0T/CUM9sy6 4QnQ==
X-Gm-Message-State: APjAAAXPMYLtBBGkFfCFVthjX4BlsRS00XbLu3b+a8sRXdSsjFMIxSa3 FQEqHo53Q+Hn1mLfSzHMDEYfr/DL8uE=
X-Google-Smtp-Source: APXvYqy0nw3CFxoVNW6fklzZMQogcGcG3X49K5FaoGo8Z/hJ93S0Y0zDRIUUNGwEVDGb0wqLP/Hq5w==
X-Received: by 2002:a5d:8cc4:: with SMTP id k4mr3592825iot.2.1578680353446; Fri, 10 Jan 2020 10:19:13 -0800 (PST)
Received: from mail-il1-f176.google.com (mail-il1-f176.google.com. [209.85.166.176]) by smtp.gmail.com with ESMTPSA id z24sm897488ilf.31.2020.01.10.10.19.12 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:19:12 -0800 (PST)
Received: by mail-il1-f176.google.com with SMTP id z12so2467575iln.11 for ; Fri, 10 Jan 2020 10:19:12 -0800 (PST)
X-Received: by 2002:a92:bbc1:: with SMTP id x62mr3539739ilk.156.1578680352691;  Fri, 10 Jan 2020 10:19:12 -0800 (PST)
MIME-Version: 1.0
References:  <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net> 
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 10 Jan 2020 12:19:01 -0600
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dick Hardt 
Cc: Mike Jones ,  "Richard Backman, Annabelle" ,  Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000a2dc83059bcd29d8"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:19:16 -0000

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

Can the keys in the document at the jwks_uri indicate what they are for?
Either by adding other top-level properties next to "keys" or by specifying
a property on a key itself? At least that way implementations that expect
just one value of jwks_uri wouldn't have to change.

Aaron



On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:

> Yes. Thanks for clarifying.
> =E1=90=A7
>
> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> You mean additional JWKS URIs, for example?
>>
>> Am 10.01.2020 um 19:09 schrieb Dick Hardt > >:
>>
>> =EF=BB=BF
>> Perhaps I am misunderstanding what Annabelle was getting at, but having
>> more than one key in the metadata document would solve the the issue. IE=
,
>> extensions would define their own key instead of using the same one.
>>
>> The metadata document itself was an extension.
>>
>>
>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>
>>>
>>>
>>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>>> >
>>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
>>> Provider, and the access token is being defined. These extensions have
>>> assumed all of this functionality is a monolith.
>>> >
>>> > I'm not suggesting that we MUST make changes to existing extensions,
>>> but design future extensions so that an implementation can separate dut=
ies
>>> if desired.
>>>
>>> How do you envision this to work? As you said, OAuth 2.0 is built on th=
e
>>> assumption the AS is (at least logically) a monolith. All extension wer=
e
>>> built on that underlying assumption. I don=E2=80=99t see how an arbitra=
ry extension
>>> can relax that assumption and still be compatible with the rest (just
>>> revisit the discussion re PAR and keys).
>>>
>>> I think we should accept this design assumption, in the same way we
>>> should accept form encoding as request format instead of JSON, for OAut=
h
>>> 2.0 extensions.
>>>
>>> OAuth 3.0 could explicitely be developed with different architectures i=
n
>>> mind.
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
----
Aaron Parecki
aaronparecki.com
@aaronpk 

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


Can the keys in the document at the jwks_uri indicat=
e what they are for? Either by adding other top-level properties next to &q=
uot;keys" or by specifying a property on a key itself? At least that w=
ay implementations that expect just one value of jwks_uri wouldn't have=
 to change.

Aaron<=
/div>



On Fri, Jan 10,=
 2020 at 12:16 PM Dick Hardt <di=
ck.hardt@gmail.com> wrote:
<=
div dir=3D"ltr">Yes. Thanks for clarifying.
3D""=E1=90=A7<=
/div>
On Fri, Jan 10, 2020 at 10:14 AM Torsten Lo=
dderstedt <=
torsten@lodderstedt.net> wrote:
You mean addition=
al JWKS URIs, for example?

Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com>:

=EF=BB=BF
Perhaps I am misunderstanding what Annabelle was getting at, but h=
aving more than one key in the metadata document would solve the the issue.=
 IE, extensions would define their own key instead of using the same one.
The metadata document itself was an extension.=C2=A0


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderste=
dt.net> wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still be compatible with the rest (just =
revisit the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions. 



OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
----
Aaron Parecki
<=
div>aaronparecki.com<=
/a>



--000000000000a2dc83059bcd29d8--


From nobody Fri Jan 10 10:27: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 A728A120B13 for ; Fri, 10 Jan 2020 10:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Xpc63XMYzWPY for ; Fri, 10 Jan 2020 10:27:27 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987FC120B62 for ; Fri, 10 Jan 2020 10:27:04 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id p17so2988446wmb.0 for ; Fri, 10 Jan 2020 10:27:04 -0800 (PST)
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=1QuCZEqiA9+8uhRWnvtl8xj/voePE8gQze+E0XhsWPE=; b=AGEZM7zHcHzDeosKVtP920mnFbCEuOc0fuVFBDeX/THhzXHGySlHY0AVgVPcAflIBG ZrCfX4MBdIZ8YiFB+1JtED0Z5p9EZsBEFPCNN4L9iazN522iw/WX2fHr7Te/U3/2sND2 IW32DkCZ+RJ7mbzHrDzc+Wi84Vz8AV0RaC55Y=
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=1QuCZEqiA9+8uhRWnvtl8xj/voePE8gQze+E0XhsWPE=; b=GlCUipzfQEFeZetQyGz5CYmIILgG2YKXE5BA4v2832Vq/tKEw358YrQYXqpGpmVAyA J0znrXGo67WLyTIVvJ0/PGixL4o2TkhPgy1kJoIFDUQwUgitTrGU+TlDpOXevrOTAIa9 zAHkEGsVKAqKTSP/1xvGFekW2mBBRAlbaPmmLE529mdBEbAgbwPu52Ccu/DKTKkItE5Q w+RMFFjvfN7w+eGzNnJrw8C7OO8iljrgbpaGLksdsAJLInWfirl9HCzjYoC5ddf/f0a2 6t/e+JNJbRUQzopx0SQ4/ZIGIU7wX5JQkimjLk1j4hOPYB+35jrLsXShnrZ+X8Uj/6DX avVg==
X-Gm-Message-State: APjAAAWv6Ehesux3iEwAn5GoCV3MLJb4aCdhV2aDwjLzYncwka2dU9V9 JsnNN1va9WkA9+jmWUWgHhYBEw==
X-Google-Smtp-Source: APXvYqzvNlTBU+9WjOpYD4K9ZS0bS+smesyPpxmD7zC99JjeUR1zNJb6URlqncdpr40OtpREhrR6PQ==
X-Received: by 2002:a05:600c:246:: with SMTP id 6mr5953199wmj.122.1578680819893;  Fri, 10 Jan 2020 10:26:59 -0800 (PST)
Received: from ?IPv6:2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1? ([2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1]) by smtp.gmail.com with ESMTPSA id e12sm3168069wrn.56.2020.01.10.10.26.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:26:59 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-0F06A7BC-6AE7-402A-B5EB-09DDF4F3B734
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 18:26:58 +0000
Message-Id: <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com>
References: 
Cc: Dick Hardt , oauth , Mike Jones , "Richard Backman, Annabelle" 
In-Reply-To: 
To: Aaron Parecki 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:27:39 -0000

--Apple-Mail-0F06A7BC-6AE7-402A-B5EB-09DDF4F3B734
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

The problem with specifying a property on the key itself is that a microserv=
ice might lie about what it=E2=80=99s keys are for. I think you either need s=
eparate documents or some separate metadata mapping uses to key ids.=20

=E2=80=94 Neil

> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>=20
> =EF=BB=BF!
> Can the keys in the document at the jwks_uri indicate what they are for? E=
ither by adding other top-level properties next to "keys" or by specifying a=
 property on a key itself? At least that way implementations that expect jus=
t one value of jwks_uri wouldn't have to change.
>=20
> Aaron
>=20
>=20
>=20
>> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:=

>> Yes. Thanks for clarifying.
>> =E1=90=A7
>>=20
>>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt  wrote:
>>> You mean additional JWKS URIs, for example?
>>>=20
>>>>> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>>>>>=20
>>>> =EF=BB=BF
>>>> Perhaps I am misunderstanding what Annabelle was getting at, but having=
 more than one key in the metadata document would solve the the issue. IE, e=
xtensions would define their own key instead of using the same one.
>>>>=20
>>>> The metadata document itself was an extension.=20
>>>>=20
>>>>=20
>>>>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt  wrote:
>>>>>=20
>>>>>=20
>>>>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>>>>> >=20
>>>>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect=
 Provider, and the access token is being defined. These extensions have assu=
med all of this functionality is a monolith.=20
>>>>> >=20
>>>>> > I'm not suggesting that we MUST make changes to existing extensions,=
 but design future extensions so that an implementation can separate duties i=
f desired.
>>>>>=20
>>>>> How do you envision this to work? As you said, OAuth 2.0 is built on t=
he assumption the AS is (at least logically) a monolith. All extension were b=
uilt on that underlying assumption. I don=E2=80=99t see how an arbitrary ext=
ension can relax that assumption and still be compatible with the rest (just=
 revisit the discussion re PAR and keys).
>>>>>=20
>>>>> I think we should accept this design assumption, in the same way we sh=
ould accept form encoding as request format instead of JSON, for OAuth 2.0 e=
xtensions.=20
>>>>>=20
>>>>> OAuth 3.0 could explicitely be developed with different architectures i=
n mind.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> --=20
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-0F06A7BC-6AE7-402A-B5EB-09DDF4F3B734
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The problem with specifyin=
g a property on the key itself is that a microservice might lie about what i=
t=E2=80=99s keys are for. I think you either need separate documents or some=
 separate metadata mapping uses to key ids. 

=

=E2=80=94 Neil

On 10 Jan 2020, at 18:19, Aaron Parecki <aaron@parecki.com&g=
t; wrote:

=EF=BB=BF!
Can the keys in the document at the jwks=
_uri indicate what they are for? Either by adding other top-level properties=
 next to "keys" or by specifying a property on a key itself? At least that w=
ay implementations that expect just one value of jwks_uri wouldn't have to c=
hange.

Aaron
<=
div dir=3D"auto">


On Fri, Jan 10, 2020 at 1=
2:16 PM Dick Hardt <dick.hardt@gm=
ail.com> wrote:
Yes. Thanks for clarifying.
3D""=E1=90=A7=


On Fri, Jan 10, 2020 at 10:14 AM Tors=
ten Lodderstedt <torsten@lodderstedt.net> wrote:
You mean additi=
onal JWKS URIs, for example?

Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com>:

=EF=BB=BF
Perhaps I am misunderstanding what Annabelle was getting at, but havin=
g more than one key in the metadata document would solve the the issue. IE, e=
xtensions would define their own key instead of using the same one.

=

The metadata document itself was an extension. 

On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderstedt.net&=
gt; wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Pr=
ovider, and the access token is being defined. These extensions have assumed=
 all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extensions, bu=
t design future extensions so that an implementation can separate duties if d=
esired.



How do you envision this to work? As you said, OAuth 2.0 is built on the ass=
umption the AS is (at least logically) a monolith. All extension were built o=
n that underlying assumption. I don=E2=80=99t see how an arbitrary extension=
 can relax that assumption and still be compatible with the rest (just revis=
it the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should a=
ccept form encoding as request format instead of JSON, for OAuth 2.0 extensi=
ons. 



OAuth 3.0 could explicitely be developed with different architectures in min=
d.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
----
Aaron Parecki
aaronparecki.com=



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

--Apple-Mail-0F06A7BC-6AE7-402A-B5EB-09DDF4F3B734--


From nobody Fri Jan 10 10:30: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 D4499120B45 for ; Fri, 10 Jan 2020 10:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 NpXv9ShI8j0J for ; Fri, 10 Jan 2020 10:30:08 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18E0120B51 for ; Fri, 10 Jan 2020 10:30:07 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id z3so2748809wru.3 for ; Fri, 10 Jan 2020 10:30:07 -0800 (PST)
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=HrKyMZAKQfwqpfrO5pzrUQw1hYLhbRWKy7Y/EWTg/GM=; b=YbbbjMZJ13nFWexi+rAbn0swTtpwF5jNccFcjxXoasemExtSVcu1Yob3pey1iaZ+Y5 i2/VrNXMkCeNDXr+WYGbzdMvpD8t8ECTlrUkFVSs4vffjsVeXuaMj5rBxvbBE09uhf05 2F1ONjb+h5wLnXJpM1DWOc3w3T0pvUp8MWJVo=
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=HrKyMZAKQfwqpfrO5pzrUQw1hYLhbRWKy7Y/EWTg/GM=; b=SRD1El4VCw7/fYyqL4vrUT/M7JKUznZGNVEJuGs/+c92fv4FiFif0HiZJNxKgMVZgY 7No7dVUJfZxoDBv7nlEQyn1jtJj2dXdeBnY6KhlM4sPwhttHc0eFgk5h8wkBPy4ljway OZTkfwQEsPRZKCdWM9XaII6TQMOJJjW5tfPNJxIPUbmJQwNff6m5Bbb6DRt0S+AFRcA6 Ta0VzEMa2gmLMKECVOjOeqSiuNaei8vSOJ/vGCzchVHRDYlgBNt725IT2dZXgVD80ApU Pz3m6xmc6ysBBOiE5B6THQPNG3814frsNUZKgZeCulsXY4Gv03jAqqQrFEjX0ywJBSFR Ii6g==
X-Gm-Message-State: APjAAAUlj8Kvmrk5LaahzuPQHrHqKEVS7A8/xSfdCHee2S+QJ5saciiD N/X4UL2G9ZxaYThVK8h2Lg+yoA==
X-Google-Smtp-Source: APXvYqxHqRC1ZtCb5hYa/0HTW4OVLuHTQcnIYleOEHlrCMELZiW91Kcs14km0Agv0aTEiGCNvQPhtQ==
X-Received: by 2002:a5d:4602:: with SMTP id t2mr4765331wrq.37.1578681006322; Fri, 10 Jan 2020 10:30:06 -0800 (PST)
Received: from ?IPv6:2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1? ([2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1]) by smtp.gmail.com with ESMTPSA id s65sm3170086wmf.48.2020.01.10.10.30.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:30:05 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 18:30:04 +0000
Message-Id: 
References: 
Cc: Justin Richer , oauth , Mike Jones , "Richard Backman, Annabelle" 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:30:10 -0000

> On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
[...]
>=20
> =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, anot=
her goal would be increased resiliency of the components. If the JWT-decrypt=
ion-microservice is unavailable, the whole system is unavailable. If there a=
re separate keys, then a failure in one component does not fail the entire s=
ystem.=20

Well you can run more than one instance - it=E2=80=99s a completely stateles=
s service. You can also run a separate instance (or set of instances) per ke=
y if you like.=20

Neil=


From nobody Fri Jan 10 10:45: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 D888C120B09 for ; Fri, 10 Jan 2020 10:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 vXqk59IvTMRB for ; Fri, 10 Jan 2020 10:45:38 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F37120AE3 for ; Fri, 10 Jan 2020 10:45:37 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id y1so2228300lfb.6 for ; Fri, 10 Jan 2020 10:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b3Jivu8Lf4p5BG9y/MPULNjRwcb93oymoudr0xvKA4k=; b=LNfKCqABYGx0URc0D/ZTEJ861kKrghfA6z/y/iKPnLxnzR+raesifojLOtvFduN13C rOF531ds4GxhtCT2X6UXL4Jj/ivSIDHumB2tZUNa3yTb5sivMdmm4ISLP+Fmotq4WTZ1 RPdcY17uPjEuC+IKhNDhyBDPsua4ue9gvopKK2eeYBb/+8ivLNIB+OZqwKOxK+FlJqC2 ZlpUepkDR3nFBfADA0DjPsRorxA/azq87jOXhyHc72h5OoWpOEKdREmQhhyjBGKwSih9 Qt/ZSNKVDJxEqZs5p+TxXXq7LiY6Q7twERFp4uF9nTd3TdgP9SXOy2a5bl48AxvJrNp6 YwJQ==
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=b3Jivu8Lf4p5BG9y/MPULNjRwcb93oymoudr0xvKA4k=; b=K92tEkjYS2+YBgTcZK45xwWSVNoxd2uzXZgi2ejWOsH+flcrBx/p0XgFF524b0kDze zebFCVtRUjpkl2d4KYtfaRYSJ8Vi31OMurx0fNoBRFD8c840I1mRK8Oy2A/B/7SzC9IU grwfjBXkITuBsxttIjrkbp1YAWImbaHWjQnFCtjXDmMQeGNdI6dtES0BQgg4IH7F0Fbl zi2QDG5yR0HlGxV45vkUChK41zQftxy0M0fmOab5TB8OrAB2V1dXBmOv+Y/fNOViiClX i9aA7hrJhjnhps0IFZIzc4SbhimYRceg6vnAQeW9XkemBjdswQ92jJ5TiPvC6r8oXe53 3aww==
X-Gm-Message-State: APjAAAVXza0hlswWyxoTmVcY/myGTsjo2RyDhnOPU5QNAcCaHmoupUzc feXAFfR/548cAuPeLwoiRm4Nvf2dUDQyh5TPPScnf44on5bBGpAfn6nvjZa5R+MUlAUHMSCwgHw drFCNYnj/Rho7DA==
X-Google-Smtp-Source: APXvYqwNyvXql7eY2IJA0PANy1HH+5cdh4ha41NKHtsasvGVkZoJgDJ5wZyHmm1f1v4SyxV1LsUbXXRapksTqcsj2+s=
X-Received: by 2002:ac2:4d04:: with SMTP id r4mr3264236lfi.77.1578681935222; Fri, 10 Jan 2020 10:45:35 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
In-Reply-To: <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>
From: Brian Campbell 
Date: Fri, 10 Jan 2020 11:45:08 -0700
Message-ID: 
To: Torsten Lodderstedt ,  Nat Sakimura , John Bradley 
Cc: "Richard Backman, Annabelle" , oauth 
Content-Type: multipart/alternative; boundary="000000000000f66ed7059bcd8730"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:45:42 -0000

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

Agree and agree. But given that the change suggested by Annabelle has no
impact on the client or interoperability, perhaps Nat or John could work
the change into the draft during the edits that happen during the final
stages of things?

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  wrote:

> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> =EF=BB=BF
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
>
>
> What if we changed this sentence in Section 5.2 of JAR:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object.
>
>
>
> To:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object, unless the URI was provided to the client by the Authorization
>
> Server.
>
>
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
> =EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>
>
>     Hi,
>
>
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>
>
>     "There is no need to make the
>
>           authorization request data available to other parties via this
>
>           URI.=E2=80=9D
>
>
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>
>
>     best regards,
>
>     Torsten.
>
>
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>
>     >
>
>     > Hi all,
>
>     >
>
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>
>     >
>
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>
>     >
>
>     > =E2=80=93
>
>     > Annabelle Richard Backman
>
>     > AWS Identity
>
>     >
>
>     > _______________________________________________
>
>     > OAuth mailing list
>
>     > OAuth@ietf.org
>
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_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._

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


Agree and agree. But given that the change suggested =
by Annabelle has no impact on the client or interoperability, perhaps Nat o=
r John could work the change into the draft during the edits that happen du=
ring the final stages of things? 

<=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 9, 2020 at 1:56 AM Torsten=
 Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the status of JAR, we don=E2=80=99t want=
 to change it. And as I said, this difference does not impact interoperabil=
ity from client perspective.

Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richann=
a=3D40amaz=
on.com@dmarc.ietf.org>:

=EF=BB=BF









It would be more appropriate to add the text to JAR rather than PAR. It =
doesn't seem right for PAR to retcon rules in JAR. Moving the text to J=
AR also highlights the weirdness of giving PAR special treatment.=



=C2=A0


What if we changed this sentence in Section 5.2 of JAR:

The contents of the resource referenced by the URI MUST be a Reques=
t


Object.


=C2=A0


To: 


The contents of the resource referenced by the URI MUST be a Reques=
t


Object, unless the URI was provided to the client by the Authorizat=
ion


Server.


=C2=A0


This would allow for use cases such as an AS that provides pre-defined r=
equest URIs, or vends request URIs via a client management console, or bake=
s them into their client apps.


=C2=A0


=E2=80=93 


Annabelle Richard Backman


AWS Identity




=C2=A0


=EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
=3D40=
lodderstedt.net@dmarc.ietf.org> wrote:


=C2=A0


=C2=A0=C2=A0=C2=A0 Hi, 


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


=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the AS to re=
present the request as a JWT-based request object. The URI is used as inter=
nal reference only. That why the draft states



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


=C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization req=
uest data available to other parties via this


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D<=
/u>


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


=C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementatio=
n perspective, it doesn't matter from a client's (interop) perspect=
ive.


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


=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that reques=
t_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.



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


=C2=A0=C2=A0=C2=A0=C2=A0best regards,


=C2=A0=C2=A0=C2=A0 Torsten.=C2=A0 


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


=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:


=C2=A0=C2=A0=C2=A0 > 


=C2=A0=C2=A0=C2=A0=C2=A0> Hi all,


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR (-2=
0) require that the AS transform all pushed requests into JWTs. This requir=
ement arises from the following:


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 PAR uses the request_uri parameter defined in JAR to communicate the=
 pushed request to the authorization endpoint.


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 According to JAR, the resource referenced by request_uri MUST be a R=
equest Object. (Section 5.2)


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 Request Object is defined to be a JWT containing all the authorizati=
on request parameters. (Section 2.1)


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement to su=
pport interoperability, as this is internal to the AS. It is also inconsist=
ent with the rest of JAR, which avoids attempting to define the internal co=
mmunications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the st=
ate or outcome of that work must be forced into the JWT format (or retrieve=
d via a subsequent service call
 or database lookup).


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93 


=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman


=C2=A0=C2=A0=C2=A0 > AWS Identity


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> ___________________________________________=
____


=C2=A0=C2=A0=C2=A0 > OAuth mailing list


=C2=A0=C2=A0=C2=A0 > OAuth@ietf.org


=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/listinfo/oauth


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


=C2=A0=C2=A0=C2=A0=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.
--000000000000f66ed7059bcd8730--


From nobody Fri Jan 10 10:50: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 E7A021200B5 for ; Fri, 10 Jan 2020 10:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNtv_RdhSkFx for ; Fri, 10 Jan 2020 10:50:48 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09CC1200DB for ; Fri, 10 Jan 2020 10:50:44 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id a13so3144019ljm.10 for ; Fri, 10 Jan 2020 10:50:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lWi/G6RTBSfBq2zRGsMF4LcmqT2n2lqWYlbmD+Rmh1c=; b=eSBZvbwi2mz16bG6dRL05g5EWhcpzmsO2OUUHTTpeVNqrE6Wb5Vx36JU0wulxdzuFf OaUrGFu4uHVp034vBg+85/Wutz1PIQ74NTa8JQFb6iD0BbNpzb2v4Wz2A9hdOQEDCmhQ dgas5ym9j2GOatDEQa8QWHFHDjOI2AKg/36d6hkdXZyQuTMxhRw87v/+03OhoRrSE4qD q9+FeQTQEv94jk0Cg1S+TrC9+XzxkRTO77KCoHZ6go5YH4M5DNs44KD9rsPAJ3hi9I5S aUlFUQiUbx69sMcKTZU1GfGeiDeWeo9McCRDjCh4XFQTscMofxa2YyXtTJLs3ePygKmZ 45Rw==
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=lWi/G6RTBSfBq2zRGsMF4LcmqT2n2lqWYlbmD+Rmh1c=; b=TzzDse2nR+StvrBN5L47OlqiobgkDzuKpLeb7XisQYwaPuyr0BXfsM05qdhcGLAVtT IPQsuekXz/9MrzKKfVxdDA22XS3JlE2058pLUt7f000d8Cic1KaI/Oejb0wdFrd/fyN4 aLG9G+lfpqJvf5NBFbvmkhpYBvZ6dLy09MbQhnku41eaHnBPqRbXUMhV9War4fJ6CJ4F Dv/2NtBwNYUCCdpIgY50WX4ObDpHc9wMzGeTM6d6FrxsSM8NCJ2hwQmtMwOq3e272tL6 VAi6yBvU8De1uYs9FCTyAkC9hRSaHMPDEC87/skIVzCxX1K/OQjUamAZvkBH/7CBrPMg 971w==
X-Gm-Message-State: APjAAAWzjXw8Y3vSjWfbJrX3efWA0leZnyM6HKQDrhphzrUW5mbfnZ01 X5NoLaA0GDYQbiKR31a6mHY7uIEfPotr/IHKY6s=
X-Google-Smtp-Source: APXvYqzTSywz6ReYV9WmvWYzb+plApMWUFdEAAuD0WRymm5MJdQyuOEQy3JqmRjB9cDLPmIIgyVb4iVP7zty6HxwOAo=
X-Received: by 2002:a2e:7505:: with SMTP id q5mr3527092ljc.7.1578682242494; Fri, 10 Jan 2020 10:50:42 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jan 2020 10:50:31 -0800
Message-ID: 
To: Neil Madden 
Cc: Justin Richer , oauth ,  Mike Jones ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="00000000000046f793059bcd9afd"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:50:50 -0000

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

There are many other factors to resiliency than multiple instances.

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
wrote:

>
>
> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
> [...]
> >
> > =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, a=
nother
> goal would be increased resiliency of the components. If the
> JWT-decryption-microservice is unavailable, the whole system is
> unavailable. If there are separate keys, then a failure in one component
> does not fail the entire system.
>
> Well you can run more than one instance - it=E2=80=99s a completely state=
less
> service. You can also run a separate instance (or set of instances) per k=
ey
> if you like.
>
> Neil

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


There are many other factors to resiliency than multiple i=
nstances.=C2=A0

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <neil.madden@forgerock.com> wrote:=





> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com> wrote:

[...]

> 

> =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, =
another goal would be increased resiliency of the components. If the JWT-de=
cryption-microservice is unavailable, the whole system is unavailable. If t=
here are separate keys, then a failure in one component does not fail the e=
ntire system. 



Well you can run more than one instance - it=E2=80=99s a completely statele=
ss service. You can also run a separate instance (or set of instances) per =
key if you like. 



Neil


--00000000000046f793059bcd9afd--


From nobody Fri Jan 10 10:54: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 85EBA120B0D for ; Fri, 10 Jan 2020 10:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZGRQdGW0DNp for ; Fri, 10 Jan 2020 10:54:00 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5BD120AC4 for ; Fri, 10 Jan 2020 10:53:06 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id r19so3190779ljg.3 for ; Fri, 10 Jan 2020 10:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=12dnOwH5L8o3ijlT5ZjusF3pDdLwoU2XmYvLm0K4gmI=; b=Hp+BMQFPay9b9LVmyDhE7zY/gyARcm1vP2ftf127aD0wHI7Rn1vfXhI+l84mqPPINX voeCBZD0EtXG9ZeM24GOthZ4YeSwxR/UxCOeBrTo9C393Zd9XwXo59VnfebSChw41RmQ xzRgfT0GYMOhvrgV2gd7uPmGYIC2HAT3vxBDsP5pFKmo/r4SWOStrNCmz6vsNeg1tVqL Q4q6uw3/q49y4q4HzHsSgCqOgetgGH5wZZAPVnQCBvq6uo9XRsz010e3NaJS7bcj/kod /v50eQpX4/OZ5S9HJfpeOQomn4CyA+SkIvJrb2fzVRhjerW2L1nHCZ7QIYMGCEHTW1w4 Btxw==
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=12dnOwH5L8o3ijlT5ZjusF3pDdLwoU2XmYvLm0K4gmI=; b=fRKat4UXN+m5mi59Z0C9nyrTz6jphxHZR8VYsJra+8XF2AesU610gTee9lhQiexPZP KeDfBF+XGm8XRtZJdpORYfzWwt9DoHn2+KhgehiJ3Knbcic6CbCbgAYKd0otktK63bqK HRNRS7a89pfj8wt6mecjGuhv6G+y/PVeF+FI2bW0ZeUIIaq6vmbBaRGoSyg2DOr5kPoW OCxWpTk5KytPGf0QxWO0skRKMYPZdnGfoSoYWyCC3VCff6YMQoBvOaD5zFfMxyAA+ytr k0UwCM3ed3wIqn4k3kZTwezd1/I4xjsCD9MbPUHplOtmG1lLWoKxjJZAY+ZckpN5NqsA 3kqA==
X-Gm-Message-State: APjAAAWhae1VC06ns05t4xYedUG4SfFmOBTXg3lI+MIxzc8UhWPCxBY+ +IsVc8MwBnl0NIHtkVb/42uD6YxfFyTA7YxtKqU=
X-Google-Smtp-Source: APXvYqzocoVdoS67RnpDNH74IyI9p2jwPnyxWBBDGPtYcklhjzDF4XHu0Zo1hzzyJ114axhoAxELYXBpXM6G0sYG40E=
X-Received: by 2002:a2e:a404:: with SMTP id p4mr3523126ljn.234.1578682383813;  Fri, 10 Jan 2020 10:53:03 -0800 (PST)
MIME-Version: 1.0
References:  <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com>
In-Reply-To: <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 10:52:52 -0800
Message-ID: 
To: Neil Madden 
Cc: Aaron Parecki , oauth ,  Mike Jones ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="000000000000b3528e059bcda2e2"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:54:09 -0000

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

The metadata document is declarative, and can easily be yet another
separate role in the AS.

In large organizations, different people are empowered different roles, so
the team owning the metadata document could be different from the team
generating ID tokens, and different from the team generating JWTs.


On Fri, Jan 10, 2020 at 10:27 AM Neil Madden 
wrote:

> The problem with specifying a property on the key itself is that a
> microservice might lie about what it=E2=80=99s keys are for. I think you =
either
> need separate documents or some separate metadata mapping uses to key ids=
.
>
> =E2=80=94 Neil
>
> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>
> =EF=BB=BF!
> Can the keys in the document at the jwks_uri indicate what they are for?
> Either by adding other top-level properties next to "keys" or by specifyi=
ng
> a property on a key itself? At least that way implementations that expect
> just one value of jwks_uri wouldn't have to change.
>
> Aaron
>
>
>
> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:
>
>> Yes. Thanks for clarifying.
>> =E1=90=A7
>>
>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>>
>>> You mean additional JWKS URIs, for example?
>>>
>>> Am 10.01.2020 um 19:09 schrieb Dick Hardt >> >:
>>>
>>> =EF=BB=BF
>>> Perhaps I am misunderstanding what Annabelle was getting at, but having
>>> more than one key in the metadata document would solve the the issue. I=
E,
>>> extensions would define their own key instead of using the same one.
>>>
>>> The metadata document itself was an extension.
>>>
>>>
>>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>>
>>>>
>>>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>>>> >
>>>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
>>>> Provider, and the access token is being defined. These extensions have
>>>> assumed all of this functionality is a monolith.
>>>> >
>>>> > I'm not suggesting that we MUST make changes to existing extensions,
>>>> but design future extensions so that an implementation can separate du=
ties
>>>> if desired.
>>>>
>>>> How do you envision this to work? As you said, OAuth 2.0 is built on
>>>> the assumption the AS is (at least logically) a monolith. All extensio=
n
>>>> were built on that underlying assumption. I don=E2=80=99t see how an a=
rbitrary
>>>> extension can relax that assumption and still be compatible with the r=
est
>>>> (just revisit the discussion re PAR and keys).
>>>>
>>>> I think we should accept this design assumption, in the same way we
>>>> should accept form encoding as request format instead of JSON, for OAu=
th
>>>> 2.0 extensions.
>>>>
>>>> OAuth 3.0 could explicitely be developed with different architectures
>>>> in mind.
>>>
>>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


The metadata document is declarative, and can easily be ye=
t another separate=C2=A0role in the AS.=C2=A0

In large o=
rganizations, different people are empowered different roles, so the team o=
wning the metadata document could be different=C2=A0from the team generatin=
g ID tokens, and different from the team generating JWTs.


On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <neil.madden@forgerock.com> wrote:
The problem with specifying a property on the key itself is that a=
 microservice might lie about what it=E2=80=99s keys are for. I think you e=
ither need separate documents or some separate metadata mapping uses to key=
 ids.=C2=A0

=E2=80=94 Neil=


On 10 Jan 2020, at 18:=
19, Aaron Parecki <aaron@parecki.com> wrote:

=EF=BB=BF!
Can the keys =
in the document at the jwks_uri indicate what they are for? Either by addin=
g other top-level properties next to "keys" or by specifying a pr=
operty on a key itself? At least that way implementations that expect just =
one value of jwks_uri wouldn't have to change.

Aaron



On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <dick.hardt@gmail.com=
> wrote:
=

Yes. Thanks for clarifying.
3D""=E1=90=
=A7

On Fri, Jan 10, 2020 at 10:14 AM=
 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
You m=
ean additional JWKS URIs, for example?

Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com>:=


=EF=
=BB=BF
Perhaps I am misunderstanding what Annabelle was get=
ting at, but having more than one key in the metadata document would solve =
the the issue. IE, extensions would define their own key instead of using t=
he same one.

The metadata document itself was an extensi=
on.=C2=A0


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodde=
rstedt <tor=
sten@lodderstedt.net> wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still be compatible with the rest (just =
revisit the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions. 



OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
----
Aaron =
Parecki


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


--000000000000b3528e059bcda2e2--


From nobody Fri Jan 10 10: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 ADC5C120BE5 for ; Fri, 10 Jan 2020 10:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po8mgixHM7jq for ; Fri, 10 Jan 2020 10:59:27 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756EB120B69 for ; Fri, 10 Jan 2020 10:59:24 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id l18so2278548lfc.1 for ; Fri, 10 Jan 2020 10:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MT4vhvtE85iiNEhej0010sy5BdZ9Fst26qFk4aiagwY=; b=lNqPLDnI2ROG5ZAoCl+x+1Bknisn2hF3+9bHlq482mB6suWOJFLIs4TME4+fxe0jua ml5F2KmHjch6g4NJuEF0MDtv0WHvb2UT+8k3xHP5pB35BtLEaqqQIkMXs8mhINMfk7qr QSZo++V4MXLts2drgtwz2eq1ZE5rgmMC4eqhl7uBV69d/ufVXXLt76h1RT4lpwpa/tXF G28JWTTNoBkMMcxOjI0EmGc2DJ+qFxBT9jPgPlhSyg0WY5XI1mjZO/Is5cIFer5N12Dn Pf/TyLXcL/OkU4BvDCbh7HTU9SdCgOIhH6W9ZGhLD06DbJGvZmd5o+pOBqwLB08s1GPg GY/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=MT4vhvtE85iiNEhej0010sy5BdZ9Fst26qFk4aiagwY=; b=LqJD42vMDfRGKz/TytwRrlvO4ixUnU+wXt5ofVVlpFxue0TfFDdWbrRjQPk3BJDM5r cdjEbHrVIl9w9AdV32OA440T8qrR29Hwy2yDo75RyyLw+SGZ60nu3+ShK23WHfOuKFFz 7r6uDx15xiyCxcgPE7aCBAZXpy/cZYeWS8yvkqz+gUKpd0Vd3aUYPxyZv9Rn6rhfaLV+ lFwA+RG43k/A23cWDp3ixQlw8bEOM7R6wnKhWu1lx48cEJllTu5Sdsm5EP7vgObTXku6 QbX69lt0EZw4yxMDIOStWzuhI9IQ52C44yziz5SKzxSSdNl2CgQG4MYgTmQubSPbGsLy v2lQ==
X-Gm-Message-State: APjAAAUxjaeQiYPXxeBs98Rv+LYCzeGKhOHgQOPWBhmkFGjO62hy+O5M +DkBc5Ig4qW9oxPoKBSdJpnJfUGWYFzwakNQX2U=
X-Google-Smtp-Source: APXvYqxY6reqDqyjNLF8jLkZD7GBrcnDqI4UGWjZ8Y2LMisIkNrXeokZFgf8+8KRnZqENBTYG6NW2s+QNBtVwIBby6g=
X-Received: by 2002:ac2:50cc:: with SMTP id h12mr3210412lfm.29.1578682762573;  Fri, 10 Jan 2020 10:59:22 -0800 (PST)
MIME-Version: 1.0
References:  <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com> 
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jan 2020 10:59:11 -0800
Message-ID: 
To: Neil Madden 
Cc: Aaron Parecki , oauth ,  Mike Jones ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="00000000000046c4f4059bcdb947"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 18:59:35 -0000

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

To restate my previous point, we may not be able to change what is
currently specified and deployed, but we can for future extensions such as
RAR and PAR.

To paraphrase Annabelle, this ship may have already sailed.

On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt  wrote:

> The metadata document is declarative, and can easily be yet another
> separate role in the AS.
>
> In large organizations, different people are empowered different roles, s=
o
> the team owning the metadata document could be different from the team
> generating ID tokens, and different from the team generating JWTs.
>
>
> On Fri, Jan 10, 2020 at 10:27 AM Neil Madden 
> wrote:
>
>> The problem with specifying a property on the key itself is that a
>> microservice might lie about what it=E2=80=99s keys are for. I think you=
 either
>> need separate documents or some separate metadata mapping uses to key id=
s.
>>
>> =E2=80=94 Neil
>>
>> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>>
>> =EF=BB=BF!
>> Can the keys in the document at the jwks_uri indicate what they are for?
>> Either by adding other top-level properties next to "keys" or by specify=
ing
>> a property on a key itself? At least that way implementations that expec=
t
>> just one value of jwks_uri wouldn't have to change.
>>
>> Aaron
>>
>>
>>
>> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote=
:
>>
>>> Yes. Thanks for clarifying.
>>> =E1=90=A7
>>>
>>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>> You mean additional JWKS URIs, for example?
>>>>
>>>> Am 10.01.2020 um 19:09 schrieb Dick Hardt >>> >:
>>>>
>>>> =EF=BB=BF
>>>> Perhaps I am misunderstanding what Annabelle was getting at, but havin=
g
>>>> more than one key in the metadata document would solve the the issue. =
IE,
>>>> extensions would define their own key instead of using the same one.
>>>>
>>>> The metadata document itself was an extension.
>>>>
>>>>
>>>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
>>>> torsten@lodderstedt.net> wrote:
>>>>
>>>>>
>>>>>
>>>>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>>>>> >
>>>>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connec=
t
>>>>> Provider, and the access token is being defined. These extensions hav=
e
>>>>> assumed all of this functionality is a monolith.
>>>>> >
>>>>> > I'm not suggesting that we MUST make changes to existing extensions=
,
>>>>> but design future extensions so that an implementation can separate d=
uties
>>>>> if desired.
>>>>>
>>>>> How do you envision this to work? As you said, OAuth 2.0 is built on
>>>>> the assumption the AS is (at least logically) a monolith. All extensi=
on
>>>>> were built on that underlying assumption. I don=E2=80=99t see how an =
arbitrary
>>>>> extension can relax that assumption and still be compatible with the =
rest
>>>>> (just revisit the discussion re PAR and keys).
>>>>>
>>>>> I think we should accept this design assumption, in the same way we
>>>>> should accept form encoding as request format instead of JSON, for OA=
uth
>>>>> 2.0 extensions.
>>>>>
>>>>> OAuth 3.0 could explicitely be developed with different architectures
>>>>> in mind.
>>>>
>>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

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


To restate my previous point, we may not be able to change=
 what is currently specified and deployed, but we can for future extensions=
 such as RAR and PAR.

To paraphrase Annabelle, this ship=
 may have already sailed.

On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt =
<dick.hardt@gm=
ail.com> wrote:
The metadata document is declarative, and can easil=
y be yet another separate=C2=A0role in the AS.=C2=A0

In =
large organizations, different people are empowered different roles, so the=
 team owning the metadata document could be different=C2=A0from the team ge=
nerating ID tokens, and different from the team generating JWTs.
=


On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <neil.madden@forgerock.com> wrote:
The problem with specifying a property on t=
he key itself is that a microservice might lie about what it=E2=80=99s keys=
 are for. I think you either need separate documents or some separate metad=
ata mapping uses to key ids.=C2=A0

=E2=80=94 Neil
=EF=BB=BF!
Can the keys in the document at the jwks_uri indicate what they a=
re for? Either by adding other top-level properties next to "keys"=
; or by specifying a property on a key itself? At least that way implementa=
tions that expect just one value of jwks_uri wouldn't have to change.

Aaron



On Fri, Jan 10, 2020 at 12:1=
6 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Yes. Thanks for clarifying.
3D""=E1=90=A7

<=
div class=3D"gmail_quote">
On Fri, Jan=
 10, 2020 at 10:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<=
/div>
You mean additional JWKS URIs, for example?

Am 10.01.2020 um 19:09 schrieb Dick Har=
dt <dick.hardt=
@gmail..com>:

=EF=BB=BF
Perhaps I am misunderstanding what=
 Annabelle was getting at, but having more than one key in the metadata doc=
ument would solve the the issue. IE, extensions would define their own key =
instead of using the same one.

The metadata document its=
elf was an extension.=C2=A0


On Fri, Jan 10, 2020 at 9:5=
8 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:




> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith. 

> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still be compatible with the rest (just =
revisit the discussion re PAR and keys).



I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions. 



OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 
----
Aaron =
Parecki


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



--00000000000046c4f4059bcdb947--


From nobody Fri Jan 10 11:31: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 9577F1200DB for ; Fri, 10 Jan 2020 11:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 bB-3J0yYI1Vz for ; Fri, 10 Jan 2020 11:31:44 -0800 (PST)
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 1511712001A for ; Fri, 10 Jan 2020 11:31:43 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id m24so3197684wmc.3 for ; Fri, 10 Jan 2020 11:31:43 -0800 (PST)
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=ByoOjT1EttwXq7Cy1R+9Tj5LmB5ol7oF99ZjtPkw0Ec=; b=cbDYrgmsx/spyy/IdHTBgdNyteVHOJysaYU1HDoAebU5EvijD0ouJt+rASbViPhDCH hvpAjRNDXVImX6zvEXb3QVWcGFdap5E+ga9e4jdGNBmVgRJ9Mg84gfPbw03cmZ0iM3Zf 4eokXx2YbhxHJxar4+tBMvrqgnwe8Yjyg/MmY=
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=ByoOjT1EttwXq7Cy1R+9Tj5LmB5ol7oF99ZjtPkw0Ec=; b=DGCtPHF1d2tCrhO9mOKORAu687xrRRdyl4hFbZz0S0ca4FBofeQ3vaSMv6qJL2Qhc5 jpVNzH4Ho99552H987bJP85kCTEK/dsjriHSjE8HFSzyD/7FhK8z8VmXogEw9tKqCPT2 k8jdMFXEkBJrfTkm7KbwWzMaouJIQlgBVMYa4/JpeaM9paJbvMCIqxczUST6zYE2MTEG 6f0ABmWPtvhHp4DoRNFkoCJxQT3DOPxUmrVNFk1ZJ5bPCDeFwOs8dDkI3KYRcf/VM77d KG5dNWTI6B9u0es0xEfVFT/XtWNJ2GdvumOnYLrAMwqmP+7eqGEKXjOSwg6nc+8KtPR9 w+Mg==
X-Gm-Message-State: APjAAAXW+isLVNjHSCdmm2IpFqyl4mOFkF2K2KoM26rrxcBaeYaMpEeu EKp8LVXn21JRQFdIQlQb86qxUQ==
X-Google-Smtp-Source: APXvYqwtc1ZrULI2xlR0nUJl24OTuIJTqpHvpnieVgJGIaYzLlkwM22AgC8I8Ow0uP++/qlZ1ml/9g==
X-Received: by 2002:a05:600c:2283:: with SMTP id 3mr6067630wmf.100.1578684701906;  Fri, 10 Jan 2020 11:31:41 -0800 (PST)
Received: from ?IPv6:2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1? ([2a01:4c8:3e:f3a1:2c7f:8e44:d8c9:8ce1]) by smtp.gmail.com with ESMTPSA id b68sm3457128wme.6.2020.01.10.11.31.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 11:31:41 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-07E02DCB-A9CC-4A21-931F-EE4721648203
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 19:31:39 +0000
Message-Id: <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>
References: 
Cc: Justin Richer , oauth , Mike Jones , "Richard Backman, Annabelle" 
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 19:31:48 -0000

--Apple-Mail-07E02DCB-A9CC-4A21-931F-EE4721648203
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sure, but we know how to run resilient services. My point is that there=E2=80=
=99s nothing particularly special about cryptographic keys: if you want to c=
ontrol how they are used there is a whole range of normal access control met=
hods you can apply to them without needing to change anything in OAuth.=20

Neil

> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>=20
> =EF=BB=BF
> There are many other factors to resiliency than multiple instances.=20
>=20
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden  w=
rote:
>>=20
>>=20
>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>> [...]
>> >=20
>> > =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, a=
nother goal would be increased resiliency of the components. If the JWT-decr=
yption-microservice is unavailable, the whole system is unavailable. If ther=
e are separate keys, then a failure in one component does not fail the entir=
e system.=20
>>=20
>> Well you can run more than one instance - it=E2=80=99s a completely state=
less service. You can also run a separate instance (or set of instances) per=
 key if you like.=20
>>=20
>> Neil

--Apple-Mail-07E02DCB-A9CC-4A21-931F-EE4721648203
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sure, but we know how to r=
un resilient services. My point is that there=E2=80=99s nothing particularly=
 special about cryptographic keys: if you want to control how they are used t=
here is a whole range of normal access control methods you can apply to them=
 without needing to change anything in OAuth. 
Neil

On 10 Jan 2020, at 18:50, Dick Hardt <dick.hardt@gmail.com> wrot=
e:

=EF=BB=
=BF
There are many other factors to resiliency than multiple=
 instances. 

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <neil.madden@forgerock.com> wrote:




> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com> wrote:

[...]

> 

> =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, a=
nother goal would be increased resiliency of the components. If the JWT-decr=
yption-microservice is unavailable, the whole system is unavailable. If ther=
e are separate keys, then a failure in one component does not fail the entir=
e system. 



Well you can run more than one instance - it=E2=80=99s a completely stateles=
s service. You can also run a separate instance (or set of instances) per ke=
y if you like. 



Neil


=

--Apple-Mail-07E02DCB-A9CC-4A21-931F-EE4721648203--


From nobody Fri Jan 10 11:48: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 B0BFB1200FF for ; Fri, 10 Jan 2020 11:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzp0KojqqyMd for ; Fri, 10 Jan 2020 11:48:40 -0800 (PST)
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 9724D1200F1 for ; Fri, 10 Jan 2020 11:48:39 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id z3so2931133wru.3 for ; Fri, 10 Jan 2020 11:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P562vpr8IHDLzgwM969/LhMb2Fn/iDOt7iYAQV2G+64=; b=oGtcOTthvnuIwjlZIjCHSrLijTiR3FIpDB+o2xPl4zdmjJOoIJvRCuzh8vB/t+2jJd ZYA5DD7hVw7HtL1jcliGy8c+4LNrnEV/sznx+ccqgiGqdXBWs5k8QALipmkzXd76SOKj U8Y14Dd/QPqWTKIESJulJUHVzSlRln4EEMBrMPYWP9uOtYQSWg5HiPvyH3eahnQVkk9y wyAJ3LDWCQxiG+1Nc1bVg+UJ4j/YFX2KkhqqokZ6ux71C8czTk8q7ynYNlYpJTUJ1XjJ 8w4dCoiivBY68tVXMj4h3ru9dmKnGG7tLl0vT/ScFGo5rOcAI8CEjBfgOm4akQsBJYIu 0oOQ==
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=P562vpr8IHDLzgwM969/LhMb2Fn/iDOt7iYAQV2G+64=; b=bSFdFBX9ckFEWAIOp8lf8OBbYJsoEAzlymiuEdEOG39atXalhS19ULgIzrL/SiyJBv F1vVHheheBZ97r+YjOIAW9q1Wfn92IZY1VvA3xUYR2sgYLaOCffSancRMcSn8+sqXoUw EuejHuiaBm0MpWdXrcuJhfqd2Fei1wykMpZ+MYCIHB7D1sF86l2d4DGMEKj3j/LyIRBm VDpg0RAnO29JQuSPD429r77E/fdE+RK8nra0yIOgXy4bS/73QTJt5voFQPaMPI/nYvqN ei/ZgZDV8rnBp1BiAhGpOfUUIOLeqGRiXFVt1zegJdFDL5H8sMsmx9Ywc4Upm/pXhxm0 rCpg==
X-Gm-Message-State: APjAAAV91dY7Rtcxy+Tj2WMlx4C+FdAlskFsJ5jqmBBXC8/aag9JvsTh kEIMixak+S0gZYniXRGq/A1bGF54Si/uB0rev3jCWfCtf58=
X-Google-Smtp-Source: APXvYqz8+2o4Yj+JeR+msnEvs1JyjaA14ZWm3dkpuLEvHXKbBdnrMg8n5u3H+kh9hywfDwtVLBeyxQ6WhgRISUe+vBw=
X-Received: by 2002:a5d:410e:: with SMTP id l14mr4960046wrp.238.1578685717755;  Fri, 10 Jan 2020 11:48:37 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net> 
In-Reply-To: 
From: John Bradley 
Date: Fri, 10 Jan 2020 16:48:28 -0300
Message-ID: 
To: Brian Campbell 
Cc: Torsten Lodderstedt ,  Nat Sakimura ,  "Richard Backman, Annabelle" , oauth 
Content-Type: multipart/alternative; boundary="0000000000006b4d40059bce69d2"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 19:48:43 -0000

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

It may be a challenge to change text saying that the contents of the
resource could be something other than a request object.

If not a request object then what and how is that interoperable are likely
AD questions.

I could perhaps see changing it to must be a request object, or other
format defined by a profile.

John B.


On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
wrote:

> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> I would assume given the status of JAR, we don=E2=80=99t want to change =
it. And
>> as I said, this difference does not impact interoperability from client
>> perspective.
>>
>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org>:
>>
>> =EF=BB=BF
>>
>> It would be more appropriate to add the text to JAR rather than PAR. It
>> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JA=
R
>> also highlights the weirdness of giving PAR special treatment.
>>
>>
>>
>> What if we changed this sentence in Section 5.2 of JAR:
>>
>> The contents of the resource referenced by the URI MUST be a Request
>>
>> Object.
>>
>>
>>
>> To:
>>
>> The contents of the resource referenced by the URI MUST be a Request
>>
>> Object, unless the URI was provided to the client by the Authorization
>>
>> Server.
>>
>>
>>
>> This would allow for use cases such as an AS that provides pre-defined
>> request URIs, or vends request URIs via a client management console, or
>> bakes them into their client apps.
>>
>>
>>
>> =E2=80=93
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>> =EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" > 40lodderstedt.net@dmarc.ietf.org> wrote:
>>
>>
>>
>>     Hi,
>>
>>
>>
>>     you are right, PAR does not require the AS to represent the request
>> as a JWT-based request object. The URI is used as internal reference onl=
y.
>> That why the draft states
>>
>>
>>
>>     "There is no need to make the
>>
>>           authorization request data available to other parties via this
>>
>>           URI.=E2=80=9D
>>
>>
>>
>>     This difference matters from an AS implementation perspective, it
>> doesn't matter from a client's (interop) perspective.
>>
>>
>>
>>     We may add a statement to PAR saying that request_uris issued by the
>> PAR mechanism (MAY) deviate from the JAR definition.
>>
>>
>>
>>     best regards,
>>
>>     Torsten.
>>
>>
>>
>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote:
>>
>>     >
>>
>>     > Hi all,
>>
>>     >
>>
>>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
>> transform all pushed requests into JWTs. This requirement arises from th=
e
>> following:
>>
>>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JA=
R to
>> communicate the pushed request to the authorization endpoint.
>>
>>     >         =E2=80=A2 According to JAR, the resource referenced by req=
uest_uri
>> MUST be a Request Object. (Section 5.2)
>>
>>     >         =E2=80=A2 Request Object is defined to be a JWT containing=
 all the
>> authorization request parameters. (Section 2.1)
>>
>>     >
>>
>>     > There is no need for this requirement to support interoperability,
>> as this is internal to the AS. It is also inconsistent with the rest of
>> JAR, which avoids attempting to define the internal communications betwe=
en
>> the two AS endpoints. Worse, this restriction makes it harder for the
>> authorization endpoint to leverage validation and other work performed a=
t
>> the PAR endpoint, as the state or outcome of that work must be forced in=
to
>> the JWT format (or retrieved via a subsequent service call or database
>> lookup).
>>
>>     >
>>
>>     > =E2=80=93
>>
>>     > Annabelle Richard Backman
>>
>>     > AWS Identity
>>
>>     >
>>
>>     > _______________________________________________
>>
>>     > OAuth mailing list
>>
>>     > OAuth@ietf.org
>>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended 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.*

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


It may be a challenge to change text saying that the=
 contents of the resource could be something other than a request object.=
=C2=A0

If not a request =
object then what and how is that interoperable are likely AD questions.=C2=
=A0

I could perhaps see =
changing it to must be a request object, or other format defined by a profi=
le.

John B.=C2=A0=C2=A0


On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrot=
e:
Agree and =
agree. But given that the change suggested by Annabelle has no impact on th=
e client or interoperability, perhaps Nat or John could work the change int=
o the draft during the edits that happen during the final stages of things?=
 

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the status of JAR, we don=E2=80=99t want to change it=
. And as I said, this difference does not impact interoperability from clie=
nt perspective.

Am 09.0=
1.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

=EF=BB=BF









It would be more appropriate to add the text to JAR rather than PAR. It =
doesn't seem right for PAR to retcon rules in JAR. Moving the text to J=
AR also highlights the weirdness of giving PAR special treatment.=



=C2=A0


What if we changed this sentence in Section 5.2 of JAR:

The contents of the resource referenced by the URI MUST be a Reques=
t


Object.


=C2=A0


To: 


The contents of the resource referenced by the URI MUST be a Reques=
t


Object, unless the URI was provided to the client by the Authorizat=
ion


Server.


=C2=A0


This would allow for use cases such as an AS that provides pre-defined r=
equest URIs, or vends request URIs via a client management console, or bake=
s them into their client apps.


=C2=A0


=E2=80=93 


Annabelle Richard Backman


AWS Identity




=C2=A0


=EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
=3D40lodderstedt.net@dmarc.ietf.org> wrote:<=
/u>


=C2=A0


=C2=A0=C2=A0=C2=A0 Hi, 


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


=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the AS to re=
present the request as a JWT-based request object. The URI is used as inter=
nal reference only. That why the draft states



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


=C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization req=
uest data available to other parties via this


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D<=
/u>


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


=C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementatio=
n perspective, it doesn't matter from a client's (interop) perspect=
ive.


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


=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that reques=
t_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.



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


=C2=A0=C2=A0=C2=A0=C2=A0best regards,


=C2=A0=C2=A0=C2=A0 Torsten.=C2=A0 


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


=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote=
:


=C2=A0=C2=A0=C2=A0 > 


=C2=A0=C2=A0=C2=A0=C2=A0> Hi all,


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR (-2=
0) require that the AS transform all pushed requests into JWTs. This requir=
ement arises from the following:


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 PAR uses the request_uri parameter defined in JAR to communicate the=
 pushed request to the authorization endpoint.


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 According to JAR, the resource referenced by request_uri MUST be a R=
equest Object. (Section 5.2)


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 Request Object is defined to be a JWT containing all the authorizati=
on request parameters. (Section 2.1)


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement to su=
pport interoperability, as this is internal to the AS. It is also inconsist=
ent with the rest of JAR, which avoids attempting to define the internal co=
mmunications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the st=
ate or outcome of that work must be forced into the JWT format (or retrieve=
d via a subsequent service call
 or database lookup).


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93 


=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman


=C2=A0=C2=A0=C2=A0 > AWS Identity


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> ___________________________________________=
____


=C2=A0=C2=A0=C2=A0 > OAuth mailing list


=C2=A0=C2=A0=C2=A0 > OAuth@ietf.org


=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/l=
istinfo/oauth


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


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






_______________________________________________
OAuth mailing list

OAut=
h@ietf.org

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






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

--0000000000006b4d40059bce69d2--


From nobody Fri Jan 10 11:57: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 DF64A1200FA for ; Fri, 10 Jan 2020 11:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 7plMDeGnNgsp for ; Fri, 10 Jan 2020 11:57:21 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B9C12001A for ; Fri, 10 Jan 2020 11:57:20 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id n12so2383280lfe.3 for ; Fri, 10 Jan 2020 11:57:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hrgmVxmXgtdaYhmQG7ngP9Tns+xi/L672OZmltnTS28=; b=VRNWXeRPkZzUlqZWeeVIgKmiW7gKW5OrGNU9xb7ohezEBbb25PJdWGgUNFfKjkASpL IHWOBq4Q0yP+EZ6YGJLY4ySao6j3/JEhMg3nH7Yq/GABIGUukw3HWd52mIesrx8fosxG JLb7GE99aB3JKkYq5Rw+w9YhtYLahRpU9XnHtfM36hK7ySPWC586qZwgVlgUZBWmwalm ugea/UEopEl1UNyHvkxx128vGs3MBfIVAejl27dCAav5jN7dHI+PUeA8eML5g+gCnQbL IZ8XNg+m+p/FETBIUlyfJao3+DeCzAeFPiPB8ONu7LR0NZByqIwKHzNVhA+Kj7m6GZes RfHA==
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=hrgmVxmXgtdaYhmQG7ngP9Tns+xi/L672OZmltnTS28=; b=al2YMTCO+JiwEQITQuMQYauOFkb+igRjhftaZCUMHm5n9jy5NaVegb6D4Nr8vsGhib sFxddKQaXOq2b+9kqYhP1q42Z59KivvLrNbTWDq+H9ijD5G8tQq7vXIQQhs65rOpydTt 7kJoqrJNGJkO9CAB76Ym/bAO5nmOKRvAjkh8/H/bBishSi/lS/W/CVD5udz1VuPeuEC2 fnwsqdoX+8nkEcBSm5jGv1ikxdS+ZMAF2jgg2PTIugWa+2QnZwiuLJaIwDevQzQV+jxU UxFB+WD1FEnm3lNsrBH1YiQ6AcpB9N7etWA9QM18uF/RgLIUswyXify/7tN0XKFDRHC3 plQA==
X-Gm-Message-State: APjAAAW7wXrRzuBhbcKRez8MsjPj9gCeIrTzn8NDGSrwk8hMRBERRdab s2Rl3US82rUr4FE/hgOlWAHoYUAlFj3Qypy4Ew3b5WNFfBXzhuQABBHZPtwfAqcGpWl8OnIoerN M3xh8+Fu0jg/CXw==
X-Google-Smtp-Source: APXvYqx8h0RSYSB5KGByMy0S9Ci4hHyBA7M5TMRBCsiESMl+wCqNtYW/uQDemN6ee57v9amyVOzIgS/HlzTBumcSrhw=
X-Received: by 2002:ac2:5f59:: with SMTP id 25mr1420007lfz.193.1578686238395;  Fri, 10 Jan 2020 11:57:18 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>  
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 10 Jan 2020 12:56:52 -0700
Message-ID: 
To: John Bradley 
Cc: Torsten Lodderstedt ,  Nat Sakimura ,  "Richard Backman, Annabelle" , oauth 
Content-Type: multipart/alternative; boundary="00000000000073b434059bce88a3"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 19:57:26 -0000

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

Sure but the text proposed (or something like it) qualifies it such that
there aren't interoperability questions because it's only an implementation
detail to the AS who both produces the URI and consumes its content.

On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:

> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
>> Agree and agree. But given that the change suggested by Annabelle has no
>> impact on the client or interoperability, perhaps Nat or John could work
>> the change into the draft during the edits that happen during the final
>> stages of things?
>>
>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org> wrote:
>>
>>> I would assume given the status of JAR, we don=E2=80=99t want to change=
 it. And
>>> as I said, this difference does not impact interoperability from client
>>> perspective.
>>>
>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org>:
>>>
>>> =EF=BB=BF
>>>
>>> It would be more appropriate to add the text to JAR rather than PAR. It
>>> doesn't seem right for PAR to retcon rules in JAR. Moving the text to J=
AR
>>> also highlights the weirdness of giving PAR special treatment.
>>>
>>>
>>>
>>> What if we changed this sentence in Section 5.2 of JAR:
>>>
>>> The contents of the resource referenced by the URI MUST be a Request
>>>
>>> Object.
>>>
>>>
>>>
>>> To:
>>>
>>> The contents of the resource referenced by the URI MUST be a Request
>>>
>>> Object, unless the URI was provided to the client by the Authorization
>>>
>>> Server.
>>>
>>>
>>>
>>> This would allow for use cases such as an AS that provides pre-defined
>>> request URIs, or vends request URIs via a client management console, or
>>> bakes them into their client apps.
>>>
>>>
>>>
>>> =E2=80=93
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>> =EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" >> 40lodderstedt.net@dmarc.ietf.org> wrote:
>>>
>>>
>>>
>>>     Hi,
>>>
>>>
>>>
>>>     you are right, PAR does not require the AS to represent the request
>>> as a JWT-based request object. The URI is used as internal reference on=
ly.
>>> That why the draft states
>>>
>>>
>>>
>>>     "There is no need to make the
>>>
>>>           authorization request data available to other parties via thi=
s
>>>
>>>           URI.=E2=80=9D
>>>
>>>
>>>
>>>     This difference matters from an AS implementation perspective, it
>>> doesn't matter from a client's (interop) perspective.
>>>
>>>
>>>
>>>     We may add a statement to PAR saying that request_uris issued by th=
e
>>> PAR mechanism (MAY) deviate from the JAR definition.
>>>
>>>
>>>
>>>     best regards,
>>>
>>>     Torsten.
>>>
>>>
>>>
>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote:
>>>
>>>     >
>>>
>>>     > Hi all,
>>>
>>>     >
>>>
>>>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
>>> transform all pushed requests into JWTs. This requirement arises from t=
he
>>> following:
>>>
>>>     >         =E2=80=A2 PAR uses the request_uri parameter defined in J=
AR to
>>> communicate the pushed request to the authorization endpoint.
>>>
>>>     >         =E2=80=A2 According to JAR, the resource referenced by re=
quest_uri
>>> MUST be a Request Object. (Section 5.2)
>>>
>>>     >         =E2=80=A2 Request Object is defined to be a JWT containin=
g all the
>>> authorization request parameters. (Section 2.1)
>>>
>>>     >
>>>
>>>     > There is no need for this requirement to support interoperability=
,
>>> as this is internal to the AS. It is also inconsistent with the rest of
>>> JAR, which avoids attempting to define the internal communications betw=
een
>>> the two AS endpoints. Worse, this restriction makes it harder for the
>>> authorization endpoint to leverage validation and other work performed =
at
>>> the PAR endpoint, as the state or outcome of that work must be forced i=
nto
>>> the JWT format (or retrieved via a subsequent service call or database
>>> lookup).
>>>
>>>     >
>>>
>>>     > =E2=80=93
>>>
>>>     > Annabelle Richard Backman
>>>
>>>     > AWS Identity
>>>
>>>     >
>>>
>>>     > _______________________________________________
>>>
>>>     > OAuth mailing list
>>>
>>>     > OAuth@ietf.org
>>>
>>>     > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
.
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>
>

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

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


Sure but the text proposed (or something like it) qualifie=
s it such that there aren't interoperability questions because it's=
 only an implementation detail to the AS who both produces the URI and cons=
umes its content. 

On Fri, Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
I=
t may be a challenge to change text saying that the contents of the resourc=
e could be something other than a request object.=C2=A0

If not a request object then what and how i=
s that interoperable are likely AD questions.=C2=A0
=

I could perhaps see changing it to must be a re=
quest object, or other format defined by a profile.

John B.=C2=A0=C2=
=A0


On Fri, Jan 1=
0, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Ag=
ree and agree. But given that the change suggested by Annabelle has no impa=
ct on the client or interoperability, perhaps Nat or John could work the ch=
ange into the draft during the edits that happen during the final stages of=
 things? 

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=
=3D40lodderstedt.net@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">
I would assume given the status of JAR, we don=E2=80=99t want to c=
hange it. And as I said, this difference does not impact interoperability f=
rom client perspective.

Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=3D<=
a href=3D"mailto:40amazon.com@dmarc.ietf.org" rel=3D"noreferrer" target=3D"=
_blank">40amazon.com@dmarc.ietf.org>:

=EF=BB=BF









It would be more appropriate to add the text to JAR rather than PAR. It =
doesn't seem right for PAR to retcon rules in JAR. Moving the text to J=
AR also highlights the weirdness of giving PAR special treatment.=



=C2=A0


What if we changed this sentence in Section 5.2 of JAR:

The contents of the resource referenced by the URI MUST be a Reques=
t


Object.


=C2=A0


To: 


The contents of the resource referenced by the URI MUST be a Reques=
t


Object, unless the URI was provided to the client by the Authorizat=
ion


Server.


=C2=A0


This would allow for use cases such as an AS that provides pre-defined r=
equest URIs, or vends request URIs via a client management console, or bake=
s them into their client apps.


=C2=A0


=E2=80=93 


Annabelle Richard Backman


AWS Identity




=C2=A0


=EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
=3D40lodderstedt.net@dmarc.ietf.org> wrote:<=
/u>


=C2=A0


=C2=A0=C2=A0=C2=A0 Hi, 


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


=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the AS to re=
present the request as a JWT-based request object. The URI is used as inter=
nal reference only. That why the draft states



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


=C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization req=
uest data available to other parties via this


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D<=
/u>


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


=C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementatio=
n perspective, it doesn't matter from a client's (interop) perspect=
ive.


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


=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that reques=
t_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.



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


=C2=A0=C2=A0=C2=A0=C2=A0best regards,


=C2=A0=C2=A0=C2=A0 Torsten.=C2=A0 


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


=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote=
:


=C2=A0=C2=A0=C2=A0 > 


=C2=A0=C2=A0=C2=A0=C2=A0> Hi all,


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR (-2=
0) require that the AS transform all pushed requests into JWTs. This requir=
ement arises from the following:


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 PAR uses the request_uri parameter defined in JAR to communicate the=
 pushed request to the authorization endpoint.


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 According to JAR, the resource referenced by request_uri MUST be a R=
equest Object. (Section 5.2)


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 Request Object is defined to be a JWT containing all the authorizati=
on request parameters. (Section 2.1)


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement to su=
pport interoperability, as this is internal to the AS. It is also inconsist=
ent with the rest of JAR, which avoids attempting to define the internal co=
mmunications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the st=
ate or outcome of that work must be forced into the JWT format (or retrieve=
d via a subsequent service call
 or database lookup).


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93 


=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman


=C2=A0=C2=A0=C2=A0 > AWS Identity


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> ___________________________________________=
____


=C2=A0=C2=A0=C2=A0 > OAuth mailing list


=C2=A0=C2=A0=C2=A0 > OAuth@ietf.org


=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/l=
istinfo/oauth


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


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






_______________________________________________
OAuth mailing list

OAut=
h@ietf.org

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






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




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


From nobody Fri Jan 10 12: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 E2F6612008A for ; Fri, 10 Jan 2020 12:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5g9fP7Y206ig for ; Fri, 10 Jan 2020 12:18:51 -0800 (PST)
Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CF1120052 for ; Fri, 10 Jan 2020 12:18:51 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id q0k4iGaJNdTTgq0k5iHlM3; Fri, 10 Jan 2020 13:18:50 -0700
To: oauth@ietf.org
References:  <8DFAF146-442E-4115-B31C-4BA1AAAABD2C@lodderstedt.net>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Fri, 10 Jan 2020 22:18:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <8DFAF146-442E-4115-B31C-4BA1AAAABD2C@lodderstedt.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060502040600080708010403"
X-CMAE-Envelope: MS4wfO/v7oHLJfnZCn2Xc9Uo+Xvtw9EjKqlfZK1QUx4cUtyDMf3nkKsUl77xL2Br4KmabAxZtc5erNJIxioPPYfr9ndA3n0DNxVcz6vyFJJn0rXJbxzbpezP Ktkq2GaOo6F5JHJ3wEDAh5IeKcElEEh0b5oX1I4PhEFTD8k3fZV2qsBF
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 20:18:54 -0000

This is a cryptographically signed message in MIME format.

--------------ms060502040600080708010403
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

I just realised there is one class of JARs where it's practially
impossible to process the request if merge isn't supported:

The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
for that and specs a method for deriving the shared key from the
client_secret:

https://openid.net/specs/openid-connect-core-1_0.html#Encryption

If the JAR is encrypted with the client_secret, and there is no
top-level client_id parameter, there's no good way for the OP to find
out which client_secret to get to try to decrypt the JWE. Unless the OP
keeps an index of all issued client_secret's.


OP servers which require request_uri registration
(require_request_uri_registration=3Dtrue) and don't want to index all
registered request_uri's, also have no good way to process a request_uri
if the client_id isn't present as top-level parameter.


Vladimir


On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>
>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>
>> I think Torsten is speculating that is not a feature people use.  =20
> I=E2=80=99m still trying to understand the use case for merging signed =
and unsigned parameters. Nat once explained a use case, where a client us=
es parameters signed by a 3rd party (some =E2=80=9Ecertification authorit=
y=E2=80=9C) in combination with transaction-specific parameters. Is this =
being done in the wild?=20
>
> PS: PAR would work with both modes.



--------------ms060502040600080708010403
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTAyMDE4NDhaMC8G
CSqGSIb3DQEJBDEiBCDE8SPqWnDrxFaqblJUAfSReho3miGXJY7fs0tD5TgKKTBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAKAz6qm8rI7bnwfV0++Sqa/4DAtijlzoSDeEgbPLXiKqRCLD
FZ76Sk3nrG1TY1DS9cBFxiWaHzZPLVM0NZ5a/Qu62gT6vgWVM7qOul7m9A3m0BIEvmcF8Gj3
5KUVPXhv6jlZk5O64EFKXUZwXkbcSkwr0LhOru34LkWPH3a5qnhlzY9Myp7AyAECHB0csBXs
Z9EHZtrt5C0tRRX4REovus/xqkX+zbfD86t6zHI8KbBny7efubzoHypqvHEsmO2hryVK1bCh
OMcNIw+SmYwFqtgDbG1IErjNLw/dJS1jBRI15iV+QwVeRDfs64XL2NK+MsRLc2QfRQxgy4Ci
o1342rEAAAAAAAA=
--------------ms060502040600080708010403--


From nobody Fri Jan 10 12:28: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 50EDE120100 for ; Fri, 10 Jan 2020 12:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n0oEJeX84PO for ; Fri, 10 Jan 2020 12:28:41 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73B21200FF for ; Fri, 10 Jan 2020 12:28:40 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id b6so3037674wrq.0 for ; Fri, 10 Jan 2020 12:28:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r69CKG402OJKJhfFCILYX5vf5AVNnGtYrWYhHJk7L/8=; b=tpUrXg6EkRn+E1s6up7hBtdlCRG144p3seH/82blb3LrgENzTGtLbTDyAlApk7B1gu KJ2CO+nGEKtuxA8nxkaDfaJ/dQEQ7fyUq+HH48yFrEyiVnMo9+PWQQBfSX8RbZM8LNzb HsY/3Wl23DI/ZE/2cBLLw63dH4Xs/m/CvIAC77qGt50ikbQfzgyzZJgwy/mM+WjzfpYH tK2eeRsQSvUDKjEkuOw2urqwAqaKPswDBUu+it3aWF9eJGKmPLur7DvnjvwWYr2INvNv Wpvcsa+NTG7FO4/lX8mVuurhO8lW9ZMmZtmLVOonbF2rfq8pdDb/I4LAj8y7pRSuFvVU TflQ==
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=r69CKG402OJKJhfFCILYX5vf5AVNnGtYrWYhHJk7L/8=; b=eyNZp5qCbBOgCc9isIQH8unVirzFHTljoQiTkFxMYmdSGrRLF34RQZQ3sQr2nd/zFn 0Ntw/4v1DS3fLV47Q6yp/eNO2+HGnyoV5ntokM903IuQ+cYSHjx5uAMfKHqR4qUDzCce YetkEC7eCSAOuEfTrrUzmzoCakI4OBRb0i0dGKfUg8pzt6UU+VNqTSGOAT8EQoLeLLAb kvFNy7aJhhn5O9gLTMI/Pk9R9QeR6MHzUZhezETQRIyB9CKUj2YVrNJBar5SsSoTexa6 6lBgLvOn0Djieq00I7qMfyDfo1wiP0MKPW7Z8Qf0GGlc+RblJvIegzqz4vpZi2lrB8J0 xHJg==
X-Gm-Message-State: APjAAAUqXqyHaZDN5lqR4nrmj8ZBB+JwAZjlOGEKlsywQXXlMDQkxRFK vE0BtXKhr/U6eaW0gMoGUUuziAp4crtGXbUaoxZK6g==
X-Google-Smtp-Source: APXvYqyI/S8VrZOZ78GxQtiySQytRvDMkoe2gqFhLlScNDmH016uYCMuFOT3ExQnX3DdjNHCBb6HHWW+fVEgrtSq3Fc=
X-Received: by 2002:adf:f382:: with SMTP id m2mr5222434wro.163.1578688118831;  Fri, 10 Jan 2020 12:28:38 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>   
In-Reply-To: 
From: John Bradley 
Date: Fri, 10 Jan 2020 17:28:29 -0300
Message-ID: 
To: Brian Campbell 
Cc: Torsten Lodderstedt ,  Nat Sakimura ,  "Richard Backman, Annabelle" , oauth 
Content-Type: multipart/alternative; boundary="00000000000088d2c6059bcef875"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 20:28:46 -0000

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

If we assume the client posts a JAR and gets back a reference.  Then the
reference is to a JAR.

I think I see the problem.  If the server providing the reference is
associated with the AS then the server dosen't need to dereference the
object via HTTP, so it could be a URN as an example.

So yes it is not a interoperability issue for the client.

I will think about how I can finesse that.

I agree it is not a change in intent.

I will see if I can get our AD to accept that.

John B.




On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
wrote:

> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
>> It may be a challenge to change text saying that the contents of the
>> resource could be something other than a request object.
>>
>> If not a request object then what and how is that interoperable are
>> likely AD questions.
>>
>> I could perhaps see changing it to must be a request object, or other
>> format defined by a profile.
>>
>> John B.
>>
>>
>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
>> wrote:
>>
>>> Agree and agree. But given that the change suggested by Annabelle has n=
o
>>> impact on the client or interoperability, perhaps Nat or John could wor=
k
>>> the change into the draft during the edits that happen during the final
>>> stages of things?
>>>
>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt >> 40lodderstedt.net@dmarc.ietf.org> wrote:
>>>
>>>> I would assume given the status of JAR, we don=E2=80=99t want to chang=
e it. And
>>>> as I said, this difference does not impact interoperability from clien=
t
>>>> perspective.
>>>>
>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle >>> 40amazon.com@dmarc.ietf.org>:
>>>>
>>>> =EF=BB=BF
>>>>
>>>> It would be more appropriate to add the text to JAR rather than PAR. I=
t
>>>> doesn't seem right for PAR to retcon rules in JAR. Moving the text to =
JAR
>>>> also highlights the weirdness of giving PAR special treatment.
>>>>
>>>>
>>>>
>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>
>>>> The contents of the resource referenced by the URI MUST be a Request
>>>>
>>>> Object.
>>>>
>>>>
>>>>
>>>> To:
>>>>
>>>> The contents of the resource referenced by the URI MUST be a Request
>>>>
>>>> Object, unless the URI was provided to the client by the Authorization
>>>>
>>>> Server.
>>>>
>>>>
>>>>
>>>> This would allow for use cases such as an AS that provides pre-defined
>>>> request URIs, or vends request URIs via a client management console, o=
r
>>>> bakes them into their client apps.
>>>>
>>>>
>>>>
>>>> =E2=80=93
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>> =EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" >>> 40lodderstedt.net@dmarc.ietf.org> wrote:
>>>>
>>>>
>>>>
>>>>     Hi,
>>>>
>>>>
>>>>
>>>>     you are right, PAR does not require the AS to represent the reques=
t
>>>> as a JWT-based request object. The URI is used as internal reference o=
nly.
>>>> That why the draft states
>>>>
>>>>
>>>>
>>>>     "There is no need to make the
>>>>
>>>>           authorization request data available to other parties via th=
is
>>>>
>>>>           URI.=E2=80=9D
>>>>
>>>>
>>>>
>>>>     This difference matters from an AS implementation perspective, it
>>>> doesn't matter from a client's (interop) perspective.
>>>>
>>>>
>>>>
>>>>     We may add a statement to PAR saying that request_uris issued by
>>>> the PAR mechanism (MAY) deviate from the JAR definition.
>>>>
>>>>
>>>>
>>>>     best regards,
>>>>
>>>>     Torsten.
>>>>
>>>>
>>>>
>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle >>> 40amazon.com@dmarc.ietf.org> wrote:
>>>>
>>>>     >
>>>>
>>>>     > Hi all,
>>>>
>>>>     >
>>>>
>>>>     > The current drafts of PAR (-00) and JAR (-20) require that the A=
S
>>>> transform all pushed requests into JWTs. This requirement arises from =
the
>>>> following:
>>>>
>>>>     >         =E2=80=A2 PAR uses the request_uri parameter defined in =
JAR to
>>>> communicate the pushed request to the authorization endpoint.
>>>>
>>>>     >         =E2=80=A2 According to JAR, the resource referenced by
>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>
>>>>     >         =E2=80=A2 Request Object is defined to be a JWT containi=
ng all
>>>> the authorization request parameters. (Section 2.1)
>>>>
>>>>     >
>>>>
>>>>     > There is no need for this requirement to support
>>>> interoperability, as this is internal to the AS. It is also inconsiste=
nt
>>>> with the rest of JAR, which avoids attempting to define the internal
>>>> communications between the two AS endpoints. Worse, this restriction m=
akes
>>>> it harder for the authorization endpoint to leverage validation and ot=
her
>>>> work performed at the PAR endpoint, as the state or outcome of that wo=
rk
>>>> must be forced into the JWT format (or retrieved via a subsequent serv=
ice
>>>> call or database lookup).
>>>>
>>>>     >
>>>>
>>>>     > =E2=80=93
>>>>
>>>>     > Annabelle Richard Backman
>>>>
>>>>     > AWS Identity
>>>>
>>>>     >
>>>>
>>>>     > _______________________________________________
>>>>
>>>>     > OAuth mailing list
>>>>
>>>>     > OAuth@ietf.org
>>>>
>>>>     > https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibite=
d.
>>> If you have received this communication in error, please notify the sen=
der
>>> immediately by e-mail and delete the message and any file attachments f=
rom
>>> your computer. Thank you.*
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*

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


If we assume the client posts a JAR and=
 gets back a reference.=C2=A0 Then the reference is to a JAR.=C2=A0

I think I see the problem.=C2=
=A0 If the server providing the reference is associated with the AS then th=
e server dosen't need to dereference the object via HTTP, so it could b=
e a URN as an example.=C2=A0

So yes it is not a interoperability issue for the client.=C2=A0=C2=A0<=
/div>

I will think about how I=
 can finesse that.=C2=A0

I agree it is not a change in intent.=C2=A0

I will see if I can get our AD to accept that.

John B.=C2=A0




On =
Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Sure but the text proposed (or som=
ething like it) qualifies it such that there aren't interoperability qu=
estions because it's only an implementation detail to the AS who both p=
roduces the URI and consumes its content. 

On Fri, Jan 10, 2020 at 12:48=
 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a cha=
llenge to change text saying that the contents of the resource could be som=
ething other than a request object.=C2=A0

=

If not a request object then what and how is that interop=
erable are likely AD questions.=C2=A0

I could perhaps see changing it to must be a request object, =
or other format defined by a profile.

John B.=C2=A0=C2=A0


On Fri, Jan 10, 2020, 3:45 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
<=
div>Agree and agree. But given that the change suggested by Annabelle has n=
o impact on the client or interoperability, perhaps Nat or John could work =
the change into the draft during the edits that happen during the final sta=
ges of things? 

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <t=
orsten=3D40lodderstedt.net@dmarc.ietf.org> =
wrote:
I would assume given the status of JAR, we don=
=E2=80=99t want to change it. And as I said, this difference does not impac=
t interoperability from client perspective.

Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabe=
lle <richanna=3D40amazon.com@dmarc.ietf.org>:=


=EF=
=BB=BF









It would be more appropriate to add the text to JAR rather than PAR. It =
doesn't seem right for PAR to retcon rules in JAR. Moving the text to J=
AR also highlights the weirdness of giving PAR special treatment.=



=C2=A0


What if we changed this sentence in Section 5.2 of JAR:

The contents of the resource referenced by the URI MUST be a Reques=
t


Object.


=C2=A0


To: 


The contents of the resource referenced by the URI MUST be a Reques=
t


Object, unless the URI was provided to the client by the Authorizat=
ion


Server.


=C2=A0


This would allow for use cases such as an AS that provides pre-defined r=
equest URIs, or vends request URIs via a client management console, or bake=
s them into their client apps.


=C2=A0


=E2=80=93 


Annabelle Richard Backman


AWS Identity




=C2=A0


=EF=BB=BFOn 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
=3D40lodderstedt.net@dmarc.ietf.org> wrote:=



=C2=A0


=C2=A0=C2=A0=C2=A0 Hi, 


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


=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the AS to re=
present the request as a JWT-based request object. The URI is used as inter=
nal reference only. That why the draft states



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


=C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization req=
uest data available to other parties via this


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D<=
/u>


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


=C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementatio=
n perspective, it doesn't matter from a client's (interop) perspect=
ive.


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


=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that reques=
t_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.



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


=C2=A0=C2=A0=C2=A0=C2=A0best regards,


=C2=A0=C2=A0=C2=A0 Torsten.=C2=A0 


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


=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backman, =
Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:


=C2=A0=C2=A0=C2=A0 > 


=C2=A0=C2=A0=C2=A0=C2=A0> Hi all,


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR (-2=
0) require that the AS transform all pushed requests into JWTs. This requir=
ement arises from the following:


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 PAR uses the request_uri parameter defined in JAR to communicate the=
 pushed request to the authorization endpoint.


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 According to JAR, the resource referenced by request_uri MUST be a R=
equest Object. (Section 5.2)


=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 Request Object is defined to be a JWT containing all the authorizati=
on request parameters. (Section 2.1)


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement to su=
pport interoperability, as this is internal to the AS. It is also inconsist=
ent with the rest of JAR, which avoids attempting to define the internal co=
mmunications between the two AS endpoints.
 Worse, this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the st=
ate or outcome of that work must be forced into the JWT format (or retrieve=
d via a subsequent service call
 or database lookup).


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93 


=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman


=C2=A0=C2=A0=C2=A0 > AWS Identity


=C2=A0=C2=A0=C2=A0 >=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0> ___________________________________________=
____


=C2=A0=C2=A0=C2=A0 > OAuth mailing list


=C2=A0=C2=A0=C2=A0 > OAuth@ietf.org


=C2=A0=C2=A0=C2=A0 > https://www.ietf.or=
g/mailman/listinfo/oauth


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


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






_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listin=
fo/oauth






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





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

--00000000000088d2c6059bcef875--


From nobody Fri Jan 10 12:39: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 2E73B120104 for ; Fri, 10 Jan 2020 12:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 aucA1kigFx8F for ; Fri, 10 Jan 2020 12:39:47 -0800 (PST)
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 6E9C91200FF for ; Fri, 10 Jan 2020 12:39:47 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id p9so3381877wmc.2 for ; Fri, 10 Jan 2020 12:39:47 -0800 (PST)
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=KuZPN1Ga+KeBaFW7/MlwoEzzEb9vyvKY3WSPMqJJNJA=; b=WJvdjAWfBhrJ1WXgMzIHk4w2j0TCLkXATFzpqq1yUN79WxDBqHIdexbrPDo0XP+J3U Avz6bLLgStF4VMiaEjvXC0RQzBW3NriEBDMSVw8O64puiUZD/kaLf7DgjLhOxVie88F+ cm15wQdZnEH3t2JShym2xGVFim5heoY8HSweeHjEXjMRCRCUlFHjzPnznIqrwy3fDKxu nN1ys2Mso58Lb7+Q2VxljI99loP5xNRcTfSn23seT29Tdzt2f2UDnU3CyZ4MZNrlCRva SsSfmbHx/JMhwbKWK9RivOoqxquqnuvyxuf3Ni1bh5X8pDbTHsq6Z3W5DR8raUeYrpa5 Hd3Q==
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=KuZPN1Ga+KeBaFW7/MlwoEzzEb9vyvKY3WSPMqJJNJA=; b=X6pf8xxFCnF42cG+OhtbOIlG9BPPzPCZejqzK+XcKw4QPUI5FSh10p/j44h6Y7MTg+ rPq46YUfwwhE88afgklW6WssIe3TnT7e9SlVNr1ZI5JqFXota3+bVNbAPfDpnPuAMIxP rMU1j+8tYPWFaDvSYTPtZoS0dxn/fNcVlmDen/pj4EeYoPK3k1uHtgDP9GJaGfNElgqv 3VwJllyYppHu0Zh1OI81T3vi6hEIxaKVs61Cjxl90UFAvwMoIJ3rh2mAJuYgyy5BuLD9 suAipjJ8UAhoqwtJwGIYM6qSBptB5YiNrR1M8AWLaw+zDjzRgkV4lruN0Gr64B62P94C W/HA==
X-Gm-Message-State: APjAAAUEqIeITDZxjxbxjm/lEE8NV3NeglmQ1CQ+uQscuf5iUJWhg5xz QnIkQDn6x/mZRyb5WX62vhLwQXeNSA==
X-Google-Smtp-Source: APXvYqw0QP40eNabQDDjSuiASpOWUKGpl4dmODlKIEF6cg72qazFuIUqZ+fgrRU3tHr4RlgPQg0fJQ==
X-Received: by 2002:a1c:184:: with SMTP id 126mr6155302wmb.127.1578688785819;  Fri, 10 Jan 2020 12:39:45 -0800 (PST)
Received: from [192.168.0.150] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id g18sm3406442wmh.48.2020.01.10.12.39.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 12:39:45 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Filip Skokan 
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 21:39:44 +0100
Message-Id: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com>
References: 
Cc: oauth@ietf.org
In-Reply-To: 
To: Vladimir Dzhuvinov 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 20:39:50 -0000

Vladimir,=20

For that very case the payload claims may be repeated in the JWE protected h=
eader. An implementation wanting to handle this may look for iss/client_id t=
here.=20

Odesl=C3=A1no z iPhonu

> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>=20
> =EF=BB=BFI just realised there is one class of JARs where it's practially
> impossible to process the request if merge isn't supported:
>=20
> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
> for that and specs a method for deriving the shared key from the
> client_secret:
>=20
> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>=20
> If the JAR is encrypted with the client_secret, and there is no
> top-level client_id parameter, there's no good way for the OP to find
> out which client_secret to get to try to decrypt the JWE. Unless the OP
> keeps an index of all issued client_secret's.
>=20
>=20
> OP servers which require request_uri registration
> (require_request_uri_registration=3Dtrue) and don't want to index all
> registered request_uri's, also have no good way to process a request_uri
> if the client_id isn't present as top-level parameter.
>=20
>=20
> Vladimir
>=20
>=20
>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>=20
>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>>=20
>>> I think Torsten is speculating that is not a feature people use.  =20
>> I=E2=80=99m still trying to understand the use case for merging signed an=
d unsigned parameters. Nat once explained a use case, where a client uses pa=
rameters signed by a 3rd party (some =E2=80=9Ecertification authority=E2=80=9C=
) in combination with transaction-specific parameters. Is this being done in=
 the wild?=20
>>=20
>> PS: PAR would work with both modes.
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jan 10 12:41: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 42E23120119 for ; Fri, 10 Jan 2020 12:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5wmqk8kJg7 for ; Fri, 10 Jan 2020 12:41:19 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C772120111 for ; Fri, 10 Jan 2020 12:41:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578688880; x=1610224880; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pYZY8Za9xH7Y82xMBZ2ONkza2vZJy+gIKezT0Kiz2P8=; b=BKRMUv/Xmz7rGXQlw49L57JI9XN6w7jbTn+0vTAmp4iycC6XvzYw8EL+ FT8qfAG1CYYTEmGhZ6aYunDRHU6CFy4qx1xc7sZ6WZCtEIovWruFN42x6 zn2OkHLs1OyC/QIxqZszrWVqMZjN5NUlDeDxfLAubyw/4FWVxl+DXtxx8 Y=;
IronPort-SDR: ZiPWos0kqPlTNLAzyyzgxn/fkoVF0N8S1O7pXxRKTWVP46gTmGtVQRZGLRqespQTKGyWHIn7s/ BsjDukXi1wrg==
X-IronPort-AV: E=Sophos;i="5.69,418,1571702400"; d="scan'208,217";a="9636039"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-1968f9fa.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 10 Jan 2020 20:41:09 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-1968f9fa.us-west-2.amazon.com (Postfix) with ESMTPS id E3820A27DF; Fri, 10 Jan 2020 20:41:07 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 20:41:07 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 20:41:07 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 10 Jan 2020 20:41:07 +0000
From: "Richard Backman, Annabelle" 
To: John Bradley , Brian Campbell 
CC: Torsten Lodderstedt , Nat Sakimura , oauth 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs
Thread-Index: AQHVx+8B8oWn2Dtc6kCluPEQok9/CKfkUFYAgAAI1YD//31rgA==
Date: Fri, 10 Jan 2020 20:41:07 +0000
Message-ID: 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.115]
Content-Type: multipart/alternative; boundary="_000_CAC46A6B229C4B5AAEE3A2D8662A81DBamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 20:41:22 -0000

--_000_CAC46A6B229C4B5AAEE3A2D8662A81DBamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29ycmVjdC4gVGhlIHByb2JsZW0gYmVjb21lcyBwcmV0dHkgY2xlYXIgaW4gdGhlIGNvbnRleHQg
b2YgUEFSLCB3aGVyZSB0aGUgQVMgaXMgZ2VuZXJhdGluZyBhbmQgdmVuZGluZyBvdXQgdGhlIFVS
SSBhdCB0aGUgUEFSIGVuZHBvaW50LCBhbmQgY29uc3VtaW5nIGl0IGF0IHRoZSBhdXRob3JpemF0
aW9uIGVuZHBvaW50LiBGcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgc3RhbmRwb2ludCwgaXTigJlz
IGFuYWxvZ291cyB0byB0aGUgQVMgdmVuZGluZyBhbiBhdXRob3JpemF0aW9uIGNvZGUgYXQgdGhl
IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGNvbnN1bWluZyBpdCBhdCB0aGUgdG9rZW4gZW5k
cG9pbnQuDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoN
CkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+DQpEYXRlOiBGcmlkYXksIEph
bnVhcnkgMTAsIDIwMjAgYXQgMTI6MjkgUE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb20+DQpDYzogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2Rk
ZXJzdGVkdC5uZXQ+LCBOYXQgU2FraW11cmEgPG5hdEBzYWtpbXVyYS5vcmc+LCAiUmljaGFyZCBC
YWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPiwgb2F1dGggPG9hdXRoQGll
dGYub3JnPg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBQQVI6
IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzDQoNCklmIHdlIGFzc3VtZSB0aGUgY2xp
ZW50IHBvc3RzIGEgSkFSIGFuZCBnZXRzIGJhY2sgYSByZWZlcmVuY2UuICBUaGVuIHRoZSByZWZl
cmVuY2UgaXMgdG8gYSBKQVIuDQoNCkkgdGhpbmsgSSBzZWUgdGhlIHByb2JsZW0uICBJZiB0aGUg
c2VydmVyIHByb3ZpZGluZyB0aGUgcmVmZXJlbmNlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQVMg
dGhlbiB0aGUgc2VydmVyIGRvc2VuJ3QgbmVlZCB0byBkZXJlZmVyZW5jZSB0aGUgb2JqZWN0IHZp
YSBIVFRQLCBzbyBpdCBjb3VsZCBiZSBhIFVSTiBhcyBhbiBleGFtcGxlLg0KDQpTbyB5ZXMgaXQg
aXMgbm90IGEgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSBmb3IgdGhlIGNsaWVudC4NCg0KSSB3aWxs
IHRoaW5rIGFib3V0IGhvdyBJIGNhbiBmaW5lc3NlIHRoYXQuDQoNCkkgYWdyZWUgaXQgaXMgbm90
IGEgY2hhbmdlIGluIGludGVudC4NCg0KSSB3aWxsIHNlZSBpZiBJIGNhbiBnZXQgb3VyIEFEIHRv
IGFjY2VwdCB0aGF0Lg0KDQpKb2huIEIuDQoNCg0KDQoNCk9uIEZyaSwgSmFuIDEwLCAyMDIwLCA0
OjU3IFBNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86
YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNClN1cmUgYnV0IHRoZSB0ZXh0IHBy
b3Bvc2VkIChvciBzb21ldGhpbmcgbGlrZSBpdCkgcXVhbGlmaWVzIGl0IHN1Y2ggdGhhdCB0aGVy
ZSBhcmVuJ3QgaW50ZXJvcGVyYWJpbGl0eSBxdWVzdGlvbnMgYmVjYXVzZSBpdCdzIG9ubHkgYW4g
aW1wbGVtZW50YXRpb24gZGV0YWlsIHRvIHRoZSBBUyB3aG8gYm90aCBwcm9kdWNlcyB0aGUgVVJJ
IGFuZCBjb25zdW1lcyBpdHMgY29udGVudC4NCg0KT24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTI6
NDggUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0
Yi5jb20+PiB3cm90ZToNCkl0IG1heSBiZSBhIGNoYWxsZW5nZSB0byBjaGFuZ2UgdGV4dCBzYXlp
bmcgdGhhdCB0aGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIGNvdWxkIGJlIHNvbWV0aGluZyBv
dGhlciB0aGFuIGEgcmVxdWVzdCBvYmplY3QuDQoNCklmIG5vdCBhIHJlcXVlc3Qgb2JqZWN0IHRo
ZW4gd2hhdCBhbmQgaG93IGlzIHRoYXQgaW50ZXJvcGVyYWJsZSBhcmUgbGlrZWx5IEFEIHF1ZXN0
aW9ucy4NCg0KSSBjb3VsZCBwZXJoYXBzIHNlZSBjaGFuZ2luZyBpdCB0byBtdXN0IGJlIGEgcmVx
dWVzdCBvYmplY3QsIG9yIG90aGVyIGZvcm1hdCBkZWZpbmVkIGJ5IGEgcHJvZmlsZS4NCg0KSm9o
biBCLg0KDQoNCk9uIEZyaSwgSmFuIDEwLCAyMDIwLCAzOjQ1IFBNIEJyaWFuIENhbXBiZWxsIDxi
Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b20+PiB3cm90ZToNCkFncmVlIGFuZCBhZ3JlZS4gQnV0IGdpdmVuIHRoYXQgdGhlIGNoYW5nZSBz
dWdnZXN0ZWQgYnkgQW5uYWJlbGxlIGhhcyBubyBpbXBhY3Qgb24gdGhlIGNsaWVudCBvciBpbnRl
cm9wZXJhYmlsaXR5LCBwZXJoYXBzIE5hdCBvciBKb2huIGNvdWxkIHdvcmsgdGhlIGNoYW5nZSBp
bnRvIHRoZSBkcmFmdCBkdXJpbmcgdGhlIGVkaXRzIHRoYXQgaGFwcGVuIGR1cmluZyB0aGUgZmlu
YWwgc3RhZ2VzIG9mIHRoaW5ncz8NCg0KT24gVGh1LCBKYW4gOSwgMjAyMCBhdCAxOjU2IEFNIFRv
cnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5v
cmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIHdv
dWxkIGFzc3VtZSBnaXZlbiB0aGUgc3RhdHVzIG9mIEpBUiwgd2UgZG9u4oCZdCB3YW50IHRvIGNo
YW5nZSBpdC4gQW5kIGFzIEkgc2FpZCwgdGhpcyBkaWZmZXJlbmNlIGRvZXMgbm90IGltcGFjdCBp
bnRlcm9wZXJhYmlsaXR5IGZyb20gY2xpZW50IHBlcnNwZWN0aXZlLg0KDQoNCkFtIDA5LjAxLjIw
MjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9
NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0
Zi5vcmc+PjoNCg0KSXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRleHQg
dG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8g
cmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdo
dHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcgUEFSIHNwZWNpYWwgdHJlYXRtZW50Lg0KDQoNCg0K
V2hhdCBpZiB3ZSBjaGFuZ2VkIHRoaXMgc2VudGVuY2UgaW4gU2VjdGlvbiA1LjIgb2YgSkFSOg0K
DQpUaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNU
IGJlIGEgUmVxdWVzdA0KDQpPYmplY3QuDQoNCg0KDQpUbzoNCg0KVGhlIGNvbnRlbnRzIG9mIHRo
ZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJlcXVlc3QNCg0KT2Jq
ZWN0LCB1bmxlc3MgdGhlIFVSSSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0
aG9yaXphdGlvbg0KDQpTZXJ2ZXIuDQoNCg0KDQpUaGlzIHdvdWxkIGFsbG93IGZvciB1c2UgY2Fz
ZXMgc3VjaCBhcyBhbiBBUyB0aGF0IHByb3ZpZGVzIHByZS1kZWZpbmVkIHJlcXVlc3QgVVJJcywg
b3IgdmVuZHMgcmVxdWVzdCBVUklzIHZpYSBhIGNsaWVudCBtYW5hZ2VtZW50IGNvbnNvbGUsIG9y
IGJha2VzIHRoZW0gaW50byB0aGVpciBjbGllbnQgYXBwcy4NCg0KDQoNCuKAkw0KDQpBbm5hYmVs
bGUgUmljaGFyZCBCYWNrbWFuDQoNCkFXUyBJZGVudGl0eQ0KDQoNCg0KT24gMS84LzIwLCAyOjUw
IFBNLCAiVG9yc3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1h
cmMuaWV0Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3Jv
dGU6DQoNCg0KDQogICAgSGksDQoNCg0KDQogICAgeW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90
IHJlcXVpcmUgdGhlIEFTIHRvIHJlcHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCBy
ZXF1ZXN0IG9iamVjdC4gVGhlIFVSSSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5
LiBUaGF0IHdoeSB0aGUgZHJhZnQgc3RhdGVzDQoNCg0KDQogICAgIlRoZXJlIGlzIG5vIG5lZWQg
dG8gbWFrZSB0aGUNCg0KICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBkYXRhIGF2YWls
YWJsZSB0byBvdGhlciBwYXJ0aWVzIHZpYSB0aGlzDQoNCiAgICAgICAgICBVUkku4oCdDQoNCg0K
DQogICAgVGhpcyBkaWZmZXJlbmNlIG1hdHRlcnMgZnJvbSBhbiBBUyBpbXBsZW1lbnRhdGlvbiBw
ZXJzcGVjdGl2ZSwgaXQgZG9lc24ndCBtYXR0ZXIgZnJvbSBhIGNsaWVudCdzIChpbnRlcm9wKSBw
ZXJzcGVjdGl2ZS4NCg0KDQoNCiAgICBXZSBtYXkgYWRkIGEgc3RhdGVtZW50IHRvIFBBUiBzYXlp
bmcgdGhhdCByZXF1ZXN0X3VyaXMgaXNzdWVkIGJ5IHRoZSBQQVIgbWVjaGFuaXNtIChNQVkpIGRl
dmlhdGUgZnJvbSB0aGUgSkFSIGRlZmluaXRpb24uDQoNCg0KDQogICAgYmVzdCByZWdhcmRzLA0K
DQogICAgVG9yc3Rlbi4NCg0KDQoNCiAgICA+IE9uIDguIEphbiAyMDIwLCBhdCAyMzo0MiwgUmlj
aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRm
Lm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCiAgICA+
DQoNCiAgICA+IEhpIGFsbCwNCg0KICAgID4NCg0KICAgID4gVGhlIGN1cnJlbnQgZHJhZnRzIG9m
IFBBUiAoLTAwKSBhbmQgSkFSICgtMjApIHJlcXVpcmUgdGhhdCB0aGUgQVMgdHJhbnNmb3JtIGFs
bCBwdXNoZWQgcmVxdWVzdHMgaW50byBKV1RzLiBUaGlzIHJlcXVpcmVtZW50IGFyaXNlcyBmcm9t
IHRoZSBmb2xsb3dpbmc6DQoNCiAgICA+ICAgICAgICAg4oCiIFBBUiB1c2VzIHRoZSByZXF1ZXN0
X3VyaSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBKQVIgdG8gY29tbXVuaWNhdGUgdGhlIHB1c2hlZCBy
ZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50Lg0KDQogICAgPiAgICAgICAgIOKA
oiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1ZXN0X3Vy
aSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMikNCg0KICAgID4gICAgICAg
ICDigKIgUmVxdWVzdCBPYmplY3QgaXMgZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5nIGFs
bCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSkNCg0K
ICAgID4NCg0KICAgID4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudCB0byBz
dXBwb3J0IGludGVyb3BlcmFiaWxpdHksIGFzIHRoaXMgaXMgaW50ZXJuYWwgdG8gdGhlIEFTLiBJ
dCBpcyBhbHNvIGluY29uc2lzdGVudCB3aXRoIHRoZSByZXN0IG9mIEpBUiwgd2hpY2ggYXZvaWRz
IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBpbnRlcm5hbCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVu
IHRoZSB0d28gQVMgZW5kcG9pbnRzLiBXb3JzZSwgdGhpcyByZXN0cmljdGlvbiBtYWtlcyBpdCBo
YXJkZXIgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGxldmVyYWdlIHZhbGlkYXRp
b24gYW5kIG90aGVyIHdvcmsgcGVyZm9ybWVkIGF0IHRoZSBQQVIgZW5kcG9pbnQsIGFzIHRoZSBz
dGF0ZSBvciBvdXRjb21lIG9mIHRoYXQgd29yayBtdXN0IGJlIGZvcmNlZCBpbnRvIHRoZSBKV1Qg
Zm9ybWF0IChvciByZXRyaWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNhbGwgb3IgZGF0
YWJhc2UgbG9va3VwKS4NCg0KICAgID4NCg0KICAgID4g4oCTDQoNCiAgICA+IEFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW4NCg0KICAgID4gQVdTIElkZW50aXR5DQoNCiAgICA+DQoNCiAgICA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICA+IE9B
dXRoIG1haWxpbmcgbGlzdA0KDQogICAgPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQoNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05G
SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh
bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg
Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l
ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0
YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElU
WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl
Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz
KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg
aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11
bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi
eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg
ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo=

--_000_CAC46A6B229C4B5AAEE3A2D8662A81DBamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIg
MCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v
cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z
b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K
CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5Db3JyZWN0LiBUaGUgcHJvYmxlbSBiZWNvbWVzIHByZXR0eSBjbGVhciBpbiB0aGUg
Y29udGV4dCBvZiBQQVIsIHdoZXJlIHRoZSBBUyBpcyBnZW5lcmF0aW5nIGFuZCB2ZW5kaW5nIG91
dCB0aGUgVVJJIGF0IHRoZSBQQVIgZW5kcG9pbnQsIGFuZCBjb25zdW1pbmcgaXQgYXQgdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQuIEZyb20gYW4gaW50ZXJvcGVyYWJpbGl0eSBzdGFuZHBvaW50
LCBpdOKAmXMgYW5hbG9nb3VzDQogdG8gdGhlIEFTIHZlbmRpbmcgYW4gYXV0aG9yaXphdGlvbiBj
b2RlIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFuZCBjb25zdW1pbmcgaXQgYXQgdGhl
IHRva2VuIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmlj
aGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Kb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2
ZTdqdGIuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEphbnVhcnkgMTAsIDIwMjAg
YXQgMTI6MjkgUE08YnI+DQo8Yj5UbzogPC9iPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlRvcnN0ZW4gTG9kZGVyc3RlZHQg
Jmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OywgTmF0IFNha2ltdXJhICZsdDtuYXRAc2Fr
aW11cmEub3JnJmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0
O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gUEFS
OiBwdXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUgSldUczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFzc3Vt
ZSB0aGUgY2xpZW50IHBvc3RzIGEgSkFSIGFuZCBnZXRzIGJhY2sgYSByZWZlcmVuY2UuJm5ic3A7
IFRoZW4gdGhlIHJlZmVyZW5jZSBpcyB0byBhIEpBUi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBJIHNlZSB0aGUgcHJv
YmxlbS4mbmJzcDsgSWYgdGhlIHNlcnZlciBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZSBpcyBhc3Nv
Y2lhdGVkIHdpdGggdGhlIEFTIHRoZW4gdGhlIHNlcnZlciBkb3Nlbid0IG5lZWQgdG8gZGVyZWZl
cmVuY2UgdGhlIG9iamVjdCB2aWEgSFRUUCwgc28gaXQgY291bGQgYmUgYSBVUk4gYXMgYW4gZXhh
bXBsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U28geWVzIGl0IGlzIG5vdCBhIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgZm9yIHRo
ZSBjbGllbnQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCB0aGluayBhYm91dCBob3cgSSBjYW4gZmluZXNzZSB0
aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIGFncmVlIGl0IGlzIG5vdCBhIGNoYW5nZSBpbiBpbnRlbnQuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBz
ZWUgaWYgSSBjYW4gZ2V0IG91ciBBRCB0byBhY2NlcHQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG
cmksIEphbiAxMCwgMjAyMCwgNDo1NyBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUgYnV0IHRoZSB0ZXh0IHByb3Bvc2VkIChvciBz
b21ldGhpbmcgbGlrZSBpdCkgcXVhbGlmaWVzIGl0IHN1Y2ggdGhhdCB0aGVyZSBhcmVuJ3QgaW50
ZXJvcGVyYWJpbGl0eSBxdWVzdGlvbnMgYmVjYXVzZSBpdCdzIG9ubHkgYW4gaW1wbGVtZW50YXRp
b24gZGV0YWlsIHRvIHRoZSBBUyB3aG8gYm90aCBwcm9kdWNlcyB0aGUgVVJJIGFuZCBjb25zdW1l
cyBpdHMgY29udGVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+T24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTI6NDggUE0gSm9obiBCcmFkbGV5ICZsdDs8
YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJA
dmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtYXkgYmUgYSBjaGFs
bGVuZ2UgdG8gY2hhbmdlIHRleHQgc2F5aW5nIHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSByZXNv
dXJjZSBjb3VsZCBiZSBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIHJlcXVlc3Qgb2JqZWN0LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
ZiBub3QgYSByZXF1ZXN0IG9iamVjdCB0aGVuIHdoYXQgYW5kIGhvdyBpcyB0aGF0IGludGVyb3Bl
cmFibGUgYXJlIGxpa2VseSBBRCBxdWVzdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY291bGQgcGVyaGFwcyBzZWUgY2hh
bmdpbmcgaXQgdG8gbXVzdCBiZSBhIHJlcXVlc3Qgb2JqZWN0LCBvciBvdGhlciBmb3JtYXQgZGVm
aW5lZCBieSBhIHByb2ZpbGUuPGJyPg0KPGJyPg0KSm9obiBCLiZuYnNwOyZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBK
YW4gMTAsIDIwMjAsIDM6NDUgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpi
Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5n
aWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0
OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlIGFuZCBhZ3Jl
ZS4gQnV0IGdpdmVuIHRoYXQgdGhlIGNoYW5nZSBzdWdnZXN0ZWQgYnkgQW5uYWJlbGxlIGhhcyBu
byBpbXBhY3Qgb24gdGhlIGNsaWVudCBvciBpbnRlcm9wZXJhYmlsaXR5LCBwZXJoYXBzIE5hdCBv
ciBKb2huIGNvdWxkIHdvcmsgdGhlIGNoYW5nZSBpbnRvIHRoZSBkcmFmdCBkdXJpbmcgdGhlIGVk
aXRzIHRoYXQgaGFwcGVuIGR1cmluZyB0aGUgZmluYWwgc3RhZ2VzIG9mIHRoaW5ncz8NCjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gOSwg
MjAyMCBhdCAxOjU2IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49PGEgaHJlZj0i
bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSB3b3VsZCBhc3N1bWUgZ2l2ZW4gdGhlIHN0YXR1cyBvZiBKQVIsIHdlIGRvbuKAmXQg
d2FudCB0byBjaGFuZ2UgaXQuIEFuZCBhcyBJIHNhaWQsIHRoaXMgZGlmZmVyZW5jZSBkb2VzIG5v
dCBpbXBhY3QgaW50ZXJvcGVyYWJpbGl0eSBmcm9tIGNsaWVudCBwZXJzcGVjdGl2ZS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv
dHRvbToxMi4wcHQiPkFtIDA5LjAxLjIwMjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJhY2tt
YW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBk
bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9y
ZzwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPHA+SXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRleHQg
dG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8g
cmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdo
dHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcgUEFSIHNwZWNpYWwgdHJlYXRtZW50LjxvOnA+PC9v
OnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5XaGF0IGlmIHdlIGNoYW5nZWQg
dGhpcyBzZW50ZW5jZSBpbiBTZWN0aW9uIDUuMiBvZiBKQVI6PG86cD48L286cD48L3A+DQo8cCBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij5UaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQg
YnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPk9iamVjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxwPlRvOiA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSB0aGUgVVJJIE1V
U1QgYmUgYSBSZXF1ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+T2JqZWN0LCB1bmxlc3MgdGhlIFVSSSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBieSB0
aGUgQXV0aG9yaXphdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPlNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwPlRoaXMgd291bGQgYWxsb3cgZm9yIHVzZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQg
cHJvdmlkZXMgcHJlLWRlZmluZWQgcmVxdWVzdCBVUklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMg
dmlhIGEgY2xpZW50IG1hbmFnZW1lbnQgY29uc29sZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWly
IGNsaWVudCBhcHBzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
cD7igJMgPG86cD48L286cD48L3A+DQo8cD5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48
L286cD48L3A+DQo8cD5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPHA+T24gMS84LzIwLCAyOjUwIFBNLCAmcXVvdDtUb3JzdGVuIExvZGRlcnN0
ZWR0JnF1b3Q7ICZsdDt0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBk
bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmll
dGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBIaSwgPG86cD48L286cD48L3A+DQo8cD4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO3lvdSBhcmUgcmlnaHQsIFBBUiBkb2VzIG5vdCByZXF1aXJlIHRoZSBBUyB0byByZXBy
ZXNlbnQgdGhlIHJlcXVlc3QgYXMgYSBKV1QtYmFzZWQgcmVxdWVzdCBvYmplY3QuIFRoZSBVUkkg
aXMgdXNlZCBhcyBpbnRlcm5hbCByZWZlcmVuY2Ugb25seS4gVGhhdCB3aHkgdGhlIGRyYWZ0IHN0
YXRlcw0KPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O1RoZXJlIGlzIG5vIG5l
ZWQgdG8gbWFrZSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0
YSBhdmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHA+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVS
SS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv
cD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZy
b20gYW4gQVMgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZy
b20gYSBjbGllbnQncyAoaW50ZXJvcCkgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3A+DQo8cD4m
bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtXZSBtYXkgYWRkIGEgc3RhdGVtZW50IHRvIFBBUiBzYXlpbmcgdGhhdCByZXF1ZXN0X3Vy
aXMgaXNzdWVkIGJ5IHRoZSBQQVIgbWVjaGFuaXNtIChNQVkpIGRldmlhdGUgZnJvbSB0aGUgSkFS
IGRlZmluaXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmVzdCByZWdhcmRz
LDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvcnN0ZW4uJm5ic3A7IDxv
OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+
DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IE9uIDguIEphbiAyMDIwLCBhdCAyMzo0
MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0
bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5j
b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw
OyZuYnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jmd0OyBIaSBhbGwsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsg
Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZn
dDsgVGhlIGN1cnJlbnQgZHJhZnRzIG9mIFBBUiAoLTAwKSBhbmQgSkFSICgtMjApIHJlcXVpcmUg
dGhhdCB0aGUgQVMgdHJhbnNmb3JtIGFsbCBwdXNoZWQgcmVxdWVzdHMgaW50byBKV1RzLiBUaGlz
IHJlcXVpcmVtZW50IGFyaXNlcyBmcm9tIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8
cD4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsg4oCiIFBBUiB1c2VzIHRoZSByZXF1ZXN0X3VyaSBwYXJhbWV0ZXIgZGVmaW5l
ZCBpbiBKQVIgdG8gY29tbXVuaWNhdGUgdGhlIHB1c2hlZCByZXF1ZXN0IHRvIHRoZSBhdXRob3Jp
emF0aW9uIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBBY2NvcmRp
bmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1ZXN0X3VyaSBNVVNUIGJl
IGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMik8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw
OyZuYnNwOyZuYnNwOyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyDigKIgUmVxdWVzdCBPYmplY3QgaXMgZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5n
IGFsbCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSk8
bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7IDxvOnA+PC9v
OnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGVyZSBpcyBubyBuZWVk
IGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhp
cyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlzIGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhl
IHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGludGVy
bmFsIGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlIHR3byBBUyBlbmRwb2ludHMuIFdvcnNlLCB0
aGlzDQogcmVzdHJpY3Rpb24gbWFrZXMgaXQgaGFyZGVyIGZvciB0aGUgYXV0aG9yaXphdGlvbiBl
bmRwb2ludCB0byBsZXZlcmFnZSB2YWxpZGF0aW9uIGFuZCBvdGhlciB3b3JrIHBlcmZvcm1lZCBh
dCB0aGUgUEFSIGVuZHBvaW50LCBhcyB0aGUgc3RhdGUgb3Igb3V0Y29tZSBvZiB0aGF0IHdvcmsg
bXVzdCBiZSBmb3JjZWQgaW50byB0aGUgSldUIGZvcm1hdCAob3IgcmV0cmlldmVkIHZpYSBhIHN1
YnNlcXVlbnQgc2VydmljZSBjYWxsIG9yIGRhdGFiYXNlDQogbG9va3VwKS48bzpwPjwvbzpwPjwv
cD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHA+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyDigJMgPG86cD48L286cD48L3A+DQo8cD4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwv
bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEFXUyBJZGVudGl0eTxvOnA+PC9v
OnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgPG86cD48L286cD48L3A+
DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsm
bmJzcDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZu
YnNwOyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgPG86
cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0
IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h
eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv
bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBk
aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl
ZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl
dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl
ci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRl
cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJ
Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h
dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55
IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz
dHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t
dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg
YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz
IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CAC46A6B229C4B5AAEE3A2D8662A81DBamazoncom_--


From nobody Fri Jan 10 12:56: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 8108C120100 for ; Fri, 10 Jan 2020 12:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m23Q0YN5FdE for ; Fri, 10 Jan 2020 12:56:04 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159F5120111 for ; Fri, 10 Jan 2020 12:56:03 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00AKttb9017462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 15:55:57 -0500
From: Justin Richer 
Message-Id: <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CE1F738F-3E7F-4B65-B17B-4B9E5F6E2AA5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 10 Jan 2020 15:55:55 -0500
In-Reply-To: 
Cc: John Bradley , Brian Campbell , oauth , Nat Sakimura 
To: "Richard Backman, Annabelle" 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>     
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 20:56:08 -0000

--Apple-Mail=_CE1F738F-3E7F-4B65-B17B-4B9E5F6E2AA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

So we could solve this by saying the resulting data object of a PAR is a =
request object. Which might also contain a request object internally as =
well. In that case JAR should back off from saying it=E2=80=99s a JWT =
and instead say it=E2=80=99s a request object. Or we define a new term =
for this authorization request blob thing.

Or PAR could at least say that if it=E2=80=99s dereferenced over a =
remote protocol then it MUST be a JWT, but otherwise it can be whatever =
you want. That=E2=80=99s where the real interop concerns come in.

 =E2=80=94 Justin

> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
 wrote:
>=20
> Correct. The problem becomes pretty clear in the context of PAR, where =
the AS is generating and vending out the URI at the PAR endpoint, and =
consuming it at the authorization endpoint. =46rom an interoperability =
standpoint, it=E2=80=99s analogous to the AS vending an authorization =
code at the authorization endpoint and consuming it at the token =
endpoint.
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: John Bradley 
> Date: Friday, January 10, 2020 at 12:29 PM
> To: Brian Campbell 
> Cc: Torsten Lodderstedt , Nat Sakimura =
, "Richard Backman, Annabelle" , =
oauth 
> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must =
become JWTs
> =20
> If we assume the client posts a JAR and gets back a reference.  Then =
the reference is to a JAR.=20
> =20
> I think I see the problem.  If the server providing the reference is =
associated with the AS then the server dosen't need to dereference the =
object via HTTP, so it could be a URN as an example.=20
> =20
> So yes it is not a interoperability issue for the client. =20
> =20
> I will think about how I can finesse that.=20
> =20
> I agree it is not a change in intent.=20
> =20
> I will see if I can get our AD to accept that.
> =20
> John B.=20
> =20
> =20
> =20
> =20
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>> Sure but the text proposed (or something like it) qualifies it such =
that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>> =20
>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley > wrote:
>>> It may be a challenge to change text saying that the contents of the =
resource could be something other than a request object.=20
>>> =20
>>> If not a request object then what and how is that interoperable are =
likely AD questions.=20
>>> =20
>>> I could perhaps see changing it to must be a request object, or =
other format defined by a profile.
>>>=20
>>> John B. =20
>>> =20
>>> =20
>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>> Agree and agree. But given that the change suggested by Annabelle =
has no impact on the client or interoperability, perhaps Nat or John =
could work the change into the draft during the edits that happen during =
the final stages of things?
>>>> =20
>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>> I would assume given the status of JAR, we don=E2=80=99t want to =
change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>=20
>>>>>=20
>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>=20
>>>>>> It would be more appropriate to add the text to JAR rather than =
PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving the =
text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>> =20
>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>=20
>>>>>> Object.
>>>>>>=20
>>>>>> =20
>>>>>> To:=20
>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>=20
>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>=20
>>>>>> Server.
>>>>>>=20
>>>>>> =20
>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>> =20
>>>>>> =E2=80=93=20
>>>>>> Annabelle Richard Backman
>>>>>> AWS Identity
>>>>>> =20
>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>> =20
>>>>>>     Hi,=20
>>>>>>    =20
>>>>>>     you are right, PAR does not require the AS to represent the =
request as a JWT-based request object. The URI is used as internal =
reference only. That why the draft states
>>>>>>    =20
>>>>>>     "There is no need to make the
>>>>>>           authorization request data available to other parties =
via this
>>>>>>           URI.=E2=80=9D
>>>>>>    =20
>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>    =20
>>>>>>     We may add a statement to PAR saying that request_uris issued =
by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>    =20
>>>>>>     best regards,
>>>>>>     Torsten. =20
>>>>>>    =20
>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>     >=20
>>>>>>     > Hi all,
>>>>>>     > =20
>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require that =
the AS transform all pushed requests into JWTs. This requirement arises =
from the following:
>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>     >         =E2=80=A2 According to JAR, the resource referenced =
by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>     >         =E2=80=A2 Request Object is defined to be a JWT =
containing all the authorization request parameters. (Section 2.1)
>>>>>>     > =20
>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>     > =20
>>>>>>     > =E2=80=93=20
>>>>>>     > Annabelle Richard Backman
>>>>>>     > AWS Identity
>>>>>>     > =20
>>>>>>     > _______________________________________________
>>>>>>     > OAuth mailing list
>>>>>>     > OAuth@ietf.org 
>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_CE1F738F-3E7F-4B65-B17B-4B9E5F6E2AA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

So =
we could solve this by saying the resulting data object of a PAR is a =
request object. Which might also contain a request object internally as =
well. In that case JAR should back off from saying it=E2=80=99s a JWT =
and instead say it=E2=80=99s a request object. Or we define a new term =
for this authorization request blob thing.

Or PAR could at least say that if =
it=E2=80=99s dereferenced over a remote protocol then it MUST be a JWT, =
but otherwise it can be whatever you want. That=E2=80=99s where the real =
interop concerns come in.

 =E2=80=94 Justin

On Jan =
10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:

Correct. =
The problem becomes pretty clear in the context of PAR, where the AS is =
generating and vending out the URI at the PAR endpoint, and consuming it =
at the authorization endpoint. =46rom an interoperability standpoint, =
it=E2=80=99s analogous to the AS vending an authorization code at the =
authorization endpoint and consuming it at the token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, =
2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt =
<torsten@lodderstedt.net>, Nat Sakimura <nat@sakimura.org>, =
"Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: =
[OAUTH-WG] PAR: pushed requests must become JWTs
 
If we assume the client =
posts a JAR and gets back a reference.  Then the reference is to a =
JAR. 
 
I think I see the problem.  If the server providing the =
reference is associated with the AS then the server dosen't need to =
dereference the object via HTTP, so it could be a URN as an =
example. 
 
So yes it is not a interoperability issue for the =
client.  
 
I will think about how I can finesse that. 
 
I agree it is not a change in =
intent. 
 
I will see if I can get our AD to accept that.
 
John B. 
 
 
 
 
On Fri, =
Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com>=
 wrote:
Sure but the text proposed =
(or something like it) qualifies it such that there aren't =
interoperability questions because it's only an implementation detail to =
the AS who both produces the URI and consumes its content.
 
On Fri, Jan 10, 2020 at 12:48 PM John =
Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a challenge to change text =
saying that the contents of the resource could be something other than a =
request object. 
 
If not a request object then what and how is that =
interoperable are likely AD questions. 
 
I could perhaps see changing it to must =
be a request object, or other format defined by a profile.

John B.  
 
 
On Fri, =
Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree and agree. But given that the =
change suggested by Annabelle has no impact on the client or =
interoperability, perhaps Nat or John could work the change into the =
draft during the edits that happen during the final stages of =
things?
 
On Thu, Jan 9, 2020 at =
1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the status of JAR, =
we don=E2=80=99t want to change it. And as I said, this difference does =
not impact interoperability from client perspective.


Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
<richanna=3D40amazon.com@dmarc.ietf.org>:
It would be more appropriate to add the text =
to JAR rather than PAR. It doesn't seem right for PAR to retcon rules in =
JAR. Moving the text to JAR also highlights the weirdness of giving PAR =
special treatment.
 
What if we changed this sentence =
in Section 5.2 of JAR:
The contents of the resource referenced by the =
URI MUST be a Request
Object.
 
To: 
The contents =
of the resource referenced by the URI MUST be a Request
Object, =
unless the URI was provided to the client by the =
Authorization
Server.
 
This would =
allow for use cases such as an AS that provides pre-defined request =
URIs, or vends request URIs via a client management console, or bakes =
them into their client apps.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
On 1/8/20, 2:50 PM, "Torsten =
Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 
    Hi, 
    
    you are =
right, PAR does not require the AS to represent the request as a =
JWT-based request object. The URI is used as internal reference only. =
That why the draft states
    
    "There is no need to make the
          =
authorization request data available to other parties via this
          =
URI.=E2=80=9D
    
    This =
difference matters from an AS implementation perspective, it doesn't =
matter from a client's (interop) perspective.
    
    We may =
add a statement to PAR saying that request_uris issued by the PAR =
mechanism (MAY) deviate from the JAR definition.
    
    best =
regards,
    =
Torsten.  
    
    > On =
8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
    > 
    > Hi =
all,
    =
>  
    > The =
current drafts of PAR (-00) and JAR (-20) require that the AS transform =
all pushed requests into JWTs. This requirement arises from the =
following:
    =
>         =E2=80=A2 PAR uses the =
request_uri parameter defined in JAR to communicate the pushed request =
to the authorization endpoint.
    > =
        =E2=80=A2 According to JAR, =
the resource referenced by request_uri MUST be a Request Object. =
(Section 5.2)
    > =
        =E2=80=A2 Request Object is =
defined to be a JWT containing all the authorization request parameters. =
(Section 2.1)
    >  
    > =
There is no need for this requirement to support interoperability, as =
this is internal to the AS. It is also inconsistent with the rest of =
JAR, which avoids attempting to define the internal communications =
between the two AS endpoints. Worse, this restriction makes it harder =
for the authorization endpoint to leverage validation and other work =
performed at the PAR endpoint, as the state or outcome of that work must =
be forced into the JWT format (or retrieved via a subsequent service =
call or database lookup).
    >  
    > =
=E2=80=93 
    > =
Annabelle Richard Backman
    > AWS Identity
    =
>  
    > =
_______________________________________________
    > OAuth =
mailing list
   =
 > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth
    
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged material for the sole use of the intended recipient(s). =
Any review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, =
please notify the sender immediately by e-mail and delete the message =
and any file attachments from your computer. Thank =
you.
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D"">
CONFIDENTIALITY NOTICE: This email may contain =
confidential and privileged material for the sole use of the intended =
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=_CE1F738F-3E7F-4B65-B17B-4B9E5F6E2AA5--


From nobody Fri Jan 10 13:22: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 E7681120100 for ; Fri, 10 Jan 2020 13:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.518
X-Spam-Level: 
X-Spam-Status: No, score=-14.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3-53sxZ7kNM for ; Fri, 10 Jan 2020 13:22:16 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC2B1200CC for ; Fri, 10 Jan 2020 13:22:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578691336; x=1610227336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K69SGuYvsv/OUFx7Y+Izgb5dVhociwvPj/9fIxbDMZ4=; b=YDvA7ApQZCxuigdjQRafRel3VI/qc0DizZ5SbHrDuXoHaGgwzvzxd3/z mg8/JE7tdpqKVNvkrX0xTA88MxGdDieN+HRAfKrQnVCA4vmytLBgTOh40 iNRccPexRT5rLuM6XhE3frvoA/cmctwaMdXddWet3yz0PR1vDZ58Yrcek Y=;
IronPort-SDR: 7L/hUavI2456z0pMWfNSi97FEr5thbl6AVD8kfl2/c1Cyre/EcJFQL2zsaG17nsBTZecRlgm2y HwZZP0nF4hqw==
X-IronPort-AV: E=Sophos; i="5.69,418,1571702400"; d="scan'208,217"; a="11947881"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 10 Jan 2020 21:22:15 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id D9C9FA1F7F; Fri, 10 Jan 2020 21:22:12 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 21:22:11 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Jan 2020 21:22:10 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 10 Jan 2020 21:22:10 +0000
From: "Richard Backman, Annabelle" 
To: Dick Hardt , Neil Madden 
CC: Aaron Parecki , oauth , Mike Jones 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVx+drfYDyunsQfU+Jcs71iQJM4KfkQEeA//+h1wA=
Date: Fri, 10 Jan 2020 21:22:10 +0000
Message-ID: <99A2BC24-C265-48DB-9353-4CE4105ED435@amazon.com>
References:  <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.48]
Content-Type: multipart/alternative; boundary="_000_99A2BC24C26548DB93534CE4105ED435amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 10 Jan 2020 21:22:18 -0000

--_000_99A2BC24C26548DB93534CE4105ED435amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGF2aW5nIGRpZmZlcmVudCBKV0tTIFVSSXMgaW4gdGhlIG1ldGFkYXRhIGRvY3VtZW50IGZvciBk
aWZmZXJlbnQgcHVycG9zZXMgd291bGQgYWRkcmVzcyB0aGUgaXNzdWUsIGJ1dCBJ4oCZbSBub3Qg
c3VyZSBvZmYtaGFuZCBpZiB3ZSBjYW4gY2xlYXJseSBkZWxpbmVhdGUgcHVycG9zZXMgaW4gYSBy
b2J1c3Qgd2F5IHdpdGhvdXQgbWFraW5nIGl0IHRvbyBjb21wbGljYXRlZC4gU28gaXQgbWF5IGJl
IGNvcnJlY3QgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGFjY2VwdCB0aGUgc2l0dWF0aW9uIGZv
ciB3aGF0IGl0IGlzLg0KDQpIb3dldmVyLCBpZiB3ZSBkbyB0aGF0IHRoZW4gd2UgbmVlZCB0byBz
dG9wIHByZXRlbmRpbmcgdGhhdCDigJx1c2UgZGlmZmVyZW50IGtleXPigJ0gaXMgYSB2aWFibGUg
b3B0aW9uLiBUaGF0IHRvb2wgbmVlZHMgdG8gYmUgdG9zc2VkIG91dCBvZiB0aGUgdG9vbGJveCwg
YmVjYXVzZSBvdXIgc3BlY2lmaWNhdGlvbnMgZG8gbm90IGFsbG93IGltcGxlbWVudGVycyB0byBk
byB0aGF0IGluIGEgbWVhbmluZ2Z1bCB3YXkuIFRoZSBmYWN0IHRoYXQgd2XigJl2ZSB1c2VkIHRo
YXQgYXJndW1lbnQgZGVzcGl0ZSB0aGlzIGxpbWl0YXRpb24gZGVtb25zdHJhdGVzIHRoYXQgdGhp
cyBpcyBhIG5vbi1vYnZpb3VzIHJlc3VsdCBvZiB0aGUgdHJ1c3QgbW9kZWwgd2XigJl2ZSBhZG9w
dGVkLiBJZiB3ZSBzdGljayB3aXRoIHRoYXQgbW9kZWwsIHdlIG5lZWQgdG8gYmUgbW9yZSBjb25z
Y2lvdXMgb2YgdGhpcyBpc3N1ZSBpbiBvdXIgZnV0dXJlIHdvcmsuIFNvbWUgZG9jdW1lbnRzIHdp
bGwgbmVlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyB0aGF0IGRyYXcgYXR0ZW50aW9uIHRvIGl0
LCBvdGhlcnMgbWF5IG5lZWQgbW9yZSBhdHRlbnRpb24uIFdlIGFsc28gbmVlZCB0byByZWNvZ25p
emUgdGhhdCB3ZSB3aWxsIGJlIHJ1bGluZyBvdXQgY2VydGFpbiB0eXBlcyBvZiBkZXBsb3ltZW50
cywgYW5kIGNlcnRhaW4gdXNlIGNhc2VzLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt
YW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu
Y29tPg0KRGF0ZTogRnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIGF0IDExOjAwIEFNDQpUbzogTmVp
bCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+DQpDYzogQWFyb24gUGFyZWNraSA8
YWFyb25AcGFyZWNraS5jb20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+LCBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi
IDxyaWNoYW5uYUBhbWF6b24uY29tPg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTog
W09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJFOiBDcnlwdG9ncmFwaGljIGh5Z2llbmUg
YW5kIHRoZSBsaW1pdHMgb2Ygandrc191cmkNCg0KVG8gcmVzdGF0ZSBteSBwcmV2aW91cyBwb2lu
dCwgd2UgbWF5IG5vdCBiZSBhYmxlIHRvIGNoYW5nZSB3aGF0IGlzIGN1cnJlbnRseSBzcGVjaWZp
ZWQgYW5kIGRlcGxveWVkLCBidXQgd2UgY2FuIGZvciBmdXR1cmUgZXh0ZW5zaW9ucyBzdWNoIGFz
IFJBUiBhbmQgUEFSLg0KDQpUbyBwYXJhcGhyYXNlIEFubmFiZWxsZSwgdGhpcyBzaGlwIG1heSBo
YXZlIGFscmVhZHkgc2FpbGVkLg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMDo1MiBBTSBE
aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j
b20+PiB3cm90ZToNClRoZSBtZXRhZGF0YSBkb2N1bWVudCBpcyBkZWNsYXJhdGl2ZSwgYW5kIGNh
biBlYXNpbHkgYmUgeWV0IGFub3RoZXIgc2VwYXJhdGUgcm9sZSBpbiB0aGUgQVMuDQoNCkluIGxh
cmdlIG9yZ2FuaXphdGlvbnMsIGRpZmZlcmVudCBwZW9wbGUgYXJlIGVtcG93ZXJlZCBkaWZmZXJl
bnQgcm9sZXMsIHNvIHRoZSB0ZWFtIG93bmluZyB0aGUgbWV0YWRhdGEgZG9jdW1lbnQgY291bGQg
YmUgZGlmZmVyZW50IGZyb20gdGhlIHRlYW0gZ2VuZXJhdGluZyBJRCB0b2tlbnMsIGFuZCBkaWZm
ZXJlbnQgZnJvbSB0aGUgdGVhbSBnZW5lcmF0aW5nIEpXVHMuDQoNCg0KT24gRnJpLCBKYW4gMTAs
IDIwMjAgYXQgMTA6MjcgQU0gTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208
bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNClRoZSBwcm9ibGVtIHdp
dGggc3BlY2lmeWluZyBhIHByb3BlcnR5IG9uIHRoZSBrZXkgaXRzZWxmIGlzIHRoYXQgYSBtaWNy
b3NlcnZpY2UgbWlnaHQgbGllIGFib3V0IHdoYXQgaXTigJlzIGtleXMgYXJlIGZvci4gSSB0aGlu
ayB5b3UgZWl0aGVyIG5lZWQgc2VwYXJhdGUgZG9jdW1lbnRzIG9yIHNvbWUgc2VwYXJhdGUgbWV0
YWRhdGEgbWFwcGluZyB1c2VzIHRvIGtleSBpZHMuDQoNCuKAlCBOZWlsDQoNCg0KT24gMTAgSmFu
IDIwMjAsIGF0IDE4OjE5LCBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tpLmNvbTxtYWlsdG86
YWFyb25AcGFyZWNraS5jb20+PiB3cm90ZToNCiENCkNhbiB0aGUga2V5cyBpbiB0aGUgZG9jdW1l
bnQgYXQgdGhlIGp3a3NfdXJpIGluZGljYXRlIHdoYXQgdGhleSBhcmUgZm9yPyBFaXRoZXIgYnkg
YWRkaW5nIG90aGVyIHRvcC1sZXZlbCBwcm9wZXJ0aWVzIG5leHQgdG8gImtleXMiIG9yIGJ5IHNw
ZWNpZnlpbmcgYSBwcm9wZXJ0eSBvbiBhIGtleSBpdHNlbGY/IEF0IGxlYXN0IHRoYXQgd2F5IGlt
cGxlbWVudGF0aW9ucyB0aGF0IGV4cGVjdCBqdXN0IG9uZSB2YWx1ZSBvZiBqd2tzX3VyaSB3b3Vs
ZG4ndCBoYXZlIHRvIGNoYW5nZS4NCg0KQWFyb24NCg0KDQoNCk9uIEZyaSwgSmFuIDEwLCAyMDIw
IGF0IDEyOjE2IFBNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNr
LmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KWWVzLiBUaGFua3MgZm9yIGNsYXJpZnlpbmcuDQpb
aHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJu
YldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTM3MzQzNmE1LTI5NGYtNDhiNi1h
MDZkLTczYzU5ZmRhZmUwZF3hkKcNCg0KT24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTA6MTQgQU0g
VG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0
ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQpZb3UgbWVhbiBhZGRpdGlvbmFsIEpXS1MgVVJJ
cywgZm9yIGV4YW1wbGU/DQoNCg0KQW0gMTAuMDEuMjAyMCB1bSAxOTowOSBzY2hyaWViIERpY2sg
SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+
PjoNClBlcmhhcHMgSSBhbSBtaXN1bmRlcnN0YW5kaW5nIHdoYXQgQW5uYWJlbGxlIHdhcyBnZXR0
aW5nIGF0LCBidXQgaGF2aW5nIG1vcmUgdGhhbiBvbmUga2V5IGluIHRoZSBtZXRhZGF0YSBkb2N1
bWVudCB3b3VsZCBzb2x2ZSB0aGUgdGhlIGlzc3VlLiBJRSwgZXh0ZW5zaW9ucyB3b3VsZCBkZWZp
bmUgdGhlaXIgb3duIGtleSBpbnN0ZWFkIG9mIHVzaW5nIHRoZSBzYW1lIG9uZS4NCg0KVGhlIG1l
dGFkYXRhIGRvY3VtZW50IGl0c2VsZiB3YXMgYW4gZXh0ZW5zaW9uLg0KDQoNCk9uIEZyaSwgSmFu
IDEwLCAyMDIwIGF0IDk6NTggQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJz
dGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQoNCg0KPiBB
bSAxMC4wMS4yMDIwIHVtIDE4OjIzIHNjaHJpZWIgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFp
bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj46DQo+DQo+IEFzIE9BdXRoIDIuMCBo
YXMgYmVlbiBleHRlbmRlZCwgdGhlIEFTIGlzIG5vdyBhbHNvIGFuIE9wZW5JRCBDb25uZWN0IFBy
b3ZpZGVyLCBhbmQgdGhlIGFjY2VzcyB0b2tlbiBpcyBiZWluZyBkZWZpbmVkLiBUaGVzZSBleHRl
bnNpb25zIGhhdmUgYXNzdW1lZCBhbGwgb2YgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIGEgbW9ub2xp
dGguDQo+DQo+IEknbSBub3Qgc3VnZ2VzdGluZyB0aGF0IHdlIE1VU1QgbWFrZSBjaGFuZ2VzIHRv
IGV4aXN0aW5nIGV4dGVuc2lvbnMsIGJ1dCBkZXNpZ24gZnV0dXJlIGV4dGVuc2lvbnMgc28gdGhh
dCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gc2VwYXJhdGUgZHV0aWVzIGlmIGRlc2lyZWQuDQoNCkhv
dyBkbyB5b3UgZW52aXNpb24gdGhpcyB0byB3b3JrPyBBcyB5b3Ugc2FpZCwgT0F1dGggMi4wIGlz
IGJ1aWx0IG9uIHRoZSBhc3N1bXB0aW9uIHRoZSBBUyBpcyAoYXQgbGVhc3QgbG9naWNhbGx5KSBh
IG1vbm9saXRoLiBBbGwgZXh0ZW5zaW9uIHdlcmUgYnVpbHQgb24gdGhhdCB1bmRlcmx5aW5nIGFz
c3VtcHRpb24uIEkgZG9u4oCZdCBzZWUgaG93IGFuIGFyYml0cmFyeSBleHRlbnNpb24gY2FuIHJl
bGF4IHRoYXQgYXNzdW1wdGlvbiBhbmQgc3RpbGwgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSByZXN0
IChqdXN0IHJldmlzaXQgdGhlIGRpc2N1c3Npb24gcmUgUEFSIGFuZCBrZXlzKS4NCg0KSSB0aGlu
ayB3ZSBzaG91bGQgYWNjZXB0IHRoaXMgZGVzaWduIGFzc3VtcHRpb24sIGluIHRoZSBzYW1lIHdh
eSB3ZSBzaG91bGQgYWNjZXB0IGZvcm0gZW5jb2RpbmcgYXMgcmVxdWVzdCBmb3JtYXQgaW5zdGVh
ZCBvZiBKU09OLCBmb3IgT0F1dGggMi4wIGV4dGVuc2lvbnMuDQoNCk9BdXRoIDMuMCBjb3VsZCBl
eHBsaWNpdGVseSBiZSBkZXZlbG9wZWQgd2l0aCBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJlcyBpbiBt
aW5kLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KLS0NCi0tLS0NCkFh
cm9uIFBhcmVja2kNCmFhcm9ucGFyZWNraS5jb208aHR0cDovL2Fhcm9ucGFyZWNraS5jb20+DQpA
YWFyb25wazxodHRwOi8vdHdpdHRlci5jb20vYWFyb25waz4NCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_99A2BC24C26548DB93534CE4105ED435amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <89D1FC77BC6819438FD42C7B28ABEBE8@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut
MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy
aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJFdXBoZW1pYSBVQ0FTIjsNCglwYW5vc2UtMToyIDEx
IDUgMyA0IDEgMiAyIDEgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2
aW5nIGRpZmZlcmVudCBKV0tTIFVSSXMgaW4gdGhlIG1ldGFkYXRhIGRvY3VtZW50IGZvciBkaWZm
ZXJlbnQgcHVycG9zZXMgd291bGQgYWRkcmVzcyB0aGUgaXNzdWUsIGJ1dCBJ4oCZbSBub3Qgc3Vy
ZSBvZmYtaGFuZCBpZiB3ZSBjYW4gY2xlYXJseSBkZWxpbmVhdGUgcHVycG9zZXMgaW4gYSByb2J1
c3Qgd2F5IHdpdGhvdXQgbWFraW5nIGl0IHRvbyBjb21wbGljYXRlZC4gU28gaXQgbWF5IGJlIGNv
cnJlY3QgZm9yDQogdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWNjZXB0IHRoZSBzaXR1YXRpb24gZm9y
IHdoYXQgaXQgaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGlmIHdlIGRvIHRo
YXQgdGhlbiB3ZSBuZWVkIHRvIHN0b3AgcHJldGVuZGluZyB0aGF0IOKAnHVzZSBkaWZmZXJlbnQg
a2V5c+KAnSBpcyBhIHZpYWJsZSBvcHRpb24uIFRoYXQgdG9vbCBuZWVkcyB0byBiZSB0b3NzZWQg
b3V0IG9mIHRoZSB0b29sYm94LCBiZWNhdXNlIG91ciBzcGVjaWZpY2F0aW9ucyBkbyBub3QgYWxs
b3cgaW1wbGVtZW50ZXJzIHRvIGRvIHRoYXQgaW4gYSBtZWFuaW5nZnVsIHdheS4gVGhlDQogZmFj
dCB0aGF0IHdl4oCZdmUgdXNlZCB0aGF0IGFyZ3VtZW50IGRlc3BpdGUgdGhpcyBsaW1pdGF0aW9u
IGRlbW9uc3RyYXRlcyB0aGF0IHRoaXMgaXMgYSBub24tb2J2aW91cyByZXN1bHQgb2YgdGhlIHRy
dXN0IG1vZGVsIHdl4oCZdmUgYWRvcHRlZC4gSWYgd2Ugc3RpY2sgd2l0aCB0aGF0IG1vZGVsLCB3
ZSBuZWVkIHRvIGJlIG1vcmUgY29uc2Npb3VzIG9mIHRoaXMgaXNzdWUgaW4gb3VyIGZ1dHVyZSB3
b3JrLiBTb21lIGRvY3VtZW50cyB3aWxsIG5lZWQNCiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyB0
aGF0IGRyYXcgYXR0ZW50aW9uIHRvIGl0LCBvdGhlcnMgbWF5IG5lZWQgbW9yZSBhdHRlbnRpb24u
IFdlIGFsc28gbmVlZCB0byByZWNvZ25pemUgdGhhdCB3ZSB3aWxsIGJlIHJ1bGluZyBvdXQgY2Vy
dGFpbiB0eXBlcyBvZiBkZXBsb3ltZW50cywgYW5kIGNlcnRhaW4gdXNlIGNhc2VzLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKA
kyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv
bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOmJsYWNrIj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+
DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIGF0IDExOjAwIEFNPGJyPg0K
PGI+VG86IDwvYj5OZWlsIE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDs8
YnI+DQo8Yj5DYzogPC9iPkFhcm9uIFBhcmVja2kgJmx0O2Fhcm9uQHBhcmVja2kuY29tJmd0Oywg
b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0OywgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25l
c0BtaWNyb3NvZnQuY29tJmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVv
dDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZF
UklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBSRTogQ3J5
cHRvZ3JhcGhpYyBoeWdpZW5lIGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyByZXN0
YXRlIG15IHByZXZpb3VzIHBvaW50LCB3ZSBtYXkgbm90IGJlIGFibGUgdG8gY2hhbmdlIHdoYXQg
aXMgY3VycmVudGx5IHNwZWNpZmllZCBhbmQgZGVwbG95ZWQsIGJ1dCB3ZSBjYW4gZm9yIGZ1dHVy
ZSBleHRlbnNpb25zIHN1Y2ggYXMgUkFSIGFuZCBQQVIuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHBhcmFwaHJhc2UgQW5uYWJlbGxlLCB0aGlzIHNo
aXAgbWF5IGhhdmUgYWxyZWFkeSBzYWlsZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEwOjUyIEFN
IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIG1ldGFkYXRhIGRvY3VtZW50IGlzIGRlY2xhcmF0aXZlLCBhbmQgY2FuIGVhc2lseSBiZSB5
ZXQgYW5vdGhlciBzZXBhcmF0ZSZuYnNwO3JvbGUgaW4gdGhlIEFTLiZuYnNwOw0KPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBsYXJnZSBvcmdhbml6YXRp
b25zLCBkaWZmZXJlbnQgcGVvcGxlIGFyZSBlbXBvd2VyZWQgZGlmZmVyZW50IHJvbGVzLCBzbyB0
aGUgdGVhbSBvd25pbmcgdGhlIG1ldGFkYXRhIGRvY3VtZW50IGNvdWxkIGJlIGRpZmZlcmVudCZu
YnNwO2Zyb20gdGhlIHRlYW0gZ2VuZXJhdGluZyBJRCB0b2tlbnMsIGFuZCBkaWZmZXJlbnQgZnJv
bSB0aGUgdGVhbSBnZW5lcmF0aW5nIEpXVHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTA6Mjcg
QU0gTmVpbCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2su
Y29tIiB0YXJnZXQ9Il9ibGFuayI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvYmxlbSB3aXRoIHNwZWNpZnlpbmcgYSBwcm9wZXJ0
eSBvbiB0aGUga2V5IGl0c2VsZiBpcyB0aGF0IGEgbWljcm9zZXJ2aWNlIG1pZ2h0IGxpZSBhYm91
dCB3aGF0IGl04oCZcyBrZXlzIGFyZSBmb3IuIEkgdGhpbmsgeW91IGVpdGhlciBuZWVkIHNlcGFy
YXRlIGRvY3VtZW50cyBvciBzb21lIHNlcGFyYXRlIG1ldGFkYXRhIG1hcHBpbmcgdXNlcyB0byBr
ZXkgaWRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj7igJQgTmVpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gMTAgSmFuIDIwMjAsIGF0
IDE4OjE5LCBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5j
b20iIHRhcmdldD0iX2JsYW5rIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4hIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5DYW4gdGhlIGtleXMgaW4gdGhlIGRvY3VtZW50IGF0IHRoZSBqd2tzX3VyaSBpbmRpY2F0
ZSB3aGF0IHRoZXkgYXJlIGZvcj8gRWl0aGVyIGJ5IGFkZGluZyBvdGhlciB0b3AtbGV2ZWwgcHJv
cGVydGllcyBuZXh0IHRvICZxdW90O2tleXMmcXVvdDsgb3IgYnkgc3BlY2lmeWluZyBhIHByb3Bl
cnR5IG9uIGEga2V5IGl0c2VsZj8gQXQgbGVhc3QgdGhhdCB3YXkgaW1wbGVtZW50YXRpb25zIHRo
YXQgZXhwZWN0IGp1c3Qgb25lIHZhbHVlDQogb2Ygandrc191cmkgd291bGRuJ3QgaGF2ZSB0byBj
aGFuZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QWFyb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTI6MTYgUE0gRGljayBI
YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i
bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIFRo
YW5rcyBmb3IgY2xhcmlmeWluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0
dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJX
RnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTM3MzQzNmE1LTI5NGYt
NDhiNi1hMDZkLTczYzU5ZmRhZmUwZCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250
LWZhbWlseTomcXVvdDtFdXBoZW1pYSBVQ0FTJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUi
PuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEwOjE0IEFNIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0
OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsi
PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv
dSBtZWFuIGFkZGl0aW9uYWwgSldLUyBVUklzLCBmb3IgZXhhbXBsZT88bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPkFtIDEwLjAxLjIwMjAgdW0gMTk6MDkgc2NocmllYiBEaWNrIEhhcmR0ICZsdDs8YSBocmVm
PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0
QGdtYWlsLi5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgSSBhbSBtaXN1
bmRlcnN0YW5kaW5nIHdoYXQgQW5uYWJlbGxlIHdhcyBnZXR0aW5nIGF0LCBidXQgaGF2aW5nIG1v
cmUgdGhhbiBvbmUga2V5IGluIHRoZSBtZXRhZGF0YSBkb2N1bWVudCB3b3VsZCBzb2x2ZSB0aGUg
dGhlIGlzc3VlLiBJRSwgZXh0ZW5zaW9ucyB3b3VsZCBkZWZpbmUgdGhlaXIgb3duIGtleSBpbnN0
ZWFkIG9mIHVzaW5nIHRoZSBzYW1lIG9uZS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIG1ldGFkYXRhIGRvY3VtZW50IGl0c2VsZiB3YXMgYW4gZXh0
ZW5zaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDk6NTggQU0gVG9yc3RlbiBMb2Rk
ZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJn
ZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCiZndDsgQW0gMTAuMDEuMjAyMCB1bSAxODoyMyBzY2hyaWViIERpY2sgSGFyZHQgJmx0
OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRp
Y2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIE9BdXRo
IDIuMCBoYXMgYmVlbiBleHRlbmRlZCwgdGhlIEFTIGlzIG5vdyBhbHNvIGFuIE9wZW5JRCBDb25u
ZWN0IFByb3ZpZGVyLCBhbmQgdGhlIGFjY2VzcyB0b2tlbiBpcyBiZWluZyBkZWZpbmVkLiBUaGVz
ZSBleHRlbnNpb25zIGhhdmUgYXNzdW1lZCBhbGwgb2YgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIGEg
bW9ub2xpdGguDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQg
d2UgTVVTVCBtYWtlIGNoYW5nZXMgdG8gZXhpc3RpbmcgZXh0ZW5zaW9ucywgYnV0IGRlc2lnbiBm
dXR1cmUgZXh0ZW5zaW9ucyBzbyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGNhbiBzZXBhcmF0ZSBk
dXRpZXMgaWYgZGVzaXJlZC48YnI+DQo8YnI+DQpIb3cgZG8geW91IGVudmlzaW9uIHRoaXMgdG8g
d29yaz8gQXMgeW91IHNhaWQsIE9BdXRoIDIuMCBpcyBidWlsdCBvbiB0aGUgYXNzdW1wdGlvbiB0
aGUgQVMgaXMgKGF0IGxlYXN0IGxvZ2ljYWxseSkgYSBtb25vbGl0aC4gQWxsIGV4dGVuc2lvbiB3
ZXJlIGJ1aWx0IG9uIHRoYXQgdW5kZXJseWluZyBhc3N1bXB0aW9uLiBJIGRvbuKAmXQgc2VlIGhv
dyBhbiBhcmJpdHJhcnkgZXh0ZW5zaW9uIGNhbiByZWxheCB0aGF0IGFzc3VtcHRpb24gYW5kIHN0
aWxsDQogYmUgY29tcGF0aWJsZSB3aXRoIHRoZSByZXN0IChqdXN0IHJldmlzaXQgdGhlIGRpc2N1
c3Npb24gcmUgUEFSIGFuZCBrZXlzKS48YnI+DQo8YnI+DQpJIHRoaW5rIHdlIHNob3VsZCBhY2Nl
cHQgdGhpcyBkZXNpZ24gYXNzdW1wdGlvbiwgaW4gdGhlIHNhbWUgd2F5IHdlIHNob3VsZCBhY2Nl
cHQgZm9ybSBlbmNvZGluZyBhcyByZXF1ZXN0IGZvcm1hdCBpbnN0ZWFkIG9mIEpTT04sIGZvciBP
QXV0aCAyLjAgZXh0ZW5zaW9ucy4NCjxicj4NCjxicj4NCk9BdXRoIDMuMCBjb3VsZCBleHBsaWNp
dGVseSBiZSBkZXZlbG9wZWQgd2l0aCBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJlcyBpbiBtaW5kLjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo
IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYXJvbiBQYXJl
Y2tpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9ucGFy
ZWNraS5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vYWFyb25wayIgdGFyZ2V0PSJfYmxh
bmsiPkBhYXJvbnBrPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_99A2BC24C26548DB93534CE4105ED435amazoncom_--


From nobody Fri Jan 10 13:29: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 BFAE3120119 for ; Fri, 10 Jan 2020 13:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 LFIZRU4uOBty for ; Fri, 10 Jan 2020 13:29:13 -0800 (PST)
Received: from p3plsmtpa12-08.prod.phx3.secureserver.net (p3plsmtpa12-08.prod.phx3.secureserver.net [68.178.252.237]) (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 03A0012008C for ; Fri, 10 Jan 2020 13:29:12 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id q1qAiTGrbfh6jq1qBicMV4; Fri, 10 Jan 2020 14:29:12 -0700
To: Filip Skokan 
Cc: oauth@ietf.org
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com>
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>
Date: Fri, 10 Jan 2020 23:29:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000404020203050107070909"
X-CMAE-Envelope: MS4wfCUhJxpOq8sSuUggV30OiNc60w0JhiLK1EmF4gj0KnFhVpXejL/8QuZRy5eWTKMqUYNFmMmLF7j6/ZpbMAt6zdTHE8zwLw/qtX6E4+yzr1Q3byU3qrda 0zeEx5WAj+H0j78DZO+3pzm3R0cp3bQEDxdeJdsUZVbMbi18r3rWE0+CXa102oulLByM9wjHYlwAEwndA7kZWg3LGvM0Fqrof8w=
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 21:29:15 -0000

This is a cryptographically signed message in MIME format.

--------------ms000404020203050107070909
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Yes, putting the client_id into the JWE header is a way around the need
to have the client_id outside the JWE as top-level authZ request paramete=
r.

Unfortunately this work around isn't mentioned anywhere, I just checked
the most recent draft-ietf-oauth-jwsreq-20.

Our DDoS attack mitigation (for OIDC request_uri) also relies on the
presence of client_id as top-level parameter, together with requiring
RPs to register their request_uri's (so that we don't need to build and
store an index of all request_uri's). I just had a look at "DDoS Attack
on the Authorization Server" and also realised the request_uri
registration isn't explicitly mentioned as attack prevention ("the
server should (a) check that the value of "request_uri" parameter does
not point to an unexpected location").

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

To be honest, I feel quite bad about the situation with JAR we are in
now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other
OIDC bits that later became general purpose OAuth 2.0 specs.

I find it unfortunate I didn't notice this when I was reviewing the spec
in the past.

Vladimir


On 10/01/2020 22:39, Filip Skokan wrote:
> Vladimir,=20
>
> For that very case the payload claims may be repeated in the JWE protec=
ted header. An implementation wanting to handle this may look for iss/cli=
ent_id there.=20
>
> Odesl=C3=A1no z iPhonu
>
>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>>
>> =EF=BB=BFI just realised there is one class of JARs where it's practia=
lly
>> impossible to process the request if merge isn't supported:
>>
>> The client submits a JAR encrypted (JWT) with a shared key. OIDC allow=
s
>> for that and specs a method for deriving the shared key from the
>> client_secret:
>>
>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>>
>> If the JAR is encrypted with the client_secret, and there is no
>> top-level client_id parameter, there's no good way for the OP to find
>> out which client_secret to get to try to decrypt the JWE. Unless the O=
P
>> keeps an index of all issued client_secret's.
>>
>>
>> OP servers which require request_uri registration
>> (require_request_uri_registration=3Dtrue) and don't want to index all
>> registered request_uri's, also have no good way to process a request_u=
ri
>> if the client_id isn't present as top-level parameter.
>>
>>
>> Vladimir
>>
>>
>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>
>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>>> I think Torsten is speculating that is not a feature people use.  =20
>>> I=E2=80=99m still trying to understand the use case for merging signe=
d and unsigned parameters. Nat once explained a use case, where a client =
uses parameters signed by a 3rd party (some =E2=80=9Ecertification author=
ity=E2=80=9C) in combination with transaction-specific parameters. Is thi=
s being done in the wild?=20
>>>
>>> PS: PAR would work with both modes.



--------------ms000404020203050107070909
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTAyMTI5MTBaMC8G
CSqGSIb3DQEJBDEiBCDgxSYTaJuulZef1HlckiJtgvBWnbH/ZL2CTdOq1OUI6DBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAHXbu2oqPQ3ukw7GenaCKxhAPnlkp9YlQJ2IZ9zQZfUrY24G
3rmMXxCkaolzXCeSHs8jT1B9ztsUn8UoUkUg48pcBAwqL+25s8SiiIvSu4nnMAwkPm1kjIUg
UUkIGdhpY7WJc1ri2+sWyoVw8VFq+Q3wRZo2kdJiOOnvMs9dTGWnmQT7nE3gk1Z6VCKWxPM8
zY8k+SDVlDsAzAdtHEr8+mGfBDNRu3DudPPe/IlP0GQgqCanT0b9TOtVxbo7pTwBPd4WmFL1
wOE2QCyIZO97fey4gpcVO8TSpQmC2Z0ZNnj3s6I4XhUWgPLUfnagt2v/hCmThS8arSPJ236b
w8tmDWYAAAAAAAA=
--------------ms000404020203050107070909--


From nobody Fri Jan 10 14:14: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 3EC84120123 for ; Fri, 10 Jan 2020 14:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGtc8mMttDjy for ; Fri, 10 Jan 2020 14:14:51 -0800 (PST)
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 D1767120119 for ; Fri, 10 Jan 2020 14:14:50 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id d73so3595718wmd.1 for ; Fri, 10 Jan 2020 14:14:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGqtLBSjAFdN7yJqr8GAOHwyW5j0PYvogKQZwTa8bkg=; b=WLHBtFKSXpxnQ5avzZs/DaBMTxTQoc59Up2KlAxYqDO9diITpqZWjWqjGD1T9mSfNf NFH3275/Ae1l0SJWRcl3/yKd7flLebv9TMLVKgXKAAl2n7rU2cIUWXwukcohCfTwj7hv KSb1mbyhryHf80NdLTZffwFFNprJ5HTajXP5oJfK//whvqjm5zSpX1YaW5MfBYnJwXaZ Cj0nC91VuAhMiOQnKrXYDtJOzu6dFNDGStONEp4Ieq+FT6lIJIW80Oab4xlBZ8agDEQx GVO/wpAueKcAVIN4LnC7UIuZKuejUM0R6JYa25s9onbZxD8b/aXtrvRUHgRnnT+jk1px 1HOg==
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=AGqtLBSjAFdN7yJqr8GAOHwyW5j0PYvogKQZwTa8bkg=; b=kAsHo1HW0OnXHkT/q/w3nmnehhiH950HHe9q2wSXEkzvtaKVar0qK8fFKj+xrPgcpk pjWYjvE+euKO7+Ex/gC1aFmcbp9Be54vPPLIUhD3YwxB/GT1vtwEuRoa7yAOUGam/rCa +bxOUSh3Ytc4nkEfyTdr2RjW0Y+dXdkg5CcxlztXZhzKg7WIJJS+UzJeB55O+eApZJHt rSMC/nJ1DIeo20c37iXkKecAyjud4MxBrL8s6LnaaewpkGIJjYAT27YdhQArp0xAWB8K zDaepn897NDhNZC33O4NvBcne6AaS4CnGAzWoO5xiCgOk/vIYW61+ETdiqbaoYANUqIO CYQg==
X-Gm-Message-State: APjAAAX2PZo7rKzOLQy0X0nu1WuGN/tWAeUMj+uZ7zBPpXyw21g/+fpy kz4YvUmDc/Q9lyU00jEwfDxHrTSmRUWaZ8hYJxTtRg==
X-Google-Smtp-Source: APXvYqx+UDvF93mwPV/jH+HRHD/sCZVdGcquvXBR1HNDHB1UfLvynsndPPEnH4eMsgg6/3cOuy/6jGk7nhKhPw5BScc=
X-Received: by 2002:a1c:61c1:: with SMTP id v184mr6356315wmb.160.1578694489155;  Fri, 10 Jan 2020 14:14:49 -0800 (PST)
MIME-Version: 1.0
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>
In-Reply-To: <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>
From: John Bradley 
Date: Fri, 10 Jan 2020 19:14:36 -0300
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: Filip Skokan , IETF oauth WG 
Content-Type: multipart/alternative; boundary="0000000000003c3fd1059bd0747d"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 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, 10 Jan 2020 22:14:53 -0000

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

The intent was to do that, but specs change once the OAuth WG and IESG get
there hands on them.

Being backwards compatible with OIDC is not a compelling argument to the
IESG.

We were mostly thinking of asymmetric encryption.

Specifying puting the issuer and or the audience in the headder has come up
in the past but probably is not documented.

John B


On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov 
wrote:

> Yes, putting the client_id into the JWE header is a way around the need
> to have the client_id outside the JWE as top-level authZ request paramete=
r.
>
> Unfortunately this work around isn't mentioned anywhere, I just checked
> the most recent draft-ietf-oauth-jwsreq-20.
>
> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
> presence of client_id as top-level parameter, together with requiring
> RPs to register their request_uri's (so that we don't need to build and
> store an index of all request_uri's). I just had a look at "DDoS Attack
> on the Authorization Server" and also realised the request_uri
> registration isn't explicitly mentioned as attack prevention ("the
> server should (a) check that the value of "request_uri" parameter does
> not point to an unexpected location").
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>
> To be honest, I feel quite bad about the situation with JAR we are in
> now. For some reason I had the impression that OAuth JAR was going to be
> the OIDC request / request_uri for general OAuth 2.0 use, as with other
> OIDC bits that later became general purpose OAuth 2.0 specs.
>
> I find it unfortunate I didn't notice this when I was reviewing the spec
> in the past.
>
> Vladimir
>
>
> On 10/01/2020 22:39, Filip Skokan wrote:
> > Vladimir,
> >
> > For that very case the payload claims may be repeated in the JWE
> protected header. An implementation wanting to handle this may look for
> iss/client_id there.
> >
> > Odesl=C3=A1no z iPhonu
> >
> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
> >>
> >> =EF=BB=BFI just realised there is one class of JARs where it's practia=
lly
> >> impossible to process the request if merge isn't supported:
> >>
> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allow=
s
> >> for that and specs a method for deriving the shared key from the
> >> client_secret:
> >>
> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> >>
> >> If the JAR is encrypted with the client_secret, and there is no
> >> top-level client_id parameter, there's no good way for the OP to find
> >> out which client_secret to get to try to decrypt the JWE. Unless the O=
P
> >> keeps an index of all issued client_secret's.
> >>
> >>
> >> OP servers which require request_uri registration
> >> (require_request_uri_registration=3Dtrue) and don't want to index all
> >> registered request_uri's, also have no good way to process a request_u=
ri
> >> if the client_id isn't present as top-level parameter.
> >>
> >>
> >> Vladimir
> >>
> >>
> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> >>>
> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
> >>>> I think Torsten is speculating that is not a feature people use.
> >>> I=E2=80=99m still trying to understand the use case for merging signe=
d and
> unsigned parameters. Nat once explained a use case, where a client uses
> parameters signed by a 3rd party (some =E2=80=9Ecertification authority=
=E2=80=9C) in
> combination with transaction-specific parameters. Is this being done in t=
he
> wild?
> >>>
> >>> PS: PAR would work with both modes.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


The intent was to do that, but specs change once the=
 OAuth WG and IESG get there hands on them.=C2=A0=C2=A0
Being backwards compatible with OIDC is not a com=
pelling argument to the IESG.

We were mostly thinking of asymmetric encryption.=C2=A0=C2=A0

Specifying puting the issuer an=
d or the audience in the headder has come up in the past but probably is no=
t documented.=C2=A0=C2=A0

John B=C2=A0


On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrot=
e:
Yes, putting the client_id into =
the JWE header is a way around the need

to have the client_id outside the JWE as top-level authZ request parameter.=




Unfortunately this work around isn't mentioned anywhere, I just checked=


the most recent draft-ietf-oauth-jwsreq-20.



Our DDoS attack mitigation (for OIDC request_uri) also relies on the

presence of client_id as top-level parameter, together with requiring

RPs to register their request_uri's (so that we don't need to build=
 and

store an index of all request_uri's). I just had a look at "DDoS A=
ttack

on the Authorization Server" and also realised the request_uri

registration isn't explicitly mentioned as attack prevention ("the=


server should (a) check that the value of "request_uri" parameter=
 does

not point to an unexpected location").



https://tools.ietf.o=
rg/html/draft-ietf-oauth-jwsreq-20#section-10.4.1



To be honest, I feel quite bad about the situation with JAR we are in

now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other

OIDC bits that later became general purpose OAuth 2.0 specs.



I find it unfortunate I didn't notice this when I was reviewing the spe=
c

in the past.



Vladimir





On 10/01/2020 22:39, Filip Skokan wrote:

> Vladimir, 

>

> For that very case the payload claims may be repeated in the JWE prote=
cted header. An implementation wanting to handle this may look for iss/clie=
nt_id there. 

>

> Odesl=C3=A1no z iPhonu

>

>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <vladimir@connect2=
id.com>:

>>

>> =EF=BB=BFI just realised there is one class of JARs where it's=
 practially

>> impossible to process the request if merge isn't supported:
>>

>> The client submits a JAR encrypted (JWT) with a shared key. OIDC a=
llows

>> for that and specs a method for deriving the shared key from the
>> client_secret:

>>

>> https://openid.n=
et/specs/openid-connect-core-1_0.html#Encryption

>>

>> If the JAR is encrypted with the client_secret, and there is no
>> top-level client_id parameter, there's no good way for the OP =
to find

>> out which client_secret to get to try to decrypt the JWE. Unless t=
he OP

>> keeps an index of all issued client_secret's.

>>

>>

>> OP servers which require request_uri registration

>> (require_request_uri_registration=3Dtrue) and don't want to in=
dex all

>> registered request_uri's, also have no good way to process a r=
equest_uri

>> if the client_id isn't present as top-level parameter.

>>

>>

>> Vladimir

>>

>>

>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:

>>>

>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <ve7jtb@=
ve7jtb.com>:

>>>> I think Torsten is speculating that is not a feature peopl=
e use.=C2=A0 =C2=A0

>>> I=E2=80=99m still trying to understand the use case for mergin=
g signed and unsigned parameters. Nat once explained a use case, where a cl=
ient uses parameters signed by a 3rd party (some =E2=80=9Ecertification aut=
hority=E2=80=9C) in combination with transaction-specific parameters. Is th=
is being done in the wild? 

>>>

>>> PS: PAR would work with both modes.





_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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




--0000000000003c3fd1059bd0747d--


From nobody Fri Jan 10 16:41: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 0979912012D for ; Fri, 10 Jan 2020 16:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 quypq3F_kjuM for ; Fri, 10 Jan 2020 16:41:36 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650128.outbound.protection.outlook.com [40.107.65.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38886120120 for ; Fri, 10 Jan 2020 16:41:36 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OhU9DcKa0opGebfpdJrRhGoRMKmDx2w8/JXJgCctzXyTrC7wo80T2PNLL95bFsRNLba1J5pd5TKe5E6f2FIhfUIYKRicYDZxLbSiSRdNfkPtbIOakjY589ugiQMQ1x2xdjzSNwqa4krrvacOFIGWfDqa68m9US6cR229/88RMGrHaBzyKUO3QugU1r0IVD58/TeqywKkL1Waq1iETPw/qWPqL8Yi5EU+T9MYbpCrH5PVY79OGkV0pgD7xWLTQPAast8+QGqA5RzcovuNsNvs/yK1se6Vo878I1V4+YsQoSfcYPiR1Vwnvd4egt2mgesljV1bNR/KyZZUGtjBTtQW7A==
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=nKxQW0+L83LExBJIgI+zXpCz7TQs+Y/KcAvUL9NSD3Q=; b=IqepejVQyKJ/OuBdXfNw4xcdM/nUuAolNyWbOu4CAWONh3ZgRiFIJvu4JwSiE7XSAjTV2S2/StEO7uWZdHZipm1yHiqub5HNzMcD3ftsn4GOXcUkiHHViLAWy67wn8bWvsxVT7SuY/PSpBwOIEspe7ZqTqPkHG1jvY7J+X5mdekTIzof2/pEFcFO8Slpl6NWfP/q4fzE+A3AeaHXXeMPFoJdUIkuQ5f1z+TI2O2uRZnrx730hBYtCeM0LQIa7pS6jqyL2qeHKeYaFqSD48QKsKvp7+nTEoLkgvwDfxpcmEJFESvgWMDXX3A3mlDme2bvH4KDBpslerf2vJxYA3JHFw==
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=nKxQW0+L83LExBJIgI+zXpCz7TQs+Y/KcAvUL9NSD3Q=; b=D4yJ5Zfe0vdcJMHOiCQmwhI+HcLFnO4kDoL6wpUNf1lEjlBSsQemj4TfmWV9l6KFj+3s2L3CRION3Jd/AugLE2BsPrBFLbbW2YMytYhXEO9D8KDHQ6jGI1X5PJLO4OeXASma0iHRN3fBVoZH0qfcV5eRe94CNLaLyXi+/y1eyvE=
Received: from CH2PR00MB0843.namprd00.prod.outlook.com (10.186.139.150) by CH2PR00MB0780.namprd00.prod.outlook.com (10.186.139.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2669.0; Sat, 11 Jan 2020 00:41:33 +0000
Received: from CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::a116:aee3:2579:8104]) by CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::a116:aee3:2579:8104%8]) with mapi id 15.20.2668.000; Sat, 11 Jan 2020 00:41:33 +0000
From: Mike Jones 
To: John Bradley , Vladimir Dzhuvinov 
CC: IETF oauth WG 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVxFdFRSg/Wxr/G0+itQaCAzT9nKfePqqAgACvu4CABRMlAIAAA10AgAAOoICAACcyAIAAIu0AgAAF2QCAAA3QAIAADLEAgAAnlIA=
Date: Sat, 11 Jan 2020 00:41:33 +0000
Message-ID: 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.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=2317d277-ebe4-4204-b843-0000041a45d2; 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-01-11T00:36:15Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.92.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 38d10811-dfca-4dad-b741-08d7962f020a
x-ms-traffictypediagnostic: CH2PR00MB0780:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0279B3DD0D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(136003)(366004)(396003)(39860400002)(199004)(189003)(26005)(86362001)(316002)(8990500004)(4326008)(7696005)(5660300002)(6506007)(53546011)(66574012)(9686003)(55016002)(52536014)(71200400001)(110136005)(2906002)(478600001)(76116006)(66476007)(64756008)(66556008)(66446008)(66946007)(10290500003)(33656002)(186003)(81166006)(8936002)(8676002)(966005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0780; H:CH2PR00MB0843.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4Urf/pJW3e88++tSS5/mHBNE5Nmrktz6Vw1SMs1W5NPo9tui6fzA7jqDvEp+Lc370y35KfAMPTFVAj9WnEY3JIQSs+qgpVh0T2d6SdooaJKOZjL5o9FmSBW1kQnJf1pV6cUI6fKfKxR5b6zSw0RKX+EsSfkrCV8u5s+P6G03byhI8hjRmYV+rx/FlMgEEnpEdhVVl0Uy0P/YiC5VPy0SBIz6Z9zYQGw1euNHeVPwjRZFyYVzUOW251lbIvH9SgPQK0nLN6aLa761RBSuqzjYg/lhEgU0keI56Ms68cfqsCMYjFe4ka5GzEjuthjqGjYEGOyJ/WG8cqyOV4KK78sFzvpMEKKO4rmAiYLB/xkwyYxzsP6CrUwyRdB3nBuHv82hH5DUH4ejT79ep/MOCEqmXwFFLnpstooTvne6vwufX6WHPbrGLmaQYOFCYJ/FBVL1wXXNLriCFc+E71rfFEUU5YRd8xPkekm9VGaLZtVPCNgFCFd9cInpUM+DrLcPOuShq7VmHaOE53sXW4W68nRdhA==
x-ms-exchange-antispam-messagedata: yN/tP+Vv48OVEkg/+/g5poEjgpT3S2siAJdqYDtcm0ajzEMe/m97jmh2w3IkzBStPlUdJd+sD5a9CplTkrdGcwh2cd5aT8hLWTxlX9euTYd93F/nEQfF0M0ah+J2Z4f4vIOu0MdmUn3uZ93DUwy55A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0CH2PR00MB0843namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38d10811-dfca-4dad-b741-08d7962f020a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2020 00:41:33.6666 (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: iGG4EjxbY0z9zG17cAlV+LvfvHdI9UVIjBxIOIENDORx0CR7fKwXvO7JTs0uvu1wWpuDqHMx9m5cvvJQdPqiKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0780
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 11 Jan 2020 00:41:41 -0000

--_000_CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0CH2PR00MB0843namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHRlY2huaXF1ZSBvZiByZXBsaWNhdGluZyBKV1QgY2xhaW1zIHRoYXQgbmVlZCB0byBiZSBw
dWJsaWNseSB2aXNpYmxlIGluIGFuIGVuY3J5cHRlZCBKV1QgaW4gdGhlIGhlYWRlciBpcyBkZWZp
bmVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4zLiAg
KFRoYW5rcyB0byBEaWNrIEhhcmR0IGZvciBicmluZ2luZyB0aGlzIG5lZWQgdG8gbXkgYXR0ZW50
aW9uIGFzIHdlIHdlcmUgZmluaXNoaW5nIHRoZSBKV1Qgc3BlYy4pDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206
IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5
DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTAsIDIwMjAgMjoxNSBQTQ0KVG86IFZsYWRpbWlyIER6
aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQpDYzogSUVURiBvYXV0aCBXRyA8b2F1
dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIEpXVCBTZWN1
cmVkIEF1dGhvcml6YXRpb24gUmVxdWVzdCAoSkFSKSB2cyBPSURDIHJlcXVlc3Qgb2JqZWN0DQoN
ClRoZSBpbnRlbnQgd2FzIHRvIGRvIHRoYXQsIGJ1dCBzcGVjcyBjaGFuZ2Ugb25jZSB0aGUgT0F1
dGggV0cgYW5kIElFU0cgZ2V0IHRoZXJlIGhhbmRzIG9uIHRoZW0uDQoNCkJlaW5nIGJhY2t3YXJk
cyBjb21wYXRpYmxlIHdpdGggT0lEQyBpcyBub3QgYSBjb21wZWxsaW5nIGFyZ3VtZW50IHRvIHRo
ZSBJRVNHLg0KDQpXZSB3ZXJlIG1vc3RseSB0aGlua2luZyBvZiBhc3ltbWV0cmljIGVuY3J5cHRp
b24uDQoNClNwZWNpZnlpbmcgcHV0aW5nIHRoZSBpc3N1ZXIgYW5kIG9yIHRoZSBhdWRpZW5jZSBp
biB0aGUgaGVhZGRlciBoYXMgY29tZSB1cCBpbiB0aGUgcGFzdCBidXQgcHJvYmFibHkgaXMgbm90
IGRvY3VtZW50ZWQuDQoNCkpvaG4gQg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCwgNjoyOSBQTSBW
bGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1p
ckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KWWVzLCBwdXR0aW5nIHRoZSBjbGllbnRfaWQgaW50
byB0aGUgSldFIGhlYWRlciBpcyBhIHdheSBhcm91bmQgdGhlIG5lZWQNCnRvIGhhdmUgdGhlIGNs
aWVudF9pZCBvdXRzaWRlIHRoZSBKV0UgYXMgdG9wLWxldmVsIGF1dGhaIHJlcXVlc3QgcGFyYW1l
dGVyLg0KDQpVbmZvcnR1bmF0ZWx5IHRoaXMgd29yayBhcm91bmQgaXNuJ3QgbWVudGlvbmVkIGFu
eXdoZXJlLCBJIGp1c3QgY2hlY2tlZA0KdGhlIG1vc3QgcmVjZW50IGRyYWZ0LWlldGYtb2F1dGgt
andzcmVxLTIwLg0KDQpPdXIgRERvUyBhdHRhY2sgbWl0aWdhdGlvbiAoZm9yIE9JREMgcmVxdWVz
dF91cmkpIGFsc28gcmVsaWVzIG9uIHRoZQ0KcHJlc2VuY2Ugb2YgY2xpZW50X2lkIGFzIHRvcC1s
ZXZlbCBwYXJhbWV0ZXIsIHRvZ2V0aGVyIHdpdGggcmVxdWlyaW5nDQpSUHMgdG8gcmVnaXN0ZXIg
dGhlaXIgcmVxdWVzdF91cmkncyAoc28gdGhhdCB3ZSBkb24ndCBuZWVkIHRvIGJ1aWxkIGFuZA0K
c3RvcmUgYW4gaW5kZXggb2YgYWxsIHJlcXVlc3RfdXJpJ3MpLiBJIGp1c3QgaGFkIGEgbG9vayBh
dCAiRERvUyBBdHRhY2sNCm9uIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciIgYW5kIGFsc28gcmVh
bGlzZWQgdGhlIHJlcXVlc3RfdXJpDQpyZWdpc3RyYXRpb24gaXNuJ3QgZXhwbGljaXRseSBtZW50
aW9uZWQgYXMgYXR0YWNrIHByZXZlbnRpb24gKCJ0aGUNCnNlcnZlciBzaG91bGQgKGEpIGNoZWNr
IHRoYXQgdGhlIHZhbHVlIG9mICJyZXF1ZXN0X3VyaSIgcGFyYW1ldGVyIGRvZXMNCm5vdCBwb2lu
dCB0byBhbiB1bmV4cGVjdGVkIGxvY2F0aW9uIikuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMCNzZWN0aW9uLTEwLjQuMTxodHRwczovL25h
bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0
b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMCUyM3NlY3Rp
b24tMTAuNC4xJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD
YzQ3MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4NzkzMTkzJnNkYXRhPSUyRnZIVnA2OFNO
NUNBSGltcVo1ang5M2FPQ0lydXhxTENSTVVGQ2M1RFN4YyUzRCZyZXNlcnZlZD0wPg0KDQpUbyBi
ZSBob25lc3QsIEkgZmVlbCBxdWl0ZSBiYWQgYWJvdXQgdGhlIHNpdHVhdGlvbiB3aXRoIEpBUiB3
ZSBhcmUgaW4NCm5vdy4gRm9yIHNvbWUgcmVhc29uIEkgaGFkIHRoZSBpbXByZXNzaW9uIHRoYXQg
T0F1dGggSkFSIHdhcyBnb2luZyB0byBiZQ0KdGhlIE9JREMgcmVxdWVzdCAvIHJlcXVlc3RfdXJp
IGZvciBnZW5lcmFsIE9BdXRoIDIuMCB1c2UsIGFzIHdpdGggb3RoZXINCk9JREMgYml0cyB0aGF0
IGxhdGVyIGJlY2FtZSBnZW5lcmFsIHB1cnBvc2UgT0F1dGggMi4wIHNwZWNzLg0KDQpJIGZpbmQg
aXQgdW5mb3J0dW5hdGUgSSBkaWRuJ3Qgbm90aWNlIHRoaXMgd2hlbiBJIHdhcyByZXZpZXdpbmcg
dGhlIHNwZWMNCmluIHRoZSBwYXN0Lg0KDQpWbGFkaW1pcg0KDQoNCk9uIDEwLzAxLzIwMjAgMjI6
MzksIEZpbGlwIFNrb2thbiB3cm90ZToNCj4gVmxhZGltaXIsDQo+DQo+IEZvciB0aGF0IHZlcnkg
Y2FzZSB0aGUgcGF5bG9hZCBjbGFpbXMgbWF5IGJlIHJlcGVhdGVkIGluIHRoZSBKV0UgcHJvdGVj
dGVkIGhlYWRlci4gQW4gaW1wbGVtZW50YXRpb24gd2FudGluZyB0byBoYW5kbGUgdGhpcyBtYXkg
bG9vayBmb3IgaXNzL2NsaWVudF9pZCB0aGVyZS4NCj4NCj4gT2Rlc2zDoW5vIHogaVBob251DQo+
DQo+PiAxMC4gMS4gMjAyMCB2IDIxOjE5LCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+Og0KPj4NCj4+IO+7
v0kganVzdCByZWFsaXNlZCB0aGVyZSBpcyBvbmUgY2xhc3Mgb2YgSkFScyB3aGVyZSBpdCdzIHBy
YWN0aWFsbHkNCj4+IGltcG9zc2libGUgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdCBpZiBtZXJnZSBp
c24ndCBzdXBwb3J0ZWQ6DQo+Pg0KPj4gVGhlIGNsaWVudCBzdWJtaXRzIGEgSkFSIGVuY3J5cHRl
ZCAoSldUKSB3aXRoIGEgc2hhcmVkIGtleS4gT0lEQyBhbGxvd3MNCj4+IGZvciB0aGF0IGFuZCBz
cGVjcyBhIG1ldGhvZCBmb3IgZGVyaXZpbmcgdGhlIHNoYXJlZCBrZXkgZnJvbSB0aGUNCj4+IGNs
aWVudF9zZWNyZXQ6DQo+Pg0KPj4gaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25u
ZWN0LWNvcmUtMV8wLmh0bWwjRW5jcnlwdGlvbjxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90
ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZvcGVuaWQubmV0JTJGc3BlY3Ml
MkZvcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sJTIzRW5jcnlwdGlvbiZkYXRhPTAyJTdDMDEl
N0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Q2M0NzBkNGVjNGJkMTRkNDgxYzBmMDhk
Nzk2MWE4YWJiJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz
NzE0MjkxMzA2ODc5MzE5MyZzZGF0YT1zb0s5dDdwenU1MDRpSUx1RE5GbkclMkJNTHhaUFAycE42
dWdFSjRaT3BxZDQlM0QmcmVzZXJ2ZWQ9MD4NCj4+DQo+PiBJZiB0aGUgSkFSIGlzIGVuY3J5cHRl
ZCB3aXRoIHRoZSBjbGllbnRfc2VjcmV0LCBhbmQgdGhlcmUgaXMgbm8NCj4+IHRvcC1sZXZlbCBj
bGllbnRfaWQgcGFyYW1ldGVyLCB0aGVyZSdzIG5vIGdvb2Qgd2F5IGZvciB0aGUgT1AgdG8gZmlu
ZA0KPj4gb3V0IHdoaWNoIGNsaWVudF9zZWNyZXQgdG8gZ2V0IHRvIHRyeSB0byBkZWNyeXB0IHRo
ZSBKV0UuIFVubGVzcyB0aGUgT1ANCj4+IGtlZXBzIGFuIGluZGV4IG9mIGFsbCBpc3N1ZWQgY2xp
ZW50X3NlY3JldCdzLg0KPj4NCj4+DQo+PiBPUCBzZXJ2ZXJzIHdoaWNoIHJlcXVpcmUgcmVxdWVz
dF91cmkgcmVnaXN0cmF0aW9uDQo+PiAocmVxdWlyZV9yZXF1ZXN0X3VyaV9yZWdpc3RyYXRpb249
dHJ1ZSkgYW5kIGRvbid0IHdhbnQgdG8gaW5kZXggYWxsDQo+PiByZWdpc3RlcmVkIHJlcXVlc3Rf
dXJpJ3MsIGFsc28gaGF2ZSBubyBnb29kIHdheSB0byBwcm9jZXNzIGEgcmVxdWVzdF91cmkNCj4+
IGlmIHRoZSBjbGllbnRfaWQgaXNuJ3QgcHJlc2VudCBhcyB0b3AtbGV2ZWwgcGFyYW1ldGVyLg0K
Pj4NCj4+DQo+PiBWbGFkaW1pcg0KPj4NCj4+DQo+Pj4gT24gMTAvMDEvMjAyMCAyMDoxMywgVG9y
c3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCj4+Pg0KPj4+Pj4gQW0gMTAuMDEuMjAyMCB1bSAxNjo1
MyBzY2hyaWViIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2
ZTdqdGIuY29tPj46DQo+Pj4+IEkgdGhpbmsgVG9yc3RlbiBpcyBzcGVjdWxhdGluZyB0aGF0IGlz
IG5vdCBhIGZlYXR1cmUgcGVvcGxlIHVzZS4NCj4+PiBJ4oCZbSBzdGlsbCB0cnlpbmcgdG8gdW5k
ZXJzdGFuZCB0aGUgdXNlIGNhc2UgZm9yIG1lcmdpbmcgc2lnbmVkIGFuZCB1bnNpZ25lZCBwYXJh
bWV0ZXJzLiBOYXQgb25jZSBleHBsYWluZWQgYSB1c2UgY2FzZSwgd2hlcmUgYSBjbGllbnQgdXNl
cyBwYXJhbWV0ZXJzIHNpZ25lZCBieSBhIDNyZCBwYXJ0eSAoc29tZSDigJ5jZXJ0aWZpY2F0aW9u
IGF1dGhvcml0eeKAnCkgaW4gY29tYmluYXRpb24gd2l0aCB0cmFuc2FjdGlvbi1zcGVjaWZpYyBw
YXJhbWV0ZXJzLiBJcyB0aGlzIGJlaW5nIGRvbmUgaW4gdGhlIHdpbGQ/DQo+Pj4NCj4+PiBQUzog
UEFSIHdvdWxkIHdvcmsgd2l0aCBib3RoIG1vZGVzLg0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp
bmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20l
N0NjNDcwZDRlYzRiZDE0ZDQ4MWMwZjA4ZDc5NjFhOGFiYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDI5MTMwNjg4MDMxNDUmc2RhdGE9a29iSCUyRnNH
VDdFbFNTVUNKdnUlMkZiaUFxblJDWHglMkI0U1pOSnNyTCUyRkN1VnljJTNEJnJlc2VydmVkPTA+
DQo=

--_000_CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0CH2PR00MB0843namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGUgdGVjaG5pcXVlIG9mIHJlcGxpY2F0aW5n
IEpXVCBjbGFpbXMgdGhhdCBuZWVkIHRvIGJlIHB1YmxpY2x5IHZpc2libGUgaW4gYW4gZW5jcnlw
dGVkIEpXVCBpbiB0aGUgaGVhZGVyIGlzIGRlZmluZWQgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4zIj5odHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTUuMzwvYT4uJm5ic3A7IChUaGFua3MgdG8gRGljayBI
YXJkdCBmb3IgYnJpbmdpbmcgdGhpcyBuZWVkIHRvIG15IGF0dGVudGlvbiBhcyB3ZSB3ZXJlIGZp
bmlzaGluZyB0aGUgSldUIHNwZWMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5P
biBCZWhhbGYgT2YgPC9iPg0KSm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg
SmFudWFyeSAxMCwgMjAyMCAyOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBWbGFkaW1pciBEemh1dmlu
b3YgJmx0O3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBv
YXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRF
Uk5BTF0gUmU6IFtPQVVUSC1XR10gSldUIFNlY3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChK
QVIpIHZzIE9JREMgcmVxdWVzdCBvYmplY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGUgaW50ZW50IHdhcyB0byBkbyB0aGF0LCBidXQgc3BlY3MgY2hhbmdlIG9uY2Ug
dGhlIE9BdXRoIFdHIGFuZCBJRVNHIGdldCB0aGVyZSBoYW5kcyBvbiB0aGVtLiZuYnNwOyZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVpbmcgYmFj
a3dhcmRzIGNvbXBhdGlibGUgd2l0aCBPSURDIGlzIG5vdCBhIGNvbXBlbGxpbmcgYXJndW1lbnQg
dG8gdGhlIElFU0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPldlIHdlcmUgbW9zdGx5IHRoaW5raW5nIG9mIGFzeW1tZXRyaWMgZW5jcnlwdGlv
bi4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+U3BlY2lmeWluZyBwdXRpbmcgdGhlIGlzc3VlciBhbmQgb3IgdGhlIGF1ZGll
bmNlIGluIHRoZSBoZWFkZGVyIGhhcyBjb21lIHVwIGluIHRoZSBwYXN0IGJ1dCBwcm9iYWJseSBp
cyBub3QgZG9jdW1lbnRlZC4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIEZyaSwgSmFuIDEwLCAyMDIwLCA2OjI5IFBNIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj52bGFkaW1pckBjb25uZWN0Mmlk
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBwdXR0aW5nIHRoZSBjbGllbnRfaWQgaW50byB0aGUg
SldFIGhlYWRlciBpcyBhIHdheSBhcm91bmQgdGhlIG5lZWQ8YnI+DQp0byBoYXZlIHRoZSBjbGll
bnRfaWQgb3V0c2lkZSB0aGUgSldFIGFzIHRvcC1sZXZlbCBhdXRoWiByZXF1ZXN0IHBhcmFtZXRl
ci48YnI+DQo8YnI+DQpVbmZvcnR1bmF0ZWx5IHRoaXMgd29yayBhcm91bmQgaXNuJ3QgbWVudGlv
bmVkIGFueXdoZXJlLCBJIGp1c3QgY2hlY2tlZDxicj4NCnRoZSBtb3N0IHJlY2VudCBkcmFmdC1p
ZXRmLW9hdXRoLWp3c3JlcS0yMC48YnI+DQo8YnI+DQpPdXIgRERvUyBhdHRhY2sgbWl0aWdhdGlv
biAoZm9yIE9JREMgcmVxdWVzdF91cmkpIGFsc28gcmVsaWVzIG9uIHRoZTxicj4NCnByZXNlbmNl
IG9mIGNsaWVudF9pZCBhcyB0b3AtbGV2ZWwgcGFyYW1ldGVyLCB0b2dldGhlciB3aXRoIHJlcXVp
cmluZzxicj4NClJQcyB0byByZWdpc3RlciB0aGVpciByZXF1ZXN0X3VyaSdzIChzbyB0aGF0IHdl
IGRvbid0IG5lZWQgdG8gYnVpbGQgYW5kPGJyPg0Kc3RvcmUgYW4gaW5kZXggb2YgYWxsIHJlcXVl
c3RfdXJpJ3MpLiBJIGp1c3QgaGFkIGEgbG9vayBhdCAmcXVvdDtERG9TIEF0dGFjazxicj4NCm9u
IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciZxdW90OyBhbmQgYWxzbyByZWFsaXNlZCB0aGUgcmVx
dWVzdF91cmk8YnI+DQpyZWdpc3RyYXRpb24gaXNuJ3QgZXhwbGljaXRseSBtZW50aW9uZWQgYXMg
YXR0YWNrIHByZXZlbnRpb24gKCZxdW90O3RoZTxicj4NCnNlcnZlciBzaG91bGQgKGEpIGNoZWNr
IHRoYXQgdGhlIHZhbHVlIG9mICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7IHBhcmFtZXRlciBkb2Vz
PGJyPg0Kbm90IHBvaW50IHRvIGFuIHVuZXhwZWN0ZWQgbG9jYXRpb24mcXVvdDspLjxicj4NCjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYt
b2F1dGgtandzcmVxLTIwJTIzc2VjdGlvbi0xMC40LjEmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hh
ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThh
YmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEz
MDY4NzkzMTkzJmFtcDtzZGF0YT0lMkZ2SFZwNjhTTjVDQUhpbXFaNWp4OTNhT0NJcnV4cUxDUk1V
RkNjNURTeGMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjAjc2VjdGlvbi0xMC40LjE8
L2E+PGJyPg0KPGJyPg0KVG8gYmUgaG9uZXN0LCBJIGZlZWwgcXVpdGUgYmFkIGFib3V0IHRoZSBz
aXR1YXRpb24gd2l0aCBKQVIgd2UgYXJlIGluPGJyPg0Kbm93LiBGb3Igc29tZSByZWFzb24gSSBo
YWQgdGhlIGltcHJlc3Npb24gdGhhdCBPQXV0aCBKQVIgd2FzIGdvaW5nIHRvIGJlPGJyPg0KdGhl
IE9JREMgcmVxdWVzdCAvIHJlcXVlc3RfdXJpIGZvciBnZW5lcmFsIE9BdXRoIDIuMCB1c2UsIGFz
IHdpdGggb3RoZXI8YnI+DQpPSURDIGJpdHMgdGhhdCBsYXRlciBiZWNhbWUgZ2VuZXJhbCBwdXJw
b3NlIE9BdXRoIDIuMCBzcGVjcy48YnI+DQo8YnI+DQpJIGZpbmQgaXQgdW5mb3J0dW5hdGUgSSBk
aWRuJ3Qgbm90aWNlIHRoaXMgd2hlbiBJIHdhcyByZXZpZXdpbmcgdGhlIHNwZWM8YnI+DQppbiB0
aGUgcGFzdC48YnI+DQo8YnI+DQpWbGFkaW1pcjxicj4NCjxicj4NCjxicj4NCk9uIDEwLzAxLzIw
MjAgMjI6MzksIEZpbGlwIFNrb2thbiB3cm90ZTo8YnI+DQomZ3Q7IFZsYWRpbWlyLCA8YnI+DQom
Z3Q7PGJyPg0KJmd0OyBGb3IgdGhhdCB2ZXJ5IGNhc2UgdGhlIHBheWxvYWQgY2xhaW1zIG1heSBi
ZSByZXBlYXRlZCBpbiB0aGUgSldFIHByb3RlY3RlZCBoZWFkZXIuIEFuIGltcGxlbWVudGF0aW9u
IHdhbnRpbmcgdG8gaGFuZGxlIHRoaXMgbWF5IGxvb2sgZm9yIGlzcy9jbGllbnRfaWQgdGhlcmUu
DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPZGVzbMOhbm8geiBpUGhvbnU8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyZndDsgMTAuIDEuIDIwMjAgdiAyMToxOSwgVmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBo
cmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iIHRhcmdldD0iX2JsYW5rIj52bGFk
aW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
77u/SSBqdXN0IHJlYWxpc2VkIHRoZXJlIGlzIG9uZSBjbGFzcyBvZiBKQVJzIHdoZXJlIGl0J3Mg
cHJhY3RpYWxseTxicj4NCiZndDsmZ3Q7IGltcG9zc2libGUgdG8gcHJvY2VzcyB0aGUgcmVxdWVz
dCBpZiBtZXJnZSBpc24ndCBzdXBwb3J0ZWQ6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBU
aGUgY2xpZW50IHN1Ym1pdHMgYSBKQVIgZW5jcnlwdGVkIChKV1QpIHdpdGggYSBzaGFyZWQga2V5
LiBPSURDIGFsbG93czxicj4NCiZndDsmZ3Q7IGZvciB0aGF0IGFuZCBzcGVjcyBhIG1ldGhvZCBm
b3IgZGVyaXZpbmcgdGhlIHNoYXJlZCBrZXkgZnJvbSB0aGU8YnI+DQomZ3Q7Jmd0OyBjbGllbnRf
c2VjcmV0Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0w
Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGb3Bl
bmlkLm5ldCUyRnNwZWNzJTJGb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCUyM0VuY3J5cHRp
b24mYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3
MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4NzkzMTkzJmFtcDtzZGF0YT1zb0s5dDdwenU1
MDRpSUx1RE5GbkclMkJNTHhaUFAycE42dWdFSjRaT3BxZDQlM0QmYW1wO3Jlc2VydmVkPTAiIHRh
cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1j
b3JlLTFfMC5odG1sI0VuY3J5cHRpb248L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJ
ZiB0aGUgSkFSIGlzIGVuY3J5cHRlZCB3aXRoIHRoZSBjbGllbnRfc2VjcmV0LCBhbmQgdGhlcmUg
aXMgbm88YnI+DQomZ3Q7Jmd0OyB0b3AtbGV2ZWwgY2xpZW50X2lkIHBhcmFtZXRlciwgdGhlcmUn
cyBubyBnb29kIHdheSBmb3IgdGhlIE9QIHRvIGZpbmQ8YnI+DQomZ3Q7Jmd0OyBvdXQgd2hpY2gg
Y2xpZW50X3NlY3JldCB0byBnZXQgdG8gdHJ5IHRvIGRlY3J5cHQgdGhlIEpXRS4gVW5sZXNzIHRo
ZSBPUDxicj4NCiZndDsmZ3Q7IGtlZXBzIGFuIGluZGV4IG9mIGFsbCBpc3N1ZWQgY2xpZW50X3Nl
Y3JldCdzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPUCBzZXJ2
ZXJzIHdoaWNoIHJlcXVpcmUgcmVxdWVzdF91cmkgcmVnaXN0cmF0aW9uPGJyPg0KJmd0OyZndDsg
KHJlcXVpcmVfcmVxdWVzdF91cmlfcmVnaXN0cmF0aW9uPXRydWUpIGFuZCBkb24ndCB3YW50IHRv
IGluZGV4IGFsbDxicj4NCiZndDsmZ3Q7IHJlZ2lzdGVyZWQgcmVxdWVzdF91cmkncywgYWxzbyBo
YXZlIG5vIGdvb2Qgd2F5IHRvIHByb2Nlc3MgYSByZXF1ZXN0X3VyaTxicj4NCiZndDsmZ3Q7IGlm
IHRoZSBjbGllbnRfaWQgaXNuJ3QgcHJlc2VudCBhcyB0b3AtbGV2ZWwgcGFyYW1ldGVyLjxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBWbGFkaW1pcjxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gMTAvMDEvMjAyMCAyMDoxMywg
VG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBBbSAxMC4wMS4yMDIwIHVtIDE2OjUzIHNjaHJpZWIgSm9obiBCcmFkbGV5
ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52
ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSB0aGluayBU
b3JzdGVuIGlzIHNwZWN1bGF0aW5nIHRoYXQgaXMgbm90IGEgZmVhdHVyZSBwZW9wbGUgdXNlLiZu
YnNwOyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsgSeKAmW0gc3RpbGwgdHJ5aW5nIHRvIHVuZGVy
c3RhbmQgdGhlIHVzZSBjYXNlIGZvciBtZXJnaW5nIHNpZ25lZCBhbmQgdW5zaWduZWQgcGFyYW1l
dGVycy4gTmF0IG9uY2UgZXhwbGFpbmVkIGEgdXNlIGNhc2UsIHdoZXJlIGEgY2xpZW50IHVzZXMg
cGFyYW1ldGVycyBzaWduZWQgYnkgYSAzcmQgcGFydHkgKHNvbWUg4oCeY2VydGlmaWNhdGlvbiBh
dXRob3JpdHnigJwpIGluIGNvbWJpbmF0aW9uIHdpdGggdHJhbnNhY3Rpb24tc3BlY2lmaWMgcGFy
YW1ldGVycy4NCiBJcyB0aGlzIGJlaW5nIGRvbmUgaW4gdGhlIHdpbGQ/IDxicj4NCiZndDsmZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBQUzogUEFSIHdvdWxkIHdvcmsgd2l0aCBib3RoIG1vZGVz
Ljxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgm
YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0
ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4ODAzMTQ1JmFtcDtzZGF0YT1rb2JIJTJGc0dUN0Vs
U1NVQ0p2dSUyRmJpQXFuUkNYeCUyQjRTWk5Kc3JMJTJGQ3VWeWMlM0QmYW1wO3Jlc2VydmVkPTAi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0CH2PR00MB0843namp_--


From nobody Fri Jan 10 16:58: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 79C7F120120 for ; Fri, 10 Jan 2020 16:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level: 
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9mSkUY17xnu for ; Fri, 10 Jan 2020 16:58:32 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F58812003E for ; Fri, 10 Jan 2020 16:58:32 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id m24so3854144wmc.3 for ; Fri, 10 Jan 2020 16:58:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/sHe9CI8cmzJxzeR6JYbT9csgJBoXXZOtf+sIL2q29A=; b=aqGWJuUh308Pq+KmQZmaz9aII2J5FnYa467Qa14CO9ZxBlzncIHyxCu1MGITjz6quV JPS5nlyt2i9oOaGHe0pcIy6fIBrbBjphsqE7Vy1nbVTc/Xoen646cZZVMQGaG3rxKS4H BULpHsOsAXjbYUOAs8KAuYHkYjCG9UKa7CmBRxyQWgXgyQaiXxUuSjO9B9aqMinjrI95 N0a0FWzU8+Eh4jh1GUDDw7zjexNZt33vI5MaQt5Q6cLeicWhHmgMfktMGaVBV9Ajwmli w30/csOjS0v1/5UrZrYDBP8JSvDAfooTN1YQoPvqW5wOYqQhWv/5PbxG5IQ8VBCZZ1VJ iMOg==
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=/sHe9CI8cmzJxzeR6JYbT9csgJBoXXZOtf+sIL2q29A=; b=JYmroAD8Q1jb1twJmU2sRtm49anaCuRn07GYKucLRtNuGNYckw+SewggLXz8woXh7S TEkEni2Sql+zM8fMt3M5nEKhP9MgCPX4Cma5GiCN964rj9f5wMaOr8xq2Yw7gvA0Je7U YnYi2NWVaqkbX8+fRwndztzeWaInBo2s4ZfIXn75DCzP3JsfCRg/wcWIVs7sEEw9MYZh OYXuSyU6DQ4vmVr4NeUJqjQQNM3xQdP3MWqzNqu96CBLkshvX/8pbAMedPmkLF/1RAlZ aqvut7w0Xidd1eeC77WRf8RhP9FJj1DGl4dnVnPQXdkEe+Nrb4pcc8rbQAHarRMAYVhD 8feA==
X-Gm-Message-State: APjAAAWC8t+QrcpqndfhQ+hcOBltB3VTFHlhqck/XOrBFFAnR1RJY2u7 PpDhkH0S0q8bo7ENUC4kpoPchmzjCVxauX0jcHkvdA==
X-Google-Smtp-Source: APXvYqywmDn4a1sCzt5WjSojpXeidoQqlzXyWdyqkoIcWhMtgEJx9vD26BisLh5r2oRkWZqohOHZKN5xpF/O3cZ/Y4s=
X-Received: by 2002:a1c:740b:: with SMTP id p11mr7437792wmc.78.1578704310777;  Fri, 10 Jan 2020 16:58:30 -0800 (PST)
MIME-Version: 1.0
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>  
In-Reply-To: 
From: John Bradley 
Date: Fri, 10 Jan 2020 21:58:14 -0300
Message-ID: 
To: Mike Jones 
Cc: Vladimir Dzhuvinov , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000a64a3f059bd2bdb3"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 11 Jan 2020 00:58:36 -0000

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

Right we just don't say to put the iss there in OIDC if it's symetricly
encrypted.

On Fri, Jan 10, 2020, 9:41 PM Mike Jones 
wrote:

> The technique of replicating JWT claims that need to be publicly visible
> in an encrypted JWT in the header is defined at
> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
> for bringing this need to my attention as we were finishing the JWT spec.=
)
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * John Bradley
> *Sent:* Friday, January 10, 2020 2:15 PM
> *To:* Vladimir Dzhuvinov 
> *Cc:* IETF oauth WG 
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request
> (JAR) vs OIDC request object
>
>
>
> The intent was to do that, but specs change once the OAuth WG and IESG ge=
t
> there hands on them.
>
>
>
> Being backwards compatible with OIDC is not a compelling argument to the
> IESG.
>
>
>
> We were mostly thinking of asymmetric encryption.
>
>
>
> Specifying puting the issuer and or the audience in the headder has come
> up in the past but probably is not documented.
>
>
>
> John B
>
>
>
> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov 
> wrote:
>
> Yes, putting the client_id into the JWE header is a way around the need
> to have the client_id outside the JWE as top-level authZ request paramete=
r.
>
> Unfortunately this work around isn't mentioned anywhere, I just checked
> the most recent draft-ietf-oauth-jwsreq-20.
>
> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
> presence of client_id as top-level parameter, together with requiring
> RPs to register their request_uri's (so that we don't need to build and
> store an index of all request_uri's). I just had a look at "DDoS Attack
> on the Authorization Server" and also realised the request_uri
> registration isn't explicitly mentioned as attack prevention ("the
> server should (a) check that the value of "request_uri" parameter does
> not point to an unexpected location").
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> 
>
> To be honest, I feel quite bad about the situation with JAR we are in
> now. For some reason I had the impression that OAuth JAR was going to be
> the OIDC request / request_uri for general OAuth 2.0 use, as with other
> OIDC bits that later became general purpose OAuth 2.0 specs.
>
> I find it unfortunate I didn't notice this when I was reviewing the spec
> in the past.
>
> Vladimir
>
>
> On 10/01/2020 22:39, Filip Skokan wrote:
> > Vladimir,
> >
> > For that very case the payload claims may be repeated in the JWE
> protected header. An implementation wanting to handle this may look for
> iss/client_id there.
> >
> > Odesl=C3=A1no z iPhonu
> >
> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
> >>
> >> =EF=BB=BFI just realised there is one class of JARs where it's practia=
lly
> >> impossible to process the request if merge isn't supported:
> >>
> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allow=
s
> >> for that and specs a method for deriving the shared key from the
> >> client_secret:
> >>
> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> 
> >>
> >> If the JAR is encrypted with the client_secret, and there is no
> >> top-level client_id parameter, there's no good way for the OP to find
> >> out which client_secret to get to try to decrypt the JWE. Unless the O=
P
> >> keeps an index of all issued client_secret's.
> >>
> >>
> >> OP servers which require request_uri registration
> >> (require_request_uri_registration=3Dtrue) and don't want to index all
> >> registered request_uri's, also have no good way to process a request_u=
ri
> >> if the client_id isn't present as top-level parameter.
> >>
> >>
> >> Vladimir
> >>
> >>
> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> >>>
> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
> >>>> I think Torsten is speculating that is not a feature people use.
> >>> I=E2=80=99m still trying to understand the use case for merging signe=
d and
> unsigned parameters. Nat once explained a use case, where a client uses
> parameters signed by a 3rd party (some =E2=80=9Ecertification authority=
=E2=80=9C) in
> combination with transaction-specific parameters. Is this being done in t=
he
> wild?
> >>>
> >>> PS: PAR would work with both modes.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>

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


Right we just don't say to put the iss there in OIDC =
if it's symetricly encrypted.=C2=A0

On Fri, Jan 10, 2020, 9:41 PM Mike J=
ones <Michael.Jones@micro=
soft.com> wrote:











The technique of repli=
cating JWT claims that need to be publicly visible in an encrypted JWT in t=
he header is defined at
https://tools.ietf.org/html/rfc7519#section-5.3.=
=C2=A0 (Thanks to Dick Hardt for bringing this need to my attention as we w=
ere finishing the JWT 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=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 
John Bradley

Sent: Friday, January 10, 2020 2:15 PM

To: Vladimir Dzhuvinov <vladimir@connect2id.com>

Cc: IETF oauth WG <oauth@ietf.org>

Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request=
 (JAR) vs OIDC request object


=C2=A0






The intent was to do that, but specs change once the=
 OAuth WG and IESG get there hands on them.=C2=A0=C2=A0




=C2=A0






Being backwards compatible with OIDC is not a compel=
ling argument to the IESG.






=C2=A0






We were mostly thinking of asymmetric encryption.=C2=
=A0=C2=A0






=C2=A0






Specifying puting the issuer and or the audience in =
the headder has come up in the past but probably is not documented.=C2=A0=
=C2=A0






=C2=A0






John B=C2=A0




=C2=A0<=
/p>





On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <=
;vladimir@connect2id.com> wrote:






Yes, putting the client_id into the JWE header is a =
way around the need

to have the client_id outside the JWE as top-level authZ request parameter.=




Unfortunately this work around isn't mentioned anywhere, I just checked=


the most recent draft-ietf-oauth-jwsreq-20.



Our DDoS attack mitigation (for OIDC request_uri) also relies on the

presence of client_id as top-level parameter, together with requiring

RPs to register their request_uri's (so that we don't need to build=
 and

store an index of all request_uri's). I just had a look at "DDoS A=
ttack

on the Authorization Server" and also realised the request_uri

registration isn't explicitly mentioned as attack prevention ("the=


server should (a) check that the value of "request_uri" parameter=
 does

not point to an unexpected location").



https://tools.ietf.org/html/draft-iet=
f-oauth-jwsreq-20#section-10.4.1



To be honest, I feel quite bad about the situation with JAR we are in

now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other

OIDC bits that later became general purpose OAuth 2.0 specs.



I find it unfortunate I didn't notice this when I was reviewing the spe=
c

in the past.



Vladimir





On 10/01/2020 22:39, Filip Skokan wrote:

> Vladimir, 

>

> For that very case the payload claims may be repeated in the JWE prote=
cted header. An implementation wanting to handle this may look for iss/clie=
nt_id there.


>

> Odesl=C3=A1no z iPhonu

>

>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <vladimir@connect2=
id.com>:

>>

>> =EF=BB=BFI just realised there is one class of JARs where it's=
 practially

>> impossible to process the request if merge isn't supported:
>>

>> The client submits a JAR encrypted (JWT) with a shared key. OIDC a=
llows

>> for that and specs a method for deriving the shared key from the
>> client_secret:

>>

>> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

>>

>> If the JAR is encrypted with the client_secret, and there is no
>> top-level client_id parameter, there's no good way for the OP =
to find

>> out which client_secret to get to try to decrypt the JWE. Unless t=
he OP

>> keeps an index of all issued client_secret's.

>>

>>

>> OP servers which require request_uri registration

>> (require_request_uri_registration=3Dtrue) and don't want to in=
dex all

>> registered request_uri's, also have no good way to process a r=
equest_uri

>> if the client_id isn't present as top-level parameter.

>>

>>

>> Vladimir

>>

>>

>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:

>>>

>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <ve7jtb@=
ve7jtb.com>:

>>>> I think Torsten is speculating that is not a feature peopl=
e use.=C2=A0 =C2=A0

>>> I=E2=80=99m still trying to understand the use case for mergin=
g signed and unsigned parameters. Nat once explained a use case, where a cl=
ient uses parameters signed by a 3rd party (some =E2=80=9Ecertification aut=
hority=E2=80=9C) in combination with transaction-specific parameters.
 Is this being done in the wild? 

>>>

>>> PS: PAR would work with both modes.





_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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


















--000000000000a64a3f059bd2bdb3--


From nobody Fri Jan 10 18:34:33 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 5B15B120129 for ; Fri, 10 Jan 2020 18:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JZ8riHQRf_x for ; Fri, 10 Jan 2020 18:34:30 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD75120018 for ; Fri, 10 Jan 2020 18:34:30 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id o13so4104890ljg.4 for ; Fri, 10 Jan 2020 18:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VzTyqNb5lrcOIFFsqUE1Sx5rhY4gsS9VJP2ilKVhxwg=; b=UCWIMspRTvoL4O5Ww0/YCn/V3QEdGdgHGNKMCH0rUtZQ4fMCCqWXWc7dw/zGWxSPqv YT8TSbKetc/dwQY5EG2q8L9qMWCCzUnpZoEzShvPa7+6M0r7xPzt7h3giTmfmymZyDAt gUYZuy5KdmdAQAcpillTBfXXPz5+jEvVQ3JxBH77PQtUfJLaQ1AoISuby+cm+XjP2/UH srUXEUiB3L/sAojWRcxzunlVXZRhftyLEJDYWyLKCLWE54x5y5zTLO2SKLsCbQs6WSFH eJ5byv7p17yIIWuGIz9tXIfE0iX5NNN1UuMak6zDYq7supv5kBwLX1l0DJ9IoFlM2f0n RnLQ==
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=VzTyqNb5lrcOIFFsqUE1Sx5rhY4gsS9VJP2ilKVhxwg=; b=n3AOW2OFWnyjDs0/pWAGJz8KljrUXuOBR6z1hlCcVrsWc/KI5NpyNdWPkOaaJNRZSf GD4c90RPiJnwBA3Aaf89RFCiuIfCNOf/N3aLhGyczE96NBsviH0lEr9woGr2h5P3Ylnw bsZL1/wZ5uGhfVIyujzqlSszB6Bkw7dZfoPsC9bphJYxrfdusv6utP94c/y0AYuRbCmd 6vljVOCBTjt2ox60Zg+ICkind8v4LDWCPP3AnOFwIz7KpTF/ecZoc0KFBo5ONa4e1ma/ 3qFJxBJawixm9we8rLq8JqUvqetJZOHJkMptj/kvpr+OSHzalsCrArcXj54L4CBACFWE ELvg==
X-Gm-Message-State: APjAAAXHs/nyMV3QayzCgAtAKqy84Kcj0pGcFAFCXSJKX+WFX4kmO464 zuKz/bRmLoAhsLpmeKIkD2+XbnNhCOVwqYcASCw=
X-Google-Smtp-Source: APXvYqw6na+4dCyTqt/5e+SEp8CAMf1mO31gF3VG2pLeS6TWvDYf4qS9SwLuJSPtQOh3/QRdFMqFBKMLxhJ+nb/hNvE=
X-Received: by 2002:a2e:3a13:: with SMTP id h19mr4632789lja.16.1578710068529;  Fri, 10 Jan 2020 18:34:28 -0800 (PST)
MIME-Version: 1.0
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>
In-Reply-To: <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 18:34:17 -0800
Message-ID: 
To: Neil Madden 
Cc: Justin Richer , oauth ,  Mike Jones ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="000000000000d68fb6059bd4146f"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 11 Jan 2020 02:34:32 -0000

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

I was not saying that there was anything special about keys, nor that we
needed to change OAuth.

While using one key and controlling where it us used via access control
works, it is not ideal.

OAuth could have had just one endpoint, and done access control for
different roles -- but it did not. We enabled flexibility by separating the
authorization endpoint and the token endpoint. The dynamic client
registration extension defined a new endpoint, the registration endpoint.

I don't think we can change what has been deployed today -- but NEW
extensions that use keys for new purposes SHOULD define their own URI.
=E1=90=A7

On Fri, Jan 10, 2020 at 11:31 AM Neil Madden 
wrote:

> Sure, but we know how to run resilient services. My point is that there=
=E2=80=99s
> nothing particularly special about cryptographic keys: if you want to
> control how they are used there is a whole range of normal access control
> methods you can apply to them without needing to change anything in OAuth=
.
>
> Neil
>
> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>
> =EF=BB=BF
> There are many other factors to resiliency than multiple instances.
>
> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
> wrote:
>
>>
>>
>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>> [...]
>> >
>> > =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, =
another
>> goal would be increased resiliency of the components. If the
>> JWT-decryption-microservice is unavailable, the whole system is
>> unavailable. If there are separate keys, then a failure in one component
>> does not fail the entire system.
>>
>> Well you can run more than one instance - it=E2=80=99s a completely stat=
eless
>> service. You can also run a separate instance (or set of instances) per =
key
>> if you like.
>>
>> Neil
>
>

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


I was not saying that there was anything special about key=
s, nor that we needed to change OAuth.

While using one k=
ey and controlling where it us used via access control works, it is not ide=
al.

OAuth could have had just one endpoint, and do=
ne access control for different roles -- but it did not. We enabled flexibi=
lity by separating the authorization endpoint and the token endpoint. The d=
ynamic client registration extension defined a new endpoint, the registrati=
on endpoint.

I don't think we can change what =
has been deployed today -- but NEW extensions that use keys for new purpose=
s SHOULD define their own URI.
3D""=E1=90=A7
On Fri, =
Jan 10, 2020 at 11:31 AM Neil Madden <neil.madden@forgerock.com> wrote:
Sure=
, but we know how to run resilient services. My point is that there=E2=80=
=99s nothing particularly special about cryptographic keys: if you want to =
control how they are used there is a whole range of normal access control m=
ethods you can apply to them without needing to change anything in OAuth.=
=C2=A0

Neil

On 10 Jan 2020, at 18:50, Dick Hardt=
 <dick.hardt@g=
mail.com> wrote:

=EF=BB=BF
There are many other factors to=
 resiliency than multiple instances.=C2=A0

On Fri, Jan 10, 2020 at 10:30 AM =
Neil Madden <neil.madden@forgerock.com> wrote:




> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com> wrote:

[...]

> 

> =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, =
another goal would be increased resiliency of the components. If the JWT-de=
cryption-microservice is unavailable, the whole system is unavailable. If t=
here are separate keys, then a failure in one component does not fail the e=
ntire system. 



Well you can run more than one instance - it=E2=80=99s a completely statele=
ss service. You can also run a separate instance (or set of instances) per =
key if you like. 



Neil




--000000000000d68fb6059bd4146f--


From nobody Fri Jan 10 18:35: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 1A08412002E for ; Fri, 10 Jan 2020 18:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB6nvO7iQL1s for ; Fri, 10 Jan 2020 18:35:52 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15286120018 for ; Fri, 10 Jan 2020 18:35:52 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id 203so2901201lfa.12 for ; Fri, 10 Jan 2020 18:35:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VWjxQMBNUIYzMEkYItKDeNOPXo8KmBy01CFu4mvy0k=; b=oMq6c1MW9eGvcLFJUrwIuz1/KYPCVc+Utu67tsEGTJmSP9TyUwDWdyHup/mxeLU26p xF+Nz28GnPfLy/kJoAAokQPBgaqt72SHA0x9955QeE/W3n8fhcjk1oiEYlxdzfCoNl4/ pHcFH8Dt9r/BuSe7MI9k7De8fqavJ/K/6IHS//9TrUSmbw27I8xhiYoWZWto1w2YdpL1 83otXzOdUmzAAoJX67YifJBqU2G+9XMpxkvfEK5rz1hgY0J0wPP64RnAzkFvYemC4w43 828jm4UxckaUR3Ldkg8336UtnsHSuHe1R4m8VO/K55+A3kqpUX2HTA5gMD4C2jbDqCBx CFEg==
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=1VWjxQMBNUIYzMEkYItKDeNOPXo8KmBy01CFu4mvy0k=; b=TisNeeeriyiI6ZBqFzeXlfNLynYjfiGmnNMjHaSv3WdVDqT/fyaYJ2Oyamu1HPaSKM zKfX0qm1TX7uMLEtaS+CCYgof1kmjkypRbrDiR9K9bernXLMzHZ7VghlzwNE8EB391Cz sxdadw56as3EUr6FGwMeKFvEH8RyNaWNZlhqEIP1tk29GzvBURXC9eK7YibaUd+GCf6D YGjpHTktCCs9flSeEchLX4EI9EnySg+URxfErOLLOkdje6ba6zaV/41LK+PAKweN7wwC zPHLzDp8P6JZ7RyXikYvNUBFA6Rt4jsSUi4iYIMWJS+z4Ai9wBu/aZ5m+lycH7wQsusO 46vw==
X-Gm-Message-State: APjAAAU7dD5vi+ISuLbQW/r4M/SJmw0zh0p7+40kcrNgHdKixRbYQmKf PuuodxP4pe51qWzX76NHrCeKGHMSGf0T7xszKL8=
X-Google-Smtp-Source: APXvYqxjXVi/AIu6KIcoN7ov/CG0e8SrHP2+VzStkxlVm7d0kQ429CDE/9mX1wMFruG2Atj2vaOMhjvzYxihaCBmKiQ=
X-Received: by 2002:ac2:50cc:: with SMTP id h12mr4126663lfm.29.1578710150258;  Fri, 10 Jan 2020 18:35:50 -0800 (PST)
MIME-Version: 1.0
References:  <23D54EBE-359C-40FF-8204-9F03E45D09E9@forgerock.com>   <99A2BC24-C265-48DB-9353-4CE4105ED435@amazon.com>
In-Reply-To: <99A2BC24-C265-48DB-9353-4CE4105ED435@amazon.com>
From: Dick Hardt 
Date: Fri, 10 Jan 2020 18:35:38 -0800
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Neil Madden , Aaron Parecki , oauth , Mike Jones 
Content-Type: multipart/alternative; boundary="000000000000b5a68a059bd41962"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 11 Jan 2020 02:35:55 -0000

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

For new extensions, giving the key uri a new name would seem to work the
same as we have different names for different endpoints.

The cow is out of the barn for current work though.
=E1=90=A7

On Fri, Jan 10, 2020 at 1:22 PM Richard Backman, Annabelle <
richanna@amazon.com> wrote:

> Having different JWKS URIs in the metadata document for different purpose=
s
> would address the issue, but I=E2=80=99m not sure off-hand if we can clea=
rly
> delineate purposes in a robust way without making it too complicated. So =
it
> may be correct for the working group to accept the situation for what it =
is.
>
>
>
> However, if we do that then we need to stop pretending that =E2=80=9Cuse =
different
> keys=E2=80=9D is a viable option. That tool needs to be tossed out of the=
 toolbox,
> because our specifications do not allow implementers to do that in a
> meaningful way. The fact that we=E2=80=99ve used that argument despite th=
is
> limitation demonstrates that this is a non-obvious result of the trust
> model we=E2=80=99ve adopted. If we stick with that model, we need to be m=
ore
> conscious of this issue in our future work. Some documents will need
> Security Considerations that draw attention to it, others may need more
> attention. We also need to recognize that we will be ruling out certain
> types of deployments, and certain use cases.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Dick Hardt 
> *Date: *Friday, January 10, 2020 at 11:00 AM
> *To: *Neil Madden 
> *Cc: *Aaron Parecki , oauth , Mike
> Jones , "Richard Backman, Annabelle" <
> richanna@amazon.com>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE:
> Cryptographic hygiene and the limits of jwks_uri
>
>
>
> To restate my previous point, we may not be able to change what is
> currently specified and deployed, but we can for future extensions such a=
s
> RAR and PAR.
>
>
>
> To paraphrase Annabelle, this ship may have already sailed.
>
>
>
> On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt  wrote:
>
> The metadata document is declarative, and can easily be yet another
> separate role in the AS.
>
>
>
> In large organizations, different people are empowered different roles, s=
o
> the team owning the metadata document could be different from the team
> generating ID tokens, and different from the team generating JWTs.
>
>
>
>
>
> On Fri, Jan 10, 2020 at 10:27 AM Neil Madden 
> wrote:
>
> The problem with specifying a property on the key itself is that a
> microservice might lie about what it=E2=80=99s keys are for. I think you =
either
> need separate documents or some separate metadata mapping uses to key ids=
.
>
>
>
> =E2=80=94 Neil
>
>
>
> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>
> !
>
> Can the keys in the document at the jwks_uri indicate what they are for?
> Either by adding other top-level properties next to "keys" or by specifyi=
ng
> a property on a key itself? At least that way implementations that expect
> just one value of jwks_uri wouldn't have to change.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:
>
> Yes. Thanks for clarifying.
>
> =E1=90=A7
>
>
>
> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
> You mean additional JWKS URIs, for example?
>
>
>
> Am 10.01.2020 um 19:09 schrieb Dick Hardt  >:
>
> Perhaps I am misunderstanding what Annabelle was getting at, but having
> more than one key in the metadata document would solve the the issue. IE,
> extensions would define their own key instead of using the same one.
>
>
>
> The metadata document itself was an extension.
>
>
>
>
>
> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>
>
> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
> >
> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
> Provider, and the access token is being defined. These extensions have
> assumed all of this functionality is a monolith.
> >
> > I'm not suggesting that we MUST make changes to existing extensions, bu=
t
> design future extensions so that an implementation can separate duties if
> desired.
>
> How do you envision this to work? As you said, OAuth 2.0 is built on the
> assumption the AS is (at least logically) a monolith. All extension were
> built on that underlying assumption. I don=E2=80=99t see how an arbitrary=
 extension
> can relax that assumption and still be compatible with the rest (just
> revisit the discussion re PAR and keys).
>
> I think we should accept this design assumption, in the same way we shoul=
d
> accept form encoding as request format instead of JSON, for OAuth 2.0
> extensions.
>
> OAuth 3.0 could explicitely be developed with different architectures in
> mind.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> ----
>
> Aaron Parecki
>
> aaronparecki.com
>
> @aaronpk 
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


For new extensions, giving the key uri a new name would se=
em to work the same as we have different names for different endpoints.
The cow is out of the barn for current work though.=C2=A0
=3D""=E1=90=A7

On Fri, Jan 10, 2020 at 1:22 PM Richard=
 Backman, Annabelle <richanna@ama=
zon.com> wrote:











Having different JWKS URIs in the metadata document =
for different purposes would address the issue, but I=E2=80=99m not sure of=
f-hand if we can clearly delineate purposes in a robust way without making =
it too complicated. So it may be correct for
 the working group to accept the situation for what it is.

=C2=A0


However, if we do that then we need to stop pretendi=
ng that =E2=80=9Cuse different keys=E2=80=9D is a viable option. That tool =
needs to be tossed out of the toolbox, because our specifications do not al=
low implementers to do that in a meaningful way. The
 fact that we=E2=80=99ve used that argument despite this limitation demonst=
rates that this is a non-obvious result of the trust model we=E2=80=99ve ad=
opted. If we stick with that model, we need to be more conscious of this is=
sue in our future work. Some documents will need
 Security Considerations that draw attention to it, others may need more at=
tention. We also need to recognize that we will be ruling out certain types=
 of deployments, and certain use cases.


=C2=A0




=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
Dick Hardt <dick.hardt@gmail.com>

Date: Friday, January 10, 2020 at 11:00 AM

To: Neil Madden <neil.madden@forgerock.com>

Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>, Mike Jones <Michael.Jones@microsoft=
.com>, "Richard Backman, Annabelle" <richanna@amazon.com>

Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: =
Cryptographic hygiene and the limits of jwks_uri






=C2=A0






To restate my previous point, we may not be able to =
change what is currently specified and deployed, but we can for future exte=
nsions such as RAR and PAR.





=C2=A0






To paraphrase Annabelle, this ship may have already =
sailed.






=C2=A0






On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt <dick.hardt@gmail.com<=
/a>> wrote:








The metadata document is declarative, and can easily=
 be yet another separate=C2=A0role in the AS.=C2=A0





=C2=A0






In large organizations, different people are empower=
ed different roles, so the team owning the metadata document could be diffe=
rent=C2=A0from the team generating ID tokens, and different from the team g=
enerating JWTs.






=C2=A0






=C2=A0











The problem with specifying a property on the key it=
self is that a microservice might lie about what it=E2=80=99s keys are for.=
 I think you either need separate documents or some separate metadata mappi=
ng uses to key ids.=C2=A0






=C2=A0






=E2=80=94 Neil















On 10 Jan 2020, at 18:1=
9, Aaron Parecki <aaron@parecki.com> wrote:










! 






Can the keys in the document at the jwks_uri indicat=
e what they are for? Either by adding other top-level properties next to &q=
uot;keys" or by specifying a property on a key itself? At least that w=
ay implementations that expect just one value
 of jwks_uri wouldn't have to change.








=C2=A0






Aaron






=C2=A0






=C2=A0






=C2=A0






On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <dick.hardt@gmail.com<=
/a>> wrote:








Yes. Thanks for clarifying.






=E1=90=A7




=C2=A0











You mean additional JWKS URIs, for example?















Am 10.01.2020 um 19:09 =
schrieb Dick Hardt <dick.hardt@gmail..com>:












Perhaps I am misunderstanding what Annabelle was get=
ting at, but having more than one key in the metadata document would solve =
the the issue. IE, extensions would define their own key instead of using t=
he same one.





=C2=A0






The metadata document itself was an extension.=C2=A0=







=C2=A0






=C2=A0






On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt =
<torsten@lo=
dderstedt.net> wrote:










> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:

> 

> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect P=
rovider, and the access token is being defined. These extensions have assum=
ed all of this functionality is a monolith.


> 

> I'm not suggesting that we MUST make changes to existing extension=
s, but design future extensions so that an implementation can separate duti=
es if desired.



How do you envision this to work? As you said, OAuth 2.0 is built on the as=
sumption the AS is (at least logically) a monolith. All extension were buil=
t on that underlying assumption. I don=E2=80=99t see how an arbitrary exten=
sion can relax that assumption and still
 be compatible with the rest (just revisit the discussion re PAR and keys).=




I think we should accept this design assumption, in the same way we should =
accept form encoding as request format instead of JSON, for OAuth 2.0 exten=
sions.




OAuth 3.0 could explicitely be developed with different architectures in mi=
nd.
















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








-- 






----






Aaron Parecki








=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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























--000000000000b5a68a059bd41962--


From nobody Sat Jan 11 01:17: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 2E51E12004A for ; Sat, 11 Jan 2020 01:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level: 
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=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 PVjMCBCSYiFV for ; Sat, 11 Jan 2020 01:17:01 -0800 (PST)
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 D18EC120043 for ; Sat, 11 Jan 2020 01:17:00 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id qCt6ir8av7qCuqCt7iJfxC; Sat, 11 Jan 2020 02:16:58 -0700
To: John Bradley , Mike Jones 
Cc: IETF oauth WG 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>   
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com>
Date: Sat, 11 Jan 2020 11:16:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208000506070301060407"
X-CMAE-Envelope: MS4wfL/oTudRgD3u535mOq0/RtCwR9cmrTkQTS4ZzdG4xaTI9qhgP/qLX7itIkqLi4fINsL57cNNTQNuk5YZSsOECfxnEgnyW3tiLtMw+BfLiZVy4oWXwRFZ TE27tDR7FYLb5APDJXDoh5n9HOrfAtm0GZKTvu2VvosWGMoI7oKNCBUgfqFQMG9Fk/6MjK0jLakJOydc5WuU8kpb+h230B33/0CBfPimFgX0gJmzrgrftlEv x9PYXSTVBO1ThP9HCkuzWw==
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 11 Jan 2020 09:17:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms020208000506070301060407
Content-Type: multipart/alternative;
 boundary="------------7AD063D9CF6193BF5448FB81"
Content-Language: en-US

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

Thanks Mike for the rfc7519 section-5.3
 pointer. Can this
parameter replication be used for client_id or the client_id ass "iss"
even though it isn't explicitly mentioned in the JAR spec?

On 11/01/2020 02:58, John Bradley wrote:
> Right we just don't say to put the iss there in OIDC if it's
> symetricly encrypted.

OIDC doesn't have the symmetric key selection issue, I suppose that why
the possibility to replicate params to the JWE header isn't mentioned at
all. OIDC requires the top-level query params to represent a valid OAuth
2.0 request, and there client_id is required. If the client_id is
present the client registration together with any present client_secret
can be retrieved.

I reread the JAR spec, this is the only place that mentions handling of
symmetric JWE.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

>    (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.


Vladimir


>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  > wrote:
>
>     The technique of replicating JWT claims that need to be publicly
>     visible in an encrypted JWT in the header is defined at
>     https://tools.ietf.org/html/rfc7519#section-5.3.=C2=A0 (Thanks to D=
ick
>     Hardt for bringing this need to my attention as we were finishing
>     the JWT 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=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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      > *On Behalf Of * John Bradley
>     *Sent:* Friday, January 10, 2020 2:15 PM
>     *To:* Vladimir Dzhuvinov      >
>     *Cc:* IETF oauth WG >
>     *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>     Request (JAR) vs OIDC request object
>
>     =C2=A0
>
>     The intent was to do that, but specs change once the OAuth WG and
>     IESG get there hands on them.=C2=A0=C2=A0
>
>     =C2=A0
>
>     Being backwards compatible with OIDC is not a compelling argument
>     to the IESG.
>
>     =C2=A0
>
>     We were mostly thinking of asymmetric encryption.=C2=A0=C2=A0
>
>     =C2=A0
>
>     Specifying puting the issuer and or the audience in the headder
>     has come up in the past but probably is not documented.=C2=A0=C2=A0=

>
>     =C2=A0
>
>     John B=C2=A0
>
>     =C2=A0
>
>     On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>     > wrote:
>
>         Yes, putting the client_id into the JWE header is a way around
>         the need
>         to have the client_id outside the JWE as top-level authZ
>         request parameter.
>
>         Unfortunately this work around isn't mentioned anywhere, I
>         just checked
>         the most recent draft-ietf-oauth-jwsreq-20.
>
>         Our DDoS attack mitigation (for OIDC request_uri) also relies
>         on the
>         presence of client_id as top-level parameter, together with
>         requiring
>         RPs to register their request_uri's (so that we don't need to
>         build and
>         store an index of all request_uri's). I just had a look at
>         "DDoS Attack
>         on the Authorization Server" and also realised the request_uri
>         registration isn't explicitly mentioned as attack prevention ("=
the
>         server should (a) check that the value of "request_uri"
>         parameter does
>         not point to an unexpected location").
>
>         https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-=
10.4.1
>         
>
>         To be honest, I feel quite bad about the situation with JAR we
>         are in
>         now. For some reason I had the impression that OAuth JAR was
>         going to be
>         the OIDC request / request_uri for general OAuth 2.0 use, as
>         with other
>         OIDC bits that later became general purpose OAuth 2.0 specs.
>
>         I find it unfortunate I didn't notice this when I was
>         reviewing the spec
>         in the past.
>
>         Vladimir
>
>
>         On 10/01/2020 22:39, Filip Skokan wrote:
>         > Vladimir,
>         >
>         > For that very case the payload claims may be repeated in the
>         JWE protected header. An implementation wanting to handle this
>         may look for iss/client_id there.
>         >
>         > Odesl=C3=A1no z iPhonu
>         >
>         >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>         >:
>         >>
>         >> =EF=BB=BFI just realised there is one class of JARs where it=
's
>         practially
>         >> impossible to process the request if merge isn't supported:
>         >>
>         >> The client submits a JAR encrypted (JWT) with a shared key.
>         OIDC allows
>         >> for that and specs a method for deriving the shared key
>         from the
>         >> client_secret:
>         >>
>         >>
>         https://openid.net/specs/openid-connect-core-1_0.html#Encryptio=
n
>         
>         >>
>         >> If the JAR is encrypted with the client_secret, and there is=
 no
>         >> top-level client_id parameter, there's no good way for the
>         OP to find
>         >> out which client_secret to get to try to decrypt the JWE.
>         Unless the OP
>         >> keeps an index of all issued client_secret's.
>         >>
>         >>
>         >> OP servers which require request_uri registration
>         >> (require_request_uri_registration=3Dtrue) and don't want to
>         index all
>         >> registered request_uri's, also have no good way to process
>         a request_uri
>         >> if the client_id isn't present as top-level parameter.
>         >>
>         >>
>         >> Vladimir
>         >>
>         >>
>         >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>         >>>
>         >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>         >:
>         >>>> I think Torsten is speculating that is not a feature
>         people use.=C2=A0 =C2=A0
>         >>> I=E2=80=99m still trying to understand the use case for mer=
ging
>         signed and unsigned parameters. Nat once explained a use case,
>         where a client uses parameters signed by a 3rd party (some
>         =E2=80=9Ecertification authority=E2=80=9C) in combination with
>         transaction-specific parameters. Is this being done in the wild=
?
>         >>>
>         >>> PS: PAR would work with both modes.
>
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org 
>         https://www.ietf.org/mailman/listinfo/oauth
>         
>
--=20
Vladimir Dzhuvinov


--------------7AD063D9CF6193BF5448FB81
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Thanks Mike for the rfc7519 section-5.3
        pointer. Can this parameter replication be used for client_id or
        the client_id ass "iss" even though it isn't explicitly
        mentioned in the JAR spec?

      

    
On 11/01/2020 02:58, John Bradley
      wrote:

    

    

      
      
Right we just don't say to put the iss there in
        OIDC if it's symetricly encrypted. 

      

    

    
OIDC doesn't have the symmetric key selection issue, I suppose
      that why the possibility to replicate params to the JWE header
      isn't mentioned at all. OIDC requires the top-level query params
      to represent a valid OAuth 2.0 request, and there client_id is
      required. If the client_id is present the client registration
      together with any present client_secret can be retrieved. 

    

    
I reread the JAR spec, this is the only place that mentions
      handling of symmetric JWE.

    

    
https://tools.ietf.org/html=
/draft-ietf-oauth-jwsreq-20#section-10.2

    

    

      

        
   (b)  Verifying that the symmetric key f=
or the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

      

    

    


    

    
Vladimir

    


    

    


      

        
On Fri, Jan 10, 2020, 9:41 =
PM
          Mike Jones <Michael.Jones@microsoft.com>
          wrote:

        

        

          

            

              
The
                  technique of replicating JWT claims that need to be
                  publicly visible in an encrypted JWT in the header is
                  defined at
                  https://tools.ietf.org/html/=
rfc7519#section-5.3.=C2=A0
                  (Thanks to Dick Hardt for bringing this need to my
                  attention as we were finishing the JWT 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=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=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-bounc=
es@ietf.org>
                On Behalf Of 
                John Bradley

                Sent: Friday, January 10, 2020 2:15 PM

                To: Vladimir Dzhuvinov <vladimir@co=
nnect2id.com>

                Cc: IETF oauth WG <oauth@ietf.=
org>

                Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured
                Authorization Request (JAR) vs OIDC request object

              
=C2=A0

              

                

                  
The intent was to do that, but
                    specs change once the OAuth WG and IESG get there
                    hands on them.=C2=A0=C2=A0

                  

                    
=C2=A0

                  

                  

                    
Being backwards compatible wit=
h
                      OIDC is not a compelling argument to the IESG.

                  

                  

                    
=C2=A0

                  

                  

                    
We were mostly thinking of
                      asymmetric encryption.=C2=A0=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
Specifying puting the issuer
                      and or the audience in the headder has come up in
                      the past but probably is not documented.=C2=A0=C2=A0=


                  

                  

                    
=C2=A0

                  

                  

                    
John B=C2=A0

                  

                  
=C2=
=A0

                  

                    

                      
On Fri, Jan 10, 2020, 6:29 P=
M
                        Vladimir Dzhuvinov <vladimir@connect2id.co=
m>
                        wrote:

                    

                    

                      
Yes, putting the client_id
                        into the JWE header is a way around the need

                        to have the client_id outside the JWE as
                        top-level authZ request parameter.

                        

                        Unfortunately this work around isn't mentioned
                        anywhere, I just checked

                        the most recent draft-ietf-oauth-jwsreq-20.

                        

                        Our DDoS attack mitigation (for OIDC
                        request_uri) also relies on the

                        presence of client_id as top-level parameter,
                        together with requiring

                        RPs to register their request_uri's (so that we
                        don't need to build and

                        store an index of all request_uri's). I just had
                        a look at "DDoS Attack

                        on the Authorization Server" and also realised
                        the request_uri

                        registration isn't explicitly mentioned as
                        attack prevention ("the

                        server should (a) check that the value of
                        "request_uri" parameter does

                        not point to an unexpected location").

                        

                        https://tools.ietf.org=
/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

                        

                        To be honest, I feel quite bad about the
                        situation with JAR we are in

                        now. For some reason I had the impression that
                        OAuth JAR was going to be

                        the OIDC request / request_uri for general OAuth
                        2.0 use, as with other

                        OIDC bits that later became general purpose
                        OAuth 2.0 specs.

                        

                        I find it unfortunate I didn't notice this when
                        I was reviewing the spec

                        in the past.

                        

                        Vladimir

                        

                        

                        On 10/01/2020 22:39, Filip Skokan wrote:

                        > Vladimir, 

                        >

                        > For that very case the payload claims may
                        be repeated in the JWE protected header. An
                        implementation wanting to handle this may look
                        for iss/client_id there.
                        

                        >

                        > Odesl=C3=A1no z iPhonu

                        >

                        >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
                        <vladimir@connect2id.co=
m>:

                        >>

                        >> =EF=BB=BFI just realised there is one cl=
ass of
                        JARs where it's practially

                        >> impossible to process the request if
                        merge isn't supported:

                        >>

                        >> The client submits a JAR encrypted
                        (JWT) with a shared key. OIDC allows

                        >> for that and specs a method for
                        deriving the shared key from the

                        >> client_secret:

                        >>

                        >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                        >>

                        >> If the JAR is encrypted with the
                        client_secret, and there is no

                        >> top-level client_id parameter, there's
                        no good way for the OP to find

                        >> out which client_secret to get to try
                        to decrypt the JWE. Unless the OP

                        >> keeps an index of all issued
                        client_secret's.

                        >>

                        >>

                        >> OP servers which require request_uri
                        registration

                        >> (require_request_uri_registration=3Dtrue=
)
                        and don't want to index all

                        >> registered request_uri's, also have no
                        good way to process a request_uri

                        >> if the client_id isn't present as
                        top-level parameter.

                        >>

                        >>

                        >> Vladimir

                        >>

                        >>

                        >>> On 10/01/2020 20:13, Torsten
                        Lodderstedt wrote:

                        >>>

                        >>>>> Am 10.01.2020 um 16:53
                        schrieb John Bradley <ve7jtb@ve7jtb.com&=
gt;:

                        >>>> I think Torsten is speculating
                        that is not a feature people use.=C2=A0 =C2=A0
                        >>> I=E2=80=99m still trying to understa=
nd the
                        use case for merging signed and unsigned
                        parameters. Nat once explained a use case, where
                        a client uses parameters signed by a 3rd party
                        (some =E2=80=9Ecertification authority=E2=80=9C) =
in combination
                        with transaction-specific parameters. Is this
                        being done in the wild? 

                        >>>

                        >>> PS: PAR would work with both modes.<=
br>
                        

                        

                        _______________________________________________
                        OAuth mailing list

                        OAu=
th@ietf.org

                        https://www.ietf.org/m=
ailman/listinfo/oauth

                    

                  

                

              

            

          

        

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------7AD063D9CF6193BF5448FB81--

--------------ms020208000506070301060407
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTEwOTE2NTZaMC8G
CSqGSIb3DQEJBDEiBCAQHkKWbz1C70G9xApn7HhqlfEqehPht/svM+MUBz1hJTBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAEpVFNylaidM/ihy8GlbtbggxA2CLn3VzJu4rLWKUhszAQti
qaSk/duw1gzPEBp4P4D95Tno3FUJJjj1ghKSpASPEXjaBhvuY1cpgcEoz3+Mn92IHvcDT0Gz
ZnYHwU/LDFRZY5ngzquOjlGwh3VTEOwLnK7/DV8Mc2ltHvRwPdx5l5v1BIb2kSH3f4aiH1Jc
gPFveiv5ZpnYMcf7iwSS9FgKmTI1lfkUhFxK3M1N9aI48xnRtM7yPfQ+HWqM3e7o9KmKPNbE
glzCDoMWe25qqI+5k7TYXrt3Hv2bAop+h2viC3KnCj4WmIpGyV22FsRrBW/uNbk4pYiXFlSB
dVNFWHEAAAAAAAA=
--------------ms020208000506070301060407--


From nobody Sat Jan 11 02:28: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 82D0B1200FD for ; Sat, 11 Jan 2020 02:28:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 XiFIZIZtHZ1G for ; Sat, 11 Jan 2020 02:28:09 -0800 (PST)
Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (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 4E67F120033 for ; Sat, 11 Jan 2020 02:28:09 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id qDzyi86OK0h91qDzzijBaK; Sat, 11 Jan 2020 03:28:08 -0700
x-spam-cmae: v=2.3 cv=Ga9pYjfL c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=Mhp_Scw7AAAA:8 a=LS6YZpeZAAAA:8 a=DVqm7IH0AAAA:8 a=vggBfdFIAAAA:8 a=N8h_gfpVYWjWe7o_yeAA:9 a=bE3uGCcN48NBn6tY:21 a=W2xEMAoTgaYpDO5-:21 a=QEXdDO2ut3YA:10 a=ghQvJjrl4gepV0MTyA4A:9 a=9JXru4TqZan1D6SP:21 a=1QcUOMp1dgdAzQA9:21 a=WnRXZD6sfpb669X1:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=rCfoGGe4EEIQCwLoKFZE:22 a=IRr2vCDBpksuBOXhfkKu:22 a=IdGyktwZ2tr74praB_5u:22 a=M6wP_kGduNurgptF5PJY:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
To: Justin Richer , "Richard Backman, Annabelle" 
Cc: oauth , Nat Sakimura 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Sat, 11 Jan 2020 12:28:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000001000806090209070408"
X-CMAE-Envelope: MS4wfAInAD+OcyrjcgqdlYetsjGR1JjX8EavolTNmWbr6E9lz64Bo1t9XMznb6qaOAbTLKCIUzuFTMLn+19svLss+YKBt2Ty/op4A8nudPfMnU+ak42tpcHW jND6OSW9Amde/KOt31yGTkpMqf2Sc4c95qmIwL1Qg63Dwe1Ib0Vk5LATqVfch+E/WsK5VuWLjYtAhTnFNHwdEXcAdhWf/0ZtwslHNHW6uac07TIhGk/PBoTt kmlClrSo3QEcooa5ObIuYiGpJJc4qyE7ilnEYUL5YU8=
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 11 Jan 2020 10:28:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms000001000806090209070408
Content-Type: multipart/alternative;
 boundary="------------94006C41C77E1E3C5DE74D44"
Content-Language: en-US

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

My suggestion is to abstain from specifying the concrete form of the
resource pointed to by the PAR URI. Regardless of URI type (URN,
downloadable https URL or something else), and even if the PAR endpoint
and the authZ endpoint are managed by two different entities
(microservice or other scenario).

In the Connect2id implementation of PAR the returned URI doesn't point
to a request object and it doesn't point to a JWT either. It points to
an internally stored "pre-processed" authZ request, which the authZ
endpoint then picks up to complete the authZ.

Even if we eventually end up in microservice world, or allow the PAR
endpoint to be managed by some external entity, the PAR URI - its
interpretation, validation and potentially resource retrieval (JWT or
other blob), is an "internal contract" on the AS side. This doesn't
concern the client, and in OAuth 2.0 the role of AS is indivisible.


I see PAR request + authZ request as one logical OAuth 2.0 authZ
request: the client submits an authZ request and gets an authZ response
at the end. The URI is necessary for the client to proceed from the 1st
to the 2nd step. If we manage to frame / word the PAR URI in this
logical way, without getting stuck in the JAR definition / framing of
what the request_uri / object is, it would be great.


The normative language I think should focus on maintaining the OAuth 2.0
contract for the entire logical authZ request, together with the basic
contracts of 1) JAR and the 2) authZ endpoint.


Vladimir


On 10/01/2020 22:55, Justin Richer wrote:
> So we could solve this by saying the resulting data object of a PAR is
> a request object. Which might also contain a request object internally
> as well. In that case JAR should back off from saying it=E2=80=99s a JW=
T and
> instead say it=E2=80=99s a request object. Or we define a new term for =
this
> authorization request blob thing.
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remo=
te
> protocol then it MUST be a JWT, but otherwise it can be whatever you
> want. That=E2=80=99s where the real interop concerns come in.
>
> =C2=A0=E2=80=94 Justin
>
>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle
>> > > wrote:
>>
>> Correct. The problem becomes pretty clear in the context of PAR,
>> where the AS is generating and vending out the URI at the PAR
>> endpoint, and consuming it at the authorization endpoint. From an
>> interoperability standpoint, it=E2=80=99s analogous to the AS vending =
an
>> authorization code at the authorization endpoint and consuming it at
>> the token endpoint.
>> =E2=80=93=C2=A0
>> Annabelle Richard Backman
>> AWS Identity
>> =C2=A0
>> =C2=A0
>> *From:=C2=A0*John Bradley >
>> *Date:=C2=A0*Friday, January 10, 2020 at 12:29 PM
>> *To:=C2=A0*Brian Campbell > >
>> *Cc:=C2=A0*Torsten Lodderstedt > >, Nat Sakimura > >, "Richard Backman, Annabelle"
>> >, oauth
>> >
>> *Subject:=C2=A0*[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed request=
s
>> must become JWTs
>> =C2=A0
>> If we assume the client posts a JAR and gets back a reference.=C2=A0 T=
hen
>> the reference is to a JAR.=C2=A0
>> =C2=A0
>> I think I see the problem.=C2=A0 If the server providing the reference=
 is
>> associated with the AS then the server dosen't need to dereference
>> the object via HTTP, so it could be a URN as an example.=C2=A0
>> =C2=A0
>> So yes it is not a interoperability issue for the client.=C2=A0=C2=A0
>> =C2=A0
>> I will think about how I can finesse that.=C2=A0
>> =C2=A0
>> I agree it is not a change in intent.=C2=A0
>> =C2=A0
>> I will see if I can get our AD to accept that.
>> =C2=A0
>> John B.=C2=A0
>> =C2=A0
>> =C2=A0
>> =C2=A0
>> =C2=A0
>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell
>> > wrote=
:
>>> Sure but the text proposed (or something like it) qualifies it such
>>> that there aren't interoperability questions because it's only an
>>> implementation detail to the AS who both produces the URI and
>>> consumes its content.
>>> =C2=A0
>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley >> > wrote:
>>>> It may be a challenge to change text saying that the contents of
>>>> the resource could be something other than a request object.=C2=A0
>>>> =C2=A0
>>>> If not a request object then what and how is that interoperable are
>>>> likely AD questions.=C2=A0
>>>> =C2=A0
>>>> I could perhaps see changing it to must be a request object, or
>>>> other format defined by a profile.
>>>>
>>>> John B.=C2=A0=C2=A0
>>>> =C2=A0
>>>> =C2=A0
>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell
>>>> > wro=
te:
>>>>> Agree and agree. But given that the change suggested by Annabelle
>>>>> has no impact on the client or interoperability, perhaps Nat or
>>>>> John could work the change into the draft during the edits that
>>>>> happen during the final stages of things?
>>>>> =C2=A0
>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt
>>>>> >>>> > wrote:
>>>>>> I would assume given the status of JAR, we don=E2=80=99t want to c=
hange
>>>>>> it. And as I said, this difference does not impact
>>>>>> interoperability from client perspective.
>>>>>>
>>>>>>
>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle
>>>>>>> >>>>>> >:
>>>>>>>
>>>>>>> It would be more appropriate to add the text to JAR rather than
>>>>>>> PAR. It doesn't seem right for PAR to retcon rules in JAR.
>>>>>>> Moving the text to JAR also highlights the weirdness of giving
>>>>>>> PAR special treatment.
>>>>>>> =C2=A0
>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>
>>>>>>> The contents of the resource referenced by the URI MUST be a Requ=
est
>>>>>>>
>>>>>>> Object.
>>>>>>>
>>>>>>> =C2=A0
>>>>>>> To:=C2=A0
>>>>>>>
>>>>>>> The contents of the resource referenced by the URI MUST be a Requ=
est
>>>>>>>
>>>>>>> Object, unless the URI was provided to the client by the
>>>>>>> Authorization
>>>>>>>
>>>>>>> Server.
>>>>>>>
>>>>>>> =C2=A0
>>>>>>> This would allow for use cases such as an AS that provides
>>>>>>> pre-defined request URIs, or vends request URIs via a client
>>>>>>> management console, or bakes them into their client apps.
>>>>>>> =C2=A0
>>>>>>> =E2=80=93=C2=A0
>>>>>>> Annabelle Richard Backman
>>>>>>> AWS Identity
>>>>>>> =C2=A0
>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"
>>>>>>> >>>>>> > wrote:
>>>>>>> =C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0 Hi,=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the A=
S to represent the
>>>>>>> request as a JWT-based request object. The URI is used as
>>>>>>> internal reference only. That why the draft states
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorizat=
ion request data available to other parties
>>>>>>> via this
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=
=9D
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implem=
entation
>>>>>>> perspective, it doesn't matter from a client's (interop)
>>>>>>> perspective.
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that=
 request_uris
>>>>>>> issued by the PAR mechanism (MAY) deviate from the JAR definition=
=2E
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0best regards,
>>>>>>> =C2=A0=C2=A0=C2=A0 Torsten.=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backm=
an, Annabelle
>>>>>>> >>>>>> > wrote:
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> Hi all,
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR=
 (-20) require that
>>>>>>> the AS transform all pushed requests into JWTs. This requirement
>>>>>>> arises from the following:
>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 PAR uses the request_uri parameter defined in
>>>>>>> JAR to communicate the pushed request to the authorization endpoi=
nt.
>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 According to JAR, the resource referenced by
>>>>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=A2 Request Object is defined to be a JWT containing
>>>>>>> all the authorization request parameters. (Section 2.1)
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement t=
o support
>>>>>>> interoperability, as this is internal to the AS. It is also
>>>>>>> inconsistent with the rest of JAR, which avoids attempting to
>>>>>>> define the internal communications between the two AS endpoints.
>>>>>>> Worse, this restriction makes it harder for the authorization
>>>>>>> endpoint to leverage validation and other work performed at the
>>>>>>> PAR endpoint, as the state or outcome of that work must be
>>>>>>> forced into the JWT format (or retrieved via a subsequent
>>>>>>> service call or database lookup).
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman
>>>>>>> =C2=A0=C2=A0=C2=A0 > AWS Identity
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> _______________________________________=
________
>>>>>>> =C2=A0=C2=A0=C2=A0 > OAuth mailing list
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf.org 
>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0https://www.ietf.org/mailman/listinfo/o=
auth
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>> _______________________________________________
>>>>>> 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.=C2=A0 If you have received this communication in error,=

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

--=20
Vladimir Dzhuvinov


--------------94006C41C77E1E3C5DE74D44
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
My suggestion is to abstain from specifying the concrete form of
      the resource pointed to by the PAR URI. Regardless of URI type
      (URN, downloadable https URL or something else), and even if the
      PAR endpoint and the authZ endpoint are managed by two different
      entities (microservice or other scenario).

    
In the Connect2id implementation of PAR the returned URI doesn't
      point to a request object and it doesn't point to a JWT either. It
      points to an internally stored "pre-processed" authZ request,
      which the authZ endpoint then picks up to complete the authZ.

    
Even if we eventually end up in microservice world, or allow the
      PAR endpoint to be managed by some external entity, the PAR URI -
      its interpretation, validation and potentially resource retrieval
      (JWT or other blob), is an "internal contract" on the AS side.
      This doesn't concern the client, and in OAuth 2.0 the role of AS
      is indivisible.

    


    

    
I see PAR request + authZ request as one logical OAuth 2.0 authZ
      request: the client submits an authZ request and gets an authZ
      response at the end. The URI is necessary for the client to
      proceed from the 1st to the 2nd step. If we manage to frame / word
      the PAR URI in this logical way, without getting stuck in the JAR
      definition / framing of what the request_uri / object is, it would
      be great.

    


    

    
The normative language I think should focus on maintaining the
      OAuth 2.0 contract for the entire logical authZ request, together
      with the basic contracts of 1) JAR and the 2) authZ endpoint.

    

    


    

    
Vladimir

    

    


    

    
On 10/01/2020 22:55, Justin Richer
      wrote:

    

    

      
      So we could solve this by saying the resulting data object of a
      PAR is a request object. Which might also contain a request object
      internally as well. In that case JAR should back off from saying
      it=E2=80=99s a JWT and instead say it=E2=80=99s a request object. O=
r we define a
      new term for this authorization request blob thing.
      


      

      
Or PAR could at least say that if it=E2=80=99s dere=
ferenced
        over a remote protocol then it MUST be a JWT, but otherwise it
        can be whatever you want. That=E2=80=99s where the real interop c=
oncerns
        come in.

      


      

      
=C2=A0=E2=80=94 Justin

        


          

            
On Jan 10, 2020, at 3:41 PM, Richard Backman,=

              Annabelle <richanna=3D40amazon.c=
om@dmarc.ietf.org>
              wrote:

            

            

              

                
Correct.
                  The problem becomes pretty clear in the context of
                  PAR, where the AS is generating and vending out the
                  URI at the PAR endpoint, and consuming it at the
                  authorization endpoint. From an interoperability
                  standpoint, it=E2=80=99s analogous to the AS vending an=

                  authorization code at the authorization endpoint and
                  consuming it at the token endpoint.

                

                

                  
=E2=80=93=C2=A0=


                  
Annabelle
                      Richard Backman

                  
AWS Identity<=
o:p
                        class=3D"">

                

                
=C2=A0

                
=C2=A0

                

                  
From:=C2=A0John Bradley
                      <ve7jtb@ve7jtb.com>=
;

                      Date:=C2=A0Friday,
                      January 10, 2020 at 12:29 PM

                      To:=C2=A0Brian
                      Campbell <bcampbell@pin=
gidentity.com>

                      Cc:=C2=A0Torsten
                      Lodderstedt <torsten@lodderstedt.net<=
/a>>,
                      Nat Sakimura <nat@sakimura.=
org>,
                      "Richard Backman, Annabelle" <richanna@amazon.com&=
gt;,
                      oauth <oauth@ietf.org>
                      Subject:=C2=A0[UNVERIFIED
                      SENDER] Re: [OAUTH-WG] PAR: pushed requests must
                      become JWTs

                

                

                  
=C2=A0

                

                

                  

                    
If
                      we assume the client posts a JAR and gets back a
                      reference.=C2=A0 Then the reference is to a JAR.=C2=
=A0

                  

                  

                    
=C2=A0

                  

                  

                    
I
                      think I see the problem.=C2=A0 If the server provid=
ing
                      the reference is associated with the AS then the
                      server dosen't need to dereference the object via
                      HTTP, so it could be a URN as an example.=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
So
                      yes it is not a interoperability issue for the
                      client.=C2=A0=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
I
                      will think about how I can finesse that.=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
I
                      agree it is not a change in intent.=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
I
                      will see if I can get our AD to accept that.

                  

                  

                    
=C2=A0

                  

                  

                    
John
                      B.=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                  

                    
=C2=A0

                  

                

                
=C2=A0

                

                  

                    
On
                      Fri, Jan 10, 2020, 4:57 PM Brian Campbell <b=
campbell@pingidentity.com>
                      wrote:

                  

                  

                    

                      
Sure but the text proposed (or
                        something like it) qualifies it such that there
                        aren't interoperability questions because it's
                        only an implementation detail to the AS who both
                        produces the URI and consumes its content.

                    

                    
=C2=A0

                    

                      

                        
On Fri, Jan 10, 2020 at 12:48 PM Joh=
n
                          Bradley <ve7jtb@ve7jtb.com>
                          wrote:

                      

                      

                        

                          

                            
It may be a
                              challenge to change text saying that the
                              contents of the resource could be
                              something other than a request object.=C2=A0=


                          

                          

                            
=C2=
=A0

                          

                          

                            
If not a request
                              object then what and how is that
                              interoperable are likely AD questions.=C2=A0=


                          

                          

                            
=C2=
=A0

                          

                          

                            
I could perhaps see=

                              changing it to must be a request object,
                              or other format defined by a profile.

                              

                              John B.=C2=A0=C2=A0
                          

                          

                            
=C2=
=A0

                          

                          

                            
=C2=
=A0

                            

                              

                                
On Fri, Jan 10,=

                                  2020, 3:45 PM Brian Campbell <b=
campbell@pingidentity.com>
                                  wrote:

                              

                              

                                

                                  

                                    
Agree and agree. But
                                      given that the change suggested by
                                      Annabelle has no impact on the
                                      client or interoperability,
                                      perhaps Nat or John could work the
                                      change into the draft during the
                                      edits that happen during the final
                                      stages of things?

                                  

                                  
=C2=A0

                                  

                                    

                                      
On Thu,
                                        Jan 9, 2020 at 1:56 AM Torsten
                                        Lodderstedt <torsten=3D40lodd=
erstedt.net@dmarc.ietf.org>
                                        wrote:
                                    

                                    

                                      

                                        

                                          
I
                                            would assume given the
                                            status of JAR, we don=E2=80=99=
t want
                                            to change it. And as I said,
                                            this difference does not
                                            impact interoperability from
                                            client perspective.

                                        

                                        

                                          


                                            

                                            

                                          

                                            
Am 09.01.2020
                                              um 00:58 schrieb Richard
                                              Backman, Annabelle
                                              <richanna=3D=
40amazon.com@dmarc.ietf.org>:

                                          

                                        

                                        

                                          

                                            

                                              
It would be=

                                                more appropriate to add
                                                the text to JAR rather
                                                than PAR. It doesn't
                                                seem right for PAR to
                                                retcon rules in JAR.
                                                Moving the text to JAR
                                                also highlights the
                                                weirdness of giving PAR
                                                special treatment.
=

                                              
=C2=A0
=

                                              
What if we
                                                changed this sentence in
                                                Section 5.2 of JAR:
=

                                              
=
The
                                                  contents of the
                                                  resource referenced by
                                                  the URI MUST be a
                                                  Request

                                              
=
Object.

                                              
=C2=A0
=

                                              
To:=C2=A0
=

                                              
=
The
                                                  contents of the
                                                  resource referenced by
                                                  the URI MUST be a
                                                  Request

                                              
=
Object,
                                                  unless the URI was
                                                  provided to the client
                                                  by the Authorization

                                              
=
Server.

                                              
=C2=A0
=

                                              
This would
                                                allow for use cases such
                                                as an AS that provides
                                                pre-defined request
                                                URIs, or vends request
                                                URIs via a client
                                                management console, or
                                                bakes them into their
                                                client apps.
=

                                              
=C2=A0
=

                                              
=E2=80=93=C2=A0
=

                                              
Annabelle
                                                Richard Backman
=

                                              
AWS Identit=
y
=

                                              
=C2=A0
=

                                              
On 1/8/20,
                                                2:50 PM, "Torsten
                                                Lodderstedt"
                                                <torsten=3D40lodderstedt.net@dmarc.ietf.org>
                                                wrote:

                                              
=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0 Hi,=C2=A0
=

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0you are
                                                right, PAR does not
                                                require the AS to
                                                represent the request as
                                                a JWT-based request
                                                object. The URI is used
                                                as internal reference
                                                only. That why the draft
                                                states

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0"There
                                                is no need to make the
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                authorization request
                                                data available to other
                                                parties via this
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                URI.=E2=80=9D

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0This
                                                difference matters from
                                                an AS implementation
                                                perspective, it doesn't
                                                matter from a client's
                                                (interop) perspective.
=

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0We may
                                                add a statement to PAR
                                                saying that request_uris
                                                issued by the PAR
                                                mechanism (MAY) deviate
                                                from the JAR definition.<=
o:p
                                                  class=3D"">
=

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0best
                                                regards,<=
/o:p>

                                              
=C2=A0=C2=A0=
=C2=A0
                                                Torsten.=C2=A0=C2=A0
=

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

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0> On
                                                8. Jan 2020, at 23:42,
                                                Richard Backman,
                                                Annabelle <richanna=3D=
40amazon.com@dmarc.ietf.org>
                                                wrote:

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0> Hi
                                                all,

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0> The
                                                current drafts of PAR
                                                (-00) and JAR (-20)
                                                require that the AS
                                                transform all pushed
                                                requests into JWTs. This
                                                requirement arises from
                                                the following:
=

                                              
=C2=A0=C2=A0=
=C2=A0 >
                                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=A2 PAR uses the
                                                request_uri parameter
                                                defined in JAR to
                                                communicate the pushed
                                                request to the
                                                authorization endpoint.
=

                                              
=C2=A0=C2=A0=
=C2=A0 >
                                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=A2 According to
                                                JAR, the resource
                                                referenced by
                                                request_uri MUST be a
                                                Request Object. (Section
                                                5.2)

                                              
=C2=A0=C2=A0=
=C2=A0 >
                                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=A2 Request Object
                                                is defined to be a JWT
                                                containing all the
                                                authorization request
                                                parameters. (Section
                                                2.1)

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0>
                                                There is no need for
                                                this requirement to
                                                support
                                                interoperability, as
                                                this is internal to the
                                                AS. It is also
                                                inconsistent with the
                                                rest of JAR, which
                                                avoids attempting to
                                                define the internal
                                                communications between
                                                the two AS endpoints.
                                                Worse, this restriction
                                                makes it harder for the
                                                authorization endpoint
                                                to leverage validation
                                                and other work performed
                                                at the PAR endpoint, as
                                                the state or outcome of
                                                that work must be forced
                                                into the JWT format (or
                                                retrieved via a
                                                subsequent service call
                                                or database lookup).
=

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0> =E2=80=93=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0>
                                                Annabelle Richard
                                                Backman

                                              
=C2=A0=C2=A0=
=C2=A0 > AWS
                                                Identity<=
/o:p>

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0
=

                                              
=C2=A0=C2=A0=
=C2=A0=C2=A0>
                                                _________________________=
______________________
=

                                              
=C2=A0=C2=A0=
=C2=A0 >
                                                OAuth mailing list
=

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0OAuth@ietf.org
=

                                              
=C2=A0=C2=A0=
=C2=A0 >=C2=A0https://www.ietf.org/mailman/listinfo/oauth
=

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

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

                                            

                                          

                                        

                                      

                                      
_________=
______________________________________

                                        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.=C2=A0 If you have
                                        received this communication in
                                        error, please notify the sender
                                        immediately by e-mail and delete
                                        the message and any file
                                        attachments from your computer.
                                        Thank you.

                              

                            

                          

                        

                      

                    

                    


                      CONFIDENTIALITY
                            NOTICE: This email may contain confidential
                            and privileged material for the sole use of
                            the intended recipient(s). Any review, use,
                            distribution or disclosure by others is
                            strictly prohibited..=C2=A0 If you have recei=
ved
                            this 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<=
/span>

              https://www.ietf.or=
g/mailman/listinfo/oauth

          

        

        

      

      

      

      
____________________________=
___________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    
--=20
Vladimir Dzhuvinov

  


--------------94006C41C77E1E3C5DE74D44--

--------------ms000001000806090209070408
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTExMDI4MDZaMC8G
CSqGSIb3DQEJBDEiBCBB48pDnHVPeQJcc/6hLL54K9D45dg+TT8CrUcEUTzBrDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAGBfYxOukTgRGp1S2LxkDWr5Q3MoMMts7lRnGOhb+QLiYACp
7dMMK+uuAH4CkAjHJ5xkuobXXrOffHrPODFXNV0NIY+zov4VSC5iZuRbKCExGtcwSlIpWHee
TzfFCqpGGq6ljefeW0YqppukWoPfZosiahfpVK77Ouak0f3SWpryHE2ur+dvOsen9TwO/mBL
SQLiq8Qza/lfWs9oI7oGZgsc26zuXILWlFv4oKqbGKluSOJme+8NlsoeF3FVMWCPOAeDGfwL
QSi1CBcIE4djYOljcISitIGh8kNsU8vjNQneGhzA3nWNM5xvSpys7ZZc1P7y30fLK/weYMLY
L0ZtuYkAAAAAAAA=
--------------ms000001000806090209070408--


From nobody Sat Jan 11 11:36: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 07185120096 for ; Sat, 11 Jan 2020 11:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level: 
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PW3WIg7g8GK for ; Sat, 11 Jan 2020 11:36:34 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3954E12004C for ; Sat, 11 Jan 2020 11:36:33 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id w47so5336091qtk.4 for ; Sat, 11 Jan 2020 11:36:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ybQrghtEi9G6bISKZu25fg2b7bEmPynvaszBcs+NYyI=; b=PWrznKcHEzAktYNFHkbI7RwNRlJSZl+sFPW5LlreId71/osS6E8tICUmS7YPPFrw3w 0tY57DGvUas6jeWi7tO7JtpGlLdTtJyen5gGofwp4F61FeI5XWSKm+AbMl+YMcrWwBFG 02wXCjeHwXKc4tcfnwG1SSlSJVSZKSP5IUGzxW/cUFT7a6jR9p/oHkrL6vHJh6EYzT2o PKeYnKq+Ueq3pkcVw0/fGTPerlAw2weXZEBXVtZjydj//+1V5ny7NUn3AvuTpyjM1f+7 An60Z/8ZfhXASYVLzMO7LC0lBBBMt0tNlV3Rf3ZYNNGXahMdu5QgP/uJxvD0xrXgW4/4 8snA==
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:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=ybQrghtEi9G6bISKZu25fg2b7bEmPynvaszBcs+NYyI=; b=cdTdRmpaCxwaBOSUlMblejuk72zbftLvCEXR8fONx+gkIDLL/3ONDyU4YXrwTI0Knx 5t08gs1/wEcaEuoXRW13QpC3VVqeuBKlh6mwrc1DRq8ETJ8ca3tdRC6A80t0+z3J9Wud 4dARNi1QzKjLDt9aFax3/rwFvJW/63WC6PTO2mmEXJxZGVxt9pTzjDxP+lQCyEaIsoyO w2YGl5Az9KqjSh9+4IftYALzAb5tNxhhkKpBJn8qnjnM2PrAL/y6M/w7RmKNreUFbRpr D7d/0iaYgTn7Y7ItsRZ5vCttEXb42X/BXvCcLfaP4TaxbuWzws5BU9IX/rVfLPHNC532 +Utw==
X-Gm-Message-State: APjAAAXfPnxmtNcKvw2MqeZmOrARRQwT7fUpFyJr89ZG86eqQ5w+3TCx Dy1m8pWV2Qaw08Gz3LBAxyeM0H3hpwdg5PVb
X-Google-Smtp-Source: APXvYqxsacvcdcBwxt7F8GXXqXF8V+HSdLBdRQdJ3kWIRcrSmUV530ok2Ul/ozoua4wL8XB8v7aaMQ==
X-Received: by 2002:aed:3f32:: with SMTP id p47mr8062523qtf.374.1578771391629;  Sat, 11 Jan 2020 11:36:31 -0800 (PST)
Received: from [192.168.86.36] ([191.115.91.53]) by smtp.gmail.com with ESMTPSA id c13sm2656908qko.87.2020.01.11.11.36.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jan 2020 11:36:30 -0800 (PST)
To: Vladimir Dzhuvinov , Mike Jones 
Cc: IETF oauth WG 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com>
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
Date: Sat, 11 Jan 2020 16:36:25 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com>
Content-Type: multipart/alternative; boundary="------------3584F9716D5265D80C78EBAC"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 11 Jan 2020 19:36:37 -0000

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

Yes JAR is not prohibiting paramater replication in the header. 

I will see if i can add something in final edits to call that out.

John B.

On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>
> Thanks Mike for the rfc7519 section-5.3
>  pointer. Can this
> parameter replication be used for client_id or the client_id ass "iss"
> even though it isn't explicitly mentioned in the JAR spec?
>
> On 11/01/2020 02:58, John Bradley wrote:
>> Right we just don't say to put the iss there in OIDC if it's
>> symetricly encrypted.
>
> OIDC doesn't have the symmetric key selection issue, I suppose that
> why the possibility to replicate params to the JWE header isn't
> mentioned at all. OIDC requires the top-level query params to
> represent a valid OAuth 2.0 request, and there client_id is required.
> If the client_id is present the client registration together with any
> present client_secret can be retrieved.
>
> I reread the JAR spec, this is the only place that mentions handling
> of symmetric JWE.
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>
>>    (b)  Verifying that the symmetric key for the JWE encryption is the
>>         correct one if the JWE is using symmetric encryption.
>
>
> Vladimir
>
>
>>
>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones > > wrote:
>>
>>     The technique of replicating JWT claims that need to be publicly
>>     visible in an encrypted JWT in the header is defined at
>>     https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick
>>     Hardt for bringing this need to my attention as we were finishing
>>     the JWT spec.)
>>
>>      
>>
>>                                                            -- Mike
>>
>>      
>>
>>     *From:* OAuth >     > *On Behalf Of * John Bradley
>>     *Sent:* Friday, January 10, 2020 2:15 PM
>>     *To:* Vladimir Dzhuvinov >     >
>>     *Cc:* IETF oauth WG >
>>     *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>>     Request (JAR) vs OIDC request object
>>
>>      
>>
>>     The intent was to do that, but specs change once the OAuth WG and
>>     IESG get there hands on them.  
>>
>>      
>>
>>     Being backwards compatible with OIDC is not a compelling argument
>>     to the IESG.
>>
>>      
>>
>>     We were mostly thinking of asymmetric encryption.  
>>
>>      
>>
>>     Specifying puting the issuer and or the audience in the headder
>>     has come up in the past but probably is not documented.  
>>
>>      
>>
>>     John B 
>>
>>      
>>
>>     On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>     > wrote:
>>
>>         Yes, putting the client_id into the JWE header is a way
>>         around the need
>>         to have the client_id outside the JWE as top-level authZ
>>         request parameter.
>>
>>         Unfortunately this work around isn't mentioned anywhere, I
>>         just checked
>>         the most recent draft-ietf-oauth-jwsreq-20.
>>
>>         Our DDoS attack mitigation (for OIDC request_uri) also relies
>>         on the
>>         presence of client_id as top-level parameter, together with
>>         requiring
>>         RPs to register their request_uri's (so that we don't need to
>>         build and
>>         store an index of all request_uri's). I just had a look at
>>         "DDoS Attack
>>         on the Authorization Server" and also realised the request_uri
>>         registration isn't explicitly mentioned as attack prevention
>>         ("the
>>         server should (a) check that the value of "request_uri"
>>         parameter does
>>         not point to an unexpected location").
>>
>>         https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>>         
>>
>>         To be honest, I feel quite bad about the situation with JAR
>>         we are in
>>         now. For some reason I had the impression that OAuth JAR was
>>         going to be
>>         the OIDC request / request_uri for general OAuth 2.0 use, as
>>         with other
>>         OIDC bits that later became general purpose OAuth 2.0 specs.
>>
>>         I find it unfortunate I didn't notice this when I was
>>         reviewing the spec
>>         in the past.
>>
>>         Vladimir
>>
>>
>>         On 10/01/2020 22:39, Filip Skokan wrote:
>>         > Vladimir,
>>         >
>>         > For that very case the payload claims may be repeated in
>>         the JWE protected header. An implementation wanting to handle
>>         this may look for iss/client_id there.
>>         >
>>         > Odesláno z iPhonu
>>         >
>>         >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>>         >:
>>         >>
>>         >> I just realised there is one class of JARs where it's
>>         practially
>>         >> impossible to process the request if merge isn't supported:
>>         >>
>>         >> The client submits a JAR encrypted (JWT) with a shared
>>         key. OIDC allows
>>         >> for that and specs a method for deriving the shared key
>>         from the
>>         >> client_secret:
>>         >>
>>         >>
>>         https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>>         
>>         >>
>>         >> If the JAR is encrypted with the client_secret, and there
>>         is no
>>         >> top-level client_id parameter, there's no good way for the
>>         OP to find
>>         >> out which client_secret to get to try to decrypt the JWE.
>>         Unless the OP
>>         >> keeps an index of all issued client_secret's.
>>         >>
>>         >>
>>         >> OP servers which require request_uri registration
>>         >> (require_request_uri_registration=true) and don't want to
>>         index all
>>         >> registered request_uri's, also have no good way to process
>>         a request_uri
>>         >> if the client_id isn't present as top-level parameter.
>>         >>
>>         >>
>>         >> Vladimir
>>         >>
>>         >>
>>         >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>         >>>
>>         >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>>         >:
>>         >>>> I think Torsten is speculating that is not a feature
>>         people use.   
>>         >>> I’m still trying to understand the use case for merging
>>         signed and unsigned parameters. Nat once explained a use
>>         case, where a client uses parameters signed by a 3rd party
>>         (some „certification authority“) in combination with
>>         transaction-specific parameters. Is this being done in the wild?
>>         >>>
>>         >>> PS: PAR would work with both modes.
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         
>>
> -- 
> Vladimir Dzhuvinov

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


  
    
  
  
    
Yes JAR is not prohibiting paramater replication in the header. 
      

    

    
I will see if i can add something in final edits to call that
      out.

    
John B.

    

    
On 1/11/2020 6:16 AM, Vladimir
      Dzhuvinov wrote:

    

    

      
      
Thanks Mike for the rfc7519
            section-5.3 pointer. Can this parameter replication be
          used for client_id or the client_id ass "iss" even though it
          isn't explicitly mentioned in the JAR spec?

        

      
On 11/01/2020 02:58, John Bradley
        wrote:

      

      

        
        
Right we just don't say to put the iss there in
          OIDC if it's symetricly encrypted. 

        

      

      
OIDC doesn't have the symmetric key selection issue, I suppose
        that why the possibility to replicate params to the JWE header
        isn't mentioned at all. OIDC requires the top-level query params
        to represent a valid OAuth 2.0 request, and there client_id is
        required. If the client_id is present the client registration
        together with any present client_secret can be retrieved. 

      

      
I reread the JAR spec, this is the only place that mentions
        handling of symmetric JWE.

      

      
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

      

      
 

      

        
   (b)  Verifying that the symmetric key for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

      

      


      

      
Vladimir

      


      

      


        

          
On Fri, Jan 10, 2020, 9:41
            PM Mike Jones <Michael.Jones@microsoft.com>
            wrote:

          

          

            

              

                
The
                    technique of replicating JWT claims that need to be
                    publicly visible in an encrypted JWT in the header
                    is defined at https://tools.ietf.org/html/rfc7519#section-5.3. 
                    (Thanks to Dick Hardt for bringing this need to my
                    attention as we were finishing the JWT spec.)

                
 

                
                                                      
                    -- Mike

                
 

                
From: OAuth <oauth-bounces@ietf.org>
                  On Behalf Of  John Bradley

                  Sent: Friday, January 10, 2020 2:15 PM

                  To: Vladimir Dzhuvinov <vladimir@connect2id.com>

                  Cc: IETF oauth WG <oauth@ietf.org>

                  Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured
                  Authorization Request (JAR) vs OIDC request object

                
 

                

                  

                    
The intent was to do that, but
                      specs change once the OAuth WG and IESG get there
                      hands on them.  

                    

                      
 

                    

                    

                      
Being backwards compatible
                        with OIDC is not a compelling argument to the
                        IESG.

                    

                    

                      
 

                    

                    

                      
We were mostly thinking of
                        asymmetric encryption.  

                    

                    

                      
 

                    

                    

                      
Specifying puting the issuer
                        and or the audience in the headder has come up
                        in the past but probably is not documented.  

                    

                    

                      
 

                    

                    

                      
John B 

                    

                    
 

                    

                      

                        
On Fri, Jan 10, 2020, 6:29
                          PM Vladimir Dzhuvinov <vladimir@connect2id.com>
                          wrote:

                      

                      

                        
Yes, putting the client_id
                          into the JWE header is a way around the need

                          to have the client_id outside the JWE as
                          top-level authZ request parameter.

                          

                          Unfortunately this work around isn't mentioned
                          anywhere, I just checked

                          the most recent draft-ietf-oauth-jwsreq-20.

                          

                          Our DDoS attack mitigation (for OIDC
                          request_uri) also relies on the

                          presence of client_id as top-level parameter,
                          together with requiring

                          RPs to register their request_uri's (so that
                          we don't need to build and

                          store an index of all request_uri's). I just
                          had a look at "DDoS Attack

                          on the Authorization Server" and also realised
                          the request_uri

                          registration isn't explicitly mentioned as
                          attack prevention ("the

                          server should (a) check that the value of
                          "request_uri" parameter does

                          not point to an unexpected location").

                          

                          https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

                          

                          To be honest, I feel quite bad about the
                          situation with JAR we are in

                          now. For some reason I had the impression that
                          OAuth JAR was going to be

                          the OIDC request / request_uri for general
                          OAuth 2.0 use, as with other

                          OIDC bits that later became general purpose
                          OAuth 2.0 specs.

                          

                          I find it unfortunate I didn't notice this
                          when I was reviewing the spec

                          in the past.

                          

                          Vladimir

                          

                          

                          On 10/01/2020 22:39, Filip Skokan wrote:

                          > Vladimir, 

                          >

                          > For that very case the payload claims may
                          be repeated in the JWE protected header. An
                          implementation wanting to handle this may look
                          for iss/client_id there. 

                          >

                          > Odesláno z iPhonu

                          >

                          >> 10. 1. 2020 v 21:19, Vladimir
                          Dzhuvinov <vladimir@connect2id.com>:

                          >>

                          >> I just realised there is one class
                          of JARs where it's practially

                          >> impossible to process the request if
                          merge isn't supported:

                          >>

                          >> The client submits a JAR encrypted
                          (JWT) with a shared key. OIDC allows

                          >> for that and specs a method for
                          deriving the shared key from the

                          >> client_secret:

                          >>

                          >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                          >>

                          >> If the JAR is encrypted with the
                          client_secret, and there is no

                          >> top-level client_id parameter,
                          there's no good way for the OP to find

                          >> out which client_secret to get to try
                          to decrypt the JWE. Unless the OP

                          >> keeps an index of all issued
                          client_secret's.

                          >>

                          >>

                          >> OP servers which require request_uri
                          registration

                          >>
                          (require_request_uri_registration=true) and
                          don't want to index all

                          >> registered request_uri's, also have
                          no good way to process a request_uri

                          >> if the client_id isn't present as
                          top-level parameter.

                          >>

                          >>

                          >> Vladimir

                          >>

                          >>

                          >>> On 10/01/2020 20:13, Torsten
                          Lodderstedt wrote:

                          >>>

                          >>>>> Am 10.01.2020 um 16:53
                          schrieb John Bradley <ve7jtb@ve7jtb.com>:

                          >>>> I think Torsten is
                          speculating that is not a feature people use. 
                           

                          >>> I’m still trying to understand
                          the use case for merging signed and unsigned
                          parameters. Nat once explained a use case,
                          where a client uses parameters signed by a 3rd
                          party (some „certification authority“) in
                          combination with transaction-specific
                          parameters. Is this being done in the wild? 

                          >>>

                          >>> PS: PAR would work with both
                          modes.

                          

                          

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                      

                    

                  

                

              

            

          

        

      

      
-- 
Vladimir Dzhuvinov

    

  


--------------3584F9716D5265D80C78EBAC--


From matt.dehaast@coil.com  Mon Jan 13 05:42: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 91F78120103 for ; Mon, 13 Jan 2020 05:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 8YmfmI6RC6Y4 for ; Mon, 13 Jan 2020 05:42:46 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450: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 82D1E120104 for ; Mon, 13 Jan 2020 05:42:46 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id i16so8478817edr.5 for ; Mon, 13 Jan 2020 05:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FbHteVh5brSKLQkeiFO5dFJJJUhXTHIo6FIFOOInQoM=; b=XS2YaArNbXxTISKX7iVY5kged7P8O0JndBla4Fws/7QjRzvfaBzmw2GVkCvYkzStVK U5QK3yaRLbp5LHV2XyJMs4T6NaIhmZ29ilTvUYMo4HsgjBee0W9i4M89BSP7Bm5yHmsV XIVc6rTbZbLXkohRfSNTJeYikXwzzdu6VRcEFg5gqK2ZBeGBl8U/5I4JFyFNx6aAaJGV aFoH8mZUzgRL8lBxGnGPLZaEzOvVuqGQ2i97yRcNt59P9/4GCPBZ4dhBKsr8b5r4A0XF GadpZWy/6ZXFJspJagteKpNPokTlgPhDJM0EZHwLo2xo2XZJkrMgXzkLKDgI0iueDxlE 81mw==
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=FbHteVh5brSKLQkeiFO5dFJJJUhXTHIo6FIFOOInQoM=; b=FF9WQ4Pte6gtv7+oEsqJeb9FtdGQRGKvV01tCE1Z1eBR6/aC5VgJTBTlb78tRe3RBn oOx1FXdLMbmCvS0twxm/xUevG44nfJNIMQSZIIMr5dNQQjWgODP/VNbIIWPzq8Nk/Byx hu+nU8Pth3d44nYuT72CDk8AKdK8EjhwAbA6/Mng+df6V4VeZc6Ucpe5xcc4vvRK0kkM aUGKMBR+dR9f3ewZ6wxRfqkbWlzOiCe8lQofB85s8ow1+PtNLV1DL5tBo1hRw5Z1DopV C6Y4KRhGwaZhs5gZ3TKp0q5zMxe51AESyOoSCTXDaFwG72fJY+ST2qkmi9qMEtVpFD2A 2h5A==
X-Gm-Message-State: APjAAAXssp/oElo4lHiBoW8S7r9LacqfgA3JyjB9R6iPFde/XeF6e+Tp udkqlBHg0UeeDZezSYHe7L7QdBAHClmR1tCb8xXWX0MSLSY=
X-Google-Smtp-Source: APXvYqxzmINZ6QZoF4E4FVa+VXz2kMM2PQ+7bdcHy7b/G8VfFIE1Al3i9ToK0ra72dcMwRWeoYdkN/eEZNm2DU2KX5E=
X-Received: by 2002:a50:f785:: with SMTP id h5mr16693482edn.209.1578922964893;  Mon, 13 Jan 2020 05:42:44 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Matthew De Haast 
Date: Mon, 13 Jan 2020 15:42:33 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000735f81059c05a615"
Archived-At: 
X-Mailman-Approved-At: Mon, 13 Jan 2020 06:33:48 -0800
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 13 Jan 2020 14:31:05 -0000

--000000000000735f81059c05a615
Content-Type: text/plain; charset="UTF-8"

+1 for adoption

Matt

On Mon, Jan 6, 2020 at 9:38 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1 for adoption

Matt
On Mon, J=
an 6, 2020 at 9:38 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

T=
his is a call for adoption for the=C2=A0OAuth 2.0 Rich Authorization Req=
uests document.
=C2=A0
Plea=
se, let us know if you support or object to the adoption of this document a=
s a working group document by Jan 20th.

Regard=
s,
=C2=A0Rifaat & Hannes

<=
/div>
_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000735f81059c05a615--


From nobody Mon Jan 13 07:57: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 B34A3120811 for ; Mon, 13 Jan 2020 07:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level: 
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=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 A-015aFpH5l6 for ; Mon, 13 Jan 2020 07:57:17 -0800 (PST)
Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (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 AF4BA12080B for ; Mon, 13 Jan 2020 07:57:14 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id r25XiNobiigqCr25Yi1nlU; Mon, 13 Jan 2020 08:57:13 -0700
To: John Bradley , Mike Jones 
Cc: IETF oauth WG 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>
Date: Mon, 13 Jan 2020 17:57:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080403020503050708070400"
X-CMAE-Envelope: MS4wfJIckjzrkS36TvL1IduXeBAMUIrF0MMIpMZ1NOKmjAjK7A0ay4yhS6sokwOmcrjnUdBRSRfg5mjNM+7dQK0ttVLATaHAaXX3bMp49hWFD2nY6I4S6bhw qX/ZEERjA0wKqlUghoKNCz0Y3T56H6bvBaVSuutQ8UMnpSANuQMLjn1vrwBgCkTJYuLqe25nJY6czqBbz79uFYUghM+BAc1BxcqQIg2dbfVsMuiYZ8XFYoev UiiPNONVeI5PMPFse7hrug==
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Mon, 13 Jan 2020 15:57:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms080403020503050708070400
Content-Type: multipart/alternative;
 boundary="------------83782A4DE05D6EECDF3352C7"
Content-Language: en-US

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

John, thanks, much appreciated!

On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header.=C2=A0
>
> I will see if i can add something in final edits to call that out.
>
> John B.
>
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>
>> Thanks Mike for the rfc7519 section-5.3
>>  pointer. Can this
>> parameter replication be used for client_id or the client_id ass
>> "iss" even though it isn't explicitly mentioned in the JAR spec?
>>
>> On 11/01/2020 02:58, John Bradley wrote:
>>> Right we just don't say to put the iss there in OIDC if it's
>>> symetricly encrypted.
>>
>> OIDC doesn't have the symmetric key selection issue, I suppose that
>> why the possibility to replicate params to the JWE header isn't
>> mentioned at all. OIDC requires the top-level query params to
>> represent a valid OAuth 2.0 request, and there client_id is required.
>> If the client_id is present the client registration together with any
>> present client_secret can be retrieved.
>>
>> I reread the JAR spec, this is the only place that mentions handling
>> of symmetric JWE.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>
>>>    (b)  Verifying that the symmetric key for the JWE encryption is th=
e
>>>         correct one if the JWE is using symmetric encryption.
>>
>>
>> Vladimir
>>
>>
>>>
>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>> >
>>> wrote:
>>>
>>>     The technique of replicating JWT claims that need to be publicly
>>>     visible in an encrypted JWT in the header is defined at
>>>     https://tools.ietf.org/html/rfc7519#section-5.3.=C2=A0 (Thanks to=

>>>     Dick Hardt for bringing this need to my attention as we were
>>>     finishing the JWT 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=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 >>     > *On Behalf Of * John Bradley
>>>     *Sent:* Friday, January 10, 2020 2:15 PM
>>>     *To:* Vladimir Dzhuvinov >>     >
>>>     *Cc:* IETF oauth WG >
>>>     *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>>>     Request (JAR) vs OIDC request object
>>>
>>>     =C2=A0
>>>
>>>     The intent was to do that, but specs change once the OAuth WG
>>>     and IESG get there hands on them.=C2=A0=C2=A0
>>>
>>>     =C2=A0
>>>
>>>     Being backwards compatible with OIDC is not a compelling
>>>     argument to the IESG.
>>>
>>>     =C2=A0
>>>
>>>     We were mostly thinking of asymmetric encryption.=C2=A0=C2=A0
>>>
>>>     =C2=A0
>>>
>>>     Specifying puting the issuer and or the audience in the headder
>>>     has come up in the past but probably is not documented.=C2=A0=C2=A0=

>>>
>>>     =C2=A0
>>>
>>>     John B=C2=A0
>>>
>>>     =C2=A0
>>>
>>>     On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>>     > wrote:=

>>>
>>>         Yes, putting the client_id into the JWE header is a way
>>>         around the need
>>>         to have the client_id outside the JWE as top-level authZ
>>>         request parameter.
>>>
>>>         Unfortunately this work around isn't mentioned anywhere, I
>>>         just checked
>>>         the most recent draft-ietf-oauth-jwsreq-20.
>>>
>>>         Our DDoS attack mitigation (for OIDC request_uri) also
>>>         relies on the
>>>         presence of client_id as top-level parameter, together with
>>>         requiring
>>>         RPs to register their request_uri's (so that we don't need
>>>         to build and
>>>         store an index of all request_uri's). I just had a look at
>>>         "DDoS Attack
>>>         on the Authorization Server" and also realised the request_ur=
i
>>>         registration isn't explicitly mentioned as attack prevention
>>>         ("the
>>>         server should (a) check that the value of "request_uri"
>>>         parameter does
>>>         not point to an unexpected location").
>>>
>>>         https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#sectio=
n-10.4.1
>>>         
>>>
>>>         To be honest, I feel quite bad about the situation with JAR
>>>         we are in
>>>         now. For some reason I had the impression that OAuth JAR was
>>>         going to be
>>>         the OIDC request / request_uri for general OAuth 2.0 use, as
>>>         with other
>>>         OIDC bits that later became general purpose OAuth 2.0 specs.
>>>
>>>         I find it unfortunate I didn't notice this when I was
>>>         reviewing the spec
>>>         in the past.
>>>
>>>         Vladimir
>>>
>>>
>>>         On 10/01/2020 22:39, Filip Skokan wrote:
>>>         > Vladimir,
>>>         >
>>>         > For that very case the payload claims may be repeated in
>>>         the JWE protected header. An implementation wanting to
>>>         handle this may look for iss/client_id there.
>>>         >
>>>         > Odesl=C3=A1no z iPhonu
>>>         >
>>>         >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>>>         >:
>>>         >>
>>>         >> =EF=BB=BFI just realised there is one class of JARs where =
it's
>>>         practially
>>>         >> impossible to process the request if merge isn't supported=
:
>>>         >>
>>>         >> The client submits a JAR encrypted (JWT) with a shared
>>>         key. OIDC allows
>>>         >> for that and specs a method for deriving the shared key
>>>         from the
>>>         >> client_secret:
>>>         >>
>>>         >>
>>>         https://openid.net/specs/openid-connect-core-1_0.html#Encrypt=
ion
>>>         
>>>         >>
>>>         >> If the JAR is encrypted with the client_secret, and there
>>>         is no
>>>         >> top-level client_id parameter, there's no good way for
>>>         the OP to find
>>>         >> out which client_secret to get to try to decrypt the JWE.
>>>         Unless the OP
>>>         >> keeps an index of all issued client_secret's.
>>>         >>
>>>         >>
>>>         >> OP servers which require request_uri registration
>>>         >> (require_request_uri_registration=3Dtrue) and don't want t=
o
>>>         index all
>>>         >> registered request_uri's, also have no good way to
>>>         process a request_uri
>>>         >> if the client_id isn't present as top-level parameter.
>>>         >>
>>>         >>
>>>         >> Vladimir
>>>         >>
>>>         >>
>>>         >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>         >>>
>>>         >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>>>         >:
>>>         >>>> I think Torsten is speculating that is not a feature
>>>         people use.=C2=A0 =C2=A0
>>>         >>> I=E2=80=99m still trying to understand the use case for m=
erging
>>>         signed and unsigned parameters. Nat once explained a use
>>>         case, where a client uses parameters signed by a 3rd party
>>>         (some =E2=80=9Ecertification authority=E2=80=9C) in combinati=
on with
>>>         transaction-specific parameters. Is this being done in the
>>>         wild?
>>>         >>>
>>>         >>> PS: PAR would work with both modes.
>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://
>>>         
>>>


--------------83782A4DE05D6EECDF3352C7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
John, thanks, much appreciated!

    

    
On 11/01/2020 21:36, John Bradley
      wrote:

    

    

      
      
Yes JAR is not prohibiting paramater replication in the
        header.=C2=A0 

      

      
I will see if i can add something in final edits to call that
        out.

      
John B.

      

      
On 1/11/2020 6:16 AM, Vladimir
        Dzhuvinov wrote:

      

      
=

        
        
Thanks Mike for the rfc7519
              section-5.3 pointer. Can this parameter replication be
            used for client_id or the client_id ass "iss" even though it
            isn't explicitly mentioned in the JAR spec?

          

        
On 11/01/2020 02:58, John Bradley
          wrote:

        

        

          
          
Right we just don't say to put the iss there
            in OIDC if it's symetricly encrypted. 

          

        

        
OIDC doesn't have the symmetric key selection issue, I
          suppose that why the possibility to replicate params to the
          JWE header isn't mentioned at all. OIDC requires the top-level
          query params to represent a valid OAuth 2.0 request, and there
          client_id is required. If the client_id is present the client
          registration together with any present client_secret can be
          retrieved. 

        

        
I reread the JAR spec, this is the only place that mentions
          handling of symmetric JWE.

        

        
https://tools.ietf.org/html/draft-ie=
tf-oauth-jwsreq-20#section-10.2

        

        
 

        

          
   (b)  Verifying that the symmetric key=
 for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

        

        


        

        
Vladimir

        


        

        


          

            
On Fri, Jan 10, 2020, 9=
:41
              PM Mike Jones <Michael.Jones@microsoft.com&=
gt;
              wrote:

            

            

              

                

                  
Th=
e
                      technique of replicating JWT claims that need to
                      be publicly visible in an encrypted JWT in the
                      header is defined at https://tools.ietf.org/h=
tml/rfc7519#section-5.3.=C2=A0
                      (Thanks to Dick Hardt for bringing this need to my
                      attention as we were finishing the JWT 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=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=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  John Bradley

                    Sent: Friday, January 10, 2020 2:15 PM

                    To: Vladimir Dzhuvinov <vladimir@connect2id.com>

                    Cc: IETF oauth WG <oauth@i=
etf.org>

                    Subject: [EXTERNAL] Re: [OAUTH-WG] JWT
                    Secured Authorization Request (JAR) vs OIDC request
                    object

                  
=C2=A0

                  

                    

                      
The intent was to do that,
                        but specs change once the OAuth WG and IESG get
                        there hands on them.=C2=A0=C2=A0

                      

                        
=C2=A0

                      

                      

                        
Being backwards compatible=

                          with OIDC is not a compelling argument to the
                          IESG.

                      

                      

                        
=C2=A0

                      

                      

                        
We were mostly thinking of=

                          asymmetric encryption.=C2=A0=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        
Specifying puting the
                          issuer and or the audience in the headder has
                          come up in the past but probably is not
                          documented.=C2=A0=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        
John B=C2=A0

                      

                      
=C2=A0

                      

                        

                          
On Fri, Jan 10, 2020,
                            6:29 PM Vladimir Dzhuvinov <vladimir@connect2i=
d.com>
                            wrote:

                        

                        

                          
Yes, putting the
                            client_id into the JWE header is a way
                            around the need

                            to have the client_id outside the JWE as
                            top-level authZ request parameter.

                            

                            Unfortunately this work around isn't
                            mentioned anywhere, I just checked

                            the most recent draft-ietf-oauth-jwsreq-20.
                            

                            Our DDoS attack mitigation (for OIDC
                            request_uri) also relies on the

                            presence of client_id as top-level
                            parameter, together with requiring

                            RPs to register their request_uri's (so that
                            we don't need to build and

                            store an index of all request_uri's). I just
                            had a look at "DDoS Attack

                            on the Authorization Server" and also
                            realised the request_uri

                            registration isn't explicitly mentioned as
                            attack prevention ("the

                            server should (a) check that the value of
                            "request_uri" parameter does

                            not point to an unexpected location").

                            

                            https://tools.ietf=
=2Eorg/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

                            

                            To be honest, I feel quite bad about the
                            situation with JAR we are in

                            now. For some reason I had the impression
                            that OAuth JAR was going to be

                            the OIDC request / request_uri for general
                            OAuth 2.0 use, as with other

                            OIDC bits that later became general purpose
                            OAuth 2.0 specs.

                            

                            I find it unfortunate I didn't notice this
                            when I was reviewing the spec

                            in the past.

                            

                            Vladimir

                            

                            

                            On 10/01/2020 22:39, Filip Skokan wrote:

                            > Vladimir, 

                            >

                            > For that very case the payload claims
                            may be repeated in the JWE protected header.
                            An implementation wanting to handle this may
                            look for iss/client_id there. 

                            >

                            > Odesl=C3=A1no z iPhonu

                            >

                            >> 10. 1. 2020 v 21:19, Vladimir
                            Dzhuvinov <vladimir@connect2i=
d.com>:

                            >>

                            >> =EF=BB=BFI just realised there is on=
e class
                            of JARs where it's practially

                            >> impossible to process the request
                            if merge isn't supported:

                            >>

                            >> The client submits a JAR encrypted
                            (JWT) with a shared key. OIDC allows

                            >> for that and specs a method for
                            deriving the shared key from the

                            >> client_secret:

                            >>

                            >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                            >>

                            >> If the JAR is encrypted with the
                            client_secret, and there is no

                            >> top-level client_id parameter,
                            there's no good way for the OP to find

                            >> out which client_secret to get to
                            try to decrypt the JWE. Unless the OP

                            >> keeps an index of all issued
                            client_secret's.

                            >>

                            >>

                            >> OP servers which require
                            request_uri registration

                            >>
                            (require_request_uri_registration=3Dtrue) and=

                            don't want to index all

                            >> registered request_uri's, also have
                            no good way to process a request_uri

                            >> if the client_id isn't present as
                            top-level parameter.

                            >>

                            >>

                            >> Vladimir

                            >>

                            >>

                            >>> On 10/01/2020 20:13, Torsten
                            Lodderstedt wrote:

                            >>>

                            >>>>> Am 10.01.2020 um 16:53
                            schrieb John Bradley <ve7jtb@ve7jtb.com<=
/a>>:

                            >>>> I think Torsten is
                            speculating that is not a feature people
                            use.=C2=A0 =C2=A0

                            >>> I=E2=80=99m still trying to unde=
rstand
                            the use case for merging signed and unsigned
                            parameters. Nat once explained a use case,
                            where a client uses parameters signed by a
                            3rd party (some =E2=80=9Ecertification author=
ity=E2=80=9C)
                            in combination with transaction-specific
                            parameters. Is this being done in the wild?
                            

                            >>>

                            >>> PS: PAR would work with both
                            modes.

                            

                            

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org=


                            https://

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


--------------83782A4DE05D6EECDF3352C7--

--------------ms080403020503050708070400
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTMxNTU3MTBaMC8G
CSqGSIb3DQEJBDEiBCDuWqDy2XOHoaB2qrzXYVViKGRb8/H/hU8ud3TqiVVe2DBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAGyG9Uia72x+7Edz8h6i85C4TMv2SIa1EipxRnmQL5un0E57
Mw2Yax8XAu8YnPLQ5t+xA+fHT2Y5b7hoUExOHZYJuCXfnmwav54HAz5kF88eGEe09blgtE8p
ntpCSlysunhelLz3ApfGrE0op29ok38izSlFryz8kQ46P0t5CMeImO/XjUq5VLxu66YUo3+z
3z61MXb1VBXgYBw27Yt+7zLqBPAWPvmYUJCkb86+1ZVWvAMo9Qe+gXOquvHCCkOsp0NNns4C
9bAa/HxDd9kD0XQ7f++fU6HgT21IokqU/vTwBlMUIB/yaknR51JH+Oz0H322W4bvuVurIAGn
rehcA28AAAAAAAA=
--------------ms080403020503050708070400--


From nobody Mon Jan 13 09:19: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 C128012086C for ; Mon, 13 Jan 2020 09:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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=2otwLKAK; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=poV+JFy6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh-5hkIMmN6a for ; Mon, 13 Jan 2020 09:19:07 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150081.outbound.protection.outlook.com [40.107.15.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820F512004A for ; Mon, 13 Jan 2020 09:19:07 -0800 (PST)
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=35fARIDb6N342JehGOY+D8gLriphx5VdbEHBqjbkAkg=; b=2otwLKAKNHa0NL+Al1NMBZcF6TQpgofkNC9DJUnkTJz8too0oGc4H7Dq03VDnOCj7pIYl/V3s68PAawQbxOu1bY74MHD6zks/k/foLTI85CA5MGQ0If1EjEoJ3bAM5XMk00pk+XuZlYEoxynh1z6CDtTzW+Eyg6PaQZbFfOpAfo=
Received: from VI1PR08CA0126.eurprd08.prod.outlook.com (2603:10a6:800:d4::28) by AM6PR08MB5220.eurprd08.prod.outlook.com (2603:10a6:20b:c3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Mon, 13 Jan 2020 17:19:04 +0000
Received: from AM5EUR03FT062.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::205) by VI1PR08CA0126.outlook.office365.com (2603:10a6:800:d4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Mon, 13 Jan 2020 17:19:04 +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 AM5EUR03FT062.mail.protection.outlook.com (10.152.17.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Mon, 13 Jan 2020 17:19:03 +0000
Received: ("Tessian outbound 0eaff1016ea4:v40"); Mon, 13 Jan 2020 17:19:03 +0000
X-CR-MTA-TID: 64aa7808
Received: from 7d98fa9b512c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 53C0764A-B3D9-491A-BCF3-B36DCACA1ED3.1;  Mon, 13 Jan 2020 17:18:58 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7d98fa9b512c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 13 Jan 2020 17:18:58 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V4SbYPPiK3y9QoOdBkfAUifE6NUZVg9Z5hbmMJvSXO67RM9zp/y8gQcytND9Dui1MCuLqnu1Ilc4RWksS4ZU3GNHm+fNIh9GAySqY7vPbmg2yAkWE2FIraAn1vbKL+E9BA+IaEBIr39zb7A3liR3LVhPtCA5QLECYJQpSgkn0vGsLEX42gCs43On/EYvt+mSlkaS/GNnxIbTO9bmLdKDMPKY/9x6RmYuDX7gsPSfU/SSy8oQUgKorhJQJgfJj2NKCPlR+LTNjZ4tAocj87u3JHyyDWofYnR1BPG3UmA4J+Tg04RTl95NnvlTwU1q6bx+Ci8DPaLNL1YtPa6LMaQRJw==
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=fyKE8q8XR3FWapPPxzPQkVzm6Idc3DFQyosPLBpxlLQ=; b=UKTPHLsMEgsQ176mw6a+Hg6xP7drhs4oo2gdOMQ+yIP269MS/RKPrrwt8b5IedB6mYVE8Hd2HEMVJsOWEDGyvGTlcxq++yPVq7A/aJEltiEZyHBFgKxmJM70paYVYb7u8rF6DeGeGtbq55wUpWP69BGBcPRzmWh4nxl/eKOvSIhSyF++837666dqhpVDHePUqhEDucilzkFWTVLdd/OwrQ8pIT2d9/PiAz/URaFBzDMY44hHso7rDOBsfzoYV5vVrlpmBtaJN/Xh/1jW6VQjxN2r1s9bh7VlXh7imKhyCPTq1YDMdTvm5La7ig1pN3Iy0kkUAyPvlOUh0IcOT2J80A==
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=fyKE8q8XR3FWapPPxzPQkVzm6Idc3DFQyosPLBpxlLQ=; b=poV+JFy657FOCJbdVG//UPd75TFSMyXPpQyQ/82kItkLdw4KID74QmTa4AACEmx+k2osrBDHzEfB/+NqX3z5k9U8wz9ZYG2LptIKUkTtCsGGtZR2wOUp87rFFAtveJxEHVP2kG8FqxHKCTmJAC6FctnTm21pD1at+fyES14PV/I=
Received: from AM6PR08MB4423.eurprd08.prod.outlook.com (20.179.7.140) by AM6PR08MB4213.eurprd08.prod.outlook.com (20.178.91.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Mon, 13 Jan 2020 17:18:57 +0000
Received: from AM6PR08MB4423.eurprd08.prod.outlook.com ([fe80::11a9:a944:c946:3030]) by AM6PR08MB4423.eurprd08.prod.outlook.com ([fe80::11a9:a944:c946:3030%7]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 17:18:57 +0000
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Thread-Topic: Doodle Poll for scheduling a discussion on proof-of-possession tokens
Thread-Index: AdXKNYbvqbCy5wXMS7qgwOQdzXjLlA==
Date: Mon, 13 Jan 2020 17:18:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ts-tracking-id: b0272e45-0413-4c85-85ed-37e3af1d8eca.0
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [195.149.223.43]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: ff53b2a7-ec7f-45bb-7c45-08d7984cb05f
X-MS-TrafficTypeDiagnostic: AM6PR08MB4213:|AM6PR08MB5220:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:5516;OLM:9508;
x-forefront-prvs: 028166BF91
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(396003)(376002)(366004)(39860400002)(189003)(199004)(40434004)(76116006)(64756008)(66556008)(66476007)(66946007)(66446008)(2906002)(55016002)(9686003)(6916009)(5660300002)(81166006)(7696005)(81156014)(6506007)(33656002)(52536014)(26005)(966005)(186003)(4744005)(478600001)(8676002)(316002)(86362001)(8936002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4213; H:AM6PR08MB4423.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: kegs3BGy6ROp5leaGF8FwD5DUSbYCXB9lZgPjcYYh9vNF9SBzFxE93bNvRfJktxYIItCnVXI0HUS7FolFXqCDRemVb0n9mbxP+rKZopALGlYT7isVL2OE1cfIvOXIiezU+73bsbPt1m8VED9R8WooZXHug8Szt0JeLZm1ON9NPFQCbDRzrrsTTT26EavWOXBPi4aFoP3n9pIsS1PN5jJHZnJPfQnccZ+O8zCF32FZ19L9MrfUz0mkBjvkVhD+D7aUuF0usjurzLb0t/1tYdrhhB8+8l+7IQ7dK1UjySlr61dzXVL51l06l6jStr/YIxSP8Gi+s0twMqPBFnFft8pGBvSe/q+/zRM6Rq9QtzsO+anzIr2HMjUsecS4hiv5WZE2jb9gifG0LEJIBYhAqt1d3CZRmDkrgkYzAodRL56MBiIj1n/45xW9azVF7Ijw8esRTva4PjXGKZKs3awHdWlOIc/Ef58pW6QBtQmF+IcPPLv1QKCwBQZaOK8vxJpIEMrnPY3ai0Ki/ytngz11PgBDfnBkbN6iA19dgekRm11+M0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB4423C3515932DB8E1C9B3595FA350AM6PR08MB4423eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4213
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT062.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(346002)(396003)(40434004)(199004)(189003)(356004)(36906005)(86362001)(8936002)(9686003)(55016002)(70206006)(70586007)(336012)(26826003)(8676002)(7696005)(81156014)(2906002)(6916009)(33656002)(478600001)(81166006)(5660300002)(6506007)(52536014)(26005)(316002)(186003)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5220; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: 83505696-1c0f-44ac-1ecf-08d7984cac6d
X-Forefront-PRVS: 028166BF91
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: LsZWZzR2omhq2McCFXZoWnRjOhkrbDzhqSj0SOuIw+nHo40F+9SoKjM3ht/4j7AuX+mcjY3IQL3JqMv+/VAiP+qP1AVwEDIpIncoReim0ritXlHOdSJPu7p4Rtm+0+DSePO4LfTjxLeib/WQuOgNTTOo7Pgtd+WTxDVG5xpk13GblXyiFd9tdT5aDK0oBPvRkxDl/hlFTNDR0rnzzQIntXT+dU//dVawIQiU45MdcLXTKB/JPM2Upbtbfvxe13ksbLK4qyC2t48SYToWXAFSJgIPI7VfvNa67KE9OKrPri859k0rqMa/MSWIBdzaVFSu2bW8vLVhlehoVtl6n8y61liOqbjEAE6Gy80IbpXO+NFUB7ByFmbQt7YkDNyNikGgy6ouFFjt5mGmguhJI192PKX3u69LOaVO2RDSxOow+tq4aX/tErvp0ELXwkNg/ascU/gax88d1OgFD9wXnASpHzc5b/+VQMY1W1YGtqj9/viw+MT1wfyVs1IUstLlkwlBhxYMvRQzMF4mlDKsseHLBdh5bTZWke99F7RKNuW4vpH3+UKt4VKxw9YuuhShiI4J
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2020 17:19:03.9638 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ff53b2a7-ec7f-45bb-7c45-08d7984cb05f
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: AM6PR08MB5220
Archived-At: 
Subject: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession 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, 13 Jan 2020 17:19:11 -0000

--_000_AM6PR08MB4423C3515932DB8E1C9B3595FA350AM6PR08MB4423eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

at the Singapore IETF meeting we talked about setting time aside for discus=
sing proof-of-possession tokens.

To schedule a call we put a Doodle poll together:
https://doodle.com/poll/sqhbeeg6knp435ag

Please let us know by the end of the week what dates work for you.

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. 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 c=
opy the information in any medium. Thank you.

--_000_AM6PR08MB4423C3515932DB8E1C9B3595FA350AM6PR08MB4423eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 


at the Singapore IETF meeting we talked about settin=
g time aside for discussing proof-of-possession tokens.



 


To schedule a call we put a Doodle poll together: 


https://doodle.com/poll/sqhbeeg=
6knp435ag


 


Please let us know by the end of the week what dates=
 work for you.



 


Ciao


Hannes & Rifaat<=
/span>



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



--_000_AM6PR08MB4423C3515932DB8E1C9B3595FA350AM6PR08MB4423eurp_--


From nobody Mon Jan 13 09:32: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 B9B8A12086C for ; Mon, 13 Jan 2020 09:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7QfBQ_5_rOo for ; Mon, 13 Jan 2020 09:32:50 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DDC12008F for ; Mon, 13 Jan 2020 09:32:50 -0800 (PST)
Received: from [192.168.3.142] (c-24-60-137-1.hsd1.ma.comcast.net [24.60.137.1]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00DHWheS024577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 12:32:45 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_016A2591-A6B2-4CD0-A659-97B55AD466CF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 13 Jan 2020 12:32:41 -0500
In-Reply-To: 
Cc: "Richard Backman, Annabelle" , oauth , Nat Sakimura 
To: Vladimir Dzhuvinov 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu> 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 13 Jan 2020 17:32:53 -0000

--Apple-Mail=_016A2591-A6B2-4CD0-A659-97B55AD466CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

To be clear, I=E2=80=99m not saying we suggest a particular form, and I =
agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a =
JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases.=20

In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D =
to be formatted as a JWT.=20

We had a case of similarly unintentional limiting in JAR previously, =
saying that you had to do an HTTP lookup on the request_uri, but I =
believe that=E2=80=99s been backed off now and made conditional.

 =E2=80=94 Justin

> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov =
 wrote:
>=20
> My suggestion is to abstain from specifying the concrete form of the =
resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
>=20
> In the Connect2id implementation of PAR the returned URI doesn't point =
to a request object and it doesn't point to a JWT either. It points to =
an internally stored "pre-processed" authZ request, which the authZ =
endpoint then picks up to complete the authZ.
>=20
> Even if we eventually end up in microservice world, or allow the PAR =
endpoint to be managed by some external entity, the PAR URI - its =
interpretation, validation and potentially resource retrieval (JWT or =
other blob), is an "internal contract" on the AS side. This doesn't =
concern the client, and in OAuth 2.0 the role of AS is indivisible.
>=20
>=20
>=20
> I see PAR request + authZ request as one logical OAuth 2.0 authZ =
request: the client submits an authZ request and gets an authZ response =
at the end. The URI is necessary for the client to proceed from the 1st =
to the 2nd step. If we manage to frame / word the PAR URI in this =
logical way, without getting stuck in the JAR definition / framing of =
what the request_uri / object is, it would be great.
>=20
>=20
>=20
> The normative language I think should focus on maintaining the OAuth =
2.0 contract for the entire logical authZ request, together with the =
basic contracts of 1) JAR and the 2) authZ endpoint.
>=20
>=20
>=20
> Vladimir
>=20
>=20
>=20
> On 10/01/2020 22:55, Justin Richer wrote:
>> So we could solve this by saying the resulting data object of a PAR =
is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing.
>>=20
>> Or PAR could at least say that if it=E2=80=99s dereferenced over a =
remote protocol then it MUST be a JWT, but otherwise it can be whatever =
you want. That=E2=80=99s where the real interop concerns come in.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
> wrote:
>>>=20
>>> Correct. The problem becomes pretty clear in the context of PAR, =
where the AS is generating and vending out the URI at the PAR endpoint, =
and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
>>> =E2=80=93=20
>>> Annabelle Richard Backman
>>> AWS Identity
>>> =20
>>> =20
>>> From: John Bradley >
>>> Date: Friday, January 10, 2020 at 12:29 PM
>>> To: Brian Campbell >
>>> Cc: Torsten Lodderstedt >, Nat Sakimura >, "Richard Backman, Annabelle" =
>, oauth =
>
>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests =
must become JWTs
>>> =20
>>> If we assume the client posts a JAR and gets back a reference.  Then =
the reference is to a JAR.=20
>>> =20
>>> I think I see the problem.  If the server providing the reference is =
associated with the AS then the server dosen't need to dereference the =
object via HTTP, so it could be a URN as an example.=20
>>> =20
>>> So yes it is not a interoperability issue for the client. =20
>>> =20
>>> I will think about how I can finesse that.=20
>>> =20
>>> I agree it is not a change in intent.=20
>>> =20
>>> I will see if I can get our AD to accept that.
>>> =20
>>> John B.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>>>> Sure but the text proposed (or something like it) qualifies it such =
that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>>>> =20
>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley > wrote:
>>>>> It may be a challenge to change text saying that the contents of =
the resource could be something other than a request object.=20
>>>>> =20
>>>>> If not a request object then what and how is that interoperable =
are likely AD questions.=20
>>>>> =20
>>>>> I could perhaps see changing it to must be a request object, or =
other format defined by a profile.
>>>>>=20
>>>>> John B. =20
>>>>> =20
>>>>> =20
>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>>>> Agree and agree. But given that the change suggested by Annabelle =
has no impact on the client or interoperability, perhaps Nat or John =
could work the change into the draft during the edits that happen during =
the final stages of things?
>>>>>> =20
>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>>>> I would assume given the status of JAR, we don=E2=80=99t want to =
change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>>>=20
>>>>>>>> It would be more appropriate to add the text to JAR rather than =
PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving the =
text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>>>> =20
>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>>>=20
>>>>>>>> Object.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>> To:=20
>>>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>>>=20
>>>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>>>=20
>>>>>>>> Server.
>>>>>>>>=20
>>>>>>>> =20
>>>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>>>> =20
>>>>>>>> =E2=80=93=20
>>>>>>>> Annabelle Richard Backman
>>>>>>>> AWS Identity
>>>>>>>> =20
>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>>>> =20
>>>>>>>>     Hi,=20
>>>>>>>>    =20
>>>>>>>>     you are right, PAR does not require the AS to represent the =
request as a JWT-based request object. The URI is used as internal =
reference only. That why the draft states
>>>>>>>>    =20
>>>>>>>>     "There is no need to make the
>>>>>>>>           authorization request data available to other parties =
via this
>>>>>>>>           URI.=E2=80=9D
>>>>>>>>    =20
>>>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>>>    =20
>>>>>>>>     We may add a statement to PAR saying that request_uris =
issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>    =20
>>>>>>>>     best regards,
>>>>>>>>     Torsten. =20
>>>>>>>>    =20
>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>>>     >=20
>>>>>>>>     > Hi all,
>>>>>>>>     > =20
>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require =
that the AS transform all pushed requests into JWTs. This requirement =
arises from the following:
>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>>>     >         =E2=80=A2 According to JAR, the resource =
referenced by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a JWT =
containing all the authorization request parameters. (Section 2.1)
>>>>>>>>     > =20
>>>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>>>     > =20
>>>>>>>>     > =E2=80=93=20
>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>     > AWS Identity
>>>>>>>>     > =20
>>>>>>>>     > _______________________________________________
>>>>>>>>     > OAuth mailing list
>>>>>>>>     > OAuth@ietf.org 
>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

> --=20
> Vladimir Dzhuvinov


--Apple-Mail=_016A2591-A6B2-4CD0-A659-97B55AD466CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

To =
be clear, I=E2=80=99m not saying we suggest a particular form, and I =
agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a =
JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases. 

In cases where you do a =
remote look up, we want =E2=80=9Cthing X=E2=80=9D to be formatted as a =
JWT. 

We =
had a case of similarly unintentional limiting in JAR previously, saying =
that you had to do an HTTP lookup on the request_uri, but I believe =
that=E2=80=99s been backed off now and made conditional.

 =E2=80=94 =
Justin

On Jan 11, 2020, at 5:28 AM, Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
My suggestion is to abstain from =
specifying the concrete form of
      the resource pointed to by the PAR URI. Regardless of URI type
      (URN, downloadable https URL or something else), and even if the
      PAR endpoint and the authZ endpoint are managed by two different
      entities (microservice or other scenario).
In the =
Connect2id implementation of PAR the returned URI doesn't
      point to a request object and it doesn't point to a JWT either. It
      points to an internally stored "pre-processed" authZ request,
      which the authZ endpoint then picks up to complete the =
authZ.
Even if we eventually end up in microservice =
world, or allow the
      PAR endpoint to be managed by some external entity, the PAR URI -
      its interpretation, validation and potentially resource retrieval
      (JWT or other blob), is an "internal contract" on the AS side.
      This doesn't concern the client, and in OAuth 2.0 the role of AS
      is indivisible.


    
I see PAR request + authZ request as one logical =
OAuth 2.0 authZ
      request: the client submits an authZ request and gets an authZ
      response at the end. The URI is necessary for the client to
      proceed from the 1st to the 2nd step. If we manage to frame / word
      the PAR URI in this logical way, without getting stuck in the JAR
      definition / framing of what the request_uri / object is, it would
      be great.


    
The normative language I think should focus on =
maintaining the
      OAuth 2.0 contract for the entire logical authZ request, together
      with the basic contracts of 1) JAR and the 2) authZ endpoint.

    


    
Vladimir

    


    

    
On 10/01/2020 22:55, Justin Richer
      wrote:

    

    

      
      So we could solve this by saying the resulting data object of a
      PAR is a request object. Which might also contain a request object
      internally as well. In that case JAR should back off from saying
      it=E2=80=99s a JWT and instead say it=E2=80=99s a request object. =
Or we define a
      new term for this authorization request blob thing.
      


      

      
Or PAR could at least say that if it=E2=80=99s =
dereferenced
        over a remote protocol then it MUST be a JWT, but otherwise it
        can be whatever you want. That=E2=80=99s where the real interop =
concerns
        come in.

      


      

      
 =E2=80=94 Justin

        


          

            
On Jan 10, 2020, at 3:41 PM, Richard =
Backman,
              Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>
              wrote:

            

            

              

                
Correct.
                  The problem becomes pretty clear in the context of
                  PAR, where the AS is generating and vending out the
                  URI at the PAR endpoint, and consuming it at the
                  authorization endpoint. =46rom an interoperability
                  standpoint, it=E2=80=99s analogous to the AS vending =
an
                  authorization code at the authorization endpoint and
                  consuming it at the token endpoint.

                

                

                  
=E2=80=93 

                  
Annabelle
                      Richard Backman

                  
AWS Identity

                

                
 

                
 

                

                  
From: John Bradley
                      <ve7jtb@ve7jtb.com>

                      Date: Friday,
                      January 10, 2020 at 12:29 PM

                      To: Brian
                      Campbell <bcampbell@pingidentity.com>
=

                      Cc: Torsten
                      Lodderstedt <torsten@lodderstedt.net>,
                      Nat Sakimura <nat@sakimura.org>,
                      "Richard Backman, Annabelle" <richanna@amazon.com>,
                      oauth <oauth@ietf.org>

                      Subject: [UNVERIFIED
                      SENDER] Re: [OAUTH-WG] PAR: pushed requests must
                      become JWTs

                

                

                  
 

                

                

                  

                    
If
                      we assume the client posts a JAR and gets back a
                      reference.  Then the reference is to a =
JAR. 

                  

                  

                    
 

                  

                  

                    
I
                      think I see the problem.  If the server =
providing
                      the reference is associated with the AS then the
                      server dosen't need to dereference the object via
                      HTTP, so it could be a URN as an =
example. 

                  

                  

                    
 

                  

                  

                    
So
                      yes it is not a interoperability issue for the
                      client.  

                  

                  

                    
 

                  

                  

                    
I
                      will think about how I can finesse that. 

                  

                  

                    
 

                  

                  

                    
I
                      agree it is not a change in intent. 

                  

                  

                    
 

                  

                  

                    
I
                      will see if I can get our AD to accept that.

                  

                  

                    
 

                  

                  

                    
John
                      B. 

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
 

                  

                

                
 

                

                  

                    
On
                      Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com>
                      wrote:

                  

                  

                    

                      
Sure but the text proposed (or
                        something like it) qualifies it such that there
                        aren't interoperability questions because it's
                        only an implementation detail to the AS who both
                        produces the URI and consumes its content.

                    

                    
 

                    

                      

                        
On Fri, Jan 10, 2020 at 12:48 PM John
                          Bradley <ve7jtb@ve7jtb.com>
                          wrote:

                      

                      

                        

                          

                            
It may be a
                              challenge to change text saying that the
                              contents of the resource could be
                              something other than a request =
object. 

                          

                          

                            
 

                          

                          

                            
If not a request
                              object then what and how is that
                              interoperable are likely AD =
questions. 

                          

                          

                            
 

                          

                          

                            
I could perhaps =
see
                              changing it to must be a request object,
                              or other format defined by a profile.

                              

                              John B.  

                          

                          

                            
 

                          

                          

                            
 

                            

                              

                                
On Fri, Jan =
10,
                                  2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com>
                                  wrote:

                              

                              

                                

                                  

                                    
Agree and agree. But
                                      given that the change suggested by
                                      Annabelle has no impact on the
                                      client or interoperability,
                                      perhaps Nat or John could work the
                                      change into the draft during the
                                      edits that happen during the final
                                      stages of things?

                                  

                                  
 

                                  

                                    

                                      
On Thu,
                                        Jan 9, 2020 at 1:56 AM Torsten
                                        Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>
                                        wrote:
=

                                    

                                    

                                      

                                        

                                          
I
                                            would assume given the
                                            status of JAR, we don=E2=80=99=
t want
                                            to change it. And as I said,
                                            this difference does not
                                            impact interoperability from
                                            client perspective.

                                        

                                        

                                          


                                            

                                            

                                          
Am 09.01.2020
                                              um 00:58 schrieb Richard
                                              Backman, Annabelle
                                              <richanna=3D40amazon.com@dmarc.ietf.org>:

                                          

                                        

                                        

                                          

                                            

                                              
It would =
be
                                                more appropriate to add
                                                the text to JAR rather
                                                than PAR. It doesn't
                                                seem right for PAR to
                                                retcon rules in JAR.
                                                Moving the text to JAR
                                                also highlights the
                                                weirdness of giving PAR
                                                special treatment.

                                              
 

                                              
What if we
                                                changed this sentence in
                                                Section 5.2 of JAR:
The
                                                  contents of the
                                                  resource referenced by
                                                  the URI MUST be a
                                                  Request
Object.

                                              
 

                                              
To: 
The
                                                  contents of the
                                                  resource referenced by
                                                  the URI MUST be a
                                                  Request
Object,
                                                  unless the URI was
                                                  provided to the client
                                                  by the =
Authorization
Server.

                                              
 

                                              
This would
                                                allow for use cases such
                                                as an AS that provides
                                                pre-defined request
                                                URIs, or vends request
                                                URIs via a client
                                                management console, or
                                                bakes them into their
                                                client apps.

                                              
 

                                              
=E2=80=93 

                                              
Annabelle
                                                Richard Backman

                                              
AWS =
Identity

                                              
 

                                              
On 1/8/20,
                                                2:50 PM, "Torsten
                                                Lodderstedt"
                                                <torsten=3D40lodderstedt.net@dmarc.ietf.org>
                                                wrote:

                                              
 

                                              
    Hi, 

                                              
    

                                              
    you are
                                                right, PAR does not
                                                require the AS to
                                                represent the request as
                                                a JWT-based request
                                                object. The URI is used
                                                as internal reference
                                                only. That why the draft
                                                states

                                              
    

                                              
    "There
                                                is no need to make =
the

                                              
         
                                                authorization request
                                                data available to other
                                                parties via this

                                              
         
                                                URI.=E2=80=9D

                                              
    

                                              
    This
                                                difference matters from
                                                an AS implementation
                                                perspective, it doesn't
                                                matter from a client's
                                                (interop) =
perspective.

                                              
    

                                              
    We may
                                                add a statement to PAR
                                                saying that request_uris
                                                issued by the PAR
                                                mechanism (MAY) deviate
                                                from the JAR =
definition.

                                              
    

                                              
    best
                                                regards,

                                              
   
                                                Torsten.  

                                              
    

                                              
    > On
                                                8. Jan 2020, at 23:42,
                                                Richard Backman,
                                                Annabelle =
<richanna=3D40amazon.com@dmarc.ietf.org>
                                                wrote:

                                              
    > 

                                              
    > Hi
                                                all,

                                              
    >  

                                              
    > The
                                                current drafts of PAR
                                                (-00) and JAR (-20)
                                                require that the AS
                                                transform all pushed
                                                requests into JWTs. This
                                                requirement arises from
                                                the following:

                                              
    >
                                                =
        =E2=80=A2 PAR uses the
                                                request_uri parameter
                                                defined in JAR to
                                                communicate the pushed
                                                request to the
                                                authorization =
endpoint.

                                              
    >
                                                =
        =E2=80=A2 According to
                                                JAR, the resource
                                                referenced by
                                                request_uri MUST be a
                                                Request Object. (Section
                                                5.2)

                                              
    >
                                                =
        =E2=80=A2 Request Object
                                                is defined to be a JWT
                                                containing all the
                                                authorization request
                                                parameters. (Section
                                                2.1)

                                              
    >  

                                              
    >
                                                There is no need for
                                                this requirement to
                                                support
                                                interoperability, as
                                                this is internal to the
                                                AS. It is also
                                                inconsistent with the
                                                rest of JAR, which
                                                avoids attempting to
                                                define the internal
                                                communications between
                                                the two AS endpoints.
                                                Worse, this restriction
                                                makes it harder for the
                                                authorization endpoint
                                                to leverage validation
                                                and other work performed
                                                at the PAR endpoint, as
                                                the state or outcome of
                                                that work must be forced
                                                into the JWT format (or
                                                retrieved via a
                                                subsequent service call
                                                or database lookup).

                                              
    >  

                                              
    > =E2=80=93 

                                              
    >
                                                Annabelle Richard
                                                Backman

                                              
    > AWS
                                                Identity

                                              
    >  

                                              
    >
                                                =
_______________________________________________

                                              
    >
                                                OAuth mailing list

                                              
    > OAuth@ietf.org

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

                                              
    

                                              
    

                                            

                                          

                                        

                                      

                                      
_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

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

                                    

                                  

                                

                                


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

                              

                            

                          

                        

                      

                    

                    


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

                  

                

              

              _______________________________________________

              OAuth mailing list

              OAuth@ietf.org

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

          

        

        

      

      

      

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


    

    
--=20
Vladimir Dzhuvinov

  




=

--Apple-Mail=_016A2591-A6B2-4CD0-A659-97B55AD466CF--


From nobody Mon Jan 13 15:14: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 C15DC1200E3 for ; Mon, 13 Jan 2020 15:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.8
X-Spam-Level: 
X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIGPQ21r6TcK for ; Mon, 13 Jan 2020 15:14:44 -0800 (PST)
Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63DA120041 for ; Mon, 13 Jan 2020 15:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578957284; x=1610493284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8IhT35GHnur1QNnhl/3EqgxnoX/GxurUi4872JQaZew=; b=czDoQgazt3xGmNYlSOQc9xoiLP7UtHjHpZOE2zNRN1Lf2Uv1YBOfksnw 0fWKKI2wlo/moextx+PzdiuWpU8kSRZh2YzCfmdeIG+2bCUwqnz97yteU M8Cq6ZT0BwKxvrnbdFevXs+wc+Chlu/5wOJOBUaRGIzxnm5HHSAWxm+aO Y=;
IronPort-SDR: 1rGc/8p0IgC1Y49ljgOdFLsz02/6TTNVrVrUIJwpI3KuYDuX4L+5G6SUaUL6Jtlx1cbfPTuu8C Y0UQsTRGlyqA==
X-IronPort-AV: E=Sophos; i="5.69,430,1571702400"; d="scan'208,217"; a="11369583"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-e7be2041.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 13 Jan 2020 23:14:41 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-e7be2041.us-west-2.amazon.com (Postfix) with ESMTPS id 08EE6A2613; Mon, 13 Jan 2020 23:14:40 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 13 Jan 2020 23:14:40 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 13 Jan 2020 23:14:40 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 13 Jan 2020 23:14:40 +0000
From: "Richard Backman, Annabelle" 
To: Justin Richer , Vladimir Dzhuvinov 
CC: oauth , Nat Sakimura , "Richard Backman,  Annabelle" 
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
Thread-Index: AQHVyGnmuDzxiSgL6kO/nJ8pkgSMsqfo3hWA///ZcIA=
Date: Mon, 13 Jan 2020 23:14:40 +0000
Message-ID: 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.115]
Content-Type: multipart/alternative; boundary="_000_C0644BEE97F14C189E22F517F8991AA1amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 13 Jan 2020 23:14:49 -0000

--_000_C0644BEE97F14C189E22F517F8991AA1amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TXkgb3JpZ2luYWwgc3VnZ2VzdGlvbiB3YXMgdG8gcmVtb3ZlIHRoaXMgcmVxdWlyZW1lbnQgZnJv
bSBjYXNlcyB3aGVyZSB0aGUgQVMgb3JpZ2luYWxseSBwcm92aWRlZCB0aGUgcmVxdWVzdF91cmks
IGJlY2F1c2UgaW4gdGhlc2UgY2FzZXMsIHRoZSByZXF1ZXN0X3VyaSByZXNvbHV0aW9uIGJlY29t
ZXMgYW4gaW50ZXJuYWwgaW1wbGVtZW50YXRpb24gZGV0YWlsIG9mIHRoZSBBUy4gSSBzdGlsbCB0
aGluayB0aGF04oCZcyB0aGUgYmVzdCBjcml0ZXJpb24gdG8gdXNlIGZvciB3aGVuIHRoaXMgcmVx
dWlyZW1lbnQgc2hvdWxkIGFwcGx5LiBUaGlzIGNyaXRlcmlvbiBjb3ZlcnMgYWxsIEpBUiBpbXBs
ZW1lbnRhdGlvbnMsIGFzIHRoZSBKQVIgZW5kcG9pbnQgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFz
IGJlaW5nIHBhcnQgb2YgdGhlIEFTLg0KDQpOb3RlIHRoYXQg4oCcQVPigJ0gcmVmZXJzIHRvIGEg
cm9sZSB3aXRoaW4gT0F1dGgsIGFuZCB0aGF0IHJvbGUgbWF5IGJlIGltcGxlbWVudGVkIGJ5IGEg
Y29sbGVjdGlvbiBvZiBtaWNybyBzZXJ2aWNlcyBhbmQvb3IgdGhpcmQgcGFydHkgc2VydmljZXMu
IEZyb20gYW4gaW50ZXJvcCBzdGFuZHBvaW50LCBpdCBkb2VzbuKAmXQgbWF0dGVyIHRoYXQgdGhl
IFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgaG9zdGVkIG9uIHNl
cGFyYXRlIG1pY3JvIHNlcnZpY2VzOyBpdOKAmXMgc3RpbGwgdGhlIEFTIHZlbmRpbmcgb3V0IGEg
cmVxdWVzdF91cmkgZm9yIGl0cyBvd24gY29uc3VtcHRpb24gbGF0ZXIuIFdoZXRoZXIgdGhhdCBy
ZXF1ZXN0X3VyaSBpcyByZXNvbHZlZCB2aWEgYSBsb2NhbCBEQiBsb29rdXAsIGludGVybmFsIHdl
YiBzZXJ2aWNlIGNhbGwsIG9yIEhUVFAgcmVxdWVzdCB0byBhbiBTMyBidWNrZXQgaXMgaXJyZWxl
dmFudC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0K
DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEp1c3Rp
biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAxMywgMjAy
MCBhdCA5OjMzIEFNDQpUbzogVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0Mmlk
LmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+LCBOYXQgU2FraW11cmEgPG5hdEBzYWtp
bXVyYS5vcmc+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYT00MGFtYXpv
bi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklF
RCBTRU5ERVJdIFJlOiBQQVI6IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzDQoNClRv
IGJlIGNsZWFyLCBJ4oCZbSBub3Qgc2F5aW5nIHdlIHN1Z2dlc3QgYSBwYXJ0aWN1bGFyIGZvcm0s
IGFuZCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkbuKAmXQgc3BlY2lmeSB0aGF0IOKAnGl04oCZcyBh
IEpXVOKAnSBvciBzb21ldGhpbmcgb2YgdGhhdCBuYXR1cmUuIEJ1dCBpZiB3ZSBjYWxsIHRoZSBy
ZXN1bHQgb2YgUEFSIOKAnHRoaW5nIFjigJ0gYW5kIHRoZSB0YXJnZXQgb2YgcmVxdWVzdF91cmkg
4oCcdGhpbmcgWOKAnSBpbiBKQVIsIHRoZW4gd2XigJlyZSBjb21wYXRpYmxlIHdpdGhvdXQgc2F5
aW5nIHdoYXQg4oCcdGhpbmcgWOKAnSBuZWVkcyB0byBiZSBpbiBhbGwgY2FzZXMuDQoNCkluIGNh
c2VzIHdoZXJlIHlvdSBkbyBhIHJlbW90ZSBsb29rIHVwLCB3ZSB3YW50IOKAnHRoaW5nIFjigJ0g
dG8gYmUgZm9ybWF0dGVkIGFzIGEgSldULg0KDQpXZSBoYWQgYSBjYXNlIG9mIHNpbWlsYXJseSB1
bmludGVudGlvbmFsIGxpbWl0aW5nIGluIEpBUiBwcmV2aW91c2x5LCBzYXlpbmcgdGhhdCB5b3Ug
aGFkIHRvIGRvIGFuIEhUVFAgbG9va3VwIG9uIHRoZSByZXF1ZXN0X3VyaSwgYnV0IEkgYmVsaWV2
ZSB0aGF04oCZcyBiZWVuIGJhY2tlZCBvZmYgbm93IGFuZCBtYWRlIGNvbmRpdGlvbmFsLg0KDQog
4oCUIEp1c3Rpbg0KDQoNCk9uIEphbiAxMSwgMjAyMCwgYXQgNToyOCBBTSwgVmxhZGltaXIgRHpo
dXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp
ZC5jb20+PiB3cm90ZToNCg0KTXkgc3VnZ2VzdGlvbiBpcyB0byBhYnN0YWluIGZyb20gc3BlY2lm
eWluZyB0aGUgY29uY3JldGUgZm9ybSBvZiB0aGUgcmVzb3VyY2UgcG9pbnRlZCB0byBieSB0aGUg
UEFSIFVSSS4gUmVnYXJkbGVzcyBvZiBVUkkgdHlwZSAoVVJOLCBkb3dubG9hZGFibGUgaHR0cHMg
VVJMIG9yIHNvbWV0aGluZyBlbHNlKSwgYW5kIGV2ZW4gaWYgdGhlIFBBUiBlbmRwb2ludCBhbmQg
dGhlIGF1dGhaIGVuZHBvaW50IGFyZSBtYW5hZ2VkIGJ5IHR3byBkaWZmZXJlbnQgZW50aXRpZXMg
KG1pY3Jvc2VydmljZSBvciBvdGhlciBzY2VuYXJpbykuDQpJbiB0aGUgQ29ubmVjdDJpZCBpbXBs
ZW1lbnRhdGlvbiBvZiBQQVIgdGhlIHJldHVybmVkIFVSSSBkb2Vzbid0IHBvaW50IHRvIGEgcmVx
dWVzdCBvYmplY3QgYW5kIGl0IGRvZXNuJ3QgcG9pbnQgdG8gYSBKV1QgZWl0aGVyLiBJdCBwb2lu
dHMgdG8gYW4gaW50ZXJuYWxseSBzdG9yZWQgInByZS1wcm9jZXNzZWQiIGF1dGhaIHJlcXVlc3Qs
IHdoaWNoIHRoZSBhdXRoWiBlbmRwb2ludCB0aGVuIHBpY2tzIHVwIHRvIGNvbXBsZXRlIHRoZSBh
dXRoWi4NCkV2ZW4gaWYgd2UgZXZlbnR1YWxseSBlbmQgdXAgaW4gbWljcm9zZXJ2aWNlIHdvcmxk
LCBvciBhbGxvdyB0aGUgUEFSIGVuZHBvaW50IHRvIGJlIG1hbmFnZWQgYnkgc29tZSBleHRlcm5h
bCBlbnRpdHksIHRoZSBQQVIgVVJJIC0gaXRzIGludGVycHJldGF0aW9uLCB2YWxpZGF0aW9uIGFu
ZCBwb3RlbnRpYWxseSByZXNvdXJjZSByZXRyaWV2YWwgKEpXVCBvciBvdGhlciBibG9iKSwgaXMg
YW4gImludGVybmFsIGNvbnRyYWN0IiBvbiB0aGUgQVMgc2lkZS4gVGhpcyBkb2Vzbid0IGNvbmNl
cm4gdGhlIGNsaWVudCwgYW5kIGluIE9BdXRoIDIuMCB0aGUgcm9sZSBvZiBBUyBpcyBpbmRpdmlz
aWJsZS4NCg0KSSBzZWUgUEFSIHJlcXVlc3QgKyBhdXRoWiByZXF1ZXN0IGFzIG9uZSBsb2dpY2Fs
IE9BdXRoIDIuMCBhdXRoWiByZXF1ZXN0OiB0aGUgY2xpZW50IHN1Ym1pdHMgYW4gYXV0aFogcmVx
dWVzdCBhbmQgZ2V0cyBhbiBhdXRoWiByZXNwb25zZSBhdCB0aGUgZW5kLiBUaGUgVVJJIGlzIG5l
Y2Vzc2FyeSBmb3IgdGhlIGNsaWVudCB0byBwcm9jZWVkIGZyb20gdGhlIDFzdCB0byB0aGUgMm5k
IHN0ZXAuIElmIHdlIG1hbmFnZSB0byBmcmFtZSAvIHdvcmQgdGhlIFBBUiBVUkkgaW4gdGhpcyBs
b2dpY2FsIHdheSwgd2l0aG91dCBnZXR0aW5nIHN0dWNrIGluIHRoZSBKQVIgZGVmaW5pdGlvbiAv
IGZyYW1pbmcgb2Ygd2hhdCB0aGUgcmVxdWVzdF91cmkgLyBvYmplY3QgaXMsIGl0IHdvdWxkIGJl
IGdyZWF0Lg0KDQpUaGUgbm9ybWF0aXZlIGxhbmd1YWdlIEkgdGhpbmsgc2hvdWxkIGZvY3VzIG9u
IG1haW50YWluaW5nIHRoZSBPQXV0aCAyLjAgY29udHJhY3QgZm9yIHRoZSBlbnRpcmUgbG9naWNh
bCBhdXRoWiByZXF1ZXN0LCB0b2dldGhlciB3aXRoIHRoZSBiYXNpYyBjb250cmFjdHMgb2YgMSkg
SkFSIGFuZCB0aGUgMikgYXV0aFogZW5kcG9pbnQuDQoNClZsYWRpbWlyDQoNCk9uIDEwLzAxLzIw
MjAgMjI6NTUsIEp1c3RpbiBSaWNoZXIgd3JvdGU6DQpTbyB3ZSBjb3VsZCBzb2x2ZSB0aGlzIGJ5
IHNheWluZyB0aGUgcmVzdWx0aW5nIGRhdGEgb2JqZWN0IG9mIGEgUEFSIGlzIGEgcmVxdWVzdCBv
YmplY3QuIFdoaWNoIG1pZ2h0IGFsc28gY29udGFpbiBhIHJlcXVlc3Qgb2JqZWN0IGludGVybmFs
bHkgYXMgd2VsbC4gSW4gdGhhdCBjYXNlIEpBUiBzaG91bGQgYmFjayBvZmYgZnJvbSBzYXlpbmcg
aXTigJlzIGEgSldUIGFuZCBpbnN0ZWFkIHNheSBpdOKAmXMgYSByZXF1ZXN0IG9iamVjdC4gT3Ig
d2UgZGVmaW5lIGEgbmV3IHRlcm0gZm9yIHRoaXMgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGJsb2Ig
dGhpbmcuDQoNCk9yIFBBUiBjb3VsZCBhdCBsZWFzdCBzYXkgdGhhdCBpZiBpdOKAmXMgZGVyZWZl
cmVuY2VkIG92ZXIgYSByZW1vdGUgcHJvdG9jb2wgdGhlbiBpdCBNVVNUIGJlIGEgSldULCBidXQg
b3RoZXJ3aXNlIGl0IGNhbiBiZSB3aGF0ZXZlciB5b3Ugd2FudC4gVGhhdOKAmXMgd2hlcmUgdGhl
IHJlYWwgaW50ZXJvcCBjb25jZXJucyBjb21lIGluLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEph
biAxMCwgMjAyMCwgYXQgMzo0MSBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hh
bm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBhbWF6b24u
Y29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkNvcnJlY3QuIFRoZSBwcm9ibGVtIGJlY29t
ZXMgcHJldHR5IGNsZWFyIGluIHRoZSBjb250ZXh0IG9mIFBBUiwgd2hlcmUgdGhlIEFTIGlzIGdl
bmVyYXRpbmcgYW5kIHZlbmRpbmcgb3V0IHRoZSBVUkkgYXQgdGhlIFBBUiBlbmRwb2ludCwgYW5k
IGNvbnN1bWluZyBpdCBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gRnJvbSBhbiBpbnRl
cm9wZXJhYmlsaXR5IHN0YW5kcG9pbnQsIGl04oCZcyBhbmFsb2dvdXMgdG8gdGhlIEFTIHZlbmRp
bmcgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFu
ZCBjb25zdW1pbmcgaXQgYXQgdGhlIHRva2VuIGVuZHBvaW50Lg0K4oCTDQpBbm5hYmVsbGUgUmlj
aGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0
YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRlOiBGcmlkYXksIEph
bnVhcnkgMTAsIDIwMjAgYXQgMTI6MjkgUE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCkNj
OiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9y
c3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiwgTmF0IFNha2ltdXJhIDxuYXRAc2FraW11cmEub3JnPG1h
aWx0bzpuYXRAc2FraW11cmEub3JnPj4sICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJp
Y2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Piwgb2F1dGggPG9h
dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbVU5WRVJJRklF
RCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIFBBUjogcHVzaGVkIHJlcXVlc3RzIG11c3QgYmVjb21l
IEpXVHMNCg0KSWYgd2UgYXNzdW1lIHRoZSBjbGllbnQgcG9zdHMgYSBKQVIgYW5kIGdldHMgYmFj
ayBhIHJlZmVyZW5jZS4gIFRoZW4gdGhlIHJlZmVyZW5jZSBpcyB0byBhIEpBUi4NCg0KSSB0aGlu
ayBJIHNlZSB0aGUgcHJvYmxlbS4gIElmIHRoZSBzZXJ2ZXIgcHJvdmlkaW5nIHRoZSByZWZlcmVu
Y2UgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBBUyB0aGVuIHRoZSBzZXJ2ZXIgZG9zZW4ndCBuZWVk
IHRvIGRlcmVmZXJlbmNlIHRoZSBvYmplY3QgdmlhIEhUVFAsIHNvIGl0IGNvdWxkIGJlIGEgVVJO
IGFzIGFuIGV4YW1wbGUuDQoNClNvIHllcyBpdCBpcyBub3QgYSBpbnRlcm9wZXJhYmlsaXR5IGlz
c3VlIGZvciB0aGUgY2xpZW50Lg0KDQpJIHdpbGwgdGhpbmsgYWJvdXQgaG93IEkgY2FuIGZpbmVz
c2UgdGhhdC4NCg0KSSBhZ3JlZSBpdCBpcyBub3QgYSBjaGFuZ2UgaW4gaW50ZW50Lg0KDQpJIHdp
bGwgc2VlIGlmIEkgY2FuIGdldCBvdXIgQUQgdG8gYWNjZXB0IHRoYXQuDQoNCkpvaG4gQi4NCg0K
DQoNCg0KT24gRnJpLCBKYW4gMTAsIDIwMjAsIDQ6NTcgUE0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1w
YmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+
IHdyb3RlOg0KU3VyZSBidXQgdGhlIHRleHQgcHJvcG9zZWQgKG9yIHNvbWV0aGluZyBsaWtlIGl0
KSBxdWFsaWZpZXMgaXQgc3VjaCB0aGF0IHRoZXJlIGFyZW4ndCBpbnRlcm9wZXJhYmlsaXR5IHF1
ZXN0aW9ucyBiZWNhdXNlIGl0J3Mgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgdG8gdGhl
IEFTIHdobyBib3RoIHByb2R1Y2VzIHRoZSBVUkkgYW5kIGNvbnN1bWVzIGl0cyBjb250ZW50Lg0K
DQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMjo0OCBQTSBKb2huIEJyYWRsZXkgPHZlN2p0YkB2
ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSXQgbWF5IGJlIGEg
Y2hhbGxlbmdlIHRvIGNoYW5nZSB0ZXh0IHNheWluZyB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUg
cmVzb3VyY2UgY291bGQgYmUgc29tZXRoaW5nIG90aGVyIHRoYW4gYSByZXF1ZXN0IG9iamVjdC4N
Cg0KSWYgbm90IGEgcmVxdWVzdCBvYmplY3QgdGhlbiB3aGF0IGFuZCBob3cgaXMgdGhhdCBpbnRl
cm9wZXJhYmxlIGFyZSBsaWtlbHkgQUQgcXVlc3Rpb25zLg0KDQpJIGNvdWxkIHBlcmhhcHMgc2Vl
IGNoYW5naW5nIGl0IHRvIG11c3QgYmUgYSByZXF1ZXN0IG9iamVjdCwgb3Igb3RoZXIgZm9ybWF0
IGRlZmluZWQgYnkgYSBwcm9maWxlLg0KDQpKb2huIEIuDQoNCg0KT24gRnJpLCBKYW4gMTAsIDIw
MjAsIDM6NDUgUE0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1h
aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KQWdyZWUgYW5kIGFncmVl
LiBCdXQgZ2l2ZW4gdGhhdCB0aGUgY2hhbmdlIHN1Z2dlc3RlZCBieSBBbm5hYmVsbGUgaGFzIG5v
IGltcGFjdCBvbiB0aGUgY2xpZW50IG9yIGludGVyb3BlcmFiaWxpdHksIHBlcmhhcHMgTmF0IG9y
IEpvaG4gY291bGQgd29yayB0aGUgY2hhbmdlIGludG8gdGhlIGRyYWZ0IGR1cmluZyB0aGUgZWRp
dHMgdGhhdCBoYXBwZW4gZHVyaW5nIHRoZSBmaW5hbCBzdGFnZXMgb2YgdGhpbmdzPw0KDQpPbiBU
aHUsIEphbiA5LCAyMDIwIGF0IDE6NTYgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00
MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRA
ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgd291bGQgYXNzdW1lIGdpdmVuIHRoZSBzdGF0dXMg
b2YgSkFSLCB3ZSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGl0LiBBbmQgYXMgSSBzYWlkLCB0aGlz
IGRpZmZlcmVuY2UgZG9lcyBub3QgaW1wYWN0IGludGVyb3BlcmFiaWxpdHkgZnJvbSBjbGllbnQg
cGVyc3BlY3RpdmUuDQoNCg0KDQpBbSAwOS4wMS4yMDIwIHVtIDAwOjU4IHNjaHJpZWIgUmljaGFy
ZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9y
ZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj46DQpJdCB3b3VsZCBiZSBtb3Jl
IGFwcHJvcHJpYXRlIHRvIGFkZCB0aGUgdGV4dCB0byBKQVIgcmF0aGVyIHRoYW4gUEFSLiBJdCBk
b2Vzbid0IHNlZW0gcmlnaHQgZm9yIFBBUiB0byByZXRjb24gcnVsZXMgaW4gSkFSLiBNb3Zpbmcg
dGhlIHRleHQgdG8gSkFSIGFsc28gaGlnaGxpZ2h0cyB0aGUgd2VpcmRuZXNzIG9mIGdpdmluZyBQ
QVIgc3BlY2lhbCB0cmVhdG1lbnQuDQoNCldoYXQgaWYgd2UgY2hhbmdlZCB0aGlzIHNlbnRlbmNl
IGluIFNlY3Rpb24gNS4yIG9mIEpBUjoNClRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgcmVm
ZXJlbmNlZCBieSB0aGUgVVJJIE1VU1QgYmUgYSBSZXF1ZXN0DQpPYmplY3QuDQoNClRvOg0KVGhl
IGNvbnRlbnRzIG9mIHRoZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBh
IFJlcXVlc3QNCk9iamVjdCwgdW5sZXNzIHRoZSBVUkkgd2FzIHByb3ZpZGVkIHRvIHRoZSBjbGll
bnQgYnkgdGhlIEF1dGhvcml6YXRpb24NClNlcnZlci4NCg0KVGhpcyB3b3VsZCBhbGxvdyBmb3Ig
dXNlIGNhc2VzIHN1Y2ggYXMgYW4gQVMgdGhhdCBwcm92aWRlcyBwcmUtZGVmaW5lZCByZXF1ZXN0
IFVSSXMsIG9yIHZlbmRzIHJlcXVlc3QgVVJJcyB2aWEgYSBjbGllbnQgbWFuYWdlbWVudCBjb25z
b2xlLCBvciBiYWtlcyB0aGVtIGludG8gdGhlaXIgY2xpZW50IGFwcHMuDQoNCuKAkw0KQW5uYWJl
bGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCk9uIDEvOC8yMCwgMjo1MCBQTSwg
IlRvcnN0ZW4gTG9kZGVyc3RlZHQiIDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmll
dGYub3JnPG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K
DQogICAgSGksDQoNCiAgICB5b3UgYXJlIHJpZ2h0LCBQQVIgZG9lcyBub3QgcmVxdWlyZSB0aGUg
QVMgdG8gcmVwcmVzZW50IHRoZSByZXF1ZXN0IGFzIGEgSldULWJhc2VkIHJlcXVlc3Qgb2JqZWN0
LiBUaGUgVVJJIGlzIHVzZWQgYXMgaW50ZXJuYWwgcmVmZXJlbmNlIG9ubHkuIFRoYXQgd2h5IHRo
ZSBkcmFmdCBzdGF0ZXMNCg0KICAgICJUaGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgdGhlDQogICAg
ICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGRhdGEgYXZhaWxhYmxlIHRvIG90aGVyIHBhcnRp
ZXMgdmlhIHRoaXMNCiAgICAgICAgICBVUkku4oCdDQoNCiAgICBUaGlzIGRpZmZlcmVuY2UgbWF0
dGVycyBmcm9tIGFuIEFTIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLCBpdCBkb2Vzbid0IG1h
dHRlciBmcm9tIGEgY2xpZW50J3MgKGludGVyb3ApIHBlcnNwZWN0aXZlLg0KDQogICAgV2UgbWF5
IGFkZCBhIHN0YXRlbWVudCB0byBQQVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBi
eSB0aGUgUEFSIG1lY2hhbmlzbSAoTUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9u
Lg0KDQogICAgYmVzdCByZWdhcmRzLA0KICAgIFRvcnN0ZW4uDQoNCiAgICA+IE9uIDguIEphbiAy
MDIwLCBhdCAyMzo0MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1h
em9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn
Pj4gd3JvdGU6DQogICAgPg0KICAgID4gSGkgYWxsLA0KICAgID4NCiAgICA+IFRoZSBjdXJyZW50
IGRyYWZ0cyBvZiBQQVIgKC0wMCkgYW5kIEpBUiAoLTIwKSByZXF1aXJlIHRoYXQgdGhlIEFTIHRy
YW5zZm9ybSBhbGwgcHVzaGVkIHJlcXVlc3RzIGludG8gSldUcy4gVGhpcyByZXF1aXJlbWVudCBh
cmlzZXMgZnJvbSB0aGUgZm9sbG93aW5nOg0KICAgID4gICAgICAgICDigKIgUEFSIHVzZXMgdGhl
IHJlcXVlc3RfdXJpIHBhcmFtZXRlciBkZWZpbmVkIGluIEpBUiB0byBjb21tdW5pY2F0ZSB0aGUg
cHVzaGVkIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuDQogICAgPiAgICAg
ICAgIOKAoiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVmZXJlbmNlZCBieSByZXF1
ZXN0X3VyaSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9uIDUuMikNCiAgICA+ICAg
ICAgICAg4oCiIFJlcXVlc3QgT2JqZWN0IGlzIGRlZmluZWQgdG8gYmUgYSBKV1QgY29udGFpbmlu
ZyBhbGwgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBwYXJhbWV0ZXJzLiAoU2VjdGlvbiAyLjEp
DQogICAgPg0KICAgID4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudCB0byBz
dXBwb3J0IGludGVyb3BlcmFiaWxpdHksIGFzIHRoaXMgaXMgaW50ZXJuYWwgdG8gdGhlIEFTLiBJ
dCBpcyBhbHNvIGluY29uc2lzdGVudCB3aXRoIHRoZSByZXN0IG9mIEpBUiwgd2hpY2ggYXZvaWRz
IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBpbnRlcm5hbCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVu
IHRoZSB0d28gQVMgZW5kcG9pbnRzLiBXb3JzZSwgdGhpcyByZXN0cmljdGlvbiBtYWtlcyBpdCBo
YXJkZXIgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGxldmVyYWdlIHZhbGlkYXRp
b24gYW5kIG90aGVyIHdvcmsgcGVyZm9ybWVkIGF0IHRoZSBQQVIgZW5kcG9pbnQsIGFzIHRoZSBz
dGF0ZSBvciBvdXRjb21lIG9mIHRoYXQgd29yayBtdXN0IGJlIGZvcmNlZCBpbnRvIHRoZSBKV1Qg
Zm9ybWF0IChvciByZXRyaWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNhbGwgb3IgZGF0
YWJhc2UgbG9va3VwKS4NCiAgICA+DQogICAgPiDigJMNCiAgICA+IEFubmFiZWxsZSBSaWNoYXJk
IEJhY2ttYW4NCiAgICA+IEFXUyBJZGVudGl0eQ0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBPQXV0aCBtYWlsaW5nIGxp
c3QNCiAgICA+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCiAgICA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0
DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo
aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs
IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll
dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl
cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg
ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t
cHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt
YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz
b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp
c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk
Li4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo
ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo
YW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGgg
bWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQotLQ0KDQpWbGFk
aW1pciBEemh1dmlub3YNCg0K

--_000_C0644BEE97F14C189E22F517F8991AA1amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg
MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN
YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3IFw7IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6
YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv
LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5
OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu
NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG9yaWdpbmFsIHN1Z2dlc3Rp
b24gd2FzIHRvIHJlbW92ZSB0aGlzIHJlcXVpcmVtZW50IGZyb20gY2FzZXMgd2hlcmUgdGhlIEFT
IG9yaWdpbmFsbHkgcHJvdmlkZWQgdGhlIHJlcXVlc3RfdXJpLCBiZWNhdXNlIGluIHRoZXNlIGNh
c2VzLCB0aGUgcmVxdWVzdF91cmkgcmVzb2x1dGlvbiBiZWNvbWVzIGFuIGludGVybmFsIGltcGxl
bWVudGF0aW9uIGRldGFpbCBvZiB0aGUgQVMuIEkgc3RpbGwgdGhpbmsgdGhhdOKAmXMNCiB0aGUg
YmVzdCBjcml0ZXJpb24gdG8gdXNlIGZvciB3aGVuIHRoaXMgcmVxdWlyZW1lbnQgc2hvdWxkIGFw
cGx5LiBUaGlzIGNyaXRlcmlvbiBjb3ZlcnMgYWxsIEpBUiBpbXBsZW1lbnRhdGlvbnMsIGFzIHRo
ZSBKQVIgZW5kcG9pbnQgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFzIGJlaW5nIHBhcnQgb2YgdGhl
IEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQg4oCcQVPigJ0gcmVmZXJzIHRv
IGEgcm9sZSB3aXRoaW4gT0F1dGgsIGFuZCB0aGF0IHJvbGUgbWF5IGJlIGltcGxlbWVudGVkIGJ5
IGEgY29sbGVjdGlvbiBvZiBtaWNybyBzZXJ2aWNlcyBhbmQvb3IgdGhpcmQgcGFydHkgc2Vydmlj
ZXMuIEZyb20gYW4gaW50ZXJvcCBzdGFuZHBvaW50LCBpdCBkb2VzbuKAmXQgbWF0dGVyIHRoYXQg
dGhlIFBBUiBlbmRwb2ludCBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludA0KIGFyZSBob3N0ZWQg
b24gc2VwYXJhdGUgbWljcm8gc2VydmljZXM7IGl04oCZcyBzdGlsbCB0aGUgQVMgdmVuZGluZyBv
dXQgYSByZXF1ZXN0X3VyaSBmb3IgaXRzIG93biBjb25zdW1wdGlvbiBsYXRlci4gV2hldGhlciB0
aGF0IHJlcXVlc3RfdXJpIGlzIHJlc29sdmVkIHZpYSBhIGxvY2FsIERCIGxvb2t1cCwgaW50ZXJu
YWwgd2ViIHNlcnZpY2UgY2FsbCwgb3IgSFRUUCByZXF1ZXN0IHRvIGFuIFMzIGJ1Y2tldCBpcyBp
cnJlbGV2YW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmlj
aGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVk
dSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKYW51YXJ5IDEzLCAyMDIwIGF0IDk6MzMg
QU08YnI+DQo8Yj5UbzogPC9iPlZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7dmxhZGltaXJAY29ubmVj
dDJpZC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
LCBOYXQgU2FraW11cmEgJmx0O25hdEBzYWtpbXVyYS5vcmcmZ3Q7LCAmcXVvdDtSaWNoYXJkIEJh
Y2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmll
dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBbVU5WRVJJRklF
RCBTRU5ERVJdIFJlOiBQQVI6IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGJlIGNs
ZWFyLCBJ4oCZbSBub3Qgc2F5aW5nIHdlIHN1Z2dlc3QgYSBwYXJ0aWN1bGFyIGZvcm0sIGFuZCBJ
IGFncmVlIHRoYXQgd2Ugc2hvdWxkbuKAmXQgc3BlY2lmeSB0aGF0IOKAnGl04oCZcyBhIEpXVOKA
nSBvciBzb21ldGhpbmcgb2YgdGhhdCBuYXR1cmUuIEJ1dCBpZiB3ZSBjYWxsIHRoZSByZXN1bHQg
b2YgUEFSIOKAnHRoaW5nIFjigJ0gYW5kIHRoZSB0YXJnZXQgb2YgcmVxdWVzdF91cmkg4oCcdGhp
bmcgWOKAnSBpbiBKQVIsIHRoZW4NCiB3ZeKAmXJlIGNvbXBhdGlibGUgd2l0aG91dCBzYXlpbmcg
d2hhdCDigJx0aGluZyBY4oCdIG5lZWRzIHRvIGJlIGluIGFsbCBjYXNlcy4mbmJzcDsgPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBjYXNlcyB3aGVyZSB5
b3UgZG8gYSByZW1vdGUgbG9vayB1cCwgd2Ugd2FudCDigJx0aGluZyBY4oCdIHRvIGJlIGZvcm1h
dHRlZCBhcyBhIEpXVC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+V2UgaGFkIGEgY2FzZSBvZiBzaW1pbGFybHkgdW5pbnRlbnRpb25h
bCBsaW1pdGluZyBpbiBKQVIgcHJldmlvdXNseSwgc2F5aW5nIHRoYXQgeW91IGhhZCB0byBkbyBh
biBIVFRQIGxvb2t1cCBvbiB0aGUgcmVxdWVzdF91cmksIGJ1dCBJIGJlbGlldmUgdGhhdOKAmXMg
YmVlbiBiYWNrZWQgb2ZmIG5vdyBhbmQgbWFkZSBjb25kaXRpb25hbC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3Rpbjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDExLCAy
MDIwLCBhdCA1OjI4IEFNLCBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhyZWY9Im1haWx0bzp2
bGFkaW1pckBjb25uZWN0MmlkLmNvbSI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkg
c3VnZ2VzdGlvbiBpcyB0byBhYnN0YWluIGZyb20gc3BlY2lmeWluZyB0aGUgY29uY3JldGUgZm9y
bSBvZiB0aGUgcmVzb3VyY2UgcG9pbnRlZCB0byBieSB0aGUgUEFSIFVSSS4gUmVnYXJkbGVzcyBv
ZiBVUkkgdHlwZSAoVVJOLCBkb3dubG9hZGFibGUgaHR0cHMgVVJMIG9yIHNvbWV0aGluZyBlbHNl
KSwNCiBhbmQgZXZlbiBpZiB0aGUgUEFSIGVuZHBvaW50IGFuZCB0aGUgYXV0aFogZW5kcG9pbnQg
YXJlIG1hbmFnZWQgYnkgdHdvIGRpZmZlcmVudCBlbnRpdGllcyAobWljcm9zZXJ2aWNlIG9yIG90
aGVyIHNjZW5hcmlvKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4g
dGhlIENvbm5lY3QyaWQgaW1wbGVtZW50YXRpb24gb2YgUEFSIHRoZSByZXR1cm5lZCBVUkkgZG9l
c24ndCBwb2ludCB0byBhIHJlcXVlc3Qgb2JqZWN0IGFuZCBpdCBkb2Vzbid0IHBvaW50IHRvIGEg
SldUIGVpdGhlci4gSXQgcG9pbnRzIHRvIGFuIGludGVybmFsbHkgc3RvcmVkICZxdW90O3ByZS1w
cm9jZXNzZWQmcXVvdDsNCiBhdXRoWiByZXF1ZXN0LCB3aGljaCB0aGUgYXV0aFogZW5kcG9pbnQg
dGhlbiBwaWNrcyB1cCB0byBjb21wbGV0ZSB0aGUgYXV0aFouPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkV2ZW4gaWYgd2UgZXZlbnR1YWxseSBlbmQgdXAgaW4gbWljcm9z
ZXJ2aWNlIHdvcmxkLCBvciBhbGxvdyB0aGUgUEFSIGVuZHBvaW50IHRvIGJlIG1hbmFnZWQgYnkg
c29tZSBleHRlcm5hbCBlbnRpdHksIHRoZSBQQVIgVVJJIC0gaXRzIGludGVycHJldGF0aW9uLCB2
YWxpZGF0aW9uIGFuZCBwb3RlbnRpYWxseQ0KIHJlc291cmNlIHJldHJpZXZhbCAoSldUIG9yIG90
aGVyIGJsb2IpLCBpcyBhbiAmcXVvdDtpbnRlcm5hbCBjb250cmFjdCZxdW90OyBvbiB0aGUgQVMg
c2lkZS4gVGhpcyBkb2Vzbid0IGNvbmNlcm4gdGhlIGNsaWVudCwgYW5kIGluIE9BdXRoIDIuMCB0
aGUgcm9sZSBvZiBBUyBpcyBpbmRpdmlzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pkkgc2VlIFBBUiByZXF1ZXN0ICYjNDM7IGF1dGhaIHJlcXVlc3QgYXMgb25lIGxvZ2ljYWwgT0F1
dGggMi4wIGF1dGhaIHJlcXVlc3Q6IHRoZSBjbGllbnQgc3VibWl0cyBhbiBhdXRoWiByZXF1ZXN0
IGFuZCBnZXRzIGFuIGF1dGhaIHJlc3BvbnNlIGF0IHRoZSBlbmQuIFRoZSBVUkkgaXMgbmVjZXNz
YXJ5IGZvciB0aGUNCiBjbGllbnQgdG8gcHJvY2VlZCBmcm9tIHRoZSAxc3QgdG8gdGhlIDJuZCBz
dGVwLiBJZiB3ZSBtYW5hZ2UgdG8gZnJhbWUgLyB3b3JkIHRoZSBQQVIgVVJJIGluIHRoaXMgbG9n
aWNhbCB3YXksIHdpdGhvdXQgZ2V0dGluZyBzdHVjayBpbiB0aGUgSkFSIGRlZmluaXRpb24gLyBm
cmFtaW5nIG9mIHdoYXQgdGhlIHJlcXVlc3RfdXJpIC8gb2JqZWN0IGlzLCBpdCB3b3VsZCBiZSBn
cmVhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ug
SSB0aGluayBzaG91bGQgZm9jdXMgb24gbWFpbnRhaW5pbmcgdGhlIE9BdXRoIDIuMCBjb250cmFj
dCBmb3IgdGhlIGVudGlyZSBsb2dpY2FsIGF1dGhaIHJlcXVlc3QsIHRvZ2V0aGVyIHdpdGggdGhl
IGJhc2ljIGNvbnRyYWN0cyBvZiAxKSBKQVIgYW5kIHRoZSAyKSBhdXRoWg0KIGVuZHBvaW50Ljxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VmxhZGltaXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gMTAvMDEvMjAyMCAyMjo1NSwgSnVzdGluIFJpY2hlciB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3ZSBjb3VsZCBz
b2x2ZSB0aGlzIGJ5IHNheWluZyB0aGUgcmVzdWx0aW5nIGRhdGEgb2JqZWN0IG9mIGEgUEFSIGlz
IGEgcmVxdWVzdCBvYmplY3QuIFdoaWNoIG1pZ2h0IGFsc28gY29udGFpbiBhIHJlcXVlc3Qgb2Jq
ZWN0IGludGVybmFsbHkgYXMgd2VsbC4gSW4gdGhhdCBjYXNlIEpBUiBzaG91bGQgYmFjayBvZmYg
ZnJvbSBzYXlpbmcgaXTigJlzIGEgSldUIGFuZCBpbnN0ZWFkIHNheSBpdOKAmXMgYSByZXF1ZXN0
DQogb2JqZWN0LiBPciB3ZSBkZWZpbmUgYSBuZXcgdGVybSBmb3IgdGhpcyBhdXRob3JpemF0aW9u
IHJlcXVlc3QgYmxvYiB0aGluZy4gPG86cD4NCjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9yIFBBUiBjb3VsZCBhdCBsZWFzdCBzYXkgdGhhdCBpZiBpdOKAmXMgZGVy
ZWZlcmVuY2VkIG92ZXIgYSByZW1vdGUgcHJvdG9jb2wgdGhlbiBpdCBNVVNUIGJlIGEgSldULCBi
dXQgb3RoZXJ3aXNlIGl0IGNhbiBiZSB3aGF0ZXZlciB5b3Ugd2FudC4gVGhhdOKAmXMgd2hlcmUg
dGhlIHJlYWwgaW50ZXJvcCBjb25jZXJucyBjb21lIGluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMTAsIDIwMjAsIGF0
IDM6NDEgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86
cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNoYW5uYT00MGFtYXpvbi5j
b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvcnJlY3QuIFRoZSBwcm9ibGVtIGJlY29tZXMgcHJldHR5
IGNsZWFyIGluIHRoZSBjb250ZXh0IG9mIFBBUiwgd2hlcmUgdGhlIEFTIGlzIGdlbmVyYXRpbmcg
YW5kIHZlbmRpbmcgb3V0IHRoZSBVUkkgYXQgdGhlIFBBUiBlbmRwb2ludCwgYW5kIGNvbnN1bWlu
ZyBpdCBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gRnJvbSBhbiBpbnRlcm9wZXJhYmls
aXR5IHN0YW5kcG9pbnQsIGl04oCZcyBhbmFsb2dvdXMNCiB0byB0aGUgQVMgdmVuZGluZyBhbiBh
dXRob3JpemF0aW9uIGNvZGUgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGNvbnN1
bWluZyBpdCBhdCB0aGUgdG9rZW4gZW5kcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPuKAkyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVs
bGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJ
ZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLXRvcC1jb2xvcjpyZ2IoMTgxLCAxOTYsCiAgICAg
ICAgICAgICAgICAgIDIyMykiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij5Kb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNv
bSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5GcmlkYXksIEphbnVhcnkgMTAs
IDIwMjAgYXQgMTI6MjkgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWls
dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t
PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC9iPlRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Oywg
TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86bmF0QHNha2ltdXJhLm9yZyI+bmF0QHNh
a2ltdXJhLm9yZzwvYT4mZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iPnJpY2hhbm5hQGFtYXpv
bi5jb208L2E+Jmd0OywNCiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPltVTlZFUklGSUVEIFNFTkRFUl0g
UmU6IFtPQVVUSC1XR10gUEFSOiBwdXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUgSldUczwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFzc3VtZSB0aGUgY2xp
ZW50IHBvc3RzIGEgSkFSIGFuZCBnZXRzIGJhY2sgYSByZWZlcmVuY2UuJm5ic3A7IFRoZW4gdGhl
IHJlZmVyZW5jZSBpcyB0byBhIEpBUi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB0aGluayBJIHNlZSB0aGUgcHJvYmxlbS4mbmJzcDsgSWYgdGhlIHNlcnZlciBwcm92aWRpbmcg
dGhlIHJlZmVyZW5jZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIEFTIHRoZW4gdGhlIHNlcnZlciBk
b3Nlbid0IG5lZWQgdG8gZGVyZWZlcmVuY2UgdGhlIG9iamVjdCB2aWEgSFRUUCwgc28gaXQgY291
bGQgYmUgYSBVUk4gYXMgYW4gZXhhbXBsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+U28geWVzIGl0IGlzIG5vdCBhIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgZm9yIHRoZSBjbGll
bnQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCB0aGluayBh
Ym91dCBob3cgSSBjYW4gZmluZXNzZSB0aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGFncmVlIGl0IGlzIG5vdCBhIGNoYW5nZSBpbiBpbnRlbnQuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBzZWUgaWYgSSBjYW4gZ2V0IG91ciBBRCB0byBhY2Nl
cHQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAxMCwgMjAyMCwgNDo1NyBQTSBCcmlhbiBDYW1wYmVs
bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvc3Bhbj48L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1sZWZ0LWNvbG9yOnJn
YigyMDQsCiAgICAgICAgICAgICAgICAgICAgMjA0LCAyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+U3VyZSBidXQgdGhlIHRleHQgcHJvcG9zZWQgKG9yIHNvbWV0aGlu
ZyBsaWtlIGl0KSBxdWFsaWZpZXMgaXQgc3VjaCB0aGF0IHRoZXJlIGFyZW4ndCBpbnRlcm9wZXJh
YmlsaXR5IHF1ZXN0aW9ucyBiZWNhdXNlIGl0J3Mgb25seSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRh
aWwgdG8gdGhlIEFTIHdobyBib3RoIHByb2R1Y2VzIHRoZSBVUkkgYW5kIGNvbnN1bWVzIGl0cyBj
b250ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTAsIDIwMjAgYXQgMTI6NDgg
UE0gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52ZTdqdGJAdmU3anRiLmNv
bTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1heSBiZSBhIGNoYWxsZW5nZSB0
byBjaGFuZ2UgdGV4dCBzYXlpbmcgdGhhdCB0aGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIGNv
dWxkIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIGEgcmVxdWVzdCBvYmplY3QuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIG5vdCBhIHJlcXVlc3Qgb2JqZWN0IHRoZW4gd2hhdCBh
bmQgaG93IGlzIHRoYXQgaW50ZXJvcGVyYWJsZSBhcmUgbGlrZWx5IEFEIHF1ZXN0aW9ucy4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBwZXJoYXBzIHNlZSBjaGFuZ2lu
ZyBpdCB0byBtdXN0IGJlIGEgcmVxdWVzdCBvYmplY3QsIG9yIG90aGVyIGZvcm1hdCBkZWZpbmVk
IGJ5IGEgcHJvZmlsZS48YnI+DQo8YnI+DQpKb2huIEIuJm5ic3A7Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAxMCwgMjAyMCwgMzo0
NSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmNh
bXBiZWxsQHBpbmdpZGVudGl0eS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B
Z3JlZSBhbmQgYWdyZWUuIEJ1dCBnaXZlbiB0aGF0IHRoZSBjaGFuZ2Ugc3VnZ2VzdGVkIGJ5IEFu
bmFiZWxsZSBoYXMgbm8gaW1wYWN0IG9uIHRoZSBjbGllbnQgb3IgaW50ZXJvcGVyYWJpbGl0eSwg
cGVyaGFwcyBOYXQgb3IgSm9obiBjb3VsZCB3b3JrIHRoZSBjaGFuZ2UgaW50byB0aGUgZHJhZnQg
ZHVyaW5nIHRoZSBlZGl0cyB0aGF0IGhhcHBlbiBkdXJpbmcgdGhlIGZpbmFsIHN0YWdlcyBvZiB0
aGluZ3M/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiA5LCAyMDIwIGF0IDE6NTYgQU0g
VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJz
dGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj40MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1sZWZ0LWNvbG9yOnJnYigy
MDQsIDIwNCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDQpIj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYXNzdW1lIGdp
dmVuIHRoZSBzdGF0dXMgb2YgSkFSLCB3ZSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGl0LiBBbmQg
YXMgSSBzYWlkLCB0aGlzIGRpZmZlcmVuY2UgZG9lcyBub3QgaW1wYWN0IGludGVyb3BlcmFiaWxp
dHkgZnJvbSBjbGllbnQgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPkFtIDA5LjAxLjIwMjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJk
IEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9u
LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+SXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRl
eHQgdG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIg
dG8gcmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hs
aWdodHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcNCiBQQVIgc3BlY2lhbCB0cmVhdG1lbnQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5X
aGF0IGlmIHdlIGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBTZWN0aW9uIDUuMiBvZiBKQVI6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu
LWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3IFw7JnF1b3Q7Ij5UaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJl
ZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVzdDwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyBcOyZxdW90
OyI+T2JqZWN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h
cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyBcOyZxdW90OyI+VGhlIGNvbnRlbnRzIG9mIHRoZSByZXNvdXJj
ZSByZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJlcXVlc3Q8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDsm
cXVvdDsiPk9iamVjdCwgdW5sZXNzIHRoZSBVUkkgd2FzIHByb3ZpZGVkIHRvIHRoZSBjbGllbnQg
YnkgdGhlIEF1dGhvcml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgXDsmcXVvdDsiPlNlcnZlci48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgd291bGQg
YWxsb3cgZm9yIHVzZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQgcHJvdmlkZXMgcHJlLWRlZmlu
ZWQgcmVxdWVzdCBVUklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMgdmlhIGEgY2xpZW50IG1hbmFn
ZW1lbnQgY29uc29sZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWlyIGNsaWVudCBhcHBzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+4oCT
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5Bbm5hYmVsbGUg
UmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+T24gMS84LzIwLCAyOjUwIFBNLCAmcXVvdDtUb3Jz
dGVuIExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDt0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRl
cnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT4m
Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgSGksPHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7eW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90IHJlcXVpcmUgdGhlIEFT
IHRvIHJlcHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCByZXF1ZXN0IG9iamVjdC4g
VGhlIFVSSSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5LiBUaGF0IHdoeSB0aGUg
ZHJhZnQgc3RhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
cXVvdDtUaGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0YSBh
dmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO1RoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZyb20gYW4gQVMgaW1wbGVtZW50YXRp
b24gcGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZyb20gYSBjbGllbnQncyAoaW50ZXJv
cCkgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UgbWF5IGFkZCBh
IHN0YXRlbWVudCB0byBQQVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBieSB0aGUg
UEFSIG1lY2hhbmlzbSAoTUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9uLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmVzdCByZWdhcmRzLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsm
bmJzcDsmbmJzcDsgVG9yc3Rlbi4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmZ3Q7IE9uIDguIEphbiAyMDIwLCBhdCAyMzo0MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5h
YmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0
Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj40MGFtYXpv
bi5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgSGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZu
YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGUgY3VycmVudCBkcmFmdHMgb2YgUEFSICgtMDApIGFu
ZCBKQVIgKC0yMCkgcmVxdWlyZSB0aGF0IHRoZSBBUyB0cmFuc2Zvcm0gYWxsIHB1c2hlZCByZXF1
ZXN0cyBpbnRvIEpXVHMuIFRoaXMgcmVxdWlyZW1lbnQgYXJpc2VzIGZyb20gdGhlIGZvbGxvd2lu
Zzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IOKAoiBQQVIgdXNlcyB0aGUgcmVxdWVzdF91cmkgcGFyYW1ldGVyIGRlZmluZWQg
aW4gSkFSIHRvIGNvbW11bmljYXRlIHRoZSBwdXNoZWQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2Ug
cmVmZXJlbmNlZCBieSByZXF1ZXN0X3VyaSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0
aW9uIDUuMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IOKAoiBSZXF1ZXN0IE9iamVjdCBpcyBkZWZpbmVkIHRvIGJlIGEgSldU
IGNvbnRhaW5pbmcgYWxsIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gKFNl
Y3Rpb24gMi4xKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs
dmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBU
aGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgaW50ZXJvcGVy
YWJpbGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlzIGFsc28gaW5jb25z
aXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0ZW1wdGluZyB0byBk
ZWZpbmUNCiB0aGUgaW50ZXJuYWwgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUgdHdvIEFTIGVu
ZHBvaW50cy4gV29yc2UsIHRoaXMgcmVzdHJpY3Rpb24gbWFrZXMgaXQgaGFyZGVyIGZvciB0aGUg
YXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBsZXZlcmFnZSB2YWxpZGF0aW9uIGFuZCBvdGhlciB3
b3JrIHBlcmZvcm1lZCBhdCB0aGUgUEFSIGVuZHBvaW50LCBhcyB0aGUgc3RhdGUgb3Igb3V0Y29t
ZSBvZiB0aGF0IHdvcmsgbXVzdCBiZSBmb3JjZWQgaW50byB0aGUNCiBKV1QgZm9ybWF0IChvciBy
ZXRyaWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNhbGwgb3IgZGF0YWJhc2UgbG9va3Vw
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsg4oCTPHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmZ3Q7IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsgQVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZu
YnNwOyZuYnNwOyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Ym9yZGVyOm5vbmUg
d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhp
cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg
Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3
LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycw0KIGlzIHN0cmljdGx5
IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv
biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp
bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv
dXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h
aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0
aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl
LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlDQogcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu
IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu
ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj
b21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRo
IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0
aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1p
ciBEemh1dmlub3Y8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C0644BEE97F14C189E22F517F8991AA1amazoncom_--


From nobody Mon Jan 13 15:19: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 1B5481200E3 for ; Mon, 13 Jan 2020 15:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FjJF_0mb-Dx for ; Mon, 13 Jan 2020 15:19:33 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D830120091 for ; Mon, 13 Jan 2020 15:19:32 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id o13so12090977ljg.4 for ; Mon, 13 Jan 2020 15:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8TGdj2iOfn5q3Hj3ZaqLjA6tWdMVWL7Lvk3Mbb6tGLc=; b=J3a6ZXeUyZGRBvaVoehLzUrBYIhQNULAnzYXcTyOAtFFQzTvXgUnl5bSMRMbXl60Q0 CMIWIWJVw5EZKNw67enfogLF4m3+CZeOEfuVu2PTvGjxIGD0JpkX3IXV6KbcEKCGst+I 2dZdpFkEraohJoWRQp5sfYM+RjONb1FS9ktg/zpNwZrTPjc2nf5852LJHERX76Iapd+7 z83h8AK3CoAbuZi5uBbowp+2iKmVydpID4qKgIIhOuK7eej4F1oFESSk3U1d3t5mgtZw Gvo2xk8aKteP7PMgflpdKrsqf5VGdR9IaV26Bx/CXk6aHZmjs8xMaoSKjkE0zGsOV6Vn b8EA==
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=8TGdj2iOfn5q3Hj3ZaqLjA6tWdMVWL7Lvk3Mbb6tGLc=; b=PWIyeWQofUUChYYbYRzpN7cXXC4oNlKihF6z8DT+SUj3uaIU7RnZf96qtnxOktV2s6 PQ2Kemb3H4BhRfpZes49b33DkRKw6OBQw/pB68CnT2oluaBjQ3Zdskg8O9e2O3CYwohh aa4CrOIFzMmlhviNFktzlk02LPK5KBpNPMhqW/lxslRP6pUSlasMNWAKFhsyUHgQOHcJ BcPLV7OOMi4LR5RBpFWyweQwQfSu36oxoEsNxV0ttpUQhxnz4sQBhmMcYN+2/Iu8+ff7 G0Q6pBlzngDnMLimr97xiQG1ChjPYhDzCxv7xA85NwVFDR0GxClN+KoGW+TjjVFw27Dp I4Dg==
X-Gm-Message-State: APjAAAW7JLjgkOlAVUZtPTwvL1tHXmWN/7qdzLMRkAhUyqsyQ1WRXhuJ b6sdCAvbl3wNwuZ0H7cNmUw5YljU32CkzolG4cdDcx9UX8xnJapBBM2ZBFOp95JsRdzJiiHA9sK 0tR/vXVw3mouleQ==
X-Google-Smtp-Source: APXvYqw0tEme3R5J1aB8z3FrFBc5MRcFx9r14V1vh/yPq1LD9Sjz8TlbBikC5poquIhWTucyBnjL766RGiY6nAamT0M=
X-Received: by 2002:a2e:8946:: with SMTP id b6mr12265700ljk.1.1578957569189; Mon, 13 Jan 2020 15:19:29 -0800 (PST)
MIME-Version: 1.0
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>   
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 13 Jan 2020 16:19:17 -0700
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Justin Richer , Vladimir Dzhuvinov , oauth ,  Nat Sakimura 
Content-Type: multipart/alternative; boundary="00000000000007012c059c0db566"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 13 Jan 2020 23:19:37 -0000

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

+1

On Mon, Jan 13, 2020, 4:15 PM Richard Backman, Annabelle  wrote:

> My original suggestion was to remove this requirement from cases where th=
e
> AS originally provided the request_uri, because in these cases, the
> request_uri resolution becomes an internal implementation detail of the A=
S.
> I still think that=E2=80=99s the best criterion to use for when this requ=
irement
> should apply. This criterion covers all JAR implementations, as the JAR
> endpoint is explicitly defined as being part of the AS.
>
>
>
> Note that =E2=80=9CAS=E2=80=9D refers to a role within OAuth, and that ro=
le may be
> implemented by a collection of micro services and/or third party services=
.
> From an interop standpoint, it doesn=E2=80=99t matter that the PAR endpoi=
nt and
> authorization endpoint are hosted on separate micro services; it=E2=80=99=
s still
> the AS vending out a request_uri for its own consumption later. Whether
> that request_uri is resolved via a local DB lookup, internal web service
> call, or HTTP request to an S3 bucket is irrelevant.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Justin Richer <
> jricher@mit.edu>
> *Date: *Monday, January 13, 2020 at 9:33 AM
> *To: *Vladimir Dzhuvinov 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
>
>
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that
> we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or=
 something of that nature. But if
> we call the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of req=
uest_uri =E2=80=9Cthing X=E2=80=9D
> in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in
> all cases.
>
>
>
> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted
> as a JWT.
>
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believ=
e
> that=E2=80=99s been backed off now and made conditional.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
>
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint a=
nd
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
>
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
>
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or oth=
er
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
>
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end=
.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, witho=
ut
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
>
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
>
>
> Vladimir
>
>
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it=E2=80=99s a JWT and=
 instead
> say it=E2=80=99s a request object. Or we define a new term for this autho=
rization
> request blob thing.
>
>
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remote=
 protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That=E2=
=80=99s
> where the real interop concerns come in.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
>
>
> Correct. The problem becomes pretty clear in the context of PAR, where th=
e
> AS is generating and vending out the URI at the PAR endpoint, and consumi=
ng
> it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
>
>
> If we assume the client posts a JAR and gets back a reference.  Then the
> reference is to a JAR.
>
>
>
> I think I see the problem.  If the server providing the reference is
> associated with the AS then the server dosen't need to dereference the
> object via HTTP, so it could be a URN as an example.
>
>
>
> So yes it is not a interoperability issue for the client.
>
>
>
> I will think about how I can finesse that.
>
>
>
> I agree it is not a change in intent.
>
>
>
> I will see if I can get our AD to accept that.
>
>
>
> John B.
>
>
>
>
>
>
>
>
>
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
> wrote:
>
> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
>
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
>
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
>
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
>
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
>
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
>
>
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
>
>
> What if we changed this sentence in Section 5.2 of JAR:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object.
>
>
>
> To:
>
> The contents of the resource referenced by the URI MUST be a Request
>
> Object, unless the URI was provided to the client by the Authorization
>
> Server.
>
>
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>
>
>     Hi,
>
>
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>
>
>     "There is no need to make the
>
>           authorization request data available to other parties via this
>
>           URI.=E2=80=9D
>
>
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>
>
>     best regards,
>
>     Torsten.
>
>
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>
>     >
>
>     > Hi all,
>
>     >
>
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>
>     >
>
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>
>     >
>
>     > =E2=80=93
>
>     > Annabelle Richard Backman
>
>     > AWS Identity
>
>     >
>
>     > _______________________________________________
>
>     > OAuth mailing list
>
>     > OAuth@ietf.org
>
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> 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._

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


+1

On Mon, Jan 13, 2020, 4:15 PM Richard Backman, Annabell=
e <richanna=3D40amazon.co=
m@dmarc.ietf.org> wrote:











My original suggestion was to remove this requiremen=
t from cases where the AS originally provided the request_uri, because in t=
hese cases, the request_uri resolution becomes an internal implementation d=
etail of the AS. I still think that=E2=80=99s
 the best criterion to use for when this requirement should apply. This cri=
terion covers all JAR implementations, as the JAR endpoint is explicitly de=
fined as being part of the AS.


=C2=A0


Note that =E2=80=9CAS=E2=80=9D refers to a role with=
in OAuth, and that role may be implemented by a collection of micro service=
s and/or third party services. From an interop standpoint, it doesn=E2=80=
=99t matter that the PAR endpoint and authorization endpoint
 are hosted on separate micro services; it=E2=80=99s still the AS vending o=
ut a request_uri for its own consumption later. Whether that request_uri is=
 resolved via a local DB lookup, internal web service call, or HTTP request=
 to an S3 bucket is irrelevant.


=C2=A0




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


Annabelle Richard B=
ackman


AWS Identity=





=C2=A0


=C2=A0




From=
: OAuth <oau=
th-bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu=
>

Date: Monday, January 13, 2020 at 9:33 AM

To: Vladimir Dzhuvinov <vladimir@connect2id.com>

Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40ama=
zon.com@dmarc.ietf.org>

Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests=
 must become JWTs






=C2=A0




To be clear, I=E2=80=99m not saying we suggest a par=
ticular form, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Ci=
t=E2=80=99s a JWT=E2=80=9D or something of that nature. But if we call the =
result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=
=80=9Cthing X=E2=80=9D in JAR, then
 we=E2=80=99re compatible without saying what =E2=80=9Cthing X=E2=80=9D nee=
ds to be in all cases.=C2=A0 




=C2=A0






In cases where you do a remote look up, we want =E2=
=80=9Cthing X=E2=80=9D to be formatted as a JWT.=C2=A0






=C2=A0






We had a case of similarly unintentional limiting in=
 JAR previously, saying that you had to do an HTTP lookup on the request_ur=
i, but I believe that=E2=80=99s been backed off now and made conditional.






=C2=A0






=C2=A0=E2=80=94 Justin















On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <=
vladimir@connect2id.com> wrote:




=C2=A0






My suggestion is to abstain from specifying the conc=
rete form of the resource pointed to by the PAR URI. Regardless of URI type=
 (URN, downloadable https URL or something else),
 and even if the PAR endpoint and the authZ endpoint are managed by two dif=
ferent entities (microservice or other scenario).


In the Connect2id implementation of PAR the returned=
 URI doesn't point to a request object and it doesn't point to a JW=
T either. It points to an internally stored "pre-processed"
 authZ request, which the authZ endpoint then picks up to complete the auth=
Z.


Even if we eventually end up in microservice world, =
or allow the PAR endpoint to be managed by some external entity, the PAR UR=
I - its interpretation, validation and potentially
 resource retrieval (JWT or other blob), is an "internal contract"=
; on the AS side. This doesn't concern the client, and in OAuth 2.0 the=
 role of AS is indivisible.


=C2=A0


I see PAR request + authZ request as one logical OAu=
th 2.0 authZ request: the client submits an authZ request and gets an authZ=
 response at the end. The URI is necessary for the
 client to proceed from the 1st to the 2nd step. If we manage to frame / wo=
rd the PAR URI in this logical way, without getting stuck in the JAR defini=
tion / framing of what the request_uri / object is, it would be great.


=C2=A0


The normative language I think should focus on maint=
aining the OAuth 2.0 contract for the entire logical authZ request, togethe=
r with the basic contracts of 1) JAR and the 2) authZ
 endpoint.


=C2=A0


Vladimir


=C2=A0




On 10/01/2020 22:55, Justin Richer wrote:<=
/u>






So we could solve this by saying the resulting data =
object of a PAR is a request object. Which might also contain a request obj=
ect internally as well. In that case JAR should back off from saying it=E2=
=80=99s a JWT and instead say it=E2=80=99s a request
 object. Or we define a new term for this authorization request blob thing.=
 





=C2=A0






Or PAR could at least say that if it=E2=80=99s deref=
erenced over a remote protocol then it MUST be a JWT, but otherwise it can =
be whatever you want. That=E2=80=99s where the real interop concerns come i=
n.






=C2=A0






=C2=A0=E2=80=94 Justin















On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabe=
lle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:




=C2=A0






Correct. The problem becomes pretty clear in the con=
text of PAR, where the AS is generating and vending out the URI at the PAR =
endpoint, and consuming it at the authorization endpoint. From an interoper=
ability standpoint, it=E2=80=99s analogous
 to the AS vending an authorization code at the authorization endpoint and =
consuming it at the token endpoint.








=E2=80=93=C2=A0






Annabelle Richard B=
ackman






AWS Identity=









=C2=A0






=C2=A0








From:=C2=A0John Bradley <ve7jtb@ve7jtb.com>
Date:=C2=A0<=
/span>Friday, January 10, 2020 at 12:29 PM

To:=C2=A0Brian Campbell <bcampbell@pingidentity.com>

Cc:=C2=A0Torsten Lodderstedt <torsten@lodderstedt.net>, Nat S=
akimura <nat@sakimura.org>, "Richard Backman, Annabelle" =
<richanna@amazon.com>,
 oauth <oauth@ietf.org>

Subject:=C2=
=A0[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must =
become JWTs










=C2=A0












If we assume the client posts a JAR and gets back a =
reference.=C2=A0 Then the reference is to a JAR.=C2=A0










=C2=A0










I think I see the problem.=C2=A0 If the server provi=
ding the reference is associated with the AS then the server dosen't ne=
ed to dereference the object via HTTP, so it could be a URN as an example.=
=C2=A0










=C2=A0










So yes it is not a interoperability issue for the cl=
ient.=C2=A0=C2=A0










=C2=A0










I will think about how I can finesse that.=C2=A0<=
/u>










=C2=A0










I agree it is not a change in intent.=C2=A0










=C2=A0










I will see if I can get our AD to accept that.










=C2=A0










John B.=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0










On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com>=
 wrote:












Sure but the text proposed (or something like it) qu=
alifies it such that there aren't interoperability questions because it=
's only an implementation detail to the AS who both produces the URI an=
d consumes its content.








=C2=A0










On Fri, Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:=















It may be a challenge to change text saying that the=
 contents of the resource could be something other than a request object.=
=C2=A0










=C2=A0










If not a request object then what and how is that in=
teroperable are likely AD questions.=C2=A0










=C2=A0










I could perhaps see changing it to must be a request=
 object, or other format defined by a profile.



John B.=C2=A0=C2=A0










=C2=A0










=C2=A0










On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com>=
 wrote:














Agree and agree. But given that the change suggested=
 by Annabelle has no impact on the client or interoperability, perhaps Nat =
or John could work the change into the draft during the edits that happen d=
uring the final stages of things?








=C2=A0










On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt &=
lt;torsten=3D40lodderstedt.net@d=
marc.ietf.org> wrote:














I would assume given the status of JAR, we don=E2=80=
=99t want to change it. And as I said, this difference does not impact inte=
roperability from client perspective.























Am 09.01.2020 um 00:5=
8 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:













It would be more appropriate to add the text to JAR rather than PAR. It d=
oesn't seem right for PAR to retcon rules in JAR. Moving the text to JA=
R also highlights the weirdness of giving
 PAR special treatment.






=C2=A0






What if we changed this sentence in Section 5.2 of JAR:





The c=
ontents of the resource referenced by the URI MUST be a Request



Objec=
t.




=C2=A0






To:=C2=A0





The c=
ontents of the resource referenced by the URI MUST be a Request



Objec=
t, unless the URI was provided to the client by the Authorization


Serve=
r.




=C2=A0






This would allow for use cases such as an AS that provides pre-defined re=
quest URIs, or vends request URIs via a client management console, or bakes=
 them into their client apps.






=C2=A0






=E2=80=93=C2=
=A0






Annabelle Richard Backman






AWS Identity






=C2=A0






On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org=
>
 wrote:






=C2=A0






=C2=A0=C2=A0=C2=A0 Hi,=C2=A0






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






=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the AS to rep=
resent the request as a JWT-based request object. The URI is used as intern=
al reference only. That why the draft states






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






=C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the<=
/span>






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization requ=
est data available to other parties via this






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D






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






=C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementation=
 perspective, it doesn't matter from a client's (interop) perspecti=
ve.






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






=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that request=
_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.=







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






=C2=A0=C2=A0=C2=A0=C2=A0best regards,






=C2=A0=C2=A0=C2=A0 Torsten.=C2=A0=C2=A0






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






=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Backman, A=
nnabelle <richanna=3D40amazon.com@=
dmarc.ietf.org>
 wrote:






=C2=A0=C2=A0=C2=A0 >=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> Hi all,






=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and JAR (-20=
) require that the AS transform all pushed requests into JWTs. This require=
ment arises from the following:






=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=A2 PAR uses the request_uri parameter defined in JAR to communicate the pu=
shed request to the authorization endpoint.






=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=A2 According to JAR, the resource referenced by request_uri MUST be a Requ=
est Object. (Section 5.2)






=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=A2 Request Object is defined to be a JWT containing all the authorization =
request parameters. (Section 2.1)






=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement to sup=
port interoperability, as this is internal to the AS. It is also inconsiste=
nt with the rest of JAR, which avoids attempting to define
 the internal communications between the two AS endpoints. Worse, this rest=
riction makes it harder for the authorization endpoint to leverage validati=
on and other work performed at the PAR endpoint, as the state or outcome of=
 that work must be forced into the
 JWT format (or retrieved via a subsequent service call or database lookup)=
.






=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman






=C2=A0=C2=A0=C2=A0 > AWS Identity






=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0> ____________________________________________=
___






=C2=A0=C2=A0=C2=A0 > OAuth mailing list






=C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf.org







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






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














_______________________________________________

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 e=
rror, please notify the sender immediately by e-mail and delete the message=
 and any file attachments from your computer. Thank you.<=
/u>




















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








_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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









=C2=A0











_______________________________________________


OAuth mailing list


OAuth@ietf.org


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




-- 


Vladimir Dzhuvinov










=C2=A0








_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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






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


From nobody Mon Jan 13 17:31: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 814EA120020 for ; Mon, 13 Jan 2020 17:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv6vqFywH5YY for ; Mon, 13 Jan 2020 17:31:44 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F4E12001B for ; Mon, 13 Jan 2020 17:31:44 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id v201so8422766lfa.11 for ; Mon, 13 Jan 2020 17:31:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=rhAVeJaSxiz1Fh8VRLPT7OTP02facygatz4MXOSIa2A=; b=FuwzaH9RxkFiUz+5kWHfhOQcQDWi1fOjbFrGwapJaN1xtvWeosWHWhdBXO9woOQE/U sBqD5S0MYaY+bXXjvFwrBvl0+mCNIm7dsgjjhhBrYSy9fIH7BFQe95w/KftLKfowODYI NOiHiRuOIlTqyxWPFY4XAo29Q+eXnw3Kl/gNiEiGpqCkHrHj4Bc4DzqhJtN1SCCAlvsy skB/ONIpkeICnYPFl1RvdY5beY33aRfmKleGw8scIXegb26x22ME4fbPe9larNOyr1qv EkzPuNWSCOpF/uAsf30YZqKF9na35KcYfgCpt1HfnndphYSt9yzK4TkpxmsxXNq1ysox fi6Q==
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=rhAVeJaSxiz1Fh8VRLPT7OTP02facygatz4MXOSIa2A=; b=uNCmV/MdVPbkKRi5cMQExsfL1JJGngZ+pz982dYVlJJXYVZ+uLk43k1ONWqH/W+6N6 B3SbEHEQV1VMlMDGoKRfpaHGVPgpVHPX40/9B2alUyHtcUJwlgNbYh7ErhX4T7vzfg+x Agz2qxJVacvFzkSrkw7SQ/OWTOWDe6CzkoOY+sN3NoAZoMASq/2FOxHaA9+EJIBFx7H5 WUIdbjGEB5upMxIeQg+NQafs9h2mvPkSLCaQkUpLp8Re7Vt9ARCC9+cPFlJlOO5/p/OR FzZegsJUDdWUFUwBZoUvFBvnmLOevysc9NmV0jonpaEvVVvjih9IaCoPjHcikggdUJHG 006Q==
X-Gm-Message-State: APjAAAUSpIfz/t90PqhJA2nQvZ9UcuSa5Mm/IUYfzVYNa2k3fqZgQpDI sMjdc3eKhLWODr5BmkHLJXevynZovglCeqZWMoM=
X-Google-Smtp-Source: APXvYqz0+QpYvg6xBVBP2ofaEiIjTZg6Z+/EW9wHCRNCBDrjx7QQ5vn6lc0Cwd04DB69eT7OEV+HbhK2OO9RASGJV/Q=
X-Received: by 2002:a19:cb54:: with SMTP id b81mr180146lfg.188.1578965502597;  Mon, 13 Jan 2020 17:31:42 -0800 (PST)
MIME-Version: 1.0
From: Dick Hardt 
Date: Mon, 13 Jan 2020 17:31:31 -0800
Message-ID: 
To: Torsten Lodderstedt , Brian Campbell ,  Justin Richer 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e51f79059c0f8d43"
Archived-At: 
Subject: [OAUTH-WG] RAR & multiple resources?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 01:31:47 -0000

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

Torsten / Justin / Brian

In my reading of the ID, it appears that there is a request for just one
access token, and the authorization_details array lists one or more
resources that the one access token will provide access to. Correct?

I have heard anecdotally that there is interest in granting access to
multiple resources, and having multiple access tokens, which would enable
different components of a client to have different access tokens.

Do you consider multiple access tokens out of scope of RAR?

/Dick

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


Torsten / Justin / Brian
<=
br>
In my reading of the ID, it appears that there is a request f=
or just one access token, and the authorization_details array=C2=A0lists on=
e or more resources that the one access token will provide access to. Corre=
ct?

I have heard anecdotally that there is interes=
t in granting access to multiple=C2=A0resources, and having multiple=C2=A0a=
ccess tokens, which would enable different components of a client to have d=
ifferent access tokens.=C2=A0

Do you consider mult=
iple access tokens out of scope of RAR?

/Dick


--000000000000e51f79059c0f8d43--


From nobody Mon Jan 13 17:33: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 F129912001B for ; Mon, 13 Jan 2020 17:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1P_d57QXwDn for ; Mon, 13 Jan 2020 17:33:41 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4467120026 for ; Mon, 13 Jan 2020 17:33:40 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id j26so12359373ljc.12 for ; Mon, 13 Jan 2020 17:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oMco1CfoSVWtafn2Q5cj4XfGHLDaH8H1i7mh7M42Jzw=; b=BZLmFl47ygr0pSfbCxawWl9WlDO2Wi7B3OXQ/BiSN8vXwGfpW6rElyBmGDhqxN27AJ 2XuVCs4E8rGPPI6W7R8zcxw9Q5FKZdmkQ/KgBKgmZIzgr+u5Aw07wfFHaXXeRwPycUaL KVcJSgIGPDGPd/hFt+oOeQzmsUapmA2wtUR9BbfODer7OLMoonL8YciMSqX+6Gpev5p7 uVRgrglCmAYupzJcOjuFBfkwvdsqBtjmmXcJI9B+iF+I1eMeHy5HF/obWO/VkGKcgyTC E/y2lk8iJuMTo6BvF54YbHDqp1yQ+SfqX0+ZAmCXy5h82B3T1Vb7mnIrfTZ42xLtPJ+I fxQg==
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=oMco1CfoSVWtafn2Q5cj4XfGHLDaH8H1i7mh7M42Jzw=; b=QUyAFBqwt0ii6mQ8Fu/XgemqPRC2v5FLjq1bENdtyItdsUQntJOXPzAwVfTXweYeci Ju4Q+pyj7KvHk3AVIzhL3742alMCR1vSK7pGRwi7Yy8PsTeZbm7WP2UNOpGNzV8hLfYp JmSn+O82Cmp6fa+1kgWGvX+ac4FTTD7Xsp6fPaxl4NRA2T/eEpByPryiEEbGrkDkyLRv 9Kx6AhFG1ejliTXFzbMDd/lQBfaf6JKDTCJd/4LXVPW/ZK35+fdE8unZ4oV5aEPnT0ST O+/FuYI4QtKF729sD2rX7J0OYx4zu1PDdtnJKCrHD0+PNtO4bVbrwOj/A608cS5XdeL9 TA/A==
X-Gm-Message-State: APjAAAXkqJpp6+CQrKDQWqCb5FkPGnWJ3saeek7q+Dw8Fi7ZwuheooXW 6oiWKk29sJBqeCISvEMxINrDJJslMMwLh9GDA2eJ9IOX
X-Google-Smtp-Source: APXvYqycV5s/h7BQgIQQW8fVHeKFlh7D3biCzPUT953IBT//51Pvvd7T0lYTBzvEtrK1CG5QtsdVUzEqGcCjYsyZ+Jw=
X-Received: by 2002:a2e:3a13:: with SMTP id h19mr12862269lja.16.1578965618874;  Mon, 13 Jan 2020 17:33:38 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 13 Jan 2020 17:33:27 -0800
Message-ID: 
To: Hannes Tschofenig 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d35f00059c0f941a"
Archived-At: 
Subject: Re: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession 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, 14 Jan 2020 01:33:43 -0000

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

3/4 options are at the same time on the same day of the week. More options
would be nice!

On Mon, Jan 13, 2020 at 9:19 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> at the Singapore IETF meeting we talked about setting time aside for
> discussing proof-of-possession tokens.
>
>
>
> To schedule a call we put a Doodle poll together:
>
> https://doodle.com/poll/sqhbeeg6knp435ag
>
>
>
> Please let us know by the end of the week what dates work for you.
>
>
>
> Ciao
>
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you. IMPORTANT NOTICE: The contents of
> this email and any attachments are confidential and may also be privileged.
> If you are not the intended recipient, please notify the sender immediately
> and do not disclose the contents to any other person, use it for any
> purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


3/4 options are at the same time on the same day of the we=
ek. More options would be nice!

On Mon, Jan 13, 2020 at 9:19 AM Hannes Tscho=
fenig <Hannes.Tschofenig@ar=
m.com> wrote:











Hi all, 


=C2=A0


at the Singapore IETF meeting we talked about settin=
g time aside for discussing proof-of-possession tokens.



=C2=A0


To schedule a call we put a Doodle poll together: 


https://doodle.com/poll/sqhbeeg6knp=
435ag


=C2=A0


Please let us know by the end of the week what dates=
 work for you.



=C2=A0


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. IMPORTANT NOTIC=
E: The contents of this email and any attachments are confidential and may =
also be privileged. If you are not the intended recipient, please notify th=
e sender immediately and do not
 disclose the contents to any other person, use it for any purpose, or stor=
e or copy the information in any medium. Thank you.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000d35f00059c0f941a--


From nobody Mon Jan 13 17:48: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 F0799120091 for ; Mon, 13 Jan 2020 17:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6soQdn5UXzTI for ; Mon, 13 Jan 2020 17:48:22 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650099.outbound.protection.outlook.com [40.107.65.99]) (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 6C9EE120026 for ; Mon, 13 Jan 2020 17:48:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U9EZdsTZO4mE8G+QKyO22MYyrWRSs+2Ror0BWJVZay5yYhVfXhMwSY8soV8AOEWcM+z26ls3rP2z8OMpipDlH4lHEjNka/hJGnBhLo4tEshyUbOzDc9ofrUAv2UZcPcrZ+vCyQri5UI+NOgAScqJWwQYf2PLoNu1ytG08NXG1f/bsIyKhEg0+CT8f9AZz4S4SW/PB4+yE3AxqWrxalWC+6afOaMjnsQv/y5LJVrk+T2gF1RYtm0nQYotUuC1cvFKDpqK2aaffaRw9MypNuYCwqWziJRpAi691EawXHyUEEx+CzqvP5kkBYgtRR40rjZMRkuQMBGQ0zOiaHDGvWK46g==
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=06j0GcTt5CMD4jsamdPatUHiH07VBMPmuljdCD239GU=; b=klIkm9+tYVpjKkxnFg4a9FBSSMMJ4oJxnIEI7I/OodFz/2eeISKVmbPqANfJYM5LKdzWvgvOD0pfJHQdCrc45+p1360ogwLl7OdAFKzF4A0nPwXTn8qe7TnKFToplTvE/iZJIhEjp2p1iQlLj5iaCYmyRqPyiQJM5jOgjvhy/3KSF6mCw2vsCgPQRko1QukIwzqZSl2FwH4K4xhfSmyNc3SoIWtVGZj80wI0oHAjfbO4UYoEVQCxfEJNcuZXAYih3Nv6J9KVqXS24/qVZXU91sKTubXI1PPQ8dpBYEC95/Or0qdt9eKbYtxrCeVgllq5cKXl5cQVrgwondSuWA9v9g==
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=06j0GcTt5CMD4jsamdPatUHiH07VBMPmuljdCD239GU=; b=Se6ztqng9WBMmhPXBQPJY8p20lhBpPNSFIuoIY5CYFICn7eofy+gPkhTKa0f1pQvBw797u2RIboibrX3xIKlZ43e5vjrCRBb5f/x9xzKcZMeQprhKp/IVk/NfMMSnXy8+7M1f0KJ/vLVViRbPdbKGE6DFYREeaPUuceDf40FJ5U=
Received: from CH2PR00MB0843.namprd00.prod.outlook.com (10.186.139.150) by CH2PR00MB0762.namprd00.prod.outlook.com (10.186.136.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2678.0; Tue, 14 Jan 2020 01:48:20 +0000
Received: from CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::417a:ede3:355:587]) by CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::417a:ede3:355:587%4]) with mapi id 15.20.2678.000; Tue, 14 Jan 2020 01:48:19 +0000
From: Mike Jones 
To: Dick Hardt , Torsten Lodderstedt , Brian Campbell , Justin Richer 
CC: "oauth@ietf.org" 
Thread-Topic: [EXTERNAL] [OAUTH-WG] RAR & multiple resources?
Thread-Index: AQHVynppk5DfJJ6bUEywx9EBFjubAKfpZAZA
Date: Tue, 14 Jan 2020 01:48:19 +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=68f549cb-81f6-4730-9093-000056f84f5e; 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-01-14T01:46:51Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.92.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c4edb55f-3b65-4fab-636a-08d79893d4f6
x-ms-traffictypediagnostic: CH2PR00MB0762:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(136003)(366004)(346002)(39860400002)(396003)(199004)(189003)(55016002)(64756008)(81166006)(5660300002)(8990500004)(6506007)(9686003)(53546011)(52536014)(4744005)(26005)(81156014)(66556008)(66476007)(8936002)(8676002)(66946007)(66446008)(76116006)(33656002)(2906002)(110136005)(4326008)(10290500003)(86362001)(316002)(478600001)(186003)(71200400001)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0762; H:CH2PR00MB0843.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H2MCmLGDptusPyhbDM9bSeScmqSJwh0n7RrdIfGI0crySL1Zplt1pNcIzDbUTnvjkah0JGkNn9DBhr3bvu06KwsF0wnaTx6hO9aRyxs2Sz1sc6OarzDtYhWfNf+FMlRlbUR/guO86bRlYivJJ1i6wEXgdRc/lN1T0plWXzPOjEoLmPbKYwT65YPHrn1tylmNsUcp8NTy3NPSKIuQiRPBnuN8s6MpFkm8fgorFxJm+CKXsp6eZZ2kmP6XpwhEM4GYfzuu5gCaPmPpMghrNdrjf8lRmOR/QDz16NNTX78R+nNxXfUp4OuCuk4G5uzEllzbQRtUTHXzBOphOaUJZbAEDUQqNOM4qPE5OFYg4gwZTy2AT/kc8cm7GEsnMQN9RcI66hRsQ0/oBVv8O/uDRcczdFIDkdxwPZkMG8/kk+H0/k5hPzO5CO0aflV1t8Z+4nal
x-ms-exchange-antispam-messagedata: Msu8Vr6pMATbWFnJqMsDh+qINH9TYKnfkisNjQiAFzsrC0IxX6ewye0QC+9nGg6L9ryB0SQWLpM0+3PrIKcPWPsPfCn8vcIHV1PfY19pdU3Fdyf+7f/fP4ahcW34DC9CYBHhd9KuVQfW6+uDg9Mtew==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB08433246E309260C650727C1F5340CH2PR00MB0843namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4edb55f-3b65-4fab-636a-08d79893d4f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 01:48:19.6088 (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: 1q6uLzU5WNMZTd3QxSrkidMjqYx4EBZvwVWzchuROlt35PnOyf9GJMPNbK6hcYxECnOFI2GZjwreEyebwtjmwg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL]  RAR & multiple resources?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 01:48:25 -0000

--_000_CH2PR00MB08433246E309260C650727C1F5340CH2PR00MB0843namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGxlYXNlIGRvbuKAmXQgdXNlIFJBUiBhcyBhIHBhbmRvcmHigJlzIGJveCB0byBpbnRyb2R1Y2Ug
dW5yZWxhdGVkIG5ldyBzZW1hbnRpY3MsIGluY2x1ZGluZyBpc3N1aW5nIG11bHRpcGxlIGFjY2Vz
cyB0b2tlbnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn
PiBPbiBCZWhhbGYgT2YgRGljayBIYXJkdA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDEzLCAyMDIw
IDU6MzIgUE0NClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l
dD47IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IEp1c3RpbiBS
aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW0VY
VEVSTkFMXSBbT0FVVEgtV0ddIFJBUiAmIG11bHRpcGxlIHJlc291cmNlcz8NCg0KVG9yc3RlbiAv
IEp1c3RpbiAvIEJyaWFuDQoNCkluIG15IHJlYWRpbmcgb2YgdGhlIElELCBpdCBhcHBlYXJzIHRo
YXQgdGhlcmUgaXMgYSByZXF1ZXN0IGZvciBqdXN0IG9uZSBhY2Nlc3MgdG9rZW4sIGFuZCB0aGUg
YXV0aG9yaXphdGlvbl9kZXRhaWxzIGFycmF5IGxpc3RzIG9uZSBvciBtb3JlIHJlc291cmNlcyB0
aGF0IHRoZSBvbmUgYWNjZXNzIHRva2VuIHdpbGwgcHJvdmlkZSBhY2Nlc3MgdG8uIENvcnJlY3Q/
DQoNCkkgaGF2ZSBoZWFyZCBhbmVjZG90YWxseSB0aGF0IHRoZXJlIGlzIGludGVyZXN0IGluIGdy
YW50aW5nIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMsIGFuZCBoYXZpbmcgbXVsdGlwbGUg
YWNjZXNzIHRva2Vucywgd2hpY2ggd291bGQgZW5hYmxlIGRpZmZlcmVudCBjb21wb25lbnRzIG9m
IGEgY2xpZW50IHRvIGhhdmUgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMuDQoNCkRvIHlvdSBjb25z
aWRlciBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIG91dCBvZiBzY29wZSBvZiBSQVI/DQoNCi9EaWNr
DQo=

--_000_CH2PR00MB08433246E309260C650727C1F5340CH2PR00MB0843namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QbGVhc2Ug
ZG9u4oCZdCB1c2UgUkFSIGFzIGEgcGFuZG9yYeKAmXMgYm94IHRvIGludHJvZHVjZSB1bnJlbGF0
ZWQgbmV3IHNlbWFudGljcywgaW5jbHVkaW5nIGlzc3VpbmcgbXVsdGlwbGUgYWNjZXNzIHRva2Vu
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0
aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRp
Y2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDEzLCAyMDIwIDU6MzIg
UE08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0Jmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHku
Y29tJmd0OzsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkNj
OjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBbT0FV
VEgtV0ddIFJBUiAmYW1wOyBtdWx0aXBsZSByZXNvdXJjZXM/PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvcnN0ZW4gLyBKdXN0aW4gLyBCcmlhbjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSByZWFk
aW5nIG9mIHRoZSBJRCwgaXQgYXBwZWFycyB0aGF0IHRoZXJlIGlzIGEgcmVxdWVzdCBmb3IganVz
dCBvbmUgYWNjZXNzIHRva2VuLCBhbmQgdGhlIGF1dGhvcml6YXRpb25fZGV0YWlscyBhcnJheSZu
YnNwO2xpc3RzIG9uZSBvciBtb3JlIHJlc291cmNlcyB0aGF0IHRoZSBvbmUgYWNjZXNzIHRva2Vu
IHdpbGwgcHJvdmlkZSBhY2Nlc3MgdG8uIENvcnJlY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBoZWFyZCBhbmVjZG90YWxseSB0
aGF0IHRoZXJlIGlzIGludGVyZXN0IGluIGdyYW50aW5nIGFjY2VzcyB0byBtdWx0aXBsZSZuYnNw
O3Jlc291cmNlcywgYW5kIGhhdmluZyBtdWx0aXBsZSZuYnNwO2FjY2VzcyB0b2tlbnMsIHdoaWNo
IHdvdWxkIGVuYWJsZSBkaWZmZXJlbnQgY29tcG9uZW50cyBvZiBhIGNsaWVudCB0byBoYXZlIGRp
ZmZlcmVudCBhY2Nlc3MgdG9rZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgY29uc2lkZXIgbXVsdGlwbGUgYWNjZXNz
IHRva2VucyBvdXQgb2Ygc2NvcGUgb2YgUkFSPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CH2PR00MB08433246E309260C650727C1F5340CH2PR00MB0843namp_--


From nobody Mon Jan 13 18:09: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 63441120026 for ; Mon, 13 Jan 2020 18:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.799
X-Spam-Level: 
X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDRh4aZQQw3r for ; Mon, 13 Jan 2020 18:09:45 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 57E27120048 for ; Mon, 13 Jan 2020 18:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578967786; x=1610503786; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GXFl1BFKThUtMSgLY5eS5UrsxH2OM1IrQzl+jSm3t8Y=; b=DLfpti1Epr3ZppyeZOKzuOmRjGyhcUxAaAxNAyBVJLFrnJcY32K5Hfz9 l/uomGKSMSmKGQvKwmNAB2pIxSbwmI/Zj9L19QGylblZDpyHX0Clngz4g XMDcTk/ch0L97IAFoNxrlHVh9vFbLekU3yHHxt4VKMGR3ZlBBJu75qsdU I=;
IronPort-SDR: Tz8eS/ijdYUx4DdhC+ZdIyZ7CvDP4QzNYBrYEp60EIQFpX85I6GOJbXgI4pH8AW9FPjuhLyQ95 cgEpH6o2rSgw==
X-IronPort-AV: E=Sophos; i="5.69,431,1571702400"; d="scan'208,217"; a="12828599"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 14 Jan 2020 02:09:36 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS id 3BE34A2122; Tue, 14 Jan 2020 02:09:35 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 02:09:34 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 02:09:34 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 14 Jan 2020 02:09:34 +0000
From: "Richard Backman, Annabelle" 
To: Mike Jones , Dick Hardt , Torsten Lodderstedt , "Brian Campbell" , Justin Richer 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] [EXTERNAL]  RAR & multiple resources?
Thread-Index: AQHVynzVrMmun4veJUOgrsyG+tQzM6fo5D4A
Date: Tue, 14 Jan 2020 02:09:34 +0000
Message-ID: <52ED8810-3FFF-4512-BB36-B80D93033FFD@amazon.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.95]
Content-Type: multipart/alternative; boundary="_000_52ED88103FFF4512BB36B80D93033FFDamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL]  RAR & multiple resources?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 02:09:49 -0000

--_000_52ED88103FFF4512BB36B80D93033FFDamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzEgdG8gTWlrZeKAmXMgY29tbWVudC4gVGhlc2UgYXJlIGluZGVwZW5kZW50IGlzc3Vlczsgb25l
IGNvdWxkIHVzZSBSQVIgd2l0aCBvbmUgYWNjZXNzIHRva2VuIG9yIG11bHRpcGxlIGFjY2VzcyB0
b2tlbnMsIGFuZCBvbmUgY291bGQgdXNlIG11bHRpcGxlIGFjY2VzcyB0b2tlbnMgd2l0aCBvciB3
aXRob3V0IFJBUi4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRp
dHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m
IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn
Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDEzLCAyMDIwIGF0IDU6NDkgUE0NClRvOiBEaWNrIEhh
cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0PiwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHku
Y29tPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6ICJvYXV0aEBpZXRmLm9y
ZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW0VYVEVSTkFMXSBS
QVIgJiBtdWx0aXBsZSByZXNvdXJjZXM/DQoNClBsZWFzZSBkb27igJl0IHVzZSBSQVIgYXMgYSBw
YW5kb3Jh4oCZcyBib3ggdG8gaW50cm9kdWNlIHVucmVsYXRlZCBuZXcgc2VtYW50aWNzLCBpbmNs
dWRpbmcgaXNzdWluZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBP
QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNl
bnQ6IE1vbmRheSwgSmFudWFyeSAxMywgMjAyMCA1OjMyIFBNDQpUbzogVG9yc3RlbiBMb2RkZXJz
dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb20+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpDYzog
b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gW09BVVRILVdHXSBSQVIgJiBtdWx0
aXBsZSByZXNvdXJjZXM/DQoNClRvcnN0ZW4gLyBKdXN0aW4gLyBCcmlhbg0KDQpJbiBteSByZWFk
aW5nIG9mIHRoZSBJRCwgaXQgYXBwZWFycyB0aGF0IHRoZXJlIGlzIGEgcmVxdWVzdCBmb3IganVz
dCBvbmUgYWNjZXNzIHRva2VuLCBhbmQgdGhlIGF1dGhvcml6YXRpb25fZGV0YWlscyBhcnJheSBs
aXN0cyBvbmUgb3IgbW9yZSByZXNvdXJjZXMgdGhhdCB0aGUgb25lIGFjY2VzcyB0b2tlbiB3aWxs
IHByb3ZpZGUgYWNjZXNzIHRvLiBDb3JyZWN0Pw0KDQpJIGhhdmUgaGVhcmQgYW5lY2RvdGFsbHkg
dGhhdCB0aGVyZSBpcyBpbnRlcmVzdCBpbiBncmFudGluZyBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVz
b3VyY2VzLCBhbmQgaGF2aW5nIG11bHRpcGxlIGFjY2VzcyB0b2tlbnMsIHdoaWNoIHdvdWxkIGVu
YWJsZSBkaWZmZXJlbnQgY29tcG9uZW50cyBvZiBhIGNsaWVudCB0byBoYXZlIGRpZmZlcmVudCBh
Y2Nlc3MgdG9rZW5zLg0KDQpEbyB5b3UgY29uc2lkZXIgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBv
dXQgb2Ygc2NvcGUgb2YgUkFSPw0KDQovRGljaw0K

--_000_52ED88103FFF4512BB36B80D93033FFDamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <8A266CD1B6DEE44AB1E4355D3928B28A@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNg0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRvIE1pa2XigJlz
IGNvbW1lbnQuIFRoZXNlIGFyZSBpbmRlcGVuZGVudCBpc3N1ZXM7IG9uZSBjb3VsZCB1c2UgUkFS
IHdpdGggb25lIGFjY2VzcyB0b2tlbiBvciBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLCBhbmQgb25l
IGNvdWxkIHVzZSBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIHdpdGggb3Igd2l0aG91dCBSQVIuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBv
biBiZWhhbGYgb2YgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A
ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAxMywg
MjAyMCBhdCA1OjQ5IFBNPGJyPg0KPGI+VG86IDwvYj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0
QGdtYWlsLmNvbSZndDssIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3Rl
ZHQubmV0Jmd0OywgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t
Jmd0OywgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkNjOiA8
L2I+JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4N
CjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBbRVhURVJOQUxdIFJBUiAmYW1wOyBtdWx0
aXBsZSByZXNvdXJjZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QbGVhc2UgZG9u4oCZdCB1
c2UgUkFSIGFzIGEgcGFuZG9yYeKAmXMgYm94IHRvIGludHJvZHVjZSB1bnJlbGF0ZWQgbmV3IHNl
bWFudGljcywgaW5jbHVkaW5nIGlzc3VpbmcgbXVsdGlwbGUgYWNjZXNzIHRva2Vucy48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1
dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRpY2sgSGFyZHQ8
YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDEzLCAyMDIwIDU6MzIgUE08YnI+DQo8
Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0
Jmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0Ozsg
SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1
dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBbT0FVVEgtV0ddIFJB
UiAmYW1wOyBtdWx0aXBsZSByZXNvdXJjZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRvcnN0ZW4gLyBKdXN0aW4gLyBCcmlhbjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSByZWFkaW5nIG9mIHRo
ZSBJRCwgaXQgYXBwZWFycyB0aGF0IHRoZXJlIGlzIGEgcmVxdWVzdCBmb3IganVzdCBvbmUgYWNj
ZXNzIHRva2VuLCBhbmQgdGhlIGF1dGhvcml6YXRpb25fZGV0YWlscyBhcnJheSZuYnNwO2xpc3Rz
IG9uZSBvciBtb3JlIHJlc291cmNlcyB0aGF0IHRoZSBvbmUgYWNjZXNzIHRva2VuIHdpbGwgcHJv
dmlkZSBhY2Nlc3MgdG8uIENvcnJlY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBoZWFyZCBhbmVjZG90YWxseSB0aGF0IHRoZXJl
IGlzIGludGVyZXN0IGluIGdyYW50aW5nIGFjY2VzcyB0byBtdWx0aXBsZSZuYnNwO3Jlc291cmNl
cywgYW5kIGhhdmluZyBtdWx0aXBsZSZuYnNwO2FjY2VzcyB0b2tlbnMsIHdoaWNoIHdvdWxkIGVu
YWJsZSBkaWZmZXJlbnQgY29tcG9uZW50cyBvZiBhIGNsaWVudCB0byBoYXZlIGRpZmZlcmVudCBh
Y2Nlc3MgdG9rZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgY29uc2lkZXIgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBv
dXQgb2Ygc2NvcGUgb2YgUkFSPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_52ED88103FFF4512BB36B80D93033FFDamazoncom_--


From nobody Mon Jan 13 18:20: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 7370512006B for ; Mon, 13 Jan 2020 18:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4l6HUM2l8Ow for ; Mon, 13 Jan 2020 18:20:10 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BDF12001B for ; Mon, 13 Jan 2020 18:20:09 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00E2K6GP030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 21:20:07 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 13 Jan 2020 21:20:06 -0500
Cc: Torsten Lodderstedt , Brian Campbell , oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <11D44A57-1255-4DDB-807E-7E2DE7A47B74@mit.edu>
References: 
To: Dick Hardt 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] RAR & multiple resources?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 02:20:11 -0000

Multiple access tokens are outside the scope of RAR. The request is =
intended to describe the access for a single returned access token. If =
semantics for multiple access tokens are agreed upon, then it can use =
the RAR structure, the Resources parameter, and the Scope parameter all =
in parallel again.

 =E2=80=94 Justin

> On Jan 13, 2020, at 8:31 PM, Dick Hardt  wrote:
>=20
> Torsten / Justin / Brian
>=20
> In my reading of the ID, it appears that there is a request for just =
one access token, and the authorization_details array lists one or more =
resources that the one access token will provide access to. Correct?
>=20
> I have heard anecdotally that there is interest in granting access to =
multiple resources, and having multiple access tokens, which would =
enable different components of a client to have different access tokens.=20=

>=20
> Do you consider multiple access tokens out of scope of RAR?
>=20
> /Dick


From nobody Mon Jan 13 18:26: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 44A3712006F for ; Mon, 13 Jan 2020 18:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzvU5wNmbVOr for ; Mon, 13 Jan 2020 18:25:58 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B196C12001B for ; Mon, 13 Jan 2020 18:25:57 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00E2Pqou032193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 21:25:53 -0500
From: Justin Richer 
Message-Id: <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_47704DC5-A6BB-4DF8-B2E2-344F3A93A401"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 13 Jan 2020 21:25:52 -0500
In-Reply-To: 
Cc: Neil Madden , oauth , Mike Jones , "Richard Backman, Annabelle" 
To: Dick Hardt 
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com> 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 02:25:59 -0000

--Apple-Mail=_47704DC5-A6BB-4DF8-B2E2-344F3A93A401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I would rather see extensions define a key ID than a new key set URI. =
Otherwise what=E2=80=99s the point of having more than one key in the =
set, with unique identifiers?

It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on a =
URL-based addressing format for individual keys within the set, but that =
ship=E2=80=99s sailed.

 =E2=80=94 Justin

> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
>=20
> I was not saying that there was anything special about keys, nor that =
we needed to change OAuth.
>=20
> While using one key and controlling where it us used via access =
control works, it is not ideal.
>=20
> OAuth could have had just one endpoint, and done access control for =
different roles -- but it did not. We enabled flexibility by separating =
the authorization endpoint and the token endpoint. The dynamic client =
registration extension defined a new endpoint, the registration =
endpoint.
>=20
> I don't think we can change what has been deployed today -- but NEW =
extensions that use keys for new purposes SHOULD define their own URI.
> =E1=90=A7
>=20
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden =
> wrote:
> Sure, but we know how to run resilient services. My point is that =
there=E2=80=99s nothing particularly special about cryptographic keys: =
if you want to control how they are used there is a whole range of =
normal access control methods you can apply to them without needing to =
change anything in OAuth.=20
>=20
> Neil
>=20
>> On 10 Jan 2020, at 18:50, Dick Hardt > wrote:
>>=20
>> =EF=BB=BF
>> There are many other factors to resiliency than multiple instances.=20=

>>=20
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden =
> wrote:
>>=20
>>=20
>> > On 10 Jan 2020, at 17:22, Dick Hardt > wrote:
>> [...]
>> >=20
>> > =EF=BB=BFAs to the suggestion of using a =
JWT-decryption-microservice, another goal would be increased resiliency =
of the components. If the JWT-decryption-microservice is unavailable, =
the whole system is unavailable. If there are separate keys, then a =
failure in one component does not fail the entire system.=20
>>=20
>> Well you can run more than one instance - it=E2=80=99s a completely =
stateless service. You can also run a separate instance (or set of =
instances) per key if you like.=20
>>=20
>> Neil


--Apple-Mail=_47704DC5-A6BB-4DF8-B2E2-344F3A93A401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
would rather see extensions define a key ID than a new key set URI. =
Otherwise what=E2=80=99s the point of having more than one key in the =
set, with unique identifiers?

It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed =
on a URL-based addressing format for individual keys within the set, but =
that ship=E2=80=99s sailed.

 =E2=80=94 Justin

On Jan 10, 2020, at 9:34 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I was not saying that there was =
anything special about keys, nor that we needed to change OAuth.

While using one key and =
controlling where it us used via access control works, it is not =
ideal.

OAuth =
could have had just one endpoint, and done access control for different =
roles -- but it did not. We enabled flexibility by separating the =
authorization endpoint and the token endpoint. The dynamic client =
registration extension defined a new endpoint, the registration =
endpoint.

I =
don't think we can change what has been deployed today -- but NEW =
extensions that use keys for new purposes SHOULD define their own =
URI.
3D""=E1=90=A7

On Fri, Jan =
10, 2020 at 11:31 AM Neil Madden <neil.madden@forgerock.com> wrote:
Sure, but we know how to run resilient services. =
My point is that there=E2=80=99s nothing particularly special about =
cryptographic keys: if you want to control how they are used there is a =
whole range of normal access control methods you can apply to them =
without needing to change anything in OAuth. 

Neil

On 10 Jan 2020, at 18:50, Dick Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
There are =
many other factors to resiliency than multiple instances. 

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <neil.madden@forgerock.com> wrote:




> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com> wrote:

[...]

> 

> =EF=BB=BFAs to the suggestion of using a =
JWT-decryption-microservice, another goal would be increased resiliency =
of the components. If the JWT-decryption-microservice is unavailable, =
the whole system is unavailable. If there are separate keys, then a =
failure in one component does not fail the entire system. 



Well you can run more than one instance - it=E2=80=99s a completely =
stateless service. You can also run a separate instance (or set of =
instances) per key if you like. 



Neil





=

--Apple-Mail=_47704DC5-A6BB-4DF8-B2E2-344F3A93A401--


From nobody Mon Jan 13 18:38: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 B6D4012006F for ; Mon, 13 Jan 2020 18:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RT4Hdkd_8wDc for ; Mon, 13 Jan 2020 18:38:56 -0800 (PST)
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 D002112006B for ; Mon, 13 Jan 2020 18:38:55 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id t26so12141403ioi.13 for ; Mon, 13 Jan 2020 18:38:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bfur3aPnu2Vjhbj5Vn5DIWwR/isw4PQknA8aDur4w8Q=; b=JvwCzPp3KY1dJa8n9+FofPDW7uflBxTrQimWg4wDqQzIQxIDS0m1zh3tYCDbF4ocUt jagejNRg+kze4yp2Xg1n+GXev8rbj49i3waOQNH+xuHc4lIz6WKz6DBvEJKbDOTt6GjN NCv8DYFHsAqNs6O6HibkYSzQHKSjQZb/oNweDDzSVDQKp1qNG+iCt0qamcxKrIyQNTeN 1ScSb/nwgvA6I1zAbsdB4zmAsaPd6V9EZG2+abr5WST66obZl7WbytEZAzZeysLOMwQ+ 7U8ukQJ2uwkDv4YaADyDycpZHpFkypo49Oxr1T5RmZ6ancTenpSLR/Mop5QV6As7jDp6 /BLQ==
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=Bfur3aPnu2Vjhbj5Vn5DIWwR/isw4PQknA8aDur4w8Q=; b=rYblDbrWH9WSquaz06x2V8M0PuIf0brk0IZvzCBuwc9H9v+UcCDMQDSB3SVTHlVAtY UbmDb915wDTNYzFtPMNGt/QiDfpeuY9Mo5htVh4urmetB5JvvgIahibjXt93LfG4K8l6 2Pt95alX83etXqSdq9V8HbzcJ3rUqQF4c1B/7Zcj73BLuqHnzi0CP4C1gZLnI8hJILYt xBqhY9vijYJzIXw/0bEGMFVnlOSEc3daOG0dZeN8I+pb9x+VGBtlmKrZ0btpO6itUszB ftnw1KaFKCRIbiarYaL8JUyIP/yhAkhyv2/6s6tkq9dZh1O0MmWrR/vYw3H/XDOamteS FaQQ==
X-Gm-Message-State: APjAAAV8yBx5z13gYWJ9D2W8sRTOLkRmoDCtFVrYEJhTKcbK6cY0Itdk zvDgBB+M+OkZipEnUUc8fTVIMhUU0cA=
X-Google-Smtp-Source: APXvYqwlAWDoj9OnS24Ri0uxQ9WisEmSGYlnotNOR03OYkCPAH6sWEXlyXcbAra+8UBo9bARLvK8Zg==
X-Received: by 2002:a5d:964e:: with SMTP id d14mr14935862ios.193.1578969534696;  Mon, 13 Jan 2020 18:38:54 -0800 (PST)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id w11sm4445420ilh.55.2020.01.13.18.38.53 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jan 2020 18:38:53 -0800 (PST)
Received: by mail-io1-f45.google.com with SMTP id h8so12185942iob.2 for ; Mon, 13 Jan 2020 18:38:53 -0800 (PST)
X-Received: by 2002:a05:6602:2345:: with SMTP id r5mr14248398iot.156.1578969533709;  Mon, 13 Jan 2020 18:38:53 -0800 (PST)
MIME-Version: 1.0
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu>
In-Reply-To: <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu>
From: Aaron Parecki 
Date: Mon, 13 Jan 2020 18:38:42 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Justin Richer 
Cc: Dick Hardt ,  Mike Jones ,  "Richard Backman, Annabelle" , oauth 
Content-Type: multipart/alternative; boundary="0000000000002b0579059c107ed5"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 02:38:58 -0000

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

Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be
fine to include additional keys that are used for something other than
access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a
decent extension mechanism.



On Mon, Jan 13, 2020 at 6:26 PM Justin Richer  wrote:

> I would rather see extensions define a key ID than a new key set URI.
> Otherwise what=E2=80=99s the point of having more than one key in the set=
, with
> unique identifiers?
>
> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on a URL-bas=
ed addressing
> format for individual keys within the set, but that ship=E2=80=99s sailed=
.
>
>
>  =E2=80=94 Justin
>
> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
>
> I was not saying that there was anything special about keys, nor that we
> needed to change OAuth.
>
> While using one key and controlling where it us used via access control
> works, it is not ideal.
>
> OAuth could have had just one endpoint, and done access control for
> different roles -- but it did not. We enabled flexibility by separating t=
he
> authorization endpoint and the token endpoint. The dynamic client
> registration extension defined a new endpoint, the registration endpoint.
>
> I don't think we can change what has been deployed today -- but NEW
> extensions that use keys for new purposes SHOULD define their own URI.
> =E1=90=A7
>
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden 
> wrote:
>
>> Sure, but we know how to run resilient services. My point is that there=
=E2=80=99s
>> nothing particularly special about cryptographic keys: if you want to
>> control how they are used there is a whole range of normal access contro=
l
>> methods you can apply to them without needing to change anything in OAut=
h.
>>
>> Neil
>>
>> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>>
>> =EF=BB=BF
>> There are many other factors to resiliency than multiple instances.
>>
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
>> wrote:
>>
>>>
>>>
>>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>>> [...]
>>> >
>>> > =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice,=
 another
>>> goal would be increased resiliency of the components. If the
>>> JWT-decryption-microservice is unavailable, the whole system is
>>> unavailable. If there are separate keys, then a failure in one componen=
t
>>> does not fail the entire system.
>>>
>>> Well you can run more than one instance - it=E2=80=99s a completely sta=
teless
>>> service. You can also run a separate instance (or set of instances) per=
 key
>>> if you like.
>>>
>>> Neil
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
----
Aaron Parecki
aaronparecki.com
@aaronpk 

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


Right now, Okta publishes two keys at the jwks_uri i=
n order to be able to rotate keys periodically. During the token lifetime w=
indow during key rotation, the RSs can still find both the old and new key =
IDs in the set.

RS=
s are looking for a specific key ID when they do this, so it would be fine =
to include additional keys that are used for something other than access to=
kens since the RSs would just ignore them.

So an extension could say "use this key identified =
by kid" and that'd be a decent extension mechanism.=C2=A0



On Mon, Jan 13, 2020 at=
 6:26 PM Justin Richer <jricher@mit.e=
du> wrote:
I would rather see extensio=
ns define a key ID than a new key set URI. Otherwise what=E2=80=99s the poi=
nt of having more than one key in the set, with unique identifiers?
It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on=
 a URL-based addressing format for individual keys within the set, but that=
 ship=E2=80=99s sailed.


=C2=A0=E2=80=94 Justi=
n

On Jan 10, 2020, at 9:34 PM, D=
ick Hardt <dic=
k.hardt@gmail.com> wrote:

I was not s=
aying that there was anything special about keys, nor that we needed to cha=
nge OAuth.

While using one key and controlling where it =
us used via access control works, it is not ideal.

OAuth could have had just one endpoint, and done access control for differ=
ent roles -- but it did not. We enabled flexibility by separating the autho=
rization endpoint and the token endpoint. The dynamic client registration e=
xtension defined a new endpoint, the registration endpoint.

<=
/div>
I don't think we can change what has been deployed today -- b=
ut NEW extensions that use keys for new purposes SHOULD define their own UR=
I.
3D""=E1=90=A7

On Fri, Jan 10, 2020 at 11:31 AM Ne=
il Madden <neil.madden@forgerock.com> wrote:
Sure, but we =
know how to run resilient services. My point is that there=E2=80=99s nothin=
g particularly special about cryptographic keys: if you want to control how=
 they are used there is a whole range of normal access control methods you =
can apply to them without needing to change anything in OAuth.=C2=A0
<=
div dir=3D"ltr">
Neil

<=
blockquote type=3D"cite">On 10 Jan 2020, at 18:50, Dick Hardt <dick.hardt@gmail.com=
> wrote:

=EF=BB=BF
There are many other factors to resiliency =
than multiple instances.=C2=A0

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden =
<neil.mad=
den@forgerock.com> wrote:




> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com> wrote:

[...]

> 

> =EF=BB=BFAs to the suggestion of using a JWT-decryption-microservice, =
another goal would be increased resiliency of the components. If the JWT-de=
cryption-microservice is unavailable, the whole system is unavailable. If t=
here are separate keys, then a failure in one component does not fail the e=
ntire system. 



Well you can run more than one instance - it=E2=80=99s a completely statele=
ss service. You can also run a separate instance (or set of instances) per =
key if you like. 



Neil





____________________________=
___________________

OAuth mailing list

OAuth@ietf.org

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

-- 
----
Aaron Parecki
<=
div>aaronparecki.com<=
/a>



--0000000000002b0579059c107ed5--


From nobody Mon Jan 13 20: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 E5B1A12006E for ; Mon, 13 Jan 2020 20:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 gfzr8FcTn1gu for ; Mon, 13 Jan 2020 20:46:37 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69E1120026 for ; Mon, 13 Jan 2020 20:46:36 -0800 (PST)
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 00E4kSTa031876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 23:46:30 -0500
Date: Mon, 13 Jan 2020 20:46:27 -0800
From: Benjamin Kaduk 
To: Justin Richer 
Cc: Vladimir Dzhuvinov , oauth , Nat Sakimura , "Richard Backman, Annabelle" 
Message-ID: <20200114044627.GM66991@kduck.mit.edu>
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@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] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 04:46:38 -0000

On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree that we shouldn’t specify that “it’s a JWT” or something of that nature. But if we call the result of PAR “thing X” and the target of request_uri “thing X” in JAR, then we’re compatible without saying what “thing X” needs to be in all cases. 
> 

That seems fair.  What properties would a given "thing X" need to have in
order to work, though -- uniqueness over a specific period of time?
Unpredictability?  More?

-Ben


From nobody Mon Jan 13 21:09: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 B4C9D12001E for ; Mon, 13 Jan 2020 21:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogXltN10ZnaF for ; Mon, 13 Jan 2020 21:08:58 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E505A120019 for ; Mon, 13 Jan 2020 21:08:57 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id z22so12805658ljg.1 for ; Mon, 13 Jan 2020 21:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ny8mABINk+9UjwvwgenYI44Jhxdtym//dXEw0XYWFJk=; b=actxzOGujXZOARreT2FPK97z4AdFBgrebw1iwJk4209zmMdBDjA/kp+wO3ZsMhZBpa EpnOZvCvA30t0Fk1KOkItq4YRHk54ViKgdyfrwOzsiTIhR6Fma/1h9I3dLHfhZRqMkt/ 1TQku6xfmBFA3aUwZTRXyUeDqKaDwNJlgUn7ePMGykNscnUUhXRPb291LrFyZNpO8R9l yOy/Sk7XZJ6SBw4QwBPZ+zjS1bBX9VyeNpY2nod2O1DY2XWknRKSuCRJmqF5OgV7Ag9H FAQ2Yy6kY/bi4kePMdozm0+5f3tO4Zt+NizTKj+Akoco/N2wGkYayerXSAWBB+xsCyZL mIaw==
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=Ny8mABINk+9UjwvwgenYI44Jhxdtym//dXEw0XYWFJk=; b=EoK3fe8FZS/fXLsKTNsut7mzl9mHH0Nx828OkIXdb9Gt1AET8EbLXhM3LFVJPgvFwn 79y/bJuKbCkkq/cJHLmxsRZ2JxGgaDZedrbNf3YIq+1KG8bTh4Xio1/4FRFU9BUJKrCh L5J5z9cjtOYpPqPMLzMh1muNSLmBy0XXnThXrqJvhR5TqUhGfzAacR23iZb3gvtpa0AL E6hvw09FlxaL0tQ2mleQMvAz3c2H9mr6QkYb2W+lMCYrqgkaIcK6X35Bl8BSLK4X1yF0 hwmlQWs9YeJhF3uPE0EzZNqXJDVo1EdgICtYYQWj1cofoXH0phRjdmClEtVSNAb1n5Xi Mn6Q==
X-Gm-Message-State: APjAAAWZtTK7nuYBZrOCJ7p6vFB4iqRYczo8exkfWheGDKrPsv64I3NU dXYxkBv3N4xqPudDfwBgjAZmDv+NCuNl64J956g=
X-Google-Smtp-Source: APXvYqxDwFwVgQbEwKU2fJ0paqVGU/HKi+P967pOF3QJKdzE617Wo+3HOG2UpwOyFyzBg9bFtjtNtYeNpecXjZ4z2LU=
X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr12971445ljk.15.1578978536205;  Mon, 13 Jan 2020 21:08:56 -0800 (PST)
MIME-Version: 1.0
References:  <11D44A57-1255-4DDB-807E-7E2DE7A47B74@mit.edu>
In-Reply-To: <11D44A57-1255-4DDB-807E-7E2DE7A47B74@mit.edu>
From: Dick Hardt 
Date: Mon, 13 Jan 2020 21:08:44 -0800
Message-ID: 
To: Justin Richer 
Cc: Brian Campbell ,  Torsten Lodderstedt , oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c23011059c1296c6"
Archived-At: 
Subject: Re: [OAUTH-WG] RAR & multiple resources?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 05:09:00 -0000

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

That=E2=80=99s what I thought. Thanks for the clarification.

On Mon, Jan 13, 2020 at 6:20 PM Justin Richer  wrote:

> Multiple access tokens are outside the scope of RAR. The request is
> intended to describe the access for a single returned access token. If
> semantics for multiple access tokens are agreed upon, then it can use the
> RAR structure, the Resources parameter, and the Scope parameter all in
> parallel again.
>
>  =E2=80=94 Justin
>
> > On Jan 13, 2020, at 8:31 PM, Dick Hardt  wrote:
> >
> > Torsten / Justin / Brian
> >
> > In my reading of the ID, it appears that there is a request for just on=
e
> access token, and the authorization_details array lists one or more
> resources that the one access token will provide access to. Correct?
> >
> > I have heard anecdotally that there is interest in granting access to
> multiple resources, and having multiple access tokens, which would enable
> different components of a client to have different access tokens.
> >
> > Do you consider multiple access tokens out of scope of RAR?
> >
> > /Dick
>
>

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


That=E2=80=99s what I thought. Thanks for the clarif=
ication.

On Mon, Jan 13, 2020 at 6:20 PM Justin Richer <jricher@mit.edu> wrote:
Multiple access tokens are outside the scope of RA=
R. The request is intended to describe the access for a single returned acc=
ess token. If semantics for multiple access tokens are agreed upon, then it=
 can use the RAR structure, the Resources parameter, and the Scope paramete=
r all in parallel again.



=C2=A0=E2=80=94 Justin



> On Jan 13, 2020, at 8:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> 

> Torsten / Justin / Brian

> 

> In my reading of the ID, it appears that there is a request for just o=
ne access token, and the authorization_details array lists one or more reso=
urces that the one access token will provide access to. Correct?

> 

> I have heard anecdotally that there is interest in granting access to =
multiple resources, and having multiple access tokens, which would enable d=
ifferent components of a client to have different access tokens. 

> 

> Do you consider multiple access tokens out of scope of RAR?

> 

> /Dick






--000000000000c23011059c1296c6--


From nobody Tue Jan 14 09:21:06 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 48981120A26 for ; Tue, 14 Jan 2020 09:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qU_yiZOnskEn for ; Tue, 14 Jan 2020 09:20:59 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA11120A47 for ; Tue, 14 Jan 2020 09:20:52 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id z7so12947874wrl.13 for ; Tue, 14 Jan 2020 09:20:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lVxyjtIAbRqyGY97ymZUlLHdtEy4u7ya4k/Y45qnvpo=; b=PZBVe7/+zIIz78Xobh+2RkNZjV+T95KtIbJKSUwrnd6AANH3F5U6N0x8pq0F7xjbHY HWNjtIx3X41ezPDf1MQbKlnjQqQOTYNvpA8GYGnqmjG+zDgwJWjw673yu1DfodTXEvfW 7OA5QBGqlBZyhkLJ2CEym+rxkT8M3CT/pdLH6NHgfIKLn4IO5Kku/2OC/R/piU4Vpv2T JW4HqeiQGhTTNsIJ9xVHWhejrmlJtfkc3dCdlAtB0mlgGZmPJDcrVSMRW9SlYj3rgvsm dZ9zfkMQK0JMB1nrhAmLlNgOfx4B/vwBXF4VrnDOzwSGytqmKVB5ZHQ2rqnLUM7oyVUG TKFA==
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=lVxyjtIAbRqyGY97ymZUlLHdtEy4u7ya4k/Y45qnvpo=; b=EPyA6HTn6w7IFK40Sl6uXzXjdIUKxspxemdBegz0G1DdzntdEdQALFaYHOgshfVkrE +AxwStkm23kNV3kq97EzCbmBTPZQF+F8rOtPbSToq0S9bPzRzZ5smytWGvykwsW23IM2 xJCmFe6iAYOGn4VyHf1M8jMN3wDM0MF6/LwW6+j09jwA+orfMaJAv6JsA/oPsRYGSEvU nopQmeDH1jr6nhq61V17h56aOQ5n/T5jjvhdwbfuDay7KwHixzL2FWYsnUKQWwjt5DX4 wLC0Yg+tFCmeNUlNijbW4tF3egeqNf7k+nBKcfCe0Ut2bHDA2vV/tOvdNpciaAZBuOiX J6IQ==
X-Gm-Message-State: APjAAAWtuslhIcqQnJxqzMMSBa8Ulq319YUB4IpgRHrdbgWgVnvQiCVx HxcQlRj12TLwPNfMUpo1PUZliHlUX+sqy0hrOE2atOODCgk=
X-Google-Smtp-Source: APXvYqzoju0I2rmR2Ebup0MSE6e11F7gHiRNUX2baxZLPVDdvN6bm1ES+VKPTfebx/H5OzmlGDbbHfWduRoqYS8AmjQ=
X-Received: by 2002:adf:8150:: with SMTP id 74mr27177410wrm.114.1579022450982;  Tue, 14 Jan 2020 09:20:50 -0800 (PST)
MIME-Version: 1.0
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>
In-Reply-To: <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>
From: Takahiko Kawasaki 
Date: Wed, 15 Jan 2020 02:20:39 +0900
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: John Bradley , Mike Jones , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000489442059c1cd054"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 14 Jan 2020 17:21:04 -0000

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

Well, embedding a client_id claim in the JWE header in order to achieve
"request parameters outside the request object should not be referred to"
is like "putting the cart before the horse". Why do we have to avoid using
the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1
 of RFC 6749 says as
follows.

*A client MAY use the "client_id" request parameter to identify itself when
sending requests to the token endpoint.  In the "authorization_code"
"grant_type" request to the token endpoint, an unauthenticated client MUST
send its "client_id" to prevent itself from inadvertently accepting a code
intended for a client with a different "client_id".  This protects the
client from substitution of the authentication code.  (It provides no
additional security for the protected resource.)*


If the same reasoning applies, a client_id must always be sent with request
/ request_uri because client authentication is not performed at the
authorization endpoint. In other words, *an unauthenticated client (every
client is unauthenticated at the authorization endpoint) MUST send its
"client_id" to prevent itself from inadvertently accepting a request object
for a client with a different "client_id".*

Best Regards,
Taka



On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
wrote:

> John, thanks, much appreciated!
> On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header.
>
> I will see if i can add something in final edits to call that out.
>
> John B.
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>
> Thanks Mike for the rfc7519 section-5.3
>  pointer. Can this
> parameter replication be used for client_id or the client_id ass "iss" ev=
en
> though it isn't explicitly mentioned in the JAR spec?
> On 11/01/2020 02:58, John Bradley wrote:
>
> Right we just don't say to put the iss there in OIDC if it's symetricly
> encrypted.
>
> OIDC doesn't have the symmetric key selection issue, I suppose that why
> the possibility to replicate params to the JWE header isn't mentioned at
> all. OIDC requires the top-level query params to represent a valid OAuth
> 2.0 request, and there client_id is required. If the client_id is present
> the client registration together with any present client_secret can be
> retrieved.
>
> I reread the JAR spec, this is the only place that mentions handling of
> symmetric JWE.
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>
>    (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.
>
>
> Vladimir
>
>
>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones 
> wrote:
>
>> The technique of replicating JWT claims that need to be publicly visible
>> in an encrypted JWT in the header is defined at
>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
>> for bringing this need to my attention as we were finishing the JWT spec=
.)
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * John Bradley
>> *Sent:* Friday, January 10, 2020 2:15 PM
>> *To:* Vladimir Dzhuvinov 
>> *Cc:* IETF oauth WG 
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request
>> (JAR) vs OIDC request object
>>
>>
>>
>> The intent was to do that, but specs change once the OAuth WG and IESG
>> get there hands on them.
>>
>>
>>
>> Being backwards compatible with OIDC is not a compelling argument to the
>> IESG.
>>
>>
>>
>> We were mostly thinking of asymmetric encryption.
>>
>>
>>
>> Specifying puting the issuer and or the audience in the headder has come
>> up in the past but probably is not documented.
>>
>>
>>
>> John B
>>
>>
>>
>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov 
>> wrote:
>>
>> Yes, putting the client_id into the JWE header is a way around the need
>> to have the client_id outside the JWE as top-level authZ request
>> parameter.
>>
>> Unfortunately this work around isn't mentioned anywhere, I just checked
>> the most recent draft-ietf-oauth-jwsreq-20.
>>
>> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
>> presence of client_id as top-level parameter, together with requiring
>> RPs to register their request_uri's (so that we don't need to build and
>> store an index of all request_uri's). I just had a look at "DDoS Attack
>> on the Authorization Server" and also realised the request_uri
>> registration isn't explicitly mentioned as attack prevention ("the
>> server should (a) check that the value of "request_uri" parameter does
>> not point to an unexpected location").
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>> 
>>
>> To be honest, I feel quite bad about the situation with JAR we are in
>> now. For some reason I had the impression that OAuth JAR was going to be
>> the OIDC request / request_uri for general OAuth 2.0 use, as with other
>> OIDC bits that later became general purpose OAuth 2.0 specs.
>>
>> I find it unfortunate I didn't notice this when I was reviewing the spec
>> in the past.
>>
>> Vladimir
>>
>>
>> On 10/01/2020 22:39, Filip Skokan wrote:
>> > Vladimir,
>> >
>> > For that very case the payload claims may be repeated in the JWE
>> protected header. An implementation wanting to handle this may look for
>> iss/client_id there.
>> >
>> > Odesl=C3=A1no z iPhonu
>> >
>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>> >>
>> >> =EF=BB=BFI just realised there is one class of JARs where it's practi=
ally
>> >> impossible to process the request if merge isn't supported:
>> >>
>> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allo=
ws
>> >> for that and specs a method for deriving the shared key from the
>> >> client_secret:
>> >>
>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>> 
>> >>
>> >> If the JAR is encrypted with the client_secret, and there is no
>> >> top-level client_id parameter, there's no good way for the OP to find
>> >> out which client_secret to get to try to decrypt the JWE. Unless the =
OP
>> >> keeps an index of all issued client_secret's.
>> >>
>> >>
>> >> OP servers which require request_uri registration
>> >> (require_request_uri_registration=3Dtrue) and don't want to index all
>> >> registered request_uri's, also have no good way to process a
>> request_uri
>> >> if the client_id isn't present as top-level parameter.
>> >>
>> >>
>> >> Vladimir
>> >>
>> >>
>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> >>>
>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>> >>>> I think Torsten is speculating that is not a feature people use.
>> >>> I=E2=80=99m still trying to understand the use case for merging sign=
ed and
>> unsigned parameters. Nat once explained a use case, where a client uses
>> parameters signed by a 3rd party (some =E2=80=9Ecertification authority=
=E2=80=9C) in
>> combination with transaction-specific parameters. Is this being done in =
the
>> wild?
>> >>>
>> >>> PS: PAR would work with both modes.
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://
>> 
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Best Regards,=

Taka



On Tue, Jan 14, 2020 at =
12:57 AM Vladimir Dzhuvinov <=
vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  

    
John, thanks, much appreciated!

    

    
On 11/01/2020 21:36, John Bradley
      wrote:

    

    

     =20
      
Yes JAR is not prohibiting paramater replication in the
        header.=C2=A0 

      

      
I will see if i can add something in final edits to call that
        out.

      
John B.

      

      
On 1/11/2020 6:16 AM, Vladimir
        Dzhuvinov wrote:

      

      

       =20
        
Thanks Mike for the rfc7519
              section-5.3 pointer. Can this parameter replication be
            used for client_id or the client_id ass "iss" even th=
ough it
            isn't explicitly mentioned in the JAR spec?

          

        
On 11/01/2020 02:58, John Bradley
          wrote:

        

        

         =20
          
Right we just don't say to put the iss ther=
e
            in OIDC if it's symetricly encrypted. 

          

        

        
OIDC doesn't have the symmetric key selection issue, I
          suppose that why the possibility to replicate params to the
          JWE header isn't mentioned at all. OIDC requires the top-leve=
l
          query params to represent a valid OAuth 2.0 request, and there
          client_id is required. If the client_id is present the client
          registration together with any present client_secret can be
          retrieved. 

        

        
I reread the JAR spec, this is the only place that mentions
          handling of symmetric JWE.

        

        
https://tools.ietf.org/html/draft-ietf-oa=
uth-jwsreq-20#section-10.2

        

        
 

        

          
   (b)  Verifying that the symmetric key for the JWE encrypt=
ion is the
        correct one if the JWE is using symmetric encryption.

        

        


        

        
Vladimir

        


        

        


          

            
On Fri, Jan 10, 2020, 9:4=
1
              PM Mike Jones <Michael.Jones@microsoft.com>
              wrote:

            

            

              

                

                  
The
                      technique of replicating JWT claims that need to
                      be publicly visible in an encrypted JWT in the
                      header is defined at https://to=
ols.ietf.org/html/rfc7519#section-5.3.=C2=A0
                      (Thanks to Dick Hardt for bringing this need to my
                      attention as we were finishing the JWT spec.)<=
/p>
                  
=C2=A0

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

                  
=C2=A0

                  
From: OAuth <oauth-b=
ounces@ietf.org>
                    On Behalf Of  John Bradley

                    Sent: Friday, January 10, 2020 2:15 PM

                    To: Vladimir Dzhuvinov <vladimir@connect=
2id.com>

                    Cc: IETF oauth WG <oauth@ietf.org>

                    Subject: [EXTERNAL] Re: [OAUTH-WG] JWT
                    Secured Authorization Request (JAR) vs OIDC request
                    object

                  
=C2=A0

                  

                    

                      
The intent was to do that,
                        but specs change once the OAuth WG and IESG get
                        there hands on them.=C2=A0=C2=A0

                      

                        
=C2=A0

                      

                      

                        
Being backwards compatible
                          with OIDC is not a compelling argument to the
                          IESG.

                      

                      

                        
=C2=A0

                      

                      

                        
We were mostly thinking of
                          asymmetric encryption.=C2=A0=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        
Specifying puting the
                          issuer and or the audience in the headder has
                          come up in the past but probably is not
                          documented.=C2=A0=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        
John B=C2=A0

                      

                      
=
=C2=A0

                      

                        

                          
On Fri, Jan 10, 2020,
                            6:29 PM Vladimir Dzhuvinov <vladimir@co=
nnect2id.com>
                            wrote:

                        

                        

                          
Yes, putting the
                            client_id into the JWE header is a way
                            around the need

                            to have the client_id outside the JWE as
                            top-level authZ request parameter.

                            

                            Unfortunately this work around isn't
                            mentioned anywhere, I just checked

                            the most recent draft-ietf-oauth-jwsreq-20.

                            

                            Our DDoS attack mitigation (for OIDC
                            request_uri) also relies on the

                            presence of client_id as top-level
                            parameter, together with requiring

                            RPs to register their request_uri's (so tha=
t
                            we don't need to build and

                            store an index of all request_uri's). I jus=
t
                            had a look at "DDoS Attack

                            on the Authorization Server" and also
                            realised the request_uri

                            registration isn't explicitly mentioned as
                            attack prevention ("the

                            server should (a) check that the value of
                            "request_uri" parameter does

                            not point to an unexpected location").

                            

                            https://t=
ools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

                            

                            To be honest, I feel quite bad about the
                            situation with JAR we are in

                            now. For some reason I had the impression
                            that OAuth JAR was going to be

                            the OIDC request / request_uri for general
                            OAuth 2.0 use, as with other

                            OIDC bits that later became general purpose
                            OAuth 2.0 specs.

                            

                            I find it unfortunate I didn't notice this
                            when I was reviewing the spec

                            in the past.

                            

                            Vladimir

                            

                            

                            On 10/01/2020 22:39, Filip Skokan wrote:

                            > Vladimir, 

                            >

                            > For that very case the payload claims
                            may be repeated in the JWE protected header.
                            An implementation wanting to handle this may
                            look for iss/client_id there. 

                            >

                            > Odesl=C3=A1no z iPhonu

                            >

                            >> 10. 1. 2020 v 21:19, Vladimir
                            Dzhuvinov <vladimir@connect2id.com&=
gt;:

                            >>

                            >> =EF=BB=BFI just realised there is one =
class
                            of JARs where it's practially

                            >> impossible to process the request
                            if merge isn't supported:

                            >>

                            >> The client submits a JAR encrypted
                            (JWT) with a shared key. OIDC allows

                            >> for that and specs a method for
                            deriving the shared key from the

                            >> client_secret:

                            >>

                            >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                            >>

                            >> If the JAR is encrypted with the
                            client_secret, and there is no

                            >> top-level client_id parameter,
                            there's no good way for the OP to find

                            >> out which client_secret to get to
                            try to decrypt the JWE. Unless the OP

                            >> keeps an index of all issued
                            client_secret's.

                            >>

                            >>

                            >> OP servers which require
                            request_uri registration

                            >>
                            (require_request_uri_registration=3Dtrue) and
                            don't want to index all

                            >> registered request_uri's, also hav=
e
                            no good way to process a request_uri

                            >> if the client_id isn't present as
                            top-level parameter.

                            >>

                            >>

                            >> Vladimir

                            >>

                            >>

                            >>> On 10/01/2020 20:13, Torsten
                            Lodderstedt wrote:

                            >>>

                            >>>>> Am 10.01.2020 um 16:53
                            schrieb John Bradley <ve7jtb@ve7jtb.com&g=
t;:

                            >>>> I think Torsten is
                            speculating that is not a feature people
                            use.=C2=A0 =C2=A0

                            >>> I=E2=80=99m still trying to unders=
tand
                            the use case for merging signed and unsigned
                            parameters. Nat once explained a use case,
                            where a client uses parameters signed by a
                            3rd party (some =E2=80=9Ecertification authorit=
y=E2=80=9C)
                            in combination with transaction-specific
                            parameters. Is this being done in the wild?
                            

                            >>>

                            >>> PS: PAR would work with both
                            modes.

                            

                            

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

                            https://

                        

                      

                    

                  

                

              

            

          

        

      

    

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000489442059c1cd054--


From nobody Tue Jan 14 13:18: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 B27FD120110 for ; Tue, 14 Jan 2020 13:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level: 
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD7ri8gx8ZsG for ; Tue, 14 Jan 2020 13:17:59 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77F3120889 for ; Tue, 14 Jan 2020 13:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579036680; x=1610572680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KncKTotEdR1OK7MN/V/P537yJ5LBTGZQo2zPYX6OKfM=; b=NHoJdenDPf9woNargIONKbC3v3g340snJtpmlFfcUeBGd8s3p2tZf/pS rds03TpBHwrC50E6Oc3uYq0Cp1GLqj+b6vPWDycM8mnijcTkntX0qfRXC b0Zwrn7W6Ikkn5HF6bsucynDBXqBKdnj1fNGSh6O4/d46Wd4iXtD26SzN k=;
IronPort-SDR: E7tc9N3/xFZjzjG5JL2rBovSZLBCRwcxETCEvDDddjPy8BuQ2S1UVFrOV6TM8nkXaDJjClUav6 aWTr0kuDfG8w==
X-IronPort-AV: E=Sophos; i="5.70,320,1574121600"; d="scan'208,217"; a="10322954"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 14 Jan 2020 21:17:49 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com (Postfix) with ESMTPS id 504BFA11D3; Tue, 14 Jan 2020 21:17:48 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 21:17:47 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 21:17:47 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 14 Jan 2020 21:17:47 +0000
From: "Richard Backman, Annabelle" 
To: Aaron Parecki , Justin Richer 
CC: "Richard Backman, Annabelle" , oauth , Mike Jones 
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVyoPR7PL9YO5H+k2gS2IKzXqhA6fqJP+A
Date: Tue, 14 Jan 2020 21:17:47 +0000
Message-ID: 
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.253]
Content-Type: multipart/alternative; boundary="_000_A5B3B18889D845B78CEBA68B907B931Camazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 21:18:02 -0000

--_000_A5B3B18889D845B78CEBA68B907B931Camazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGtpZCB1c2VkIGJ5IGEgc2VydmljZSB3aWxsIGNoYW5nZSB3aGVuIGl0IHJvdGF0ZXMga2V5
cyAodGhpcyBpcyB0aGUgbWFpbiB2YWx1ZSBvZiBKV0sgU2V0cyBJTUhPKSwgc28ga2lkIGNhbm5v
dCBiZSB1c2VkIGFzIHBhcnQgb2Ygc3RhdGljIG1ldGFkYXRhLiBZb3XigJlkIG5lZWQgdG8gaW50
cm9kdWNlIGEgbmV3IGZpZWxkIHNvIHlvdSBjYW4gYXNzaWduIGEg4oCcbG9naWNhbCBrZXnigJ0g
aWRlbnRpZmllciB0aGF0IHJlbWFpbnMgdGhlIHNhbWUgYWNyb3NzIGtleSByb3RhdGlvbnMvdmVy
c2lvbnMuDQoNClRoZXJlIGFyZSBzZXZlcmFsIGlzc3VlcyB3aXRoIHRyeWluZyB0byBhZGRyZXNz
IHRoaXMgYnkgYXVnbWVudGluZyBKV0sgdGhvdWdoOg0KDQogICogICBFeGlzdGluZyBkZXBsb3lt
ZW50cyB3aWxsIGlnbm9yZSB0aGUgbG9naWNhbCBrZXkgaWRlbnRpZmllciwgc28gdGhlcmUgaXMg
bm8gd2F5IHRvIGtlZXAgdGhvc2Uga2V5cyBmcm9tIGJlaW5nIHVzZWQgdG8gc2lnbiBmcmF1ZHVs
ZW50IElEIFRva2VucyAoZm9yIGV4YW1wbGUpLg0KICAqICAgVGhlIEpXSyBzZXQgYmVjb21lcyBh
IHNoYXJlZCByZXNvdXJjZSB0aGF0IHNwYW5zIHRydXN0IGJvdW5kYXJpZXMuDQoNCkEgc29sdXRp
b24gYmFzZWQgb24gc2VwYXJhdGUgandrc191cmkgbWV0YWRhdGEgcGFyYW1ldGVycyBzb2x2ZXMg
Ym90aCBvZiB0aGVzZSBwcm9ibGVtcywgYW5kIHJlcXVpcmVzIHZlcnkgbGl0dGxlIGVmZm9ydCBm
b3IgQVNlcyB0aGF0IGRvbuKAmXQgaGF2ZSB0aGlzIGNvbmNlcm4uDQoNCuKAkw0KQW5uYWJlbGxl
IFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBYXJvbiBQYXJlY2tpIDxhYXJvbkBwYXJlY2tp
LmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAxMywgMjAyMCBhdCA2OjM5IFBNDQpUbzogSnVz
dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFi
ZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4sIG9hdXRoIDxvYXV0
aEBpZXRmLm9yZz4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRt
YXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVS
XSBSRTogQ3J5cHRvZ3JhcGhpYyBoeWdpZW5lIGFuZCB0aGUgbGltaXRzIG9mIGp3a3NfdXJpDQoN
ClJpZ2h0IG5vdywgT2t0YSBwdWJsaXNoZXMgdHdvIGtleXMgYXQgdGhlIGp3a3NfdXJpIGluIG9y
ZGVyIHRvIGJlIGFibGUgdG8gcm90YXRlIGtleXMgcGVyaW9kaWNhbGx5LiBEdXJpbmcgdGhlIHRv
a2VuIGxpZmV0aW1lIHdpbmRvdyBkdXJpbmcga2V5IHJvdGF0aW9uLCB0aGUgUlNzIGNhbiBzdGls
bCBmaW5kIGJvdGggdGhlIG9sZCBhbmQgbmV3IGtleSBJRHMgaW4gdGhlIHNldC4NCg0KUlNzIGFy
ZSBsb29raW5nIGZvciBhIHNwZWNpZmljIGtleSBJRCB3aGVuIHRoZXkgZG8gdGhpcywgc28gaXQg
d291bGQgYmUgZmluZSB0byBpbmNsdWRlIGFkZGl0aW9uYWwga2V5cyB0aGF0IGFyZSB1c2VkIGZv
ciBzb21ldGhpbmcgb3RoZXIgdGhhbiBhY2Nlc3MgdG9rZW5zIHNpbmNlIHRoZSBSU3Mgd291bGQg
anVzdCBpZ25vcmUgdGhlbS4NCg0KU28gYW4gZXh0ZW5zaW9uIGNvdWxkIHNheSAidXNlIHRoaXMg
a2V5IGlkZW50aWZpZWQgYnkga2lkIiBhbmQgdGhhdCdkIGJlIGEgZGVjZW50IGV4dGVuc2lvbiBt
ZWNoYW5pc20uDQoNCg0KDQpPbiBNb24sIEphbiAxMywgMjAyMCBhdCA2OjI2IFBNIEp1c3RpbiBS
aWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpJ
IHdvdWxkIHJhdGhlciBzZWUgZXh0ZW5zaW9ucyBkZWZpbmUgYSBrZXkgSUQgdGhhbiBhIG5ldyBr
ZXkgc2V0IFVSSS4gT3RoZXJ3aXNlIHdoYXTigJlzIHRoZSBwb2ludCBvZiBoYXZpbmcgbW9yZSB0
aGFuIG9uZSBrZXkgaW4gdGhlIHNldCwgd2l0aCB1bmlxdWUgaWRlbnRpZmllcnM/DQoNCkl0IHdv
dWxk4oCZdmUgYmVlbiBuaWNlIGlmIEpXSyBjb3VsZOKAmXZlIGFncmVlZCBvbiBhIFVSTC1iYXNl
ZCBhZGRyZXNzaW5nIGZvcm1hdCBmb3IgaW5kaXZpZHVhbCBrZXlzIHdpdGhpbiB0aGUgc2V0LCBi
dXQgdGhhdCBzaGlw4oCZcyBzYWlsZWQuDQoNCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBKYW4gMTAs
IDIwMjAsIGF0IDk6MzQgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0
bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIHdhcyBub3Qgc2F5aW5nIHRoYXQg
dGhlcmUgd2FzIGFueXRoaW5nIHNwZWNpYWwgYWJvdXQga2V5cywgbm9yIHRoYXQgd2UgbmVlZGVk
IHRvIGNoYW5nZSBPQXV0aC4NCg0KV2hpbGUgdXNpbmcgb25lIGtleSBhbmQgY29udHJvbGxpbmcg
d2hlcmUgaXQgdXMgdXNlZCB2aWEgYWNjZXNzIGNvbnRyb2wgd29ya3MsIGl0IGlzIG5vdCBpZGVh
bC4NCg0KT0F1dGggY291bGQgaGF2ZSBoYWQganVzdCBvbmUgZW5kcG9pbnQsIGFuZCBkb25lIGFj
Y2VzcyBjb250cm9sIGZvciBkaWZmZXJlbnQgcm9sZXMgLS0gYnV0IGl0IGRpZCBub3QuIFdlIGVu
YWJsZWQgZmxleGliaWxpdHkgYnkgc2VwYXJhdGluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu
dCBhbmQgdGhlIHRva2VuIGVuZHBvaW50LiBUaGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9u
IGV4dGVuc2lvbiBkZWZpbmVkIGEgbmV3IGVuZHBvaW50LCB0aGUgcmVnaXN0cmF0aW9uIGVuZHBv
aW50Lg0KDQpJIGRvbid0IHRoaW5rIHdlIGNhbiBjaGFuZ2Ugd2hhdCBoYXMgYmVlbiBkZXBsb3ll
ZCB0b2RheSAtLSBidXQgTkVXIGV4dGVuc2lvbnMgdGhhdCB1c2Uga2V5cyBmb3IgbmV3IHB1cnBv
c2VzIFNIT1VMRCBkZWZpbmUgdGhlaXIgb3duIFVSSS4NCltodHRwczovL21haWxmb29nYWUuYXBw
c3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXpl
cm9jb250ZW50Jmd1aWQ9NDBlZTlmMjAtYmZhZi00ZjJkLTg5MDUtNmUwYWQ4YjI4NDgxXeGQpw0K
DQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMTozMSBBTSBOZWlsIE1hZGRlbiA8bmVpbC5tYWRk
ZW5AZm9yZ2Vyb2NrLmNvbTxtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4+IHdyb3Rl
Og0KU3VyZSwgYnV0IHdlIGtub3cgaG93IHRvIHJ1biByZXNpbGllbnQgc2VydmljZXMuIE15IHBv
aW50IGlzIHRoYXQgdGhlcmXigJlzIG5vdGhpbmcgcGFydGljdWxhcmx5IHNwZWNpYWwgYWJvdXQg
Y3J5cHRvZ3JhcGhpYyBrZXlzOiBpZiB5b3Ugd2FudCB0byBjb250cm9sIGhvdyB0aGV5IGFyZSB1
c2VkIHRoZXJlIGlzIGEgd2hvbGUgcmFuZ2Ugb2Ygbm9ybWFsIGFjY2VzcyBjb250cm9sIG1ldGhv
ZHMgeW91IGNhbiBhcHBseSB0byB0aGVtIHdpdGhvdXQgbmVlZGluZyB0byBjaGFuZ2UgYW55dGhp
bmcgaW4gT0F1dGguDQoNCk5laWwNCg0KDQpPbiAxMCBKYW4gMjAyMCwgYXQgMTg6NTAsIERpY2sg
SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+
IHdyb3RlOg0KVGhlcmUgYXJlIG1hbnkgb3RoZXIgZmFjdG9ycyB0byByZXNpbGllbmN5IHRoYW4g
bXVsdGlwbGUgaW5zdGFuY2VzLg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMDozMCBBTSBO
ZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTxtYWlsdG86bmVpbC5tYWRkZW5A
Zm9yZ2Vyb2NrLmNvbT4+IHdyb3RlOg0KDQoNCj4gT24gMTAgSmFuIDIwMjAsIGF0IDE3OjIyLCBE
aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j
b20+PiB3cm90ZToNClsuLi5dDQo+DQo+IEFzIHRvIHRoZSBzdWdnZXN0aW9uIG9mIHVzaW5nIGEg
SldULWRlY3J5cHRpb24tbWljcm9zZXJ2aWNlLCBhbm90aGVyIGdvYWwgd291bGQgYmUgaW5jcmVh
c2VkIHJlc2lsaWVuY3kgb2YgdGhlIGNvbXBvbmVudHMuIElmIHRoZSBKV1QtZGVjcnlwdGlvbi1t
aWNyb3NlcnZpY2UgaXMgdW5hdmFpbGFibGUsIHRoZSB3aG9sZSBzeXN0ZW0gaXMgdW5hdmFpbGFi
bGUuIElmIHRoZXJlIGFyZSBzZXBhcmF0ZSBrZXlzLCB0aGVuIGEgZmFpbHVyZSBpbiBvbmUgY29t
cG9uZW50IGRvZXMgbm90IGZhaWwgdGhlIGVudGlyZSBzeXN0ZW0uDQoNCldlbGwgeW91IGNhbiBy
dW4gbW9yZSB0aGFuIG9uZSBpbnN0YW5jZSAtIGl04oCZcyBhIGNvbXBsZXRlbHkgc3RhdGVsZXNz
IHNlcnZpY2UuIFlvdSBjYW4gYWxzbyBydW4gYSBzZXBhcmF0ZSBpbnN0YW5jZSAob3Igc2V0IG9m
IGluc3RhbmNlcykgcGVyIGtleSBpZiB5b3UgbGlrZS4NCg0KTmVpbA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP
QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQotLQ0KLS0tLQ0KQWFyb24gUGFyZWNraQ0KYWFyb25w
YXJlY2tpLmNvbTxodHRwOi8vYWFyb25wYXJlY2tpLmNvbT4NCkBhYXJvbnBrPGh0dHA6Ly90d2l0
dGVyLmNvbS9hYXJvbnBrPg0KDQo=

--_000_A5B3B18889D845B78CEBA68B907B931Camazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy
IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h
dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg
MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlhIFVDQVMiOw0K
CXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz
dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg
ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z
ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDMzNjAzOTQ4Ow0KCW1zby1saXN0LXR5cGU6
aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDA1NzUxNjg0IDE1MjA2MDE0ODggNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0K
CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN
Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBraWQgdXNl
ZCBieSBhIHNlcnZpY2Ugd2lsbCBjaGFuZ2Ugd2hlbiBpdCByb3RhdGVzIGtleXMgKHRoaXMgaXMg
dGhlIG1haW4gdmFsdWUgb2YgSldLIFNldHMgSU1ITyksIHNvIGtpZCBjYW5ub3QgYmUgdXNlZCBh
cyBwYXJ0IG9mIHN0YXRpYyBtZXRhZGF0YS4gWW914oCZZCBuZWVkIHRvIGludHJvZHVjZSBhIG5l
dyBmaWVsZCBzbyB5b3UgY2FuIGFzc2lnbiBhIOKAnGxvZ2ljYWwga2V54oCdIGlkZW50aWZpZXIg
dGhhdA0KIHJlbWFpbnMgdGhlIHNhbWUgYWNyb3NzIGtleSByb3RhdGlvbnMvdmVyc2lvbnMuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBzZXZlcmFsIGlzc3VlcyB3aXRoIHRyeWlu
ZyB0byBhZGRyZXNzIHRoaXMgYnkgYXVnbWVudGluZyBKV0sgdGhvdWdoOjxvOnA+PC9vOnA+PC9w
Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z
b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx
IGxmbzEiPkV4aXN0aW5nIGRlcGxveW1lbnRzIHdpbGwgaWdub3JlIHRoZSBsb2dpY2FsIGtleSBp
ZGVudGlmaWVyLCBzbyB0aGVyZSBpcyBubyB3YXkgdG8ga2VlcCB0aG9zZSBrZXlzIGZyb20gYmVp
bmcgdXNlZCB0byBzaWduIGZyYXVkdWxlbnQgSUQgVG9rZW5zIChmb3IgZXhhbXBsZSkuPG86cD48
L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhlIEpXSyBzZXQgYmVjb21lcyBhIHNoYXJl
ZCByZXNvdXJjZSB0aGF0IHNwYW5zIHRydXN0IGJvdW5kYXJpZXMuPG86cD48L286cD48L2xpPjwv
dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkEgc29sdXRpb24gYmFzZWQgb24gc2VwYXJhdGUgandrc191cmkgbWV0YWRh
dGEgcGFyYW1ldGVycyBzb2x2ZXMgYm90aCBvZiB0aGVzZSBwcm9ibGVtcywgYW5kIHJlcXVpcmVz
IHZlcnkgbGl0dGxlIGVmZm9ydCBmb3IgQVNlcyB0aGF0IGRvbuKAmXQgaGF2ZSB0aGlzIGNvbmNl
cm4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJh
Y2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu
IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3Jn
Jmd0OyBvbiBiZWhhbGYgb2YgQWFyb24gUGFyZWNraSAmbHQ7YWFyb25AcGFyZWNraS5jb20mZ3Q7
PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAxMywgMjAyMCBhdCA2OjM5IFBNPGJy
Pg0KPGI+VG86IDwvYj5KdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0K
PGI+Q2M6IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmlj
aGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnJmd0Oywgb2F1dGggJmx0O29hdXRoQGll
dGYub3JnJmd0OywgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A
ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFtV
TlZFUklGSUVEIFNFTkRFUl0gUkU6IENyeXB0b2dyYXBoaWMgaHlnaWVuZSBhbmQgdGhlIGxpbWl0
cyBvZiBqd2tzX3VyaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJpZ2h0IG5vdywgT2t0YSBwdWJsaXNoZXMgdHdvIGtl
eXMgYXQgdGhlIGp3a3NfdXJpIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gcm90YXRlIGtleXMgcGVy
aW9kaWNhbGx5LiBEdXJpbmcgdGhlIHRva2VuIGxpZmV0aW1lIHdpbmRvdyBkdXJpbmcga2V5IHJv
dGF0aW9uLCB0aGUgUlNzIGNhbiBzdGlsbCBmaW5kIGJvdGggdGhlIG9sZCBhbmQgbmV3IGtleSBJ
RHMgaW4gdGhlIHNldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5SU3MgYXJlIGxvb2tpbmcgZm9yIGEgc3BlY2lmaWMga2V5IElE
IHdoZW4gdGhleSBkbyB0aGlzLCBzbyBpdCB3b3VsZCBiZSBmaW5lIHRvIGluY2x1ZGUgYWRkaXRp
b25hbCBrZXlzIHRoYXQgYXJlIHVzZWQgZm9yIHNvbWV0aGluZyBvdGhlciB0aGFuIGFjY2VzcyB0
b2tlbnMgc2luY2UgdGhlIFJTcyB3b3VsZCBqdXN0IGlnbm9yZSB0aGVtLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBhbiBleHRlbnNpb24g
Y291bGQgc2F5ICZxdW90O3VzZSB0aGlzIGtleSBpZGVudGlmaWVkIGJ5IGtpZCZxdW90OyBhbmQg
dGhhdCdkIGJlIGEgZGVjZW50IGV4dGVuc2lvbiBtZWNoYW5pc20uJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSmFu
IDEzLCAyMDIwIGF0IDY6MjYgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy
aWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3
b3VsZCByYXRoZXIgc2VlIGV4dGVuc2lvbnMgZGVmaW5lIGEga2V5IElEIHRoYW4gYSBuZXcga2V5
IHNldCBVUkkuIE90aGVyd2lzZSB3aGF04oCZcyB0aGUgcG9pbnQgb2YgaGF2aW5nIG1vcmUgdGhh
biBvbmUga2V5IGluIHRoZSBzZXQsIHdpdGggdW5pcXVlIGlkZW50aWZpZXJzPw0KPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZOKAmXZlIGJlZW4g
bmljZSBpZiBKV0sgY291bGTigJl2ZSBhZ3JlZWQgb24gYSBVUkwtYmFzZWQgYWRkcmVzc2luZyBm
b3JtYXQgZm9yIGluZGl2aWR1YWwga2V5cyB3aXRoaW4gdGhlIHNldCwgYnV0IHRoYXQgc2hpcOKA
mXMgc2FpbGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMTAsIDIwMjAsIGF0IDk6MzQgUE0sIERpY2sg
SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBub3Qgc2F5aW5nIHRoYXQgdGhl
cmUgd2FzIGFueXRoaW5nIHNwZWNpYWwgYWJvdXQga2V5cywgbm9yIHRoYXQgd2UgbmVlZGVkIHRv
IGNoYW5nZSBPQXV0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+V2hpbGUgdXNpbmcgb25lIGtleSBhbmQgY29udHJvbGxpbmcgd2hlcmUgaXQgdXMgdXNl
ZCB2aWEgYWNjZXNzIGNvbnRyb2wgd29ya3MsIGl0IGlzIG5vdCBpZGVhbC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0F1dGggY291bGQgaGF2
ZSBoYWQganVzdCBvbmUgZW5kcG9pbnQsIGFuZCBkb25lIGFjY2VzcyBjb250cm9sIGZvciBkaWZm
ZXJlbnQgcm9sZXMgLS0gYnV0IGl0IGRpZCBub3QuIFdlIGVuYWJsZWQgZmxleGliaWxpdHkgYnkg
c2VwYXJhdGluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhbmQgdGhlIHRva2VuIGVuZHBv
aW50LiBUaGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGV4dGVuc2lvbiBkZWZpbmVkDQog
YSBuZXcgZW5kcG9pbnQsIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgd2Ug
Y2FuIGNoYW5nZSB3aGF0IGhhcyBiZWVuIGRlcGxveWVkIHRvZGF5IC0tIGJ1dCBORVcgZXh0ZW5z
aW9ucyB0aGF0IHVzZSBrZXlzIGZvciBuZXcgcHVycG9zZXMgU0hPVUxEIGRlZmluZSB0aGVpciBv
d24gVVJJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczov
L21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1
amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD00MGVlOWYyMC1iZmFmLTRmMmQt
ODkwNS02ZTBhZDhiMjg0ODEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7RXVwaGVtaWEgVUNBUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG
cmksIEphbiAxMCwgMjAyMCBhdCAxMTozMSBBTSBOZWlsIE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20iIHRhcmdldD0iX2JsYW5rIj5uZWlsLm1hZGRl
bkBmb3JnZXJvY2suY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIGJ1dCB3
ZSBrbm93IGhvdyB0byBydW4gcmVzaWxpZW50IHNlcnZpY2VzLiBNeSBwb2ludCBpcyB0aGF0IHRo
ZXJl4oCZcyBub3RoaW5nIHBhcnRpY3VsYXJseSBzcGVjaWFsIGFib3V0IGNyeXB0b2dyYXBoaWMg
a2V5czogaWYgeW91IHdhbnQgdG8gY29udHJvbCBob3cgdGhleSBhcmUgdXNlZCB0aGVyZSBpcyBh
IHdob2xlIHJhbmdlIG9mIG5vcm1hbCBhY2Nlc3MgY29udHJvbCBtZXRob2RzIHlvdSBjYW4gYXBw
bHkNCiB0byB0aGVtIHdpdGhvdXQgbmVlZGluZyB0byBjaGFuZ2UgYW55dGhpbmcgaW4gT0F1dGgu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk5laWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDEwIEphbiAyMDIwLCBhdCAxODo1MCwgRGlj
ayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZXJlIGFyZSBtYW55IG90aGVyIGZhY3RvcnMgdG8gcmVzaWxpZW5jeSB0aGFuIG11
bHRpcGxlIGluc3RhbmNlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEwOjMwIEFNIE5laWwgTWFkZGVu
ICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi
cj4NCiZndDsgT24gMTAgSmFuIDIwMjAsIGF0IDE3OjIyLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVm
PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NClsuLi5dPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IEFzIHRvIHRoZSBzdWdnZXN0aW9uIG9mIHVzaW5nIGEgSldULWRlY3J5cHRpb24tbWljcm9zZXJ2
aWNlLCBhbm90aGVyIGdvYWwgd291bGQgYmUgaW5jcmVhc2VkIHJlc2lsaWVuY3kgb2YgdGhlIGNv
bXBvbmVudHMuIElmIHRoZSBKV1QtZGVjcnlwdGlvbi1taWNyb3NlcnZpY2UgaXMgdW5hdmFpbGFi
bGUsIHRoZSB3aG9sZSBzeXN0ZW0gaXMgdW5hdmFpbGFibGUuIElmIHRoZXJlIGFyZSBzZXBhcmF0
ZSBrZXlzLCB0aGVuIGEgZmFpbHVyZSBpbiBvbmUNCiBjb21wb25lbnQgZG9lcyBub3QgZmFpbCB0
aGUgZW50aXJlIHN5c3RlbS4gPGJyPg0KPGJyPg0KV2VsbCB5b3UgY2FuIHJ1biBtb3JlIHRoYW4g
b25lIGluc3RhbmNlIC0gaXTigJlzIGEgY29tcGxldGVseSBzdGF0ZWxlc3Mgc2VydmljZS4gWW91
IGNhbiBhbHNvIHJ1biBhIHNlcGFyYXRlIGluc3RhbmNlIChvciBzZXQgb2YgaW5zdGFuY2VzKSBw
ZXIga2V5IGlmIHlvdSBsaWtlLg0KPGJyPg0KPGJyPg0KTmVpbDxvOnA+PC9vOnA+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5BYXJvbiBQYXJlY2tpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPmFhcm9ucGFyZWNraS5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vdHdpdHRlci5j
b20vYWFyb25wayIgdGFyZ2V0PSJfYmxhbmsiPkBhYXJvbnBrPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A5B3B18889D845B78CEBA68B907B931Camazoncom_--


From nobody Tue Jan 14 13:29: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 7A792120110 for ; Tue, 14 Jan 2020 13:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss5pv6ELLr7m for ; Tue, 14 Jan 2020 13:29:51 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C73E120059 for ; Tue, 14 Jan 2020 13:29:51 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id z193so15520647iof.1 for ; Tue, 14 Jan 2020 13:29:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=CmrYgO9XaOM4zls/KQoAvclhv3Obfcq0T6HTbLi1fUQ=; b=dQZtKFwt5ux8nnFT7S/8lnbCSBRxKpR0TcQ95AUcKj4so8qDUCEKtDZaIs6v29ju4k snUh+WZDYtbR3x1r5rCn2pllafbetTI5M8eIgzKQO+w6MbtYjtLKbCSj90cEGMXjxT9e 60PA/m5hf0cs4YIdoZSH6HlZTaN1ftQKBXCO5HqKOueuI6wcqc+XDqi3ZSlA53AZPK8i nBhDysQDYbrTgT/gyaNMhdhcQ+AE93Dckb60Tbj+XGAZMeO8wzQ+lVwsv9jx0ShgywoM H6E+1cUd/fgTONIRN2Dl1aXb1DsgypWMY+pJUYhDXuwHR1IHhMDlwA3sXMGpKem/N6oD Ek8w==
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=CmrYgO9XaOM4zls/KQoAvclhv3Obfcq0T6HTbLi1fUQ=; b=DmhNp3pnfR3mUDLQFklqV5UK7bo6EUDOMf3QSlchJ+mvGIFtuA5WSJcJCcgi1syDAa 6wp8DAn2pwBj3pOrknUYl0igpQahfRw4GsH9e9qCaNP3s+ZLtflvC+gQyWZYRY/Cj7Ya nSFbXcDi1hfdJckBaNLTOIksU1O1B81nB9GOjt8O86Wz7uqzPLP59G2Qs2cY4r70lDzQ an49T+CmvVJSvk9h58TvjFRnIR18PNv1JSXVQ19RQbqGFIvddSg7xg9HgAZp01cUeBDj Nc5tGBwy3w971j7wMdPb/8dKVjPA2HYdZAWiTmLclnWjUX17T6ZimJtN9YJo/ikhxWpR oAgQ==
X-Gm-Message-State: APjAAAVx5bYiORzZJpMcv5KBrlFS8ezPPlEY8u/LiXQoPyPIYn1nYkHH OKeitwj8C2kHSjeJ9elTbuk8qzujulU9ll6QyW0Afd0LOic=
X-Google-Smtp-Source: APXvYqwSGmIG3F/3ikbBZGA6W9zGSFg/L0K6KKZTS51IGfDiuPgjSOv039kAS70PRIr/jU47Vrmi/FbeSTtEe8V5C7A=
X-Received: by 2002:a5e:8f41:: with SMTP id x1mr19861262iop.113.1579037390193;  Tue, 14 Jan 2020 13:29:50 -0800 (PST)
MIME-Version: 1.0
From: George Aristy 
Date: Tue, 14 Jan 2020 16:29:39 -0500
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bacb20059c204aea"
Archived-At: 
Subject: [OAUTH-WG] JWT Secured Authorization Request (JAR): signing
X-BeenThere: oauth@ietf.org
X-Mailman-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, 14 Jan 2020 21:29:53 -0000

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

Hello everyone.

Is it possible to relax the requirement to sign the claims set if an
authenticated encryption mode with prior shared secrets is used? Eg.
https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02. This would
reduce the size of the request object substantially.

Regards,
George Aristy

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


Hello everyone.

Is it possib=
le to relax the requirement to sign the claims set if an authenticated encr=
yption mode with prior shared secrets is used? Eg. https://tools.ietf.org/html/d=
raft-madden-jose-ecdh-1pu-02. This would reduce the size of the request=
 object substantially.

Regards, 
George Aristy
=



--000000000000bacb20059c204aea--


From nobody Wed Jan 15 12:32: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 CCBCC120975 for ; Wed, 15 Jan 2020 12:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZeNYCV20aHZ for ; Wed, 15 Jan 2020 12:32:52 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE54B120979 for ; Wed, 15 Jan 2020 12:32:51 -0800 (PST)
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 00FKWkop012688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 15:32:48 -0500
Date: Wed, 15 Jan 2020 12:32:45 -0800
From: Benjamin Kaduk 
To: George Aristy 
Cc: oauth@ietf.org
Message-ID: <20200115203245.GO30105@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] JWT Secured Authorization Request (JAR): signing
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 20:32:56 -0000

On Tue, Jan 14, 2020 at 04:29:39PM -0500, George Aristy wrote:
> Hello everyone.
> 
> Is it possible to relax the requirement to sign the claims set if an
> authenticated encryption mode with prior shared secrets is used? Eg.
> https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02. This would
> reduce the size of the request object substantially.

It seems fairly late in the publication process to make such a change,
since the properties provided by digital signature and AEAD tag are subtly
different, and the key-management lifecycle needed to provide secure
operation is different.

That said, off the top of my head, I don't know of anything that would
prevent this functionality from being specified as an extension to plain
JAR.

-Ben


From nobody Wed Jan 15 12:33: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 1E3C41208EA for ; Wed, 15 Jan 2020 12:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 sl_YCpFKQqHU for ; Wed, 15 Jan 2020 12:33:19 -0800 (PST)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 65487120967 for ; Wed, 15 Jan 2020 12:33:19 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpLoirJoawWVzrpLoiiH8t; Wed, 15 Jan 2020 13:33:18 -0700
x-spam-cmae: v=2.3 cv=U/bs8tju c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=Mhp_Scw7AAAA:8 a=LS6YZpeZAAAA:8 a=DVqm7IH0AAAA:8 a=vggBfdFIAAAA:8 a=oI8NkQaCAhIDyLdqDioA:9 a=QXEX9zbxSCVRNd8W:21 a=8uTPL6tWqCW9Q3gY:21 a=QEXdDO2ut3YA:10 a=6GDzRCPCMzKxnl74T_kA:9 a=oKr0jl5zW2fyofK8:21 a=zsRuuMFJ1ZmsxyAE:21 a=d1hEjZnxr6VYrB5g:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 a=rCfoGGe4EEIQCwLoKFZE:22 a=IRr2vCDBpksuBOXhfkKu:22 a=IdGyktwZ2tr74praB_5u:22 a=M6wP_kGduNurgptF5PJY:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
To: Justin Richer 
Cc: "Richard Backman, Annabelle" , oauth , Nat Sakimura 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>  
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: 
Date: Wed, 15 Jan 2020 22:33:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050200030807070704090400"
X-CMAE-Envelope: MS4wfJf8vY5jdGyUT2kaA5vuz5fbMy2Xpv7SEg58Luifq2+0NVWq3lmo9rJZPjzZI6d4OJjBfJCGG1cMBE0AbOU8Ha2cA+e8DtmbkIwuI2WdYTRo4/Ih0PnL 8n2mCich7VTGpZO8pakbnziVkj6+9OmxXHUgC0pTUCzclna6UfhG34Xvb0eQmug0BDUDBqltP98nNni/0i9edsGRNpzGGE4010rynJsnGBIVw2PCOLt9bOKh 75yE9HtTJOasCYn+G+LfGbBKAwgsPTM22MYI3jbBrQI=
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 20:33:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms050200030807070704090400
Content-Type: multipart/alternative;
 boundary="------------583CDDD29DB97E6904C6E664"
Content-Language: en-US

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

On 13/01/2020 19:32, Justin Richer wrote:
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I=
 agree
> that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=
=9D or something of that
> nature. But if we call the result of PAR =E2=80=9Cthing X=E2=80=9D and =
the target of
> request_uri =E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compat=
ible without saying
> what =E2=80=9Cthing X=E2=80=9D needs to be in all cases.

Good, we're on the same page then.

How about simply saying that the result of PAR is an URI referencing the
pushed authZ request; at the authZ endpoint its processing is completed.

No need is both clear and abstract enough to not require a form to be
specified.


> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be
> formatted as a JWT.

But why?

Both PAR and authZ endpoints belong to the AS, which makes that impl
specific. The URI is the contract, between client and AS.

The AS, if uService based, could choose to implement that as CBOR Web
Token, or some other verifiable blob, resulting in the same essential
function, and this isn't affecting the client <-> AS contract in any way.=



> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I
> believe that=E2=80=99s been backed off now and made conditional.

That was precisely my point.

Vladimir



> =C2=A0=E2=80=94 Justin
>
>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov
>> > wrote:
>>
>> My suggestion is to abstain from specifying the concrete form of the
>> resource pointed to by the PAR URI. Regardless of URI type (URN,
>> downloadable https URL or something else), and even if the PAR
>> endpoint and the authZ endpoint are managed by two different entities
>> (microservice or other scenario).
>>
>> In the Connect2id implementation of PAR the returned URI doesn't
>> point to a request object and it doesn't point to a JWT either. It
>> points to an internally stored "pre-processed" authZ request, which
>> the authZ endpoint then picks up to complete the authZ.
>>
>> Even if we eventually end up in microservice world, or allow the PAR
>> endpoint to be managed by some external entity, the PAR URI - its
>> interpretation, validation and potentially resource retrieval (JWT or
>> other blob), is an "internal contract" on the AS side. This doesn't
>> concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>
>>
>> I see PAR request + authZ request as one logical OAuth 2.0 authZ
>> request: the client submits an authZ request and gets an authZ
>> response at the end. The URI is necessary for the client to proceed
>> from the 1st to the 2nd step. If we manage to frame / word the PAR
>> URI in this logical way, without getting stuck in the JAR definition
>> / framing of what the request_uri / object is, it would be great.
>>
>>
>> The normative language I think should focus on maintaining the OAuth
>> 2.0 contract for the entire logical authZ request, together with the
>> basic contracts of 1) JAR and the 2) authZ endpoint.
>>
>>
>> Vladimir
>>
>>
>> On 10/01/2020 22:55, Justin Richer wrote:
>>> So we could solve this by saying the resulting data object of a PAR
>>> is a request object. Which might also contain a request object
>>> internally as well. In that case JAR should back off from saying
>>> it=E2=80=99s a JWT and instead say it=E2=80=99s a request object. Or =
we define a new
>>> term for this authorization request blob thing.
>>>
>>> Or PAR could at least say that if it=E2=80=99s dereferenced over a re=
mote
>>> protocol then it MUST be a JWT, but otherwise it can be whatever you
>>> want. That=E2=80=99s where the real interop concerns come in.
>>>
>>> =C2=A0=E2=80=94 Justin
>>>
>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle
>>>> >>> > wrote:
>>>>
>>>> Correct. The problem becomes pretty clear in the context of PAR,
>>>> where the AS is generating and vending out the URI at the PAR
>>>> endpoint, and consuming it at the authorization endpoint. From an
>>>> interoperability standpoint, it=E2=80=99s analogous to the AS vendin=
g an
>>>> authorization code at the authorization endpoint and consuming it
>>>> at the token endpoint.
>>>> =E2=80=93=C2=A0
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>> =C2=A0
>>>> =C2=A0
>>>> *From:=C2=A0*John Bradley >
>>>> *Date:=C2=A0*Friday, January 10, 2020 at 12:29 PM
>>>> *To:=C2=A0*Brian Campbell >>> >
>>>> *Cc:=C2=A0*Torsten Lodderstedt >>> >, Nat Sakimura >>> >, "Richard Backman, Annabelle"
>>>> >, oauth
>>>> >
>>>> *Subject:=C2=A0*[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed reque=
sts
>>>> must become JWTs
>>>> =C2=A0
>>>> If we assume the client posts a JAR and gets back a reference.=C2=A0=

>>>> Then the reference is to a JAR.=C2=A0
>>>> =C2=A0
>>>> I think I see the problem.=C2=A0 If the server providing the referen=
ce
>>>> is associated with the AS then the server dosen't need to
>>>> dereference the object via HTTP, so it could be a URN as an example.=
=C2=A0
>>>> =C2=A0
>>>> So yes it is not a interoperability issue for the client.=C2=A0=C2=A0=

>>>> =C2=A0
>>>> I will think about how I can finesse that.=C2=A0
>>>> =C2=A0
>>>> I agree it is not a change in intent.=C2=A0
>>>> =C2=A0
>>>> I will see if I can get our AD to accept that.
>>>> =C2=A0
>>>> John B.=C2=A0
>>>> =C2=A0
>>>> =C2=A0
>>>> =C2=A0
>>>> =C2=A0
>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell
>>>> > wro=
te:
>>>>> Sure but the text proposed (or something like it) qualifies it
>>>>> such that there aren't interoperability questions because it's
>>>>> only an implementation detail to the AS who both produces the URI
>>>>> and consumes its content.
>>>>> =C2=A0
>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley >>>> > wrote:
>>>>>> It may be a challenge to change text saying that the contents of
>>>>>> the resource could be something other than a request object.=C2=A0=

>>>>>> =C2=A0
>>>>>> If not a request object then what and how is that interoperable
>>>>>> are likely AD questions.=C2=A0
>>>>>> =C2=A0
>>>>>> I could perhaps see changing it to must be a request object, or
>>>>>> other format defined by a profile.
>>>>>>
>>>>>> John B.=C2=A0=C2=A0
>>>>>> =C2=A0
>>>>>> =C2=A0
>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell
>>>>>> >
>>>>>> wrote:
>>>>>>> Agree and agree. But given that the change suggested by
>>>>>>> Annabelle has no impact on the client or interoperability,
>>>>>>> perhaps Nat or John could work the change into the draft during
>>>>>>> the edits that happen during the final stages of things?
>>>>>>> =C2=A0
>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt
>>>>>>> >>>>>> > wrote:
>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t want to=
 change
>>>>>>>> it. And as I said, this difference does not impact
>>>>>>>> interoperability from client perspective.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle
>>>>>>>>> >>>>>>>> >:
>>>>>>>>>
>>>>>>>>> It would be more appropriate to add the text to JAR rather
>>>>>>>>> than PAR. It doesn't seem right for PAR to retcon rules in
>>>>>>>>> JAR. Moving the text to JAR also highlights the weirdness of
>>>>>>>>> giving PAR special treatment.
>>>>>>>>> =C2=A0
>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>
>>>>>>>>> The contents of the resource referenced by the URI MUST be a
>>>>>>>>> Request
>>>>>>>>>
>>>>>>>>> Object.
>>>>>>>>>
>>>>>>>>> =C2=A0
>>>>>>>>> To:=C2=A0
>>>>>>>>>
>>>>>>>>> The contents of the resource referenced by the URI MUST be a
>>>>>>>>> Request
>>>>>>>>>
>>>>>>>>> Object, unless the URI was provided to the client by the
>>>>>>>>> Authorization
>>>>>>>>>
>>>>>>>>> Server.
>>>>>>>>>
>>>>>>>>> =C2=A0
>>>>>>>>> This would allow for use cases such as an AS that provides
>>>>>>>>> pre-defined request URIs, or vends request URIs via a client
>>>>>>>>> management console, or bakes them into their client apps.
>>>>>>>>> =C2=A0
>>>>>>>>> =E2=80=93=C2=A0
>>>>>>>>> Annabelle Richard Backman
>>>>>>>>> AWS Identity
>>>>>>>>> =C2=A0
>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"
>>>>>>>>> >>>>>>>> > wrote:
>>>>>>>>> =C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0 Hi,=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the=
 AS to represent
>>>>>>>>> the request as a JWT-based request object. The URI is used as
>>>>>>>>> internal reference only. That why the draft states
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0"There is no need to make the
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authoriz=
ation request data available to other
>>>>>>>>> parties via this
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=
=9D
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS impl=
ementation
>>>>>>>>> perspective, it doesn't matter from a client's (interop)
>>>>>>>>> perspective.
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying th=
at request_uris
>>>>>>>>> issued by the PAR mechanism (MAY) deviate from the JAR definiti=
on.
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0best regards,
>>>>>>>>> =C2=A0=C2=A0=C2=A0 Torsten.=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan 2020, at 23:42, Richard Bac=
kman, Annabelle
>>>>>>>>> >>>>>>>> > wrote:
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> Hi all,
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> The current drafts of PAR (-00) and J=
AR (-20) require
>>>>>>>>> that the AS transform all pushed requests into JWTs. This
>>>>>>>>> requirement arises from the following:
>>>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=A2 PAR uses the request_uri parameter defined in
>>>>>>>>> JAR to communicate the pushed request to the authorization
>>>>>>>>> endpoint.
>>>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=A2 According to JAR, the resource referenced by
>>>>>>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>> =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=A2 Request Object is defined to be a JWT
>>>>>>>>> containing all the authorization request parameters. (Section 2=
=2E1)
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> There is no need for this requirement=
 to support
>>>>>>>>> interoperability, as this is internal to the AS. It is also
>>>>>>>>> inconsistent with the rest of JAR, which avoids attempting to
>>>>>>>>> define the internal communications between the two AS
>>>>>>>>> endpoints. Worse, this restriction makes it harder for the
>>>>>>>>> authorization endpoint to leverage validation and other work
>>>>>>>>> performed at the PAR endpoint, as the state or outcome of that
>>>>>>>>> work must be forced into the JWT format (or retrieved via a
>>>>>>>>> subsequent service call or database lookup).
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman
>>>>>>>>> =C2=A0=C2=A0=C2=A0 > AWS Identity
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0> _____________________________________=
__________
>>>>>>>>> =C2=A0=C2=A0=C2=A0 > OAuth mailing list
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf.org 
>>>>>>>>> =C2=A0=C2=A0=C2=A0 >=C2=A0https://www.ietf.org/mailman/listinfo=
/oauth
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>> _______________________________________________
>>>>>>>> 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.=C2=A0 If you have received this
>>>>>>> communication in error, please notify the sender immediately by
>>>>>>> e-mail and delete the message and any file attachments from your
>>>>>>> computer. Thank you./*
>>>>>
>>>>> */CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s).
>>>>> Any review, use, distribution or disclosure by others is strictly
>>>>> prohibited..=C2=A0 If you have received this communication in error=
,
>>>>> please notify the sender immediately by e-mail and delete the
>>>>> message and any file attachments from your computer. Thank you./*
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> --=20
>> Vladimir Dzhuvinov
>
--=20
Vladimir Dzhuvinov


--------------583CDDD29DB97E6904C6E664
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 13/01/2020 19:32, Justin Richer
      wrote:

    

    

      
      To be clear, I=E2=80=99m not saying we suggest a particular form, a=
nd I
      agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s =
a JWT=E2=80=9D or something of
      that nature. But if we call the result of PAR =E2=80=9Cthing X=E2=80=
=9D and the
      target of request_uri =E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=
=99re compatible
      without saying what =E2=80=9Cthing X=E2=80=9D needs to be in all ca=
ses. 

    

    
Good, we're on the same page then.

    
How about simply saying that the result of PAR is an URI
      referencing the pushed authZ request; at the authZ endpoint its
      processing is completed.

    
No need is both clear and abstract enough to not require a form
      to be specified.

    

    


    

    

      
In cases where you do a remote look up, we want
        =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT. 

      

    

    
But why?

    
Both PAR and authZ endpoints belong to the AS, which makes that
      impl specific. The URI is the contract, between client and AS.

    
The AS, if uService based, could choose to implement that as CBOR
      Web Token, or some other verifiable blob, resulting in the same
      essential function, and this isn't affecting the client <->
      AS contract in any way.

    

    


    

    

      
We had a case of similarly unintentional limiting i=
n
        JAR previously, saying that you had to do an HTTP lookup on the
        request_uri, but I believe that=E2=80=99s been backed off now and=
 made
        conditional.

    

    
That was precisely my point.

    
Vladimir

    

    


    

    


    

    

      
=C2=A0=E2=80=94 Justin

        


          

            
On Jan 11, 2020, at 5:28 AM, Vladimir
              Dzhuvinov <vladimir@connect2id.c=
om>
              wrote:

            

            

              
              

                
My suggestion is to abstain from specifying=

                  the concrete form of the resource pointed to by the
                  PAR URI. Regardless of URI type (URN, downloadable
                  https URL or something else), and even if the PAR
                  endpoint and the authZ endpoint are managed by two
                  different entities (microservice or other scenario).
                
In the Connect2id implementation of PAR the=

                  returned URI doesn't point to a request object and it
                  doesn't point to a JWT either. It points to an
                  internally stored "pre-processed" authZ request, which
                  the authZ endpoint then picks up to complete the
                  authZ.

                
Even if we eventually end up in microservic=
e
                  world, or allow the PAR endpoint to be managed by some
                  external entity, the PAR URI - its interpretation,
                  validation and potentially resource retrieval (JWT or
                  other blob), is an "internal contract" on the AS side.
                  This doesn't concern the client, and in OAuth 2.0 the
                  role of AS is indivisible.

                


                

                
I see PAR request + authZ request as one
                  logical OAuth 2.0 authZ request: the client submits an
                  authZ request and gets an authZ response at the end.
                  The URI is necessary for the client to proceed from
                  the 1st to the 2nd step. If we manage to frame / word
                  the PAR URI in this logical way, without getting stuck
                  in the JAR definition / framing of what the
                  request_uri / object is, it would be great.

                


                

                
The normative language I think should focus=

                  on maintaining the OAuth 2.0 contract for the entire
                  logical authZ request, together with the basic
                  contracts of 1) JAR and the 2) authZ endpoint.

                

                


                

                
Vladimir

                

                


                

                
On 10/01/2020 22:55, Justi=
n
                  Richer wrote:

                

                

                  
                  So we could solve this by saying the resulting data
                  object of a PAR is a request object. Which might also
                  contain a request object internally as well. In that
                  case JAR should back off from saying it=E2=80=99s a JWT=
 and
                  instead say it=E2=80=99s a request object. Or we define=
 a new
                  term for this authorization request blob thing.
                  


                  

                  
Or PAR could at least say that if it=E2=
=80=99s
                    dereferenced over a remote protocol then it MUST be
                    a JWT, but otherwise it can be whatever you want.
                    That=E2=80=99s where the real interop concerns come i=
n.

                  


                  

                  
=C2=A0=E2=80=94 Justin

                    


                      

                        
On Jan 10, 2020, at 3:41 PM,
                          Richard Backman, Annabelle <richanna=3D=
40amazon.com@dmarc.ietf.org>
                          wrote:

                        

                        

                          

                            
Correct. The proble=
m
                              becomes pretty clear in the context of
                              PAR, where the AS is generating and
                              vending out the URI at the PAR endpoint,
                              and consuming it at the authorization
                              endpoint. From an interoperability
                              standpoint, it=E2=80=99s analogous to the A=
S
                              vending an authorization code at the
                              authorization endpoint and consuming it at
                              the token endpoint.
                            

                            

                              
=E2=
=80=93=C2=A0

                              
A=
nnabelle
                                  Richard Backman

                              
A=
WS
                                  Identity
                            

                            
=C2=
=A0

                            
=C2=
=A0

                            

                              
From:=C2=
=A0J=
ohn
                                  Bradley <v=
e7jtb@ve7jtb.com>

                                  Date:=C2=
=A0Friday,
                                  January 10, 2020 at 12:29 PM

                                  To:=C2=
=A0Brian
                                  Campbell <b=
campbell@pingidentity.com>

                                  Cc:=C2=
=A0Torsten
                                  Lodderstedt <t=
orsten@lodderstedt.net>,
                                  Nat Sakimura <n=
at@sakimura.org>,
                                  "Richard Backman, Annabelle" <r=
ichanna@amazon.com>,
                                  oauth <o=
auth@ietf.org>

                                  Subject:=C2=
=A0[UNVERIFIED
                                  SENDER] Re: [OAUTH-WG] PAR: pushed
                                  requests must become JWTs

                            

                            

                              
=C2=
=A0

                            

                            

                              

                                
If we assume th=
e
                                  client posts a JAR and gets back a
                                  reference.=C2=A0 Then the reference is =
to a
                                  JAR.=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
I think I see
                                  the problem.=C2=A0 If the server provid=
ing
                                  the reference is associated with the
                                  AS then the server dosen't need to
                                  dereference the object via HTTP, so it
                                  could be a URN as an example.=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
So yes it is no=
t
                                  a interoperability issue for the
                                  client.=C2=A0=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
I will think
                                  about how I can finesse that.=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
I agree it is
                                  not a change in intent.=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
I will see if I=

                                  can get our AD to accept that.

                              

                              

                                
=C2=A0

                              

                              

                                
John B.=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
=C2=A0

                              

                            

                            
=C2=
=A0

                            

                              

                                
On Fri, Jan 10,=

                                  2020, 4:57 PM Brian Campbell <b=
campbell@pingidentity.com>
                                  wrote:

                              

                              

                                

                                  
Sure=

                                    but the text proposed (or something
                                    like it) qualifies it such that
                                    there aren't interoperability
                                    questions because it's only an
                                    implementation detail to the AS who
                                    both produces the URI and consumes
                                    its content.
                                

                                
=C2=A0

                                

                                  

                                    
On Fri, Jan 10, 2020 at
                                      12:48 PM John Bradley <ve7jtb@v=
e7jtb.com>
                                      wrote:

                                  

                                  

                                    

                                      

                                        
It may
                                          be a challenge to change text
                                          saying that the contents of
                                          the resource could be
                                          something other than a request
                                          object.=C2=A0

                                      

                                      

                                        
=C2=A0
=

                                      

                                      

                                        
If not =
a
                                          request object then what and
                                          how is that interoperable are
                                          likely AD questions.=C2=A0

                                      

                                      

                                        
=C2=A0
=

                                      

                                      

                                        
I could=

                                          perhaps see changing it to
                                          must be a request object, or
                                          other format defined by a
                                          profile.

                                          

                                          John B.=C2=A0=C2=A0

                                      

                                      

                                        
=C2=A0
=

                                      

                                      

                                        
=C2=A0
=

                                        

                                          

                                            
On
                                              Fri, Jan 10, 2020, 3:45 PM
                                              Brian Campbell <=
bcampbell@pingidentity.com>
                                              wrote:

                                          

                                          

                                            

                                              

                                                
Agree
                                                  and agree. But given
                                                  that the change
                                                  suggested by Annabelle
                                                  has no impact on the
                                                  client or
                                                  interoperability,
                                                  perhaps Nat or John
                                                  could work the change
                                                  into the draft during
                                                  the edits that happen
                                                  during the final
                                                  stages of things?
                                              

                                              
=C2=A0

                                              

                                                

                                                  
On Thu, Ja=
n
                                                    9, 2020 at 1:56 AM
                                                    Torsten Lodderstedt
                                                    <torsten=3D40lodderstedt.net@dmarc.ietf.org>
                                                    wrote:

                                                

                                                

                                                  

                                                    

                                                      
I woul=
d
                                                        assume given the
                                                        status of JAR,
                                                        we don=E2=80=99t =
want to
                                                        change it. And
                                                        as I said, this
                                                        difference does
                                                        not impact
                                                        interoperability
                                                        from client
                                                        perspective.

                                                    

                                                    

                                                      


                                                        

                                                        <=
/o:p>

                                                      

                                                        
Am=

                                                          09.01.2020 um
                                                          00:58 schrieb
                                                          Richard
                                                          Backman,
                                                          Annabelle
                                                          <richanna=3D=
40amazon.com@dmarc.ietf.org>:

                                                      

                                                    

                                                    

                                                      

                                                        

                                                          
It
                                                          would be more
                                                          appropriate to
                                                          add the text
                                                          to JAR rather
                                                          than PAR. It
                                                          doesn't seem
                                                          right for PAR
                                                          to retcon
                                                          rules in JAR.
                                                          Moving the
                                                          text to JAR
                                                          also
                                                          highlights the
                                                          weirdness of
                                                          giving PAR
                                                          special
                                                          treatment.

                                                          
=C2=A0

                                                          
What
                                                          if we changed
                                                          this sentence
                                                          in Section 5.2
                                                          of JAR:

                                                          
The contents o=
f
                                                          the resource
                                                          referenced by
                                                          the URI MUST
                                                          be a Request

                                                          
Object.=


                                                          
=C2=A0

                                                          
To:=C2=A0
=

                                                          
The contents o=
f
                                                          the resource
                                                          referenced by
                                                          the URI MUST
                                                          be a Request

                                                          
Object, unless=

                                                          the URI was
                                                          provided to
                                                          the client by
                                                          the
                                                          Authorization

                                                          
Server.=


                                                          
=C2=A0

                                                          
This
                                                          would allow
                                                          for use cases
                                                          such as an AS
                                                          that provides
                                                          pre-defined
                                                          request URIs,
                                                          or vends
                                                          request URIs
                                                          via a client
                                                          management
                                                          console, or
                                                          bakes them
                                                          into their
                                                          client apps.

                                                          
=C2=A0

                                                          
=E2=80=93=C2=A0
=

                                                          
Annabelle
                                                          Richard
                                                          Backman

                                                          
AWS
                                                          Identity

                                                          
=C2=A0

                                                          
On
                                                          1/8/20, 2:50
                                                          PM, "Torsten
                                                          Lodderstedt"
                                                          <torsten=3D<=
a
href=3D"mailto:40lodderstedt.net@dmarc.ietf.org" target=3D"_blank"
                                                          style=3D"color:=

                                                          purple;
                                                          text-decoration=
:
                                                          underline;"
                                                          class=3D""
                                                          moz-do-not-send=
=3D"true">40lodderstedt.net@dmarc.ietf.org>
                                                          wrote:

                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0
                                                          Hi,=C2=A0

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0you
                                                          are right, PAR
                                                          does not
                                                          require the AS
                                                          to represent
                                                          the request as
                                                          a JWT-based
                                                          request
                                                          object. The
                                                          URI is used as
                                                          internal
                                                          reference
                                                          only. That why
                                                          the draft
                                                          states

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0"There
                                                          is no need to
                                                          make the

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          authorization
                                                          request data
                                                          available to
                                                          other parties
                                                          via this

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          URI.=E2=80=9D

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0This
                                                          difference
                                                          matters from
                                                          an AS
                                                          implementation
                                                          perspective,
                                                          it doesn't
                                                          matter from a
                                                          client's
                                                          (interop)
                                                          perspective.

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0We
                                                          may add a
                                                          statement to
                                                          PAR saying
                                                          that
                                                          request_uris
                                                          issued by the
                                                          PAR mechanism
                                                          (MAY) deviate
                                                          from the JAR
                                                          definition.

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0best
                                                          regards,

                                                          
=C2=A0=C2=A0=C2=A0
                                                          Torsten.=C2=A0<=
span
class=3D"Apple-converted-space">=C2=A0
=

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

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          On 8. Jan
                                                          2020, at
                                                          23:42, Richard
                                                          Backman,
                                                          Annabelle
                                                          <richanna=3D=
40amazon.com@dmarc.ietf.org>
                                                          wrote:

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          Hi all,

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          The current
                                                          drafts of PAR
                                                          (-00) and JAR
                                                          (-20) require
                                                          that the AS
                                                          transform all
                                                          pushed
                                                          requests into
                                                          JWTs. This
                                                          requirement
                                                          arises from
                                                          the following:<=
o:p
                                                          class=3D"">

                                                          
=C2=A0=C2=A0=C2=A0
                                                          > =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2
                                                          PAR uses the
                                                          request_uri
                                                          parameter
                                                          defined in JAR
                                                          to communicate
                                                          the pushed
                                                          request to the
                                                          authorization
                                                          endpoint.

                                                          
=C2=A0=C2=A0=C2=A0
                                                          > =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2
                                                          According to
                                                          JAR, the
                                                          resource
                                                          referenced by
                                                          request_uri
                                                          MUST be a
                                                          Request
                                                          Object.
                                                          (Section 5.2)

                                                          
=C2=A0=C2=A0=C2=A0
                                                          > =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2
                                                          Request Object
                                                          is defined to
                                                          be a JWT
                                                          containing all
                                                          the
                                                          authorization
                                                          request
                                                          parameters.
                                                          (Section 2.1)

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          There is no
                                                          need for this
                                                          requirement to
                                                          support
                                                          interoperabilit=
y,
                                                          as this is
                                                          internal to
                                                          the AS. It is
                                                          also
                                                          inconsistent
                                                          with the rest
                                                          of JAR, which
                                                          avoids
                                                          attempting to
                                                          define the
                                                          internal
                                                          communications
                                                          between the
                                                          two AS
                                                          endpoints.
                                                          Worse, this
                                                          restriction
                                                          makes it
                                                          harder for the
                                                          authorization
                                                          endpoint to
                                                          leverage
                                                          validation and
                                                          other work
                                                          performed at
                                                          the PAR
                                                          endpoint, as
                                                          the state or
                                                          outcome of
                                                          that work must
                                                          be forced into
                                                          the JWT format
                                                          (or retrieved
                                                          via a
                                                          subsequent
                                                          service call
                                                          or database
                                                          lookup).

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          =E2=80=93=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
                                                          Annabelle
                                                          Richard
                                                          Backman

                                                          
=C2=A0=C2=A0=C2=A0
                                                          > AWS
                                                          Identity

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0>
_______________________________________________
                                                          
=C2=A0=C2=A0=C2=A0
                                                          > OAuth
                                                          mailing list

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0OAuth@ietf.org

                                                          
=C2=A0=C2=A0=C2=A0
                                                          >=C2=A0https://www.ietf.org/mailman/listinfo/oauth

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

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

                                                        

                                                      

                                                    

                                                  

                                                  
__________=
_____________________________________

                                                    OAuth mailing list
                                                    OAuth@ietf.org

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

                                              

                                            

                                            

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


                                          

                                        

                                      

                                    

                                  

                                

                                

=

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

                              

                            

                          

                          ______________=
_________________________________

                          OAuth mailing
                            list

                          OAuth@ietf.org=


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

                      

                    

                    

                  

                  

                  

                  
________________=
_______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list=
info/oauth


                

                
--=20
Vladimir Dzhuvinov

              

            

          

        

        

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------583CDDD29DB97E6904C6E664--

--------------ms050200030807070704090400
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTUyMDMzMTVaMC8G
CSqGSIb3DQEJBDEiBCBWQ3mSiFmap4Hz+7dSorT+KUs2ZQcDz2Tmq2JYIo7snzBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAIQiiKKiXrGHKnrmvrNAeIu+lbvm+nmujrylpdQMsz77m7FM
sPotAN5rBRcO5xiXBlL0VYz08Row8rm8dC8FeQfyRkABGQKZ6fhTz0maqlupE0jRQdhlAIdw
6WcMguoWVRvcnfJYgXVthzCe5W/gu4UPy4XDcULEx2d2GJDo3H+UybQYRQb/pehoRDN1GDD8
1h4Azu+SlpSLJ5P4Kw3ipFUtmDHhixDbHhMzBFdNveRa87+9fRc1zo8r27P9/igMU4AndWYU
FGJLIGEsGsqVA5nm9Sfm4O1vt2tFabils3ab6o4R+Ew/pVyqoun69VUO9L2VNvp+pAELbNmC
LtWSOKsAAAAAAAA=
--------------ms050200030807070704090400--


From nobody Wed Jan 15 12:43:33 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 6CF65120935 for ; Wed, 15 Jan 2020 12:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 PKK8birFe0-E for ; Wed, 15 Jan 2020 12:43:30 -0800 (PST)
Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (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 2D84812089C for ; Wed, 15 Jan 2020 12:43:30 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpVfir91sRMh6rpVgiTbeA; Wed, 15 Jan 2020 13:43:29 -0700
To: Benjamin Kaduk , Justin Richer 
Cc: oauth , Nat Sakimura , "Richard Backman, Annabelle" 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>   <20200114044627.GM66991@kduck.mit.edu>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <7550b441-c598-c2a6-041f-417f7c2c18a3@connect2id.com>
Date: Wed, 15 Jan 2020 22:43:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <20200114044627.GM66991@kduck.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090101020902050505020002"
X-CMAE-Envelope: MS4wfIc2o/ZHi7MN52HEdZOAy62xeCtWR8suhGIyLprlJOD3xE5ceLdhWdVNdRKLA1PLDTaSsMgVOVUFnJBo0tHDdpoq2LywrvcAKkWm2mshkKOkzVIgAKS+ dqsQU22wfekxmcaLba7BYM1nQqJcmblQeklUp1YiW8O587EoZdJSGpOukHlpURCW05TmSsueIbS7BZEI4hCZjHy7o4EeMm5ZCOwhFNhpVk6zNRjXLpmgaboo 6iY7JPXbKo12GP/P9hit/TR1yxicDU5SOCCTKrf19+iSUEbe6Edqt0oJcSZFcsyL
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 20:43:32 -0000

This is a cryptographically signed message in MIME format.

--------------ms090101020902050505020002
Content-Type: multipart/alternative;
 boundary="------------2CDB599C186E5EA81E37FC09"
Content-Language: en-US

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

On 14/01/2020 06:46, Benjamin Kaduk wrote:
> On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
>> To be clear, I=E2=80=99m not saying we suggest a particular form, and =
I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JW=
T=E2=80=9D or something of that nature. But if we call the result of PAR =
=E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing X=E2=
=80=9D in JAR, then we=E2=80=99re compatible without saying what =E2=80=9C=
thing X=E2=80=9D needs to be in all cases.=20
>>
> That seems fair.  What properties would a given "thing X" need to have =
in
> order to work, though -- uniqueness over a specific period of time?
> Unpredictability?  More?

 1. That the request_uri uniquely points to the submitted authZ request
    for the duration of the request_uri lifetime (defined by the
    expires_in response parameter).
 2. The request_uri cannot be reasonably guessed.

I think that's all we need Ben.

Vladimir



--------------2CDB599C186E5EA81E37FC09
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 14/01/2020 06:46, Benjamin Kaduk
      wrote:

    

    

      
On Mon, Jan 13, 2020 at 12:3=
2:41PM -0500, Justin Richer wrote:


      

        
To be clear, I=E2=80=99m n=
ot saying we suggest a particular form, and I agree that we shouldn=E2=80=
=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or something of th=
at nature. But if we call the result of PAR =E2=80=9Cthing X=E2=80=9D and=
 the target of request_uri =E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=
=99re compatible without saying what =E2=80=9Cthing X=E2=80=9D needs to b=
e in all cases.=20



      

      
That seems fair.  What properties would a given "thing X" need to have in=

order to work, though -- uniqueness over a specific period of time?
Unpredictability?  More?

    

    
    
      
  1. That the request_uri uniquely points to the submitted authZ
        request for the duration of the request_uri lifetime (defined by
        the expires_in response parameter).
    2. 
      
  2. The request_uri cannot be reasonably guessed.
    
      
    3. 
    

    
I think that's all we need Ben.

    

    
Vladimir

    

    


    

  


--------------2CDB599C186E5EA81E37FC09--

--------------ms090101020902050505020002
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTUyMDQzMjZaMC8G
CSqGSIb3DQEJBDEiBCD/aNXOZZPFEivgz40pMcDu4E+Ypd4RSOLe/azCNHDX/jBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAKCn9+pgrMSo8b1r08YV90Fy9NHqDP7jgs2AXDCmXibeytGz
t8+Flt3Z/X6z3OpLSdWpv3gEKm5qHf+DJfmx5VFRgkxq4TaD40ZjRV+AGtz9iw2CCenG14tL
GK6LSieiXCblP+iXCJMrzxdclZyxalKAkLa8HVyuRJWL3Rjrk02P08iT9yGAOLdJB9XKdP+z
t/CZ60W4pyuFOo0gvm+SDwjC6p5K+ft1g4RXGn0GOzmbZsNi5KUNRsIUIa0+jmc27Ycvz6ml
VJXhdJZGsr/CS/FE5YnXLyjmm+Qfxu4b/BeKL6lRDsEJTZ2LmM78pWzAHTji2/Z4TxhWNq80
Qr4nUZ4AAAAAAAA=
--------------ms090101020902050505020002--


From nobody Wed Jan 15 12:53: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 0311112088C for ; Wed, 15 Jan 2020 12:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 8cSZAg6VkQTm for ; Wed, 15 Jan 2020 12:53:03 -0800 (PST)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 3EA6B120288 for ; Wed, 15 Jan 2020 12:53:03 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpeui5tHgQTQBrpevi1oz5; Wed, 15 Jan 2020 13:53:02 -0700
To: oauth@ietf.org
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com>
Date: Wed, 15 Jan 2020 22:53:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050508000100030506040607"
X-CMAE-Envelope: MS4wfIsqhl7DlMgnAFUEkwcIdt4/yO+G+FeMxxmWEkM3+peoGPMe4G2zqsvsNAa1C1IIJC6HSpMcEjX36KOBO4XbvGTANcNwV474cX9oz4E+vf7mzSy4Txi2 p2ojx/KXWVZELc0afXcN7BNT4WI5cQX/uPRy23um7PueSTzSAwENQZKY
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 20:53:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms050508000100030506040607
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

On 14/01/2020 04:25, Justin Richer wrote:
> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on a URL-b=
ased addressing
> format for individual keys within the set, but that ship=E2=80=99s sail=
ed.

For querying / selecting JWKs from a set this would have been a useful
addition to the spec.

But I don't see how such an URL can help us to identify a single JWK in
a set, given the possibility to have multiple JWKs with the same "kid".

I.e. if we do "https://example.com/jwks.json?kid=3Dxyz", there is no
guarantee for a single key. Even if we add additional query params, like
use, alg, etc, none of them guarantees a unique JWK identification.

I like the utility of that though.

Vladimir



--------------ms050508000100030506040607
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTUyMDUzMDBaMC8G
CSqGSIb3DQEJBDEiBCAKeRZuBf2WmK8XH89l4L+r8g35REjCdoj75xOg3TOPMDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBALNyTuDXnG2uDu27Euzu0mKGt0c3N+Vp2ItT5bIhd/3JsrE7
5w65GB1ZC9P5unaIZECGk+k7vAcRBj0JDn9Y8h1B0dCcnQCrgfoC/g7po/odNtqaOk/LR5xA
D9lTD6X740JB4h0dm2xsxSIp0od/jT0H2GVJL6aINO5cd0iVNaajfGxTXrMnMmcjBf0gxlKT
C3i3sn55U/TdKJmNi/XPGzg/R6JOto92SbKbPRez+KVg3J6Oqm3vCnzpuAbR+fz3NKJTJ80s
YtbvLmUa83pU4GDrTg3B3Ekp2Zf0rE6ZTlYvIcLIUiLNIgJhr9oXxssM4ZrnNmZi0aA2Y+n8
0e4LQvIAAAAAAAA=
--------------ms050508000100030506040607--


From nobody Wed Jan 15 13:02: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 5C234120967 for ; Wed, 15 Jan 2020 13:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level: 
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 8zW8VTDbt5TE for ; Wed, 15 Jan 2020 13:02:36 -0800 (PST)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (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 3C310120288 for ; Wed, 15 Jan 2020 13:02:36 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpo9iNOTlXcz7rpoAiK0yL; Wed, 15 Jan 2020 14:02:35 -0700
To: Takahiko Kawasaki 
Cc: John Bradley , Mike Jones , IETF oauth WG 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
Date: Wed, 15 Jan 2020 23:02:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000105080308070105030007"
X-CMAE-Envelope: MS4wfNrQBc0l2t8XXcP5/T7/ZMh0kMqx0KjGFMU6N8N0yNVBdhwCAl0dva5m7BZQbSOjt3toTLFrHd7j1z6osLsckItjwFnRJD6k+Q71MQII0qHfXa327kOH GC+qEeLza+hE+6ruRC3OlLIYC5tsla9dDY4vbkRKqJZNP58HRr8KFIClX89xomjnvMPn2e6qTYNXUkq4ppn+lxQhUWAEV6vhpwkWBQb9JJ2BJuLo3LljnJXh DOYicbuFXAOFbdoeiR02P9Xkd0hYIdWNVvKjt+I7vQI=
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Wed, 15 Jan 2020 21:02:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms000105080308070105030007
Content-Type: multipart/alternative;
 boundary="------------EC134B8008BD2322F29F8988"
Content-Language: en-US

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


On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not be
> referred to" is like "putting the cart before the horse". Why do we
> have to avoid using the traditional client_id request parameter so
> stubbornly?
>
> The last paragraph of Section 3.2.1
>  of RFC 6749 says
> as follows.
>
>     /A client MAY use the "client_id" request parameter to identify
>     itself when sending requests to the token endpoint.=C2=A0 In the
>     "authorization_code" "grant_type" request to the token endpoint,
>     *an unauthenticated client MUST send its "client_id" to prevent
>     itself from inadvertently accepting a code intended for a client
>     with a different "client_id".* =C2=A0This protects the client from
>     substitution of the authentication code. =C2=A0(It provides no
>     additional security for the protected resource.)/
>
>
> If the same reasoning applies, a client_id must always be sent with
> request / request_uri because client authentication is not performed
> at the authorization endpoint. In other words, */an unauthenticated
> client (every client is unauthenticated at the authorization endpoint)
> MUST send its "client_id" to prevent itself from inadvertently
> accepting a request object for a client with a different "client_id"./*=

>
Identifying the client in JAR request_uri requests can be really useful
so that an AS which requires request_uri registration to prevent DDoS
attacks and other checks can do those without having to index all
request_uris individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist
on no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't
particularly transparent to WG members.

Vladimir


> Best Regards,
> Taka
>
>
>
> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov
> > wrote:
>
>     John, thanks, much appreciated!
>
>     On 11/01/2020 21:36, John Bradley wrote:
>>
>>     Yes JAR is not prohibiting paramater replication in the header.=C2=
=A0
>>
>>     I will see if i can add something in final edits to call that out.=

>>
>>     John B.
>>
>>     On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>>
>>>     Thanks Mike for the rfc7519 section-5.3
>>>      pointer. Can
>>>     this parameter replication be used for client_id or the
>>>     client_id ass "iss" even though it isn't explicitly mentioned in
>>>     the JAR spec?
>>>
>>>     On 11/01/2020 02:58, John Bradley wrote:
>>>>     Right we just don't say to put the iss there in OIDC if it's
>>>>     symetricly encrypted.
>>>
>>>     OIDC doesn't have the symmetric key selection issue, I suppose
>>>     that why the possibility to replicate params to the JWE header
>>>     isn't mentioned at all. OIDC requires the top-level query params
>>>     to represent a valid OAuth 2.0 request, and there client_id is
>>>     required. If the client_id is present the client registration
>>>     together with any present client_secret can be retrieved.
>>>
>>>     I reread the JAR spec, this is the only place that mentions
>>>     handling of symmetric JWE.
>>>
>>>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10=
=2E2
>>>
>>>>        (b)  Verifying that the symmetric key for the JWE encryption =
is the
>>>>             correct one if the JWE is using symmetric encryption.
>>>
>>>
>>>     Vladimir
>>>
>>>
>>>>
>>>>     On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>>>     >>>     > wrote:
>>>>
>>>>         The technique of replicating JWT claims that need to be
>>>>         publicly visible in an encrypted JWT in the header is
>>>>         defined at
>>>>         https://tools.ietf.org/html/rfc7519#section-5.3.=C2=A0 (Than=
ks
>>>>         to Dick Hardt for bringing this need to my attention as we
>>>>         were finishing the JWT 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 >>>         > *On Behalf Of * John Bradle=
y
>>>>         *Sent:* Friday, January 10, 2020 2:15 PM
>>>>         *To:* Vladimir Dzhuvinov >>>         >
>>>>         *Cc:* IETF oauth WG >=

>>>>         *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured
>>>>         Authorization Request (JAR) vs OIDC request object
>>>>
>>>>         =C2=A0
>>>>
>>>>         The intent was to do that, but specs change once the OAuth
>>>>         WG and IESG get there hands on them.=C2=A0=C2=A0
>>>>
>>>>         =C2=A0
>>>>
>>>>         Being backwards compatible with OIDC is not a compelling
>>>>         argument to the IESG.
>>>>
>>>>         =C2=A0
>>>>
>>>>         We were mostly thinking of asymmetric encryption.=C2=A0=C2=A0=

>>>>
>>>>         =C2=A0
>>>>
>>>>         Specifying puting the issuer and or the audience in the
>>>>         headder has come up in the past but probably is not
>>>>         documented.=C2=A0=C2=A0
>>>>
>>>>         =C2=A0
>>>>
>>>>         John B=C2=A0
>>>>
>>>>         =C2=A0
>>>>
>>>>         On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>>>         >
>>>>         wrote:
>>>>
>>>>             Yes, putting the client_id into the JWE header is a way
>>>>             around the need
>>>>             to have the client_id outside the JWE as top-level
>>>>             authZ request parameter.
>>>>
>>>>             Unfortunately this work around isn't mentioned
>>>>             anywhere, I just checked
>>>>             the most recent draft-ietf-oauth-jwsreq-20.
>>>>
>>>>             Our DDoS attack mitigation (for OIDC request_uri) also
>>>>             relies on the
>>>>             presence of client_id as top-level parameter, together
>>>>             with requiring
>>>>             RPs to register their request_uri's (so that we don't
>>>>             need to build and
>>>>             store an index of all request_uri's). I just had a look
>>>>             at "DDoS Attack
>>>>             on the Authorization Server" and also realised the
>>>>             request_uri
>>>>             registration isn't explicitly mentioned as attack
>>>>             prevention ("the
>>>>             server should (a) check that the value of "request_uri"
>>>>             parameter does
>>>>             not point to an unexpected location").
>>>>
>>>>             https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#s=
ection-10.4.1
>>>>             
>>>>
>>>>             To be honest, I feel quite bad about the situation with
>>>>             JAR we are in
>>>>             now. For some reason I had the impression that OAuth
>>>>             JAR was going to be
>>>>             the OIDC request / request_uri for general OAuth 2.0
>>>>             use, as with other
>>>>             OIDC bits that later became general purpose OAuth 2.0
>>>>             specs.
>>>>
>>>>             I find it unfortunate I didn't notice this when I was
>>>>             reviewing the spec
>>>>             in the past.
>>>>
>>>>             Vladimir
>>>>
>>>>
>>>>             On 10/01/2020 22:39, Filip Skokan wrote:
>>>>             > Vladimir,
>>>>             >
>>>>             > For that very case the payload claims may be repeated
>>>>             in the JWE protected header. An implementation wanting
>>>>             to handle this may look for iss/client_id there.
>>>>             >
>>>>             > Odesl=C3=A1no z iPhonu
>>>>             >
>>>>             >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>>>>             >:
>>>>             >>
>>>>             >> =EF=BB=BFI just realised there is one class of JARs w=
here
>>>>             it's practially
>>>>             >> impossible to process the request if merge isn't
>>>>             supported:
>>>>             >>
>>>>             >> The client submits a JAR encrypted (JWT) with a
>>>>             shared key. OIDC allows
>>>>             >> for that and specs a method for deriving the shared
>>>>             key from the
>>>>             >> client_secret:
>>>>             >>
>>>>             >>
>>>>             https://openid.net/specs/openid-connect-core-1_0.html#En=
cryption
>>>>             =

>>>>             >>
>>>>             >> If the JAR is encrypted with the client_secret, and
>>>>             there is no
>>>>             >> top-level client_id parameter, there's no good way
>>>>             for the OP to find
>>>>             >> out which client_secret to get to try to decrypt the
>>>>             JWE. Unless the OP
>>>>             >> keeps an index of all issued client_secret's.
>>>>             >>
>>>>             >>
>>>>             >> OP servers which require request_uri registration
>>>>             >> (require_request_uri_registration=3Dtrue) and don't
>>>>             want to index all
>>>>             >> registered request_uri's, also have no good way to
>>>>             process a request_uri
>>>>             >> if the client_id isn't present as top-level parameter=
=2E
>>>>             >>
>>>>             >>
>>>>             >> Vladimir
>>>>             >>
>>>>             >>
>>>>             >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>>             >>>
>>>>             >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>>>>             >:
>>>>             >>>> I think Torsten is speculating that is not a
>>>>             feature people use.=C2=A0 =C2=A0
>>>>             >>> I=E2=80=99m still trying to understand the use case =
for
>>>>             merging signed and unsigned parameters. Nat once
>>>>             explained a use case, where a client uses parameters
>>>>             signed by a 3rd party (some =E2=80=9Ecertification autho=
rity=E2=80=9C)
>>>>             in combination with transaction-specific parameters. Is
>>>>             this being done in the wild?
>>>>             >>>
>>>>             >>> PS: PAR would work with both modes.
>>>>
>>>>
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org 
>>>>             https://
>>>>             
>>>>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
--=20
Vladimir Dzhuvinov


--------------EC134B8008BD2322F29F8988
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    
On 14/01/2020 19:20, Takahiko Kawasaki=

      wrote:

    

    

      
      
Well, embedding a client_=
id
        claim in the JWE header in order to achieve "request parameters
        outside the request object should not be referred to" is like
        "putting the cart before the horse". Why do we have to avoid
        using the traditional client_id
        request parameter so stubbornly?
        


        

        
The last paragraph of Section 3.2.1 of RFC 6749 says a=
s
          follows.

          

        

        

          
A client MAY use the "client_id" request parameter to
              identify itself when sending requests to the token
              endpoint.=C2=A0 In the "authorization_code" "grant_type"
              request to the token endpoint, an unauthenticated
                client MUST send its "client_id" to prevent itself from
                inadvertently accepting a code intended for a client
                with a different "client_id". =C2=A0This protects the=

              client from substitution of the authentication code. =C2=A0=
(It
              provides no additional security for the protected
              resource.)

        

        

          


          

          
If the same reasoning applies, a =
client_id
            must always be sent with request
            / request_uri because client
            authentication is not performed at the authorization
            endpoint. In other words, an unauthenticated client
                (every client is unauthenticated at the authorization
                endpoint) MUST send its "client_id" to prevent itself
                from inadvertently accepting a request object for a
                client with a different "client_id".

          


          

        

      

    

    
Identifying the client in JAR request_uri requests can be really
      useful so that an AS which requires request_uri registration to
      prevent DDoS attacks and other checks can do those without having
      to index all request_uris individually. I mentioned this before.
    
I really wonder what the reasoning of the IESG reviewers was to
      insist on no params outside the JAR JWT / request_uri.

    
I'm beginning to realise this step of the review process isn't
      particularly transparent to WG members.

    
Vladimir

    

    


    

    

      

        
Best Regards,

        
Taka

        


        

        


        

      

      

      

        
On Tue, Jan 14, 2020 at 12:=
57
          AM Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        
=

          

            
John, thanks, much appreciated!

            

            
On 11/01/2020 21:36, John Bradley wrote:

            

            

              
Yes JAR is not prohibiting paramater replication in the
                header.=C2=A0 

              

              
I will see if i can add something in final edits to
                call that out.

              
John B.

              

              
On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:

              

              

                
Thanks Mike for the rfc7519
                      section-5.3 pointer. Can this parameter
                    replication be used for client_id or the client_id
                    ass "iss" even though it isn't explicitly mentioned
                    in the JAR spec?

                  

                
On 11/01/2020 02:58, John Bradley wrote:

                

                

                  
Right we just don't say to put the is=
s
                    there in OIDC if it's symetricly encrypted. 

                  

                

                
OIDC doesn't have the symmetric key selection issue,
                  I suppose that why the possibility to replicate params
                  to the JWE header isn't mentioned at all. OIDC
                  requires the top-level query params to represent a
                  valid OAuth 2.0 request, and there client_id is
                  required. If the client_id is present the client
                  registration together with any present client_secret
                  can be retrieved. 

                

                
I reread the JAR spec, this is the only place that
                  mentions handling of symmetric JWE.

                

                
https://to=
ols.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

                

                
 

                

                  
   (b)  Verifying that the symmetric key for the J=
WE encryption is the
        correct one if the JWE is using symmetric encryption.

                

                


                

                
Vladimir

                


                

                


                  

                    
On Fri, Jan 10,=

                      2020, 9:41 PM Mike Jones <Michae=
l.Jones@microsoft.com>
                      wrote:

                    

                    

                      

                        

                          
The technique
                              of replicating JWT claims that need to be
                              publicly visible in an encrypted JWT in
                              the header is defined at https://tools.ie=
tf.org/html/rfc7519#section-5.3.=C2=A0
                              (Thanks to Dick Hardt for bringing this
                              need to my attention as we were finishing
                              the JWT spec.)

                          
=C2=A0<=
/p>
                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                              -- Mike

                          
=C2=A0<=
/p>
                          
From: OAuth <<=
a
                              href=3D"mailto:oauth-bounces@ietf.org"
                              rel=3D"noreferrer" target=3D"_blank"
                              moz-do-not-send=3D"true">oauth-bounces@ietf=
=2Eorg>
                            On Behalf Of  John Bradley

                            Sent: Friday, January 10, 2020 2:15
                            PM

                            To: Vladimir Dzhuvinov <vladimir@connect2i=
d.com>

                            Cc: IETF oauth WG <oauth@ietf.org=
>

                            Subject: [EXTERNAL] Re: [OAUTH-WG]
                            JWT Secured Authorization Request (JAR) vs
                            OIDC request object

                          
=C2=A0

                          

                            

                              
The intent was to do=

                                that, but specs change once the OAuth WG
                                and IESG get there hands on them.=C2=A0=C2=
=A0

                              

                                
=C2=A0

                              

                              

                                
Being backwards
                                  compatible with OIDC is not a
                                  compelling argument to the IESG.

                              

                              

                                
=C2=A0

                              

                              

                                
We were mostly
                                  thinking of asymmetric encryption.=C2=A0=
=C2=A0

                              

                              

                                
=C2=A0

                              

                              

                                
Specifying puting
                                  the issuer and or the audience in the
                                  headder has come up in the past but
                                  probably is not documented.=C2=A0=C2=A0=


                              

                              

                                
=C2=A0

                              

                              

                                
John B=C2=A0

                              

                              
=C2=A0

                              

                                

                                  
On Fri, Jan 10,
                                    2020, 6:29 PM Vladimir Dzhuvinov
                                    <vladimir@c=
onnect2id.com>
                                    wrote:

                                

                                

                                  
Yes, putting the=

                                    client_id into the JWE header is a
                                    way around the need

                                    to have the client_id outside the
                                    JWE as top-level authZ request
                                    parameter.

                                    

                                    Unfortunately this work around isn't
                                    mentioned anywhere, I just checked
                                    the most recent
                                    draft-ietf-oauth-jwsreq-20.

                                    

                                    Our DDoS attack mitigation (for OIDC
                                    request_uri) also relies on the

                                    presence of client_id as top-level
                                    parameter, together with requiring
                                    RPs to register their request_uri's
                                    (so that we don't need to build and
                                    store an index of all
                                    request_uri's). I just had a look at
                                    "DDoS Attack

                                    on the Authorization Server" and
                                    also realised the request_uri

                                    registration isn't explicitly
                                    mentioned as attack prevention ("the<=
br>
                                    server should (a) check that the
                                    value of "request_uri" parameter
                                    does

                                    not point to an unexpected
                                    location").

                                    

                                    https://to=
ols.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

                                    

                                    To be honest, I feel quite bad about
                                    the situation with JAR we are in

                                    now. For some reason I had the
                                    impression that OAuth JAR was going
                                    to be

                                    the OIDC request / request_uri for
                                    general OAuth 2.0 use, as with other<=
br>
                                    OIDC bits that later became general
                                    purpose OAuth 2.0 specs.

                                    

                                    I find it unfortunate I didn't
                                    notice this when I was reviewing the
                                    spec

                                    in the past.

                                    

                                    Vladimir

                                    

                                    

                                    On 10/01/2020 22:39, Filip Skokan
                                    wrote:

                                    > Vladimir, 

                                    >

                                    > For that very case the payload
                                    claims may be repeated in the JWE
                                    protected header. An implementation
                                    wanting to handle this may look for
                                    iss/client_id there. 

                                    >

                                    > Odesl=C3=A1no z iPhonu

                                    >

                                    >> 10. 1. 2020 v 21:19,
                                    Vladimir Dzhuvinov <vladimir@c=
onnect2id.com>:

                                    >>

                                    >> =EF=BB=BFI just realised the=
re is
                                    one class of JARs where it's
                                    practially

                                    >> impossible to process the
                                    request if merge isn't supported:
=

                                    >>

                                    >> The client submits a JAR
                                    encrypted (JWT) with a shared key.
                                    OIDC allows

                                    >> for that and specs a method
                                    for deriving the shared key from the<=
br>
                                    >> client_secret:

                                    >>

                                    >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                                    >>

                                    >> If the JAR is encrypted
                                    with the client_secret, and there is
                                    no

                                    >> top-level client_id
                                    parameter, there's no good way for
                                    the OP to find

                                    >> out which client_secret to
                                    get to try to decrypt the JWE.
                                    Unless the OP

                                    >> keeps an index of all
                                    issued client_secret's.

                                    >>

                                    >>

                                    >> OP servers which require
                                    request_uri registration

                                    >>
                                    (require_request_uri_registration=3Dt=
rue)
                                    and don't want to index all

                                    >> registered request_uri's,
                                    also have no good way to process a
                                    request_uri

                                    >> if the client_id isn't
                                    present as top-level parameter.

                                    >>

                                    >>

                                    >> Vladimir

                                    >>

                                    >>

                                    >>> On 10/01/2020 20:13,
                                    Torsten Lodderstedt wrote:

                                    >>>

                                    >>>>> Am 10.01.2020
                                    um 16:53 schrieb John Bradley <ve7jtb@ve7=
jtb.com>:

                                    >>>> I think Torsten is
                                    speculating that is not a feature
                                    people use.=C2=A0 =C2=A0

                                    >>> I=E2=80=99m still trying=
 to
                                    understand the use case for merging
                                    signed and unsigned parameters. Nat
                                    once explained a use case, where a
                                    client uses parameters signed by a
                                    3rd party (some =E2=80=9Ecertificatio=
n
                                    authority=E2=80=9C) in combination wi=
th
                                    transaction-specific parameters. Is
                                    this being done in the wild? 

                                    >>>

                                    >>> PS: PAR would work with
                                    both modes.

                                    

                                    

_______________________________________________

                                    OAuth mailing list

                                    OAuth@ietf=
=2Eorg

                                    https://

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

        

      

    

    
--=20
Vladimir Dzhuvinov

  


--------------EC134B8008BD2322F29F8988--

--------------ms000105080308070105030007
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTUyMTAyMzNaMC8G
CSqGSIb3DQEJBDEiBCDAccVO0YW8ySvFuAaCl8clCG21Or0uZAocHql/p2WYczBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBALmX5N2MfE0CDjswGsDxvKSoYDd3Vue6YwJjLFAZbGRaS/S0
DMT5l33gq6OBig0RoI8jks0FTfgXDEkYIi/KOCS8K8RkkZ7CEaHA7e/1W4O6u6olWj2kkE4v
IzCl6hQBId2PN71imLa1OMMdaAC78ZRELmfArvVKRvmw/tPns040axJgN8F1cp6O5N1EFJ9K
d0ByrF6n0BvuoMopMvVn8g5Lcuc7u2d20Az+PwoiFMY7+q33bN0WyKvICpTBUzdHlg+DxR4H
7Ix3/YV3rdVy8EDKMqWY0QZEmDrvJQbkOldS+5OnIzhGeepiMY9ULfz7IPfAdm3c6sJbM4Th
JtjV5QIAAAAAAAA=
--------------ms000105080308070105030007--


From nobody Wed Jan 15 13:27: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 CCA7612098E for ; Wed, 15 Jan 2020 13:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0CrPqMkLHC9R for ; Wed, 15 Jan 2020 13:27:40 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640137.outbound.protection.outlook.com [40.107.64.137]) (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 CD48C12097F for ; Wed, 15 Jan 2020 13:27:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jo/e+R6shsrDot1QIJb9xuDzMfH60OBaQqCvdTA3tsdbNrWc70aZBpN9yrqfSqfrBa/Yvsm50kEzVKqaVP6JDgwaL0iQqZ7EiJSTToNEjrl1NbENmRwcQDr+fY+yEkHp7gpVnSbz1eBDUIiI0Rj6UpPAccdGFyo9bg2e1pO48rTCkKiMnitY2xT7oMmWNeQ2HpgOWqXlhmn2QydPg6OOP2Hdh0YBcP/z9NYRvoTrBRNFxstFjrLurtuATiRGncLpj8cg7hb2UW8G2KO3Q2Cr7/+prssM2JzjywKKQhqOm6nWZ3bKlZ74J9gx+zxiZ/g4kQdYWBZtQGKtMqmtSLdk/g==
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=t/t3mArVHSUyGNYnOTbwTE6fyAT2lHcughXE5RbshMM=; b=Zh2PFIa8QZywgGx8UC4EMmg/5+OpJaKLX/7D0Ed6Ew9gD+rPXVpwqxyJORFHGwAAkFLKOFQwhg/+0L3IDZW8ngphp0wYN1pz2pPRVpFbC3yExOQn8Bs42x0+BHDvGxcxolNleMJ9s4nSd9u1LJBlp1mss9Pe4sKNjBdjodF2G/gl2L9CRejPSXKy8C1VXA6t9lmlbP9dVcMnzPqzBJO3Fpz/IEpUpGg+ml2P6EnSRVxdiSDFLHpYkcv4idXUTcAmpPLtwM6ryZ1odbsuMq6xpaDxy4l5ihFeV5ce5LuRiyYbLtVxVf8UvN4+n1bHr6/DALgf6q8QWpAPPdKsKl+YMQ==
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=t/t3mArVHSUyGNYnOTbwTE6fyAT2lHcughXE5RbshMM=; b=M44bxBKg3n8bpapbsaQOr9EgMCrBb+oDj0/HEtFt9eHHGlK+uGrIwVJt1VJqoIDMU40dvJ83NdL/K4FI8+u9UcfDYb8EMRvASdxFQmGSdufomzdPWufblwJhUU6x7jzH6kmmgSn19t8rXaJwW486jZ1NSzZjQgg+uM2+z2fxvWs=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (20.180.16.71) by CH2PR00MB0794.namprd00.prod.outlook.com (10.186.139.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2684.0; Wed, 15 Jan 2020 21:27:38 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::bc12:5826:ded6:299]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::bc12:5826:ded6:299%5]) with mapi id 15.20.2671.000; Wed, 15 Jan 2020 21:27:38 +0000
From: Mike Jones 
To: Vladimir Dzhuvinov , Takahiko Kawasaki 
CC: John Bradley , IETF oauth WG 
Thread-Topic: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVyv76Tgq69ACZJ0qRRkD+fK3CnqfsODiAgAAGkSA=
Date: Wed, 15 Jan 2020 21:27:38 +0000
Message-ID: 
References:  <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
In-Reply-To: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5cf92803-4e58-4f11-9ed9-00000b322440; 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-01-15T21:26:03Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [2001:4898:80e8:f:63b8:5fb2:5e31:1cf3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5116299f-7506-4a21-9d25-08d79a01bec6
x-ms-traffictypediagnostic: CH2PR00MB0794:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(189003)(199004)(33656002)(10290500003)(86362001)(478600001)(7696005)(66556008)(64756008)(76116006)(66446008)(66476007)(66946007)(53546011)(5660300002)(4326008)(966005)(71200400001)(6506007)(54906003)(8936002)(9686003)(81166006)(110136005)(55016002)(52536014)(81156014)(2906002)(8676002)(66574012)(316002)(186003)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0794; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FFPgv6tSM//qckuY72f/dl/vGX9mfRAIyJFCqfCzFqSOmrTCPgJPWdDSZd4cbk+bXEEOLXXxbr+VeDWiHjn1nsN/Lbw2nkq6pp48W0R5BLTNTzLTp+SF0zSpVvq4RDe0ZjZaUMfQJkuaM3lmf5kc8oya1h97jVe064n+2+Fp+U54SBFp2C+kYM548rYPPArbHnWOcH7H58tRchVA0RLCx9lffpHtjWTXzrmiawHTwkEf0hTJeMHsiTPRAgOe7neM+mS4L8DbHOCGBlAoiXrYX2VmH9Ak4ERcCcjGyUCBMMbvmZv6zHbTJM3Fsg6yx/JERVUzDN2TNxXE2H9Qg5wEXPbbIFZpg2XznuRiNY8A9Ei8ERR/3uFkG5+1O9Id4TrDZ9xuogKa5QPZFLOG84baa5lMBKyBZggCtGR2igDQeSkreVemdBeeYTDZomAz+VSu4Eql+qwvs1aqQN1PFQiydYmmzF8YWS7x43X2wcpK3+I=
x-ms-exchange-antispam-messagedata: L240Hc4qWdNCeZw6hCW7UPW1fxtu/56wThScBQbqlVVQ8EMHxlLBkEMRVbtPfN85ivl0be9Ap2pSOOfudMgeAgnouA/uMpTdAN1NiYDSdOON+UCx/a2+S1NYZKig5JYtuDkzdaJKiFRU8CUtO2I/2PlIwQyVIWM2gDNwLeISdGlmtZ3FQX+11oIbAHxCvnZjlumH4GfIC1npA/GBRxniGw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679453419D7494476B21DFDF5370CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5116299f-7506-4a21-9d25-08d79a01bec6
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 21:27:38.1093 (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: NKcyVx1UFOoDbOTBmkrehX2Aatzi+3VAnwgWoz112AsZQOHeghdNH4dbWfZbcTd1aHiD77TrmENwOuLg6l6flg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0794
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Wed, 15 Jan 2020 21:27:43 -0000

--_000_CH2PR00MB0679453419D7494476B21DFDF5370CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gaW5jcmVhc2luZ2x5IHRoaW5raW5nIHRoYXQgd2Ugc2hvdWxkIHB1c2ggYmFjayBvbiB0
aGUgSUVTRyBhbmQgZ28gYmFjayB0byB0aGUgc2VtYW50aWNzIHRoYXQgdGhlIHdvcmtpbmcgZ3Jv
dXAgYXBwcm92ZWQuICBXZSBjYW4gdXNlIHRoZSBjbGllbnRfaWQgZXhhbXBsZSB3aXRoIGFuIGVu
Y3J5cHRlZCByZXF1ZXN0IG9iamVjdCB0byBtb3RpdmF0ZSB0aGUgKENvbm5lY3QtY29tcGF0aWJs
ZSkgc3ludGF4IGFuZCBzZW1hbnRpY3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFZsYWRpbWlyIER6aHV2
aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg
MTUsIDIwMjAgMTowMyBQTQ0KVG86IFRha2FoaWtvIEthd2FzYWtpIDx0YWthQGF1dGhsZXRlLmNv
bT4NCkNjOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPjsgTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbRVhURVJOQUxdIFJlOiBKV1QgU2VjdXJlZCBBdXRo
b3JpemF0aW9uIFJlcXVlc3QgKEpBUikgdnMgT0lEQyByZXF1ZXN0IG9iamVjdA0KDQoNCg0KT24g
MTQvMDEvMjAyMCAxOToyMCwgVGFrYWhpa28gS2F3YXNha2kgd3JvdGU6DQpXZWxsLCBlbWJlZGRp
bmcgYSBjbGllbnRfaWQgY2xhaW0gaW4gdGhlIEpXRSBoZWFkZXIgaW4gb3JkZXIgdG8gYWNoaWV2
ZSAicmVxdWVzdCBwYXJhbWV0ZXJzIG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0IHNob3VsZCBu
b3QgYmUgcmVmZXJyZWQgdG8iIGlzIGxpa2UgInB1dHRpbmcgdGhlIGNhcnQgYmVmb3JlIHRoZSBo
b3JzZSIuIFdoeSBkbyB3ZSBoYXZlIHRvIGF2b2lkIHVzaW5nIHRoZSB0cmFkaXRpb25hbCBjbGll
bnRfaWQgcmVxdWVzdCBwYXJhbWV0ZXIgc28gc3R1YmJvcm5seT8NCg0KVGhlIGxhc3QgcGFyYWdy
YXBoIG9mIFNlY3Rpb24gMy4yLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkj
c2VjdGlvbi0zLjIuMT4gb2YgUkZDIDY3NDkgc2F5cyBhcyBmb2xsb3dzLg0KQSBjbGllbnQgTUFZ
IHVzZSB0aGUgImNsaWVudF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgdG8gaWRlbnRpZnkgaXRzZWxm
IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQuICBJbiB0aGUgImF1
dGhvcml6YXRpb25fY29kZSIgImdyYW50X3R5cGUiIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBv
aW50LCBhbiB1bmF1dGhlbnRpY2F0ZWQgY2xpZW50IE1VU1Qgc2VuZCBpdHMgImNsaWVudF9pZCIg
dG8gcHJldmVudCBpdHNlbGYgZnJvbSBpbmFkdmVydGVudGx5IGFjY2VwdGluZyBhIGNvZGUgaW50
ZW5kZWQgZm9yIGEgY2xpZW50IHdpdGggYSBkaWZmZXJlbnQgImNsaWVudF9pZCIuICBUaGlzIHBy
b3RlY3RzIHRoZSBjbGllbnQgZnJvbSBzdWJzdGl0dXRpb24gb2YgdGhlIGF1dGhlbnRpY2F0aW9u
IGNvZGUuICAoSXQgcHJvdmlkZXMgbm8gYWRkaXRpb25hbCBzZWN1cml0eSBmb3IgdGhlIHByb3Rl
Y3RlZCByZXNvdXJjZS4pDQoNCklmIHRoZSBzYW1lIHJlYXNvbmluZyBhcHBsaWVzLCBhIGNsaWVu
dF9pZCBtdXN0IGFsd2F5cyBiZSBzZW50IHdpdGggcmVxdWVzdCAvIHJlcXVlc3RfdXJpIGJlY2F1
c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBwZXJmb3JtZWQgYXQgdGhlIGF1dGhvcml6
YXRpb24gZW5kcG9pbnQuIEluIG90aGVyIHdvcmRzLCBhbiB1bmF1dGhlbnRpY2F0ZWQgY2xpZW50
IChldmVyeSBjbGllbnQgaXMgdW5hdXRoZW50aWNhdGVkIGF0IHRoZSBhdXRob3JpemF0aW9uIGVu
ZHBvaW50KSBNVVNUIHNlbmQgaXRzICJjbGllbnRfaWQiIHRvIHByZXZlbnQgaXRzZWxmIGZyb20g
aW5hZHZlcnRlbnRseSBhY2NlcHRpbmcgYSByZXF1ZXN0IG9iamVjdCBmb3IgYSBjbGllbnQgd2l0
aCBhIGRpZmZlcmVudCAiY2xpZW50X2lkIi4NCg0KDQpJZGVudGlmeWluZyB0aGUgY2xpZW50IGlu
IEpBUiByZXF1ZXN0X3VyaSByZXF1ZXN0cyBjYW4gYmUgcmVhbGx5IHVzZWZ1bCBzbyB0aGF0IGFu
IEFTIHdoaWNoIHJlcXVpcmVzIHJlcXVlc3RfdXJpIHJlZ2lzdHJhdGlvbiB0byBwcmV2ZW50IERE
b1MgYXR0YWNrcyBhbmQgb3RoZXIgY2hlY2tzIGNhbiBkbyB0aG9zZSB3aXRob3V0IGhhdmluZyB0
byBpbmRleCBhbGwgcmVxdWVzdF91cmlzIGluZGl2aWR1YWxseS4gSSBtZW50aW9uZWQgdGhpcyBi
ZWZvcmUuDQoNCkkgcmVhbGx5IHdvbmRlciB3aGF0IHRoZSByZWFzb25pbmcgb2YgdGhlIElFU0cg
cmV2aWV3ZXJzIHdhcyB0byBpbnNpc3Qgb24gbm8gcGFyYW1zIG91dHNpZGUgdGhlIEpBUiBKV1Qg
LyByZXF1ZXN0X3VyaS4NCg0KSSdtIGJlZ2lubmluZyB0byByZWFsaXNlIHRoaXMgc3RlcCBvZiB0
aGUgcmV2aWV3IHByb2Nlc3MgaXNuJ3QgcGFydGljdWxhcmx5IHRyYW5zcGFyZW50IHRvIFdHIG1l
bWJlcnMuDQoNClZsYWRpbWlyDQoNCg0KQmVzdCBSZWdhcmRzLA0KVGFrYQ0KDQoNCg0KT24gVHVl
LCBKYW4gMTQsIDIwMjAgYXQgMTI6NTcgQU0gVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBj
b25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+PiB3cm90ZToNCg0K
Sm9obiwgdGhhbmtzLCBtdWNoIGFwcHJlY2lhdGVkIQ0KT24gMTEvMDEvMjAyMCAyMTozNiwgSm9o
biBCcmFkbGV5IHdyb3RlOg0KDQpZZXMgSkFSIGlzIG5vdCBwcm9oaWJpdGluZyBwYXJhbWF0ZXIg
cmVwbGljYXRpb24gaW4gdGhlIGhlYWRlci4NCg0KSSB3aWxsIHNlZSBpZiBpIGNhbiBhZGQgc29t
ZXRoaW5nIGluIGZpbmFsIGVkaXRzIHRvIGNhbGwgdGhhdCBvdXQuDQoNCkpvaG4gQi4NCk9uIDEv
MTEvMjAyMCA2OjE2IEFNLCBWbGFkaW1pciBEemh1dmlub3Ygd3JvdGU6DQoNClRoYW5rcyBNaWtl
IGZvciB0aGUgcmZjNzUxOSBzZWN0aW9uLTUuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
cmZjNzUxOSNzZWN0aW9uLTUuMz4gcG9pbnRlci4gQ2FuIHRoaXMgcGFyYW1ldGVyIHJlcGxpY2F0
aW9uIGJlIHVzZWQgZm9yIGNsaWVudF9pZCBvciB0aGUgY2xpZW50X2lkIGFzcyAiaXNzIiBldmVu
IHRob3VnaCBpdCBpc24ndCBleHBsaWNpdGx5IG1lbnRpb25lZCBpbiB0aGUgSkFSIHNwZWM/DQpP
biAxMS8wMS8yMDIwIDAyOjU4LCBKb2huIEJyYWRsZXkgd3JvdGU6DQpSaWdodCB3ZSBqdXN0IGRv
bid0IHNheSB0byBwdXQgdGhlIGlzcyB0aGVyZSBpbiBPSURDIGlmIGl0J3Mgc3ltZXRyaWNseSBl
bmNyeXB0ZWQuDQoNCk9JREMgZG9lc24ndCBoYXZlIHRoZSBzeW1tZXRyaWMga2V5IHNlbGVjdGlv
biBpc3N1ZSwgSSBzdXBwb3NlIHRoYXQgd2h5IHRoZSBwb3NzaWJpbGl0eSB0byByZXBsaWNhdGUg
cGFyYW1zIHRvIHRoZSBKV0UgaGVhZGVyIGlzbid0IG1lbnRpb25lZCBhdCBhbGwuIE9JREMgcmVx
dWlyZXMgdGhlIHRvcC1sZXZlbCBxdWVyeSBwYXJhbXMgdG8gcmVwcmVzZW50IGEgdmFsaWQgT0F1
dGggMi4wIHJlcXVlc3QsIGFuZCB0aGVyZSBjbGllbnRfaWQgaXMgcmVxdWlyZWQuIElmIHRoZSBj
bGllbnRfaWQgaXMgcHJlc2VudCB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiB0b2dldGhlciB3aXRo
IGFueSBwcmVzZW50IGNsaWVudF9zZWNyZXQgY2FuIGJlIHJldHJpZXZlZC4NCg0KSSByZXJlYWQg
dGhlIEpBUiBzcGVjLCB0aGlzIGlzIHRoZSBvbmx5IHBsYWNlIHRoYXQgbWVudGlvbnMgaGFuZGxp
bmcgb2Ygc3ltbWV0cmljIEpXRS4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtb2F1dGgtandzcmVxLTIwI3NlY3Rpb24tMTAuMg0KDQogICAoYikgIFZlcmlmeWluZyB0
aGF0IHRoZSBzeW1tZXRyaWMga2V5IGZvciB0aGUgSldFIGVuY3J5cHRpb24gaXMgdGhlDQoNCiAg
ICAgICAgY29ycmVjdCBvbmUgaWYgdGhlIEpXRSBpcyB1c2luZyBzeW1tZXRyaWMgZW5jcnlwdGlv
bi4NCg0KDQoNClZsYWRpbWlyDQoNCg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCwgOTo0MSBQTSBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhlIHRlY2huaXF1ZSBvZiByZXBsaWNhdGluZyBK
V1QgY2xhaW1zIHRoYXQgbmVlZCB0byBiZSBwdWJsaWNseSB2aXNpYmxlIGluIGFuIGVuY3J5cHRl
ZCBKV1QgaW4gdGhlIGhlYWRlciBpcyBkZWZpbmVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4zLiAgKFRoYW5rcyB0byBEaWNrIEhhcmR0IGZvciBicmlu
Z2luZyB0aGlzIG5lZWQgdG8gbXkgYXR0ZW50aW9uIGFzIHdlIHdlcmUgZmluaXNoaW5nIHRoZSBK
V1Qgc3BlYy4pDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn
PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxl
eQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIDI6MTUgUE0NClRvOiBWbGFkaW1pciBE
emh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0
MmlkLmNvbT4+DQpDYzogSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo
QGlldGYub3JnPj4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtPQVVUSC1XR10gSldUIFNlY3Vy
ZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpIHZzIE9JREMgcmVxdWVzdCBvYmplY3QNCg0K
VGhlIGludGVudCB3YXMgdG8gZG8gdGhhdCwgYnV0IHNwZWNzIGNoYW5nZSBvbmNlIHRoZSBPQXV0
aCBXRyBhbmQgSUVTRyBnZXQgdGhlcmUgaGFuZHMgb24gdGhlbS4NCg0KQmVpbmcgYmFja3dhcmRz
IGNvbXBhdGlibGUgd2l0aCBPSURDIGlzIG5vdCBhIGNvbXBlbGxpbmcgYXJndW1lbnQgdG8gdGhl
IElFU0cuDQoNCldlIHdlcmUgbW9zdGx5IHRoaW5raW5nIG9mIGFzeW1tZXRyaWMgZW5jcnlwdGlv
bi4NCg0KU3BlY2lmeWluZyBwdXRpbmcgdGhlIGlzc3VlciBhbmQgb3IgdGhlIGF1ZGllbmNlIGlu
IHRoZSBoZWFkZGVyIGhhcyBjb21lIHVwIGluIHRoZSBwYXN0IGJ1dCBwcm9iYWJseSBpcyBub3Qg
ZG9jdW1lbnRlZC4NCg0KSm9obiBCDQoNCk9uIEZyaSwgSmFuIDEwLCAyMDIwLCA2OjI5IFBNIFZs
YWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tPj4gd3JvdGU6DQpZZXMsIHB1dHRpbmcgdGhlIGNsaWVudF9pZCBpbnRv
IHRoZSBKV0UgaGVhZGVyIGlzIGEgd2F5IGFyb3VuZCB0aGUgbmVlZA0KdG8gaGF2ZSB0aGUgY2xp
ZW50X2lkIG91dHNpZGUgdGhlIEpXRSBhcyB0b3AtbGV2ZWwgYXV0aFogcmVxdWVzdCBwYXJhbWV0
ZXIuDQoNClVuZm9ydHVuYXRlbHkgdGhpcyB3b3JrIGFyb3VuZCBpc24ndCBtZW50aW9uZWQgYW55
d2hlcmUsIEkganVzdCBjaGVja2VkDQp0aGUgbW9zdCByZWNlbnQgZHJhZnQtaWV0Zi1vYXV0aC1q
d3NyZXEtMjAuDQoNCk91ciBERG9TIGF0dGFjayBtaXRpZ2F0aW9uIChmb3IgT0lEQyByZXF1ZXN0
X3VyaSkgYWxzbyByZWxpZXMgb24gdGhlDQpwcmVzZW5jZSBvZiBjbGllbnRfaWQgYXMgdG9wLWxl
dmVsIHBhcmFtZXRlciwgdG9nZXRoZXIgd2l0aCByZXF1aXJpbmcNClJQcyB0byByZWdpc3RlciB0
aGVpciByZXF1ZXN0X3VyaSdzIChzbyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gYnVpbGQgYW5kDQpz
dG9yZSBhbiBpbmRleCBvZiBhbGwgcmVxdWVzdF91cmkncykuIEkganVzdCBoYWQgYSBsb29rIGF0
ICJERG9TIEF0dGFjaw0Kb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIiBhbmQgYWxzbyByZWFs
aXNlZCB0aGUgcmVxdWVzdF91cmkNCnJlZ2lzdHJhdGlvbiBpc24ndCBleHBsaWNpdGx5IG1lbnRp
b25lZCBhcyBhdHRhY2sgcHJldmVudGlvbiAoInRoZQ0Kc2VydmVyIHNob3VsZCAoYSkgY2hlY2sg
dGhhdCB0aGUgdmFsdWUgb2YgInJlcXVlc3RfdXJpIiBwYXJhbWV0ZXIgZG9lcw0Kbm90IHBvaW50
IHRvIGFuIHVuZXhwZWN0ZWQgbG9jYXRpb24iKS4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIwI3NlY3Rpb24tMTAuNC4xPGh0dHBzOi8vbmFt
MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv
b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIwJTIzc2VjdGlv
bi0xMC40LjEmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0Nj
NDcwZDRlYzRiZDE0ZDQ4MWMwZjA4ZDc5NjFhOGFiYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDI5MTMwNjg3OTMxOTMmc2RhdGE9JTJGdkhWcDY4U041
Q0FIaW1xWjVqeDkzYU9DSXJ1eHFMQ1JNVUZDYzVEU3hjJTNEJnJlc2VydmVkPTA+DQoNClRvIGJl
IGhvbmVzdCwgSSBmZWVsIHF1aXRlIGJhZCBhYm91dCB0aGUgc2l0dWF0aW9uIHdpdGggSkFSIHdl
IGFyZSBpbg0Kbm93LiBGb3Igc29tZSByZWFzb24gSSBoYWQgdGhlIGltcHJlc3Npb24gdGhhdCBP
QXV0aCBKQVIgd2FzIGdvaW5nIHRvIGJlDQp0aGUgT0lEQyByZXF1ZXN0IC8gcmVxdWVzdF91cmkg
Zm9yIGdlbmVyYWwgT0F1dGggMi4wIHVzZSwgYXMgd2l0aCBvdGhlcg0KT0lEQyBiaXRzIHRoYXQg
bGF0ZXIgYmVjYW1lIGdlbmVyYWwgcHVycG9zZSBPQXV0aCAyLjAgc3BlY3MuDQoNCkkgZmluZCBp
dCB1bmZvcnR1bmF0ZSBJIGRpZG4ndCBub3RpY2UgdGhpcyB3aGVuIEkgd2FzIHJldmlld2luZyB0
aGUgc3BlYw0KaW4gdGhlIHBhc3QuDQoNClZsYWRpbWlyDQoNCg0KT24gMTAvMDEvMjAyMCAyMjoz
OSwgRmlsaXAgU2tva2FuIHdyb3RlOg0KPiBWbGFkaW1pciwNCj4NCj4gRm9yIHRoYXQgdmVyeSBj
YXNlIHRoZSBwYXlsb2FkIGNsYWltcyBtYXkgYmUgcmVwZWF0ZWQgaW4gdGhlIEpXRSBwcm90ZWN0
ZWQgaGVhZGVyLiBBbiBpbXBsZW1lbnRhdGlvbiB3YW50aW5nIHRvIGhhbmRsZSB0aGlzIG1heSBs
b29rIGZvciBpc3MvY2xpZW50X2lkIHRoZXJlLg0KPg0KPiBPZGVzbMOhbm8geiBpUGhvbnUNCj4N
Cj4+IDEwLiAxLiAyMDIwIHYgMjE6MTksIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29u
bmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPj46DQo+Pg0KPj4g77u/
SSBqdXN0IHJlYWxpc2VkIHRoZXJlIGlzIG9uZSBjbGFzcyBvZiBKQVJzIHdoZXJlIGl0J3MgcHJh
Y3RpYWxseQ0KPj4gaW1wb3NzaWJsZSB0byBwcm9jZXNzIHRoZSByZXF1ZXN0IGlmIG1lcmdlIGlz
bid0IHN1cHBvcnRlZDoNCj4+DQo+PiBUaGUgY2xpZW50IHN1Ym1pdHMgYSBKQVIgZW5jcnlwdGVk
IChKV1QpIHdpdGggYSBzaGFyZWQga2V5LiBPSURDIGFsbG93cw0KPj4gZm9yIHRoYXQgYW5kIHNw
ZWNzIGEgbWV0aG9kIGZvciBkZXJpdmluZyB0aGUgc2hhcmVkIGtleSBmcm9tIHRoZQ0KPj4gY2xp
ZW50X3NlY3JldDoNCj4+DQo+PiBodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5l
Y3QtY29yZS0xXzAuaHRtbCNFbmNyeXB0aW9uPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm9wZW5pZC5uZXQlMkZzcGVjcyUy
Rm9wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwlMjNFbmNyeXB0aW9uJmRhdGE9MDIlN0MwMSU3
Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3
OTYxYThhYmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3
MTQyOTEzMDY4NzkzMTkzJnNkYXRhPXNvSzl0N3B6dTUwNGlJTHVETkZuRyUyQk1MeFpQUDJwTjZ1
Z0VKNFpPcHFkNCUzRCZyZXNlcnZlZD0wPg0KPj4NCj4+IElmIHRoZSBKQVIgaXMgZW5jcnlwdGVk
IHdpdGggdGhlIGNsaWVudF9zZWNyZXQsIGFuZCB0aGVyZSBpcyBubw0KPj4gdG9wLWxldmVsIGNs
aWVudF9pZCBwYXJhbWV0ZXIsIHRoZXJlJ3Mgbm8gZ29vZCB3YXkgZm9yIHRoZSBPUCB0byBmaW5k
DQo+PiBvdXQgd2hpY2ggY2xpZW50X3NlY3JldCB0byBnZXQgdG8gdHJ5IHRvIGRlY3J5cHQgdGhl
IEpXRS4gVW5sZXNzIHRoZSBPUA0KPj4ga2VlcHMgYW4gaW5kZXggb2YgYWxsIGlzc3VlZCBjbGll
bnRfc2VjcmV0J3MuDQo+Pg0KPj4NCj4+IE9QIHNlcnZlcnMgd2hpY2ggcmVxdWlyZSByZXF1ZXN0
X3VyaSByZWdpc3RyYXRpb24NCj4+IChyZXF1aXJlX3JlcXVlc3RfdXJpX3JlZ2lzdHJhdGlvbj10
cnVlKSBhbmQgZG9uJ3Qgd2FudCB0byBpbmRleCBhbGwNCj4+IHJlZ2lzdGVyZWQgcmVxdWVzdF91
cmkncywgYWxzbyBoYXZlIG5vIGdvb2Qgd2F5IHRvIHByb2Nlc3MgYSByZXF1ZXN0X3VyaQ0KPj4g
aWYgdGhlIGNsaWVudF9pZCBpc24ndCBwcmVzZW50IGFzIHRvcC1sZXZlbCBwYXJhbWV0ZXIuDQo+
Pg0KPj4NCj4+IFZsYWRpbWlyDQo+Pg0KPj4NCj4+PiBPbiAxMC8wMS8yMDIwIDIwOjEzLCBUb3Jz
dGVuIExvZGRlcnN0ZWR0IHdyb3RlOg0KPj4+DQo+Pj4+PiBBbSAxMC4wMS4yMDIwIHVtIDE2OjUz
IHNjaHJpZWIgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl
N2p0Yi5jb20+PjoNCj4+Pj4gSSB0aGluayBUb3JzdGVuIGlzIHNwZWN1bGF0aW5nIHRoYXQgaXMg
bm90IGEgZmVhdHVyZSBwZW9wbGUgdXNlLg0KPj4+IEnigJltIHN0aWxsIHRyeWluZyB0byB1bmRl
cnN0YW5kIHRoZSB1c2UgY2FzZSBmb3IgbWVyZ2luZyBzaWduZWQgYW5kIHVuc2lnbmVkIHBhcmFt
ZXRlcnMuIE5hdCBvbmNlIGV4cGxhaW5lZCBhIHVzZSBjYXNlLCB3aGVyZSBhIGNsaWVudCB1c2Vz
IHBhcmFtZXRlcnMgc2lnbmVkIGJ5IGEgM3JkIHBhcnR5IChzb21lIOKAnmNlcnRpZmljYXRpb24g
YXV0aG9yaXR54oCcKSBpbiBjb21iaW5hdGlvbiB3aXRoIHRyYW5zYWN0aW9uLXNwZWNpZmljIHBh
cmFtZXRlcnMuIElzIHRoaXMgYmVpbmcgZG9uZSBpbiB0aGUgd2lsZD8NCj4+Pg0KPj4+IFBTOiBQ
QVIgd291bGQgd29yayB3aXRoIGJvdGggbW9kZXMuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly88aHR0cHM6Ly9uYW0wNi5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu
b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K
b25lcyU0MG1pY3Jvc29mdC5jb20lN0NjNDcwZDRlYzRiZDE0ZDQ4MWMwZjA4ZDc5NjFhOGFiYiU3
QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNDI5MTMwNjg4
MDMxNDUmc2RhdGE9a29iSCUyRnNHVDdFbFNTVUNKdnUlMkZiaUFxblJDWHglMkI0U1pOSnNyTCUy
RkN1VnljJTNEJnJlc2VydmVkPTA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg0KLS0NCg0KVmxhZGltaXIgRHpodXZpbm92DQo=

--_000_CH2PR00MB0679453419D7494476B21DFDF5370CH2PR00MB0679namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPknigJltIGluY3JlYXNpbmdseSB0aGlua2luZyB0aGF0IHdlIHNob3VsZCBwdXNoIGJh
Y2sgb24gdGhlIElFU0cgYW5kIGdvIGJhY2sgdG8gdGhlIHNlbWFudGljcyB0aGF0IHRoZSB3b3Jr
aW5nIGdyb3VwIGFwcHJvdmVkLiZuYnNwOyBXZSBjYW4gdXNlIHRoZSBjbGllbnRfaWQgZXhhbXBs
ZSB3aXRoIGFuIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdCB0byBtb3RpdmF0ZSB0aGUNCiAoQ29u
bmVjdC1jb21wYXRpYmxlKSBzeW50YXggYW5kIHNlbWFudGljcy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G
cm9tOjwvYj4gVmxhZGltaXIgRHpodXZpbm92ICZsdDt2bGFkaW1pckBjb25uZWN0MmlkLmNvbSZn
dDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAxNSwgMjAyMCAxOjAzIFBN
PGJyPg0KPGI+VG86PC9iPiBUYWthaGlrbyBLYXdhc2FraSAmbHQ7dGFrYUBhdXRobGV0ZS5jb20m
Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0
OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBv
YXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
T0FVVEgtV0ddIFtFWFRFUk5BTF0gUmU6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24gUmVxdWVz
dCAoSkFSKSB2cyBPSURDIHJlcXVlc3Qgb2JqZWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNC8wMS8y
MDIwIDE5OjIwLCBUYWthaGlrbyBLYXdhc2FraSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VsbCwgZW1iZWRkaW5nIGEgPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jbGllbnRfaWQ8L3Nw
YW4+IGNsYWltIGluIHRoZSBKV0UgaGVhZGVyIGluIG9yZGVyIHRvIGFjaGlldmUgJnF1b3Q7cmVx
dWVzdCBwYXJhbWV0ZXJzIG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0IHNob3VsZCBub3QgYmUg
cmVmZXJyZWQgdG8mcXVvdDsgaXMgbGlrZSAmcXVvdDtwdXR0aW5nIHRoZSBjYXJ0IGJlZm9yZSB0
aGUgaG9yc2UmcXVvdDsuDQogV2h5IGRvIHdlIGhhdmUgdG8gYXZvaWQgdXNpbmcgdGhlIHRyYWRp
dGlvbmFsIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
DQpjbGllbnRfaWQ8L3NwYW4+IHJlcXVlc3QgcGFyYW1ldGVyIHNvIHN0dWJib3JubHk/IDxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij5UaGUgbGFzdCBwYXJhZ3JhcGggb2YgPGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjIuMSI+DQpTZWN0aW9uIDMuMi4xPC9h
PiBvZiBSRkMgNjc0OSBzYXlzIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+QSBjbGllbnQgTUFZIHVzZSB0aGUgJnF1b3Q7
Y2xpZW50X2lkJnF1b3Q7IHJlcXVlc3QgcGFyYW1ldGVyIHRvIGlkZW50aWZ5IGl0c2VsZiB3aGVu
IHNlbmRpbmcgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LiZuYnNwOyBJbiB0aGUgJnF1
b3Q7YXV0aG9yaXphdGlvbl9jb2RlJnF1b3Q7ICZxdW90O2dyYW50X3R5cGUmcXVvdDsgcmVxdWVz
dCB0byB0aGUgdG9rZW4gZW5kcG9pbnQsDQo8Yj5hbiB1bmF1dGhlbnRpY2F0ZWQgY2xpZW50IE1V
U1Qgc2VuZCBpdHMgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IHRvIHByZXZlbnQgaXRzZWxmIGZyb20g
aW5hZHZlcnRlbnRseSBhY2NlcHRpbmcgYSBjb2RlIGludGVuZGVkIGZvciBhIGNsaWVudCB3aXRo
IGEgZGlmZmVyZW50ICZxdW90O2NsaWVudF9pZCZxdW90Oy48L2I+ICZuYnNwO1RoaXMgcHJvdGVj
dHMgdGhlIGNsaWVudCBmcm9tIHN1YnN0aXR1dGlvbiBvZiB0aGUgYXV0aGVudGljYXRpb24gY29k
ZS4gJm5ic3A7KEl0IHByb3ZpZGVzIG5vIGFkZGl0aW9uYWwNCiBzZWN1cml0eSBmb3IgdGhlIHBy
b3RlY3RlZCByZXNvdXJjZS4pPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNhbWUgcmVh
c29uaW5nIGFwcGxpZXMsIGEgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4NCmNsaWVudF9pZDwvc3Bhbj4gbXVzdCBhbHdheXMgYmUgc2VudCB3aXRoIDxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQpyZXF1ZXN0
PC9zcGFuPiAvIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+cmVxdWVzdF91cmk8L3NwYW4+IGJlY2F1c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5v
dCBwZXJmb3JtZWQgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIEluIG90aGVyIHdvcmRz
LA0KPGI+PGk+YW4gdW5hdXRoZW50aWNhdGVkIGNsaWVudCAoZXZlcnkgY2xpZW50IGlzIHVuYXV0
aGVudGljYXRlZCBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCkgTVVTVCBzZW5kIGl0cyAm
cXVvdDtjbGllbnRfaWQmcXVvdDsgdG8gcHJldmVudCBpdHNlbGYgZnJvbSBpbmFkdmVydGVudGx5
IGFjY2VwdGluZyBhIHJlcXVlc3Qgb2JqZWN0IGZvciBhIGNsaWVudCB3aXRoIGEgZGlmZmVyZW50
ICZxdW90O2NsaWVudF9pZCZxdW90Oy48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD5JZGVudGlmeWluZyB0aGUgY2xpZW50
IGluIEpBUiByZXF1ZXN0X3VyaSByZXF1ZXN0cyBjYW4gYmUgcmVhbGx5IHVzZWZ1bCBzbyB0aGF0
IGFuIEFTIHdoaWNoIHJlcXVpcmVzIHJlcXVlc3RfdXJpIHJlZ2lzdHJhdGlvbiB0byBwcmV2ZW50
IEREb1MgYXR0YWNrcyBhbmQgb3RoZXIgY2hlY2tzIGNhbiBkbyB0aG9zZSB3aXRob3V0IGhhdmlu
ZyB0byBpbmRleCBhbGwgcmVxdWVzdF91cmlzIGluZGl2aWR1YWxseS4gSSBtZW50aW9uZWQgdGhp
cyBiZWZvcmUuPG86cD48L286cD48L3A+DQo8cD5JIHJlYWxseSB3b25kZXIgd2hhdCB0aGUgcmVh
c29uaW5nIG9mIHRoZSBJRVNHIHJldmlld2VycyB3YXMgdG8gaW5zaXN0IG9uIG5vIHBhcmFtcyBv
dXRzaWRlIHRoZSBKQVIgSldUIC8gcmVxdWVzdF91cmkuPG86cD48L286cD48L3A+DQo8cD5JJ20g
YmVnaW5uaW5nIHRvIHJlYWxpc2UgdGhpcyBzdGVwIG9mIHRoZSByZXZpZXcgcHJvY2VzcyBpc24n
dCBwYXJ0aWN1bGFybHkgdHJhbnNwYXJlbnQgdG8gV0cgbWVtYmVycy48bzpwPjwvbzpwPjwvcD4N
CjxwPlZsYWRpbWlyPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWthPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs
IEphbiAxNCwgMjAyMCBhdCAxMjo1NyBBTSBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhyZWY9
Im1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+
DQo8cD5Kb2huLCB0aGFua3MsIG11Y2ggYXBwcmVjaWF0ZWQhPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTEvMDEvMjAyMCAyMTozNiwgSm9obiBCcmFkbGV5
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwPlllcyBKQVIgaXMgbm90IHByb2hp
Yml0aW5nIHBhcmFtYXRlciByZXBsaWNhdGlvbiBpbiB0aGUgaGVhZGVyLiZuYnNwOyA8bzpwPjwv
bzpwPjwvcD4NCjxwPkkgd2lsbCBzZWUgaWYgaSBjYW4gYWRkIHNvbWV0aGluZyBpbiBmaW5hbCBl
ZGl0cyB0byBjYWxsIHRoYXQgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMTEvMjAyMCA2OjE2IEFN
LCBWbGFkaW1pciBEemh1dmlub3Ygd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+
VGhhbmtzIE1pa2UgZm9yIHRoZSA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi01LjMiIHRhcmdldD0i
X2JsYW5rIj5yZmM3NTE5IHNlY3Rpb24tNS4zPC9hPiBwb2ludGVyLiBDYW4gdGhpcyBwYXJhbWV0
ZXIgcmVwbGljYXRpb24gYmUgdXNlZCBmb3IgY2xpZW50X2lkIG9yIHRoZSBjbGllbnRfaWQgYXNz
ICZxdW90O2lzcyZxdW90OyBldmVuIHRob3VnaCBpdCBpc24ndA0KIGV4cGxpY2l0bHkgbWVudGlv
bmVkIGluIHRoZSBKQVIgc3BlYz88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gMTEvMDEvMjAyMCAwMjo1OCwgSm9obiBCcmFkbGV5IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdo
dCB3ZSBqdXN0IGRvbid0IHNheSB0byBwdXQgdGhlIGlzcyB0aGVyZSBpbiBPSURDIGlmIGl0J3Mg
c3ltZXRyaWNseSBlbmNyeXB0ZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPHA+T0lEQyBkb2Vzbid0IGhhdmUgdGhlIHN5bW1ldHJpYyBrZXkgc2VsZWN0aW9uIGlz
c3VlLCBJIHN1cHBvc2UgdGhhdCB3aHkgdGhlIHBvc3NpYmlsaXR5IHRvIHJlcGxpY2F0ZSBwYXJh
bXMgdG8gdGhlIEpXRSBoZWFkZXIgaXNuJ3QgbWVudGlvbmVkIGF0IGFsbC4gT0lEQyByZXF1aXJl
cyB0aGUgdG9wLWxldmVsIHF1ZXJ5IHBhcmFtcyB0byByZXByZXNlbnQgYSB2YWxpZCBPQXV0aCAy
LjAgcmVxdWVzdCwgYW5kIHRoZXJlIGNsaWVudF9pZCBpcw0KIHJlcXVpcmVkLiBJZiB0aGUgY2xp
ZW50X2lkIGlzIHByZXNlbnQgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gdG9nZXRoZXIgd2l0aCBh
bnkgcHJlc2VudCBjbGllbnRfc2VjcmV0IGNhbiBiZSByZXRyaWV2ZWQuDQo8bzpwPjwvbzpwPjwv
cD4NCjxwPkkgcmVyZWFkIHRoZSBKQVIgc3BlYywgdGhpcyBpcyB0aGUgb25seSBwbGFjZSB0aGF0
IG1lbnRpb25zIGhhbmRsaW5nIG9mIHN5bW1ldHJpYyBKV0UuPG86cD48L286cD48L3A+DQo8cD48
YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3Ny
ZXEtMjAjc2VjdGlvbi0xMC4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIwI3NlY3Rpb24tMTAuMjwvYT48bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT4mbmJzcDsmbmJzcDsgKGIpJm5ic3A7IFZlcmlmeWluZyB0aGF0IHRo
ZSBzeW1tZXRyaWMga2V5IGZvciB0aGUgSldFIGVuY3J5cHRpb24gaXMgdGhlPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNv
cnJlY3Qgb25lIGlmIHRoZSBKV0UgaXMgdXNpbmcgc3ltbWV0cmljIGVuY3J5cHRpb24uPG86cD48
L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+
VmxhZGltaXI8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTAsIDIwMjAsIDk6NDEgUE0gTWlrZSBKb25l
cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGUgdGVjaG5pcXVlIG9m
IHJlcGxpY2F0aW5nIEpXVCBjbGFpbXMgdGhhdCBuZWVkIHRvIGJlIHB1YmxpY2x5IHZpc2libGUg
aW4gYW4gZW5jcnlwdGVkIEpXVCBpbiB0aGUgaGVhZGVyIGlzIGRlZmluZWQgYXQNCjxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNS4zIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi01LjM8
L2E+LiZuYnNwOyAoVGhhbmtzIHRvIERpY2sgSGFyZHQgZm9yIGJyaW5naW5nIHRoaXMgbmVlZCB0
byBteSBhdHRlbnRpb24gYXMgd2Ugd2VyZSBmaW5pc2hpbmcgdGhlIEpXVCBzcGVjLik8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE9BdXRo
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5K
b2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIDI6
MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAY29u
bmVjdDJpZC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBvYXV0aCBXRyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5v
cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0dd
IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24gUmVxdWVzdCAoSkFSKSB2cyBPSURDIHJlcXVlc3Qg
b2JqZWN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpbnRl
bnQgd2FzIHRvIGRvIHRoYXQsIGJ1dCBzcGVjcyBjaGFuZ2Ugb25jZSB0aGUgT0F1dGggV0cgYW5k
IElFU0cgZ2V0IHRoZXJlIGhhbmRzIG9uIHRoZW0uJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVpbmcgYmFja3dhcmRzIGNvbXBh
dGlibGUgd2l0aCBPSURDIGlzIG5vdCBhIGNvbXBlbGxpbmcgYXJndW1lbnQgdG8gdGhlIElFU0cu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5XZSB3ZXJlIG1vc3RseSB0aGlua2luZyBvZiBhc3ltbWV0cmljIGVuY3J5cHRpb24uJm5ic3A7
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5TcGVjaWZ5aW5nIHB1dGluZyB0aGUgaXNzdWVyIGFuZCBvciB0aGUgYXVkaWVuY2Ug
aW4gdGhlIGhlYWRkZXIgaGFzIGNvbWUgdXAgaW4gdGhlIHBhc3QgYnV0IHByb2JhYmx5IGlzIG5v
dCBkb2N1bWVudGVkLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMTAsIDIwMjAsIDY6MjkgUE0g
VmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp
ZC5jb20iIHRhcmdldD0iX2JsYW5rIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLCBwdXR0aW5n
IHRoZSBjbGllbnRfaWQgaW50byB0aGUgSldFIGhlYWRlciBpcyBhIHdheSBhcm91bmQgdGhlIG5l
ZWQ8YnI+DQp0byBoYXZlIHRoZSBjbGllbnRfaWQgb3V0c2lkZSB0aGUgSldFIGFzIHRvcC1sZXZl
bCBhdXRoWiByZXF1ZXN0IHBhcmFtZXRlci48YnI+DQo8YnI+DQpVbmZvcnR1bmF0ZWx5IHRoaXMg
d29yayBhcm91bmQgaXNuJ3QgbWVudGlvbmVkIGFueXdoZXJlLCBJIGp1c3QgY2hlY2tlZDxicj4N
CnRoZSBtb3N0IHJlY2VudCBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMC48YnI+DQo8YnI+DQpP
dXIgRERvUyBhdHRhY2sgbWl0aWdhdGlvbiAoZm9yIE9JREMgcmVxdWVzdF91cmkpIGFsc28gcmVs
aWVzIG9uIHRoZTxicj4NCnByZXNlbmNlIG9mIGNsaWVudF9pZCBhcyB0b3AtbGV2ZWwgcGFyYW1l
dGVyLCB0b2dldGhlciB3aXRoIHJlcXVpcmluZzxicj4NClJQcyB0byByZWdpc3RlciB0aGVpciBy
ZXF1ZXN0X3VyaSdzIChzbyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gYnVpbGQgYW5kPGJyPg0Kc3Rv
cmUgYW4gaW5kZXggb2YgYWxsIHJlcXVlc3RfdXJpJ3MpLiBJIGp1c3QgaGFkIGEgbG9vayBhdCAm
cXVvdDtERG9TIEF0dGFjazxicj4NCm9uIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciZxdW90OyBh
bmQgYWxzbyByZWFsaXNlZCB0aGUgcmVxdWVzdF91cmk8YnI+DQpyZWdpc3RyYXRpb24gaXNuJ3Qg
ZXhwbGljaXRseSBtZW50aW9uZWQgYXMgYXR0YWNrIHByZXZlbnRpb24gKCZxdW90O3RoZTxicj4N
CnNlcnZlciBzaG91bGQgKGEpIGNoZWNrIHRoYXQgdGhlIHZhbHVlIG9mICZxdW90O3JlcXVlc3Rf
dXJpJnF1b3Q7IHBhcmFtZXRlciBkb2VzPGJyPg0Kbm90IHBvaW50IHRvIGFuIHVuZXhwZWN0ZWQg
bG9jYXRpb24mcXVvdDspLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYu
b3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIwJTIzc2VjdGlvbi0xMC40LjEm
YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0
ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4NzkzMTkzJmFtcDtzZGF0YT0lMkZ2SFZwNjhTTjVD
QUhpbXFaNWp4OTNhT0NJcnV4cUxDUk1VRkNjNURTeGMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1q
d3NyZXEtMjAjc2VjdGlvbi0xMC40LjE8L2E+PGJyPg0KPGJyPg0KVG8gYmUgaG9uZXN0LCBJIGZl
ZWwgcXVpdGUgYmFkIGFib3V0IHRoZSBzaXR1YXRpb24gd2l0aCBKQVIgd2UgYXJlIGluPGJyPg0K
bm93LiBGb3Igc29tZSByZWFzb24gSSBoYWQgdGhlIGltcHJlc3Npb24gdGhhdCBPQXV0aCBKQVIg
d2FzIGdvaW5nIHRvIGJlPGJyPg0KdGhlIE9JREMgcmVxdWVzdCAvIHJlcXVlc3RfdXJpIGZvciBn
ZW5lcmFsIE9BdXRoIDIuMCB1c2UsIGFzIHdpdGggb3RoZXI8YnI+DQpPSURDIGJpdHMgdGhhdCBs
YXRlciBiZWNhbWUgZ2VuZXJhbCBwdXJwb3NlIE9BdXRoIDIuMCBzcGVjcy48YnI+DQo8YnI+DQpJ
IGZpbmQgaXQgdW5mb3J0dW5hdGUgSSBkaWRuJ3Qgbm90aWNlIHRoaXMgd2hlbiBJIHdhcyByZXZp
ZXdpbmcgdGhlIHNwZWM8YnI+DQppbiB0aGUgcGFzdC48YnI+DQo8YnI+DQpWbGFkaW1pcjxicj4N
Cjxicj4NCjxicj4NCk9uIDEwLzAxLzIwMjAgMjI6MzksIEZpbGlwIFNrb2thbiB3cm90ZTo8YnI+
DQomZ3Q7IFZsYWRpbWlyLCA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgdGhhdCB2ZXJ5IGNhc2Ug
dGhlIHBheWxvYWQgY2xhaW1zIG1heSBiZSByZXBlYXRlZCBpbiB0aGUgSldFIHByb3RlY3RlZCBo
ZWFkZXIuIEFuIGltcGxlbWVudGF0aW9uIHdhbnRpbmcgdG8gaGFuZGxlIHRoaXMgbWF5IGxvb2sg
Zm9yIGlzcy9jbGllbnRfaWQgdGhlcmUuDQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPZGVzbMOhbm8g
eiBpUGhvbnU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgMTAuIDEuIDIwMjAgdiAyMToxOSwgVmxh
ZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5j
b20iIHRhcmdldD0iX2JsYW5rIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7Ojxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg77u/SSBqdXN0IHJlYWxpc2VkIHRoZXJlIGlzIG9uZSBj
bGFzcyBvZiBKQVJzIHdoZXJlIGl0J3MgcHJhY3RpYWxseTxicj4NCiZndDsmZ3Q7IGltcG9zc2li
bGUgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdCBpZiBtZXJnZSBpc24ndCBzdXBwb3J0ZWQ6PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgY2xpZW50IHN1Ym1pdHMgYSBKQVIgZW5jcnlwdGVk
IChKV1QpIHdpdGggYSBzaGFyZWQga2V5LiBPSURDIGFsbG93czxicj4NCiZndDsmZ3Q7IGZvciB0
aGF0IGFuZCBzcGVjcyBhIG1ldGhvZCBmb3IgZGVyaXZpbmcgdGhlIHNoYXJlZCBrZXkgZnJvbSB0
aGU8YnI+DQomZ3Q7Jmd0OyBjbGllbnRfc2VjcmV0Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNBJTJGJTJGb3BlbmlkLm5ldCUyRnNwZWNzJTJGb3BlbmlkLWNvbm5lY3Qt
Y29yZS0xXzAuaHRtbCUyM0VuY3J5cHRpb24mYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9u
ZXMlNDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4Nzkz
MTkzJmFtcDtzZGF0YT1zb0s5dDdwenU1MDRpSUx1RE5GbkclMkJNTHhaUFAycE42dWdFSjRaT3Bx
ZDQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vb3BlbmlkLm5l
dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI0VuY3J5cHRpb248L2E+PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiB0aGUgSkFSIGlzIGVuY3J5cHRlZCB3aXRoIHRoZSBj
bGllbnRfc2VjcmV0LCBhbmQgdGhlcmUgaXMgbm88YnI+DQomZ3Q7Jmd0OyB0b3AtbGV2ZWwgY2xp
ZW50X2lkIHBhcmFtZXRlciwgdGhlcmUncyBubyBnb29kIHdheSBmb3IgdGhlIE9QIHRvIGZpbmQ8
YnI+DQomZ3Q7Jmd0OyBvdXQgd2hpY2ggY2xpZW50X3NlY3JldCB0byBnZXQgdG8gdHJ5IHRvIGRl
Y3J5cHQgdGhlIEpXRS4gVW5sZXNzIHRoZSBPUDxicj4NCiZndDsmZ3Q7IGtlZXBzIGFuIGluZGV4
IG9mIGFsbCBpc3N1ZWQgY2xpZW50X3NlY3JldCdzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBPUCBzZXJ2ZXJzIHdoaWNoIHJlcXVpcmUgcmVxdWVzdF91cmkgcmVn
aXN0cmF0aW9uPGJyPg0KJmd0OyZndDsgKHJlcXVpcmVfcmVxdWVzdF91cmlfcmVnaXN0cmF0aW9u
PXRydWUpIGFuZCBkb24ndCB3YW50IHRvIGluZGV4IGFsbDxicj4NCiZndDsmZ3Q7IHJlZ2lzdGVy
ZWQgcmVxdWVzdF91cmkncywgYWxzbyBoYXZlIG5vIGdvb2Qgd2F5IHRvIHByb2Nlc3MgYSByZXF1
ZXN0X3VyaTxicj4NCiZndDsmZ3Q7IGlmIHRoZSBjbGllbnRfaWQgaXNuJ3QgcHJlc2VudCBhcyB0
b3AtbGV2ZWwgcGFyYW1ldGVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyBWbGFkaW1pcjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgT24gMTAvMDEvMjAyMCAyMDoxMywgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZTo8YnI+DQom
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbSAxMC4wMS4yMDIwIHVtIDE2
OjUzIHNjaHJpZWIgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0
Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgSSB0aGluayBUb3JzdGVuIGlzIHNwZWN1bGF0aW5nIHRoYXQgaXMgbm90
IGEgZmVhdHVyZSBwZW9wbGUgdXNlLiZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyZndDsgSeKA
mW0gc3RpbGwgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIGZvciBtZXJnaW5nIHNp
Z25lZCBhbmQgdW5zaWduZWQgcGFyYW1ldGVycy4gTmF0IG9uY2UgZXhwbGFpbmVkIGEgdXNlIGNh
c2UsIHdoZXJlIGEgY2xpZW50IHVzZXMgcGFyYW1ldGVycyBzaWduZWQgYnkgYSAzcmQgcGFydHkg
KHNvbWUg4oCeY2VydGlmaWNhdGlvbiBhdXRob3JpdHnigJwpIGluIGNvbWJpbmF0aW9uIHdpdGgg
dHJhbnNhY3Rpb24tc3BlY2lmaWMgcGFyYW1ldGVycy4NCiBJcyB0aGlzIGJlaW5nIGRvbmUgaW4g
dGhlIHdpbGQ/IDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBQUzogUEFSIHdv
dWxkIHdvcmsgd2l0aCBib3RoIG1vZGVzLjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1
dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp
bG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMl
NDBtaWNyb3NvZnQuY29tJTdDYzQ3MGQ0ZWM0YmQxNGQ0ODFjMGYwOGQ3OTYxYThhYmIlN0M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTQyOTEzMDY4ODAzMTQ1
JmFtcDtzZGF0YT1rb2JIJTJGc0dUN0VsU1NVQ0p2dSUyRmJpQXFuUkNYeCUyQjRTWk5Kc3JMJTJG
Q3VWeWMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovLzwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlZsYWRpbWly
IER6aHV2aW5vdjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CH2PR00MB0679453419D7494476B21DFDF5370CH2PR00MB0679namp_--


From nobody Wed Jan 15 15:00: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 632FE120A4A; Wed, 15 Jan 2020 15:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RgBCvyrl5a8q; Wed, 15 Jan 2020 15:00:27 -0800 (PST)
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 A920C120A9A; Wed, 15 Jan 2020 15:00:26 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 5FA25F40725; Wed, 15 Jan 2020 15:00:23 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20200115230023.5FA25F40725@rfc-editor.org>
Date: Wed, 15 Jan 2020 15:00:23 -0800 (PST)
Archived-At: 
Subject: [OAUTH-WG] =?utf-8?q?RFC_8693_on_OAuth_2=2E0_Token_Exchange?=
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 23:00:35 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8693

        Title:      OAuth 2.0 Token Exchange 
        Author:     M. Jones, 
                    A. Nadalin,
                    B. Campbell, Ed.,
                    J. Bradley,
                    C. Mortimore
        Status:     Standards Track
        Stream:     IETF
        Date:       January 2020
        Mailbox:    mbj@microsoft.com, 
                    tonynad@microsoft.com, 
                    brian.d.campbell@gmail.com,
                    ve7jtb@ve7jtb.com, 
                    chuck.mortimore@visa.com
        Pages:      27
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-oauth-token-exchange-19.txt

        URL:        https://www.rfc-editor.org/info/rfc8693

        DOI:        10.17487/RFC8693

This specification defines a protocol for an HTTP- and JSON-based
Security Token Service (STS) by defining how to request and obtain
security tokens from OAuth 2.0 authorization servers, including
security tokens employing impersonation and delegation.

This document is a product of the Web Authorization Protocol Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Jan 15 15:12: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 7114E120113 for ; Wed, 15 Jan 2020 15:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 1WTRUetHcok4 for ; Wed, 15 Jan 2020 15:11:58 -0800 (PST)
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 EF3FD120110 for ; Wed, 15 Jan 2020 15:11:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U17DFjMPkZ0/qvylfkL5XgMFCHj7Im0goLQqN2buZ1JdTjytjWvM8iZaoG1PWNJwf25vrtkHZAlfCBJAByyQ0sXnVxsJSKbKb8cYEZl/8PvzwvsvuUFFT9n+KHTT+6h/d1TpNvM5Cg/ARspwMWVnOVhNAPqIWkg4xieBrwvw3Z8S+pLA8HZc+Hc8kxie516RoSZYC7JrOfyDxolqcaAEa7ZnvifL8Tk5uiBzUWW7eYzPaSzK5HYvk9iKTR81rQ5RTgvAqhu7KzUY766vihx8rKYycnD/ChHTAEdeuFrsjJYUYKzY/6tdYKZEEZOpIDkkEL6QEww/Xl6551Br08Eo5g==
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=zQVT4EQyqai2wqfRfdMbIIvynx33jAYBNIhbRHNsD4M=; b=ao6y6xcS4B0TPd9RcRSrNuaTKHbImp0ldLSjajNm9s+Cy/hf5e+9uNXq9C8InzmOGLjtyqzQPslXi+Z2rVHiPBewH0pO1p/qcnIsOay/x2U3jMaXmxLNjuXAK9v/Su+F+ZZ3GLXVUNlLmeAjJrXaMS1joP1p7ELeEoUkBCSq/ok+ulAJfEoKs34/7Khw0AWOzv1HTV4+pFlN+llProuAhMBNFbRv4J/nmVmXOgRATRxaNGVAnNmOvilMmI6Upbk07G6gBzjkgIrQJYrh4vxROlYUFimKcoRDF8lcPvRERMioEp+v3ljCKIb7PdjRJSxavhIeTbfOsWu71p98Xlf3JA==
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=zQVT4EQyqai2wqfRfdMbIIvynx33jAYBNIhbRHNsD4M=; b=PCNOfXeBL0bqDFVaLpfQq5dnm3VnzjmpjoUG0s9JAbGi/FHm6Iv6iHqwKHeL9Xo6RkmJkmvR5qZAGi2bSYPKYN9rdZkI0oagiRE1H/XaYR48HzDL/lVy16MZDRHjBNZeCka8g68ubiTdXaqkiL8Z9refCwVUmkcgbWUsg1gVlE8=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (20.180.16.71) by CH2PR00MB0812.namprd00.prod.outlook.com (10.186.139.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2684.0; Wed, 15 Jan 2020 23:11:56 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::bc12:5826:ded6:299]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::bc12:5826:ded6:299%5]) with mapi id 15.20.2671.000; Wed, 15 Jan 2020 23:11:56 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Token Exchange is now RFC 8693
Thread-Index: AdXL+N5yJ7+3/yxcQkuV3r8hGIpXRw==
Date: Wed, 15 Jan 2020 23:11: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=457b4dbd-7e75-4fb1-b642-000085b3e52b; 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-01-15T23:09:38Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [2001:4898:80e8:9:9985:3257:75a:5b2f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: aa3ebfc1-ff6f-47c6-1531-08d79a1050e9
x-ms-traffictypediagnostic: CH2PR00MB0812:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 02830F0362
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(366004)(396003)(39860400002)(376002)(346002)(136003)(189003)(199004)(4744005)(8936002)(9686003)(5660300002)(81166006)(81156014)(8676002)(71200400001)(6916009)(8990500004)(7696005)(478600001)(316002)(6506007)(2906002)(66476007)(66556008)(66446008)(66946007)(64756008)(86362001)(76116006)(186003)(10290500003)(33656002)(52536014)(55016002)(966005)(21615005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0812; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: i7WwjWahv8Aj1IsmXmxneBCVNMIKoOVsgDhL8/v/vC/dHzw5JXWmRAM3k2GwQGhnLpWv+UQGFqAr5C1e40I7+4dc0/gtb0b/4HnOO8gjvZjfAwKwTRxvLt202njPLhjozefGagzeYHnfVgIZyYco83rbb50si1p+FRbeP087x4iAkai3aqi/rQ5rGFtoaVagUBpRp2pUFLExxH/LUfW/C9PsHxOhehApyCxLDKR8Atc1dx1mgFAlfKfRGJI0On+Wo/GCVESWAvJjuiURsgUARAUy3Y0shOxgMiPgXkHbQnB33kv2I4/bcomMfgYX9QY8imYXdHphOPrw+48CZy8QRjvsFhltz1S1FnULlh/sqxxN4X4t7nxhHFaUGZD41jDDT8gPh8y7PuI8g6fMZ0o8hTx2luzh8V6kzCLuM3xDtrAcsNXFVLJ8i9fbu6i89gFdbxfeGkrWa+q+7Da2UmmPD7IIFajsNb9N+44C+Zm21sIPpQwsP2EoiczeHLB2mIFQQ6sNfX4ccawsgFvfcFo4HsKsPSWUpvzqX/0Vf8WkgmX14hREU41XicT+umG/JbSeHMG91qVmCHFPpq55SaRJcAel7y9rk7Ejc/g5F2l/Hks=
x-ms-exchange-antispam-messagedata: HWdonSjnCtV4fzY4E2reoL27lnv7gYR6vNh1VQFql7TEKjeCHSHXdAKKmu/10E5abpH4f8LqUOuqxcqnZXQ5Dz9Fn1O5XBlvQifpCYWylkkxTC7BGun8Uzpv2+eGgFcZOVkJgkEvv7/+OUqxQHPDfVd18Dt2xKwJ3N2/WVRXocDIC0vxf7hULP3Jz5pm8Si0dOi51W2D8UsauVgCsPDwMw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679112F25F3B90D9C3DEB26F5370CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa3ebfc1-ff6f-47c6-1531-08d79a1050e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 23:11:56.2069 (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: l8/UTgc1kFqY4o0R0dfOSDCfpVR2c6sV5gsxnJArQ684TWZjnAlITGXKwiUXC8OKpfqpnwiqQEFgW1DICZZ2Cg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0812
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.0 Token Exchange is now RFC 8693
X-BeenThere: oauth@ietf.org
X-Mailman-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, 15 Jan 2020 23:12:00 -0000

--_000_CH2PR00MB0679112F25F3B90D9C3DEB26F5370CH2PR00MB0679namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 Token Exchange specification  is now RFC 8693.  The abstract of the specification is:
This specification defines a protocol for an HTTP- and JSON-based Security =
Token Service (STS) by defining how to request and obtain security tokens f=
rom OAuth 2.0 authorization servers, including security tokens employing im=
personation and delegation.

This specification standardizes an already widely-deployed pattern in produ=
ction use by Box, Microsoft, RedHat, Salesforce, and many others.  Thanks t=
o all of you who helped make a standard for this important functionality!

                                                       -- Mike

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


--_000_CH2PR00MB0679112F25F3B90D9C3DEB26F5370CH2PR00MB0679namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The OAuth 2.0 Token Exchange specification  is =
now 
RFC 8693.  The abstract of the specification is:


This specification define=
s a protocol for an HTTP- and JSON-based Security Token Service (STS) by de=
fining how to request and obtain security tokens from OAuth 2.0 authorizati=
on servers, including security tokens
 employing impersonation and delegation.


 


This specification standardizes an already widely-de=
ployed pattern in production use by Box, Microsoft, RedHat, Salesforce, and=
 many others.  Thanks to all of you who helped make a standard for thi=
s important functionality!


 


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


 


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


 






--_000_CH2PR00MB0679112F25F3B90D9C3DEB26F5370CH2PR00MB0679namp_--


From nobody Wed Jan 15 17:30: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 4968D120882 for ; Wed, 15 Jan 2020 17:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.497
X-Spam-Level: 
X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfEXtFLbniMR for ; Wed, 15 Jan 2020 17:30:41 -0800 (PST)
Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B5E12008F for ; Wed, 15 Jan 2020 17:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579138242; x=1610674242; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pXZTWxYu3YHNIqPen4OFZKXoPmbQ2BUXsWEKy90ps3I=; b=S6WA++jzTwqOe37ITyoQioEp4Q6WhYVf+nkuc4/nkmKhKzngEkVgjRLn SHIdv3udZF9ObbrbhVdmkjr8p0+HYXPK4/vfGTZ9FA5UWOt+KBiSp9p/R TZeqgOgFjMyh9tlIL/WKWhX1d+9dMejS3D5o7Q4LI8VmoD4n+6lMOyNG/ E=;
IronPort-SDR: McBrqm54DpUfcTuk7ad545wopeBsSoGG9qhn/bOvWJv8oKJMaHPc6jYyX3mqIS8cdOHvPf2kjY IapJvoEZi3CA==
X-IronPort-AV: E=Sophos; i="5.70,323,1574121600"; d="scan'208,217"; a="12583137"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 16 Jan 2020 01:30:39 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com (Postfix) with ESMTPS id 51E15A07C6; Thu, 16 Jan 2020 01:30:37 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 01:30:32 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 01:30:31 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 16 Jan 2020 01:30:31 +0000
From: "Richard Backman, Annabelle" 
To: Vladimir Dzhuvinov , Justin Richer 
CC: oauth , Nat Sakimura , "Richard Backman,  Annabelle" 
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
Thread-Index: AQHVyGnmuDzxiSgL6kO/nJ8pkgSMsqfo3hWAgANXHYD//8zygA==
Date: Thu, 16 Jan 2020 01:30:31 +0000
Message-ID: <05BEC41F-8709-41B7-A691-3B679618E854@amazon.com>
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.18]
Content-Type: multipart/alternative; boundary="_000_05BEC41F870941B7A6913B679618E854amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 01:30:46 -0000

--_000_05BEC41F870941B7A6913B679618E854amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHByb2JsZW0gaXMgdGhlIEpXVCByZXF1aXJlbWVudCBpbiBKQVIsIG5vdCBob3cgd2UgdGFs
ayBhYm91dCBQQVIgcmVxdWVzdF91cmkgdmFsdWVzIGluIFBBUi4gV2UgbmVlZCB0byBlaXRoZXIg
Y2hhbmdlIHRoZSBsYW5ndWFnZSBpbiBKQVIgKHNlZSBteSBzdWdnZXN0aW9ucyBlbHNld2hlcmUg
aW4gdGhpcyB0aHJlYWQpLCBvciBhZGQgdGV4dCBpbiBQQVIgdGhhdCBleHBsaWNpdGx5IGV4ZW1w
dHMgUEFSIHJlcXVlc3RfdXJpIHZhbHVlcyAob3IgcHJlZmVyYWJseSBhbGwgQVMtcHJvdmlkZWQg
cmVxdWVzdF91cmkgdmFsdWVzKSBmcm9tIHRoaXMgcmVxdWlyZW1lbnQgKGFsc28gc2VlIG15IHN1
Z2dlc3Rpb25zIGVsc2V3aGVyZSBpbiB0aGlzIHRocmVhZCkuDQoNCk15IHByZWZlcmVuY2UgcmVt
YWlucyB0aGUgZm9ybWVyLiBJdCBzdHJpa2VzIG1lIGFzIGJhZCBmb3JtIGZvciBvbmUgZXh0ZW5z
aW9uIHRvIG92ZXJyaWRlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgbGFpZCBvdXQgaW4gYW5vdGhl
ciBkb2N1bWVudC4gR3JhbnRlZCwgdGhlIGluY29tcGF0aWJpbGl0eSBzY2VuYXJpb3MgaW50cm9k
dWNlZCBieSB0aGlzIHJldGNvbiBhcmUgZWRnZS1jYXNlIGF0IGJlc3QsIGJ1dCB0aGF0IGp1c3Qg
cmFpc2VzIHRoZSBxdWVzdGlvbiBvZiB3aHkgd2UgY2Fu4oCZdCBmaXggdGhlIGRyYWZ0IHRoYXQg
aGFzbuKAmXQgYWN0dWFsbHkgYmVlbiBwdWJsaXNoZWQgeWV0Lg0KDQrigJMNCkFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBj
b25uZWN0MmlkLmNvbT4NCk9yZ2FuaXphdGlvbjogQ29ubmVjdDJpZCBMdGQuDQpEYXRlOiBXZWRu
ZXNkYXksIEphbnVhcnkgMTUsIDIwMjAgYXQgMTI6MzQgUE0NClRvOiBKdXN0aW4gUmljaGVyIDxq
cmljaGVyQG1pdC5lZHU+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPiwgTmF0IFNha2ltdXJh
IDxuYXRAc2FraW11cmEub3JnPiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu
bmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogUEFSOiBwdXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUg
SldUcw0KDQpPbiAxMy8wMS8yMDIwIDE5OjMyLCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KVG8gYmUg
Y2xlYXIsIEnigJltIG5vdCBzYXlpbmcgd2Ugc3VnZ2VzdCBhIHBhcnRpY3VsYXIgZm9ybSwgYW5k
IEkgYWdyZWUgdGhhdCB3ZSBzaG91bGRu4oCZdCBzcGVjaWZ5IHRoYXQg4oCcaXTigJlzIGEgSldU
4oCdIG9yIHNvbWV0aGluZyBvZiB0aGF0IG5hdHVyZS4gQnV0IGlmIHdlIGNhbGwgdGhlIHJlc3Vs
dCBvZiBQQVIg4oCcdGhpbmcgWOKAnSBhbmQgdGhlIHRhcmdldCBvZiByZXF1ZXN0X3VyaSDigJx0
aGluZyBY4oCdIGluIEpBUiwgdGhlbiB3ZeKAmXJlIGNvbXBhdGlibGUgd2l0aG91dCBzYXlpbmcg
d2hhdCDigJx0aGluZyBY4oCdIG5lZWRzIHRvIGJlIGluIGFsbCBjYXNlcy4NCg0KR29vZCwgd2Un
cmUgb24gdGhlIHNhbWUgcGFnZSB0aGVuLg0KDQpIb3cgYWJvdXQgc2ltcGx5IHNheWluZyB0aGF0
IHRoZSByZXN1bHQgb2YgUEFSIGlzIGFuIFVSSSByZWZlcmVuY2luZyB0aGUgcHVzaGVkIGF1dGha
IHJlcXVlc3Q7IGF0IHRoZSBhdXRoWiBlbmRwb2ludCBpdHMgcHJvY2Vzc2luZyBpcyBjb21wbGV0
ZWQuDQoNCk5vIG5lZWQgaXMgYm90aCBjbGVhciBhbmQgYWJzdHJhY3QgZW5vdWdoIHRvIG5vdCBy
ZXF1aXJlIGEgZm9ybSB0byBiZSBzcGVjaWZpZWQuDQoNCg0KSW4gY2FzZXMgd2hlcmUgeW91IGRv
IGEgcmVtb3RlIGxvb2sgdXAsIHdlIHdhbnQg4oCcdGhpbmcgWOKAnSB0byBiZSBmb3JtYXR0ZWQg
YXMgYSBKV1QuDQoNCkJ1dCB3aHk/DQoNCkJvdGggUEFSIGFuZCBhdXRoWiBlbmRwb2ludHMgYmVs
b25nIHRvIHRoZSBBUywgd2hpY2ggbWFrZXMgdGhhdCBpbXBsIHNwZWNpZmljLiBUaGUgVVJJIGlz
IHRoZSBjb250cmFjdCwgYmV0d2VlbiBjbGllbnQgYW5kIEFTLg0KDQpUaGUgQVMsIGlmIHVTZXJ2
aWNlIGJhc2VkLCBjb3VsZCBjaG9vc2UgdG8gaW1wbGVtZW50IHRoYXQgYXMgQ0JPUiBXZWIgVG9r
ZW4sIG9yIHNvbWUgb3RoZXIgdmVyaWZpYWJsZSBibG9iLCByZXN1bHRpbmcgaW4gdGhlIHNhbWUg
ZXNzZW50aWFsIGZ1bmN0aW9uLCBhbmQgdGhpcyBpc24ndCBhZmZlY3RpbmcgdGhlIGNsaWVudCA8
LT4gQVMgY29udHJhY3QgaW4gYW55IHdheS4NCg0KDQpXZSBoYWQgYSBjYXNlIG9mIHNpbWlsYXJs
eSB1bmludGVudGlvbmFsIGxpbWl0aW5nIGluIEpBUiBwcmV2aW91c2x5LCBzYXlpbmcgdGhhdCB5
b3UgaGFkIHRvIGRvIGFuIEhUVFAgbG9va3VwIG9uIHRoZSByZXF1ZXN0X3VyaSwgYnV0IEkgYmVs
aWV2ZSB0aGF04oCZcyBiZWVuIGJhY2tlZCBvZmYgbm93IGFuZCBtYWRlIGNvbmRpdGlvbmFsLg0K
DQpUaGF0IHdhcyBwcmVjaXNlbHkgbXkgcG9pbnQuDQoNClZsYWRpbWlyDQoNCg0KDQoNCiDigJQg
SnVzdGluDQoNCg0KT24gSmFuIDExLCAyMDIwLCBhdCA1OjI4IEFNLCBWbGFkaW1pciBEemh1dmlu
b3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNv
bT4+IHdyb3RlOg0KDQpNeSBzdWdnZXN0aW9uIGlzIHRvIGFic3RhaW4gZnJvbSBzcGVjaWZ5aW5n
IHRoZSBjb25jcmV0ZSBmb3JtIG9mIHRoZSByZXNvdXJjZSBwb2ludGVkIHRvIGJ5IHRoZSBQQVIg
VVJJLiBSZWdhcmRsZXNzIG9mIFVSSSB0eXBlIChVUk4sIGRvd25sb2FkYWJsZSBodHRwcyBVUkwg
b3Igc29tZXRoaW5nIGVsc2UpLCBhbmQgZXZlbiBpZiB0aGUgUEFSIGVuZHBvaW50IGFuZCB0aGUg
YXV0aFogZW5kcG9pbnQgYXJlIG1hbmFnZWQgYnkgdHdvIGRpZmZlcmVudCBlbnRpdGllcyAobWlj
cm9zZXJ2aWNlIG9yIG90aGVyIHNjZW5hcmlvKS4NCkluIHRoZSBDb25uZWN0MmlkIGltcGxlbWVu
dGF0aW9uIG9mIFBBUiB0aGUgcmV0dXJuZWQgVVJJIGRvZXNuJ3QgcG9pbnQgdG8gYSByZXF1ZXN0
IG9iamVjdCBhbmQgaXQgZG9lc24ndCBwb2ludCB0byBhIEpXVCBlaXRoZXIuIEl0IHBvaW50cyB0
byBhbiBpbnRlcm5hbGx5IHN0b3JlZCAicHJlLXByb2Nlc3NlZCIgYXV0aFogcmVxdWVzdCwgd2hp
Y2ggdGhlIGF1dGhaIGVuZHBvaW50IHRoZW4gcGlja3MgdXAgdG8gY29tcGxldGUgdGhlIGF1dGha
Lg0KRXZlbiBpZiB3ZSBldmVudHVhbGx5IGVuZCB1cCBpbiBtaWNyb3NlcnZpY2Ugd29ybGQsIG9y
IGFsbG93IHRoZSBQQVIgZW5kcG9pbnQgdG8gYmUgbWFuYWdlZCBieSBzb21lIGV4dGVybmFsIGVu
dGl0eSwgdGhlIFBBUiBVUkkgLSBpdHMgaW50ZXJwcmV0YXRpb24sIHZhbGlkYXRpb24gYW5kIHBv
dGVudGlhbGx5IHJlc291cmNlIHJldHJpZXZhbCAoSldUIG9yIG90aGVyIGJsb2IpLCBpcyBhbiAi
aW50ZXJuYWwgY29udHJhY3QiIG9uIHRoZSBBUyBzaWRlLiBUaGlzIGRvZXNuJ3QgY29uY2VybiB0
aGUgY2xpZW50LCBhbmQgaW4gT0F1dGggMi4wIHRoZSByb2xlIG9mIEFTIGlzIGluZGl2aXNpYmxl
Lg0KDQpJIHNlZSBQQVIgcmVxdWVzdCArIGF1dGhaIHJlcXVlc3QgYXMgb25lIGxvZ2ljYWwgT0F1
dGggMi4wIGF1dGhaIHJlcXVlc3Q6IHRoZSBjbGllbnQgc3VibWl0cyBhbiBhdXRoWiByZXF1ZXN0
IGFuZCBnZXRzIGFuIGF1dGhaIHJlc3BvbnNlIGF0IHRoZSBlbmQuIFRoZSBVUkkgaXMgbmVjZXNz
YXJ5IGZvciB0aGUgY2xpZW50IHRvIHByb2NlZWQgZnJvbSB0aGUgMXN0IHRvIHRoZSAybmQgc3Rl
cC4gSWYgd2UgbWFuYWdlIHRvIGZyYW1lIC8gd29yZCB0aGUgUEFSIFVSSSBpbiB0aGlzIGxvZ2lj
YWwgd2F5LCB3aXRob3V0IGdldHRpbmcgc3R1Y2sgaW4gdGhlIEpBUiBkZWZpbml0aW9uIC8gZnJh
bWluZyBvZiB3aGF0IHRoZSByZXF1ZXN0X3VyaSAvIG9iamVjdCBpcywgaXQgd291bGQgYmUgZ3Jl
YXQuDQoNClRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgSSB0aGluayBzaG91bGQgZm9jdXMgb24gbWFp
bnRhaW5pbmcgdGhlIE9BdXRoIDIuMCBjb250cmFjdCBmb3IgdGhlIGVudGlyZSBsb2dpY2FsIGF1
dGhaIHJlcXVlc3QsIHRvZ2V0aGVyIHdpdGggdGhlIGJhc2ljIGNvbnRyYWN0cyBvZiAxKSBKQVIg
YW5kIHRoZSAyKSBhdXRoWiBlbmRwb2ludC4NCg0KVmxhZGltaXINCg0KT24gMTAvMDEvMjAyMCAy
Mjo1NSwgSnVzdGluIFJpY2hlciB3cm90ZToNClNvIHdlIGNvdWxkIHNvbHZlIHRoaXMgYnkgc2F5
aW5nIHRoZSByZXN1bHRpbmcgZGF0YSBvYmplY3Qgb2YgYSBQQVIgaXMgYSByZXF1ZXN0IG9iamVj
dC4gV2hpY2ggbWlnaHQgYWxzbyBjb250YWluIGEgcmVxdWVzdCBvYmplY3QgaW50ZXJuYWxseSBh
cyB3ZWxsLiBJbiB0aGF0IGNhc2UgSkFSIHNob3VsZCBiYWNrIG9mZiBmcm9tIHNheWluZyBpdOKA
mXMgYSBKV1QgYW5kIGluc3RlYWQgc2F5IGl04oCZcyBhIHJlcXVlc3Qgb2JqZWN0LiBPciB3ZSBk
ZWZpbmUgYSBuZXcgdGVybSBmb3IgdGhpcyBhdXRob3JpemF0aW9uIHJlcXVlc3QgYmxvYiB0aGlu
Zy4NCg0KT3IgUEFSIGNvdWxkIGF0IGxlYXN0IHNheSB0aGF0IGlmIGl04oCZcyBkZXJlZmVyZW5j
ZWQgb3ZlciBhIHJlbW90ZSBwcm90b2NvbCB0aGVuIGl0IE1VU1QgYmUgYSBKV1QsIGJ1dCBvdGhl
cndpc2UgaXQgY2FuIGJlIHdoYXRldmVyIHlvdSB3YW50LiBUaGF04oCZcyB3aGVyZSB0aGUgcmVh
bCBpbnRlcm9wIGNvbmNlcm5zIGNvbWUgaW4uDQoNCiDigJQgSnVzdGluDQoNCg0KT24gSmFuIDEw
LCAyMDIwLCBhdCAzOjQxIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9
NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpyaWNoYW5uYT00MGFtYXpvbi5jb21A
ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KQ29ycmVjdC4gVGhlIHByb2JsZW0gYmVjb21lcyBw
cmV0dHkgY2xlYXIgaW4gdGhlIGNvbnRleHQgb2YgUEFSLCB3aGVyZSB0aGUgQVMgaXMgZ2VuZXJh
dGluZyBhbmQgdmVuZGluZyBvdXQgdGhlIFVSSSBhdCB0aGUgUEFSIGVuZHBvaW50LCBhbmQgY29u
c3VtaW5nIGl0IGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBGcm9tIGFuIGludGVyb3Bl
cmFiaWxpdHkgc3RhbmRwb2ludCwgaXTigJlzIGFuYWxvZ291cyB0byB0aGUgQVMgdmVuZGluZyBh
biBhdXRob3JpemF0aW9uIGNvZGUgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGNv
bnN1bWluZyBpdCBhdCB0aGUgdG9rZW4gZW5kcG9pbnQuDQrigJMNCkFubmFiZWxsZSBSaWNoYXJk
IEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZl
N2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkRhdGU6IEZyaWRheSwgSmFudWFy
eSAxMCwgMjAyMCBhdCAxMjoyOSBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGlu
Z2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KQ2M6IFRv
cnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldD4+LCBOYXQgU2FraW11cmEgPG5hdEBzYWtpbXVyYS5vcmc8bWFpbHRv
Om5hdEBzYWtpbXVyYS5vcmc+PiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu
bmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBvYXV0aCA8b2F1dGhA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNF
TkRFUl0gUmU6IFtPQVVUSC1XR10gUEFSOiBwdXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUgSldU
cw0KDQpJZiB3ZSBhc3N1bWUgdGhlIGNsaWVudCBwb3N0cyBhIEpBUiBhbmQgZ2V0cyBiYWNrIGEg
cmVmZXJlbmNlLiAgVGhlbiB0aGUgcmVmZXJlbmNlIGlzIHRvIGEgSkFSLg0KDQpJIHRoaW5rIEkg
c2VlIHRoZSBwcm9ibGVtLiAgSWYgdGhlIHNlcnZlciBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZSBp
cyBhc3NvY2lhdGVkIHdpdGggdGhlIEFTIHRoZW4gdGhlIHNlcnZlciBkb3Nlbid0IG5lZWQgdG8g
ZGVyZWZlcmVuY2UgdGhlIG9iamVjdCB2aWEgSFRUUCwgc28gaXQgY291bGQgYmUgYSBVUk4gYXMg
YW4gZXhhbXBsZS4NCg0KU28geWVzIGl0IGlzIG5vdCBhIGludGVyb3BlcmFiaWxpdHkgaXNzdWUg
Zm9yIHRoZSBjbGllbnQuDQoNCkkgd2lsbCB0aGluayBhYm91dCBob3cgSSBjYW4gZmluZXNzZSB0
aGF0Lg0KDQpJIGFncmVlIGl0IGlzIG5vdCBhIGNoYW5nZSBpbiBpbnRlbnQuDQoNCkkgd2lsbCBz
ZWUgaWYgSSBjYW4gZ2V0IG91ciBBRCB0byBhY2NlcHQgdGhhdC4NCg0KSm9obiBCLg0KDQoNCg0K
DQpPbiBGcmksIEphbiAxMCwgMjAyMCwgNDo1NyBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3Jv
dGU6DQpTdXJlIGJ1dCB0aGUgdGV4dCBwcm9wb3NlZCAob3Igc29tZXRoaW5nIGxpa2UgaXQpIHF1
YWxpZmllcyBpdCBzdWNoIHRoYXQgdGhlcmUgYXJlbid0IGludGVyb3BlcmFiaWxpdHkgcXVlc3Rp
b25zIGJlY2F1c2UgaXQncyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCB0byB0aGUgQVMg
d2hvIGJvdGggcHJvZHVjZXMgdGhlIFVSSSBhbmQgY29uc3VtZXMgaXRzIGNvbnRlbnQuDQoNCk9u
IEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEyOjQ4IFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJdCBtYXkgYmUgYSBjaGFs
bGVuZ2UgdG8gY2hhbmdlIHRleHQgc2F5aW5nIHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSByZXNv
dXJjZSBjb3VsZCBiZSBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIHJlcXVlc3Qgb2JqZWN0Lg0KDQpJ
ZiBub3QgYSByZXF1ZXN0IG9iamVjdCB0aGVuIHdoYXQgYW5kIGhvdyBpcyB0aGF0IGludGVyb3Bl
cmFibGUgYXJlIGxpa2VseSBBRCBxdWVzdGlvbnMuDQoNCkkgY291bGQgcGVyaGFwcyBzZWUgY2hh
bmdpbmcgaXQgdG8gbXVzdCBiZSBhIHJlcXVlc3Qgb2JqZWN0LCBvciBvdGhlciBmb3JtYXQgZGVm
aW5lZCBieSBhIHByb2ZpbGUuDQoNCkpvaG4gQi4NCg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCwg
Mzo0NSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv
OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpBZ3JlZSBhbmQgYWdyZWUuIEJ1
dCBnaXZlbiB0aGF0IHRoZSBjaGFuZ2Ugc3VnZ2VzdGVkIGJ5IEFubmFiZWxsZSBoYXMgbm8gaW1w
YWN0IG9uIHRoZSBjbGllbnQgb3IgaW50ZXJvcGVyYWJpbGl0eSwgcGVyaGFwcyBOYXQgb3IgSm9o
biBjb3VsZCB3b3JrIHRoZSBjaGFuZ2UgaW50byB0aGUgZHJhZnQgZHVyaW5nIHRoZSBlZGl0cyB0
aGF0IGhhcHBlbiBkdXJpbmcgdGhlIGZpbmFsIHN0YWdlcyBvZiB0aGluZ3M/DQoNCk9uIFRodSwg
SmFuIDksIDIwMjAgYXQgMTo1NiBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9k
ZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFy
Yy5pZXRmLm9yZz4+IHdyb3RlOg0KSSB3b3VsZCBhc3N1bWUgZ2l2ZW4gdGhlIHN0YXR1cyBvZiBK
QVIsIHdlIGRvbuKAmXQgd2FudCB0byBjaGFuZ2UgaXQuIEFuZCBhcyBJIHNhaWQsIHRoaXMgZGlm
ZmVyZW5jZSBkb2VzIG5vdCBpbXBhY3QgaW50ZXJvcGVyYWJpbGl0eSBmcm9tIGNsaWVudCBwZXJz
cGVjdGl2ZS4NCg0KDQoNCkFtIDA5LjAxLjIwMjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJh
Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1h
aWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PjoNCkl0IHdvdWxkIGJlIG1vcmUgYXBw
cm9wcmlhdGUgdG8gYWRkIHRoZSB0ZXh0IHRvIEpBUiByYXRoZXIgdGhhbiBQQVIuIEl0IGRvZXNu
J3Qgc2VlbSByaWdodCBmb3IgUEFSIHRvIHJldGNvbiBydWxlcyBpbiBKQVIuIE1vdmluZyB0aGUg
dGV4dCB0byBKQVIgYWxzbyBoaWdobGlnaHRzIHRoZSB3ZWlyZG5lc3Mgb2YgZ2l2aW5nIFBBUiBz
cGVjaWFsIHRyZWF0bWVudC4NCg0KV2hhdCBpZiB3ZSBjaGFuZ2VkIHRoaXMgc2VudGVuY2UgaW4g
U2VjdGlvbiA1LjIgb2YgSkFSOg0KVGhlIGNvbnRlbnRzIG9mIHRoZSByZXNvdXJjZSByZWZlcmVu
Y2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJlcXVlc3QNCk9iamVjdC4NCg0KVG86DQpUaGUgY29u
dGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVx
dWVzdA0KT2JqZWN0LCB1bmxlc3MgdGhlIFVSSSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBi
eSB0aGUgQXV0aG9yaXphdGlvbg0KU2VydmVyLg0KDQpUaGlzIHdvdWxkIGFsbG93IGZvciB1c2Ug
Y2FzZXMgc3VjaCBhcyBhbiBBUyB0aGF0IHByb3ZpZGVzIHByZS1kZWZpbmVkIHJlcXVlc3QgVVJJ
cywgb3IgdmVuZHMgcmVxdWVzdCBVUklzIHZpYSBhIGNsaWVudCBtYW5hZ2VtZW50IGNvbnNvbGUs
IG9yIGJha2VzIHRoZW0gaW50byB0aGVpciBjbGllbnQgYXBwcy4NCg0K4oCTDQpBbm5hYmVsbGUg
UmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KT24gMS84LzIwLCAyOjUwIFBNLCAiVG9y
c3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5v
cmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCiAg
ICBIaSwNCg0KICAgIHlvdSBhcmUgcmlnaHQsIFBBUiBkb2VzIG5vdCByZXF1aXJlIHRoZSBBUyB0
byByZXByZXNlbnQgdGhlIHJlcXVlc3QgYXMgYSBKV1QtYmFzZWQgcmVxdWVzdCBvYmplY3QuIFRo
ZSBVUkkgaXMgdXNlZCBhcyBpbnRlcm5hbCByZWZlcmVuY2Ugb25seS4gVGhhdCB3aHkgdGhlIGRy
YWZ0IHN0YXRlcw0KDQogICAgIlRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSB0aGUNCiAgICAgICAg
ICBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0YSBhdmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2
aWEgdGhpcw0KICAgICAgICAgIFVSSS7igJ0NCg0KICAgIFRoaXMgZGlmZmVyZW5jZSBtYXR0ZXJz
IGZyb20gYW4gQVMgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVy
IGZyb20gYSBjbGllbnQncyAoaW50ZXJvcCkgcGVyc3BlY3RpdmUuDQoNCiAgICBXZSBtYXkgYWRk
IGEgc3RhdGVtZW50IHRvIFBBUiBzYXlpbmcgdGhhdCByZXF1ZXN0X3VyaXMgaXNzdWVkIGJ5IHRo
ZSBQQVIgbWVjaGFuaXNtIChNQVkpIGRldmlhdGUgZnJvbSB0aGUgSkFSIGRlZmluaXRpb24uDQoN
CiAgICBiZXN0IHJlZ2FyZHMsDQogICAgVG9yc3Rlbi4NCg0KICAgID4gT24gOC4gSmFuIDIwMjAs
IGF0IDIzOjQyLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24u
Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3
cm90ZToNCiAgICA+DQogICAgPiBIaSBhbGwsDQogICAgPg0KICAgID4gVGhlIGN1cnJlbnQgZHJh
ZnRzIG9mIFBBUiAoLTAwKSBhbmQgSkFSICgtMjApIHJlcXVpcmUgdGhhdCB0aGUgQVMgdHJhbnNm
b3JtIGFsbCBwdXNoZWQgcmVxdWVzdHMgaW50byBKV1RzLiBUaGlzIHJlcXVpcmVtZW50IGFyaXNl
cyBmcm9tIHRoZSBmb2xsb3dpbmc6DQogICAgPiAgICAgICAgIOKAoiBQQVIgdXNlcyB0aGUgcmVx
dWVzdF91cmkgcGFyYW1ldGVyIGRlZmluZWQgaW4gSkFSIHRvIGNvbW11bmljYXRlIHRoZSBwdXNo
ZWQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4NCiAgICA+ICAgICAgICAg
4oCiIEFjY29yZGluZyB0byBKQVIsIHRoZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHJlcXVlc3Rf
dXJpIE1VU1QgYmUgYSBSZXF1ZXN0IE9iamVjdC4gKFNlY3Rpb24gNS4yKQ0KICAgID4gICAgICAg
ICDigKIgUmVxdWVzdCBPYmplY3QgaXMgZGVmaW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5nIGFs
bCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSkNCiAg
ICA+DQogICAgPiBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBv
cnQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlz
IGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0
ZW1wdGluZyB0byBkZWZpbmUgdGhlIGludGVybmFsIGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhl
IHR3byBBUyBlbmRwb2ludHMuIFdvcnNlLCB0aGlzIHJlc3RyaWN0aW9uIG1ha2VzIGl0IGhhcmRl
ciBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG8gbGV2ZXJhZ2UgdmFsaWRhdGlvbiBh
bmQgb3RoZXIgd29yayBwZXJmb3JtZWQgYXQgdGhlIFBBUiBlbmRwb2ludCwgYXMgdGhlIHN0YXRl
IG9yIG91dGNvbWUgb2YgdGhhdCB3b3JrIG11c3QgYmUgZm9yY2VkIGludG8gdGhlIEpXVCBmb3Jt
YXQgKG9yIHJldHJpZXZlZCB2aWEgYSBzdWJzZXF1ZW50IHNlcnZpY2UgY2FsbCBvciBkYXRhYmFz
ZSBsb29rdXApLg0KICAgID4NCiAgICA+IOKAkw0KICAgID4gQW5uYWJlbGxlIFJpY2hhcmQgQmFj
a21hbg0KICAgID4gQVdTIElkZW50aXR5DQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IE9BdXRoIG1haWxpbmcgbGlzdA0K
ICAgID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KICAgID4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl
bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y
IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1
c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o
aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl
dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl
ci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj
b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg
dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp
YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAg
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l
c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg
eW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWls
aW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCi0tDQoNClZsYWRpbWly
IER6aHV2aW5vdg0KDQoNCi0tDQoNClZsYWRpbWlyIER6aHV2aW5vdg0K

--_000_05BEC41F870941B7A6913B679618E854amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <31390DAF346ED842B6D62E588187E36F@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6
MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg
NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h
bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl
DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVm
b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIy
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9ibGVt
IGlzIHRoZSBKV1QgcmVxdWlyZW1lbnQgaW4gSkFSLCBub3QgaG93IHdlIHRhbGsgYWJvdXQgUEFS
IHJlcXVlc3RfdXJpIHZhbHVlcyBpbiBQQVIuIFdlIG5lZWQgdG8gZWl0aGVyIGNoYW5nZSB0aGUg
bGFuZ3VhZ2UgaW4gSkFSIChzZWUgbXkgc3VnZ2VzdGlvbnMgZWxzZXdoZXJlIGluIHRoaXMgdGhy
ZWFkKSwgb3IgYWRkIHRleHQgaW4gUEFSIHRoYXQgZXhwbGljaXRseSBleGVtcHRzIFBBUiByZXF1
ZXN0X3VyaQ0KIHZhbHVlcyAob3IgcHJlZmVyYWJseSBhbGwgQVMtcHJvdmlkZWQgcmVxdWVzdF91
cmkgdmFsdWVzKSBmcm9tIHRoaXMgcmVxdWlyZW1lbnQgKGFsc28gc2VlIG15IHN1Z2dlc3Rpb25z
IGVsc2V3aGVyZSBpbiB0aGlzIHRocmVhZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHBy
ZWZlcmVuY2UgcmVtYWlucyB0aGUgZm9ybWVyLiBJdCBzdHJpa2VzIG1lIGFzIGJhZCBmb3JtIGZv
ciBvbmUgZXh0ZW5zaW9uIHRvIG92ZXJyaWRlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgbGFpZCBv
dXQgaW4gYW5vdGhlciBkb2N1bWVudC4gR3JhbnRlZCwgdGhlIGluY29tcGF0aWJpbGl0eSBzY2Vu
YXJpb3MgaW50cm9kdWNlZCBieSB0aGlzIHJldGNvbiBhcmUgZWRnZS1jYXNlIGF0IGJlc3QsIGJ1
dCB0aGF0DQoganVzdCByYWlzZXMgdGhlIHF1ZXN0aW9uIG9mIHdoeSB3ZSBjYW7igJl0IGZpeCB0
aGUgZHJhZnQgdGhhdCBoYXNu4oCZdCBhY3R1YWxseSBiZWVuIHB1Ymxpc2hlZCB5ZXQuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi
ZWhhbGYgb2YgVmxhZGltaXIgRHpodXZpbm92ICZsdDt2bGFkaW1pckBjb25uZWN0MmlkLmNvbSZn
dDs8YnI+DQo8Yj5Pcmdhbml6YXRpb246IDwvYj5Db25uZWN0MmlkIEx0ZC48YnI+DQo8Yj5EYXRl
OiA8L2I+V2VkbmVzZGF5LCBKYW51YXJ5IDE1LCAyMDIwIGF0IDEyOjM0IFBNPGJyPg0KPGI+VG86
IDwvYj5KdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6IDwv
Yj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7LCBOYXQgU2FraW11cmEgJmx0O25hdEBzYWtp
bXVyYS5vcmcmZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7
cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6
IDwvYj5SZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBQQVI6IHB1c2hlZCBy
ZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMy8wMS8yMDIwIDE5OjMyLCBKdXN0aW4g
UmljaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRvIGJlIGNsZWFyLCBJ4oCZbSBub3Qgc2F5aW5nIHdlIHN1Z2dlc3QgYSBwYXJ0aWN1bGFy
IGZvcm0sIGFuZCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkbuKAmXQgc3BlY2lmeSB0aGF0IOKAnGl0
4oCZcyBhIEpXVOKAnSBvciBzb21ldGhpbmcgb2YgdGhhdCBuYXR1cmUuIEJ1dCBpZiB3ZSBjYWxs
IHRoZSByZXN1bHQgb2YgUEFSIOKAnHRoaW5nIFjigJ0gYW5kIHRoZSB0YXJnZXQgb2YgcmVxdWVz
dF91cmkg4oCcdGhpbmcgWOKAnSBpbiBKQVIsIHRoZW4NCiB3ZeKAmXJlIGNvbXBhdGlibGUgd2l0
aG91dCBzYXlpbmcgd2hhdCDigJx0aGluZyBY4oCdIG5lZWRzIHRvIGJlIGluIGFsbCBjYXNlcy4g
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Hb29kLCB3ZSdyZSBvbiB0aGUgc2Ft
ZSBwYWdlIHRoZW4uPG86cD48L286cD48L3A+DQo8cD5Ib3cgYWJvdXQgc2ltcGx5IHNheWluZyB0
aGF0IHRoZSByZXN1bHQgb2YgUEFSIGlzIGFuIFVSSSByZWZlcmVuY2luZyB0aGUgcHVzaGVkIGF1
dGhaIHJlcXVlc3Q7IGF0IHRoZSBhdXRoWiBlbmRwb2ludCBpdHMgcHJvY2Vzc2luZyBpcyBjb21w
bGV0ZWQuPG86cD48L286cD48L3A+DQo8cD5ObyBuZWVkIGlzIGJvdGggY2xlYXIgYW5kIGFic3Ry
YWN0IGVub3VnaCB0byBub3QgcmVxdWlyZSBhIGZvcm0gdG8gYmUgc3BlY2lmaWVkLjxvOnA+PC9v
OnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JbiBjYXNlcyB3aGVyZSB5b3UgZG8gYSByZW1vdGUgbG9vayB1cCwgd2Ugd2FudCDi
gJx0aGluZyBY4oCdIHRvIGJlIGZvcm1hdHRlZCBhcyBhIEpXVC4NCjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD5CdXQgd2h5PzxvOnA+PC9vOnA+PC9wPg0KPHA+Qm90
aCBQQVIgYW5kIGF1dGhaIGVuZHBvaW50cyBiZWxvbmcgdG8gdGhlIEFTLCB3aGljaCBtYWtlcyB0
aGF0IGltcGwgc3BlY2lmaWMuIFRoZSBVUkkgaXMgdGhlIGNvbnRyYWN0LCBiZXR3ZWVuIGNsaWVu
dCBhbmQgQVMuPG86cD48L286cD48L3A+DQo8cD5UaGUgQVMsIGlmIHVTZXJ2aWNlIGJhc2VkLCBj
b3VsZCBjaG9vc2UgdG8gaW1wbGVtZW50IHRoYXQgYXMgQ0JPUiBXZWIgVG9rZW4sIG9yIHNvbWUg
b3RoZXIgdmVyaWZpYWJsZSBibG9iLCByZXN1bHRpbmcgaW4gdGhlIHNhbWUgZXNzZW50aWFsIGZ1
bmN0aW9uLCBhbmQgdGhpcyBpc24ndCBhZmZlY3RpbmcgdGhlIGNsaWVudCAmbHQ7LSZndDsgQVMg
Y29udHJhY3QgaW4gYW55IHdheS48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGFkIGEgY2FzZSBvZiBzaW1p
bGFybHkgdW5pbnRlbnRpb25hbCBsaW1pdGluZyBpbiBKQVIgcHJldmlvdXNseSwgc2F5aW5nIHRo
YXQgeW91IGhhZCB0byBkbyBhbiBIVFRQIGxvb2t1cCBvbiB0aGUgcmVxdWVzdF91cmksIGJ1dCBJ
IGJlbGlldmUgdGhhdOKAmXMgYmVlbiBiYWNrZWQgb2ZmIG5vdyBhbmQgbWFkZSBjb25kaXRpb25h
bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+VGhhdCB3YXMgcHJl
Y2lzZWx5IG15IHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+VmxhZGltaXI8bzpwPjwvbzpwPjwv
cD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMTEsIDIwMjAsIGF0IDU6
MjggQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBzdWdnZXN0aW9u
IGlzIHRvIGFic3RhaW4gZnJvbSBzcGVjaWZ5aW5nIHRoZSBjb25jcmV0ZSBmb3JtIG9mIHRoZSBy
ZXNvdXJjZSBwb2ludGVkIHRvIGJ5IHRoZSBQQVIgVVJJLiBSZWdhcmRsZXNzIG9mIFVSSSB0eXBl
IChVUk4sIGRvd25sb2FkYWJsZSBodHRwcyBVUkwgb3Igc29tZXRoaW5nIGVsc2UpLA0KIGFuZCBl
dmVuIGlmIHRoZSBQQVIgZW5kcG9pbnQgYW5kIHRoZSBhdXRoWiBlbmRwb2ludCBhcmUgbWFuYWdl
ZCBieSB0d28gZGlmZmVyZW50IGVudGl0aWVzIChtaWNyb3NlcnZpY2Ugb3Igb3RoZXIgc2NlbmFy
aW8pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGUgQ29ubmVj
dDJpZCBpbXBsZW1lbnRhdGlvbiBvZiBQQVIgdGhlIHJldHVybmVkIFVSSSBkb2Vzbid0IHBvaW50
IHRvIGEgcmVxdWVzdCBvYmplY3QgYW5kIGl0IGRvZXNuJ3QgcG9pbnQgdG8gYSBKV1QgZWl0aGVy
LiBJdCBwb2ludHMgdG8gYW4gaW50ZXJuYWxseSBzdG9yZWQgJnF1b3Q7cHJlLXByb2Nlc3NlZCZx
dW90Ow0KIGF1dGhaIHJlcXVlc3QsIHdoaWNoIHRoZSBhdXRoWiBlbmRwb2ludCB0aGVuIHBpY2tz
IHVwIHRvIGNvbXBsZXRlIHRoZSBhdXRoWi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+RXZlbiBpZiB3ZSBldmVudHVhbGx5IGVuZCB1cCBpbiBtaWNyb3NlcnZpY2Ugd29y
bGQsIG9yIGFsbG93IHRoZSBQQVIgZW5kcG9pbnQgdG8gYmUgbWFuYWdlZCBieSBzb21lIGV4dGVy
bmFsIGVudGl0eSwgdGhlIFBBUiBVUkkgLSBpdHMgaW50ZXJwcmV0YXRpb24sIHZhbGlkYXRpb24g
YW5kIHBvdGVudGlhbGx5DQogcmVzb3VyY2UgcmV0cmlldmFsIChKV1Qgb3Igb3RoZXIgYmxvYiks
IGlzIGFuICZxdW90O2ludGVybmFsIGNvbnRyYWN0JnF1b3Q7IG9uIHRoZSBBUyBzaWRlLiBUaGlz
IGRvZXNuJ3QgY29uY2VybiB0aGUgY2xpZW50LCBhbmQgaW4gT0F1dGggMi4wIHRoZSByb2xlIG9m
IEFTIGlzIGluZGl2aXNpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzZWUgUEFS
IHJlcXVlc3QgJiM0MzsgYXV0aFogcmVxdWVzdCBhcyBvbmUgbG9naWNhbCBPQXV0aCAyLjAgYXV0
aFogcmVxdWVzdDogdGhlIGNsaWVudCBzdWJtaXRzIGFuIGF1dGhaIHJlcXVlc3QgYW5kIGdldHMg
YW4gYXV0aFogcmVzcG9uc2UgYXQgdGhlIGVuZC4gVGhlIFVSSSBpcyBuZWNlc3NhcnkgZm9yIHRo
ZQ0KIGNsaWVudCB0byBwcm9jZWVkIGZyb20gdGhlIDFzdCB0byB0aGUgMm5kIHN0ZXAuIElmIHdl
IG1hbmFnZSB0byBmcmFtZSAvIHdvcmQgdGhlIFBBUiBVUkkgaW4gdGhpcyBsb2dpY2FsIHdheSwg
d2l0aG91dCBnZXR0aW5nIHN0dWNrIGluIHRoZSBKQVIgZGVmaW5pdGlvbiAvIGZyYW1pbmcgb2Yg
d2hhdCB0aGUgcmVxdWVzdF91cmkgLyBvYmplY3QgaXMsIGl0IHdvdWxkIGJlIGdyZWF0LjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBJIHRoaW5rIHNo
b3VsZCBmb2N1cyBvbiBtYWludGFpbmluZyB0aGUgT0F1dGggMi4wIGNvbnRyYWN0IGZvciB0aGUg
ZW50aXJlIGxvZ2ljYWwgYXV0aFogcmVxdWVzdCwgdG9nZXRoZXIgd2l0aCB0aGUgYmFzaWMgY29u
dHJhY3RzIG9mIDEpIEpBUiBhbmQgdGhlIDIpIGF1dGhaDQogZW5kcG9pbnQuPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5WbGFkaW1pcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiAxMC8wMS8yMDIwIDIyOjU1LCBKdXN0aW4gUmljaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHdlIGNvdWxkIHNvbHZlIHRoaXMg
Ynkgc2F5aW5nIHRoZSByZXN1bHRpbmcgZGF0YSBvYmplY3Qgb2YgYSBQQVIgaXMgYSByZXF1ZXN0
IG9iamVjdC4gV2hpY2ggbWlnaHQgYWxzbyBjb250YWluIGEgcmVxdWVzdCBvYmplY3QgaW50ZXJu
YWxseSBhcyB3ZWxsLiBJbiB0aGF0IGNhc2UgSkFSIHNob3VsZCBiYWNrIG9mZiBmcm9tIHNheWlu
ZyBpdOKAmXMgYSBKV1QgYW5kIGluc3RlYWQgc2F5IGl04oCZcyBhIHJlcXVlc3QNCiBvYmplY3Qu
IE9yIHdlIGRlZmluZSBhIG5ldyB0ZXJtIGZvciB0aGlzIGF1dGhvcml6YXRpb24gcmVxdWVzdCBi
bG9iIHRoaW5nLiA8bzpwPg0KPC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T3IgUEFSIGNvdWxkIGF0IGxlYXN0IHNheSB0aGF0IGlmIGl04oCZcyBkZXJlZmVyZW5jZWQg
b3ZlciBhIHJlbW90ZSBwcm90b2NvbCB0aGVuIGl0IE1VU1QgYmUgYSBKV1QsIGJ1dCBvdGhlcndp
c2UgaXQgY2FuIGJlIHdoYXRldmVyIHlvdSB3YW50LiBUaGF04oCZcyB3aGVyZSB0aGUgcmVhbCBp
bnRlcm9wIGNvbmNlcm5zIGNvbWUgaW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAxMCwgMjAyMCwgYXQgMzo0MSBQTSwg
UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYT00
MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciPnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5p
ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Q29ycmVjdC4gVGhlIHByb2JsZW0gYmVjb21lcyBwcmV0dHkgY2xlYXIgaW4g
dGhlIGNvbnRleHQgb2YgUEFSLCB3aGVyZSB0aGUgQVMgaXMgZ2VuZXJhdGluZyBhbmQgdmVuZGlu
ZyBvdXQgdGhlIFVSSSBhdCB0aGUgUEFSIGVuZHBvaW50LCBhbmQgY29uc3VtaW5nIGl0IGF0IHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBGcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgc3RhbmRw
b2ludCwgaXTigJlzIGFuYWxvZ291cw0KIHRvIHRoZSBBUyB2ZW5kaW5nIGFuIGF1dGhvcml6YXRp
b24gY29kZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhbmQgY29uc3VtaW5nIGl0IGF0
IHRoZSB0b2tlbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCT
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJk
IEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkpv
aG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJA
dmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkZyaWRheSwgSmFudWFyeSAxMCwgMjAyMCBhdCAx
MjoyOSBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L2I+QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJl
bGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozxi
cj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L2I+VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9k
ZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7LCBOYXQgU2FraW11
cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpuYXRAc2FraW11cmEub3JnIj5uYXRAc2FraW11cmEub3Jn
PC9hPiZndDssICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBo
cmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4m
Z3Q7LA0KIG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll
dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRI
LVdHXSBQQVI6IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgYXNzdW1lIHRoZSBjbGllbnQgcG9zdHMg
YSBKQVIgYW5kIGdldHMgYmFjayBhIHJlZmVyZW5jZS4mbmJzcDsgVGhlbiB0aGUgcmVmZXJlbmNl
IGlzIHRvIGEgSkFSLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkg
c2VlIHRoZSBwcm9ibGVtLiZuYnNwOyBJZiB0aGUgc2VydmVyIHByb3ZpZGluZyB0aGUgcmVmZXJl
bmNlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQVMgdGhlbiB0aGUgc2VydmVyIGRvc2VuJ3QgbmVl
ZCB0byBkZXJlZmVyZW5jZSB0aGUgb2JqZWN0IHZpYSBIVFRQLCBzbyBpdCBjb3VsZCBiZSBhIFVS
TiBhcyBhbiBleGFtcGxlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB5ZXMg
aXQgaXMgbm90IGEgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSBmb3IgdGhlIGNsaWVudC4mbmJzcDsm
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aWxsIHRoaW5rIGFib3V0IGhvdyBJ
IGNhbiBmaW5lc3NlIHRoYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdy
ZWUgaXQgaXMgbm90IGEgY2hhbmdlIGluIGludGVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SSB3aWxsIHNlZSBpZiBJIGNhbiBnZXQgb3VyIEFEIHRvIGFjY2VwdCB0aGF0Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIEZyaSwgSmFuIDEwLCAyMDIwLCA0OjU3IFBNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBo
cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5TdXJlIGJ1dCB0aGUgdGV4dCBwcm9wb3NlZCAob3Igc29tZXRoaW5nIGxpa2UgaXQpIHF1
YWxpZmllcyBpdCBzdWNoIHRoYXQgdGhlcmUgYXJlbid0IGludGVyb3BlcmFiaWxpdHkgcXVlc3Rp
b25zIGJlY2F1c2UgaXQncyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCB0byB0aGUgQVMg
d2hvIGJvdGggcHJvZHVjZXMgdGhlIFVSSSBhbmQgY29uc3VtZXMgaXRzIGNvbnRlbnQuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAxMCwgMjAyMCBhdCAxMjo0OCBQTSBKb2huIEJyYWRs
ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnZlN2p0YkB2ZTdqdGIuY29tPC9zcGFuPjwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdi
KDIwNCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjA0LCAyMDQpIj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1heSBiZSBhIGNoYWxs
ZW5nZSB0byBjaGFuZ2UgdGV4dCBzYXlpbmcgdGhhdCB0aGUgY29udGVudHMgb2YgdGhlIHJlc291
cmNlIGNvdWxkIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIGEgcmVxdWVzdCBvYmplY3QuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIG5vdCBhIHJlcXVlc3Qgb2JqZWN0IHRoZW4g
d2hhdCBhbmQgaG93IGlzIHRoYXQgaW50ZXJvcGVyYWJsZSBhcmUgbGlrZWx5IEFEIHF1ZXN0aW9u
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBwZXJoYXBzIHNlZSBj
aGFuZ2luZyBpdCB0byBtdXN0IGJlIGEgcmVxdWVzdCBvYmplY3QsIG9yIG90aGVyIGZvcm1hdCBk
ZWZpbmVkIGJ5IGEgcHJvZmlsZS48YnI+DQo8YnI+DQpKb2huIEIuJm5ic3A7Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAxMCwgMjAy
MCwgMzo0NSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBw
aW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47
bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwNCwgMjA0KSI+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZSBhbmQgYWdyZWUuIEJ1dCBnaXZl
biB0aGF0IHRoZSBjaGFuZ2Ugc3VnZ2VzdGVkIGJ5IEFubmFiZWxsZSBoYXMgbm8gaW1wYWN0IG9u
IHRoZSBjbGllbnQgb3IgaW50ZXJvcGVyYWJpbGl0eSwgcGVyaGFwcyBOYXQgb3IgSm9obiBjb3Vs
ZCB3b3JrIHRoZSBjaGFuZ2UgaW50byB0aGUgZHJhZnQgZHVyaW5nIHRoZSBlZGl0cyB0aGF0IGhh
cHBlbiBkdXJpbmcgdGhlIGZpbmFsIHN0YWdlcyBvZiB0aGluZ3M/PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBUaHUsIEphbiA5LCAyMDIwIGF0IDE6NTYgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7
dG9yc3Rlbj08YSBocmVmPSJtYWlsdG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj40MGxvZGRlcnN0ZWR0
Lm5ldEBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291
bGQgYXNzdW1lIGdpdmVuIHRoZSBzdGF0dXMgb2YgSkFSLCB3ZSBkb27igJl0IHdhbnQgdG8gY2hh
bmdlIGl0LiBBbmQgYXMgSSBzYWlkLCB0aGlzIGRpZmZlcmVuY2UgZG9lcyBub3QgaW1wYWN0IGlu
dGVyb3BlcmFiaWxpdHkgZnJvbSBjbGllbnQgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFtIDA5LjAxLjIwMjAgdW0gMDA6NTggc2No
cmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFp
bHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+
Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0
byBhZGQgdGhlIHRleHQgdG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQgZG9lc24ndCBzZWVtIHJp
Z2h0IGZvciBQQVIgdG8gcmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5nIHRoZSB0ZXh0IHRvIEpB
UiBhbHNvIGhpZ2hsaWdodHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcNCiBQQVIgc3BlY2lhbCB0
cmVhdG1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj5XaGF0IGlmIHdlIGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBTZWN0aW9uIDUu
MiBvZiBKQVI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgY29udGVudHMgb2YgdGhlIHJl
c291cmNlIHJlZmVyZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVzdDwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+T2JqZWN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs
dmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIGNvbnRlbnRzIG9mIHRoZSByZXNv
dXJjZSByZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJlcXVlc3Q8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPk9iamVjdCwgdW5sZXNzIHRoZSBVUkkgd2FzIHByb3ZpZGVkIHRvIHRoZSBjbGllbnQg
YnkgdGhlIEF1dGhvcml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlcnZlci48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgd291bGQgYWxs
b3cgZm9yIHVzZSBjYXNlcyBzdWNoIGFzIGFuIEFTIHRoYXQgcHJvdmlkZXMgcHJlLWRlZmluZWQg
cmVxdWVzdCBVUklzLCBvciB2ZW5kcyByZXF1ZXN0IFVSSXMgdmlhIGEgY2xpZW50IG1hbmFnZW1l
bnQgY29uc29sZSwgb3IgYmFrZXMgdGhlbSBpbnRvIHRoZWlyIGNsaWVudCBhcHBzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+4oCTPHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5Bbm5hYmVsbGUgUmlj
aGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+T24gMS84LzIwLCAyOjUwIFBNLCAmcXVvdDtUb3JzdGVu
IExvZGRlcnN0ZWR0JnF1b3Q7ICZsdDt0b3JzdGVuPTxhIGhyZWY9Im1haWx0bzo0MGxvZGRlcnN0
ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPjQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7
DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgSGksPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7eW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90IHJlcXVpcmUgdGhlIEFTIHRv
IHJlcHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCByZXF1ZXN0IG9iamVjdC4gVGhl
IFVSSSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5LiBUaGF0IHdoeSB0aGUgZHJh
ZnQgc3RhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVv
dDtUaGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0YSBhdmFp
bGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO1RoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZyb20gYW4gQVMgaW1wbGVtZW50YXRpb24g
cGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZyb20gYSBjbGllbnQncyAoaW50ZXJvcCkg
cGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UgbWF5IGFkZCBhIHN0
YXRlbWVudCB0byBQQVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBieSB0aGUgUEFS
IG1lY2hhbmlzbSAoTUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmVzdCByZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJz
cDsmbmJzcDsgVG9yc3Rlbi4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmZ3Q7IE9uIDguIEphbiAyMDIwLCBhdCAyMzo0MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs
bGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj40MGFtYXpvbi5j
b21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgSGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw
OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGUgY3VycmVudCBkcmFmdHMgb2YgUEFSICgtMDApIGFuZCBK
QVIgKC0yMCkgcmVxdWlyZSB0aGF0IHRoZSBBUyB0cmFuc2Zvcm0gYWxsIHB1c2hlZCByZXF1ZXN0
cyBpbnRvIEpXVHMuIFRoaXMgcmVxdWlyZW1lbnQgYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZzo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IOKAoiBQQVIgdXNlcyB0aGUgcmVxdWVzdF91cmkgcGFyYW1ldGVyIGRlZmluZWQgaW4g
SkFSIHRvIGNvbW11bmljYXRlIHRoZSBwdXNoZWQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlv
biBlbmRwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBBY2NvcmRpbmcgdG8gSkFSLCB0aGUgcmVzb3VyY2UgcmVm
ZXJlbmNlZCBieSByZXF1ZXN0X3VyaSBNVVNUIGJlIGEgUmVxdWVzdCBPYmplY3QuIChTZWN0aW9u
IDUuMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IOKAoiBSZXF1ZXN0IE9iamVjdCBpcyBkZWZpbmVkIHRvIGJlIGEgSldUIGNv
bnRhaW5pbmcgYWxsIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgcGFyYW1ldGVycy4gKFNlY3Rp
b24gMi4xKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGVy
ZSBpcyBubyBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgaW50ZXJvcGVyYWJp
bGl0eSwgYXMgdGhpcyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlzIGFsc28gaW5jb25zaXN0
ZW50IHdpdGggdGhlIHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0ZW1wdGluZyB0byBkZWZp
bmUNCiB0aGUgaW50ZXJuYWwgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUgdHdvIEFTIGVuZHBv
aW50cy4gV29yc2UsIHRoaXMgcmVzdHJpY3Rpb24gbWFrZXMgaXQgaGFyZGVyIGZvciB0aGUgYXV0
aG9yaXphdGlvbiBlbmRwb2ludCB0byBsZXZlcmFnZSB2YWxpZGF0aW9uIGFuZCBvdGhlciB3b3Jr
IHBlcmZvcm1lZCBhdCB0aGUgUEFSIGVuZHBvaW50LCBhcyB0aGUgc3RhdGUgb3Igb3V0Y29tZSBv
ZiB0aGF0IHdvcmsgbXVzdCBiZSBmb3JjZWQgaW50byB0aGUNCiBKV1QgZm9ybWF0IChvciByZXRy
aWV2ZWQgdmlhIGEgc3Vic2VxdWVudCBzZXJ2aWNlIGNhbGwgb3IgZGF0YWJhc2UgbG9va3VwKS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsg4oCTPHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmZ3Q7IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNw
OyZuYnNwOyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Ym9yZGVyOm5vbmUgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl
bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y
IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1
c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycw0KIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp
biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh
bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg
Y29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n
OjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m
aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk
aXNjbG9zdXJlIGJ5IG90aGVycw0KIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2Fn
ZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3Uu
PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp
ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlZsYWRpbWlyIER6aHV2aW5vdjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1dmlub3Y8bzpw
PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_05BEC41F870941B7A6913B679618E854amazoncom_--


From nobody Wed Jan 15 20:13: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 26A3A120889 for ; Wed, 15 Jan 2020 20:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQscl35e_x12 for ; Wed, 15 Jan 2020 20:13:05 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53E712002F for ; Wed, 15 Jan 2020 20:13:04 -0800 (PST)
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 00G4CqAm011020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:12:54 -0500
Date: Wed, 15 Jan 2020 20:12:52 -0800
From: Benjamin Kaduk 
To: Mike Jones 
Cc: Vladimir Dzhuvinov , Takahiko Kawasaki , IETF oauth WG 
Message-ID: <20200116041252.GD80030@kduck.mit.edu>
References: <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> 
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] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 04:13:07 -0000

I'm only the irresponsible AD here, but I expect that you would be welcome
(nay, encouraged!) to write up a clear explanation of why the current
(post-IESG) formulation is bad, what a better formulation should be, and
why.  This would presumably also include some justification for how the
better formulation remains secure (which can be somewhat challenging when
combining data sources that have differing levels of provenance).  The
strongest voice that drove the change at IESG evaluation (Ben C) is no longer
on the IESG, though IIRC the arguments resonated pretty well with me.

-Ben

On Wed, Jan 15, 2020 at 09:27:38PM +0000, Mike Jones wrote:
> I’m increasingly thinking that we should push back on the IESG and go back to the semantics that the working group approved.  We can use the client_id example with an encrypted request object to motivate the (Connect-compatible) syntax and semantics.
> 
>                                                        -- Mike
> 
> From: Vladimir Dzhuvinov 
> Sent: Wednesday, January 15, 2020 1:03 PM
> To: Takahiko Kawasaki 
> Cc: John Bradley ; Mike Jones ; IETF oauth WG 
> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
> 
> 
> 
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to achieve "request parameters outside the request object should not be referred to" is like "putting the cart before the horse". Why do we have to avoid using the traditional client_id request parameter so stubbornly?
> 
> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
> A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.  In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id".  This protects the client from substitution of the authentication code.  (It provides no additional security for the protected resource.)
> 
> If the same reasoning applies, a client_id must always be sent with request / request_uri because client authentication is not performed at the authorization endpoint. In other words, an unauthenticated client (every client is unauthenticated at the authorization endpoint) MUST send its "client_id" to prevent itself from inadvertently accepting a request object for a client with a different "client_id".
> 
> 
> Identifying the client in JAR request_uri requests can be really useful so that an AS which requires request_uri registration to prevent DDoS attacks and other checks can do those without having to index all request_uris individually. I mentioned this before.
> 
> I really wonder what the reasoning of the IESG reviewers was to insist on no params outside the JAR JWT / request_uri.
> 
> I'm beginning to realise this step of the review process isn't particularly transparent to WG members.
> 
> Vladimir
> 
> 
> Best Regards,
> Taka
> 
> 
> 
> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov > wrote:
> 
> John, thanks, much appreciated!
> On 11/01/2020 21:36, John Bradley wrote:
> 
> Yes JAR is not prohibiting paramater replication in the header.
> 
> I will see if i can add something in final edits to call that out.
> 
> John B.
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> 
> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter replication be used for client_id or the client_id ass "iss" even though it isn't explicitly mentioned in the JAR spec?
> On 11/01/2020 02:58, John Bradley wrote:
> Right we just don't say to put the iss there in OIDC if it's symetricly encrypted.
> 
> OIDC doesn't have the symmetric key selection issue, I suppose that why the possibility to replicate params to the JWE header isn't mentioned at all. OIDC requires the top-level query params to represent a valid OAuth 2.0 request, and there client_id is required. If the client_id is present the client registration together with any present client_secret can be retrieved.
> 
> I reread the JAR spec, this is the only place that mentions handling of symmetric JWE.
> 
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> 
>    (b)  Verifying that the symmetric key for the JWE encryption is the
> 
>         correct one if the JWE is using symmetric encryption.
> 
> 
> 
> Vladimir
> 
> 
> 
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones > wrote:
> The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)
> 
>                                                        -- Mike
> 
> From: OAuth > On Behalf Of John Bradley
> Sent: Friday, January 10, 2020 2:15 PM
> To: Vladimir Dzhuvinov >
> Cc: IETF oauth WG >
> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
> 
> The intent was to do that, but specs change once the OAuth WG and IESG get there hands on them.
> 
> Being backwards compatible with OIDC is not a compelling argument to the IESG.
> 
> We were mostly thinking of asymmetric encryption.
> 
> Specifying puting the issuer and or the audience in the headder has come up in the past but probably is not documented.
> 
> John B
> 
> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov > wrote:
> Yes, putting the client_id into the JWE header is a way around the need
> to have the client_id outside the JWE as top-level authZ request parameter.
> 
> Unfortunately this work around isn't mentioned anywhere, I just checked
> the most recent draft-ietf-oauth-jwsreq-20.
> 
> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
> presence of client_id as top-level parameter, together with requiring
> RPs to register their request_uri's (so that we don't need to build and
> store an index of all request_uri's). I just had a look at "DDoS Attack
> on the Authorization Server" and also realised the request_uri
> registration isn't explicitly mentioned as attack prevention ("the
> server should (a) check that the value of "request_uri" parameter does
> not point to an unexpected location").
> 
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> 
> To be honest, I feel quite bad about the situation with JAR we are in
> now. For some reason I had the impression that OAuth JAR was going to be
> the OIDC request / request_uri for general OAuth 2.0 use, as with other
> OIDC bits that later became general purpose OAuth 2.0 specs.
> 
> I find it unfortunate I didn't notice this when I was reviewing the spec
> in the past.
> 
> Vladimir
> 
> 
> On 10/01/2020 22:39, Filip Skokan wrote:
> > Vladimir,
> >
> > For that very case the payload claims may be repeated in the JWE protected header. An implementation wanting to handle this may look for iss/client_id there.
> >
> > Odesláno z iPhonu
> >
> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov >:
> >>
> >> I just realised there is one class of JARs where it's practially
> >> impossible to process the request if merge isn't supported:
> >>
> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
> >> for that and specs a method for deriving the shared key from the
> >> client_secret:
> >>
> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> >>
> >> If the JAR is encrypted with the client_secret, and there is no
> >> top-level client_id parameter, there's no good way for the OP to find
> >> out which client_secret to get to try to decrypt the JWE. Unless the OP
> >> keeps an index of all issued client_secret's.
> >>
> >>
> >> OP servers which require request_uri registration
> >> (require_request_uri_registration=true) and don't want to index all
> >> registered request_uri's, also have no good way to process a request_uri
> >> if the client_id isn't present as top-level parameter.
> >>
> >>
> >> Vladimir
> >>
> >>
> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> >>>
> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley >:
> >>>> I think Torsten is speculating that is not a feature people use.
> >>> I’m still trying to understand the use case for merging signed and unsigned parameters. Nat once explained a use case, where a client uses parameters signed by a 3rd party (some „certification authority“) in combination with transaction-specific parameters. Is this being done in the wild?
> >>>
> >>> PS: PAR would work with both modes.
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> --
> 
> Vladimir Dzhuvinov

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


From nobody Wed Jan 15 20:20: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 66936120855 for ; Wed, 15 Jan 2020 20:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8023aE9iuTWn for ; Wed, 15 Jan 2020 20:20:40 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E226D12002F for ; Wed, 15 Jan 2020 20:20:39 -0800 (PST)
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 00G4KYFX012590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:20:37 -0500
Date: Wed, 15 Jan 2020 20:20:34 -0800
From: Benjamin Kaduk 
To: Mike Jones 
Cc: IETF oauth WG 
Message-ID: <20200116042034.GE80030@kduck.mit.edu>
References:    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>  <20200116041252.GD80030@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200116041252.GD80030@kduck.mit.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 04:20:41 -0000

On Wed, Jan 15, 2020 at 08:12:52PM -0800, Benjamin Kaduk wrote:
> I'm only the irresponsible AD here, but I expect that you would be welcome
> (nay, encouraged!) to write up a clear explanation of why the current
> (post-IESG) formulation is bad, what a better formulation should be, and
> why.  This would presumably also include some justification for how the
> better formulation remains secure (which can be somewhat challenging when
> combining data sources that have differing levels of provenance).  The
> strongest voice that drove the change at IESG evaluation (Ben C) is no longer
> on the IESG, though IIRC the arguments resonated pretty well with me.

[looks like I'm misremembering the bit about Ben C, at least as far as
shows up at
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/history/]


From nobody Wed Jan 15 20:53: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 2C119120A70 for ; Wed, 15 Jan 2020 20:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 brMDV0NzgyyA for ; Wed, 15 Jan 2020 20:53:12 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AC7120A3F for ; Wed, 15 Jan 2020 20:53:12 -0800 (PST)
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 00G4r3mr019346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:53:05 -0500
Date: Wed, 15 Jan 2020 20:53:02 -0800
From: Benjamin Kaduk 
To: Vladimir Dzhuvinov 
Cc: Takahiko Kawasaki , IETF oauth WG 
Message-ID: <20200116045302.GG80030@kduck.mit.edu>
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 04:53:17 -0000

On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> 
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > Well, embedding a client_id claim in the JWE header in order to
> > achieve "request parameters outside the request object should not be
> > referred to" is like "putting the cart before the horse". Why do we
> > have to avoid using the traditional client_id request parameter so
> > stubbornly?
> >
> > The last paragraph of Section 3.2.1
> >  of RFC 6749 says
> > as follows.
> >
> >     /A client MAY use the "client_id" request parameter to identify
> >     itself when sending requests to the token endpoint. In the
> >     "authorization_code" "grant_type" request to the token endpoint,
> >     *an unauthenticated client MUST send its "client_id" to prevent
> >     itself from inadvertently accepting a code intended for a client
> >     with a different "client_id".* This protects the client from
> >     substitution of the authentication code. (It provides no
> >     additional security for the protected resource.)/
> >
> >
> > If the same reasoning applies, a client_id must always be sent with
> > request / request_uri because client authentication is not performed
> > at the authorization endpoint. In other words, */an unauthenticated
> > client (every client is unauthenticated at the authorization endpoint)
> > MUST send its "client_id" to prevent itself from inadvertently
> > accepting a request object for a client with a different "client_id"./*
> >
> Identifying the client in JAR request_uri requests can be really useful
> so that an AS which requires request_uri registration to prevent DDoS
> attacks and other checks can do those without having to index all
> request_uris individually. I mentioned this before.
> 
> I really wonder what the reasoning of the IESG reviewers was to insist
> on no params outside the JAR JWT / request_uri.
> 
> I'm beginning to realise this step of the review process isn't
> particularly transparent to WG members.

Could you expand on that a bit more?  My understanding is that the IESG
ballot mail gets copied to the WG precisely so that there is transparency,
e.g., the thread starting at
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
Which admittely is from almost three years ago, but that's the earliest
that I found that could be seen as the source of this behavior.

-Ben

P.S. some other discussion at
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
so on.


From nobody Wed Jan 15 23:07: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 E96A1120967 for ; Wed, 15 Jan 2020 23:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 ubNI_FuDcl8H for ; Wed, 15 Jan 2020 23:07:33 -0800 (PST)
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 D294F1208B4 for ; Wed, 15 Jan 2020 23:07:32 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id f129so2567255wmf.2 for ; Wed, 15 Jan 2020 23:07:32 -0800 (PST)
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=3OC/sKM11oiaRL8Ge9GsDSBu9g0lLaOjl4Mw8KNmbDA=; b=EAzoMaFVNpea+4qXKRaw0lVuR/R/G89sCzyqKAmJff5urAFUmaJAuwE2LhcBvGMcHy DMwDPFu6dlxd89uaJqp3GbaZ6KzXbUXEYNK270r0LcOAjTcXoR4m5vv0kEmf8wQ2NOM/ OY4F/h+rdSqvv/uYV+BoSrKlE0y0KTv9LToMo=
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=3OC/sKM11oiaRL8Ge9GsDSBu9g0lLaOjl4Mw8KNmbDA=; b=DQRlIc4Nl5BlM3YHMrluWajHAMYFwiJRjCEgsqBES74cgnbEVeo4PkRMtnO+VCpHSR zjf8m2I0sHdKlENYfP+RVT4acFEHuUJqeGH9vhmrb+T4hyjwNWi7MnH2yeEJTZBGCpod RUPeEn4itf6yWSmyCbNndc+6l2mXEFRfXB/BzH9KILKINC4eTbncLJOvX48BMheTYPBF ZM5M3v+AYnnDT/fJ6FAfr5Rmhp0zISWxMYHnKWIO/Ct47TAExWIqypERCJ4MX+RwHbGJ 1/Cb/wZ2Hm+ZzlsadZYhPCBKlZr7gwN6oBIyA8AldUOCxd7jDBf5mMFnbWwxAUjsfHiY hGvw==
X-Gm-Message-State: APjAAAXqUnsZvymrv6AZ/bn6rLtGHQMFRLn7jUBjOCogaqLpcsNGpBtb 3T4tgkyFeLST5Sgkef2Wr3v5P1EAAQ3YepGbTKN2+WvHpg//EhgEBW369ZisVzwkzjmTcBYEQAg wOk5VM7Oo8fEGrvpf5rRSO0y6HzbJVKtYf75ZqScRXkdfyketebcPkjY5eCYkfOY=
X-Google-Smtp-Source: APXvYqy5XdXn0Gyx9Q2005R1BkiJ+1c3Ejp5dVlNdpJBt63CC4dWbI0mrkQsi6vc2NtDl1VyAL6TZw==
X-Received: by 2002:a1c:2355:: with SMTP id j82mr4482918wmj.135.1579158450033;  Wed, 15 Jan 2020 23:07:30 -0800 (PST)
Received: from ?IPv6:2a01:4c8:1f:702a:84d9:1731:5d13:c644? ([2a01:4c8:1f:702a:84d9:1731:5d13:c644]) by smtp.gmail.com with ESMTPSA id b67sm2306802wmc.38.2020.01.15.23.07.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2020 23:07:29 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-44A1A9F4-227D-403F-864D-577E9628F5EF
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jan 2020 07:07:28 +0000
Message-Id: <2DED6D1F-8611-4104-9B1C-65AC4445D663@forgerock.com>
References: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
Cc: Takahiko Kawasaki , IETF oauth WG 
In-Reply-To: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 07:07:38 -0000

--Apple-Mail-44A1A9F4-227D-403F-864D-577E9628F5EF
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

If the AS can=E2=80=99t validate the request_uri it may also open itself up t=
o SSRF attacks where a malicious client uses the request_uri to probe/attack=
 resources inside the AS=E2=80=99s private network. This was a crucial part o=
f the recent Capital One breach for example [1].  ForgeRock currently requir=
es strict validation of request_uris against a client-specific whitelist for=
 exactly this reason.=20

NB some clients might legitimately be on that private network (eg microservi=
ces) so changing to a global whitelist for all clients is undesirable.=20

[1]: https://ejj.io/blog/capital-one

=E2=80=94 Neil

> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov  wro=
te:
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>> Well, embedding a client_id claim in the JWE header in order to achieve "=
request parameters outside the request object should not be referred to" is l=
ike "putting the cart before the horse". Why do we have to avoid using the t=
raditional client_id request parameter so stubbornly?
>>=20
>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
>>=20
>> A client MAY use the "client_id" request parameter to identify itself whe=
n sending requests to the token endpoint.  In the "authorization_code" "gran=
t_type" request to the token endpoint, an unauthenticated client MUST send i=
ts "client_id" to prevent itself from inadvertently accepting a code intende=
d for a client with a different "client_id".  This protects the client from s=
ubstitution of the authentication code.  (It provides no additional security=
 for the protected resource.)
>>=20
>> If the same reasoning applies, a client_id must always be sent with reque=
st / request_uri because client authentication is not performed at the autho=
rization endpoint. In other words, an unauthenticated client (every client i=
s unauthenticated at the authorization endpoint) MUST send its "client_id" t=
o prevent itself from inadvertently accepting a request object for a client w=
ith a different "client_id".
>>=20
> Identifying the client in JAR request_uri requests can be really useful so=
 that an AS which requires request_uri registration to prevent DDoS attacks a=
nd other checks can do those without having to index all request_uris indivi=
dually. I mentioned this before.
>=20
> I really wonder what the reasoning of the IESG reviewers was to insist on n=
o params outside the JAR JWT / request_uri.
>=20
> I'm beginning to realise this step of the review process isn't particularl=
y transparent to WG members.
>=20
> Vladimir
>=20
>=20
>=20
>> Best Regards,
>> Taka
>>=20
>>=20
>>=20
>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov  wrote:
>>> John, thanks, much appreciated!
>>>=20
>>> On 11/01/2020 21:36, John Bradley wrote:
>>>> Yes JAR is not prohibiting paramater replication in the header. =20
>>>>=20
>>>> I will see if i can add something in final edits to call that out.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter re=
plication be used for client_id or the client_id ass "iss" even though it is=
n't explicitly mentioned in the JAR spec?
>>>>>=20
>>>>> On 11/01/2020 02:58, John Bradley wrote:
>>>>>> Right we just don't say to put the iss there in OIDC if it's symetric=
ly encrypted.=20
>>>>> OIDC doesn't have the symmetric key selection issue, I suppose that wh=
y the possibility to replicate params to the JWE header isn't mentioned at a=
ll. OIDC requires the top-level query params to represent a valid OAuth 2.0 r=
equest, and there client_id is required. If the client_id is present the cli=
ent registration together with any present client_secret can be retrieved.=20=

>>>>>=20
>>>>> I reread the JAR spec, this is the only place that mentions handling o=
f symmetric JWE.
>>>>>=20
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>>>>=20
>>>>>>    (b)  Verifying that the symmetric key for the JWE encryption is th=
e
>>>>>>         correct one if the JWE is using symmetric encryption.
>>>>>=20
>>>>> Vladimir
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  wrote:
>>>>>>> The technique of replicating JWT claims that need to be publicly vis=
ible in an encrypted JWT in the header is defined at https://tools.ietf.org/=
html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to m=
y attention as we were finishing the JWT spec.)
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>>                                                        -- Mike
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> From: OAuth  On Behalf Of John Bradley
>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
>>>>>>> To: Vladimir Dzhuvinov 
>>>>>>> Cc: IETF oauth WG 
>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request=
 (JAR) vs OIDC request object
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> The intent was to do that, but specs change once the OAuth WG and IE=
SG get there hands on them. =20
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> Being backwards compatible with OIDC is not a compelling argument to=
 the IESG.
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> We were mostly thinking of asymmetric encryption. =20
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> Specifying puting the issuer and or the audience in the headder has c=
ome up in the past but probably is not documented. =20
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> John B=20
>>>>>>>=20
>>>>>>> =20
>>>>>>>=20
>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov  wrote:
>>>>>>>=20
>>>>>>> Yes, putting the client_id into the JWE header is a way around the n=
eed
>>>>>>> to have the client_id outside the JWE as top-level authZ request par=
ameter.
>>>>>>>=20
>>>>>>> Unfortunately this work around isn't mentioned anywhere, I just chec=
ked
>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
>>>>>>>=20
>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies on the=

>>>>>>> presence of client_id as top-level parameter, together with requirin=
g
>>>>>>> RPs to register their request_uri's (so that we don't need to build a=
nd
>>>>>>> store an index of all request_uri's). I just had a look at "DDoS Att=
ack
>>>>>>> on the Authorization Server" and also realised the request_uri
>>>>>>> registration isn't explicitly mentioned as attack prevention ("the
>>>>>>> server should (a) check that the value of "request_uri" parameter do=
es
>>>>>>> not point to an unexpected location").
>>>>>>>=20
>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.=
1
>>>>>>>=20
>>>>>>> To be honest, I feel quite bad about the situation with JAR we are i=
n
>>>>>>> now. For some reason I had the impression that OAuth JAR was going t=
o be
>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as with ot=
her
>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
>>>>>>>=20
>>>>>>> I find it unfortunate I didn't notice this when I was reviewing the s=
pec
>>>>>>> in the past.
>>>>>>>=20
>>>>>>> Vladimir
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
>>>>>>> > Vladimir,=20
>>>>>>> >
>>>>>>> > For that very case the payload claims may be repeated in the JWE p=
rotected header. An implementation wanting to handle this may look for iss/c=
lient_id there.=20
>>>>>>> >
>>>>>>> > Odesl=C3=A1no z iPhonu
>>>>>>> >
>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov =
:
>>>>>>> >>
>>>>>>> >> =EF=BB=BFI just realised there is one class of JARs where it's pr=
actially
>>>>>>> >> impossible to process the request if merge isn't supported:
>>>>>>> >>
>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC a=
llows
>>>>>>> >> for that and specs a method for deriving the shared key from the
>>>>>>> >> client_secret:
>>>>>>> >>
>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>>>>>>> >>
>>>>>>> >> If the JAR is encrypted with the client_secret, and there is no
>>>>>>> >> top-level client_id parameter, there's no good way for the OP to f=
ind
>>>>>>> >> out which client_secret to get to try to decrypt the JWE. Unless t=
he OP
>>>>>>> >> keeps an index of all issued client_secret's.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> OP servers which require request_uri registration
>>>>>>> >> (require_request_uri_registration=3Dtrue) and don't want to index=
 all
>>>>>>> >> registered request_uri's, also have no good way to process a requ=
est_uri
>>>>>>> >> if the client_id isn't present as top-level parameter.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Vladimir
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>>>>> >>>
>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>>>>>> >>>> I think Torsten is speculating that is not a feature people use=
.  =20
>>>>>>> >>> I=E2=80=99m still trying to understand the use case for merging s=
igned and unsigned parameters. Nat once explained a use case, where a client=
 uses parameters signed by a 3rd party (some =E2=80=9Ecertification authorit=
y=E2=80=9C) in combination with transaction-specific parameters. Is this bei=
ng done in the wild?=20
>>>>>>> >>>
>>>>>>> >>> PS: PAR would work with both modes.
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://
>>>>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> --=20
> Vladimir Dzhuvinov
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-44A1A9F4-227D-403F-864D-577E9628F5EF
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


If the AS can=E2=80=99t va=
lidate the request_uri it may also open itself up to SSRF attacks where a ma=
licious client uses the request_uri to probe/attack resources inside the AS=E2=
=80=99s private network. This was a crucial part of the recent Capital One b=
reach for example [1].  ForgeRock currently requires strict validation o=
f request_uris against a client-specific whitelist for exactly this reason.&=
nbsp;

NB some clients might=
 legitimately be on that private network (eg microservices) so changing to a=
 global whitelist for all clients is undesirable. 


<=
div dir=3D"ltr">=E2=80=94 Neil

On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <vladimir@connect2id.=
com> wrote:

    
On 14/01/2020 19:20, Takahiko Kawasaki
      wrote:

    

    

      
      
Well, embedding a client_id<=
/font>
        claim in the JWE header in order to achieve "request parameters
        outside the request object should not be referred to" is like
        "putting the cart before the horse". Why do we have to avoid
        using the traditional client_id
        request parameter so stubbornly?
        


        

        
The last paragraph of Section 3.2.1 of RFC 6749 s=
ays as
          follows.

          

        

        

          
A client MAY use the "client_id" request parameter to
              identify itself when sending requests to the token
              endpoint.  In the "authorization_code" "grant_type"
              request to the token endpoint, an unauthenticated
                client MUST send its "client_id" to prevent itself from
                inadvertently accepting a code intended for a client
                with a different "client_id".  This protects the
              client from substitution of the authentication code.  (It=

              provides no additional security for the protected
              resource.)

        

        

          


          

          
If the same reasoning applies, a cli=
ent_id
            must always be sent with request=

            / request_uri because client
            authentication is not performed at the authorization
            endpoint. In other words, an unauthenticated client
                (every client is unauthenticated at the authorization
                endpoint) MUST send its "client_id" to prevent itself
                from inadvertently accepting a request object for a
                client with a different "client_id".

          


          

        

      

    

    
Identifying the client in JAR request_uri requests can be really
      useful so that an AS which requires request_uri registration to
      prevent DDoS attacks and other checks can do those without having
      to index all request_uris individually. I mentioned this before.

    
I really wonder what the reasoning of the IESG reviewers was to
      insist on no params outside the JAR JWT / request_uri.

    
I'm beginning to realise this step of the review process isn't
      particularly transparent to WG members.

    
Vladimir

    

    


    

    

      

        
Best Regards,

        
Taka

        


        

        


        

      

      

      

        
On Tue, Jan 14, 2020 at 12:57
          AM Vladimir Dzhuvinov <vladimir@connect2id.com>
          wrote:

        

        

          

            
John, thanks, much appreciated!

            

            
On 11/01/2020 21:36, John Bradley wrote:

            

            

              
Yes JAR is not prohibiting paramater replication in the
                header.  

              

              
I will see if i can add something in final edits to
                call that out.

              
John B.

              

              
On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:

              

              

                
Thanks Mike for the rfc7519
                      section-5.3 pointer. Can this parameter
                    replication be used for client_id or the client_id
                    ass "iss" even though it isn't explicitly mentioned
                    in the JAR spec?

                  

                
On 11/01/2020 02:58, John Bradley wrote:

                

                

                  
Right we just don't say to put the iss
                    there in OIDC if it's symetricly encrypted. 

                  

                

                
OIDC doesn't have the symmetric key selection issue,
                  I suppose that why the possibility to replicate params
                  to the JWE header isn't mentioned at all. OIDC
                  requires the top-level query params to represent a
                  valid OAuth 2.0 request, and there client_id is
                  required. If the client_id is present the client
                  registration together with any present client_secret
                  can be retrieved. 

                

                
I reread the JAR spec, this is the only place that
                  mentions handling of symmetric JWE.

                

                
https://to=
ols.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

                

                
 

                

                  
   (b)  Verifying that the symmetric key for the JWE e=
ncryption is the
        correct one if the JWE is using symmetric encryption.

                

                


                

                
Vladimir

                


                

                


                  

                    
On Fri, Jan 10,
                      2020, 9:41 PM Mike Jones <Michael.Jon=
es@microsoft.com>
                      wrote:

                    

                    

                      

                        

                          
The technique
                              of replicating JWT claims that need to be
                              publicly visible in an encrypted JWT in
                              the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.=
 
                              (Thanks to Dick Hardt for bringing this
                              need to my attention as we were finishing
                              the JWT spec.)

                          
 

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

                          
 

                          
From: OAuth <oauth-bounces@ietf.org>
                            On Behalf Of  John Bradley

                            Sent: Friday, January 10, 2020 2:15
                            PM

                            To: Vladimir Dzhuvinov <vladimir@connect2id.com>

                            Cc: IETF oauth WG <oauth@ietf.org>

                            Subject: [EXTERNAL] Re: [OAUTH-WG]
                            JWT Secured Authorization Request (JAR) vs
                            OIDC request object

                          
 

                          

                            

                              
The intent was to do
                                that, but specs change once the OAuth WG
                                and IESG get there hands on them.  =
;

                              

                                
 

                              

                              

                                
Being backwards
                                  compatible with OIDC is not a
                                  compelling argument to the IESG.

                              

                              

                                
 

                              

                              

                                
We were mostly
                                  thinking of asymmetric encryption. &n=
bsp;

                              

                              

                                
 

                              

                              

                                
Specifying puting
                                  the issuer and or the audience in the
                                  headder has come up in the past but
                                  probably is not documented.  
                              

                              

                                
 

                              

                              

                                
John B 

                              

                              
 

                              

                                

                                  
On Fri, Jan 10,
                                    2020, 6:29 PM Vladimir Dzhuvinov
                                    <vladimi=
r@connect2id.com>
                                    wrote:

                                

                                

                                  
Yes, putting the
                                    client_id into the JWE header is a
                                    way around the need

                                    to have the client_id outside the
                                    JWE as top-level authZ request
                                    parameter.

                                    

                                    Unfortunately this work around isn't
                                    mentioned anywhere, I just checked

                                    the most recent
                                    draft-ietf-oauth-jwsreq-20.

                                    

                                    Our DDoS attack mitigation (for OIDC
                                    request_uri) also relies on the

                                    presence of client_id as top-level
                                    parameter, together with requiring

                                    RPs to register their request_uri's
                                    (so that we don't need to build and

                                    store an index of all
                                    request_uri's). I just had a look at
                                    "DDoS Attack

                                    on the Authorization Server" and
                                    also realised the request_uri

                                    registration isn't explicitly
                                    mentioned as attack prevention ("the
=

                                    server should (a) check that the
                                    value of "request_uri" parameter
                                    does

                                    not point to an unexpected
                                    location").

                                    

                                    https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#sec=
tion-10.4.1

                                    

                                    To be honest, I feel quite bad about
                                    the situation with JAR we are in

                                    now. For some reason I had the
                                    impression that OAuth JAR was going
                                    to be

                                    the OIDC request / request_uri for
                                    general OAuth 2.0 use, as with other
=

                                    OIDC bits that later became general
                                    purpose OAuth 2.0 specs.

                                    

                                    I find it unfortunate I didn't
                                    notice this when I was reviewing the
                                    spec

                                    in the past.

                                    

                                    Vladimir

                                    

                                    

                                    On 10/01/2020 22:39, Filip Skokan
                                    wrote:

                                    > Vladimir, 

                                    >

                                    > For that very case the payload
                                    claims may be repeated in the JWE
                                    protected header. An implementation
                                    wanting to handle this may look for
                                    iss/client_id there. 

                                    >

                                    > Odesl=C3=A1no z iPhonu

                                    >

                                    >> 10. 1. 2020 v 21:19,
                                    Vladimir Dzhuvinov <vladimir@connect2id.com>:

                                    >>

                                    >> =EF=BB=BFI just realised there i=
s
                                    one class of JARs where it's
                                    practially

                                    >> impossible to process the
                                    request if merge isn't supported:

                                    >>

                                    >> The client submits a JAR
                                    encrypted (JWT) with a shared key.
                                    OIDC allows

                                    >> for that and specs a method
                                    for deriving the shared key from the
=

                                    >> client_secret:

                                    >>

                                    >> 
https://openid.net/specs/openid-connect-core-1_0.html#Encryption

                                    >>

                                    >> If the JAR is encrypted
                                    with the client_secret, and there is
                                    no

                                    >> top-level client_id
                                    parameter, there's no good way for
                                    the OP to find

                                    >> out which client_secret to
                                    get to try to decrypt the JWE.
                                    Unless the OP

                                    >> keeps an index of all
                                    issued client_secret's.

                                    >>

                                    >>

                                    >> OP servers which require
                                    request_uri registration

                                    >>
                                    (require_request_uri_registration=3Dtrue=
)
                                    and don't want to index all

                                    >> registered request_uri's,
                                    also have no good way to process a
                                    request_uri

                                    >> if the client_id isn't
                                    present as top-level parameter.

                                    >>

                                    >>

                                    >> Vladimir

                                    >>

                                    >>

                                    >>> On 10/01/2020 20:13,
                                    Torsten Lodderstedt wrote:

                                    >>>

                                    >>>>> Am 10.01.2020
                                    um 16:53 schrieb John Bradley <ve7jtb@ve7jtb.com>:

                                    >>>> I think Torsten is
                                    speculating that is not a feature
                                    people use.   

                                    >>> I=E2=80=99m still trying to=

                                    understand the use case for merging
                                    signed and unsigned parameters. Nat
                                    once explained a use case, where a
                                    client uses parameters signed by a
                                    3rd party (some =E2=80=9Ecertification
                                    authority=E2=80=9C) in combination with
                                    transaction-specific parameters. Is
                                    this being done in the wild? 

                                    >>>

                                    >>> PS: PAR would work with
                                    both modes.

                                    

                                    

_______________________________________________

                                    OAuth mailing list

                                    OAuth@ietf.org
                                    ht=
tps://

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mai=
lman/listinfo/oauth

        

      

    

    
--=20
Vladimir Dzhuvinov

 =20

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

--Apple-Mail-44A1A9F4-227D-403F-864D-577E9628F5EF--


From nobody Thu Jan 16 00:15: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 6F3DC120020 for ; Thu, 16 Jan 2020 00:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level: 
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 AK4U-mGreZ8t for ; Thu, 16 Jan 2020 00:15:31 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68185120A15 for ; Thu, 16 Jan 2020 00:15:31 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id d71so18371876qkc.0 for ; Thu, 16 Jan 2020 00:15:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=z+CjJWn/xScdLg0rJ0g3sH3mf0Zc94GxGFjZIQyxDMM=; b=eKxMskCyWhfDIlImZnP0KRC1kY24hI5eHpag3Sukv/n7/FhQTe7PWLEEJCeZuA0Qt5 6XHSQyCS6okmD6hY5u9epCieZaOmFBl4JdJmoBv4xwMMb5yDADAEqVsIm/HxvEPVsD8Q C9Bb+lMbPkw7HvyiUv9TNhq7tGylAsArx//N4uUjbH2+v1/9QWWG5sO7gG9EVG+961UZ WL0VQqO9Sb//j/ySWU3RYn0XQwkKaQKdeB6X4Q9ujG6dcg1eaHzkLTENOM7W6lTjIDJO hmgaFJJK9sLVELhjrO/xRvOnuO//8ibRedhZUtsfCYHIknq4obnY5rIYwuJzyZJKNebO zcQQ==
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=z+CjJWn/xScdLg0rJ0g3sH3mf0Zc94GxGFjZIQyxDMM=; b=V/IgUmS3L1uEu/Vpu4Qk26R/C+9J34apZgUfiTF5UtgGuoIcINKqr9+L5P8m383WtF W/dbj5XREkovaXTUYo1hygylXygOi5W0/YLD4G+G/fVs8ipJgNsoYTyR0XYjWQIpP2dV tADy3zr/965cWxoRPdMloxN6HmT3TKPLlM2nsDZwcKynStiuI+tVtUV+i+ndn8Pvk6/b Fu53Sa+kByBq4Ay3STUU0uMWObUTdokvDsaqPQIUmO6JuYmrb8+NW6yFdX0HdCzmsA94 +vgoCDXiME1s79MBXk3dgJpgEd4+iwkLbgpt2qx4sQlOXdQ8RxrLci7vqYYPRYj4IEGn XaMg==
X-Gm-Message-State: APjAAAVQfOdg3yShDYBDXzQWeX563JEvL3twTPKDE3QSwUcdJ3xdXk3t 2K0avaT0v4i1QZl9kKuaHmSCltV7iopubUPHqBIK
X-Google-Smtp-Source: APXvYqzh2W9Gu3q5ZZJL1Ak/Bg/D4cRZuAj+JaZVKr5JYNvTvLBjWnfi+GLfjychvojpKy08Pm1un+ZezL1vZZfjMHI=
X-Received: by 2002:a05:620a:48e:: with SMTP id 14mr26734121qkr.292.1579162530361;  Thu, 16 Jan 2020 00:15:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Jan 2020 09:15:29 +0100
From: Dominick Baier 
In-Reply-To: <2DED6D1F-8611-4104-9B1C-65AC4445D663@forgerock.com>
References: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <2DED6D1F-8611-4104-9B1C-65AC4445D663@forgerock.com>
MIME-Version: 1.0
Date: Thu, 16 Jan 2020 09:15:29 +0100
Message-ID: 
To: Vladimir Dzhuvinov , Neil Madden 
Cc: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000aa4525059c3d6dca"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 08:15:35 -0000

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

Agreed - that=E2=80=99s why we disabled request_uri by default and added
extensibility points to implement validation.

I thought it is odd that this was not mentioned in the typical =E2=80=9Csec=
urity
considerations=E2=80=9D in the OIDC spec..

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

On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com)
wrote:

If the AS can=E2=80=99t validate the request_uri it may also open itself up=
 to SSRF
attacks where a malicious client uses the request_uri to probe/attack
resources inside the AS=E2=80=99s private network. This was a crucial part =
of the
recent Capital One breach for example [1].  ForgeRock currently requires
strict validation of request_uris against a client-specific whitelist for
exactly this reason.

NB some clients might legitimately be on that private network (eg
microservices) so changing to a global whitelist for all clients is
undesirable.

[1]: https://ejj.io/blog/capital-one

=E2=80=94 Neil

On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov 
wrote:

On 14/01/2020 19:20, Takahiko Kawasaki wrote:

Well, embedding a client_id claim in the JWE header in order to achieve
"request parameters outside the request object should not be referred to"
is like "putting the cart before the horse". Why do we have to avoid using
the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1
 of RFC 6749 says as
follows.

*A client MAY use the "client_id" request parameter to identify itself when
sending requests to the token endpoint.  In the "authorization_code"
"grant_type" request to the token endpoint, an unauthenticated client MUST
send its "client_id" to prevent itself from inadvertently accepting a code
intended for a client with a different "client_id".  This protects the
client from substitution of the authentication code.  (It provides no
additional security for the protected resource.)*


If the same reasoning applies, a client_id must always be sent with request
/ request_uri because client authentication is not performed at the
authorization endpoint. In other words, *an unauthenticated client (every
client is unauthenticated at the authorization endpoint) MUST send its
"client_id" to prevent itself from inadvertently accepting a request object
for a client with a different "client_id".*

Identifying the client in JAR request_uri requests can be really useful so
that an AS which requires request_uri registration to prevent DDoS attacks
and other checks can do those without having to index all request_uris
individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist on
no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't particularly
transparent to WG members.

Vladimir


Best Regards,
Taka



On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
wrote:

> John, thanks, much appreciated!
> On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header.
>
> I will see if i can add something in final edits to call that out.
>
> John B.
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>
> Thanks Mike for the rfc7519 section-5.3
>  pointer. Can this
> parameter replication be used for client_id or the client_id ass "iss" ev=
en
> though it isn't explicitly mentioned in the JAR spec?
> On 11/01/2020 02:58, John Bradley wrote:
>
> Right we just don't say to put the iss there in OIDC if it's symetricly
> encrypted.
>
> OIDC doesn't have the symmetric key selection issue, I suppose that why
> the possibility to replicate params to the JWE header isn't mentioned at
> all. OIDC requires the top-level query params to represent a valid OAuth
> 2.0 request, and there client_id is required. If the client_id is present
> the client registration together with any present client_secret can be
> retrieved.
>
> I reread the JAR spec, this is the only place that mentions handling of
> symmetric JWE.
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>
> (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.
>
>
> Vladimir
>
>
>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  > wrote:
>
>> The technique of replicating JWT claims that need to be publicly visible
>> in an encrypted JWT in the header is defined at
>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
>> for bringing this need to my attention as we were finishing the JWT spec=
.)
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of* John Bradley
>> *Sent:* Friday, January 10, 2020 2:15 PM
>> *To:* Vladimir Dzhuvinov 
>> *Cc:* IETF oauth WG 
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request
>> (JAR) vs OIDC request object
>>
>>
>>
>> The intent was to do that, but specs change once the OAuth WG and IESG
>> get there hands on them.
>>
>>
>>
>> Being backwards compatible with OIDC is not a compelling argument to the
>> IESG.
>>
>>
>>
>> We were mostly thinking of asymmetric encryption.
>>
>>
>>
>> Specifying puting the issuer and or the audience in the headder has come
>> up in the past but probably is not documented.
>>
>>
>>
>> John B
>>
>>
>>
>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov 
>> wrote:
>>
>> Yes, putting the client_id into the JWE header is a way around the need
>> to have the client_id outside the JWE as top-level authZ request
>> parameter.
>>
>> Unfortunately this work around isn't mentioned anywhere, I just checked
>> the most recent draft-ietf-oauth-jwsreq-20.
>>
>> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
>> presence of client_id as top-level parameter, together with requiring
>> RPs to register their request_uri's (so that we don't need to build and
>> store an index of all request_uri's). I just had a look at "DDoS Attack
>> on the Authorization Server" and also realised the request_uri
>> registration isn't explicitly mentioned as attack prevention ("the
>> server should (a) check that the value of "request_uri" parameter does
>> not point to an unexpected location").
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>> 
>>
>> To be honest, I feel quite bad about the situation with JAR we are in
>> now. For some reason I had the impression that OAuth JAR was going to be
>> the OIDC request / request_uri for general OAuth 2.0 use, as with other
>> OIDC bits that later became general purpose OAuth 2.0 specs.
>>
>> I find it unfortunate I didn't notice this when I was reviewing the spec
>> in the past.
>>
>> Vladimir
>>
>>
>> On 10/01/2020 22:39, Filip Skokan wrote:
>> > Vladimir,
>> >
>> > For that very case the payload claims may be repeated in the JWE
>> protected header. An implementation wanting to handle this may look for
>> iss/client_id there.
>> >
>> > Odesl=C3=A1no z iPhonu
>> >
>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>> >>
>> >> =EF=BB=BFI just realised there is one class of JARs where it's practi=
ally
>> >> impossible to process the request if merge isn't supported:
>> >>
>> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allo=
ws
>> >> for that and specs a method for deriving the shared key from the
>> >> client_secret:
>> >>
>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>> 
>> >>
>> >> If the JAR is encrypted with the client_secret, and there is no
>> >> top-level client_id parameter, there's no good way for the OP to find
>> >> out which client_secret to get to try to decrypt the JWE. Unless the =
OP
>> >> keeps an index of all issued client_secret's.
>> >>
>> >>
>> >> OP servers which require request_uri registration
>> >> (require_request_uri_registration=3Dtrue) and don't want to index all
>> >> registered request_uri's, also have no good way to process a
>> request_uri
>> >> if the client_id isn't present as top-level parameter.
>> >>
>> >>
>> >> Vladimir
>> >>
>> >>
>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> >>>
>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>> >>>> I think Torsten is speculating that is not a feature people use.
>> >>> I=E2=80=99m still trying to understand the use case for merging sign=
ed and
>> unsigned parameters. Nat once explained a use case, where a client uses
>> parameters signed by a 3rd party (some =E2=80=9Ecertification authority=
=E2=80=9C) in
>> combination with transaction-specific parameters. Is this being done in =
the
>> wild?
>> >>>
>> >>> PS: PAR would work with both modes.
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://
>> 
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Vladimir Dzhuvinov

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

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

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

=

Agre=
ed - that=E2=80=99s why we disabled request_uri by default and added extens=
ibility points to implement validation.

I thought it is odd that this was not mentioned in the=
 typical =E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..
=
 
 
=E2=80=94=E2=80=94=E2=80=94
Domini=
ck Baier
 
On 16. January 2020 at 08:=
07:44, Neil Madden (neil.madde=
n@forgerock.com) wrote:
 








If the AS can=E2=80=99t validate the request_uri it may al=
so
open itself up to SSRF attacks where a malicious client uses the
request_uri to probe/attack resources inside the AS=E2=80=99s private
network. This was a crucial part of the recent Capital One breach
for example [1].=C2=A0 ForgeRock currently requires strict
validation of request_uris against a client-specific whitelist for
exactly this reason.=C2=A0





NB some clients might legitimately be on that
private network (eg microservices) so changing to a global
whitelist for all clients is undesirable.=C2=A0









=E2=80=94 Neil





On 15 Jan 2020, at 21:02, Vladimir
Dzhuvinov <vladimir@connect2i=
d.com> wrote:








On 14/01/2020 19:20, Takahiko Kawasaki
wrote:





Well, embedding a client_id claim in the JWE header in order to
achieve "request parameters outside the request object should not
be referred to" is like "putting the cart before the horse".=
 Why do
we have to avoid using the traditional client_id request parameter so stubbornly?




The last paragraph of Section 3.2.1 of RFC 6749 says as
follows.






A client MAY use the "client_id" request parameter to
identify itself when sending requests to the token endpoint.=C2=A0
In the "authorization_code" "grant_type" request to the=
 token
endpoint, an unauthenticated client MUST send its "client_id" =
to
prevent itself from inadvertently accepting a code intended for a
client with a different "client_id". =C2=A0This protects the
client from substitution of the authentication code. =C2=A0(It
provides no additional security for the protected
resource.)









If the same reasoning applies, a client_id must always be sent with request / request_uri because client authentication is n=
ot
performed at the authorization endpoint. In other words, an
unauthenticated client (every client is unauthenticated at the
authorization endpoint) MUST send its "client_id" to prevent itse=
lf
from inadvertently accepting a request object for a client with a
different "client_id".











Identifying the client in JAR request_uri requests can be really
useful so that an AS which requires request_uri registration to
prevent DDoS attacks and other checks can do those without having
to index all request_uris individually. I mentioned this
before.


I really wonder what the reasoning of the IESG reviewers was to
insist on no params outside the JAR JWT / request_uri.


I'm beginning to realise this step of the review process isn't
particularly transparent to WG members.


Vladimir









Best Regards,


Taka














On Tue, Jan 14, 2020 at 12:57 AM
Vladimir Dzhuvinov <vladimir@=
connect2id.com>
wrote:






John, thanks, much appreciated!


On 11/01/2020 21:36, John Bradley wrote:




Yes JAR is not prohibiting paramater replication in the
header.=C2=A0


I will see if i can add something in final edits to call that
out.


John B.


On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:




Thanks Mike for the rfc7519 section-5.3
pointer. Can this parameter replication be used for client_id or
the client_id ass "iss" even though it isn't explicitly menti=
oned
in the JAR spec?


On 11/01/2020 02:58, John Bradley wrote:




Right we just don't say to put the iss there in
OIDC if it's symetricly encrypted.




OIDC doesn't have the symmetric key selection issue, I suppose
that why the possibility to replicate params to the JWE header
isn't mentioned at all. OIDC requires the top-level query params to
represent a valid OAuth 2.0 request, and there client_id is
required. If the client_id is present the client registration
together with any present client_secret can be retrieved.


I reread the JAR spec, this is the only place that mentions
handling of symmetric JWE.


https://tools.ietf.org/html/draft-ietf-oauth-jwsr=
eq-20#section-10.2






(b)  Verifying that the symmetric key for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.





Vladimir










On Fri, Jan 10, 2020, 9:41 PM
Mike Jones <Michael.Jones@microsoft.com> wrote:








The technique
of replicating JWT claims that need to be publicly visible in an
encrypted JWT in the header is defined at https://too=
ls.ietf.org/html/rfc7519#section-5.3.=C2=A0
(Thanks to Dick Hardt for bringing this need to my attention as we
were finishing the JWT 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=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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 John Bradley

Sent: Friday, January 10, 2020 2:15 PM

To: Vladimir Dzhuvinov <vladimir@connect2id.com>

Cc: IETF oauth WG <oauth@ietf.org>

Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
Request (JAR) vs OIDC request object


=C2=A0






The intent was to do that, but specs change
once the OAuth WG and IESG get there hands on them.=C2=A0=C2=A0




=C2=A0






Being backwards compatible with OIDC is not a
compelling argument to the IESG.






=C2=A0






We were mostly thinking of asymmetric
encryption.=C2=A0=C2=A0






=C2=A0






Specifying puting the issuer and or the
audience in the headder has come up in the past but probably is not
documented.=C2=A0=C2=A0






=C2=A0






John B=C2=A0




=C2=A0






On Fri, Jan 10, 2020, 6:29 PM Vladimir
Dzhuvinov <vladimir@connect2id.com> wrote:






Yes, putting the client_id into the JWE header
is a way around the need

to have the client_id outside the JWE as top-level authZ request
parameter.



Unfortunately this work around isn't mentioned anywhere, I just
checked

the most recent draft-ietf-oauth-jwsreq-20.



Our DDoS attack mitigation (for OIDC request_uri) also relies on
the

presence of client_id as top-level parameter, together with
requiring

RPs to register their request_uri's (so that we don't need to build
and

store an index of all request_uri's). I just had a look at "DDoS
Attack

on the Authorization Server" and also realised the
request_uri

registration isn't explicitly mentioned as attack prevention
("the

server should (a) check that the value of "request_uri" parameter
does

not point to an unexpected location").



https://tools.ietf.org/html/draft-iet=
f-oauth-jwsreq-20#section-10.4.1




To be honest, I feel quite bad about the situation with JAR we are
in

now. For some reason I had the impression that OAuth JAR was going
to be

the OIDC request / request_uri for general OAuth 2.0 use, as with
other

OIDC bits that later became general purpose OAuth 2.0 specs.



I find it unfortunate I didn't notice this when I was reviewing the
spec

in the past.



Vladimir





On 10/01/2020 22:39, Filip Skokan wrote:

> Vladimir,

>

> For that very case the payload claims may be repeated in the
JWE protected header. An implementation wanting to handle this may
look for iss/client_id there.

>

> Odesl=C3=A1no z iPhonu

>

>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <vladimir@connect2=
id.com>:

>>

>> =EF=BB=BFI just realised there is one class of JARs where it's
practially

>> impossible to process the request if merge isn't
supported:

>>

>> The client submits a JAR encrypted (JWT) with a shared
key. OIDC allows

>> for that and specs a method for deriving the shared key
from the

>> client_secret:

>>

>> https://openid.net/specs/openid-=
connect-core-1_0.html#Encryption


>>

>> If the JAR is encrypted with the client_secret, and there
is no

>> top-level client_id parameter, there's no good way for the
OP to find

>> out which client_secret to get to try to decrypt the JWE.
Unless the OP

>> keeps an index of all issued client_secret's.

>>

>>

>> OP servers which require request_uri registration

>> (require_request_uri_registration=3Dtrue) and don't want to
index all

>> registered request_uri's, also have no good way to process
a request_uri

>> if the client_id isn't present as top-level
parameter.

>>

>>

>> Vladimir

>>

>>

>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:

>>>

>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
<ve7jtb@ve7jtb.com>:

>>>> I think Torsten is speculating that is not a
feature people use.=C2=A0 =C2=A0

>>> I=E2=80=99m still trying to understand the use case for
merging signed and unsigned parameters. Nat once explained a use
case, where a client uses parameters signed by a 3rd party (some
=E2=80=9Ecertification authority=E2=80=9C) in combination with transaction-=
specific
parameters. Is this being done in the wild?

>>>

>>> PS: PAR would work with both modes.





_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

https://

























_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






-- =20
Vladimir Dzhuvinov

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.i=
etf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--000000000000aa4525059c3d6dca--


From nobody Thu Jan 16 00:34: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 27FD712002F for ; Thu, 16 Jan 2020 00:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 8LdshSPFd2l5 for ; Thu, 16 Jan 2020 00:34:10 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450: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 D03DD120019 for ; Thu, 16 Jan 2020 00:34:09 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id f129so2797015wmf.2 for ; Thu, 16 Jan 2020 00:34:09 -0800 (PST)
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=P44UDZpxFQtt25Y9O2oR10kSj73V3xLjgO9E70UMnKs=; b=AZFY8GTqaj9hN3U1pz8RhevDMKAgAo1yN9M5V/K3FpuC7970nZe0TWMVk89jrEwial XgSU3jBOBdD0QKl11Ev8fi56PgegeVYF0oBplwqRuBc8ygD4tRugGOd9FaFeEgeSyYjm Zau8coVnkw6GoqoXCZtSdCNLx7+zQoqYgsXkM=
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=P44UDZpxFQtt25Y9O2oR10kSj73V3xLjgO9E70UMnKs=; b=lKZQ/795T6wvqsc0tBhwUz96IB8jbv0mjK23RvQgdrHDnbpGHJadWeSCxiEwX/gV23 oCDWIgDVXCOmLGTHNE0ymILXCnCmH1Z1BvyXlXFOWCPVRK++sj1EbuoE17kxlNQ/1i0M RHyt9tE+xwhl2+zpojou2Zmf3DIGOby2+XHC2CtiV2mF3JYFYTIZ8pfQ8nIEh9Z9PZ+A UwjPrADWBevI15TIDkjVDFXL+z2/tY3Se6ExyGUZgkytSsTq/BYEuZiDetoCQfaP2aNp 6+vL0/1/9AbwN3l9E0cDLXgfD3uzZFa6fl545Xc3/MuLmbToITZllvWU1k5gBKF/jng1 uPJw==
X-Gm-Message-State: APjAAAVQOG48tAcnAaIWGouiu3fHpBqHoghHrIu4WLI1YFKMebC3pZcv /Do0nzo62AahDXq2b9REx5/HgnGwVvo=
X-Google-Smtp-Source: APXvYqw1lafTbCpo05aRK8d+pq61u2SlHP2UWAv7IE2oKbdB/7VGktuxixZnMxoluc+i3kUZkNFbrQ==
X-Received: by 2002:a05:600c:294:: with SMTP id 20mr4690109wmk.97.1579163648241;  Thu, 16 Jan 2020 00:34:08 -0800 (PST)
Received: from ?IPv6:2a01:4c8:1f:702a:84d9:1731:5d13:c644? ([2a01:4c8:1f:702a:84d9:1731:5d13:c644]) by smtp.gmail.com with ESMTPSA id l6sm3584966wmf.21.2020.01.16.00.34.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 00:34:07 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D9EDC5A8-4423-4B19-8D55-0BD7CECCE0CA
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jan 2020 08:34:06 +0000
Message-Id: 
References: 
Cc: Vladimir Dzhuvinov , IETF oauth WG 
In-Reply-To: 
To: Dominick Baier 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 08:34:15 -0000

--Apple-Mail-D9EDC5A8-4423-4B19-8D55-0BD7CECCE0CA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Is it too late to add it to the security considerations for JAR?=20

=E2=80=94 Neil

> On 16 Jan 2020, at 08:15, Dominick Baier  wrote=
:
>=20
> =EF=BB=BF
> Agreed - that=E2=80=99s why we disabled request_uri by default and added e=
xtensibility points to implement validation.
>=20
> I thought it is odd that this was not mentioned in the typical =E2=80=9Cse=
curity considerations=E2=80=9D in the OIDC spec..
>=20
> =E2=80=94=E2=80=94=E2=80=94
> Dominick Baier
>=20
>> On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com) w=
rote:
>>=20
>> If the AS can=E2=80=99t validate the request_uri it may also open itself u=
p to SSRF attacks where a malicious client uses the request_uri to probe/att=
ack resources inside the AS=E2=80=99s private network. This was a crucial pa=
rt of the recent Capital One breach for example [1].  ForgeRock currently re=
quires strict validation of request_uris against a client-specific whitelist=
 for exactly this reason.=20
>>=20
>> NB some clients might legitimately be on that private network (eg microse=
rvices) so changing to a global whitelist for all clients is undesirable.=20=

>>=20
>> [1]: https://ejj.io/blog/capital-one
>>=20
>> =E2=80=94 Neil
>>=20
>>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov  w=
rote:
>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>> Well, embedding a client_id claim in the JWE header in order to achieve=
 "request parameters outside the request object should not be referred to" i=
s like "putting the cart before the horse". Why do we have to avoid using th=
e traditional client_id request parameter so stubbornly?
>>>>=20
>>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
>>>>=20
>>>> A client MAY use the "client_id" request parameter to identify itself w=
hen sending requests to the token endpoint.  In the "authorization_code" "gr=
ant_type" request to the token endpoint, an unauthenticated client MUST send=
 its "client_id" to prevent itself from inadvertently accepting a code inten=
ded for a client with a different "client_id".  This protects the client fro=
m substitution of the authentication code.  (It provides no additional secur=
ity for the protected resource.)
>>>>=20
>>>> If the same reasoning applies, a client_id must always be sent with req=
uest / request_uri because client authentication is not performed at the aut=
horization endpoint. In other words, an unauthenticated client (every client=
 is unauthenticated at the authorization endpoint) MUST send its "client_id"=
 to prevent itself from inadvertently accepting a request object for a clien=
t with a different "client_id".
>>>>=20
>>> Identifying the client in JAR request_uri requests can be really useful s=
o that an AS which requires request_uri registration to prevent DDoS attacks=
 and other checks can do those without having to index all request_uris indi=
vidually. I mentioned this before.
>>>=20
>>> I really wonder what the reasoning of the IESG reviewers was to insist o=
n no params outside the JAR JWT / request_uri.
>>>=20
>>> I'm beginning to realise this step of the review process isn't particula=
rly transparent to WG members.
>>>=20
>>> Vladimir
>>>=20
>>>=20
>>>=20
>>>> Best Regards,
>>>> Taka
>>>>=20
>>>>=20
>>>>=20
>>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov  wrote:
>>>>> John, thanks, much appreciated!
>>>>>=20
>>>>>> On 11/01/2020 21:36, John Bradley wrote:
>>>>>> Yes JAR is not prohibiting paramater replication in the header.=20
>>>>>>=20
>>>>>> I will see if i can add something in final edits to call that out.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter r=
eplication be used for client_id or the client_id ass "iss" even though it i=
sn't explicitly mentioned in the JAR spec?
>>>>>>>=20
>>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
>>>>>>>> Right we just don't say to put the iss there in OIDC if it's symetr=
icly encrypted.
>>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose that w=
hy the possibility to replicate params to the JWE header isn't mentioned at a=
ll. OIDC requires the top-level query params to represent a valid OAuth 2.0 r=
equest, and there client_id is required. If the client_id is present the cli=
ent registration together with any present client_secret can be retrieved.
>>>>>>>=20
>>>>>>> I reread the JAR spec, this is the only place that mentions handling=
 of symmetric JWE.
>>>>>>>=20
>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>>>>>>=20
>>>>>>>> (b)  Verifying that the symmetric key for the JWE encryption is the=

>>>>>>>>         correct one if the JWE is using symmetric encryption.
>>>>>>>=20
>>>>>>> Vladimir
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  wrote:
>>>>>>>>> The technique of replicating JWT claims that need to be publicly v=
isible in an encrypted JWT in the header is defined at https://tools.ietf.or=
g/html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to=
 my attention as we were finishing the JWT spec.)
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>>                                                        -- Mike
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> From: OAuth  On Behalf Of John Bradley
>>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
>>>>>>>>> To: Vladimir Dzhuvinov 
>>>>>>>>> Cc: IETF oauth WG 
>>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Reque=
st (JAR) vs OIDC request object
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> The intent was to do that, but specs change once the OAuth WG and I=
ESG get there hands on them. =20
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> Being backwards compatible with OIDC is not a compelling argument t=
o the IESG.
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> We were mostly thinking of asymmetric encryption. =20
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> Specifying puting the issuer and or the audience in the headder ha=
s come up in the past but probably is not documented. =20
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> John B=20
>>>>>>>>>=20
>>>>>>>>> =20
>>>>>>>>>=20
>>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov  wrote:
>>>>>>>>>=20
>>>>>>>>> Yes, putting the client_id into the JWE header is a way around the=
 need
>>>>>>>>> to have the client_id outside the JWE as top-level authZ request p=
arameter.
>>>>>>>>>=20
>>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I just ch=
ecked
>>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
>>>>>>>>>=20
>>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies on t=
he
>>>>>>>>> presence of client_id as top-level parameter, together with requir=
ing
>>>>>>>>> RPs to register their request_uri's (so that we don't need to buil=
d and
>>>>>>>>> store an index of all request_uri's). I just had a look at "DDoS A=
ttack
>>>>>>>>> on the Authorization Server" and also realised the request_uri
>>>>>>>>> registration isn't explicitly mentioned as attack prevention ("the=

>>>>>>>>> server should (a) check that the value of "request_uri" parameter d=
oes
>>>>>>>>> not point to an unexpected location").
>>>>>>>>>=20
>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.=
4.1
>>>>>>>>>=20
>>>>>>>>> To be honest, I feel quite bad about the situation with JAR we are=
 in
>>>>>>>>> now. For some reason I had the impression that OAuth JAR was going=
 to be
>>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as with o=
ther
>>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
>>>>>>>>>=20
>>>>>>>>> I find it unfortunate I didn't notice this when I was reviewing th=
e spec
>>>>>>>>> in the past.
>>>>>>>>>=20
>>>>>>>>> Vladimir
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
>>>>>>>>> > Vladimir,
>>>>>>>>> >
>>>>>>>>> > For that very case the payload claims may be repeated in the JWE=
 protected header. An implementation wanting to handle this may look for iss=
/client_id there.
>>>>>>>>> >
>>>>>>>>> > Odesl=C3=A1no z iPhonu
>>>>>>>>> >
>>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>>>>>>>>> >>
>>>>>>>>> >> =EF=BB=BFI just realised there is one class of JARs where it's p=
ractially
>>>>>>>>> >> impossible to process the request if merge isn't supported:
>>>>>>>>> >>
>>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key. OID=
C allows
>>>>>>>>> >> for that and specs a method for deriving the shared key from th=
e
>>>>>>>>> >> client_secret:
>>>>>>>>> >>
>>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryptio=
n
>>>>>>>>> >>
>>>>>>>>> >> If the JAR is encrypted with the client_secret, and there is no=

>>>>>>>>> >> top-level client_id parameter, there's no good way for the OP t=
o find
>>>>>>>>> >> out which client_secret to get to try to decrypt the JWE. Unles=
s the OP
>>>>>>>>> >> keeps an index of all issued client_secret's.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> OP servers which require request_uri registration
>>>>>>>>> >> (require_request_uri_registration=3Dtrue) and don't want to ind=
ex all
>>>>>>>>> >> registered request_uri's, also have no good way to process a re=
quest_uri
>>>>>>>>> >> if the client_id isn't present as top-level parameter.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> Vladimir
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>>>>>>>> >>>> I think Torsten is speculating that is not a feature people u=
se.  =20
>>>>>>>>> >>> I=E2=80=99m still trying to understand the use case for mergin=
g signed and unsigned parameters. Nat once explained a use case, where a cli=
ent uses parameters signed by a 3rd party (some =E2=80=9Ecertification autho=
rity=E2=80=9C) in combination with transaction-specific parameters. Is this b=
eing done in the wild?
>>>>>>>>> >>>
>>>>>>>>> >>> PS: PAR would work with both modes.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://
>>>>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> -- =20
>>> Vladimir Dzhuvinov
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________=20
>> OAuth mailing list=20
>> OAuth@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/oauth=20

--Apple-Mail-D9EDC5A8-4423-4B19-8D55-0BD7CECCE0CA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Is it too late to add it t=
o the security considerations for JAR? 
 
-- 
Vladimir =
Dzhuvinov

=

--Apple-Mail=_80407108-E82E-4DC4-B995-9D97421FB10B--


From nobody Thu Jan 16 07:48: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 1E19312098C for ; Thu, 16 Jan 2020 07:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa3ieWCkf28f for ; Thu, 16 Jan 2020 07:48:09 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B15120952 for ; Thu, 16 Jan 2020 07:48:01 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id w15so19686906wru.4 for ; Thu, 16 Jan 2020 07:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QfdyrAxj/arJ0W2BsnOanl5UR6TW19m474DoWh6fr/Q=; b=AUlGGOfTXlbjgJrLsLjK6PF8W+9h5Mu8zBapfGB3oaoLfCNZym2UFQ8CggeLmFQlGL zdgWdGzQPnkZoHdq+nlg3cKG2xJpYunLCsl+gjOM54pN19DoDNZU5W7bFSu+6Ouaqc4s DkLftWUa6ogwPGwUVgVdIEJf3JugELooE0x+pxZR+glvtdrG5mXtx4Fbf6Wwrm2nHH26 Swoxx7vFxGi2aTMXmErb6H3X6taWxxJjBckL1Z5c1QtztSDr4bUUsQs2mm9bqc1VSNCV mxSxQm0+Eq6t7PZyB39Pvs8j9wbr4INKjufftYJUzADwn526Jfl/rHOauahM/9jOi6Q6 t8tg==
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=QfdyrAxj/arJ0W2BsnOanl5UR6TW19m474DoWh6fr/Q=; b=q+moKz6OUFtSjYrdwDPe02vyVOUPjs195CxCUE3nYtlPvakQ6wqN8JBHAKn4BBIBDo 7aN7vNWw4cyGlZBHfIvija/Vaw43cShbtM4TuJXDHRsksS5sZWrIDHH2iDEzSisnDdWa bR6k5rFunMcXDgb1qClfUBVtC0JE4iEXP0S/YvVVlhKvZ7haRe7aW/8jCyR9VO5NhtiC oZOCIYi3hXCwHPblOvXNSKMCXxm8as5VvYN0Ti4Mj5Qxymng0YhdzNBPKn/XO3HQLbUl 0WA/Y7GD/YeAgPeelz5NQgRmLaaIIS7W1afozjSfZO/wSRoGI4E90sGUnDGJdq2nUOOV AXiQ==
X-Gm-Message-State: APjAAAV82mGB+Ti3LuxUug76qmiZ+AqCrnGhsxjEIwAEXu+L4Y6nqSe1 7Frk0qtDtCP/q7vS51zFZvL0ZcJvOw68bnYfyIw=
X-Google-Smtp-Source: APXvYqze6ebYLCtXuswTVZUgfHqgf1GS+XbHVRvU8ZhxkGyevKP2TeRtEAEqTUn0s3vEqU8Hcdf1e1rFiuZyrTOitC0=
X-Received: by 2002:adf:f98c:: with SMTP id f12mr3846291wrr.138.1579189679294;  Thu, 16 Jan 2020 07:47:59 -0800 (PST)
MIME-Version: 1.0
References:   <20200116143233.GJ80030@kduck.mit.edu>
In-Reply-To: <20200116143233.GJ80030@kduck.mit.edu>
From: Nat Sakimura 
Date: Fri, 17 Jan 2020 00:47:45 +0900
Message-ID: 
To: Benjamin Kaduk 
Cc: Neil Madden , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000de0e18059c43bfb7"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 15:48:18 -0000

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

Right. We could add a security consideration like that, though the
mitigation probably is pretty much the same as what is stated in 10.4.1:

the server should (a) check that
   the value of "request_uri" parameter does not point to an unexpected
   location, (b) check the content type of the response is "application/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on the
   "request_uri".

If not, please let me know so that we can add that as the mitigation as
well.

Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt
but it has to validate that content is a valid request object anyways and
if it is malformed, it MUST stop the processing and return an error
invalid_request_uri. So, unlike in the case of Capital One's SSRF, the
content of the request_uri will not be exposed. The main downside is
therefore as depicted in the current draft, consumption of the network and
processing power of the AS, and the unwanted access load to the servers
serving the URL pointed by request_uri. The above-quoted mitigations were
introduced to address these issues.




On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk  wrote:

> It is not too late to add to the security considerations.
>
> It seems that the new application/oauth.authz.req+jwt media-type is helpf=
ul
> in this regard, in that if an AS can require that content-type from
> dereferencing the request_uri, then seeing anything else indicates that t=
he
> request was bogus (or an attack).  I guess existing OIDC deployments aren=
't
> exactly in a position to do that, though.
>
> -Ben
>
> On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:
> > Is it too late to add it to the security considerations for JAR?
> >
> > =E2=80=94 Neil
> >
> > > On 16 Jan 2020, at 08:15, Dominick Baier 
> wrote:
> > >
> > > =EF=BB=BF
> > > Agreed - that=E2=80=99s why we disabled request_uri by default and ad=
ded
> extensibility points to implement validation.
> > >
> > > I thought it is odd that this was not mentioned in the typical
> =E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..
> > >
> > > =E2=80=94=E2=80=94=E2=80=94
> > > Dominick Baier
> > >
> > >> On 16. January 2020 at 08:07:44, Neil Madden (
> neil.madden@forgerock.com) wrote:
> > >>
> > >> If the AS can=E2=80=99t validate the request_uri it may also open it=
self up
> to SSRF attacks where a malicious client uses the request_uri to
> probe/attack resources inside the AS=E2=80=99s private network. This was =
a crucial
> part of the recent Capital One breach for example [1].  ForgeRock current=
ly
> requires strict validation of request_uris against a client-specific
> whitelist for exactly this reason.
> > >>
> > >> NB some clients might legitimately be on that private network (eg
> microservices) so changing to a global whitelist for all clients is
> undesirable.
> > >>
> > >> [1]: https://ejj.io/blog/capital-one
> > >>
> > >> =E2=80=94 Neil
> > >>
> > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> > >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > >>>> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not be
> referred to" is like "putting the cart before the horse". Why do we have =
to
> avoid using the traditional client_id request parameter so stubbornly?
> > >>>>
> > >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
> > >>>>
> > >>>> A client MAY use the "client_id" request parameter to identify
> itself when sending requests to the token endpoint.  In the
> "authorization_code" "grant_type" request to the token endpoint, an
> unauthenticated client MUST send its "client_id" to prevent itself from
> inadvertently accepting a code intended for a client with a different
> "client_id".  This protects the client from substitution of the
> authentication code.  (It provides no additional security for the protect=
ed
> resource.)
> > >>>>
> > >>>> If the same reasoning applies, a client_id must always be sent wit=
h
> request / request_uri because client authentication is not performed at t=
he
> authorization endpoint. In other words, an unauthenticated client (every
> client is unauthenticated at the authorization endpoint) MUST send its
> "client_id" to prevent itself from inadvertently accepting a request obje=
ct
> for a client with a different "client_id".
> > >>>>
> > >>> Identifying the client in JAR request_uri requests can be really
> useful so that an AS which requires request_uri registration to prevent
> DDoS attacks and other checks can do those without having to index all
> request_uris individually. I mentioned this before.
> > >>>
> > >>> I really wonder what the reasoning of the IESG reviewers was to
> insist on no params outside the JAR JWT / request_uri.
> > >>>
> > >>> I'm beginning to realise this step of the review process isn't
> particularly transparent to WG members.
> > >>>
> > >>> Vladimir
> > >>>
> > >>>
> > >>>
> > >>>> Best Regards,
> > >>>> Taka
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> > >>>>> John, thanks, much appreciated!
> > >>>>>
> > >>>>>> On 11/01/2020 21:36, John Bradley wrote:
> > >>>>>> Yes JAR is not prohibiting paramater replication in the header.
> > >>>>>>
> > >>>>>> I will see if i can add something in final edits to call that ou=
t.
> > >>>>>>
> > >>>>>> John B.
> > >>>>>>
> > >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this
> parameter replication be used for client_id or the client_id ass "iss" ev=
en
> though it isn't explicitly mentioned in the JAR spec?
> > >>>>>>>
> > >>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
> > >>>>>>>> Right we just don't say to put the iss there in OIDC if it's
> symetricly encrypted.
> > >>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose
> that why the possibility to replicate params to the JWE header isn't
> mentioned at all. OIDC requires the top-level query params to represent a
> valid OAuth 2.0 request, and there client_id is required. If the client_i=
d
> is present the client registration together with any present client_secre=
t
> can be retrieved.
> > >>>>>>>
> > >>>>>>> I reread the JAR spec, this is the only place that mentions
> handling of symmetric JWE.
> > >>>>>>>
> > >>>>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> > >>>>>>>
> > >>>>>>>> (b)  Verifying that the symmetric key for the JWE encryption i=
s
> the
> > >>>>>>>>         correct one if the JWE is using symmetric encryption.
> > >>>>>>>
> > >>>>>>> Vladimir
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <
> Michael.Jones@microsoft.com> wrote:
> > >>>>>>>>> The technique of replicating JWT claims that need to be
> publicly visible in an encrypted JWT in the header is defined at
> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
> for bringing this need to my attention as we were finishing the JWT spec.=
)
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>                                                        -- Mik=
e
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> From: OAuth  On Behalf Of John Bradle=
y
> > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
> > >>>>>>>>> To: Vladimir Dzhuvinov 
> > >>>>>>>>> Cc: IETF oauth WG 
> > >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
> Request (JAR) vs OIDC request object
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> The intent was to do that, but specs change once the OAuth WG
> and IESG get there hands on them.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Being backwards compatible with OIDC is not a compelling
> argument to the IESG.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> We were mostly thinking of asymmetric encryption.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Specifying puting the issuer and or the audience in the
> headder has come up in the past but probably is not documented.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> John B
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Yes, putting the client_id into the JWE header is a way aroun=
d
> the need
> > >>>>>>>>> to have the client_id outside the JWE as top-level authZ
> request parameter.
> > >>>>>>>>>
> > >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I
> just checked
> > >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
> > >>>>>>>>>
> > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies
> on the
> > >>>>>>>>> presence of client_id as top-level parameter, together with
> requiring
> > >>>>>>>>> RPs to register their request_uri's (so that we don't need to
> build and
> > >>>>>>>>> store an index of all request_uri's). I just had a look at
> "DDoS Attack
> > >>>>>>>>> on the Authorization Server" and also realised the request_ur=
i
> > >>>>>>>>> registration isn't explicitly mentioned as attack prevention
> ("the
> > >>>>>>>>> server should (a) check that the value of "request_uri"
> parameter does
> > >>>>>>>>> not point to an unexpected location").
> > >>>>>>>>>
> > >>>>>>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> > >>>>>>>>>
> > >>>>>>>>> To be honest, I feel quite bad about the situation with JAR w=
e
> are in
> > >>>>>>>>> now. For some reason I had the impression that OAuth JAR was
> going to be
> > >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as
> with other
> > >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
> > >>>>>>>>>
> > >>>>>>>>> I find it unfortunate I didn't notice this when I was
> reviewing the spec
> > >>>>>>>>> in the past.
> > >>>>>>>>>
> > >>>>>>>>> Vladimir
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
> > >>>>>>>>> > Vladimir,
> > >>>>>>>>> >
> > >>>>>>>>> > For that very case the payload claims may be repeated in th=
e
> JWE protected header. An implementation wanting to handle this may look f=
or
> iss/client_id there.
> > >>>>>>>>> >
> > >>>>>>>>> > Odesl=C3=A1no z iPhonu
> > >>>>>>>>> >
> > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <
> vladimir@connect2id.com>:
> > >>>>>>>>> >>
> > >>>>>>>>> >> =EF=BB=BFI just realised there is one class of JARs where =
it's
> practially
> > >>>>>>>>> >> impossible to process the request if merge isn't supported=
:
> > >>>>>>>>> >>
> > >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key=
.
> OIDC allows
> > >>>>>>>>> >> for that and specs a method for deriving the shared key
> from the
> > >>>>>>>>> >> client_secret:
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> > >>>>>>>>> >>
> > >>>>>>>>> >> If the JAR is encrypted with the client_secret, and there
> is no
> > >>>>>>>>> >> top-level client_id parameter, there's no good way for the
> OP to find
> > >>>>>>>>> >> out which client_secret to get to try to decrypt the JWE.
> Unless the OP
> > >>>>>>>>> >> keeps an index of all issued client_secret's.
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >> OP servers which require request_uri registration
> > >>>>>>>>> >> (require_request_uri_registration=3Dtrue) and don't want t=
o
> index all
> > >>>>>>>>> >> registered request_uri's, also have no good way to process
> a request_uri
> > >>>>>>>>> >> if the client_id isn't present as top-level parameter.
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >> Vladimir
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> > >>>>>>>>> >>>
> > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <
> ve7jtb@ve7jtb.com>:
> > >>>>>>>>> >>>> I think Torsten is speculating that is not a feature
> people use.
> > >>>>>>>>> >>> I=E2=80=99m still trying to understand the use case for m=
erging
> signed and unsigned parameters. Nat once explained a use case, where a
> client uses parameters signed by a 3rd party (some =E2=80=9Ecertification
> authority=E2=80=9C) in combination with transaction-specific parameters. =
Is this
> being done in the wild?
> > >>>>>>>>> >>>
> > >>>>>>>>> >>> PS: PAR would work with both modes.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> OAuth mailing list
> > >>>>>>>>> OAuth@ietf.org
> > >>>>>>>>> https://
> > >>>>>>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> OAuth mailing list
> > >>>>> OAuth@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
> > >>> --
> > >>> Vladimir Dzhuvinov
> > >>> _______________________________________________
> > >>> OAuth mailing list
> > >>> OAuth@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/oauth
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> 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

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


Right. We could add a security consideration like that, th=
ough the mitigation probably is pretty much the same as what is stated in 1=
0.4.1:=C2=A0
the server should (a) check that
   the value of "request_uri" parameter does not point to an unex=
pected
   location, (b) check the content type of the response is "applicatio=
n/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on=
 the
   "request_uri".
If not, please let me know so t=
hat we can add that as the mitigation as well.=C2=A0

Existing OIDC deployment cannot make use of application/oauth.authz.req+=
jwt but it has to validate that content is a valid request object anyways a=
nd if it is malformed, it MUST stop the processing and return an error inva=
lid_request_uri. So, unlike in the case of Capital One's SSRF, the cont=
ent of the request_uri will not be exposed. The main downside is therefore =
as depicted in the current draft, consumption of the network and processing=
 power of the AS, and the unwanted access load to the servers serving the U=
RL pointed by request_uri. The above-quoted mitigations were introduced to =
address these issues.=C2=A0




On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
It is not too late to add to the security conside=
rations.



It seems that the new application/oauth.authz.req+jwt media-type is helpful=


in this regard, in that if an AS can require that content-type from

dereferencing the request_uri, then seeing anything else indicates that the=


request was bogus (or an attack).=C2=A0 I guess existing OIDC deployments a=
ren't

exactly in a position to do that, though.



-Ben



On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:

> Is it too late to add it to the security considerations for JAR? 

> 

> =E2=80=94 Neil

> 

> > On 16 Jan 2020, at 08:15, Dominick Baier <dbaier@leastprivilege.com>=
; wrote:

> > 

> > =EF=BB=BF

> > Agreed - that=E2=80=99s why we disabled request_uri by default an=
d added extensibility points to implement validation.

> > 

> > I thought it is odd that this was not mentioned in the typical =
=E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..

> > 

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

> > Dominick Baier

> > 

> >> On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com) wrote:

> >> 

> >> If the AS can=E2=80=99t validate the request_uri it may also =
open itself up to SSRF attacks where a malicious client uses the request_ur=
i to probe/attack resources inside the AS=E2=80=99s private network. This w=
as a crucial part of the recent Capital One breach for example [1].=C2=A0 F=
orgeRock currently requires strict validation of request_uris against a cli=
ent-specific whitelist for exactly this reason. 

> >> 

> >> NB some clients might legitimately be on that private network=
 (eg microservices) so changing to a global whitelist for all clients is un=
desirable. 

> >> 

> >> [1]: https://ejj.io/blog/capital-one

> >> 

> >> =E2=80=94 Neil

> >> 

> >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <vladimir@connect2id.c=
om> wrote:

> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:

> >>>> Well, embedding a client_id claim in the JWE header i=
n order to achieve "request parameters outside the request object shou=
ld not be referred to" is like "putting the cart before the horse=
". Why do we have to avoid using the traditional client_id request par=
ameter so stubbornly?

> >>>> 

> >>>> The last paragraph of Section 3.2.1 of RFC 6749 says =
as follows.

> >>>> 

> >>>> A client MAY use the "client_id" request pa=
rameter to identify itself when sending requests to the token endpoint.=C2=
=A0 In the "authorization_code" "grant_type" request to=
 the token endpoint, an unauthenticated client MUST send its "client_i=
d" to prevent itself from inadvertently accepting a code intended for =
a client with a different "client_id".=C2=A0 This protects the cl=
ient from substitution of the authentication code.=C2=A0 (It provides no ad=
ditional security for the protected resource.)

> >>>> 

> >>>> If the same reasoning applies, a client_id must alway=
s be sent with request / request_uri because client authentication is not p=
erformed at the authorization endpoint. In other words, an unauthenticated =
client (every client is unauthenticated at the authorization endpoint) MUST=
 send its "client_id" to prevent itself from inadvertently accept=
ing a request object for a client with a different "client_id".
> >>>> 

> >>> Identifying the client in JAR request_uri requests can be=
 really useful so that an AS which requires request_uri registration to pre=
vent DDoS attacks and other checks can do those without having to index all=
 request_uris individually. I mentioned this before.

> >>> 

> >>> I really wonder what the reasoning of the IESG reviewers =
was to insist on no params outside the JAR JWT / request_uri.

> >>> 

> >>> I'm beginning to realise this step of the review proc=
ess isn't particularly transparent to WG members.

> >>> 

> >>> Vladimir

> >>> 

> >>> 

> >>> 

> >>>> Best Regards,

> >>>> Taka

> >>>> 

> >>>> 

> >>>> 

> >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov &=
lt;vladimir@co=
nnect2id.com> wrote:

> >>>>> John, thanks, much appreciated!

> >>>>> 

> >>>>>> On 11/01/2020 21:36, John Bradley wrote:

> >>>>>> Yes JAR is not prohibiting paramater replicat=
ion in the header. 

> >>>>>> 

> >>>>>> I will see if i can add something in final ed=
its to call that out.

> >>>>>> 

> >>>>>> John B.

> >>>>>> 

> >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov =
wrote:

> >>>>>>> Thanks Mike for the rfc7519 section-5.3 p=
ointer. Can this parameter replication be used for client_id or the client_=
id ass "iss" even though it isn't explicitly mentioned in the=
 JAR spec?

> >>>>>>> 

> >>>>>>>> On 11/01/2020 02:58, John Bradley wro=
te:

> >>>>>>>> Right we just don't say to put th=
e iss there in OIDC if it's symetricly encrypted.

> >>>>>>> OIDC doesn't have the symmetric key s=
election issue, I suppose that why the possibility to replicate params to t=
he JWE header isn't mentioned at all. OIDC requires the top-level query=
 params to represent a valid OAuth 2.0 request, and there client_id is requ=
ired. If the client_id is present the client registration together with any=
 present client_secret can be retrieved.

> >>>>>>> 

> >>>>>>> I reread the JAR spec, this is the only p=
lace that mentions handling of symmetric JWE.

> >>>>>>> 

> >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> >>>>>>> 

> >>>>>>>> (b)=C2=A0 Verifying that the symmetri=
c key for the JWE encryption is the

> >>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corr=
ect one if the JWE is using symmetric encryption.

> >>>>>>> 

> >>>>>>> Vladimir

> >>>>>>> 

> >>>>>>> 

> >>>>>>> 

> >>>>>>>> 

> >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jo=
nes <Mi=
chael.Jones@microsoft.com> wrote:

> >>>>>>>>> The technique of replicating JWT =
claims that need to be publicly visible in an encrypted JWT in the header i=
s defined at https://tools.ietf.org/html/rfc7519#sect=
ion-5.3.=C2=A0 (Thanks to Dick Hardt for bringing this need to my atten=
tion as we were finishing the JWT 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =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> O=
n Behalf Of John Bradley

> >>>>>>>>> Sent: Friday, January 10, 2020 2:=
15 PM

> >>>>>>>>> To: Vladimir Dzhuvinov <vladimir@connect2id.=
com>

> >>>>>>>>> Cc: IETF oauth WG <oauth@ietf.org>

> >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG=
] JWT Secured Authorization Request (JAR) vs OIDC request object

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> The intent was to do that, but sp=
ecs change once the OAuth WG and IESG get there hands on them.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> Being backwards compatible with O=
IDC is not a compelling argument to the IESG.

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> We were mostly thinking of asymme=
tric encryption.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> Specifying puting the issuer and =
or the audience in the headder has come up in the past but probably is not =
documented.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> John B 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vla=
dimir Dzhuvinov <vladimir@connect2id.com> wrote:

> >>>>>>>>> 

> >>>>>>>>> Yes, putting the client_id into t=
he JWE header is a way around the need

> >>>>>>>>> to have the client_id outside the=
 JWE as top-level authZ request parameter.

> >>>>>>>>> 

> >>>>>>>>> Unfortunately this work around is=
n't mentioned anywhere, I just checked

> >>>>>>>>> the most recent draft-ietf-oauth-=
jwsreq-20.

> >>>>>>>>> 

> >>>>>>>>> Our DDoS attack mitigation (for O=
IDC request_uri) also relies on the

> >>>>>>>>> presence of client_id as top-leve=
l parameter, together with requiring

> >>>>>>>>> RPs to register their request_uri=
's (so that we don't need to build and

> >>>>>>>>> store an index of all request_uri=
's). I just had a look at "DDoS Attack

> >>>>>>>>> on the Authorization Server"=
 and also realised the request_uri

> >>>>>>>>> registration isn't explicitly=
 mentioned as attack prevention ("the

> >>>>>>>>> server should (a) check that the =
value of "request_uri" parameter does

> >>>>>>>>> not point to an unexpected locati=
on").

> >>>>>>>>> 

> >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-=
10.4.1

> >>>>>>>>> 

> >>>>>>>>> To be honest, I feel quite bad ab=
out the situation with JAR we are in

> >>>>>>>>> now. For some reason I had the im=
pression that OAuth JAR was going to be

> >>>>>>>>> the OIDC request / request_uri fo=
r general OAuth 2.0 use, as with other

> >>>>>>>>> OIDC bits that later became gener=
al purpose OAuth 2.0 specs.

> >>>>>>>>> 

> >>>>>>>>> I find it unfortunate I didn'=
t notice this when I was reviewing the spec

> >>>>>>>>> in the past.

> >>>>>>>>> 

> >>>>>>>>> Vladimir

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> On 10/01/2020 22:39, Filip Skokan=
 wrote:

> >>>>>>>>> > Vladimir,

> >>>>>>>>> >

> >>>>>>>>> > For that very case the paylo=
ad claims may be repeated in the JWE protected header. An implementation wa=
nting to handle this may look for iss/client_id there.

> >>>>>>>>> >

> >>>>>>>>> > Odesl=C3=A1no z iPhonu

> >>>>>>>>> >

> >>>>>>>>> >> 10. 1. 2020 v 21:19, Vla=
dimir Dzhuvinov <vladimir@connect2id.com>:

> >>>>>>>>> >>

> >>>>>>>>> >> =EF=BB=BFI just realised=
 there is one class of JARs where it's practially

> >>>>>>>>> >> impossible to process th=
e request if merge isn't supported:

> >>>>>>>>> >>

> >>>>>>>>> >> The client submits a JAR=
 encrypted (JWT) with a shared key. OIDC allows

> >>>>>>>>> >> for that and specs a met=
hod for deriving the shared key from the

> >>>>>>>>> >> client_secret:

> >>>>>>>>> >>

> >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryp=
tion

> >>>>>>>>> >>

> >>>>>>>>> >> If the JAR is encrypted =
with the client_secret, and there is no

> >>>>>>>>> >> top-level client_id para=
meter, there's no good way for the OP to find

> >>>>>>>>> >> out which client_secret =
to get to try to decrypt the JWE. Unless the OP

> >>>>>>>>> >> keeps an index of all is=
sued client_secret's.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> OP servers which require=
 request_uri registration

> >>>>>>>>> >> (require_request_uri_reg=
istration=3Dtrue) and don't want to index all

> >>>>>>>>> >> registered request_uri&#=
39;s, also have no good way to process a request_uri

> >>>>>>>>> >> if the client_id isn'=
;t present as top-level parameter.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> Vladimir

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >>> On 10/01/2020 20:13,=
 Torsten Lodderstedt wrote:

> >>>>>>>>> >>>

> >>>>>>>>> >>>>> Am 10.01.202=
0 um 16:53 schrieb John Bradley <ve7jtb@ve7jtb.com>:

> >>>>>>>>> >>>> I think Torsten =
is speculating that is not a feature people use.=C2=A0 =C2=A0

> >>>>>>>>> >>> I=E2=80=99m still tr=
ying to understand the use case for merging signed and unsigned parameters.=
 Nat once explained a use case, where a client uses parameters signed by a =
3rd party (some =E2=80=9Ecertification authority=E2=80=9C) in combination w=
ith transaction-specific parameters. Is this being done in the wild?

> >>>>>>>>> >>>

> >>>>>>>>> >>> PS: PAR would work w=
ith both modes.

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> _________________________________=
______________

> >>>>>>>>> OAuth mailing list

> >>>>>>>>> OAuth@ietf.org

> >>>>>>>>> https://

> >>>>>>>>> 

> >>>>> 

> >>>>> _______________________________________________
> >>>>> OAuth mailing list

> >>>>> OAuth@ietf.org

> >>>>> https://www.ietf.org/mailman/li=
stinfo/oauth

> >>> --=C2=A0 

> >>> Vladimir Dzhuvinov

> >>> _______________________________________________

> >>> OAuth mailing list

> >>> OAuth=
@ietf.org

> >>> https://www.ietf.org/mailman/listinfo/o=
auth

> >> _______________________________________________ 

> >> OAuth mailing list 

> >> OAuth@iet=
f.org 

> >> https://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




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Found=
ation
http://nat.=
sakimura.org/
@_nat_en


--000000000000de0e18059c43bfb7--


From nobody Thu Jan 16 08:25: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 2A474120994 for ; Thu, 16 Jan 2020 08:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 eJrxr4cp9ecf for ; Thu, 16 Jan 2020 08:25:19 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450: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 801211200C1 for ; Thu, 16 Jan 2020 08:25:18 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id b19so4374859wmj.4 for ; Thu, 16 Jan 2020 08:25:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=CeCrELLG8Ys2I8ypV+WHLA6cza8vwx9pEi5zkwoPN+w=; b=xg81dAYx5TdNB+sNRHBsSi21bP/RPjyc4nTC1VGXkrG2IVHJo3LN0vWrz6F1NbUaq8 OQsWKdVIC0koOn9EKqEsBXDUMSm521ecrLF1MjtVdZa5oI173QghrQqCvoy98ZaDJqm+ +/Uy+4PLEuqdfjMR9v4iMRTvjDUpEZfwUGUbcxsoeM40ny34FxTu7JEwfmGLehxwr92g aQKH8DnSwZFrP4VF8M9n+VaKdpVBm2WmXfNkI18eYgHeCVGm9EfL2pDfhX4/fqaNYs/3 C3911QuomzBQzhYjGCU4G4ABtPFflHrzLIBU47eW1QReEPw4VQ2CmmVLmZZfMHs0lt/2 k23g==
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=CeCrELLG8Ys2I8ypV+WHLA6cza8vwx9pEi5zkwoPN+w=; b=fGTziAMroTWfraz+a0lu103oP0GJzi8JTiwdqoLMCxn2avXC+Tb2yYa73n14CtWz7k EsU665hj07QknInolO8tJCOwmHw1Ds68Xop5gEEbM3/OvRTvsYAxtTP3gxe7duLuKCtS gwVnN3v+g9HBtVlERvgesb9B7SSenNZ8r+e4cy4wKN2ZhG7vepsrrtdW5OxrNN7NQfpP VT6IpopAcBP1X+Go72jM/5kuCZISmLvIHR2kdThQ7vxiGo0aLpW0CfJDT6EycWvcELAH GJzXl3ndZeSN2oayV6egFN9fKOWPdYxZCFxRTiFhL79nKl5hEBAtucDbRsEW6lyOF7sY ouAA==
X-Gm-Message-State: APjAAAXePc6SPJBrghkYuDMlYNeaFnERB03AzPePLTnf8v1Q3aetEjz2 Igwv+yzu/Wv8r8q5rfeIogXerw==
X-Google-Smtp-Source: APXvYqydAgXinb5D6fGbHDCOgpL/IqBf1kUV4wyATWwO/lBLFFQwD4Gw+EAuMlby151b2q3/Hy54fw==
X-Received: by 2002:a7b:cfc9:: with SMTP id f9mr157673wmm.1.1579191916816; Thu, 16 Jan 2020 08:25:16 -0800 (PST)
Received: from [172.17.103.27] ([193.242.134.240]) by smtp.gmail.com with ESMTPSA id z187sm5623580wme.16.2020.01.16.08.25.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 08:25:15 -0800 (PST)
Content-Type: multipart/signed; boundary=Apple-Mail-34E1D282-015F-434F-A469-DBA3E35510D0; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jan 2020 17:25:13 +0100
Message-Id: <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu>
Cc: "Richard Backman, Annabelle" , "Richard Backman, Annabelle" , oauth , Nat Sakimura 
In-Reply-To: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu>
To: Justin Richer 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:25:24 -0000

--Apple-Mail-34E1D282-015F-434F-A469-DBA3E35510D0
Content-Type: multipart/alternative;
	boundary=Apple-Mail-9FAF64CB-D9A2-4359-8DEA-180C56D1E35D
Content-Transfer-Encoding: 7bit


--Apple-Mail-9FAF64CB-D9A2-4359-8DEA-180C56D1E35D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I just thought about another option. What if we change PAR to not use the re=
quest_uri parameter but a new parameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri was to mak=
e the life of clients easier since they can use the standard library functio=
n for request objects to pass the PAR reference to the AS. Is this worth the=
 trouble?

> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>=20
> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to come ba=
ck to go through another round anyway thanks to the breaking changes the IES=
G pushed into it after it left WGLC.
>=20
> I=E2=80=99d rather see us get this right than publish something many of us=
 think is broken.=20
>=20
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>=20
>  =E2=80=94 Justin
>=20
>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle  wrote:
>>=20
>> The problem is the JWT requirement in JAR, not how we talk about PAR requ=
est_uri values in PAR. We need to either change the language in JAR (see my s=
uggestions elsewhere in this thread), or add text in PAR that explicitly exe=
mpts PAR request_uri values (or preferably all AS-provided request_uri value=
s) from this requirement (also see my suggestions elsewhere in this thread).=

>> =20
>> My preference remains the former. It strikes me as bad form for one exten=
sion to override normative requirements laid out in another document. Grante=
d, the incompatibility scenarios introduced by this retcon are edge-case at b=
est, but that just raises the question of why we can=E2=80=99t fix the draft=
 that hasn=E2=80=99t actually been published yet.
>> =20
>> =E2=80=93=20
>> Annabelle Richard Backman
>> AWS Identity
>> =20
>> =20
>> From: OAuth  on behalf of Vladimir Dzhuvinov 
>> Organization: Connect2id Ltd.
>> Date: Wednesday, January 15, 2020 at 12:34 PM
>> To: Justin Richer 
>> Cc: oauth , Nat Sakimura , "Richard Bac=
kman, Annabelle" 
>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must=
 become JWTs
>> =20
>> On 13/01/2020 19:32, Justin Richer wrote:
>>> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=
=9D or something of that nature. But if we call the result of PAR =E2=80=9Ct=
hing X=E2=80=9D and the target of request_uri =E2=80=9Cthing X=E2=80=9D in J=
AR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing X=E2=80=
=9D needs to be in all cases.=20
>> Good, we're on the same page then.
>> How about simply saying that the result of PAR is an URI referencing the p=
ushed authZ request; at the authZ endpoint its processing is completed.
>> No need is both clear and abstract enough to not require a form to be spe=
cified.
>> =20
>>> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted as a JWT.
>> But why?
>> Both PAR and authZ endpoints belong to the AS, which makes that impl spec=
ific. The URI is the contract, between client and AS.
>> The AS, if uService based, could choose to implement that as CBOR Web Tok=
en, or some other verifiable blob, resulting in the same essential function,=
 and this isn't affecting the client <-> AS contract in any way.
>> =20
>>> We had a case of similarly unintentional limiting in JAR previously, say=
ing that you had to do an HTTP lookup on the request_uri, but I believe that=
=E2=80=99s been backed off now and made conditional.
>> That was precisely my point.
>> Vladimir
>> =20
>> =20
>>>  =E2=80=94 Justin
>>>=20
>>>=20
>>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov  wrote:
>>>> =20
>>>> My suggestion is to abstain from specifying the concrete form of the re=
source pointed to by the PAR URI. Regardless of URI type (URN, downloadable h=
ttps URL or something else), and even if the PAR endpoint and the authZ endp=
oint are managed by two different entities (microservice or other scenario).=

>>>> In the Connect2id implementation of PAR the returned URI doesn't point t=
o a request object and it doesn't point to a JWT either. It points to an int=
ernally stored "pre-processed" authZ request, which the authZ endpoint then p=
icks up to complete the authZ.
>>>> Even if we eventually end up in microservice world, or allow the PAR en=
dpoint to be managed by some external entity, the PAR URI - its interpretati=
on, validation and potentially resource retrieval (JWT or other blob), is an=
 "internal contract" on the AS side. This doesn't concern the client, and in=
 OAuth 2.0 the role of AS is indivisible.
>>>> =20
>>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ reques=
t: the client submits an authZ request and gets an authZ response at the end=
. The URI is necessary for the client to proceed from the 1st to the 2nd ste=
p. If we manage to frame / word the PAR URI in this logical way, without get=
ting stuck in the JAR definition / framing of what the request_uri / object i=
s, it would be great.
>>>> =20
>>>> The normative language I think should focus on maintaining the OAuth 2.=
0 contract for the entire logical authZ request, together with the basic con=
tracts of 1) JAR and the 2) authZ endpoint.
>>>> =20
>>>> Vladimir
>>>> =20
>>>> On 10/01/2020 22:55, Justin Richer wrote:
>>>>> So we could solve this by saying the resulting data object of a PAR is=
 a request object. Which might also contain a request object internally as w=
ell. In that case JAR should back off from saying it=E2=80=99s a JWT and ins=
tead say it=E2=80=99s a request object. Or we define a new term for this aut=
horization request blob thing.=20
>>>>> =20
>>>>> Or PAR could at least say that if it=E2=80=99s dereferenced over a rem=
ote protocol then it MUST be a JWT, but otherwise it can be whatever you wan=
t. That=E2=80=99s where the real interop concerns come in.
>>>>> =20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>>=20
>>>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle  wrote:
>>>>>> =20
>>>>>> Correct. The problem becomes pretty clear in the context of PAR, wher=
e the AS is generating and vending out the URI at the PAR endpoint, and cons=
uming it at the authorization endpoint. =46rom an interoperability standpoin=
t, it=E2=80=99s analogous to the AS vending an authorization code at the aut=
horization endpoint and consuming it at the token endpoint.
>>>>>> =E2=80=93=20
>>>>>> Annabelle Richard Backman
>>>>>> AWS Identity
>>>>>> =20
>>>>>> =20
>>>>>> From: John Bradley 
>>>>>> Date: Friday, January 10, 2020 at 12:29 PM
>>>>>> To: Brian Campbell 
>>>>>> Cc: Torsten Lodderstedt , Nat Sakimura , "Richard Backman, Annabelle" , oauth 
>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must=
 become JWTs
>>>>>> =20
>>>>>> If we assume the client posts a JAR and gets back a reference.  Then t=
he reference is to a JAR.=20
>>>>>> =20
>>>>>> I think I see the problem.  If the server providing the reference is a=
ssociated with the AS then the server dosen't need to dereference the object=
 via HTTP, so it could be a URN as an example.=20
>>>>>> =20
>>>>>> So yes it is not a interoperability issue for the client. =20
>>>>>> =20
>>>>>> I will think about how I can finesse that.=20
>>>>>> =20
>>>>>> I agree it is not a change in intent.=20
>>>>>> =20
>>>>>> I will see if I can get our AD to accept that.
>>>>>> =20
>>>>>> John B.=20
>>>>>> =20
>>>>>> =20
>>>>>> =20
>>>>>> =20
>>>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell  wrote:
>>>>>>> Sure but the text proposed (or something like it) qualifies it such t=
hat there aren't interoperability questions because it's only an implementat=
ion detail to the AS who both produces the URI and consumes its content.
>>>>>>> =20
>>>>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  w=
rote:
>>>>>>>> It may be a challenge to change text saying that the contents of th=
e resource could be something other than a request object.=20
>>>>>>>> =20
>>>>>>>> If not a request object then what and how is that interoperable are=
 likely AD questions.=20
>>>>>>>> =20
>>>>>>>> I could perhaps see changing it to must be a request object, or oth=
er format defined by a profile.
>>>>>>>>=20
>>>>>>>> John B. =20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell  wrote:
>>>>>>>>> Agree and agree. But given that the change suggested by Annabelle h=
as no impact on the client or interoperability, perhaps Nat or John could wo=
rk the change into the draft during the edits that happen during the final s=
tages of things?
>>>>>>>>> =20
>>>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  wrote:
>>>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t want to c=
hange it. And as I said, this difference does not impact interoperability fr=
om client perspective.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle :
>>>>>>>>>>>>=20
>>>>>>>>>>> It would be more appropriate to add the text to JAR rather than P=
AR. It doesn't seem right for PAR to retcon rules in JAR. Moving the text to=
 JAR also highlights the weirdness of giving PAR special treatment.
>>>>>>>>>>> =20
>>>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>>> The contents of the resource referenced by the URI MUST be a Req=
uest
>>>>>>>>>>> Object.
>>>>>>>>>>> =20
>>>>>>>>>>> To:=20
>>>>>>>>>>> The contents of the resource referenced by the URI MUST be a Req=
uest
>>>>>>>>>>> Object, unless the URI was provided to the client by the Authori=
zation
>>>>>>>>>>> Server.
>>>>>>>>>>> =20
>>>>>>>>>>> This would allow for use cases such as an AS that provides pre-d=
efined request URIs, or vends request URIs via a client management console, o=
r bakes them into their client apps.
>>>>>>>>>>> =20
>>>>>>>>>>> =E2=80=93=20
>>>>>>>>>>> Annabelle Richard Backman
>>>>>>>>>>> AWS Identity
>>>>>>>>>>> =20
>>>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  wrote:
>>>>>>>>>>> =20
>>>>>>>>>>>     Hi,=20
>>>>>>>>>>>    =20
>>>>>>>>>>>     you are right, PAR does not require the AS to represent the r=
equest as a JWT-based request object. The URI is used as internal reference o=
nly. That why the draft states
>>>>>>>>>>>    =20
>>>>>>>>>>>     "There is no need to make the
>>>>>>>>>>>           authorization request data available to other parties v=
ia this
>>>>>>>>>>>           URI.=E2=80=9D
>>>>>>>>>>>    =20
>>>>>>>>>>>     This difference matters from an AS implementation perspectiv=
e, it doesn't matter from a client's (interop) perspective.
>>>>>>>>>>>    =20
>>>>>>>>>>>     We may add a statement to PAR saying that request_uris issue=
d by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>>>>    =20
>>>>>>>>>>>     best regards,
>>>>>>>>>>>     Torsten. =20
>>>>>>>>>>>    =20
>>>>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  wrote:
>>>>>>>>>>>     >=20
>>>>>>>>>>>     > Hi all,
>>>>>>>>>>>     > =20
>>>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require that=
 the AS transform all pushed requests into JWTs. This requirement arises fro=
m the following:
>>>>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter defin=
ed in JAR to communicate the pushed request to the authorization endpoint.
>>>>>>>>>>>     >         =E2=80=A2 According to JAR, the resource reference=
d by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a JWT co=
ntaining all the authorization request parameters. (Section 2.1)
>>>>>>>>>>>     > =20
>>>>>>>>>>>     > There is no need for this requirement to support interoper=
ability, as this is internal to the AS. It is also inconsistent with the res=
t of JAR, which avoids attempting to define the internal communications betw=
een the two AS endpoints. Worse, this restriction makes it harder for the au=
thorization endpoint to leverage validation and other work performed at the P=
AR endpoint, as the state or outcome of that work must be forced into the JW=
T format (or retrieved via a subsequent service call or database lookup).
>>>>>>>>>>>     > =20
>>>>>>>>>>>     > =E2=80=93=20
>>>>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>>>>     > AWS Identity
>>>>>>>>>>>     > =20
>>>>>>>>>>>     > _______________________________________________
>>>>>>>>>>>     > OAuth mailing list
>>>>>>>>>>>     > OAuth@ietf.org
>>>>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>    =20
>>>>>>>>>>>    =20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr=
ivileged material for the sole use of the intended recipient(s). Any review,=
 use, distribution or disclosure by others is strictly prohibited.  If you h=
ave received this communication in error, please notify the sender immediate=
ly by e-mail and delete the message and any file attachments from your compu=
ter. Thank you.
>>>>>>>=20
>>>>>>>=20
>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and priv=
ileged material for the sole use of the intended recipient(s). Any review, u=
se, distribution or disclosure by others is strictly prohibited..  If you ha=
ve received this communication in error, please notify the sender immediatel=
y by e-mail and delete the message and any file attachments from your comput=
er. Thank you.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>=20
>>> =20
>> --=20
>> Vladimir Dzhuvinov
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-9FAF64CB-D9A2-4359-8DEA-180C56D1E35D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I just thought about anoth=
er option. What if we change PAR to not use the request_uri parameter but a n=
ew parameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri was to=
 make the life of clients easier since they can use the standard library fun=
ction for request objects to pass the PAR reference to the AS. Is this worth=
 the trouble?

Am 16.01.2=
020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BF+1 to this approa=
ch, and it sounds like JAR might need to come back to go through another rou=
nd anyway thanks to the breaking changes the IESG pushed into it after it le=
ft WGLC.

I=E2=80=99d rat=
her see us get this right than publish something many of us think is broken.=
 

Maybe PAR a=
nd JAR (and JARM?) end up going out as a bundle of specs.

 =E2=80=94 Justin

On=
 Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

The pr=
oblem is the JWT requirement in JAR, not how we talk about PAR request_uri v=
alues in PAR. We need to either change the language in JAR (see my suggestio=
ns elsewhere in this thread), or add text in PAR that explicitly exempts PAR=
 request_uri values (or preferably all AS-provided request_uri values) from t=
his requirement (also see my suggestions elsewhere in this thread).
 
My preference remains the former. It strikes m=
e as bad form for one extension to override normative requirements laid out i=
n another document. Granted, the incompatibility scenarios introduced by thi=
s retcon are edge-case at best, but that just raises the question of why we c=
an=E2=80=99t fix the draft that hasn=E2=80=99t actually been published yet.<=
o:p class=3D"">
 =

=E2=80=93 
Annabelle=
 Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounc=
es@ietf.org> on behalf of Vladimir Dzhuvinov <vladimir@connect2id.com>
Organi=
zation: Connect2id Ltd=
.
Date:&nb=
sp;Wednesday, January 15, 2020 at 12:34 PM
To: Justin Riche=
r <jricher@mit.edu><=
br class=3D"">Cc: <=
/span>oauth <oauth@ietf.=
org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com=
@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re=
: PAR: pushed requests must become JWTs
 <=
/div>
On 13/01/2020 19:32, J=
ustin Richer wrote:
To be clear, I=E2=80=99m not saying we suggest a particular form=
, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a=
 JWT=E2=80=9D or something of that nature. But if we call the result of PAR =E2=
=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing X=E2=80=9D=
 in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing X=E2=
=80=9D needs to be in all cases. =

Good, we're o=
n the same page then.
How about s=
imply saying that the result of PAR is an URI referencing the pushed authZ r=
equest; at the authZ endpoint its processing is completed.
No need is both clear and abstract enough to not r=
equire a form to be specified.
 
In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=
=9D to be formatted as a JWT.
=

But why?
Both PAR=
 and authZ endpoints belong to the AS, which makes that impl specific. The U=
RI is the contract, between client and AS.
The AS, if uService based, could choose to implement that as CBOR W=
eb Token, or some other verifiable blob, resulting in the same essential fun=
ction, and this isn't affecting the client <-> AS contract in any way.=

 
We had a case of simila=
rly unintentional limiting in JAR previously, saying that you had to do an H=
TTP lookup on the request_uri, but I believe that=E2=80=99s been backed off n=
ow and made conditional.
That was precisely my point.
Vladimir
&n=
bsp;
 
 =E2=80=94 Justin

On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:<=
/o:p>
 
My suggestion i=
s to abstain from specifying the concrete form of the resource pointed to by=
 the PAR URI. Regardless of URI type (URN, downloadable https URL or somethi=
ng else), and even if the PAR endpoint and the authZ endpoint are managed by=
 two different entities (microservice or other scenario).
In the Connect2id implementation of PAR t=
he returned URI doesn't point to a request object and it doesn't point to a J=
WT either. It points to an internally stored "pre-processed" authZ request, w=
hich the authZ endpoint then picks up to complete the authZ.=

Even if we eventually end up in micro=
service world, or allow the PAR endpoint to be managed by some external enti=
ty, the PAR URI - its interpretation, validation and potentially resource re=
trieval (JWT or other blob), is an "internal contract" on the AS side. This d=
oesn't concern the client, and in OAuth 2.0 the role of AS is indivisible.
 <=
/o:p>
I see PAR request + authZ request as o=
ne logical OAuth 2.0 authZ request: the client submits an authZ request and g=
ets an authZ response at the end. The URI is necessary for the client to pro=
ceed from the 1st to the 2nd step. If we manage to frame / word the PAR URI i=
n this logical way, without getting stuck in the JAR definition / framing of=
 what the request_uri / object is, it would be great.<=
/div>
 
The normative language I think should focus on maintaining t=
he OAuth 2.0 contract for the entire logical authZ request, together with th=
e basic contracts of 1) JAR and the 2) authZ endpoint.=

 
Vladimir
 
On 10/01/2020 22:55, Justin Richer wrote:
So we could solve this by saying the re=
sulting data object of a PAR is a request object. Which might also contain a=
 request object internally as well. In that case JAR should back off from sa=
ying it=E2=80=99s a JWT and instead say it=E2=80=99s a request object. Or we=
 define a new term for this authorization request blob thing. 
 
Or PAR could at least say that if it=E2=
=80=99s dereferenced over a remote protocol then it MUST be a JWT, but other=
wise it can be whatever you want. That=E2=80=99s where the real interop conc=
erns come in.
 
 =E2=80=94 Justin


On Jan=
 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote=
:
 
Correct. The problem becomes pretty clear in the context of PAR, where th=
e AS is generating and vending out the URI at the PAR endpoint, and consumin=
g it at the authorization endpoint. =46rom an interoperability standpoint, i=
t=E2=80=99s analogous to the AS vending an authorization code at the authori=
zation endpoint and consuming it at the token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Jo=
hn Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, 2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten L=
odderstedt <torsten@lodderstedt.net>=
;, Nat Sakimura <nat@sakimura.org>, "Richa=
rd Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
=
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs
=

 
If w=
e assume the client posts a JAR and gets back a reference.  Then the re=
ference is to a JAR. 
 
I think I see the problem.  If the server providing the reference is a=
ssociated with the AS then the server dosen't need to dereference the object=
 via HTTP, so it could be a URN as an example. 
&=
nbsp;
So yes it is not a interoperability issue for th=
e client.  
 
I wi=
ll think about how I can finesse that. 
 
I agree it is not a change in intent. 
 
I will see if I can get our AD to acc=
ept that.
 
=

John B. 
 
 
&n=
bsp;
 
On Fri, Jan 10, 2020=
, 4:57 PM Brian Campbell <bcampbell@pingidentity.com> wrote:=

Sure b=
ut the text proposed (or something like it) qualifies it such that there are=
n't interoperability questions because it's only an implementation detail to=
 the AS who both produces the URI and consumes its content.<=
/o:p>
 
On Fri, Jan 10, 2020 at 12:48 PM John Bradley &=
lt;ve7jtb@ve7jtb.com> wrote:
It may be a cha=
llenge to change text saying that the contents of the resource could be some=
thing other than a request object. 
 
If not a request object then what and how is that interoperabl=
e are likely AD questions. 
 
I could perhaps see changing it to must be a request object, or othe=
r format defined by a profile.

John B. &nb=
sp;
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri=
, sans-serif;" class=3D""> 
 
On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree and a=
gree. But given that the change suggested by Annabelle has no impact on the c=
lient or interoperability, perhaps Nat or John could work the change into th=
e draft during the edits that happen during the final stages of things?
=
 
On Thu, Jan 9, 2020 at 1:56 AM Torste=
n Lodderstedt <torsten=3D40lodderstedt.net@dmarc.=
ietf.org> wrote:
I would assume given the status of JA=
R, we don=E2=80=99t want to change it. And as I said, this difference does n=
ot impact interoperability from client perspective.


Am 09.01.2020 um 00:58 schrieb Richard B=
ackman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.=
org>:
It would be more=
 appropriate to add the text to JAR rather than PAR. It doesn't seem right f=
or PAR to retcon rules in JAR. Moving the text to JAR also highlights the we=
irdness of giving PAR special treatment.
<=
/div>
 
What if we changed this sentence=
 in Section 5.2 of JAR:
The contents of the resource referenced by the URI M=
UST be a Request
Object.
 
To: 
The conte=
nts of the resource referenced by the URI MUST be a Request
Object, unless the URI=
 was provided to the client by the Authorization<=
/div>
Server.
 <=
/div>
This would allow for use cases s=
uch as an AS that provides pre-defined request URIs, or vends request URIs v=
ia a client management console, or bakes them into their client apps.
=
 
=E2=80=
=93 =

Annabelle Richard Backm=
an
AWS Identity
 
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri=
, sans-serif;" class=3D"">On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 =

&=
nbsp;   Hi, 
 =
   
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri=
, sans-serif;" class=3D"">    you are right, PAR does not require=
 the AS to represent the request as a JWT-based request object. The URI is u=
sed as internal reference only. That why the draft states
   &n=
bsp;
    "There is no need to make the
    =
;      authorization request data available to othe=
r parties via this
<=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri=
, sans-serif;" class=3D"">          URI.=
=E2=80=9D
    
=
    This difference matters from an AS implementation pe=
rspective, it doesn't matter from a client's (interop) perspective.
<=
span style=3D"font-size: 9pt; font-family: Helvetica;" class=3D""> &nbs=
p;  <=
/o:p>
   =
 We may add a statement to PAR saying that request_uris issued by the P=
AR mechanism (MAY) deviate from the JAR definition.
    
&nb=
sp;   best regards,
<=
div class=3D"">
    Torsten.  
=

    
  &n=
bsp; > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <rich=
anna=3D40amazon.com@dmarc.ietf.org> wrote:<=
o:p class=3D"">
&n=
bsp;   > 
 =
   > Hi all,
    >  
    > The current draf=
ts of PAR (-00) and JAR (-20) require that the AS transform all pushed reque=
sts into JWTs. This requirement arises from the following:
    &=
gt;         =E2=80=A2 PAR uses the reques=
t_uri parameter defined in JAR to communicate the pushed request to the auth=
orization endpoint.
=

    >      &nbs=
p;  =E2=80=A2 According to JAR, the resource referenced by request_uri M=
UST be a Request Object. (Section 5.2)
    >    =
;     =E2=80=A2 Request Object is defined to be a JWT co=
ntaining all the authorization request parameters. (Section 2.1)
  &n=
bsp; >  
  =
;  > There is no need for this requirement to support interoper=
ability, as this is internal to the AS. It is also inconsistent with the res=
t of JAR, which avoids attempting to define the internal communications betw=
een the two AS endpoints. Worse, this restriction makes it harder for the au=
thorization endpoint to leverage validation and other work performed at the P=
AR endpoint, as the state or outcome of that work must be forced into the JW=
T format (or retrieved via a subsequent service call or database lookup).
 =
   >  
&nb=
sp;   > =E2=80=93&nb=
sp;
    > Annabelle Richard Backman
  &n=
bsp; > AWS Identity
    >  
    > _________________________=
______________________
    > OAuth mailing list
  &n=
bsp; > OAuth@ietf=
.org
    >&=
nbsp;https://www.ietf.org/mailman/listinfo=
/oauth
   &nbs=
p;
    
_____=
__________________________________________
OAuth mailing list<=
br class=3D"">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


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

 
=


_______________________________________________=

OAuth mailing list
OAuth@ietf=
.org
https://www.ietf.org/mailman/listinfo/oaut=
h
=
-- 
Vladimir Dzhuv=
inov
 
-- 
Vladimir Dzhuvinov

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

--Apple-Mail-9FAF64CB-D9A2-4359-8DEA-180C56D1E35D--

--Apple-Mail-34E1D282-015F-434F-A469-DBA3E35510D0
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0
aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTE2MTYyNTE0WjAv
BgkqhkiG9w0BCQQxIgQg2SDkJWF4glOPztJdqM9Nw+3mkxpk5f+q8G9DtGW7xj4wgb0GCSsGAQQB
gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ
MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0
aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH
21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv
IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQBbOiqr
T4sF23MvxFRAii3KdAqePdIADXWkpkbC+bKbIzPvmSBccfnjDm/oAtccvmhNQt8ceofTF5vR8AUc
la8Y5KOmVUPYHvPOmaDOojcy5DSPLheX6rkHGjhKSvzpe7SdiRaIZbQ3GwlAn9CpzR7a5qPbzUA+
CXS8x1W3nw7Lej9MB/QtEKHTEGtIcKlG8ZE6GeIR0uMxugLcK3eK5I2tpdX/5u44u9EQSmiABOau
OTsAsW1Ggh7xVSXqVnevdSCtzOD2BtzjYC6RhdBxbnphNmzckN19f7jWIycTkJFFNKfYWaFOley8
yGTIQ9n9MU3UH7hAe5fAbO9ItXLKrR3kAAAAAAAA
--Apple-Mail-34E1D282-015F-434F-A469-DBA3E35510D0--


From nobody Thu Jan 16 08:28: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 D30D3120A79 for ; Thu, 16 Jan 2020 08:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 kdTbaXxbErTU for ; Thu, 16 Jan 2020 08:28:18 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7B81209C6 for ; Thu, 16 Jan 2020 08:28:18 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id j42so19760228wrj.12 for ; Thu, 16 Jan 2020 08:28:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=FzdN/LoWGARNElPMehLpeMMHbu9i1N4d7Gy5LN5VYEc=; b=KUt7PvB77/kuVUd/L+imEv5TqKlyP9ChpvwYTP/FSQrezvNDflXb/61HJTMhz9jDLF eNGm+kIPOKMIrG//gG8LYSamXyWzkyDZL72Dbfn916gUk9srcKkwmMQVM/HyS0haXsRp XOk2KGchRHRge+IbFmt4N3l64hsT5f2vu8g7PJQOHIDnZelVj6q1aOlng0KAUvdw160Y wZF/sRuYh7aCnybjiy1BRS0nj8Sm8lwI2k2srtJSBdG/u4W4WlPEyW1S//23mJef0y/i UIJ4FCj/Aqp/zQQB0So2DGPgJ/XvXdrNws4lQmr8dg3T4iU0Hj8pY5saQLFhg7Gk9Wb9 qrSg==
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=FzdN/LoWGARNElPMehLpeMMHbu9i1N4d7Gy5LN5VYEc=; b=k0xh8ezAu4b+ip44LKuP/Rx2jBn+05mv3sSB0B3+7R8g0+AsXy+Y4CLRVzZ0lM9lNV pEa+3VKI4HIrzwnp9ql0/SX2Jl02vel+3OAaQLf94AdCKAt2Lm5IqYxIoBronyAQuPmT RXNUOrtw2ES20IdnlEW0Ln4d4Aka4iXAQyP9LFVtcFx2JGb6V3GqzeYRDMZPG7VZfNaw Q9ey+v6rW4HDAZOFqMdot0dbpOPMJO0Yl/JNfGK36WzzkD6fjHwx5bk3Zg+0nn8QaZEf aAY9N7TQOQtbNRojWc4d6LP6B14IlO9rPYlGNiJDGA0JqMNv5Apw545uZuJDvbHv30a4 joGA==
X-Gm-Message-State: APjAAAU9B3wqmqV83N10qybq3K3mPy6Si0braPYKwtB9oFnlVFlDxcdh qAut86Q710eoMGQbSl0z+UGkpA==
X-Google-Smtp-Source: APXvYqwpzHIXYopnX7FsI7GMBRNmLn9Z/UOKIdVZcqU7XJPcKqPtid5bjbobGexm4m0ZuK7qXRm7Qg==
X-Received: by 2002:adf:ebd0:: with SMTP id v16mr4275009wrn.146.1579192096774;  Thu, 16 Jan 2020 08:28:16 -0800 (PST)
Received: from [172.17.103.27] ([193.242.134.240]) by smtp.gmail.com with ESMTPSA id e6sm31337872wru.44.2020.01.16.08.28.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 08:28:15 -0800 (PST)
Content-Type: multipart/signed; boundary=Apple-Mail-9E3D98D6-077E-43BD-96FF-51D6847842C2; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jan 2020 17:28:14 +0100
Message-Id: <40E68FE9-BEA6-4F44-8401-BD30E6F7C927@lodderstedt.net>
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu>
Cc: "Richard Backman, Annabelle" , "Richard Backman, Annabelle" , oauth , Nat Sakimura 
In-Reply-To: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu>
To: Justin Richer 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] JARM
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:28:23 -0000

--Apple-Mail-9E3D98D6-077E-43BD-96FF-51D6847842C2
Content-Type: multipart/alternative;
	boundary=Apple-Mail-A413F743-FE81-4F89-87D3-F35D0C66011D
Content-Transfer-Encoding: 7bit


--Apple-Mail-A413F743-FE81-4F89-87D3-F35D0C66011D
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>=20
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would like to know whether the community has a=
ppetite to standardize JARM as well.

Here is the link to the spec: https://openid.net/specs/openid-financial-api-=
jarm-ID1.html

What do you think?=

--Apple-Mail-A413F743-FE81-4F89-87D3-F35D0C66011D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit




Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would like to know whether the community has appetite to standardize JARM as well.


What do you think?

--Apple-Mail-A413F743-FE81-4F89-87D3-F35D0C66011D--

--Apple-Mail-9E3D98D6-077E-43BD-96FF-51D6847842C2
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBTYw
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDGCA8cwggPDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0
aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAesw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTE2MTYyODE0WjAv
BgkqhkiG9w0BCQQxIgQgTR1yhELPsEPs5AnkZvEoPe7nUlnjU6SLzQpj8/Cfu90wgb0GCSsGAQQB
gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ
MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0
aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH
21UuPcbaTCkHebYwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv
IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQEFAASCAQDHNldI
zheeDDJ2MYYg+bLkN6ZfQeu6xGIyyMhldUkPIlFC/NjxoxjVlJOHh129bi2sZWm72cNYnhl3UVru
NwTE+dq7Rq3rdCGea32clXLsFakuV8Ax1ajAXB39UzIb+KpGj5jj9yDkF3m576SDPkY86QF3QRRy
ZwUOWVhwH56P3gTy2dB+y4kd5bp2mxGFG2vMJgaNFlcV3zUqblSn1FBtaaFGmWdZm7M9wWKmQ48x
qyx2JeNF8gu58ZasW0rSjK0MNRz7pblxSExLEWsbF/VuWbXl4Pp+h6LjztOEwZpet89CQhyuzh3U
f97d0ueHWZxNsO2vOJ2TgklxeF/kesGxAAAAAAAA
--Apple-Mail-9E3D98D6-077E-43BD-96FF-51D6847842C2--


From nobody Thu Jan 16 08:31: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 944A6120A89 for ; Thu, 16 Jan 2020 08:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WZzgv75-4ysx for ; Thu, 16 Jan 2020 08:31:34 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E931120A81 for ; Thu, 16 Jan 2020 08:31:34 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id q10so19804895wrm.11 for ; Thu, 16 Jan 2020 08:31:34 -0800 (PST)
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=u5SxiWPIHJ14v1Wk/1tL9d+0qDsuJNU3cjn2Frjw3Ts=; b=CHcKYFDhKVDvtLmAN1+SjxQ2lkFmVfdSfknaBRnul7kZqyAFGLaCoy6ziq5ylsVfmA wXBt5xxlLWuNmICJvnKHy9RVvkRzFYQ3Z/P3AfIDIxOnGpQfBJJSb5xAIrJad4LmNB3X O2ZwmIPQInhGYTFVAk60HLoqk6IK1YXMOf7Ek=
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=u5SxiWPIHJ14v1Wk/1tL9d+0qDsuJNU3cjn2Frjw3Ts=; b=cIjZRmkRiQceeePUGgl2+/YylGXlKUMvLKpJ2Q6jE4zhGt1CzRaVNs1Oivs3N4sqPo PsrtZ5DeMuwBLlGZnYjkTmyPT4NK+QurKcSpRdbWukSQVmiYMTBL1sC7ppZglvOqj3wm goNY2YBvD+nZ1SHsMe5HA0coFI+CCA+QLZCqNDsy2AAhK/ynhr8/W70UbOwI81mvZ9Kg C4NRPMaE6qJu/GZ/WO90YQSYia0V3kkTTC+T6PgQnq96d/rbB+xbCJvefkJEdbSiwbij cJH+B/bLpSrwNuetHG+IgISatMW2GVTaKUokqC9shAQrzXkc8Jc7TeRm8ZR4COpd/Mlt sPZg==
X-Gm-Message-State: APjAAAWFGVcc3SYnzbVRdeovS9PcYzoj5bcj7jD5cX1oAUgGqesdtZFG NbStbNikb0emMdv5+iHG2qT8BA==
X-Google-Smtp-Source: APXvYqwNt/Po7VXHSvO0HwngsoxP7VvrkAIpAWOiOkZ8v1xvTmHATUKdwQ0bL1zWgBIJveZj0/eZ2w==
X-Received: by 2002:adf:ee52:: with SMTP id w18mr425988wro.415.1579192292495;  Thu, 16 Jan 2020 08:31:32 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id h8sm31261466wrx.63.2020.01.16.08.31.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 08:31:31 -0800 (PST)
From: Neil Madden 
Message-Id: <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_97418524-0F27-4112-A8BB-72E2CF051C10"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 16 Jan 2020 16:31:30 +0000
In-Reply-To: 
Cc: Benjamin Kaduk , IETF oauth WG 
To: Nat Sakimura 
References:   <20200116143233.GJ80030@kduck.mit.edu> 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 16:31:39 -0000

--Apple-Mail=_97418524-0F27-4112-A8BB-72E2CF051C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The mitigations of 10.4.1 are related, but the section heading is about =
(D)DoS attacks. I think this heading needs to be reworded to apply to =
SSRF attacks too or else add another section with similar mitigations.=20=


Mitigation (a) is a bit vague as to what an "unexpected location" is. =
Perhaps specific wording that it should be a URI that has been =
pre-registered for the client (and validated at that time) or is =
otherwise known to be safe (e.g., is a URI scheme controlled by the AS =
itself as with PAR).

In addition for this to be effective the AS should not follow redirects =
when fetching the URI. It's not clear to me whether that is implied by =
"not perform recursive GET" so it may be worth explicitly spelling that =
out.

-- Neil


> On 16 Jan 2020, at 15:47, Nat Sakimura  wrote:
>=20
> Right. We could add a security consideration like that, though the =
mitigation probably is pretty much the same as what is stated in 10.4.1:=20=

> the server should (a) check that
>    the value of "request_uri" parameter does not point to an =
unexpected
>    location, (b) check the content type of the response is =
"application/
>    oauth.authz.req+jwt" (c) implement a time-out for obtaining the
>    content of "request_uri", and (d) not perform recursive GET on the
>    "request_uri".
> If not, please let me know so that we can add that as the mitigation =
as well.=20
>=20
> Existing OIDC deployment cannot make use of =
application/oauth.authz.req+jwt but it has to validate that content is a =
valid request object anyways and if it is malformed, it MUST stop the =
processing and return an error invalid_request_uri. So, unlike in the =
case of Capital One's SSRF, the content of the request_uri will not be =
exposed. The main downside is therefore as depicted in the current =
draft, consumption of the network and processing power of the AS, and =
the unwanted access load to the servers serving the URL pointed by =
request_uri. The above-quoted mitigations were introduced to address =
these issues.=20
>=20
>=20
>=20
>=20
> On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk > wrote:
> It is not too late to add to the security considerations.
>=20
> It seems that the new application/oauth.authz.req+jwt media-type is =
helpful
> in this regard, in that if an AS can require that content-type from
> dereferencing the request_uri, then seeing anything else indicates =
that the
> request was bogus (or an attack).  I guess existing OIDC deployments =
aren't
> exactly in a position to do that, though.
>=20
> -Ben
>=20
> On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:
> > Is it too late to add it to the security considerations for JAR?=20
> >=20
> > =E2=80=94 Neil
> >=20
> > > On 16 Jan 2020, at 08:15, Dominick Baier =
> wrote:
> > >=20
> > > =EF=BB=BF
> > > Agreed - that=E2=80=99s why we disabled request_uri by default and =
added extensibility points to implement validation.
> > >=20
> > > I thought it is odd that this was not mentioned in the typical =
=E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..
> > >=20
> > > =E2=80=94=E2=80=94=E2=80=94
> > > Dominick Baier
> > >=20
> > >> On 16. January 2020 at 08:07:44, Neil Madden =
(neil.madden@forgerock.com ) wrote:
> > >>=20
> > >> If the AS can=E2=80=99t validate the request_uri it may also open =
itself up to SSRF attacks where a malicious client uses the request_uri =
to probe/attack resources inside the AS=E2=80=99s private network. This =
was a crucial part of the recent Capital One breach for example [1].  =
ForgeRock currently requires strict validation of request_uris against a =
client-specific whitelist for exactly this reason.=20
> > >>=20
> > >> NB some clients might legitimately be on that private network (eg =
microservices) so changing to a global whitelist for all clients is =
undesirable.=20
> > >>=20
> > >> [1]: https://ejj.io/blog/capital-one =

> > >>=20
> > >> =E2=80=94 Neil
> > >>=20
> > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov =
> wrote:
> > >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > >>>> Well, embedding a client_id claim in the JWE header in order to =
achieve "request parameters outside the request object should not be =
referred to" is like "putting the cart before the horse". Why do we have =
to avoid using the traditional client_id request parameter so =
stubbornly?
> > >>>>=20
> > >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as =
follows.
> > >>>>=20
> > >>>> A client MAY use the "client_id" request parameter to identify =
itself when sending requests to the token endpoint.  In the =
"authorization_code" "grant_type" request to the token endpoint, an =
unauthenticated client MUST send its "client_id" to prevent itself from =
inadvertently accepting a code intended for a client with a different =
"client_id".  This protects the client from substitution of the =
authentication code.  (It provides no additional security for the =
protected resource.)
> > >>>>=20
> > >>>> If the same reasoning applies, a client_id must always be sent =
with request / request_uri because client authentication is not =
performed at the authorization endpoint. In other words, an =
unauthenticated client (every client is unauthenticated at the =
authorization endpoint) MUST send its "client_id" to prevent itself from =
inadvertently accepting a request object for a client with a different =
"client_id".
> > >>>>=20
> > >>> Identifying the client in JAR request_uri requests can be really =
useful so that an AS which requires request_uri registration to prevent =
DDoS attacks and other checks can do those without having to index all =
request_uris individually. I mentioned this before.
> > >>>=20
> > >>> I really wonder what the reasoning of the IESG reviewers was to =
insist on no params outside the JAR JWT / request_uri.
> > >>>=20
> > >>> I'm beginning to realise this step of the review process isn't =
particularly transparent to WG members.
> > >>>=20
> > >>> Vladimir
> > >>>=20
> > >>>=20
> > >>>=20
> > >>>> Best Regards,
> > >>>> Taka
> > >>>>=20
> > >>>>=20
> > >>>>=20
> > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov =
> wrote:
> > >>>>> John, thanks, much appreciated!
> > >>>>>=20
> > >>>>>> On 11/01/2020 21:36, John Bradley wrote:
> > >>>>>> Yes JAR is not prohibiting paramater replication in the =
header.=20
> > >>>>>>=20
> > >>>>>> I will see if i can add something in final edits to call that =
out.
> > >>>>>>=20
> > >>>>>> John B.
> > >>>>>>=20
> > >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this =
parameter replication be used for client_id or the client_id ass "iss" =
even though it isn't explicitly mentioned in the JAR spec?
> > >>>>>>>=20
> > >>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
> > >>>>>>>> Right we just don't say to put the iss there in OIDC if =
it's symetricly encrypted.
> > >>>>>>> OIDC doesn't have the symmetric key selection issue, I =
suppose that why the possibility to replicate params to the JWE header =
isn't mentioned at all. OIDC requires the top-level query params to =
represent a valid OAuth 2.0 request, and there client_id is required. If =
the client_id is present the client registration together with any =
present client_secret can be retrieved.
> > >>>>>>>=20
> > >>>>>>> I reread the JAR spec, this is the only place that mentions =
handling of symmetric JWE.
> > >>>>>>>=20
> > >>>>>>> =
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 =

> > >>>>>>>=20
> > >>>>>>>> (b)  Verifying that the symmetric key for the JWE =
encryption is the
> > >>>>>>>>         correct one if the JWE is using symmetric =
encryption.
> > >>>>>>>=20
> > >>>>>>> Vladimir
> > >>>>>>>=20
> > >>>>>>>=20
> > >>>>>>>=20
> > >>>>>>>>=20
> > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones =
> =
wrote:
> > >>>>>>>>> The technique of replicating JWT claims that need to be =
publicly visible in an encrypted JWT in the header is defined at =
https://tools.ietf.org/html/rfc7519#section-5.3 =
.  (Thanks to Dick =
Hardt for bringing this need to my attention as we were finishing the =
JWT spec.)
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>>                                                        -- =
Mike
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> From: OAuth > On Behalf Of John Bradley
> > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
> > >>>>>>>>> To: Vladimir Dzhuvinov >
> > >>>>>>>>> Cc: IETF oauth WG >
> > >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured =
Authorization Request (JAR) vs OIDC request object
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> The intent was to do that, but specs change once the OAuth =
WG and IESG get there hands on them. =20
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> Being backwards compatible with OIDC is not a compelling =
argument to the IESG.
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> We were mostly thinking of asymmetric encryption. =20
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> Specifying puting the issuer and or the audience in the =
headder has come up in the past but probably is not documented. =20
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> John B=20
> > >>>>>>>>>=20
> > >>>>>>>>> =20
> > >>>>>>>>>=20
> > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov =
> wrote:
> > >>>>>>>>>=20
> > >>>>>>>>> Yes, putting the client_id into the JWE header is a way =
around the need
> > >>>>>>>>> to have the client_id outside the JWE as top-level authZ =
request parameter.
> > >>>>>>>>>=20
> > >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I =
just checked
> > >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
> > >>>>>>>>>=20
> > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also =
relies on the
> > >>>>>>>>> presence of client_id as top-level parameter, together =
with requiring
> > >>>>>>>>> RPs to register their request_uri's (so that we don't need =
to build and
> > >>>>>>>>> store an index of all request_uri's). I just had a look at =
"DDoS Attack
> > >>>>>>>>> on the Authorization Server" and also realised the =
request_uri
> > >>>>>>>>> registration isn't explicitly mentioned as attack =
prevention ("the
> > >>>>>>>>> server should (a) check that the value of "request_uri" =
parameter does
> > >>>>>>>>> not point to an unexpected location").
> > >>>>>>>>>=20
> > >>>>>>>>> =
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1 =

> > >>>>>>>>>=20
> > >>>>>>>>> To be honest, I feel quite bad about the situation with =
JAR we are in
> > >>>>>>>>> now. For some reason I had the impression that OAuth JAR =
was going to be
> > >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, =
as with other
> > >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 =
specs.
> > >>>>>>>>>=20
> > >>>>>>>>> I find it unfortunate I didn't notice this when I was =
reviewing the spec
> > >>>>>>>>> in the past.
> > >>>>>>>>>=20
> > >>>>>>>>> Vladimir
> > >>>>>>>>>=20
> > >>>>>>>>>=20
> > >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
> > >>>>>>>>> > Vladimir,
> > >>>>>>>>> >
> > >>>>>>>>> > For that very case the payload claims may be repeated in =
the JWE protected header. An implementation wanting to handle this may =
look for iss/client_id there.
> > >>>>>>>>> >
> > >>>>>>>>> > Odesl=C3=A1no z iPhonu
> > >>>>>>>>> >
> > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov =
>:
> > >>>>>>>>> >>
> > >>>>>>>>> >> =EF=BB=BFI just realised there is one class of JARs =
where it's practially
> > >>>>>>>>> >> impossible to process the request if merge isn't =
supported:
> > >>>>>>>>> >>
> > >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared =
key. OIDC allows
> > >>>>>>>>> >> for that and specs a method for deriving the shared key =
from the
> > >>>>>>>>> >> client_secret:
> > >>>>>>>>> >>
> > >>>>>>>>> >> =
https://openid.net/specs/openid-connect-core-1_0.html#Encryption =

> > >>>>>>>>> >>
> > >>>>>>>>> >> If the JAR is encrypted with the client_secret, and =
there is no
> > >>>>>>>>> >> top-level client_id parameter, there's no good way for =
the OP to find
> > >>>>>>>>> >> out which client_secret to get to try to decrypt the =
JWE. Unless the OP
> > >>>>>>>>> >> keeps an index of all issued client_secret's.
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >> OP servers which require request_uri registration
> > >>>>>>>>> >> (require_request_uri_registration=3Dtrue) and don't =
want to index all
> > >>>>>>>>> >> registered request_uri's, also have no good way to =
process a request_uri
> > >>>>>>>>> >> if the client_id isn't present as top-level parameter.
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >> Vladimir
> > >>>>>>>>> >>
> > >>>>>>>>> >>
> > >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> > >>>>>>>>> >>>
> > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley =
>:
> > >>>>>>>>> >>>> I think Torsten is speculating that is not a feature =
people use.  =20
> > >>>>>>>>> >>> I=E2=80=99m still trying to understand the use case =
for merging signed and unsigned parameters. Nat once explained a use =
case, where a client uses parameters signed by a 3rd party (some =
=E2=80=9Ecertification authority=E2=80=9C) in combination with =
transaction-specific parameters. Is this being done in the wild?
> > >>>>>>>>> >>>
> > >>>>>>>>> >>> PS: PAR would work with both modes.
> > >>>>>>>>>=20
> > >>>>>>>>>=20
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> OAuth mailing list
> > >>>>>>>>> OAuth@ietf.org 
> > >>>>>>>>> https://
> > >>>>>>>>>=20
> > >>>>>=20
> > >>>>> _______________________________________________
> > >>>>> OAuth mailing list
> > >>>>> OAuth@ietf.org 
> > >>>>> https://www.ietf.org/mailman/listinfo/oauth =

> > >>> -- =20
> > >>> Vladimir Dzhuvinov
> > >>> _______________________________________________
> > >>> OAuth mailing list
> > >>> OAuth@ietf.org 
> > >>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ 
> @_nat_en


--Apple-Mail=_97418524-0F27-4112-A8BB-72E2CF051C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
mitigations of 10.4.1 are related, but the section heading is about =
(D)DoS attacks. I think this heading needs to be reworded to apply to =
SSRF attacks too or else add another section with similar =
mitigations. 

Mitigation (a) is a bit vague as to what an "unexpected =
location" is. Perhaps specific wording that it should be a URI that has =
been pre-registered for the client (and validated at that time) or is =
otherwise known to be safe (e.g., is a URI scheme controlled by the AS =
itself as with PAR).

In addition for this to be effective the AS should not follow =
redirects when fetching the URI. It's not clear to me whether that is =
implied by "not perform recursive GET" so it may be worth explicitly =
spelling that out.

-- Neil


On 16 Jan 2020, at 15:47, Nat =
Sakimura <sakimura@gmail.com> wrote:

Right. We could add a security consideration like that, =
though the mitigation probably is pretty much the same as what is stated =
in 10.4.1: 
the server should (a) check =
that
   the value of "request_uri" parameter does not point to an unexpected
   location, (b) check the content type of the response is "application/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on the
   "request_uri".
If not, please let me know =
so that we can add that as the mitigation as well. 

Existing OIDC deployment =
cannot make use of application/oauth.authz.req+jwt but it has to =
validate that content is a valid request object anyways and if it is =
malformed, it MUST stop the processing and return an error =
invalid_request_uri. So, unlike in the case of Capital One's SSRF, the =
content of the request_uri will not be exposed. The main downside is =
therefore as depicted in the current draft, consumption of the network =
and processing power of the AS, and the unwanted access load to the =
servers serving the URL pointed by request_uri. The above-quoted =
mitigations were introduced to address these issues. 




On Thu, Jan =
16, 2020 at 11:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
It is not too late to add to =
the security considerations.



It seems that the new application/oauth.authz.req+jwt media-type is =
helpful

in this regard, in that if an AS can require that content-type from

dereferencing the request_uri, then seeing anything else indicates that =
the

request was bogus (or an attack).  I guess existing OIDC =
deployments aren't

exactly in a position to do that, though.



-Ben



On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:

> Is it too late to add it to the security considerations for JAR? =


> 

> =E2=80=94 Neil

> 

> > On 16 Jan 2020, at 08:15, Dominick Baier <dbaier@leastprivilege.com> wrote:

> > 

> > =EF=BB=BF

> > Agreed - that=E2=80=99s why we disabled request_uri by default =
and added extensibility points to implement validation.

> > 

> > I thought it is odd that this was not mentioned in the typical =
=E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..

> > 

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

> > Dominick Baier

> > 

> >> On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com) wrote:

> >> 

> >> If the AS can=E2=80=99t validate the request_uri it may =
also open itself up to SSRF attacks where a malicious client uses the =
request_uri to probe/attack resources inside the AS=E2=80=99s private =
network. This was a crucial part of the recent Capital One breach for =
example [1].  ForgeRock currently requires strict validation of =
request_uris against a client-specific whitelist for exactly this =
reason. 

> >> 

> >> NB some clients might legitimately be on that private =
network (eg microservices) so changing to a global whitelist for all =
clients is undesirable. 

> >> 

> >> [1]: https://ejj.io/blog/capital-one

> >> 

> >> =E2=80=94 Neil

> >> 

> >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:

> >>>> Well, embedding a client_id claim in the JWE =
header in order to achieve "request parameters outside the request =
object should not be referred to" is like "putting the cart before the =
horse". Why do we have to avoid using the traditional client_id request =
parameter so stubbornly?

> >>>> 

> >>>> The last paragraph of Section 3.2.1 of RFC 6749 =
says as follows.

> >>>> 

> >>>> A client MAY use the "client_id" request parameter =
to identify itself when sending requests to the token endpoint.  In =
the "authorization_code" "grant_type" request to the token endpoint, an =
unauthenticated client MUST send its "client_id" to prevent itself from =
inadvertently accepting a code intended for a client with a different =
"client_id".  This protects the client from substitution of the =
authentication code.  (It provides no additional security for the =
protected resource.)

> >>>> 

> >>>> If the same reasoning applies, a client_id must =
always be sent with request / request_uri because client authentication =
is not performed at the authorization endpoint. In other words, an =
unauthenticated client (every client is unauthenticated at the =
authorization endpoint) MUST send its "client_id" to prevent itself from =
inadvertently accepting a request object for a client with a different =
"client_id".

> >>>> 

> >>> Identifying the client in JAR request_uri requests can =
be really useful so that an AS which requires request_uri registration =
to prevent DDoS attacks and other checks can do those without having to =
index all request_uris individually. I mentioned this before.

> >>> 

> >>> I really wonder what the reasoning of the IESG =
reviewers was to insist on no params outside the JAR JWT / =
request_uri.

> >>> 

> >>> I'm beginning to realise this step of the review =
process isn't particularly transparent to WG members.

> >>> 

> >>> Vladimir

> >>> 

> >>> 

> >>> 

> >>>> Best Regards,

> >>>> Taka

> >>>> 

> >>>> 

> >>>> 

> >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:

> >>>>> John, thanks, much appreciated!

> >>>>> 

> >>>>>> On 11/01/2020 21:36, John Bradley =
wrote:

> >>>>>> Yes JAR is not prohibiting paramater =
replication in the header. 

> >>>>>> 

> >>>>>> I will see if i can add something in final =
edits to call that out.

> >>>>>> 

> >>>>>> John B.

> >>>>>> 

> >>>>>>> On 1/11/2020 6:16 AM, Vladimir =
Dzhuvinov wrote:

> >>>>>>> Thanks Mike for the rfc7519 =
section-5.3 pointer. Can this parameter replication be used for =
client_id or the client_id ass "iss" even though it isn't explicitly =
mentioned in the JAR spec?

> >>>>>>> 

> >>>>>>>> On 11/01/2020 02:58, John Bradley =
wrote:

> >>>>>>>> Right we just don't say to put the =
iss there in OIDC if it's symetricly encrypted.

> >>>>>>> OIDC doesn't have the symmetric key =
selection issue, I suppose that why the possibility to replicate params =
to the JWE header isn't mentioned at all. OIDC requires the top-level =
query params to represent a valid OAuth 2.0 request, and there client_id =
is required. If the client_id is present the client registration =
together with any present client_secret can be retrieved.

> >>>>>>> 

> >>>>>>> I reread the JAR spec, this is the =
only place that mentions handling of symmetric JWE.

> >>>>>>> 

> >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-=
10.2

> >>>>>>> 

> >>>>>>>> (b)  Verifying that the =
symmetric key for the JWE encryption is the

> >>>>>>>>        =
 correct one if the JWE is using symmetric encryption.
=

> >>>>>>> 

> >>>>>>> Vladimir

> >>>>>>> 

> >>>>>>> 

> >>>>>>> 

> >>>>>>>> 

> >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike =
Jones <Michael.Jones@microsoft.com> wrote:

> >>>>>>>>> The technique of replicating =
JWT claims that need to be publicly visible in an encrypted JWT in the =
header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.  =
(Thanks to Dick Hardt for bringing this need to my attention as we were =
finishing the JWT spec.)

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>>        =
                    =
                    =
        -- Mike

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley

> >>>>>>>>> Sent: Friday, January 10, 2020 =
2:15 PM

> >>>>>>>>> To: Vladimir Dzhuvinov <vladimir@connect2id.com>

> >>>>>>>>> Cc: IETF oauth WG <oauth@ietf.org>

> >>>>>>>>> Subject: [EXTERNAL] Re: =
[OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request =
object

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> The intent was to do that, but =
specs change once the OAuth WG and IESG get there hands on them.  =


> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> Being backwards compatible =
with OIDC is not a compelling argument to the IESG.

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> We were mostly thinking of =
asymmetric encryption.  

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> Specifying puting the issuer =
and or the audience in the headder has come up in the past but probably =
is not documented.  

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> John B 

> >>>>>>>>> 

> >>>>>>>>>  

> >>>>>>>>> 

> >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM =
Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

> >>>>>>>>> 

> >>>>>>>>> Yes, putting the client_id =
into the JWE header is a way around the need

> >>>>>>>>> to have the client_id outside =
the JWE as top-level authZ request parameter.

> >>>>>>>>> 

> >>>>>>>>> Unfortunately this work around =
isn't mentioned anywhere, I just checked

> >>>>>>>>> the most recent =
draft-ietf-oauth-jwsreq-20.

> >>>>>>>>> 

> >>>>>>>>> Our DDoS attack mitigation =
(for OIDC request_uri) also relies on the

> >>>>>>>>> presence of client_id as =
top-level parameter, together with requiring

> >>>>>>>>> RPs to register their =
request_uri's (so that we don't need to build and

> >>>>>>>>> store an index of all =
request_uri's). I just had a look at "DDoS Attack

> >>>>>>>>> on the Authorization Server" =
and also realised the request_uri

> >>>>>>>>> registration isn't explicitly =
mentioned as attack prevention ("the

> >>>>>>>>> server should (a) check that =
the value of "request_uri" parameter does

> >>>>>>>>> not point to an unexpected =
location").

> >>>>>>>>> 

> >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-=
10.4.1

> >>>>>>>>> 

> >>>>>>>>> To be honest, I feel quite bad =
about the situation with JAR we are in

> >>>>>>>>> now. For some reason I had the =
impression that OAuth JAR was going to be

> >>>>>>>>> the OIDC request / request_uri =
for general OAuth 2.0 use, as with other

> >>>>>>>>> OIDC bits that later became =
general purpose OAuth 2.0 specs.

> >>>>>>>>> 

> >>>>>>>>> I find it unfortunate I didn't =
notice this when I was reviewing the spec

> >>>>>>>>> in the past.

> >>>>>>>>> 

> >>>>>>>>> Vladimir

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> On 10/01/2020 22:39, Filip =
Skokan wrote:

> >>>>>>>>> > Vladimir,

> >>>>>>>>> >

> >>>>>>>>> > For that very case the =
payload claims may be repeated in the JWE protected header. An =
implementation wanting to handle this may look for iss/client_id =
there.

> >>>>>>>>> >

> >>>>>>>>> > Odesl=C3=A1no z iPhonu

> >>>>>>>>> >

> >>>>>>>>> >> 10. 1. 2020 v 21:19, =
Vladimir Dzhuvinov <vladimir@connect2id.com>:

> >>>>>>>>> >>

> >>>>>>>>> >> =EF=BB=BFI just =
realised there is one class of JARs where it's practially

> >>>>>>>>> >> impossible to process =
the request if merge isn't supported:

> >>>>>>>>> >>

> >>>>>>>>> >> The client submits a =
JAR encrypted (JWT) with a shared key. OIDC allows

> >>>>>>>>> >> for that and specs a =
method for deriving the shared key from the

> >>>>>>>>> >> client_secret:

> >>>>>>>>> >>

> >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryptio=
n

> >>>>>>>>> >>

> >>>>>>>>> >> If the JAR is =
encrypted with the client_secret, and there is no

> >>>>>>>>> >> top-level client_id =
parameter, there's no good way for the OP to find

> >>>>>>>>> >> out which =
client_secret to get to try to decrypt the JWE. Unless the OP

> >>>>>>>>> >> keeps an index of all =
issued client_secret's.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> OP servers which =
require request_uri registration

> >>>>>>>>> >> =
(require_request_uri_registration=3Dtrue) and don't want to index all

> >>>>>>>>> >> registered =
request_uri's, also have no good way to process a request_uri

> >>>>>>>>> >> if the client_id =
isn't present as top-level parameter.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> Vladimir
=

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >>> On 10/01/2020 =
20:13, Torsten Lodderstedt wrote:

> >>>>>>>>> >>>

> >>>>>>>>> >>>>> Am =
10.01.2020 um 16:53 schrieb John Bradley <ve7jtb@ve7jtb.com>:

> >>>>>>>>> >>>> I think =
Torsten is speculating that is not a feature people use.   

> >>>>>>>>> >>> I=E2=80=99m still =
trying to understand the use case for merging signed and unsigned =
parameters. Nat once explained a use case, where a client uses =
parameters signed by a 3rd party (some =E2=80=9Ecertification =
authority=E2=80=9C) in combination with transaction-specific parameters. =
Is this being done in the wild?

> >>>>>>>>> >>>

> >>>>>>>>> >>> PS: PAR would =
work with both modes.

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> =
_______________________________________________

> >>>>>>>>> OAuth mailing list

> >>>>>>>>> OAuth@ietf.org

> >>>>>>>>> https://

> >>>>>>>>> 

> >>>>> 

> >>>>> =
_______________________________________________

> >>>>> OAuth mailing list

> >>>>> OAuth@ietf.org

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

> >>> --  

> >>> Vladimir Dzhuvinov

> >>> _______________________________________________

> >>> OAuth mailing list

> >>> OAuth@ietf.org

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

> >> _______________________________________________ 

> >> OAuth mailing list 

> >> OAuth@ietf.org 

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



> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Nat Sakimura (=3Dnat)
Chairman, =
OpenID Foundation
http://nat.sakimura.org/
@_nat_en



=

--Apple-Mail=_97418524-0F27-4112-A8BB-72E2CF051C10--


From nobody Thu Jan 16 08:37: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 4980D120AA5 for ; Thu, 16 Jan 2020 08:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 3gVgOPyREOEs for ; Thu, 16 Jan 2020 08:37:03 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D25120AA7 for ; Thu, 16 Jan 2020 08:37:02 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id t2so19843983wrr.1 for ; Thu, 16 Jan 2020 08:37:02 -0800 (PST)
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=AOvnS9bsvkQeScWyQzaH06xCb2l9kWYzkXQ4gVOgiaU=; b=kJs3e4uTsv7+0ipipFZ0bjIVmze1RxwENxXYN5+c7/lZ5f8AAZDfxo0dQkl+zqjO0t v8CywTAbSrwvsTCi4Ufyx+FZxti1ahDw7C2+glMhGutM1yac7n+55nlSUSs6GYddUeZY CfEG9MiTSUFdSJQ3rArTCkf2nMZuC6GUGo+Mc=
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=AOvnS9bsvkQeScWyQzaH06xCb2l9kWYzkXQ4gVOgiaU=; b=KgH+dLvEaqB0G0ppqhB3GnfoILEIbR56ks2N214lku+i/00+2LPu2Y93e14on9hQBe GYBi/TP4/bXduG/9zmK1DLQ6COzkeBLd5UqYpoEgAdO4stv6nahNVvb0t1DRzoZfGA9H po6ffBHs4eeMa+G9i9sWE4SNgp6q5wbBI2aJKw/usje/U+Zp6gOfNbT6pvoAeaS0E7bv qy5b2Wl+pBPdyu7NeO1N8OmypeIayRoXBL0fnH/+AusmpnCxgPNuGklskJq7TdVjdoJs BMV91EE+1c5AM8fvRXgklhfNNulP99/FykB1Uaea5CLodA1lT7Sj5SC8X6VjOUHX0Ydd worg==
X-Gm-Message-State: APjAAAVb+ViHde9et4BdHtGowchdXlhmk0BVyCNQXpiB4V+fPcdqmHjt P6H62eh1s2yqJRi5mmy7tsH5Ag==
X-Google-Smtp-Source: APXvYqxxHVO3KmgnFawLAKYwiuOZgv4uUDOTsN5sOx68GSPOQ7MnJLBQ1XKtXihbsW2ZCblWtqzp1w==
X-Received: by 2002:adf:bc4f:: with SMTP id a15mr4252259wrh.160.1579192620824;  Thu, 16 Jan 2020 08:37:00 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id o7sm1742982wmh.11.2020.01.16.08.36.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 08:37:00 -0800 (PST)
From: Neil Madden 
Message-Id: <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_448E5A6A-A067-45FC-8C76-29709CEF7FFE"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 16 Jan 2020 16:36:59 +0000
In-Reply-To: <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
Cc: Justin Richer , oauth , Nat Sakimura , "Richard Backman, Annabelle" 
To: Torsten Lodderstedt 
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:37:08 -0000

--Apple-Mail=_448E5A6A-A067-45FC-8C76-29709CEF7FFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Why not have the PAR endpoint return a 30x redirect with the full URL to =
the authorization endpoint in the Location header? That way the AS can =
decide for itself how to communicate any id from the PAR endpoint to the =
authorization endpoint.

This also has the side effect that you can kick off an OAuth2 flow with =
a simple HTML form pointed at the PAR endpoint (with hidden fields for =
state/code_challenge etc).

If actually performing the redirect is a bit problematic then at least =
the idea of returning a full URL for the authorization endpoint =
(hyperlink) rather than returning an id/URI and requiring the client to =
construct one seems reasonable to me and would seem to avoid some of the =
difficulties being discussed with JAR etc as the exact mechanism of =
communication becomes an implementation detail that the client needn't =
know about.

-- Neil

> On 16 Jan 2020, at 16:25, Torsten Lodderstedt =
 wrote:
>=20
> I just thought about another option. What if we change PAR to not use =
the request_uri parameter but a new parameter, e.g. request_id?
>=20
> That would decouple both specs. The reason why we use request_uri was =
to make the life of clients easier since they can use the standard =
library function for request objects to pass the PAR reference to the =
AS. Is this worth the trouble?
>=20
>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>=20
>> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to =
come back to go through another round anyway thanks to the breaking =
changes the IESG pushed into it after it left WGLC.
>>=20
>> I=E2=80=99d rather see us get this right than publish something many =
of us think is broken.=20
>>=20
>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
> wrote:
>>>=20
>>> The problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
>>> =20
>>> My preference remains the former. It strikes me as bad form for one =
extension to override normative requirements laid out in another =
document. Granted, the incompatibility scenarios introduced by this =
retcon are edge-case at best, but that just raises the question of why =
we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been =
published yet.
>>> =20
>>> =E2=80=93=20
>>> Annabelle Richard Backman
>>> AWS Identity
>>> =20
>>> =20
>>> From: OAuth > =
on behalf of Vladimir Dzhuvinov >
>>> Organization: Connect2id Ltd..
>>> Date: Wednesday, January 15, 2020 at 12:34 PM
>>> To: Justin Richer >
>>> Cc: oauth >, Nat Sakimura =
>, "Richard Backman, =
Annabelle" >
>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests =
must become JWTs
>>> =20
>>> On 13/01/2020 19:32, Justin Richer wrote:
>>>> To be clear, I=E2=80=99m not saying we suggest a particular form, =
and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s =
a JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases.=20
>>> Good, we're on the same page then.
>>> How about simply saying that the result of PAR is an URI referencing =
the pushed authZ request; at the authZ endpoint its processing is =
completed.
>>> No need is both clear and abstract enough to not require a form to =
be specified.
>>> =20
>>>> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=
=9D to be formatted as a JWT.
>>> But why?
>>> Both PAR and authZ endpoints belong to the AS, which makes that impl =
specific. The URI is the contract, between client and AS.
>>> The AS, if uService based, could choose to implement that as CBOR =
Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS contract =
in any way.
>>> =20
>>>> We had a case of similarly unintentional limiting in JAR =
previously, saying that you had to do an HTTP lookup on the request_uri, =
but I believe that=E2=80=99s been backed off now and made conditional.
>>> That was precisely my point.
>>> Vladimir
>>> =20
>>> =20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>=20
>>>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov =
> wrote:
>>>>> =20
>>>>> My suggestion is to abstain from specifying the concrete form of =
the resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
>>>>> In the Connect2id implementation of PAR the returned URI doesn't =
point to a request object and it doesn't point to a JWT either. It =
points to an internally stored "pre-processed" authZ request, which the =
authZ endpoint then picks up to complete the authZ.
>>>>> Even if we eventually end up in microservice world, or allow the =
PAR endpoint to be managed by some external entity, the PAR URI - its =
interpretation, validation and potentially resource retrieval (JWT or =
other blob), is an "internal contract" on the AS side. This doesn't =
concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>>>> =20
>>>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ =
request: the client submits an authZ request and gets an authZ response =
at the end. The URI is necessary for the client to proceed from the 1st =
to the 2nd step. If we manage to frame / word the PAR URI in this =
logical way, without getting stuck in the JAR definition / framing of =
what the request_uri / object is, it would be great.
>>>>> =20
>>>>> The normative language I think should focus on maintaining the =
OAuth 2.0 contract for the entire logical authZ request, together with =
the basic contracts of 1) JAR and the 2) authZ endpoint.
>>>>> =20
>>>>> Vladimir
>>>>> =20
>>>>> On 10/01/2020 22:55, Justin Richer wrote:
>>>>>> So we could solve this by saying the resulting data object of a =
PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing.=20
>>>>>> =20
>>>>>> Or PAR could at least say that if it=E2=80=99s dereferenced over =
a remote protocol then it MUST be a JWT, but otherwise it can be =
whatever you want. That=E2=80=99s where the real interop concerns come =
in.
>>>>>> =20
>>>>>>  =E2=80=94 Justin
>>>>>>=20
>>>>>>=20
>>>>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
> wrote:
>>>>>>> =20
>>>>>>> Correct. The problem becomes pretty clear in the context of PAR, =
where the AS is generating and vending out the URI at the PAR endpoint, =
and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
>>>>>>> =E2=80=93=20
>>>>>>> Annabelle Richard Backman
>>>>>>> AWS Identity
>>>>>>> =20
>>>>>>> =20
>>>>>>> From: John Bradley >
>>>>>>> Date: Friday, January 10, 2020 at 12:29 PM
>>>>>>> To: Brian Campbell >
>>>>>>> Cc: Torsten Lodderstedt >, Nat Sakimura >, "Richard Backman, Annabelle" =
>, oauth =
>
>>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests =
must become JWTs
>>>>>>> =20
>>>>>>> If we assume the client posts a JAR and gets back a reference.  =
Then the reference is to a JAR.=20
>>>>>>> =20
>>>>>>> I think I see the problem.  If the server providing the =
reference is associated with the AS then the server dosen't need to =
dereference the object via HTTP, so it could be a URN as an example.=20
>>>>>>> =20
>>>>>>> So yes it is not a interoperability issue for the client. =20
>>>>>>> =20
>>>>>>> I will think about how I can finesse that.=20
>>>>>>> =20
>>>>>>> I agree it is not a change in intent.=20
>>>>>>> =20
>>>>>>> I will see if I can get our AD to accept that.
>>>>>>> =20
>>>>>>> John B.=20
>>>>>>> =20
>>>>>>> =20
>>>>>>> =20
>>>>>>> =20
>>>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>>>>>>>> Sure but the text proposed (or something like it) qualifies it =
such that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>>>>>>>> =20
>>>>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley =
> wrote:
>>>>>>>>> It may be a challenge to change text saying that the contents =
of the resource could be something other than a request object.=20
>>>>>>>>> =20
>>>>>>>>> If not a request object then what and how is that =
interoperable are likely AD questions.=20
>>>>>>>>> =20
>>>>>>>>> I could perhaps see changing it to must be a request object, =
or other format defined by a profile.
>>>>>>>>>=20
>>>>>>>>> John B. =20
>>>>>>>>> =20
>>>>>>>>> =20
>>>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>>>>>>>> Agree and agree. But given that the change suggested by =
Annabelle has no impact on the client or interoperability, perhaps Nat =
or John could work the change into the draft during the edits that =
happen during the final stages of things?
>>>>>>>>>> =20
>>>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t =
want to change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>>>>>>>=20
>>>>>>>>>>>> It would be more appropriate to add the text to JAR rather =
than PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving =
the text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>>>>>>>> =20
>>>>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>> Object.
>>>>>>>>>>>> =20
>>>>>>>>>>>> To:=20
>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>>>>>>> Server.
>>>>>>>>>>>> =20
>>>>>>>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>>>>>>>> =20
>>>>>>>>>>>> =E2=80=93=20
>>>>>>>>>>>> Annabelle Richard Backman
>>>>>>>>>>>> AWS Identity
>>>>>>>>>>>> =20
>>>>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>>>>>>>> =20
>>>>>>>>>>>>     Hi,=20
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     you are right, PAR does not require the AS to represent =
the request as a JWT-based request object. The URI is used as internal =
reference only. That why the draft states
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     "There is no need to make the
>>>>>>>>>>>>           authorization request data available to other =
parties via this
>>>>>>>>>>>>           URI.=E2=80=9D
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     We may add a statement to PAR saying that request_uris =
issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     best regards,
>>>>>>>>>>>>     Torsten. =20
>>>>>>>>>>>>    =20
>>>>>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>>>>>>>     >=20
>>>>>>>>>>>>     > Hi all,
>>>>>>>>>>>>     > =20
>>>>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require =
that the AS transform all pushed requests into JWTs. This requirement =
arises from the following:
>>>>>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>>>>>>>     >         =E2=80=A2 According to JAR, the resource =
referenced by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a =
JWT containing all the authorization request parameters. (Section 2.1)
>>>>>>>>>>>>     > =20
>>>>>>>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>>>>>>>     > =20
>>>>>>>>>>>>     > =E2=80=93=20
>>>>>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>>>>>     > AWS Identity
>>>>>>>>>>>>     > =20
>>>>>>>>>>>>     > _______________________________________________
>>>>>>>>>>>>     > OAuth mailing list
>>>>>>>>>>>>     > OAuth@ietf..org 
>>>>>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>>>> =20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf..org 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth =
--=20
>>>>> Vladimir Dzhuvinov
>>>>=20
>>>> =20
>>> --=20
>>> Vladimir Dzhuvinov
>>=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=_448E5A6A-A067-45FC-8C76-29709CEF7FFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Why =
not have the PAR endpoint return a 30x redirect with the full URL to the =
authorization endpoint in the Location header? That way the AS can =
decide for itself how to communicate any id from the PAR endpoint to the =
authorization endpoint.

This also has the side effect that you can kick off an OAuth2 =
flow with a simple HTML form pointed at the PAR endpoint (with hidden =
fields for state/code_challenge etc).

If actually performing the redirect is =
a bit problematic then at least the idea of returning a full URL for the =
authorization endpoint (hyperlink) rather than returning an id/URI and =
requiring the client to construct one seems reasonable to me and would =
seem to avoid some of the difficulties being discussed with JAR etc as =
the exact mechanism of communication becomes an implementation detail =
that the client needn't know about.

-- Neil



On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> =
wrote:

I =
just thought about another option. What if we change PAR to not use the =
request_uri parameter but a new parameter, e.g. request_id?

That would decouple both specs. The reason why we use =
request_uri was to make the life of clients easier since they can use =
the standard library function for request objects to pass the PAR =
reference to the AS. Is this worth the trouble?

Am =
16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BF+1 to this approach, and it sounds like JAR might need to =
come back to go through another round anyway thanks to the breaking =
changes the IESG pushed into it after it left WGLC.

I=E2=80=99d rather see us get this =
right than publish something many of us think is broken. 

Maybe PAR and JAR (and =
JARM?) end up going out as a bundle of specs.

 =E2=80=94 Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
<richanna@amazon.com> wrote:

The =
problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
 
My preference remains the former. It =
strikes me as bad form for one extension to override normative =
requirements laid out in another document. Granted, the incompatibility =
scenarios introduced by this retcon are edge-case at best, but that just =
raises the question of why we can=E2=80=99t fix the draft that hasn=E2=80=99=
t actually been published yet.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> =
on behalf of Vladimir Dzhuvinov <vladimir@connect2id.com>Organization: Connect2id Ltd..
Date: Wednesday, January 15, =
2020 at 12:34 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>, Nat =
Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] =
[UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
 
On 13/01/2020 19:32, Justin Richer =
wrote:
To be clear, I=E2=80=99m not saying we suggest a particular =
form, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=
=99s a JWT=E2=80=9D or something of that nature. But if we call the =
result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =
=E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without =
saying what =E2=80=9Cthing X=E2=80=9D needs to be in all cases. 
Good, we're on the =
same page then.
How about =
simply saying that the result of PAR is an URI referencing the pushed =
authZ request; at the authZ endpoint its processing is completed.
No need is both clear and =
abstract enough to not require a form to be specified.
 
In cases where you do a remote look up, =
we want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.
But why?
Both PAR and authZ endpoints =
belong to the AS, which makes that impl specific. The URI is the =
contract, between client and AS.
The AS, if uService based, could choose to implement that as =
CBOR Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS =
contract in any way.
 
We had a case of similarly =
unintentional limiting in JAR previously, saying that you had to do an =
HTTP lookup on the request_uri, but I believe that=E2=80=99s been backed =
off now and made conditional.
That was =
precisely my point.
Vladimir
 
 
 =E2=80=94 Justin


On Jan 11, 2020, at 5:28 AM, Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:
 
My suggestion is to abstain from =
specifying the concrete form of the resource pointed to by the PAR URI. =
Regardless of URI type (URN, downloadable https URL or something else), =
and even if the PAR endpoint and the authZ endpoint are managed by two =
different entities (microservice or other scenario).
In the =
Connect2id implementation of PAR the returned URI doesn't point to a =
request object and it doesn't point to a JWT either. It points to an =
internally stored "pre-processed" authZ request, which the authZ =
endpoint then picks up to complete the authZ.
Even if =
we eventually end up in microservice world, or allow the PAR endpoint to =
be managed by some external entity, the PAR URI - its interpretation, =
validation and potentially resource retrieval (JWT or other blob), is an =
"internal contract" on the AS side. This doesn't concern the client, and =
in OAuth 2.0 the role of AS is indivisible.
 
I see PAR =
request + authZ request as one logical OAuth 2.0 authZ request: the =
client submits an authZ request and gets an authZ response at the end. =
The URI is necessary for the client to proceed from the 1st to the 2nd =
step. If we manage to frame / word the PAR URI in this logical way, =
without getting stuck in the JAR definition / framing of what the =
request_uri / object is, it would be great.
 
The =
normative language I think should focus on maintaining the OAuth 2.0 =
contract for the entire logical authZ request, together with the basic =
contracts of 1) JAR and the 2) authZ endpoint.
 
Vladimir
 
On 10/01/2020 22:55, Justin Richer =
wrote:
So we could solve this by saying the resulting data object of =
a PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing. 
 
Or PAR could at least say that if =
it=E2=80=99s dereferenced over a remote protocol then it MUST be a JWT, =
but otherwise it can be whatever you want. That=E2=80=99s where the real =
interop concerns come in.
 
 =E2=80=94 Justin


On Jan 10, 2020, at 3:41 PM, Richard =
Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
Correct. The problem becomes pretty =
clear in the context of PAR, where the AS is generating and vending out =
the URI at the PAR endpoint, and consuming it at the authorization =
endpoint. =46rom an interoperability standpoint, it=E2=80=99s analogous =
to the AS vending an authorization code at the authorization endpoint =
and consuming it at the token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, =
2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt =
<torsten@lodderstedt.net>, =
Nat Sakimura <nat@sakimura.org>, =
"Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: =
[OAUTH-WG] PAR: pushed requests must become JWTs
 
If we assume the client =
posts a JAR and gets back a reference.  Then the reference is to a =
JAR. 
 
I think I see the problem.  If the =
server providing the reference is associated with the AS then the server =
dosen't need to dereference the object via HTTP, so it could be a URN as =
an example. 
 
So yes it is not a interoperability =
issue for the client.  
 
I will think about how I can finesse =
that. 
 
I agree it is not a change in =
intent. 
 
I will see if I can get our AD to =
accept that.
 
John B. 
 
 
 
 
On Fri, Jan 10, 2020, 4:57 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Sure but the text proposed (or =
something like it) qualifies it such that there aren't interoperability =
questions because it's only an implementation detail to the AS who both =
produces the URI and consumes its content.
 
On Fri, =
Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a challenge to =
change text saying that the contents of the resource could be something =
other than a request object. 
 
If not a request object then what and =
how is that interoperable are likely AD questions. 
 
I could perhaps see changing it to must =
be a request object, or other format defined by a profile.

John B.  
 
 
On Fri, Jan 10, 2020, 3:45 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree and agree. But given =
that the change suggested by Annabelle has no impact on the client or =
interoperability, perhaps Nat or John could work the change into the =
draft during the edits that happen during the final stages of =
things?
 
On Thu, Jan 9, 2020 at =
1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the =
status of JAR, we don=E2=80=99t want to change it. And as I said, this =
difference does not impact interoperability from client perspective.



Am 09.01.2020 um 00:58 schrieb =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:
It would be =
more appropriate to add the text to JAR rather than PAR. It doesn't seem =
right for PAR to retcon rules in JAR. Moving the text to JAR also =
highlights the weirdness of giving PAR special treatment.
 
What if we changed this =
sentence in Section 5.2 of JAR:
The contents of the resource referenced by the =
URI MUST be a Request
Object.
 
To: 
The contents of the resource referenced by the =
URI MUST be a Request
Object, unless the URI =
was provided to the client by the Authorization
Server.
 
This would allow for use cases =
such as an AS that provides pre-defined request URIs, or vends request =
URIs via a client management console, or bakes them into their client =
apps.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 
    Hi, 
    
    you are right, PAR does not require =
the AS to represent the request as a JWT-based request object. The URI =
is used as internal reference only. That why the draft states
    
    "There is no need to make the
          =
authorization request data available to other parties via this
          =
URI.=E2=80=9D
    
    This difference matters from an AS =
implementation perspective, it doesn't matter from a client's (interop) =
perspective.
    
    We may add a statement to PAR saying =
that request_uris issued by the PAR mechanism (MAY) deviate from the JAR =
definition.
    
    best regards,
    Torsten.  
    
    > On 8. Jan 2020, at 23:42, =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
    > 
    > Hi all,
    >  
    > The current drafts of PAR (-00) =
and JAR (-20) require that the AS transform all pushed requests into =
JWTs. This requirement arises from the following:
    > =
        =E2=80=A2 PAR uses the =
request_uri parameter defined in JAR to communicate the pushed request =
to the authorization endpoint.
    > =
        =E2=80=A2 According to JAR, =
the resource referenced by request_uri MUST be a Request Object. =
(Section 5.2)
    > =
        =E2=80=A2 Request Object is =
defined to be a JWT containing all the authorization request parameters. =
(Section 2.1)
    >  
    > There is no need for this =
requirement to support interoperability, as this is internal to the AS. =
It is also inconsistent with the rest of JAR, which avoids attempting to =
define the internal communications between the two AS endpoints. Worse, =
this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the =
state or outcome of that work must be forced into the JWT format (or =
retrieved via a subsequent service call or database lookup).
    >  
    > =E2=80=93 
    > Annabelle Richard Backman
    > AWS Identity
    >  
    > =
_______________________________________________
    > OAuth mailing list
    > OAuth@ietf..org
    
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


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

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

=

--Apple-Mail=_448E5A6A-A067-45FC-8C76-29709CEF7FFE--


From nobody Thu Jan 16 08:40: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 D3EF91209A1 for ; Thu, 16 Jan 2020 08:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHiyvuvSH1vp for ; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823FE12004C for ; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
Received: by mail-yw1-xc2d.google.com with SMTP id i126so12993884ywe.7 for ; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tnqi9Z9gofsBQXA82sqVpawhYp8WofiFpp2PlYl/4bY=; b=vXzZz5PfVxmeQYKIRdABi9ivzx0iz2vF/xADTWXNiinIXYjdxtc0BN9WSK5/IJ4C+T HIvniBXBitAmrxbigb3FIde2GZAcp3f1Kkd4Utom1khNlhkyxqCYvYsPz8lpxT3Ecpwh v3102QN5/fHBpEETaCqifRETUsYzoFY2ipX7lpYhi9rmqidgtRZbERTVKuu1k5FzdnFO UdBeilsmKRjVma9/StjAOcAZPj36NBWJ+86GjUdJYyxyBsCDddzOceeSTFimhACeTFhY cG4zckhSwud+kbm2YsHufmo+h91RgAwyW5DdIfbYRMjtYC7fyzzm13SNqwBJWx6MRl3X jI3w==
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=tnqi9Z9gofsBQXA82sqVpawhYp8WofiFpp2PlYl/4bY=; b=O6XeHOuwolPG2BFOoi2ICrcA1SeHAs7qFc/OWIoKFBiPSxcPr+7v4pd0Z0Dw0v1vwU nGxVvrKDeKGFdSfnyknjQgPVPn5x1tEGv34v0ESuPJ5jHwhy3Ch/TnfjVcu8v0Pu0tna k0EfRj/b1qVheewGM7u99aibZXQk/W/gcNadRFO8iuTBL9S/tfDvAFy64ibZl4qpwWtW xozhaoj3L4ybtPY7+3+qr1MVJ/HjwsLNOC0eY/dl+KLR383D6lM06fMDAf/bkBvdgTcr SgGE/osvtXdfM/kEdUpZe1BPtJuTcUjQpx3vePkwD5Tb7PFQ1qJ2YEfQnK15ZIp3VFdf 4wHg==
X-Gm-Message-State: APjAAAWFAUjJTU0/hb0ZkAGPtt8qkA6M9ncC0NFO/8ULDt5Lu02Qr85G fjn1WOryQamn9dVx78sQ6RL0LAotK29TU+Fr2y4FuvM7uQ==
X-Google-Smtp-Source: APXvYqz6jbjyUb4OxowVKivCBiSglnhsF3ZdQl906QxZL/r/oX07pu0Vx9vWYvNhyr+sdfbB6Y4l+ciijZ9BignBuGk=
X-Received: by 2002:a81:844f:: with SMTP id u76mr24269434ywf.99.1579192841532;  Thu, 16 Jan 2020 08:40:41 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
In-Reply-To: <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
From: Filip Skokan 
Date: Thu, 16 Jan 2020 17:40:30 +0100
Message-ID: 
To: Torsten Lodderstedt 
Cc: Justin Richer , oauth , Nat Sakimura ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="00000000000059f96b059c447c81"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:40:48 -0000

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

Thinking of all the new edge cases we'd have to cover, i don't believe its
a good idea, as-is i see it elegant, capable of re-using existing
pipelines, the moment you change the parameter name new edge cases and
conditions start to popup. As an implementer i don't care that JAR says the
request_uri must reference a JWT, i know that requirement is in place for
the client<>AS contract. I'm fine with a language lifting that particular
requirement being present in PAR but i see that as a nitpick that adds
little to no real value to the final specification.

S pozdravem,
*Filip Skokan*


On Thu, 16 Jan 2020 at 17:25, Torsten Lodderstedt  wrote:

> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to come b=
ack to go
> through another round anyway thanks to the breaking changes the IESG push=
ed
> into it after it left WGLC.
>
> I=E2=80=99d rather see us get this right than publish something many of u=
s think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  =E2=80=94 Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richanna@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document=
.
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can=E2=80=
=99t fix
> the draft that hasn=E2=80=99t actually been published yet.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that
> we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or=
 something of that nature. But if
> we call the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of req=
uest_uri =E2=80=9Cthing X=E2=80=9D
> in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believ=
e
> that=E2=80=99s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  =E2=80=94 Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint a=
nd
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or oth=
er
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end=
.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, witho=
ut
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
> Vladimir
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it=E2=80=99s a JWT and=
 instead
> say it=E2=80=99s a request object. Or we define a new term for this autho=
rization
> request blob thing.
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remote=
 protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That=E2=
=80=99s
> where the real interop concerns come in.
>
>  =E2=80=94 Justin
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> Correct. The problem becomes pretty clear in the context of PAR, where th=
e
> AS is generating and vending out the URI at the PAR endpoint, and consumi=
ng
> it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
> If we assume the client posts a JAR and gets back a reference.  Then the
> reference is to a JAR.
>
> I think I see the problem.  If the server providing the reference is
> associated with the AS then the server dosen't need to dereference the
> object via HTTP, so it could be a URN as an example.
>
> So yes it is not a interoperability issue for the client.
>
> I will think about how I can finesse that.
>
> I agree it is not a change in intent.
>
> I will see if I can get our AD to accept that.
>
> John B.
>
>
>
>
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
> wrote:
>
> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
>
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
>
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>     Hi,
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>     best regards,
>     Torsten.
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>     >
>     > Hi all,
>     >
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>     >
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>     >
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf..org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf..org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Thinking of all the new edge cases we'd have to c=
over, i don't believe its a good idea, as-is i see it elegant, capable =
of re-using existing pipelines, the moment you change the parameter name ne=
w edge cases and conditions start to popup. As an implementer i don't c=
are that JAR says the request_uri must reference a JWT, i know that require=
ment is in place for the client<>AS contract. I'm fine with a lan=
guage lifting that particular requirement being present in PAR but i see th=
at as a nitpick that adds little to no real value to the final specificatio=
n.

S pozdravem,
Filip Skokan
=



On Thu, 16 Jan 2020 at 17:25, Torsten Lodderstedt <torsten=3D<=
a href=3D"mailto:40lodderstedt.net@dmarc.ietf.org">40lodderstedt.net@dmarc.=
ietf.org> wrote:
I just thought about another opt=
ion. What if we change PAR to not use the request_uri parameter but a new p=
arameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri was to m=
ake the life of clients easier since they can use the standard library func=
tion for request objects to pass the PAR reference to the AS. Is this worth=
 the trouble?

Am 16.01.=
2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BF+1 to this approach, and it s=
ounds like JAR might need to come back to go through another round anyway t=
hanks to the breaking changes the IESG pushed into it after it left WGLC.
I=E2=80=99d rather see us get this right than publish som=
ething many of us think is broken.=C2=A0

Maybe PAR=
 and JAR (and JARM?) end up going out as a bundle of specs.

<=
/div>
=C2=A0=E2=80=94 Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <richanna@amazon.com> wrot=
e:

The problem is the JWT requ=
irement in JAR, not how we talk about PAR request_uri values in PAR. We nee=
d to either change the language in JAR (see my suggestions elsewhere in thi=
s thread), or add text in PAR that explicitly exempts PAR request_uri value=
s (or preferably all AS-provided request_uri values) from this requirement =
(also see my suggestions elsewhere in this thread).
=C2=A0
My preference remains the former.=
 It strikes me as bad form for one extension to override normative requirem=
ents laid out in another document. Granted, the incompatibility scenarios i=
ntroduced by this retcon are edge-case at best, but that just raises the qu=
estion of why we can=E2=80=99t fix the draft that hasn=E2=80=99t actually b=
een published yet.
=C2=A0
<=
div>
=E2=80=93=C2=A0<=
/span>
Annabelle Richard Back=
man
AWS =
Identity
=C2=A0
=C2=A0
From:=C2=A0=
OAuth <oauth-bounces@ietf.org> on behalf of Vladimir Dzhuvinov =
<vladimir@connect2id.com>
<=
b>Organization:=C2=A0Connect2id Ltd..
Date:=C2=
=A0Wednesday, January 15, 2020 at 12:34 PM
To:=C2=A0=
Justin Richer <jricher@mit.edu>
Cc:=C2=A0oauth <oauth@ietf.org>, N=
at Sakimura <nat@s=
akimura.org>, "Richard Backman, Annabelle" <richanna=
=3D40amazon.com@dmarc.ietf.org>
Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JW=
Ts
=C2=A0
On 13/01/2020 19:32, Justin Richer wrote:
To be clear, I=E2=80=99m not saying we suggest a partic=
ular form, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=
=E2=80=99s a JWT=E2=80=9D or something of that nature. But if we call the r=
esult of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=
=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying wh=
at =E2=80=9Cthing X=E2=80=9D needs to be in all cases.=C2=A0
Good, we're on the same page then.<=
u>
How about simply saying that the result of PAR is a=
n URI referencing the pushed authZ request; at the authZ endpoint its proce=
ssing is completed.
No need is both clear and abstr=
act enough to not require a form to be specified.
<=
u>=C2=A0
In cases where you do a remote look up, w=
e want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.
But why?
Both PAR and au=
thZ endpoints belong to the AS, which makes that impl specific. The URI is =
the contract, between client and AS.
The AS, if uSe=
rvice based, could choose to implement that as CBOR Web Token, or some othe=
r verifiable blob, resulting in the same essential function, and this isn&#=
39;t affecting the client <-> AS contract in any way.
=C2=A0
We had a case of similarly unin=
tentional limiting in JAR previously, saying that you had to do an HTTP loo=
kup on the request_uri, but I believe that=E2=80=99s been backed off now an=
d made conditional.
That was pre=
cisely my point.
Vladimir
<=
u>=C2=A0
=C2=A0
=C2=A0=
=E2=80=94 Justin


On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=C2=A0
My su=
ggestion is to abstain from specifying the concrete form of the resource po=
inted to by the PAR URI. Regardless of URI type (URN, downloadable https UR=
L or something else), and even if the PAR endpoint and the authZ endpoint a=
re managed by two different entities (microservice or other scenario).
In the Connect2id implementation of PAR the return=
ed URI doesn't point to a request object and it doesn't point to a =
JWT either. It points to an internally stored "pre-processed" aut=
hZ request, which the authZ endpoint then picks up to complete the authZ.
Even if we eventually end up in microservice wo=
rld, or allow the PAR endpoint to be managed by some external entity, the P=
AR URI - its interpretation, validation and potentially resource retrieval =
(JWT or other blob), is an "internal contract" on the AS side. Th=
is doesn't concern the client, and in OAuth 2.0 the role of AS is indiv=
isible.
=C2=A0
=
I see PAR request + authZ request as one logical OAuth 2.0 authZ request: t=
he client submits an authZ request and gets an authZ response at the end. T=
he URI is necessary for the client to proceed from the 1st to the 2nd step.=
 If we manage to frame / word the PAR URI in this logical way, without gett=
ing stuck in the JAR definition / framing of what the request_uri / object =
is, it would be great.
=C2=A0
The normative language I think should focus on maintaining the=
 OAuth 2.0 contract for the entire logical authZ request, together with the=
 basic contracts of 1) JAR and the 2) authZ endpoint.
=C2=A0
Vladimir
=C2=A0
On 10/01/2020 22:55, Justin=
 Richer wrote:
So we could solve this by sayin=
g the resulting data object of a PAR is a request object. Which might also =
contain a request object internally as well. In that case JAR should back o=
ff from saying it=E2=80=99s a JWT and instead say it=E2=80=99s a request ob=
ject. Or we define a new term for this authorization request blob thing.=C2=A0
=C2=A0
Or PAR could at least say that if it=E2=80=99s deref=
erenced over a remote protocol then it MUST be a JWT, but otherwise it can =
be whatever you want. That=E2=80=99s where the real interop concerns come i=
n.
=C2=A0
=

=C2=A0=E2=80=94 Justin

On Jan 10, 2020, at 3:41 PM, Richard Back=
man, Annabelle <richan=
na=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0
Correct. The problem =
becomes pretty clear in the context of PAR, where the AS is generating and =
vending out the URI at the PAR endpoint, and consuming it at the authorizat=
ion endpoint. From an interoperability standpoint, it=E2=80=99s analogous t=
o the AS vending an authorization code at the authorization endpoint and co=
nsuming it at the token endpoint.
<=
span style=3D"font-size:12pt">=E2=80=93=C2=A0
Annabelle Richard Backman<=
/span>
AWS Identity
=C2=A0=

=C2=A0
From:=C2=A0John Bradley <ve7jtb@ve7jtb.com&=
gt;
Date:=C2=A0Friday, January 10, 2020 at 12:29 PM<=
br>To:=C2=A0Brian Campbell <bcampbell@pingidentity.com>
Cc:=C2=A0Torsten Lodderstedt <torsten@lo=
dderstedt.net>, Nat Sakimura <nat@sak=
imura.org>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject:=C2=A0[UNVERI=
FIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs=

=C2=A0
=

If we assume the client posts a JAR and get=
s back a reference.=C2=A0 Then the reference is to a JAR.=C2=A0
=C2=A0
I think I see the problem.=C2=A0 If the server provi=
ding the reference is associated with the AS then the server dosen't ne=
ed to dereference the object via HTTP, so it could be a URN as an example.=
=C2=A0
=C2=A0<=
/u>
So yes it is not a interoperabilit=
y issue for the client.=C2=A0=C2=A0
=C2=A0
I will thi=
nk about how I can finesse that.=C2=A0
=

=C2=A0
=
I agree it is not a change in intent.=C2=A0
=

=C2=A0
I will see if I can get our AD to accept that.
=

=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">John B.=C2=A0
=
=C2=A0
=C2=A0<=
/u>
=C2=A0
=C2=A0
On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com<=
/span>> wrote:
Sure but the text proposed (or something like it) q=
ualifies it such that there aren't interoperability questions because i=
t's only an implementation detail to the AS who both produces the URI a=
nd consumes its content.
=C2=
=A0
On Fri, Jan 10, 2020 =
at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a chal=
lenge to change text saying that the contents of the resource could be some=
thing other than a request object.=C2=A0
=C2=A0
=
If not a request object then what and how is that interoperable are likely =
AD questions.=C2=A0
=C2=
=A0
I could perhaps see =
changing it to must be a request object, or other format defined by a profi=
le.

John B.=C2=A0=C2=A0
=C2=A0
=C2=A0<=
/u>
On Fri, Jan 10, 2020, 3:45 P=
M Brian Campbell <bcampbell@pingidentity.com> wrote:=

Agree =
and agree. But given that the change suggested by Annabelle has no impact o=
n the client or interoperability, perhaps Nat or John could work the change=
 into the draft during the edits that happen during the final stages of thi=
ngs?
=C2=A0
On Thu, Jan 9, 2020 at 1:56 AM Torsten Lod=
derstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:=

I would assume given the status of JAR, we don=E2=80=99t want to ch=
ange it. And as I said, this difference does not impact interoperability fr=
om client perspective.
=



Am 09.01.2020 um 00=
:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org<=
/span>>:
It would be more appropriat=
e to add the text to JAR rather than PAR. It doesn't seem right for PAR=
 to retcon rules in JAR. Moving the text to JAR also highlights the weirdne=
ss of giving PAR special treatment.
=C2=A0
What if we changed this sentence in Section 5.2 of JAR:<=
/u>
The contents of the resource referenced=
 by the URI MUST be a Request
Object.
=C2=A0
To:=C2=A0
=
The contents of the resource referenced by the URI MUST be a Request=

Object, unless the URI was provided to the client by the Authori=
zation=

Server.
=C2=A0
This would=
 allow for use cases such as an AS that provides pre-defined request URIs, =
or vends request URIs via a client management console, or bakes them into t=
heir client apps.
=C2=A0
=

=
=E2=80=93=C2=A0
Annabelle Richard Back=
man
AWS Identity
=C2=A0<=
/u>
On 1/8/20, 2:50 PM, "Torsten Lodderstedt" &l=
t;torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:<=
/u>
=C2=A0
=C2=A0=C2=A0=C2=A0 Hi,=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not require the=
 AS to represent the request as a JWT-based request object. The URI is used=
 as internal reference only. That why the draft states=

=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=
=A0"There is no need to make the
=

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization request data avail=
able to other parties via this
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D
=
=C2=A0=C2=A0=C2=A0=C2=A0
=

=C2=A0=C2=A0=
=C2=A0=C2=A0This difference matters from an AS implementation perspective, =
it doesn't matter from a client's (interop) perspective.<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that request_=
uris issued by the PAR mechanism (MAY) deviate from the JAR definition.<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0best regards,
=C2=A0=C2=A0=C2=
=A0 Torsten.=C2=A0=C2=A0
=

=C2=A0=C2=A0=
=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> On 8. Jan=
 2020, at 23:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf=
.org> wrote:
=
=C2=A0=C2=A0=C2=A0 >=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> Hi=
 all,
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> The current drafts=
 of PAR (-00) and JAR (-20) require that the AS transform all pushed reques=
ts into JWTs. This requirement arises from the following:
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=A2 PAR uses the request_uri parameter defined in JAR to communicate =
the pushed request to the authorization endpoint.
=
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=A2 According to JAR, the resource referenced by request_uri MUST be a Requ=
est Object. (Section 5.2)
=
=C2=A0=C2=A0=C2=A0 >=
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 Request Object is def=
ined to be a JWT containing all the authorization request parameters. (Sect=
ion 2.1)
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0> There is no nee=
d for this requirement to support interoperability, as this is internal to =
the AS. It is also inconsistent with the rest of JAR, which avoids attempti=
ng to define the internal communications between the two AS endpoints. Wors=
e, this restriction makes it harder for the authorization endpoint to lever=
age validation and other work performed at the PAR endpoint, as the state o=
r outcome of that work must be forced into the JWT format (or retrieved via=
 a subsequent service call or database lookup).
<=
/div>
=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman
=C2=A0=C2=A0=C2=A0 > AWS Identity
=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0
=

=C2=A0=
=C2=A0=C2=A0=C2=A0> _______________________________________________
=C2=A0=C2=A0=C2=A0 > OAuth mailing list
=C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf..org<=
/span>
=C2=A0=C2=A0=C2=
=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0<=
/u>
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
/a>
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 di=
sclosure by others is strictly prohibited.=C2=A0 If you have received this =
communication in error, please notify the sender immediately by e-mail and =
delete the message and any file attachments from your computer. Thank you.<=
/span>

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


_______________________________________________
OAuth mailing list
OAuth@ietf..org
https://www.ietf.org/mailman/=
listinfo/oauth
-- 
Vladimir Dzhuvinov
=C2=A0
-- 
Vladimir Dzhuvinov

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

OAuth mailing list

OAuth@ietf.org

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



--00000000000059f96b059c447c81--


From nobody Thu Jan 16 08:41: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 97E0F12004C for ; Thu, 16 Jan 2020 08:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level: 
X-Spam-Status: No, score=-1.739 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 zThsdks9rXs0 for ; Thu, 16 Jan 2020 08:41:46 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6760E1209C8 for ; Thu, 16 Jan 2020 08:41:46 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id p125so19405852oif.10 for ; Thu, 16 Jan 2020 08:41:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e9+4pzA4YeOrmDi8NzvzwL+L4Dgi+NEYje8W0LjypR4=; b=DCsOYb1C7PNNZnz5moRk0dakK0XuI57Zw+WO6HvRuz3vUlMJO85Cz6EptzxkIw/YFK /KHNm0p9adGhyIBRCZwV9LF3e8b3Le2EFBKq8lmu7UKyDubtiPMbqZT4Vq3MpfoDFojC yYvVm+ajaNXMe1Gn0teq9a27WxOA3birY8MIk=
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=e9+4pzA4YeOrmDi8NzvzwL+L4Dgi+NEYje8W0LjypR4=; b=hzQscUTXtLI1BQg1RVKbRSwM4VZY6PxcPma3/zeNuXdh4coUDyou73mNvUVfOl2fXb ZRiMvthIwk8p9b+IpMopZPVuQxT249h6cxuHLXXOtooSmsPIZvdBCdB+0boLAWAVo1ch bRY/XPV59ERBVxRI0PvxhLdQCk+s4AcOhLkOEUTVMvEgke/sqmg4JnKdvgnVAimQZ2Aq tCsnl9pEvn+9cOKnKP/VYwT4KL9HlEi9VvdsknhNT/7xEyY4/KYVizdtpo94KaVAUhVx JeCug4B5Q7LiWa+wowc+d5RAEetluMOOFVt1fYq75bb+C/qmun3SaG59BBXkoooVumnR swgw==
X-Gm-Message-State: APjAAAUxNLJZhEP60ZvVCAbucepCr+urOAsZHDsJdIlqyeb4e/LAQB+r 3cCWNqj6Y7/A5RjwugcYwmAivcWDYth31s5fMjw7Gw==
X-Google-Smtp-Source: APXvYqwe4sb0+QMZHj9G+hLPRcMwVKrkmD8lEyo0eT0DIHb++U0y2elFTOdEYi4YeUu1ihJWWZkyCdczBKsEXssz0Cs=
X-Received: by 2002:aca:6744:: with SMTP id b4mr4881557oiy.99.1579192905560; Thu, 16 Jan 2020 08:41:45 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
In-Reply-To: <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
From: Dave Tonge 
Date: Thu, 16 Jan 2020 17:41:34 +0100
Message-ID: 
To: Neil Madden 
Cc: Torsten Lodderstedt ,  Nat Sakimura , oauth ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="0000000000002b07ff059c44805d"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:41:51 -0000

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

I like that idea - although not the 301. But returning the full url seems
like a good idea.
Most of the time PAR will be used on the backend and the user-agent won't
be directly submitting a form - so for the most common use-case a 301 would
cause problems.

On Thu, 16 Jan 2020 at 17:37, Neil Madden  wrote=
:

> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the Location header? That way the AS can
> decide for itself how to communicate any id from the PAR endpoint to the
> authorization endpoint.
>
> This also has the side effect that you can kick off an OAuth2 flow with a
> simple HTML form pointed at the PAR endpoint (with hidden fields for
> state/code_challenge etc).
>
> If actually performing the redirect is a bit problematic then at least th=
e
> idea of returning a full URL for the authorization endpoint (hyperlink)
> rather than returning an id/URI and requiring the client to construct one
> seems reasonable to me and would seem to avoid some of the difficulties
> being discussed with JAR etc as the exact mechanism of communication
> becomes an implementation detail that the client needn't know about.
>
> -- Neil
>
> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <
> torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to come b=
ack to go
> through another round anyway thanks to the breaking changes the IESG push=
ed
> into it after it left WGLC.
>
> I=E2=80=99d rather see us get this right than publish something many of u=
s think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  =E2=80=94 Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richanna@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document=
.
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can=E2=80=
=99t fix
> the draft that hasn=E2=80=99t actually been published yet.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that
> we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or=
 something of that nature. But if
> we call the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of req=
uest_uri =E2=80=9Cthing X=E2=80=9D
> in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believ=
e
> that=E2=80=99s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  =E2=80=94 Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint a=
nd
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or oth=
er
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end=
.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, witho=
ut
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
> Vladimir
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it=E2=80=99s a JWT and=
 instead
> say it=E2=80=99s a request object. Or we define a new term for this autho=
rization
> request blob thing.
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remote=
 protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That=E2=
=80=99s
> where the real interop concerns come in.
>
>  =E2=80=94 Justin
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> Correct. The problem becomes pretty clear in the context of PAR, where th=
e
> AS is generating and vending out the URI at the PAR endpoint, and consumi=
ng
> it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
> If we assume the client posts a JAR and gets back a reference.  Then the
> reference is to a JAR.
>
> I think I see the problem.  If the server providing the reference is
> associated with the AS then the server dosen't need to dereference the
> object via HTTP, so it could be a URN as an example.
>
> So yes it is not a interoperability issue for the client.
>
> I will think about how I can finesse that.
>
> I agree it is not a change in intent.
>
> I will see if I can get our AD to accept that.
>
> John B.
>
>
>
>
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
> wrote:
>
> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
>
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
>
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>     Hi,
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>     best regards,
>     Torsten.
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>     >
>     > Hi all,
>     >
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>     >
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>     >
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf..org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf..org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Dave Tonge
CTO
[image: Moneyhub Enterprise]

Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 =C2=A9

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

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


I like that idea - although not the 301. But returning the=
 full url seems like a good idea.
Most of the time PAR will be used =
on the backend and the user-agent won't be directly submitting a form -=
 so for the most common use-case a 301 would cause problems.
On Thu, 1=
6 Jan 2020 at 17:37, Neil Madden <neil.madden@forgerock.com> wrote:
=
Why not have the PAR endpoint return a 30x redirect with the full URL to th=
e authorization endpoint in the Location header? That way the AS can decide=
 for itself how to communicate any id from the PAR endpoint to the authoriz=
ation endpoint.

This also has the side effect that you c=
an kick off an OAuth2 flow with a simple HTML form pointed at the PAR endpo=
int (with hidden fields for state/code_challenge etc).

=

If actually performing the redirect is a bit problematic then at least=
 the idea of returning a full URL for the authorization endpoint (hyperlink=
) rather than returning an id/URI and requiring the client to construct one=
 seems reasonable to me and would seem to avoid some of the difficulties be=
ing discussed with JAR etc as the exact mechanism of communication becomes =
an implementation detail that the client needn't know about.
=

-- Neil



On 16 Jan 2020, at 16:25, Torsten L=
odderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrot=
e:

I just thought about an=
other option. What if we change PAR to not use the request_uri parameter bu=
t a new parameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri=
 was to make the life of clients easier since they can use the standard lib=
rary function for request objects to pass the PAR reference to the AS. Is t=
his worth the trouble?

=
Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BF+1 to this approach,=
 and it sounds like JAR might need to come back to go through another round=
 anyway thanks to the breaking changes the IESG pushed into it after it lef=
t WGLC.

I=E2=80=99d rather see us get this right than pu=
blish something many of us think is broken.=C2=A0

=
Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
<=
div>
=C2=A0=E2=80=94 Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <richanna@amazon.com=
> wrote:

The problem is the=
 JWT requirement in JAR, not how we talk about PAR request_uri values in PA=
R. We need to either change the language in JAR (see my suggestions elsewhe=
re in this thread), or add text in PAR that explicitly exempts PAR request_=
uri values (or preferably all AS-provided request_uri values) from this req=
uirement (also see my suggestions elsewhere in this thread).<=
/div>
=C2=A0
My preference remains th=
e former. It strikes me as bad form for one extension to override normative=
 requirements laid out in another document. Granted, the incompatibility sc=
enarios introduced by this retcon are edge-case at best, but that just rais=
es the question of why we can=E2=80=99t fix the draft that hasn=E2=80=99t a=
ctually been published yet.
=C2=A0
=E2=80=93=C2=A0
Annabelle Ric=
hard Backman
AWS Identity
=C2=A0
=C2=A0
From:=C2=
=A0OAuth <oauth-bounces@ietf.org> on behalf of Vladimir D=
zhuvinov <vladimir@connect2id.com=
>
Organization:=C2=A0Connect2id Ltd..
Date:=
=C2=A0Wednesday, January 15, 2020 at 12:34 PM
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0oau=
th <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <r=
ichanna=3D40amazon.com@dmarc.ietf.org>
Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must be=
come JWTs
=C2=A0
On 13/01/2020 19:32, Justin Richer wrote:
To be clear, I=E2=80=99m not saying we suggest a p=
articular form, and I agree that we shouldn=E2=80=99t specify that =E2=80=
=9Cit=E2=80=99s a JWT=E2=80=9D or something of that nature. But if we call =
the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =
=E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without say=
ing what =E2=80=9Cthing X=E2=80=9D needs to be in all cases.=C2=A0
Good, we're on the same page =
then.
How about simply saying that the result of PA=
R is an URI referencing the pushed authZ request; at the authZ endpoint its=
 processing is completed.
No need is both clear and=
 abstract enough to not require a form to be specified.
=

=C2=A0
In cases where you do a remote look=
 up, we want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.<=
/u>
But why?
Both PAR =
and authZ endpoints belong to the AS, which makes that impl specific. The U=
RI is the contract, between client and AS.
The AS, =
if uService based, could choose to implement that as CBOR Web Token, or som=
e other verifiable blob, resulting in the same essential function, and this=
 isn't affecting the client <-> AS contract in any way.=

=C2=A0
We had a case of similarl=
y unintentional limiting in JAR previously, saying that you had to do an HT=
TP lookup on the request_uri, but I believe that=E2=80=99s been backed off =
now and made conditional.
That w=
as precisely my point.
Vladimir
=

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


On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=C2=A0
=
My suggestion is to abstain from specifying the concrete form of the resour=
ce pointed to by the PAR URI. Regardless of URI type (URN, downloadable htt=
ps URL or something else), and even if the PAR endpoint and the authZ endpo=
int are managed by two different entities (microservice or other scenario).=

In the Connect2id implementation of PAR the r=
eturned URI doesn't point to a request object and it doesn't point =
to a JWT either. It points to an internally stored "pre-processed"=
; authZ request, which the authZ endpoint then picks up to complete the aut=
hZ.
Even if we eventually end up in microservi=
ce world, or allow the PAR endpoint to be managed by some external entity, =
the PAR URI - its interpretation, validation and potentially resource retri=
eval (JWT or other blob), is an "internal contract" on the AS sid=
e. This doesn't concern the client, and in OAuth 2.0 the role of AS is =
indivisible.
=C2=A0
I see PAR request + authZ request as one logical OAuth 2.0 authZ request=
: the client submits an authZ request and gets an authZ response at the end=
. The URI is necessary for the client to proceed from the 1st to the 2nd st=
ep. If we manage to frame / word the PAR URI in this logical way, without g=
etting stuck in the JAR definition / framing of what the request_uri / obje=
ct is, it would be great.
=C2=A0=

The normative language I think should focus on maintaining =
the OAuth 2.0 contract for the entire logical authZ request, together with =
the basic contracts of 1) JAR and the 2) authZ endpoint.
=C2=A0
Vladimir
=

=C2=A0
On 10/01/2020 22:55, Jus=
tin Richer wrote:
So we could solve this by sa=
ying the resulting data object of a PAR is a request object. Which might al=
so contain a request object internally as well. In that case JAR should bac=
k off from saying it=E2=80=99s a JWT and instead say it=E2=80=99s a request=
 object. Or we define a new term for this authorization request blob thing.=
=C2=A0
=C2=A0<=
/div>
Or PAR could at least say that if it=E2=80=99s de=
referenced over a remote protocol then it MUST be a JWT, but otherwise it c=
an be whatever you want. That=E2=80=99s where the real interop concerns com=
e in.
=C2=A0
=C2=A0=E2=80=94 Justin
=


On Jan 10, 2020, at 3:41 PM, Richard B=
ackman, Annabelle <ric=
hanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0
Correct. The probl=
em becomes pretty clear in the context of PAR, where the AS is generating a=
nd vending out the URI at the PAR endpoint, and consuming it at the authori=
zation endpoint. From an interoperability standpoint, it=E2=80=99s analogou=
s to the AS vending an authorization code at the authorization endpoint and=
 consuming it at the token endpoint.
=E2=80=93=C2=A0
=

Annabelle Richard Backm=
an
AWS Identity
=C2=
=A0
=C2=A0
From:=C2=A0John Bradley <ve7jtb@ve7jtb.com<=
/a>>
Date:=C2=A0Friday, January 10, 2020 at 12:29=
 PM
To:=C2=A0Brian Campbell <bcampbell@pingidentity.com>
Cc:=C2=A0<=
/span>Torsten Lodderstedt <torste=
n@lodderstedt.net>, Nat Sakimura <nat=
@sakimura.org>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject:=C2=A0[=
UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs
=C2=A0=

If we assume the client posts a JAR a=
nd gets back a reference.=C2=A0 Then the reference is to a JAR.=C2=A0
=C2=A0
I think I see the problem.=C2=A0 If the server=
 providing the reference is associated with the AS then the server dosen=
9;t need to dereference the object via HTTP, so it could be a URN as an exa=
mple.=C2=A0
=C2=A0
So yes it is not a interopera=
bility issue for the client.=C2=A0=C2=A0
=C2=A0
I wil=
l think about how I can finesse that.=C2=A0
=

=C2=A0
I agree it is not a change in intent.=C2=A0
=C2=A0
I will see if I can get our AD to accept that.
=C2=A0
John B.=C2=A0
=C2=A0
=C2=A0
=

=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.co=
m> wrote:
Sure but the text proposed (or something like it)=
 qualifies it such that there aren't interoperability questions because=
 it's only an implementation detail to the AS who both produces the URI=
 and consumes its content.
=
=C2=A0
On Fri, Jan 10, 20=
20 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be =
a challenge to change text saying that the contents of the resource could b=
e something other than a request object.=C2=A0
=C2=A0
If not a request object then what and how is that interoperable are l=
ikely AD questions.=C2=A0
I could perhaps=
 see changing it to must be a request object, or other format defined by a =
profile.

John B.=C2=A0=C2=A0
=C2=A0
=C2=
=A0
On Fri, Jan 10, 2020,=
 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:=

Agree and agree. But given that the change suggested by Annabelle has no i=
mpact on the client or interoperability, perhaps Nat or John could work the=
 change into the draft during the edits that happen during the final stages=
 of things?
=C2=A0<=
/u>
On Thu, Jan 9, 2020 at 1:56 AM Tors=
ten Lodderstedt <torsten=3D<=
span style=3D"color:purple">40lodderstedt.net@dmarc.ietf.org>=
 wrote:
=

I would assume given the status of JAR, we don=E2=80=99t wan=
t to change it. And as I said, this difference does not impact interoperabi=
lity from client perspective.



Am 09.01.2020=
 um 00:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.iet=
f.org>:
It would be more appr=
opriate to add the text to JAR rather than PAR. It doesn't seem right f=
or PAR to retcon rules in JAR. Moving the text to JAR also highlights the w=
eirdness of giving PAR special treatment.
<=
div>
=C2=A0=

What if we changed this sentence in Section 5.2 of JA=
R:
The contents of the resource refe=
renced by the URI MUST be a Request
Object.
=C2=A0<=
/u>
To:=C2=A0
The contents of the resource referenced by the URI MUST be a Reques=
t<=
/span>
Object, unless the URI was provided to the client by the=
 Authorization
Server.
=C2=A0
=

Th=
is would allow for use cases such as an AS that provides pre-defined reques=
t URIs, or vends request URIs via a client management console, or bakes the=
m into their client apps.
=
=C2=A0
=E2=80=93=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">Annabelle Rich=
ard Backman
AWS Identity
=

=
=C2=A0
On 1/8/20, 2:50 PM, "Torsten Loddersted=
t" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:<=
u>
=C2=A0
=C2=A0=C2=A0=C2=A0 H=
i,=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not req=
uire the AS to represent the request as a JWT-based request object. The URI=
 is used as internal reference only. That why the draft states
=C2=A0=C2=A0=C2=A0=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">=C2=A0=C2=A0=
=C2=A0=C2=A0"There is no need to make the
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization request d=
ata available to other parties via this
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementation pers=
pective, it doesn't matter from a client's (interop) perspective.
=C2=A0=C2=A0=C2=A0=C2=A0<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that=
 request_uris issued by the PAR mechanism (MAY) deviate from the JAR defini=
tion.
=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0best regards,
<=
div>
=C2=A0=C2=
=A0=C2=A0 Torsten.=C2=A0=C2=A0
=C2=A0=
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> On =
8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmar=
c.ietf.org> wrote:
=C2=A0=C2=A0=C2=A0=
 >=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0&g=
t; Hi all,
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0> The current=
 drafts of PAR (-00) and JAR (-20) require that the AS transform all pushed=
 requests into JWTs. This requirement arises from the following:<=
/u>
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=A2 PAR uses the request_uri parameter defined in JAR to commu=
nicate the pushed request to the authorization endpoint.
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=A2 According to JAR, the resource referenced by request_uri MUST be =
a Request Object. (Section 5.2)
=C2=A0=C2=A0=C2=A0 =
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 Request Object is=
 defined to be a JWT containing all the authorization request parameters. (=
Section 2.1)
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0> There is no=
 need for this requirement to support interoperability, as this is internal=
 to the AS. It is also inconsistent with the rest of JAR, which avoids atte=
mpting to define the internal communications between the two AS endpoints. =
Worse, this restriction makes it harder for the authorization endpoint to l=
everage validation and other work performed at the PAR endpoint, as the sta=
te or outcome of that work must be forced into the JWT format (or retrieved=
 via a subsequent service call or database lookup).
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=
=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman=

=C2=A0=C2=A0=C2=A0 > AWS Identity
<=
/div>
=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0> _______________________________________________
=C2=A0=C2=A0=C2=A0 > OAuth mailing list=

=C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf..org
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">=C2=A0=C2=A0=
=C2=A0=C2=A0
=
=C2=A0=C2=A0=C2=A0=C2=
=A0
_______________________________________________
OAuth mailing lis=
t
OAuth@ietf.org<=
/span>
https://www.ietf.org/mailman/listinfo/oauth=


CONFIDE=
NTIALITY NOTICE: This email may contain confidential and privileged materia=
l for the sole use of the intended recipient(s). Any review, use, distribut=
ion or disclosure by others is strictly prohibited.=C2=A0 If you have recei=
ved this communication in error, please notify the sender immediately by e-=
mail and delete the message and any file attachments from your computer. Th=
ank you.
<=
/div>

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

_______________________________________________<=
br>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/m=
ailman/listinfo/oauth
-- 
Vladimir Dzhuvinov
=C2=A0
=

-- 
Vladimir Dzhuvinov

__________________________=
_____________________
OAuth mailing list
OAuth@ietf.org=

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

_____________________________________________=
__

OAuth mailing list

OAuth@ietf.org

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



-- 
Da=
ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl=
oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512=
0

Moneyhub =
Enterprise is a trading style of Moneyhub Financial Technology Limited whic=
h is authorised and regulated by the Financial Conduct Authority ("FCA=
").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser=
vices Register=C2=A0(FRN=C2=A0809360) at fca.=
org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &=
; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<=
/span>
Moneyhub=C2=A0Financial Technology L=
imited 2018=C2=A0=C2=A9<=
/div>

DISCLAIMER: This email (including any attachments) is subject to co=
pyright, and the information in it is confidential. Use of this email or of=
 any information in it other than by the addressee is unauthorised and unla=
wful. Whilst reasonable efforts are made to ensure that any attachments are=
 virus-free, it is the recipient's sole responsibility to scan all atta=
chments for viruses. All calls and emails to and from this company may be m=
onitored and recorded for legitimate purposes relating to this company'=
s business. Any opinions expressed in this email (or in any attachments) ar=
e those of the author and do not necessarily represent the opinions of Mone=
yhub Financial Technology Limited or of any other group company.
<=
/div>


--0000000000002b07ff059c44805d--


From nobody Thu Jan 16 08:44: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 8AD6612085D for ; Thu, 16 Jan 2020 08:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRirP30r_Ggp for ; Thu, 16 Jan 2020 08:44:14 -0800 (PST)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C9512006B for ; Thu, 16 Jan 2020 08:44:14 -0800 (PST)
Received: by mail-yb1-xb2f.google.com with SMTP id l7so4792182ybp.1 for ; Thu, 16 Jan 2020 08:44:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hrt70WzbY0IUW6HlnZZQPnccSNgEcnLpvGpv4EiARZg=; b=JG7/Kb5bmUssWb/KaIyhIMjK4iRTv1nQwxYHSVzvHastRFBrks4qXKXhd/ZJaaRAZo LKtJ/g+e3DW8Jp6oyT6xyWmROhSRkiVrF3+AgP4fgULhOHVOdNXcdSkojUgXofXN/yZJ D/TyU7MC6Hb4AR0fryB55nieFMt2KpobsxVAO8f8NJvfpOtq0cIczAwzBKxFu6hK7W8Q a2effbdjDfl2vk7Q1y9CdJ6ItWm9O9TxYiO/qs3UOgTGsnST1aG39qdfGBhI4lZc3Ffv GvdVQmnRKNWZCov2EhNjXRQDN6KdV5gEk2mHx8UPQaODR02MDz4o1PdIcEB9g03hPnpp gNzg==
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=hrt70WzbY0IUW6HlnZZQPnccSNgEcnLpvGpv4EiARZg=; b=LoY1RX//7cq6zwvbswZT1fsyMJW0FKqjn03pRHrG1a4AJr9x7nCGKjOOU1PIjqxZQT n4cmNCyJEE1fGL2h6HSgNimBCDf2JzdCC35hJlpcFA9MzTyR6Imij0/LXu4VpPYrLG9w 2HvWRjGwezTElBWrwjewhCbgqZsqPBITNLy/DfkFH2XI5ySZG8ivEnyU3gbfoxdEOqjo F6gti/vw7PrY4Pr2b71JuaXJwLvBukDpCoFvJPRseWSijYAZlhHsxCVNsSG1S2aKg61K TzUW2JqFT2belBlqccAF+nG0VoDT7gPJGrG4ibB3I5QHFooRH7F1RsxYzZ4GW36jsZi+ GicQ==
X-Gm-Message-State: APjAAAV1eQW7kmP6oNsBrQk5WOEH9W2VYiKew2IO+Jq6OwMvjqiFiaXR vO9bGhQlva6s/UkjHleIsquW4uWOrlG51wz1XGCLqFdbLw==
X-Google-Smtp-Source: APXvYqw63lmzoLo3f0e3gnf/HW9NbNqNrpZ0YVr/uSG1vexvJ1biLcQPJDkCElq7jtgqWfvq9PNcSkARk4YRXrQqu40=
X-Received: by 2002:a25:6f02:: with SMTP id k2mr24768620ybc.254.1579193053657;  Thu, 16 Jan 2020 08:44:13 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
In-Reply-To: <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
From: Filip Skokan 
Date: Thu, 16 Jan 2020 17:44:02 +0100
Message-ID: 
To: Neil Madden 
Cc: Torsten Lodderstedt ,  Nat Sakimura , oauth ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="000000000000fec29e059c4488ee"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:44:20 -0000

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

A 30x redirect to what is designed to be an authenticated backend client
call? Doesn't seem right to me.

S pozdravem,
*Filip Skokan*


On Thu, 16 Jan 2020 at 17:37, Neil Madden  wrote=
:

> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the Location header? That way the AS can
> decide for itself how to communicate any id from the PAR endpoint to the
> authorization endpoint.
>
> This also has the side effect that you can kick off an OAuth2 flow with a
> simple HTML form pointed at the PAR endpoint (with hidden fields for
> state/code_challenge etc).
>
> If actually performing the redirect is a bit problematic then at least th=
e
> idea of returning a full URL for the authorization endpoint (hyperlink)
> rather than returning an id/URI and requiring the client to construct one
> seems reasonable to me and would seem to avoid some of the difficulties
> being discussed with JAR etc as the exact mechanism of communication
> becomes an implementation detail that the client needn't know about.
>
> -- Neil
>
> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <
> torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to come b=
ack to go
> through another round anyway thanks to the breaking changes the IESG push=
ed
> into it after it left WGLC.
>
> I=E2=80=99d rather see us get this right than publish something many of u=
s think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  =E2=80=94 Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richanna@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document=
.
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can=E2=80=
=99t fix
> the draft that hasn=E2=80=99t actually been published yet.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that
> we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or=
 something of that nature. But if
> we call the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of req=
uest_uri =E2=80=9Cthing X=E2=80=9D
> in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believ=
e
> that=E2=80=99s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  =E2=80=94 Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint a=
nd
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or oth=
er
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end=
.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, witho=
ut
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
> Vladimir
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it=E2=80=99s a JWT and=
 instead
> say it=E2=80=99s a request object. Or we define a new term for this autho=
rization
> request blob thing.
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remote=
 protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That=E2=
=80=99s
> where the real interop concerns come in.
>
>  =E2=80=94 Justin
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> Correct. The problem becomes pretty clear in the context of PAR, where th=
e
> AS is generating and vending out the URI at the PAR endpoint, and consumi=
ng
> it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
> If we assume the client posts a JAR and gets back a reference.  Then the
> reference is to a JAR.
>
> I think I see the problem.  If the server providing the reference is
> associated with the AS then the server dosen't need to dereference the
> object via HTTP, so it could be a URN as an example.
>
> So yes it is not a interoperability issue for the client.
>
> I will think about how I can finesse that.
>
> I agree it is not a change in intent.
>
> I will see if I can get our AD to accept that.
>
> John B.
>
>
>
>
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
> wrote:
>
> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
>
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
>
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>     Hi,
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>     best regards,
>     Torsten.
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>     >
>     > Hi all,
>     >
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>     >
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>     >
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf..org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf..org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


A 30x redirect to what is designed to be an authentic=
ated backend client call? Doesn't seem right to me.

S pozdravem,
Filip Skokan


On Thu, 16 J=
an 2020 at 17:37, Neil Madden <neil.madden@forgerock.com> wrote:
Why =
not have the PAR endpoint return a 30x redirect with the full URL to the au=
thorization endpoint in the Location header? That way the AS can decide for=
 itself how to communicate any id from the PAR endpoint to the authorizatio=
n endpoint.

This also has the side effect that you can k=
ick off an OAuth2 flow with a simple HTML form pointed at the PAR endpoint =
(with hidden fields for state/code_challenge etc).

If actually performing the redirect is a bit problematic then at least the=
 idea of returning a full URL for the authorization endpoint (hyperlink) ra=
ther than returning an id/URI and requiring the client to construct one see=
ms reasonable to me and would seem to avoid some of the difficulties being =
discussed with JAR etc as the exact mechanism of communication becomes an i=
mplementation detail that the client needn't know about.

=

-- Neil



On 16 Jan 2020, at 16:25, Torsten L=
odderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrot=
e:

I just thought about an=
other option. What if we change PAR to not use the request_uri parameter bu=
t a new parameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri=
 was to make the life of clients easier since they can use the standard lib=
rary function for request objects to pass the PAR reference to the AS. Is t=
his worth the trouble?

=
Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BF+1 to this approach,=
 and it sounds like JAR might need to come back to go through another round=
 anyway thanks to the breaking changes the IESG pushed into it after it lef=
t WGLC.

I=E2=80=99d rather see us get this right than pu=
blish something many of us think is broken.=C2=A0

=
Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
<=
div>
=C2=A0=E2=80=94 Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <richanna@amazon.com=
> wrote:

The problem is the=
 JWT requirement in JAR, not how we talk about PAR request_uri values in PA=
R. We need to either change the language in JAR (see my suggestions elsewhe=
re in this thread), or add text in PAR that explicitly exempts PAR request_=
uri values (or preferably all AS-provided request_uri values) from this req=
uirement (also see my suggestions elsewhere in this thread).<=
/div>
=C2=A0
My preference remains th=
e former. It strikes me as bad form for one extension to override normative=
 requirements laid out in another document. Granted, the incompatibility sc=
enarios introduced by this retcon are edge-case at best, but that just rais=
es the question of why we can=E2=80=99t fix the draft that hasn=E2=80=99t a=
ctually been published yet.
=C2=A0
=E2=80=93=C2=A0
Annabelle Ric=
hard Backman
AWS Identity
=C2=A0
=C2=A0
From:=C2=
=A0OAuth <oauth-bounces@ietf.org> on behalf of Vladimir D=
zhuvinov <vladimir@connect2id.com=
>
Organization:=C2=A0Connect2id Ltd..
Date:=
=C2=A0Wednesday, January 15, 2020 at 12:34 PM
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0oau=
th <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <r=
ichanna=3D40amazon.com@dmarc.ietf.org>
Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must be=
come JWTs
=C2=A0
On 13/01/2020 19:32, Justin Richer wrote:
To be clear, I=E2=80=99m not saying we suggest a p=
articular form, and I agree that we shouldn=E2=80=99t specify that =E2=80=
=9Cit=E2=80=99s a JWT=E2=80=9D or something of that nature. But if we call =
the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =
=E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without say=
ing what =E2=80=9Cthing X=E2=80=9D needs to be in all cases.=C2=A0
Good, we're on the same page =
then.
How about simply saying that the result of PA=
R is an URI referencing the pushed authZ request; at the authZ endpoint its=
 processing is completed.
No need is both clear and=
 abstract enough to not require a form to be specified.
=

=C2=A0
In cases where you do a remote look=
 up, we want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.<=
/u>
But why?
Both PAR =
and authZ endpoints belong to the AS, which makes that impl specific. The U=
RI is the contract, between client and AS.
The AS, =
if uService based, could choose to implement that as CBOR Web Token, or som=
e other verifiable blob, resulting in the same essential function, and this=
 isn't affecting the client <-> AS contract in any way.=

=C2=A0
We had a case of similarl=
y unintentional limiting in JAR previously, saying that you had to do an HT=
TP lookup on the request_uri, but I believe that=E2=80=99s been backed off =
now and made conditional.
That w=
as precisely my point.
Vladimir
=

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


On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=C2=A0
=
My suggestion is to abstain from specifying the concrete form of the resour=
ce pointed to by the PAR URI. Regardless of URI type (URN, downloadable htt=
ps URL or something else), and even if the PAR endpoint and the authZ endpo=
int are managed by two different entities (microservice or other scenario).=

In the Connect2id implementation of PAR the r=
eturned URI doesn't point to a request object and it doesn't point =
to a JWT either. It points to an internally stored "pre-processed"=
; authZ request, which the authZ endpoint then picks up to complete the aut=
hZ.
Even if we eventually end up in microservi=
ce world, or allow the PAR endpoint to be managed by some external entity, =
the PAR URI - its interpretation, validation and potentially resource retri=
eval (JWT or other blob), is an "internal contract" on the AS sid=
e. This doesn't concern the client, and in OAuth 2.0 the role of AS is =
indivisible.
=C2=A0
I see PAR request + authZ request as one logical OAuth 2.0 authZ request=
: the client submits an authZ request and gets an authZ response at the end=
. The URI is necessary for the client to proceed from the 1st to the 2nd st=
ep. If we manage to frame / word the PAR URI in this logical way, without g=
etting stuck in the JAR definition / framing of what the request_uri / obje=
ct is, it would be great.
=C2=A0=

The normative language I think should focus on maintaining =
the OAuth 2.0 contract for the entire logical authZ request, together with =
the basic contracts of 1) JAR and the 2) authZ endpoint.
=C2=A0
Vladimir
=

=C2=A0
On 10/01/2020 22:55, Jus=
tin Richer wrote:
So we could solve this by sa=
ying the resulting data object of a PAR is a request object. Which might al=
so contain a request object internally as well. In that case JAR should bac=
k off from saying it=E2=80=99s a JWT and instead say it=E2=80=99s a request=
 object. Or we define a new term for this authorization request blob thing.=
=C2=A0
=C2=A0<=
/div>
Or PAR could at least say that if it=E2=80=99s de=
referenced over a remote protocol then it MUST be a JWT, but otherwise it c=
an be whatever you want. That=E2=80=99s where the real interop concerns com=
e in.
=C2=A0
=C2=A0=E2=80=94 Justin
=


On Jan 10, 2020, at 3:41 PM, Richard B=
ackman, Annabelle <ric=
hanna=3D40amazon.com@dmarc.ietf.org> wrote:
=C2=A0
Correct. The probl=
em becomes pretty clear in the context of PAR, where the AS is generating a=
nd vending out the URI at the PAR endpoint, and consuming it at the authori=
zation endpoint. From an interoperability standpoint, it=E2=80=99s analogou=
s to the AS vending an authorization code at the authorization endpoint and=
 consuming it at the token endpoint.
=E2=80=93=C2=A0
=

Annabelle Richard Backm=
an
AWS Identity
=C2=
=A0
=C2=A0
From:=C2=A0John Bradley <ve7jtb@ve7jtb.com<=
/a>>
Date:=C2=A0Friday, January 10, 2020 at 12:29=
 PM
To:=C2=A0Brian Campbell <bcampbell@pingidentity.com>
Cc:=C2=A0<=
/span>Torsten Lodderstedt <torste=
n@lodderstedt.net>, Nat Sakimura <nat=
@sakimura.org>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject:=C2=A0[=
UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs
=C2=A0=

If we assume the client posts a JAR a=
nd gets back a reference.=C2=A0 Then the reference is to a JAR.=C2=A0
=C2=A0
I think I see the problem.=C2=A0 If the server=
 providing the reference is associated with the AS then the server dosen=
9;t need to dereference the object via HTTP, so it could be a URN as an exa=
mple.=C2=A0
=C2=A0
So yes it is not a interopera=
bility issue for the client.=C2=A0=C2=A0
=C2=A0
I wil=
l think about how I can finesse that.=C2=A0
=

=C2=A0
I agree it is not a change in intent.=C2=A0
=C2=A0
I will see if I can get our AD to accept that.
=C2=A0
John B.=C2=A0
=C2=A0
=C2=A0
=

=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.co=
m> wrote:
Sure but the text proposed (or something like it)=
 qualifies it such that there aren't interoperability questions because=
 it's only an implementation detail to the AS who both produces the URI=
 and consumes its content.
=
=C2=A0
On Fri, Jan 10, 20=
20 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be =
a challenge to change text saying that the contents of the resource could b=
e something other than a request object.=C2=A0
=C2=A0
If not a request object then what and how is that interoperable are l=
ikely AD questions.=C2=A0
I could perhaps=
 see changing it to must be a request object, or other format defined by a =
profile.

John B.=C2=A0=C2=A0
=C2=A0
=C2=
=A0
On Fri, Jan 10, 2020,=
 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:=

Agree and agree. But given that the change suggested by Annabelle has no i=
mpact on the client or interoperability, perhaps Nat or John could work the=
 change into the draft during the edits that happen during the final stages=
 of things?
=C2=A0<=
/u>
On Thu, Jan 9, 2020 at 1:56 AM Tors=
ten Lodderstedt <torsten=3D<=
span style=3D"color:purple">40lodderstedt.net@dmarc.ietf.org>=
 wrote:
=

I would assume given the status of JAR, we don=E2=80=99t wan=
t to change it. And as I said, this difference does not impact interoperabi=
lity from client perspective.



Am 09.01.2020=
 um 00:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.iet=
f.org>:
It would be more appr=
opriate to add the text to JAR rather than PAR. It doesn't seem right f=
or PAR to retcon rules in JAR. Moving the text to JAR also highlights the w=
eirdness of giving PAR special treatment.
<=
div>
=C2=A0=

What if we changed this sentence in Section 5.2 of JA=
R:
The contents of the resource refe=
renced by the URI MUST be a Request
Object.
=C2=A0<=
/u>
To:=C2=A0
The contents of the resource referenced by the URI MUST be a Reques=
t<=
/span>
Object, unless the URI was provided to the client by the=
 Authorization
Server.
=C2=A0
=

Th=
is would allow for use cases such as an AS that provides pre-defined reques=
t URIs, or vends request URIs via a client management console, or bakes the=
m into their client apps.
=
=C2=A0
=E2=80=93=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">Annabelle Rich=
ard Backman
AWS Identity
=

=
=C2=A0
On 1/8/20, 2:50 PM, "Torsten Loddersted=
t" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:<=
u>
=C2=A0
=C2=A0=C2=A0=C2=A0 H=
i,=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0you are right, PAR does not req=
uire the AS to represent the request as a JWT-based request object. The URI=
 is used as internal reference only. That why the draft states
=C2=A0=C2=A0=C2=A0=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">=C2=A0=C2=A0=
=C2=A0=C2=A0"There is no need to make the
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization request d=
ata available to other parties via this
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0This difference matters from an AS implementation pers=
pective, it doesn't matter from a client's (interop) perspective.
=C2=A0=C2=A0=C2=A0=C2=A0<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0We may add a statement to PAR saying that=
 request_uris issued by the PAR mechanism (MAY) deviate from the JAR defini=
tion.
=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0best regards,
<=
div>
=C2=A0=C2=
=A0=C2=A0 Torsten.=C2=A0=C2=A0
=C2=A0=
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> On =
8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=3D40amazon.com@dmar=
c.ietf.org> wrote:
=C2=A0=C2=A0=C2=A0=
 >=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0&g=
t; Hi all,
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0> The current=
 drafts of PAR (-00) and JAR (-20) require that the AS transform all pushed=
 requests into JWTs. This requirement arises from the following:<=
/u>
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=A2 PAR uses the request_uri parameter defined in JAR to commu=
nicate the pushed request to the authorization endpoint.
=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=A2 According to JAR, the resource referenced by request_uri MUST be =
a Request Object. (Section 5.2)
=C2=A0=C2=A0=C2=A0 =
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 Request Object is=
 defined to be a JWT containing all the authorization request parameters. (=
Section 2.1)
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0> There is no=
 need for this requirement to support interoperability, as this is internal=
 to the AS. It is also inconsistent with the rest of JAR, which avoids atte=
mpting to define the internal communications between the two AS endpoints. =
Worse, this restriction makes it harder for the authorization endpoint to l=
everage validation and other work performed at the PAR endpoint, as the sta=
te or outcome of that work must be forced into the JWT format (or retrieved=
 via a subsequent service call or database lookup).
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=
=C2=A0=C2=A0=C2=A0=C2=A0> =E2=80=93=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0> Annabelle Richard Backman=

=C2=A0=C2=A0=C2=A0 > AWS Identity
<=
/div>
=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0> _______________________________________________
=C2=A0=C2=A0=C2=A0 > OAuth mailing list=

=C2=A0=C2=A0=C2=A0 >=C2=A0OAuth@ietf..org
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">=C2=A0=C2=A0=
=C2=A0=C2=A0
=
=C2=A0=C2=A0=C2=A0=C2=
=A0
_______________________________________________
OAuth mailing lis=
t
OAuth@ietf.org<=
/span>
https://www.ietf.org/mailman/listinfo/oauth=


CONFIDE=
NTIALITY NOTICE: This email may contain confidential and privileged materia=
l for the sole use of the intended recipient(s). Any review, use, distribut=
ion or disclosure by others is strictly prohibited.=C2=A0 If you have recei=
ved this communication in error, please notify the sender immediately by e-=
mail and delete the message and any file attachments from your computer. Th=
ank you.
<=
/div>

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

_______________________________________________<=
br>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/m=
ailman/listinfo/oauth
-- 
Vladimir Dzhuvinov
=C2=A0
=

-- 
Vladimir Dzhuvinov

__________________________=
_____________________
OAuth mailing list
OAuth@ietf.org=

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

_____________________________________________=
__

OAuth mailing list

OAuth@ietf.org

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



--000000000000fec29e059c4488ee--


From nobody Thu Jan 16 08:55: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 B7277120AB5 for ; Thu, 16 Jan 2020 08:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1z5A3FsGkxgP for ; Thu, 16 Jan 2020 08:55:24 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CBE120A9E for ; Thu, 16 Jan 2020 08:55:24 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00GGt52b002202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 11:55:09 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer 
In-Reply-To: <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com>
Date: Thu, 16 Jan 2020 11:55:05 -0500
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 16:55:30 -0000

Well that=E2=80=99s what I=E2=80=99m saying =E2=80=94 we could have had =
restrictions within JWK (and maybe even a different syntax) that would =
guarantee a unique key ID, as well as ways to talk about it from the =
outside.=20

 =E2=80=94 Justin

> On Jan 15, 2020, at 3:53 PM, Vladimir Dzhuvinov =
 wrote:
>=20
> On 14/01/2020 04:25, Justin Richer wrote:
>> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on a =
URL-based addressing
>> format for individual keys within the set, but that ship=E2=80=99s =
sailed.
>=20
> For querying / selecting JWKs from a set this would have been a useful
> addition to the spec.
>=20
> But I don't see how such an URL can help us to identify a single JWK =
in
> a set, given the possibility to have multiple JWKs with the same =
"kid".
>=20
> I.e. if we do "https://example.com/jwks.json?kid=3Dxyz", there is no
> guarantee for a single key. Even if we add additional query params, =
like
> use, alg, etc, none of them guarantees a unique JWK identification.
>=20
> I like the utility of that though.
>=20
> Vladimir
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jan 16 09:13:33 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 BD823120B01 for ; Thu, 16 Jan 2020 09:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 yvTdp4jKrcYC for ; Thu, 16 Jan 2020 09:13:26 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B3E1200F9 for ; Thu, 16 Jan 2020 09:13:26 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id y17so19970622wrh.5 for ; Thu, 16 Jan 2020 09:13:26 -0800 (PST)
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=LgQ3WDnOMgyi92e+57eL+pGfLYbjIw/X8bF4RtoccT0=; b=VMfoMSvJ2mD2YCEYZOmhDPk5vmlzP980b2RamKiuBA/ZIdaR0xMPN6GgeJSk9v8NSi 5oXvg7ILSPtxJ6CMHlDlAd7oY8735vA7eOB0LP3NgIYmxhcTLGo1QZOyP64HUaf5OKBQ d1r5DiBG/YwQM8in7aIOzcslfCQ1L6ppoBFWs=
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=LgQ3WDnOMgyi92e+57eL+pGfLYbjIw/X8bF4RtoccT0=; b=BY60LMEk0hjrIe6ZRWatstbd+5alwhvwZtafC0GmdoEYcZjf8Y9SVnOMXWtS+7wcjq LKVY3Z1kGC+z+KjU+IBsWyIAHuNHKUTK1LEzXcx3+6464wSLSpYnfIBEQmB+dttiRndl A5DY4F/aFR1ds6p6ozaIj03MNWWNeC8O1C/q/uadhcHM2YcR0Mk7Y9nDvVy8a0oHt1Jc xAsMERZ4xaM8S5PJQGaMJPltQNBOLTXrRQReiQ3iu+LaMuLqq4N+rpnGUz1cc9aNzXVT ss5j+X1RijDboV5JPVBbHP5XekfSIHUXNmsWYvMKCiCZdx0UbBriiyDLj2u43Kcy1xxq XOpQ==
X-Gm-Message-State: APjAAAUN9tY2IU1cEHIAamkDNXz2IZ0fYlYb6lHeTH1XU8rehgNoIH3G SOrJdZgKI090LQu2Mr8gJXcboQ==
X-Google-Smtp-Source: APXvYqwTxRZ0+UaRaaGXztiGHizzwFDxIu4Fq3RIU3U8HuuewHYz/QEFS+uBYt9pbMoPCSOVD+ATdA==
X-Received: by 2002:adf:e58b:: with SMTP id l11mr602226wrm.402.1579194804318;  Thu, 16 Jan 2020 09:13:24 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id h2sm31507715wrt.45.2020.01.16.09.13.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 09:13:21 -0800 (PST)
From: Neil Madden 
Message-Id: <7F3C64DB-EFB6-4D3D-92D4-0B6FF4A243E8@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F30917A-74AD-4BC6-ACC6-0EACFE508EE1"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 16 Jan 2020 17:13:21 +0000
In-Reply-To: 
Cc: Torsten Lodderstedt , Nat Sakimura , oauth , "Richard Backman, Annabelle" 
To: Filip Skokan 
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com> 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 17:13:32 -0000

--Apple-Mail=_6F30917A-74AD-4BC6-ACC6-0EACFE508EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Well I don't think PAR is limited to confidential clients, but also =
there are client authentication methods that would make sense in this =
scenario, e.g. JWT-based client_assertion authentication with a =
short-lived/replay-protected JWT.

This cuts out the need for an extra HTTP call on the server side. The =
trade-off is that the parameters can still be tampered with in the =
user-agent, but you still get the other benefits listed in the PAR =
draft:
- The client is authenticated up-front before the user authorization is =
performed
- The authorization request parameters are not exposed in URL query =
strings (in logs, Referer headers etc)
- Any size restrictions on query parameters are avoided

I'm not 100% convinced myself that a redirect is a good idea, but if the =
AS is exposing an endpoint that accepts POST requests with form-encoded =
parameters, then as a developer it seems perfectly reasonable to expect =
to be able to post a form to it. Maybe we could make that do something =
useful? If the intention is to rule out this kind of usage, then perhaps =
the payload should be defined to be JSON.

-- Neil

> On 16 Jan 2020, at 16:44, Filip Skokan  wrote:
>=20
> A 30x redirect to what is designed to be an authenticated backend =
client call? Doesn't seem right to me.
>=20
> S pozdravem,
> Filip Skokan
>=20
>=20
> On Thu, 16 Jan 2020 at 17:37, Neil Madden > wrote:
> Why not have the PAR endpoint return a 30x redirect with the full URL =
to the authorization endpoint in the Location header? That way the AS =
can decide for itself how to communicate any id from the PAR endpoint to =
the authorization endpoint.
>=20
> This also has the side effect that you can kick off an OAuth2 flow =
with a simple HTML form pointed at the PAR endpoint (with hidden fields =
for state/code_challenge etc).
>=20
> If actually performing the redirect is a bit problematic then at least =
the idea of returning a full URL for the authorization endpoint =
(hyperlink) rather than returning an id/URI and requiring the client to =
construct one seems reasonable to me and would seem to avoid some of the =
difficulties being discussed with JAR etc as the exact mechanism of =
communication becomes an implementation detail that the client needn't =
know about.
>=20
> -- Neil
>=20
>> On 16 Jan 2020, at 16:25, Torsten Lodderstedt =
> wrote:
>>=20
>> I just thought about another option. What if we change PAR to not use =
the request_uri parameter but a new parameter, e.g. request_id?
>>=20
>> That would decouple both specs. The reason why we use request_uri was =
to make the life of clients easier since they can use the standard =
library function for request objects to pass the PAR reference to the =
AS. Is this worth the trouble?
>>=20
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer >:
>>>=20
>>> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to =
come back to go through another round anyway thanks to the breaking =
changes the IESG pushed into it after it left WGLC.
>>>=20
>>> I=E2=80=99d rather see us get this right than publish something many =
of us think is broken.=20
>>>=20
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
> wrote:
>>>>=20
>>>> The problem is the JWT requirement in JAR, not how we talk about =
PAR request_uri values in PAR. We need to either change the language in =
JAR (see my suggestions elsewhere in this thread), or add text in PAR =
that explicitly exempts PAR request_uri values (or preferably all =
AS-provided request_uri values) from this requirement (also see my =
suggestions elsewhere in this thread).
>>>> =20
>>>> My preference remains the former. It strikes me as bad form for one =
extension to override normative requirements laid out in another =
document. Granted, the incompatibility scenarios introduced by this =
retcon are edge-case at best, but that just raises the question of why =
we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been =
published yet.
>>>> =20
>>>> =E2=80=93=20
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>> =20
>>>> =20
>>>> From: OAuth > on behalf of Vladimir Dzhuvinov =
>
>>>> Organization: Connect2id Ltd..
>>>> Date: Wednesday, January 15, 2020 at 12:34 PM
>>>> To: Justin Richer >
>>>> Cc: oauth >, Nat Sakimura =
>, "Richard Backman, =
Annabelle" >
>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed =
requests must become JWTs
>>>> =20
>>>> On 13/01/2020 19:32, Justin Richer wrote:
>>>>> To be clear, I=E2=80=99m not saying we suggest a particular form, =
and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s =
a JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases.=20
>>>> Good, we're on the same page then.
>>>> How about simply saying that the result of PAR is an URI =
referencing the pushed authZ request; at the authZ endpoint its =
processing is completed.
>>>> No need is both clear and abstract enough to not require a form to =
be specified.
>>>> =20
>>>>> In cases where you do a remote look up, we want =E2=80=9Cthing =
X=E2=80=9D to be formatted as a JWT.
>>>> But why?
>>>> Both PAR and authZ endpoints belong to the AS, which makes that =
impl specific. The URI is the contract, between client and AS.
>>>> The AS, if uService based, could choose to implement that as CBOR =
Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS contract =
in any way.
>>>> =20
>>>>> We had a case of similarly unintentional limiting in JAR =
previously, saying that you had to do an HTTP lookup on the request_uri, =
but I believe that=E2=80=99s been backed off now and made conditional.
>>>> That was precisely my point.
>>>> Vladimir
>>>> =20
>>>> =20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>>=20
>>>>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov =
> wrote:
>>>>>> =20
>>>>>> My suggestion is to abstain from specifying the concrete form of =
the resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
>>>>>> In the Connect2id implementation of PAR the returned URI doesn't =
point to a request object and it doesn't point to a JWT either. It =
points to an internally stored "pre-processed" authZ request, which the =
authZ endpoint then picks up to complete the authZ.
>>>>>> Even if we eventually end up in microservice world, or allow the =
PAR endpoint to be managed by some external entity, the PAR URI - its =
interpretation, validation and potentially resource retrieval (JWT or =
other blob), is an "internal contract" on the AS side. This doesn't =
concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>>>>> =20
>>>>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ =
request: the client submits an authZ request and gets an authZ response =
at the end. The URI is necessary for the client to proceed from the 1st =
to the 2nd step. If we manage to frame / word the PAR URI in this =
logical way, without getting stuck in the JAR definition / framing of =
what the request_uri / object is, it would be great.
>>>>>> =20
>>>>>> The normative language I think should focus on maintaining the =
OAuth 2.0 contract for the entire logical authZ request, together with =
the basic contracts of 1) JAR and the 2) authZ endpoint.
>>>>>> =20
>>>>>> Vladimir
>>>>>> =20
>>>>>> On 10/01/2020 22:55, Justin Richer wrote:
>>>>>>> So we could solve this by saying the resulting data object of a =
PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing.=20
>>>>>>> =20
>>>>>>> Or PAR could at least say that if it=E2=80=99s dereferenced over =
a remote protocol then it MUST be a JWT, but otherwise it can be =
whatever you want. That=E2=80=99s where the real interop concerns come =
in.
>>>>>>> =20
>>>>>>>  =E2=80=94 Justin
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
> wrote:
>>>>>>>> =20
>>>>>>>> Correct. The problem becomes pretty clear in the context of =
PAR, where the AS is generating and vending out the URI at the PAR =
endpoint, and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
>>>>>>>> =E2=80=93=20
>>>>>>>> Annabelle Richard Backman
>>>>>>>> AWS Identity
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> From: John Bradley >
>>>>>>>> Date: Friday, January 10, 2020 at 12:29 PM
>>>>>>>> To: Brian Campbell >
>>>>>>>> Cc: Torsten Lodderstedt >, Nat Sakimura >, "Richard Backman, Annabelle" =
>, oauth =
>
>>>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed =
requests must become JWTs
>>>>>>>> =20
>>>>>>>> If we assume the client posts a JAR and gets back a reference.  =
Then the reference is to a JAR.=20
>>>>>>>> =20
>>>>>>>> I think I see the problem.  If the server providing the =
reference is associated with the AS then the server dosen't need to =
dereference the object via HTTP, so it could be a URN as an example.=20
>>>>>>>> =20
>>>>>>>> So yes it is not a interoperability issue for the client. =20
>>>>>>>> =20
>>>>>>>> I will think about how I can finesse that.=20
>>>>>>>> =20
>>>>>>>> I agree it is not a change in intent.=20
>>>>>>>> =20
>>>>>>>> I will see if I can get our AD to accept that.
>>>>>>>> =20
>>>>>>>> John B.=20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>>>>>>>>> Sure but the text proposed (or something like it) qualifies it =
such that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>>>>>>>>> =20
>>>>>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley =
> wrote:
>>>>>>>>>> It may be a challenge to change text saying that the contents =
of the resource could be something other than a request object.=20
>>>>>>>>>> =20
>>>>>>>>>> If not a request object then what and how is that =
interoperable are likely AD questions.=20
>>>>>>>>>> =20
>>>>>>>>>> I could perhaps see changing it to must be a request object, =
or other format defined by a profile.
>>>>>>>>>>=20
>>>>>>>>>> John B. =20
>>>>>>>>>> =20
>>>>>>>>>> =20
>>>>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>>>>>>>>> Agree and agree. But given that the change suggested by =
Annabelle has no impact on the client or interoperability, perhaps Nat =
or John could work the change into the draft during the edits that =
happen during the final stages of things?
>>>>>>>>>>> =20
>>>>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t =
want to change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> It would be more appropriate to add the text to JAR rather =
than PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving =
the text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>>> Object.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> To:=20
>>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>>>>>>>> Server.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> =E2=80=93=20
>>>>>>>>>>>>> Annabelle Richard Backman
>>>>>>>>>>>>> AWS Identity
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>>>>>>>>> =20
>>>>>>>>>>>>>     Hi,=20
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     you are right, PAR does not require the AS to =
represent the request as a JWT-based request object. The URI is used as =
internal reference only. That why the draft states
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     "There is no need to make the
>>>>>>>>>>>>>           authorization request data available to other =
parties via this
>>>>>>>>>>>>>           URI.=E2=80=9D
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     We may add a statement to PAR saying that request_uris =
issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     best regards,
>>>>>>>>>>>>>     Torsten. =20
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>>>>>>>>     >=20
>>>>>>>>>>>>>     > Hi all,
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) =
require that the AS transform all pushed requests into JWTs. This =
requirement arises from the following:
>>>>>>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>>>>>>>>     >         =E2=80=A2 According to JAR, the resource =
referenced by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a =
JWT containing all the authorization request parameters. (Section 2.1)
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > =E2=80=93=20
>>>>>>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>>>>>>     > AWS Identity
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > _______________________________________________
>>>>>>>>>>>>>     > OAuth mailing list
>>>>>>>>>>>>>     > OAuth@ietf..org 
>>>>>>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>>>>> =20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf..org 
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =
--=20
>>>>>> Vladimir Dzhuvinov
>>>>>=20
>>>>> =20
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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



--Apple-Mail=_6F30917A-74AD-4BC6-ACC6-0EACFE508EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Well =
I don't think PAR is limited to confidential clients, but also there are =
client authentication methods that would make sense in this scenario, =
e.g. JWT-based client_assertion authentication with a =
short-lived/replay-protected JWT.

This cuts out the need for an extra HTTP call on the =
server side. The trade-off is that the parameters can still be tampered =
with in the user-agent, but you still get the other benefits listed in =
the PAR draft:
- The client is authenticated up-front before =
the user authorization is performed
- The authorization =
request parameters are not exposed in URL query strings (in logs, =
Referer headers etc)
- Any size restrictions on query =
parameters are avoided

I'm not 100% =
convinced myself that a redirect is a good idea, but if the AS is =
exposing an endpoint that accepts POST requests with form-encoded =
parameters, then as a developer it seems perfectly reasonable to expect =
to be able to post a form to it. Maybe we could make that do something =
useful? If the intention is to rule out this kind of usage, then perhaps =
the payload should be defined to be JSON.

-- Neil

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



=

--Apple-Mail=_6F30917A-74AD-4BC6-ACC6-0EACFE508EE1--


From nobody Thu Jan 16 09:33: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 9BE0912087E for ; Thu, 16 Jan 2020 09:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waOq4nXnY0xC for ; Thu, 16 Jan 2020 09:33:29 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C871208A5 for ; Thu, 16 Jan 2020 09:33:28 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00GHXJmr015907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 12:33:20 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D650DAB-93E3-4CA4-8CFD-DF773CE36571"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 16 Jan 2020 12:33:19 -0500
In-Reply-To: <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
Cc: Torsten Lodderstedt , oauth , Nat Sakimura , "Richard Backman, Annabelle" 
To: Neil Madden 
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 17:33:34 -0000

--Apple-Mail=_9D650DAB-93E3-4CA4-8CFD-DF773CE36571
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

What you=E2=80=99ve described is exactly what happens in XYZ:

https://oauth.xyz/interaction/

And this is what we=E2=80=99re discussing as the basis in TxAuth. But in =
this case since you=E2=80=99re stuck with OAuth 2=E2=80=99s =
authorization endpoint syntax and semantics, you=E2=80=99re still =
limited with what=E2=80=99s happening there and it could come with its =
own security oddities (like maybe a new form of a mixup attack?) that we =
haven=E2=80=99t figured out yet. Like, is the AS allowed to send the =
client to something other than its own authorization endpoint? Is the =
client supposed to validate the syntax of the authorization endpoint URL =
against its discovery document? It deeply changes what OAuth 2 does, and =
that makes it really hard to add on.

Using request_uri to pass the artifact is clever, but I also like =
Torsten=E2=80=99s idea of using a new field defined by PAR to pass the =
artifact. Granted, in the Authlete implementation of PAR, we were able =
to re-use a whole bunch of code for processing request objects, and that =
was pretty nice. Still, the issues with JAR are non-zero, and so we need =
to figure out whether we should fully decouple or fix the issues. I=E2=80=99=
m in favor of fixing things and using these together, but there=E2=80=99s =
a lot of inertia against that.

 =E2=80=94 Justin

> On Jan 16, 2020, at 11:36 AM, Neil Madden  =
wrote:
>=20
> Why not have the PAR endpoint return a 30x redirect with the full URL =
to the authorization endpoint in the Location header? That way the AS =
can decide for itself how to communicate any id from the PAR endpoint to =
the authorization endpoint.
>=20
> This also has the side effect that you can kick off an OAuth2 flow =
with a simple HTML form pointed at the PAR endpoint (with hidden fields =
for state/code_challenge etc).
>=20
> If actually performing the redirect is a bit problematic then at least =
the idea of returning a full URL for the authorization endpoint =
(hyperlink) rather than returning an id/URI and requiring the client to =
construct one seems reasonable to me and would seem to avoid some of the =
difficulties being discussed with JAR etc as the exact mechanism of =
communication becomes an implementation detail that the client needn't =
know about.
>=20
> -- Neil
>=20
>> On 16 Jan 2020, at 16:25, Torsten Lodderstedt =
> wrote:
>>=20
>> I just thought about another option. What if we change PAR to not use =
the request_uri parameter but a new parameter, e.g. request_id?
>>=20
>> That would decouple both specs. The reason why we use request_uri was =
to make the life of clients easier since they can use the standard =
library function for request objects to pass the PAR reference to the =
AS. Is this worth the trouble?
>>=20
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer >:
>>>=20
>>> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to =
come back to go through another round anyway thanks to the breaking =
changes the IESG pushed into it after it left WGLC.
>>>=20
>>> I=E2=80=99d rather see us get this right than publish something many =
of us think is broken.=20
>>>=20
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
> wrote:
>>>>=20
>>>> The problem is the JWT requirement in JAR, not how we talk about =
PAR request_uri values in PAR. We need to either change the language in =
JAR (see my suggestions elsewhere in this thread), or add text in PAR =
that explicitly exempts PAR request_uri values (or preferably all =
AS-provided request_uri values) from this requirement (also see my =
suggestions elsewhere in this thread).
>>>> =20
>>>> My preference remains the former. It strikes me as bad form for one =
extension to override normative requirements laid out in another =
document. Granted, the incompatibility scenarios introduced by this =
retcon are edge-case at best, but that just raises the question of why =
we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been =
published yet.
>>>> =20
>>>> =E2=80=93=20
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>> =20
>>>> =20
>>>> From: OAuth > on behalf of Vladimir Dzhuvinov =
>
>>>> Organization: Connect2id Ltd..
>>>> Date: Wednesday, January 15, 2020 at 12:34 PM
>>>> To: Justin Richer >
>>>> Cc: oauth >, Nat Sakimura =
>, "Richard Backman, =
Annabelle" >
>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed =
requests must become JWTs
>>>> =20
>>>> On 13/01/2020 19:32, Justin Richer wrote:
>>>>> To be clear, I=E2=80=99m not saying we suggest a particular form, =
and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s =
a JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases.=20
>>>> Good, we're on the same page then.
>>>> How about simply saying that the result of PAR is an URI =
referencing the pushed authZ request; at the authZ endpoint its =
processing is completed.
>>>> No need is both clear and abstract enough to not require a form to =
be specified.
>>>> =20
>>>>> In cases where you do a remote look up, we want =E2=80=9Cthing =
X=E2=80=9D to be formatted as a JWT.
>>>> But why?
>>>> Both PAR and authZ endpoints belong to the AS, which makes that =
impl specific. The URI is the contract, between client and AS.
>>>> The AS, if uService based, could choose to implement that as CBOR =
Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS contract =
in any way.
>>>> =20
>>>>> We had a case of similarly unintentional limiting in JAR =
previously, saying that you had to do an HTTP lookup on the request_uri, =
but I believe that=E2=80=99s been backed off now and made conditional.
>>>> That was precisely my point.
>>>> Vladimir
>>>> =20
>>>> =20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>>=20
>>>>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov =
> wrote:
>>>>>> =20
>>>>>> My suggestion is to abstain from specifying the concrete form of =
the resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
>>>>>> In the Connect2id implementation of PAR the returned URI doesn't =
point to a request object and it doesn't point to a JWT either. It =
points to an internally stored "pre-processed" authZ request, which the =
authZ endpoint then picks up to complete the authZ.
>>>>>> Even if we eventually end up in microservice world, or allow the =
PAR endpoint to be managed by some external entity, the PAR URI - its =
interpretation, validation and potentially resource retrieval (JWT or =
other blob), is an "internal contract" on the AS side. This doesn't =
concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>>>>> =20
>>>>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ =
request: the client submits an authZ request and gets an authZ response =
at the end. The URI is necessary for the client to proceed from the 1st =
to the 2nd step. If we manage to frame / word the PAR URI in this =
logical way, without getting stuck in the JAR definition / framing of =
what the request_uri / object is, it would be great.
>>>>>> =20
>>>>>> The normative language I think should focus on maintaining the =
OAuth 2.0 contract for the entire logical authZ request, together with =
the basic contracts of 1) JAR and the 2) authZ endpoint.
>>>>>> =20
>>>>>> Vladimir
>>>>>> =20
>>>>>> On 10/01/2020 22:55, Justin Richer wrote:
>>>>>>> So we could solve this by saying the resulting data object of a =
PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing.=20
>>>>>>> =20
>>>>>>> Or PAR could at least say that if it=E2=80=99s dereferenced over =
a remote protocol then it MUST be a JWT, but otherwise it can be =
whatever you want. That=E2=80=99s where the real interop concerns come =
in.
>>>>>>> =20
>>>>>>>  =E2=80=94 Justin
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
> wrote:
>>>>>>>> =20
>>>>>>>> Correct. The problem becomes pretty clear in the context of =
PAR, where the AS is generating and vending out the URI at the PAR =
endpoint, and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
>>>>>>>> =E2=80=93=20
>>>>>>>> Annabelle Richard Backman
>>>>>>>> AWS Identity
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> From: John Bradley >
>>>>>>>> Date: Friday, January 10, 2020 at 12:29 PM
>>>>>>>> To: Brian Campbell >
>>>>>>>> Cc: Torsten Lodderstedt >, Nat Sakimura >, "Richard Backman, Annabelle" =
>, oauth =
>
>>>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed =
requests must become JWTs
>>>>>>>> =20
>>>>>>>> If we assume the client posts a JAR and gets back a reference.  =
Then the reference is to a JAR.=20
>>>>>>>> =20
>>>>>>>> I think I see the problem.  If the server providing the =
reference is associated with the AS then the server dosen't need to =
dereference the object via HTTP, so it could be a URN as an example.=20
>>>>>>>> =20
>>>>>>>> So yes it is not a interoperability issue for the client. =20
>>>>>>>> =20
>>>>>>>> I will think about how I can finesse that.=20
>>>>>>>> =20
>>>>>>>> I agree it is not a change in intent.=20
>>>>>>>> =20
>>>>>>>> I will see if I can get our AD to accept that.
>>>>>>>> =20
>>>>>>>> John B.=20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>>>>>>>>> Sure but the text proposed (or something like it) qualifies it =
such that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>>>>>>>>> =20
>>>>>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley =
> wrote:
>>>>>>>>>> It may be a challenge to change text saying that the contents =
of the resource could be something other than a request object.=20
>>>>>>>>>> =20
>>>>>>>>>> If not a request object then what and how is that =
interoperable are likely AD questions.=20
>>>>>>>>>> =20
>>>>>>>>>> I could perhaps see changing it to must be a request object, =
or other format defined by a profile.
>>>>>>>>>>=20
>>>>>>>>>> John B. =20
>>>>>>>>>> =20
>>>>>>>>>> =20
>>>>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>>>>>>>>> Agree and agree. But given that the change suggested by =
Annabelle has no impact on the client or interoperability, perhaps Nat =
or John could work the change into the draft during the edits that =
happen during the final stages of things?
>>>>>>>>>>> =20
>>>>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t =
want to change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> It would be more appropriate to add the text to JAR rather =
than PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving =
the text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>>> Object.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> To:=20
>>>>>>>>>>>>> The contents of the resource referenced by the URI MUST be =
a Request
>>>>>>>>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>>>>>>>> Server.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> =E2=80=93=20
>>>>>>>>>>>>> Annabelle Richard Backman
>>>>>>>>>>>>> AWS Identity
>>>>>>>>>>>>> =20
>>>>>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>>>>>>>>> =20
>>>>>>>>>>>>>     Hi,=20
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     you are right, PAR does not require the AS to =
represent the request as a JWT-based request object. The URI is used as =
internal reference only. That why the draft states
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     "There is no need to make the
>>>>>>>>>>>>>           authorization request data available to other =
parties via this
>>>>>>>>>>>>>           URI.=E2=80=9D
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     We may add a statement to PAR saying that request_uris =
issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     best regards,
>>>>>>>>>>>>>     Torsten. =20
>>>>>>>>>>>>>    =20
>>>>>>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>>>>>>>>     >=20
>>>>>>>>>>>>>     > Hi all,
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) =
require that the AS transform all pushed requests into JWTs. This =
requirement arises from the following:
>>>>>>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>>>>>>>>     >         =E2=80=A2 According to JAR, the resource =
referenced by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a =
JWT containing all the authorization request parameters. (Section 2.1)
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > =E2=80=93=20
>>>>>>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>>>>>>     > AWS Identity
>>>>>>>>>>>>>     > =20
>>>>>>>>>>>>>     > _______________________________________________
>>>>>>>>>>>>>     > OAuth mailing list
>>>>>>>>>>>>>     > OAuth@ietf..org 
>>>>>>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>>>>> =20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf..org 
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =
--=20
>>>>>> Vladimir Dzhuvinov
>>>>>=20
>>>>> =20
>>>> --=20
>>>> Vladimir Dzhuvinov
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_9D650DAB-93E3-4CA4-8CFD-DF773CE36571
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

What =
you=E2=80=99ve described is exactly what happens in XYZ:

https://oauth.xyz/interaction/

And this is what we=E2=80=99re =
discussing as the basis in TxAuth. But in this case since you=E2=80=99re =
stuck with OAuth 2=E2=80=99s authorization endpoint syntax and =
semantics, you=E2=80=99re still limited with what=E2=80=99s happening =
there and it could come with its own security oddities (like maybe a new =
form of a mixup attack?) that we haven=E2=80=99t figured out yet. Like, =
is the AS allowed to send the client to something other than its own =
authorization endpoint? Is the client supposed to validate the syntax of =
the authorization endpoint URL against its discovery document? It deeply =
changes what OAuth 2 does, and that makes it really hard to add =
on.

Using =
request_uri to pass the artifact is clever, but I also like Torsten=E2=80=99=
s idea of using a new field defined by PAR to pass the artifact. =
Granted, in the Authlete implementation of PAR, we were able to re-use a =
whole bunch of code for processing request objects, and that was pretty =
nice. Still, the issues with JAR are non-zero, and so we need to figure =
out whether we should fully decouple or fix the issues. I=E2=80=99m in =
favor of fixing things and using these together, but there=E2=80=99s a =
lot of inertia against that.

 =E2=80=94 Justin

On Jan 16, 2020, at 11:36 AM, Neil Madden <neil.madden@forgerock.com> wrote:



Why not have the PAR =
endpoint return a 30x redirect with the full URL to the authorization =
endpoint in the Location header? That way the AS can decide for itself =
how to communicate any id from the PAR endpoint to the authorization =
endpoint.

This also =
has the side effect that you can kick off an OAuth2 flow with a simple =
HTML form pointed at the PAR endpoint (with hidden fields for =
state/code_challenge etc).

If actually performing the redirect is a bit problematic then =
at least the idea of returning a full URL for the authorization endpoint =
(hyperlink) rather than returning an id/URI and requiring the client to =
construct one seems reasonable to me and would seem to avoid some of the =
difficulties being discussed with JAR etc as the exact mechanism of =
communication becomes an implementation detail that the client needn't =
know about.

-- =
Neil



On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> =
wrote:

I just thought about =
another option. What if we change PAR to not use the request_uri =
parameter but a new parameter, e.g. request_id?

That would =
decouple both specs. The reason why we use request_uri was to make the =
life of clients easier since they can use the standard library function =
for request objects to pass the PAR reference to the AS. Is this worth =
the trouble?

Am 16.01.2020 um 16:48 schrieb Justin Richer =
<jricher@mit.edu>:

=EF=BB=BF+1 to this approach, and it sounds like =
JAR might need to come back to go through another round anyway thanks to =
the breaking changes the IESG pushed into it after it left WGLC.

I=E2=80=99d rather see =
us get this right than publish something many of us think is =
broken. 

Maybe PAR and JAR (and JARM?) end up going out as a bundle of =
specs.

 =E2=
=80=94 Justin

On Jan 15, 2020, at 8:30 PM, =
Richard Backman, Annabelle <richanna@amazon.com> wrote:

The =
problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
 
My preference remains the former. It =
strikes me as bad form for one extension to override normative =
requirements laid out in another document. Granted, the incompatibility =
scenarios introduced by this retcon are edge-case at best, but that just =
raises the question of why we can=E2=80=99t fix the draft that hasn=E2=80=99=
t actually been published yet.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> =
on behalf of Vladimir Dzhuvinov <vladimir@connect2id.com>Organization: Connect2id Ltd..
Date: Wednesday, January 15, =
2020 at 12:34 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>, Nat =
Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] =
[UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
 
On 13/01/2020 19:32, Justin Richer =
wrote:
To be clear, I=E2=80=99m not saying we suggest a particular =
form, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=
=99s a JWT=E2=80=9D or something of that nature. But if we call the =
result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =
=E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without =
saying what =E2=80=9Cthing X=E2=80=9D needs to be in all cases. 
Good, we're on the =
same page then.
How about =
simply saying that the result of PAR is an URI referencing the pushed =
authZ request; at the authZ endpoint its processing is completed.
No need is both clear and =
abstract enough to not require a form to be specified.
 
In cases where you do a remote look up, =
we want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.
But why?
Both PAR and authZ endpoints =
belong to the AS, which makes that impl specific. The URI is the =
contract, between client and AS.
The AS, if uService based, could choose to implement that as =
CBOR Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS =
contract in any way.
 
We had a case of similarly =
unintentional limiting in JAR previously, saying that you had to do an =
HTTP lookup on the request_uri, but I believe that=E2=80=99s been backed =
off now and made conditional.
That was =
precisely my point.
Vladimir
 
 
 =E2=80=94 Justin


On Jan 11, 2020, at 5:28 AM, Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:
 
My suggestion is to abstain from =
specifying the concrete form of the resource pointed to by the PAR URI. =
Regardless of URI type (URN, downloadable https URL or something else), =
and even if the PAR endpoint and the authZ endpoint are managed by two =
different entities (microservice or other scenario).
In the =
Connect2id implementation of PAR the returned URI doesn't point to a =
request object and it doesn't point to a JWT either. It points to an =
internally stored "pre-processed" authZ request, which the authZ =
endpoint then picks up to complete the authZ.
Even if =
we eventually end up in microservice world, or allow the PAR endpoint to =
be managed by some external entity, the PAR URI - its interpretation, =
validation and potentially resource retrieval (JWT or other blob), is an =
"internal contract" on the AS side. This doesn't concern the client, and =
in OAuth 2.0 the role of AS is indivisible.
 
I see PAR =
request + authZ request as one logical OAuth 2.0 authZ request: the =
client submits an authZ request and gets an authZ response at the end. =
The URI is necessary for the client to proceed from the 1st to the 2nd =
step. If we manage to frame / word the PAR URI in this logical way, =
without getting stuck in the JAR definition / framing of what the =
request_uri / object is, it would be great.
 
The =
normative language I think should focus on maintaining the OAuth 2.0 =
contract for the entire logical authZ request, together with the basic =
contracts of 1) JAR and the 2) authZ endpoint.
 
Vladimir
 
On 10/01/2020 22:55, Justin Richer =
wrote:
So we could solve this by saying the resulting data object of =
a PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing. 
 
Or PAR could at least say that if =
it=E2=80=99s dereferenced over a remote protocol then it MUST be a JWT, =
but otherwise it can be whatever you want. That=E2=80=99s where the real =
interop concerns come in.
 
 =E2=80=94 Justin


On Jan 10, 2020, at 3:41 PM, Richard =
Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
Correct. The problem becomes pretty =
clear in the context of PAR, where the AS is generating and vending out =
the URI at the PAR endpoint, and consuming it at the authorization =
endpoint. =46rom an interoperability standpoint, it=E2=80=99s analogous =
to the AS vending an authorization code at the authorization endpoint =
and consuming it at the token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, =
2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt =
<torsten@lodderstedt.net>, =
Nat Sakimura <nat@sakimura.org>, =
"Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: =
[OAUTH-WG] PAR: pushed requests must become JWTs
 
If we assume the client =
posts a JAR and gets back a reference.  Then the reference is to a =
JAR. 
 
I think I see the problem.  If the =
server providing the reference is associated with the AS then the server =
dosen't need to dereference the object via HTTP, so it could be a URN as =
an example. 
 
So yes it is not a interoperability =
issue for the client.  
 
I will think about how I can finesse =
that. 
 
I agree it is not a change in =
intent. 
 
I will see if I can get our AD to =
accept that.
 
John B. 
 
 
 
 
On Fri, Jan 10, 2020, 4:57 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Sure but the text proposed (or =
something like it) qualifies it such that there aren't interoperability =
questions because it's only an implementation detail to the AS who both =
produces the URI and consumes its content.
 
On Fri, =
Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a challenge to =
change text saying that the contents of the resource could be something =
other than a request object. 
 
If not a request object then what and =
how is that interoperable are likely AD questions. 
 
I could perhaps see changing it to must =
be a request object, or other format defined by a profile.

John B.  
 
 
On Fri, Jan 10, 2020, 3:45 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree and agree. But given =
that the change suggested by Annabelle has no impact on the client or =
interoperability, perhaps Nat or John could work the change into the =
draft during the edits that happen during the final stages of =
things?
 
On Thu, Jan 9, 2020 at =
1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the =
status of JAR, we don=E2=80=99t want to change it. And as I said, this =
difference does not impact interoperability from client perspective.



Am 09.01.2020 um 00:58 schrieb =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:
It would be =
more appropriate to add the text to JAR rather than PAR. It doesn't seem =
right for PAR to retcon rules in JAR. Moving the text to JAR also =
highlights the weirdness of giving PAR special treatment.
 
What if we changed this =
sentence in Section 5.2 of JAR:
The contents of the resource referenced by the =
URI MUST be a Request
Object.
 
To: 
The contents of the resource referenced by the =
URI MUST be a Request
Object, unless the URI =
was provided to the client by the Authorization
Server.
 
This would allow for use cases =
such as an AS that provides pre-defined request URIs, or vends request =
URIs via a client management console, or bakes them into their client =
apps.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 
    Hi, 
    
    you are right, PAR does not require =
the AS to represent the request as a JWT-based request object. The URI =
is used as internal reference only. That why the draft states
    
    "There is no need to make the
          =
authorization request data available to other parties via this
          =
URI.=E2=80=9D
    
    This difference matters from an AS =
implementation perspective, it doesn't matter from a client's (interop) =
perspective.
    
    We may add a statement to PAR saying =
that request_uris issued by the PAR mechanism (MAY) deviate from the JAR =
definition.
    
    best regards,
    Torsten.  
    
    > On 8. Jan 2020, at 23:42, =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
    > 
    > Hi all,
    >  
    > The current drafts of PAR (-00) =
and JAR (-20) require that the AS transform all pushed requests into =
JWTs. This requirement arises from the following:
    > =
        =E2=80=A2 PAR uses the =
request_uri parameter defined in JAR to communicate the pushed request =
to the authorization endpoint.
    > =
        =E2=80=A2 According to JAR, =
the resource referenced by request_uri MUST be a Request Object. =
(Section 5.2)
    > =
        =E2=80=A2 Request Object is =
defined to be a JWT containing all the authorization request parameters. =
(Section 2.1)
    >  
    > There is no need for this =
requirement to support interoperability, as this is internal to the AS. =
It is also inconsistent with the rest of JAR, which avoids attempting to =
define the internal communications between the two AS endpoints. Worse, =
this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the =
state or outcome of that work must be forced into the JWT format (or =
retrieved via a subsequent service call or database lookup).
    >  
    > =E2=80=93 
    > Annabelle Richard Backman
    > AWS Identity
    >  
    > =
_______________________________________________
    > OAuth mailing list
    > OAuth@ietf..org
    
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


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

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


=

--Apple-Mail=_9D650DAB-93E3-4CA4-8CFD-DF773CE36571--


From nobody Thu Jan 16 09:42: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 268E2120071 for ; Thu, 16 Jan 2020 09:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF1kOryX3T2g for ; Thu, 16 Jan 2020 09:42:53 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD94912004A for ; Thu, 16 Jan 2020 09:42:52 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id b6so20087183wrq.0 for ; Thu, 16 Jan 2020 09:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wIBHHwjetI0OCwEAKJx0Osw2T6UqmoQWc6Fy3jFGLoc=; b=jrqX5b5lcB+mKD2rusA9aAP3x2DduITJ8+XRDXN0vpgrlBBpxsaAFG8tAq2vdOqQeP lyNoMok4f66ViJtKXKeTqmI13pIUso+uAEOo+f2UJ+dPxznh0onCUtcxXA/tqkAZLJ/9 VHl1dgwLNTDWv38nqiq90NAzSfgccEM60d346vKhViDgnkRvIKgnsBnbSJquD9UuDkte j+U2Wmwjvn0wIWIwHNxmPz0TGyLiYz8MXjJ4XM9oZBxdVYBdzsibFgmfz7/0A6yL6XqQ ogreFm8Cy1vyMCoePokocg5z8Ih3THOAV5NLnEWrVgWbcQcUjTsqWUYm2qqbO6/SUzvf t7Fg==
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=wIBHHwjetI0OCwEAKJx0Osw2T6UqmoQWc6Fy3jFGLoc=; b=eAvUtUIZPOMtSTstViC5cS3rr2uh5PTR7mycEJrT1f+zWwe4xXqD0Kxr9JM4t3rgEh J1kjA06zCYkQsShHo0zT6a0CCXN1cLy/jB/UUMtZRv3ptZ+YxnVfSS6xtsERFjBjkert vJdJvQ4IVNK4FD9WUdFQljLrfxsXVw9izlGGfVs7nDBOTPv1TDTLbo79TWayuuLro9P3 yge3Ne0xSph656kIchunB/XWKTkvyTh9J6CzN+iJp1DL3StDduJfBZdvMLqdn4pADhGd I9y0KiM/qHka0/ZbV0Ae36Ucl3MCUG34jHxce7mw8L2Ua56qh9EDANmMT8kPsNjFvZDH +sFw==
X-Gm-Message-State: APjAAAVTzuonLIMvGjECPHlFjDjRg7ZRZfEA2e1pTxl8EdIdNJ39WKU/ dxFUTq2nyqR0WGDaIjUxQEFvCLQR8j7FPTF2mz0=
X-Google-Smtp-Source: APXvYqzVvgA/r/2pNblmd7y7dpWMLe1H+yrm+Jfk4kKwE+8BstAe+nY5PRHs7XQNkWqyMMHC5m7V85rgp1ZY6s/eC6w=
X-Received: by 2002:adf:ed83:: with SMTP id c3mr4362895wro.51.1579196570895; Thu, 16 Jan 2020 09:42:50 -0800 (PST)
MIME-Version: 1.0
References:   <20200116143233.GJ80030@kduck.mit.edu>  <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>
In-Reply-To: <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>
From: Nat Sakimura 
Date: Fri, 17 Jan 2020 02:42:39 +0900
Message-ID: 
To: Neil Madden 
Cc: Benjamin Kaduk , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000a38930059c455a7f"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 17:42:58 -0000

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

Agree that the heading at least should be changed. I am OK with adding a
dedicated section to describe the possible attacks as well. I was merely
pointing out that the mitigation can be very similar to 10.4.1 and was
asking if there is anything else to be added.

The wording around Mitigation (a) can be a bit tricky as it cannot be an
exact match as it should have enough entropy to thwart guessing attacks.
That's why I resorted to "unexpected location." Perhaps we could say that
it should be under a pre-registered path or something like that. I would
love a pull request to
https://bitbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.=
xml
by
the way.

By "recursive" I exactly meant that AS should not follow redirect blindly.
I did not state that AS MUST NOT follow redirect as I feared that there
could be an implementation or middleware that implements a limited number
of redirects for its internal reasons. Again, I would love a pull request
to
https://bitbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.=
xml
 .

On Fri, Jan 17, 2020 at 1:31 AM Neil Madden 
wrote:

> The mitigations of 10.4.1 are related, but the section heading is about
> (D)DoS attacks. I think this heading needs to be reworded to apply to SSR=
F
> attacks too or else add another section with similar mitigations.
>
> Mitigation (a) is a bit vague as to what an "unexpected location" is.
> Perhaps specific wording that it should be a URI that has been
> pre-registered for the client (and validated at that time) or is otherwis=
e
> known to be safe (e.g., is a URI scheme controlled by the AS itself as wi=
th
> PAR).
>
> In addition for this to be effective the AS should not follow redirects
> when fetching the URI. It's not clear to me whether that is implied by "n=
ot
> perform recursive GET" so it may be worth explicitly spelling that out.
>
> -- Neil
>
>
> On 16 Jan 2020, at 15:47, Nat Sakimura  wrote:
>
> Right. We could add a security consideration like that, though the
> mitigation probably is pretty much the same as what is stated in 10.4.1:
>
> the server should (a) check that
>    the value of "request_uri" parameter does not point to an unexpected
>    location, (b) check the content type of the response is "application/
>    oauth.authz.req+jwt" (c) implement a time-out for obtaining the
>    content of "request_uri", and (d) not perform recursive GET on the
>    "request_uri".
>
> If not, please let me know so that we can add that as the mitigation as
> well.
>
> Existing OIDC deployment cannot make use of
> application/oauth.authz.req+jwt but it has to validate that content is a
> valid request object anyways and if it is malformed, it MUST stop the
> processing and return an error invalid_request_uri. So, unlike in the cas=
e
> of Capital One's SSRF, the content of the request_uri will not be exposed=
.
> The main downside is therefore as depicted in the current draft,
> consumption of the network and processing power of the AS, and the unwant=
ed
> access load to the servers serving the URL pointed by request_uri. The
> above-quoted mitigations were introduced to address these issues.
>
>
>
>
> On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk  wrote:
>
>> It is not too late to add to the security considerations.
>>
>> It seems that the new application/oauth.authz.req+jwt media-type is
>> helpful
>> in this regard, in that if an AS can require that content-type from
>> dereferencing the request_uri, then seeing anything else indicates that
>> the
>> request was bogus (or an attack).  I guess existing OIDC deployments
>> aren't
>> exactly in a position to do that, though.
>>
>> -Ben
>>
>> On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:
>> > Is it too late to add it to the security considerations for JAR?
>> >
>> > =E2=80=94 Neil
>> >
>> > > On 16 Jan 2020, at 08:15, Dominick Baier 
>> wrote:
>> > >
>> > > =EF=BB=BF
>> > > Agreed - that=E2=80=99s why we disabled request_uri by default and a=
dded
>> extensibility points to implement validation.
>> > >
>> > > I thought it is odd that this was not mentioned in the typical
>> =E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..
>> > >
>> > > =E2=80=94=E2=80=94=E2=80=94
>> > > Dominick Baier
>> > >
>> > >> On 16. January 2020 at 08:07:44, Neil Madden (
>> neil.madden@forgerock.com) wrote:
>> > >>
>> > >> If the AS can=E2=80=99t validate the request_uri it may also open i=
tself up
>> to SSRF attacks where a malicious client uses the request_uri to
>> probe/attack resources inside the AS=E2=80=99s private network. This was=
 a crucial
>> part of the recent Capital One breach for example [1].  ForgeRock curren=
tly
>> requires strict validation of request_uris against a client-specific
>> whitelist for exactly this reason.
>> > >>
>> > >> NB some clients might legitimately be on that private network (eg
>> microservices) so changing to a global whitelist for all clients is
>> undesirable.
>> > >>
>> > >> [1]: https://ejj.io/blog/capital-one
>> > >>
>> > >> =E2=80=94 Neil
>> > >>
>> > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>> > >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>> > >>>> Well, embedding a client_id claim in the JWE header in order to
>> achieve "request parameters outside the request object should not be
>> referred to" is like "putting the cart before the horse". Why do we have=
 to
>> avoid using the traditional client_id request parameter so stubbornly?
>> > >>>>
>> > >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
>> > >>>>
>> > >>>> A client MAY use the "client_id" request parameter to identify
>> itself when sending requests to the token endpoint.  In the
>> "authorization_code" "grant_type" request to the token endpoint, an
>> unauthenticated client MUST send its "client_id" to prevent itself from
>> inadvertently accepting a code intended for a client with a different
>> "client_id".  This protects the client from substitution of the
>> authentication code.  (It provides no additional security for the protec=
ted
>> resource.)
>> > >>>>
>> > >>>> If the same reasoning applies, a client_id must always be sent
>> with request / request_uri because client authentication is not performe=
d
>> at the authorization endpoint. In other words, an unauthenticated client
>> (every client is unauthenticated at the authorization endpoint) MUST sen=
d
>> its "client_id" to prevent itself from inadvertently accepting a request
>> object for a client with a different "client_id".
>> > >>>>
>> > >>> Identifying the client in JAR request_uri requests can be really
>> useful so that an AS which requires request_uri registration to prevent
>> DDoS attacks and other checks can do those without having to index all
>> request_uris individually. I mentioned this before.
>> > >>>
>> > >>> I really wonder what the reasoning of the IESG reviewers was to
>> insist on no params outside the JAR JWT / request_uri.
>> > >>>
>> > >>> I'm beginning to realise this step of the review process isn't
>> particularly transparent to WG members.
>> > >>>
>> > >>> Vladimir
>> > >>>
>> > >>>
>> > >>>
>> > >>>> Best Regards,
>> > >>>> Taka
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>> > >>>>> John, thanks, much appreciated!
>> > >>>>>
>> > >>>>>> On 11/01/2020 21:36, John Bradley wrote:
>> > >>>>>> Yes JAR is not prohibiting paramater replication in the header.
>> > >>>>>>
>> > >>>>>> I will see if i can add something in final edits to call that
>> out.
>> > >>>>>>
>> > >>>>>> John B.
>> > >>>>>>
>> > >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>> > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this
>> parameter replication be used for client_id or the client_id ass "iss" e=
ven
>> though it isn't explicitly mentioned in the JAR spec?
>> > >>>>>>>
>> > >>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
>> > >>>>>>>> Right we just don't say to put the iss there in OIDC if it's
>> symetricly encrypted.
>> > >>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose
>> that why the possibility to replicate params to the JWE header isn't
>> mentioned at all. OIDC requires the top-level query params to represent =
a
>> valid OAuth 2.0 request, and there client_id is required. If the client_=
id
>> is present the client registration together with any present client_secr=
et
>> can be retrieved.
>> > >>>>>>>
>> > >>>>>>> I reread the JAR spec, this is the only place that mentions
>> handling of symmetric JWE.
>> > >>>>>>>
>> > >>>>>>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>> > >>>>>>>
>> > >>>>>>>> (b)  Verifying that the symmetric key for the JWE encryption
>> is the
>> > >>>>>>>>         correct one if the JWE is using symmetric encryption.
>> > >>>>>>>
>> > >>>>>>> Vladimir
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <
>> Michael.Jones@microsoft.com> wrote:
>> > >>>>>>>>> The technique of replicating JWT claims that need to be
>> publicly visible in an encrypted JWT in the header is defined at
>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
>> for bringing this need to my attention as we were finishing the JWT spec=
.)
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>                                                        -- Mi=
ke
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> From: OAuth  On Behalf Of John
>> Bradley
>> > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
>> > >>>>>>>>> To: Vladimir Dzhuvinov 
>> > >>>>>>>>> Cc: IETF oauth WG 
>> > >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>> Request (JAR) vs OIDC request object
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> The intent was to do that, but specs change once the OAuth W=
G
>> and IESG get there hands on them.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> Being backwards compatible with OIDC is not a compelling
>> argument to the IESG.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> We were mostly thinking of asymmetric encryption.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> Specifying puting the issuer and or the audience in the
>> headder has come up in the past but probably is not documented.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> John B
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>> > >>>>>>>>>
>> > >>>>>>>>> Yes, putting the client_id into the JWE header is a way
>> around the need
>> > >>>>>>>>> to have the client_id outside the JWE as top-level authZ
>> request parameter.
>> > >>>>>>>>>
>> > >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I
>> just checked
>> > >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
>> > >>>>>>>>>
>> > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relie=
s
>> on the
>> > >>>>>>>>> presence of client_id as top-level parameter, together with
>> requiring
>> > >>>>>>>>> RPs to register their request_uri's (so that we don't need t=
o
>> build and
>> > >>>>>>>>> store an index of all request_uri's). I just had a look at
>> "DDoS Attack
>> > >>>>>>>>> on the Authorization Server" and also realised the request_u=
ri
>> > >>>>>>>>> registration isn't explicitly mentioned as attack prevention
>> ("the
>> > >>>>>>>>> server should (a) check that the value of "request_uri"
>> parameter does
>> > >>>>>>>>> not point to an unexpected location").
>> > >>>>>>>>>
>> > >>>>>>>>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>> > >>>>>>>>>
>> > >>>>>>>>> To be honest, I feel quite bad about the situation with JAR
>> we are in
>> > >>>>>>>>> now. For some reason I had the impression that OAuth JAR was
>> going to be
>> > >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as
>> with other
>> > >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
>> > >>>>>>>>>
>> > >>>>>>>>> I find it unfortunate I didn't notice this when I was
>> reviewing the spec
>> > >>>>>>>>> in the past.
>> > >>>>>>>>>
>> > >>>>>>>>> Vladimir
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
>> > >>>>>>>>> > Vladimir,
>> > >>>>>>>>> >
>> > >>>>>>>>> > For that very case the payload claims may be repeated in
>> the JWE protected header. An implementation wanting to handle this may l=
ook
>> for iss/client_id there.
>> > >>>>>>>>> >
>> > >>>>>>>>> > Odesl=C3=A1no z iPhonu
>> > >>>>>>>>> >
>> > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <
>> vladimir@connect2id.com>:
>> > >>>>>>>>> >>
>> > >>>>>>>>> >> =EF=BB=BFI just realised there is one class of JARs where=
 it's
>> practially
>> > >>>>>>>>> >> impossible to process the request if merge isn't supporte=
d:
>> > >>>>>>>>> >>
>> > >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared
>> key. OIDC allows
>> > >>>>>>>>> >> for that and specs a method for deriving the shared key
>> from the
>> > >>>>>>>>> >> client_secret:
>> > >>>>>>>>> >>
>> > >>>>>>>>> >>
>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>> > >>>>>>>>> >>
>> > >>>>>>>>> >> If the JAR is encrypted with the client_secret, and there
>> is no
>> > >>>>>>>>> >> top-level client_id parameter, there's no good way for th=
e
>> OP to find
>> > >>>>>>>>> >> out which client_secret to get to try to decrypt the JWE.
>> Unless the OP
>> > >>>>>>>>> >> keeps an index of all issued client_secret's.
>> > >>>>>>>>> >>
>> > >>>>>>>>> >>
>> > >>>>>>>>> >> OP servers which require request_uri registration
>> > >>>>>>>>> >> (require_request_uri_registration=3Dtrue) and don't want =
to
>> index all
>> > >>>>>>>>> >> registered request_uri's, also have no good way to proces=
s
>> a request_uri
>> > >>>>>>>>> >> if the client_id isn't present as top-level parameter.
>> > >>>>>>>>> >>
>> > >>>>>>>>> >>
>> > >>>>>>>>> >> Vladimir
>> > >>>>>>>>> >>
>> > >>>>>>>>> >>
>> > >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> > >>>>>>>>> >>>
>> > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <
>> ve7jtb@ve7jtb.com>:
>> > >>>>>>>>> >>>> I think Torsten is speculating that is not a feature
>> people use.
>> > >>>>>>>>> >>> I=E2=80=99m still trying to understand the use case for =
merging
>> signed and unsigned parameters. Nat once explained a use case, where a
>> client uses parameters signed by a 3rd party (some =E2=80=9Ecertificatio=
n
>> authority=E2=80=9C) in combination with transaction-specific parameters.=
 Is this
>> being done in the wild?
>> > >>>>>>>>> >>>
>> > >>>>>>>>> >>> PS: PAR would work with both modes.
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> _______________________________________________
>> > >>>>>>>>> OAuth mailing list
>> > >>>>>>>>> OAuth@ietf.org
>> > >>>>>>>>> https://
>> > >>>>>>>>>
>> > >>>>>
>> > >>>>> _______________________________________________
>> > >>>>> OAuth mailing list
>> > >>>>> OAuth@ietf.org
>> > >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> > >>> --
>> > >>> Vladimir Dzhuvinov
>> > >>> _______________________________________________
>> > >>> OAuth mailing list
>> > >>> OAuth@ietf.org
>> > >>> https://www.ietf.org/mailman/listinfo/oauth
>> > >> _______________________________________________
>> > >> OAuth mailing list
>> > >> OAuth@ietf.org
>> > >> https://www.ietf.org/mailman/listinfo/oauth
>>
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


Agree that the heading at least should be changed. I am OK=
 with adding a dedicated section to describe the possible attacks as well. =
I was merely pointing out that the mitigation can be very similar to 10.4.1=
 and was asking if there is anything else to be added.=C2=A0

=

The wording around Mitigation (a) can be a bit tricky as it cannot be =
an exact match as it should have enough entropy to thwart guessing attacks.=
 That's why I resorted to "unexpected location." Perhaps we c=
ould say that it should be under a pre-registered path or something like th=
at. I would love a pull request to=C2=A0https://bitbucket.o=
rg/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.xml=C2=A0by the=
 way.=C2=A0

By "recursive" I exactly mea=
nt that AS should not follow redirect blindly. I did not state that AS MUST=
 NOT follow redirect as I feared that there could be an implementation or m=
iddleware that implements a limited number of redirects for its internal re=
asons. Again, I would love a pull request to=C2=A0https://b=
itbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.xml=
=C2=A0.=C2=A0

On Fri, Jan 17, 2020 at 1:31 AM Neil Madden <neil.madden@forgerock.com> wro=
te:
The mitigations of 10.4.1 are related, but =
the section heading is about (D)DoS attacks. I think this heading needs to =
be reworded to apply to SSRF attacks too or else add another section with s=
imilar mitigations.=C2=A0

Mitigation (a) is a bit vague =
as to what an "unexpected location" is. Perhaps specific wording =
that it should be a URI that has been pre-registered for the client (and va=
lidated at that time) or is otherwise known to be safe (e.g., is a URI sche=
me controlled by the AS itself as with PAR).

In ad=
dition for this to be effective the AS should not follow redirects when fet=
ching the URI. It's not clear to me whether that is implied by "no=
t perform recursive GET" so it may be worth explicitly spelling that o=
ut.

-- Neil


On 16 Jan 2020, at 15:47, Nat Sakimur=
a <sakimura@gmai=
l.com> wrote:

Right. We could add a s=
ecurity consideration like that, though the mitigation probably is pretty m=
uch the same as what is stated in 10.4.1:=C2=A0
the server should (a) check that
   the value of "request_uri" parameter does not point to an unex=
pected
   location, (b) check the content type of the response is "applicatio=
n/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on=
 the
   "request_uri".
If not, please let me know so t=
hat we can add that as the mitigation as well.=C2=A0

Existing OIDC deployment cannot make use of application/oauth.authz.req+=
jwt but it has to validate that content is a valid request object anyways a=
nd if it is malformed, it MUST stop the processing and return an error inva=
lid_request_uri. So, unlike in the case of Capital One's SSRF, the cont=
ent of the request_uri will not be exposed. The main downside is therefore =
as depicted in the current draft, consumption of the network and processing=
 power of the AS, and the unwanted access load to the servers serving the U=
RL pointed by request_uri. The above-quoted mitigations were introduced to =
address these issues.=C2=A0




On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
It is not too late to add to th=
e security considerations.



It seems that the new application/oauth.authz.req+jwt media-type is helpful=


in this regard, in that if an AS can require that content-type from

dereferencing the request_uri, then seeing anything else indicates that the=


request was bogus (or an attack).=C2=A0 I guess existing OIDC deployments a=
ren't

exactly in a position to do that, though.



-Ben



On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:

> Is it too late to add it to the security considerations for JAR? 

> 

> =E2=80=94 Neil

> 

> > On 16 Jan 2020, at 08:15, Dominick Baier <dbaier@leastprivilege.com>=
; wrote:

> > 

> > =EF=BB=BF

> > Agreed - that=E2=80=99s why we disabled request_uri by default an=
d added extensibility points to implement validation.

> > 

> > I thought it is odd that this was not mentioned in the typical =
=E2=80=9Csecurity considerations=E2=80=9D in the OIDC spec..

> > 

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

> > Dominick Baier

> > 

> >> On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com) wrote:

> >> 

> >> If the AS can=E2=80=99t validate the request_uri it may also =
open itself up to SSRF attacks where a malicious client uses the request_ur=
i to probe/attack resources inside the AS=E2=80=99s private network. This w=
as a crucial part of the recent Capital One breach for example [1].=C2=A0 F=
orgeRock currently requires strict validation of request_uris against a cli=
ent-specific whitelist for exactly this reason. 

> >> 

> >> NB some clients might legitimately be on that private network=
 (eg microservices) so changing to a global whitelist for all clients is un=
desirable. 

> >> 

> >> [1]: https://ejj.io/blog/capital-one

> >> 

> >> =E2=80=94 Neil

> >> 

> >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <vladimir@connect2id.c=
om> wrote:

> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:

> >>>> Well, embedding a client_id claim in the JWE header i=
n order to achieve "request parameters outside the request object shou=
ld not be referred to" is like "putting the cart before the horse=
". Why do we have to avoid using the traditional client_id request par=
ameter so stubbornly?

> >>>> 

> >>>> The last paragraph of Section 3.2.1 of RFC 6749 says =
as follows.

> >>>> 

> >>>> A client MAY use the "client_id" request pa=
rameter to identify itself when sending requests to the token endpoint.=C2=
=A0 In the "authorization_code" "grant_type" request to=
 the token endpoint, an unauthenticated client MUST send its "client_i=
d" to prevent itself from inadvertently accepting a code intended for =
a client with a different "client_id".=C2=A0 This protects the cl=
ient from substitution of the authentication code.=C2=A0 (It provides no ad=
ditional security for the protected resource.)

> >>>> 

> >>>> If the same reasoning applies, a client_id must alway=
s be sent with request / request_uri because client authentication is not p=
erformed at the authorization endpoint. In other words, an unauthenticated =
client (every client is unauthenticated at the authorization endpoint) MUST=
 send its "client_id" to prevent itself from inadvertently accept=
ing a request object for a client with a different "client_id".
> >>>> 

> >>> Identifying the client in JAR request_uri requests can be=
 really useful so that an AS which requires request_uri registration to pre=
vent DDoS attacks and other checks can do those without having to index all=
 request_uris individually. I mentioned this before.

> >>> 

> >>> I really wonder what the reasoning of the IESG reviewers =
was to insist on no params outside the JAR JWT / request_uri.

> >>> 

> >>> I'm beginning to realise this step of the review proc=
ess isn't particularly transparent to WG members.

> >>> 

> >>> Vladimir

> >>> 

> >>> 

> >>> 

> >>>> Best Regards,

> >>>> Taka

> >>>> 

> >>>> 

> >>>> 

> >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov &=
lt;vladimir@co=
nnect2id.com> wrote:

> >>>>> John, thanks, much appreciated!

> >>>>> 

> >>>>>> On 11/01/2020 21:36, John Bradley wrote:

> >>>>>> Yes JAR is not prohibiting paramater replicat=
ion in the header. 

> >>>>>> 

> >>>>>> I will see if i can add something in final ed=
its to call that out.

> >>>>>> 

> >>>>>> John B.

> >>>>>> 

> >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov =
wrote:

> >>>>>>> Thanks Mike for the rfc7519 section-5.3 p=
ointer. Can this parameter replication be used for client_id or the client_=
id ass "iss" even though it isn't explicitly mentioned in the=
 JAR spec?

> >>>>>>> 

> >>>>>>>> On 11/01/2020 02:58, John Bradley wro=
te:

> >>>>>>>> Right we just don't say to put th=
e iss there in OIDC if it's symetricly encrypted.

> >>>>>>> OIDC doesn't have the symmetric key s=
election issue, I suppose that why the possibility to replicate params to t=
he JWE header isn't mentioned at all. OIDC requires the top-level query=
 params to represent a valid OAuth 2.0 request, and there client_id is requ=
ired. If the client_id is present the client registration together with any=
 present client_secret can be retrieved.

> >>>>>>> 

> >>>>>>> I reread the JAR spec, this is the only p=
lace that mentions handling of symmetric JWE.

> >>>>>>> 

> >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> >>>>>>> 

> >>>>>>>> (b)=C2=A0 Verifying that the symmetri=
c key for the JWE encryption is the

> >>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corr=
ect one if the JWE is using symmetric encryption.

> >>>>>>> 

> >>>>>>> Vladimir

> >>>>>>> 

> >>>>>>> 

> >>>>>>> 

> >>>>>>>> 

> >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jo=
nes <Mi=
chael.Jones@microsoft.com> wrote:

> >>>>>>>>> The technique of replicating JWT =
claims that need to be publicly visible in an encrypted JWT in the header i=
s defined at https://tools.ietf.org/html/rfc7519#sect=
ion-5.3.=C2=A0 (Thanks to Dick Hardt for bringing this need to my atten=
tion as we were finishing the JWT 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =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> O=
n Behalf Of John Bradley

> >>>>>>>>> Sent: Friday, January 10, 2020 2:=
15 PM

> >>>>>>>>> To: Vladimir Dzhuvinov <vladimir@connect2id.=
com>

> >>>>>>>>> Cc: IETF oauth WG <oauth@ietf.org>

> >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG=
] JWT Secured Authorization Request (JAR) vs OIDC request object

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> The intent was to do that, but sp=
ecs change once the OAuth WG and IESG get there hands on them.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> Being backwards compatible with O=
IDC is not a compelling argument to the IESG.

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> We were mostly thinking of asymme=
tric encryption.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> Specifying puting the issuer and =
or the audience in the headder has come up in the past but probably is not =
documented.=C2=A0 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> John B 

> >>>>>>>>> 

> >>>>>>>>>=C2=A0 

> >>>>>>>>> 

> >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vla=
dimir Dzhuvinov <vladimir@connect2id.com> wrote:

> >>>>>>>>> 

> >>>>>>>>> Yes, putting the client_id into t=
he JWE header is a way around the need

> >>>>>>>>> to have the client_id outside the=
 JWE as top-level authZ request parameter.

> >>>>>>>>> 

> >>>>>>>>> Unfortunately this work around is=
n't mentioned anywhere, I just checked

> >>>>>>>>> the most recent draft-ietf-oauth-=
jwsreq-20.

> >>>>>>>>> 

> >>>>>>>>> Our DDoS attack mitigation (for O=
IDC request_uri) also relies on the

> >>>>>>>>> presence of client_id as top-leve=
l parameter, together with requiring

> >>>>>>>>> RPs to register their request_uri=
's (so that we don't need to build and

> >>>>>>>>> store an index of all request_uri=
's). I just had a look at "DDoS Attack

> >>>>>>>>> on the Authorization Server"=
 and also realised the request_uri

> >>>>>>>>> registration isn't explicitly=
 mentioned as attack prevention ("the

> >>>>>>>>> server should (a) check that the =
value of "request_uri" parameter does

> >>>>>>>>> not point to an unexpected locati=
on").

> >>>>>>>>> 

> >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-=
10.4.1

> >>>>>>>>> 

> >>>>>>>>> To be honest, I feel quite bad ab=
out the situation with JAR we are in

> >>>>>>>>> now. For some reason I had the im=
pression that OAuth JAR was going to be

> >>>>>>>>> the OIDC request / request_uri fo=
r general OAuth 2.0 use, as with other

> >>>>>>>>> OIDC bits that later became gener=
al purpose OAuth 2.0 specs.

> >>>>>>>>> 

> >>>>>>>>> I find it unfortunate I didn'=
t notice this when I was reviewing the spec

> >>>>>>>>> in the past.

> >>>>>>>>> 

> >>>>>>>>> Vladimir

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> On 10/01/2020 22:39, Filip Skokan=
 wrote:

> >>>>>>>>> > Vladimir,

> >>>>>>>>> >

> >>>>>>>>> > For that very case the paylo=
ad claims may be repeated in the JWE protected header. An implementation wa=
nting to handle this may look for iss/client_id there.

> >>>>>>>>> >

> >>>>>>>>> > Odesl=C3=A1no z iPhonu

> >>>>>>>>> >

> >>>>>>>>> >> 10. 1. 2020 v 21:19, Vla=
dimir Dzhuvinov <vladimir@connect2id.com>:

> >>>>>>>>> >>

> >>>>>>>>> >> =EF=BB=BFI just realised=
 there is one class of JARs where it's practially

> >>>>>>>>> >> impossible to process th=
e request if merge isn't supported:

> >>>>>>>>> >>

> >>>>>>>>> >> The client submits a JAR=
 encrypted (JWT) with a shared key. OIDC allows

> >>>>>>>>> >> for that and specs a met=
hod for deriving the shared key from the

> >>>>>>>>> >> client_secret:

> >>>>>>>>> >>

> >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryp=
tion

> >>>>>>>>> >>

> >>>>>>>>> >> If the JAR is encrypted =
with the client_secret, and there is no

> >>>>>>>>> >> top-level client_id para=
meter, there's no good way for the OP to find

> >>>>>>>>> >> out which client_secret =
to get to try to decrypt the JWE. Unless the OP

> >>>>>>>>> >> keeps an index of all is=
sued client_secret's.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> OP servers which require=
 request_uri registration

> >>>>>>>>> >> (require_request_uri_reg=
istration=3Dtrue) and don't want to index all

> >>>>>>>>> >> registered request_uri&#=
39;s, also have no good way to process a request_uri

> >>>>>>>>> >> if the client_id isn'=
;t present as top-level parameter.

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >> Vladimir

> >>>>>>>>> >>

> >>>>>>>>> >>

> >>>>>>>>> >>> On 10/01/2020 20:13,=
 Torsten Lodderstedt wrote:

> >>>>>>>>> >>>

> >>>>>>>>> >>>>> Am 10.01.202=
0 um 16:53 schrieb John Bradley <ve7jtb@ve7jtb.com>:

> >>>>>>>>> >>>> I think Torsten =
is speculating that is not a feature people use.=C2=A0 =C2=A0

> >>>>>>>>> >>> I=E2=80=99m still tr=
ying to understand the use case for merging signed and unsigned parameters.=
 Nat once explained a use case, where a client uses parameters signed by a =
3rd party (some =E2=80=9Ecertification authority=E2=80=9C) in combination w=
ith transaction-specific parameters. Is this being done in the wild?

> >>>>>>>>> >>>

> >>>>>>>>> >>> PS: PAR would work w=
ith both modes.

> >>>>>>>>> 

> >>>>>>>>> 

> >>>>>>>>> _________________________________=
______________

> >>>>>>>>> OAuth mailing list

> >>>>>>>>> OAuth@ietf.org

> >>>>>>>>> https://

> >>>>>>>>> 

> >>>>> 

> >>>>> _______________________________________________
> >>>>> OAuth mailing list

> >>>>> OAuth@ietf.org

> >>>>> https://www.ietf.org/mailman/li=
stinfo/oauth

> >>> --=C2=A0 

> >>> Vladimir Dzhuvinov

> >>> _______________________________________________

> >>> OAuth mailing list

> >>> OAuth=
@ietf.org

> >>> https://www.ietf.org/mailman/listinfo/o=
auth

> >> _______________________________________________ 

> >> OAuth mailing list 

> >> OAuth@iet=
f.org 

> >> https://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




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat=
_en





-- 
Nat Sak=
imura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


--000000000000a38930059c455a7f--


From nobody Thu Jan 16 09:49: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 B8AF41200DF for ; Thu, 16 Jan 2020 09:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.799
X-Spam-Level: 
X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W95i7q1SFDsz for ; Thu, 16 Jan 2020 09:49:07 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 457E2120071 for ; Thu, 16 Jan 2020 09:49:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579196947; x=1610732947; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J6dun0B1/bhFzIQqZkTIN3VFGdxJpv6iK+MQCrDBfmo=; b=ZRJlTP22f2bcMbscSxvIrE9v6qcCwHvlu8aoo8frTLanSe2XR6acI0gf 4dSKawYfF2+HQvMDr5h03NbKDTIlD4Tzpqh1Gu8PSbOSA64pwrOJCI6zz Hd3WPL88Yer54oWUKP43hCr6enMZ2sCJpiEuwYqSqkaDixbnYYEeF7Wy4 E=;
IronPort-SDR: 9PwxsxEmIBQM3tBP/llSwyY9lqZq9YlyVqe2EkMAm2GE5+j7TO8Uo9pVJqi6MsVHRHf+qBB29G j4ofJMMabf+Q==
X-IronPort-AV: E=Sophos; i="5.70,327,1574121600"; d="scan'208,217"; a="13293104"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-81e76b79.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 16 Jan 2020 17:49:05 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-81e76b79.us-west-2.amazon.com (Postfix) with ESMTPS id 8DFE5A2184; Thu, 16 Jan 2020 17:49:04 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 17:49:04 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 17:49:03 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 16 Jan 2020 17:49:03 +0000
From: "Richard Backman, Annabelle" 
To: Justin Richer 
CC: Neil Madden , Torsten Lodderstedt , oauth , Nat Sakimura 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
Thread-Index: AQHVyGnmuDzxiSgL6kO/nJ8pkgSMsqfo3hWAgANXHYD//8zygIABdXIAgAAKpICAAANKgIAAD72AgAAEZiI=
Date: Thu, 16 Jan 2020 17:49:03 +0000
Message-ID: <00807967-2452-4DB0-AF0C-5BE7EA92B3A7@amazon.com>
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_0080796724524DB0AF0C5BE7EA92B3A7amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 17:49:13 -0000

--_000_0080796724524DB0AF0C5BE7EA92B3A7amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2XigJl2ZSBhbHJlYWR5IGRlZmluZWQgYSByZXF1ZXN0IGlkZW50aWZpZXIgcGFyYW1ldGVyLiBX
ZSBjYWxsZWQgaXQg4oCccmVxdWVzdF91cmnigJ0uIFRoYXTigJlzIHdoYXQgdGhlIOKAnEnigJ0g
aW4gVVJJIHN0YW5kcyBmb3IuIExldOKAmXMganVzdCBmaXggdGhlIHNlbWFudGljcyBvbiB0aGF0
IG9uZS4gSXTigJlzIGJhZCBlbm91Z2ggdGhhdCB3ZSBoYXZlIHJlcXVlc3QgYW5kIHJlcXVlc3Rf
dXJpLCBsZXTigJlzIG5vdCBhZGQgYSB0aGlyZCBvbmUuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN
Cg0KT24gSmFuIDE2LCAyMDIwLCBhdCA5OjMzIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p
dC5lZHU+IHdyb3RlOg0KDQrvu78gV2hhdCB5b3XigJl2ZSBkZXNjcmliZWQgaXMgZXhhY3RseSB3
aGF0IGhhcHBlbnMgaW4gWFlaOg0KDQpodHRwczovL29hdXRoLnh5ei9pbnRlcmFjdGlvbi8NCg0K
QW5kIHRoaXMgaXMgd2hhdCB3ZeKAmXJlIGRpc2N1c3NpbmcgYXMgdGhlIGJhc2lzIGluIFR4QXV0
aC4gQnV0IGluIHRoaXMgY2FzZSBzaW5jZSB5b3XigJlyZSBzdHVjayB3aXRoIE9BdXRoIDLigJlz
IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgc3ludGF4IGFuZCBzZW1hbnRpY3MsIHlvdeKAmXJlIHN0
aWxsIGxpbWl0ZWQgd2l0aCB3aGF04oCZcyBoYXBwZW5pbmcgdGhlcmUgYW5kIGl0IGNvdWxkIGNv
bWUgd2l0aCBpdHMgb3duIHNlY3VyaXR5IG9kZGl0aWVzIChsaWtlIG1heWJlIGEgbmV3IGZvcm0g
b2YgYSBtaXh1cCBhdHRhY2s/KSB0aGF0IHdlIGhhdmVu4oCZdCBmaWd1cmVkIG91dCB5ZXQuIExp
a2UsIGlzIHRoZSBBUyBhbGxvd2VkIHRvIHNlbmQgdGhlIGNsaWVudCB0byBzb21ldGhpbmcgb3Ro
ZXIgdGhhbiBpdHMgb3duIGF1dGhvcml6YXRpb24gZW5kcG9pbnQ/IElzIHRoZSBjbGllbnQgc3Vw
cG9zZWQgdG8gdmFsaWRhdGUgdGhlIHN5bnRheCBvZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu
dCBVUkwgYWdhaW5zdCBpdHMgZGlzY292ZXJ5IGRvY3VtZW50PyBJdCBkZWVwbHkgY2hhbmdlcyB3
aGF0IE9BdXRoIDIgZG9lcywgYW5kIHRoYXQgbWFrZXMgaXQgcmVhbGx5IGhhcmQgdG8gYWRkIG9u
Lg0KDQpVc2luZyByZXF1ZXN0X3VyaSB0byBwYXNzIHRoZSBhcnRpZmFjdCBpcyBjbGV2ZXIsIGJ1
dCBJIGFsc28gbGlrZSBUb3JzdGVu4oCZcyBpZGVhIG9mIHVzaW5nIGEgbmV3IGZpZWxkIGRlZmlu
ZWQgYnkgUEFSIHRvIHBhc3MgdGhlIGFydGlmYWN0LiBHcmFudGVkLCBpbiB0aGUgQXV0aGxldGUg
aW1wbGVtZW50YXRpb24gb2YgUEFSLCB3ZSB3ZXJlIGFibGUgdG8gcmUtdXNlIGEgd2hvbGUgYnVu
Y2ggb2YgY29kZSBmb3IgcHJvY2Vzc2luZyByZXF1ZXN0IG9iamVjdHMsIGFuZCB0aGF0IHdhcyBw
cmV0dHkgbmljZS4gU3RpbGwsIHRoZSBpc3N1ZXMgd2l0aCBKQVIgYXJlIG5vbi16ZXJvLCBhbmQg
c28gd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgd2Ugc2hvdWxkIGZ1bGx5IGRlY291cGxl
IG9yIGZpeCB0aGUgaXNzdWVzLiBJ4oCZbSBpbiBmYXZvciBvZiBmaXhpbmcgdGhpbmdzIGFuZCB1
c2luZyB0aGVzZSB0b2dldGhlciwgYnV0IHRoZXJl4oCZcyBhIGxvdCBvZiBpbmVydGlhIGFnYWlu
c3QgdGhhdC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSmFuIDE2LCAyMDIwLCBhdCAxMTozNiBBTSwg
TmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208bWFpbHRvOm5laWwubWFkZGVu
QGZvcmdlcm9jay5jb20+PiB3cm90ZToNCg0KV2h5IG5vdCBoYXZlIHRoZSBQQVIgZW5kcG9pbnQg
cmV0dXJuIGEgMzB4IHJlZGlyZWN0IHdpdGggdGhlIGZ1bGwgVVJMIHRvIHRoZSBhdXRob3JpemF0
aW9uIGVuZHBvaW50IGluIHRoZSBMb2NhdGlvbiBoZWFkZXI/IFRoYXQgd2F5IHRoZSBBUyBjYW4g
ZGVjaWRlIGZvciBpdHNlbGYgaG93IHRvIGNvbW11bmljYXRlIGFueSBpZCBmcm9tIHRoZSBQQVIg
ZW5kcG9pbnQgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuDQoNClRoaXMgYWxzbyBoYXMg
dGhlIHNpZGUgZWZmZWN0IHRoYXQgeW91IGNhbiBraWNrIG9mZiBhbiBPQXV0aDIgZmxvdyB3aXRo
IGEgc2ltcGxlIEhUTUwgZm9ybSBwb2ludGVkIGF0IHRoZSBQQVIgZW5kcG9pbnQgKHdpdGggaGlk
ZGVuIGZpZWxkcyBmb3Igc3RhdGUvY29kZV9jaGFsbGVuZ2UgZXRjKS4NCg0KSWYgYWN0dWFsbHkg
cGVyZm9ybWluZyB0aGUgcmVkaXJlY3QgaXMgYSBiaXQgcHJvYmxlbWF0aWMgdGhlbiBhdCBsZWFz
dCB0aGUgaWRlYSBvZiByZXR1cm5pbmcgYSBmdWxsIFVSTCBmb3IgdGhlIGF1dGhvcml6YXRpb24g
ZW5kcG9pbnQgKGh5cGVybGluaykgcmF0aGVyIHRoYW4gcmV0dXJuaW5nIGFuIGlkL1VSSSBhbmQg
cmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gY29uc3RydWN0IG9uZSBzZWVtcyByZWFzb25hYmxlIHRv
IG1lIGFuZCB3b3VsZCBzZWVtIHRvIGF2b2lkIHNvbWUgb2YgdGhlIGRpZmZpY3VsdGllcyBiZWlu
ZyBkaXNjdXNzZWQgd2l0aCBKQVIgZXRjIGFzIHRoZSBleGFjdCBtZWNoYW5pc20gb2YgY29tbXVu
aWNhdGlvbiBiZWNvbWVzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCB0aGF0IHRoZSBjbGllbnQg
bmVlZG4ndCBrbm93IGFib3V0Lg0KDQotLSBOZWlsDQoNCk9uIDE2IEphbiAyMDIwLCBhdCAxNjoy
NSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5p
ZXRmLm9yZzxtYWlsdG86dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+
IHdyb3RlOg0KDQpJIGp1c3QgdGhvdWdodCBhYm91dCBhbm90aGVyIG9wdGlvbi4gV2hhdCBpZiB3
ZSBjaGFuZ2UgUEFSIHRvIG5vdCB1c2UgdGhlIHJlcXVlc3RfdXJpIHBhcmFtZXRlciBidXQgYSBu
ZXcgcGFyYW1ldGVyLCBlLmcuIHJlcXVlc3RfaWQ/DQoNClRoYXQgd291bGQgZGVjb3VwbGUgYm90
aCBzcGVjcy4gVGhlIHJlYXNvbiB3aHkgd2UgdXNlIHJlcXVlc3RfdXJpIHdhcyB0byBtYWtlIHRo
ZSBsaWZlIG9mIGNsaWVudHMgZWFzaWVyIHNpbmNlIHRoZXkgY2FuIHVzZSB0aGUgc3RhbmRhcmQg
bGlicmFyeSBmdW5jdGlvbiBmb3IgcmVxdWVzdCBvYmplY3RzIHRvIHBhc3MgdGhlIFBBUiByZWZl
cmVuY2UgdG8gdGhlIEFTLiBJcyB0aGlzIHdvcnRoIHRoZSB0cm91YmxlPw0KDQpBbSAxNi4wMS4y
MDIwIHVtIDE2OjQ4IHNjaHJpZWIgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0
bzpqcmljaGVyQG1pdC5lZHU+PjoNCg0K77u/KzEgdG8gdGhpcyBhcHByb2FjaCwgYW5kIGl0IHNv
dW5kcyBsaWtlIEpBUiBtaWdodCBuZWVkIHRvIGNvbWUgYmFjayB0byBnbyB0aHJvdWdoIGFub3Ro
ZXIgcm91bmQgYW55d2F5IHRoYW5rcyB0byB0aGUgYnJlYWtpbmcgY2hhbmdlcyB0aGUgSUVTRyBw
dXNoZWQgaW50byBpdCBhZnRlciBpdCBsZWZ0IFdHTEMuDQoNCknigJlkIHJhdGhlciBzZWUgdXMg
Z2V0IHRoaXMgcmlnaHQgdGhhbiBwdWJsaXNoIHNvbWV0aGluZyBtYW55IG9mIHVzIHRoaW5rIGlz
IGJyb2tlbi4NCg0KTWF5YmUgUEFSIGFuZCBKQVIgKGFuZCBKQVJNPykgZW5kIHVwIGdvaW5nIG91
dCBhcyBhIGJ1bmRsZSBvZiBzcGVjcy4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSmFuIDE1LCAyMDIw
LCBhdCA4OjMwIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9u
LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpUaGUgcHJvYmxlbSBp
cyB0aGUgSldUIHJlcXVpcmVtZW50IGluIEpBUiwgbm90IGhvdyB3ZSB0YWxrIGFib3V0IFBBUiBy
ZXF1ZXN0X3VyaSB2YWx1ZXMgaW4gUEFSLiBXZSBuZWVkIHRvIGVpdGhlciBjaGFuZ2UgdGhlIGxh
bmd1YWdlIGluIEpBUiAoc2VlIG15IHN1Z2dlc3Rpb25zIGVsc2V3aGVyZSBpbiB0aGlzIHRocmVh
ZCksIG9yIGFkZCB0ZXh0IGluIFBBUiB0aGF0IGV4cGxpY2l0bHkgZXhlbXB0cyBQQVIgcmVxdWVz
dF91cmkgdmFsdWVzIChvciBwcmVmZXJhYmx5IGFsbCBBUy1wcm92aWRlZCByZXF1ZXN0X3VyaSB2
YWx1ZXMpIGZyb20gdGhpcyByZXF1aXJlbWVudCAoYWxzbyBzZWUgbXkgc3VnZ2VzdGlvbnMgZWxz
ZXdoZXJlIGluIHRoaXMgdGhyZWFkKS4NCg0KTXkgcHJlZmVyZW5jZSByZW1haW5zIHRoZSBmb3Jt
ZXIuIEl0IHN0cmlrZXMgbWUgYXMgYmFkIGZvcm0gZm9yIG9uZSBleHRlbnNpb24gdG8gb3ZlcnJp
ZGUgbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBsYWlkIG91dCBpbiBhbm90aGVyIGRvY3VtZW50LiBH
cmFudGVkLCB0aGUgaW5jb21wYXRpYmlsaXR5IHNjZW5hcmlvcyBpbnRyb2R1Y2VkIGJ5IHRoaXMg
cmV0Y29uIGFyZSBlZGdlLWNhc2UgYXQgYmVzdCwgYnV0IHRoYXQganVzdCByYWlzZXMgdGhlIHF1
ZXN0aW9uIG9mIHdoeSB3ZSBjYW7igJl0IGZpeCB0aGUgZHJhZnQgdGhhdCBoYXNu4oCZdCBhY3R1
YWxseSBiZWVuIHB1Ymxpc2hlZCB5ZXQuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h
bg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgVmxhZGltaXIgRHpo
dXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp
ZC5jb20+Pg0KT3JnYW5pemF0aW9uOiBDb25uZWN0MmlkIEx0ZC4uDQpEYXRlOiBXZWRuZXNkYXks
IEphbnVhcnkgMTUsIDIwMjAgYXQgMTI6MzQgUE0NClRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVy
QG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYu
b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+LCBOYXQgU2FraW11cmEgPG5hdEBzYWtpbXVyYS5v
cmc8bWFpbHRvOm5hdEBzYWtpbXVyYS5vcmc+PiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl
IiA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpyaWNoYW5uYT00
MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VO
VkVSSUZJRUQgU0VOREVSXSBSZTogUEFSOiBwdXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUgSldU
cw0KDQpPbiAxMy8wMS8yMDIwIDE5OjMyLCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KVG8gYmUgY2xl
YXIsIEnigJltIG5vdCBzYXlpbmcgd2Ugc3VnZ2VzdCBhIHBhcnRpY3VsYXIgZm9ybSwgYW5kIEkg
YWdyZWUgdGhhdCB3ZSBzaG91bGRu4oCZdCBzcGVjaWZ5IHRoYXQg4oCcaXTigJlzIGEgSldU4oCd
IG9yIHNvbWV0aGluZyBvZiB0aGF0IG5hdHVyZS4gQnV0IGlmIHdlIGNhbGwgdGhlIHJlc3VsdCBv
ZiBQQVIg4oCcdGhpbmcgWOKAnSBhbmQgdGhlIHRhcmdldCBvZiByZXF1ZXN0X3VyaSDigJx0aGlu
ZyBY4oCdIGluIEpBUiwgdGhlbiB3ZeKAmXJlIGNvbXBhdGlibGUgd2l0aG91dCBzYXlpbmcgd2hh
dCDigJx0aGluZyBY4oCdIG5lZWRzIHRvIGJlIGluIGFsbCBjYXNlcy4NCkdvb2QsIHdlJ3JlIG9u
IHRoZSBzYW1lIHBhZ2UgdGhlbi4NCkhvdyBhYm91dCBzaW1wbHkgc2F5aW5nIHRoYXQgdGhlIHJl
c3VsdCBvZiBQQVIgaXMgYW4gVVJJIHJlZmVyZW5jaW5nIHRoZSBwdXNoZWQgYXV0aFogcmVxdWVz
dDsgYXQgdGhlIGF1dGhaIGVuZHBvaW50IGl0cyBwcm9jZXNzaW5nIGlzIGNvbXBsZXRlZC4NCk5v
IG5lZWQgaXMgYm90aCBjbGVhciBhbmQgYWJzdHJhY3QgZW5vdWdoIHRvIG5vdCByZXF1aXJlIGEg
Zm9ybSB0byBiZSBzcGVjaWZpZWQuDQoNCkluIGNhc2VzIHdoZXJlIHlvdSBkbyBhIHJlbW90ZSBs
b29rIHVwLCB3ZSB3YW50IOKAnHRoaW5nIFjigJ0gdG8gYmUgZm9ybWF0dGVkIGFzIGEgSldULg0K
QnV0IHdoeT8NCkJvdGggUEFSIGFuZCBhdXRoWiBlbmRwb2ludHMgYmVsb25nIHRvIHRoZSBBUywg
d2hpY2ggbWFrZXMgdGhhdCBpbXBsIHNwZWNpZmljLiBUaGUgVVJJIGlzIHRoZSBjb250cmFjdCwg
YmV0d2VlbiBjbGllbnQgYW5kIEFTLg0KVGhlIEFTLCBpZiB1U2VydmljZSBiYXNlZCwgY291bGQg
Y2hvb3NlIHRvIGltcGxlbWVudCB0aGF0IGFzIENCT1IgV2ViIFRva2VuLCBvciBzb21lIG90aGVy
IHZlcmlmaWFibGUgYmxvYiwgcmVzdWx0aW5nIGluIHRoZSBzYW1lIGVzc2VudGlhbCBmdW5jdGlv
biwgYW5kIHRoaXMgaXNuJ3QgYWZmZWN0aW5nIHRoZSBjbGllbnQgPC0+IEFTIGNvbnRyYWN0IGlu
IGFueSB3YXkuDQoNCldlIGhhZCBhIGNhc2Ugb2Ygc2ltaWxhcmx5IHVuaW50ZW50aW9uYWwgbGlt
aXRpbmcgaW4gSkFSIHByZXZpb3VzbHksIHNheWluZyB0aGF0IHlvdSBoYWQgdG8gZG8gYW4gSFRU
UCBsb29rdXAgb24gdGhlIHJlcXVlc3RfdXJpLCBidXQgSSBiZWxpZXZlIHRoYXTigJlzIGJlZW4g
YmFja2VkIG9mZiBub3cgYW5kIG1hZGUgY29uZGl0aW9uYWwuDQpUaGF0IHdhcyBwcmVjaXNlbHkg
bXkgcG9pbnQuDQpWbGFkaW1pcg0KDQoNCiDigJQgSnVzdGluDQoNCg0KT24gSmFuIDExLCAyMDIw
LCBhdCA1OjI4IEFNLCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29t
PG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KDQpNeSBzdWdnZXN0aW9u
IGlzIHRvIGFic3RhaW4gZnJvbSBzcGVjaWZ5aW5nIHRoZSBjb25jcmV0ZSBmb3JtIG9mIHRoZSBy
ZXNvdXJjZSBwb2ludGVkIHRvIGJ5IHRoZSBQQVIgVVJJLiBSZWdhcmRsZXNzIG9mIFVSSSB0eXBl
IChVUk4sIGRvd25sb2FkYWJsZSBodHRwcyBVUkwgb3Igc29tZXRoaW5nIGVsc2UpLCBhbmQgZXZl
biBpZiB0aGUgUEFSIGVuZHBvaW50IGFuZCB0aGUgYXV0aFogZW5kcG9pbnQgYXJlIG1hbmFnZWQg
YnkgdHdvIGRpZmZlcmVudCBlbnRpdGllcyAobWljcm9zZXJ2aWNlIG9yIG90aGVyIHNjZW5hcmlv
KS4NCkluIHRoZSBDb25uZWN0MmlkIGltcGxlbWVudGF0aW9uIG9mIFBBUiB0aGUgcmV0dXJuZWQg
VVJJIGRvZXNuJ3QgcG9pbnQgdG8gYSByZXF1ZXN0IG9iamVjdCBhbmQgaXQgZG9lc24ndCBwb2lu
dCB0byBhIEpXVCBlaXRoZXIuIEl0IHBvaW50cyB0byBhbiBpbnRlcm5hbGx5IHN0b3JlZCAicHJl
LXByb2Nlc3NlZCIgYXV0aFogcmVxdWVzdCwgd2hpY2ggdGhlIGF1dGhaIGVuZHBvaW50IHRoZW4g
cGlja3MgdXAgdG8gY29tcGxldGUgdGhlIGF1dGhaLg0KRXZlbiBpZiB3ZSBldmVudHVhbGx5IGVu
ZCB1cCBpbiBtaWNyb3NlcnZpY2Ugd29ybGQsIG9yIGFsbG93IHRoZSBQQVIgZW5kcG9pbnQgdG8g
YmUgbWFuYWdlZCBieSBzb21lIGV4dGVybmFsIGVudGl0eSwgdGhlIFBBUiBVUkkgLSBpdHMgaW50
ZXJwcmV0YXRpb24sIHZhbGlkYXRpb24gYW5kIHBvdGVudGlhbGx5IHJlc291cmNlIHJldHJpZXZh
bCAoSldUIG9yIG90aGVyIGJsb2IpLCBpcyBhbiAiaW50ZXJuYWwgY29udHJhY3QiIG9uIHRoZSBB
UyBzaWRlLiBUaGlzIGRvZXNuJ3QgY29uY2VybiB0aGUgY2xpZW50LCBhbmQgaW4gT0F1dGggMi4w
IHRoZSByb2xlIG9mIEFTIGlzIGluZGl2aXNpYmxlLg0KDQpJIHNlZSBQQVIgcmVxdWVzdCArIGF1
dGhaIHJlcXVlc3QgYXMgb25lIGxvZ2ljYWwgT0F1dGggMi4wIGF1dGhaIHJlcXVlc3Q6IHRoZSBj
bGllbnQgc3VibWl0cyBhbiBhdXRoWiByZXF1ZXN0IGFuZCBnZXRzIGFuIGF1dGhaIHJlc3BvbnNl
IGF0IHRoZSBlbmQuIFRoZSBVUkkgaXMgbmVjZXNzYXJ5IGZvciB0aGUgY2xpZW50IHRvIHByb2Nl
ZWQgZnJvbSB0aGUgMXN0IHRvIHRoZSAybmQgc3RlcC4gSWYgd2UgbWFuYWdlIHRvIGZyYW1lIC8g
d29yZCB0aGUgUEFSIFVSSSBpbiB0aGlzIGxvZ2ljYWwgd2F5LCB3aXRob3V0IGdldHRpbmcgc3R1
Y2sgaW4gdGhlIEpBUiBkZWZpbml0aW9uIC8gZnJhbWluZyBvZiB3aGF0IHRoZSByZXF1ZXN0X3Vy
aSAvIG9iamVjdCBpcywgaXQgd291bGQgYmUgZ3JlYXQuDQoNClRoZSBub3JtYXRpdmUgbGFuZ3Vh
Z2UgSSB0aGluayBzaG91bGQgZm9jdXMgb24gbWFpbnRhaW5pbmcgdGhlIE9BdXRoIDIuMCBjb250
cmFjdCBmb3IgdGhlIGVudGlyZSBsb2dpY2FsIGF1dGhaIHJlcXVlc3QsIHRvZ2V0aGVyIHdpdGgg
dGhlIGJhc2ljIGNvbnRyYWN0cyBvZiAxKSBKQVIgYW5kIHRoZSAyKSBhdXRoWiBlbmRwb2ludC4N
Cg0KVmxhZGltaXINCg0KT24gMTAvMDEvMjAyMCAyMjo1NSwgSnVzdGluIFJpY2hlciB3cm90ZToN
ClNvIHdlIGNvdWxkIHNvbHZlIHRoaXMgYnkgc2F5aW5nIHRoZSByZXN1bHRpbmcgZGF0YSBvYmpl
Y3Qgb2YgYSBQQVIgaXMgYSByZXF1ZXN0IG9iamVjdC4gV2hpY2ggbWlnaHQgYWxzbyBjb250YWlu
IGEgcmVxdWVzdCBvYmplY3QgaW50ZXJuYWxseSBhcyB3ZWxsLiBJbiB0aGF0IGNhc2UgSkFSIHNo
b3VsZCBiYWNrIG9mZiBmcm9tIHNheWluZyBpdOKAmXMgYSBKV1QgYW5kIGluc3RlYWQgc2F5IGl0
4oCZcyBhIHJlcXVlc3Qgb2JqZWN0LiBPciB3ZSBkZWZpbmUgYSBuZXcgdGVybSBmb3IgdGhpcyBh
dXRob3JpemF0aW9uIHJlcXVlc3QgYmxvYiB0aGluZy4NCg0KT3IgUEFSIGNvdWxkIGF0IGxlYXN0
IHNheSB0aGF0IGlmIGl04oCZcyBkZXJlZmVyZW5jZWQgb3ZlciBhIHJlbW90ZSBwcm90b2NvbCB0
aGVuIGl0IE1VU1QgYmUgYSBKV1QsIGJ1dCBvdGhlcndpc2UgaXQgY2FuIGJlIHdoYXRldmVyIHlv
dSB3YW50LiBUaGF04oCZcyB3aGVyZSB0aGUgcmVhbCBpbnRlcm9wIGNvbmNlcm5zIGNvbWUgaW4u
DQoNCiDigJQgSnVzdGluDQoNCg0KT24gSmFuIDEwLCAyMDIwLCBhdCAzOjQxIFBNLCBSaWNoYXJk
IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn
PG1haWx0bzpyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0K
Q29ycmVjdC4gVGhlIHByb2JsZW0gYmVjb21lcyBwcmV0dHkgY2xlYXIgaW4gdGhlIGNvbnRleHQg
b2YgUEFSLCB3aGVyZSB0aGUgQVMgaXMgZ2VuZXJhdGluZyBhbmQgdmVuZGluZyBvdXQgdGhlIFVS
SSBhdCB0aGUgUEFSIGVuZHBvaW50LCBhbmQgY29uc3VtaW5nIGl0IGF0IHRoZSBhdXRob3JpemF0
aW9uIGVuZHBvaW50LiBGcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgc3RhbmRwb2ludCwgaXTigJlz
IGFuYWxvZ291cyB0byB0aGUgQVMgdmVuZGluZyBhbiBhdXRob3JpemF0aW9uIGNvZGUgYXQgdGhl
IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGNvbnN1bWluZyBpdCBhdCB0aGUgdG9rZW4gZW5k
cG9pbnQuDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoN
CkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdq
dGIuY29tPj4NCkRhdGU6IEZyaWRheSwgSmFudWFyeSAxMCwgMjAyMCBhdCAxMjoyOSBQTQ0KVG86
IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBi
ZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KQ2M6IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+LCBOYXQgU2Fr
aW11cmEgPG5hdEBzYWtpbXVyYS5vcmc8bWFpbHRvOm5hdEBzYWtpbXVyYS5vcmc+PiwgIlJpY2hh
cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu
bmFAYW1hem9uLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu
b3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gUEFSOiBw
dXNoZWQgcmVxdWVzdHMgbXVzdCBiZWNvbWUgSldUcw0KDQpJZiB3ZSBhc3N1bWUgdGhlIGNsaWVu
dCBwb3N0cyBhIEpBUiBhbmQgZ2V0cyBiYWNrIGEgcmVmZXJlbmNlLiAgVGhlbiB0aGUgcmVmZXJl
bmNlIGlzIHRvIGEgSkFSLg0KDQpJIHRoaW5rIEkgc2VlIHRoZSBwcm9ibGVtLiAgSWYgdGhlIHNl
cnZlciBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIEFTIHRo
ZW4gdGhlIHNlcnZlciBkb3Nlbid0IG5lZWQgdG8gZGVyZWZlcmVuY2UgdGhlIG9iamVjdCB2aWEg
SFRUUCwgc28gaXQgY291bGQgYmUgYSBVUk4gYXMgYW4gZXhhbXBsZS4NCg0KU28geWVzIGl0IGlz
IG5vdCBhIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgZm9yIHRoZSBjbGllbnQuDQoNCkkgd2lsbCB0
aGluayBhYm91dCBob3cgSSBjYW4gZmluZXNzZSB0aGF0Lg0KDQpJIGFncmVlIGl0IGlzIG5vdCBh
IGNoYW5nZSBpbiBpbnRlbnQuDQoNCkkgd2lsbCBzZWUgaWYgSSBjYW4gZ2V0IG91ciBBRCB0byBh
Y2NlcHQgdGhhdC4NCg0KSm9obiBCLg0KDQoNCg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCwgNDo1
NyBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpTdXJlIGJ1dCB0aGUgdGV4dCBwcm9w
b3NlZCAob3Igc29tZXRoaW5nIGxpa2UgaXQpIHF1YWxpZmllcyBpdCBzdWNoIHRoYXQgdGhlcmUg
YXJlbid0IGludGVyb3BlcmFiaWxpdHkgcXVlc3Rpb25zIGJlY2F1c2UgaXQncyBvbmx5IGFuIGlt
cGxlbWVudGF0aW9uIGRldGFpbCB0byB0aGUgQVMgd2hvIGJvdGggcHJvZHVjZXMgdGhlIFVSSSBh
bmQgY29uc3VtZXMgaXRzIGNvbnRlbnQuDQoNCk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEyOjQ4
IFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIu
Y29tPj4gd3JvdGU6DQpJdCBtYXkgYmUgYSBjaGFsbGVuZ2UgdG8gY2hhbmdlIHRleHQgc2F5aW5n
IHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSByZXNvdXJjZSBjb3VsZCBiZSBzb21ldGhpbmcgb3Ro
ZXIgdGhhbiBhIHJlcXVlc3Qgb2JqZWN0Lg0KDQpJZiBub3QgYSByZXF1ZXN0IG9iamVjdCB0aGVu
IHdoYXQgYW5kIGhvdyBpcyB0aGF0IGludGVyb3BlcmFibGUgYXJlIGxpa2VseSBBRCBxdWVzdGlv
bnMuDQoNCkkgY291bGQgcGVyaGFwcyBzZWUgY2hhbmdpbmcgaXQgdG8gbXVzdCBiZSBhIHJlcXVl
c3Qgb2JqZWN0LCBvciBvdGhlciBmb3JtYXQgZGVmaW5lZCBieSBhIHByb2ZpbGUuDQoNCkpvaG4g
Qi4NCg0KDQpPbiBGcmksIEphbiAxMCwgMjAyMCwgMzo0NSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNh
bXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t
Pj4gd3JvdGU6DQpBZ3JlZSBhbmQgYWdyZWUuIEJ1dCBnaXZlbiB0aGF0IHRoZSBjaGFuZ2Ugc3Vn
Z2VzdGVkIGJ5IEFubmFiZWxsZSBoYXMgbm8gaW1wYWN0IG9uIHRoZSBjbGllbnQgb3IgaW50ZXJv
cGVyYWJpbGl0eSwgcGVyaGFwcyBOYXQgb3IgSm9obiBjb3VsZCB3b3JrIHRoZSBjaGFuZ2UgaW50
byB0aGUgZHJhZnQgZHVyaW5nIHRoZSBlZGl0cyB0aGF0IGhhcHBlbiBkdXJpbmcgdGhlIGZpbmFs
IHN0YWdlcyBvZiB0aGluZ3M/DQoNCk9uIFRodSwgSmFuIDksIDIwMjAgYXQgMTo1NiBBTSBUb3Jz
dGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3Jn
PG1haWx0bzo0MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSSB3b3Vs
ZCBhc3N1bWUgZ2l2ZW4gdGhlIHN0YXR1cyBvZiBKQVIsIHdlIGRvbuKAmXQgd2FudCB0byBjaGFu
Z2UgaXQuIEFuZCBhcyBJIHNhaWQsIHRoaXMgZGlmZmVyZW5jZSBkb2VzIG5vdCBpbXBhY3QgaW50
ZXJvcGVyYWJpbGl0eSBmcm9tIGNsaWVudCBwZXJzcGVjdGl2ZS4NCg0KDQoNCkFtIDA5LjAxLjIw
MjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9
NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0
Zi5vcmc+PjoNCkl0IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gYWRkIHRoZSB0ZXh0IHRv
IEpBUiByYXRoZXIgdGhhbiBQQVIuIEl0IGRvZXNuJ3Qgc2VlbSByaWdodCBmb3IgUEFSIHRvIHJl
dGNvbiBydWxlcyBpbiBKQVIuIE1vdmluZyB0aGUgdGV4dCB0byBKQVIgYWxzbyBoaWdobGlnaHRz
IHRoZSB3ZWlyZG5lc3Mgb2YgZ2l2aW5nIFBBUiBzcGVjaWFsIHRyZWF0bWVudC4NCg0KV2hhdCBp
ZiB3ZSBjaGFuZ2VkIHRoaXMgc2VudGVuY2UgaW4gU2VjdGlvbiA1LjIgb2YgSkFSOg0KVGhlIGNv
bnRlbnRzIG9mIHRoZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHRoZSBVUkkgTVVTVCBiZSBhIFJl
cXVlc3QNCk9iamVjdC4NCg0KVG86DQpUaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVy
ZW5jZWQgYnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVzdA0KT2JqZWN0LCB1bmxlc3MgdGhlIFVS
SSB3YXMgcHJvdmlkZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgQXV0aG9yaXphdGlvbg0KU2VydmVy
Lg0KDQpUaGlzIHdvdWxkIGFsbG93IGZvciB1c2UgY2FzZXMgc3VjaCBhcyBhbiBBUyB0aGF0IHBy
b3ZpZGVzIHByZS1kZWZpbmVkIHJlcXVlc3QgVVJJcywgb3IgdmVuZHMgcmVxdWVzdCBVUklzIHZp
YSBhIGNsaWVudCBtYW5hZ2VtZW50IGNvbnNvbGUsIG9yIGJha2VzIHRoZW0gaW50byB0aGVpciBj
bGllbnQgYXBwcy4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRp
dHkNCg0KT24gMS84LzIwLCAyOjUwIFBNLCAiVG9yc3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW49
NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbG9kZGVyc3RlZHQubmV0
QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCiAgICBIaSwNCg0KICAgIHlvdSBhcmUgcmlnaHQs
IFBBUiBkb2VzIG5vdCByZXF1aXJlIHRoZSBBUyB0byByZXByZXNlbnQgdGhlIHJlcXVlc3QgYXMg
YSBKV1QtYmFzZWQgcmVxdWVzdCBvYmplY3QuIFRoZSBVUkkgaXMgdXNlZCBhcyBpbnRlcm5hbCBy
ZWZlcmVuY2Ugb25seS4gVGhhdCB3aHkgdGhlIGRyYWZ0IHN0YXRlcw0KDQogICAgIlRoZXJlIGlz
IG5vIG5lZWQgdG8gbWFrZSB0aGUNCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0
YSBhdmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpcw0KICAgICAgICAgIFVSSS7igJ0N
Cg0KICAgIFRoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZyb20gYW4gQVMgaW1wbGVtZW50YXRpb24g
cGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZyb20gYSBjbGllbnQncyAoaW50ZXJvcCkg
cGVyc3BlY3RpdmUuDQoNCiAgICBXZSBtYXkgYWRkIGEgc3RhdGVtZW50IHRvIFBBUiBzYXlpbmcg
dGhhdCByZXF1ZXN0X3VyaXMgaXNzdWVkIGJ5IHRoZSBQQVIgbWVjaGFuaXNtIChNQVkpIGRldmlh
dGUgZnJvbSB0aGUgSkFSIGRlZmluaXRpb24uDQoNCiAgICBiZXN0IHJlZ2FyZHMsDQogICAgVG9y
c3Rlbi4NCg0KICAgID4gT24gOC4gSmFuIDIwMjAsIGF0IDIzOjQyLCBSaWNoYXJkIEJhY2ttYW4s
IEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0
MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCiAgICA+DQogICAgPiBIaSBhbGws
DQogICAgPg0KICAgID4gVGhlIGN1cnJlbnQgZHJhZnRzIG9mIFBBUiAoLTAwKSBhbmQgSkFSICgt
MjApIHJlcXVpcmUgdGhhdCB0aGUgQVMgdHJhbnNmb3JtIGFsbCBwdXNoZWQgcmVxdWVzdHMgaW50
byBKV1RzLiBUaGlzIHJlcXVpcmVtZW50IGFyaXNlcyBmcm9tIHRoZSBmb2xsb3dpbmc6DQogICAg
PiAgICAgICAgIOKAoiBQQVIgdXNlcyB0aGUgcmVxdWVzdF91cmkgcGFyYW1ldGVyIGRlZmluZWQg
aW4gSkFSIHRvIGNvbW11bmljYXRlIHRoZSBwdXNoZWQgcmVxdWVzdCB0byB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludC4NCiAgICA+ICAgICAgICAg4oCiIEFjY29yZGluZyB0byBKQVIsIHRoZSBy
ZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHJlcXVlc3RfdXJpIE1VU1QgYmUgYSBSZXF1ZXN0IE9iamVj
dC4gKFNlY3Rpb24gNS4yKQ0KICAgID4gICAgICAgICDigKIgUmVxdWVzdCBPYmplY3QgaXMgZGVm
aW5lZCB0byBiZSBhIEpXVCBjb250YWluaW5nIGFsbCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0
IHBhcmFtZXRlcnMuIChTZWN0aW9uIDIuMSkNCiAgICA+DQogICAgPiBUaGVyZSBpcyBubyBuZWVk
IGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhp
cyBpcyBpbnRlcm5hbCB0byB0aGUgQVMuIEl0IGlzIGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhl
IHJlc3Qgb2YgSkFSLCB3aGljaCBhdm9pZHMgYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGludGVy
bmFsIGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlIHR3byBBUyBlbmRwb2ludHMuIFdvcnNlLCB0
aGlzIHJlc3RyaWN0aW9uIG1ha2VzIGl0IGhhcmRlciBmb3IgdGhlIGF1dGhvcml6YXRpb24gZW5k
cG9pbnQgdG8gbGV2ZXJhZ2UgdmFsaWRhdGlvbiBhbmQgb3RoZXIgd29yayBwZXJmb3JtZWQgYXQg
dGhlIFBBUiBlbmRwb2ludCwgYXMgdGhlIHN0YXRlIG9yIG91dGNvbWUgb2YgdGhhdCB3b3JrIG11
c3QgYmUgZm9yY2VkIGludG8gdGhlIEpXVCBmb3JtYXQgKG9yIHJldHJpZXZlZCB2aWEgYSBzdWJz
ZXF1ZW50IHNlcnZpY2UgY2FsbCBvciBkYXRhYmFzZSBsb29rdXApLg0KICAgID4NCiAgICA+IOKA
kw0KICAgID4gQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KICAgID4gQVdTIElkZW50aXR5DQog
ICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICA+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4gT0F1dGhAaWV0Zi4ub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN
CkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu
ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv
c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls
ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5U
SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy
aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90
aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg
Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0
ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2ht
ZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYuLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KLS0NCg0KVmxhZGltaXIgRHpodXZpbm92DQoNCg0KDQotLQ0KDQpW
bGFkaW1pciBEemh1dmlub3YNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg==

--_000_0080796724524DB0AF0C5BE7EA92B3A7amazoncom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpX
ZeKAmXZlIGFscmVhZHkgZGVmaW5lZCBhIHJlcXVlc3QgaWRlbnRpZmllciBwYXJhbWV0ZXIuIFdl
IGNhbGxlZCBpdCDigJxyZXF1ZXN0X3VyaeKAnS4gVGhhdOKAmXMgd2hhdCB0aGUg4oCcSeKAnSBp
biBVUkkgc3RhbmRzIGZvci4gTGV04oCZcyBqdXN0IGZpeCB0aGUgc2VtYW50aWNzIG9uIHRoYXQg
b25lLiBJdOKAmXMgYmFkIGVub3VnaCB0aGF0IHdlIGhhdmUgcmVxdWVzdCBhbmQgcmVxdWVzdF91
cmksIGxldOKAmXMgbm90IGFkZCBhIHRoaXJkIG9uZS4NCjxkaXY+PGJyPg0KPGRpdiBkaXI9Imx0
ciI+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+T24gSmFuIDE2LCAyMDIwLCBhdCA5OjMzIEFNLCBKdXN0aW4gUmlj
aGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78g
V2hhdCB5b3XigJl2ZSBkZXNjcmliZWQgaXMgZXhhY3RseSB3aGF0IGhhcHBlbnMgaW4gWFlaOg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJl
Zj0iaHR0cHM6Ly9vYXV0aC54eXovaW50ZXJhY3Rpb24vIiBjbGFzcz0iIj5odHRwczovL29hdXRo
Lnh5ei9pbnRlcmFjdGlvbi88L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbmQgdGhpcyBpcyB3aGF0IHdl4oCZcmUgZGlzY3Vzc2lu
ZyBhcyB0aGUgYmFzaXMgaW4gVHhBdXRoLiBCdXQgaW4gdGhpcyBjYXNlIHNpbmNlIHlvdeKAmXJl
IHN0dWNrIHdpdGggT0F1dGggMuKAmXMgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBzeW50YXggYW5k
IHNlbWFudGljcywgeW914oCZcmUgc3RpbGwgbGltaXRlZCB3aXRoIHdoYXTigJlzIGhhcHBlbmlu
ZyB0aGVyZSBhbmQgaXQgY291bGQgY29tZSB3aXRoIGl0cyBvd24gc2VjdXJpdHkNCiBvZGRpdGll
cyAobGlrZSBtYXliZSBhIG5ldyBmb3JtIG9mIGEgbWl4dXAgYXR0YWNrPykgdGhhdCB3ZSBoYXZl
buKAmXQgZmlndXJlZCBvdXQgeWV0LiBMaWtlLCBpcyB0aGUgQVMgYWxsb3dlZCB0byBzZW5kIHRo
ZSBjbGllbnQgdG8gc29tZXRoaW5nIG90aGVyIHRoYW4gaXRzIG93biBhdXRob3JpemF0aW9uIGVu
ZHBvaW50PyBJcyB0aGUgY2xpZW50IHN1cHBvc2VkIHRvIHZhbGlkYXRlIHRoZSBzeW50YXggb2Yg
dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQNCiBVUkwgYWdhaW5zdCBpdHMgZGlzY292ZXJ5IGRv
Y3VtZW50PyBJdCBkZWVwbHkgY2hhbmdlcyB3aGF0IE9BdXRoIDIgZG9lcywgYW5kIHRoYXQgbWFr
ZXMgaXQgcmVhbGx5IGhhcmQgdG8gYWRkIG9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VXNpbmcgcmVxdWVzdF91cmkgdG8gcGFzcyB0
aGUgYXJ0aWZhY3QgaXMgY2xldmVyLCBidXQgSSBhbHNvIGxpa2UgVG9yc3RlbuKAmXMgaWRlYSBv
ZiB1c2luZyBhIG5ldyBmaWVsZCBkZWZpbmVkIGJ5IFBBUiB0byBwYXNzIHRoZSBhcnRpZmFjdC4g
R3JhbnRlZCwgaW4gdGhlIEF1dGhsZXRlIGltcGxlbWVudGF0aW9uIG9mIFBBUiwgd2Ugd2VyZSBh
YmxlIHRvIHJlLXVzZSBhIHdob2xlIGJ1bmNoIG9mIGNvZGUgZm9yIHByb2Nlc3NpbmcNCiByZXF1
ZXN0IG9iamVjdHMsIGFuZCB0aGF0IHdhcyBwcmV0dHkgbmljZS4gU3RpbGwsIHRoZSBpc3N1ZXMg
d2l0aCBKQVIgYXJlIG5vbi16ZXJvLCBhbmQgc28gd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRo
ZXIgd2Ugc2hvdWxkIGZ1bGx5IGRlY291cGxlIG9yIGZpeCB0aGUgaXNzdWVzLiBJ4oCZbSBpbiBm
YXZvciBvZiBmaXhpbmcgdGhpbmdzIGFuZCB1c2luZyB0aGVzZSB0b2dldGhlciwgYnV0IHRoZXJl
4oCZcyBhIGxvdCBvZiBpbmVydGlhIGFnYWluc3QNCiB0aGF0LjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A74oCUIEp1c3Rpbjxi
ciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEphbiAxNiwgMjAyMCwgYXQgMTE6MzYgQU0sIE5l
aWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIg
Y2xhc3M9IiI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K
PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj
ZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldoeSBub3QgaGF2
ZSB0aGUgUEFSIGVuZHBvaW50IHJldHVybiBhIDMweCByZWRpcmVjdCB3aXRoIHRoZSBmdWxsIFVS
TCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBpbiB0aGUgTG9jYXRpb24gaGVhZGVyPyBU
aGF0IHdheSB0aGUgQVMgY2FuIGRlY2lkZSBmb3IgaXRzZWxmIGhvdyB0byBjb21tdW5pY2F0ZSBh
bnkgaWQgZnJvbSB0aGUgUEFSIGVuZHBvaW50IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50
Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhp
cyBhbHNvIGhhcyB0aGUgc2lkZSBlZmZlY3QgdGhhdCB5b3UgY2FuIGtpY2sgb2ZmIGFuIE9BdXRo
MiBmbG93IHdpdGggYSBzaW1wbGUgSFRNTCBmb3JtIHBvaW50ZWQgYXQgdGhlIFBBUiBlbmRwb2lu
dCAod2l0aCBoaWRkZW4gZmllbGRzIGZvciBzdGF0ZS9jb2RlX2NoYWxsZW5nZSBldGMpLjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYg
YWN0dWFsbHkgcGVyZm9ybWluZyB0aGUgcmVkaXJlY3QgaXMgYSBiaXQgcHJvYmxlbWF0aWMgdGhl
biBhdCBsZWFzdCB0aGUgaWRlYSBvZiByZXR1cm5pbmcgYSBmdWxsIFVSTCBmb3IgdGhlIGF1dGhv
cml6YXRpb24gZW5kcG9pbnQgKGh5cGVybGluaykgcmF0aGVyIHRoYW4gcmV0dXJuaW5nIGFuIGlk
L1VSSSBhbmQgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gY29uc3RydWN0IG9uZSBzZWVtcyByZWFz
b25hYmxlIHRvIG1lDQogYW5kIHdvdWxkIHNlZW0gdG8gYXZvaWQgc29tZSBvZiB0aGUgZGlmZmlj
dWx0aWVzIGJlaW5nIGRpc2N1c3NlZCB3aXRoIEpBUiBldGMgYXMgdGhlIGV4YWN0IG1lY2hhbmlz
bSBvZiBjb21tdW5pY2F0aW9uIGJlY29tZXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIHRoYXQg
dGhlIGNsaWVudCBuZWVkbid0IGtub3cgYWJvdXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tLSBOZWlsPGJyIGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i
Ij4NCjxkaXYgY2xhc3M9IiI+T24gMTYgSmFuIDIwMjAsIGF0IDE2OjI1LCBUb3JzdGVuIExvZGRl
cnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFy
Yy5pZXRmLm9yZyIgY2xhc3M9IiI+dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm
Lm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u
ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2
IGRpcj0ibHRyIiBjbGFzcz0iIj5JIGp1c3QgdGhvdWdodCBhYm91dCBhbm90aGVyIG9wdGlvbi4g
V2hhdCBpZiB3ZSBjaGFuZ2UgUEFSIHRvIG5vdCB1c2UgdGhlIHJlcXVlc3RfdXJpIHBhcmFtZXRl
ciBidXQgYSBuZXcgcGFyYW1ldGVyLCBlLmcuIHJlcXVlc3RfaWQ/PC9kaXY+DQo8ZGl2IGRpcj0i
bHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz
PSIiPlRoYXQgd291bGQgZGVjb3VwbGUgYm90aCBzcGVjcy4gVGhlIHJlYXNvbiB3aHkgd2UgdXNl
IHJlcXVlc3RfdXJpIHdhcyB0byBtYWtlIHRoZSBsaWZlIG9mIGNsaWVudHMgZWFzaWVyIHNpbmNl
IHRoZXkgY2FuIHVzZSB0aGUgc3RhbmRhcmQgbGlicmFyeSBmdW5jdGlvbiBmb3IgcmVxdWVzdCBv
YmplY3RzIHRvIHBhc3MgdGhlIFBBUiByZWZlcmVuY2UgdG8gdGhlIEFTLiBJcyB0aGlzIHdvcnRo
IHRoZSB0cm91YmxlPzwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QW0gMTYuMDEuMjAyMCB1bSAxNjo0
OCBzY2hyaWViIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l
ZHUiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7OjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg
Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj7vu78mIzQzOzEgdG8gdGhpcyBhcHBy
b2FjaCwgYW5kIGl0IHNvdW5kcyBsaWtlIEpBUiBtaWdodCBuZWVkIHRvIGNvbWUgYmFjayB0byBn
byB0aHJvdWdoIGFub3RoZXIgcm91bmQgYW55d2F5IHRoYW5rcyB0byB0aGUgYnJlYWtpbmcgY2hh
bmdlcyB0aGUgSUVTRyBwdXNoZWQgaW50byBpdCBhZnRlciBpdCBsZWZ0IFdHTEMuDQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZZCByYXRoZXIg
c2VlIHVzIGdldCB0aGlzIHJpZ2h0IHRoYW4gcHVibGlzaCBzb21ldGhpbmcgbWFueSBvZiB1cyB0
aGluayBpcyBicm9rZW4uJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYXliZSBQQVIgYW5kIEpBUiAoYW5kIEpBUk0/KSBlbmQg
dXAgZ29pbmcgb3V0IGFzIGEgYnVuZGxlIG9mIHNwZWNzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A74oCUIEp1c3RpbjxiciBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEphbiAxNSwgMjAyMCwgYXQgODozMCBQ
TSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5u
YUBhbWF6b24uY29tIiBjbGFzcz0iIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6
PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz
cz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9u
MTsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp
biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoZSBwcm9ibGVtIGlzIHRoZSBKV1QgcmVxdWlyZW1lbnQg
aW4gSkFSLCBub3QgaG93IHdlIHRhbGsgYWJvdXQgUEFSIHJlcXVlc3RfdXJpIHZhbHVlcyBpbiBQ
QVIuIFdlIG5lZWQgdG8gZWl0aGVyIGNoYW5nZSB0aGUgbGFuZ3VhZ2UgaW4gSkFSIChzZWUgbXkg
c3VnZ2VzdGlvbnMgZWxzZXdoZXJlIGluIHRoaXMgdGhyZWFkKSwgb3IgYWRkIHRleHQgaW4gUEFS
IHRoYXQgZXhwbGljaXRseSBleGVtcHRzIFBBUiByZXF1ZXN0X3VyaSB2YWx1ZXMgKG9yDQogcHJl
ZmVyYWJseSBhbGwgQVMtcHJvdmlkZWQgcmVxdWVzdF91cmkgdmFsdWVzKSBmcm9tIHRoaXMgcmVx
dWlyZW1lbnQgKGFsc28gc2VlIG15IHN1Z2dlc3Rpb25zIGVsc2V3aGVyZSBpbiB0aGlzIHRocmVh
ZCkuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KTXkgcHJlZmVyZW5jZSByZW1h
aW5zIHRoZSBmb3JtZXIuIEl0IHN0cmlrZXMgbWUgYXMgYmFkIGZvcm0gZm9yIG9uZSBleHRlbnNp
b24gdG8gb3ZlcnJpZGUgbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBsYWlkIG91dCBpbiBhbm90aGVy
IGRvY3VtZW50LiBHcmFudGVkLCB0aGUgaW5jb21wYXRpYmlsaXR5IHNjZW5hcmlvcyBpbnRyb2R1
Y2VkIGJ5IHRoaXMgcmV0Y29uIGFyZSBlZGdlLWNhc2UgYXQgYmVzdCwgYnV0IHRoYXQganVzdCBy
YWlzZXMgdGhlIHF1ZXN0aW9uDQogb2Ygd2h5IHdlIGNhbuKAmXQgZml4IHRoZSBkcmFmdCB0aGF0
IGhhc27igJl0IGFjdHVhbGx5IGJlZW4gcHVibGlzaGVkIHlldC48bzpwIGNsYXNzPSIiPjwvbzpw
PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw
IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTJwdDsiIGNsYXNzPSIiPuKAkyZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls
ZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxv
OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9
IiI+QVdTIElkZW50aXR5PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N
CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm
b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i
Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs
YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IGJvcmRl
ci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgcGFkZGluZzogM3B0IDBpbiAwaW47IiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGIg
Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkZyb206PHNw
YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPk9BdXRoICZsdDs8YSBocmVm
PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl
eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+b2F1dGgtYm91bmNlc0BpZXRmLm9y
ZzwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4
dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj52bGFkaW1pckBjb25uZWN0MmlkLmNv
bTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+T3JnYW5pemF0aW9uOjxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Q29ubmVjdDJpZCBM
dGQuLjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIEphbnVhcnkgMTUsIDIw
MjAgYXQgMTI6MzQgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkp1c3RpbiBSaWNoZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVk
dTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5vYXV0aCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIiBjbGFzcz0iIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7LCBOYXQg
U2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpuYXRAc2FraW11cmEub3JnIiBjbGFzcz0iIj5u
YXRAc2FraW11cmEub3JnPC9hPiZndDssICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl
JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmll
dGYub3JnIiBjbGFzcz0iIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+
Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW09BVVRILVdHXSBbVU5WRVJJ
RklFRCBTRU5ERVJdIFJlOiBQQVI6IHB1c2hlZCByZXF1ZXN0cyBtdXN0IGJlY29tZSBKV1RzPG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+
Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9uIDEzLzAxLzIwMjAgMTk6MzIsIEp1c3Rp
biBSaWNoZXIgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9
IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i
Ij4NClRvIGJlIGNsZWFyLCBJ4oCZbSBub3Qgc2F5aW5nIHdlIHN1Z2dlc3QgYSBwYXJ0aWN1bGFy
IGZvcm0sIGFuZCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkbuKAmXQgc3BlY2lmeSB0aGF0IOKAnGl0
4oCZcyBhIEpXVOKAnSBvciBzb21ldGhpbmcgb2YgdGhhdCBuYXR1cmUuIEJ1dCBpZiB3ZSBjYWxs
IHRoZSByZXN1bHQgb2YgUEFSIOKAnHRoaW5nIFjigJ0gYW5kIHRoZSB0YXJnZXQgb2YgcmVxdWVz
dF91cmkg4oCcdGhpbmcgWOKAnSBpbiBKQVIsIHRoZW4gd2XigJlyZSBjb21wYXRpYmxlIHdpdGhv
dXQNCiBzYXlpbmcgd2hhdCDigJx0aGluZyBY4oCdIG5lZWRzIHRvIGJlIGluIGFsbCBjYXNlcy48
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+R29vZCwgd2Un
cmUgb24gdGhlIHNhbWUgcGFnZSB0aGVuLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPkhvdyBhYm91dCBzaW1wbHkgc2F5aW5nIHRoYXQgdGhlIHJlc3VsdCBvZiBQQVIg
aXMgYW4gVVJJIHJlZmVyZW5jaW5nIHRoZSBwdXNoZWQgYXV0aFogcmVxdWVzdDsgYXQgdGhlIGF1
dGhaIGVuZHBvaW50IGl0cyBwcm9jZXNzaW5nIGlzIGNvbXBsZXRlZC48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ObyBuZWVkIGlzIGJvdGggY2xlYXIgYW5kIGFic3Ry
YWN0IGVub3VnaCB0byBub3QgcmVxdWlyZSBhIGZvcm0gdG8gYmUgc3BlY2lmaWVkLjxvOnAgY2xh
c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v
OnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90
dG9tOiA1cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkluIGNhc2VzIHdoZXJlIHlvdSBk
byBhIHJlbW90ZSBsb29rIHVwLCB3ZSB3YW50IOKAnHRoaW5nIFjigJ0gdG8gYmUgZm9ybWF0dGVk
IGFzIGEgSldULjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxkaXYgY2xhc3M9IiI+QnV0IHdoeT88bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj5Cb3RoIFBBUiBhbmQgYXV0aFogZW5kcG9pbnRzIGJlbG9uZyB0byB0aGUgQVMs
IHdoaWNoIG1ha2VzIHRoYXQgaW1wbCBzcGVjaWZpYy4gVGhlIFVSSSBpcyB0aGUgY29udHJhY3Qs
IGJldHdlZW4gY2xpZW50IGFuZCBBUy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj5UaGUgQVMsIGlmIHVTZXJ2aWNlIGJhc2VkLCBjb3VsZCBjaG9vc2UgdG8gaW1wbGVt
ZW50IHRoYXQgYXMgQ0JPUiBXZWIgVG9rZW4sIG9yIHNvbWUgb3RoZXIgdmVyaWZpYWJsZSBibG9i
LCByZXN1bHRpbmcgaW4gdGhlIHNhbWUgZXNzZW50aWFsIGZ1bmN0aW9uLCBhbmQgdGhpcyBpc24n
dCBhZmZlY3RpbmcgdGhlIGNsaWVudCAmbHQ7LSZndDsgQVMgY29udHJhY3QgaW4gYW55IHdheS48
bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZu
YnNwOzwvbzpwPjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFy
Z2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGNsYXNzPSIiPg0K
PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpXZSBoYWQgYSBjYXNl
IG9mIHNpbWlsYXJseSB1bmludGVudGlvbmFsIGxpbWl0aW5nIGluIEpBUiBwcmV2aW91c2x5LCBz
YXlpbmcgdGhhdCB5b3UgaGFkIHRvIGRvIGFuIEhUVFAgbG9va3VwIG9uIHRoZSByZXF1ZXN0X3Vy
aSwgYnV0IEkgYmVsaWV2ZSB0aGF04oCZcyBiZWVuIGJhY2tlZCBvZmYgbm93IGFuZCBtYWRlIGNv
bmRpdGlvbmFsLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxkaXYgY2xhc3M9IiI+VGhhdCB3YXMgcHJlY2lzZWx5IG15IHBvaW50LjxvOnAgY2xhc3M9
IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlZsYWRpbWlyPG86cCBjbGFzcz0iIj48L286
cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIi
IHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A74oCUIEp1c3RpbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpw
PjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRv
bTogNXB0OyIgY2xhc3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBKYW4gMTEsIDIwMjAsIGF0IDU6
MjggQU0sIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl
cmxpbmU7IiBjbGFzcz0iIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv
OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl
cmlmOyIgY2xhc3M9IiI+DQpNeSBzdWdnZXN0aW9uIGlzIHRvIGFic3RhaW4gZnJvbSBzcGVjaWZ5
aW5nIHRoZSBjb25jcmV0ZSBmb3JtIG9mIHRoZSByZXNvdXJjZSBwb2ludGVkIHRvIGJ5IHRoZSBQ
QVIgVVJJLiBSZWdhcmRsZXNzIG9mIFVSSSB0eXBlIChVUk4sIGRvd25sb2FkYWJsZSBodHRwcyBV
Ukwgb3Igc29tZXRoaW5nIGVsc2UpLCBhbmQgZXZlbiBpZiB0aGUgUEFSIGVuZHBvaW50IGFuZCB0
aGUgYXV0aFogZW5kcG9pbnQgYXJlIG1hbmFnZWQgYnkgdHdvIGRpZmZlcmVudA0KIGVudGl0aWVz
IChtaWNyb3NlcnZpY2Ugb3Igb3RoZXIgc2NlbmFyaW8pLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k
aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw
dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkluIHRoZSBD
b25uZWN0MmlkIGltcGxlbWVudGF0aW9uIG9mIFBBUiB0aGUgcmV0dXJuZWQgVVJJIGRvZXNuJ3Qg
cG9pbnQgdG8gYSByZXF1ZXN0IG9iamVjdCBhbmQgaXQgZG9lc24ndCBwb2ludCB0byBhIEpXVCBl
aXRoZXIuIEl0IHBvaW50cyB0byBhbiBpbnRlcm5hbGx5IHN0b3JlZCAmcXVvdDtwcmUtcHJvY2Vz
c2VkJnF1b3Q7IGF1dGhaIHJlcXVlc3QsIHdoaWNoIHRoZSBhdXRoWiBlbmRwb2ludCB0aGVuIHBp
Y2tzIHVwIHRvIGNvbXBsZXRlIHRoZSBhdXRoWi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K
PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpFdmVuIGlmIHdlIGV2
ZW50dWFsbHkgZW5kIHVwIGluIG1pY3Jvc2VydmljZSB3b3JsZCwgb3IgYWxsb3cgdGhlIFBBUiBl
bmRwb2ludCB0byBiZSBtYW5hZ2VkIGJ5IHNvbWUgZXh0ZXJuYWwgZW50aXR5LCB0aGUgUEFSIFVS
SSAtIGl0cyBpbnRlcnByZXRhdGlvbiwgdmFsaWRhdGlvbiBhbmQgcG90ZW50aWFsbHkgcmVzb3Vy
Y2UgcmV0cmlldmFsIChKV1Qgb3Igb3RoZXIgYmxvYiksIGlzIGFuICZxdW90O2ludGVybmFsIGNv
bnRyYWN0JnF1b3Q7IG9uIHRoZSBBUyBzaWRlLg0KIFRoaXMgZG9lc24ndCBjb25jZXJuIHRoZSBj
bGllbnQsIGFuZCBpbiBPQXV0aCAyLjAgdGhlIHJvbGUgb2YgQVMgaXMgaW5kaXZpc2libGUuPG86
cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi
IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSBzZWUgUEFSIHJlcXVlc3QgJiM0Mzsg
YXV0aFogcmVxdWVzdCBhcyBvbmUgbG9naWNhbCBPQXV0aCAyLjAgYXV0aFogcmVxdWVzdDogdGhl
IGNsaWVudCBzdWJtaXRzIGFuIGF1dGhaIHJlcXVlc3QgYW5kIGdldHMgYW4gYXV0aFogcmVzcG9u
c2UgYXQgdGhlIGVuZC4gVGhlIFVSSSBpcyBuZWNlc3NhcnkgZm9yIHRoZSBjbGllbnQgdG8gcHJv
Y2VlZCBmcm9tIHRoZSAxc3QgdG8gdGhlIDJuZCBzdGVwLiBJZiB3ZSBtYW5hZ2UgdG8gZnJhbWUg
LyB3b3JkIHRoZQ0KIFBBUiBVUkkgaW4gdGhpcyBsb2dpY2FsIHdheSwgd2l0aG91dCBnZXR0aW5n
IHN0dWNrIGluIHRoZSBKQVIgZGVmaW5pdGlvbiAvIGZyYW1pbmcgb2Ygd2hhdCB0aGUgcmVxdWVz
dF91cmkgLyBvYmplY3QgaXMsIGl0IHdvdWxkIGJlIGdyZWF0LjxvOnAgY2xhc3M9IiI+PC9vOnA+
PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog
MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg
Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7IiBjbGFzcz0iIj4NClRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgSSB0aGluayBzaG91bGQgZm9j
dXMgb24gbWFpbnRhaW5pbmcgdGhlIE9BdXRoIDIuMCBjb250cmFjdCBmb3IgdGhlIGVudGlyZSBs
b2dpY2FsIGF1dGhaIHJlcXVlc3QsIHRvZ2V0aGVyIHdpdGggdGhlIGJhc2ljIGNvbnRyYWN0cyBv
ZiAxKSBKQVIgYW5kIHRoZSAyKSBhdXRoWiBlbmRwb2ludC48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx
cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs
YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu
MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm
OyIgY2xhc3M9IiI+DQpWbGFkaW1pcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7
PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl
cmlmOyIgY2xhc3M9IiI+DQpPbiAxMC8wMS8yMDIwIDIyOjU1LCBKdXN0aW4gUmljaGVyIHdyb3Rl
OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiIHR5cGU9ImNpdGUi
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpTbyB3ZSBjb3Vs
ZCBzb2x2ZSB0aGlzIGJ5IHNheWluZyB0aGUgcmVzdWx0aW5nIGRhdGEgb2JqZWN0IG9mIGEgUEFS
IGlzIGEgcmVxdWVzdCBvYmplY3QuIFdoaWNoIG1pZ2h0IGFsc28gY29udGFpbiBhIHJlcXVlc3Qg
b2JqZWN0IGludGVybmFsbHkgYXMgd2VsbC4gSW4gdGhhdCBjYXNlIEpBUiBzaG91bGQgYmFjayBv
ZmYgZnJvbSBzYXlpbmcgaXTigJlzIGEgSldUIGFuZCBpbnN0ZWFkIHNheSBpdOKAmXMgYSByZXF1
ZXN0IG9iamVjdC4gT3Igd2UgZGVmaW5lDQogYSBuZXcgdGVybSBmb3IgdGhpcyBhdXRob3JpemF0
aW9uIHJlcXVlc3QgYmxvYiB0aGluZy48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9
IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9yIFBBUiBjb3VsZCBhdCBsZWFzdCBz
YXkgdGhhdCBpZiBpdOKAmXMgZGVyZWZlcmVuY2VkIG92ZXIgYSByZW1vdGUgcHJvdG9jb2wgdGhl
biBpdCBNVVNUIGJlIGEgSldULCBidXQgb3RoZXJ3aXNlIGl0IGNhbiBiZSB3aGF0ZXZlciB5b3Ug
d2FudC4gVGhhdOKAmXMgd2hlcmUgdGhlIHJlYWwgaW50ZXJvcCBjb25jZXJucyBjb21lIGluLjxv
OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7
PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwO+KAlCBKdXN0aW48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i
Ij48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdp
bi1ib3R0b206IDVwdDsiIGNsYXNzPSIiIHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT24gSmFuIDEwLCAyMDIw
LCBhdCAzOjQxIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBw
dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+cmljaGFubmE9NDBh
bWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286
cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9
IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N
CkNvcnJlY3QuIFRoZSBwcm9ibGVtIGJlY29tZXMgcHJldHR5IGNsZWFyIGluIHRoZSBjb250ZXh0
IG9mIFBBUiwgd2hlcmUgdGhlIEFTIGlzIGdlbmVyYXRpbmcgYW5kIHZlbmRpbmcgb3V0IHRoZSBV
UkkgYXQgdGhlIFBBUiBlbmRwb2ludCwgYW5kIGNvbnN1bWluZyBpdCBhdCB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludC4gRnJvbSBhbiBpbnRlcm9wZXJhYmlsaXR5IHN0YW5kcG9pbnQsIGl04oCZ
cyBhbmFsb2dvdXMgdG8gdGhlIEFTIHZlbmRpbmcgYW4NCiBhdXRob3JpemF0aW9uIGNvZGUgYXQg
dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGNvbnN1bWluZyBpdCBhdCB0aGUgdG9rZW4g
ZW5kcG9pbnQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4uMDAwMXB0
OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh
c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+4oCTJm5ic3A7
PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9z
cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cCBjbGFzcz0i
Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVy
LXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IHBh
ZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMnB0OyIgY2xhc3M9IiI+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3
anRiQHZlN2p0Yi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsiIGNsYXNzPSIiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+
DQo8YiBjbGFzcz0iIj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L2I+RnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIGF0IDEyOjI5IFBNPGJyIGNs
YXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvYj5CcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv
cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwv
YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8
YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHN0eWxlPSJjb2xvcjogcHVy
cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0PC9hPiZndDssIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hdEBz
YWtpbXVyYS5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy
bGluZTsiIGNsYXNzPSIiPm5hdEBzYWtpbXVyYS5vcmc8L2E+Jmd0OywNCiAmcXVvdDtSaWNoYXJk
IEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFt
YXpvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu
ZTsiIGNsYXNzPSIiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhy
ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj
b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzxiciBj
bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgt
V0ddIFBBUjogcHVzaGVkIHJlcXVlc3RzIG11c3QgYmVjb21lIEpXVHM8L3NwYW4+PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i
c3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4uMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJZiB3ZSBhc3N1bWUgdGhlIGNsaWVudCBwb3N0cyBh
IEpBUiBhbmQgZ2V0cyBiYWNrIGEgcmVmZXJlbmNlLiZuYnNwOyBUaGVuIHRoZSByZWZlcmVuY2Ug
aXMgdG8gYSBKQVIuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls
eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSB0aGluayBJIHNlZSB0aGUgcHJv
YmxlbS4mbmJzcDsgSWYgdGhlIHNlcnZlciBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZSBpcyBhc3Nv
Y2lhdGVkIHdpdGggdGhlIEFTIHRoZW4gdGhlIHNlcnZlciBkb3Nlbid0IG5lZWQgdG8gZGVyZWZl
cmVuY2UgdGhlIG9iamVjdCB2aWEgSFRUUCwgc28gaXQgY291bGQgYmUgYSBVUk4gYXMgYW4gZXhh
bXBsZS4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl
cmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpTbyB5ZXMgaXQgaXMgbm90IGEgaW50ZXJvcGVy
YWJpbGl0eSBpc3N1ZSBmb3IgdGhlIGNsaWVudC4mbmJzcDsmbmJzcDs8bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpw
IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuLjAwMDFwdDsgZm9u
dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi
Pg0KSSB3aWxsIHRoaW5rIGFib3V0IGhvdyBJIGNhbiBmaW5lc3NlIHRoYXQuJm5ic3A7PG86cCBj
bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z
aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K
Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi
IGNsYXNzPSIiPg0KSSBhZ3JlZSBpdCBpcyBub3QgYSBjaGFuZ2UgaW4gaW50ZW50LiZuYnNwOzxv
OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i
Ij4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7IiBjbGFzcz0iIj4NCkkgd2lsbCBzZWUgaWYgSSBjYW4gZ2V0IG91ciBBRCB0byBhY2NlcHQg
dGhhdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw
MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg
Y2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpKb2huIEIuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i
c3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs
YXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7
IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT24gRnJpLCBKYW4gMTAsIDIwMjAsIDQ6
NTcgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lk
ZW50aXR5LmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs
aW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5iY2Ft
cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIi
PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXIt
c3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBib3Jk
ZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2
cHQ7IG1hcmdpbjogNXB0IDBpbiA1cHQgNC44cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxk
aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl
cmlmOyIgY2xhc3M9IiI+DQpTdXJlIGJ1dCB0aGUgdGV4dCBwcm9wb3NlZCAob3Igc29tZXRoaW5n
IGxpa2UgaXQpIHF1YWxpZmllcyBpdCBzdWNoIHRoYXQgdGhlcmUgYXJlbid0IGludGVyb3BlcmFi
aWxpdHkgcXVlc3Rpb25zIGJlY2F1c2UgaXQncyBvbmx5IGFuIGltcGxlbWVudGF0aW9uIGRldGFp
bCB0byB0aGUgQVMgd2hvIGJvdGggcHJvZHVjZXMgdGhlIFVSSSBhbmQgY29uc3VtZXMgaXRzIGNv
bnRlbnQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJz
cDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDEyOjQ4IFBNIEpvaG4gQnJh
ZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFu
ayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh
c3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj52ZTdqdGJAdmU3anRi
LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBu
b25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2
cHQ7IG1hcmdpbjogNXB0IDBpbiA1cHQgNC44cHQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0
LCAyMDQsIDIwNCk7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsiIGNsYXNzPSIiPg0KSXQgbWF5IGJlIGEgY2hhbGxlbmdlIHRvIGNoYW5nZSB0ZXh0IHNheWlu
ZyB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgcmVzb3VyY2UgY291bGQgYmUgc29tZXRoaW5nIG90
aGVyIHRoYW4gYSByZXF1ZXN0IG9iamVjdC4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi
PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx
cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJZiBub3Qg
YSByZXF1ZXN0IG9iamVjdCB0aGVuIHdoYXQgYW5kIGhvdyBpcyB0aGF0IGludGVyb3BlcmFibGUg
YXJlIGxpa2VseSBBRCBxdWVzdGlvbnMuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls
eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48
L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSBjb3VsZCBw
ZXJoYXBzIHNlZSBjaGFuZ2luZyBpdCB0byBtdXN0IGJlIGEgcmVxdWVzdCBvYmplY3QsIG9yIG90
aGVyIGZvcm1hdCBkZWZpbmVkIGJ5IGEgcHJvZmlsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQpKb2huIEIuJm5ic3A7Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9
IiI+DQpPbiBGcmksIEphbiAxMCwgMjAyMCwgMzo0NSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayIg
c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9
IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lk
ZW50aXR5LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUg
bm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBwYWRkaW5nOiAwaW4gMGlu
IDBpbiA2cHQ7IG1hcmdpbjogNXB0IDBpbiA1cHQgNC44cHQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBy
Z2IoMjA0LCAyMDQsIDIwNCk7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsiIGNsYXNzPSIiPg0KQWdyZWUgYW5kIGFncmVlLiBCdXQgZ2l2ZW4gdGhhdCB0aGUg
Y2hhbmdlIHN1Z2dlc3RlZCBieSBBbm5hYmVsbGUgaGFzIG5vIGltcGFjdCBvbiB0aGUgY2xpZW50
IG9yIGludGVyb3BlcmFiaWxpdHksIHBlcmhhcHMgTmF0IG9yIEpvaG4gY291bGQgd29yayB0aGUg
Y2hhbmdlIGludG8gdGhlIGRyYWZ0IGR1cmluZyB0aGUgZWRpdHMgdGhhdCBoYXBwZW4gZHVyaW5n
IHRoZSBmaW5hbCBzdGFnZXMgb2YgdGhpbmdzPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBUaHUsIEphbiA5LCAyMDIw
IGF0IDE6NTYgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWls
dG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHls
ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48
c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPjQwbG9kZGVyc3RlZHQubmV0QGRt
YXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBu
b25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgYm9yZGVyLWxlZnQt
Y29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJn
aW46IDVwdCAwaW4gNXB0IDQuOHB0OyIgY2xhc3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkkgd291bGQgYXNzdW1lIGdpdmVuIHRoZSBzdGF0dXMg
b2YgSkFSLCB3ZSBkb27igJl0IHdhbnQgdG8gY2hhbmdlIGl0LiBBbmQgYXMgSSBzYWlkLCB0aGlz
IGRpZmZlcmVuY2UgZG9lcyBub3QgaW1wYWN0IGludGVyb3BlcmFiaWxpdHkgZnJvbSBjbGllbnQg
cGVyc3BlY3RpdmUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiIgdHlwZT0i
Y2l0ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7
IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCkFt
IDA5LjAxLjIwMjAgdW0gMDA6NTggc2NocmllYiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAm
bHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+
NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7OjxvOnAgY2xhc3M9IiI+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls
eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+SXQgd291bGQgYmUgbW9y
ZSBhcHByb3ByaWF0ZSB0byBhZGQgdGhlIHRleHQgdG8gSkFSIHJhdGhlciB0aGFuIFBBUi4gSXQg
ZG9lc24ndCBzZWVtIHJpZ2h0IGZvciBQQVIgdG8gcmV0Y29uIHJ1bGVzIGluIEpBUi4gTW92aW5n
IHRoZSB0ZXh0IHRvIEpBUiBhbHNvIGhpZ2hsaWdodHMgdGhlIHdlaXJkbmVzcyBvZiBnaXZpbmcg
UEFSIHNwZWNpYWwNCiB0cmVhdG1lbnQuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu
MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IiBjbGFzcz0iIj5XaGF0IGlmIHdlIGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBpbiBT
ZWN0aW9uIDUuMiBvZiBKQVI6PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm
cXVvdDs7IiBjbGFzcz0iIj5UaGUgY29udGVudHMgb2YgdGhlIHJlc291cmNlIHJlZmVyZW5jZWQg
YnkgdGhlIFVSSSBNVVNUIGJlIGEgUmVxdWVzdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAw
LjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi
IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5PYmplY3QuPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPjxvOnAg
Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
OXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7PG86cCBjbGFzcz0i
Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPlRvOjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAm
cXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPlRoZSBjb250ZW50cyBvZiB0aGUgcmVz
b3VyY2UgcmVmZXJlbmNlZCBieSB0aGUgVVJJIE1VU1QgYmUgYSBSZXF1ZXN0PC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIi
PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7
IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPk9iamVjdCwg
dW5sZXNzIHRoZSBVUkkgd2FzIHByb3ZpZGVkIHRvIHRoZSBjbGllbnQgYnkgdGhlIEF1dGhvcml6
YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIg
Y2xhc3M9IiI+U2VydmVyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx
cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj
bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsiIGNsYXNzPSIiPiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw
MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IiBjbGFzcz0iIj5UaGlzIHdvdWxkIGFsbG93IGZvciB1c2UgY2FzZXMgc3VjaCBhcyBh
biBBUyB0aGF0IHByb3ZpZGVzIHByZS1kZWZpbmVkIHJlcXVlc3QgVVJJcywgb3IgdmVuZHMgcmVx
dWVzdCBVUklzIHZpYSBhIGNsaWVudCBtYW5hZ2VtZW50IGNvbnNvbGUsIG9yIGJha2VzIHRoZW0g
aW50byB0aGVpciBjbGllbnQgYXBwcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi
IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsiIGNsYXNzPSIiPuKAkzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u
dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIg
Y2xhc3M9IiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z
cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj5BV1MgSWRlbnRpdHk8bzpwIGNsYXNzPSIiPjwv
bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7PG86cCBjbGFzcz0iIj48
L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlw
dDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPk9uIDEvOC8yMCwgMjo1MCBQTSwg
JnF1b3Q7VG9yc3RlbiBMb2RkZXJzdGVkdCZxdW90OyAmbHQ7dG9yc3Rlbj08YSBocmVmPSJtYWls
dG86NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHls
ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48
c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPjQwbG9kZGVyc3RlZHQubmV0QGRt
YXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48
L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+
PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgSGksPHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9
IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9
IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eW91IGFyZSByaWdodCwgUEFSIGRvZXMgbm90IHJl
cXVpcmUgdGhlIEFTIHRvIHJlcHJlc2VudCB0aGUgcmVxdWVzdCBhcyBhIEpXVC1iYXNlZCByZXF1
ZXN0IG9iamVjdC4gVGhlIFVSSSBpcyB1c2VkIGFzIGludGVybmFsIHJlZmVyZW5jZSBvbmx5LiBU
aGF0IHdoeSB0aGUgZHJhZnQgc3RhdGVzPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnAgY2xhc3M9IiI+
PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5
cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmcXVvdDtUaGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgdGhlPG86cCBjbGFzcz0iIj48L286
cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn
aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsg
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0
YSBhdmFpbGFibGUgdG8gb3RoZXIgcGFydGllcyB2aWEgdGhpczxvOnAgY2xhc3M9IiI+PC9vOnA+
PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJLuKAnTxvOnAgY2xhc3M9IiI+PC9vOnA+
PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48
L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlw
dDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO1RoaXMgZGlmZmVyZW5jZSBtYXR0ZXJzIGZyb20gYW4gQVMgaW1wbGVtZW50YXRpb24gcGVy
c3BlY3RpdmUsIGl0IGRvZXNuJ3QgbWF0dGVyIGZyb20gYSBjbGllbnQncyAoaW50ZXJvcCkgcGVy
c3BlY3RpdmUuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNz
PSIiPiZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u
dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIg
Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2UgbWF5IGFkZCBhIHN0YXRlbWVudCB0
byBQQVIgc2F5aW5nIHRoYXQgcmVxdWVzdF91cmlzIGlzc3VlZCBieSB0aGUgUEFSIG1lY2hhbmlz
bSAoTUFZKSBkZXZpYXRlIGZyb20gdGhlIEpBUiBkZWZpbml0aW9uLjxvOnAgY2xhc3M9IiI+PC9v
OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7
IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmVzdCByZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z
cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgVG9yc3Rlbi4m
bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9
IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IE9uIDguIEphbiAyMDIwLCBh
dCAyMzo0MiwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9
Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHls
ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48
c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPjQwYW1hem9uLmNvbUBkbWFyYy5p
ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu
PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jmd0OyBIaSBhbGwsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsi
IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu
PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IFRo
ZSBjdXJyZW50IGRyYWZ0cyBvZiBQQVIgKC0wMCkgYW5kIEpBUiAoLTIwKSByZXF1aXJlIHRoYXQg
dGhlIEFTIHRyYW5zZm9ybSBhbGwgcHVzaGVkIHJlcXVlc3RzIGludG8gSldUcy4gVGhpcyByZXF1
aXJlbWVudCBhcmlzZXMgZnJvbSB0aGUgZm9sbG93aW5nOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z
cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIFBBUiB1c2VzIHRoZSBy
ZXF1ZXN0X3VyaSBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBKQVIgdG8gY29tbXVuaWNhdGUgdGhlIHB1
c2hlZCByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LjxvOnAgY2xhc3M9IiI+
PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5
cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsg
Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIEFjY29y
ZGluZyB0byBKQVIsIHRoZSByZXNvdXJjZSByZWZlcmVuY2VkIGJ5IHJlcXVlc3RfdXJpIE1VU1Qg
YmUgYSBSZXF1ZXN0IE9iamVjdC4gKFNlY3Rpb24gNS4yKTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z
cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIFJlcXVlc3QgT2JqZWN0
IGlzIGRlZmluZWQgdG8gYmUgYSBKV1QgY29udGFpbmluZyBhbGwgdGhlIGF1dGhvcml6YXRpb24g
cmVxdWVzdCBwYXJhbWV0ZXJzLiAoU2VjdGlvbiAyLjEpPG86cCBjbGFzcz0iIj48L286cD48L3Nw
YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp
biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1m
YW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xh
c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmZ3Q7IFRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoaXMgcmVxdWlyZW1lbnQgdG8g
c3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5LCBhcyB0aGlzIGlzIGludGVybmFsIHRvIHRoZSBBUy4g
SXQgaXMgYWxzbyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgcmVzdCBvZiBKQVIsIHdoaWNoIGF2b2lk
cyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgaW50ZXJuYWwNCiBjb21tdW5pY2F0aW9ucyBiZXR3
ZWVuIHRoZSB0d28gQVMgZW5kcG9pbnRzLiBXb3JzZSwgdGhpcyByZXN0cmljdGlvbiBtYWtlcyBp
dCBoYXJkZXIgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGxldmVyYWdlIHZhbGlk
YXRpb24gYW5kIG90aGVyIHdvcmsgcGVyZm9ybWVkIGF0IHRoZSBQQVIgZW5kcG9pbnQsIGFzIHRo
ZSBzdGF0ZSBvciBvdXRjb21lIG9mIHRoYXQgd29yayBtdXN0IGJlIGZvcmNlZCBpbnRvIHRoZSBK
V1QgZm9ybWF0DQogKG9yIHJldHJpZXZlZCB2aWEgYSBzdWJzZXF1ZW50IHNlcnZpY2UgY2FsbCBv
ciBkYXRhYmFzZSBsb29rdXApLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh
c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOzxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250
LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0
OyDigJM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZndDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnAgY2xhc3M9
IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OyBBV1MgSWRlbnRpdHk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDs8c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48
L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZn
dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwIGNs
YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw
aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt
c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p
bHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0
LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVy
cGxlOyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi4ub3JnPC9zcGFuPjwvYT48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf
YmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi
IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cCBjbGFzcz0i
Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw
OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNs
YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m
YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGlu
ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs
aW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5PQXV0
aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJj
b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFu
IHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGJv
cmRlcjogMXB0IG5vbmUgd2luZG93dGV4dDsgcGFkZGluZzogMGluOyIgY2xhc3M9IiI+Q09ORklE
RU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k
IHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj
aXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbg0KIG9yIGRpc2Nsb3N1cmUg
Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls
ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwv
Yj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7
IGJvcmRlcjogMXB0IG5vbmUgd2luZG93dGV4dDsgcGFkZGluZzogMGluOyIgY2xhc3M9IiI+Q09O
RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg
YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg
cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbg0KIG9yIGRpc2Nsb3N1
cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl
bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55
IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwv
aT48L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4uMDAwMXB0OyBmb250LXNpemU6
IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh
biBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0i
Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz
cz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k
ZXJsaW5lOyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNv
bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7
PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286
cD48L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnAgY2xhc3M9
IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xh
c3M9IiI+T0F1dGggbWFpbGluZyBsaXN0PG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh
bWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsiIGNsYXNzPSIiPk9BdXRoQGlldGYuLm9yZzwvYT48bzpwIGNsYXNzPSIiPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHN0eWxl
PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cCBjbGFzcz0i
Ij48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLi4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7OyIgY2xhc3M9IiI+LS0gPG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh
bWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5WbGFkaW1pciBEemh1dmlu
b3Y8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp
emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8
bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9u
dC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xhc3M9IiI+LS0gPG86cCBjbGFz
cz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBj
bGFzcz0iIj5WbGFkaW1pciBEemh1dmlub3Y8L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9IiI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIGNs
YXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxiciBjbGFz
cz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xh
c3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNz
PSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N
Ck9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp
ZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgY2xhc3M9IiI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_0080796724524DB0AF0C5BE7EA92B3A7amazoncom_--


From nobody Thu Jan 16 16:38: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 BF1211200C7 for ; Thu, 16 Jan 2020 16:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 BeYTnYAW-DRp for ; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DC3120059 for ; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id b22so9084147pls.12 for ; Thu, 16 Jan 2020 16:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HwfmOsoazhSxXl2uRKkTw2hQsvPP14ciWgH7ujJqrk4=; b=vQtGDo/kkO/LRHjlwfb9r6GbaZL1My0w9pRyNJPwnh2XeAcQYHh/3X4tEL34daidR3 teyqCGBktd31QQL3tUoZXnVEaSUuh8sdk0eR13ayw43CcwRGw+6GqAi65Q85pfn65bZi f2VxN8Z8f2ZdM1EulM0yufp8/4GcmgmGdOQ31UNmcXnqYLiWcugd1aiaKukNWsWYsIcH 4ay7WKre/zTnCskRpECgEfL/BwCaTg1IEJBN0RUcr68T3AW3brcccsRa67VYHJxhSaXY /qfPSpjOrmkSDOIRaMM1OQFLqQ/upOoQ9oHUXxyMSIE7g3DMQv7HQnm3MrcYsqXaSKi6 Q5/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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HwfmOsoazhSxXl2uRKkTw2hQsvPP14ciWgH7ujJqrk4=; b=YitS067ohx7Tl6W5GJl/ER8PJUB9jy+pRr88uYiSlRHOxG7El2OoDsisCZ9DA7LBKV RpLmnpZTaTHyimfJX+K92JaGTJwg/TywZSPdIagMBB4UUCzi+Uf5slb/ZY41LeLMKqCA zPzYNESTKJfxKCLlfILOSJQxrOA4ySsXiF84+xO4vkiIzaUhzJVB94hztIDgGFIL0ddF 6wx6YrWT+4Uprip4z4T49Z7SSBaI1EdDgudrRadKN7ivalkl1c/IdaaqkoOg45tjAj9J M30oJYULoxAAKg/RH5AXA6EkJfTNRXzpXLEgo9ho12Jt27jrhDVug7DaBJf2s5vOz/lw apbw==
X-Gm-Message-State: APjAAAXFPa9u+cxs3h7cBnWGhsDtoxX7gudnmwlsKzLTc1La5hLHzhgI VP4YqwPrJcOo1X6txFtBOb9CjcSmmVo=
X-Google-Smtp-Source: APXvYqzwrZ9wq+PW0OqAvLqVCCcpUn6whhHV/EUo9eHoxm762C5fYmjrzZouL8is3LDHHK3KxKa4Ng==
X-Received: by 2002:a17:902:c693:: with SMTP id r19mr37067017plx.25.1579221488695;  Thu, 16 Jan 2020 16:38:08 -0800 (PST)
Received: from [192.168.128.107] (ai126165179117.73.access-internet.ne.jp. [126.165.179.117]) by smtp.gmail.com with ESMTPSA id g11sm25850704pgd.26.2020.01.16.16.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 16:38:07 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Joseph Heenan 
In-Reply-To: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Fri, 17 Jan 2020 09:38:01 +0900
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 00:38:13 -0000

I agree with this, particularly the security concerns of merging. If we =
merge, we can much guarantee there will eventually be a security issue =
where an attacker is able to gain an advantage by adding a parameter to =
the url query (which the server would then happily process if that =
parameter isn=E2=80=99t found inside the request object). Ruling out =
that case makes security analysis (particularly when creating new OAuth2 =
parameters) significantly simpler.

Putting the iss in the JWE header and having the client_id duplicated =
outside the request object seem to address all the concerns I=E2=80=99ve =
seen raised.

(It seems like it may be unnecessary to have the client_id duplicated =
outside if the request_uri is a PAR one though.)

Joseph



> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>=20
> I agree with the IESG reasoning that merging is problimatic.  Once we
> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.
>=20
> Query paramaters can still be sent outside the JAR, but if they are in
> the OAuth registry the AS MUST ignore them.
>=20
> Puting the iss in the JWE headder addresses the encryption issue =
without
> merging.
>=20
> I understand that some existing servers have dependencys on getting =
the
> clientID as a query paramater.
>=20
> Is that the only paramater that people have a issue with as oposed to =
a
> nice to have?
>=20
> Would allowing the AS to not ignore the clientID as a query paramater =
as
> long as it matches the one inside the JAR, basicly the same as Connect
> request object but for just the one paramater make life easier for the
> servers?
>=20
> I am not promising a change but gathering info before proposing =
something.
>=20
> John B.
>=20
>=20
> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>> Well, embedding a client_id claim in the JWE header in order to
>>>> achieve "request parameters outside the request object should not =
be
>>>> referred to" is like "putting the cart before the horse". Why do we
>>>> have to avoid using the traditional client_id request parameter so
>>>> stubbornly?
>>>>=20
>>>> The last paragraph of Section 3.2.1
>>>>  of RFC 6749 =
says
>>>> as follows.
>>>>=20
>>>>    /A client MAY use the "client_id" request parameter to identify
>>>>    itself when sending requests to the token endpoint.  In the
>>>>    "authorization_code" "grant_type" request to the token endpoint,
>>>>    *an unauthenticated client MUST send its "client_id" to prevent
>>>>    itself from inadvertently accepting a code intended for a client
>>>>    with a different "client_id".*  This protects the client from
>>>>    substitution of the authentication code.  (It provides no
>>>>    additional security for the protected resource.)/
>>>>=20
>>>>=20
>>>> If the same reasoning applies, a client_id must always be sent with
>>>> request / request_uri because client authentication is not =
performed
>>>> at the authorization endpoint. In other words, */an unauthenticated
>>>> client (every client is unauthenticated at the authorization =
endpoint)
>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>> accepting a request object for a client with a different =
"client_id"./*
>>>>=20
>>> Identifying the client in JAR request_uri requests can be really =
useful
>>> so that an AS which requires request_uri registration to prevent =
DDoS
>>> attacks and other checks can do those without having to index all
>>> request_uris individually. I mentioned this before.
>>>=20
>>> I really wonder what the reasoning of the IESG reviewers was to =
insist
>>> on no params outside the JAR JWT / request_uri.
>>>=20
>>> I'm beginning to realise this step of the review process isn't
>>> particularly transparent to WG members.
>> Could you expand on that a bit more?  My understanding is that the =
IESG
>> ballot mail gets copied to the WG precisely so that there is =
transparency,
>> e.g., the thread starting at
>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>> Which admittely is from almost three years ago, but that's the =
earliest
>> that I found that could be seen as the source of this behavior.
>>=20
>> -Ben
>>=20
>> P.S. some other discussion at
>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 =
and
>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY =
and
>> so on.
>>=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 Jan 16 19:39: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 33970120099 for ; Thu, 16 Jan 2020 19:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 eTz6sGgouu1U for ; Thu, 16 Jan 2020 19:38:57 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767F7120044 for ; Thu, 16 Jan 2020 19:38:57 -0800 (PST)
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 00H3cpDs026788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 22:38:53 -0500
Date: Thu, 16 Jan 2020 19:38:50 -0800
From: Benjamin Kaduk 
To: Nat Sakimura 
Cc: Neil Madden , IETF oauth WG 
Message-ID: <20200117033850.GO80030@kduck.mit.edu>
References:   <20200116143233.GJ80030@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] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 03:39:00 -0000

On Fri, Jan 17, 2020 at 12:47:45AM +0900, Nat Sakimura wrote:
> Right. We could add a security consideration like that, though the
> mitigation probably is pretty much the same as what is stated in 10.4.1:
> 
> the server should (a) check that
>    the value of "request_uri" parameter does not point to an unexpected
>    location, (b) check the content type of the response is "application/
>    oauth.authz.req+jwt" (c) implement a time-out for obtaining the
>    content of "request_uri", and (d) not perform recursive GET on the
>    "request_uri".
> 
> If not, please let me know so that we can add that as the mitigation as
> well.

We should probably make sure that we talk about the risks and scope of
potential problems if these checks are not correctly performed.  (I forget
whether we talk about them already or not.)

> Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt
> but it has to validate that content is a valid request object anyways and
> if it is malformed, it MUST stop the processing and return an error
> invalid_request_uri. So, unlike in the case of Capital One's SSRF, the
> content of the request_uri will not be exposed. The main downside is
> therefore as depicted in the current draft, consumption of the network and
> processing power of the AS, and the unwanted access load to the servers
> serving the URL pointed by request_uri. The above-quoted mitigations were
> introduced to address these issues.

Understood; thanks.

-Ben

> 
> 
> 
> On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk  wrote:
> 
> > It is not too late to add to the security considerations.
> >
> > It seems that the new application/oauth.authz.req+jwt media-type is helpful
> > in this regard, in that if an AS can require that content-type from
> > dereferencing the request_uri, then seeing anything else indicates that the
> > request was bogus (or an attack).  I guess existing OIDC deployments aren't
> > exactly in a position to do that, though.
> >
> > -Ben
> >
> > On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:
> > > Is it too late to add it to the security considerations for JAR?
> > >
> > > — Neil
> > >
> > > > On 16 Jan 2020, at 08:15, Dominick Baier 
> > wrote:
> > > >
> > > > 
> > > > Agreed - that’s why we disabled request_uri by default and added
> > extensibility points to implement validation.
> > > >
> > > > I thought it is odd that this was not mentioned in the typical
> > “security considerations” in the OIDC spec..
> > > >
> > > > ———
> > > > Dominick Baier
> > > >
> > > >> On 16. January 2020 at 08:07:44, Neil Madden (
> > neil.madden@forgerock.com) wrote:
> > > >>
> > > >> If the AS can’t validate the request_uri it may also open itself up
> > to SSRF attacks where a malicious client uses the request_uri to
> > probe/attack resources inside the AS’s private network. This was a crucial
> > part of the recent Capital One breach for example [1].  ForgeRock currently
> > requires strict validation of request_uris against a client-specific
> > whitelist for exactly this reason.
> > > >>
> > > >> NB some clients might legitimately be on that private network (eg
> > microservices) so changing to a global whitelist for all clients is
> > undesirable.
> > > >>
> > > >> [1]: https://ejj.io/blog/capital-one
> > > >>
> > > >> — Neil
> > > >>
> > > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <
> > vladimir@connect2id.com> wrote:
> > > >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > > >>>> Well, embedding a client_id claim in the JWE header in order to
> > achieve "request parameters outside the request object should not be
> > referred to" is like "putting the cart before the horse". Why do we have to
> > avoid using the traditional client_id request parameter so stubbornly?
> > > >>>>
> > > >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
> > > >>>>
> > > >>>> A client MAY use the "client_id" request parameter to identify
> > itself when sending requests to the token endpoint.  In the
> > "authorization_code" "grant_type" request to the token endpoint, an
> > unauthenticated client MUST send its "client_id" to prevent itself from
> > inadvertently accepting a code intended for a client with a different
> > "client_id".  This protects the client from substitution of the
> > authentication code.  (It provides no additional security for the protected
> > resource.)
> > > >>>>
> > > >>>> If the same reasoning applies, a client_id must always be sent with
> > request / request_uri because client authentication is not performed at the
> > authorization endpoint. In other words, an unauthenticated client (every
> > client is unauthenticated at the authorization endpoint) MUST send its
> > "client_id" to prevent itself from inadvertently accepting a request object
> > for a client with a different "client_id".
> > > >>>>
> > > >>> Identifying the client in JAR request_uri requests can be really
> > useful so that an AS which requires request_uri registration to prevent
> > DDoS attacks and other checks can do those without having to index all
> > request_uris individually. I mentioned this before.
> > > >>>
> > > >>> I really wonder what the reasoning of the IESG reviewers was to
> > insist on no params outside the JAR JWT / request_uri.
> > > >>>
> > > >>> I'm beginning to realise this step of the review process isn't
> > particularly transparent to WG members.
> > > >>>
> > > >>> Vladimir
> > > >>>
> > > >>>
> > > >>>
> > > >>>> Best Regards,
> > > >>>> Taka
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <
> > vladimir@connect2id.com> wrote:
> > > >>>>> John, thanks, much appreciated!
> > > >>>>>
> > > >>>>>> On 11/01/2020 21:36, John Bradley wrote:
> > > >>>>>> Yes JAR is not prohibiting paramater replication in the header.
> > > >>>>>>
> > > >>>>>> I will see if i can add something in final edits to call that out.
> > > >>>>>>
> > > >>>>>> John B.
> > > >>>>>>
> > > >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> > > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this
> > parameter replication be used for client_id or the client_id ass "iss" even
> > though it isn't explicitly mentioned in the JAR spec?
> > > >>>>>>>
> > > >>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
> > > >>>>>>>> Right we just don't say to put the iss there in OIDC if it's
> > symetricly encrypted.
> > > >>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose
> > that why the possibility to replicate params to the JWE header isn't
> > mentioned at all. OIDC requires the top-level query params to represent a
> > valid OAuth 2.0 request, and there client_id is required. If the client_id
> > is present the client registration together with any present client_secret
> > can be retrieved.
> > > >>>>>>>
> > > >>>>>>> I reread the JAR spec, this is the only place that mentions
> > handling of symmetric JWE.
> > > >>>>>>>
> > > >>>>>>>
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> > > >>>>>>>
> > > >>>>>>>> (b)  Verifying that the symmetric key for the JWE encryption is
> > the
> > > >>>>>>>>         correct one if the JWE is using symmetric encryption.
> > > >>>>>>>
> > > >>>>>>> Vladimir
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <
> > Michael.Jones@microsoft.com> wrote:
> > > >>>>>>>>> The technique of replicating JWT claims that need to be
> > publicly visible in an encrypted JWT in the header is defined at
> > https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
> > for bringing this need to my attention as we were finishing the JWT spec.)
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>                                                        -- Mike
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> From: OAuth  On Behalf Of John Bradley
> > > >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
> > > >>>>>>>>> To: Vladimir Dzhuvinov 
> > > >>>>>>>>> Cc: IETF oauth WG 
> > > >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
> > Request (JAR) vs OIDC request object
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> The intent was to do that, but specs change once the OAuth WG
> > and IESG get there hands on them.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Being backwards compatible with OIDC is not a compelling
> > argument to the IESG.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> We were mostly thinking of asymmetric encryption.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Specifying puting the issuer and or the audience in the
> > headder has come up in the past but probably is not documented.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> John B
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <
> > vladimir@connect2id.com> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> Yes, putting the client_id into the JWE header is a way around
> > the need
> > > >>>>>>>>> to have the client_id outside the JWE as top-level authZ
> > request parameter.
> > > >>>>>>>>>
> > > >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I
> > just checked
> > > >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
> > > >>>>>>>>>
> > > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies
> > on the
> > > >>>>>>>>> presence of client_id as top-level parameter, together with
> > requiring
> > > >>>>>>>>> RPs to register their request_uri's (so that we don't need to
> > build and
> > > >>>>>>>>> store an index of all request_uri's). I just had a look at
> > "DDoS Attack
> > > >>>>>>>>> on the Authorization Server" and also realised the request_uri
> > > >>>>>>>>> registration isn't explicitly mentioned as attack prevention
> > ("the
> > > >>>>>>>>> server should (a) check that the value of "request_uri"
> > parameter does
> > > >>>>>>>>> not point to an unexpected location").
> > > >>>>>>>>>
> > > >>>>>>>>>
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> > > >>>>>>>>>
> > > >>>>>>>>> To be honest, I feel quite bad about the situation with JAR we
> > are in
> > > >>>>>>>>> now. For some reason I had the impression that OAuth JAR was
> > going to be
> > > >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as
> > with other
> > > >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
> > > >>>>>>>>>
> > > >>>>>>>>> I find it unfortunate I didn't notice this when I was
> > reviewing the spec
> > > >>>>>>>>> in the past.
> > > >>>>>>>>>
> > > >>>>>>>>> Vladimir
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
> > > >>>>>>>>> > Vladimir,
> > > >>>>>>>>> >
> > > >>>>>>>>> > For that very case the payload claims may be repeated in the
> > JWE protected header. An implementation wanting to handle this may look for
> > iss/client_id there.
> > > >>>>>>>>> >
> > > >>>>>>>>> > Odesláno z iPhonu
> > > >>>>>>>>> >
> > > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <
> > vladimir@connect2id.com>:
> > > >>>>>>>>> >>
> > > >>>>>>>>> >> I just realised there is one class of JARs where it's
> > practially
> > > >>>>>>>>> >> impossible to process the request if merge isn't supported:
> > > >>>>>>>>> >>
> > > >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key.
> > OIDC allows
> > > >>>>>>>>> >> for that and specs a method for deriving the shared key
> > from the
> > > >>>>>>>>> >> client_secret:
> > > >>>>>>>>> >>
> > > >>>>>>>>> >>
> > https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> > > >>>>>>>>> >>
> > > >>>>>>>>> >> If the JAR is encrypted with the client_secret, and there
> > is no
> > > >>>>>>>>> >> top-level client_id parameter, there's no good way for the
> > OP to find
> > > >>>>>>>>> >> out which client_secret to get to try to decrypt the JWE.
> > Unless the OP
> > > >>>>>>>>> >> keeps an index of all issued client_secret's.
> > > >>>>>>>>> >>
> > > >>>>>>>>> >>
> > > >>>>>>>>> >> OP servers which require request_uri registration
> > > >>>>>>>>> >> (require_request_uri_registration=true) and don't want to
> > index all
> > > >>>>>>>>> >> registered request_uri's, also have no good way to process
> > a request_uri
> > > >>>>>>>>> >> if the client_id isn't present as top-level parameter.
> > > >>>>>>>>> >>
> > > >>>>>>>>> >>
> > > >>>>>>>>> >> Vladimir
> > > >>>>>>>>> >>
> > > >>>>>>>>> >>
> > > >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> > > >>>>>>>>> >>>
> > > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <
> > ve7jtb@ve7jtb.com>:
> > > >>>>>>>>> >>>> I think Torsten is speculating that is not a feature
> > people use.
> > > >>>>>>>>> >>> I’m still trying to understand the use case for merging
> > signed and unsigned parameters. Nat once explained a use case, where a
> > client uses parameters signed by a 3rd party (some „certification
> > authority“) in combination with transaction-specific parameters. Is this
> > being done in the wild?
> > > >>>>>>>>> >>>
> > > >>>>>>>>> >>> PS: PAR would work with both modes.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> _______________________________________________
> > > >>>>>>>>> OAuth mailing list
> > > >>>>>>>>> OAuth@ietf.org
> > > >>>>>>>>> https://
> > > >>>>>>>>>
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> OAuth mailing list
> > > >>>>> OAuth@ietf.org
> > > >>>>> https://www.ietf.org/mailman/listinfo/oauth
> > > >>> --
> > > >>> Vladimir Dzhuvinov
> > > >>> _______________________________________________
> > > >>> OAuth mailing list
> > > >>> OAuth@ietf.org
> > > >>> https://www.ietf.org/mailman/listinfo/oauth
> > > >> _______________________________________________
> > > >> OAuth mailing list
> > > >> OAuth@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en


From nobody Thu Jan 16 19:58: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 5716C1200C7 for ; Thu, 16 Jan 2020 19:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2EDPjnD5BkX for ; Thu, 16 Jan 2020 19:58:50 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94948120044 for ; Thu, 16 Jan 2020 19:58:50 -0800 (PST)
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 00H3wj6b031433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 22:58:47 -0500
Date: Thu, 16 Jan 2020 19:58:44 -0800
From: Benjamin Kaduk 
To: Neil Madden 
Cc: Nat Sakimura , IETF oauth WG 
Message-ID: <20200117035844.GQ80030@kduck.mit.edu>
References:   <20200116143233.GJ80030@kduck.mit.edu>  <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 03:58:52 -0000

On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote:
> The mitigations of 10.4.1 are related, but the section heading is about (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF attacks too or else add another section with similar mitigations. 
> 
> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is otherwise known to be safe (e.g., is a URI scheme controlled by the AS itself as with PAR).

pedantic nit: "URI scheme" is probably not what we want, as the authority
component of the URI (per RFC 3986) seems more likely to match "controlled
by the AS itself"

-Ben

> In addition for this to be effective the AS should not follow redirects when fetching the URI. It's not clear to me whether that is implied by "not perform recursive GET" so it may be worth explicitly spelling that out.
> 


From nobody Fri Jan 17 05:44: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 B87EB12002E for ; Fri, 17 Jan 2020 05:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Fprs2NTUIGfB for ; Fri, 17 Jan 2020 05:44:22 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1C112001A for ; Fri, 17 Jan 2020 05:44:21 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00HDiIbH024356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 08:44:19 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D632EF00-20CE-4937-BED3-AA08405EE7F5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 17 Jan 2020 08:44:18 -0500
In-Reply-To: <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>
Cc: John Bradley , oauth 
To: Joseph Heenan 
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 13:44:25 -0000

--Apple-Mail=_D632EF00-20CE-4937-BED3-AA08405EE7F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I don=E2=80=99t agree with this stance from a security or implementation =
perspective.=20

If there=E2=80=99s a clear order of precedence for the information, =
it=E2=80=99s not particularly problematic. Everything inside the request =
object is to be taken over things outside the request object. We have =
the exact same semantics and process with dynamic registration, where =
the software statement is carried alongside plain JSON claims, and the =
two are mixed with a very simple algorithm:

 - If a field is inside the signed payload, use that value and ignore =
any copy of it on the outside
 - If a field is not inside the signed payload and is outside the signed =
payload, use the outside value

Can someone please point out a concrete security issue with this =
algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics =
that we need here, and it would solve not only the ability to use this =
for use cases that call for a more static request object (perhaps signed =
by a third party and not the client) along side the plain parameters =
that can vary, but also the backwards compatibility issue that=E2=80=99s =
been discussed. With this algorithm in place, you could have OIDC =
clients actually be compliant with the spec, since OIDC requires =
replication of the values inside the request object on the outside with =
exact matches. An OIDC server wouldn=E2=80=99t be fully compliant with =
the new spec since it would reject some compliant JAR requests that are =
missing the external parameters, but that=E2=80=99s fairly easy logic to =
add on the OIDC side. And in that case you get a matrix of compatibility =
like:


              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |      NO      |
OIDC Client |     YES    |     YES      |

Breaking one out of the four possible combinations in a very predictable =
way is, I think, the best way to handle backwards compatibility here.=20

But between this issue and JAR=E2=80=99s problematic call for the value =
of a request_uri to always be a JWT and be fetchable by the AS (neither =
of which are true in the case of PAR) makes me think we need to pull =
this back and rework those things, in a push back to the IESG=E2=80=99s =
comments.

 =E2=80=94 Justin


> On Jan 16, 2020, at 7:38 PM, Joseph Heenan  =
wrote:
>=20
> I agree with this, particularly the security concerns of merging. If =
we merge, we can much guarantee there will eventually be a security =
issue where an attacker is able to gain an advantage by adding a =
parameter to the url query (which the server would then happily process =
if that parameter isn=E2=80=99t found inside the request object). Ruling =
out that case makes security analysis (particularly when creating new =
OAuth2 parameters) significantly simpler.
>=20
> Putting the iss in the JWE header and having the client_id duplicated =
outside the request object seem to address all the concerns I=E2=80=99ve =
seen raised.
>=20
> (It seems like it may be unnecessary to have the client_id duplicated =
outside if the request_uri is a PAR one though.)
>=20
> Joseph
>=20
>=20
>=20
>> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>>=20
>> I agree with the IESG reasoning that merging is problimatic.  Once we
>> allow that given a unknown list of possible paramaters with diffrent
>> security properties it would be quite difficult to specify safely.
>>=20
>> Query paramaters can still be sent outside the JAR, but if they are =
in
>> the OAuth registry the AS MUST ignore them.
>>=20
>> Puting the iss in the JWE headder addresses the encryption issue =
without
>> merging.
>>=20
>> I understand that some existing servers have dependencys on getting =
the
>> clientID as a query paramater.
>>=20
>> Is that the only paramater that people have a issue with as oposed to =
a
>> nice to have?
>>=20
>> Would allowing the AS to not ignore the clientID as a query paramater =
as
>> long as it matches the one inside the JAR, basicly the same as =
Connect
>> request object but for just the one paramater make life easier for =
the
>> servers?
>>=20
>> I am not promising a change but gathering info before proposing =
something.
>>=20
>> John B.
>>=20
>>=20
>> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>>> Well, embedding a client_id claim in the JWE header in order to
>>>>> achieve "request parameters outside the request object should not =
be
>>>>> referred to" is like "putting the cart before the horse". Why do =
we
>>>>> have to avoid using the traditional client_id request parameter so
>>>>> stubbornly?
>>>>>=20
>>>>> The last paragraph of Section 3.2.1
>>>>>  of RFC 6749 =
says
>>>>> as follows.
>>>>>=20
>>>>>   /A client MAY use the "client_id" request parameter to identify
>>>>>   itself when sending requests to the token endpoint.  In the
>>>>>   "authorization_code" "grant_type" request to the token endpoint,
>>>>>   *an unauthenticated client MUST send its "client_id" to prevent
>>>>>   itself from inadvertently accepting a code intended for a client
>>>>>   with a different "client_id".*  This protects the client from
>>>>>   substitution of the authentication code.  (It provides no
>>>>>   additional security for the protected resource.)/
>>>>>=20
>>>>>=20
>>>>> If the same reasoning applies, a client_id must always be sent =
with
>>>>> request / request_uri because client authentication is not =
performed
>>>>> at the authorization endpoint. In other words, */an =
unauthenticated
>>>>> client (every client is unauthenticated at the authorization =
endpoint)
>>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>>> accepting a request object for a client with a different =
"client_id"./*
>>>>>=20
>>>> Identifying the client in JAR request_uri requests can be really =
useful
>>>> so that an AS which requires request_uri registration to prevent =
DDoS
>>>> attacks and other checks can do those without having to index all
>>>> request_uris individually. I mentioned this before.
>>>>=20
>>>> I really wonder what the reasoning of the IESG reviewers was to =
insist
>>>> on no params outside the JAR JWT / request_uri.
>>>>=20
>>>> I'm beginning to realise this step of the review process isn't
>>>> particularly transparent to WG members.
>>> Could you expand on that a bit more?  My understanding is that the =
IESG
>>> ballot mail gets copied to the WG precisely so that there is =
transparency,
>>> e.g., the thread starting at
>>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>>> Which admittely is from almost three years ago, but that's the =
earliest
>>> that I found that could be seen as the source of this behavior.
>>>=20
>>> -Ben
>>>=20
>>> P.S. some other discussion at
>>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 =
and
>>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY =
and
>>> so on.
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_D632EF00-20CE-4937-BED3-AA08405EE7F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
don=E2=80=99t agree with this stance from a security or implementation =
perspective. 

If =
there=E2=80=99s a clear order of precedence for the information, it=E2=80=99=
s not particularly problematic. Everything inside the request object is =
to be taken over things outside the request object. We have the exact =
same semantics and process with dynamic registration, where the software =
statement is carried alongside plain JSON claims, and the two are mixed =
with a very simple algorithm:

 - If a field is inside the signed =
payload, use that value and ignore any copy of it on the =
outside
 - If a field is not inside the signed =
payload and is outside the signed payload, use the outside =
value

Can =
someone please point out a concrete security issue with this algorithm? =
This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics that we need =
here, and it would solve not only the ability to use this for use cases =
that call for a more static request object (perhaps signed by a third =
party and not the client) along side the plain parameters that can vary, =
but also the backwards compatibility issue that=E2=80=99s been =
discussed. With this algorithm in place, you could have OIDC clients =
actually be compliant with the spec, since OIDC requires replication of =
the values inside the request object on the outside with exact matches. =
An OIDC server wouldn=E2=80=99t be fully compliant with the new spec =
since it would reject some compliant JAR requests that are missing the =
external parameters, but that=E2=80=99s fairly easy logic to add on the =
OIDC side. And in that case you get a matrix of compatibility =
like:


              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |     =
 NO      |
OIDC Client |    =
 YES    |     YES      |

Breaking one out of the four =
possible combinations in a very predictable way is, I think, the best =
way to handle backwards compatibility here. 
But between this issue and JAR=E2=80=99s=
 problematic call for the value of a request_uri to always be a JWT and =
be fetchable by the AS (neither of which are true in the case of PAR) =
makes me think we need to pull this back and rework those things, in a =
push back to the IESG=E2=80=99s comments.

 =E2=80=94 Justin


On Jan =
16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com>=
 wrote:

I agree with this, particularly the security concerns of =
merging. If we merge, we can much guarantee there will eventually be a =
security issue where an attacker is able to gain an advantage by adding =
a parameter to the url query (which the server would then happily =
process if that parameter isn=E2=80=99t found inside the request =
object). Ruling out that case makes security analysis (particularly when =
creating new OAuth2 parameters) significantly simpler.

Putting the iss in the JWE header and having the client_id =
duplicated outside the request object seem to address all the concerns =
I=E2=80=99ve seen raised.

(It seems like it =
may be unnecessary to have the client_id duplicated outside if the =
request_uri is a PAR one though.)

Joseph



On 16 Jan 2020, at 22:40, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

I agree with the IESG reasoning that =
merging is problimatic.  Once we
allow that given a =
unknown list of possible paramaters with diffrent
security =
properties it would be quite difficult to specify safely.

Query paramaters can still be sent outside the =
JAR, but if they are in
the OAuth registry the AS MUST =
ignore them.

Puting the iss in the JWE =
headder addresses the encryption issue without
merging.

I understand that some existing servers have =
dependencys on getting the
clientID as a query =
paramater.

Is that the only paramater that =
people have a issue with as oposed to a
nice to have?

Would allowing the AS to not ignore the =
clientID as a query paramater as
long as it matches the =
one inside the JAR, basicly the same as Connect
request =
object but for just the one paramater make life easier for the
servers?

I am not promising a =
change but gathering info before proposing something.

John B.


On =
1/16/2020 1:53 AM, Benjamin Kaduk wrote:
On Wed, Jan 15, 2020 at 11:02:33PM +0200, =
Vladimir Dzhuvinov wrote:
On 14/01/2020 19:20, Takahiko Kawasaki wrote:
Well, embedding a =
client_id claim in the JWE header in order to
achieve =
"request parameters outside the request object should not be
referred to" is like "putting the cart before the horse". Why =
do we
have to avoid using the traditional client_id =
request parameter so
stubbornly?

The last paragraph of Section 3.2.1
<https://tools.ietf.org/html/rfc6749#section-3.2.1> of =
RFC 6749 says
as follows.

 =
  /A client MAY use the "client_id" request parameter to =
identify
   itself when sending requests to the =
token endpoint.  In the
 =
  "authorization_code" "grant_type" request to the token =
endpoint,
   *an unauthenticated client MUST =
send its "client_id" to prevent
   itself from =
inadvertently accepting a code intended for a client
 =
  with a different "client_id".*  This protects the =
client from
   substitution of the =
authentication code.  (It provides no
 =
  additional security for the protected resource.)/


If the same reasoning applies, =
a client_id must always be sent with
request / request_uri =
because client authentication is not performed
at the =
authorization endpoint. In other words, */an unauthenticated
client (every client is unauthenticated at the authorization =
endpoint)
MUST send its "client_id" to prevent itself from =
inadvertently
accepting a request object for a client with =
a different "client_id"./*

Identifying the client in JAR request_uri =
requests can be really useful
so that an AS which requires =
request_uri registration to prevent DDoS
attacks and other =
checks can do those without having to index all
request_uris=
 individually. I mentioned this before.

I =
really wonder what the reasoning of the IESG reviewers was to insist
on no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the =
review process isn't
particularly transparent to WG =
members.
Could you expand on that a bit more? =
 My understanding is that the IESG
ballot mail gets =
copied to the WG precisely so that there is transparency,
e.g., the thread starting at
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdi=
R9R0JwgI
Which admittely is from almost three years =
ago, but that's the earliest
that I found that could be =
seen as the source of this behavior.

-Ben

P.S. some other discussion at
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-=
IGx4xHy8 and
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZg=
pWCz_UwY and
so on.

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

_______________________________________________
OAuth mailing 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=_D632EF00-20CE-4937-BED3-AA08405EE7F5--


From nobody Fri Jan 17 08:24: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 9A6B2120074 for ; Fri, 17 Jan 2020 08:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.497
X-Spam-Level: 
X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUG-N1RnqtxY for ; Fri, 17 Jan 2020 08:24:42 -0800 (PST)
Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C727120018 for ; Fri, 17 Jan 2020 08:24:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579278283; x=1610814283; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jN0XNsK7it2oi/l37eN484+4zA1Vj3yFsMma6reg+Ek=; b=p/rtJtxNmwpeOyZ49W501+ppBex8sKJYqNWDy4PAbm7uwmbWhnXjBkPy x525R0lBnvXzCIraF8nkU2hc+dMNkTK32lArdM0IUEjck9gqWHZ8NzsjR TJMNgksQI9/8aqA/2C3HblDmxdvWUuDHw7PX97h/ZtAdFYb5m+Lt/ZN2+ w=;
IronPort-SDR: PhdZAS1wAYJ2Zw2WXVsN2XNbqA4O7BtN/66XK86qq6BkjFGhtBQWfDJH1iS+QSg4t9pqptcG5Y ivFG5mD9pA4g==
X-IronPort-AV: E=Sophos; i="5.70,330,1574121600"; d="scan'208,217"; a="12853652"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 17 Jan 2020 16:24:39 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id 290C5A299C; Fri, 17 Jan 2020 16:24:38 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:24:37 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:24:37 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 17 Jan 2020 16:24:37 +0000
From: "Richard Backman, Annabelle" 
To: Justin Richer 
CC: Joseph Heenan , oauth 
Thread-Topic: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVyBgJ47SBXlMdXkypCDJuQVGWtKfkpDcAgACLVgCAAK0VgIAC52cAgAGpqICAAdBVgIAAg3MAgACTaoCAALergIAA268AgAAszNc=
Date: Fri, 17 Jan 2020 16:24:37 +0000
Message-ID: 
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_BBBA7134B34D4A0C8DFFAD52E78BDB58amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 16:24:48 -0000

--_000_BBBA7134B34D4A0C8DFFAD52E78BDB58amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzEgdG8gSnVzdGlu4oCZcyBjb21tZW50cy4gRnJvbSBhIHNlY3VyaXR5IHN0YW5kcG9pbnQgcGFy
YW1ldGVycyBpbiB0aGUgcXVlcnkgIHN0cmluZyBhcmUgbm8gZGlmZmVyZW50IGZyb20gdGhvc2Ug
aW4gSldUIHVucHJvdGVjdGVkIGhlYWRlcnMgKG9yIHByb3RlY3RlZCBpZiB0aGV54oCZcmUgYWxz
byBpbiB0aGUgcmVxdWVzdCBvYmplY3QpLiBBbHRob3VnaCBJ4oCYZCBhbWVuZCBKdXN0aW7igJlz
IHN1Z2dlc3Rpb24gdG8gc2F5IHRoYXQgaWYgYSBwYXJhbWV0ZXIgaXMgYm90aCBpbnNpZGUgdGhl
IHJlcXVlc3Qgb2JqZWN0IGFuZCBvdXRzaWRlIGFuZCB0aGV5IGRvIG5vdCBtYXRjaCwgcmVqZWN0
IHRoZSByZXF1ZXN0IGFzIHN1c3BpY2lvdXMuDQoNCk9uIEphbiAxNywgMjAyMCwgYXQgNTo0NSBB
TSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCg0K77u/IEkgZG9u4oCZ
dCBhZ3JlZSB3aXRoIHRoaXMgc3RhbmNlIGZyb20gYSBzZWN1cml0eSBvciBpbXBsZW1lbnRhdGlv
biBwZXJzcGVjdGl2ZS4NCg0KSWYgdGhlcmXigJlzIGEgY2xlYXIgb3JkZXIgb2YgcHJlY2VkZW5j
ZSBmb3IgdGhlIGluZm9ybWF0aW9uLCBpdOKAmXMgbm90IHBhcnRpY3VsYXJseSBwcm9ibGVtYXRp
Yy4gRXZlcnl0aGluZyBpbnNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0IGlzIHRvIGJlIHRha2VuIG92
ZXIgdGhpbmdzIG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0LiBXZSBoYXZlIHRoZSBleGFjdCBz
YW1lIHNlbWFudGljcyBhbmQgcHJvY2VzcyB3aXRoIGR5bmFtaWMgcmVnaXN0cmF0aW9uLCB3aGVy
ZSB0aGUgc29mdHdhcmUgc3RhdGVtZW50IGlzIGNhcnJpZWQgYWxvbmdzaWRlIHBsYWluIEpTT04g
Y2xhaW1zLCBhbmQgdGhlIHR3byBhcmUgbWl4ZWQgd2l0aCBhIHZlcnkgc2ltcGxlIGFsZ29yaXRo
bToNCg0KIC0gSWYgYSBmaWVsZCBpcyBpbnNpZGUgdGhlIHNpZ25lZCBwYXlsb2FkLCB1c2UgdGhh
dCB2YWx1ZSBhbmQgaWdub3JlIGFueSBjb3B5IG9mIGl0IG9uIHRoZSBvdXRzaWRlDQogLSBJZiBh
IGZpZWxkIGlzIG5vdCBpbnNpZGUgdGhlIHNpZ25lZCBwYXlsb2FkIGFuZCBpcyBvdXRzaWRlIHRo
ZSBzaWduZWQgcGF5bG9hZCwgdXNlIHRoZSBvdXRzaWRlIHZhbHVlDQoNCkNhbiBzb21lb25lIHBs
ZWFzZSBwb2ludCBvdXQgYSBjb25jcmV0ZSBzZWN1cml0eSBpc3N1ZSB3aXRoIHRoaXMgYWxnb3Jp
dGhtPyBUaGlzIGlzIHRoZSBleHRlbnQgb2YgdGhlIOKAnG1lcmdl4oCdIHNlbWFudGljcyB0aGF0
IHdlIG5lZWQgaGVyZSwgYW5kIGl0IHdvdWxkIHNvbHZlIG5vdCBvbmx5IHRoZSBhYmlsaXR5IHRv
IHVzZSB0aGlzIGZvciB1c2UgY2FzZXMgdGhhdCBjYWxsIGZvciBhIG1vcmUgc3RhdGljIHJlcXVl
c3Qgb2JqZWN0IChwZXJoYXBzIHNpZ25lZCBieSBhIHRoaXJkIHBhcnR5IGFuZCBub3QgdGhlIGNs
aWVudCkgYWxvbmcgc2lkZSB0aGUgcGxhaW4gcGFyYW1ldGVycyB0aGF0IGNhbiB2YXJ5LCBidXQg
YWxzbyB0aGUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaXNzdWUgdGhhdOKAmXMgYmVlbiBkaXNj
dXNzZWQuIFdpdGggdGhpcyBhbGdvcml0aG0gaW4gcGxhY2UsIHlvdSBjb3VsZCBoYXZlIE9JREMg
Y2xpZW50cyBhY3R1YWxseSBiZSBjb21wbGlhbnQgd2l0aCB0aGUgc3BlYywgc2luY2UgT0lEQyBy
ZXF1aXJlcyByZXBsaWNhdGlvbiBvZiB0aGUgdmFsdWVzIGluc2lkZSB0aGUgcmVxdWVzdCBvYmpl
Y3Qgb24gdGhlIG91dHNpZGUgd2l0aCBleGFjdCBtYXRjaGVzLiBBbiBPSURDIHNlcnZlciB3b3Vs
ZG7igJl0IGJlIGZ1bGx5IGNvbXBsaWFudCB3aXRoIHRoZSBuZXcgc3BlYyBzaW5jZSBpdCB3b3Vs
ZCByZWplY3Qgc29tZSBjb21wbGlhbnQgSkFSIHJlcXVlc3RzIHRoYXQgYXJlIG1pc3NpbmcgdGhl
IGV4dGVybmFsIHBhcmFtZXRlcnMsIGJ1dCB0aGF04oCZcyBmYWlybHkgZWFzeSBsb2dpYyB0byBh
ZGQgb24gdGhlIE9JREMgc2lkZS4gQW5kIGluIHRoYXQgY2FzZSB5b3UgZ2V0IGEgbWF0cml4IG9m
IGNvbXBhdGliaWxpdHkgbGlrZToNCg0KDQoNCiAgICAgICAgICAgICAgSkFSIFNlcnZlciB8IE9J
REMgU2VydmVyICB8DQotLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKw0K
SkFSIENsaWVudCAgfCAgICAgWUVTICAgIHwgICAgICBOTyAgICAgIHwNCk9JREMgQ2xpZW50IHwg
ICAgIFlFUyAgICB8ICAgICBZRVMgICAgICB8DQoNCkJyZWFraW5nIG9uZSBvdXQgb2YgdGhlIGZv
dXIgcG9zc2libGUgY29tYmluYXRpb25zIGluIGEgdmVyeSBwcmVkaWN0YWJsZSB3YXkgaXMsIEkg
dGhpbmssIHRoZSBiZXN0IHdheSB0byBoYW5kbGUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgaGVy
ZS4NCg0KQnV0IGJldHdlZW4gdGhpcyBpc3N1ZSBhbmQgSkFS4oCZcyBwcm9ibGVtYXRpYyBjYWxs
IGZvciB0aGUgdmFsdWUgb2YgYSByZXF1ZXN0X3VyaSB0byBhbHdheXMgYmUgYSBKV1QgYW5kIGJl
IGZldGNoYWJsZSBieSB0aGUgQVMgKG5laXRoZXIgb2Ygd2hpY2ggYXJlIHRydWUgaW4gdGhlIGNh
c2Ugb2YgUEFSKSBtYWtlcyBtZSB0aGluayB3ZSBuZWVkIHRvIHB1bGwgdGhpcyBiYWNrIGFuZCBy
ZXdvcmsgdGhvc2UgdGhpbmdzLCBpbiBhIHB1c2ggYmFjayB0byB0aGUgSUVTR+KAmXMgY29tbWVu
dHMuDQoNCiDigJQgSnVzdGluDQoNCg0KT24gSmFuIDE2LCAyMDIwLCBhdCA3OjM4IFBNLCBKb3Nl
cGggSGVlbmFuIDxqb3NlcGhAYXV0aGxldGUuY29tPG1haWx0bzpqb3NlcGhAYXV0aGxldGUuY29t
Pj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCB0aGlzLCBwYXJ0aWN1bGFybHkgdGhlIHNlY3VyaXR5
IGNvbmNlcm5zIG9mIG1lcmdpbmcuIElmIHdlIG1lcmdlLCB3ZSBjYW4gbXVjaCBndWFyYW50ZWUg
dGhlcmUgd2lsbCBldmVudHVhbGx5IGJlIGEgc2VjdXJpdHkgaXNzdWUgd2hlcmUgYW4gYXR0YWNr
ZXIgaXMgYWJsZSB0byBnYWluIGFuIGFkdmFudGFnZSBieSBhZGRpbmcgYSBwYXJhbWV0ZXIgdG8g
dGhlIHVybCBxdWVyeSAod2hpY2ggdGhlIHNlcnZlciB3b3VsZCB0aGVuIGhhcHBpbHkgcHJvY2Vz
cyBpZiB0aGF0IHBhcmFtZXRlciBpc27igJl0IGZvdW5kIGluc2lkZSB0aGUgcmVxdWVzdCBvYmpl
Y3QpLiBSdWxpbmcgb3V0IHRoYXQgY2FzZSBtYWtlcyBzZWN1cml0eSBhbmFseXNpcyAocGFydGlj
dWxhcmx5IHdoZW4gY3JlYXRpbmcgbmV3IE9BdXRoMiBwYXJhbWV0ZXJzKSBzaWduaWZpY2FudGx5
IHNpbXBsZXIuDQoNClB1dHRpbmcgdGhlIGlzcyBpbiB0aGUgSldFIGhlYWRlciBhbmQgaGF2aW5n
IHRoZSBjbGllbnRfaWQgZHVwbGljYXRlZCBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBzZWVt
IHRvIGFkZHJlc3MgYWxsIHRoZSBjb25jZXJucyBJ4oCZdmUgc2VlbiByYWlzZWQuDQoNCihJdCBz
ZWVtcyBsaWtlIGl0IG1heSBiZSB1bm5lY2Vzc2FyeSB0byBoYXZlIHRoZSBjbGllbnRfaWQgZHVw
bGljYXRlZCBvdXRzaWRlIGlmIHRoZSByZXF1ZXN0X3VyaSBpcyBhIFBBUiBvbmUgdGhvdWdoLikN
Cg0KSm9zZXBoDQoNCg0KDQpPbiAxNiBKYW4gMjAyMCwgYXQgMjI6NDAsIEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCkkg
YWdyZWUgd2l0aCB0aGUgSUVTRyByZWFzb25pbmcgdGhhdCBtZXJnaW5nIGlzIHByb2JsaW1hdGlj
LiAgT25jZSB3ZQ0KYWxsb3cgdGhhdCBnaXZlbiBhIHVua25vd24gbGlzdCBvZiBwb3NzaWJsZSBw
YXJhbWF0ZXJzIHdpdGggZGlmZnJlbnQNCnNlY3VyaXR5IHByb3BlcnRpZXMgaXQgd291bGQgYmUg
cXVpdGUgZGlmZmljdWx0IHRvIHNwZWNpZnkgc2FmZWx5Lg0KDQpRdWVyeSBwYXJhbWF0ZXJzIGNh
biBzdGlsbCBiZSBzZW50IG91dHNpZGUgdGhlIEpBUiwgYnV0IGlmIHRoZXkgYXJlIGluDQp0aGUg
T0F1dGggcmVnaXN0cnkgdGhlIEFTIE1VU1QgaWdub3JlIHRoZW0uDQoNClB1dGluZyB0aGUgaXNz
IGluIHRoZSBKV0UgaGVhZGRlciBhZGRyZXNzZXMgdGhlIGVuY3J5cHRpb24gaXNzdWUgd2l0aG91
dA0KbWVyZ2luZy4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgc29tZSBleGlzdGluZyBzZXJ2ZXJzIGhh
dmUgZGVwZW5kZW5jeXMgb24gZ2V0dGluZyB0aGUNCmNsaWVudElEIGFzIGEgcXVlcnkgcGFyYW1h
dGVyLg0KDQpJcyB0aGF0IHRoZSBvbmx5IHBhcmFtYXRlciB0aGF0IHBlb3BsZSBoYXZlIGEgaXNz
dWUgd2l0aCBhcyBvcG9zZWQgdG8gYQ0KbmljZSB0byBoYXZlPw0KDQpXb3VsZCBhbGxvd2luZyB0
aGUgQVMgdG8gbm90IGlnbm9yZSB0aGUgY2xpZW50SUQgYXMgYSBxdWVyeSBwYXJhbWF0ZXIgYXMN
CmxvbmcgYXMgaXQgbWF0Y2hlcyB0aGUgb25lIGluc2lkZSB0aGUgSkFSLCBiYXNpY2x5IHRoZSBz
YW1lIGFzIENvbm5lY3QNCnJlcXVlc3Qgb2JqZWN0IGJ1dCBmb3IganVzdCB0aGUgb25lIHBhcmFt
YXRlciBtYWtlIGxpZmUgZWFzaWVyIGZvciB0aGUNCnNlcnZlcnM/DQoNCkkgYW0gbm90IHByb21p
c2luZyBhIGNoYW5nZSBidXQgZ2F0aGVyaW5nIGluZm8gYmVmb3JlIHByb3Bvc2luZyBzb21ldGhp
bmcuDQoNCkpvaG4gQi4NCg0KDQpPbiAxLzE2LzIwMjAgMTo1MyBBTSwgQmVuamFtaW4gS2FkdWsg
d3JvdGU6DQpPbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAxMTowMjozM1BNICswMjAwLCBWbGFkaW1p
ciBEemh1dmlub3Ygd3JvdGU6DQpPbiAxNC8wMS8yMDIwIDE5OjIwLCBUYWthaGlrbyBLYXdhc2Fr
aSB3cm90ZToNCldlbGwsIGVtYmVkZGluZyBhIGNsaWVudF9pZCBjbGFpbSBpbiB0aGUgSldFIGhl
YWRlciBpbiBvcmRlciB0bw0KYWNoaWV2ZSAicmVxdWVzdCBwYXJhbWV0ZXJzIG91dHNpZGUgdGhl
IHJlcXVlc3Qgb2JqZWN0IHNob3VsZCBub3QgYmUNCnJlZmVycmVkIHRvIiBpcyBsaWtlICJwdXR0
aW5nIHRoZSBjYXJ0IGJlZm9yZSB0aGUgaG9yc2UiLiBXaHkgZG8gd2UNCmhhdmUgdG8gYXZvaWQg
dXNpbmcgdGhlIHRyYWRpdGlvbmFsIGNsaWVudF9pZCByZXF1ZXN0IHBhcmFtZXRlciBzbw0Kc3R1
YmJvcm5seT8NCg0KVGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMy4yLjENCjxodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMi4xPiBvZiBSRkMgNjc0OSBz
YXlzDQphcyBmb2xsb3dzLg0KDQogIC9BIGNsaWVudCBNQVkgdXNlIHRoZSAiY2xpZW50X2lkIiBy
ZXF1ZXN0IHBhcmFtZXRlciB0byBpZGVudGlmeQ0KICBpdHNlbGYgd2hlbiBzZW5kaW5nIHJlcXVl
c3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4gIEluIHRoZQ0KICAiYXV0aG9yaXphdGlvbl9jb2Rl
IiAiZ3JhbnRfdHlwZSIgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQsDQogICphbiB1bmF1
dGhlbnRpY2F0ZWQgY2xpZW50IE1VU1Qgc2VuZCBpdHMgImNsaWVudF9pZCIgdG8gcHJldmVudA0K
ICBpdHNlbGYgZnJvbSBpbmFkdmVydGVudGx5IGFjY2VwdGluZyBhIGNvZGUgaW50ZW5kZWQgZm9y
IGEgY2xpZW50DQogIHdpdGggYSBkaWZmZXJlbnQgImNsaWVudF9pZCIuKiAgVGhpcyBwcm90ZWN0
cyB0aGUgY2xpZW50IGZyb20NCiAgc3Vic3RpdHV0aW9uIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBj
b2RlLiAgKEl0IHByb3ZpZGVzIG5vDQogIGFkZGl0aW9uYWwgc2VjdXJpdHkgZm9yIHRoZSBwcm90
ZWN0ZWQgcmVzb3VyY2UuKS8NCg0KDQpJZiB0aGUgc2FtZSByZWFzb25pbmcgYXBwbGllcywgYSBj
bGllbnRfaWQgbXVzdCBhbHdheXMgYmUgc2VudCB3aXRoDQpyZXF1ZXN0IC8gcmVxdWVzdF91cmkg
YmVjYXVzZSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbm90IHBlcmZvcm1lZA0KYXQgdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQuIEluIG90aGVyIHdvcmRzLCAqL2FuIHVuYXV0aGVudGljYXRl
ZA0KY2xpZW50IChldmVyeSBjbGllbnQgaXMgdW5hdXRoZW50aWNhdGVkIGF0IHRoZSBhdXRob3Jp
emF0aW9uIGVuZHBvaW50KQ0KTVVTVCBzZW5kIGl0cyAiY2xpZW50X2lkIiB0byBwcmV2ZW50IGl0
c2VsZiBmcm9tIGluYWR2ZXJ0ZW50bHkNCmFjY2VwdGluZyBhIHJlcXVlc3Qgb2JqZWN0IGZvciBh
IGNsaWVudCB3aXRoIGEgZGlmZmVyZW50ICJjbGllbnRfaWQiLi8qDQoNCklkZW50aWZ5aW5nIHRo
ZSBjbGllbnQgaW4gSkFSIHJlcXVlc3RfdXJpIHJlcXVlc3RzIGNhbiBiZSByZWFsbHkgdXNlZnVs
DQpzbyB0aGF0IGFuIEFTIHdoaWNoIHJlcXVpcmVzIHJlcXVlc3RfdXJpIHJlZ2lzdHJhdGlvbiB0
byBwcmV2ZW50IEREb1MNCmF0dGFja3MgYW5kIG90aGVyIGNoZWNrcyBjYW4gZG8gdGhvc2Ugd2l0
aG91dCBoYXZpbmcgdG8gaW5kZXggYWxsDQpyZXF1ZXN0X3VyaXMgaW5kaXZpZHVhbGx5LiBJIG1l
bnRpb25lZCB0aGlzIGJlZm9yZS4NCg0KSSByZWFsbHkgd29uZGVyIHdoYXQgdGhlIHJlYXNvbmlu
ZyBvZiB0aGUgSUVTRyByZXZpZXdlcnMgd2FzIHRvIGluc2lzdA0Kb24gbm8gcGFyYW1zIG91dHNp
ZGUgdGhlIEpBUiBKV1QgLyByZXF1ZXN0X3VyaS4NCg0KSSdtIGJlZ2lubmluZyB0byByZWFsaXNl
IHRoaXMgc3RlcCBvZiB0aGUgcmV2aWV3IHByb2Nlc3MgaXNuJ3QNCnBhcnRpY3VsYXJseSB0cmFu
c3BhcmVudCB0byBXRyBtZW1iZXJzLg0KQ291bGQgeW91IGV4cGFuZCBvbiB0aGF0IGEgYml0IG1v
cmU/ICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIElFU0cNCmJhbGxvdCBtYWlsIGdldHMg
Y29waWVkIHRvIHRoZSBXRyBwcmVjaXNlbHkgc28gdGhhdCB0aGVyZSBpcyB0cmFuc3BhcmVuY3ks
DQplLmcuLCB0aGUgdGhyZWFkIHN0YXJ0aW5nIGF0DQpodHRwczovL21haWxhcmNoaXZlLmlldGYu
b3JnL2FyY2gvbXNnL29hdXRoL2xrT2h3aURqX2hDSTU1QlFSZGlSOVIwSndnSQ0KV2hpY2ggYWRt
aXR0ZWx5IGlzIGZyb20gYWxtb3N0IHRocmVlIHllYXJzIGFnbywgYnV0IHRoYXQncyB0aGUgZWFy
bGllc3QNCnRoYXQgSSBmb3VuZCB0aGF0IGNvdWxkIGJlIHNlZW4gYXMgdGhlIHNvdXJjZSBvZiB0
aGlzIGJlaGF2aW9yLg0KDQotQmVuDQoNClAuUy4gc29tZSBvdGhlciBkaXNjdXNzaW9uIGF0DQpo
dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoLy10VXJOWTFYOWVJX3RR
R0k4VC1JR3g0eEh5OCBhbmQNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv
b2F1dGgvVWtlMW54UmxneDYyRUpMZXZaZ3BXQ3pfVXdZIGFuZA0Kc28gb24uDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_BBBA7134B34D4A0C8DFFAD52E78BDB58amazoncom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2IGRpcj0ibHRyIj4mIzQzOzEgdG8gSnVzdGlu4oCZcyBjb21tZW50cy4gRnJvbSBhIHNlY3Vy
aXR5IHN0YW5kcG9pbnQgcGFyYW1ldGVycyBpbiB0aGUgcXVlcnkgJm5ic3A7c3RyaW5nIGFyZSBu
byBkaWZmZXJlbnQgZnJvbSB0aG9zZSBpbiBKV1QgdW5wcm90ZWN0ZWQgaGVhZGVycyAob3IgcHJv
dGVjdGVkIGlmIHRoZXnigJlyZSBhbHNvIGluIHRoZSByZXF1ZXN0IG9iamVjdCkuIEFsdGhvdWdo
IEnigJhkIGFtZW5kIEp1c3RpbuKAmXMgc3VnZ2VzdGlvbiB0byBzYXkgdGhhdA0KIGlmIGEgcGFy
YW1ldGVyIGlzIGJvdGggaW5zaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBhbmQgb3V0c2lkZSBhbmQg
dGhleSBkbyBub3QgbWF0Y2gsIHJlamVjdCB0aGUgcmVxdWVzdCBhcyBzdXNwaWNpb3VzLg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPk9uIEphbiAxNywgMjAyMCwgYXQgNTo0NSBBTSwgSnVzdGluIFJpY2hlciAmbHQ7anJp
Y2hlckBtaXQuZWR1Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/IEkgZG9u4oCZdCBh
Z3JlZSB3aXRoIHRoaXMgc3RhbmNlIGZyb20gYSBzZWN1cml0eSBvciBpbXBsZW1lbnRhdGlvbiBw
ZXJzcGVjdGl2ZS4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPklmIHRoZXJl4oCZcyBhIGNsZWFyIG9yZGVyIG9mIHByZWNlZGVuY2UgZm9y
IHRoZSBpbmZvcm1hdGlvbiwgaXTigJlzIG5vdCBwYXJ0aWN1bGFybHkgcHJvYmxlbWF0aWMuIEV2
ZXJ5dGhpbmcgaW5zaWRlIHRoZSByZXF1ZXN0IG9iamVjdCBpcyB0byBiZSB0YWtlbiBvdmVyIHRo
aW5ncyBvdXRzaWRlIHRoZSByZXF1ZXN0IG9iamVjdC4gV2UgaGF2ZSB0aGUgZXhhY3Qgc2FtZSBz
ZW1hbnRpY3MgYW5kIHByb2Nlc3Mgd2l0aCBkeW5hbWljDQogcmVnaXN0cmF0aW9uLCB3aGVyZSB0
aGUgc29mdHdhcmUgc3RhdGVtZW50IGlzIGNhcnJpZWQgYWxvbmdzaWRlIHBsYWluIEpTT04gY2xh
aW1zLCBhbmQgdGhlIHR3byBhcmUgbWl4ZWQgd2l0aCBhIHZlcnkgc2ltcGxlIGFsZ29yaXRobTo8
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PiZuYnNwOy0gSWYgYSBmaWVsZCBpcyBpbnNpZGUgdGhlIHNpZ25lZCBwYXlsb2FkLCB1c2UgdGhh
dCB2YWx1ZSBhbmQgaWdub3JlIGFueSBjb3B5IG9mIGl0IG9uIHRoZSBvdXRzaWRlPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPiZuYnNwOy0gSWYgYSBmaWVsZCBpcyBub3QgaW5zaWRlIHRoZSBzaWduZWQg
cGF5bG9hZCBhbmQgaXMgb3V0c2lkZSB0aGUgc2lnbmVkIHBheWxvYWQsIHVzZSB0aGUgb3V0c2lk
ZSB2YWx1ZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+Q2FuIHNvbWVvbmUgcGxlYXNlIHBvaW50IG91dCBhIGNvbmNyZXRlIHNlY3VyaXR5
IGlzc3VlIHdpdGggdGhpcyBhbGdvcml0aG0/IFRoaXMgaXMgdGhlIGV4dGVudCBvZiB0aGUg4oCc
bWVyZ2XigJ0gc2VtYW50aWNzIHRoYXQgd2UgbmVlZCBoZXJlLCBhbmQgaXQgd291bGQgc29sdmUg
bm90IG9ubHkgdGhlIGFiaWxpdHkgdG8gdXNlIHRoaXMgZm9yIHVzZSBjYXNlcyB0aGF0IGNhbGwg
Zm9yIGEgbW9yZSBzdGF0aWMgcmVxdWVzdCBvYmplY3QNCiAocGVyaGFwcyBzaWduZWQgYnkgYSB0
aGlyZCBwYXJ0eSBhbmQgbm90IHRoZSBjbGllbnQpIGFsb25nIHNpZGUgdGhlIHBsYWluIHBhcmFt
ZXRlcnMgdGhhdCBjYW4gdmFyeSwgYnV0IGFsc28gdGhlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5
IGlzc3VlIHRoYXTigJlzIGJlZW4gZGlzY3Vzc2VkLiBXaXRoIHRoaXMgYWxnb3JpdGhtIGluIHBs
YWNlLCB5b3UgY291bGQgaGF2ZSBPSURDIGNsaWVudHMgYWN0dWFsbHkgYmUgY29tcGxpYW50IHdp
dGggdGhlIHNwZWMsDQogc2luY2UgT0lEQyByZXF1aXJlcyByZXBsaWNhdGlvbiBvZiB0aGUgdmFs
dWVzIGluc2lkZSB0aGUgcmVxdWVzdCBvYmplY3Qgb24gdGhlIG91dHNpZGUgd2l0aCBleGFjdCBt
YXRjaGVzLiBBbiBPSURDIHNlcnZlciB3b3VsZG7igJl0IGJlIGZ1bGx5IGNvbXBsaWFudCB3aXRo
IHRoZSBuZXcgc3BlYyBzaW5jZSBpdCB3b3VsZCByZWplY3Qgc29tZSBjb21wbGlhbnQgSkFSIHJl
cXVlc3RzIHRoYXQgYXJlIG1pc3NpbmcgdGhlIGV4dGVybmFsIHBhcmFtZXRlcnMsDQogYnV0IHRo
YXTigJlzIGZhaXJseSBlYXN5IGxvZ2ljIHRvIGFkZCBvbiB0aGUgT0lEQyBzaWRlLiBBbmQgaW4g
dGhhdCBjYXNlIHlvdSBnZXQgYSBtYXRyaXggb2YgY29tcGF0aWJpbGl0eSBsaWtlOjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iYy1tcmtkd25fX3By
ZSIgZGF0YS1zdHJpbmdpZnktdHlwZT0icHJlIiBzdHlsZT0iYm94LXNpemluZzogaW5oZXJpdDsg
bWFyZ2luLXRvcDogNHB4OyBtYXJnaW4tYm90dG9tOiA0cHg7IHBhZGRpbmc6IDhweDsgLS1zYWYt
MDogcmdiYSh2YXIoLS1za19mb3JlZ3JvdW5kX2xvdywyOSwyOCwyOSksMC4xMyk7IGxpbmUtaGVp
Z2h0OiAxLjUwMDAxOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub25lOyB3aGl0ZS1zcGFjZTog
cHJlLXdyYXA7IG92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IHdvcmQtYnJlYWs6IG5vcm1hbDsg
dGFiLXNpemU6IDQ7IGJvcmRlcjogMXB4IHNvbGlkIHZhcigtLXNhZi0wKTsgYm9yZGVyLXRvcC1s
ZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90
dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7IGJh
Y2tncm91bmQ6IHJnYmEodmFyKC0tc2tfZm9yZWdyb3VuZF9taW4sMjksMjgsMjkpLDAuMDQpOyBj
b3VudGVyLXJlc2V0OiBsaXN0LTAgMCBsaXN0LTEgMCBsaXN0LTIgMCBsaXN0LTMgMCBsaXN0LTQg
MCBsaXN0LTUgMCBsaXN0LTYgMCBsaXN0LTcgMCBsaXN0LTggMCBsaXN0LTkgMDsgY29sb3I6IHJn
YigyOSwgMjgsIDI5KTsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyBmb250LWZhbWlseTogTW9uYWNv
LCBNZW5sbywgQ29uc29sYXMsICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCBtb25vc3BhY2UgIWlt
cG9ydGFudDsiPiAgICAgICAgICAgICAgSkFSIFNlcnZlciB8IE9JREMgU2VydmVyICB8PGJyIHN0
eWxlPSJib3gtc2l6aW5nOiBpbmhlcml0OyIgY2xhc3M9IiI+LS0tLS0tLS0tLS0tJiM0MzstLS0t
LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tJiM0Mzs8YnIgc3R5bGU9ImJveC1zaXppbmc6IGlu
aGVyaXQ7IiBjbGFzcz0iIj5KQVIgQ2xpZW50ICB8ICAgICBZRVMgICAgfCAgICAgIE5PICAgICAg
fDxiciBzdHlsZT0iYm94LXNpemluZzogaW5oZXJpdDsiIGNsYXNzPSIiPk9JREMgQ2xpZW50IHwg
ICAgIFlFUyAgICB8ICAgICBZRVMgICAgICB8PC9wcmU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJyZWFraW5nIG9uZSBvdXQgb2Yg
dGhlIGZvdXIgcG9zc2libGUgY29tYmluYXRpb25zIGluIGEgdmVyeSBwcmVkaWN0YWJsZSB3YXkg
aXMsIEkgdGhpbmssIHRoZSBiZXN0IHdheSB0byBoYW5kbGUgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkgaGVyZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPkJ1dCBiZXR3ZWVuIHRoaXMgaXNzdWUgYW5kIEpBUuKAmXMgcHJvYmxl
bWF0aWMgY2FsbCBmb3IgdGhlIHZhbHVlIG9mIGEgcmVxdWVzdF91cmkgdG8gYWx3YXlzIGJlIGEg
SldUIGFuZCBiZSBmZXRjaGFibGUgYnkgdGhlIEFTIChuZWl0aGVyIG9mIHdoaWNoIGFyZSB0cnVl
IGluIHRoZSBjYXNlIG9mIFBBUikgbWFrZXMgbWUgdGhpbmsgd2UgbmVlZCB0byBwdWxsIHRoaXMg
YmFjayBhbmQgcmV3b3JrIHRob3NlIHRoaW5ncywgaW4NCiBhIHB1c2ggYmFjayB0byB0aGUgSUVT
R+KAmXMgY29tbWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDvigJQgSnVzdGluPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEphbiAx
NiwgMjAyMCwgYXQgNzozOCBQTSwgSm9zZXBoIEhlZW5hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpv
c2VwaEBhdXRobGV0ZS5jb20iIGNsYXNzPSIiPmpvc2VwaEBhdXRobGV0ZS5jb208L2E+Jmd0OyB3
cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2
IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIGFncmVlIHdpdGggdGhpcywgcGFydGljdWxhcmx5
IHRoZSBzZWN1cml0eSBjb25jZXJucyBvZiBtZXJnaW5nLiBJZiB3ZSBtZXJnZSwgd2UgY2FuIG11
Y2ggZ3VhcmFudGVlIHRoZXJlIHdpbGwgZXZlbnR1YWxseSBiZSBhIHNlY3VyaXR5IGlzc3VlIHdo
ZXJlIGFuIGF0dGFja2VyIGlzIGFibGUgdG8gZ2FpbiBhbiBhZHZhbnRhZ2UgYnkgYWRkaW5nIGEg
cGFyYW1ldGVyIHRvIHRoZSB1cmwgcXVlcnkgKHdoaWNoIHRoZSBzZXJ2ZXINCiB3b3VsZCB0aGVu
IGhhcHBpbHkgcHJvY2VzcyBpZiB0aGF0IHBhcmFtZXRlciBpc27igJl0IGZvdW5kIGluc2lkZSB0
aGUgcmVxdWVzdCBvYmplY3QpLiBSdWxpbmcgb3V0IHRoYXQgY2FzZSBtYWtlcyBzZWN1cml0eSBh
bmFseXNpcyAocGFydGljdWxhcmx5IHdoZW4gY3JlYXRpbmcgbmV3IE9BdXRoMiBwYXJhbWV0ZXJz
KSBzaWduaWZpY2FudGx5IHNpbXBsZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUHV0
dGluZyB0aGUgaXNzIGluIHRoZSBKV0UgaGVhZGVyIGFuZCBoYXZpbmcgdGhlIGNsaWVudF9pZCBk
dXBsaWNhdGVkIG91dHNpZGUgdGhlIHJlcXVlc3Qgb2JqZWN0IHNlZW0gdG8gYWRkcmVzcyBhbGwg
dGhlIGNvbmNlcm5zIEnigJl2ZSBzZWVuIHJhaXNlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQooSXQgc2VlbXMgbGlrZSBpdCBtYXkgYmUgdW5uZWNlc3NhcnkgdG8gaGF2ZSB0aGUgY2xp
ZW50X2lkIGR1cGxpY2F0ZWQgb3V0c2lkZSBpZiB0aGUgcmVxdWVzdF91cmkgaXMgYSBQQVIgb25l
IHRob3VnaC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSm9zZXBoPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gMTYgSmFuIDIwMjAsIGF0IDIyOjQwLCBKb2huIEJy
YWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgY2xhc3M9IiI+dmU3
anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQpJIGFncmVlIHdpdGggdGhlIElFU0cgcmVhc29uaW5nIHRoYXQgbWVyZ2luZyBpcyBwcm9ibGlt
YXRpYy4gJm5ic3A7T25jZSB3ZTxiciBjbGFzcz0iIj4NCmFsbG93IHRoYXQgZ2l2ZW4gYSB1bmtu
b3duIGxpc3Qgb2YgcG9zc2libGUgcGFyYW1hdGVycyB3aXRoIGRpZmZyZW50PGJyIGNsYXNzPSIi
Pg0Kc2VjdXJpdHkgcHJvcGVydGllcyBpdCB3b3VsZCBiZSBxdWl0ZSBkaWZmaWN1bHQgdG8gc3Bl
Y2lmeSBzYWZlbHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUXVlcnkgcGFyYW1hdGVy
cyBjYW4gc3RpbGwgYmUgc2VudCBvdXRzaWRlIHRoZSBKQVIsIGJ1dCBpZiB0aGV5IGFyZSBpbjxi
ciBjbGFzcz0iIj4NCnRoZSBPQXV0aCByZWdpc3RyeSB0aGUgQVMgTVVTVCBpZ25vcmUgdGhlbS48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQdXRpbmcgdGhlIGlzcyBpbiB0aGUgSldFIGhl
YWRkZXIgYWRkcmVzc2VzIHRoZSBlbmNyeXB0aW9uIGlzc3VlIHdpdGhvdXQ8YnIgY2xhc3M9IiI+
DQptZXJnaW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdW5kZXJzdGFuZCB0aGF0
IHNvbWUgZXhpc3Rpbmcgc2VydmVycyBoYXZlIGRlcGVuZGVuY3lzIG9uIGdldHRpbmcgdGhlPGJy
IGNsYXNzPSIiPg0KY2xpZW50SUQgYXMgYSBxdWVyeSBwYXJhbWF0ZXIuPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KSXMgdGhhdCB0aGUgb25seSBwYXJhbWF0ZXIgdGhhdCBwZW9wbGUgaGF2
ZSBhIGlzc3VlIHdpdGggYXMgb3Bvc2VkIHRvIGE8YnIgY2xhc3M9IiI+DQpuaWNlIHRvIGhhdmU/
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV291bGQgYWxsb3dpbmcgdGhlIEFTIHRvIG5v
dCBpZ25vcmUgdGhlIGNsaWVudElEIGFzIGEgcXVlcnkgcGFyYW1hdGVyIGFzPGJyIGNsYXNzPSIi
Pg0KbG9uZyBhcyBpdCBtYXRjaGVzIHRoZSBvbmUgaW5zaWRlIHRoZSBKQVIsIGJhc2ljbHkgdGhl
IHNhbWUgYXMgQ29ubmVjdDxiciBjbGFzcz0iIj4NCnJlcXVlc3Qgb2JqZWN0IGJ1dCBmb3IganVz
dCB0aGUgb25lIHBhcmFtYXRlciBtYWtlIGxpZmUgZWFzaWVyIGZvciB0aGU8YnIgY2xhc3M9IiI+
DQpzZXJ2ZXJzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgYW0gbm90IHByb21pc2lu
ZyBhIGNoYW5nZSBidXQgZ2F0aGVyaW5nIGluZm8gYmVmb3JlIHByb3Bvc2luZyBzb21ldGhpbmcu
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSm9obiBCLjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDEvMTYvMjAyMCAxOjUzIEFNLCBCZW5qYW1pbiBL
YWR1ayB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i
Ij5PbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAxMTowMjozM1BNICYjNDM7MDIwMCwgVmxhZGltaXIg
RHpodXZpbm92IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs
YXNzPSIiPk9uIDE0LzAxLzIwMjAgMTk6MjAsIFRha2FoaWtvIEthd2FzYWtpIHdyb3RlOjxiciBj
bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPldlbGwsIGVtYmVkZGlu
ZyBhIGNsaWVudF9pZCBjbGFpbSBpbiB0aGUgSldFIGhlYWRlciBpbiBvcmRlciB0bzxiciBjbGFz
cz0iIj4NCmFjaGlldmUgJnF1b3Q7cmVxdWVzdCBwYXJhbWV0ZXJzIG91dHNpZGUgdGhlIHJlcXVl
c3Qgb2JqZWN0IHNob3VsZCBub3QgYmU8YnIgY2xhc3M9IiI+DQpyZWZlcnJlZCB0byZxdW90OyBp
cyBsaWtlICZxdW90O3B1dHRpbmcgdGhlIGNhcnQgYmVmb3JlIHRoZSBob3JzZSZxdW90Oy4gV2h5
IGRvIHdlPGJyIGNsYXNzPSIiPg0KaGF2ZSB0byBhdm9pZCB1c2luZyB0aGUgdHJhZGl0aW9uYWwg
Y2xpZW50X2lkIHJlcXVlc3QgcGFyYW1ldGVyIHNvPGJyIGNsYXNzPSIiPg0Kc3R1YmJvcm5seT88
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlv
biAzLjIuMTxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMi4xIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMuMi4xPC9hPiZndDsgb2YgUkZDIDY3NDkgc2F5czxi
ciBjbGFzcz0iIj4NCmFzIGZvbGxvd3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i
c3A7Jm5ic3A7L0EgY2xpZW50IE1BWSB1c2UgdGhlICZxdW90O2NsaWVudF9pZCZxdW90OyByZXF1
ZXN0IHBhcmFtZXRlciB0byBpZGVudGlmeTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2l0c2Vs
ZiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LiAmbmJzcDtJbiB0
aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmcXVvdDthdXRob3JpemF0aW9uX2NvZGUmcXVv
dDsgJnF1b3Q7Z3JhbnRfdHlwZSZxdW90OyByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCw8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsqYW4gdW5hdXRoZW50aWNhdGVkIGNsaWVudCBNVVNU
IHNlbmQgaXRzICZxdW90O2NsaWVudF9pZCZxdW90OyB0byBwcmV2ZW50PGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7aXRzZWxmIGZyb20gaW5hZHZlcnRlbnRseSBhY2NlcHRpbmcgYSBjb2RlIGlu
dGVuZGVkIGZvciBhIGNsaWVudDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3dpdGggYSBkaWZm
ZXJlbnQgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7LiogJm5ic3A7VGhpcyBwcm90ZWN0cyB0aGUgY2xp
ZW50IGZyb208YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzdWJzdGl0dXRpb24gb2YgdGhlIGF1
dGhlbnRpY2F0aW9uIGNvZGUuICZuYnNwOyhJdCBwcm92aWRlcyBubzxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwO2FkZGl0aW9uYWwgc2VjdXJpdHkgZm9yIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Uu
KS88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiB0aGUgc2Ft
ZSByZWFzb25pbmcgYXBwbGllcywgYSBjbGllbnRfaWQgbXVzdCBhbHdheXMgYmUgc2VudCB3aXRo
PGJyIGNsYXNzPSIiPg0KcmVxdWVzdCAvIHJlcXVlc3RfdXJpIGJlY2F1c2UgY2xpZW50IGF1dGhl
bnRpY2F0aW9uIGlzIG5vdCBwZXJmb3JtZWQ8YnIgY2xhc3M9IiI+DQphdCB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludC4gSW4gb3RoZXIgd29yZHMsICovYW4gdW5hdXRoZW50aWNhdGVkPGJyIGNs
YXNzPSIiPg0KY2xpZW50IChldmVyeSBjbGllbnQgaXMgdW5hdXRoZW50aWNhdGVkIGF0IHRoZSBh
dXRob3JpemF0aW9uIGVuZHBvaW50KTxiciBjbGFzcz0iIj4NCk1VU1Qgc2VuZCBpdHMgJnF1b3Q7
Y2xpZW50X2lkJnF1b3Q7IHRvIHByZXZlbnQgaXRzZWxmIGZyb20gaW5hZHZlcnRlbnRseTxiciBj
bGFzcz0iIj4NCmFjY2VwdGluZyBhIHJlcXVlc3Qgb2JqZWN0IGZvciBhIGNsaWVudCB3aXRoIGEg
ZGlmZmVyZW50ICZxdW90O2NsaWVudF9pZCZxdW90Oy4vKjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCjwvYmxvY2txdW90ZT4NCklkZW50aWZ5aW5nIHRoZSBjbGllbnQgaW4gSkFSIHJlcXVl
c3RfdXJpIHJlcXVlc3RzIGNhbiBiZSByZWFsbHkgdXNlZnVsPGJyIGNsYXNzPSIiPg0Kc28gdGhh
dCBhbiBBUyB3aGljaCByZXF1aXJlcyByZXF1ZXN0X3VyaSByZWdpc3RyYXRpb24gdG8gcHJldmVu
dCBERG9TPGJyIGNsYXNzPSIiPg0KYXR0YWNrcyBhbmQgb3RoZXIgY2hlY2tzIGNhbiBkbyB0aG9z
ZSB3aXRob3V0IGhhdmluZyB0byBpbmRleCBhbGw8YnIgY2xhc3M9IiI+DQpyZXF1ZXN0X3VyaXMg
aW5kaXZpZHVhbGx5LiBJIG1lbnRpb25lZCB0aGlzIGJlZm9yZS48YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpJIHJlYWxseSB3b25kZXIgd2hhdCB0aGUgcmVhc29uaW5nIG9mIHRoZSBJRVNH
IHJldmlld2VycyB3YXMgdG8gaW5zaXN0PGJyIGNsYXNzPSIiPg0Kb24gbm8gcGFyYW1zIG91dHNp
ZGUgdGhlIEpBUiBKV1QgLyByZXF1ZXN0X3VyaS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQpJJ20gYmVnaW5uaW5nIHRvIHJlYWxpc2UgdGhpcyBzdGVwIG9mIHRoZSByZXZpZXcgcHJvY2Vz
cyBpc24ndDxiciBjbGFzcz0iIj4NCnBhcnRpY3VsYXJseSB0cmFuc3BhcmVudCB0byBXRyBtZW1i
ZXJzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCkNvdWxkIHlvdSBleHBhbmQgb24gdGhh
dCBhIGJpdCBtb3JlPyAmbmJzcDtNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIElFU0c8YnIg
Y2xhc3M9IiI+DQpiYWxsb3QgbWFpbCBnZXRzIGNvcGllZCB0byB0aGUgV0cgcHJlY2lzZWx5IHNv
IHRoYXQgdGhlcmUgaXMgdHJhbnNwYXJlbmN5LDxiciBjbGFzcz0iIj4NCmUuZy4sIHRoZSB0aHJl
YWQgc3RhcnRpbmcgYXQ8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl
LmlldGYub3JnL2FyY2gvbXNnL29hdXRoL2xrT2h3aURqX2hDSTU1QlFSZGlSOVIwSndnSSIgY2xh
c3M9IiI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9sa09od2lE
al9oQ0k1NUJRUmRpUjlSMEp3Z0k8L2E+PGJyIGNsYXNzPSIiPg0KV2hpY2ggYWRtaXR0ZWx5IGlz
IGZyb20gYWxtb3N0IHRocmVlIHllYXJzIGFnbywgYnV0IHRoYXQncyB0aGUgZWFybGllc3Q8YnIg
Y2xhc3M9IiI+DQp0aGF0IEkgZm91bmQgdGhhdCBjb3VsZCBiZSBzZWVuIGFzIHRoZSBzb3VyY2Ug
b2YgdGhpcyBiZWhhdmlvci48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotQmVuPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUC5TLiBzb21lIG90aGVyIGRpc2N1c3Npb24gYXQ8YnIg
Y2xhc3M9IiI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoLy10
VXJOWTFYOWVJX3RRR0k4VC1JR3g0eEh5OCBhbmQ8YnIgY2xhc3M9IiI+DQpodHRwczovL21haWxh
cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL1VrZTFueFJsZ3g2MkVKTGV2WmdwV0N6X1V3
WSBhbmQ8YnIgY2xhc3M9IiI+DQpzbyBvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i
Ij4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCk9BdXRoQGlldGYub3JnPGJyIGNs
YXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBj
bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGlu
ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFz
cz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy
IGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm
PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBj
bGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48
YnI+DQo8c3Bhbj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48YnI+DQo8c3Bhbj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BBBA7134B34D4A0C8DFFAD52E78BDB58amazoncom_--


From nobody Fri Jan 17 08:29: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 8A28E120024 for ; Fri, 17 Jan 2020 08:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 SsHbWZVllgOW for ; Fri, 17 Jan 2020 08:29:32 -0800 (PST)
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 7771B120018 for ; Fri, 17 Jan 2020 08:29:32 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id x1so23169963qkl.12 for ; Fri, 17 Jan 2020 08:29:32 -0800 (PST)
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=S6fsX3nX9kYojIZH+9dHSTo+WS57syeMpjFpq67qqNA=; b=KHNdhKu+bH57vG0XGKeXmrolTFfTnioCYuiftOPxUKQIe7wMzSmvmh9s6nn//RwoUW +eGktV3ogHY0f9FJWrGCrroON0niE+WX4j2IAAdKUdWYTWkYLkYzItD5jspb5cRjaoX/ Ppq4DPZ+TgErZItcDdPmvsuxpr0QJtio1Zt27Q9VN5gv8Wcvar0KM9JhSZQ50hNGVX5c +IKEXUzikxJvnFXpDGJ0VmLOUTWnPsjdYbbLLz7UEHCmn7grnuGW41Wku3l8+pT/V/is QjdKM2hHKezv+d/DyPLfgH6ThKO75JJkmH6Mo1gcOFfHyJzCCxFXHF91gzf4t6niMcOK AHZw==
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=S6fsX3nX9kYojIZH+9dHSTo+WS57syeMpjFpq67qqNA=; b=QSFYnuuuJXiLHC8oqiSNq4q/EARgD+U6Y82jPf3i6J9pfD1C2biAWPAJOdV9E/xAhh X39BfhIno394uYh70HHv3oWERna1mtocU6tbt+VyN5LyLjzUYLRS2CHM3MFCSrOXGFNj Gbx7THhJyX9MHlkQ7kxLew9cIGhnJN+HYZOn7RqMwOoAfQ1uNQY5Lf3gyt39irASWRv/ 3/hb0U4m8qgQbQOVh9UeSEUcNQr56Vl5NuBwdBGuI1TDOSBEMIVr3OH9uiPdT1rfgF0c Fgpc4bhbqunt02qKRQFlGdn7JKZ/k8IDoepBYT8cT4FzyeBhX0c44aFWJGj0ic27YhS/ NwiQ==
X-Gm-Message-State: APjAAAVoojJJu4I3HcPD38YDPfJ4PbGTSV4SJazVm9NA4EoURV9LNGXn wPTUlPLw0OE9doMcBEGCuVCvyg==
X-Google-Smtp-Source: APXvYqyQxHsaafrO9Nbj7flJAmUS7+X5FaDcSpv+R7P+d/lzjvfO8g8OHpWROv8XR17syl+jYRnHjw==
X-Received: by 2002:a37:6313:: with SMTP id x19mr40271018qkb.231.1579278571538;  Fri, 17 Jan 2020 08:29:31 -0800 (PST)
Received: from [192.168.0.197] (pool-173-66-45-125.washdc.fios.verizon.net. [173.66.45.125]) by smtp.gmail.com with ESMTPSA id y18sm11817555qki.0.2020.01.17.08.29.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2020 08:29:30 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-F48B2799-732B-40E9-8706-EA8E0631BA33
Content-Transfer-Encoding: 7bit
From: Jim Manico 
Mime-Version: 1.0 (1.0)
Date: Fri, 17 Jan 2020 11:29:29 -0500
Message-Id: 
References: 
Cc: Justin Richer , oauth 
In-Reply-To: 
To: "Richard Backman, Annabelle" 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 16:29:38 -0000

--Apple-Mail-F48B2799-732B-40E9-8706-EA8E0631BA33
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

It=E2=80=99s actually worse. Parameters in a URL leak over bookmarks, browse=
r history, logs everywhere, referrer headers...=20

One of the most primary rules of secure coding on the web is to never put se=
nsitive data in a URL for =E2=80=A2any=E2=80=A2 verb, not just GET.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle  wrote:
>=20
> =EF=BB=BF
> +1 to Justin=E2=80=99s comments. =46rom a security standpoint parameters i=
n the query  string are no different from those in JWT unprotected headers (=
or protected if they=E2=80=99re also in the request object). Although I=E2=80=
=98d amend Justin=E2=80=99s suggestion to say that if a parameter is both in=
side the request object and outside and they do not match, reject the reques=
t as suspicious.
>=20
>>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>>>=20
>> =EF=BB=BF I don=E2=80=99t agree with this stance from a security or imple=
mentation perspective.=20
>>=20
>> If there=E2=80=99s a clear order of precedence for the information, it=E2=
=80=99s not particularly problematic. Everything inside the request object i=
s to be taken over things outside the request object. We have the exact same=
 semantics and process with dynamic registration, where the software stateme=
nt is carried alongside plain JSON claims, and the two are mixed with a very=
 simple algorithm:
>>=20
>>  - If a field is inside the signed payload, use that value and ignore any=
 copy of it on the outside
>>  - If a field is not inside the signed payload and is outside the signed p=
ayload, use the outside value
>>=20
>> Can someone please point out a concrete security issue with this algorith=
m? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics that we need h=
ere, and it would solve not only the ability to use this for use cases that c=
all for a more static request object (perhaps signed by a third party and no=
t the client) along side the plain parameters that can vary, but also the ba=
ckwards compatibility issue that=E2=80=99s been discussed. With this algorit=
hm in place, you could have OIDC clients actually be compliant with the spec=
, since OIDC requires replication of the values inside the request object on=
 the outside with exact matches. An OIDC server wouldn=E2=80=99t be fully co=
mpliant with the new spec since it would reject some compliant JAR requests t=
hat are missing the external parameters, but that=E2=80=99s fairly easy logi=
c to add on the OIDC side. And in that case you get a matrix of compatibilit=
y like:
>>=20
>>=20
>>               JAR Server | OIDC Server  |
>> ------------+------------+--------------+
>> JAR Client  |     YES    |      NO      |
>> OIDC Client |     YES    |     YES      |
>>=20
>> Breaking one out of the four possible combinations in a very predictable w=
ay is, I think, the best way to handle backwards compatibility here.=20
>>=20
>> But between this issue and JAR=E2=80=99s problematic call for the value o=
f a request_uri to always be a JWT and be fetchable by the AS (neither of wh=
ich are true in the case of PAR) makes me think we need to pull this back an=
d rework those things, in a push back to the IESG=E2=80=99s comments.
>>=20
>>  =E2=80=94 Justin
>>=20
>>=20
>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan  wrote:
>>>=20
>>> I agree with this, particularly the security concerns of merging. If we m=
erge, we can much guarantee there will eventually be a security issue where a=
n attacker is able to gain an advantage by adding a parameter to the url que=
ry (which the server would then happily process if that parameter isn=E2=80=99=
t found inside the request object). Ruling out that case makes security anal=
ysis (particularly when creating new OAuth2 parameters) significantly simple=
r.
>>>=20
>>> Putting the iss in the JWE header and having the client_id duplicated ou=
tside the request object seem to address all the concerns I=E2=80=99ve seen r=
aised.
>>>=20
>>> (It seems like it may be unnecessary to have the client_id duplicated ou=
tside if the request_uri is a PAR one though.)
>>>=20
>>> Joseph
>>>=20
>>>=20
>>>=20
>>>> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>>>>=20
>>>> I agree with the IESG reasoning that merging is problimatic.  Once we
>>>> allow that given a unknown list of possible paramaters with diffrent
>>>> security properties it would be quite difficult to specify safely.
>>>>=20
>>>> Query paramaters can still be sent outside the JAR, but if they are in
>>>> the OAuth registry the AS MUST ignore them.
>>>>=20
>>>> Puting the iss in the JWE headder addresses the encryption issue withou=
t
>>>> merging.
>>>>=20
>>>> I understand that some existing servers have dependencys on getting the=

>>>> clientID as a query paramater.
>>>>=20
>>>> Is that the only paramater that people have a issue with as oposed to a=

>>>> nice to have?
>>>>=20
>>>> Would allowing the AS to not ignore the clientID as a query paramater a=
s
>>>> long as it matches the one inside the JAR, basicly the same as Connect
>>>> request object but for just the one paramater make life easier for the
>>>> servers?
>>>>=20
>>>> I am not promising a change but gathering info before proposing somethi=
ng.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>>>>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>>>>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>>>>> Well, embedding a client_id claim in the JWE header in order to
>>>>>>> achieve "request parameters outside the request object should not be=

>>>>>>> referred to" is like "putting the cart before the horse". Why do we
>>>>>>> have to avoid using the traditional client_id request parameter so
>>>>>>> stubbornly?
>>>>>>>=20
>>>>>>> The last paragraph of Section 3.2.1
>>>>>>>  of RFC 6749 says=

>>>>>>> as follows.
>>>>>>>=20
>>>>>>>   /A client MAY use the "client_id" request parameter to identify
>>>>>>>   itself when sending requests to the token endpoint.  In the
>>>>>>>   "authorization_code" "grant_type" request to the token endpoint,
>>>>>>>   *an unauthenticated client MUST send its "client_id" to prevent
>>>>>>>   itself from inadvertently accepting a code intended for a client
>>>>>>>   with a different "client_id".*  This protects the client from
>>>>>>>   substitution of the authentication code.  (It provides no
>>>>>>>   additional security for the protected resource.)/
>>>>>>>=20
>>>>>>>=20
>>>>>>> If the same reasoning applies, a client_id must always be sent with
>>>>>>> request / request_uri because client authentication is not performed=

>>>>>>> at the authorization endpoint. In other words, */an unauthenticated
>>>>>>> client (every client is unauthenticated at the authorization endpoin=
t)
>>>>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>>>>> accepting a request object for a client with a different "client_id"=
./*
>>>>>>>=20
>>>>>> Identifying the client in JAR request_uri requests can be really usef=
ul
>>>>>> so that an AS which requires request_uri registration to prevent DDoS=

>>>>>> attacks and other checks can do those without having to index all
>>>>>> request_uris individually. I mentioned this before.
>>>>>>=20
>>>>>> I really wonder what the reasoning of the IESG reviewers was to insis=
t
>>>>>> on no params outside the JAR JWT / request_uri.
>>>>>>=20
>>>>>> I'm beginning to realise this step of the review process isn't
>>>>>> particularly transparent to WG members.
>>>>> Could you expand on that a bit more?  My understanding is that the IES=
G
>>>>> ballot mail gets copied to the WG precisely so that there is transpare=
ncy,
>>>>> e.g., the thread starting at
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0Jwg=
I
>>>>> Which admittely is from almost three years ago, but that's the earlies=
t
>>>>> that I found that could be seen as the source of this behavior.
>>>>>=20
>>>>> -Ben
>>>>>=20
>>>>> P.S. some other discussion at
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy=
8 and
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_Uw=
Y and
>>>>> so on.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-F48B2799-732B-40E9-8706-EA8E0631BA33
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

It=E2=80=99s actually worse. Parameters in a=
 URL leak over bookmarks, browser history, logs everywhere, referrer headers=
... 

One of the most primary rules of secure coding o=
n the web is to never put sensitive data in a URL for =E2=80=A2any=E2=80=A2 v=
erb, not just GET.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-380=
5

On Jan 17, 2020,=
 at 11:24 AM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.i=
etf.org> wrote:

=EF=BB=BF





+1 to Justin=E2=80=99s comments. =46rom a security standpoi=
nt parameters in the query  string are no different from those in JWT u=
nprotected headers (or protected if they=E2=80=99re also in the request obje=
ct). Although I=E2=80=98d amend Justin=E2=80=99s suggestion to say that
 if a parameter is both inside the request object and outside and they do no=
t match, reject the request as suspicious.










On Jan 17, 2020, at 5:45 AM, Justin Richer <jri=
cher@mit.edu> wrote:










=EF=BB=BF I don=E2=80=99t agree with this stance from a sec=
urity or implementation perspective. 






If there=E2=80=99s a clear order of precedence for the infor=
mation, it=E2=80=99s not particularly problematic. Everything inside the req=
uest object is to be taken over things outside the request object. We have t=
he exact same semantics and process with dynamic
 registration, where the software statement is carried alongside plain JSON c=
laims, and the two are mixed with a very simple algorithm:







 - If a field is inside the signed payload, use that va=
lue and ignore any copy of it on the outside


 - If a field is not inside the signed payload and is o=
utside the signed payload, use the outside value







Can someone please point out a concrete security issue with t=
his algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics t=
hat we need here, and it would solve not only the ability to use this for us=
e cases that call for a more static request object
 (perhaps signed by a third party and not the client) along side the plain p=
arameters that can vary, but also the backwards compatibility issue that=E2=80=
=99s been discussed. With this algorithm in place, you could have OIDC clien=
ts actually be compliant with the spec,
 since OIDC requires replication of the values inside the request object on t=
he outside with exact matches. An OIDC server wouldn=E2=80=99t be fully comp=
liant with the new spec since it would reject some compliant JAR requests th=
at are missing the external parameters,
 but that=E2=80=99s fairly easy logic to add on the OIDC side. And in that c=
ase you get a matrix of compatibility like:














              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |      NO =
     |
OIDC Client |     YES   =
 |     YES      |









Breaking one out of the four possible combinations in a very=
 predictable way is, I think, the best way to handle backwards compatibility=
 here. 







But between this issue and JAR=E2=80=99s problematic call fo=
r the value of a request_uri to always be a JWT and be fetchable by the AS (=
neither of which are true in the case of PAR) makes me think we need to pull=
 this back and rework those things, in
 a push back to the IESG=E2=80=99s comments.







 =E2=80=94 Justin














On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com> wrote:





I agree with this, particularly the security concerns of mer=
ging. If we merge, we can much guarantee there will eventually be a security=
 issue where an attacker is able to gain an advantage by adding a parameter t=
o the url query (which the server
 would then happily process if that parameter isn=E2=80=99t found inside the=
 request object). Ruling out that case makes security analysis (particularly=
 when creating new OAuth2 parameters) significantly simpler.



Putting the iss in the JWE header and having the client_id duplicated outsid=
e the request object seem to address all the concerns I=E2=80=99ve seen rais=
ed.



(It seems like it may be unnecessary to have the client_id duplicated outsid=
e if the request_uri is a PAR one though.)



Joseph








On 16 Jan 2020, at 22:40, John Bradley &=
lt;ve7jtb@ve7jtb.com>=
 wrote:



I agree with the IESG reasoning that merging is problimatic.  Once we
allow that given a unknown list of possible paramaters with diffrent

security properties it would be quite difficult to specify safely.



Query paramaters can still be sent outside the JAR, but if they are in

the OAuth registry the AS MUST ignore them.



Puting the iss in the JWE headder addresses the encryption issue without

merging.



I understand that some existing servers have dependencys on getting the

clientID as a query paramater.



Is that the only paramater that people have a issue with as oposed to a

nice to have?



Would allowing the AS to not ignore the clientID as a query paramater as

long as it matches the one inside the JAR, basicly the same as Connect

request object but for just the one paramater make life easier for the

servers?



I am not promising a change but gathering info before proposing something.


John B.





On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:


On Wed, Jan 15, 2020 at 11:02:33PM +020=
0, Vladimir Dzhuvinov wrote:


On 14/01/2020 19:20, Takahiko Kawasaki w=
rote:


Well, embedding a client_id claim in th=
e JWE header in order to

achieve "request parameters outside the request object should not be

referred to" is like "putting the cart before the horse". Why do we

have to avoid using the traditional client_id request parameter so

stubbornly?



The last paragraph of Section 3.2.1

<https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says<=
br class=3D"">
as follows.



  /A client MAY use the "client_id" request parameter to identify<=
br class=3D"">
  itself when sending requests to the token endpoint.  In the=


  "authorization_code" "grant_type" request to the token endpoint,=


  *an unauthenticated client MUST send its "client_id" to prevent<=
br class=3D"">
  itself from inadvertently accepting a code intended for a client=


  with a different "client_id".*  This protects the client fr=
om

  substitution of the authentication code.  (It provides no
  additional security for the protected resource.)/
=





If the same reasoning applies, a client_id must always be sent with

request / request_uri because client authentication is not performed

at the authorization endpoint. In other words, */an unauthenticated

client (every client is unauthenticated at the authorization endpoint)

MUST send its "client_id" to prevent itself from inadvertently

accepting a request object for a client with a different "client_id"./*





Identifying the client in JAR request_uri requests can be really useful

so that an AS which requires request_uri registration to prevent DDoS

attacks and other checks can do those without having to index all

request_uris individually. I mentioned this before.



I really wonder what the reasoning of the IESG reviewers was to insist

on no params outside the JAR JWT / request_uri.



I'm beginning to realise this step of the review process isn't

particularly transparent to WG members.



Could you expand on that a bit more?  My understanding is that the IESG=


ballot mail gets copied to the WG precisely so that there is transparency,
e.g., the thread starting at

https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI5=
5BQRdiR9R0JwgI

Which admittely is from almost three years ago, but that's the earliest

that I found that could be seen as the source of this behavior.



-Ben



P.S. some other discussion at

https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and<=
br class=3D"">
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and<=
br class=3D"">
so on.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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













_______________________________________________

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-F48B2799-732B-40E9-8706-EA8E0631BA33--


From nobody Fri Jan 17 08:34: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 1D93E120024 for ; Fri, 17 Jan 2020 08:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqm2DN5XJACf for ; Fri, 17 Jan 2020 08:34:24 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3F9120018 for ; Fri, 17 Jan 2020 08:34:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579278865; x=1610814865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e8pVIErCbYr1bDmDjUH3c1NFxSq/hxN6uB0EJNr7HAc=; b=k/LkURjpdNIJadNoSSxdeJUFAGSYlbD9CYOaZdZiq4YH0ko+3Kw7y8Im 2ZUNIUjRPZ5/g+Vhhr7d+NM6g5FxySVQApqykeYN+TmU6IKfGnSQF+KnG vmen4LCEwMina4gW+dvP1Im+sqL+QTeynAj53Wll8kmowNBsi4wsz7pA3 w=;
IronPort-SDR: BZtUfWhIdP79snfwWMj+eWf82UggDxaYj82uP2cAbygyS2jzNuLWQG5l2r69rrzs2cZlTiLtOf a/PQvKE8nIYw==
X-IronPort-AV: E=Sophos;i="5.70,330,1574121600"; d="scan'208";a="10958638"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 17 Jan 2020 16:34:12 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-a7fdc47a.us-west-2.amazon.com (Postfix) with ESMTPS id 564F4C5DFE; Fri, 17 Jan 2020 16:34:11 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:34:10 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 17 Jan 2020 16:34:10 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 17 Jan 2020 16:34:10 +0000
From: "Richard Backman, Annabelle" 
To: Benjamin Kaduk 
CC: Neil Madden , IETF oauth WG 
Thread-Topic: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVyBgJ47SBXlMdXkypCDJuQVGWtKfkpDcAgACLVgCAAK0VgIAC52cAgAGpqICAAdBVgIAAqQMAgAATAYCAAAUzAIAAZCeAgAAVAoCAAAw5AIAAwAMAgADTEic=
Date: Fri, 17 Jan 2020 16:34:10 +0000
Message-ID: <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
References:   <20200116143233.GJ80030@kduck.mit.edu>  <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com>, <20200117035844.GQ80030@kduck.mit.edu>
In-Reply-To: <20200117035844.GQ80030@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 16:34:28 -0000

V2Ugc2hvdWxkIG5vdCBiZSBwcmVzY3JpcHRpdmUgYWJvdXQgaG93IHRoZSBBUyByZWNvZ25pemVz
IHJlcXVlc3QgVVJJcyBmcm9tIGl0c2VsZi4gVHJ1c3RlZCBhdXRob3JpdHkgb3IgY3VzdG9tIFVS
SSBzY2hlbWUgYXJlIGZpbmUgYXMgZXhhbXBsZXMsIGJ1dCB1bHRpbWF0ZWx5IHRoaXMgaXMgYW4g
aW50ZXJuYWwgaW1wbGVtZW50YXRpb24gb2YgdGhlIEFTLiBJdCBjb3VsZCBqdXN0IGFzIGVhc2ls
eSBiZSB1c2luZyBkYXRhIFVSSXMgY29udGFpbmluZyBhIHN5bW1ldHJpY2FsbHkgZW5jcnlwdGVk
IGRhdGFiYXNlIHJlY29yZCBJRC4NCg0KPiBPbiBKYW4gMTYsIDIwMjAsIGF0IDg6MDAgUE0sIEJl
bmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PiB3cm90ZToNCj4gDQo+IO+7v09uIFRodSwgSmFu
IDE2LCAyMDIwIGF0IDA0OjMxOjMwUE0gKzAwMDAsIE5laWwgTWFkZGVuIHdyb3RlOg0KPj4gVGhl
IG1pdGlnYXRpb25zIG9mIDEwLjQuMSBhcmUgcmVsYXRlZCwgYnV0IHRoZSBzZWN0aW9uIGhlYWRp
bmcgaXMgYWJvdXQgKEQpRG9TIGF0dGFja3MuIEkgdGhpbmsgdGhpcyBoZWFkaW5nIG5lZWRzIHRv
IGJlIHJld29yZGVkIHRvIGFwcGx5IHRvIFNTUkYgYXR0YWNrcyB0b28gb3IgZWxzZSBhZGQgYW5v
dGhlciBzZWN0aW9uIHdpdGggc2ltaWxhciBtaXRpZ2F0aW9ucy4gDQo+PiANCj4+IE1pdGlnYXRp
b24gKGEpIGlzIGEgYml0IHZhZ3VlIGFzIHRvIHdoYXQgYW4gInVuZXhwZWN0ZWQgbG9jYXRpb24i
IGlzLiBQZXJoYXBzIHNwZWNpZmljIHdvcmRpbmcgdGhhdCBpdCBzaG91bGQgYmUgYSBVUkkgdGhh
dCBoYXMgYmVlbiBwcmUtcmVnaXN0ZXJlZCBmb3IgdGhlIGNsaWVudCAoYW5kIHZhbGlkYXRlZCBh
dCB0aGF0IHRpbWUpIG9yIGlzIG90aGVyd2lzZSBrbm93biB0byBiZSBzYWZlIChlLmcuLCBpcyBh
IFVSSSBzY2hlbWUgY29udHJvbGxlZCBieSB0aGUgQVMgaXRzZWxmIGFzIHdpdGggUEFSKS4NCj4g
DQo+IHBlZGFudGljIG5pdDogIlVSSSBzY2hlbWUiIGlzIHByb2JhYmx5IG5vdCB3aGF0IHdlIHdh
bnQsIGFzIHRoZSBhdXRob3JpdHkNCj4gY29tcG9uZW50IG9mIHRoZSBVUkkgKHBlciBSRkMgMzk4
Nikgc2VlbXMgbW9yZSBsaWtlbHkgdG8gbWF0Y2ggImNvbnRyb2xsZWQNCj4gYnkgdGhlIEFTIGl0
c2VsZiINCj4gDQo+IC1CZW4NCj4gDQo+PiBJbiBhZGRpdGlvbiBmb3IgdGhpcyB0byBiZSBlZmZl
Y3RpdmUgdGhlIEFTIHNob3VsZCBub3QgZm9sbG93IHJlZGlyZWN0cyB3aGVuIGZldGNoaW5nIHRo
ZSBVUkkuIEl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhhdCBpcyBpbXBsaWVkIGJ5ICJu
b3QgcGVyZm9ybSByZWN1cnNpdmUgR0VUIiBzbyBpdCBtYXkgYmUgd29ydGggZXhwbGljaXRseSBz
cGVsbGluZyB0aGF0IG91dC4NCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYu
b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==


From nobody Fri Jan 17 10:29: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 39950120025 for ; Fri, 17 Jan 2020 10:29:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz4RQd6Jjjrt for ; Fri, 17 Jan 2020 10:29:12 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A3D12007C for ; Fri, 17 Jan 2020 10:29:12 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00HIT8jV019263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 13:29:09 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EB73746-34C8-4DDE-96BC-66D307026A2E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 17 Jan 2020 13:29:08 -0500
In-Reply-To: 
Cc: "Richard Backman, Annabelle" , oauth 
To: Jim Manico 
References:  
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 18:29:15 -0000

--Apple-Mail=_0EB73746-34C8-4DDE-96BC-66D307026A2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

But that=E2=80=99s also the same for parameters in a signed =
(non-encrypted) request object.

 =E2=80=94 Justin

> On Jan 17, 2020, at 11:29 AM, Jim Manico  wrote:
>=20
> It=E2=80=99s actually worse. Parameters in a URL leak over bookmarks, =
browser history, logs everywhere, referrer headers...=20
>=20
> One of the most primary rules of secure coding on the web is to never =
put sensitive data in a URL for =E2=80=A2any=E2=80=A2 verb, not just =
GET.
>=20
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>=20
>> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle =
 wrote:
>>=20
>> =EF=BB=BF
>> +1 to Justin=E2=80=99s comments. =46rom a security standpoint =
parameters in the query  string are no different from those in JWT =
unprotected headers (or protected if they=E2=80=99re also in the request =
object). Although I=E2=80=98d amend Justin=E2=80=99s suggestion to say =
that if a parameter is both inside the request object and outside and =
they do not match, reject the request as suspicious.
>>=20
>>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>>>=20
>>> =EF=BB=BF I don=E2=80=99t agree with this stance from a security or =
implementation perspective.=20
>>>=20
>>> If there=E2=80=99s a clear order of precedence for the information, =
it=E2=80=99s not particularly problematic. Everything inside the request =
object is to be taken over things outside the request object. We have =
the exact same semantics and process with dynamic registration, where =
the software statement is carried alongside plain JSON claims, and the =
two are mixed with a very simple algorithm:
>>>=20
>>>  - If a field is inside the signed payload, use that value and =
ignore any copy of it on the outside
>>>  - If a field is not inside the signed payload and is outside the =
signed payload, use the outside value
>>>=20
>>> Can someone please point out a concrete security issue with this =
algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics =
that we need here, and it would solve not only the ability to use this =
for use cases that call for a more static request object (perhaps signed =
by a third party and not the client) along side the plain parameters =
that can vary, but also the backwards compatibility issue that=E2=80=99s =
been discussed. With this algorithm in place, you could have OIDC =
clients actually be compliant with the spec, since OIDC requires =
replication of the values inside the request object on the outside with =
exact matches. An OIDC server wouldn=E2=80=99t be fully compliant with =
the new spec since it would reject some compliant JAR requests that are =
missing the external parameters, but that=E2=80=99s fairly easy logic to =
add on the OIDC side. And in that case you get a matrix of compatibility =
like:
>>>=20
>>>=20
>>>               JAR Server | OIDC Server  |
>>> ------------+------------+--------------+
>>> JAR Client  |     YES    |      NO      |
>>> OIDC Client |     YES    |     YES      |
>>>=20
>>> Breaking one out of the four possible combinations in a very =
predictable way is, I think, the best way to handle backwards =
compatibility here.=20
>>>=20
>>> But between this issue and JAR=E2=80=99s problematic call for the =
value of a request_uri to always be a JWT and be fetchable by the AS =
(neither of which are true in the case of PAR) makes me think we need to =
pull this back and rework those things, in a push back to the IESG=E2=80=99=
s comments.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>=20
>>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan > wrote:
>>>>=20
>>>> I agree with this, particularly the security concerns of merging. =
If we merge, we can much guarantee there will eventually be a security =
issue where an attacker is able to gain an advantage by adding a =
parameter to the url query (which the server would then happily process =
if that parameter isn=E2=80=99t found inside the request object). Ruling =
out that case makes security analysis (particularly when creating new =
OAuth2 parameters) significantly simpler.
>>>>=20
>>>> Putting the iss in the JWE header and having the client_id =
duplicated outside the request object seem to address all the concerns =
I=E2=80=99ve seen raised.
>>>>=20
>>>> (It seems like it may be unnecessary to have the client_id =
duplicated outside if the request_uri is a PAR one though.)
>>>>=20
>>>> Joseph
>>>>=20
>>>>=20
>>>>=20
>>>>> On 16 Jan 2020, at 22:40, John Bradley > wrote:
>>>>>=20
>>>>> I agree with the IESG reasoning that merging is problimatic.  Once =
we
>>>>> allow that given a unknown list of possible paramaters with =
diffrent
>>>>> security properties it would be quite difficult to specify safely.
>>>>>=20
>>>>> Query paramaters can still be sent outside the JAR, but if they =
are in
>>>>> the OAuth registry the AS MUST ignore them.
>>>>>=20
>>>>> Puting the iss in the JWE headder addresses the encryption issue =
without
>>>>> merging.
>>>>>=20
>>>>> I understand that some existing servers have dependencys on =
getting the
>>>>> clientID as a query paramater.
>>>>>=20
>>>>> Is that the only paramater that people have a issue with as oposed =
to a
>>>>> nice to have?
>>>>>=20
>>>>> Would allowing the AS to not ignore the clientID as a query =
paramater as
>>>>> long as it matches the one inside the JAR, basicly the same as =
Connect
>>>>> request object but for just the one paramater make life easier for =
the
>>>>> servers?
>>>>>=20
>>>>> I am not promising a change but gathering info before proposing =
something.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>=20
>>>>> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>>>>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov =
wrote:
>>>>>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>>>>>> Well, embedding a client_id claim in the JWE header in order to
>>>>>>>> achieve "request parameters outside the request object should =
not be
>>>>>>>> referred to" is like "putting the cart before the horse". Why =
do we
>>>>>>>> have to avoid using the traditional client_id request parameter =
so
>>>>>>>> stubbornly?
>>>>>>>>=20
>>>>>>>> The last paragraph of Section 3.2.1
>>>>>>>> > of RFC 6749 says
>>>>>>>> as follows.
>>>>>>>>=20
>>>>>>>>   /A client MAY use the "client_id" request parameter to =
identify
>>>>>>>>   itself when sending requests to the token endpoint.  In the
>>>>>>>>   "authorization_code" "grant_type" request to the token =
endpoint,
>>>>>>>>   *an unauthenticated client MUST send its "client_id" to =
prevent
>>>>>>>>   itself from inadvertently accepting a code intended for a =
client
>>>>>>>>   with a different "client_id".*  This protects the client from
>>>>>>>>   substitution of the authentication code.  (It provides no
>>>>>>>>   additional security for the protected resource.)/
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> If the same reasoning applies, a client_id must always be sent =
with
>>>>>>>> request / request_uri because client authentication is not =
performed
>>>>>>>> at the authorization endpoint. In other words, */an =
unauthenticated
>>>>>>>> client (every client is unauthenticated at the authorization =
endpoint)
>>>>>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>>>>>> accepting a request object for a client with a different =
"client_id"./*
>>>>>>>>=20
>>>>>>> Identifying the client in JAR request_uri requests can be really =
useful
>>>>>>> so that an AS which requires request_uri registration to prevent =
DDoS
>>>>>>> attacks and other checks can do those without having to index =
all
>>>>>>> request_uris individually. I mentioned this before.
>>>>>>>=20
>>>>>>> I really wonder what the reasoning of the IESG reviewers was to =
insist
>>>>>>> on no params outside the JAR JWT / request_uri.
>>>>>>>=20
>>>>>>> I'm beginning to realise this step of the review process isn't
>>>>>>> particularly transparent to WG members.
>>>>>> Could you expand on that a bit more?  My understanding is that =
the IESG
>>>>>> ballot mail gets copied to the WG precisely so that there is =
transparency,
>>>>>> e.g., the thread starting at
>>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI =

>>>>>> Which admittely is from almost three years ago, but that's the =
earliest
>>>>>> that I found that could be seen as the source of this behavior.
>>>>>>=20
>>>>>> -Ben
>>>>>>=20
>>>>>> P.S. some other discussion at
>>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 =
and
>>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY =
and
>>>>>> so on.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_0EB73746-34C8-4DDE-96BC-66D307026A2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

But =
that=E2=80=99s also the same for parameters in a signed (non-encrypted) =
request object.

 =E2=80=94 Justin

On Jan =
17, 2020, at 11:29 AM, Jim Manico <jim@manicode.com> wrote:



It=E2=80=99s actually worse. =
Parameters in a URL leak over bookmarks, browser history, logs =
everywhere, referrer headers... 

One of the most primary rules of secure =
coding on the web is to never put sensitive data in a URL for =E2=80=A2any=
=E2=80=A2 verb, not just GET.

--
Jim =
Manico
@Manicode
Secure Coding =
Education
+1 (808) 652-3805

On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle =
<richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=EF=BB=BF





+1 to Justin=E2=80=99s comments. =46rom a =
security standpoint parameters in the query  string are no =
different from those in JWT unprotected headers (or protected if =
they=E2=80=99re also in the request object). Although I=E2=80=98d amend =
Justin=E2=80=99s suggestion to say that
 if a parameter is both inside the request object and outside and they =
do not match, reject the request as suspicious.










On Jan 17, 2020, at 5:45 AM, Justin =
Richer <jricher@mit.edu> wrote:










=EF=BB=BF I don=E2=80=99t agree with this =
stance from a security or implementation perspective. 






If there=E2=80=99s a clear order of precedence for the =
information, it=E2=80=99s not particularly problematic. Everything =
inside the request object is to be taken over things outside the request =
object. We have the exact same semantics and process with dynamic
 registration, where the software statement is carried alongside plain =
JSON claims, and the two are mixed with a very simple algorithm:







 - If a field is inside the signed payload, use =
that value and ignore any copy of it on the outside


 - If a field is not inside the signed payload and =
is outside the signed payload, use the outside value







Can someone please point out a concrete security issue =
with this algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D =
semantics that we need here, and it would solve not only the ability to =
use this for use cases that call for a more static request object
 (perhaps signed by a third party and not the client) along side the =
plain parameters that can vary, but also the backwards compatibility =
issue that=E2=80=99s been discussed. With this algorithm in place, you =
could have OIDC clients actually be compliant with the spec,
 since OIDC requires replication of the values inside the request object =
on the outside with exact matches. An OIDC server wouldn=E2=80=99t be =
fully compliant with the new spec since it would reject some compliant =
JAR requests that are missing the external parameters,
 but that=E2=80=99s fairly easy logic to add on the OIDC side. And in =
that case you get a matrix of compatibility like:














              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |     =
 NO      |
OIDC Client |    =
 YES    |     YES      |









Breaking one out of the four possible combinations in a =
very predictable way is, I think, the best way to handle backwards =
compatibility here. 







But between this issue and JAR=E2=80=99s problematic =
call for the value of a request_uri to always be a JWT and be fetchable =
by the AS (neither of which are true in the case of PAR) makes me think =
we need to pull this back and rework those things, in
 a push back to the IESG=E2=80=99s comments.







 =E2=80=94 Justin














On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com>=
 wrote:






I agree with this, particularly the security concerns of =
merging. If we merge, we can much guarantee there will eventually be a =
security issue where an attacker is able to gain an advantage by adding =
a parameter to the url query (which the server
 would then happily process if that parameter isn=E2=80=99t found inside =
the request object). Ruling out that case makes security analysis =
(particularly when creating new OAuth2 parameters) significantly =
simpler.



Putting the iss in the JWE header and having the client_id duplicated =
outside the request object seem to address all the concerns I=E2=80=99ve =
seen raised.



(It seems like it may be unnecessary to have the client_id duplicated =
outside if the request_uri is a PAR one though.)



Joseph








On 16 Jan 2020, at 22:40, John =
Bradley <ve7jtb@ve7jtb.com> wrote:



I agree with the IESG reasoning that merging is problimatic.  Once =
we

allow that given a unknown list of possible paramaters with diffrent

security properties it would be quite difficult to specify safely.



Query paramaters can still be sent outside the JAR, but if they are =
in

the OAuth registry the AS MUST ignore them.



Puting the iss in the JWE headder addresses the encryption issue =
without

merging.



I understand that some existing servers have dependencys on getting =
the

clientID as a query paramater.



Is that the only paramater that people have a issue with as oposed to =
a

nice to have?



Would allowing the AS to not ignore the clientID as a query paramater =
as

long as it matches the one inside the JAR, basicly the same as =
Connect

request object but for just the one paramater make life easier for =
the

servers?



I am not promising a change but gathering info before proposing =
something.



John B.





On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:


On Wed, Jan 15, 2020 at 11:02:33PM =
+0200, Vladimir Dzhuvinov wrote:


On 14/01/2020 19:20, Takahiko =
Kawasaki wrote:


Well, embedding a client_id claim =
in the JWE header in order to

achieve "request parameters outside the request object should not be

referred to" is like "putting the cart before the horse". Why do we

have to avoid using the traditional client_id request parameter so

stubbornly?



The last paragraph of Section 3.2.1

<https://tools.ietf.org/html/rfc6749#section-3.2.1> of =
RFC 6749 says

as follows.



  /A client MAY use the "client_id" request parameter to =
identify

  itself when sending requests to the token endpoint.  In =
the

  "authorization_code" "grant_type" request to the token =
endpoint,

  *an unauthenticated client MUST send its "client_id" to =
prevent

  itself from inadvertently accepting a code intended for a =
client

  with a different "client_id".*  This protects the =
client from

  substitution of the authentication code.  (It provides =
no

  additional security for the protected resource.)/





If the same reasoning applies, a client_id must always be sent with

request / request_uri because client authentication is not performed

at the authorization endpoint. In other words, */an unauthenticated

client (every client is unauthenticated at the authorization =
endpoint)

MUST send its "client_id" to prevent itself from inadvertently

accepting a request object for a client with a different =
"client_id"./*





Identifying the client in JAR request_uri requests can be really =
useful

so that an AS which requires request_uri registration to prevent DDoS

attacks and other checks can do those without having to index all

request_uris individually. I mentioned this before.



I really wonder what the reasoning of the IESG reviewers was to =
insist

on no params outside the JAR JWT / request_uri.



I'm beginning to realise this step of the review process isn't

particularly transparent to WG members.



Could you expand on that a bit more?  My understanding is that the =
IESG

ballot mail gets copied to the WG precisely so that there is =
transparency,

e.g., the thread starting at

https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdi=
R9R0JwgI

Which admittely is from almost three years ago, but that's the =
earliest

that I found that could be seen as the source of this behavior.



-Ben



P.S. some other discussion at

https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-=
IGx4xHy8 and

https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZg=
pWCz_UwY and

so on.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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













_______________________________________________
OAuth mailing 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=_0EB73746-34C8-4DDE-96BC-66D307026A2E--


From nobody Fri Jan 17 11:48: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 8A09E1200A4 for ; Fri, 17 Jan 2020 11:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RmLXNCKthGQk for ; Fri, 17 Jan 2020 11:48:12 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349121200D6 for ; Fri, 17 Jan 2020 11:48:11 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id r19so27654546ljg.3 for ; Fri, 17 Jan 2020 11:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G2lOItU26xjK2QAiuDwcmVBjdhg/5+KDhFxznyq6iws=; b=E4bYK5mFO7KI81f8c5BbCnNFdBQch0kscmtH48lFZ9iuVRjyS6HxHT011UGdo3GbE5 BQ3UJpVCV8rBCW8JSDtRE9oI9LWxbrYbwTsmC8wBlC8/yjVnc9r9QXu7ptx34zNX0rsm De0zOgzZQtxbQnU6dQfG/s5QfX8kS42ry21aKHte7A/xNyVcwcTbrm1BfTnDyAJ5otc0 35XylkSlCHsdXbX29sLYiNfS/OAn6QejQ4Rr6ELk57swu58ug2Bl04kg1CoywUOS1n/5 ZYBBi7Cvtf8rqRKjRXhKcNRhJm3YLa3KnGxCXzItcZ7+DuNqzwlkkRrfCfKd+Ad0wgxi LsiA==
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=G2lOItU26xjK2QAiuDwcmVBjdhg/5+KDhFxznyq6iws=; b=clyU9UMbRKL34UYBJjBEDdc+CQWy9YENScHCxw8Z5XnSOCQKnQNbcJyukk4olRsCpJ j8skh1dIjwxJ+tZFXM6r+FbG7W3K7BzPHedqIOwRQxwFQI/U8mCRleVrSFTZmwS5t2eS SL3+tGBbYDEQoshJSHvbHTm+rAWEpuAdmFUXPxC77wiKX6GcYNBcIId7968q1RTzK3nU 7Hkb5Gfocq4cfa4xCkP9p8tYDKtipp1RDWr5hh7azpDtXFKuVMRTCPSDI0JGk6d8gPlB QnREZAuUN4AvadXuMPPQh/F/Rd5xB2nmT5yDSIWjQSJ7k64OhwCMwwiCQKnRNw+8jaSe vk5g==
X-Gm-Message-State: APjAAAXmEGpialLfeoitGzQbw2cFE6ZcWrk1vdHIbpcraZ5+fyBh5EpS 3lu+WGFpmlx3q79vLejGDlpzbhVtz7lN5ExJT5DDfNXRLGcyPQ7hW1SdtFdA2CPRCIJWhngyJbQ Hi67lCab/dCtu5Q==
X-Google-Smtp-Source: APXvYqzjqkNdT2N/ECVm1ZH/MIkj29FCU1vhoPiteZJezmWHFpSDg99Xn/vr1R0FShmNb3Zg7LKm5E5mrjFw7j4osAU=
X-Received: by 2002:a2e:805a:: with SMTP id p26mr6622323ljg.242.1579290489274;  Fri, 17 Jan 2020 11:48:09 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com>  <00807967-2452-4DB0-AF0C-5BE7EA92B3A7@amazon.com>
In-Reply-To: <00807967-2452-4DB0-AF0C-5BE7EA92B3A7@amazon.com>
From: Brian Campbell 
Date: Fri, 17 Jan 2020 12:47:41 -0700
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Justin Richer , Nat Sakimura , oauth 
Content-Type: multipart/alternative; boundary="0000000000009c5fe1059c5b382d"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 17 Jan 2020 19:48:15 -0000

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

+1 to keeping/using =E2=80=9Crequest_uri=E2=80=9D

On Thu, Jan 16, 2020 at 10:49 AM Richard Backman, Annabelle  wrote:

> We=E2=80=99ve already defined a request identifier parameter. We called i=
t
> =E2=80=9Crequest_uri=E2=80=9D. That=E2=80=99s what the =E2=80=9CI=E2=80=
=9D in URI stands for. Let=E2=80=99s just fix the
> semantics on that one. It=E2=80=99s bad enough that we have request and
> request_uri, let=E2=80=99s not add a third one.
>
> Sent from my iPhone
>
> On Jan 16, 2020, at 9:33 AM, Justin Richer  wrote:
>
> =EF=BB=BF What you=E2=80=99ve described is exactly what happens in XYZ:
>
> https://oauth.xyz/interaction/
>
> And this is what we=E2=80=99re discussing as the basis in TxAuth. But in =
this case
> since you=E2=80=99re stuck with OAuth 2=E2=80=99s authorization endpoint =
syntax and
> semantics, you=E2=80=99re still limited with what=E2=80=99s happening the=
re and it could
> come with its own security oddities (like maybe a new form of a mixup
> attack?) that we haven=E2=80=99t figured out yet. Like, is the AS allowed=
 to send
> the client to something other than its own authorization endpoint? Is the
> client supposed to validate the syntax of the authorization endpoint URL
> against its discovery document? It deeply changes what OAuth 2 does, and
> that makes it really hard to add on.
>
> Using request_uri to pass the artifact is clever, but I also like
> Torsten=E2=80=99s idea of using a new field defined by PAR to pass the ar=
tifact.
> Granted, in the Authlete implementation of PAR, we were able to re-use a
> whole bunch of code for processing request objects, and that was pretty
> nice. Still, the issues with JAR are non-zero, and so we need to figure o=
ut
> whether we should fully decouple or fix the issues. I=E2=80=99m in favor =
of fixing
> things and using these together, but there=E2=80=99s a lot of inertia aga=
inst that.
>
>  =E2=80=94 Justin
>
> On Jan 16, 2020, at 11:36 AM, Neil Madden 
> wrote:
>
> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the Location header? That way the AS can
> decide for itself how to communicate any id from the PAR endpoint to the
> authorization endpoint.
>
> This also has the side effect that you can kick off an OAuth2 flow with a
> simple HTML form pointed at the PAR endpoint (with hidden fields for
> state/code_challenge etc).
>
> If actually performing the redirect is a bit problematic then at least th=
e
> idea of returning a full URL for the authorization endpoint (hyperlink)
> rather than returning an id/URI and requiring the client to construct one
> seems reasonable to me and would seem to avoid some of the difficulties
> being discussed with JAR etc as the exact mechanism of communication
> becomes an implementation detail that the client needn't know about.
>
> -- Neil
>
> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <
> torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> =EF=BB=BF+1 to this approach, and it sounds like JAR might need to come b=
ack to go
> through another round anyway thanks to the breaking changes the IESG push=
ed
> into it after it left WGLC.
>
> I=E2=80=99d rather see us get this right than publish something many of u=
s think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  =E2=80=94 Justin
>
> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <
> richanna@amazon.com> wrote:
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document=
.
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can=E2=80=
=99t fix
> the draft that hasn=E2=80=99t actually been published yet.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>
> To be clear, I=E2=80=99m not saying we suggest a particular form, and I a=
gree that
> we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D or=
 something of that nature. But if
> we call the result of PAR =E2=80=9Cthing X=E2=80=9D and the target of req=
uest_uri =E2=80=9Cthing X=E2=80=9D
> in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in
> all cases.
>
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be
> specified.
>
>
> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted
> as a JWT.
>
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web
> Token, or some other verifiable blob, resulting in the same essential
> function, and this isn't affecting the client <-> AS contract in any way.
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believ=
e
> that=E2=80=99s been backed off now and made conditional.
>
> That was precisely my point.
> Vladimir
>
>
>
>  =E2=80=94 Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint a=
nd
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or oth=
er
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end=
.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, witho=
ut
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
> Vladimir
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it=E2=80=99s a JWT and=
 instead
> say it=E2=80=99s a request object. Or we define a new term for this autho=
rization
> request blob thing.
>
> Or PAR could at least say that if it=E2=80=99s dereferenced over a remote=
 protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That=E2=
=80=99s
> where the real interop concerns come in.
>
>  =E2=80=94 Justin
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> Correct. The problem becomes pretty clear in the context of PAR, where th=
e
> AS is generating and vending out the URI at the PAR endpoint, and consumi=
ng
> it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
> If we assume the client posts a JAR and gets back a reference.  Then the
> reference is to a JAR.
>
> I think I see the problem.  If the server providing the reference is
> associated with the AS then the server dosen't need to dereference the
> object via HTTP, so it could be a URN as an example.
>
> So yes it is not a interoperability issue for the client.
>
> I will think about how I can finesse that.
>
> I agree it is not a change in intent.
>
> I will see if I can get our AD to accept that.
>
> John B.
>
>
>
>
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell 
> wrote:
>
> Sure but the text proposed (or something like it) qualifies it such that
> there aren't interoperability questions because it's only an implementati=
on
> detail to the AS who both produces the URI and consumes its content.
>
> On Fri, Jan 10, 2020 at 12:48 PM John Bradley  wrote:
>
> It may be a challenge to change text saying that the contents of the
> resource could be something other than a request object.
>
> If not a request object then what and how is that interoperable are likel=
y
> AD questions.
>
> I could perhaps see changing it to must be a request object, or other
> format defined by a profile.
>
> John B.
>
>
> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell 
> wrote:
>
> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
> I would assume given the status of JAR, we don=E2=80=99t want to change i=
t. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
>
>
> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org>:
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
> What if we changed this sentence in Section 5.2 of JAR:
> The contents of the resource referenced by the URI MUST be a Request
> Object.
>
> To:
> The contents of the resource referenced by the URI MUST be a Request
> Object, unless the URI was provided to the client by the Authorization
> Server.
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
> =E2=80=93
> Annabelle Richard Backman
> AWS Identity
>
> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>     Hi,
>
>     you are right, PAR does not require the AS to represent the request a=
s
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>     "There is no need to make the
>           authorization request data available to other parties via this
>           URI.=E2=80=9D
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>     best regards,
>     Torsten.
>
>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
>     >
>     > Hi all,
>     >
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>     >         =E2=80=A2 PAR uses the request_uri parameter defined in JAR=
 to
> communicate the pushed request to the authorization endpoint.
>     >         =E2=80=A2 According to JAR, the resource referenced by requ=
est_uri
> MUST be a Request Object. (Section 5.2)
>     >         =E2=80=A2 Request Object is defined to be a JWT containing =
all the
> authorization request parameters. (Section 2.1)
>     >
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications betwee=
n
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced int=
o
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>     >
>     > =E2=80=93
>     > Annabelle Richard Backman
>     > AWS Identity
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf..org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf..org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=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._

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


+1 to keeping/using =E2=80=9Crequest_uri=E2=80=9D 

On T=
hu, Jan 16, 2020 at 10:49 AM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&=
gt; wrote:






We=E2=80=99ve already defined a request identifier parameter. We called it =
=E2=80=9Crequest_uri=E2=80=9D. That=E2=80=99s what the =E2=80=9CI=E2=80=9D =
in URI stands for. Let=E2=80=99s just fix the semantics on that one. It=E2=
=80=99s bad enough that we have request and request_uri, let=E2=80=99s not =
add a third one.




Sent from my iPhone





On Jan 16, 2020, at 9:33 AM, Justin Richer <jricher@mit.edu> =
wrote:










=EF=BB=BF What you=E2=80=99ve described is exactly what ha=
ppens in XYZ:












And this is what we=E2=80=99re discussing as the basis in TxAuth. But =
in this case since you=E2=80=99re stuck with OAuth 2=E2=80=99s authorizatio=
n endpoint syntax and semantics, you=E2=80=99re still limited with what=E2=
=80=99s happening there and it could come with its own security
 oddities (like maybe a new form of a mixup attack?) that we haven=E2=80=99=
t figured out yet. Like, is the AS allowed to send the client to something =
other than its own authorization endpoint? Is the client supposed to valida=
te the syntax of the authorization endpoint
 URL against its discovery document? It deeply changes what OAuth 2 does, a=
nd that makes it really hard to add on.







Using request_uri to pass the artifact is clever, but I also like Tors=
ten=E2=80=99s idea of using a new field defined by PAR to pass the artifact=
. Granted, in the Authlete implementation of PAR, we were able to re-use a =
whole bunch of code for processing
 request objects, and that was pretty nice. Still, the issues with JAR are =
non-zero, and so we need to figure out whether we should fully decouple or =
fix the issues. I=E2=80=99m in favor of fixing things and using these toget=
her, but there=E2=80=99s a lot of inertia against
 that.







=C2=A0=E2=80=94 Justin







On Jan 16, 2020, at 11:36 AM, Neil Madden <neil.madden@forgerock.com> wr=
ote:







Why not have the PAR endpoint return a 30x redirect with the full URL to th=
e authorization endpoint in the Location header? That way the AS can decide=
 for itself how to communicate any id from the PAR endpoint to the authoriz=
ation endpoint.






This also has the side effect that you can kick off an OAuth2 flow wit=
h a simple HTML form pointed at the PAR endpoint (with hidden fields for st=
ate/code_challenge etc).







If actually performing the redirect is a bit problematic then at least=
 the idea of returning a full URL for the authorization endpoint (hyperlink=
) rather than returning an id/URI and requiring the client to construct one=
 seems reasonable to me
 and would seem to avoid some of the difficulties being discussed with JAR =
etc as the exact mechanism of communication becomes an implementation detai=
l that the client needn't know about.







-- Neil







On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=3D40lod=
derstedt.net@dmarc.ietf.org> wrote:








I just thought about another option. What if we change PAR=
 to not use the request_uri parameter but a new parameter, e.g. request_id?=








That would decouple both specs. The reason why we use requ=
est_uri was to make the life of clients easier since they can use the stand=
ard library function for request objects to pass the PAR reference to the A=
S. Is this worth the trouble?





Am 16.01.2020 um 16:48 schrieb Justin Richer <=
jricher@mit.edu>=
;:










=EF=BB=BF+1 to this approach, and it sounds like JAR might=
 need to come back to go through another round anyway thanks to the breakin=
g changes the IESG pushed into it after it left WGLC.






I=E2=80=99d rather see us get this right than publish something many o=
f us think is broken.=C2=A0







Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.






=C2=A0=E2=80=94 Justin







On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <richanna@amazon.com> =
wrote:









The problem is the JWT requirement in JAR, not how we talk about PAR reques=
t_uri values in PAR. We need to either change the language in JAR (see my s=
uggestions elsewhere in this thread), or add text in PAR that explicitly ex=
empts PAR request_uri values (or
 preferably all AS-provided request_uri values) from this requirement (also=
 see my suggestions elsewhere in this thread).



=C2=A0



My preference remains the former. It strikes me as bad form for one extensi=
on to override normative requirements laid out in another document. Granted=
, the incompatibility scenarios introduced by this retcon are edge-case at =
best, but that just raises the question
 of why we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been pu=
blished yet.



=C2=A0





=E2=80=93=C2=A0



Annabelle Richard Backman



AWS Identity





=C2=A0



=C2=A0





From:=C2=A0OAuth <oauth-=
bounces@ietf.org>
 on behalf of Vladimir Dzhuvinov <vla=
dimir@connect2id.com>

Organization:=C2=A0Connect2id Ltd..

Date:=C2=A0Wednesday, January 15, 2020 at 12:34 PM

To:=C2=A0Justin Richer <jricher@mit.edu>

Cc:=C2=A0oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard=
 Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&g=
t;

Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PA=
R: pushed requests must become JWTs







=C2=A0







On 13/01/2020 19:32, Justin Richer wrote:







To be clear, I=E2=80=99m not saying we suggest a particular form, and I agr=
ee that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=
=9D or something of that nature. But if we call the result of PAR =E2=80=9C=
thing X=E2=80=9D and the target of request_uri =E2=80=9Cthing X=E2=80=9D in=
 JAR, then we=E2=80=99re compatible without
 saying what =E2=80=9Cthing X=E2=80=9D needs to be in all cases.=C2=
=A0




Good, we're on the same page then.


How about simply saying that the result of PAR is an URI referencing t=
he pushed authZ request; at the authZ endpoint its processing is completed.=



No need is both clear and abstract enough to not require a form to be =
specified.


=C2=A0







In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D t=
o be formatted as a JWT.






But why?


Both PAR and authZ endpoints belong to the AS, which makes that impl s=
pecific. The URI is the contract, between client and AS.

The AS, if uService based, could choose to implement that as CBOR Web =
Token, or some other verifiable blob, resulting in the same essential funct=
ion, and this isn't affecting the client <-> AS contract in any w=
ay.


=C2=A0







We had a case of similarly unintentional limiting in JAR previously, saying=
 that you had to do an HTTP lookup on the request_uri, but I believe that=
=E2=80=99s been backed off now and made conditional.






That was precisely my point.


Vladimir


=C2=A0


=C2=A0







=C2=A0=E2=80=94 Justin

















On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:





=C2=A0







My suggestion is to abstain from specifying the concrete form of the resour=
ce pointed to by the PAR URI. Regardless of URI type (URN, downloadable htt=
ps URL or something else), and even if the PAR endpoint and the authZ endpo=
int are managed by two different
 entities (microservice or other scenario).



In the Connect2id implementation of PAR the returned URI doesn't point =
to a request object and it doesn't point to a JWT either. It points to =
an internally stored "pre-processed" authZ request, which the aut=
hZ endpoint then picks up to complete the authZ.



Even if we eventually end up in microservice world, or allow the PAR endpoi=
nt to be managed by some external entity, the PAR URI - its interpretation,=
 validation and potentially resource retrieval (JWT or other blob), is an &=
quot;internal contract" on the AS side.
 This doesn't concern the client, and in OAuth 2.0 the role of AS is in=
divisible.



=C2=A0



I see PAR request + authZ request as one logical OAuth 2.0 authZ request: t=
he client submits an authZ request and gets an authZ response at the end. T=
he URI is necessary for the client to proceed from the 1st to the 2nd step.=
 If we manage to frame / word the
 PAR URI in this logical way, without getting stuck in the JAR definition /=
 framing of what the request_uri / object is, it would be great.<=
/u>



=C2=A0



The normative language I think should focus on maintaining the OAuth 2.0 co=
ntract for the entire logical authZ request, together with the basic contra=
cts of 1) JAR and the 2) authZ endpoint.



=C2=A0



Vladimir



=C2=A0





On 10/01/2020 22:55, Justin Richer wrote:







So we could solve this by saying the resulting data object of a PAR is a re=
quest object. Which might also contain a request object internally as well.=
 In that case JAR should back off from saying it=E2=80=99s a JWT and instea=
d say it=E2=80=99s a request object. Or we define
 a new term for this authorization request blob thing.=C2=A0





=C2=A0







Or PAR could at least say that if it=E2=80=99s dereferenced over a remote p=
rotocol then it MUST be a JWT, but otherwise it can be whatever you want. T=
hat=E2=80=99s where the real interop concerns come in.







=C2=A0







=C2=A0=E2=80=94 Justin

















On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:





=C2=A0







Correct. The problem becomes pretty clear in the context of PAR, where the =
AS is generating and vending out the URI at the PAR endpoint, and consuming=
 it at the authorization endpoint. From an interoperability standpoint, it=
=E2=80=99s analogous to the AS vending an
 authorization code at the authorization endpoint and consuming it at the t=
oken endpoint.









=E2=80=93=C2=A0







Annabelle Richard Backman







AWS Identity









=C2=A0







=C2=A0









From:=C2=A0John Bradley <ve7j=
tb@ve7jtb.com>

Date:=C2=A0Friday, January 10, 2020 at 12:29 PM

To:=C2=A0Brian Campbell <bcampbell@pingidentity.com>

Cc:=C2=A0Torsten Lodderstedt <torsten@lodderstedt.net>, Nat Sakimura <nat@sakimura.org>,
 "Richard Backman, Annabelle" <=
richanna@amazon.com>, oauth <oauth@ietf=
.org>

Subject:=C2=A0[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: p=
ushed requests must become JWTs











=C2=A0













If we assume the client posts a JAR and gets back a reference.=C2=A0 Then t=
he reference is to a JAR.=C2=A0











=C2=A0











I think I see the problem.=C2=A0 If the server providing the reference is a=
ssociated with the AS then the server dosen't need to dereference the o=
bject via HTTP, so it could be a URN as an example.=C2=A0










=C2=A0











So yes it is not a interoperability issue for the client.=C2=A0=C2=A0











=C2=A0











I will think about how I can finesse that.=C2=A0











=C2=A0











I agree it is not a change in intent.=C2=A0











=C2=A0











I will see if I can get our AD to accept that.











=C2=A0











John B.=C2=A0











=C2=A0











=C2=A0











=C2=A0











=C2=A0











On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com<=
/a>> wrote:













Sure but the text proposed (or something like it) qualifies it such that th=
ere aren't interoperability questions because it's only an implemen=
tation detail to the AS who both produces the URI and consumes its content.=










=C2=A0
















It may be a challenge to change text saying that the contents of the resour=
ce could be something other than a request object.=C2=A0










=C2=A0











If not a request object then what and how is that interoperable are likely =
AD questions.=C2=A0











=C2=A0











I could perhaps see changing it to must be a request object, or other forma=
t defined by a profile.



John B.=C2=A0=C2=A0











=C2=A0











=C2=A0











On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com<=
/a>> wrote:















Agree and agree. But given that the change suggested by Annabelle has no im=
pact on the client or interoperability, perhaps Nat or John could work the =
change into the draft during the edits that happen during the final stages =
of things?









=C2=A0
















I would assume given the status of JAR, we don=E2=80=99t want to change it.=
 And as I said, this difference does not impact interoperability from clien=
t perspective.

























Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.=
com@dmarc.ietf.org>:















It would be more approp=
riate to add the text to JAR rather than PAR. It doesn't seem right for=
 PAR to retcon rules in JAR. Moving the text to JAR also highlights the wei=
rdness of giving PAR special
 treatment.







=C2=A0







What if we changed this=
 sentence in Section 5.2 of JAR:





The conte=
nts of the resource referenced by the URI MUST be a Request



Object.





=C2=A0







To:=C2=A0<=
u>





The conte=
nts of the resource referenced by the URI MUST be a Request



Object, u=
nless the URI was provided to the client by the Authorization



Server.





=C2=A0







This would allow for us=
e cases such as an AS that provides pre-defined request URIs, or vends requ=
est URIs via a client management console, or bakes them into their client a=
pps.







=C2=A0







=E2=80=93=C2=A0







Annabelle Richard Backm=
an







AWS Identity<=
/u>







=C2=A0







On 1/8/20, 2:50 PM, &qu=
ot;Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org>
 wrote:







=C2=A0







=C2=A0=C2=A0=C2=A0 Hi,<=
span>=C2=A0







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







=C2=A0=C2=A0=C2=A0=C2=
=A0you are right, PAR does not require the AS to represent the request as a=
 JWT-based request object. The URI is used as internal reference only. That=
 why the draft states







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







=C2=A0=C2=A0=C2=A0=C2=
=A0"There is no need to make the







=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization request data available to o=
ther parties via this







=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI.=E2=80=9D







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







=C2=A0=C2=A0=C2=A0=C2=
=A0This difference matters from an AS implementation perspective, it doesn&=
#39;t matter from a client's (interop) perspective.







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







=C2=A0=C2=A0=C2=A0=C2=
=A0We may add a statement to PAR saying that request_uris issued by the PAR=
 mechanism (MAY) deviate from the JAR definition.






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







=C2=A0=C2=A0=C2=A0=C2=
=A0best regards,







=C2=A0=C2=A0=C2=A0 Tors=
ten.=C2=A0=C2=A0







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







=C2=A0=C2=A0=C2=A0=C2=
=A0> On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=
=3D40am=
azon.com@dmarc.ietf.org>
 wrote:







=C2=A0=C2=A0=C2=A0 >=
=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> Hi all,







=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> The current drafts of PAR (-00) and JAR (-20) require that the AS t=
ransform all pushed requests into JWTs. This requirement arises from the fo=
llowing:







=C2=A0=C2=A0=C2=A0 >=
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 PAR uses the request_=
uri parameter defined in JAR to communicate the pushed request to the autho=
rization endpoint.







=C2=A0=C2=A0=C2=A0 >=
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 According to JAR, the=
 resource referenced by request_uri MUST be a Request Object. (Section 5.2)=








=C2=A0=C2=A0=C2=A0 >=
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A2 Request Object is def=
ined to be a JWT containing all the authorization request parameters. (Sect=
ion 2.1)







=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> There is no need for this requirement to support interoperability, =
as this is internal to the AS. It is also inconsistent with the rest of JAR=
, which avoids attempting to define the internal
 communications between the two AS endpoints. Worse, this restriction makes=
 it harder for the authorization endpoint to leverage validation and other =
work performed at the PAR endpoint, as the state or outcome of that work mu=
st be forced into the JWT format
 (or retrieved via a subsequent service call or database lookup).=








=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> =E2=80=93=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> Annabelle Richard Backman







=C2=A0=C2=A0=C2=A0 >=
 AWS Identity







=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0







=C2=A0=C2=A0=C2=A0=C2=
=A0> _______________________________________________







=C2=A0=C2=A0=C2=A0 >=
 OAuth mailing list







=C2=A0=C2=A0=C2=A0 >=
=C2=A0O=
Auth@ietf..org







=C2=A0=C2=A0=C2=A0 >=
=C2=A0https://www.ietf.org/mailman/listinfo/oauth=








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







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















_______________________________________________

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, d=
istribution
 or disclosure by others is strictly prohibited.=C2=A0 If you have received=
 this communication in error, please notify the sender immediately by e-mai=
l and delete the message and any file attachments from your computer. Thank=
 you.





















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









_______________________=
________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailma=
n/listinfo/oauth









=C2=A0












_______________________________________________


OAuth mailing list


OAuth@ietf..org<=
/pre>

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




-- 


Vladimir Dzhuvinov











=C2=A0






-- 


Vladimir Dzhuvinov













_______________________________________________

OAuth mailing list

OAuth@ietf.org

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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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
































_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






<=
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.
--0000000000009c5fe1059c5b382d--


From nobody Fri Jan 17 12: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 AD8AE1200EC for ; Fri, 17 Jan 2020 12:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 C49Mn0lUaYxZ for ; Fri, 17 Jan 2020 12:17:30 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450: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 CC8191200E3 for ; Fri, 17 Jan 2020 12:17:29 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id i23so19281661lfo.7 for ; Fri, 17 Jan 2020 12:17:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6INXlA6tRr+HBoa3Ts9ljEscr58ZdIbWMDeANmcYKO4=; b=fvex+On5CxK5AcOoff2M6BrUGeXGgZ0hG3iS7pT2w9LE8/StAigOq9hLxVOynVji3Z UQyuikOzkimPEF0ftBAb6Dm8tNcxmOkvDtOS4fpJzAyL9xFH1W746nYSDieOBXzdQ8N7 vgC8lkeC0G/K+e+CjOJUFqwDAQ363E05vIG+uCPY+W2v24aoNCirHi37kerCWY30KLUt 3XgrrJFidEkv4vwqCN40OkG1ltKPkjDDNiWC/5Qhw7epT+fbW698FIf/RDyoQWA87xdV lnbrCrqVUp0LB8+5+eUxfXggKPM6VtITjK8XD7lZoxtml4+Ez2+hfnntRSCpD6N7p4D3 VfqA==
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=6INXlA6tRr+HBoa3Ts9ljEscr58ZdIbWMDeANmcYKO4=; b=cTJGbKy3btGE5uB7vTrG6SXDxvTCVoxSaCxc8/wPIH9z/5ogb6opfDd/asFa3AmO0q qk7B8b/tugwF9037Wj0MSJqs2SPuZCMQE6ylmN0dimAtXhfHYdQLxxtoYYBMMioPfxgE sN4vlvSDUVACU5eboD/0nKBh+hkP61tWNYRq2notqnqfe61Gsg36YRNcBdqnvbBIIAL2 LGb8hd3mp20/0X4b5D2/+wTKZlHR3kLCQw3rgnZDV6wOSkNZH02K0w27hPXvq/YcclWS CQRMOwEWdWG55LzkoAdZuRZLb/zYetoxU5FYFrtuC0KlqtMRinnMWgE4Xct49X2J+fli Wblw==
X-Gm-Message-State: APjAAAU5aZlRcPsk4f8xwfqtRb1tyi1NzzOF/xcGTxgWKR5hZ+QTNsiF /yYKALAzvwAWaVTacq0PNGT5WPPlztyJRMCrx4h8BdPwzngS5LDMbsPEzr2//PSpqehs7m51IQ4 uhGYSfpiDp5Qo2A==
X-Google-Smtp-Source: APXvYqyP7Wk7VmRQ6OUvOu7L+hdLjoymPWQm5MXW+dPmX7wCkxq8Z4AO0xGEzJybjBXaJDEylgEq0YFovjruolumPqg=
X-Received: by 2002:ac2:4988:: with SMTP id f8mr3954830lfl.210.1579292247887;  Fri, 17 Jan 2020 12:17:27 -0800 (PST)
MIME-Version: 1.0
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <2E514281-F4A5-48B1-940E-62315F46F6DB@forgerock.com>
In-Reply-To: <2E514281-F4A5-48B1-940E-62315F46F6DB@forgerock.com>
From: Brian Campbell 
Date: Fri, 17 Jan 2020 13:17:01 -0700
Message-ID: 
To: Neil Madden 
Cc: John Bradley , oauth 
Content-Type: multipart/alternative; boundary="0000000000006eb17e059c5ba1cd"
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 17 Jan 2020 20:17:34 -0000

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

I'd support this (client_id being the only additional query parameter
allowed/required) as well.

FWIW, our AS implementations looks for and requires that the response_type
and client_id parameters be present as regular request parameters. This was
done largely to maintain some semblance of compatibility/compliance to
Connect. But client_id is the only one that's helpful.

I also agree with the IESG and others that merging is problematic. I've
personally never believed there was enough real world utility in the merge
approach to justify the added complexity in policy and implementation
and/or reduced security as a result.



On Thu, Jan 16, 2020 at 7:01 AM Neil Madden 
wrote:

> I believe just client_id would be sufficient for us, so I'd support a
> compromise position in which that is the only additional query parameter
> allowed.
>
> -- Neil
>
> > On 16 Jan 2020, at 13:40, John Bradley  wrote:
> >
> > I agree with the IESG reasoning that merging is problimatic.  Once we
> > allow that given a unknown list of possible paramaters with diffrent
> > security properties it would be quite difficult to specify safely.
> >
> > Query paramaters can still be sent outside the JAR, but if they are in
> > the OAuth registry the AS MUST ignore them.
> >
> > Puting the iss in the JWE headder addresses the encryption issue withou=
t
> > merging.
> >
> > I understand that some existing servers have dependencys on getting the
> > clientID as a query paramater.
> >
> > Is that the only paramater that people have a issue with as oposed to a
> > nice to have?
> >
> > Would allowing the AS to not ignore the clientID as a query paramater a=
s
> > long as it matches the one inside the JAR, basicly the same as Connect
> > request object but for just the one paramater make life easier for the
> > servers?
> >
> > I am not promising a change but gathering info before proposing
> something.
> >
> > John B.
> >
> >
> > On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> >> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> >>>> Well, embedding a client_id claim in the JWE header in order to
> >>>> achieve "request parameters outside the request object should not be
> >>>> referred to" is like "putting the cart before the horse". Why do we
> >>>> have to avoid using the traditional client_id request parameter so
> >>>> stubbornly?
> >>>>
> >>>> The last paragraph of Section 3.2.1
> >>>>  of RFC 6749 says
> >>>> as follows.
> >>>>
> >>>>    /A client MAY use the "client_id" request parameter to identify
> >>>>    itself when sending requests to the token endpoint.  In the
> >>>>    "authorization_code" "grant_type" request to the token endpoint,
> >>>>    *an unauthenticated client MUST send its "client_id" to prevent
> >>>>    itself from inadvertently accepting a code intended for a client
> >>>>    with a different "client_id".*  This protects the client from
> >>>>    substitution of the authentication code.  (It provides no
> >>>>    additional security for the protected resource.)/
> >>>>
> >>>>
> >>>> If the same reasoning applies, a client_id must always be sent with
> >>>> request / request_uri because client authentication is not performed
> >>>> at the authorization endpoint. In other words, */an unauthenticated
> >>>> client (every client is unauthenticated at the authorization endpoin=
t)
> >>>> MUST send its "client_id" to prevent itself from inadvertently
> >>>> accepting a request object for a client with a different
> "client_id"./*
> >>>>
> >>> Identifying the client in JAR request_uri requests can be really usef=
ul
> >>> so that an AS which requires request_uri registration to prevent DDoS
> >>> attacks and other checks can do those without having to index all
> >>> request_uris individually. I mentioned this before.
> >>>
> >>> I really wonder what the reasoning of the IESG reviewers was to insis=
t
> >>> on no params outside the JAR JWT / request_uri.
> >>>
> >>> I'm beginning to realise this step of the review process isn't
> >>> particularly transparent to WG members.
> >> Could you expand on that a bit more?  My understanding is that the IES=
G
> >> ballot mail gets copied to the WG precisely so that there is
> transparency,
> >> e.g., the thread starting at
> >> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0Jwg=
I
> >> Which admittely is from almost three years ago, but that's the earlies=
t
> >> that I found that could be seen as the source of this behavior.
> >>
> >> -Ben
> >>
> >> P.S. some other discussion at
> >> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy=
8
> and
> >> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_Uw=
Y
> and
> >> so on.
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing 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._

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


I'd support this (client_id being the only additi=
onal query parameter allowed/required) as well.

FW=
IW, our AS implementations looks for and requires that the response_type an=
d client_id parameters be present as regular request parameters. This was d=
one largely to maintain some semblance of compatibility/compliance to Conne=
ct. But client_id is the only one that's helpful.

<=
div>I also agree with the IESG and others that merging is problematic. I=
9;ve personally never believed there was enough real world utility in the m=
erge approach to justify the added complexity in policy and implementation =
and/or reduced security as a result.



On =
Thu, Jan 16, 2020 at 7:01 AM Neil Madden <neil.madden@forgerock.com> wrote:
I believe just client_id would be s=
ufficient for us, so I'd support a compromise position in which that is=
 the only additional query parameter allowed.



-- Neil



> On 16 Jan 2020, at 13:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

> 

> I agree with the IESG reasoning that merging is problimatic.=C2=A0 Onc=
e we

> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.

> 

> Query paramaters can still be sent outside the JAR, but if they are in=


> the OAuth registry the AS MUST ignore them.

> 

> Puting the iss in the JWE headder addresses the encryption issue witho=
ut

> merging.

> 

> I understand that some existing servers have dependencys on getting th=
e

> clientID as a query paramater.

> 

> Is that the only paramater that people have a issue with as oposed to =
a

> nice to have?

> 

> Would allowing the AS to not ignore the clientID as a query paramater =
as

> long as it matches the one inside the JAR, basicly the same as Connect=


> request object but for just the one paramater make life easier for the=


> servers?

> 

> I am not promising a change but gathering info before proposing someth=
ing.

> 

> John B.

> 

> 

> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:

>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote=
:

>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:

>>>> Well, embedding a client_id claim in the JWE header in ord=
er to

>>>> achieve "request parameters outside the request objec=
t should not be

>>>> referred to" is like "putting the cart before th=
e horse". Why do we

>>>> have to avoid using the traditional client_id request para=
meter so

>>>> stubbornly?

>>>> 

>>>> The last paragraph of Section 3.2.1

>>>> <https://tools.ietf.org/html/rf=
c6749#section-3.2.1> of RFC 6749 says

>>>> as follows.

>>>> 

>>>>=C2=A0 =C2=A0 /A client MAY use the "client_id" r=
equest parameter to identify

>>>>=C2=A0 =C2=A0 itself when sending requests to the token end=
point.=C2=A0 In the

>>>>=C2=A0 =C2=A0 "authorization_code" "grant_ty=
pe" request to the token endpoint,

>>>>=C2=A0 =C2=A0 *an unauthenticated client MUST send its &quo=
t;client_id" to prevent

>>>>=C2=A0 =C2=A0 itself from inadvertently accepting a code in=
tended for a client

>>>>=C2=A0 =C2=A0 with a different "client_id".*=C2=
=A0 This protects the client from

>>>>=C2=A0 =C2=A0 substitution of the authentication code.=C2=
=A0 (It provides no

>>>>=C2=A0 =C2=A0 additional security for the protected resourc=
e.)/

>>>> 

>>>> 

>>>> If the same reasoning applies, a client_id must always be =
sent with

>>>> request / request_uri because client authentication is not=
 performed

>>>> at the authorization endpoint. In other words, */an unauth=
enticated

>>>> client (every client is unauthenticated at the authorizati=
on endpoint)

>>>> MUST send its "client_id" to prevent itself from=
 inadvertently

>>>> accepting a request object for a client with a different &=
quot;client_id"./*

>>>> 

>>> Identifying the client in JAR request_uri requests can be real=
ly useful

>>> so that an AS which requires request_uri registration to preve=
nt DDoS

>>> attacks and other checks can do those without having to index =
all

>>> request_uris individually. I mentioned this before.

>>> 

>>> I really wonder what the reasoning of the IESG reviewers was t=
o insist

>>> on no params outside the JAR JWT / request_uri.

>>> 

>>> I'm beginning to realise this step of the review process i=
sn't

>>> particularly transparent to WG members.

>> Could you expand on that a bit more?=C2=A0 My understanding is tha=
t the IESG

>> ballot mail gets copied to the WG precisely so that there is trans=
parency,

>> e.g., the thread starting at

>> https://mailarchive.=
ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI

>> Which admittely is from almost three years ago, but that's the=
 earliest

>> that I found that could be seen as the source of this behavior.
>> 

>> -Ben

>> 

>> P.S. some other discussion at

>> https://mailarchive.=
ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and

>> https://mailarchive.=
ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and

>> so on.

>> 

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=


>> https://www.ietf.org/mailman/listinfo/oauth<=
br>
> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






<=
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.
--0000000000006eb17e059c5ba1cd--


From nobody Fri Jan 17 12:21: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 2BBEB120846 for ; Fri, 17 Jan 2020 12:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 EeotX-57nPg9 for ; Fri, 17 Jan 2020 12:21:50 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E20F120861 for ; Fri, 17 Jan 2020 12:21:49 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id l2so27673017lja.6 for ; Fri, 17 Jan 2020 12:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x9KMKlPV1bZN2KBH3QMYfITnj/dkCbPluYE5My/AINs=; b=A2IWvLOH45pvqNzzPAmNUsLGKA5CX9ezjurOr42QKg0I4j3tGTAPa3DnwQi9Eeq1RD vWtr1HxSnBlV5mAfx2z8fgyGOYTM2C5oQnKc7I66paUuMBhLUb1iebkZq8PTCuULI7Mx a9c0LogCN+tnfKTwfoocbO+xK/k0vkuBoRM+rWysqt4RvfY9g4vMuKq+L1TvV3bkn957 gld0O1zlnugv2NNPRYYBnrFu06kS3E0xxPBHimKUkehXHotafNHbi7HC4tnIx4iSqU+k WwxYckKjEIJ2lvkIZ9H9cAJ3T0mu969tGMJs7A0+2+IDgLGylns7pfWJcmZH4Uq0SG4I Q4Ig==
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=x9KMKlPV1bZN2KBH3QMYfITnj/dkCbPluYE5My/AINs=; b=L2sirN5tjQrddVxQAgSgsudeHnIWVniOHZX1xCI7hgUbGh+OyL32vDCGMeRo0+wO3v MrHIL7MNd95XGbV3Ki0YWhpsEYMP/9aMOD+bMBObKKdaPuLrjAdWL2ErsJJJmwNl8WGP PbiUdekHpHW+WuSwJD5qNNHeK9YnrNwPQPnc7fV64MKC30xQA95t63jpGYpCvCcyXc4t uD3kn19+aRvOrP5/8E/LechNM+JgyZq+0LTOplVbVr9tF1rMHUyCkU5zQWYD09lbmqAj 7Ij7soLXH5y0JtMulPCUn0aTezBfOh07jxadIaykcvwKQn7rMRAdVZKSb2QBipTHY0eD KCZA==
X-Gm-Message-State: APjAAAWMR7TS+EUuOeUyF4EAH0gQ86bW+g6uus4ndezbBncT1xPPkW24 R/TOFpIxgmOHondsy/3aQq1dHqsmmS5I1w/KFHzMY8UvzqmMeKzyLCP8vpW+oCBx3GKBTjJAKY2 Tpam07LRRHwu4kg==
X-Google-Smtp-Source: APXvYqzcy2smcYYb0TaTs9Uu2pwX0HSKE0VuinSAQKpEUcqItwL+3o9c0AMAk3gJcSwe8V0HG5Rcawy0bbGWqpJY8yw=
X-Received: by 2002:a2e:88d6:: with SMTP id a22mr6223762ljk.163.1579292507937;  Fri, 17 Jan 2020 12:21:47 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <40E68FE9-BEA6-4F44-8401-BD30E6F7C927@lodderstedt.net>
In-Reply-To: <40E68FE9-BEA6-4F44-8401-BD30E6F7C927@lodderstedt.net>
From: Brian Campbell 
Date: Fri, 17 Jan 2020 13:21:21 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: Justin Richer , oauth , Nat Sakimura ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="000000000000eeb8b0059c5bb006"
Archived-At: 
Subject: Re: [OAUTH-WG] JARM
X-BeenThere: oauth@ietf.org
X-Mailman-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, 17 Jan 2020 20:21:54 -0000

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

I'd be in favor of it.

On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt  wrote:

>
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>
> Since Justin brought it up, I would like to know whether the community ha=
s
> appetite to standardize JARM as well.
>
> Here is the link to the spec:
> https://openid.net/specs/openid-financial-api-jarm-ID1.html
>
> What do you think?
> _______________________________________________
> 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._

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


I'd be in favor of it. 

=

On Thu, Ja=
n 16, 2020 at 9:28 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> w=
rote:


Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

Maybe PAR and =
JAR (and JARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would like to know wh=
ether the community has appetite to standardize JARM as well.

What do you think?
____________________________________________=
___

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.
--000000000000eeb8b0059c5bb006--


From nobody Fri Jan 17 16:17: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 AC03B120091 for ; Fri, 17 Jan 2020 16:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 xh4Y9_UTzbzN for ; Fri, 17 Jan 2020 16:17:35 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF59A12006B for ; Fri, 17 Jan 2020 16:17:34 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id kx11so3856993pjb.4 for ; Fri, 17 Jan 2020 16:17:34 -0800 (PST)
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=9Ys2xdJykR81hA/kS9ZiENcLJo3RAooyB2kclhe+Fbw=; b=ve6cseXnwKlqFZHVLNPMxQiXMZmInPpT7bVDBB9IOc4sIRlqqu1kg/LtEaGQolgGRh GjVIEIQbE0tzHUUa1AbCXBcApMwGn56l5B5hSVEy1WNoY9ms0p7Xu50f3Jx2bK1pR+T2 1MsjtN6GuUs8joOvEYJtzAoFqi1y3kMoTvlVKF1dnvAwCsGwIwXdywfBwMeP+ydiPnnc kLJxp3bz7pxjizjTjBeLE+DvDk2oyzWqtrqust8S+gcmXZxISFQVZ2MHPqLR2kmHxY5l w3ajFtNSmTSqosjJ5vV84ylg04Dulc3vk9AKw4fLbPUbawKSji4OzAvAGsjYse3/3kkQ mk1Q==
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=9Ys2xdJykR81hA/kS9ZiENcLJo3RAooyB2kclhe+Fbw=; b=gZow5t6Pgs4x6qrg78Sen/RIK2xnC81EYqKOTh35GGXPV6aZJn/Jan8BIn2Rq0Oo1D Ke9WsCDkSFQZjq8+wPmG8QyOzC5Wr0any9RdydGfrigkcp+/DRzZMKgBVG42sPfvzh4E jemkqFLrOasdGR8OQTTNFDCQrtM0H0qjsFoDWS1HcgdHGtcFsvXcDtwhyMkj2L2K/98/ ZNpJszJL+VqULNdpx2fJmisIbjrAasJIg+mP/uh+Jm2jchZrDBq4oMzOVKhZtEwSEWVp 4OG2idkkLWikpyIm2qF8BFhflt2/lH9Gx55f/Bf/Hul3ujKZqGaDf8oBLZ/uHij14qvt 0w6g==
X-Gm-Message-State: APjAAAUchAz6LAyL/KHZzvc1dRGqkvLcxzc2sq4wblHSRy98T9yJyBGC mRU4GoCdXr0e9Mdb4TgW96mz+A8aY6g=
X-Google-Smtp-Source: APXvYqxSYhg1wOpuuBpiLlbYrrVpa1n5OfMcL59JPZ6VhKZ2Le+nY/CcwkMlmPG1o/FQv1O1LdNmFw==
X-Received: by 2002:a17:90b:145:: with SMTP id em5mr8816146pjb.20.1579306654246;  Fri, 17 Jan 2020 16:17:34 -0800 (PST)
Received: from [192.168.128.107] (ai126198173235.60.access-internet.ne.jp. [126.198.173.235]) by smtp.gmail.com with ESMTPSA id p17sm29838015pfn.31.2020.01.17.16.17.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jan 2020 16:17:33 -0800 (PST)
From: Joseph Heenan 
Message-Id: <5BC51C13-B001-464E-A7BF-6F43D754889F@authlete.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7933E829-BEAD-4DE4-B96D-E67AD9FD7C0A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 18 Jan 2020 09:17:30 +0900
In-Reply-To: 
Cc: Justin Richer , oauth 
To: "Richard Backman, Annabelle" 
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>  
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 18 Jan 2020 00:17:38 -0000

--Apple-Mail=_7933E829-BEAD-4DE4-B96D-E67AD9FD7C0A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In my opinion it's still problematic if an attacker can inject claims =
that aren't in the request object.

A simple (albeit OIDC specific) example would injecting prompt=3Dnone or =
a login_hint, where the request object doesn't have a prompt/login_hint =
already. In that case if/when people design protocol extensions they =
have to consider in each case what will happen if a client doesn't =
specify it (and hence the attacker can inject it) rather than being sure =
that the values they get will always be genuinely sent by the client if =
the client is using JAR. (I=E2=80=99m not clear if injecting =
prompt/login_hint can actually be formed into a useful attack, but I=E2=80=
=99d don=E2=80=99t think that justifies leaving the whole vector open.)

If there=E2=80=99s really a case for having parameters outside the =
signed object, it feels like the signed object should explicitly list =
which unsigned parameters it allows to be used with it. That would mean =
existing OIDC clients aren=E2=80=99t compatible with JAR. I=E2=80=99m =
not sure the extra complexity is justified.

I think it=E2=80=99s also arguable that if using PAR the case for =
ignoring all parameters that are outside the request object is even =
stronger. We quickly give up some of the easy security gains of PAR if =
we allow it, and whilst I concede there may be some sensible use cases =
for pre-signed objects mixed with unsigned parameters (Justin mentioned =
one of combining a pre-signed request object containing =
scope/client_id/redirect_uri with unsigned nonce/state/code_challenge) =
I=E2=80=99m not sure there=E2=80=99s any reason to do this when using =
PAR.

Joseph


> On 18 Jan 2020, at 01:24, Richard Backman, Annabelle =
 wrote:
>=20
> +1 to Justin=E2=80=99s comments. =46rom a security standpoint =
parameters in the query  string are no different from those in JWT =
unprotected headers (or protected if they=E2=80=99re also in the request =
object). Although I=E2=80=98d amend Justin=E2=80=99s suggestion to say =
that if a parameter is both inside the request object and outside and =
they do not match, reject the request as suspicious.
>=20
>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>>=20
>> =EF=BB=BF I don=E2=80=99t agree with this stance from a security or =
implementation perspective.=20
>>=20
>> If there=E2=80=99s a clear order of precedence for the information, =
it=E2=80=99s not particularly problematic. Everything inside the request =
object is to be taken over things outside the request object. We have =
the exact same semantics and process with dynamic registration, where =
the software statement is carried alongside plain JSON claims, and the =
two are mixed with a very simple algorithm:
>>=20
>>  - If a field is inside the signed payload, use that value and ignore =
any copy of it on the outside
>>  - If a field is not inside the signed payload and is outside the =
signed payload, use the outside value
>>=20
>> Can someone please point out a concrete security issue with this =
algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics =
that we need here, and it would solve not only the ability to use this =
for use cases that call for a more static request object (perhaps signed =
by a third party and not the client) along side the plain parameters =
that can vary, but also the backwards compatibility issue that=E2=80=99s =
been discussed. With this algorithm in place, you could have OIDC =
clients actually be compliant with the spec, since OIDC requires =
replication of the values inside the request object on the outside with =
exact matches. An OIDC server wouldn=E2=80=99t be fully compliant with =
the new spec since it would reject some compliant JAR requests that are =
missing the external parameters, but that=E2=80=99s fairly easy logic to =
add on the OIDC side. And in that case you get a matrix of compatibility =
like:
>>=20
>>=20
>>               JAR Server | OIDC Server  |
>> ------------+------------+--------------+
>> JAR Client  |     YES    |      NO      |
>> OIDC Client |     YES    |     YES      |
>>=20
>> Breaking one out of the four possible combinations in a very =
predictable way is, I think, the best way to handle backwards =
compatibility here.=20
>>=20
>> But between this issue and JAR=E2=80=99s problematic call for the =
value of a request_uri to always be a JWT and be fetchable by the AS =
(neither of which are true in the case of PAR) makes me think we need to =
pull this back and rework those things, in a push back to the IESG=E2=80=99=
s comments.
>>=20
>>  =E2=80=94 Justin
>>=20
>>=20
>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan > wrote:
>>>=20
>>> I agree with this, particularly the security concerns of merging. If =
we merge, we can much guarantee there will eventually be a security =
issue where an attacker is able to gain an advantage by adding a =
parameter to the url query (which the server would then happily process =
if that parameter isn=E2=80=99t found inside the request object). Ruling =
out that case makes security analysis (particularly when creating new =
OAuth2 parameters) significantly simpler.
>>>=20
>>> Putting the iss in the JWE header and having the client_id =
duplicated outside the request object seem to address all the concerns =
I=E2=80=99ve seen raised.
>>>=20
>>> (It seems like it may be unnecessary to have the client_id =
duplicated outside if the request_uri is a PAR one though.)
>>>=20
>>> Joseph
>>>=20
>>>=20
>>>=20
>>>> On 16 Jan 2020, at 22:40, John Bradley > wrote:
>>>>=20
>>>> I agree with the IESG reasoning that merging is problimatic.  Once =
we
>>>> allow that given a unknown list of possible paramaters with =
diffrent
>>>> security properties it would be quite difficult to specify safely.
>>>>=20
>>>> Query paramaters can still be sent outside the JAR, but if they are =
in
>>>> the OAuth registry the AS MUST ignore them.
>>>>=20
>>>> Puting the iss in the JWE headder addresses the encryption issue =
without
>>>> merging.
>>>>=20
>>>> I understand that some existing servers have dependencys on getting =
the
>>>> clientID as a query paramater.
>>>>=20
>>>> Is that the only paramater that people have a issue with as oposed =
to a
>>>> nice to have?
>>>>=20
>>>> Would allowing the AS to not ignore the clientID as a query =
paramater as
>>>> long as it matches the one inside the JAR, basicly the same as =
Connect
>>>> request object but for just the one paramater make life easier for =
the
>>>> servers?
>>>>=20
>>>> I am not promising a change but gathering info before proposing =
something.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>>>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov =
wrote:
>>>>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>>>>> Well, embedding a client_id claim in the JWE header in order to
>>>>>>> achieve "request parameters outside the request object should =
not be
>>>>>>> referred to" is like "putting the cart before the horse". Why do =
we
>>>>>>> have to avoid using the traditional client_id request parameter =
so
>>>>>>> stubbornly?
>>>>>>>=20
>>>>>>> The last paragraph of Section 3.2.1
>>>>>>> > of RFC 6749 says
>>>>>>> as follows.
>>>>>>>=20
>>>>>>>   /A client MAY use the "client_id" request parameter to =
identify
>>>>>>>   itself when sending requests to the token endpoint.  In the
>>>>>>>   "authorization_code" "grant_type" request to the token =
endpoint,
>>>>>>>   *an unauthenticated client MUST send its "client_id" to =
prevent
>>>>>>>   itself from inadvertently accepting a code intended for a =
client
>>>>>>>   with a different "client_id".*  This protects the client from
>>>>>>>   substitution of the authentication code.  (It provides no
>>>>>>>   additional security for the protected resource.)/
>>>>>>>=20
>>>>>>>=20
>>>>>>> If the same reasoning applies, a client_id must always be sent =
with
>>>>>>> request / request_uri because client authentication is not =
performed
>>>>>>> at the authorization endpoint. In other words, */an =
unauthenticated
>>>>>>> client (every client is unauthenticated at the authorization =
endpoint)
>>>>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>>>>> accepting a request object for a client with a different =
"client_id"./*
>>>>>>>=20
>>>>>> Identifying the client in JAR request_uri requests can be really =
useful
>>>>>> so that an AS which requires request_uri registration to prevent =
DDoS
>>>>>> attacks and other checks can do those without having to index all
>>>>>> request_uris individually. I mentioned this before.
>>>>>>=20
>>>>>> I really wonder what the reasoning of the IESG reviewers was to =
insist
>>>>>> on no params outside the JAR JWT / request_uri.
>>>>>>=20
>>>>>> I'm beginning to realise this step of the review process isn't
>>>>>> particularly transparent to WG members.
>>>>> Could you expand on that a bit more?  My understanding is that the =
IESG
>>>>> ballot mail gets copied to the WG precisely so that there is =
transparency,
>>>>> e.g., the thread starting at
>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI =

>>>>> Which admittely is from almost three years ago, but that's the =
earliest
>>>>> that I found that could be seen as the source of this behavior.
>>>>>=20
>>>>> -Ben
>>>>>=20
>>>>> P.S. some other discussion at
>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 =
and
>>>>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY =
and
>>>>> so on.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_7933E829-BEAD-4DE4-B96D-E67AD9FD7C0A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In =
my opinion it's still problematic if an attacker can inject claims that =
aren't in the request object.

A simple (albeit OIDC specific) example would injecting =
prompt=3Dnone or a login_hint, where the request object doesn't have a =
prompt/login_hint already. In that case if/when people design protocol =
extensions they have to consider in each case what will happen if a =
client doesn't specify it (and hence the attacker can inject it) rather =
than being sure that the values they get will always be genuinely sent =
by the client if the client is using JAR. (I=E2=80=99m not clear if =
injecting prompt/login_hint can actually be formed into a useful attack, =
but I=E2=80=99d don=E2=80=99t think that justifies leaving the whole =
vector open.)

If =
there=E2=80=99s really a case for having parameters outside the signed =
object, it feels like the signed object should explicitly list which =
unsigned parameters it allows to be used with it. That would mean =
existing OIDC clients aren=E2=80=99t compatible with JAR. I=E2=80=99m =
not sure the extra complexity is justified.

I think it=E2=80=99s also arguable that =
if using PAR the case for ignoring all parameters that are outside the =
request object is even stronger. We quickly give up some of the easy =
security gains of PAR if we allow it, and whilst I concede there may be =
some sensible use cases for pre-signed objects mixed with unsigned =
parameters (Justin mentioned one of combining a pre-signed request =
object containing scope/client_id/redirect_uri with unsigned =
nonce/state/code_challenge) I=E2=80=99m not sure there=E2=80=99s any =
reason to do this when using PAR.

Joseph


On 18 Jan 2020, at 01:24, Richard Backman, Annabelle <richanna@amazon.com>=
 wrote:








+1 to Justin=E2=80=99s comments. =46rom a =
security standpoint parameters in the query  string are no =
different from those in JWT unprotected headers (or protected if =
they=E2=80=99re also in the request object). Although I=E2=80=98d amend =
Justin=E2=80=99s suggestion to say that
 if a parameter is both inside the request object and outside and they =
do not match, reject the request as suspicious.










On Jan 17, 2020, at 5:45 AM, Justin =
Richer <jricher@mit.edu> wrote:










=EF=BB=BF I don=E2=80=99t agree with this =
stance from a security or implementation perspective. 






If there=E2=80=99s a clear order of precedence for the =
information, it=E2=80=99s not particularly problematic. Everything =
inside the request object is to be taken over things outside the request =
object. We have the exact same semantics and process with dynamic
 registration, where the software statement is carried alongside plain =
JSON claims, and the two are mixed with a very simple algorithm:







 - If a field is inside the signed payload, use =
that value and ignore any copy of it on the outside


 - If a field is not inside the signed payload and =
is outside the signed payload, use the outside value







Can someone please point out a concrete security issue =
with this algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D =
semantics that we need here, and it would solve not only the ability to =
use this for use cases that call for a more static request object
 (perhaps signed by a third party and not the client) along side the =
plain parameters that can vary, but also the backwards compatibility =
issue that=E2=80=99s been discussed. With this algorithm in place, you =
could have OIDC clients actually be compliant with the spec,
 since OIDC requires replication of the values inside the request object =
on the outside with exact matches. An OIDC server wouldn=E2=80=99t be =
fully compliant with the new spec since it would reject some compliant =
JAR requests that are missing the external parameters,
 but that=E2=80=99s fairly easy logic to add on the OIDC side. And in =
that case you get a matrix of compatibility like:














              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |     =
 NO      |
OIDC Client |    =
 YES    |     YES      |









Breaking one out of the four possible combinations in a =
very predictable way is, I think, the best way to handle backwards =
compatibility here. 







But between this issue and JAR=E2=80=99s problematic =
call for the value of a request_uri to always be a JWT and be fetchable =
by the AS (neither of which are true in the case of PAR) makes me think =
we need to pull this back and rework those things, in
 a push back to the IESG=E2=80=99s comments.







 =E2=80=94 Justin














On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com>=
 wrote:






I agree with this, particularly the security concerns of =
merging. If we merge, we can much guarantee there will eventually be a =
security issue where an attacker is able to gain an advantage by adding =
a parameter to the url query (which the server
 would then happily process if that parameter isn=E2=80=99t found inside =
the request object). Ruling out that case makes security analysis =
(particularly when creating new OAuth2 parameters) significantly =
simpler.



Putting the iss in the JWE header and having the client_id duplicated =
outside the request object seem to address all the concerns I=E2=80=99ve =
seen raised.



(It seems like it may be unnecessary to have the client_id duplicated =
outside if the request_uri is a PAR one though.)



Joseph








On 16 Jan 2020, at 22:40, John =
Bradley <ve7jtb@ve7jtb.com> wrote:



I agree with the IESG reasoning that merging is problimatic.  Once =
we

allow that given a unknown list of possible paramaters with diffrent

security properties it would be quite difficult to specify safely.



Query paramaters can still be sent outside the JAR, but if they are =
in

the OAuth registry the AS MUST ignore them.



Puting the iss in the JWE headder addresses the encryption issue =
without

merging.



I understand that some existing servers have dependencys on getting =
the

clientID as a query paramater.



Is that the only paramater that people have a issue with as oposed to =
a

nice to have?



Would allowing the AS to not ignore the clientID as a query paramater =
as

long as it matches the one inside the JAR, basicly the same as =
Connect

request object but for just the one paramater make life easier for =
the

servers?



I am not promising a change but gathering info before proposing =
something.



John B.





On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:


On Wed, Jan 15, 2020 at 11:02:33PM =
+0200, Vladimir Dzhuvinov wrote:


On 14/01/2020 19:20, Takahiko =
Kawasaki wrote:


Well, embedding a client_id claim =
in the JWE header in order to

achieve "request parameters outside the request object should not be

referred to" is like "putting the cart before the horse". Why do we

have to avoid using the traditional client_id request parameter so

stubbornly?



The last paragraph of Section 3.2.1

<https://tools.ietf.org/html/rfc6749#section-3.2.1> of =
RFC 6749 says

as follows.



  /A client MAY use the "client_id" request parameter to =
identify

  itself when sending requests to the token endpoint.  In =
the

  "authorization_code" "grant_type" request to the token =
endpoint,

  *an unauthenticated client MUST send its "client_id" to =
prevent

  itself from inadvertently accepting a code intended for a =
client

  with a different "client_id".*  This protects the =
client from

  substitution of the authentication code.  (It provides =
no

  additional security for the protected resource.)/





If the same reasoning applies, a client_id must always be sent with

request / request_uri because client authentication is not performed

at the authorization endpoint. In other words, */an unauthenticated

client (every client is unauthenticated at the authorization =
endpoint)

MUST send its "client_id" to prevent itself from inadvertently

accepting a request object for a client with a different =
"client_id"./*





Identifying the client in JAR request_uri requests can be really =
useful

so that an AS which requires request_uri registration to prevent DDoS

attacks and other checks can do those without having to index all

request_uris individually. I mentioned this before.



I really wonder what the reasoning of the IESG reviewers was to =
insist

on no params outside the JAR JWT / request_uri.



I'm beginning to realise this step of the review process isn't

particularly transparent to WG members.



Could you expand on that a bit more?  My understanding is that the =
IESG

ballot mail gets copied to the WG precisely so that there is =
transparency,

e.g., the thread starting at

https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdi=
R9R0JwgI

Which admittely is from almost three years ago, but that's the =
earliest

that I found that could be seen as the source of this behavior.



-Ben



P.S. some other discussion at

https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-=
IGx4xHy8 and

https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZg=
pWCz_UwY and

so on.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





_______________________________________________

OAuth mailing 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=_7933E829-BEAD-4DE4-B96D-E67AD9FD7C0A--


From nobody Fri Jan 17 18:50: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 97DEE120086 for ; Fri, 17 Jan 2020 18:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOw7jWmtWGq7 for ; Fri, 17 Jan 2020 18:50:08 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42603120041 for ; Fri, 17 Jan 2020 18:50:08 -0800 (PST)
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 00I2o1J4029320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 21:50:03 -0500
Date: Fri, 17 Jan 2020 18:50:01 -0800
From: Benjamin Kaduk 
To: "Richard Backman, Annabelle" 
Cc: Neil Madden , IETF oauth WG 
Message-ID: <20200118025001.GU80030@kduck.mit.edu>
References:   <20200116143233.GJ80030@kduck.mit.edu>  <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com> <20200117035844.GQ80030@kduck.mit.edu> <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <93218BD9-EB9D-4F58-AB37-7F2A78A634E4@amazon.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 18 Jan 2020 02:50:10 -0000

Definitely; thanks for raising that explicitly.

-Ben

On Fri, Jan 17, 2020 at 04:34:10PM +0000, Richard Backman, Annabelle wrote:
> We should not be prescriptive about how the AS recognizes request URIs from itself. Trusted authority or custom URI scheme are fine as examples, but ultimately this is an internal implementation of the AS. It could just as easily be using data URIs containing a symmetrically encrypted database record ID.
> 
> > On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk  wrote:
> > 
> > On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote:
> >> The mitigations of 10.4.1 are related, but the section heading is about (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF attacks too or else add another section with similar mitigations. 
> >> 
> >> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is otherwise known to be safe (e.g., is a URI scheme controlled by the AS itself as with PAR).
> > 
> > pedantic nit: "URI scheme" is probably not what we want, as the authority
> > component of the URI (per RFC 3986) seems more likely to match "controlled
> > by the AS itself"
> > 
> > -Ben
> > 
> >> In addition for this to be effective the AS should not follow redirects when fetching the URI. It's not clear to me whether that is implied by "not perform recursive GET" so it may be worth explicitly spelling that out.
> >> 
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jan 17 18:53: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 257381200B8 for ; Fri, 17 Jan 2020 18:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJAkGLisjFX5 for ; Fri, 17 Jan 2020 18:53:25 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6966E120041 for ; Fri, 17 Jan 2020 18:53:25 -0800 (PST)
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 00I2rKl8029852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 21:53:22 -0500
Date: Fri, 17 Jan 2020 18:53:20 -0800
From: Benjamin Kaduk 
To: Justin Richer 
Cc: Joseph Heenan , oauth 
Message-ID: <20200118025320.GV80030@kduck.mit.edu>
References:  <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com> 
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] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 18 Jan 2020 02:53:28 -0000

On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> I don’t agree with this stance from a security or implementation perspective. 
> 
> If there’s a clear order of precedence for the information, it’s not particularly problematic. Everything inside the request object is to be taken over things outside the request object. We have the exact same semantics and process with dynamic registration, where the software statement is carried alongside plain JSON claims, and the two are mixed with a very simple algorithm:
> 
>  - If a field is inside the signed payload, use that value and ignore any copy of it on the outside
>  - If a field is not inside the signed payload and is outside the signed payload, use the outside value
> 
> Can someone please point out a concrete security issue with this algorithm? This is the extent of the “merge” semantics that we need here, and it would solve not only the ability to use this for use cases that call for a more static request object (perhaps signed by a third party and not the client) along side the plain parameters that can vary, but also the backwards compatibility issue that’s been discussed. With this algorithm in place, you could have OIDC clients actually be compliant with the spec, since OIDC requires replication of the values inside the request object on the outside with exact matches. An OIDC server wouldn’t be fully compliant with the new spec since it would reject some compliant JAR requests that are missing the external parameters, but that’s fairly easy logic to add on the OIDC side. And in that case you get a matrix of compatibility like:

I agree that the merge algorithm is simple and fairly straightforward to
implement.  But, as Joseph has been alluding, it's only simple if you've
already made the decision to use all the parameters, both from inside and
from outside the signed payload.  The security risk lies about having to
make the trust decision twice, more than the mundane details of actually
doing the merge.  (Though there is still some latent risk, given that we've
seen some really crazy quality of implementation out there.)

It's certainly *possible* that things end up fine in many well-deliniated
cases where merging can be used.  But it's more complicated to reason
about, and I don't remmber seeing much previous discussion about the
specifics of the double trust decision.

-Ben

> 
>               JAR Server | OIDC Server  |
> ------------+------------+--------------+
> JAR Client  |     YES    |      NO      |
> OIDC Client |     YES    |     YES      |
> 
> Breaking one out of the four possible combinations in a very predictable way is, I think, the best way to handle backwards compatibility here. 
> 
> But between this issue and JAR’s problematic call for the value of a request_uri to always be a JWT and be fetchable by the AS (neither of which are true in the case of PAR) makes me think we need to pull this back and rework those things, in a push back to the IESG’s comments.
> 
>  — Justin
> 
> 
> > On Jan 16, 2020, at 7:38 PM, Joseph Heenan  wrote:
> > 
> > I agree with this, particularly the security concerns of merging. If we merge, we can much guarantee there will eventually be a security issue where an attacker is able to gain an advantage by adding a parameter to the url query (which the server would then happily process if that parameter isn’t found inside the request object). Ruling out that case makes security analysis (particularly when creating new OAuth2 parameters) significantly simpler.
> > 
> > Putting the iss in the JWE header and having the client_id duplicated outside the request object seem to address all the concerns I’ve seen raised.
> > 
> > (It seems like it may be unnecessary to have the client_id duplicated outside if the request_uri is a PAR one though.)
> > 
> > Joseph
> > 
> > 
> > 
> >> On 16 Jan 2020, at 22:40, John Bradley  wrote:
> >> 
> >> I agree with the IESG reasoning that merging is problimatic.  Once we
> >> allow that given a unknown list of possible paramaters with diffrent
> >> security properties it would be quite difficult to specify safely.
> >> 
> >> Query paramaters can still be sent outside the JAR, but if they are in
> >> the OAuth registry the AS MUST ignore them.
> >> 
> >> Puting the iss in the JWE headder addresses the encryption issue without
> >> merging.
> >> 
> >> I understand that some existing servers have dependencys on getting the
> >> clientID as a query paramater.
> >> 
> >> Is that the only paramater that people have a issue with as oposed to a
> >> nice to have?
> >> 
> >> Would allowing the AS to not ignore the clientID as a query paramater as
> >> long as it matches the one inside the JAR, basicly the same as Connect
> >> request object but for just the one paramater make life easier for the
> >> servers?
> >> 
> >> I am not promising a change but gathering info before proposing something.
> >> 
> >> John B.
> >> 
> >> 
> >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> >>>>> Well, embedding a client_id claim in the JWE header in order to
> >>>>> achieve "request parameters outside the request object should not be
> >>>>> referred to" is like "putting the cart before the horse". Why do we
> >>>>> have to avoid using the traditional client_id request parameter so
> >>>>> stubbornly?
> >>>>> 
> >>>>> The last paragraph of Section 3.2.1
> >>>>>  of RFC 6749 says
> >>>>> as follows.
> >>>>> 
> >>>>>   /A client MAY use the "client_id" request parameter to identify
> >>>>>   itself when sending requests to the token endpoint.  In the
> >>>>>   "authorization_code" "grant_type" request to the token endpoint,
> >>>>>   *an unauthenticated client MUST send its "client_id" to prevent
> >>>>>   itself from inadvertently accepting a code intended for a client
> >>>>>   with a different "client_id".*  This protects the client from
> >>>>>   substitution of the authentication code.  (It provides no
> >>>>>   additional security for the protected resource.)/
> >>>>> 
> >>>>> 
> >>>>> If the same reasoning applies, a client_id must always be sent with
> >>>>> request / request_uri because client authentication is not performed
> >>>>> at the authorization endpoint. In other words, */an unauthenticated
> >>>>> client (every client is unauthenticated at the authorization endpoint)
> >>>>> MUST send its "client_id" to prevent itself from inadvertently
> >>>>> accepting a request object for a client with a different "client_id"./*
> >>>>> 
> >>>> Identifying the client in JAR request_uri requests can be really useful
> >>>> so that an AS which requires request_uri registration to prevent DDoS
> >>>> attacks and other checks can do those without having to index all
> >>>> request_uris individually. I mentioned this before.
> >>>> 
> >>>> I really wonder what the reasoning of the IESG reviewers was to insist
> >>>> on no params outside the JAR JWT / request_uri.
> >>>> 
> >>>> I'm beginning to realise this step of the review process isn't
> >>>> particularly transparent to WG members.
> >>> Could you expand on that a bit more?  My understanding is that the IESG
> >>> ballot mail gets copied to the WG precisely so that there is transparency,
> >>> e.g., the thread starting at
> >>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
> >>> Which admittely is from almost three years ago, but that's the earliest
> >>> that I found that could be seen as the source of this behavior.
> >>> 
> >>> -Ben
> >>> 
> >>> P.S. some other discussion at
> >>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
> >>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
> >>> so on.
> >>> 
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >> 
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > 
> > _______________________________________________
> > OAuth mailing 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 Sat Jan 18 02:21: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 C832E1200C5 for ; Sat, 18 Jan 2020 02:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OIhGrWi2JCP2 for ; Sat, 18 Jan 2020 02:21:08 -0800 (PST)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D57120058 for ; Sat, 18 Jan 2020 02:21:07 -0800 (PST)
Received: by mail-wm1-x343.google.com with SMTP id p17so10027604wmb.0 for ; Sat, 18 Jan 2020 02:21:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yi2g3LxV9VKDMkDq1ZI77LWT7EQUYJqu+0AoI+VIZnc=; b=MHAgMdorQySDqvhieQu0uO205F/MTlchEiq2uHz8KBKSZwZbP17qdnLko9MRCUerJw xX46/oDK4j/sRj+yCMY1MyVW17SF0tQrcdALYACHQEVGQw1I8Gyu7jGv8kcIiJYH43a7 srreFOHXsw38QnVIRUPremKXViSvnA4TZ4rbs=
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=Yi2g3LxV9VKDMkDq1ZI77LWT7EQUYJqu+0AoI+VIZnc=; b=iODVniktet7XlacOmekleU45tPPJk3WFO2EboWy//LeiRwq5E+ZkeMZFeYvKkuMKmk R6ptDvGap3ePKcz905MLGMDBz0rnNzHJx0GO+LuZuMsZBgh//45Qr5NfkSUqGg7CplUZ toZ/cqK3eqiCaJX4qNzjtb6SkfrFH09Q3EDvIlPC6W+MlNRFwZwAf19kLL3+funXy73G YIlMMRKXSCvB9OgSEDR6X9BSEuLy9dBHOGqQudpDi6Yho+K4reWmGIeDUTDNJv19cr7d wq8apzF0dCEoT4/dyBuC6pugyZvnzlSw7aKVtg8U0KuAZ6trZoLwTViXtopp0RFctpYO Ei0Q==
X-Gm-Message-State: APjAAAWiVCVMuXMNp7RqlOUYqckYM99L1rYqAj0EcAS0KVkGfMOpatB1 v6XcGyPsY2tNa7hE7JsquYRGjUJd3nMAOOj5
X-Google-Smtp-Source: APXvYqyrN0UyT7hSwTrEyUIeSCmuGhcEx7oyhsPfOAnp0ELSfMqpmhGFTJF8Nw3QmA1R4PcNeT65xQ==
X-Received: by 2002:a05:600c:251:: with SMTP id 17mr9061945wmj.88.1579342866337;  Sat, 18 Jan 2020 02:21:06 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id g18sm13068281wmh.48.2020.01.18.02.21.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 02:21:05 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden 
In-Reply-To: <20200117035844.GQ80030@kduck.mit.edu>
Date: Sat, 18 Jan 2020 10:21:04 +0000
Cc: Nat Sakimura , IETF oauth WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20200116143233.GJ80030@kduck.mit.edu>  <57F86DC4-F413-4D94-BFF8-2425222A69ED@forgerock.com> <20200117035844.GQ80030@kduck.mit.edu>
To: Benjamin Kaduk 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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: Sat, 18 Jan 2020 10:21:11 -0000

On 17 Jan 2020, at 03:58, Benjamin Kaduk  wrote:
>=20
> On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote:
>> The mitigations of 10.4.1 are related, but the section heading is =
about (D)DoS attacks. I think this heading needs to be reworded to apply =
to SSRF attacks too or else add another section with similar =
mitigations.=20
>>=20
>> Mitigation (a) is a bit vague as to what an "unexpected location" is. =
Perhaps specific wording that it should be a URI that has been =
pre-registered for the client (and validated at that time) or is =
otherwise known to be safe (e.g., is a URI scheme controlled by the AS =
itself as with PAR).
>=20
> pedantic nit: "URI scheme" is probably not what we want, as the =
authority
> component of the URI (per RFC 3986) seems more likely to match =
"controlled
> by the AS itself"

Well that's what actually I wanted to prevent. The authority component =
may refer to services *owned by* the AS (e.g. related microservices) but =
the authority component of a URI is not under the control of the AS - =
anybody can put whatever they like in there either from guessing likely =
hostnames or looking them up in things like certificate transparency =
logs. Compare that to something like x-request-id: where =
the AS has complete control over the address space.

As Nat requested, I'll try and come up with some wording in a pull =
request that captures the issue in a more general way.

-- Neil=


From nobody Sat Jan 18 14:09:27 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 213BE120043; Sat, 18 Jan 2020 14:09:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach via Datatracker 
To: "The IESG" 
Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach 
Message-ID: <157938536612.31650.765393290281258147.idtracker@ietfa.amsl.com>
Date: Sat, 18 Jan 2020 14:09:26 -0800
Archived-At: 
Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-jwt-introspection-response-08: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jan 2020 22:09:26 -0000

Adam Roach has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss and comments.



From nobody Mon Jan 20 07:33: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 6AAC312081C for ; Mon, 20 Jan 2020 07:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIaZAcMu_S3Y for ; Mon, 20 Jan 2020 07:32:56 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0: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 A6DC312007A for ; Mon, 20 Jan 2020 07:32:56 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id b15so27600425iln.3 for ; Mon, 20 Jan 2020 07:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=8N4/P0CCjNjOOhahr2+XzjlHFheVytNskHwj9qh4Kmc=; b=ll5SGgBEUzyXLvMJl6Kieir73AgaLmVpj313c77PSXUrFT0KSoZRotrmpcLTh91cLs KFNhEwB1+df9yFLyWHPtXlhG+dxXpnQaPVHWNgZ+/w/2ep7cJ3oaS0c1vEgT/sP8Sbk6 RoLu1NVfxp7qsyd4Qku0B2moH4Zr1IO0muebwkLgLvxstnPBx/JdNbImBSFkKw2XW6tA 5jLPm9Kiwz4ug7txKMSfQLIisUhsNvJXzIA4X/42vxQi1emF9wLqFMpfrOEKRJBrkuvf dvD/bQUGqVtLAi3ajfQgmxyy4CyY98G7lHMGpq299UYeAxQqBMw+ZcCKi0u5PWQbLN7Z umcg==
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=8N4/P0CCjNjOOhahr2+XzjlHFheVytNskHwj9qh4Kmc=; b=ibqUk1kPvtcJEEGPAnIT6cfQwo6JKiwBPgclqk2drPx7XVA3Gyd6wdmutmiTXvtjIc EcOEdfrWA6N2yA2AwAHaeTNDxDI9asjE91753L51XN85aRuao0Z6ube+QWuUb/d9bgds gvvDMCAYTwRI8Mb53Ga3dHcQfAzIGK5NTxggnw2JgPm6Q3dflHxH1AD1/u/ZY4yT1RiL 2fpjtICIfDQheEUcSLSYpEin2icptTbHrZUQZf7yxnkhtZsyRtGa+2SuWK0OrA6HahZg FrV73D+oV9nxCeEGmUOmJgNs4O1J/YZW2SewBNQe3VDk/TDRkKU9mnZHFB055ngNvpQ0 7yQg==
X-Gm-Message-State: APjAAAWGkcDCjwz9zwWGQkef3lcGgxSYDiau45BeLCqwfL1KLY2Uz2ZQ TzZjLSyR/GIyB1C1+ID/PU8Wcusj/om4QgOVr/7QHw==
X-Google-Smtp-Source: APXvYqz9EmZFoERd2cBvMNcYj32mxP5IOTNskXl3n3fysh5A+KnT4LmsSzQBjYNiNgQAhL+yMt8G96lqBMG9tae42/U=
X-Received: by 2002:a92:3984:: with SMTP id h4mr10958022ilf.36.1579534375506;  Mon, 20 Jan 2020 07:32:55 -0800 (PST)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 20 Jan 2020 10:32:44 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000005cd7e1059c940181"
Archived-At: 
Subject: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 15:33:10 -0000

--0000000000005cd7e1059c940181
Content-Type: text/plain; charset="UTF-8"

All,

Please, let us know if you have any topics that you would like to present
and discuss in Vancouver.

Regards,
 Rifaat & Hannes

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


All,

Please, let us know if you have an=
y topics that you would like to present and discuss in Vancouver.

Regards,
=C2=A0Rifaat & Hannes

=



--0000000000005cd7e1059c940181--


From nobody Mon Jan 20 08:03: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 7BCB9120876 for ; Mon, 20 Jan 2020 08:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 JhddDPoEBLLP for ; Mon, 20 Jan 2020 08:03:30 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38D812082C for ; Mon, 20 Jan 2020 08:03:29 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 7E08F1962C for ; Mon, 20 Jan 2020 16:03:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1579536207; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2u1y0n+cDR6Pq3nLYzBKQEtHLmLv0J0lcgmqKBAEZwU=; b=J8qNoMIUKvus8V9chsirPdeQEI/F/Knazru0cgNaW66A2NIwfAeAURRIvuwyqnhbzsXHZ/ PHL/542QT45FSLVhgG1l8jU2LbGS6p6BsxSkdqz4Yl1dyRHasYrpI5J5I++5LV0AOUs7h4 stKMRvNwtqnHV3P2/X4nmzzHorMuY6U=
To: oauth@ietf.org
References: 
From: Daniel Fett 
Message-ID: <1cf88880-6ea6-8cf2-89d9-ba87e458ea48@danielfett.de>
Date: Mon, 20 Jan 2020 17:03:25 +0100
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CCB44D410339AB1E72C8B98B"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1579536208; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2u1y0n+cDR6Pq3nLYzBKQEtHLmLv0J0lcgmqKBAEZwU=; b=Or52yto6PYfoCvlQKECM18B1lurJUViMHRNtfrq2TISgeBhaXVdgwADIDKfHhJ2ERL1qY9 HJ8Tvr2BNC05zu7rGiy6Dw0c83dQ15w9OidOiEY1hfTuRjSdqHzz7603Ar8YvLk7OtM5L9 jnS6PA5CyrUpwv6mNQF2uTuiHvy/Xd8=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1579536208; a=rsa-sha256; cv=none; b=sTp/QxtQ7MUoCzcRDajPk9rmrItcpZlFwaqVWam6Wxq6YD5+nFI6u+tSZRB6+Ml0rM7RCgcWmZ1PctYON9CC2Y4nFoldrBWxcnWJKk1ulM6mKlDE4scD1RuyNXQUQ7+rPepP6O/tTyhldfQlphMPdh5vN1w6uDd7ClWxpfTfcjo=
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] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 16:03:36 -0000

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

Hi!

I would like to discuss DPoP, the Security BCP, and give a brief update
about the activities at the FAPI working group.

-Daniel

Am 20.01.20 um 16:32 schrieb Rifaat Shekh-Yusef:
> All,
>
> Please, let us know if you have any topics that you would like to
> present and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
Hi!

    


    

    
I would like to discuss DPoP, the
      Security BCP, and give a brief update about the activities at the
      FAPI working group.

    


    

    
-Daniel

    

    


    

    
Am 20.01.20 um 16:32 schrieb Rifaat
      Shekh-Yusef:

    

    

      
      
All,
        


        

        
Please, let us know if you have any topics that you would
          like to present and discuss in Vancouver.

        


        

        
Regards,

        
 Rifaat & Hannes

        


        

      

      

      

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


    

    


    

  


--------------CCB44D410339AB1E72C8B98B--


From nobody Mon Jan 20 08:04: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 56C9612088F for ; Mon, 20 Jan 2020 08:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7oPPQSjI35Ex for ; Mon, 20 Jan 2020 08:03:46 -0800 (PST)
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 01AAD1208A0 for ; Mon, 20 Jan 2020 08:03:46 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id f129so124279wmf.2 for ; Mon, 20 Jan 2020 08:03:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=u4fPKTCwTbM0GwhzA9WxuPT6fS9BFSENyEE+ax9Z88U=; b=JXayfMa1pu5MG+c8+H36t3JtQFlnYt7IDkUiKKJSkkPe5LyP9Ulk4Ty2OQAq99VEFt 8VtvG+8XJT3fOZlVrgn25DEUMxFk++5i46wj/7wbIaJ0s9a6Sz6NLX4U7ga4ZHTvN9zO CSFtQv3jKWvtBnjkzWQeY4xuIDy+RookaPffL/c5nUNkRwHSR+2MJ1BXvBjFf2iZgOj5 ezWeuv+wrOoCSREVcCDHnrsc7o6wdhJncz5qqTJYGWmIojGGo/MOOMtJVB018yOc2S1Q Qi//zTGAcdXi1bGKyGvx+0C65ewc2eSYwX+y/WHkxmFKyHGJzzdwspuV8G1l9tYJFh3z K5KQ==
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=u4fPKTCwTbM0GwhzA9WxuPT6fS9BFSENyEE+ax9Z88U=; b=XFLN1l5zje+nVqpaB0GQDk7eaLXtuW18qp+zi9lxF3VncgQDPapHWfcNxWG15igm2V yZCLzA96rGKLrKl6lu44eBnefCUYALKo1BgR4r/IUgENIgG6RtbuHG533hGqfE+M4RBI ZeSS/Ed3pbVxNPE2G0MBgzipEfdIvpLJfXIRidltjqmWDO8w4UdpRLAWF+AbX3HjJCm+ /aqvfYpKbWwuUJlDyX9ibDvLf1q/Qdd5oWzYvojqxrkhYiqGKAIgqpeeoCcrV7uktYzD Utw7KxEGiqnXvHBQ7wY3Rvb6ECVGkUYTVVK7TqeSj6yGCqqbSYB4yYUnd1W7aWAhHKiJ 6C9Q==
X-Gm-Message-State: APjAAAWP9SaiD52WyjJozFaXGKHhFtDTlno/dbwiF0oEdjR5S22iYbiK Jb2Uv3swHWumxorNjcinV5vb1Q==
X-Google-Smtp-Source: APXvYqzxPqEFUnK/hc9ilM68PSjFs68nd5n/dRwbRbClHTZLVYIu6PhMVue/gxBDV5CE+rmeyAEIkQ==
X-Received: by 2002:a1c:9e4c:: with SMTP id h73mr32462wme.177.1579536224514; Mon, 20 Jan 2020 08:03:44 -0800 (PST)
Received: from [192.168.71.111] (p549EEE29.dip0.t-ipconnect.de. [84.158.238.41]) by smtp.gmail.com with ESMTPSA id u16sm571168wmj.41.2020.01.20.08.03.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 08:03:43 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_124FB6E8-AB39-4ABC-9A0D-1DCB86F01D29"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 20 Jan 2020 17:02:39 +0100
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef 
References: 
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 16:03:58 -0000

--Apple-Mail=_124FB6E8-AB39-4ABC-9A0D-1DCB86F01D29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Rifaat,

I would like to present draft-ietf-oauth-par, =
draft-lodderstedt-oauth-rar, and =
draft-ietf-oauth-jwt-introspection-response (if we did not manage to =
move it forward by then).

best regards,
Torsten.=20

> On 20. Jan 2020, at 16:32, Rifaat Shekh-Yusef  =
wrote:
>=20
> All,
>=20
> Please, let us know if you have any topics that you would like to =
present and discuss in Vancouver.
>=20
> Regards,
>  Rifaat & Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_124FB6E8-AB39-4ABC-9A0D-1DCB86F01D29
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMjAxNjAyMzlaMC8GCSqGSIb3DQEJBDEiBCAc1DQi9YybL84EpPiuCIa+5c4odXzSDZ/O
fsuBfO6EBTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAHx1FJ8ohIfaYRmLwNUSRAQY1e0NwxtY+KwLUB9O4HemtJBamcLpBg5fp6+n
tuy2QZD4qX6PT3sPXndCBTfsDgbMf1cCKsGeVb3abe6dXF2QkB/l8t+VzqQVoXfBmoqMaNIUMlYw
WOnpquAKgXv182Uyj4UO15gg0H3BQGcsaGiNJA79tAKTXM3tm5pSHITjapH0QR4S954BMNiAB4KG
PB1cA+MpUkWS6/GI9eDX1Wt4quALKHK5lzhEwOpcvNzooX62QpNw2i0IplkwJNrxb+3umJ1Fe4do
U4pGX30ogVYtjS4TQQn2x7Z9Rnpll5LxnZUQwL4MljuMxn9a1sT4mJEAAAAAAAA=
--Apple-Mail=_124FB6E8-AB39-4ABC-9A0D-1DCB86F01D29--


From nobody Mon Jan 20 08:12: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 19976120876 for ; Mon, 20 Jan 2020 08:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 IpG3FP_4MkMN for ; Mon, 20 Jan 2020 08:12:03 -0800 (PST)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD890120868 for ; Mon, 20 Jan 2020 08:12:02 -0800 (PST)
Received: by mail-il1-x12d.google.com with SMTP id t2so27664869ilq.9 for ; Mon, 20 Jan 2020 08:12:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E4fueOaTsK+xjpYD3Za21CZnH9pgkD/7lqXCi3jrojU=; b=BkGD7xDZhdIk5G2TL8n2RhbeWCPXu4ozSM8ZJ4ZGOsMu/u675FY3l59DinNNs/WJaH XBV5+q0kcy9J2XYonuIe9nRwjrFgvi/2Ba/BNvmY7V/Fit+5hBiLIv69ND33SELx2/hN hoMedhcNg1JtN4o2scaJIv0CZPrGy6WAjh6cmFU3y289DJS5Nu4XjhcvwfovWUtOaq+L mh4hI6aSwJu4UO9sW/CjBUfIGr6I0gVQnDEc/xTlwSm5y5EDXQ2O0fF5O2N0VEgdvXeC hLsLS9zYUnWWPi5Sgzy0QZ6y6HrnAux9lXn2ZRoOpxC09QH7Wv/l1xS2tLhakPp95yc0 NFew==
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=E4fueOaTsK+xjpYD3Za21CZnH9pgkD/7lqXCi3jrojU=; b=UpMV2IJ6ea/p21tl8zfQRuWjzhfQ/Rpa5UGX5ubZ1uxD4tXY1xcdqjnhWGebuf3Lg9 +hMcE4H+u2D8SGFnmcDrj64vNVPQyGcy9MXQBaXCyJt0rPaWS7251d5ilm/AGiLxlCYC 9mizR3nHp5PVVSSTQwXkOKXv6kKoIcUx89a2G8XwvurKQsC7Z7OGX0tHhnV9GyZR/bem Rn6ySEl/L/dNXW7WS9a+ZqqZZjW768psWZpUKV23SU1dW6dHYBfvMNraSR65smuibjQQ jlSioSXU+0S9344oPXDGpAJPh5jPSkQdhYlkL+dRYE80YWhRBybqlC3FF7sAAEnid0nU 9Xiw==
X-Gm-Message-State: APjAAAUvI2pzcM05IwFLzJmKsVHjB2uRvnJk5bULINDQrYPYftbjwHEh c8QcWvo8jh8HbIP7scjKDar4vXo1gm4=
X-Google-Smtp-Source: APXvYqw3c0iQVTvatfWnWepv+o537krdPlWwbK1lyP87xjg66/plkY5gx99GudGPbt4P6Dge/CYOrg==
X-Received: by 2002:a92:c686:: with SMTP id o6mr11191711ilg.212.1579536721986;  Mon, 20 Jan 2020 08:12:01 -0800 (PST)
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id l22sm11967877ilh.37.2020.01.20.08.12.01 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 08:12:01 -0800 (PST)
Received: by mail-il1-f178.google.com with SMTP id z12so27651851iln.11 for ; Mon, 20 Jan 2020 08:12:01 -0800 (PST)
X-Received: by 2002:a92:d183:: with SMTP id z3mr11252212ilz.214.1579536720837;  Mon, 20 Jan 2020 08:12:00 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Mon, 20 Jan 2020 08:11:49 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000027ce07059c948d0e"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 16:12:08 -0000

--00000000000027ce07059c948d0e
Content-Type: text/plain; charset="UTF-8"

I would like to discuss the Browser app BCP as well as the new draft which
got bumped from the agenda in Singapore:

https://tools.ietf.org/id/draft-parecki-oauth-client-intermediary-metadata

----
Aaron Parecki
aaronparecki.com



On Mon, Jan 20, 2020 at 7:34 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to present
> and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I would like to discuss the Browser app BCP as well a=
s the new draft which got bumped from the agenda in Singapore:

----
Aaron Parecki


=

On Mon=
, Jan 20, 2020 at 7:34 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Please, let us know if you have any topics that you would like to present=
 and discuss in Vancouver.

Regards,
=C2=
=A0Rifaat & Hannes


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000027ce07059c948d0e--


From nobody Mon Jan 20 08: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 0955A1208FA for ; Mon, 20 Jan 2020 08:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ese40jn9Ci_0 for ; Mon, 20 Jan 2020 08:51:36 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E841208E8 for ; Mon, 20 Jan 2020 08:51:36 -0800 (PST)
Received: from [18.20.149.103] ([18.20.149.103]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00KGpYSK024596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 20 Jan 2020 11:51:35 -0500
From: Justin Richer 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <6589BCE0-7710-4E2C-8E41-73BC28F8BCCA@mit.edu>
Date: Mon, 20 Jan 2020 11:51:34 -0500
To: oauth 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: [OAUTH-WG] HTTP Signing
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 16:51:40 -0000

As many of you know, Annabelle and I have put forward a general-purpose =
HTTP Signing specification in the HTTP Working Group, at least initially =
based on the old Cavage signatures spec that=E2=80=99s been used in the =
wild. We expect a number of important changes to happen as it goes =
through the standards process (which is to say, we aren=E2=80=99t =
approaching this to get a stamp on existing code), including some key =
things that would allow it to be used for more advanced OAuth proof of =
possession work. I would fully expect that a fairly small profile of =
this new signature document would be sufficient for OAuth PoP tokens, =
replacing the expired draft-ietf-http-signatures spec.=20

As I said in Singapore, I think that there=E2=80=99s room for this kind =
of thing alongside DPoP, which is much more focused and constrained than =
this is trying to be.=20

The new draft is currently going through its call for adoption within =
the HTTP WG, and if you have any interest in this work moving forward, =
please join the thread on the HTTP list to show your support for the =
draft. The Call For Adoption is currently open and runs through Jan 31.

Thanks,
 =E2=80=94 Justin=


From nobody Mon Jan 20 09:33: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 73C27120A1C for ; Mon, 20 Jan 2020 09:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.8
X-Spam-Level: 
X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p_BDcxKUne6 for ; Mon, 20 Jan 2020 09:33:30 -0800 (PST)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 E678C1209ED for ; Mon, 20 Jan 2020 09:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579541610; x=1611077610; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=b4gtAFKX4Chlt3wJLJ8eAFxAntjLoLphhZSLO5AveJo=; b=JASGqBnomKgohN3zg9mR/GidPurIpukMp0yTTiTwF/VBGsbSu301ro9N /3rHmCzvzCh7eUPENHLSykI3nNU62ObSHnAbchKM5cQlbJm4873b4czKf 03vBhF9M+WtA8PconPgjbkMguUSDmkX08NClojplHiYTQpvBFC/qfyQiD 4=;
IronPort-SDR: BeJYWWqYHAd5tSe+aHYg92XiUaBDDsOHGqYhGu6tQqcIDRFBLPAZx7eIcMUv34ujrEgemuV0Xd LW9rQGEd0iOA==
X-IronPort-AV: E=Sophos; i="5.70,342,1574121600"; d="scan'208,217"; a="13800902"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 20 Jan 2020 17:33:27 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (Postfix) with ESMTPS id 9262BA26CD; Mon, 20 Jan 2020 17:33:27 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 17:33:27 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 17:33:26 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 20 Jan 2020 17:33:27 +0000
From: "Richard Backman, Annabelle" 
To: Rifaat Shekh-Yusef , oauth 
Thread-Topic: [OAUTH-WG] OAuth Topics for Vancouver
Thread-Index: AQHVz6cmxk4jjxQ5zkeyuBJCXveYtafzSgYA
Date: Mon, 20 Jan 2020 17:33:26 +0000
Message-ID: <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.95]
Content-Type: multipart/alternative; boundary="_000_0BA39EEAB7904B3AA51F4D1EE5B5C937amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 17:33:35 -0000

--_000_0BA39EEAB7904B3AA51F4D1EE5B5C937amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgSFRUUCBNZXNzYWdlIFNpZ25hdHVyZXM8aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hhbm5hLWh0dHAtbWVzc2FnZS1zaWduYXR1cmVz
LTAwPiBhcyBhIHByb29mLW9mLXBvc3Nlc3Npb24gbWVjaGFuaXNtIGZvciBPQXV0aC4gQSBkcmFm
dCB3aWxsIGJlIGF2YWlsYWJsZSAoZWl0aGVyIGFzIGFuIHVwZGF0ZSB0byBkcmFmdC1pZXRmLW9h
dXRoLXNpZ25lZC1odHRwLXJlcXVlc3Qgb3IgYXMgYSBuZXcgaW5kaXZpZHVhbCBzdWJtaXNzaW9u
KS4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpG
cm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJpZmFhdCBT
aGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5
IDIwLCAyMDIwIGF0IDc6MzQgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBbT0FVVEgtV0ddIE9BdXRoIFRvcGljcyBmb3IgVmFuY291dmVyDQoNCkFsbCwNCg0KUGxlYXNl
LCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgdG9waWNzIHRoYXQgeW91IHdvdWxkIGxpa2Ug
dG8gcHJlc2VudCBhbmQgZGlzY3VzcyBpbiBWYW5jb3V2ZXIuDQoNClJlZ2FyZHMsDQogUmlmYWF0
ICYgSGFubmVzDQoNCg==

--_000_0BA39EEAB7904B3AA51F4D1EE5B5C937amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <718D0CE7EDE993499B7EDA30F0049A6F@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2
M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291
bGQgbGlrZSB0byBkaXNjdXNzIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1yaWNoYW5uYS1odHRwLW1lc3NhZ2Utc2lnbmF0dXJlcy0wMCI+DQpIVFRQIE1lc3NhZ2Ug
U2lnbmF0dXJlczwvYT4gYXMgYSBwcm9vZi1vZi1wb3NzZXNzaW9uIG1lY2hhbmlzbSBmb3IgT0F1
dGguIEEgZHJhZnQgd2lsbCBiZSBhdmFpbGFibGUgKGVpdGhlciBhcyBhbiB1cGRhdGUgdG8gZHJh
ZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0IG9yIGFzIGEgbmV3IGluZGl2aWR1YWwg
c3VibWlzc2lvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2Vz
QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQu
aWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAyMCwg
MjAyMCBhdCA3OjM0IEFNPGJyPg0KPGI+VG86IDwvYj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltPQVVUSC1XR10gT0F1dGggVG9waWNzIGZvciBWYW5j
b3V2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5QbGVhc2UsIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSB0b3BpY3MgdGhhdCB5b3Ug
d291bGQgbGlrZSB0byBwcmVzZW50IGFuZCBkaXNjdXNzIGluIFZhbmNvdXZlci48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1Jp
ZmFhdCAmYW1wOyBIYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_0BA39EEAB7904B3AA51F4D1EE5B5C937amazoncom_--


From nobody Mon Jan 20 10:18: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 1BDB41200B7 for ; Mon, 20 Jan 2020 10:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEBzRWty3g0D for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B89C1201DC for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id w15so483619wru.4 for ; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
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=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=oYPQzqeu2SzQnyRJ8RNIbHSBYAtnne1JxkkKbYLYxo1kgvFxC4xg4qxaeX+dvawllY +7JPCxMHccI9LAgL82XG4x/eN2PQNfNfc1jKqKdFBejedvlToO+z075ZB7i534eKs4PY NJ1N6z3SIC3pAuMGYOuwCpx/96oFAAoJL/fc7//8UXWUwSh6cG1TiQrO3jvqGWZJx4fa PfJ7RmStA+ygd5+hiB60qI98n7GHsejYATjvJPL1lowBES1o8fnkXYWhzH0pc5LgDwfU JyvR8t0XajbQCfuGL28NEE20ViSczubU7yRGWTm0Pkof6VT95WnVBErUW7DhDmSf0PBh R/2g==
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=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=RvgSGFBNHl5brRuuMPsYaxvw4YuXpeDLZo5sdH5Wtu/vi2tb+y1AltpeOPFiQmPQsX Nlc85C/B5w+WBhIm11DFvnFxjoL4SsVCguKhDxHRIPXAhvTAdCIh1Tg3Na+1qygiXlCg p8JK6BwXdBUqUQfuWEr6PgVz8bVX6wWQMkI1tlq3meJyMwMaEWnvbx++zO84FywL9FRb 9hBKN8+5/m20GKbhXvbNqVkzO+BBEVvWW079Zq/v+MvROsg5xZ8lHr5DG/+Cjb/SUUUs e+kikrJSIETGsJyhcPjOJJv656IOgZa5DgJbgAB74A2vdDv/z0hSD/c7uDFCbKiFCPvi iQgw==
X-Gm-Message-State: APjAAAV6tqHqq1YlWQcbkPNcPV16icLNaJzu6+991hQ9PG9WNzsWBU/V T0bG74VlLZvtfjGZPi7W1NA=
X-Google-Smtp-Source: APXvYqzsLsP7jK6NftoNAlfQlsOBMB8YuDaDm2VAh9iM1nAUa1lWxgw74j/kBZY1+0lF6lvm+8py9g==
X-Received: by 2002:a05:6000:1047:: with SMTP id c7mr742062wrx.341.1579544294513;  Mon, 20 Jan 2020 10:18:14 -0800 (PST)
Received: from ?IPv6:2a02:a443:c7cb:1:6daa:a695:f46c:5b08? ([2a02:a443:c7cb:1:6daa:a695:f46c:5b08]) by smtp.gmail.com with ESMTPSA id w17sm48658445wrt.89.2020.01.20.10.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 10:18:13 -0800 (PST)
From: Rob Cordes 
Message-Id: <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 20 Jan 2020 19:18:12 +0100
In-Reply-To: <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com>
Cc: Rifaat Shekh-Yusef , oauth 
To: "Richard Backman, Annabelle" 
References:  <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 18:18:19 -0000

--Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,


Sorry for me answering in this direct manner instead of via the OAUTH =
mailing list or so.

I would like to point a practical issue out wrt the HTTP signature spec. =
I have got practical experience with the spec through my work for ING in =
our PSD2 (European electronic banking scheme) platform. We have =
implemented this spec (cavage-10) in our platform as well. We experience =
lots of issues with 3rd party developers who have issues getting their =
code right. It is the canalisation that is troubling the adoption in =
practice. People are continuously making mistakes with setting up the =
payload for signatures / body digest.
This can only be solved by making available ready made libraries. That =
might be done through vendors and their solutions and one would =
encounter  probably less interoperability issues.=20

However until then still troubles is what people have with this spec. =
Apart form that,  the spec is very much draft and as I understood from =
one of the draft members and still not security tested ands so perhaps =
still not secure.

Before one can adopt another spec into, in this case OAuth 2.0 it would =
be wise to tackle this first. While HTTP signing does help in better =
authenticating and safeguarding messages/token requests, this will make =
key management even more important. =20

The risk that HTTP signing in OAUTH might mitigate, could very well be =
far easier solved by TLS 1.2 or 1.3. That is even better because the =
implementations are security tested (TLS 1.2 or depending on the =
supplier/implementer in the process of (TLS 1.3) due to their importance =
and can be implemented in a turn key manner.=20

These are I believe important attention points that one might think over =
before extending the OAUTH 2.0 spec even further with perhaps too little =
gain?

Best regards,

Rob Cordes
Feature Engineer  / InfoSec specialist @ ING bank


> On 20 Jan 2020, at 18:33, Richard Backman, Annabelle =
 wrote:
>=20
> I would like to discuss HTTP Message Signatures =
 =
as a proof-of-possession mechanism for OAuth. A draft will be available =
(either as an update to draft-ietf-oauth-signed-http-request or as a new =
individual submission).
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: OAuth  on behalf of Rifaat Shekh-Yusef =

> Date: Monday, January 20, 2020 at 7:34 AM
> To: oauth 
> Subject: [OAUTH-WG] OAuth Topics for Vancouver
> =20
> All,=20
> =20
> Please, let us know if you have any topics that you would like to =
present and discuss in Vancouver.
> =20
> Regards,
>  Rifaat & Hannes
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi,


Sorry for me answering in this direct =
manner instead of via the OAUTH mailing list or so.

I would like to point a =
practical issue out wrt the HTTP signature spec. I have got practical =
experience with the spec through my work for ING in our PSD2 (European =
electronic banking scheme) platform. We have implemented this spec =
(cavage-10) in our platform as well. We experience lots of issues with =
3rd party developers who have issues getting their code right. It is the =
canalisation that is troubling the adoption in practice. People are =
continuously making mistakes with setting up the payload for signatures =
/ body digest.
This can only be solved by making =
available ready made libraries. That might be done through vendors and =
their solutions and one would encounter  probably less =
interoperability issues. 

However until then still troubles is =
what people have with this spec. Apart form that,  the spec is very =
much draft and as I understood from one of the draft members and still =
not security tested ands so perhaps still not secure.

Before one can adopt =
another spec into, in this case OAuth 2.0 it would be wise to tackle =
this first. While HTTP signing does help in better authenticating and =
safeguarding messages/token requests, this will make key management even =
more important.  

The risk that HTTP signing in OAUTH might mitigate, could =
very well be far easier solved by TLS 1.2 or 1.3. That is even better =
because the implementations are security tested (TLS 1.2 or depending on =
the supplier/implementer in the process of (TLS 1.3) due to their =
importance and can be implemented in a turn key manner. 

These are I believe important attention points =
that one might think over before extending the OAUTH 2.0 spec =
even further with perhaps too little gain?

Best regards,

Rob =
Cordes
Feature Engineer  / InfoSec specialist @ ING =
bank


On 20 =
Jan 2020, at 18:33, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> =
wrote:

I would =
like to discuss HTTP Message Signatures as a proof-of-possession =
mechanism for OAuth. A draft will be available (either as an update to =
draft-ietf-oauth-signed-http-request or as a new individual =
submission).
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Rifaat =
Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Monday, January 20, =
2020 at 7:34 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Topics =
for Vancouver
 
All, 
 
Please, let us know if you have any =
topics that you would like to present and discuss in Vancouver.
 
Regards,
 Rifaat & Hannes
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E--


From nobody Mon Jan 20 10:57: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 A389B12083A for ; Mon, 20 Jan 2020 10:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nvxv5yE-FanV for ; Mon, 20 Jan 2020 10:57:47 -0800 (PST)
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 23E71120845 for ; Mon, 20 Jan 2020 10:57:38 -0800 (PST)
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; Mon, 20 Jan 2020 10:57:13 -0800
From: Jim Schaad 
To: 
CC: 'oauth' 
Date: Mon, 20 Jan 2020 10:57:07 -0800
Message-ID: <002501d5cfc3$6d3a0930$47ae1b90$@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: AdXPwu8/l3HG9L7fRL2eLS+vwxL9Cg==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: 
Subject: [OAUTH-WG] Question for encrypted POP Key
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 18:57:54 -0000

I am trying to deal with some of the various confirmation methods for a  POP
token.  The question that I have is about the format of the JOSE Encrypted
value to be used.  The document has an example of a compact serialization
for this concept, it does not have an example of a JSON serialization.  The
document appears to be silent about the legal serialization formats except
for this example.  

Is only the compact serialization format allowed or are all three
serialization formats allowed?

Jim



From nobody Mon Jan 20 10:58: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 79738120875 for ; Mon, 20 Jan 2020 10:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 iLLu6HZxj4f3 for ; Mon, 20 Jan 2020 10:58:24 -0800 (PST)
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 F2835120945 for ; Mon, 20 Jan 2020 10:58:23 -0800 (PST)
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; Mon, 20 Jan 2020 10:58:19 -0800
From: Jim Schaad 
To: 
CC: 'oauth' 
References: 
In-Reply-To: 
Date: Mon, 20 Jan 2020 10:58:15 -0800
Message-ID: <002601d5cfc3$942e43d0$bc8acb70$@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: AdXPwu8/l3HG9L7fRL2eLS+vwxL9CgAAJ62g
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: 
Subject: Re: [OAUTH-WG] Question for encrypted POP Key
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 18:58:32 -0000

Never mind, I just saw the answer.

-----Original Message-----
From: Jim Schaad  
Sent: Monday, January 20, 2020 10:57 AM
To: 'draft-ietf-oauth-proof-of-possession@ietf.org'

Cc: 'oauth' 
Subject: Question for encrypted POP Key

I am trying to deal with some of the various confirmation methods for a  POP
token.  The question that I have is about the format of the JOSE Encrypted
value to be used.  The document has an example of a compact serialization
for this concept, it does not have an example of a JSON serialization.  The
document appears to be silent about the legal serialization formats except
for this example.  

Is only the compact serialization format allowed or are all three
serialization formats allowed?

Jim



From nobody Mon Jan 20 12:50: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 4C9DA120232 for ; Mon, 20 Jan 2020 12:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTpUzk1RLzuR for ; Mon, 20 Jan 2020 12:50:49 -0800 (PST)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A1112001A for ; Mon, 20 Jan 2020 12:50:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579553450; x=1611089450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TY6atr19xi1+H17JbWkXi1KykC3ymyp7Y7e+V08RL8I=; b=QwHm5BnsSUOSpi5sh6rpSJso0kzon2HN9VxT4uUzb75ENADRspRCEYFF BZTY3J9MDUF5cpMpFvOAKVktyxp2Egj1j9mpg05/0K5YbuZQ1VR0m/FS/ csgx+31ox71A49BGd48u4aZr7j450n5Vm4D8NGB2et2CnudIUToKiz3rX g=;
IronPort-SDR: 1Q+cJqBtGd5iNqIpQYBB8hQ6C8Wcd3RT38RbjTA3LkZX8YBlk2h4t7C3l9v0i9Y3w0FbM0bv0t Fk8evDKoIZIg==
X-IronPort-AV: E=Sophos; i="5.70,343,1574121600"; d="scan'208,217"; a="19858227"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 20 Jan 2020 20:50:39 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id B6A96A19F1; Mon, 20 Jan 2020 20:50:35 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 20:50:35 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 20:50:34 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 20 Jan 2020 20:50:34 +0000
From: "Richard Backman, Annabelle" 
To: Rob Cordes 
CC: Rifaat Shekh-Yusef , oauth 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] OAuth Topics for Vancouver
Thread-Index: AQHVz6cmxk4jjxQ5zkeyuBJCXveYtafzSgYAgACSngD//6R2AA==
Date: Mon, 20 Jan 2020 20:50:34 +0000
Message-ID: <3950598E-F3F1-4821-8C18-DC9008C65DFD@amazon.com>
References:  <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com> <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com>
In-Reply-To: <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.7]
Content-Type: multipart/alternative; boundary="_000_3950598EF3F148218C18DC9008C65DFDamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re:  OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 20:50:56 -0000

--_000_3950598EF3F148218C18DC9008C65DFDamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgZWRpdG9yIG9mIHRoZSBtZXNzYWdlIHNpZ25hdHVyZXMgZHJhZnQgYmVpbmcgY29uc2lkZXJl
ZCBmb3IgYWRvcHRpb24gd2l0aGluIHRoZSBIVFRQIFdHIEkgY2FuIGNvbmZpcm0gaXQgaGFzIHNp
Z25pZmljYW50IGZsYXdzLiDwn5iDIEFzIG5vdGVkIGluIHRoYXQgZHJhZnQsIHRoZSBjdXJyZW50
IHRleHQgaXMgaW50ZW5kZWQgdG8gc2VydmUgYXMgYSBiYXNlbGluaW5nIG9mIHNvcnRzIHRvIGdl
dCB3b3JrIHRoYXQgaGFzIGJlZW4gZmxvYXRpbmcgYXJvdW5kIGluIHRoZSBjb21tdW5pdHkgaW50
byB0aGUgd29ya2luZyBncm91cCwgYW5kIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIHdvcmtpbmcg
Z3JvdXAgd2lsbCBtYWtlIHNpZ25pZmljYW50IGJyZWFraW5nIGNoYW5nZXMgdG8gaXQuIEkgZW5j
b3VyYWdlIGFueW9uZSB3aG8gd2FudHMgdG8gcGFydGljaXBhdGUgaW4gdGhvc2UgZGlzY3Vzc2lv
bnMgKGFzIHdlbGwgYXMgdGhlIGdlbmVyYWwg4oCcY2FsbCBmb3IgYWRvcHRpb27igJ0gZGlzY3Vz
c2lvbiB0byBkbyBzbywgb24gdGhlIEhUVFAgV0cgbWFpbGluZyBsaXN0LiDwn5iDDQoNCkkgYmVs
aWV2ZSBpdCB3b3VsZCBiZSB0byBib3RoIHdvcmtpbmcgZ3JvdXBz4oCZIGJlbmVmaXQgdG8gaGF2
ZSBhbiBPQXV0aCBQb1AgZHJhZnQgYmFzZWQgb24gSFRUUCBtZXNzYWdlIHNpZ25hdHVyZXMgdW5k
ZXIgZGlzY3Vzc2lvbiBlYXJseS4gSXQgd291bGQgcHJvdmlkZSB0aGUgSFRUUCBXRyB3aXRoIGEg
dGVzdCBjYXNlIGZvciB0aGUgbGF5ZXJlZCBhcHByb2FjaCB0aGF0IHRoZSBIVFRQIG1lc3NhZ2Ug
c2lnbmF0dXJlcyBkcmFmdCB0YWtlcyB0b3dhcmRzIHRoaXMgcHJvYmxlbSwgYW5kIHdvdWxkIGFs
bG93IHRoZSBPQXV0aCBXRyB0byBlbnN1cmUgdGhhdCBvdXIgdXNlIGNhc2VzIGFyZSBzdXBwb3J0
ZWQuIEFsc28sIGdpdmVuIHRoZSBpbnRlcmVzdCBpbiBEUG9QLCBJIHRoaW5rIGl0IHdpbGwgYmUg
aGVscGZ1bCBmb3IgdGhlIE9BdXRoIFdHIHRvIHNlZSB3aGF0IG1lc3NhZ2Ugc2lnbmF0dXJlLWJh
c2VkIFBvUCBtaWdodCBsb29rIGxpa2UuIEl0IG1heSBiZSBlYXNpZXIgdG8gdGFyZ2V0IERQb1Ag
YXQgYSBuYXJyb3dlciBzZXQgb2YgdXNlIGNhc2VzIGlmIHBlb3BsZSBzZWUgYSBicm9hZGVyIHNv
bHV0aW9uIGlzIGNvbWluZy4NCg0KVGhlIGludHJvZHVjdGlvbiB0byB0aGUgSFRUUCBNZXNzYWdl
IFNpZ25hdHVyZXMgZHJhZnQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hh
bm5hLWh0dHAtbWVzc2FnZS1zaWduYXR1cmVzLTAwI3NlY3Rpb24tMT4gZGVzY3JpYmVzIHdoeSBU
TFMgaXMgbm90IGEgdW5pdmVyc2FsIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbS4NCg0K4oCTDQpB
bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBSb2IgQ29y
ZGVzIDxyb2Jjb3JkZXNAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDIwLCAyMDIw
IGF0IDEwOjE5IEFNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFA
YW1hem9uLmNvbT4NCkNjOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNv
bT4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0g
UmU6IFtPQVVUSC1XR10gT0F1dGggVG9waWNzIGZvciBWYW5jb3V2ZXINCg0KSGksDQoNCg0KU29y
cnkgZm9yIG1lIGFuc3dlcmluZyBpbiB0aGlzIGRpcmVjdCBtYW5uZXIgaW5zdGVhZCBvZiB2aWEg
dGhlIE9BVVRIIG1haWxpbmcgbGlzdCBvciBzby4NCg0KSSB3b3VsZCBsaWtlIHRvIHBvaW50IGEg
cHJhY3RpY2FsIGlzc3VlIG91dCB3cnQgdGhlIEhUVFAgc2lnbmF0dXJlIHNwZWMuIEkgaGF2ZSBn
b3QgcHJhY3RpY2FsIGV4cGVyaWVuY2Ugd2l0aCB0aGUgc3BlYyB0aHJvdWdoIG15IHdvcmsgZm9y
IElORyBpbiBvdXIgUFNEMiAoRXVyb3BlYW4gZWxlY3Ryb25pYyBiYW5raW5nIHNjaGVtZSkgcGxh
dGZvcm0uIFdlIGhhdmUgaW1wbGVtZW50ZWQgdGhpcyBzcGVjIChjYXZhZ2UtMTApIGluIG91ciBw
bGF0Zm9ybSBhcyB3ZWxsLiBXZSBleHBlcmllbmNlIGxvdHMgb2YgaXNzdWVzIHdpdGggM3JkIHBh
cnR5IGRldmVsb3BlcnMgd2hvIGhhdmUgaXNzdWVzIGdldHRpbmcgdGhlaXIgY29kZSByaWdodC4g
SXQgaXMgdGhlIGNhbmFsaXNhdGlvbiB0aGF0IGlzIHRyb3VibGluZyB0aGUgYWRvcHRpb24gaW4g
cHJhY3RpY2UuIFBlb3BsZSBhcmUgY29udGludW91c2x5IG1ha2luZyBtaXN0YWtlcyB3aXRoIHNl
dHRpbmcgdXAgdGhlIHBheWxvYWQgZm9yIHNpZ25hdHVyZXMgLyBib2R5IGRpZ2VzdC4NClRoaXMg
Y2FuIG9ubHkgYmUgc29sdmVkIGJ5IG1ha2luZyBhdmFpbGFibGUgcmVhZHkgbWFkZSBsaWJyYXJp
ZXMuIFRoYXQgbWlnaHQgYmUgZG9uZSB0aHJvdWdoIHZlbmRvcnMgYW5kIHRoZWlyIHNvbHV0aW9u
cyBhbmQgb25lIHdvdWxkIGVuY291bnRlciAgcHJvYmFibHkgbGVzcyBpbnRlcm9wZXJhYmlsaXR5
IGlzc3Vlcy4NCg0KSG93ZXZlciB1bnRpbCB0aGVuIHN0aWxsIHRyb3VibGVzIGlzIHdoYXQgcGVv
cGxlIGhhdmUgd2l0aCB0aGlzIHNwZWMuIEFwYXJ0IGZvcm0gdGhhdCwgIHRoZSBzcGVjIGlzIHZl
cnkgbXVjaCBkcmFmdCBhbmQgYXMgSSB1bmRlcnN0b29kIGZyb20gb25lIG9mIHRoZSBkcmFmdCBt
ZW1iZXJzIGFuZCBzdGlsbCBub3Qgc2VjdXJpdHkgdGVzdGVkIGFuZHMgc28gcGVyaGFwcyBzdGls
bCBub3Qgc2VjdXJlLg0KDQpCZWZvcmUgb25lIGNhbiBhZG9wdCBhbm90aGVyIHNwZWMgaW50bywg
aW4gdGhpcyBjYXNlIE9BdXRoIDIuMCBpdCB3b3VsZCBiZSB3aXNlIHRvIHRhY2tsZSB0aGlzIGZp
cnN0LiBXaGlsZSBIVFRQIHNpZ25pbmcgZG9lcyBoZWxwIGluIGJldHRlciBhdXRoZW50aWNhdGlu
ZyBhbmQgc2FmZWd1YXJkaW5nIG1lc3NhZ2VzL3Rva2VuIHJlcXVlc3RzLCB0aGlzIHdpbGwgbWFr
ZSBrZXkgbWFuYWdlbWVudCBldmVuIG1vcmUgaW1wb3J0YW50Lg0KDQpUaGUgcmlzayB0aGF0IEhU
VFAgc2lnbmluZyBpbiBPQVVUSCBtaWdodCBtaXRpZ2F0ZSwgY291bGQgdmVyeSB3ZWxsIGJlIGZh
ciBlYXNpZXIgc29sdmVkIGJ5IFRMUyAxLjIgb3IgMS4zLiBUaGF0IGlzIGV2ZW4gYmV0dGVyIGJl
Y2F1c2UgdGhlIGltcGxlbWVudGF0aW9ucyBhcmUgc2VjdXJpdHkgdGVzdGVkIChUTFMgMS4yIG9y
IGRlcGVuZGluZyBvbiB0aGUgc3VwcGxpZXIvaW1wbGVtZW50ZXIgaW4gdGhlIHByb2Nlc3Mgb2Yg
KFRMUyAxLjMpIGR1ZSB0byB0aGVpciBpbXBvcnRhbmNlIGFuZCBjYW4gYmUgaW1wbGVtZW50ZWQg
aW4gYSB0dXJuIGtleSBtYW5uZXIuDQoNCg0KVGhlc2UgYXJlIEkgYmVsaWV2ZSBpbXBvcnRhbnQg
YXR0ZW50aW9uIHBvaW50cyB0aGF0IG9uZSBtaWdodCB0aGluayBvdmVyIGJlZm9yZSBleHRlbmRp
bmcgdGhlIE9BVVRIIDIuMCBzcGVjIGV2ZW4gZnVydGhlciB3aXRoIHBlcmhhcHMgdG9vIGxpdHRs
ZSBnYWluPw0KDQpCZXN0IHJlZ2FyZHMsDQoNClJvYiBDb3JkZXMNCkZlYXR1cmUgRW5naW5lZXIg
IC8gSW5mb1NlYyBzcGVjaWFsaXN0IEAgSU5HIGJhbmsNCg0KDQoNCk9uIDIwIEphbiAyMDIwLCBh
dCAxODozMywgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNv
bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu
b3JnPj4gd3JvdGU6DQoNCkkgd291bGQgbGlrZSB0byBkaXNjdXNzIEhUVFAgTWVzc2FnZSBTaWdu
YXR1cmVzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoYW5uYS1odHRwLW1l
c3NhZ2Utc2lnbmF0dXJlcy0wMD4gYXMgYSBwcm9vZi1vZi1wb3NzZXNzaW9uIG1lY2hhbmlzbSBm
b3IgT0F1dGguIEEgZHJhZnQgd2lsbCBiZSBhdmFpbGFibGUgKGVpdGhlciBhcyBhbiB1cGRhdGUg
dG8gZHJhZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0IG9yIGFzIGEgbmV3IGluZGl2
aWR1YWwgc3VibWlzc2lvbikuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdT
IElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUmlmYWF0IFNoZWtoLVl1c2Vm
IDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+DQpE
YXRlOiBNb25kYXksIEphbnVhcnkgMjAsIDIwMjAgYXQgNzozNCBBTQ0KVG86IG9hdXRoIDxvYXV0
aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW09BVVRILVdHXSBP
QXV0aCBUb3BpY3MgZm9yIFZhbmNvdXZlcg0KDQpBbGwsDQoNClBsZWFzZSwgbGV0IHVzIGtub3cg
aWYgeW91IGhhdmUgYW55IHRvcGljcyB0aGF0IHlvdSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYW5k
IGRpc2N1c3MgaW4gVmFuY291dmVyLg0KDQpSZWdhcmRzLA0KIFJpZmFhdCAmIEhhbm5lcw0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

--_000_3950598EF3F148218C18DC9008C65DFDamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <7696AAC4A87622409BC4404EE685177C@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg
MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN
YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwg
bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252
ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw
YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw
dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu
MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5BcyBlZGl0b3Igb2YgdGhlIG1lc3NhZ2Ugc2lnbmF0dXJlcyBkcmFmdCBi
ZWluZyBjb25zaWRlcmVkIGZvciBhZG9wdGlvbiB3aXRoaW4gdGhlIEhUVFAgV0cgSSBjYW4gY29u
ZmlybSBpdCBoYXMgc2lnbmlmaWNhbnQgZmxhd3MuDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTE1Ozwvc3Bhbj4gQXMgbm90ZWQg
aW4gdGhhdCBkcmFmdCwgdGhlIGN1cnJlbnQgdGV4dCBpcyBpbnRlbmRlZCB0byBzZXJ2ZSBhcyBh
IGJhc2VsaW5pbmcgb2Ygc29ydHMgdG8gZ2V0IHdvcmsgdGhhdCBoYXMgYmVlbiBmbG9hdGluZyBh
cm91bmQgaW4gdGhlIGNvbW11bml0eSBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLCBhbmQgaXQgaXMg
ZXhwZWN0ZWQgdGhhdCB0aGUgd29ya2luZw0KIGdyb3VwIHdpbGwgbWFrZSBzaWduaWZpY2FudCBi
cmVha2luZyBjaGFuZ2VzIHRvIGl0LiBJIGVuY291cmFnZSBhbnlvbmUgd2hvIHdhbnRzIHRvIHBh
cnRpY2lwYXRlIGluIHRob3NlIGRpc2N1c3Npb25zIChhcyB3ZWxsIGFzIHRoZSBnZW5lcmFsIOKA
nGNhbGwgZm9yIGFkb3B0aW9u4oCdIGRpc2N1c3Npb24gdG8gZG8gc28sIG9uIHRoZSBIVFRQIFdH
IG1haWxpbmcgbGlzdC4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xv
ciBFbW9qaSZxdW90OyI+JiMxMjg1MTU7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGJlbGlldmUgaXQgd291bGQgYmUgdG8gYm90aCB3b3JraW5nIGdyb3Vwc+KAmSBiZW5lZml0IHRv
IGhhdmUgYW4gT0F1dGggUG9QIGRyYWZ0IGJhc2VkIG9uIEhUVFAgbWVzc2FnZSBzaWduYXR1cmVz
IHVuZGVyIGRpc2N1c3Npb24gZWFybHkuIEl0IHdvdWxkIHByb3ZpZGUgdGhlIEhUVFAgV0cgd2l0
aCBhIHRlc3QgY2FzZSBmb3IgdGhlIGxheWVyZWQgYXBwcm9hY2ggdGhhdCB0aGUgSFRUUCBtZXNz
YWdlIHNpZ25hdHVyZXMNCiBkcmFmdCB0YWtlcyB0b3dhcmRzIHRoaXMgcHJvYmxlbSwgYW5kIHdv
dWxkIGFsbG93IHRoZSBPQXV0aCBXRyB0byBlbnN1cmUgdGhhdCBvdXIgdXNlIGNhc2VzIGFyZSBz
dXBwb3J0ZWQuIEFsc28sIGdpdmVuIHRoZSBpbnRlcmVzdCBpbiBEUG9QLCBJIHRoaW5rIGl0IHdp
bGwgYmUgaGVscGZ1bCBmb3IgdGhlIE9BdXRoIFdHIHRvIHNlZSB3aGF0IG1lc3NhZ2Ugc2lnbmF0
dXJlLWJhc2VkIFBvUCBtaWdodCBsb29rIGxpa2UuIEl0IG1heSBiZSBlYXNpZXINCiB0byB0YXJn
ZXQgRFBvUCBhdCBhIG5hcnJvd2VyIHNldCBvZiB1c2UgY2FzZXMgaWYgcGVvcGxlIHNlZSBhIGJy
b2FkZXIgc29sdXRpb24gaXMgY29taW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgPGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hhbm5hLWh0dHAtbWVz
c2FnZS1zaWduYXR1cmVzLTAwI3NlY3Rpb24tMSI+DQppbnRyb2R1Y3Rpb24gdG8gdGhlIEhUVFAg
TWVzc2FnZSBTaWduYXR1cmVzIGRyYWZ0PC9hPiBkZXNjcmliZXMgd2h5IFRMUyBpcyBub3QgYSB1
bml2ZXJzYWwgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFX
UyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t
OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5S
b2IgQ29yZGVzICZsdDtyb2Jjb3JkZXNAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5N
b25kYXksIEphbnVhcnkgMjAsIDIwMjAgYXQgMTA6MTkgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90
O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29t
Jmd0Ozxicj4NCjxiPkNjOiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBn
bWFpbC5jb20mZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gT0F1dGggVG9waWNzIGZv
ciBWYW5jb3V2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Tb3JyeSBmb3IgbWUgYW5zd2VyaW5nIGluIHRoaXMgZGlyZWN0IG1hbm5lciBpbnN0ZWFk
IG9mIHZpYSB0aGUgT0FVVEggbWFpbGluZyBsaXN0IG9yIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gcG9pbnQg
YSBwcmFjdGljYWwgaXNzdWUgb3V0IHdydCB0aGUgSFRUUCBzaWduYXR1cmUgc3BlYy4gSSBoYXZl
IGdvdCBwcmFjdGljYWwgZXhwZXJpZW5jZSB3aXRoIHRoZSBzcGVjIHRocm91Z2ggbXkgd29yayBm
b3IgSU5HIGluIG91ciBQU0QyIChFdXJvcGVhbiBlbGVjdHJvbmljIGJhbmtpbmcgc2NoZW1lKSBw
bGF0Zm9ybS4gV2UgaGF2ZSBpbXBsZW1lbnRlZCB0aGlzIHNwZWMgKGNhdmFnZS0xMCkNCiBpbiBv
dXIgcGxhdGZvcm0gYXMgd2VsbC4gV2UgZXhwZXJpZW5jZSBsb3RzIG9mIGlzc3VlcyB3aXRoIDNy
ZCBwYXJ0eSBkZXZlbG9wZXJzIHdobyBoYXZlIGlzc3VlcyBnZXR0aW5nIHRoZWlyIGNvZGUgcmln
aHQuIEl0IGlzIHRoZSBjYW5hbGlzYXRpb24gdGhhdCBpcyB0cm91YmxpbmcgdGhlIGFkb3B0aW9u
IGluIHByYWN0aWNlLiBQZW9wbGUgYXJlIGNvbnRpbnVvdXNseSBtYWtpbmcgbWlzdGFrZXMgd2l0
aCBzZXR0aW5nIHVwIHRoZSBwYXlsb2FkDQogZm9yIHNpZ25hdHVyZXMgLyBib2R5IGRpZ2VzdC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg
Y2FuIG9ubHkgYmUgc29sdmVkIGJ5IG1ha2luZyBhdmFpbGFibGUgcmVhZHkgbWFkZSBsaWJyYXJp
ZXMuIFRoYXQgbWlnaHQgYmUgZG9uZSB0aHJvdWdoIHZlbmRvcnMgYW5kIHRoZWlyIHNvbHV0aW9u
cyBhbmQgb25lIHdvdWxkIGVuY291bnRlciAmbmJzcDtwcm9iYWJseSBsZXNzIGludGVyb3BlcmFi
aWxpdHkgaXNzdWVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyIHVudGlsIHRoZW4gc3RpbGwgdHJvdWJsZXMgaXMgd2hh
dCBwZW9wbGUgaGF2ZSB3aXRoIHRoaXMgc3BlYy4gQXBhcnQgZm9ybSB0aGF0LCAmbmJzcDt0aGUg
c3BlYyBpcyB2ZXJ5IG11Y2ggZHJhZnQgYW5kIGFzIEkgdW5kZXJzdG9vZCBmcm9tIG9uZSBvZiB0
aGUgZHJhZnQgbWVtYmVycyBhbmQgc3RpbGwgbm90IHNlY3VyaXR5IHRlc3RlZCBhbmRzIHNvIHBl
cmhhcHMgc3RpbGwgbm90IHNlY3VyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVmb3JlIG9uZSBjYW4gYWRvcHQgYW5vdGhlciBzcGVjIGlu
dG8sIGluIHRoaXMgY2FzZSBPQXV0aCAyLjAgaXQgd291bGQgYmUgd2lzZSB0byB0YWNrbGUgdGhp
cyBmaXJzdC4gV2hpbGUgSFRUUCBzaWduaW5nIGRvZXMgaGVscCBpbiBiZXR0ZXIgYXV0aGVudGlj
YXRpbmcgYW5kIHNhZmVndWFyZGluZyBtZXNzYWdlcy90b2tlbiByZXF1ZXN0cywgdGhpcyB3aWxs
IG1ha2Uga2V5IG1hbmFnZW1lbnQgZXZlbiBtb3JlDQogaW1wb3J0YW50LiAmbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJpc2sg
dGhhdCBIVFRQIHNpZ25pbmcgaW4gT0FVVEggbWlnaHQgbWl0aWdhdGUsIGNvdWxkIHZlcnkgd2Vs
bCBiZSBmYXIgZWFzaWVyIHNvbHZlZCBieSBUTFMgMS4yIG9yIDEuMy4gVGhhdCBpcyBldmVuIGJl
dHRlciBiZWNhdXNlIHRoZSBpbXBsZW1lbnRhdGlvbnMgYXJlIHNlY3VyaXR5IHRlc3RlZCAoVExT
IDEuMiBvciBkZXBlbmRpbmcgb24gdGhlIHN1cHBsaWVyL2ltcGxlbWVudGVyIGluIHRoZSBwcm9j
ZXNzDQogb2YgKFRMUyAxLjMpIGR1ZSB0byB0aGVpciBpbXBvcnRhbmNlIGFuZCBjYW4gYmUgaW1w
bGVtZW50ZWQgaW4gYSB0PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj51cm4ga2V5Jm5ic3A7bWFu
bmVyLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVzZSBhcmUgSSZuYnNwO2JlbGlldmUmbmJzcDtpbXBv
cnRhbnQgYXR0ZW50aW9uIHBvaW50cyB0aGF0Jm5ic3A7b25lIG1pZ2h0IHRoaW5rIG92ZXIgYmVm
b3JlJm5ic3A7ZXh0ZW5kaW5nIHRoZSBPQVVUSCAyLjAgc3BlYyBldmVuJm5ic3A7ZnVydGhlciB3
aXRoIHBlcmhhcHMgdG9vIGxpdHRsZSBnYWluPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij5CZXN0Jm5ic3A7cmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Um9iIENv
cmRlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RmVhdHVyZSBFbmdpbmVlciAmbmJzcDsv
IEluZm9TZWMgc3BlY2lhbGlzdCBAIElORyBiYW5rPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMCBKYW4gMjAyMCwgYXQgMTg6MzMsIFJp
Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBh
bWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0
Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBkaXNjdXNzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1yaWNoYW5uYS1odHRwLW1lc3NhZ2Utc2lnbmF0dXJlcy0wMCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiM5NTRGNzIiPkhUVFAgTWVzc2FnZSBTaWduYXR1cmVzPC9zcGFuPjwvYT48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YXMNCiBhIHByb29m
LW9mLXBvc3Nlc3Npb24gbWVjaGFuaXNtIGZvciBPQXV0aC4gQSBkcmFmdCB3aWxsIGJlIGF2YWls
YWJsZSAoZWl0aGVyIGFzIGFuIHVwZGF0ZSB0byBkcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRw
LXJlcXVlc3Qgb3IgYXMgYSBuZXcgaW5kaXZpZHVhbCBzdWJtaXNzaW9uKS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxm
IG9mIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdt
YWlsLmNvbSI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9uZGF5LCBK
YW51YXJ5IDIwLCAyMDIwIGF0IDc6MzQgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPm9hdXRoICZsdDs8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0
OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+W09B
VVRILVdHXSBPQXV0aCBUb3BpY3MgZm9yIFZhbmNvdXZlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QWxsLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSwgbGV0IHVzIGtub3cgaWYgeW91IGhh
dmUgYW55IHRvcGljcyB0aGF0IHlvdSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYW5kIGRpc2N1c3Mg
aW4gVmFuY291dmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7UmlmYWF0ICZhbXA7IEhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_3950598EF3F148218C18DC9008C65DFDamazoncom_--


From nobody Mon Jan 20 13:15: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 557B312013D for ; Mon, 20 Jan 2020 13:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.572
X-Spam-Level: 
X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zusVxuw4eZ09 for ; Mon, 20 Jan 2020 13:15:12 -0800 (PST)
Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B49D12011D for ; Mon, 20 Jan 2020 13:15:09 -0800 (PST)
Received: by mail-yb1-xb41.google.com with SMTP id o199so390129ybc.4 for ; Mon, 20 Jan 2020 13:15:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=Xl9IFghB6G27U4/ewQup9bFp3sjQJzmn+ld6DDN1njw=; b=uM0ZriSz5ouiCXKNEFxUEOGaRYzQNAEWXjfRJuZqxKIJVnbDuulo3OpVrm707Y0/7K lH2BtHyMHPwiRilRXD3WMSyKbwwPxEGAXy1Xlzwgrt+2+JDvT/IxOb1ZwpL9Y0IPahuW FSJrjwv0l7ZG1j31EeJWJ5bxfe0iljkOr3QWdW6jwTZvA0wXWFOSoikUbOs5poX7CUI3 +E4Pdx6pMeTI7huxZsUuVuqFtHI5WPBZRt45cDIO615LjfWFV8MRoFGVrbNeRgylgjUQ QTmcleUIXPuwsTSYDPVQSmmN5ONwYCxaDutLX+E9ZSJxl+I9pSX0BgCEQpVn3kUs6Nv8 ZGqQ==
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=Xl9IFghB6G27U4/ewQup9bFp3sjQJzmn+ld6DDN1njw=; b=WmbYjZmJcjii+/0kZspdwLdsaM6NESrEZjahsCgnexmEf7Hk/PKiKWmFMkIk/DUdJF H2y1H2WuquJPLKoAjLAczpSnMFjZbcHOmD/qnncqpg5MKa/+ooHKVF7sS5xJlLDjNr2J Xais0y0eJEiFuEVY1E9uTP2txUPe+JXs1IBA37zUCAM1QkLZgtI8r7edEHTtU0eSWerq ZCSpSH7NA5+u5Uq8J4t1xrv9PqV9oBiVd3i7HpYEgOh0Va83g3JLZF0t3WshdiEPWETj vs8H/N1hIGWANTZxsxAkUuLC14FkRAVqYRzZ2HeCBjluoGH0Uq4R9Di9/4YLVWUhE4s7 aDlA==
X-Gm-Message-State: APjAAAWSglnG5/wdIqd3e2PBauVH/0tb8771CtMXbVQCvO2JDIZkkqL2 ulK8Ou6/yriJPHFk4gBmShHOUDxfYqKFRR1Gug7ZsOhBtOQ=
X-Google-Smtp-Source: APXvYqxzvBfMSGzSysySw5Kj+EgjD177wfoA2TsB4R6orfFgxO4NRnGFaYd1csQMvXGdu59Sr21APfysGq1uc2hQY5U=
X-Received: by 2002:a25:5944:: with SMTP id n65mr1215719ybb.291.1579554907643;  Mon, 20 Jan 2020 13:15:07 -0800 (PST)
MIME-Version: 1.0
From: Schlampa Schlampa 
Date: Mon, 20 Jan 2020 22:14:57 +0100
Message-ID: 
To: OAuth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002c6362059c98c94e"
Archived-At: 
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 21:15:13 -0000

--0000000000002c6362059c98c94e
Content-Type: text/plain; charset="UTF-8"



--0000000000002c6362059c98c94e
Content-Type: text/html; charset="UTF-8"




--0000000000002c6362059c98c94e--


From nobody Mon Jan 20 13:37: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 4197A120232 for ; Mon, 20 Jan 2020 13:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 CYRGBctphOtk for ; Mon, 20 Jan 2020 13:37:19 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870A412011D for ; Mon, 20 Jan 2020 13:37:19 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id t2so1084462wrr.1 for ; Mon, 20 Jan 2020 13:37:19 -0800 (PST)
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=tjBJ9WLq7z27DVXl6kzpv2Qsq5bSQSyixOFsv6m6gkQ=; b=OA5/2jKMNRsuH3Xp0aJHny8Fdn+9j+DK1MVwstoJwIFJjvBJHSwAKb0GiTb1LxR9gb tX/+JneIbxqfreY9IdD76/hCwpd0K3VHGDJk1TY7UwT79LcA1SdzR4C3U2AwtQ9iUnhm EaCAahwvXFj0Io9DXgx4K1PBOzYT1TTJk6pbix0Og0U5oCPxtqB1+jbZr97pKF23FAiC 0o4fROatw1KiWzuy12Gm5QdCMOMhg2MUGqymipzgKwx7FGkRKt+FDalySnXne4S2kfLW qQp5YtiY3pU7xvkz+TXUmi2M9DM1xly3+neDWma/hBpuCknYRMahCu9nMBbRsU85n6tg oeAg==
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=tjBJ9WLq7z27DVXl6kzpv2Qsq5bSQSyixOFsv6m6gkQ=; b=HmBuvxLV8ydwPkOCjnNyNAqJUGPCFIO6uWeS3hT1suEPygyy9bJ1ppcwdsyuZcqbne q+7pg+1JewMZBIQvzrsw9fkymMfYI4LPnuB87WR4Fc8wIxgCK0d3QaB6uFVAEHqwdMUc /ZGnH+KcZEu7DpBtCyXqiOdudab3ErhbrsHaZ0phwr9mfoby4LOwBQl6y+XgKHMNIjPQ v5xjUKva0Vr4vdC8x+HtnXznXkH1sMQ2S2uNE4sKcFtrO3P+7tr8SbJVtDtLQvlzI7mW OXLYuwAZgPg1w7/sY3BQ041LEuM07mg1dulHgDUujHtgya/pe0PIy4viLoAyJOFrVC50 UZHg==
X-Gm-Message-State: APjAAAWZQsbiS9bSZlH+r9MJwvFPFzNT5L/Ls/mkQ0PaIWvn4bWHylc3 gGRphI6Zt1hodrSDrPpxHR7MYo2UHwA=
X-Google-Smtp-Source: APXvYqwhoMAnp3ZU/Yf7OpvgUkkHRTptBOfrI0CbkE+wLgx0qJHkqCW+Hg5Mz35vaIxNR3aoWwaWtw==
X-Received: by 2002:a05:6000:cf:: with SMTP id q15mr1391377wrx.393.1579556237967;  Mon, 20 Jan 2020 13:37:17 -0800 (PST)
Received: from ?IPv6:2a02:a443:c7cb:1:6daa:a695:f46c:5b08? ([2a02:a443:c7cb:1:6daa:a695:f46c:5b08]) by smtp.gmail.com with ESMTPSA id w20sm803365wmk.34.2020.01.20.13.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 13:37:17 -0800 (PST)
From: Rob Cordes 
Message-Id: <149B3074-EF98-46D0-8860-C5F93A2D580F@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BA55084-B8CD-4D79-B259-EB7FBCAE1D5F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 20 Jan 2020 22:37:16 +0100
In-Reply-To: <3950598E-F3F1-4821-8C18-DC9008C65DFD@amazon.com>
Cc: Rifaat Shekh-Yusef , oauth 
To: "Richard Backman, Annabelle" 
References:  <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com> <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com> <3950598E-F3F1-4821-8C18-DC9008C65DFD@amazon.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER]  OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 21:37:22 -0000

--Apple-Mail=_4BA55084-B8CD-4D79-B259-EB7FBCAE1D5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Annabelle,


Sure TLS is not th one size fits all but if you swap out Client Y signs =
/ authenticates message A to recipient X  by:  Client  Y uses TLS for =
authentication of the source (itself), integrity of data / =
communications and  even confidentiality (not really needed in our HTTP =
signing use case)  where TLS is initiated and handled by the client Y  =
itself (native libs or proxy at the same host(s) then you have precisely =
that what HTTP Message signing should do. (authenticity,  integrity and =
as a bonus confidentiality).=20


That said, one can opt for HTTP signing if one wants to, except it is =
not secure for now and is at present for many developers a nuisance use  =
as it turns out. If you do not want  or cannot deal with TLS tunnels and =
yes indeed TLS connection re-use, by all means go ahead. I would advise =
my customers to try TLS first because it is proven and simple to =
implement and so easy (cheap ;-) ) to support. It is always worthwhile =
to at least try to get Infra on board to see if one can go the TLS route =
first and if that fails=E2=80=A6 well then HTTP signing or accept the =
risk.

The issues we have at ING with 3rd parties cause us to back down from =
using it in general but still for those API=E2=80=99s wanting to have =
better assurance than otherwise. We do not want to provide our own libs =
to external parties for obvious (legal mostly) reasons. We did not go =
the TLS route at first, that turned out a mistake ;-).=20


Let me conclude that I always am quite happy to see alternatives popping =
up and existing protocols being continuously enhanced. For this I thank =
you and others to continue developing protocol implementations such as =
HTTP message signing.


Regards,

Rob


> On 20 Jan 2020, at 21:50, Richard Backman, Annabelle =
 wrote:
>=20
> introduction to the HTTP Message Signatures draft =


--Apple-Mail=_4BA55084-B8CD-4D79-B259-EB7FBCAE1D5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Annabelle,


Sure TLS is not th one size fits all =
but if you swap out Client Y signs / authenticates message A to =
recipient X  by:  Client  Y uses TLS for authentication =
of the source (itself), integrity of data / communications and =
 even confidentiality (not really needed in our HTTP signing use =
case)  where TLS is initiated and handled by the client Y =
 itself (native libs or proxy at the same host(s) then you have =
precisely that what HTTP Message signing should do. (authenticity, =
 integrity and as a bonus confidentiality). 


That said, one can opt for HTTP signing if one wants to, =
except it is not secure for now and is at present for many developers a =
nuisance use  as it turns out. If you do not want  or cannot =
deal with TLS tunnels and yes indeed TLS connection re-use, by all means =
go ahead. I would advise my customers to try TLS first because it is =
proven and simple to implement and so easy (cheap ;-) ) to support. It =
is always worthwhile to at least try to get Infra on board to see if one =
can go the TLS route first and if that fails=E2=80=A6 well then HTTP =
signing or accept the risk.

The issues we have at ING with 3rd parties cause us to back =
down from using it in general but still for those API=E2=80=99s wanting =
to have better assurance than otherwise. We do not want to provide our =
own libs to external parties for obvious (legal mostly) reasons. We did =
not go the TLS route at first, that turned out a mistake =
;-). 


Let me conclude that I always am quite =
happy to see alternatives popping up and existing protocols being =
continuously enhanced. For this I thank you and others to continue =
developing protocol implementations such as HTTP message =
signing.


Regards,

Rob


On 20 Jan 2020, at 21:50, Richard Backman, Annabelle <richanna@amazon.com>=
 wrote:

introduction to the HTTP =
Message Signatures draft

=

--Apple-Mail=_4BA55084-B8CD-4D79-B259-EB7FBCAE1D5F--


From nobody Mon Jan 20 14:09: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 1B2BF120045 for ; Mon, 20 Jan 2020 14:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z92ig_nNYvD for ; Mon, 20 Jan 2020 14:09:11 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFAA120018 for ; Mon, 20 Jan 2020 14:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579558151; x=1611094151; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CJcNH291ur/ZMXAcpTEu26KC47esHMZS0/nxYz8jqgw=; b=ahgR3EbRX0KuJQmLvlmVE+46X7NAf8nnRMBk2nRDv2v1zShXoAnxivew 2/Q/dxaX8zIrOjxwu3nh5WdxG7Q/fdkEJW+NVxjKX6fMMomLzmeHqvlJ3 kOGAw8LjNDigQhXg1Hu8pxwj3plBMwXuCRj4UprWpVN+7IYVe2RtOV5ZA Q=;
IronPort-SDR: IRLlxGiF9iIBUrM6ayxRWSZov7BfX5EipiB47/lrNFIaPh2/vddZKWbKBy7BgIils6k5AxcZlL WLeXdkqx/T/A==
X-IronPort-AV: E=Sophos; i="5.70,343,1574121600"; d="scan'208,217"; a="11469235"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 20 Jan 2020 22:08:59 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com (Postfix) with ESMTPS id 598C7A23C9; Mon, 20 Jan 2020 22:08:58 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 22:08:57 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 22:08:56 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 20 Jan 2020 22:08:56 +0000
From: "Richard Backman, Annabelle" 
To: Rifaat Shekh-Yusef , oauth 
Thread-Topic: [UNVERIFIED SENDER] [OAUTH-WG] OAuth Topics for Vancouver
Thread-Index: AQHVz9noSMX41D1sF0OdpKI6rvVIGKfzlpoA
Date: Mon, 20 Jan 2020 22:08:56 +0000
Message-ID: <670F3DAF-2FAD-42F5-AD6D-E158F05D396A@amazon.com>
References:  <0BA39EEA-B790-4B3A-A51F-4D1EE5B5C937@amazon.com> <94883708-884E-48E5-A464-1FE04A4AD5E9@gmail.com> <3950598E-F3F1-4821-8C18-DC9008C65DFD@amazon.com> <149B3074-EF98-46D0-8860-C5F93A2D580F@gmail.com>
In-Reply-To: <149B3074-EF98-46D0-8860-C5F93A2D580F@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.224]
Content-Type: multipart/alternative; boundary="_000_670F3DAF2FAD42F5AD6DE158F05D396Aamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER]  OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 22:09:15 -0000

--_000_670F3DAF2FAD42F5AD6DE158F05D396Aamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG8gYmUgaG9uZXN0IEnigJltIHNvbWV3aGF0IHRha2VuIGFiYWNrIGJ5IHRoaXMgcmVhY3Rpb24u
IFRoZSByZXF1ZXN0IHdhcyBmb3IgdGltZSB0byBkaXNjdXNzIGFuIGFsdGVybmF0aXZlIFBvUCBt
ZWNoYW5pc20gZmFjZS10by1mYWNlLiBUaGlzIGlzIGEgdG9waWMgd2hpY2ggaGFzIGNvbWUgdXAg
aW4gdGhlIGNvbnRleHQgb2Ygb3RoZXIgd29yayAoZS5nLiwgRFBvUCkgYXQgc2V2ZXJhbCByZWNl
bnQgSUVURiBtZWV0aW5ncywgaW5jbHVkaW5nIHRoZSBsYXN0IG9uZSBpbiBTaW5nYXBvcmUuIFdo
aWxlIEkgcmVjb2duaXplIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGEgbG90IG9uIGl0cyBw
bGF0ZSBhbmQgbmVlZHMgdG8gYWxsb2NhdGUgdGltZSBqdWRpY2lvdXNseSwgaXQgc2VlbXMgY2xl
YXIgdG8gbWUgdGhhdCB0aGlzIGlzIGJvdGggdGltZWx5IGFuZCByZWxldmFudC4NCg0KVW5sZXNz
IHRoZSBjaGFpcnMgaW5kaWNhdGUgdGhhdCB0aGV5IHJlcXVpcmUgZnVydGhlciBqdXN0aWZpY2F0
aW9uIGZvciB0aGUgdGltZSBzbG90LCBJ4oCZbSBnb2luZyB0byBzdG9wIGNsdXR0ZXJpbmcgdGhp
cyB0aHJlYWQgd2l0aCBkZWZlbnNlcyBvZiBhIGRyYWZ0IHRoYXQgZG9lc27igJl0IGV4aXN0IHll
dC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpG
cm9tOiBSb2IgQ29yZGVzIDxyb2Jjb3JkZXNAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBKYW51
YXJ5IDIwLCAyMDIwIGF0IDE6MzggUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi
IDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0Lmll
dGZAZ21haWwuY29tPiwgb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVTlZF
UklGSUVEIFNFTkRFUl0gW09BVVRILVdHXSBPQXV0aCBUb3BpY3MgZm9yIFZhbmNvdXZlcg0KDQpI
aSBBbm5hYmVsbGUsDQoNCg0KU3VyZSBUTFMgaXMgbm90IHRoIG9uZSBzaXplIGZpdHMgYWxsIGJ1
dCBpZiB5b3Ugc3dhcCBvdXQgQ2xpZW50IFkgc2lnbnMgLyBhdXRoZW50aWNhdGVzIG1lc3NhZ2Ug
QSB0byByZWNpcGllbnQgWCAgYnk6ICBDbGllbnQgIFkgdXNlcyBUTFMgZm9yIGF1dGhlbnRpY2F0
aW9uIG9mIHRoZSBzb3VyY2UgKGl0c2VsZiksIGludGVncml0eSBvZiBkYXRhIC8gY29tbXVuaWNh
dGlvbnMgYW5kICBldmVuIGNvbmZpZGVudGlhbGl0eSAobm90IHJlYWxseSBuZWVkZWQgaW4gb3Vy
IEhUVFAgc2lnbmluZyB1c2UgY2FzZSkgIHdoZXJlIFRMUyBpcyBpbml0aWF0ZWQgYW5kIGhhbmRs
ZWQgYnkgdGhlIGNsaWVudCBZICBpdHNlbGYgKG5hdGl2ZSBsaWJzIG9yIHByb3h5IGF0IHRoZSBz
YW1lIGhvc3QocykgdGhlbiB5b3UgaGF2ZSBwcmVjaXNlbHkgdGhhdCB3aGF0IEhUVFAgTWVzc2Fn
ZSBzaWduaW5nIHNob3VsZCBkby4gKGF1dGhlbnRpY2l0eSwgIGludGVncml0eSBhbmQgYXMgYSBi
b251cyBjb25maWRlbnRpYWxpdHkpLg0KDQoNClRoYXQgc2FpZCwgb25lIGNhbiBvcHQgZm9yIEhU
VFAgc2lnbmluZyBpZiBvbmUgd2FudHMgdG8sIGV4Y2VwdCBpdCBpcyBub3Qgc2VjdXJlIGZvciBu
b3cgYW5kIGlzIGF0IHByZXNlbnQgZm9yIG1hbnkgZGV2ZWxvcGVycyBhIG51aXNhbmNlIHVzZSAg
YXMgaXQgdHVybnMgb3V0LiBJZiB5b3UgZG8gbm90IHdhbnQgIG9yIGNhbm5vdCBkZWFsIHdpdGgg
VExTIHR1bm5lbHMgYW5kIHllcyBpbmRlZWQgVExTIGNvbm5lY3Rpb24gcmUtdXNlLCBieSBhbGwg
bWVhbnMgZ28gYWhlYWQuIEkgd291bGQgYWR2aXNlIG15IGN1c3RvbWVycyB0byB0cnkgVExTIGZp
cnN0IGJlY2F1c2UgaXQgaXMgcHJvdmVuIGFuZCBzaW1wbGUgdG8gaW1wbGVtZW50IGFuZCBzbyBl
YXN5IChjaGVhcCA7LSkgKSB0byBzdXBwb3J0LiBJdCBpcyBhbHdheXMgd29ydGh3aGlsZSB0byBh
dCBsZWFzdCB0cnkgdG8gZ2V0IEluZnJhIG9uIGJvYXJkIHRvIHNlZSBpZiBvbmUgY2FuIGdvIHRo
ZSBUTFMgcm91dGUgZmlyc3QgYW5kIGlmIHRoYXQgZmFpbHPigKYgd2VsbCB0aGVuIEhUVFAgc2ln
bmluZyBvciBhY2NlcHQgdGhlIHJpc2suDQoNClRoZSBpc3N1ZXMgd2UgaGF2ZSBhdCBJTkcgd2l0
aCAzcmQgcGFydGllcyBjYXVzZSB1cyB0byBiYWNrIGRvd24gZnJvbSB1c2luZyBpdCBpbiBnZW5l
cmFsIGJ1dCBzdGlsbCBmb3IgdGhvc2UgQVBJ4oCZcyB3YW50aW5nIHRvIGhhdmUgYmV0dGVyIGFz
c3VyYW5jZSB0aGFuIG90aGVyd2lzZS4gV2UgZG8gbm90IHdhbnQgdG8gcHJvdmlkZSBvdXIgb3du
IGxpYnMgdG8gZXh0ZXJuYWwgcGFydGllcyBmb3Igb2J2aW91cyAobGVnYWwgbW9zdGx5KSByZWFz
b25zLiBXZSBkaWQgbm90IGdvIHRoZSBUTFMgcm91dGUgYXQgZmlyc3QsIHRoYXQgdHVybmVkIG91
dCBhIG1pc3Rha2UgOy0pLg0KDQoNCkxldCBtZSBjb25jbHVkZSB0aGF0IEkgYWx3YXlzIGFtIHF1
aXRlIGhhcHB5IHRvIHNlZSBhbHRlcm5hdGl2ZXMgcG9wcGluZyB1cCBhbmQgZXhpc3RpbmcgcHJv
dG9jb2xzIGJlaW5nIGNvbnRpbnVvdXNseSBlbmhhbmNlZC4gRm9yIHRoaXMgSSB0aGFuayB5b3Ug
YW5kIG90aGVycyB0byBjb250aW51ZSBkZXZlbG9waW5nIHByb3RvY29sIGltcGxlbWVudGF0aW9u
cyBzdWNoIGFzIEhUVFAgbWVzc2FnZSBzaWduaW5nLg0KDQoNClJlZ2FyZHMsDQoNClJvYg0KDQoN
Cg0KT24gMjAgSmFuIDIwMjAsIGF0IDIxOjUwLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8
cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0K
DQppbnRyb2R1Y3Rpb24gdG8gdGhlIEhUVFAgTWVzc2FnZSBTaWduYXR1cmVzIGRyYWZ0PGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoYW5uYS1odHRwLW1lc3NhZ2Utc2lnbmF0
dXJlcy0wMCNzZWN0aW9uLTE+DQoNCg==

--_000_670F3DAF2FAD42F5AD6DE158F05D396Aamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1578E1C254911D4C84C0AEE892ABA44B@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs
IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBiZSBob25lc3Qg
SeKAmW0gc29tZXdoYXQgdGFrZW4gYWJhY2sgYnkgdGhpcyByZWFjdGlvbi4gVGhlIHJlcXVlc3Qg
d2FzIGZvciB0aW1lIHRvIGRpc2N1c3MgYW4gYWx0ZXJuYXRpdmUgUG9QIG1lY2hhbmlzbSBmYWNl
LXRvLWZhY2UuIFRoaXMgaXMgYSB0b3BpYyB3aGljaCBoYXMgY29tZSB1cCBpbiB0aGUgY29udGV4
dCBvZiBvdGhlciB3b3JrIChlLmcuLCBEUG9QKSBhdCBzZXZlcmFsIHJlY2VudCBJRVRGIG1lZXRp
bmdzLA0KIGluY2x1ZGluZyB0aGUgbGFzdCBvbmUgaW4gU2luZ2Fwb3JlLiBXaGlsZSBJIHJlY29n
bml6ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBhIGxvdCBvbiBpdHMgcGxhdGUgYW5kIG5l
ZWRzIHRvIGFsbG9jYXRlIHRpbWUganVkaWNpb3VzbHksIGl0IHNlZW1zIGNsZWFyIHRvIG1lIHRo
YXQgdGhpcyBpcyBib3RoIHRpbWVseSBhbmQgcmVsZXZhbnQuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlVubGVzcyB0aGUgY2hhaXJzIGluZGljYXRlIHRoYXQgdGhleSByZXF1aXJlIGZ1cnRoZXIg
anVzdGlmaWNhdGlvbiBmb3IgdGhlIHRpbWUgc2xvdCwgSeKAmW0gZ29pbmcgdG8gc3RvcCBjbHV0
dGVyaW5nIHRoaXMgdGhyZWFkIHdpdGggZGVmZW5zZXMgb2YgYSBkcmFmdCB0aGF0IGRvZXNu4oCZ
dCBleGlzdCB5ZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBS
aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvYiBDb3JkZXMgJmx0O3JvYmNvcmRl
c0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAyMCwgMjAy
MCBhdCAxOjM4IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFi
ZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlJp
ZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwuY29tJmd0Oywgb2F1dGggJmx0
O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1VOVkVSSUZJRUQg
U0VOREVSXSBbT0FVVEgtV0ddIE9BdXRoIFRvcGljcyBmb3IgVmFuY291dmVyPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFubmFiZWxsZSwg
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUgVExT
IGlzIG5vdCB0aCBvbmUgc2l6ZSBmaXRzIGFsbCBidXQgaWYgeW91IHN3YXAgb3V0IENsaWVudCBZ
IHNpZ25zIC8gYXV0aGVudGljYXRlcyBtZXNzYWdlIEEgdG8gcmVjaXBpZW50IFggJm5ic3A7Ynk6
ICZuYnNwO0NsaWVudCAmbmJzcDtZIHVzZXMgVExTIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUg
c291cmNlIChpdHNlbGYpLCBpbnRlZ3JpdHkgb2YgZGF0YSAvIGNvbW11bmljYXRpb25zIGFuZCAm
bmJzcDtldmVuIGNvbmZpZGVudGlhbGl0eQ0KIChub3QgcmVhbGx5IG5lZWRlZCBpbiBvdXIgSFRU
UCBzaWduaW5nIHVzZSBjYXNlKSAmbmJzcDt3aGVyZSBUTFMgaXMgaW5pdGlhdGVkIGFuZCBoYW5k
bGVkIGJ5IHRoZSBjbGllbnQgWSAmbmJzcDtpdHNlbGYgKG5hdGl2ZSBsaWJzIG9yIHByb3h5IGF0
IHRoZSBzYW1lIGhvc3QocykgdGhlbiB5b3UgaGF2ZSBwcmVjaXNlbHkgdGhhdCB3aGF0IEhUVFAg
TWVzc2FnZSBzaWduaW5nIHNob3VsZCBkby4gKGF1dGhlbnRpY2l0eSwgJm5ic3A7aW50ZWdyaXR5
IGFuZCBhcyBhIGJvbnVzDQogY29uZmlkZW50aWFsaXR5KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQsIG9uZSBj
YW4gb3B0IGZvciBIVFRQIHNpZ25pbmcgaWYgb25lIHdhbnRzIHRvLCBleGNlcHQgaXQgaXMgbm90
IHNlY3VyZSBmb3Igbm93IGFuZCBpcyBhdCBwcmVzZW50IGZvciBtYW55IGRldmVsb3BlcnMgYSBu
dWlzYW5jZSB1c2UgJm5ic3A7YXMgaXQgdHVybnMgb3V0LiBJZiB5b3UgZG8gbm90IHdhbnQgJm5i
c3A7b3IgY2Fubm90IGRlYWwgd2l0aCBUTFMgdHVubmVscyBhbmQgeWVzIGluZGVlZCBUTFMgY29u
bmVjdGlvbg0KIHJlLXVzZSwgYnkgYWxsIG1lYW5zIGdvIGFoZWFkLiBJIHdvdWxkIGFkdmlzZSBt
eSBjdXN0b21lcnMgdG8gdHJ5IFRMUyBmaXJzdCBiZWNhdXNlIGl0IGlzIHByb3ZlbiBhbmQgc2lt
cGxlIHRvIGltcGxlbWVudCBhbmQgc28gZWFzeSAoY2hlYXAgOy0pICkgdG8gc3VwcG9ydC4gSXQg
aXMgYWx3YXlzIHdvcnRod2hpbGUgdG8gYXQgbGVhc3QgdHJ5IHRvIGdldCBJbmZyYSBvbiBib2Fy
ZCB0byBzZWUgaWYgb25lIGNhbiBnbyB0aGUgVExTIHJvdXRlIGZpcnN0DQogYW5kIGlmIHRoYXQg
ZmFpbHPigKYgd2VsbCB0aGVuIEhUVFAgc2lnbmluZyBvciBhY2NlcHQgdGhlIHJpc2suPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpc3N1
ZXMgd2UgaGF2ZSBhdCBJTkcgd2l0aCAzcmQgcGFydGllcyBjYXVzZSB1cyB0byBiYWNrIGRvd24g
ZnJvbSB1c2luZyBpdCBpbiBnZW5lcmFsIGJ1dCBzdGlsbCBmb3IgdGhvc2UgQVBJ4oCZcyB3YW50
aW5nIHRvIGhhdmUgYmV0dGVyIGFzc3VyYW5jZSB0aGFuIG90aGVyd2lzZS4gV2UgZG8gbm90IHdh
bnQgdG8gcHJvdmlkZSBvdXIgb3duIGxpYnMgdG8gZXh0ZXJuYWwgcGFydGllcyBmb3Igb2J2aW91
cw0KIChsZWdhbCBtb3N0bHkpIHJlYXNvbnMuIFdlIGRpZCBub3QgZ28gdGhlIFRMUyByb3V0ZSBh
dCBmaXJzdCwgdGhhdCB0dXJuZWQgb3V0IGEgbWlzdGFrZSA7LSkuJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IG1lIGNvbmNs
dWRlIHRoYXQgSSBhbHdheXMgYW0gcXVpdGUgaGFwcHkgdG8gc2VlIGFsdGVybmF0aXZlcyBwb3Bw
aW5nIHVwIGFuZCBleGlzdGluZyBwcm90b2NvbHMgYmVpbmcgY29udGludW91c2x5IGVuaGFuY2Vk
LiBGb3IgdGhpcyBJIHRoYW5rIHlvdSBhbmQgb3RoZXJzIHRvIGNvbnRpbnVlIGRldmVsb3Bpbmcg
cHJvdG9jb2wgaW1wbGVtZW50YXRpb25zIHN1Y2ggYXMgSFRUUCBtZXNzYWdlIHNpZ25pbmcuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Um9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IDIwIEphbiAyMDIwLCBhdCAyMTo1MCwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0Ozxh
IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoYW5uYS1odHRwLW1lc3Nh
Z2Utc2lnbmF0dXJlcy0wMCNzZWN0aW9uLTEiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlu
dHJvZHVjdGlvbiB0byB0aGUgSFRUUCBNZXNzYWdlIFNpZ25hdHVyZXMgZHJhZnQ8L3NwYW4+PC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_670F3DAF2FAD42F5AD6DE158F05D396Aamazoncom_--


From nobody Mon Jan 20 14:10: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 DA1DD120045 for ; Mon, 20 Jan 2020 14:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.572
X-Spam-Level: 
X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1EiI_dBYFSb for ; Mon, 20 Jan 2020 14:10:03 -0800 (PST)
Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CF3120018 for ; Mon, 20 Jan 2020 14:10:03 -0800 (PST)
Received: by mail-yw1-xc42.google.com with SMTP id l14so527168ywj.9 for ; Mon, 20 Jan 2020 14:10:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=ULKJMjqovRc8Rd5+a2BayfDvNw+htSTzlYaX2rxQkOs=; b=Smh4MZM48ecUBj3TiWMi9cc/8OCyUwlap1To5fq+Su5gZzOhSfVBLcMNHSL+mWWud2 sXBivuOmjbyDBcul9MyLOwTXv0lsPhcizrVRxdJ3ii6L8ZufPBQ0mmW0i4b+u5IeFcs7 jT1/Ugq9Dl00ym7TbLq4nqaK3pEs2M/QwK301a7GsVnSp8hdTV4UWJnDVpbra1pWudTS NVAXyFaP8m/7oeS8VEiQ2amxze4KB8fkgejgUYnyUw4OQCBuDHN3OAL621YDPYul8GvT KIDUBluyCxeZfqUFBRiHSQIRtV0sigRLn313TKRiKTgirzDrQGol7DeIF3eQ4geii1Dk EaYw==
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=ULKJMjqovRc8Rd5+a2BayfDvNw+htSTzlYaX2rxQkOs=; b=n7Lja0vltbjxIPQBVwdlhuVkoEy/dqc6wan+WMr1Sf0iqjUXSWDjsPD2MRtbOr9BrT jvoqyAucV9g1TxIMGofo6eHAPYiSG2oE/LvlC/5+ZOXXhHL8VEWaKTFoydv0hp/rj+hi Y+ijzSEHa2wanhsPAAFXmMals8GuhpHGB/8uV/JpJime/fUo9f77htFT1Ft2HHqK9n/Y CYyPrWTlkJn2Zkb1X71EMLIEQ/rRyjmNYG7IbhOGqE5hdFo5y55mtiqzzaQIwxoEQFcY rK17kg3JRURPiMXjEEfTWyewEJreEOYm3dyNlEqBKiItit/JdaLHMDIlrW+7yIjLsl/c tjCQ==
X-Gm-Message-State: APjAAAWhE0JyjIqVUOq8hRceNJdjvgkTJH5e4uf7nkCGDKmTM6wmbdwZ iUh/OhTKNbSt2pq9Fw9Utem4Yys90C1lVT+b3eOKkmpLS3A=
X-Google-Smtp-Source: APXvYqyLy+m3R70XOYyErkdBAtbe7Go4gSiv7ZcJaT53sd0WrF5Gv/eoRdWl2kBfVxD5HKTLQDkXgL3ralzFhDhVKn0=
X-Received: by 2002:a0d:cc55:: with SMTP id o82mr981040ywd.426.1579558201636;  Mon, 20 Jan 2020 14:10:01 -0800 (PST)
MIME-Version: 1.0
From: Schlampa Schlampa 
Date: Mon, 20 Jan 2020 23:09:51 +0100
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000082bb71059c998d67"
Archived-At: 
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 22:10:04 -0000

--00000000000082bb71059c998d67
Content-Type: text/plain; charset="UTF-8"



--00000000000082bb71059c998d67
Content-Type: text/html; charset="UTF-8"




--00000000000082bb71059c998d67--


From nobody Mon Jan 20 14:10: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 98385120857 for ; Mon, 20 Jan 2020 14:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level: 
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 BVVVD6isvXwG for ; Mon, 20 Jan 2020 14:10:09 -0800 (PST)
Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A24A120841 for ; Mon, 20 Jan 2020 14:10:09 -0800 (PST)
Received: by mail-yb1-xb42.google.com with SMTP id k15so436253ybd.10 for ; Mon, 20 Jan 2020 14:10:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=jLCL6+4AHpumJpYRcew19RSIKbZWfb8Y2IE1EyhVsjg=; b=Dgu8EKXM+XmbxImBwl9I8FoyfM1F4EBk/kQo0Ecj/UaKLLl3VQ2hke2Rr/dJho0ewD ywC+3GYR8gvYjCYi5YuARundJY3IFcZnw7XU4H0fJc+ay7gxr7TnFTUAxJZzRc/2O8M8 Ggvvn5sTXo5jd+ToTFL38652H5+gXjN/FqJl2CtBlxEkmPck+isg7nlCNIgqM66T8t3Q bmWS6t199nKfAxPV4Xi+Vac3gSwzPKa6y/YBx9M+z0pFoI77hW/ZDWBAIQL2AVWL5q4N 36PYH7aZ0+HiyjhHhqkd8ikeWeM5/toDMuoPVAkP0ddOw5N4N4gQRAyd5y0cPXZI897U a2Gw==
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=jLCL6+4AHpumJpYRcew19RSIKbZWfb8Y2IE1EyhVsjg=; b=FVfXqTe+vRgo/0UfJpYwBFFQ+nhTx5UvLaIjUyAHg5rHTO0SKMF/M1RF7t6MzJOUlE GwWzMG3VGGIpqbJWY49xpVexbTrNcbcEjb45PB5f3sOSayRaa/+GJbjMJFYMMc3ZFZy3 K57GHQiTIVxLrw0w2JxymzvLwmgP1zfv7wNaS8gSZNHkGGvZJV9jIuMFnd85KiQ7RyM/ 9GrIxUrNJja8ugW4/x4rH7sOxIWPMzFIImwUtPtREkClgvbrk8BPEqJEq3jouoO5UBat tHHq7523//Lt7JITdeqp70h3gGjv3iT+UPIWNaaxuBQBd/HSl15zf3IPiL3+EIlnD8Tb tfxw==
X-Gm-Message-State: APjAAAUqf1CKkoOYHL2Sn6xZcUmpAjzlSqAyOJjdX6zfu38MoS7dwdT3 FORwLT49PODT3M1v1wNe/9RinvSb2EWVwz7CIDXSJKgwVCA=
X-Google-Smtp-Source: APXvYqwS/l8rPYSyA4wIKHZipZ2PVLXRisqZTlWCmdw0GVRs6NZr8HuMCEnJDcN8Cp7wLLU2cqQi25HrXq+WPwV3jUo=
X-Received: by 2002:a25:5944:: with SMTP id n65mr1353410ybb.291.1579558208189;  Mon, 20 Jan 2020 14:10:08 -0800 (PST)
MIME-Version: 1.0
From: Schlampa Schlampa 
Date: Mon, 20 Jan 2020 23:09:57 +0100
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e6b857059c998dbc"
Archived-At: 
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 20 Jan 2020 22:10:17 -0000

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

https://adguard.com/de/versions/android/release.html?utm_source=android&utm_medium=activity_about&utm_campaign=versionhistory

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



--000000000000e6b857059c998dbc--


From nobody Mon Jan 20 16:37: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 B33B3120835 for ; Mon, 20 Jan 2020 16:37:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N-8ZwsVCyZ0 for ; Mon, 20 Jan 2020 16:37:08 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5548120832 for ; Mon, 20 Jan 2020 16:37:07 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id z18so748578lfe.2 for ; Mon, 20 Jan 2020 16:37:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DR64zbHOLaPfD1gKmuFjaHc//hjO62pUkBdvLcf0uWI=; b=intj1EhQ5yjP9l9IFhGQ7WTsJXxy/BBXMW6owR7r6fnxgQ12fIrNKKx5h13tfV4SNg bgPVCdSwhmvUVCgauP+pYjw3Zwp7ZPeijbOvt5aqmj5jnp+rOieR5dWLtJi+vqDtywmb UME6yShF2HbwrkB0bMySxtrjPpe07MBw8GJJaNs1jYX5Jx+hz7aTlFb4FOXcjcWKHxzw UaAUG4NlwxucyPVDRN08hDBkDTV4t7OfxgoUJqogAtwShgPUA6HtFp9wNmTydGgwTvyt YsgYdGk7owWnRGvez11cPiD5LAaggVdP/HL+mJZwZ31Eu3eKoDsV5cCSanZ1Ucu7xljE 53HA==
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=DR64zbHOLaPfD1gKmuFjaHc//hjO62pUkBdvLcf0uWI=; b=HDVQOEIEUua9uLO+omw14YsUS5fnSUIWhiF3Yh0QSZIp1beqEuxTsPPJs0KrvhB77W FmjsiKhAhjMmg64PunNpqonbf4Xb0H0zh0s95AFNZz3ge3ctFqHSHXRy8Gc/mlvI8Sn3 QUpvDkhTNk8KFNWKqEAa6IGxFUeizeIq9MHu73Ur06K1peZYbzPL8hnNlppfuz8IwEe3 wfhxOVqey0pkPsCdmPULnKfh8mgDNi16hyn8MeEeRvOZtetD3PqO49/c7XlVXfzray87 ZBGy6rV77B1iuVkIbQ95UCZFmXjAL8uYg3ldxb22rvA4wrSsoVrbyE3EnM0oQUW7WW56 3paA==
X-Gm-Message-State: APjAAAVMlmi8ViIHtbq1TQTgl9qTWpjBze301IE3S0oOSFnecoiPQDAi J92ES6nUrBZl08Mo2X0y515AjxKm2vxX5O8nVIE=
X-Google-Smtp-Source: APXvYqz33kNbd4eH0TFO4UborbO3VwYYFlPeAQsJXD/ieQdMkUp/GBHgHFGYBmvA2lc62AOqLf8Sz6fVx0hisRrkr9Y=
X-Received: by 2002:a19:8456:: with SMTP id g83mr1104495lfd.0.1579567025878; Mon, 20 Jan 2020 16:37:05 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 20 Jan 2020 16:36:53 -0800
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000079fc66059c9b9bf5"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 00:37:10 -0000

--00000000000079fc66059c9b9bf5
Content-Type: text/plain; charset="UTF-8"

I'd like 5 minutes to see what the interest in Reciprocal OAuth is, if any.

On Mon, Jan 20, 2020 at 7:33 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to present
> and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I'd like 5 minutes to see what the interest in Recipro=
cal OAuth is, if any.

On Mon, Jan 20, 2020 at 7:33 AM Rifaat Shekh-Yusef <=
;rifaat.ietf@gmail.com> wro=
te:
All,

Please, let us know if you have any topics tha=
t you would like to present and discuss in Vancouver.

<=
div>Regards,
=C2=A0Rifaat & Hannes


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



--00000000000079fc66059c9b9bf5--


From nobody Tue Jan 21 00:43: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 0B0F1120025 for ; Tue, 21 Jan 2020 00:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Pk2Pz9z-Ju1a for ; Tue, 21 Jan 2020 00:43:45 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4C5120071 for ; Tue, 21 Jan 2020 00:43:45 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id D4B1E196F8 for ; Tue, 21 Jan 2020 08:43:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1579596223; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ctj6/KRrpapUwqiEo6UN3CNK3QXV+OOnkRmAfoVkDCI=; b=Tz69V9XhUOhG4D7CUg5CUB0R2RcWvNDb06DduJoAZZM1p7LuY0i+N1HFRD1WmQLIjPfQq0 n+BmWeW6JjAI/9A8jlyvY5e7AEAZdCUq/RT4Ddqk0iLgvAoLCF3tZiBkqqkfsMWv5SgJtn 6nkrgSL4cN5xvCNjaBRCqs70WjCh5x4=
To: oauth@ietf.org
References:  <1cf88880-6ea6-8cf2-89d9-ba87e458ea48@danielfett.de>
From: Daniel Fett 
Message-ID: 
Date: Tue, 21 Jan 2020 09:40:54 +0100
MIME-Version: 1.0
In-Reply-To: <1cf88880-6ea6-8cf2-89d9-ba87e458ea48@danielfett.de>
Content-Type: multipart/alternative; boundary="------------189E8D18B1054D80AD47EC47"
Content-Language: de-AT-frami
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1579596223; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ctj6/KRrpapUwqiEo6UN3CNK3QXV+OOnkRmAfoVkDCI=; b=dRzi+v/vYMEm0Ho+QPADix3Iu46siRkDfPRkX/x69GYN8+67h1ZDX6U3rWNtbB/sdEG9NY e6tuyMnGNJjKL5zimVpxeQxF2EZSd7kJqc20WU3zXujhFayTuxCVmVxsEAYlMGbtEucXb+ rvCalOKkRAjiMCDdHWCpw7svpM9o0LQ=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1579596223; a=rsa-sha256; cv=none; b=sokRjEq+sNXSP2HafczGGeelqHbf01wPYqlfSRQcgAYtHxJM9eCeFr9Ob1jc1ZVWGCY21ZNGYDylsAS1eHsdVQMKTzEaNE7aBR6wWuB7FLUz5XFGymVQ4aIT6hITDI4qiy43okz6N/eT2DLbfz8YDUYtfejm6YF2ewp6+95S0t8=
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] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 08:43:51 -0000

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

One more thing: I'd like to present a very brief update/advertisement
for the OAuth Security Workshop. Immediately after the chairs update
might be a good fit.

-Daniel

Am 20.01.20 um 17:03 schrieb Daniel Fett:
> Hi!
>
> I would like to discuss DPoP, the Security BCP, and give a brief
> update about the activities at the FAPI working group.
>
> -Daniel
>
> Am 20.01.20 um 16:32 schrieb Rifaat Shekh-Yusef:
>> All,
>>
>> Please, let us know if you have any topics that you would like to
>> present and discuss in Vancouver.
>>
>> 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



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


  
    
  
  
    
One more thing: I'd like to present a
      very brief update/advertisement for the OAuth Security Workshop.
      Immediately after the chairs update might be a good fit.

    

    


    

    
-Daniel

    

    


    

    
Am 20.01.20 um 17:03 schrieb Daniel
      Fett:

    

    

      
      
Hi!

      


      

      
I would like to discuss DPoP, the
        Security BCP, and give a brief update about the activities at
        the FAPI working group.

      


      

      
-Daniel

      

      


      

      
Am 20.01.20 um 16:32 schrieb Rifaat
        Shekh-Yusef:

      

      

        
        
All,
          


          

          
Please, let us know if you have any topics that you would
            like to present and discuss in Vancouver.

          


          

          
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


    

    


    

  


--------------189E8D18B1054D80AD47EC47--


From nobody Tue Jan 21 04:06: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 BAD5B1200FB for ; Tue, 21 Jan 2020 04:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJl7quWWmXpv for ; Tue, 21 Jan 2020 04:06:02 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450: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 525381200F7 for ; Tue, 21 Jan 2020 04:06:02 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id a5so2706086wmb.0 for ; Tue, 21 Jan 2020 04:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=Ge2DMIAvrFN2Zr3p12UoSZOXSMIoj5Cxi9AGiYxet7Y=; b=YL2t572J0bV9KMWxnQ95mXA49OtNQk01D2UjqewyFaeAnM2agXEsMX+zn1CW55vjut ZxLRDvSJUm7QC4PHth5HPm+hgQM+fvVF2fZ03ueCz2+HSzwFkvPD4gjroc5EnpDdoVd0 ihIfbg+pKWWsvmy1/xp3+6gyTCNLxkcVMJiaTTowgtgt6/4Yq5cWf1kt5n2Hexn2g30U S0aOAZv8PBQ6PzRRj/KyMMojp3Bidmtxa7T9SrJqkgXH26BYQdA90Eh/ZrXwUszG9Iyu y4pxvkYJqv2oJqOFC+5y9SJcA2mGhmfApnHccd5j6e6J+hg7wKnzU29rS9AFIs2z1TNC QAww==
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=Ge2DMIAvrFN2Zr3p12UoSZOXSMIoj5Cxi9AGiYxet7Y=; b=gyO69wKr9LIhf3F42k433tIYTMEzbHUcWHj3kuGBfrd7bBaU/yB4z+w/+Phas4PUAp zh+pIeCcd7VrK8g+tjK/lScwje8T6MDdM24+8itFgia4p6XUST4KA34KCNmmncRAX29W c3R42R0Z3HEOnosYFchhYRXyDQzHp0Tr2fHL9r3DCJ9GPxGvPAY7bs6piKMQcqpqDkJ3 DnBikqvik/1MK+HFDIuZtEJhy/7gjLqWo9XQpz6mfy4iX32K3+TuU8i5IyfWWXmToWbL bMmTwLGBU7I5RYv12CQXCiqqwj+hM7/BUlkvLKHqkprKxL/ZswVTm737qCRVPvqiVOS3 kzgQ==
X-Gm-Message-State: APjAAAXYwAS4RUI8yBofrg/LMrNDmklmRHXQqW/KFRaRKAd5HRUTRUI9 1xgvD+EhuB4UqFmnXM+ljS3O5hVD1cBh29XD2ObN3Q==
X-Google-Smtp-Source: APXvYqxP43Ti/WPxYaCL7EExGFtyUXzgMaa/JOFXiin++ZuAxomqWi1w3pyIRsRtwXsFOS1+KTuvSJJBa72HLfQx8+U=
X-Received: by 2002:a7b:c5d8:: with SMTP id n24mr4017343wmk.124.1579608360630;  Tue, 21 Jan 2020 04:06:00 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Tue, 21 Jan 2020 07:05:50 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000383d0b059ca53b1e"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 12:06:08 -0000

--000000000000383d0b059ca53b1e
Content-Type: text/plain; charset="UTF-8"

All,

Based on the feedback received, we believe that the WG has decided to adopt
this draft as a WG document.
Authors, please submit a new WG draft.

Regards,
 Rifaat & Hannes


On Mon, Jan 6, 2020 at 2:37 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
>

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


All,

Based on the feedback received, we=
 believe=C2=A0that the WG has decided to adopt this draft as a WG document.=

Authors, please=C2=A0submit a new WG draft.

=

Regards,
=C2=A0Rifaat & Hannes


On Mo=
n, Jan 6, 2020 at 2:37 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

This is a call for adoption for the=C2=A0OAuth 2.0 Rich Authorization =
Requests document.
=C2=A0
P=
lease, let us know if you support or object to the adoption of this documen=
t as a working group document by Jan 20th.

Reg=
ards,
=C2=A0Rifaat & Hannes





--000000000000383d0b059ca53b1e--


From nobody Tue Jan 21 08:16:21 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 A8B14120131; Tue, 21 Jan 2020 08:16:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <157962337845.28885.6081388014056387036@ietfa.amsl.com>
Date: Tue, 21 Jan 2020 08:16:18 -0800
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2020 16:16:19 -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 Rich Authorization Requests
        Authors         : Torsten Lodderstedt
                          Justin Richer
                          Brian Campbell
	Filename        : draft-ietf-oauth-rar-00.txt
	Pages           : 30
	Date            : 2020-01-21

Abstract:
   This document specifies a new parameter "authorization_details" that
   is used to carry fine grained authorization data in the OAuth
   authorization request.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-rar-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-00


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

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


From nobody Tue Jan 21 08:17: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 8289C120154 for ; Tue, 21 Jan 2020 08:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 I1hdylvCTlu2 for ; Tue, 21 Jan 2020 08:17:06 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85DB120989 for ; Tue, 21 Jan 2020 08:17:03 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id y11so3892249wrt.6 for ; Tue, 21 Jan 2020 08:17:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EozPxjSisLsXiDuZZ/AId29348chHqYjdjyA7wP5g2I=; b=lFJVzm8gdMBh3atGRlzWPZwH1g4ueDl3SHBBffa55I+SW8RYjQEs/3wVqg/rlL6gIM wvtJx+OX2oG3EpXpOj/rvEagpYgoaBu6tw8QICoc9ADrSw76l1lmrTWqYijY9OeOsCyR m+hUDfQhuQn1WWRrxd4z0Um001cNc1LFRppJP1FK9bPaIrT0UB/BpiHIJZIccULAC5qY yLgCJDejWbJ2AXGP6U1rZys/Vtg+zY6ga2lS+xAaY8qOqdSleBWq+lLCTWHcbJi9ngrr owozqq7MJnhpsfKvYrYluywW3JjeZ3LgBT8qxLf5/LlEOFsl+Z0YjJSNiA1qHmMXHI2j u95g==
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=EozPxjSisLsXiDuZZ/AId29348chHqYjdjyA7wP5g2I=; b=EwesC8BzOL924modcfweiqaD+FADrTLeQ8I45gpgTxAjyQ4hN+qMMfjFJ9syHy56/n QZ7y5LDpfqdRe57rt1H4iP7SkZjn6bxlmnkhBWye2bY81D+jnygPsylcuzfgjpIaT8ph Wbg131JUOMBsj4uJjoRht4dmhv+TCr8LKa3rw1hh/RF497/Pi6P7V6/mvbisbRfOODJ8 RPR3oks/RIoj8jL+VfN2lxLM8LkuKkexTcT0CZZ93/usSJUSYBTrCgPEfGV/+LTGT6sx 6ZmuCWc7Izzjx/GGnU3MifB0ABhFZL5OZpsDsQDyE3k4t1NIEj8KiprxKN72kz9dp9Ta ij9g==
X-Gm-Message-State: APjAAAWU1lYCGMMz90jwSMIALymKnlWYI+Xvh/802u3+1CStO7sjVJ+M iulcWiu2yrrH4USnrVOfPCoEEg==
X-Google-Smtp-Source: APXvYqxgwKpuM5h8zN9n8BJimz9PEk/FNLWq9XktGACwQhzTcWyW270ftRI8XX7UtnTthKjFyd+Zvg==
X-Received: by 2002:a5d:6344:: with SMTP id b4mr5932419wrw.414.1579623422244;  Tue, 21 Jan 2020 08:17:02 -0800 (PST)
Received: from [172.18.236.111] ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id d14sm56641812wru.9.2020.01.21.08.16.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 08:17:01 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_A4233F4A-1BE3-4A9A-9AA6-CF01533123D4"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 21 Jan 2020 17:15:00 +0100
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef 
References:  
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 16:17:11 -0000

--Apple-Mail=_A4233F4A-1BE3-4A9A-9AA6-CF01533123D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all.,

thanks for the support of this draft!

@chairs: I submitted the the WG draft. Please publish.

best regards,
Torsten.

> On 21. Jan 2020, at 13:05, Rifaat Shekh-Yusef  =
wrote:
>=20
> All,
>=20
> Based on the feedback received, we believe that the WG has decided to =
adopt this draft as a WG document.
> Authors, please submit a new WG draft.
>=20
> Regards,
>  Rifaat & Hannes
>=20
>=20
> On Mon, Jan 6, 2020 at 2:37 PM Rifaat Shekh-Yusef =
 wrote:
> All,
>=20
> This is a call for adoption for the OAuth 2.0 Rich Authorization =
Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/=20
> =20
> Please, let us know if you support or object to the adoption of this =
document as a working group document by Jan 20th.
>=20
> Regards,
>  Rifaat & Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A4233F4A-1BE3-4A9A-9AA6-CF01533123D4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMjExNjE1MDBaMC8GCSqGSIb3DQEJBDEiBCAfdteb3Yi4bxWAtQqMswnLuhqOuwLrpaXd
5rX71dPAwjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBALv3ey4B1O4nzzemGqH7Ow+VuHTjv3wOW4osNgbV8eHJPzvLi0t9TaVVqvYr
/JHzMD6QKvePL6cFaK58KXEK4OcS1y9UwU7KGC3JJmRIJDAfVM88DkXc67wNc6oJRg+1MmnhTqGL
ZEyE/k2njwXwewGzgBwEYqZYYpWJarP4X0PKvZ9oGeoqnPxgLsfro6Q2zWX42k8olrC7pIy6+Zms
0lsv5xSgVmi37ex/RMyPY3y6Ji7J+XCXZDMwSljK4sGc9U3Hkt2YSHXUFm01wC6I55QvSjWyxdw0
P0h/stS87gatl8C42zL+bvxALh+jIUYtL4aSlT2oTsMDtxhXjwfAEjgAAAAAAAA=
--Apple-Mail=_A4233F4A-1BE3-4A9A-9AA6-CF01533123D4--


From nobody Tue Jan 21 08:22: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 C29B71201A3 for ; Tue, 21 Jan 2020 08:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 3EYyx9OCqdsj for ; Tue, 21 Jan 2020 08:22:08 -0800 (PST)
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 7DD34120131 for ; Tue, 21 Jan 2020 08:22:08 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id a5so3587480wmb.0 for ; Tue, 21 Jan 2020 08:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DQPIGHmBiMZT7E9KEaYw6bWX8Mkb1H3XBdKDxxsMCSM=; b=prmrUCb7Rvgnpshy8xfNZqCFnW9l5u79vvzcwbH9fI4DnhAnc+iw4O4Dy1eV7O+5/8 lgbXTJFhwIdSMZZjjz4wz4n0ZETBWGRhf1Zcv0vLzgkPxesxiwee7FLevRmes/MpslS0 AJL4NNMA3xSMQsN+EPjdTBZBLwEhEHpjiEEwpTsmX97FqQJ3SsHczljBmDE6PQ3dlVIn SPLsmQQX+mMRVs70oVoH74EjcNbBEYKBJr+5sjAwf3LPswmxMqeKNmfB+BEjwSEhGmEr PurHRpF8qJxFxY3oqDXkIfUjrYT5xWAU9SptBZibf0Lto7EyhwMYUpY1xGRC+nS7T/Dp +QTw==
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=DQPIGHmBiMZT7E9KEaYw6bWX8Mkb1H3XBdKDxxsMCSM=; b=L83gaGU4IhFdJosxmTC3UpicctonhR708WxEeYLB7oFJ4l0Lq7hAD24Zno24UUji65 VyDCGoGMAOZIGw2GTD3UU3Jd7D8Yje4qGaoCKkazYriKcCdk1Lpj7lq2nAm8wgbs+/KK 9eSLjS108aUz0xSsUR82w71Qf716MXAWSQU9sY/nr6xtYpIiihXieIKeY68Xtp4HNGAo vusMoIiIx1i4voEf0JTNX6IRXkgRk8zm684qd9hZRMxpTC+ip2FmD2I44UMtdj9+7fOF Ekb7288WylnOXwlr53pI/TuDsKEV40wdPYcH67MSUhmFoYuHfU4S9XihUhwawjvCm20K svwA==
X-Gm-Message-State: APjAAAX33mvkzTCd4+u1buXzLQ+9t4SgrmhYBy81BuwxR9Fw8gsKb6ug Q8hK2uKMAVfeM+bu1IxNJFhoH6EXNFgOhw==
X-Google-Smtp-Source: APXvYqwZ0epgJtd6ZHvgNTHLVBVhanHmvt6FqdQR3hCQuTG+S0+XxArVViNH9Cc37kZlEOoqb4Szrg==
X-Received: by 2002:a7b:c851:: with SMTP id c17mr4977617wml.71.1579623726991;  Tue, 21 Jan 2020 08:22:06 -0800 (PST)
Received: from [172.18.236.111] ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id u22sm55942780wru.30.2020.01.21.08.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 08:22:06 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: <9BD97716-5D76-4A45-AFFD-C9A4508A2642@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_77597BFC-3BDB-4A52-B571-2FA55FF354B8"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 21 Jan 2020 17:20:01 +0100
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef 
References:  
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 16:22:14 -0000

--Apple-Mail=_77597BFC-3BDB-4A52-B571-2FA55FF354B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

thanks for the support of this draft!

The WG draft is available at =
https://tools.ietf.org/html/draft-ietf-oauth-rar-00.

best regards,
Torsten.

> On 21. Jan 2020, at 13:05, Rifaat Shekh-Yusef  =
wrote:
>=20
> All,
>=20
> Based on the feedback received, we believe that the WG has decided to =
adopt this draft as a WG document.
> Authors, please submit a new WG draft.
>=20
> Regards,
> Rifaat & Hannes
>=20
>=20
> On Mon, Jan 6, 2020 at 2:37 PM Rifaat Shekh-Yusef =
 wrote:
> All,
>=20
> This is a call for adoption for the OAuth 2.0 Rich Authorization =
Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/=20
>=20
> Please, let us know if you support or object to the adoption of this =
document as a working group document by Jan 20th.
>=20
> Regards,
> Rifaat & Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_77597BFC-3BDB-4A52-B571-2FA55FF354B8
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMjExNjIwMDFaMC8GCSqGSIb3DQEJBDEiBCAa2x0hnlF3DfUepaBAMNr4KR4GoHKRN4/t
S26Y6scK/TCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAB2EK4CMnjXK1XuFwrUMIFNOioddVzU5Ft5F6rkkAkAWROUQQiZuq1Qwc291
oH6zF4scpILRXISftlpGn2cw4oIYnz+j52P9cggV63S1hYaBb5H9QMXI3dwyEZM6Lh//fZybqvVX
HWLlNdjmZ3Mk6Ruw//HK6Z+5ESYN1keo1KZjdrQOtalwvc3e3JjMb8EnCaPATHydhZz3bS9rZtbs
5WRhA2+D9z3J/6Tk8NUVVPVNtfCEahW4agb6dss6c0VJriH5SNLDrnVeCpfdW3g3LLdtirNikV6/
38sT3e5pNJQLlv/TLQecyez90J7kje9nWl+wrnfdgG9JQD2BJO4EfXkAAAAAAAA=
--Apple-Mail=_77597BFC-3BDB-4A52-B571-2FA55FF354B8--


From nobody Tue Jan 21 11:09: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 852A912007A for ; Tue, 21 Jan 2020 11:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VvbBfzPA2FuZ for ; Tue, 21 Jan 2020 11:08:54 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7CE120047 for ; Tue, 21 Jan 2020 11:08:54 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id d139so2730519wmd.0 for ; Tue, 21 Jan 2020 11:08:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bn0LfVDVKMn+iwJNB4bvksuiNFOHPRGuOf8Qf94CP+E=; b=C9VtR/SJkLT121dZzgWoB6ptdiU/IZhUznNeevgmX4GU36gzlLBuZ2Rknpf7qaAh7l xe2nvml8yyj/NvboEnH2CZSCOcuRSSfDTL9lyuADrd5YwNjIOoG4+Ti8XdIPfYEqqOIR ow/a2/9Ji9KqaFXFvEi2+ikF3y7inw15JIaOeZ22krX+ttgKpFUd1X5l1BQRs/p5nDFb QQI+NX8wQ6evxF5jCqMQhZqyXxD6+0yRRhGMd4//mKCG1+yxEePJ734LgvvgG1m8+U5s zkVb5m69s01pqjQQ3TpG6hQfZ7oWatsRI0DVK18tU7Nu6AkAaB74resttyxZhZF2Cabh RTpA==
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=bn0LfVDVKMn+iwJNB4bvksuiNFOHPRGuOf8Qf94CP+E=; b=poaNjekPVFiV1s8LpNVciLzJRs0OMsX1aREp2fC/9awQ1wQ366OqasBj2QHs3JGV7U ubqncpNUT1najefeoPPAlEUFYvfSwNisISLapUz06roQiWcI6AMtI+ZK0zpnPSf5tMHK BPIx1jqyK8AKjSPF+pCby/aM5zye50Xi/AmgaXjTcOQzw6Ap/w4ihtHyvMZ7gGKWRe3n weUMwQmYBJQFbfMaJzjdIT65ndpkvahQ4Sf+FuoNmwuxz9deaDoniMneGBbEn/owW8aN Enjq4ou/cBmSm3fNl9w8raHZy7x6Pa8XoUh36lr1xrbpH+9MGnRG+Yy5sc2k7AQI7Xkg OP9A==
X-Gm-Message-State: APjAAAXoOzkEVNWlz4x51Aca9vLYudfnPOAZkjcgXiUhW1nAZBCRG+4E RzuP0KZLmSqVy0Wgy3KrFQUirRWPeBv9FLpHFxvT8tKj
X-Google-Smtp-Source: APXvYqwmryRZ2sTK3kHGF2Yf9Q0ml+wcTDwt4jlF08hUt5T/F7glv3i7y/ZbbQtWgyD1xEYo19cddUcWnZnIdq6mRow=
X-Received: by 2002:a7b:cbc9:: with SMTP id n9mr5756193wmi.89.1579633733106; Tue, 21 Jan 2020 11:08:53 -0800 (PST)
MIME-Version: 1.0
References:  <1cf88880-6ea6-8cf2-89d9-ba87e458ea48@danielfett.de> 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Tue, 21 Jan 2020 14:08:41 -0500
Message-ID: 
To: Daniel Fett 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000898472059cab238b"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Topics for Vancouver
X-BeenThere: oauth@ietf.org
X-Mailman-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, 21 Jan 2020 19:08:59 -0000

--000000000000898472059cab238b
Content-Type: text/plain; charset="UTF-8"

I will be presenting the Nested JWT draft:
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

I appreciate it if people can review it before the meeting.

Regards,
 Rifaat


On Tue, Jan 21, 2020 at 3:44 AM Daniel Fett  wrote:

> One more thing: I'd like to present a very brief update/advertisement for
> the OAuth Security Workshop. Immediately after the chairs update might be a
> good fit.
>
> -Daniel
>
> Am 20.01.20 um 17:03 schrieb Daniel Fett:
>
> Hi!
>
> I would like to discuss DPoP, the Security BCP, and give a brief update
> about the activities at the FAPI working group.
>
> -Daniel
>
> Am 20.01.20 um 16:32 schrieb Rifaat Shekh-Yusef:
>
> All,
>
> Please, let us know if you have any topics that you would like to present
> and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> 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
>

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


I will be presenting the Nested JWT draft:
I appreciate it if people can review it before the meeting.

Regards,
=C2=A0Rifaat
=C2=A0
<=
/div>

On Tue, Jan 21, 2020 at 3:44 AM Daniel Fett <fett@danielfett.de> wrote:

 =20
   =20
 =20
  

    
One more thing: I'd like to present a
      very brief update/advertisement for the OAuth Security Workshop.
      Immediately after the chairs update might be a good fit.

    

    


    

    
-Daniel

    

    


    

    
Am 20.01.20 um 17:03 schrieb Daniel
      Fett:

    

    

     =20
      
Hi!

      


      

      
I would like to discuss DPoP, the
        Security BCP, and give a brief update about the activities at
        the FAPI working group.

      


      

      
-Daniel

      

      


      

      
Am 20.01.20 um 16:32 schrieb Rifaat
        Shekh-Yusef:

      

      

       =20
        
All,
          


          

          
Please, let us know if you have any topics that you would
            like to present and discuss in Vancouver.

          


          

          
Regards,

          
=C2=A0Rifaat & Hannes

          


          

        

        

        

        
_______________________________________________
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




--000000000000898472059cab238b--


From nobody Tue Jan 21 13:40:57 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 A4165120019; Tue, 21 Jan 2020 13:40:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: rdd@cert.org, rifaat.ietf@gmail.com, oauth-chairs@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157964285559.28831.121466757197037785.idtracker@ietfa.amsl.com>
Date: Tue, 21 Jan 2020 13:40:55 -0800
Archived-At: 
Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 107
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jan 2020 21:40:56 -0000

A new meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 Chair Conflict: acme tls sipcore anima saag




People who must be present:
  Roman Danyliw
  Hannes Tschofenig
  Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
  We have few presenters that cannot attend Friday session. We would appreciate not scheduling an OAuth session on Friday.
---------------------------------------------------------


From nobody Wed Jan 22 06:35: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 337971207FF for ; Wed, 22 Jan 2020 06:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 YDYaRzUl20aS for ; Wed, 22 Jan 2020 06:35:08 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C26120103 for ; Wed, 22 Jan 2020 06:35:08 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 4D11E19CBA; Wed, 22 Jan 2020 14:35:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1579703703; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O/ASlC9RnI5WZYy27qG2cW5Yon2bAFT3BEk/NHqfwz0=; b=uRDooMl1z8Pi5LtGx6V8ZM0KDX4pbNnoj+66uRLKc0sOuv+GAk0etNL7N/JTIJkn4lwIIf GpJOyqv9aF8RDxa5fO380QjFM4Bxnh4l5P3muFkPw4dWJt/PM5kVoF5T836O0xRJGVKRl2 mGoecpxY74ex03/A+Pa4qpVi10Sehrw=
To: Mike Jones , "oauth@ietf.org" 
Cc: "torsten@lodderstedt.net" , "ve7jtb@gmail.com" , 'Andrey Labunets' 
References: 
From: Daniel Fett 
Message-ID: <41ba813f-b6d8-ce82-a108-f53b35fc40a9@danielfett.de>
Date: Wed, 22 Jan 2020 15:35:02 +0100
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4034793D8BD06ADD5F1F1BA0"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1579703703; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O/ASlC9RnI5WZYy27qG2cW5Yon2bAFT3BEk/NHqfwz0=; b=bMdaW7ftOAsd0/PuURNLG9c57tYCtnojUtMb82BzjARS17in1/94dWUF5A+HBayIpUiZks hitSelHIOE9M+fcgYeohCD4tTqK5a/VwKMkSaYlLCRYTUqyBcdbkb8Y2dKdTFCBirVex02 PgJfS0b6x+n4Vi3l2VHeeEwF5D3divY=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1579703703; a=rsa-sha256; cv=none; b=U0voHqPHwRHh9YdjSLfF2KFuDZIAMh01BTt0XoEZVQ9Iev+FpzW0oBErvbiaYlhedAq4FJEKrc0ZBzpxzQQ/KhepCH1s5mLzOUZGJ4Mv+41JQ3QKuHzcr28oozYgrl2UFHXbVp7hMUkuDUeUgAjt8brPTpx70g8f2lUt6D3z5wQ=
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] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones
X-BeenThere: oauth@ietf.org
X-Mailman-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, 22 Jan 2020 14:35:14 -0000

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

Thanks for your feedback, Mike! I have two questions below:

Am 20.11.19 um 04:40 schrieb Mike Jones:
>
> I did a complete read of draft-ietf-oauth-security-topics-13
> . My
> review comments follow, divided into substantive and editorial sections.
>
> 
>
> SUBSTANTIVE
>
> 
>
> 3.1.2. Implicit Grant  The statement no viable mechanism exists to
> cryptographically bind access tokens issued in the authorization
> response to a certain client isnt actually true. Please describe
> how the OpenID Connect ID Token achieves this for the id_token token
> and code id_token token response types via the at_hash claim in
> this paragraph, and appropriately qualify the unconditional statement
> cited.

How does the at_hash in the ID token bind the token to the client? I do
see that the client would not accept a token issued for another client.
What is discussed here, however, is that a malicious resource server
could use the token at another resource server. This is not prevented,
or is it?


> 4.8.1.3. Audience Restricted Access Tokens, next to last paragraph 
> When you list MTLS, also please state that the MTLS key can be used as
> a correlation handle, since it is the same for connections to all sites.
>
Wouldn't it be up to the client to use or not use the same key for
multiple sites? Also, what would be the impact of correlation here?



--------------4034793D8BD06ADD5F1F1BA0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks for your feedback, Mike! I have
      two questions below:

    

    


    

    
Am 20.11.19 um 04:40 schrieb Mike
      Jones:

    

    

      
      
      
      

        
I did a complete read of 
            draft-ietf-oauth-security-topics-13. My review comments
          follow, divided into substantive and editorial sections.

        

        
SUBSTANTIVE

        

        3.1.2. Implicit Grant  The statement no
          viable mechanism exists to cryptographically bind access
          tokens issued in the authorization response to a certain
          client isnt actually true. Please describe how the
        OpenID Connect ID Token achieves this for the id_token token
        and code id_token token response types via the at_hash claim
        in this paragraph, and appropriately qualify the unconditional
        statement cited.
      

    

    
How does the at_hash in the ID token bind the token to the
      client? I do see that the client would not accept a token issued
      for another client. What is discussed here, however, is that a
      malicious resource server could use the token at another resource
      server. This is not prevented, or is it?

    


    

    

      

        
4.8.1.3. Audience Restricted Access Tokens,
          next to last paragraph  When you list MTLS, also please state
          that the MTLS key can be used as a correlation handle, since
          it is the same for connections to all sites.

      

    

    
Wouldn't it be up to the client to use or not use the same key
      for multiple sites? Also, what would be the impact of correlation
      here?

    


    

  


--------------4034793D8BD06ADD5F1F1BA0--


From nobody Wed Jan 22 22:03: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 47224120115 for ; Wed, 22 Jan 2020 22:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level: 
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 S9aZsgxLGIZ5 for ; Wed, 22 Jan 2020 22:03:21 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C478B12002F for ; Wed, 22 Jan 2020 22:03:20 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id q6so1680928wro.9 for ; Wed, 22 Jan 2020 22:03:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EECddP54hx74r9AzZ0KZjT8n2F4wVt5tUG7OMJNXVoM=; b=YmyLwn6mY9DASMekTKndzwnmp6d+RTkX3OteTKZVeIgSPcSHTErLP9WJNCZzCJ8S8F +atP4sHXNags9XkQLOJ8t5juMFAvbjwf/0tGcN/M1YIiVmff0t11wT6rV0Mf4gBLxSkg er3g3AfJZig2h+644pj7DkWLA22oWkcjRDrH452YXmyL5R3VGaBAfn/7gYQr7Lsvcw0G 1oYZms4lqaLfMVc5syE8WbN/mkoemxnzPh+zqsi2Hf4BOeImBsfIuROurkJEKYd9XFuR YGH285BT19RaKuarMVR5BqA1FpTyidrtxFvg3mTmh1px+14i7XX6gXL+OugNDWSly9MB CWTA==
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=EECddP54hx74r9AzZ0KZjT8n2F4wVt5tUG7OMJNXVoM=; b=tMrF6MDB/GjgkgK5ROjl5hjG18SP9GAxfJCS1EYEHZpSwGbrSCHlOCiG7gJpsirHPp tVL/X7KDkMtPngargQEqIJN+g0tRt41it4plnmxOl+2iodZjcIFotcIuQTPn1Vi56rKN cWYLji6sjVm2K6Wib0akupgCg8yAs37GzNu0I3WN2szC3wZ6guLbXnYLCAUXFnsSJLWV Af3ym6eGgFy82ZOEv1wKUjkTDTiWLap5KT2oUZSQrPXYh+f/L/R/AOnuYMN6L3Ceeu3C lZmkCFyoGtGyW4/J+nvIu8RVusl9NebVNSKQaM9DZq2e2mRQWaSuC/lXU4LdeMfc6wDa LoPg==
X-Gm-Message-State: APjAAAVcgRQzmW5rFf+sgbOjGkNRChpLweeb6StKqYPGMX9W943aapBi 4D1jM4r5cGhXMKCXgDruCEZ63p6hwH+sb7KGtnsagQ==
X-Google-Smtp-Source: APXvYqxsFdOJZwlZch5O8DmC2xPpDpDgQq+IjZzr+2CrKnnP2v2QYXpwdBZThC8HrMYHKomfww01X4cuMeMX0TfgVus=
X-Received: by 2002:a5d:67c7:: with SMTP id n7mr15220214wrw.319.1579759399120;  Wed, 22 Jan 2020 22:03:19 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <40E68FE9-BEA6-4F44-8401-BD30E6F7C927@lodderstedt.net> 
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Thu, 23 Jan 2020 15:03:07 +0900
Message-ID: 
To: Brian Campbell 
Cc: Torsten Lodderstedt ,  Nat Sakimura , oauth ,  "Richard Backman, Annabelle" 
Content-Type: multipart/alternative; boundary="000000000000d0c523059cc86553"
Archived-At: 
Subject: Re: [OAUTH-WG] JARM
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jan 2020 06:03:22 -0000

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

I think that JARM is good and even feel that JARM should exist there from a
logical perspective because JARM is to Authorization Response what Request
Object is to Authorization Request. It is good that we don't have to use
"ID Token as Detached Signature" (Financial-grade API Part 2) when JARM is
used.

FWIW, I (Authlete) finished implementing JARM at the beginning of October,
2018, about a year and 3 months ago.

Best Regards,
Takahiko Kawasaki

On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell  wrote:

> I'd be in favor of it.
>
> On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>>
>>
>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>
>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>
>>
>> Since Justin brought it up, I would like to know whether the community
>> has appetite to standardize JARM as well.
>>
>> Here is the link to the spec:
>> https://openid.net/specs/openid-financial-api-jarm-ID1.html
>>
>> What do you think?
>> _______________________________________________
>> 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
>

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


I think that JARM is good and even feel that JARM should e=
xist there from a logical perspective because JARM is to Authorization Resp=
onse what Request Object is to Authorization Request. It is good that we do=
n't have to use "ID Token as Detached Signature" (Financial-g=
rade API Part 2) when JARM is used.

FWIW, I (Authlete) finished impl=
ementing JARM at the beginning of October, 2018, about a year and 3 months =
ago.

Best Regards,
Takahiko Kawasaki

On Sat, Jan 18, 2020 at 5=
:22 AM Brian Campbell <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">
I'd be in favor of it. 

On Thu, Jan 16, 2020 at 9:28 AM Tor=
sten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:


=
Am 16.01.2020 um 16:48 schrieb Justin Richer <jricher@mit.edu>:

Maybe PAR and JAR (and J=
ARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would like to know whether the =
community has appetite to standardize JARM as well.

Here is the link to the spec:=C2=A0https://openid.net/spec=
s/openid-financial-api-jarm-ID1.html

What do y=
ou think?
_______________________________________________

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._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000d0c523059cc86553--


From nobody Wed Jan 22 23:03: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 874771201C6 for ; Wed, 22 Jan 2020 23:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 3jnH0bqeAMqR for ; Wed, 22 Jan 2020 23:03:07 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F021C120125 for ; Wed, 22 Jan 2020 23:03:06 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id s144so1158085wme.1 for ; Wed, 22 Jan 2020 23:03:06 -0800 (PST)
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=Nu6QDeU+qBET0Tj070pms885PQ/BxoZkIxzXclkVQVY=; b=LkwejPWQTF4y8Q+BBduW5RbmVr5GtstQmktPdBD+LxN19WgH/cNxKDN0lyXlCCIC8R q+2rX2VCSq0rOY/U9pEZgYZoaxZrtUNCqfP7y2qsBidzNSwmtJalY5a4qG1DR03a8tjd IKNArssC77o0YGQbsCvh+QKvxoHUOAub4its0=
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=Nu6QDeU+qBET0Tj070pms885PQ/BxoZkIxzXclkVQVY=; b=l90OQJN/MAweIvgwyFZ5MO6BJiT8GSOFB4skQJ9C3OkwtAZydxjqj1bTTaM2GZEcRv hGWY2MtxXHPLLnkP4t80y4AtGYZNiPwC0Giwz9CQ4dLpKhh8YLe9ErWUxDXnfVNzD/hn SF403S2q/uKDci9Y4Vws630O4NPXsTqe+CLfsIiHYqZK55QwJxaVperXQffaSmj8BqnT mN9Ya2mGL/q3k4dXML2ZMfwWDtquoXSMDOC5P6VMQqKav0by05J+AN1x5nPocP4DNE3H zlS8tE5uowD3PAx0xBDWm7ATrh7J+iqU1y9TFtTWeYC4DsDTpftALY0ufgNy8nihdraX qlkQ==
X-Gm-Message-State: APjAAAXFI+zFIJMzA/yjPzb/E/dWWFwig9FiWm9GrLl0DtgMj9muGqXV gqGGtZGVfPnJlVR22HxHbZVWSQ==
X-Google-Smtp-Source: APXvYqwBbZCvGcA7aHtW9YBxWIKXS+SqHyWUig/fYfxL7nHB503SDjRnuiZaxX8Tu1EwYyH1z7FkUw==
X-Received: by 2002:a7b:cc82:: with SMTP id p2mr2331774wma.159.1579762984248;  Wed, 22 Jan 2020 23:03:04 -0800 (PST)
Received: from [192.168.1.65] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id o1sm1776567wrn.84.2020.01.22.23.03.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2020 23:03:03 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-C185C38B-910E-4475-BF2C-559B8FE8BC14
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Thu, 23 Jan 2020 07:03:02 +0000
Message-Id: <1CBDEC38-D1C6-4E2E-AA68-C26A219F3AE4@forgerock.com>
References: 
Cc: Brian Campbell , "Richard Backman, Annabelle" , Nat Sakimura , Torsten Lodderstedt , oauth 
In-Reply-To: 
To: Takahiko Kawasaki 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] JARM
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jan 2020 07:03:09 -0000

--Apple-Mail-C185C38B-910E-4475-BF2C-559B8FE8BC14
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

If you=E2=80=99re using auth code and PKCE, what does JARM add?

Neil

> On 23 Jan 2020, at 06:03, Takahiko Kawasaki  wrote:
>=20
> =EF=BB=BF
> I think that JARM is good and even feel that JARM should exist there from a=
 logical perspective because JARM is to Authorization Response what Request O=
bject is to Authorization Request. It is good that we don't have to use "ID T=
oken as Detached Signature" (Financial-grade API Part 2) when JARM is used.
>=20
> FWIW, I (Authlete) finished implementing JARM at the beginning of October,=
 2018, about a year and 3 months ago.
>=20
> Best Regards,
> Takahiko Kawasaki
>=20
>> On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell  wrote:
>> I'd be in favor of it.=20
>>=20
>>> On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt  wrote:
>>>=20
>>>=20
>>>>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>>>>=20
>>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>>=20
>>> Since Justin brought it up, I would like to know whether the community h=
as appetite to standardize JARM as well.
>>>=20
>>> Here is the link to the spec: https://openid.net/specs/openid-financial-=
api-jarm-ID1.html
>>>=20
>>> What do you think?
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege=
d material for the sole use of the intended recipient(s). Any review, use, d=
istribution or disclosure by others is strictly prohibited...  If you have r=
eceived this communication in error, please notify the sender immediately by=
 e-mail and delete the message and any file attachments from your computer. T=
hank you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-C185C38B-910E-4475-BF2C-559B8FE8BC14
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


If you=E2=80=99re using au=
th code and PKCE, what does JARM add?

Neil

On 23 Ja=
n 2020, at 06:03, Takahiko Kawasaki <taka@authlete.com> wrote:

=

=EF=BB=BF
I think that JARM is good and even feel that JARM should exist th=
ere from a logical perspective because JARM is to Authorization Response wha=
t Request Object is to Authorization Request. It is good that we don't have t=
o use "ID Token as Detached Signature" (Financial-grade API Part 2) when JAR=
M is used.

FWIW, I (Authlete) finished implementing JARM at the begin=
ning of October, 2018, about a year and 3 months ago.

Best Regards,Takahiko Kawasaki

On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell <bca=
mpbell=3D40pingidentity=
.com@dmarc.ietf.org> wrote:
I'd be in favor of it. 

On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt <torsten=3D40lodderstedt.ne=
t@dmarc.ietf.org> wrote:

=

Am 16.01.2020 um 16:48 schrieb Justin Richer &=
lt;jricher@mit.edu&=
gt;:

Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would l=
ike to know whether the community has appetite to standardize JARM as well.<=
/div>


=

What do you think?
___________________________________=
____________

OAuth mailing list

OAuth@ietf.org

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






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

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-C185C38B-910E-4475-BF2C-559B8FE8BC14--


From nobody Thu Jan 23 04:26: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 3266812004C for ; Thu, 23 Jan 2020 04:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KJELAaWH6Eni for ; Thu, 23 Jan 2020 04:25:55 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AD2120074 for ; Thu, 23 Jan 2020 04:25:54 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id F06D619D61 for ; Thu, 23 Jan 2020 12:25:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1579782352; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SgHoElvVX42K4XEhXM+pV6EnOo+hGCxOCRzLgxE00ws=; b=lBlHe7B8ojDjvjBbT8/Py7CK8fLoJfTsan81vENN/6fJYM8vYa3EkKEu2wOhuA2Lv41YrV HKTBhGuV+BwS/a6KGRjEP/wJdkbaYUU9xlo8sQHNCOeOk+Dpr6yEzd+z7rJ9x3ZbpYyvEw F7j/k005xt/n6urFsq/L2zkfh1o2+j4=
To: oauth@ietf.org
References:      
From: Daniel Fett 
Message-ID: <8c67db9b-4d14-b2f2-2b64-8852653e81e5@danielfett.de>
Date: Thu, 23 Jan 2020 13:25:51 +0100
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D28DF7BD52933056F7262DA0"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1579782352; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SgHoElvVX42K4XEhXM+pV6EnOo+hGCxOCRzLgxE00ws=; b=HaNnguYOK+435cQRHBa70AT+JdGiYI1f4tSYjaT56foAXKWRKH8Kh5cLlemrQq+xOLDMe9 9nqs9yI5RIzVAYD6TE2cNqCSU5Yx3Ohye501nEeCfXh70gBtUamB9j79sKO+Zr2JyhPbxP 76BqxJkG08mMEX38rxhhlaT77NotGEo=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1579782352; a=rsa-sha256; cv=none; b=axyLH68IskE1fW3Dw/7XOR4ZxtZNPaois2jtICSWrPFs/bLUoTKKq9Noz+L2hk366ebot/BLatnGYXbFF+NYKvwoln0zgvgMDJZJjo8bEdf5BLfRZRVDbHeOmZMpwQzaVjl7thYK9HvQZyyl3L5X/Wia80zkKZSW6IGPatlPgfQ=
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] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jan 2020 12:25:59 -0000

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

After thinking about this a bit more, I think Brian's proposal makes
sense. Reading closely, it actually makes the advice stronger.
Sender-constrained tokens are a SHOULD somewhere else, so that still
applies. I will adopt the wording into the BCP (unless I hear protests).

-Daniel

Am 09.01.20 um 23:37 schrieb Brian Campbell:
> The scenario I described in the beginning of this thread
> (response_type=token+id_token and response_mode=form_post) started out
> a bit more humbly as a way to facilitate a simple and efficient
> cross-domain sign-on with id_token response type and form_post
> response mode. Somewhat analogous to SAML SSO using the POST binding.
> All the transactional data flows through the browser in the front
> channel so no additional calls from the client/RP to the AS/OP are
> needed. And no short-lived-transactional data has to be shared amongst
> AS nodes (or between geographic locations).  There are some nice
> aspects to front channel flows.
>
> Then along came the desire to have the ability to periodically refresh
> the user attributes associated with the session created off of SSO at
> the client/RP so as to have fresh data on which to base access control
> decisions. That was done by adding an access token into the mix, hence
> the response_type=token+id_token with response_mode=form_post, and the
> RP using it to periodically call the user info endpoint. Of course
> this isn't the same as an ID-token-only-front-channel SSO but it still
> retains some of the same benefits being a mostly front channel flow.
>
> I don't know how niche these cases are or even how often they are
> actually put into use in actual deployments. But the token+id_token
> and form_post flow was fresh in my mind for unrelated reasons when I
> was re-reviewing the security BCP draft, which made me think again
> about the SHOULD NOT wording in Section 3.1.2. And that led me to this
> thread and my proposed text that would let the SHOULD for using
> sender-constrained access tokens stand on its own and adjust the
> qualification on the SHOULD NOT for implicit style access tokens to
> focus on the issues that are particular to those flows. This doesn't
> actually change the underlying meaning of the draft because
> sender-constrained access tokens are still a SHOULD. But I think it
> would make the draft more cohesive in terms of where and why certain
> recommendations are made.
>
>
>
>
>
>
>
> On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle
> > wrote:
>
>     Brian and others with similar use cases (Filip?):
>
>      
>
>     The current text does not prohibit your approach, provided you’ve
>     done the due diligence required by BCP 14 to go against a SHOULD
>     NOT. Could you provide more detail on the scenarios where you have
>     opted to use these implicit-based solutions? Is it impractical or
>     infeasible to use an authorization code-based approach in these
>     scenarios? If this is a particularly niche use case, then it may
>     not be worth including in the BCP (that’s basically what SHOULD
>     NOT is for). But if it’s more broadly applicable, then it may be
>     worth tweaking the “unless…” clause of that paragraph.
>
>      
>
>     – 
>
>     Annabelle Richard Backman
>
>     AWS Identity
>
>      
>
>      
>
>     *From: *OAuth      > on behalf of Mike Jones
>          >
>     *Date: *Saturday, December 28, 2019 at 9:47 AM
>     *To: *Brian Campbell      >, Torsten Lodderstedt
>          >
>     *Cc: *oauth >
>     *Subject: *Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
>     response types + form_post response mode
>
>      
>
>     I agree with Brian's suggested text changes.
>
>     -- Mike
>
>     ------------------------------------------------------------------------
>
>     *From:*Brian Campbell      >
>     *Sent:* Saturday, December 28, 2019 5:33:24 AM
>     *To:* Torsten Lodderstedt
>          >
>     *Cc:* Mike Jones      >; oauth      >
>     *Subject:* Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC
>     response types + form_post response mode
>
>      
>
>     The requirement for replay/injection prevention at resource
>     servers is still there in section 3.2. This change only drops it
>     as a specific qualification on that SHOULD NOT for flows that send
>     access tokens in the authorization response. And instead focuses
>     that qualification on the additional risks that come with sending
>     access tokens in the authorization response. To me, this feels
>     more consistent. 
>
>      
>
>     Looking again at section 3, I'd suggest also moving the fourth
>     paragraph of section 3.1.2 into section 3.2 so that the
>     description of sender-constrained is in the subsection that is
>     about sender-constraining. 
>
>      
>
>     On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt
>          > wrote:
>
>         Your proposal sounds reasonable on first sight. But thinking
>         again, it would mean to keep token injection prevention in
>         authorization responses a requirement while dropping the
>         requirement for replay/injection prevention at resource
>         servers. To me this feels inconsistent.
>
>
>
>             Am 28..12.2019 um 00:02 schrieb Brian Campbell
>                          >:
>
>             I'm not suggesting that it should be a recommended flow.
>             But recommending against it, as the text does now, seems
>             overreaching and unnecessary. I know *consensus* was
>             previously found on the text in -13 but best I can recall
>             that discussion was mostly around Nat advocating to allow
>             room for some future self-issued IDP type case and the
>             conversation kind of got hung up on that.
>
>              
>
>             Here's some proposed text, which I think still largely
>             captures the intent of the BCP while not explicitly
>             recommending against legitimate cases like the one I
>             brought here or Nat's or something like JARM.
>
>              
>
>                In order to avoid these issues, clients SHOULD NOT use
>             the implicit
>                grant (response type "token") or other response types
>             issuing
>                access tokens in the authorization response, unless
>             access token injection
>
>                in the authorization response is prevented and the
>             aforementioned token leakage
>
>                vectors are mitigated.
>
>              
>
>             The draft already recommends sender-constrained access
>             tokens elsewhere in the document. It doesn't need to be
>             repeated as a qualifying condition around this SHOULD NOT.
>
>              
>
>             I am a proponent of PoP/HoK/sender-constrained access
>             tokens (as hopefully is evident from several attempts at
>             bringing/doing related work here) but I do worry that the
>             recommendation in the draft is sufficiently unachievable
>             to the vast majority that it might undermine the
>             credibility of the document. But I get the aspirational
>             aspect of it and, other than some suggested tweaks
>             ,
>             am resigned to see it stay in the document. But let's let
>             that recommendation stand on its own in the document and
>             not also tie it to other considerations. 
>
>              
>
>              
>
>             On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt
>                          > wrote:
>
>                 As Brian said, we have discussed this several times
>                 and this text found consensus.
>
>                  
>
>                 Using post reduces the attack surface but does not
>                 allow to bind the access token to the legitimate
>                 client. We are recommending sender constrained access
>                 tokens in the BCP. So recommending a flow that does
>                 not support sender constrained access tokens is a
>                 contradiction.
>
>                  
>
>                 What do other WG members think?
>
>
>
>                     Am 27.12.2019 um 21:28 schrieb Mike Jones
>                                          >:
>
>                     I agree with Brian. Please update the text to
>                     describe this already safe usage.
>
>                     -- Mike
>
>                     ------------------------------------------------------------------------
>
>                     *From:*OAuth                      > on behalf of
>                     Brian Campbell
>                                          >
>                     *Sent:* Friday, December 27, 2019 11:03:30 AM
>                     *To:* oauth >
>                     *Subject:* [EXTERNAL] [OAUTH-WG]
>                     -security-topics-13 and OIDC response types +
>                     form_post response mode
>
>                      
>
>                     We have a-sometimes used scenario where a client
>                     makes an authorization/authentication request with
>                     a "token id_token" response type and "form_post"
>                     response mode (nonce is also sent and exact
>                     redirect URI matching is done at the AS). The
>                     access token is never exposed in any URLs and
>                     access token injection is prevented by the at_hash
>                     claim in the id token.
>
>                      
>
>                     That seems to me like a legitimate and reasonable
>                     usage scenario. However, it would fall on the
>                     wrong side of the SHOULD NOT in Section 3.1.2 of
>                     the Security BCP-to-be
>                     ,
>                     which has:
>
>                      
>
>                        In order to avoid these issues, clients SHOULD
>                     NOT use the implicit
>                        grant (response type "token") or any other
>                     response type issuing
>                        access tokens in the authorization response,
>                     such as "token id_token"
>                        and "code token id_token", unless the issued
>                     access tokens are
>                        sender-constrained and access token injection
>                     in the authorization
>                        response is prevented.
>
>                      
>
>                     I know this particular text has been discussed
>                     over and over again so I hate to revisit it. But
>                     based on the aforementioned scenario I think maybe
>                     it still doesn't quite hit the mark. Access token
>                     injection is prevented. The token leakage
>                     scenarios mentioned in that section are all
>                     avoided. And while I know sender-constrained is
>                     recommended elsewhere in the draft, it's not
>                     really a realistic option for the majority of
>                     deployments.
>
>
>                     */CONFIDENTIALITY NOTICE: This email may contain
>                     confidential and privileged material for the sole
>                     use of the intended recipient(s).. Any review,
>                     use, distribution or disclosure by others is
>                     strictly prohibited..  If you have received this
>                     communication in error, please notify the sender
>                     immediately by e-mail and delete the message and
>                     any file attachments from your computer. Thank you./*
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org 
>                     https://www.ietf.org/mailman/listinfo/oauth
>                     
>
>
>             */CONFIDENTIALITY NOTICE: This email may contain
>             confidential and privileged material for the sole use of
>             the intended recipient(s).. Any review, use, distribution
>             or disclosure by others is strictly prohibited..  If you
>             have received this communication in error, please notify
>             the sender immediately by e-mail and delete the message
>             and any file attachments from your computer. Thank you./*
>
>
>     */CONFIDENTIALITY NOTICE: This email may contain confidential and
>     privileged material for the sole use of the intended
>     recipient(s).. Any review, use, distribution or disclosure by
>     others is strictly prohibited.  If you have received this
>     communication in error, please notify the sender immediately by
>     e-mail and delete the message and any file attachments from your
>     computer. Thank you./*
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited..  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
After thinking about this a bit more, I
      think Brian's proposal makes sense. Reading closely, it actually
      makes the advice stronger. Sender-constrained tokens are a SHOULD
      somewhere else, so that still applies. I will adopt the wording
      into the BCP (unless I hear protests).

    


    

    
-Daniel

    

    


    

    
Am 09.01.20 um 23:37 schrieb Brian
      Campbell:

    

    

      
      

        
The scenario I described in the beginning of this thread
          (response_type=token+id_token and response_mode=form_post)
          started out a bit more humbly as a way to facilitate a simple
          and efficient cross-domain sign-on with id_token response type
          and form_post response mode. Somewhat analogous to SAML SSO
          using the POST binding. All the transactional data flows
          through the browser in the front channel so no additional
          calls from the client/RP to the AS/OP are needed. And no
          short-lived-transactional data has to be shared amongst AS
          nodes (or between geographic locations).  There are some nice
          aspects to front channel flows. 

        

        


        

        
Then along came the desire to have the ability to
          periodically refresh the user attributes associated with the
          session created off of SSO at the client/RP so as to have
          fresh data on which to base access control decisions. That was
          done by adding an access token into the mix, hence the
          response_type=token+id_token with response_mode=form_post, and
          the RP using it to periodically call the user info endpoint.
          Of course this isn't the same as an
          ID-token-only-front-channel SSO but it still retains some of
          the same benefits being a mostly front channel flow. 

        

        


        

        
I don't know how niche these cases are or even how often
          they are actually put into use in actual deployments. But the
          token+id_token and form_post flow was fresh in my mind for
          unrelated reasons when I was re-reviewing the security BCP
          draft, which made me think again about the SHOULD NOT wording
          in Section 3.1.2. And that led me to this thread and my
          proposed text that would let the SHOULD for using
          sender-constrained access tokens stand on its own and adjust
          the qualification on the SHOULD NOT for implicit style access
          tokens to focus on the issues that are particular to those
          flows. This doesn't actually change the underlying meaning of
          the draft because sender-constrained access tokens are still a
          SHOULD. But I think it would make the draft more cohesive in
          terms of where and why certain recommendations are made. 

        

        


        

        


        

        


        

        


        

        


        

        


        

      

      

      

        
On Thu, Jan 2, 2020 at 2:53 PM
          Richard Backman, Annabelle <richanna@amazon.com> wrote:

        

        

          

            

              
Brian and others with similar use
                cases (Filip?):

              
 

              
The current text does not prohibit
                your approach, provided you’ve done the due diligence
                required by BCP 14 to go against a SHOULD NOT. Could you
                provide more detail on the scenarios where you have
                opted to use these implicit-based solutions? Is it
                impractical or infeasible to use an authorization
                code-based approach in these scenarios? If this is a
                particularly niche use case, then it may not be worth
                including in the BCP (that’s basically what SHOULD NOT
                is for). But if it’s more broadly applicable, then it
                may be worth tweaking the “unless…” clause of that
                paragraph.

              
 

              

                
– 

                
Annabelle
                    Richard Backman

                
AWS
                    Identity

              

              
 

              
 

              

                
From: OAuth <oauth-bounces@ietf.org>
                    on behalf of Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>

                    Date: Saturday, December 28, 2019 at 9:47 AM

                    To: Brian Campbell <bcampbell@pingidentity.com>,
                    Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>

                    Cc: oauth <oauth@ietf.org>

                    Subject: Re: [OAUTH-WG] [EXTERNAL]
                    -security-topics-13 and OIDC response types +
                    form_post response mode

              

              

                
 

              

              

                
I
                    agree with Brian's suggested text changes.

              

              

                
--
                    Mike

              

              

                

              

              

                
From: Brian Campbell <bcampbell@pingidentity.com>

                    Sent: Saturday, December 28, 2019 5:33:24 AM

                    To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>

                    Cc: Mike Jones <Michael.Jones@microsoft.com>;
                    oauth <oauth@ietf.org>

                    Subject: Re: [OAUTH-WG] [EXTERNAL]
                    -security-topics-13 and OIDC response types +
                    form_post response mode
                

                

                  
 

                

              

              

                

                  

                    
The requirement for
                      replay/injection prevention at resource servers is
                      still there in section 3.2. This change only drops
                      it as a specific qualification on that SHOULD NOT
                      for flows that send access tokens in the
                      authorization response. And instead focuses that
                      qualification on the additional risks that come
                      with sending access tokens in the authorization
                      response. To me, this feels more consistent. 
                    

                  

                  

                    
 

                  

                  

                    
Looking again at section 3, I'd
                      suggest also moving the fourth paragraph of
                      section 3.1.2 into section 3.2 so that the
                      description of sender-constrained is in the
                      subsection that is about sender-constraining. 
                    

                  

                

                

                  

                    
 

                    

                      

                        
On Fri, Dec 27, 2019, 5:00
                          PM Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
                          wrote:

                      

                      

                        

                          

                            
Your proposal sounds
                              reasonable on first sight. But thinking
                              again, it would mean to keep token
                              injection prevention in authorization
                              responses a requirement while dropping the
                              requirement for replay/injection
                              prevention at resource servers. To me this
                              feels inconsistent.

                          

                          

                            


                              

                            

                            

                              
Am
                                28..12.2019 um 00:02 schrieb Brian
                                Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>:

                            

                          

                          

                            

                              

                                

                                  
I'm not
                                    suggesting that it should be a
                                    recommended flow. But recommending
                                    against it, as the text does now,
                                    seems overreaching and unnecessary.
                                    I know *consensus* was previously
                                    found on the text in -13 but best I
                                    can recall that discussion was
                                    mostly around Nat advocating to
                                    allow room for some future
                                    self-issued IDP type case and the
                                    conversation kind of got hung up on
                                    that.
                                  

                                

                                

                                  
 

                                

                                

                                  
Here's some
                                    proposed text, which I think still
                                    largely captures the intent of the
                                    BCP while not explicitly
                                    recommending against legitimate
                                    cases like the one I brought here or
                                    Nat's or something like JARM.
                                  

                                

                                

                                  
 

                                

                                

                                  
   In order to
                                    avoid these issues, clients SHOULD
                                    NOT use the implicit

                                       grant (response type "token") or
                                    other response types issuing

                                       access tokens in the
                                    authorization response, unless
                                    access token injection

                                

                                

                                  
   in the
                                    authorization response is prevented
                                    and the aforementioned token leakage
                                  

                                

                                

                                  
   vectors are
                                    mitigated. 

                                

                                

                                  
 

                                

                                

                                  
The draft already
                                    recommends sender-constrained access
                                    tokens elsewhere in the document. It
                                    doesn't need to be repeated as a
                                    qualifying condition around this
                                    SHOULD NOT.
                                  

                                

                                

                                  
 

                                

                                

                                  
I am a proponent
                                    of PoP/HoK/sender-constrained access
                                    tokens (as hopefully is evident from
                                    several attempts at bringing/doing
                                    related work here) but I do worry
                                    that the recommendation in the draft
                                    is sufficiently unachievable to the
                                    vast majority that it might
                                    undermine the credibility of the
                                    document. But I get the aspirational
                                    aspect of it and, other than
                                    
                                      some suggested tweaks, am
                                    resigned to see it stay in the
                                    document. But let's let that
                                    recommendation stand on its own in
                                    the document and not also tie it to
                                    other considerations. 
                                  

                                

                                

                                  
 

                                

                                
 

                                

                                  

                                    
On Fri, Dec 27,
                                      2019 at 1:41 PM Torsten
                                      Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
                                      wrote:

                                  

                                  

                                    

                                      

                                        
As Brian
                                          said, we have discussed this
                                          several times and this text
                                          found consensus.

                                      

                                      

                                        
 

                                      

                                      

                                        
Using post
                                          reduces the attack surface but
                                          does not allow to bind the
                                          access token to the legitimate
                                          client. We are recommending
                                          sender constrained access
                                          tokens in the BCP. So
                                          recommending a flow that does
                                          not support sender constrained
                                          access tokens is a
                                          contradiction.

                                      

                                      

                                        
 

                                      

                                      

                                        
What do
                                          other WG members think?

                                      

                                      

                                        


                                          

                                        

                                        

                                          
Am
                                            27.12.2019 um 21:28 schrieb
                                            Mike Jones
                                            <Michael.Jones=40microsoft.com@dmarc.ietf.org>:

                                        

                                      

                                      

                                        

                                          

                                            
I agree
                                                with Brian. Please
                                                update the text to
                                                describe this already
                                                safe usage.

                                          

                                          

                                            
-- Mike

                                          

                                          

                                            

                                          

                                          

                                            
From:
                                                OAuth <oauth-bounces@ietf.org>
                                                on behalf of Brian
                                                Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>

                                                Sent: Friday,
                                                December 27, 2019
                                                11:03:30 AM

                                                To: oauth <oauth@ietf.org>

                                                Subject:
                                                [EXTERNAL] [OAUTH-WG]
                                                -security-topics-13 and
                                                OIDC response types +
                                                form_post response mode
                                            

                                            

                                              
 

                                            

                                          

                                          

                                            

                                              

                                                
We
                                                  have a-sometimes used
                                                  scenario where a
                                                  client makes an
                                                  authorization/authentication
                                                  request with a "token
                                                  id_token" response
                                                  type and "form_post"
                                                  response mode (nonce
                                                  is also sent and exact
                                                  redirect URI matching
                                                  is done at the AS).
                                                  The access token is
                                                  never exposed in any
                                                  URLs and access token
                                                  injection is prevented
                                                  by the at_hash claim
                                                  in the id token.
                                                

                                              

                                              

                                                
 

                                              

                                              

                                                
That
                                                  seems to me like a
                                                  legitimate and
                                                  reasonable usage
                                                  scenario. However, it
                                                  would fall on the
                                                  wrong side of the
                                                  SHOULD NOT in
                                                  
                                                    Section 3.1.2 of the
                                                    Security BCP-to-be,
                                                  which has:

                                              

                                              
 

                                              

                                                
  
                                                  In order to avoid
                                                  these issues, clients
                                                  SHOULD NOT use the
                                                  implicit

                                                     grant (response
                                                  type "token") or any
                                                  other response type
                                                  issuing

                                                     access tokens in
                                                  the authorization
                                                  response, such as
                                                  "token id_token"

                                                     and "code token
                                                  id_token", unless the
                                                  issued access tokens
                                                  are

                                                     sender-constrained
                                                  and access token
                                                  injection in the
                                                  authorization

                                                     response is
                                                  prevented.

                                              

                                              

                                                
 

                                              

                                              

                                                
I
                                                  know this particular
                                                  text has been
                                                  discussed over and
                                                  over again so I hate
                                                  to revisit it. But
                                                  based on the
                                                  aforementioned
                                                  scenario I think maybe
                                                  it still doesn't quite
                                                  hit the mark. Access
                                                  token injection is
                                                  prevented. The token
                                                  leakage scenarios
                                                  mentioned in that
                                                  section are all
                                                  avoided. And while I
                                                  know
                                                  sender-constrained is
                                                  recommended elsewhere
                                                  in the draft, it's not
                                                  really a realistic
                                                  option for the
                                                  majority of
                                                  deployments.
                                                

                                              

                                            

                                            


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

                                          

                                          
_______________________________________________

                                            OAuth mailing list

                                            OAuth@ietf.org

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

                                        

                                      

                                    

                                  

                                

                              

                              


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

                            

                          

                        

                      

                    

                  

                

                


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

              

            

          

        

      

      

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

      

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


    

    


    

  


--------------D28DF7BD52933056F7262DA0--


From nobody Thu Jan 23 08:14: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 6EEC21208AD for ; Thu, 23 Jan 2020 08:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 6ty7ZTbfqyE4 for ; Thu, 23 Jan 2020 08:14:20 -0800 (PST)
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 9D0F01208AC for ; Thu, 23 Jan 2020 08:14:19 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 7DC10F406CD; Thu, 23 Jan 2020 08:14:09 -0800 (PST)
To: torsten@lodderstedt.net, mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.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: david.piggott@disneystreaming.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200123161409.7DC10F406CD@rfc-editor.org>
Date: Thu, 23 Jan 2020 08:14:09 -0800 (PST)
Archived-At: 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6819 (5965)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jan 2020 16:14:25 -0000

The following errata report has been submitted for RFC6819,
"OAuth 2.0 Threat Model and Security Considerations".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5965

--------------------------------------
Type: Editorial
Reported by: David Piggott 

Section: 4.4.1.2

Original Text
-------------
Store access token hashes only (Section 5.1.4.1.3).

Corrected Text
--------------
Store authorization code hashes only (Section 5.1.4.1.3).

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. 

--------------------------------------
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--------------------------------------
Title               : OAuth 2.0 Threat Model and Security Considerations
Publication Date    : January 2013
Author(s)           : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category            : INFORMATIONAL
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Jan 23 13:55: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 5263512011D for ; Thu, 23 Jan 2020 13:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNqIcVz5JVa4 for ; Thu, 23 Jan 2020 13:55:17 -0800 (PST)
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 DDA9912011C for ; Thu, 23 Jan 2020 13:55:16 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id t14so4186170wmi.5 for ; Thu, 23 Jan 2020 13:55:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YAbB1jEVg8rVUC5QpSgmk/hHzlIaWXrx4XDTx7NG9NA=; b=xqmReFq/M461I+yAwUcAhZiiqI8m7dF7EGkuAaQw+6s1UEFZJrpu44hl6uio0FvSrt Pug9f8DqgwFw5njTvqDhzvXwpuroylVmRh8KFQ02A7GlLOq0ZfzvN5UAfcFz8ubXkmjq F7o7hBFoiaOCVaiW2gwBIgYzCDjIJ+UKPTS+0nMhGsLnFVCvczLGFuNA+80FBc9ZPFXC 915JjwIVjySfPB1Ylzh4bJQAij0e8x6CWAjXeL5ErdrFsjmpWZzcXZe9du2Ndb/D2vB8 wNdSXa+sem8waP9xOohFlgB2o401LuhjSZL189SKJqk/JnPKM4PdSTfOP+rjod0oUrvU kyiQ==
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=YAbB1jEVg8rVUC5QpSgmk/hHzlIaWXrx4XDTx7NG9NA=; b=LCZnQwxeYtGnLvfWscA2ekruUnr7OKnKSpaXi4ruVhidFIpm7TR4b4oLxpj1MTsk2G BguHtrbJ4bt5dS2x2BscBLx8hAzqFKXYcS8VRM9solKbzcoXFo/0vsJ4OJVbxkuHwQA1 5h972UimHg5QhChNTQ26uELwD/lzNHoJ2wPx9P78xFdBfRM+ZHBSd9ql1ObTHdeCNIzK ztMRhF4Lq1lPzPHPXaFO/SbKKgBEiRHbFfXnuKl6sVBYtFWxy8ULgHFQ+J083y0IIncP EH/h3q0f8xFpGHumfSOFoTg78g1sstT3Rvjwq6G0HPsTOaTMD+478BbV3DDXOW8wOSqt vhKg==
X-Gm-Message-State: APjAAAVKmHiO2KX/mvNZw4C9P3vNdpHfba+ZTCjlw9ttCRlW1bvp2t0k 5Ivsged8yjvrF+jSr45/aZrhl3BtE1arJh2I8Oc+zilh9Ks=
X-Google-Smtp-Source: APXvYqyqZ2wd34VFMteVHHLHFLbAUHYzvfRxL25eeKjjZLCbkw9mt1opukFPxJPmKH1oqAUwYM0qn6PjjRW6aJh7iRk=
X-Received: by 2002:a1c:4c5:: with SMTP id 188mr65866wme.82.1579816514644; Thu, 23 Jan 2020 13:55:14 -0800 (PST)
MIME-Version: 1.0
References:  <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com>  <20200118025320.GV80030@kduck.mit.edu> 
In-Reply-To: 
From: John Bradley 
Date: Thu, 23 Jan 2020 18:55:04 -0300
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a85f1059cd5b285"
Archived-At: 
Subject: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 23 Jan 2020 21:55:22 -0000

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

---------- Forwarded message ---------
From: John Bradley 
Date: Sat, Jan 18, 2020, 9:31 PM
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
(JAR) vs OIDC request object
To: Benjamin Kaduk 


If you put the iss in the JWE header it is integrity protected, as JWE
only supports AAD encryption algs.

It is more of a problem when the client is sending a requestURI in that
case having the clientID in the GET to the Authorization endpoint is useful=
.

I think there is a argument for explicitly allowing the clientID as long as
it exactly matches the clientID in the JAR.

John B.

On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk  wrote:

> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> > I don=E2=80=99t agree with this stance from a security or implementatio=
n
> perspective.
> >
> > If there=E2=80=99s a clear order of precedence for the information, it=
=E2=80=99s not
> particularly problematic. Everything inside the request object is to be
> taken over things outside the request object. We have the exact same
> semantics and process with dynamic registration, where the software
> statement is carried alongside plain JSON claims, and the two are mixed
> with a very simple algorithm:
> >
> >  - If a field is inside the signed payload, use that value and ignore
> any copy of it on the outside
> >  - If a field is not inside the signed payload and is outside the signe=
d
> payload, use the outside value
> >
> > Can someone please point out a concrete security issue with this
> algorithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics th=
at we need here,
> and it would solve not only the ability to use this for use cases that ca=
ll
> for a more static request object (perhaps signed by a third party and not
> the client) along side the plain parameters that can vary, but also the
> backwards compatibility issue that=E2=80=99s been discussed. With this al=
gorithm in
> place, you could have OIDC clients actually be compliant with the spec,
> since OIDC requires replication of the values inside the request object o=
n
> the outside with exact matches. An OIDC server wouldn=E2=80=99t be fully =
compliant
> with the new spec since it would reject some compliant JAR requests that
> are missing the external parameters, but that=E2=80=99s fairly easy logic=
 to add on
> the OIDC side. And in that case you get a matrix of compatibility like:
>
> I agree that the merge algorithm is simple and fairly straightforward to
> implement.  But, as Joseph has been alluding, it's only simple if you've
> already made the decision to use all the parameters, both from inside and
> from outside the signed payload.  The security risk lies about having to
> make the trust decision twice, more than the mundane details of actually
> doing the merge.  (Though there is still some latent risk, given that we'=
ve
> seen some really crazy quality of implementation out there.)
>
> It's certainly *possible* that things end up fine in many well-deliniated
> cases where merging can be used.  But it's more complicated to reason
> about, and I don't remmber seeing much previous discussion about the
> specifics of the double trust decision.
>
> -Ben
>
> >
> >               JAR Server | OIDC Server  |
> > ------------+------------+--------------+
> > JAR Client  |     YES    |      NO      |
> > OIDC Client |     YES    |     YES      |
> >
> > Breaking one out of the four possible combinations in a very predictabl=
e
> way is, I think, the best way to handle backwards compatibility here.
> >
> > But between this issue and JAR=E2=80=99s problematic call for the value=
 of a
> request_uri to always be a JWT and be fetchable by the AS (neither of whi=
ch
> are true in the case of PAR) makes me think we need to pull this back and
> rework those things, in a push back to the IESG=E2=80=99s comments.
> >
> >  =E2=80=94 Justin
> >
> >
> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan 
> wrote:
> > >
> > > I agree with this, particularly the security concerns of merging. If
> we merge, we can much guarantee there will eventually be a security issue
> where an attacker is able to gain an advantage by adding a parameter to t=
he
> url query (which the server would then happily process if that parameter
> isn=E2=80=99t found inside the request object). Ruling out that case make=
s security
> analysis (particularly when creating new OAuth2 parameters) significantly
> simpler.
> > >
> > > Putting the iss in the JWE header and having the client_id duplicated
> outside the request object seem to address all the concerns I=E2=80=99ve =
seen
> raised.
> > >
> > > (It seems like it may be unnecessary to have the client_id duplicated
> outside if the request_uri is a PAR one though.)
> > >
> > > Joseph
> > >
> > >
> > >
> > >> On 16 Jan 2020, at 22:40, John Bradley  wrote:
> > >>
> > >> I agree with the IESG reasoning that merging is problimatic.  Once w=
e
> > >> allow that given a unknown list of possible paramaters with diffrent
> > >> security properties it would be quite difficult to specify safely.
> > >>
> > >> Query paramaters can still be sent outside the JAR, but if they are =
in
> > >> the OAuth registry the AS MUST ignore them.
> > >>
> > >> Puting the iss in the JWE headder addresses the encryption issue
> without
> > >> merging.
> > >>
> > >> I understand that some existing servers have dependencys on getting
> the
> > >> clientID as a query paramater.
> > >>
> > >> Is that the only paramater that people have a issue with as oposed t=
o
> a
> > >> nice to have?
> > >>
> > >> Would allowing the AS to not ignore the clientID as a query paramate=
r
> as
> > >> long as it matches the one inside the JAR, basicly the same as Conne=
ct
> > >> request object but for just the one paramater make life easier for t=
he
> > >> servers?
> > >>
> > >> I am not promising a change but gathering info before proposing
> something.
> > >>
> > >> John B.
> > >>
> > >>
> > >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> > >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
> > >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> > >>>>> Well, embedding a client_id claim in the JWE header in order to
> > >>>>> achieve "request parameters outside the request object should not
> be
> > >>>>> referred to" is like "putting the cart before the horse". Why do =
we
> > >>>>> have to avoid using the traditional client_id request parameter s=
o
> > >>>>> stubbornly?
> > >>>>>
> > >>>>> The last paragraph of Section 3.2.1
> > >>>>>  of RFC 6749
> says
> > >>>>> as follows.
> > >>>>>
> > >>>>>   /A client MAY use the "client_id" request parameter to identify
> > >>>>>   itself when sending requests to the token endpoint.  In the
> > >>>>>   "authorization_code" "grant_type" request to the token endpoint=
,
> > >>>>>   *an unauthenticated client MUST send its "client_id" to prevent
> > >>>>>   itself from inadvertently accepting a code intended for a clien=
t
> > >>>>>   with a different "client_id".*  This protects the client from
> > >>>>>   substitution of the authentication code.  (It provides no
> > >>>>>   additional security for the protected resource.)/
> > >>>>>
> > >>>>>
> > >>>>> If the same reasoning applies, a client_id must always be sent wi=
th
> > >>>>> request / request_uri because client authentication is not
> performed
> > >>>>> at the authorization endpoint. In other words, */an unauthenticat=
ed
> > >>>>> client (every client is unauthenticated at the authorization
> endpoint)
> > >>>>> MUST send its "client_id" to prevent itself from inadvertently
> > >>>>> accepting a request object for a client with a different
> "client_id"./*
> > >>>>>
> > >>>> Identifying the client in JAR request_uri requests can be really
> useful
> > >>>> so that an AS which requires request_uri registration to prevent
> DDoS
> > >>>> attacks and other checks can do those without having to index all
> > >>>> request_uris individually. I mentioned this before.
> > >>>>
> > >>>> I really wonder what the reasoning of the IESG reviewers was to
> insist
> > >>>> on no params outside the JAR JWT / request_uri.
> > >>>>
> > >>>> I'm beginning to realise this step of the review process isn't
> > >>>> particularly transparent to WG members.
> > >>> Could you expand on that a bit more?  My understanding is that the
> IESG
> > >>> ballot mail gets copied to the WG precisely so that there is
> transparency,
> > >>> e.g., the thread starting at
> > >>>
> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
> > >>> Which admittely is from almost three years ago, but that's the
> earliest
> > >>> that I found that could be seen as the source of this behavior.
> > >>>
> > >>> -Ben
> > >>>
> > >>> P.S. some other discussion at
> > >>>
> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8
> and
> > >>>
> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY
> and
> > >>> so on.
> > >>>
> > >>> _______________________________________________
> > >>> OAuth mailing list
> > >>> OAuth@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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



---------- Forwarded message ---------
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Sat, Jan 18, 2020, 9:31 PM
Subject: Re: [OAUTH-WG] [EXTERNA=
L] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
To=
: Benjamin Kaduk <kaduk@mit.edu>=



If you put the iss in the JWE header it =
is integrity protected, as JWE only=C2=A0supports AAD encryption algs.
=

It is more of a problem when the client is sending a request=
URI in that case having the clientID in the GET to the Authorization endpoi=
nt is useful.

I think there is a argument=C2=A0for=
 explicitly allowing the clientID as long as it exactly matches the clientI=
D in the JAR.

John B.

On Fri, Jan 17, 2020 at=
 11:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Jan 17, 2020 at 08:44:18AM -05=
00, Justin Richer wrote:

> I don=E2=80=99t agree with this stance from a security or implementati=
on perspective. 

> 

> If there=E2=80=99s a clear order of precedence for the information, it=
=E2=80=99s not particularly problematic. Everything inside the request obje=
ct is to be taken over things outside the request object. We have the exact=
 same semantics and process with dynamic registration, where the software s=
tatement is carried alongside plain JSON claims, and the two are mixed with=
 a very simple algorithm:

> 

>=C2=A0 - If a field is inside the signed payload, use that value and ig=
nore any copy of it on the outside

>=C2=A0 - If a field is not inside the signed payload and is outside the=
 signed payload, use the outside value

> 

> Can someone please point out a concrete security issue with this algor=
ithm? This is the extent of the =E2=80=9Cmerge=E2=80=9D semantics that we n=
eed here, and it would solve not only the ability to use this for use cases=
 that call for a more static request object (perhaps signed by a third part=
y and not the client) along side the plain parameters that can vary, but al=
so the backwards compatibility issue that=E2=80=99s been discussed. With th=
is algorithm in place, you could have OIDC clients actually be compliant wi=
th the spec, since OIDC requires replication of the values inside the reque=
st object on the outside with exact matches. An OIDC server wouldn=E2=80=99=
t be fully compliant with the new spec since it would reject some compliant=
 JAR requests that are missing the external parameters, but that=E2=80=99s =
fairly easy logic to add on the OIDC side. And in that case you get a matri=
x of compatibility like:



I agree that the merge algorithm is simple and fairly straightforward to
implement.=C2=A0 But, as Joseph has been alluding, it's only simple if =
you've

already made the decision to use all the parameters, both from inside and
from outside the signed payload.=C2=A0 The security risk lies about having =
to

make the trust decision twice, more than the mundane details of actually
doing the merge.=C2=A0 (Though there is still some latent risk, given that =
we've

seen some really crazy quality of implementation out there.)



It's certainly *possible* that things end up fine in many well-deliniat=
ed

cases where merging can be used.=C2=A0 But it's more complicated to rea=
son

about, and I don't remmber seeing much previous discussion about the
specifics of the double trust decision.



-Ben



> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JAR Server | OID=
C Server=C2=A0 |

> ------------+------------+--------------+

> JAR Client=C2=A0 |=C2=A0 =C2=A0 =C2=A0YES=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =
=C2=A0 NO=C2=A0 =C2=A0 =C2=A0 |

> OIDC Client |=C2=A0 =C2=A0 =C2=A0YES=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=
=A0YES=C2=A0 =C2=A0 =C2=A0 |

> 

> Breaking one out of the four possible combinations in a very predictab=
le way is, I think, the best way to handle backwards compatibility here. 
> 

> But between this issue and JAR=E2=80=99s problematic call for the valu=
e of a request_uri to always be a JWT and be fetchable by the AS (neither o=
f which are true in the case of PAR) makes me think we need to pull this ba=
ck and rework those things, in a push back to the IESG=E2=80=99s comments.<=
br>
> 

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

> 

> 

> > On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.c=
om> wrote:

> > 

> > I agree with this, particularly the security concerns of merging.=
 If we merge, we can much guarantee there will eventually be a security iss=
ue where an attacker is able to gain an advantage by adding a parameter to =
the url query (which the server would then happily process if that paramete=
r isn=E2=80=99t found inside the request object). Ruling out that case make=
s security analysis (particularly when creating new OAuth2 parameters) sign=
ificantly simpler.

> > 

> > Putting the iss in the JWE header and having the client_id duplic=
ated outside the request object seem to address all the concerns I=E2=80=99=
ve seen raised.

> > 

> > (It seems like it may be unnecessary to have the client_id duplic=
ated outside if the request_uri is a PAR one though.)

> > 

> > Joseph

> > 

> > 

> > 

> >> On 16 Jan 2020, at 22:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

> >> 

> >> I agree with the IESG reasoning that merging is problimatic.=
=C2=A0 Once we

> >> allow that given a unknown list of possible paramaters with d=
iffrent

> >> security properties it would be quite difficult to specify sa=
fely.

> >> 

> >> Query paramaters can still be sent outside the JAR, but if th=
ey are in

> >> the OAuth registry the AS MUST ignore them.

> >> 

> >> Puting the iss in the JWE headder addresses the encryption is=
sue without

> >> merging.

> >> 

> >> I understand that some existing servers have dependencys on g=
etting the

> >> clientID as a query paramater.

> >> 

> >> Is that the only paramater that people have a issue with as o=
posed to a

> >> nice to have?

> >> 

> >> Would allowing the AS to not ignore the clientID as a query p=
aramater as

> >> long as it matches the one inside the JAR, basicly the same a=
s Connect

> >> request object but for just the one paramater make life easie=
r for the

> >> servers?

> >> 

> >> I am not promising a change but gathering info before proposi=
ng something.

> >> 

> >> John B.

> >> 

> >> 

> >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:

> >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvi=
nov wrote:

> >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:

> >>>>> Well, embedding a client_id claim in the JWE head=
er in order to

> >>>>> achieve "request parameters outside the requ=
est object should not be

> >>>>> referred to" is like "putting the cart =
before the horse". Why do we

> >>>>> have to avoid using the traditional client_id req=
uest parameter so

> >>>>> stubbornly?

> >>>>> 

> >>>>> The last paragraph of Section 3.2.1

> >>>>> <https://to=
ols.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says

> >>>>> as follows.

> >>>>> 

> >>>>>=C2=A0 =C2=A0/A client MAY use the "client_id=
" request parameter to identify

> >>>>>=C2=A0 =C2=A0itself when sending requests to the t=
oken endpoint.=C2=A0 In the

> >>>>>=C2=A0 =C2=A0"authorization_code" "=
grant_type" request to the token endpoint,

> >>>>>=C2=A0 =C2=A0*an unauthenticated client MUST send =
its "client_id" to prevent

> >>>>>=C2=A0 =C2=A0itself from inadvertently accepting a=
 code intended for a client

> >>>>>=C2=A0 =C2=A0with a different "client_id"=
;.*=C2=A0 This protects the client from

> >>>>>=C2=A0 =C2=A0substitution of the authentication co=
de.=C2=A0 (It provides no

> >>>>>=C2=A0 =C2=A0additional security for the protected=
 resource.)/

> >>>>> 

> >>>>> 

> >>>>> If the same reasoning applies, a client_id must a=
lways be sent with

> >>>>> request / request_uri because client authenticati=
on is not performed

> >>>>> at the authorization endpoint. In other words, */=
an unauthenticated

> >>>>> client (every client is unauthenticated at the au=
thorization endpoint)

> >>>>> MUST send its "client_id" to prevent it=
self from inadvertently

> >>>>> accepting a request object for a client with a di=
fferent "client_id"./*

> >>>>> 

> >>>> Identifying the client in JAR request_uri requests ca=
n be really useful

> >>>> so that an AS which requires request_uri registration=
 to prevent DDoS

> >>>> attacks and other checks can do those without having =
to index all

> >>>> request_uris individually. I mentioned this before.
> >>>> 

> >>>> I really wonder what the reasoning of the IESG review=
ers was to insist

> >>>> on no params outside the JAR JWT / request_uri.

> >>>> 

> >>>> I'm beginning to realise this step of the review =
process isn't

> >>>> particularly transparent to WG members.

> >>> Could you expand on that a bit more?=C2=A0 My understandi=
ng is that the IESG

> >>> ballot mail gets copied to the WG precisely so that there=
 is transparency,

> >>> e.g., the thread starting at

> >>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI=


> >>> Which admittely is from almost three years ago, but that&=
#39;s the earliest

> >>> that I found that could be seen as the source of this beh=
avior.

> >>> 

> >>> -Ben

> >>> 

> >>> P.S. some other discussion at

> >>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8=
 and

> >>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY=
 and

> >>> so on.

> >>> 

> >>> _______________________________________________

> >>> OAuth mailing list

> >>> OAuth@ietf.org

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

> >> 

> >> _______________________________________________

> >> OAuth mailing list

> >> OAuth@ietf.org

> >> https://www.ietf.org/mailman/l=
istinfo/oauth

> > 

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.org

> > https://www.ietf.org/mailman/listinf=
o/oauth

> 



> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailman/listinfo/oau=
th



_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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






--0000000000002a85f1059cd5b285--


From nobody Thu Jan 23 19:06: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 5370412001A for ; Thu, 23 Jan 2020 19:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5] autolearn=no 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 tBraK4SSRnlw for ; Thu, 23 Jan 2020 19:06:17 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12516120019 for ; Thu, 23 Jan 2020 19:06:16 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id d9so169408plo.11 for ; Thu, 23 Jan 2020 19:06:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rufX44uyo3mZxBInqFwQ74+ql4zj3g7UxHPL6ZsAnn8=; b=jsZbNgmj0kj+rbjrOw7Pc04GZxvTlUuZtaxoJ9M0KmLElbg7ZXYfJmf6b7/unIfbgY SRCphqRR/e62c4R/mPOegl4A9Ewv0l5wvinK7UMLcSUJiHp/bcPCcmMzx3Zyv+4Eezuj 0unhu0WO4hBGWQCbf1kaBzQAHz5DJBprQS255jvKbaRbaw0kuF16vKGjGxf/z9ESTYIp FiOJf+arsDsOZdU6HCdIolg/g8aE6/h+hARXPtfI7VrHuM4XI1eZkWetvuaBboAc9++x xvUmTYxNMB4Wt7wNYD5+A28Q2N0/SuFY/ycNyNKhki5rHqekYpOEEwXf3odU5NF6Y6RV gM/g==
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=rufX44uyo3mZxBInqFwQ74+ql4zj3g7UxHPL6ZsAnn8=; b=BFwgJvQRfI9qB3WGDVbRGhA+/9A7I4a1ra+LZC7iSBb1B7zrVEZLPrv1xW8U+Ruavp azSWuJlDjCZKIUArN89/LvWB3AXxfaxheSZ3ZmmRzt40Qu3NCyegQNu/x6qPEbduBxaV vPT3GLU8su5DnbUeLC2xGVUgdNDDevVtZkeFXvfPA+W5B/hccDWVwa0GNxCl5izu7TBE eD9hcZfsoo34Fi9As0JPgMybyY/uOYdG8xM5BlXXvlEbxgE0Hnru+C0OWQTGeMA16Lgv Ko4vZDXIADUwPvOOi9GPR92j8z0Yc4KZolU5J7wRY679Noh1li5IgAYyjuIVHy60D5n6 pVyg==
X-Gm-Message-State: APjAAAWMfAmArNXYKTSd8zOxOpyTFFBffr6sjiBJHSxoLt/tF0A5LPbx UYucO/xWPtdUblXDj0f+e01IjQ==
X-Google-Smtp-Source: APXvYqxFFdhhLpasQvbHQk4mw7dwWtuA4yYFHBm2RlBkNNM0wTTP8zVppB0EvQMUQXYN3Crf1nnXVw==
X-Received: by 2002:a17:90a:d787:: with SMTP id z7mr947179pju.10.1579835175874;  Thu, 23 Jan 2020 19:06:15 -0800 (PST)
Received: from [172.20.10.2] (153.176.138.210.rev.vmobile.jp. [210.138.176.153]) by smtp.gmail.com with ESMTPSA id b26sm4235285pgn.1.2020.01.23.19.06.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 19:06:15 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_131372D8-9F84-4778-8D48-C9E0BCF53BB3"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Fri, 24 Jan 2020 12:04:55 +0900
In-Reply-To: <1CBDEC38-D1C6-4E2E-AA68-C26A219F3AE4@forgerock.com>
Cc: Takahiko Kawasaki , Brian Campbell , Annabelle Backman , Nat Sakimura , oauth 
To: Neil Madden 
References:  <1CBDEC38-D1C6-4E2E-AA68-C26A219F3AE4@forgerock.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] JARM
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jan 2020 03:06:18 -0000

--Apple-Mail=_131372D8-9F84-4778-8D48-C9E0BCF53BB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Excellent question. Since the authorisation response contains that code =
only in this case, one basically gains sender authentication and =
non-repudiation.

> On 23. Jan 2020, at 16:03, Neil Madden  =
wrote:
>=20
> If you=E2=80=99re using auth code and PKCE, what does JARM add?
>=20
> Neil
>=20
>> On 23 Jan 2020, at 06:03, Takahiko Kawasaki  =
wrote:
>>=20
>> =EF=BB=BF
>> I think that JARM is good and even feel that JARM should exist there =
from a logical perspective because JARM is to Authorization Response =
what Request Object is to Authorization Request. It is good that we =
don't have to use "ID Token as Detached Signature" (Financial-grade API =
Part 2) when JARM is used.
>>=20
>> FWIW, I (Authlete) finished implementing JARM at the beginning of =
October, 2018, about a year and 3 months ago.
>>=20
>> Best Regards,
>> Takahiko Kawasaki
>>=20
>> On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell =
 wrote:
>> I'd be in favor of it.=20
>>=20
>> On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt =
 wrote:
>>=20
>>=20
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>>=20
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>=20
>> Since Justin brought it up, I would like to know whether the =
community has appetite to standardize JARM as well.
>>=20
>> Here is the link to the spec: =
https://openid.net/specs/openid-financial-api-jarm-ID1.html
>>=20
>> What do you think?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited...  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
>> OAuth mailing 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=_131372D8-9F84-4778-8D48-C9E0BCF53BB3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMjQwMzA0NTVaMC8GCSqGSIb3DQEJBDEiBCAO/6AU+CM9nz79J7MmIa9J9vtrb5Y2t9Ia
qt3tvbK5vDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBADM7FYZTJ8u2YhY9NSO+aXG98AADkF9OjOw40sETdzL9N+ysWowlXvGBnhRT
/C8SQBqhWZC3AEnrSeLzVNjaMcWJ3Rd9x/MWNMefBB5lSHrkyXcz5X9bwf7tMhTbt9TimwDC20Sc
Vw/4lCCxSozxtyJCYDFDCpuIJOEtiHmiSXf94SQFVexZ2uurKOEMUj7zCkU3LqOXzw1KC9eN4ydq
pchJo/KyKtYzw2E2iiOMdCJrUgG8qb577nbPnJd5/Cc3EEMJmmYXse2CFEVG3YwZmrunhhNgTFXO
/v2nywJYLlKL1DggxaqrZ6VnhtCpdhs3VbWxSAzH6tUbbMlfDzfwJjsAAAAAAAA=
--Apple-Mail=_131372D8-9F84-4778-8D48-C9E0BCF53BB3--


From nobody Thu Jan 23 22:49: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 8DF11120041 for ; Thu, 23 Jan 2020 22:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9uCOZgNwEZYR for ; Thu, 23 Jan 2020 22:49:03 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0: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 D3A1A120018 for ; Thu, 23 Jan 2020 22:48:52 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id s21so375505plr.7 for ; Thu, 23 Jan 2020 22:48:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BrpDbuN27mTX3D6Aj54y118Vn0kRRl/tav+844q2c6g=; b=CbBCPEUm9zRGF804/f9X0srisaPKgBjPsjD6P3/NiHnB8em9MXuMDhUQdjNowPvpWZ ztIGJcuDhnjz+csNSEp+MrDqtnpnPyD/QJTpanlT0DSktZx6/ZxewJjm6WUxLkSz4zKF ctnR/O4oP9kWU8Lmn5PRUyjEioKae/6o7stYSB/NwjHy7z0NnF2aK2xur5FDpVU8/WNK BLoESQrc0HU6rzVBA/fcLZ8fiSM/kvct+okdRdnbliEj+joU8yasfCpHlFH897dQTeC1 4IckyKd/4XCTTJn9F7dH1RmdSpIcHBV4Ul03DuA3mKkSLypIhuKIbWaUYXkQ9PV0lotA FAow==
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=BrpDbuN27mTX3D6Aj54y118Vn0kRRl/tav+844q2c6g=; b=rfu5G1pk+4+8LfGxMvvrHPEiMR00FUkUm5csdHe5NW+37hOBPCGAdxLZYQb5PoYpHT leIS1XoPRxstPhLNpLuu+vYDFxq3vWrebDjOMaiP93zSHE/CTovaAC80qIqjYfeOWdTb ZvuUjO1TlxKHK09TeDWEns9LKXTSb1miqy5ee+/Wb+8ysIc/5K4gYhNvbFWIJgAGA4P1 HQzIPG75YmILFbVL6cW8NF+oU3zs1oiYbEyZfs//iaRXfoxNvVCLVKoC+J29gh6jUucX 9YsiKtXC3WSq0cIJVei/lsZa/Jpl8N4GWU6ePAs12TKuAuusry+0mFbOy1YHZtiug0vG pTfw==
X-Gm-Message-State: APjAAAWh+fYRdZWdwOW007yIumMTV2uTsQMEuLXMqdaNu5O4v6CeSa90 Mn5A0R4Ge/8wdYUfouqs6Zzyzw==
X-Google-Smtp-Source: APXvYqyztrgMvXfiBRFQbIWHKrhTAtjtRAg96waYBFs6flJ+fS2wmROaeqKgj7qTuDizfvZ5ymkM3g==
X-Received: by 2002:a17:902:9687:: with SMTP id n7mr2184541plp.168.1579848531567;  Thu, 23 Jan 2020 22:48:51 -0800 (PST)
Received: from [172.20.10.4] (146.198.214.202.rev.vmobile.jp. [202.214.198.146]) by smtp.gmail.com with ESMTPSA id d189sm5057330pga.70.2020.01.23.22.48.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 22:48:50 -0800 (PST)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_C04CF98E-2245-423A-9991-1475F2B34570"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Fri, 24 Jan 2020 15:47:33 +0900
In-Reply-To: <20200123161409.7DC10F406CD@rfc-editor.org>
Cc: Mark Mcgloin , phil.hunt@yahoo.com, Roman Danyliw , Benjamin Kaduk , Hannes Tschofenig , Rifaat Shekh-Yusef , david.piggott@disneystreaming.com, oauth@ietf.org
To: RFC Errata System 
References: <20200123161409.7DC10F406CD@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6819 (5965)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jan 2020 06:49:07 -0000

--Apple-Mail=_C04CF98E-2245-423A-9991-1475F2B34570
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This errata is correct.

Thanks for bringing this to our attention!

> On 24. Jan 2020, at 01:14, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC6819,
> "OAuth 2.0 Threat Model and Security Considerations".
>=20
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5965
>=20
> --------------------------------------
> Type: Editorial
> Reported by: David Piggott 
>=20
> Section: 4.4.1.2
>=20
> Original Text
> -------------
> Store access token hashes only (Section 5.1.4.1.3).
>=20
> Corrected Text
> --------------
> Store authorization code hashes only (Section 5.1.4.1.3).
>=20
> Notes
> -----
>=20
>=20
> 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 =20
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
> --------------------------------------
> Title               : OAuth 2.0 Threat Model and Security =
Considerations
> Publication Date    : January 2013
> Author(s)           : T. Lodderstedt, Ed., M. McGloin, P. Hunt
> Category            : INFORMATIONAL
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


--Apple-Mail=_C04CF98E-2245-423A-9991-1475F2B34570
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0yMDAxMjQwNjQ3MzRaMC8GCSqGSIb3DQEJBDEiBCCrexDHfZ8vMUZvaP4oZE9HkKIJwxIYW0Ls
mhaRIVwuEjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAEFhwAeA+R2AvYcIE6E4fxBP0DUeqna0QdoDEBCfX00kppWKJnJojkVE6XZb
eiQFp6+whojTscjR3IG8kktqqXK9D/1jwwAd41ByiG1efjBAn7xiT1C6xqGk+5JG70jQeEzGUKey
1AAHlRZlQTW30NY0hOThDxP0VyF7xiixb8fAOyTGdojyX7gkJ8Ynzb/WxLfC1bQNPZlzQk9UKs12
aA5ddMzSKDVTh2PKCi/lDBYWlFsKjbZMObMIu0kxQGGMX87TmsJFpaLln+Jh1QKPJeKUEYh3wC3p
IWzkv5mxgNzXqsz0qlNr3WhUUvOCYV6kn1RXce+ZsacjZbQWKJbuva8AAAAAAAA=
--Apple-Mail=_C04CF98E-2245-423A-9991-1475F2B34570--


From nobody Fri Jan 24 14:41:51 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 59894120077; Fri, 24 Jan 2020 14:41:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: rdd@cert.org, rifaat.ietf@gmail.com, oauth-chairs@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157990570929.22149.14269044968357074172.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jan 2020 14:41:49 -0800
Archived-At: 
Subject: [OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 107
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, 24 Jan 2020 22:41:50 -0000

An update to a meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 Chair Conflict: acme anima sipcore
 Technology Overlap: tls saag



People who must be present:
  Roman Danyliw
  Hannes Tschofenig
  Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
  We have few presenters that cannot attend Friday session. We would appreciate not scheduling an OAuth session on Friday.
---------------------------------------------------------


From nobody Fri Jan 24 14:48:26 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 AB69B12080F; Fri, 24 Jan 2020 14:48:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: rdd@cert.org, rifaat.ietf@gmail.com, oauth-chairs@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157990610466.22045.15605678874305631349.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jan 2020 14:48:24 -0800
Archived-At: 
Subject: [OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 107
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, 24 Jan 2020 22:48:25 -0000

An update to a meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 Chair Conflict: sipcore anima acme txauth
 Technology Overlap: saag tls



People who must be present:
  Roman Danyliw
  Hannes Tschofenig
  Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
  We have few presenters that cannot attend Friday session. We would appreciate not scheduling an OAuth session on Friday.
---------------------------------------------------------


From nobody Tue Jan 28 22:50: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 D59CF1201DB for ; Tue, 28 Jan 2020 22:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (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 5Ozzl9Em22SE for ; Tue, 28 Jan 2020 22:50:12 -0800 (PST)
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 54F3A120142 for ; Tue, 28 Jan 2020 22:50:10 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,376,1574082000"; d="scan'208";a="352997115"
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; 29 Jan 2020 17:50:07 +1100
Received: from wsapp6783.srv.dir.telstra.com ([10.75.131.38]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Jan 2020 17:50:07 +1100
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp6783.srv.dir.telstra.com (10.75.131.38) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 29 Jan 2020 17:50:07 +1100
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.1395.4 via Frontend Transport; Wed, 29 Jan 2020 17:50:07 +1100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N0pbhqqCBmJOLAYzE/FnzLm40s6hg0GqyHnzbW6/lb1O15tekOXoaszNop+uXiUj2wqsx2Obyiv8m0rmgzHEOFJkVdSyfxDCe/K5qsXmICVFwdfxR2M0m1RkveavD4384DjrWB30YqEXwoR0VWIhE1LAU1cdOczR97y0b04YR44Oee5iuGNeXBfH5cyWDbDSCXOLcH0IH/TemW4Mm9gDzPYcPd6qeDyJ9bxlXqQgm/9Bcl0q36Ub1ialz6Myx9n1unDa0B3SBt4CSnN6w+jOIaOzSfzpfwfRPwXXip5BEB9esBvWgBathNVWEDiItUDsvsegogHJ7i4hpfJBF2lGLA==
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=cQu6COkz9SlDrVLE3T0YKOrejO5J6Oj6n+ZiDfrxD+A=; b=hts6IHZdL2+z2UDZqT2N8JeZmmRYAPxqMiF1xq3JV6QqE1OmvDH2sJqXsjvUhv7tAauK+b0gKq/+pKgvKzNqpekoDQcVTUSUXQmDF8WlL3UlgNzj38wymKlO9yJKPT4zxzF8fSJ9viaBRpS63Hv/LkTW5nRbT7Tw6sOPCRakDrrcb7Sq4Hu1Y15gRwGDkx96ubI1V6JTuwDUXnb0F3HC1DOCg3kCPmUfC9Dxr5mlHqissFIkQ9ssQ6F+uR0P0t5pcG3863dOgzOR6qeLfTCxZLG5EuWfwq7aPWPdK1SM23lTWWQ4gF7iTWlSuufsF/hurkM6Oi+NkMVmBgh/YIHOXg==
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=cQu6COkz9SlDrVLE3T0YKOrejO5J6Oj6n+ZiDfrxD+A=; b=ICTwu9Xn/Y4ZwtIkKfz1vW8227VP9cpJY+RUBKXB4l3BDJa+kGjngHvNiHBWYpVzwOE6FgfSqACJYihphQwLrabM8M5fqHv4S5Mtk+sHINbXDR8aHm4+hH91mEBxdimoFhFHzdIGxmSFt8Yd9zLhy+Pyx6z6RJDlAEepRkXyXFk=
Received: from ME2PR01MB3524.ausprd01.prod.outlook.com (52.134.220.202) by ME2PR01MB3731.ausprd01.prod.outlook.com (52.134.222.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.21; Wed, 29 Jan 2020 06:50:06 +0000
Received: from ME2PR01MB3524.ausprd01.prod.outlook.com ([fe80::18ba:8260:29e9:e39]) by ME2PR01MB3524.ausprd01.prod.outlook.com ([fe80::18ba:8260:29e9:e39%7]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 06:50:06 +0000
From: "Manger, James" 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVx0xpDyUIRyiBT0+iDXwQ2PYV6KfkDNsAgAATmYCAAAYQgIAAEtYAgAAFt4CAAAt+gIAAdhWAgAS0pQCAAsepAIABT9yAgBPCbOA=
Date: Wed, 29 Jan 2020 06:50:06 +0000
Message-ID: 
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>
In-Reply-To: <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>
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: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; 
x-originating-ip: [203.35.9.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e0694c58-50b5-4b95-7d14-08d7a487796f
x-ms-traffictypediagnostic: ME2PR01MB3731:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(366004)(136003)(396003)(376002)(346002)(199004)(189003)(86362001)(9686003)(6916009)(26005)(52536014)(7696005)(55016002)(186003)(6506007)(2906002)(66476007)(66446008)(4744005)(5660300002)(316002)(33656002)(76116006)(66946007)(66556008)(64756008)(8936002)(71200400001)(8676002)(81156014)(478600001)(966005)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:ME2PR01MB3731; H:ME2PR01MB3524.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rCc/ULXX/isqCe21TsH22++p033M2JPR6bWCepK4KODUUPnsFOUzA44OMC+sz+uZod6e0SXYZnfRZ6uym0zZO0rAVFo0khC6acv6EsMWPdRRcRWqokcSi5HOzOHerfiQUsur8OlG3fZYO5r/jKnnxMFcGzvYlpsRyxLyCyeKAu99yQQRdUDDOCvapdt9VDwfD93GoiwSnQz8LXPis3d/UgvpbxK0zVYXkbmYKjui2zSH72QJNOW0Ijn24nv5k57/84lNkJfN+EhEJ0CiJI8kpaGJdB5+BQOCDFxWA5wijMZ7GueTfC9fHrtVcoV0wFRYDDhlnNApQodjc7QNwr7GvzeOTNM8lP6pADeH/RfH3Ab28GxOa1o0meceoUXqlR/bi/ErIQ24ARq8IczE7hXgR3tPj73ZJeKERCW788Fr8FKul8i3vV0Y0dgBaXenC8nk9PNziTcI4af5v42FHR+qrhpPao73jNGGcxy1nQDM/XJPFfBmYMqSAltojrPPXZDV0zCRAf4PNiVCqQb636yL9g==
x-ms-exchange-antispam-messagedata: bHSONZ88wv0yOIMebQgsyZ0cITfYezyIzjNbcV/8M+Oleyeuz6u9YkZWXdnF2y7QEaawi0z1NisGtGDO1myj890UNr0ezZTyB7pb9vtbAxOrBLOzf9VwMeo0M2KyLzU45mqXfreU0pxirqbTm5PMvQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e0694c58-50b5-4b95-7d14-08d7a487796f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 06:50:06.0604 (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: 07rA2FH16GBGT5b4LohXAAadIPGtZUV+LF7ajWMZPvqBH63GMT3IFjhnoF0XfTmL0h6OQZAH05e+1Bjv2ihcPXbJQ1un7wAPqCg9JL5WxNQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB3731
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Jan 2020 06:50:16 -0000

Pj4gSXQgd291bGTigJl2ZSBiZWVuIG5pY2UgaWYgSldLIGNvdWxk4oCZdmUgYWdyZWVkIG9uIGEg
VVJMLWJhc2VkIA0KPj4gYWRkcmVzc2luZyBmb3JtYXQgZm9yIGluZGl2aWR1YWwga2V5cyB3aXRo
aW4gdGhlIHNldCwgYnV0IHRoYXQgc2hpcOKAmXMgc2FpbGVkLg0KDQpVc2luZyB0aGUgZnJhZ21l
bnQgb24gYSBKV0tTIFVSTCB0byBpbmRpY2F0ZSB0aGUga2V5IGlkIHdvdWxkIGJlIGdvb2QuDQpU
aGVuIGEgc2luZ2xlIFVSTCBieSBpdHNlbGYgY2FuIGlkZW50aWZ5IGEgc3BlY2lmaWMga2V5Lg0K
DQpodHRwczovL2V4YW1wbGUuY29tL2tleXMuandrcyMyMDExLTA0LTI5DQoNClRoaXMgd291bGQg
aGF2ZSB3b3JrZWQgcGFydGljdWxhcmx5IHdlbGwgaWYgYSBKV0tTIHdhcyBhIEpTT04gb2JqZWN0
IHdpdGgga2V5LWlkcyBhcyB0aGUgbWVtYmVyIG5hbWVzLCBpbnN0ZWFkIG9mIGFuIGFycmF5LiBU
aGF0IGlzIHByZXN1bWFibHkgdG9vIGxhdGUgdG8gZml4LiBCdXQgZGVmaW5pbmcgdGhlIGZyYWdt
ZW50IGZvcm1hdCBmb3IgYXBwbGljYXRpb24vandrLXNldCtqc29uIHRvIGJlIGEga2lkIHZhbHVl
IHNob3VsZCBiZSBwb3NzaWJsZS4NCg0KSWYgeW91IHB1dCBtdWx0aXBsZSBrZXlzIHdpdGggdGhl
IHNhbWUga2V5LWlkIGluIGEgSldLUyB5b3UgYXJlIGFza2luZyBmb3IgdHJvdWJsZSAtLSBqdXN0
IGNhbGwgdGhhdCBhIG5vbi1pbnRlcm9wZXJhYmxlIGNvcm5lciBmb3IgcGVvcGxlIHRvIGF2b2lk
Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo=


From nobody Wed Jan 29 01:48: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 657C0120806 for ; Wed, 29 Jan 2020 01:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 riK9_H85o6Iw for ; Wed, 29 Jan 2020 01:48:23 -0800 (PST)
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 2B48E12026E for ; Wed, 29 Jan 2020 01:48:22 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id g1so5441642wmh.4 for ; Wed, 29 Jan 2020 01:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=mXceTFefS8gV1jmQ2IpZDJAH0h1AVP8s5og0l1QrcEM=; b=U6aHrfOj81fusENaslX+RcoNMTBghUlhse2vvvXSlJNXMVr490Q6ksPv3KmFdDE5AT yeHCd5O4dvN4qvS3x8y0vb/cIp8cI+G/nESYS/ywMQifp8t4x9h0eRmWqFPfWN6WD4rl 2MSeTEcdPSfgtpZ0hw1Q6Vd5+uekodWO8H1ZA=
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:message-id:date:to; bh=mXceTFefS8gV1jmQ2IpZDJAH0h1AVP8s5og0l1QrcEM=; b=HtKwZilOB3taTpxvjlf9BihMylSuOeKJ2CmfgSkSGmGn19p39rGJg6Svjqm/NCBkE4 B3LofLcCPYaev5PogsEt+uIDs48Mko/17bkrAhjLrwNJN8RB32GCyF8GlrvxB+swmjK3 ZuI2CkijS8Fbs5swdls5A0m3KV2zh1NIxwhYB+nXxwXVB/63ZyYBqspCMQ5d254YOUiN /MSPaQRf6MBl49z3mZmCJ4/pVUaiSxdJAYmiVYpJNBVLbW9PZTuT15hiAEVWhJkKnmFh N0pLCUG1p8wbaDVrotig8T23sC9oH8LCBHNSx1KHKAe4qkQBFZBONeC3TiwDYSEV2uIZ KRnA==
X-Gm-Message-State: APjAAAUiwM49QwDEo1SAPOvdm1vJ759Gip4zw0LwHWizIn5fbOiTU7zn VQvP3fcFdTZNu8e6UYS4y31uidtpBI3GRTQw3KE1dIwV6vbnOKkqosbqRND9n0yhQwD2/ffB7Gp Bq3jMpInMz7UTVO3CHHc+jgSSgE9pLvVt/40/wv9f7Iw2wiNa3FC70w4tSJA5RAvppA==
X-Google-Smtp-Source: APXvYqxfPRA/wWB7niTBt8YcP0iLqll0taG+QELvsNgwUQ9hIy4gjg6wmWaDVM9Hovh2HQwz+G6pPA==
X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr10965608wmo.13.1580291300847;  Wed, 29 Jan 2020 01:48:20 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id c15sm2131433wrt.1.2020.01.29.01.48.20 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 01:48:20 -0800 (PST)
From: Neil Madden 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A61F5A5-5E35-4A95-919F-B3A2BDABA263"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-Id: 
Date: Wed, 29 Jan 2020 09:48:19 +0000
To: oauth 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: [OAUTH-WG] Security BCP and mTLS/PoP 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, 29 Jan 2020 09:48:25 -0000

--Apple-Mail=_8A61F5A5-5E35-4A95-919F-B3A2BDABA263
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I was wondering if the security BCP should mention something about what =
an RS should do if it encounters a token introspection response or JWT =
claims set that contains a "cnf" value, but either:

 * the RS doesn't support any kind of PoP/sender-constraints at all, or
 * the RS doesn't understand the particular confirmation method(s) in =
the "cnf" object

At the moment, the generic rules in RFC 7519 for processing JWTs say:

   Specific applications of JWTs will require implementations to
   understand and process some claims in particular ways.  However, in
   the absence of such requirements, all claims that are not understood
   by implementations MUST be ignored.

I think for confirmation keys we want to have specific requirements that =
say that an access token with a not-understood confirmation method =
should be rejected. Otherwise a client may be using a token on the =
understanding that it is PoP-protected/sender-constrained when the RS is =
silently ignoring these constraints.

In retrospect, it's a shame that JWT doesn't have something like "crit" =
for claims rather than headers. (We could perhaps bootstrap this by =
adding a new critical-claims header, which itself can be marked =
critical, but that won't help for normal JSON token introspection =
responses).

PS - the latest security BCP draft appears to have expired. Is a new =
version pending?

Cheers,

Neil=

--Apple-Mail=_8A61F5A5-5E35-4A95-919F-B3A2BDABA263
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


I was wondering if the security BCP should mention something about what an RS should do if it encounters a token introspection response or JWT claims set that contains a "cnf" value, but either:

 * the RS doesn't support any kind of PoP/sender-constraints at all, or
 * the RS doesn't understand the particular confirmation method(s) in the "cnf" object

At the moment, the generic rules in RFC 7519 for processing JWTs say:

   Specific applications of JWTs will require implementations to
   understand and process some claims in particular ways.  However, in
   the absence of such requirements, all claims that are not understood
   by implementations MUST be ignored.

I think for confirmation keys we want to have specific requirements that say that an access token with a not-understood confirmation method should be rejected. Otherwise a client may be using a token on the understanding that it is PoP-protected/sender-constrained when the RS is silently ignoring these constraints.

In retrospect, it's a shame that JWT doesn't have something like "crit" for claims rather than headers. (We could perhaps bootstrap this by adding a new critical-claims header, which itself can be marked critical, but that won't help for normal JSON token introspection responses).



PS - the latest security BCP draft appears to have expired. Is a new version pending?

Cheers,

Neil

--Apple-Mail=_8A61F5A5-5E35-4A95-919F-B3A2BDABA263--


From nobody Wed Jan 29 13:36: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 614A012004E for ; Wed, 29 Jan 2020 13:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXAhG_Zle8co for ; Wed, 29 Jan 2020 13:36:03 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33B3120047 for ; Wed, 29 Jan 2020 13:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580333763; x=1611869763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yKcCa7m1NWozs7DJRnZKdxw5tLQTEcobY19nqTESfO4=; b=gNZ/+KvEPJs3+k8hBUFOnIwvS1u2GvCNntCrJUhgsU6dOCqjZ3ohb+W2 irtestUMWrRmI/v7EeZXp0BG9ozmGMnvfCUT9Fb64WHlRgOHWvIOf+gSy BfcOhl8uM0AgtsqnUV+mWM7oUs8my7qy2UlabORAiYEoi7HmwXGYz67iQ U=;
IronPort-SDR: V5brS7/Q3VTs9oaBev4TjDpo5k7W4vSfI124zwUdR7flSJL4eUlpV5XyOu6AHBrrdTa4isAa/b ijLXmP6MVFSA==
X-IronPort-AV: E=Sophos;i="5.70,379,1574121600"; d="scan'208";a="13499776"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 29 Jan 2020 21:35:52 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 805DFA1F4F; Wed, 29 Jan 2020 21:35:50 +0000 (UTC)
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 21:35:49 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 21:35:49 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 29 Jan 2020 21:35:49 +0000
From: "Richard Backman, Annabelle" 
To: "Manger, James" 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVy+YWu2zA9W8kAkangjebWqbyl6ftg5qAgBPFRwCAAPd4rA==
Date: Wed, 29 Jan 2020 21:35:49 +0000
Message-ID: 
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Jan 2020 21:36:06 -0000

VGhpcyBjb3VsZCBiZSBuaWNlLCBidXQgaXTigJlzIHNvbHZpbmcgYSBkaWZmZXJlbnQgcHJvYmxl
bS4gVGhlIGlzc3VlIEnigJltIGRyYXdpbmcgYXR0ZW50aW9uIHRvIGlzIGFib3V0IGhvdyBhbiBB
UyBpbmRpY2F0ZXMgdGhhdCBhIGdpdmVuIGtleSBpcyB2YWxpZC4gVGhhdOKAmXMgd2hhdCB0aGUg
andrc191cmkgQVMgbWV0YWRhdGEgcHJvcGVydHkgaXMgZm9yLCBhbmQgaXQgZG9lcyBhIGdyZWF0
IGpvYi4gVGhlIHByb2JsZW0gaXMgdGhhdCBpdCBkb2VzIG5vdCBhbGxvdyBlbm91Z2ggZ3JhbnVs
YXJpdHkuIEN1cnJlbnRseSBhbGwgYW4gQVMgY2FuIGRvIGlzIHNheSDigJxoZXJlIGFyZSB0aGUg
a2V5cyB0byB1c2UgdG8gdmVyaWZ5IHN0dWZmIEkgc2lnbmVkLuKAnSBJdCBjYW7igJl0IHNheSDi
gJxoZXJlIGFyZSB0aGUga2V5cyB0byB1c2UgdG8gdmVyaWZ5IElEIFRva2VucywgYW5kIGhlcmUg
aXMgYSBkaWZmZXJlbnQgc2V0IG9mIGtleXMgdG8gdXNlIHRvIHZlcmlmeSBhY2Nlc3MgdG9rZW5z
LuKAnQ0KDQrigJQNCkFubmFiZWxsZSBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KPiBPbiBKYW4g
MjgsIDIwMjAsIGF0IDEwOjUxIFBNLCBNYW5nZXIsIEphbWVzIDxKYW1lcy5ILk1hbmdlckB0ZWFt
LnRlbHN0cmEuY29tPiB3cm90ZToNCj4gDQo+IO+7vw0KPj4gDQo+Pj4gSXQgd291bGTigJl2ZSBi
ZWVuIG5pY2UgaWYgSldLIGNvdWxk4oCZdmUgYWdyZWVkIG9uIGEgVVJMLWJhc2VkIA0KPj4+IGFk
ZHJlc3NpbmcgZm9ybWF0IGZvciBpbmRpdmlkdWFsIGtleXMgd2l0aGluIHRoZSBzZXQsIGJ1dCB0
aGF0IHNoaXDigJlzIHNhaWxlZC4NCj4gDQo+IFVzaW5nIHRoZSBmcmFnbWVudCBvbiBhIEpXS1Mg
VVJMIHRvIGluZGljYXRlIHRoZSBrZXkgaWQgd291bGQgYmUgZ29vZC4NCj4gVGhlbiBhIHNpbmds
ZSBVUkwgYnkgaXRzZWxmIGNhbiBpZGVudGlmeSBhIHNwZWNpZmljIGtleS4NCj4gDQo+IGh0dHBz
Oi8vZXhhbXBsZS5jb20va2V5cy5qd2tzIzIwMTEtMDQtMjkNCj4gDQo+IFRoaXMgd291bGQgaGF2
ZSB3b3JrZWQgcGFydGljdWxhcmx5IHdlbGwgaWYgYSBKV0tTIHdhcyBhIEpTT04gb2JqZWN0IHdp
dGgga2V5LWlkcyBhcyB0aGUgbWVtYmVyIG5hbWVzLCBpbnN0ZWFkIG9mIGFuIGFycmF5LiBUaGF0
IGlzIHByZXN1bWFibHkgdG9vIGxhdGUgdG8gZml4LiBCdXQgZGVmaW5pbmcgdGhlIGZyYWdtZW50
IGZvcm1hdCBmb3IgYXBwbGljYXRpb24vandrLXNldCtqc29uIHRvIGJlIGEga2lkIHZhbHVlIHNo
b3VsZCBiZSBwb3NzaWJsZS4NCj4gDQo+IElmIHlvdSBwdXQgbXVsdGlwbGUga2V5cyB3aXRoIHRo
ZSBzYW1lIGtleS1pZCBpbiBhIEpXS1MgeW91IGFyZSBhc2tpbmcgZm9yIHRyb3VibGUgLS0ganVz
dCBjYWxsIHRoYXQgYSBub24taW50ZXJvcGVyYWJsZSBjb3JuZXIgZm9yIHBlb3BsZSB0byBhdm9p
ZC4NCj4gDQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0
Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K


From nobody Wed Jan 29 15:20: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 B3E51120047; Wed, 29 Jan 2020 15:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cYO-BV7wUFrk; Wed, 29 Jan 2020 15:20:21 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B654212003E; Wed, 29 Jan 2020 15:20:20 -0800 (PST)
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 00TNKFlS014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 18:20:17 -0500
Date: Wed, 29 Jan 2020 15:20:14 -0800
From: Benjamin Kaduk 
To: Nat Sakimura 
Cc: The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org
Message-ID: <20200129232014.GN48797@kduck.mit.edu>
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> 
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] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Jan 2020 23:20:24 -0000

Hi Nat,

Now it is my turn to apologize for taking a long time.

I think I see the general direction these changes are going in, and it's a
reasonable approach to the unfortunate situation we find ourselves in with
respect to JWT claims vs. OAuth parameters.  In effect, what we're doing is
making a "profile" (for lack of a better term) of JWT, that leverages the
mechanisms and algorithms of JWT but uses a different registry for
interpreting the claims in the token (that is, OAuth Parameters vs. JWT
Claims).  We can tell that this "profile" of JWT is being used because of
the context in which the JWT is transferred/received: if it's the "request"
parameter, that's part of the definition of the OAuth Parameter, and if
it's the result of dereferencing a "request_uri", the
application/oauth.authz.req+jwt media-type clearly indicates how the
contents should be interpreted.

However, the changes in the -20 do not give the reader much of any hint as
to this being what's expected to happen, and that stock RFC 7519 JWT is
*not* what's in use.  So I'd request that we take a close look at how the
document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
that while the JWT encoding is in use, the contents are to be interpreted
by interpreting the JWT claims as OAuth Parameters (and not as per the IANA
registry of JWT claims); and add some discussion (similar to the above)
about how the application context makes it unambiguous whether the
JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
document.

With respect to my second ("discuss discuss") point, Nat and I did have a
discussion in-person and I accept that there may be some scenarios in which
skipping the authorization dialogue is appropriate, so the example can
remain.


Moving on from my Discuss position, I do get the sense from the ongoing
discussion on the list that there's not clear agreement about the current
formulation that requires all parameters (but "request" and "request_uri")
to be in the JAR, especially with respect to "client_id" that might be
needed to unpack the JAR in some cases!  So I'm not sure whether the WG
wants to bring the document back to the WG to iron out those issues before
it returns to the IESG.  I'm a little reluctant to switch my position to
"No Objection" until we have a clearer picture of what the WG wants to do
on this front -- in my understanding, we can't really publish the document
without at least some solution ("client_id") for the encrypted-request
key-lookup case.

Thanks,

Ben


On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
> Hi
> 
> Took a long time but finally all the changes needed to resolve the DISCUSS
> comments are (hopefully) applied as -20.
> 
> There is one change that impacts the process: the draft now has IANA
> request so it needs to be referred back to IANA.
> 
> The IETF datatracker status page for this draft is:
> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> 
> Best,
> 
> Nat Sakimura
> 
> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker :
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > This is a "discuss discuss" -- it's an important question and I'd like
> > to talk about it, but it's not clear that any change to the document
> > will be needed.
> >
> > Once this (and some of the more substantive items in the Comment
> > section) is resolved, I'd be happy to ballot Yes.
> >
> > The introduction notes as an advantage of JWT that:
> >
> >    (d)  (collection minimization) The request can be signed by a third
> >         party attesting that the authorization request is compliant with
> >         a certain policy.  For example, a request can be pre-examined by
> >         a third party that all the personal data requested is strictly
> >         necessary to perform the process that the end-user asked for,
> >         and statically signed by that third party.  The authorization
> >         server then examines the signature and shows the conformance
> >         status to the end-user, who would have some assurance as to the
> >         legitimacy of the request when authorizing it.  In some cases,
> >         it may even be desirable to skip the authorization dialogue
> >         under such circumstances.
> >
> > I'm pretty uncomfortable about suggesting that the authorization
> > dialogue can/should be skipped; do we need to keep this example?
> > Maybe just talking about what an expected use case could be would
> > help alleviate my unease.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1
> >
> >    While it is easy to implement, the encoding in the URI does not allow
> >    application layer security with confidentiality and integrity
> >    protection to be used.  While TLS is used to offer communication
> >
> > nit: this wording is a little hard to read; it might be easier to
> > reorder to "does not allow application layer security to be used to
> > provide confidentiality and integrity protection".
> >
> >    The use of application layer security allows requests to be prepared
> >    by a third party so that a client application cannot request more
> >    permissions than previously agreed.  This offers an additional degree
> >    of privacy protection.
> >
> > (side note) what would an example of such a third party be.  (We already
> > have the resource owner, the client, and the authorization server ...
> > maybe it's a fourth party?)
> >
> >    Furthermore, the request by reference allows the reduction of over-
> >    the-wire overhead.
> >
> > We only barely mentioned by-reference at this point (one line in the
> > Abstract), so I'd suggest "passing the request by reference".
> >
> >    (4)  its development status that it is an RFC and so is its
> >         associated signing and encryption methods as [RFC7515] and
> >         [RFC7516]
> >
> > nit: I'd suggest "its development status as a Proposed Standard, along
> > with the associated signing and encryption methods [RFC7515] [RFC7516]."
> >
> >    (c)  (confidentiality protection) The request can be encrypted so
> >         that end-to-end confidentiality can be provided even if the TLS
> >         connection is terminated at one point or another.
> >
> > nit: TLS is always terminated at or before the user-agent, though.  So
> > maybe the user agent needs to get called out here as well (there could
> > of course be TLS termination earlier than the user-agent in some cases,
> > too).
> >
> >    2.  When the client does not want to do the crypto.  The
> >        Authorization Server may provide an endpoint to accept the
> >        Authorization Request through direct communication with the
> >        Client so that the Client is authenticated and the channel is TLS
> >        protected.
> >
> > How can you "not want to do [the] crypto" but still be doing TLS (with
> > crypto)?  Perhaps we're looking for "not want to pay the additional
> > overhead of JWS/JWE cryptography on top of TLS"?
> >
> > Section 1.1
> >
> > RFC 8174 has updated BCP 14 boilerplate text to use.
> >
> > Section 3
> >
> > nit: should this section be 2.3 to get wrapped into "terminology"?
> >
> > It might also be worth putting references in for the terms, though they
> > are largely common knowledge at this point.
> >
> > Section 4
> >
> >    A Request Object (Section 2.1) is used to provide authorization
> >    request parameters for an OAuth 2.0 authorization request.  It MUST
> >    contains all the OAuth 2.0 [RFC6749] authorization request parameters
> >    including extension parameters.  The parameters are represented as
> >
> > nit: "all the parameters" kind of sounds like "all that are defined".
> > But I think the intent here is "any parameter used to process the
> > request must come from the request object and URL query parameters are
> > ignored", so maybe "MUST contain all the parameters (including extension
> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
> > request; parameters from other sources MUST NOT be used", akin to what
> > we say down in Sections 5 and 6.3.
> > But we need to be careful about the wording to not exclude the usage of
> > the "request" and "request_uri" query parameters to  find the Request
> > Object!
> >
> >    the JWT claims.  Parameter names and string values MUST be included
> >
> > nit: maybe "the JWT claims of the object"?
> >
> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
> >    signed or signed and encrypted.
> >
> > nit: I  think we want "This JSON [RFC7159] object".
> >
> > (Long quote incoming)
> >
> >    The following is an example of the Claims in a Request Object before
> >    base64url encoding and signing.  Note that it includes extension
> >    variables such as "nonce" and "max_age".
> >
> >      {
> >       "iss": "s6BhdRkqt3",
> >       "aud": "https://server.example.com",
> >       "response_type": "code id_token",
> >       "client_id": "s6BhdRkqt3",
> >       "redirect_uri": "https://client.example.org/cb",
> >       "scope": "openid",
> >       "state": "af0ifjsldkj",
> >       "nonce": "n-0S6_WzA2Mj",
> >       "max_age": 86400
> >      }
> >
> >    Signing it with the "RS256" algorithm results in this Request Object
> >    value (with line wraps within values for display purposes only):
> >
> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
> >
> > Decoding the base64 of the body, we see:
> > {
> >  "iss": "s6BhdRkqt3",
> >  "aud": "https://server.example.com",
> >  "response_type": "code id_token",
> >  "client_id": "s6BhdRkqt3",
> >  "redirect_uri": "https://client.example.org/cb",
> >  "scope": "openid",
> >  "state": "af0ifjsldkj",
> >  "nonce": "n-0S6_WzA2Mj",
> >  "max_age": 86400,
> >  "claims":
> >   {
> >    "userinfo":
> >     {
> >      "given_name": {"essential": true},
> >      "nickname": null,
> >      "email": {"essential": true},
> >      "email_verified": {"essential": true},
> >      "picture": null
> >     },
> >    "id_token":
> >     {
> >      "gender": null,
> >      "birthdate": {"essential": true},
> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> >     }
> >   }
> > }
> >
> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> > seem to talk about it.  (Note that this example is used later on as
> > well.)
> >
> > Section 5.2.1
> >
> >    It is possible for the Request Object to include values that are to
> >    be revealed only to the Authorization Server.  As such, the
> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
> >    that it be removed after a reasonable timeout unless access control
> >    measures are taken.
> >
> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> > also be useful.
> >
> > Section 5.2.2
> >
> > Do we want to remind the reader that the other query parameters are just
> > for backwards compatibility?
> >
> > Section 5.2.3
> >
> >    The following is an example of this fetch process:
> >
> >      GET /request.jwt HTTP/1.1
> >      Host: tfp.example.org
> >
> > It's useful to show good hygeine in examples; can we get the extra
> > entropy in this request that we have in the previous example(s)?
> >
> > Section 6.2
> >
> >    The Authorization Server MUST perform the signature validation of the
> >    JSON Web Signature [RFC7515] signed request object.  For this, the
> >    "alg" Header Parameter in its JOSE Header MUST match the value of the
> >    pre-registered algorithm.  The signature MUST be validated against
> >    the appropriate key for that "client_id" and algorithm.
> >
> > Does "the pre-registered algorithm" concept exist in the specs outside
> > of draft-ietf-oauth-jwt-bcp?
> >
> > Section 9
> >
> > The error codes we list in Section 7 are already registered, for the
> > OIDC usage.  Do we want to say anything about that?   (I guess it would
> > be disallowed by process to try to update the existing registration to
> > also point at this document.)
> >
> > Section 10
> >
> > We probably also want to reference draft-ietf-oauth-jwt-bcp.
> >
> > Section 10.1
> >
> >    When sending the authorization request object through "request"
> >    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
> >    using JWE [RFC7516] with then considered appropriate algorithm.
> >
> > Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
> > similarly, in Section 4 we reiterate "signed then encrypted".  Why is it
> > okay to talk about just "signed or encrypted" here?
> >
> > Section 10.2
> >
> >    (b)  Verifying that the symmetric key for the JWE encryption is the
> >         correct one if the JWE is using symmetric encryption.
> >
> > Similarly to the previous point, you also need to check the signature,
> > which will always be there.
> >
> >    (d)  Authorization Server is providing an endpoint that provides a
> >         Request Object URI in exchange for a Request Object.  In this
> >
> > I don't think this is a complete sentence (and it's definitely not a
> > parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
> > summary of this method would be "Delegating the authorization check to a
> > separate "Request Object to Request Object URI" endpoint on the
> > Authorization Server".  (The writing in the rest of this paragraph could
> > also use an editing pass.)
> >
> >    (e)  A third party, such as a Trust Framework Provider, provides an
> >         endpoint that provides a Request Object URI in exchange for a
> >         Request Object.  The same requirements as (b) above apply.  In
> >         addition, the Authorization Server MUST know out-of-band that
> >         the Client utilizes the Trust Framework Operator.
> >
> > The Authorization Server also has to trust the third-party provider to
> > actually do its job and not misbehave, right?
> >
> > Section 10.3
> >
> > I'm not entirely sure what "[t]he endpoints ithat come into question in
> > this specification" is supposed to mean -- is it just "the OAuth 2.0
> > endpoints presently defined in Standards-Track RFCs"?
> >
> >    In [RFC6749], while Redirection URI is included, others are not
> >    included in the Authorization Request.  As the result, the same
> >    applies to Authorization Request Object.
> >
> > nit: included in what?
> >
> > Section 10.4
> >
> > It's probably also worth citing the generic URI security considerations
> > from RFC 3986, here.
> >
> > Section 10.4.1
> >
> >    "request_uri", and (d) do not perform recursive GET on the
> >    "request_uri".
> >
> > nit: remove the "do" in order to make the construction parallel.
> >
> > Section 12.1
> >
> >    It is often hard for the user to find out if the personal data asked
> >    for is strictly necessary.  A Trust Framework Provider can help the
> >    user by examining the Client request and comparing to the proposed
> >    processing by the Client and certifying the request.  After the
> >    certification, the Client, when making an Authorization Request, can
> >    submit Authorization Request to the Trust Framework Provider to
> >    obtain the Request Object URI.
> >
> > side note: In my head the act of certification was the act of making the
> > translation to a Request Object URI, so I'm kind of curious where my
> > vision differs from reality.
> >
> > The third paragraph seems to mostly just be describing the procedure of
> > how this flow works, which would not necessarily be specific to the
> > privacy considerations section.
> >
> > Section 12.2.2
> >
> >    Even if the protected resource does not include a personally
> >    identifiable information, it is sometimes possible to identify the
> >    user through the Request Object URI if persistent per-user Request
> >    Object URI is used.  A third party may observe it through browser
> >
> > nit: need an article for "persistent per-user Request Object URI" (or
> > make it plural, as "URIs are used").
> >
> >    Therefore, per-user Request Object URI should be avoided.
> >
> > nit: I think this is better as "static per-user Requeste Object URIs".
> >
> > Section 13
> >
> > Are there two different paragraphs for "contributions from the OAuth WG
> > members"?  Are they reflecting different types of contribution?
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en


From nobody Thu Jan 30 11:27: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 23C7D1201B7 for ; Thu, 30 Jan 2020 11:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3gODPZk9m_h for ; Thu, 30 Jan 2020 11:27:40 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCC1120170 for ; Thu, 30 Jan 2020 11:27:39 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id v201so3053880lfa.11 for ; Thu, 30 Jan 2020 11:27:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rEW6bBNJR+kAlzMdAM4T0ClIT86PaFA6tyyDoJ0fRtI=; b=V167uuo9fH8YqhcVBIRJmVC46vMHdgSjTV0joTCsOQ7WKTsoKLx4Xa/wp3Q/hkPJ6Q OU2HCPK4ORxdiunTn166Sl95q/UEVaVT9aHE4Id2CWa7bc23Y186/Oq7zHH+4QobcMAp 85rcOOI60K2aJGN+T631hCf1Eymm5oBzFlIUeHnELKtMfQ8waXA/WRpRYhxjx5mPXZXE KH5xW0OS0Hi/Eg1vLRsrPXtt38TBXjlFkISrVJJOQIxoonwx3LP6WnHALg5KKaqi8edn XY/fiQqbeKWb1Apb9vK2uJUparn4V5G8ZcZAv/xPT7477Q8LMFfqpz7ogdtMBysJtp/h 69aQ==
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=rEW6bBNJR+kAlzMdAM4T0ClIT86PaFA6tyyDoJ0fRtI=; b=G6F1res8GFvpqS9UsJgiulnlwPlrpTm43HZdT80RohNKvuiogyUVW1HsgdZYfMbv02 OZmi882SZWjyJkK56HXzk/2KzGT2B2TJdnFbMhzbg1Q9UjVZaA9xd0DYvfBQz+guS7By i+Gcdv8oYutNrbvaQ1uqMSN1DKNAOb8yApLzj4LRXCuqYCiHyZWeaAiVsu0nBpxwLFdI 7FMPWyBryAt4VZGy3I00GcbcfeYAJyQzAwwc4v4LDzUWOGDbKk5188/BXOpic01hF+fR PblPwu5gHvpv1AoARd6woFOyfLjVJoaDkrk32IGy/QoQB2v9LhFmyK5hgJ7vWWhuQG0w UjiA==
X-Gm-Message-State: APjAAAXdeNEGJh5fyPccjM2D8i5rDDcy3IibStbodwozCEepGg1dtbq4 v8v7dr69s2BFHik3TIxXbDJcU0R/akjAz99Vo9U=
X-Google-Smtp-Source: APXvYqwGxJYyVjnHZP+fyYQqmSPvv+Ohye4TY6D5uR5pkjGFz3qByB7oiEHaiGjS/ll25gkSG5uNGvZ2CzOiawcJvQI=
X-Received: by 2002:a19:7711:: with SMTP id s17mr3381100lfc.164.1580412457821;  Thu, 30 Jan 2020 11:27:37 -0800 (PST)
MIME-Version: 1.0
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 30 Jan 2020 11:27:10 -0800
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: "Manger, James" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000025b47d059d6073e0"
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 30 Jan 2020 19:27:42 -0000

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

Rephrasing Annabelle's description to highlight the issue:

The AS says "here are the keys to use to verify all of the tokens that *we*
have signed"

Separating duties in a large system is good cryptographic hygiene, IE, one
component signs ID Tokens, another signs access tokens.


On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle  wrote:

> This could be nice, but it=E2=80=99s solving a different problem. The iss=
ue I=E2=80=99m
> drawing attention to is about how an AS indicates that a given key is
> valid. That=E2=80=99s what the jwks_uri AS metadata property is for, and =
it does a
> great job. The problem is that it does not allow enough granularity.
> Currently all an AS can do is say =E2=80=9Chere are the keys to use to ve=
rify stuff
> I signed.=E2=80=9D It can=E2=80=99t say =E2=80=9Chere are the keys to use=
 to verify ID Tokens, and
> here is a different set of keys to use to verify access tokens.=E2=80=9D
>
> =E2=80=94
> Annabelle Backman
> AWS Identity
>
> > On Jan 28, 2020, at 10:51 PM, Manger, James <
> James.H.Manger@team.telstra.com> wrote:
> >
> > =EF=BB=BF
> >>
> >>> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on a URL=
-based
> >>> addressing format for individual keys within the set, but that ship=
=E2=80=99s
> sailed.
> >
> > Using the fragment on a JWKS URL to indicate the key id would be good.
> > Then a single URL by itself can identify a specific key.
> >
> > https://example.com/keys.jwks#2011-04-29
> >
> > This would have worked particularly well if a JWKS was a JSON object
> with key-ids as the member names, instead of an array. That is presumably
> too late to fix. But defining the fragment format for
> application/jwk-set+json to be a kid value should be possible.
> >
> > If you put multiple keys with the same key-id in a JWKS you are asking
> for trouble -- just call that a non-interoperable corner for people to
> avoid.
> >
> > --
> > James Manger
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Rephrasing Annabelle's description to highlight the is=
sue:

The AS says "here are the keys to use to verify all =
of the tokens that we have signed"

Separating duties in a large system is good cryptographic hygiene, IE, o=
ne component signs ID Tokens, another signs access tokens.


On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle <richanna=
=3D40amazon.com@dmarc.ietf.o=
rg> wrote:
James.H.Manger@team.telstra.=
com> wrote:

> 

> =EF=BB=BF

>> 

>>> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed o=
n a URL-based 

>>> addressing format for individual keys within the set, but that=
 ship=E2=80=99s sailed.

> 

> Using the fragment on a JWKS URL to indicate the key id would be good.=


> Then a single URL by itself can identify a specific key.

> 

> https://example.com/keys.jwks#2011-04-29

> 

> This would have worked particularly well if a JWKS was a JSON object w=
ith key-ids as the member names, instead of an array. That is presumably to=
o late to fix. But defining the fragment format for application/jwk-set+jso=
n to be a kid value should be possible.

> 

> If you put multiple keys with the same key-id in a JWKS you are asking=
 for trouble -- just call that a non-interoperable corner for people to avo=
id.

> 

> --

> James Manger

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000025b47d059d6073e0--


From nobody Thu Jan 30 13:40: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 EB8641200A1; Thu, 30 Jan 2020 13:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Wpn3-lsC7XSi; Thu, 30 Jan 2020 13:40:05 -0800 (PST)
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 A812D12001A; Thu, 30 Jan 2020 13:40:05 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id BA7A3F406D0; Thu, 30 Jan 2020 13:39:58 -0800 (PST)
To: david.piggott@disneystreaming.com, torsten@lodderstedt.net, mark.mcgloin@ie.ibm.com, phil.hunt@yahoo.com
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: <20200130213958.BA7A3F406D0@rfc-editor.org>
Date: Thu, 30 Jan 2020 13:39:58 -0800 (PST)
Archived-At: 
Subject: [OAUTH-WG] [Errata Verified] RFC6819 (5965)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 30 Jan 2020 21:40:07 -0000

The following errata report has been verified for RFC6819,
"OAuth 2.0 Threat Model and Security Considerations". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5965

--------------------------------------
Status: Verified
Type: Editorial

Reported by: David Piggott 
Date Reported: 2020-01-23
Verified by: Benjamin Kaduk (IESG)

Section: 4.4.1.2

Original Text
-------------
Store access token hashes only (Section 5.1.4.1.3).

Corrected Text
--------------
Store authorization code hashes only (Section 5.1.4.1.3).

Notes
-----


--------------------------------------
RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
--------------------------------------
Title               : OAuth 2.0 Threat Model and Security Considerations
Publication Date    : January 2013
Author(s)           : T. Lodderstedt, Ed., M. McGloin, P. Hunt
Category            : INFORMATIONAL
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Jan 30 19:07: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 1EFE5120048; Thu, 30 Jan 2020 19:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoeQRUOiMvTE; Thu, 30 Jan 2020 19:07:02 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4D1120019; Thu, 30 Jan 2020 19:07:01 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id z3so6840475wru.3; Thu, 30 Jan 2020 19:07:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+4F/6cY+EwnpgAfAdxCjCuuZN7M+9cBIAOSi/TFmkR8=; b=CTpsNRwYGYnyolGoDE81Vb1wpX3ufDqIrl/jLprFiKFpVib6YSoSEDy1sMcpF9Dqh5 dteEWwVTxUf8ra/NwHp/j/txd8TMOh9EoKh7bPZEx79lt5/qFiE8hEqOO6XuBsl7H56M P08/P+L2pEKwxaiZhWM53kI3K+zMXRpMF2+2MYwTwWtoMMiXhMKd6S0jJ2yB9S9Wnit3 xyKG5aibeTHyp1qoZBPgEPR+cav9kDioA9fcp42nLMcztBG+x8VcJsuFTEiGwnOCc57G rdSPziUsmJkB6RiUkcPUX6b+YlddX8rJ2VuSpu1AkPkCa6jMg8NMIeF+NLj7mvKtKE7V 32ZQ==
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=+4F/6cY+EwnpgAfAdxCjCuuZN7M+9cBIAOSi/TFmkR8=; b=NPiTyGe+UbrR3oOo1BmKYqaLhg+PB/K5WKSeLwHlG5sL7wt3GI/DtAIvoZEhU+P2Yy IqxymEwxnT4+Xq35iQxpgcLeyUq+JpLyZZr9JQiY3PRo9Tj2MXd/iib/5/jdcWs8dFL4 Pc6YxRe0cqRtH5RnwIUDqEO/KQaRCWacxd0Ys6pvqvdNrmfEZ4TghGvPX1hnYIBjuAJL /zWnp0jdKMIvsSzkbsw4hW2k+/e1q5XJ1B2L4FqmgmZIDzXNlAGjEsINhfepnx/L+XZC gE1k3fNriQzMFjFWVrelJgpe9koOx5HmAct867YSJMAeGNx5v6qoe+AX3AVmk5XKJL8X Eyzg==
X-Gm-Message-State: APjAAAVZS677Dv46vgC7tGqyhqhlkHnpgcH+N3AkleQSaF708P78R0PJ idLWGbQFzygpxf86wh4Hj44PiUFlL4D2dyc3TGTyrOlHdQw=
X-Google-Smtp-Source: APXvYqznYoP8zNrRwEeqTOAAMGjyOxYNfNeZGTsfRD2bGH4AcBS/Hc43ZdJmXkad1kwkMXWUBZzDsWkTSRBVuP95hEE=
X-Received: by 2002:a05:6000:1289:: with SMTP id f9mr8553714wrx.381.1580440019552;  Thu, 30 Jan 2020 19:06:59 -0800 (PST)
MIME-Version: 1.0
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com>  <20200129232014.GN48797@kduck.mit.edu>
In-Reply-To: <20200129232014.GN48797@kduck.mit.edu>
From: Nat Sakimura 
Date: Fri, 31 Jan 2020 12:06:47 +0900
Message-ID: 
To: Benjamin Kaduk 
Cc: The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth , oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f44d36059d66ddf6"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Jan 2020 03:07:06 -0000

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

Hi

Re: JWT
I understand your concern and we can put some explanatory notes. Having
said that, JAR is still a valid JWT, I think :-)

Re: client_id
We actually discussed client_id issues with OpenID Connect WG Call
yesterday as well.
I hear a pretty strong voice from the developer community that they want
client_id as a query parameter and it should not pose a security issue as
long as it is required to match what is in the JWT. In fact, that was the
position taken in the WG last call. So, in effect, WG is actually pushing
back the change IESG wanted.

As I understand it, there are two points to be made:
(1) If client_id is not in the query parameter, then it MUST be in the JWT
header OR MUST be supplied as a query parameter in some encrypted JAR case
(2) To check if requst_uri is a registered and valid URI, not having
client_id in the query parameter will have performance impacts in a large
AS.

The encryption case (1) can be solved by adding client_id in the JWT Header
but it will not solve (2).
So, IMHO, putting client_id back to the query parameter (and MUST match the
value in JWT) is a way to go.
Since that was the position by the WG at the WG Last Call, I do not feel
that it needs to be brought back to the WG last call,
but that is your call.

Best,

Nat Sakimura

On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk  wrote:

> Hi Nat,
>
> Now it is my turn to apologize for taking a long time.
>
> I think I see the general direction these changes are going in, and it's =
a
> reasonable approach to the unfortunate situation we find ourselves in wit=
h
> respect to JWT claims vs. OAuth parameters.  In effect, what we're doing =
is
> making a "profile" (for lack of a better term) of JWT, that leverages the
> mechanisms and algorithms of JWT but uses a different registry for
> interpreting the claims in the token (that is, OAuth Parameters vs. JWT
> Claims).  We can tell that this "profile" of JWT is being used because of
> the context in which the JWT is transferred/received: if it's the "reques=
t"
> parameter, that's part of the definition of the OAuth Parameter, and if
> it's the result of dereferencing a "request_uri", the
> application/oauth.authz.req+jwt media-type clearly indicates how the
> contents should be interpreted.
>
> However, the changes in the -20 do not give the reader much of any hint a=
s
> to this being what's expected to happen, and that stock RFC 7519 JWT is
> *not* what's in use.  So I'd request that we take a close look at how the
> document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
> that while the JWT encoding is in use, the contents are to be interpreted
> by interpreting the JWT claims as OAuth Parameters (and not as per the IA=
NA
> registry of JWT claims); and add some discussion (similar to the above)
> about how the application context makes it unambiguous whether the
> JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
> document.
>
> With respect to my second ("discuss discuss") point, Nat and I did have a
> discussion in-person and I accept that there may be some scenarios in whi=
ch
> skipping the authorization dialogue is appropriate, so the example can
> remain.
>
>
> Moving on from my Discuss position, I do get the sense from the ongoing
> discussion on the list that there's not clear agreement about the current
> formulation that requires all parameters (but "request" and "request_uri"=
)
> to be in the JAR, especially with respect to "client_id" that might be
> needed to unpack the JAR in some cases!  So I'm not sure whether the WG
> wants to bring the document back to the WG to iron out those issues befor=
e
> it returns to the IESG.  I'm a little reluctant to switch my position to
> "No Objection" until we have a clearer picture of what the WG wants to do
> on this front -- in my understanding, we can't really publish the documen=
t
> without at least some solution ("client_id") for the encrypted-request
> key-lookup case.
>
> Thanks,
>
> Ben
>
>
> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
> > Hi
> >
> > Took a long time but finally all the changes needed to resolve the
> DISCUSS
> > comments are (hopefully) applied as -20.
> >
> > There is one change that impacts the process: the draft now has IANA
> > request so it needs to be referred back to IANA.
> >
> > The IETF datatracker status page for this draft is:
> > datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> > Best,
> >
> > Nat Sakimura
> >
> > 2019=E5=B9=B47=E6=9C=883=E6=97=A5(=E6=B0=B4) 4:21 Benjamin Kaduk via Da=
tatracker :
> >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-oauth-jwsreq-19: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut th=
is
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> > >
> > >
> > >
> > > ---------------------------------------------------------------------=
-
> > > DISCUSS:
> > > ---------------------------------------------------------------------=
-
> > >
> > > This is a "discuss discuss" -- it's an important question and I'd lik=
e
> > > to talk about it, but it's not clear that any change to the document
> > > will be needed.
> > >
> > > Once this (and some of the more substantive items in the Comment
> > > section) is resolved, I'd be happy to ballot Yes.
> > >
> > > The introduction notes as an advantage of JWT that:
> > >
> > >    (d)  (collection minimization) The request can be signed by a thir=
d
> > >         party attesting that the authorization request is compliant
> with
> > >         a certain policy.  For example, a request can be pre-examined
> by
> > >         a third party that all the personal data requested is strictl=
y
> > >         necessary to perform the process that the end-user asked for,
> > >         and statically signed by that third party.  The authorization
> > >         server then examines the signature and shows the conformance
> > >         status to the end-user, who would have some assurance as to t=
he
> > >         legitimacy of the request when authorizing it.  In some cases=
,
> > >         it may even be desirable to skip the authorization dialogue
> > >         under such circumstances.
> > >
> > > I'm pretty uncomfortable about suggesting that the authorization
> > > dialogue can/should be skipped; do we need to keep this example?
> > > Maybe just talking about what an expected use case could be would
> > > help alleviate my unease.
> > >
> > >
> > > ---------------------------------------------------------------------=
-
> > > COMMENT:
> > > ---------------------------------------------------------------------=
-
> > >
> > > Section 1
> > >
> > >    While it is easy to implement, the encoding in the URI does not
> allow
> > >    application layer security with confidentiality and integrity
> > >    protection to be used.  While TLS is used to offer communication
> > >
> > > nit: this wording is a little hard to read; it might be easier to
> > > reorder to "does not allow application layer security to be used to
> > > provide confidentiality and integrity protection".
> > >
> > >    The use of application layer security allows requests to be prepar=
ed
> > >    by a third party so that a client application cannot request more
> > >    permissions than previously agreed.  This offers an additional
> degree
> > >    of privacy protection.
> > >
> > > (side note) what would an example of such a third party be.  (We
> already
> > > have the resource owner, the client, and the authorization server ...
> > > maybe it's a fourth party?)
> > >
> > >    Furthermore, the request by reference allows the reduction of over=
-
> > >    the-wire overhead.
> > >
> > > We only barely mentioned by-reference at this point (one line in the
> > > Abstract), so I'd suggest "passing the request by reference".
> > >
> > >    (4)  its development status that it is an RFC and so is its
> > >         associated signing and encryption methods as [RFC7515] and
> > >         [RFC7516]
> > >
> > > nit: I'd suggest "its development status as a Proposed Standard, alon=
g
> > > with the associated signing and encryption methods [RFC7515]
> [RFC7516]."
> > >
> > >    (c)  (confidentiality protection) The request can be encrypted so
> > >         that end-to-end confidentiality can be provided even if the T=
LS
> > >         connection is terminated at one point or another.
> > >
> > > nit: TLS is always terminated at or before the user-agent, though.  S=
o
> > > maybe the user agent needs to get called out here as well (there coul=
d
> > > of course be TLS termination earlier than the user-agent in some case=
s,
> > > too).
> > >
> > >    2.  When the client does not want to do the crypto.  The
> > >        Authorization Server may provide an endpoint to accept the
> > >        Authorization Request through direct communication with the
> > >        Client so that the Client is authenticated and the channel is
> TLS
> > >        protected.
> > >
> > > How can you "not want to do [the] crypto" but still be doing TLS (wit=
h
> > > crypto)?  Perhaps we're looking for "not want to pay the additional
> > > overhead of JWS/JWE cryptography on top of TLS"?
> > >
> > > Section 1.1
> > >
> > > RFC 8174 has updated BCP 14 boilerplate text to use.
> > >
> > > Section 3
> > >
> > > nit: should this section be 2.3 to get wrapped into "terminology"?
> > >
> > > It might also be worth putting references in for the terms, though th=
ey
> > > are largely common knowledge at this point.
> > >
> > > Section 4
> > >
> > >    A Request Object (Section 2.1) is used to provide authorization
> > >    request parameters for an OAuth 2.0 authorization request.  It MUS=
T
> > >    contains all the OAuth 2.0 [RFC6749] authorization request
> parameters
> > >    including extension parameters.  The parameters are represented as
> > >
> > > nit: "all the parameters" kind of sounds like "all that are defined".
> > > But I think the intent here is "any parameter used to process the
> > > request must come from the request object and URL query parameters ar=
e
> > > ignored", so maybe "MUST contain all the parameters (including
> extension
> > > parameters) used to process the OAuth 2.0 [RFC6749] authorization
> > > request; parameters from other sources MUST NOT be used", akin to wha=
t
> > > we say down in Sections 5 and 6.3.
> > > But we need to be careful about the wording to not exclude the usage =
of
> > > the "request" and "request_uri" query parameters to  find the Request
> > > Object!
> > >
> > >    the JWT claims.  Parameter names and string values MUST be include=
d
> > >
> > > nit: maybe "the JWT claims of the object"?
> > >
> > >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
> > >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
> > >    signed or signed and encrypted.
> > >
> > > nit: I  think we want "This JSON [RFC7159] object".
> > >
> > > (Long quote incoming)
> > >
> > >    The following is an example of the Claims in a Request Object befo=
re
> > >    base64url encoding and signing.  Note that it includes extension
> > >    variables such as "nonce" and "max_age".
> > >
> > >      {
> > >       "iss": "s6BhdRkqt3",
> > >       "aud": "https://server.example.com",
> > >       "response_type": "code id_token",
> > >       "client_id": "s6BhdRkqt3",
> > >       "redirect_uri": "https://client.example.org/cb",
> > >       "scope": "openid",
> > >       "state": "af0ifjsldkj",
> > >       "nonce": "n-0S6_WzA2Mj",
> > >       "max_age": 86400
> > >      }
> > >
> > >    Signing it with the "RS256" algorithm results in this Request Obje=
ct
> > >    value (with line wraps within values for display purposes only):
> > >
> > >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRS=
a3
> > >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogIn=
Jl
> > >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJz=
Nk
> > >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW=
1w
> > >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYw=
aW
> > >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIj=
og
> > >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7=
DQ
> > >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm=
5p
> > >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVl=
fS
> > >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCi=
Ag
> > >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAg=
IH
> > >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2=
Vu
> > >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNl=
Om
> > >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmn=
vs
> > >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwaj=
yF
> > >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uR=
Tx
> > >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc=
8K
> > >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxm=
PG
> > >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
> > >
> > > Decoding the base64 of the body, we see:
> > > {
> > >  "iss": "s6BhdRkqt3",
> > >  "aud": "https://server.example.com",
> > >  "response_type": "code id_token",
> > >  "client_id": "s6BhdRkqt3",
> > >  "redirect_uri": "https://client.example.org/cb",
> > >  "scope": "openid",
> > >  "state": "af0ifjsldkj",
> > >  "nonce": "n-0S6_WzA2Mj",
> > >  "max_age": 86400,
> > >  "claims":
> > >   {
> > >    "userinfo":
> > >     {
> > >      "given_name": {"essential": true},
> > >      "nickname": null,
> > >      "email": {"essential": true},
> > >      "email_verified": {"essential": true},
> > >      "picture": null
> > >     },
> > >    "id_token":
> > >     {
> > >      "gender": null,
> > >      "birthdate": {"essential": true},
> > >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> > >     }
> > >   }
> > > }
> > >
> > > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> > > seem to talk about it.  (Note that this example is used later on as
> > > well.)
> > >
> > > Section 5.2.1
> > >
> > >    It is possible for the Request Object to include values that are t=
o
> > >    be revealed only to the Authorization Server.  As such, the
> > >    "request_uri" MUST have appropriate entropy for its lifetime.  For
> > >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
> > >    that it be removed after a reasonable timeout unless access contro=
l
> > >    measures are taken.
> > >
> > > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> > > also be useful.
> > >
> > > Section 5.2.2
> > >
> > > Do we want to remind the reader that the other query parameters are
> just
> > > for backwards compatibility?
> > >
> > > Section 5.2.3
> > >
> > >    The following is an example of this fetch process:
> > >
> > >      GET /request.jwt HTTP/1.1
> > >      Host: tfp.example.org
> > >
> > > It's useful to show good hygeine in examples; can we get the extra
> > > entropy in this request that we have in the previous example(s)?
> > >
> > > Section 6.2
> > >
> > >    The Authorization Server MUST perform the signature validation of
> the
> > >    JSON Web Signature [RFC7515] signed request object.  For this, the
> > >    "alg" Header Parameter in its JOSE Header MUST match the value of
> the
> > >    pre-registered algorithm.  The signature MUST be validated against
> > >    the appropriate key for that "client_id" and algorithm.
> > >
> > > Does "the pre-registered algorithm" concept exist in the specs outsid=
e
> > > of draft-ietf-oauth-jwt-bcp?
> > >
> > > Section 9
> > >
> > > The error codes we list in Section 7 are already registered, for the
> > > OIDC usage.  Do we want to say anything about that?   (I guess it wou=
ld
> > > be disallowed by process to try to update the existing registration t=
o
> > > also point at this document.)
> > >
> > > Section 10
> > >
> > > We probably also want to reference draft-ietf-oauth-jwt-bcp.
> > >
> > > Section 10.1
> > >
> > >    When sending the authorization request object through "request"
> > >    parameter, it MUST either be signed using JWS [RFC7515] or encrypt=
ed
> > >    using JWE [RFC7516] with then considered appropriate algorithm.
> > >
> > > Up in Section 5 we only allow (a) signed and (b) signed then encrypte=
d;
> > > similarly, in Section 4 we reiterate "signed then encrypted".  Why is
> it
> > > okay to talk about just "signed or encrypted" here?
> > >
> > > Section 10.2
> > >
> > >    (b)  Verifying that the symmetric key for the JWE encryption is th=
e
> > >         correct one if the JWE is using symmetric encryption.
> > >
> > > Similarly to the previous point, you also need to check the signature=
,
> > > which will always be there.
> > >
> > >    (d)  Authorization Server is providing an endpoint that provides a
> > >         Request Object URI in exchange for a Request Object.  In this
> > >
> > > I don't think this is a complete sentence (and it's definitely not a
> > > parallel construction with (a)-(c)!).  I think perhaps a crisp one-li=
ne
> > > summary of this method would be "Delegating the authorization check t=
o
> a
> > > separate "Request Object to Request Object URI" endpoint on the
> > > Authorization Server".  (The writing in the rest of this paragraph
> could
> > > also use an editing pass.)
> > >
> > >    (e)  A third party, such as a Trust Framework Provider, provides a=
n
> > >         endpoint that provides a Request Object URI in exchange for a
> > >         Request Object.  The same requirements as (b) above apply.  I=
n
> > >         addition, the Authorization Server MUST know out-of-band that
> > >         the Client utilizes the Trust Framework Operator.
> > >
> > > The Authorization Server also has to trust the third-party provider t=
o
> > > actually do its job and not misbehave, right?
> > >
> > > Section 10.3
> > >
> > > I'm not entirely sure what "[t]he endpoints ithat come into question =
in
> > > this specification" is supposed to mean -- is it just "the OAuth 2.0
> > > endpoints presently defined in Standards-Track RFCs"?
> > >
> > >    In [RFC6749], while Redirection URI is included, others are not
> > >    included in the Authorization Request.  As the result, the same
> > >    applies to Authorization Request Object.
> > >
> > > nit: included in what?
> > >
> > > Section 10.4
> > >
> > > It's probably also worth citing the generic URI security consideratio=
ns
> > > from RFC 3986, here.
> > >
> > > Section 10.4.1
> > >
> > >    "request_uri", and (d) do not perform recursive GET on the
> > >    "request_uri".
> > >
> > > nit: remove the "do" in order to make the construction parallel.
> > >
> > > Section 12.1
> > >
> > >    It is often hard for the user to find out if the personal data ask=
ed
> > >    for is strictly necessary.  A Trust Framework Provider can help th=
e
> > >    user by examining the Client request and comparing to the proposed
> > >    processing by the Client and certifying the request.  After the
> > >    certification, the Client, when making an Authorization Request, c=
an
> > >    submit Authorization Request to the Trust Framework Provider to
> > >    obtain the Request Object URI.
> > >
> > > side note: In my head the act of certification was the act of making
> the
> > > translation to a Request Object URI, so I'm kind of curious where my
> > > vision differs from reality.
> > >
> > > The third paragraph seems to mostly just be describing the procedure =
of
> > > how this flow works, which would not necessarily be specific to the
> > > privacy considerations section.
> > >
> > > Section 12.2.2
> > >
> > >    Even if the protected resource does not include a personally
> > >    identifiable information, it is sometimes possible to identify the
> > >    user through the Request Object URI if persistent per-user Request
> > >    Object URI is used.  A third party may observe it through browser
> > >
> > > nit: need an article for "persistent per-user Request Object URI" (or
> > > make it plural, as "URIs are used").
> > >
> > >    Therefore, per-user Request Object URI should be avoided.
> > >
> > > nit: I think this is better as "static per-user Requeste Object URIs"=
.
> > >
> > > Section 13
> > >
> > > Are there two different paragraphs for "contributions from the OAuth =
WG
> > > members"?  Are they reflecting different types of contribution?
> > >
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


Hi

Re: JWT
I understand your =
concern and we can put some explanatory notes. Having said that, JAR is sti=
ll a valid JWT, I think :-)

Re: client_id
We a=
ctually discussed client_id issues with OpenID Connect WG Call yesterday as=
 well.=C2=A0
I hear a pretty strong voice from the developer comm=
unity that they want client_id as a query parameter and it should not pose =
a security=C2=A0issue as long as it is required to match what is in the JWT=
. In fact, that was the position taken in the WG last call. So, in effect, =
WG is actually pushing back the change IESG wanted.=C2=A0

As I understand it, there are two points to be made:=C2=A0
(1) If client_id is not in the query parameter, then it MUST be in the JW=
T header OR MUST be supplied as a query parameter in some encrypted JAR cas=
e
(2) To check if requst_uri is a registered and valid URI, not h=
aving client_id in the query parameter will have performance impacts in a l=
arge AS.=C2=A0

The encryption case (1) can be solv=
ed by adding client_id in the JWT Header but it will not solve (2).=C2=A0
So, IMHO, putting client_id back to the query parameter (and MUST =
match the value in JWT) is a way to go.=C2=A0
Since that was the =
position by the WG at the WG Last Call, I do not feel that it needs to be b=
rought back to the WG last call,=C2=A0
but that is your call.=C2=
=A0

Best,=C2=A0

Nat Sakim=
ura

On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Nat,



Now it is my turn to apologize for taking a long time.



I think I see the general direction these changes are going in, and it'=
s a

reasonable approach to the unfortunate situation we find ourselves in with<=
br>
respect to JWT claims vs. OAuth parameters.=C2=A0 In effect, what we're=
 doing is

making a "profile" (for lack of a better term) of JWT, that lever=
ages the

mechanisms and algorithms of JWT but uses a different registry for

interpreting the claims in the token (that is, OAuth Parameters vs. JWT

Claims).=C2=A0 We can tell that this "profile" of JWT is being us=
ed because of

the context in which the JWT is transferred/received: if it's the "=
;request"

parameter, that's part of the definition of the OAuth Parameter, and if=


it's the result of dereferencing a "request_uri", the

application/oauth.authz.req+jwt media-type clearly indicates how the

contents should be interpreted.



However, the changes in the -20 do not give the reader much of any hint as<=
br>
to this being what's expected to happen, and that stock RFC 7519 JWT is=


*not* what's in use.=C2=A0 So I'd request that we take a close look=
 at how the

document uses "JWT" vs. "JWT encoding" (etc.); add an e=
xplicit statement

that while the JWT encoding is in use, the contents are to be interpreted
by interpreting the JWT claims as OAuth Parameters (and not as per the IANA=


registry of JWT claims); and add some discussion (similar to the above)

about how the application context makes it unambiguous whether the

JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
document.



With respect to my second ("discuss discuss") point, Nat and I di=
d have a

discussion in-person and I accept that there may be some scenarios in which=


skipping the authorization dialogue is appropriate, so the example can

remain.





Moving on from my Discuss position, I do get the sense from the ongoing

discussion on the list that there's not clear agreement about the curre=
nt

formulation that requires all parameters (but "request" and "=
;request_uri")

to be in the JAR, especially with respect to "client_id" that mig=
ht be

needed to unpack the JAR in some cases!=C2=A0 So I'm not sure whether t=
he WG

wants to bring the document back to the WG to iron out those issues before<=
br>
it returns to the IESG.=C2=A0 I'm a little reluctant to switch my posit=
ion to

"No Objection" until we have a clearer picture of what the WG wan=
ts to do

on this front -- in my understanding, we can't really publish the docum=
ent

without at least some solution ("client_id") for the encrypted-re=
quest

key-lookup case.



Thanks,



Ben





On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:

> Hi

> 

> Took a long time but finally all the changes needed to resolve the DIS=
CUSS

> comments are (hopefully) applied as -20.

> 

> There is one change that impacts the process: the draft now has IANA
> request so it needs to be referred back to IANA.

> 

> The IETF datatracker status page for this draft is:

> datatracker.ietf.org/doc/draft-ietf-oau=
th-jwsreq/

> 

> Best,

> 

> Nat Sakimura

> 

> 2019=E5=B9=B47=E6=9C=883=E6=97=A5(=E6=B0=B4) 4:21 Benjamin Kaduk via D=
atatracker <norepl=
y@ietf.org>:

> 

> > Benjamin Kaduk has entered the following ballot position for

> > draft-ietf-oauth-jwsreq-19: Discuss

> >

> > When responding, please keep the subject line intact and reply to=
 all

> > email addresses included in the To and CC lines. (Feel free to cu=
t this

> > introductory paragraph, however.)

> >

> >

> > Please refer to https://www.ietf.=
org/iesg/statement/discuss-criteria.html

> > for more information about IESG DISCUSS and COMMENT positions.
> >

> >

> > The document, along with other ballot positions, can be found her=
e:

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

> >

> >

> >

> > -----------------------------------------------------------------=
-----

> > DISCUSS:

> > -----------------------------------------------------------------=
-----

> >

> > This is a "discuss discuss" -- it's an important qu=
estion and I'd like

> > to talk about it, but it's not clear that any change to the d=
ocument

> > will be needed.

> >

> > Once this (and some of the more substantive items in the Comment<=
br>
> > section) is resolved, I'd be happy to ballot Yes.

> >

> > The introduction notes as an advantage of JWT that:

> >

> >=C2=A0 =C2=A0 (d)=C2=A0 (collection minimization) The request can =
be signed by a third

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0party attesting that the authori=
zation request is compliant with

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a certain policy.=C2=A0 For exam=
ple, a request can be pre-examined by

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a third party that all the perso=
nal data requested is strictly

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0necessary to perform the process=
 that the end-user asked for,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and statically signed by that th=
ird party.=C2=A0 The authorization

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server then examines the signatu=
re and shows the conformance

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status to the end-user, who woul=
d have some assurance as to the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0legitimacy of the request when a=
uthorizing it.=C2=A0 In some cases,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it may even be desirable to skip=
 the authorization dialogue

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0under such circumstances.

> >

> > I'm pretty uncomfortable about suggesting that the authorizat=
ion

> > dialogue can/should be skipped; do we need to keep this example?<=
br>
> > Maybe just talking about what an expected use case could be would=


> > help alleviate my unease.

> >

> >

> > -----------------------------------------------------------------=
-----

> > COMMENT:

> > -----------------------------------------------------------------=
-----

> >

> > Section 1

> >

> >=C2=A0 =C2=A0 While it is easy to implement, the encoding in the U=
RI does not allow

> >=C2=A0 =C2=A0 application layer security with confidentiality and =
integrity

> >=C2=A0 =C2=A0 protection to be used.=C2=A0 While TLS is used to of=
fer communication

> >

> > nit: this wording is a little hard to read; it might be easier to=


> > reorder to "does not allow application layer security to be =
used to

> > provide confidentiality and integrity protection".

> >

> >=C2=A0 =C2=A0 The use of application layer security allows request=
s to be prepared

> >=C2=A0 =C2=A0 by a third party so that a client application cannot=
 request more

> >=C2=A0 =C2=A0 permissions than previously agreed.=C2=A0 This offer=
s an additional degree

> >=C2=A0 =C2=A0 of privacy protection.

> >

> > (side note) what would an example of such a third party be.=C2=A0=
 (We already

> > have the resource owner, the client, and the authorization server=
 ...

> > maybe it's a fourth party?)

> >

> >=C2=A0 =C2=A0 Furthermore, the request by reference allows the red=
uction of over-

> >=C2=A0 =C2=A0 the-wire overhead.

> >

> > We only barely mentioned by-reference at this point (one line in =
the

> > Abstract), so I'd suggest "passing the request by refere=
nce".

> >

> >=C2=A0 =C2=A0 (4)=C2=A0 its development status that it is an RFC a=
nd so is its

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated signing and encryptio=
n methods as [RFC7515] and

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7516]

> >

> > nit: I'd suggest "its development status as a Proposed S=
tandard, along

> > with the associated signing and encryption methods [RFC7515] [RFC=
7516]."

> >

> >=C2=A0 =C2=A0 (c)=C2=A0 (confidentiality protection) The request c=
an be encrypted so

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that end-to-end confidentiality =
can be provided even if the TLS

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection is terminated at one =
point or another.

> >

> > nit: TLS is always terminated at or before the user-agent, though=
.=C2=A0 So

> > maybe the user agent needs to get called out here as well (there =
could

> > of course be TLS termination earlier than the user-agent in some =
cases,

> > too).

> >

> >=C2=A0 =C2=A0 2.=C2=A0 When the client does not want to do the cry=
pto.=C2=A0 The

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authorization Server may provide an en=
dpoint to accept the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authorization Request through direct c=
ommunication with the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Client so that the Client is authentic=
ated and the channel is TLS

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 protected.

> >

> > How can you "not want to do [the] crypto" but still be =
doing TLS (with

> > crypto)?=C2=A0 Perhaps we're looking for "not want to pa=
y the additional

> > overhead of JWS/JWE cryptography on top of TLS"?

> >

> > Section 1.1

> >

> > RFC 8174 has updated BCP 14 boilerplate text to use.

> >

> > Section 3

> >

> > nit: should this section be 2.3 to get wrapped into "termino=
logy"?

> >

> > It might also be worth putting references in for the terms, thoug=
h they

> > are largely common knowledge at this point.

> >

> > Section 4

> >

> >=C2=A0 =C2=A0 A Request Object (Section 2.1) is used to provide au=
thorization

> >=C2=A0 =C2=A0 request parameters for an OAuth 2.0 authorization re=
quest.=C2=A0 It MUST

> >=C2=A0 =C2=A0 contains all the OAuth 2.0 [RFC6749] authorization r=
equest parameters

> >=C2=A0 =C2=A0 including extension parameters.=C2=A0 The parameters=
 are represented as

> >

> > nit: "all the parameters" kind of sounds like "all=
 that are defined".

> > But I think the intent here is "any parameter used to proces=
s the

> > request must come from the request object and URL query parameter=
s are

> > ignored", so maybe "MUST contain all the parameters (in=
cluding extension

> > parameters) used to process the OAuth 2.0 [RFC6749] authorization=


> > request; parameters from other sources MUST NOT be used", ak=
in to what

> > we say down in Sections 5 and 6.3.

> > But we need to be careful about the wording to not exclude the us=
age of

> > the "request" and "request_uri" query paramet=
ers to=C2=A0 find the Request

> > Object!

> >

> >=C2=A0 =C2=A0 the JWT claims.=C2=A0 Parameter names and string val=
ues MUST be included

> >

> > nit: maybe "the JWT claims of the object"?

> >

> >=C2=A0 =C2=A0 any extension parameters.=C2=A0 This JSON [RFC7159] =
constitutes the JWT

> >=C2=A0 =C2=A0 Claims Set defined in JWT [RFC7519].=C2=A0 The JWT C=
laims Set is then

> >=C2=A0 =C2=A0 signed or signed and encrypted.

> >

> > nit: I=C2=A0 think we want "This JSON [RFC7159] object"=
.

> >

> > (Long quote incoming)

> >

> >=C2=A0 =C2=A0 The following is an example of the Claims in a Reque=
st Object before

> >=C2=A0 =C2=A0 base64url encoding and signing.=C2=A0 Note that it i=
ncludes extension

> >=C2=A0 =C2=A0 variables such as "nonce" and "max_ag=
e".

> >

> >=C2=A0 =C2=A0 =C2=A0 {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"iss": "s6BhdRkqt3"=
,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"aud": "https://server.=
example.com",

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"response_type": "code i=
d_token",

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"client_id": "s6BhdRkqt3=
",

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"redirect_uri": "htt=
ps://client.example.org/cb",

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"scope": "openid",<=
br>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"state": "af0ifjsldkj&qu=
ot;,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"nonce": "n-0S6_WzA2Mj&q=
uot;,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"max_age": 86400

> >=C2=A0 =C2=A0 =C2=A0 }

> >

> >=C2=A0 =C2=A0 Signing it with the "RS256" algorithm resu=
lts in this Request Object

> >=C2=A0 =C2=A0 value (with line wraps within values for display pur=
poses only):

> >

> >=C2=A0 =C2=A0 =C2=A0 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KI=
CJpc3MiOiAiczZCaGRSa3

> >=C2=A0 =C2=A0 =C2=A0 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGF=
tcGxlLmNvbSIsDQogInJl

> >=C2=A0 =C2=A0 =C2=A0 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogI=
mNsaWVudF9pZCI6ICJzNk

> >=C2=A0 =C2=A0 =C2=A0 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHB=
zOi8vY2xpZW50LmV4YW1w

> >=C2=A0 =C2=A0 =C2=A0 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNC=
iAic3RhdGUiOiAiYWYwaW

> >=C2=A0 =C2=A0 =C2=A0 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo=
iLA0KICJtYXhfYWdlIjog

> >=C2=A0 =C2=A0 =C2=A0 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlc=
mluZm8iOiANCiAgICB7DQ

> >=C2=A0 =C2=A0 =C2=A0 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB=
0cnVlfSwNCiAgICAgIm5p

> >=C2=A0 =C2=A0 =C2=A0 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc=
3NlbnRpYWwiOiB0cnVlfS

> >=C2=A0 =C2=A0 =C2=A0 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnR=
pYWwiOiB0cnVlfSwNCiAg

> >=C2=A0 =C2=A0 =C2=A0 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZ=
F90b2tlbiI6IA0KICAgIH

> >=C2=A0 =C2=A0 =C2=A0 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ=
0aGRhdGUiOiB7ImVzc2Vu

> >=C2=A0 =C2=A0 =C2=A0 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1Z=
XMiOiBbInVybjptYWNlOm

> >=C2=A0 =C2=A0 =C2=A0 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0=
NCn0.nwwnNsk1-Zkbmnvs

> >=C2=A0 =C2=A0 =C2=A0 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPY=
s8KQxsn6R9Emo_wHwajyF

> >=C2=A0 =C2=A0 =C2=A0 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9h=
jBcHs68PkgjDVTrG1uRTx

> >=C2=A0 =C2=A0 =C2=A0 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJ=
hM0_AKQUfqKnRlrRscc8K

> >=C2=A0 =C2=A0 =C2=A0 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70=
xnB4SkG6pXfLSjLLlxmPG

> >=C2=A0 =C2=A0 =C2=A0 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7x=
MbpL-2QgwUsAlMGzw

> >

> > Decoding the base64 of the body, we see:

> > {

> >=C2=A0 "iss": "s6BhdRkqt3",

> >=C2=A0 "aud": "https://server.example.com"=
;,

> >=C2=A0 "response_type": "code id_token",

> >=C2=A0 "client_id": "s6BhdRkqt3",

> >=C2=A0 "redirect_uri": "https://client.example.=
org/cb",

> >=C2=A0 "scope": "openid",

> >=C2=A0 "state": "af0ifjsldkj",

> >=C2=A0 "nonce": "n-0S6_WzA2Mj",

> >=C2=A0 "max_age": 86400,

> >=C2=A0 "claims":

> >=C2=A0 =C2=A0{

> >=C2=A0 =C2=A0 "userinfo":

> >=C2=A0 =C2=A0 =C2=A0{

> >=C2=A0 =C2=A0 =C2=A0 "given_name": {"essential"=
;: true},

> >=C2=A0 =C2=A0 =C2=A0 "nickname": null,

> >=C2=A0 =C2=A0 =C2=A0 "email": {"essential": tr=
ue},

> >=C2=A0 =C2=A0 =C2=A0 "email_verified": {"essential&=
quot;: true},

> >=C2=A0 =C2=A0 =C2=A0 "picture": null

> >=C2=A0 =C2=A0 =C2=A0},

> >=C2=A0 =C2=A0 "id_token":

> >=C2=A0 =C2=A0 =C2=A0{

> >=C2=A0 =C2=A0 =C2=A0 "gender": null,

> >=C2=A0 =C2=A0 =C2=A0 "birthdate": {"essential"=
: true},

> >=C2=A0 =C2=A0 =C2=A0 "acr": {"values": ["=
urn:mace:incommon:iap:silver"]}

> >=C2=A0 =C2=A0 =C2=A0}

> >=C2=A0 =C2=A0}

> > }

> >

> > I'm not sure where the "claims" claim is coming fro=
m -- 6749 doesn't

> > seem to talk about it.=C2=A0 (Note that this example is used late=
r on as

> > well.)

> >

> > Section 5.2.1

> >

> >=C2=A0 =C2=A0 It is possible for the Request Object to include val=
ues that are to

> >=C2=A0 =C2=A0 be revealed only to the Authorization Server.=C2=A0 =
As such, the

> >=C2=A0 =C2=A0 "request_uri" MUST have appropriate entrop=
y for its lifetime.=C2=A0 For

> >=C2=A0 =C2=A0 the guidance, refer to 5.1.4.2.2 of [RFC6819].=C2=A0=
 It is RECOMMENDED

> >=C2=A0 =C2=A0 that it be removed after a reasonable timeout unless=
 access control

> >=C2=A0 =C2=A0 measures are taken.

> >

> > It sounds like a link to https://www.w3.org/TR/capab=
ility-urls/ might

> > also be useful.

> >

> > Section 5.2.2

> >

> > Do we want to remind the reader that the other query parameters a=
re just

> > for backwards compatibility?

> >

> > Section 5.2.3

> >

> >=C2=A0 =C2=A0 The following is an example of this fetch process:
> >

> >=C2=A0 =C2=A0 =C2=A0 GET /request.jwt HTTP/1.1

> >=C2=A0 =C2=A0 =C2=A0 Host: tfp.example.org

> >

> > It's useful to show good hygeine in examples; can we get the =
extra

> > entropy in this request that we have in the previous example(s)?<=
br>
> >

> > Section 6.2

> >

> >=C2=A0 =C2=A0 The Authorization Server MUST perform the signature =
validation of the

> >=C2=A0 =C2=A0 JSON Web Signature [RFC7515] signed request object.=
=C2=A0 For this, the

> >=C2=A0 =C2=A0 "alg" Header Parameter in its JOSE Header =
MUST match the value of the

> >=C2=A0 =C2=A0 pre-registered algorithm.=C2=A0 The signature MUST b=
e validated against

> >=C2=A0 =C2=A0 the appropriate key for that "client_id" a=
nd algorithm.

> >

> > Does "the pre-registered algorithm" concept exist in th=
e specs outside

> > of draft-ietf-oauth-jwt-bcp?

> >

> > Section 9

> >

> > The error codes we list in Section 7 are already registered, for =
the

> > OIDC usage.=C2=A0 Do we want to say anything about that?=C2=A0 =
=C2=A0(I guess it would

> > be disallowed by process to try to update the existing registrati=
on to

> > also point at this document.)

> >

> > Section 10

> >

> > We probably also want to reference draft-ietf-oauth-jwt-bcp.

> >

> > Section 10.1

> >

> >=C2=A0 =C2=A0 When sending the authorization request object throug=
h "request"

> >=C2=A0 =C2=A0 parameter, it MUST either be signed using JWS [RFC75=
15] or encrypted

> >=C2=A0 =C2=A0 using JWE [RFC7516] with then considered appropriate=
 algorithm.

> >

> > Up in Section 5 we only allow (a) signed and (b) signed then encr=
ypted;

> > similarly, in Section 4 we reiterate "signed then encrypted&=
quot;.=C2=A0 Why is it

> > okay to talk about just "signed or encrypted" here?

> >

> > Section 10.2

> >

> >=C2=A0 =C2=A0 (b)=C2=A0 Verifying that the symmetric key for the J=
WE encryption is the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0correct one if the JWE is using =
symmetric encryption.

> >

> > Similarly to the previous point, you also need to check the signa=
ture,

> > which will always be there.

> >

> >=C2=A0 =C2=A0 (d)=C2=A0 Authorization Server is providing an endpo=
int that provides a

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Request Object URI in exchange f=
or a Request Object.=C2=A0 In this

> >

> > I don't think this is a complete sentence (and it's defin=
itely not a

> > parallel construction with (a)-(c)!).=C2=A0 I think perhaps a cri=
sp one-line

> > summary of this method would be "Delegating the authorizatio=
n check to a

> > separate "Request Object to Request Object URI" endpoin=
t on the

> > Authorization Server".=C2=A0 (The writing in the rest of thi=
s paragraph could

> > also use an editing pass.)

> >

> >=C2=A0 =C2=A0 (e)=C2=A0 A third party, such as a Trust Framework P=
rovider, provides an

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint that provides a Request=
 Object URI in exchange for a

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Request Object.=C2=A0 The same r=
equirements as (b) above apply.=C2=A0 In

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addition, the Authorization Serv=
er MUST know out-of-band that

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the Client utilizes the Trust Fr=
amework Operator.

> >

> > The Authorization Server also has to trust the third-party provid=
er to

> > actually do its job and not misbehave, right?

> >

> > Section 10.3

> >

> > I'm not entirely sure what "[t]he endpoints ithat come i=
nto question in

> > this specification" is supposed to mean -- is it just "=
the OAuth 2.0

> > endpoints presently defined in Standards-Track RFCs"?

> >

> >=C2=A0 =C2=A0 In [RFC6749], while Redirection URI is included, oth=
ers are not

> >=C2=A0 =C2=A0 included in the Authorization Request.=C2=A0 As the =
result, the same

> >=C2=A0 =C2=A0 applies to Authorization Request Object.

> >

> > nit: included in what?

> >

> > Section 10.4

> >

> > It's probably also worth citing the generic URI security cons=
iderations

> > from RFC 3986, here.

> >

> > Section 10.4.1

> >

> >=C2=A0 =C2=A0 "request_uri", and (d) do not perform recu=
rsive GET on the

> >=C2=A0 =C2=A0 "request_uri".

> >

> > nit: remove the "do" in order to make the construction =
parallel.

> >

> > Section 12.1

> >

> >=C2=A0 =C2=A0 It is often hard for the user to find out if the per=
sonal data asked

> >=C2=A0 =C2=A0 for is strictly necessary.=C2=A0 A Trust Framework P=
rovider can help the

> >=C2=A0 =C2=A0 user by examining the Client request and comparing t=
o the proposed

> >=C2=A0 =C2=A0 processing by the Client and certifying the request.=
=C2=A0 After the

> >=C2=A0 =C2=A0 certification, the Client, when making an Authorizat=
ion Request, can

> >=C2=A0 =C2=A0 submit Authorization Request to the Trust Framework =
Provider to

> >=C2=A0 =C2=A0 obtain the Request Object URI.

> >

> > side note: In my head the act of certification was the act of mak=
ing the

> > translation to a Request Object URI, so I'm kind of curious w=
here my

> > vision differs from reality.

> >

> > The third paragraph seems to mostly just be describing the proced=
ure of

> > how this flow works, which would not necessarily be specific to t=
he

> > privacy considerations section.

> >

> > Section 12.2.2

> >

> >=C2=A0 =C2=A0 Even if the protected resource does not include a pe=
rsonally

> >=C2=A0 =C2=A0 identifiable information, it is sometimes possible t=
o identify the

> >=C2=A0 =C2=A0 user through the Request Object URI if persistent pe=
r-user Request

> >=C2=A0 =C2=A0 Object URI is used.=C2=A0 A third party may observe =
it through browser

> >

> > nit: need an article for "persistent per-user Request Object=
 URI" (or

> > make it plural, as "URIs are used").

> >

> >=C2=A0 =C2=A0 Therefore, per-user Request Object URI should be avo=
ided.

> >

> > nit: I think this is better as "static per-user Requeste Obj=
ect URIs".

> >

> > Section 13

> >

> > Are there two different paragraphs for "contributions from t=
he OAuth WG

> > members"?=C2=A0 Are they reflecting different types of contr=
ibution?

> >

> >

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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


> >

> -- 

> Nat Sakimura (=3Dnat)

> Chairman, OpenID Foundation

> http://nat.sakimura.org/

> @_nat_en




-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Found=
ation
http://nat.=
sakimura.org/
@_nat_en


--000000000000f44d36059d66ddf6--


From nobody Fri Jan 31 06:25: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 ED3A712011E for ; Fri, 31 Jan 2020 06:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB51j88B5Ix6 for ; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F71120104 for ; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
Received: by mail-qt1-x843.google.com with SMTP id t13so5523791qto.3 for ; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jssWvkuWkZNoY2zsWTbml1xH4PEQ9oNd3Wubw72ckcY=; b=V/RvuR+nITPe749T2xDjvyl8Im2VZ8XQijaeZu0YkszgeleVit7bHa3CR2qEJglIfz c3c2F1NmNmA4oyCfifKIJMzG70WXQ3+xkfKwq91ML1QfPG8dSOA4sDfH7D9vxXiIgNgs TsiFVGmU8IjtClhlE5TUeA+GkW9grkOcF6JbcGKA8wSHGqfPwV6ixmnoO50AMnRis8db Gubo6ytYbhZRT7Gt+/B9gTiWd2A6ggZGAergmFVFEaOHCvYF5742tQ61aI4ZVUpU47Yy GYmWmcvbcDAWqdtrxbzHd1YLPSWmoshsjs2ycGpTguZJE1Apb8WDfRxzEnUDBqlzbesu eaGw==
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:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=jssWvkuWkZNoY2zsWTbml1xH4PEQ9oNd3Wubw72ckcY=; b=ng2Z+iCDNZUJaQF2eQ4iKgcctISIwgiWQy+hZw3J4OjSqb6mBY+ydMOjx8tLI4L/R5 hcoIcXK1FNCyjAc49MF3Pp0j2c9+CZW8QMxn4Qqn6uqdFm8Ee+54lc/7HjOnI3DiEIRe Cak9zG/nDEW0rXbd4G3vEFq+Ph1LrduOZ5CFwrvSf/gkrw5M+o6ynDJESEWsYwp2emUo gqbaHSCTHsiYyz250Q4ItaTwUkU0IWh4CUmQK4jA+gx/MoFUziRqFtjQ0VYpI2SzCTJK wFfdyblyIOURoi0iJpSO/Ws1e/KEBq6YBMy+8Cn9OlkJ5qb2JgUmkQsBIqqCCLUpD5pj IrXA==
X-Gm-Message-State: APjAAAXXw2dO7QUQeL/QWyOxk0eZUUsnue2XcP8KVPrPAFmmf41oLijU AQZQdeZaYYpKBvHK7Xw+Uzk5jLfQs8K7Ew==
X-Google-Smtp-Source: APXvYqx1aVbvcCvITR5TJ1jLTZukzVCKlUeoswykfMtPi0F3Dc95WCIGLS8UNOPkGZiU7AJpcLDGqw==
X-Received: by 2002:ac8:1e08:: with SMTP id n8mr10724730qtl.175.1580480706708;  Fri, 31 Jan 2020 06:25:06 -0800 (PST)
Received: from [192.168.8.103] ([190.107.226.39]) by smtp.gmail.com with ESMTPSA id n20sm4449590qkk.54.2020.01.31.06.25.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:25:05 -0800 (PST)
To: Nat Sakimura , Benjamin Kaduk 
Cc: The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth , oauth-chairs@ietf.org
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com>  <20200129232014.GN48797@kduck.mit.edu> 
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
Date: Fri, 31 Jan 2020 11:25:01 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Jan 2020 14:25:12 -0000

>From the discussions I have had, I agree with Nat's assment.

John B.

On 1/31/2020 12:06 AM, Nat Sakimura wrote:
> Hi
>
> Re: JWT
> I understand your concern and we can put some explanatory notes. Having
> said that, JAR is still a valid JWT, I think :-)
>
> Re: client_id
> We actually discussed client_id issues with OpenID Connect WG Call
> yesterday as well.
> I hear a pretty strong voice from the developer community that they want
> client_id as a query parameter and it should not pose a security issue as
> long as it is required to match what is in the JWT. In fact, that was the
> position taken in the WG last call. So, in effect, WG is actually pushing
> back the change IESG wanted.
>
> As I understand it, there are two points to be made:
> (1) If client_id is not in the query parameter, then it MUST be in the JWT
> header OR MUST be supplied as a query parameter in some encrypted JAR case
> (2) To check if requst_uri is a registered and valid URI, not having
> client_id in the query parameter will have performance impacts in a large
> AS.
>
> The encryption case (1) can be solved by adding client_id in the JWT Header
> but it will not solve (2).
> So, IMHO, putting client_id back to the query parameter (and MUST match the
> value in JWT) is a way to go.
> Since that was the position by the WG at the WG Last Call, I do not feel
> that it needs to be brought back to the WG last call,
> but that is your call.
>
> Best,
>
> Nat Sakimura
>
> On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk  wrote:
>
>> Hi Nat,
>>
>> Now it is my turn to apologize for taking a long time.
>>
>> I think I see the general direction these changes are going in, and it's a
>> reasonable approach to the unfortunate situation we find ourselves in with
>> respect to JWT claims vs. OAuth parameters.  In effect, what we're doing is
>> making a "profile" (for lack of a better term) of JWT, that leverages the
>> mechanisms and algorithms of JWT but uses a different registry for
>> interpreting the claims in the token (that is, OAuth Parameters vs. JWT
>> Claims).  We can tell that this "profile" of JWT is being used because of
>> the context in which the JWT is transferred/received: if it's the "request"
>> parameter, that's part of the definition of the OAuth Parameter, and if
>> it's the result of dereferencing a "request_uri", the
>> application/oauth.authz.req+jwt media-type clearly indicates how the
>> contents should be interpreted.
>>
>> However, the changes in the -20 do not give the reader much of any hint as
>> to this being what's expected to happen, and that stock RFC 7519 JWT is
>> *not* what's in use.  So I'd request that we take a close look at how the
>> document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
>> that while the JWT encoding is in use, the contents are to be interpreted
>> by interpreting the JWT claims as OAuth Parameters (and not as per the IANA
>> registry of JWT claims); and add some discussion (similar to the above)
>> about how the application context makes it unambiguous whether the
>> JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
>> document.
>>
>> With respect to my second ("discuss discuss") point, Nat and I did have a
>> discussion in-person and I accept that there may be some scenarios in which
>> skipping the authorization dialogue is appropriate, so the example can
>> remain.
>>
>>
>> Moving on from my Discuss position, I do get the sense from the ongoing
>> discussion on the list that there's not clear agreement about the current
>> formulation that requires all parameters (but "request" and "request_uri")
>> to be in the JAR, especially with respect to "client_id" that might be
>> needed to unpack the JAR in some cases!  So I'm not sure whether the WG
>> wants to bring the document back to the WG to iron out those issues before
>> it returns to the IESG.  I'm a little reluctant to switch my position to
>> "No Objection" until we have a clearer picture of what the WG wants to do
>> on this front -- in my understanding, we can't really publish the document
>> without at least some solution ("client_id") for the encrypted-request
>> key-lookup case.
>>
>> Thanks,
>>
>> Ben
>>
>>
>> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
>>> Hi
>>>
>>> Took a long time but finally all the changes needed to resolve the
>> DISCUSS
>>> comments are (hopefully) applied as -20.
>>>
>>> There is one change that impacts the process: the draft now has IANA
>>> request so it needs to be referred back to IANA.
>>>
>>> The IETF datatracker status page for this draft is:
>>> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>
>>> Best,
>>>
>>> Nat Sakimura
>>>
>>> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker :
>>>
>>>> Benjamin Kaduk has entered the following ballot position for
>>>> draft-ietf-oauth-jwsreq-19: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> This is a "discuss discuss" -- it's an important question and I'd like
>>>> to talk about it, but it's not clear that any change to the document
>>>> will be needed.
>>>>
>>>> Once this (and some of the more substantive items in the Comment
>>>> section) is resolved, I'd be happy to ballot Yes.
>>>>
>>>> The introduction notes as an advantage of JWT that:
>>>>
>>>>    (d)  (collection minimization) The request can be signed by a third
>>>>         party attesting that the authorization request is compliant
>> with
>>>>         a certain policy.  For example, a request can be pre-examined
>> by
>>>>         a third party that all the personal data requested is strictly
>>>>         necessary to perform the process that the end-user asked for,
>>>>         and statically signed by that third party.  The authorization
>>>>         server then examines the signature and shows the conformance
>>>>         status to the end-user, who would have some assurance as to the
>>>>         legitimacy of the request when authorizing it.  In some cases,
>>>>         it may even be desirable to skip the authorization dialogue
>>>>         under such circumstances.
>>>>
>>>> I'm pretty uncomfortable about suggesting that the authorization
>>>> dialogue can/should be skipped; do we need to keep this example?
>>>> Maybe just talking about what an expected use case could be would
>>>> help alleviate my unease.
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Section 1
>>>>
>>>>    While it is easy to implement, the encoding in the URI does not
>> allow
>>>>    application layer security with confidentiality and integrity
>>>>    protection to be used.  While TLS is used to offer communication
>>>>
>>>> nit: this wording is a little hard to read; it might be easier to
>>>> reorder to "does not allow application layer security to be used to
>>>> provide confidentiality and integrity protection".
>>>>
>>>>    The use of application layer security allows requests to be prepared
>>>>    by a third party so that a client application cannot request more
>>>>    permissions than previously agreed.  This offers an additional
>> degree
>>>>    of privacy protection.
>>>>
>>>> (side note) what would an example of such a third party be.  (We
>> already
>>>> have the resource owner, the client, and the authorization server ...
>>>> maybe it's a fourth party?)
>>>>
>>>>    Furthermore, the request by reference allows the reduction of over-
>>>>    the-wire overhead.
>>>>
>>>> We only barely mentioned by-reference at this point (one line in the
>>>> Abstract), so I'd suggest "passing the request by reference".
>>>>
>>>>    (4)  its development status that it is an RFC and so is its
>>>>         associated signing and encryption methods as [RFC7515] and
>>>>         [RFC7516]
>>>>
>>>> nit: I'd suggest "its development status as a Proposed Standard, along
>>>> with the associated signing and encryption methods [RFC7515]
>> [RFC7516]."
>>>>    (c)  (confidentiality protection) The request can be encrypted so
>>>>         that end-to-end confidentiality can be provided even if the TLS
>>>>         connection is terminated at one point or another.
>>>>
>>>> nit: TLS is always terminated at or before the user-agent, though.  So
>>>> maybe the user agent needs to get called out here as well (there could
>>>> of course be TLS termination earlier than the user-agent in some cases,
>>>> too).
>>>>
>>>>    2.  When the client does not want to do the crypto.  The
>>>>        Authorization Server may provide an endpoint to accept the
>>>>        Authorization Request through direct communication with the
>>>>        Client so that the Client is authenticated and the channel is
>> TLS
>>>>        protected.
>>>>
>>>> How can you "not want to do [the] crypto" but still be doing TLS (with
>>>> crypto)?  Perhaps we're looking for "not want to pay the additional
>>>> overhead of JWS/JWE cryptography on top of TLS"?
>>>>
>>>> Section 1.1
>>>>
>>>> RFC 8174 has updated BCP 14 boilerplate text to use.
>>>>
>>>> Section 3
>>>>
>>>> nit: should this section be 2.3 to get wrapped into "terminology"?
>>>>
>>>> It might also be worth putting references in for the terms, though they
>>>> are largely common knowledge at this point.
>>>>
>>>> Section 4
>>>>
>>>>    A Request Object (Section 2.1) is used to provide authorization
>>>>    request parameters for an OAuth 2.0 authorization request.  It MUST
>>>>    contains all the OAuth 2.0 [RFC6749] authorization request
>> parameters
>>>>    including extension parameters.  The parameters are represented as
>>>>
>>>> nit: "all the parameters" kind of sounds like "all that are defined".
>>>> But I think the intent here is "any parameter used to process the
>>>> request must come from the request object and URL query parameters are
>>>> ignored", so maybe "MUST contain all the parameters (including
>> extension
>>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization
>>>> request; parameters from other sources MUST NOT be used", akin to what
>>>> we say down in Sections 5 and 6.3.
>>>> But we need to be careful about the wording to not exclude the usage of
>>>> the "request" and "request_uri" query parameters to  find the Request
>>>> Object!
>>>>
>>>>    the JWT claims.  Parameter names and string values MUST be included
>>>>
>>>> nit: maybe "the JWT claims of the object"?
>>>>
>>>>    any extension parameters.  This JSON [RFC7159] constitutes the JWT
>>>>    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>>>>    signed or signed and encrypted.
>>>>
>>>> nit: I  think we want "This JSON [RFC7159] object".
>>>>
>>>> (Long quote incoming)
>>>>
>>>>    The following is an example of the Claims in a Request Object before
>>>>    base64url encoding and signing.  Note that it includes extension
>>>>    variables such as "nonce" and "max_age".
>>>>
>>>>      {
>>>>       "iss": "s6BhdRkqt3",
>>>>       "aud": "https://server.example.com",
>>>>       "response_type": "code id_token",
>>>>       "client_id": "s6BhdRkqt3",
>>>>       "redirect_uri": "https://client.example.org/cb",
>>>>       "scope": "openid",
>>>>       "state": "af0ifjsldkj",
>>>>       "nonce": "n-0S6_WzA2Mj",
>>>>       "max_age": 86400
>>>>      }
>>>>
>>>>    Signing it with the "RS256" algorithm results in this Request Object
>>>>    value (with line wraps within values for display purposes only):
>>>>
>>>>      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
>>>>      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
>>>>      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
>>>>      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
>>>>      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
>>>>      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
>>>>      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
>>>>      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
>>>>      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
>>>>      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
>>>>      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
>>>>      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
>>>>      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
>>>>      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
>>>>      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>>>>      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
>>>>      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
>>>>      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
>>>>      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>>>>
>>>> Decoding the base64 of the body, we see:
>>>> {
>>>>  "iss": "s6BhdRkqt3",
>>>>  "aud": "https://server.example.com",
>>>>  "response_type": "code id_token",
>>>>  "client_id": "s6BhdRkqt3",
>>>>  "redirect_uri": "https://client.example.org/cb",
>>>>  "scope": "openid",
>>>>  "state": "af0ifjsldkj",
>>>>  "nonce": "n-0S6_WzA2Mj",
>>>>  "max_age": 86400,
>>>>  "claims":
>>>>   {
>>>>    "userinfo":
>>>>     {
>>>>      "given_name": {"essential": true},
>>>>      "nickname": null,
>>>>      "email": {"essential": true},
>>>>      "email_verified": {"essential": true},
>>>>      "picture": null
>>>>     },
>>>>    "id_token":
>>>>     {
>>>>      "gender": null,
>>>>      "birthdate": {"essential": true},
>>>>      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>>>>     }
>>>>   }
>>>> }
>>>>
>>>> I'm not sure where the "claims" claim is coming from -- 6749 doesn't
>>>> seem to talk about it.  (Note that this example is used later on as
>>>> well.)
>>>>
>>>> Section 5.2.1
>>>>
>>>>    It is possible for the Request Object to include values that are to
>>>>    be revealed only to the Authorization Server.  As such, the
>>>>    "request_uri" MUST have appropriate entropy for its lifetime.  For
>>>>    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
>>>>    that it be removed after a reasonable timeout unless access control
>>>>    measures are taken.
>>>>
>>>> It sounds like a link to https://www.w3.org/TR/capability-urls/ might
>>>> also be useful.
>>>>
>>>> Section 5.2.2
>>>>
>>>> Do we want to remind the reader that the other query parameters are
>> just
>>>> for backwards compatibility?
>>>>
>>>> Section 5.2.3
>>>>
>>>>    The following is an example of this fetch process:
>>>>
>>>>      GET /request.jwt HTTP/1.1
>>>>      Host: tfp.example.org
>>>>
>>>> It's useful to show good hygeine in examples; can we get the extra
>>>> entropy in this request that we have in the previous example(s)?
>>>>
>>>> Section 6.2
>>>>
>>>>    The Authorization Server MUST perform the signature validation of
>> the
>>>>    JSON Web Signature [RFC7515] signed request object.  For this, the
>>>>    "alg" Header Parameter in its JOSE Header MUST match the value of
>> the
>>>>    pre-registered algorithm.  The signature MUST be validated against
>>>>    the appropriate key for that "client_id" and algorithm.
>>>>
>>>> Does "the pre-registered algorithm" concept exist in the specs outside
>>>> of draft-ietf-oauth-jwt-bcp?
>>>>
>>>> Section 9
>>>>
>>>> The error codes we list in Section 7 are already registered, for the
>>>> OIDC usage.  Do we want to say anything about that?   (I guess it would
>>>> be disallowed by process to try to update the existing registration to
>>>> also point at this document.)
>>>>
>>>> Section 10
>>>>
>>>> We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>>>
>>>> Section 10.1
>>>>
>>>>    When sending the authorization request object through "request"
>>>>    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>>>>    using JWE [RFC7516] with then considered appropriate algorithm.
>>>>
>>>> Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
>>>> similarly, in Section 4 we reiterate "signed then encrypted".  Why is
>> it
>>>> okay to talk about just "signed or encrypted" here?
>>>>
>>>> Section 10.2
>>>>
>>>>    (b)  Verifying that the symmetric key for the JWE encryption is the
>>>>         correct one if the JWE is using symmetric encryption.
>>>>
>>>> Similarly to the previous point, you also need to check the signature,
>>>> which will always be there.
>>>>
>>>>    (d)  Authorization Server is providing an endpoint that provides a
>>>>         Request Object URI in exchange for a Request Object.  In this
>>>>
>>>> I don't think this is a complete sentence (and it's definitely not a
>>>> parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
>>>> summary of this method would be "Delegating the authorization check to
>> a
>>>> separate "Request Object to Request Object URI" endpoint on the
>>>> Authorization Server".  (The writing in the rest of this paragraph
>> could
>>>> also use an editing pass.)
>>>>
>>>>    (e)  A third party, such as a Trust Framework Provider, provides an
>>>>         endpoint that provides a Request Object URI in exchange for a
>>>>         Request Object.  The same requirements as (b) above apply.  In
>>>>         addition, the Authorization Server MUST know out-of-band that
>>>>         the Client utilizes the Trust Framework Operator.
>>>>
>>>> The Authorization Server also has to trust the third-party provider to
>>>> actually do its job and not misbehave, right?
>>>>
>>>> Section 10.3
>>>>
>>>> I'm not entirely sure what "[t]he endpoints ithat come into question in
>>>> this specification" is supposed to mean -- is it just "the OAuth 2.0
>>>> endpoints presently defined in Standards-Track RFCs"?
>>>>
>>>>    In [RFC6749], while Redirection URI is included, others are not
>>>>    included in the Authorization Request.  As the result, the same
>>>>    applies to Authorization Request Object.
>>>>
>>>> nit: included in what?
>>>>
>>>> Section 10.4
>>>>
>>>> It's probably also worth citing the generic URI security considerations
>>>> from RFC 3986, here.
>>>>
>>>> Section 10.4.1
>>>>
>>>>    "request_uri", and (d) do not perform recursive GET on the
>>>>    "request_uri".
>>>>
>>>> nit: remove the "do" in order to make the construction parallel.
>>>>
>>>> Section 12.1
>>>>
>>>>    It is often hard for the user to find out if the personal data asked
>>>>    for is strictly necessary.  A Trust Framework Provider can help the
>>>>    user by examining the Client request and comparing to the proposed
>>>>    processing by the Client and certifying the request.  After the
>>>>    certification, the Client, when making an Authorization Request, can
>>>>    submit Authorization Request to the Trust Framework Provider to
>>>>    obtain the Request Object URI.
>>>>
>>>> side note: In my head the act of certification was the act of making
>> the
>>>> translation to a Request Object URI, so I'm kind of curious where my
>>>> vision differs from reality.
>>>>
>>>> The third paragraph seems to mostly just be describing the procedure of
>>>> how this flow works, which would not necessarily be specific to the
>>>> privacy considerations section.
>>>>
>>>> Section 12.2.2
>>>>
>>>>    Even if the protected resource does not include a personally
>>>>    identifiable information, it is sometimes possible to identify the
>>>>    user through the Request Object URI if persistent per-user Request
>>>>    Object URI is used.  A third party may observe it through browser
>>>>
>>>> nit: need an article for "persistent per-user Request Object URI" (or
>>>> make it plural, as "URIs are used").
>>>>
>>>>    Therefore, per-user Request Object URI should be avoided.
>>>>
>>>> nit: I think this is better as "static per-user Requeste Object URIs"


From nobody Fri Jan 31 06:31: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 625B6120104; Fri, 31 Jan 2020 06:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 YU1OgGawmbEX; Fri, 31 Jan 2020 06:31:06 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06hn0209.outbound.protection.outlook.com [104.47.54.209]) (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 CFB8512007C; Fri, 31 Jan 2020 06:31:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l42hS/quv3GYuAtgEsU8L1yyDFIB+0ynYNMInwO9BZoS8OhOUCaGQ6lqpW+peHP6gNuX/0weQGE8HSNU7LH/JTN9FsnZUiKtTsF7q1CF04Zqu11+FxltlXu9kBRkW4ZoGNCFUuSZziMsWkW7bG1t80b5fcwblz6pd9QMy+Aii/moSG3vI5S0IHxl3AGJ+wp+yF6eK0rH+/suS3Jjz5SsmkwVHPQo00OtDA9T+FdmSTq096VGpJ1dKjIX5D6LNPmxBzUAq7+Chqplsu41exndQpLtv6jTyF3iec7v4ZymnqLt2iBHDHdscKI8QxpPmokXpXpUq4aFQOmBj4zoRyNawQ==
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=d6CvkrwJQzp0C/x7ZK5DQIa3iRZcFDo/n3VOeCOfT7w=; b=TdEDiP6AUDSeAtXJJux3lSy7AUeaQcvRwGBEgJ/gKc9XJUC2jbcEmLalgvUCIYT1c9pePUWcnrO/h1ZWV0kX9ywm0/98Mj93zq3RP3m09usK7kxHIHgPea4ut7w+t6SmbBpeGtMs3R//GxxA1QCYeZ1RqkClGxrUt6fZfWtpSSyD8yiFedfTww6zfNZ2VIu6b0MvCIbUdE7gKqDim4lrTm7FzjdowpshalyEmHD89fiN653Ms06hQhdCD/UWZVLddzrQiSWiWlzocpAEcN86+8tBsWuujWDe2nhRn2NxMc2OAIr9qTp0UNTJhfCoWH/dZgclCjW3vMDpksmoJJWwTw==
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=d6CvkrwJQzp0C/x7ZK5DQIa3iRZcFDo/n3VOeCOfT7w=; b=aePDZT4m2Q6f+g5vuX9/rMWKd4tPnvzdi3IknK/rO2VS/DvrOhwEMWvHLLK9ixIDUCrqLCAzNfuUpBWEF+uOnEBdR5e6jlxBfYQZqUnnpDJ59imHkChSZSlpDYgLGjkw5OfD8Ke/01UhGRxBE0DRoUNwlh5nQuG8CO6Ajn4JNN4=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) by CH2PR00MB0795.namprd00.prod.outlook.com (10.186.139.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2731.0; Fri, 31 Jan 2020 14:30:54 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::1963:3ecd:52ea:4c5d]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::1963:3ecd:52ea:4c5d%6]) with mapi id 15.20.2731.000; Fri, 31 Jan 2020 14:30:54 +0000
From: Mike Jones 
To: John Bradley , Nat Sakimura , Benjamin Kaduk 
CC: oauth , "oauth-chairs@ietf.org" , The IESG , "draft-ietf-oauth-jwsreq@ietf.org" 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Thread-Index: AQHVMROxsVto7/ZDoUm6lxkAeRl7u6du60EAgJSn6QCAAdGhgIAAvX+AgAABVDA=
Date: Fri, 31 Jan 2020 14:30:54 +0000
Message-ID: 
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com>  <20200129232014.GN48797@kduck.mit.edu>  <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
In-Reply-To: <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6b705dff-0494-400f-932a-0000cd7113aa; 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-01-31T14:29:47Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [83.219.75.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: dabe22bd-2c2e-46ae-7894-08d7a65a2dff
x-ms-traffictypediagnostic: CH2PR00MB0795:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:SPM; SFS:(10001)(10019020)(4636009)(366004)(199004)(189003)(66446008)(64756008)(66556008)(66476007)(55016002)(52536014)(71200400001)(30864003)(4326008)(33656002)(8676002)(9686003)(81166006)(81156014)(10290500003)(86362001)(498600001)(2906002)(53546011)(8936002)(6506007)(7696005)(966005)(66946007)(76116006)(5660300002)(8990500004)(26005)(66574012)(110136005)(54906003)(186003)(61000200002); DIR:OUT; SFP:1501; SCL:5; SRVR:CH2PR00MB0795; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?B?NVd0NmZIRFZwYXRBenBmVHR2OWh3QmtJdUs0OXJncUhVQzluRDZjdldqcEVH?= =?utf-8?B?MVRVcmtoMGlzNVEvVWcrc1lDcVdrNmliZDdBVTJ5K0dlUUpwb0dFVEhvMEE4?= =?utf-8?B?RXg5NEt2cDZWVjZpeXhNQzA5RUx2bUpWRncvcTltbGExR0Qrbis2a1N0ZXBJ?= =?utf-8?B?YzU3TUZSa1RUaUVIRGxxS1FNRkE2Z0hlWmdWQTc0QytPcGJSMnZKKy9BNUNm?= =?utf-8?B?Rk9Ka0lHRFBMcG9NRmo5NXNIUHdMdVErbnd4cXVXNkxQRk5GM0RZYnJiaWw0?= =?utf-8?B?ME5wSEh1NzNXTDhPV3BEYUp2QlZnbG9mV254eW5Nb0JMajRhK0lPQm1RMkNC?= =?utf-8?B?ZVRSeXJ6cmU3RTZab1g1Z1hoeGxldURrK1hBb2d3eHJwZXFqZ0txaEdHM093?= =?utf-8?B?TTVKaE1yWk1DUG9LMC9INm5vbVlNRm13dWpxSXZPVXdEZEg5R01nZi9SbUd6?= =?utf-8?B?dlc5ZG51RHNxK1ZlVmQ3ODdVTkNFbmREamtzVFdtcWx6Z21XRkhmWXRYekFw?= =?utf-8?B?NGdRaUxSK01UMmwxODE2VjAvN1hyckwwcGVDb0lWeW1jZkRPM0E2WWkzS3BJ?= =?utf-8?B?c1RZUmJIbHlIYkI1UHZ0QUlIRzd3YndLZktvV2Q5M1l2SHpnOC91TlpGb3FM?= =?utf-8?B?Tyt0clhvTDRlaVNBQkN5eUkxMXNKRlpibURRSmcvT0RLU0YzVW15R3E4aWtY?= =?utf-8?B?NVZSMGJ0clpmN0d4ZjhWQjE3SDAxS0JVWVU5UjdENzE2QWpiUzJ5VHMrTFIw?= =?utf-8?B?UHJ1ZXNhTkhrNVh5eTIrY01rZ2s0Z1RNWDY1M1pVQng0Z2lCTm5LMnU0RXJu?= =?utf-8?B?b1orTWtuc0pxMm8rbVI4ZFAzMjJ4Zy9lUDZxbGp1aElnNkdpVXZ1TFo5KzNI?= =?utf-8?B?T0lIcW5EdkdxSGs5SjRVd0xEd3B2eXlKOWdhaVBadyt6cW42UjBGMkJUR0p2?= =?utf-8?B?MnhUVXBiUEtVNVZYcTZWNEE4UlJjZmkxa3NmWWpJMTZiak52cW40b0N4OXNa?= =?utf-8?B?VWkvSmNqSnpSVlJGaHFqS25OV2h3SHdobW9MdW1EVHlqVnNNOFFxRDBYZ3JF?= =?utf-8?B?Zm8wUUlxa2ZuaHA3ZmNmaEN6YUtqdE5DYUVQSWxZOC9WajYyb1NDYnp6TUNy?= =?utf-8?B?ZFdTVGZCVmdBTFNNZnVpS01oS2RxTmI4ZHZyNVMrRW1LTjNZNjFkWU5YTFNp?= =?utf-8?B?WkRXbVhVM3FKRVpQdUljaWdnRFdEQlNXUUJTRi9YdDluQXRUN2pHMTExV1Vj?= =?utf-8?B?dzNIUm5XT1R3Z2JWK0llSUFIamttZ1BkS0pHL0tXeEVZZDdaUT09?=
x-ms-exchange-antispam-messagedata: bIrssrrXn7LgJRu7njGv2f11VFhii/zUbrr1DIUqjgYawGYhQe5It9hKmuIEWmh/aFHN2lBh7LQTNiZntguPIFnHjjJgcIgp/8gSRMbOovJrEysmKV3F+MgB92pXdeAYuGcLwf/GJnpoDOqqoSIVlw==
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-Network-Message-Id: dabe22bd-2c2e-46ae-7894-08d7a65a2dff
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 14:30:54.3496 (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: 96NdQ49S4LAOkFSjAApOBApss5I7MdVQIJPffZIQXC2iPd8ubbyuBwNhsWPXGwI1/Hb+CSTMEZc6NpcUHMFzGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0795
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Jan 2020 14:31:09 -0000

SSBhbHNvIGFncmVlIHRoYXQgd2UgbXVzdCBhbGxvdyBjbGllbnRfaWQgdG8gYmUgZXhwcmVzc2Vk
IG91dHNpZGUgb2YgdGhlIHNpZ25lZCByZXF1ZXN0LCBhcyBkZXNjcmliZWQgYnkgTmF0Lg0KDQoJ
CQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGggPG9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IEZy
aWRheSwgSmFudWFyeSAzMSwgMjAyMCA2OjI1IEFNDQpUbzogTmF0IFNha2ltdXJhIDxzYWtpbXVy
YUBnbWFpbC5jb20+OyBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCkNjOiBvYXV0aCA8
b2F1dGhAaWV0Zi5vcmc+OyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGll
dGYub3JnPjsgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXFAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRF
Uk5BTF0gUmU6IFtPQVVUSC1XR10gQmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWll
dGYtb2F1dGgtandzcmVxLTE5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQo+RnJvbSB0
aGUgZGlzY3Vzc2lvbnMgSSBoYXZlIGhhZCwgSSBhZ3JlZSB3aXRoIE5hdCdzIGFzc21lbnQuDQoN
CkpvaG4gQi4NCg0KT24gMS8zMS8yMDIwIDEyOjA2IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6DQo+
IEhpDQo+DQo+IFJlOiBKV1QNCj4gSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiBhbmQgd2UgY2Fu
IHB1dCBzb21lIGV4cGxhbmF0b3J5IG5vdGVzLiANCj4gSGF2aW5nIHNhaWQgdGhhdCwgSkFSIGlz
IHN0aWxsIGEgdmFsaWQgSldULCBJIHRoaW5rIDotKQ0KPg0KPiBSZTogY2xpZW50X2lkDQo+IFdl
IGFjdHVhbGx5IGRpc2N1c3NlZCBjbGllbnRfaWQgaXNzdWVzIHdpdGggT3BlbklEIENvbm5lY3Qg
V0cgQ2FsbCANCj4geWVzdGVyZGF5IGFzIHdlbGwuDQo+IEkgaGVhciBhIHByZXR0eSBzdHJvbmcg
dm9pY2UgZnJvbSB0aGUgZGV2ZWxvcGVyIGNvbW11bml0eSB0aGF0IHRoZXkgDQo+IHdhbnQgY2xp
ZW50X2lkIGFzIGEgcXVlcnkgcGFyYW1ldGVyIGFuZCBpdCBzaG91bGQgbm90IHBvc2UgYSBzZWN1
cml0eSANCj4gaXNzdWUgYXMgbG9uZyBhcyBpdCBpcyByZXF1aXJlZCB0byBtYXRjaCB3aGF0IGlz
IGluIHRoZSBKV1QuIEluIGZhY3QsIA0KPiB0aGF0IHdhcyB0aGUgcG9zaXRpb24gdGFrZW4gaW4g
dGhlIFdHIGxhc3QgY2FsbC4gU28sIGluIGVmZmVjdCwgV0cgaXMgDQo+IGFjdHVhbGx5IHB1c2hp
bmcgYmFjayB0aGUgY2hhbmdlIElFU0cgd2FudGVkLg0KPg0KPiBBcyBJIHVuZGVyc3RhbmQgaXQs
IHRoZXJlIGFyZSB0d28gcG9pbnRzIHRvIGJlIG1hZGU6DQo+ICgxKSBJZiBjbGllbnRfaWQgaXMg
bm90IGluIHRoZSBxdWVyeSBwYXJhbWV0ZXIsIHRoZW4gaXQgTVVTVCBiZSBpbiB0aGUgDQo+IEpX
VCBoZWFkZXIgT1IgTVVTVCBiZSBzdXBwbGllZCBhcyBhIHF1ZXJ5IHBhcmFtZXRlciBpbiBzb21l
IGVuY3J5cHRlZCANCj4gSkFSIGNhc2UNCj4gKDIpIFRvIGNoZWNrIGlmIHJlcXVzdF91cmkgaXMg
YSByZWdpc3RlcmVkIGFuZCB2YWxpZCBVUkksIG5vdCBoYXZpbmcgDQo+IGNsaWVudF9pZCBpbiB0
aGUgcXVlcnkgcGFyYW1ldGVyIHdpbGwgaGF2ZSBwZXJmb3JtYW5jZSBpbXBhY3RzIGluIGEgDQo+
IGxhcmdlIEFTLg0KPg0KPiBUaGUgZW5jcnlwdGlvbiBjYXNlICgxKSBjYW4gYmUgc29sdmVkIGJ5
IGFkZGluZyBjbGllbnRfaWQgaW4gdGhlIEpXVCANCj4gSGVhZGVyIGJ1dCBpdCB3aWxsIG5vdCBz
b2x2ZSAoMikuDQo+IFNvLCBJTUhPLCBwdXR0aW5nIGNsaWVudF9pZCBiYWNrIHRvIHRoZSBxdWVy
eSBwYXJhbWV0ZXIgKGFuZCBNVVNUIA0KPiBtYXRjaCB0aGUgdmFsdWUgaW4gSldUKSBpcyBhIHdh
eSB0byBnby4NCj4gU2luY2UgdGhhdCB3YXMgdGhlIHBvc2l0aW9uIGJ5IHRoZSBXRyBhdCB0aGUg
V0cgTGFzdCBDYWxsLCBJIGRvIG5vdCANCj4gZmVlbCB0aGF0IGl0IG5lZWRzIHRvIGJlIGJyb3Vn
aHQgYmFjayB0byB0aGUgV0cgbGFzdCBjYWxsLCBidXQgdGhhdCBpcyANCj4geW91ciBjYWxsLg0K
Pg0KPiBCZXN0LA0KPg0KPiBOYXQgU2FraW11cmENCj4NCj4gT24gVGh1LCBKYW4gMzAsIDIwMjAg
YXQgODoyMCBBTSBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4gd3JvdGU6DQo+DQo+PiBI
aSBOYXQsDQo+Pg0KPj4gTm93IGl0IGlzIG15IHR1cm4gdG8gYXBvbG9naXplIGZvciB0YWtpbmcg
YSBsb25nIHRpbWUuDQo+Pg0KPj4gSSB0aGluayBJIHNlZSB0aGUgZ2VuZXJhbCBkaXJlY3Rpb24g
dGhlc2UgY2hhbmdlcyBhcmUgZ29pbmcgaW4sIGFuZCANCj4+IGl0J3MgYSByZWFzb25hYmxlIGFw
cHJvYWNoIHRvIHRoZSB1bmZvcnR1bmF0ZSBzaXR1YXRpb24gd2UgZmluZCANCj4+IG91cnNlbHZl
cyBpbiB3aXRoIHJlc3BlY3QgdG8gSldUIGNsYWltcyB2cy4gT0F1dGggcGFyYW1ldGVycy4gIElu
IA0KPj4gZWZmZWN0LCB3aGF0IHdlJ3JlIGRvaW5nIGlzIG1ha2luZyBhICJwcm9maWxlIiAoZm9y
IGxhY2sgb2YgYSBiZXR0ZXIgDQo+PiB0ZXJtKSBvZiBKV1QsIHRoYXQgbGV2ZXJhZ2VzIHRoZSBt
ZWNoYW5pc21zIGFuZCBhbGdvcml0aG1zIG9mIEpXVCBidXQgDQo+PiB1c2VzIGEgZGlmZmVyZW50
IHJlZ2lzdHJ5IGZvciBpbnRlcnByZXRpbmcgdGhlIGNsYWltcyBpbiB0aGUgdG9rZW4gDQo+PiAo
dGhhdCBpcywgT0F1dGggUGFyYW1ldGVycyB2cy4gSldUIENsYWltcykuICBXZSBjYW4gdGVsbCB0
aGF0IHRoaXMgDQo+PiAicHJvZmlsZSIgb2YgSldUIGlzIGJlaW5nIHVzZWQgYmVjYXVzZSBvZiB0
aGUgY29udGV4dCBpbiB3aGljaCB0aGUgSldUIGlzIHRyYW5zZmVycmVkL3JlY2VpdmVkOiBpZiBp
dCdzIHRoZSAicmVxdWVzdCINCj4+IHBhcmFtZXRlciwgdGhhdCdzIHBhcnQgb2YgdGhlIGRlZmlu
aXRpb24gb2YgdGhlIE9BdXRoIFBhcmFtZXRlciwgYW5kIA0KPj4gaWYgaXQncyB0aGUgcmVzdWx0
IG9mIGRlcmVmZXJlbmNpbmcgYSAicmVxdWVzdF91cmkiLCB0aGUgDQo+PiBhcHBsaWNhdGlvbi9v
YXV0aC5hdXRoei5yZXErand0IG1lZGlhLXR5cGUgY2xlYXJseSBpbmRpY2F0ZXMgaG93IHRoZSAN
Cj4+IGNvbnRlbnRzIHNob3VsZCBiZSBpbnRlcnByZXRlZC4NCj4+DQo+PiBIb3dldmVyLCB0aGUg
Y2hhbmdlcyBpbiB0aGUgLTIwIGRvIG5vdCBnaXZlIHRoZSByZWFkZXIgbXVjaCBvZiBhbnkgDQo+
PiBoaW50IGFzIHRvIHRoaXMgYmVpbmcgd2hhdCdzIGV4cGVjdGVkIHRvIGhhcHBlbiwgYW5kIHRo
YXQgc3RvY2sgUkZDIA0KPj4gNzUxOSBKV1QgaXMNCj4+ICpub3QqIHdoYXQncyBpbiB1c2UuICBT
byBJJ2QgcmVxdWVzdCB0aGF0IHdlIHRha2UgYSBjbG9zZSBsb29rIGF0IGhvdyANCj4+IHRoZSBk
b2N1bWVudCB1c2VzICJKV1QiIHZzLiAiSldUIGVuY29kaW5nIiAoZXRjLik7IGFkZCBhbiBleHBs
aWNpdCANCj4+IHN0YXRlbWVudCB0aGF0IHdoaWxlIHRoZSBKV1QgZW5jb2RpbmcgaXMgaW4gdXNl
LCB0aGUgY29udGVudHMgYXJlIHRvIA0KPj4gYmUgaW50ZXJwcmV0ZWQgYnkgaW50ZXJwcmV0aW5n
IHRoZSBKV1QgY2xhaW1zIGFzIE9BdXRoIFBhcmFtZXRlcnMgDQo+PiAoYW5kIG5vdCBhcyBwZXIg
dGhlIElBTkEgcmVnaXN0cnkgb2YgSldUIGNsYWltcyk7IGFuZCBhZGQgc29tZSANCj4+IGRpc2N1
c3Npb24gKHNpbWlsYXIgdG8gdGhlIGFib3ZlKSBhYm91dCBob3cgdGhlIGFwcGxpY2F0aW9uIGNv
bnRleHQgDQo+PiBtYWtlcyBpdCB1bmFtYmlndW91cyB3aGV0aGVyIHRoZSBKV1QtZW5jb2RlZCBj
bGFpbXMgYXJlIHN0YW5kYXJkIEpXVCANCj4+IGNsYWltcyBvciBPQXV0aCBQYXJtYXRlcnMgYXMg
cGVyIHRoaXMgZG9jdW1lbnQuDQo+Pg0KPj4gV2l0aCByZXNwZWN0IHRvIG15IHNlY29uZCAoImRp
c2N1c3MgZGlzY3VzcyIpIHBvaW50LCBOYXQgYW5kIEkgZGlkIA0KPj4gaGF2ZSBhIGRpc2N1c3Np
b24gaW4tcGVyc29uIGFuZCBJIGFjY2VwdCB0aGF0IHRoZXJlIG1heSBiZSBzb21lIA0KPj4gc2Nl
bmFyaW9zIGluIHdoaWNoIHNraXBwaW5nIHRoZSBhdXRob3JpemF0aW9uIGRpYWxvZ3VlIGlzIA0K
Pj4gYXBwcm9wcmlhdGUsIHNvIHRoZSBleGFtcGxlIGNhbiByZW1haW4uDQo+Pg0KPj4NCj4+IE1v
dmluZyBvbiBmcm9tIG15IERpc2N1c3MgcG9zaXRpb24sIEkgZG8gZ2V0IHRoZSBzZW5zZSBmcm9t
IHRoZSANCj4+IG9uZ29pbmcgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB0aGF0IHRoZXJlJ3Mgbm90
IGNsZWFyIGFncmVlbWVudCBhYm91dCANCj4+IHRoZSBjdXJyZW50IGZvcm11bGF0aW9uIHRoYXQg
cmVxdWlyZXMgYWxsIHBhcmFtZXRlcnMgKGJ1dCAicmVxdWVzdCIgDQo+PiBhbmQgInJlcXVlc3Rf
dXJpIikgdG8gYmUgaW4gdGhlIEpBUiwgZXNwZWNpYWxseSB3aXRoIHJlc3BlY3QgdG8gDQo+PiAi
Y2xpZW50X2lkIiB0aGF0IG1pZ2h0IGJlIG5lZWRlZCB0byB1bnBhY2sgdGhlIEpBUiBpbiBzb21l
IGNhc2VzISAgU28gDQo+PiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGUgV0cgd2FudHMgdG8gYnJp
bmcgdGhlIGRvY3VtZW50IGJhY2sgdG8gdGhlIA0KPj4gV0cgdG8gaXJvbiBvdXQgdGhvc2UgaXNz
dWVzIGJlZm9yZSBpdCByZXR1cm5zIHRvIHRoZSBJRVNHLiAgSSdtIGEgDQo+PiBsaXR0bGUgcmVs
dWN0YW50IHRvIHN3aXRjaCBteSBwb3NpdGlvbiB0byAiTm8gT2JqZWN0aW9uIiB1bnRpbCB3ZSAN
Cj4+IGhhdmUgYSBjbGVhcmVyIHBpY3R1cmUgb2Ygd2hhdCB0aGUgV0cgd2FudHMgdG8gZG8gb24g
dGhpcyBmcm9udCAtLSBpbiANCj4+IG15IHVuZGVyc3RhbmRpbmcsIHdlIGNhbid0IHJlYWxseSBw
dWJsaXNoIHRoZSBkb2N1bWVudCB3aXRob3V0IGF0IA0KPj4gbGVhc3Qgc29tZSBzb2x1dGlvbiAo
ImNsaWVudF9pZCIpIGZvciB0aGUgZW5jcnlwdGVkLXJlcXVlc3Qga2V5LWxvb2t1cCBjYXNlLg0K
Pj4NCj4+IFRoYW5rcywNCj4+DQo+PiBCZW4NCj4+DQo+Pg0KPj4gT24gU3VuLCBPY3QgMjcsIDIw
MTkgYXQgMTA6MTI6NTBBTSArMDEwMCwgTmF0IFNha2ltdXJhIHdyb3RlOg0KPj4+IEhpDQo+Pj4N
Cj4+PiBUb29rIGEgbG9uZyB0aW1lIGJ1dCBmaW5hbGx5IGFsbCB0aGUgY2hhbmdlcyBuZWVkZWQg
dG8gcmVzb2x2ZSB0aGUNCj4+IERJU0NVU1MNCj4+PiBjb21tZW50cyBhcmUgKGhvcGVmdWxseSkg
YXBwbGllZCBhcyAtMjAuDQo+Pj4NCj4+PiBUaGVyZSBpcyBvbmUgY2hhbmdlIHRoYXQgaW1wYWN0
cyB0aGUgcHJvY2VzczogdGhlIGRyYWZ0IG5vdyBoYXMgSUFOQSANCj4+PiByZXF1ZXN0IHNvIGl0
IG5lZWRzIHRvIGJlIHJlZmVycmVkIGJhY2sgdG8gSUFOQS4NCj4+Pg0KPj4+IFRoZSBJRVRGIGRh
dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IGRhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS8NCj4+Pg0KPj4+IEJlc3QsDQo+
Pj4NCj4+PiBOYXQgU2FraW11cmENCj4+Pg0KPj4+IDIwMTnlubQ35pyIM+aXpSjmsLQpIDQ6MjEg
QmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPjoNCj4+Pg0K
Pj4+PiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np
dGlvbiBmb3INCj4+Pj4gZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMTk6IERpc2N1c3MNCj4+Pj4N
Cj4+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj
dCBhbmQgcmVwbHkgdG8gDQo+Pj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl
IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byANCj4+Pj4gY3V0IHRoaXMgaW50cm9kdWN0
b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4+DQo+Pj4+DQo+Pj4+IFBsZWFzZSByZWZlciB0
bw0KPj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHBzJTNBJTJGJTJGd3d3DQo+PiAuaWV0Zi5vcmclMkZpZXNnJTJGc3RhdGVtZW50JTJGZGlz
Y3Vzcy1jcml0ZXJpYS5odG1sJmFtcDtkYXRhPTAyJTdDMDENCj4+ICU3Q01pY2hhZWwuSm9uZXMl
NDBtaWNyb3NvZnQuY29tJTdDNjU5MTI3Y2VkZDVhNDJlY2JmZWQwOGQ3YTY1OTY2MTIlNw0KPj4g
QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjA3NzUyMTg2
NzY3NDAmYW1wO3NkDQo+PiBhdGE9NlpTV2NrVTl3OFMxb0RFVXolMkJnS1BndVYyVUZqeWZ6S3JP
SXQ5VjRxWFJRJTNEJmFtcDtyZXNlcnZlZD0wDQo+Pj4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi
b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+DQo+Pj4+DQo+Pj4+
IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg
Zm91bmQgaGVyZToNCj4+Pj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZA0KPj4+PiBhdGF0cmFja2VyLmlldGYub3JnJTJG
ZG9jJTJGZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXElMkYmYW1wO2RhdGE9MDIlDQo+Pj4+IDdDMDEl
N0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzY1OTEyN2NlZGQ1YTQyZWNiZmVkMDhk
N2E2NTkNCj4+Pj4gNjYxMiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3
QzAlN0M2MzcxNjA3NzUyMTg2NzY3NA0KPj4+PiAwJmFtcDtzZGF0YT1lYWVTTiUyQmdLVENEaXk1
MDJHUE5tNDU5SmpZdU9qNW83N1RwJTJCNlFBdzNIWSUzRCZhbXA7DQo+Pj4+IHJlc2VydmVkPTAN
Cj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAtLS0NCj4+Pj4gRElTQ1VT
UzoNCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAtLS0NCj4+Pj4NCj4+Pj4gVGhpcyBpcyBhICJkaXNj
dXNzIGRpc2N1c3MiIC0tIGl0J3MgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIGFuZCBJJ2QgDQo+Pj4+
IGxpa2UgdG8gdGFsayBhYm91dCBpdCwgYnV0IGl0J3Mgbm90IGNsZWFyIHRoYXQgYW55IGNoYW5n
ZSB0byB0aGUgDQo+Pj4+IGRvY3VtZW50IHdpbGwgYmUgbmVlZGVkLg0KPj4+Pg0KPj4+PiBPbmNl
IHRoaXMgKGFuZCBzb21lIG9mIHRoZSBtb3JlIHN1YnN0YW50aXZlIGl0ZW1zIGluIHRoZSBDb21t
ZW50DQo+Pj4+IHNlY3Rpb24pIGlzIHJlc29sdmVkLCBJJ2QgYmUgaGFwcHkgdG8gYmFsbG90IFll
cy4NCj4+Pj4NCj4+Pj4gVGhlIGludHJvZHVjdGlvbiBub3RlcyBhcyBhbiBhZHZhbnRhZ2Ugb2Yg
SldUIHRoYXQ6DQo+Pj4+DQo+Pj4+ICAgIChkKSAgKGNvbGxlY3Rpb24gbWluaW1pemF0aW9uKSBU
aGUgcmVxdWVzdCBjYW4gYmUgc2lnbmVkIGJ5IGEgdGhpcmQNCj4+Pj4gICAgICAgICBwYXJ0eSBh
dHRlc3RpbmcgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIGNvbXBsaWFudA0KPj4g
d2l0aA0KPj4+PiAgICAgICAgIGEgY2VydGFpbiBwb2xpY3kuICBGb3IgZXhhbXBsZSwgYSByZXF1
ZXN0IGNhbiBiZSANCj4+Pj4gcHJlLWV4YW1pbmVkDQo+PiBieQ0KPj4+PiAgICAgICAgIGEgdGhp
cmQgcGFydHkgdGhhdCBhbGwgdGhlIHBlcnNvbmFsIGRhdGEgcmVxdWVzdGVkIGlzIHN0cmljdGx5
DQo+Pj4+ICAgICAgICAgbmVjZXNzYXJ5IHRvIHBlcmZvcm0gdGhlIHByb2Nlc3MgdGhhdCB0aGUg
ZW5kLXVzZXIgYXNrZWQgZm9yLA0KPj4+PiAgICAgICAgIGFuZCBzdGF0aWNhbGx5IHNpZ25lZCBi
eSB0aGF0IHRoaXJkIHBhcnR5LiAgVGhlIGF1dGhvcml6YXRpb24NCj4+Pj4gICAgICAgICBzZXJ2
ZXIgdGhlbiBleGFtaW5lcyB0aGUgc2lnbmF0dXJlIGFuZCBzaG93cyB0aGUgY29uZm9ybWFuY2UN
Cj4+Pj4gICAgICAgICBzdGF0dXMgdG8gdGhlIGVuZC11c2VyLCB3aG8gd291bGQgaGF2ZSBzb21l
IGFzc3VyYW5jZSBhcyB0byB0aGUNCj4+Pj4gICAgICAgICBsZWdpdGltYWN5IG9mIHRoZSByZXF1
ZXN0IHdoZW4gYXV0aG9yaXppbmcgaXQuICBJbiBzb21lIGNhc2VzLA0KPj4+PiAgICAgICAgIGl0
IG1heSBldmVuIGJlIGRlc2lyYWJsZSB0byBza2lwIHRoZSBhdXRob3JpemF0aW9uIGRpYWxvZ3Vl
DQo+Pj4+ICAgICAgICAgdW5kZXIgc3VjaCBjaXJjdW1zdGFuY2VzLg0KPj4+Pg0KPj4+PiBJJ20g
cHJldHR5IHVuY29tZm9ydGFibGUgYWJvdXQgc3VnZ2VzdGluZyB0aGF0IHRoZSBhdXRob3JpemF0
aW9uIA0KPj4+PiBkaWFsb2d1ZSBjYW4vc2hvdWxkIGJlIHNraXBwZWQ7IGRvIHdlIG5lZWQgdG8g
a2VlcCB0aGlzIGV4YW1wbGU/DQo+Pj4+IE1heWJlIGp1c3QgdGFsa2luZyBhYm91dCB3aGF0IGFu
IGV4cGVjdGVkIHVzZSBjYXNlIGNvdWxkIGJlIHdvdWxkIA0KPj4+PiBoZWxwIGFsbGV2aWF0ZSBt
eSB1bmVhc2UuDQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLS0tDQo+Pj4+IENP
TU1FTlQ6DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLS0tDQo+Pj4+DQo+Pj4+IFNlY3Rpb24gMQ0K
Pj4+Pg0KPj4+PiAgICBXaGlsZSBpdCBpcyBlYXN5IHRvIGltcGxlbWVudCwgdGhlIGVuY29kaW5n
IGluIHRoZSBVUkkgZG9lcyBub3QNCj4+IGFsbG93DQo+Pj4+ICAgIGFwcGxpY2F0aW9uIGxheWVy
IHNlY3VyaXR5IHdpdGggY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkNCj4+Pj4gICAgcHJv
dGVjdGlvbiB0byBiZSB1c2VkLiAgV2hpbGUgVExTIGlzIHVzZWQgdG8gb2ZmZXIgY29tbXVuaWNh
dGlvbg0KPj4+Pg0KPj4+PiBuaXQ6IHRoaXMgd29yZGluZyBpcyBhIGxpdHRsZSBoYXJkIHRvIHJl
YWQ7IGl0IG1pZ2h0IGJlIGVhc2llciB0byANCj4+Pj4gcmVvcmRlciB0byAiZG9lcyBub3QgYWxs
b3cgYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgdG8gYmUgdXNlZCB0byANCj4+Pj4gcHJvdmlk
ZSBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBwcm90ZWN0aW9uIi4NCj4+Pj4NCj4+Pj4g
ICAgVGhlIHVzZSBvZiBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBhbGxvd3MgcmVxdWVzdHMg
dG8gYmUgcHJlcGFyZWQNCj4+Pj4gICAgYnkgYSB0aGlyZCBwYXJ0eSBzbyB0aGF0IGEgY2xpZW50
IGFwcGxpY2F0aW9uIGNhbm5vdCByZXF1ZXN0IG1vcmUNCj4+Pj4gICAgcGVybWlzc2lvbnMgdGhh
biBwcmV2aW91c2x5IGFncmVlZC4gIFRoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwNCj4+IGRlZ3Jl
ZQ0KPj4+PiAgICBvZiBwcml2YWN5IHByb3RlY3Rpb24uDQo+Pj4+DQo+Pj4+IChzaWRlIG5vdGUp
IHdoYXQgd291bGQgYW4gZXhhbXBsZSBvZiBzdWNoIGEgdGhpcmQgcGFydHkgYmUuICAoV2UNCj4+
IGFscmVhZHkNCj4+Pj4gaGF2ZSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSBjbGllbnQsIGFuZCB0
aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgLi4uDQo+Pj4+IG1heWJlIGl0J3MgYSBmb3VydGggcGFy
dHk/KQ0KPj4+Pg0KPj4+PiAgICBGdXJ0aGVybW9yZSwgdGhlIHJlcXVlc3QgYnkgcmVmZXJlbmNl
IGFsbG93cyB0aGUgcmVkdWN0aW9uIG9mIG92ZXItDQo+Pj4+ICAgIHRoZS13aXJlIG92ZXJoZWFk
Lg0KPj4+Pg0KPj4+PiBXZSBvbmx5IGJhcmVseSBtZW50aW9uZWQgYnktcmVmZXJlbmNlIGF0IHRo
aXMgcG9pbnQgKG9uZSBsaW5lIGluIA0KPj4+PiB0aGUgQWJzdHJhY3QpLCBzbyBJJ2Qgc3VnZ2Vz
dCAicGFzc2luZyB0aGUgcmVxdWVzdCBieSByZWZlcmVuY2UiLg0KPj4+Pg0KPj4+PiAgICAoNCkg
IGl0cyBkZXZlbG9wbWVudCBzdGF0dXMgdGhhdCBpdCBpcyBhbiBSRkMgYW5kIHNvIGlzIGl0cw0K
Pj4+PiAgICAgICAgIGFzc29jaWF0ZWQgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiBtZXRob2RzIGFz
IFtSRkM3NTE1XSBhbmQNCj4+Pj4gICAgICAgICBbUkZDNzUxNl0NCj4+Pj4NCj4+Pj4gbml0OiBJ
J2Qgc3VnZ2VzdCAiaXRzIGRldmVsb3BtZW50IHN0YXR1cyBhcyBhIFByb3Bvc2VkIFN0YW5kYXJk
LCANCj4+Pj4gYWxvbmcgd2l0aCB0aGUgYXNzb2NpYXRlZCBzaWduaW5nIGFuZCBlbmNyeXB0aW9u
IG1ldGhvZHMgW1JGQzc1MTVdDQo+PiBbUkZDNzUxNl0uIg0KPj4+PiAgICAoYykgIChjb25maWRl
bnRpYWxpdHkgcHJvdGVjdGlvbikgVGhlIHJlcXVlc3QgY2FuIGJlIGVuY3J5cHRlZCBzbw0KPj4+
PiAgICAgICAgIHRoYXQgZW5kLXRvLWVuZCBjb25maWRlbnRpYWxpdHkgY2FuIGJlIHByb3ZpZGVk
IGV2ZW4gaWYgdGhlIFRMUw0KPj4+PiAgICAgICAgIGNvbm5lY3Rpb24gaXMgdGVybWluYXRlZCBh
dCBvbmUgcG9pbnQgb3IgYW5vdGhlci4NCj4+Pj4NCj4+Pj4gbml0OiBUTFMgaXMgYWx3YXlzIHRl
cm1pbmF0ZWQgYXQgb3IgYmVmb3JlIHRoZSB1c2VyLWFnZW50LCB0aG91Z2guICANCj4+Pj4gU28g
bWF5YmUgdGhlIHVzZXIgYWdlbnQgbmVlZHMgdG8gZ2V0IGNhbGxlZCBvdXQgaGVyZSBhcyB3ZWxs
ICh0aGVyZSANCj4+Pj4gY291bGQgb2YgY291cnNlIGJlIFRMUyB0ZXJtaW5hdGlvbiBlYXJsaWVy
IHRoYW4gdGhlIHVzZXItYWdlbnQgaW4gDQo+Pj4+IHNvbWUgY2FzZXMsIHRvbykuDQo+Pj4+DQo+
Pj4+ICAgIDIuICBXaGVuIHRoZSBjbGllbnQgZG9lcyBub3Qgd2FudCB0byBkbyB0aGUgY3J5cHRv
LiAgVGhlDQo+Pj4+ICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBtYXkgcHJvdmlkZSBhbiBl
bmRwb2ludCB0byBhY2NlcHQgdGhlDQo+Pj4+ICAgICAgICBBdXRob3JpemF0aW9uIFJlcXVlc3Qg
dGhyb3VnaCBkaXJlY3QgY29tbXVuaWNhdGlvbiB3aXRoIHRoZQ0KPj4+PiAgICAgICAgQ2xpZW50
IHNvIHRoYXQgdGhlIENsaWVudCBpcyBhdXRoZW50aWNhdGVkIGFuZCB0aGUgY2hhbm5lbCANCj4+
Pj4gaXMNCj4+IFRMUw0KPj4+PiAgICAgICAgcHJvdGVjdGVkLg0KPj4+Pg0KPj4+PiBIb3cgY2Fu
IHlvdSAibm90IHdhbnQgdG8gZG8gW3RoZV0gY3J5cHRvIiBidXQgc3RpbGwgYmUgZG9pbmcgVExT
IA0KPj4+PiAod2l0aCBjcnlwdG8pPyAgUGVyaGFwcyB3ZSdyZSBsb29raW5nIGZvciAibm90IHdh
bnQgdG8gcGF5IHRoZSANCj4+Pj4gYWRkaXRpb25hbCBvdmVyaGVhZCBvZiBKV1MvSldFIGNyeXB0
b2dyYXBoeSBvbiB0b3Agb2YgVExTIj8NCj4+Pj4NCj4+Pj4gU2VjdGlvbiAxLjENCj4+Pj4NCj4+
Pj4gUkZDIDgxNzQgaGFzIHVwZGF0ZWQgQkNQIDE0IGJvaWxlcnBsYXRlIHRleHQgdG8gdXNlLg0K
Pj4+Pg0KPj4+PiBTZWN0aW9uIDMNCj4+Pj4NCj4+Pj4gbml0OiBzaG91bGQgdGhpcyBzZWN0aW9u
IGJlIDIuMyB0byBnZXQgd3JhcHBlZCBpbnRvICJ0ZXJtaW5vbG9neSI/DQo+Pj4+DQo+Pj4+IEl0
IG1pZ2h0IGFsc28gYmUgd29ydGggcHV0dGluZyByZWZlcmVuY2VzIGluIGZvciB0aGUgdGVybXMs
IHRob3VnaCANCj4+Pj4gdGhleSBhcmUgbGFyZ2VseSBjb21tb24ga25vd2xlZGdlIGF0IHRoaXMg
cG9pbnQuDQo+Pj4+DQo+Pj4+IFNlY3Rpb24gNA0KPj4+Pg0KPj4+PiAgICBBIFJlcXVlc3QgT2Jq
ZWN0IChTZWN0aW9uIDIuMSkgaXMgdXNlZCB0byBwcm92aWRlIGF1dGhvcml6YXRpb24NCj4+Pj4g
ICAgcmVxdWVzdCBwYXJhbWV0ZXJzIGZvciBhbiBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiByZXF1
ZXN0LiAgSXQgTVVTVA0KPj4+PiAgICBjb250YWlucyBhbGwgdGhlIE9BdXRoIDIuMCBbUkZDNjc0
OV0gYXV0aG9yaXphdGlvbiByZXF1ZXN0DQo+PiBwYXJhbWV0ZXJzDQo+Pj4+ICAgIGluY2x1ZGlu
ZyBleHRlbnNpb24gcGFyYW1ldGVycy4gIFRoZSBwYXJhbWV0ZXJzIGFyZSByZXByZXNlbnRlZCAN
Cj4+Pj4gYXMNCj4+Pj4NCj4+Pj4gbml0OiAiYWxsIHRoZSBwYXJhbWV0ZXJzIiBraW5kIG9mIHNv
dW5kcyBsaWtlICJhbGwgdGhhdCBhcmUgZGVmaW5lZCIuDQo+Pj4+IEJ1dCBJIHRoaW5rIHRoZSBp
bnRlbnQgaGVyZSBpcyAiYW55IHBhcmFtZXRlciB1c2VkIHRvIHByb2Nlc3MgdGhlIA0KPj4+PiBy
ZXF1ZXN0IG11c3QgY29tZSBmcm9tIHRoZSByZXF1ZXN0IG9iamVjdCBhbmQgVVJMIHF1ZXJ5IHBh
cmFtZXRlcnMgDQo+Pj4+IGFyZSBpZ25vcmVkIiwgc28gbWF5YmUgIk1VU1QgY29udGFpbiBhbGwg
dGhlIHBhcmFtZXRlcnMgKGluY2x1ZGluZw0KPj4gZXh0ZW5zaW9uDQo+Pj4+IHBhcmFtZXRlcnMp
IHVzZWQgdG8gcHJvY2VzcyB0aGUgT0F1dGggMi4wIFtSRkM2NzQ5XSBhdXRob3JpemF0aW9uIA0K
Pj4+PiByZXF1ZXN0OyBwYXJhbWV0ZXJzIGZyb20gb3RoZXIgc291cmNlcyBNVVNUIE5PVCBiZSB1
c2VkIiwgYWtpbiB0byANCj4+Pj4gd2hhdCB3ZSBzYXkgZG93biBpbiBTZWN0aW9ucyA1IGFuZCA2
LjMuDQo+Pj4+IEJ1dCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYWJvdXQgdGhlIHdvcmRpbmcgdG8g
bm90IGV4Y2x1ZGUgdGhlIA0KPj4+PiB1c2FnZSBvZiB0aGUgInJlcXVlc3QiIGFuZCAicmVxdWVz
dF91cmkiIHF1ZXJ5IHBhcmFtZXRlcnMgdG8gIGZpbmQgDQo+Pj4+IHRoZSBSZXF1ZXN0IE9iamVj
dCENCj4+Pj4NCj4+Pj4gICAgdGhlIEpXVCBjbGFpbXMuICBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0
cmluZyB2YWx1ZXMgTVVTVCBiZSANCj4+Pj4gaW5jbHVkZWQNCj4+Pj4NCj4+Pj4gbml0OiBtYXli
ZSAidGhlIEpXVCBjbGFpbXMgb2YgdGhlIG9iamVjdCI/DQo+Pj4+DQo+Pj4+ICAgIGFueSBleHRl
bnNpb24gcGFyYW1ldGVycy4gIFRoaXMgSlNPTiBbUkZDNzE1OV0gY29uc3RpdHV0ZXMgdGhlIEpX
VA0KPj4+PiAgICBDbGFpbXMgU2V0IGRlZmluZWQgaW4gSldUIFtSRkM3NTE5XS4gIFRoZSBKV1Qg
Q2xhaW1zIFNldCBpcyB0aGVuDQo+Pj4+ICAgIHNpZ25lZCBvciBzaWduZWQgYW5kIGVuY3J5cHRl
ZC4NCj4+Pj4NCj4+Pj4gbml0OiBJICB0aGluayB3ZSB3YW50ICJUaGlzIEpTT04gW1JGQzcxNTld
IG9iamVjdCIuDQo+Pj4+DQo+Pj4+IChMb25nIHF1b3RlIGluY29taW5nKQ0KPj4+Pg0KPj4+PiAg
ICBUaGUgZm9sbG93aW5nIGlzIGFuIGV4YW1wbGUgb2YgdGhlIENsYWltcyBpbiBhIFJlcXVlc3Qg
T2JqZWN0IGJlZm9yZQ0KPj4+PiAgICBiYXNlNjR1cmwgZW5jb2RpbmcgYW5kIHNpZ25pbmcuICBO
b3RlIHRoYXQgaXQgaW5jbHVkZXMgZXh0ZW5zaW9uDQo+Pj4+ICAgIHZhcmlhYmxlcyBzdWNoIGFz
ICJub25jZSIgYW5kICJtYXhfYWdlIi4NCj4+Pj4NCj4+Pj4gICAgICB7DQo+Pj4+ICAgICAgICJp
c3MiOiAiczZCaGRSa3F0MyIsDQo+Pj4+ICAgICAgICJhdWQiOiAiaHR0cHM6Ly9uYW0wNi5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGc2VydmVyLmV4
YW1wbGUuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNv
bSU3QzY1OTEyN2NlZGQ1YTQyZWNiZmVkMDhkN2E2NTk2NjEyJTdDNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2MDc3NTIxODY3Njc0MCZhbXA7c2RhdGE9TDJi
d0VkZlc0dGJuVEk1RlNKVENDJTJCa0kzRUE2Q3FOTnFaNUZ6VDBKblJzJTNEJmFtcDtyZXNlcnZl
ZD0wIiwNCj4+Pj4gICAgICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQo+Pj4+
ICAgICAgICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQo+Pj4+ICAgICAgICJyZWRpcmVjdF91
cmkiOiAiaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHBzJTNBJTJGJTJGY2xpZW50LmV4YW1wbGUub3JnJTJGY2ImYW1wO2RhdGE9MDIlN0MwMSU3
Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNjU5MTI3Y2VkZDVhNDJlY2JmZWQwOGQ3
YTY1OTY2MTIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3
MTYwNzc1MjE4Njc2NzQwJmFtcDtzZGF0YT1YQnZMVEYwSnVOdXo3STNjN3BCZWwwR05TTjBsY1lx
dm9IQ05hZ0F3clNVJTNEJmFtcDtyZXNlcnZlZD0wIiwNCj4+Pj4gICAgICAgInNjb3BlIjogIm9w
ZW5pZCIsDQo+Pj4+ICAgICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsDQo+Pj4+ICAgICAgICJu
b25jZSI6ICJuLTBTNl9XekEyTWoiLA0KPj4+PiAgICAgICAibWF4X2FnZSI6IDg2NDAwDQo+Pj4+
ICAgICAgfQ0KPj4+Pg0KPj4+PiAgICBTaWduaW5nIGl0IHdpdGggdGhlICJSUzI1NiIgYWxnb3Jp
dGhtIHJlc3VsdHMgaW4gdGhpcyBSZXF1ZXN0IE9iamVjdA0KPj4+PiAgICB2YWx1ZSAod2l0aCBs
aW5lIHdyYXBzIHdpdGhpbiB2YWx1ZXMgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQo+Pj4+
DQo+Pj4+ICAgICAgZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltc3lZbVJqSW4wLmV3MEtJ
Q0pwYzNNaU9pQWljelpDYUdSU2EzDQo+Pj4+ICAgICAgRjBNeUlzRFFvZ0ltRjFaQ0k2SUNKb2RI
Undjem92TDNObGNuWmxjaTVsZUdGdGNHeGxMbU52YlNJc0RRb2dJbkpsDQo+Pj4+ICAgICAgYzNC
dmJuTmxYM1I1Y0dVaU9pQWlZMjlrWlNCcFpGOTBiMnRsYmlJc0RRb2dJbU5zYVdWdWRGOXBaQ0k2
SUNKek5rDQo+Pj4+ICAgICAgSm9aRkpyY1hReklpd05DaUFpY21Wa2FYSmxZM1JmZFhKcElqb2dJ
bWgwZEhCek9pOHZZMnhwWlc1MExtVjRZVzF3DQo+Pj4+ICAgICAgYkdVdWIzSm5MMk5pSWl3TkNp
QWljMk52Y0dVaU9pQWliM0JsYm1sa0lpd05DaUFpYzNSaGRHVWlPaUFpWVdZd2FXDQo+Pj4+ICAg
ICAgWnFjMnhrYTJvaUxBMEtJQ0p1YjI1alpTSTZJQ0p1TFRCVE5sOVhla0V5VFdvaUxBMEtJQ0p0
WVhoZllXZGxJam9nDQo+Pj4+ICAgICAgT0RZME1EQXNEUW9nSW1Oc1lXbHRjeUk2SUEwS0lDQjdE
UW9nSUNBaWRYTmxjbWx1Wm04aU9pQU5DaUFnSUNCN0RRDQo+Pj4+ICAgICAgb2dJQ0FnSUNKbmFY
WmxibDl1WVcxbElqb2dleUpsYzNObGJuUnBZV3dpT2lCMGNuVmxmU3dOQ2lBZ0lDQWdJbTVwDQo+
Pj4+ICAgICAgWTJ0dVlXMWxJam9nYm5Wc2JDd05DaUFnSUNBZ0ltVnRZV2xzSWpvZ2V5SmxjM05s
Ym5ScFlXd2lPaUIwY25WbGZTDQo+Pj4+ICAgICAgd05DaUFnSUNBZ0ltVnRZV2xzWDNabGNtbG1h
V1ZrSWpvZ2V5SmxjM05sYm5ScFlXd2lPaUIwY25WbGZTd05DaUFnDQo+Pj4+ICAgICAgSUNBZ0lu
QnBZM1IxY21VaU9pQnVkV3hzRFFvZ0lDQWdmU3dOQ2lBZ0lDSnBaRjkwYjJ0bGJpSTZJQTBLSUNB
Z0lIDQo+Pj4+ICAgICAgc05DaUFnSUNBZ0ltZGxibVJsY2lJNklHNTFiR3dzRFFvZ0lDQWdJQ0pp
YVhKMGFHUmhkR1VpT2lCN0ltVnpjMlZ1DQo+Pj4+ICAgICAgZEdsaGJDSTZJSFJ5ZFdWOUxBMEtJ
Q0FnSUNBaVlXTnlJam9nZXlKMllXeDFaWE1pT2lCYkluVnlianB0WVdObE9tDQo+Pj4+ICAgICAg
bHVZMjl0Ylc5dU9tbGhjRHB6YVd4MlpYSWlYWDBOQ2lBZ0lDQjlEUW9nSUgwTkNuMC5ud3duTnNr
MS1aa2JtbnZzDQo+Pj4+ICAgICAgRjZ6VEhtOENIRVJGTUdRUGhvcy1FSmNhSDRIaC1zTWdrOGVQ
ckdod190clBZczhLUXhzbjZSOUVtb193SHdhanlGDQo+Pj4+ICAgICAgS3p1TVhaRlNaM3A2TWI4
ZGt4dFZ5am95MkdJenZ1SlRfdTdQa1kydDhRVTloakJjSHM2OFBrZ2pEVlRyRzF1UlR4DQo+Pj4+
ICAgICAgMEd4RmJ1UGJqOTZ0VnVqMTFwVG5tRkNVUjZJRU9YS1lyN2lHT0NSQjNidGZKaE0wX0FL
UVVmcUtuUmxyUnNjYzhLDQo+Pj4+ICAgICAgb2wtY1NMV29ZRTlsNVFxaG9sSW16alRfY01uTkl6
blc5RTdDRHlXWFRzTzcweG5CNFNrRzZwWGZMU2pMTGx4bVBHDQo+Pj4+ICAgICAgaXlvbl8tVGUx
MTFWOHVFODNJbHpDWUliX05NWHZ0VElWYzFqcHNwblRTRDd4TWJwTC0yUWd3VXNBbE1HencNCj4+
Pj4NCj4+Pj4gRGVjb2RpbmcgdGhlIGJhc2U2NCBvZiB0aGUgYm9keSwgd2Ugc2VlOg0KPj4+PiB7
DQo+Pj4+ICAiaXNzIjogInM2QmhkUmtxdDMiLA0KPj4+PiAgImF1ZCI6IA0KPj4+PiAiaHR0cHM6
Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG
JTJGDQo+Pj4+IHNlcnZlci5leGFtcGxlLmNvbSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K
b25lcyU0MG1pY3Jvc29mdC5jb20NCj4+Pj4gJTdDNjU5MTI3Y2VkZDVhNDJlY2JmZWQwOGQ3YTY1
OTY2MTIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZA0KPj4+PiBiNDclN0MxJTdDMCU3
QzYzNzE2MDc3NTIxODY3Njc0MCZhbXA7c2RhdGE9TDJid0VkZlc0dGJuVEk1RlNKVENDJTJCDQo+
Pj4+IGtJM0VBNkNxTk5xWjVGelQwSm5ScyUzRCZhbXA7cmVzZXJ2ZWQ9MCIsDQo+Pj4+ICAicmVz
cG9uc2VfdHlwZSI6ICJjb2RlIGlkX3Rva2VuIiwNCj4+Pj4gICJjbGllbnRfaWQiOiAiczZCaGRS
a3F0MyIsDQo+Pj4+ICAicmVkaXJlY3RfdXJpIjogDQo+Pj4+ICJodHRwczovL25hbTA2LnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkYNCj4+Pj4gY2xp
ZW50LmV4YW1wbGUub3JnJTJGY2ImYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBt
aWNyb3NvZg0KPj4+PiB0LmNvbSU3QzY1OTEyN2NlZGQ1YTQyZWNiZmVkMDhkN2E2NTk2NjEyJTdD
NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjDQo+Pj4+IGQwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjA3
NzUyMTg2NzY3NDAmYW1wO3NkYXRhPVhCdkxURjBKdU51ejdJM2M3cEINCj4+Pj4gZWwwR05TTjBs
Y1lxdm9IQ05hZ0F3clNVJTNEJmFtcDtyZXNlcnZlZD0wIiwNCj4+Pj4gICJzY29wZSI6ICJvcGVu
aWQiLA0KPj4+PiAgInN0YXRlIjogImFmMGlmanNsZGtqIiwNCj4+Pj4gICJub25jZSI6ICJuLTBT
Nl9XekEyTWoiLA0KPj4+PiAgIm1heF9hZ2UiOiA4NjQwMCwNCj4+Pj4gICJjbGFpbXMiOg0KPj4+
PiAgIHsNCj4+Pj4gICAgInVzZXJpbmZvIjoNCj4+Pj4gICAgIHsNCj4+Pj4gICAgICAiZ2l2ZW5f
bmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQo+Pj4+ICAgICAgIm5pY2tuYW1lIjogbnVsbCwN
Cj4+Pj4gICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KPj4+PiAgICAgICJlbWFp
bF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQo+Pj4+ICAgICAgInBpY3R1cmUiOiBu
dWxsDQo+Pj4+ICAgICB9LA0KPj4+PiAgICAiaWRfdG9rZW4iOg0KPj4+PiAgICAgew0KPj4+PiAg
ICAgICJnZW5kZXIiOiBudWxsLA0KPj4+PiAgICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6
IHRydWV9LA0KPj4+PiAgICAgICJhY3IiOiB7InZhbHVlcyI6IFsidXJuOm1hY2U6aW5jb21tb246
aWFwOnNpbHZlciJdfQ0KPj4+PiAgICAgfQ0KPj4+PiAgIH0NCj4+Pj4gfQ0KPj4+Pg0KPj4+PiBJ
J20gbm90IHN1cmUgd2hlcmUgdGhlICJjbGFpbXMiIGNsYWltIGlzIGNvbWluZyBmcm9tIC0tIDY3
NDkgDQo+Pj4+IGRvZXNuJ3Qgc2VlbSB0byB0YWxrIGFib3V0IGl0LiAgKE5vdGUgdGhhdCB0aGlz
IGV4YW1wbGUgaXMgdXNlZCANCj4+Pj4gbGF0ZXIgb24gYXMNCj4+Pj4gd2VsbC4pDQo+Pj4+DQo+
Pj4+IFNlY3Rpb24gNS4yLjENCj4+Pj4NCj4+Pj4gICAgSXQgaXMgcG9zc2libGUgZm9yIHRoZSBS
ZXF1ZXN0IE9iamVjdCB0byBpbmNsdWRlIHZhbHVlcyB0aGF0IGFyZSB0bw0KPj4+PiAgICBiZSBy
ZXZlYWxlZCBvbmx5IHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gIEFzIHN1Y2gsIHRoZQ0K
Pj4+PiAgICAicmVxdWVzdF91cmkiIE1VU1QgaGF2ZSBhcHByb3ByaWF0ZSBlbnRyb3B5IGZvciBp
dHMgbGlmZXRpbWUuICBGb3INCj4+Pj4gICAgdGhlIGd1aWRhbmNlLCByZWZlciB0byA1LjEuNC4y
LjIgb2YgW1JGQzY4MTldLiAgSXQgaXMgUkVDT01NRU5ERUQNCj4+Pj4gICAgdGhhdCBpdCBiZSBy
ZW1vdmVkIGFmdGVyIGEgcmVhc29uYWJsZSB0aW1lb3V0IHVubGVzcyBhY2Nlc3MgY29udHJvbA0K
Pj4+PiAgICBtZWFzdXJlcyBhcmUgdGFrZW4uDQo+Pj4+DQo+Pj4+IEl0IHNvdW5kcyBsaWtlIGEg
bGluayB0byANCj4+Pj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r
LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LnczLm9yZyUyRlRSJTJGY2FwYWJpbGl0eS11cmxz
JTJGJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzY1
OTEyN2NlZGQ1YTQyZWNiZmVkMDhkN2E2NTk2NjEyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2MDc3NTIxODY3Njc0MCZhbXA7c2RhdGE9UXRvZlhEWGJV
YzJVMmllSlloMHdGSFhHaXZMRnVVNjRHaHN4Q1c5cEQ5TSUzRCZhbXA7cmVzZXJ2ZWQ9MCBtaWdo
dCBhbHNvIGJlIHVzZWZ1bC4NCj4+Pj4NCj4+Pj4gU2VjdGlvbiA1LjIuMg0KPj4+Pg0KPj4+PiBE
byB3ZSB3YW50IHRvIHJlbWluZCB0aGUgcmVhZGVyIHRoYXQgdGhlIG90aGVyIHF1ZXJ5IHBhcmFt
ZXRlcnMgYXJlDQo+PiBqdXN0DQo+Pj4+IGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eT8NCj4+
Pj4NCj4+Pj4gU2VjdGlvbiA1LjIuMw0KPj4+Pg0KPj4+PiAgICBUaGUgZm9sbG93aW5nIGlzIGFu
IGV4YW1wbGUgb2YgdGhpcyBmZXRjaCBwcm9jZXNzOg0KPj4+Pg0KPj4+PiAgICAgIEdFVCAvcmVx
dWVzdC5qd3QgSFRUUC8xLjENCj4+Pj4gICAgICBIb3N0OiB0ZnAuZXhhbXBsZS5vcmcNCj4+Pj4N
Cj4+Pj4gSXQncyB1c2VmdWwgdG8gc2hvdyBnb29kIGh5Z2VpbmUgaW4gZXhhbXBsZXM7IGNhbiB3
ZSBnZXQgdGhlIGV4dHJhIA0KPj4+PiBlbnRyb3B5IGluIHRoaXMgcmVxdWVzdCB0aGF0IHdlIGhh
dmUgaW4gdGhlIHByZXZpb3VzIGV4YW1wbGUocyk/DQo+Pj4+DQo+Pj4+IFNlY3Rpb24gNi4yDQo+
Pj4+DQo+Pj4+ICAgIFRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNVVNUIHBlcmZvcm0gdGhlIHNp
Z25hdHVyZSB2YWxpZGF0aW9uIA0KPj4+PiBvZg0KPj4gdGhlDQo+Pj4+ICAgIEpTT04gV2ViIFNp
Z25hdHVyZSBbUkZDNzUxNV0gc2lnbmVkIHJlcXVlc3Qgb2JqZWN0LiAgRm9yIHRoaXMsIHRoZQ0K
Pj4+PiAgICAiYWxnIiBIZWFkZXIgUGFyYW1ldGVyIGluIGl0cyBKT1NFIEhlYWRlciBNVVNUIG1h
dGNoIHRoZSB2YWx1ZSANCj4+Pj4gb2YNCj4+IHRoZQ0KPj4+PiAgICBwcmUtcmVnaXN0ZXJlZCBh
bGdvcml0aG0uICBUaGUgc2lnbmF0dXJlIE1VU1QgYmUgdmFsaWRhdGVkIGFnYWluc3QNCj4+Pj4g
ICAgdGhlIGFwcHJvcHJpYXRlIGtleSBmb3IgdGhhdCAiY2xpZW50X2lkIiBhbmQgYWxnb3JpdGht
Lg0KPj4+Pg0KPj4+PiBEb2VzICJ0aGUgcHJlLXJlZ2lzdGVyZWQgYWxnb3JpdGhtIiBjb25jZXB0
IGV4aXN0IGluIHRoZSBzcGVjcyANCj4+Pj4gb3V0c2lkZSBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3
dC1iY3A/DQo+Pj4+DQo+Pj4+IFNlY3Rpb24gOQ0KPj4+Pg0KPj4+PiBUaGUgZXJyb3IgY29kZXMg
d2UgbGlzdCBpbiBTZWN0aW9uIDcgYXJlIGFscmVhZHkgcmVnaXN0ZXJlZCwgZm9yIHRoZQ0KPj4+
PiBPSURDIHVzYWdlLiAgRG8gd2Ugd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgdGhhdD8gICAo
SSBndWVzcyBpdCB3b3VsZA0KPj4+PiBiZSBkaXNhbGxvd2VkIGJ5IHByb2Nlc3MgdG8gdHJ5IHRv
IHVwZGF0ZSB0aGUgZXhpc3RpbmcgcmVnaXN0cmF0aW9uIA0KPj4+PiB0byBhbHNvIHBvaW50IGF0
IHRoaXMgZG9jdW1lbnQuKQ0KPj4+Pg0KPj4+PiBTZWN0aW9uIDEwDQo+Pj4+DQo+Pj4+IFdlIHBy
b2JhYmx5IGFsc28gd2FudCB0byByZWZlcmVuY2UgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLg0K
Pj4+Pg0KPj4+PiBTZWN0aW9uIDEwLjENCj4+Pj4NCj4+Pj4gICAgV2hlbiBzZW5kaW5nIHRoZSBh
dXRob3JpemF0aW9uIHJlcXVlc3Qgb2JqZWN0IHRocm91Z2ggInJlcXVlc3QiDQo+Pj4+ICAgIHBh
cmFtZXRlciwgaXQgTVVTVCBlaXRoZXIgYmUgc2lnbmVkIHVzaW5nIEpXUyBbUkZDNzUxNV0gb3Ig
ZW5jcnlwdGVkDQo+Pj4+ICAgIHVzaW5nIEpXRSBbUkZDNzUxNl0gd2l0aCB0aGVuIGNvbnNpZGVy
ZWQgYXBwcm9wcmlhdGUgYWxnb3JpdGhtLg0KPj4+Pg0KPj4+PiBVcCBpbiBTZWN0aW9uIDUgd2Ug
b25seSBhbGxvdyAoYSkgc2lnbmVkIGFuZCAoYikgc2lnbmVkIHRoZW4gDQo+Pj4+IGVuY3J5cHRl
ZDsgc2ltaWxhcmx5LCBpbiBTZWN0aW9uIDQgd2UgcmVpdGVyYXRlICJzaWduZWQgdGhlbiANCj4+
Pj4gZW5jcnlwdGVkIi4gIFdoeSBpcw0KPj4gaXQNCj4+Pj4gb2theSB0byB0YWxrIGFib3V0IGp1
c3QgInNpZ25lZCBvciBlbmNyeXB0ZWQiIGhlcmU/DQo+Pj4+DQo+Pj4+IFNlY3Rpb24gMTAuMg0K
Pj4+Pg0KPj4+PiAgICAoYikgIFZlcmlmeWluZyB0aGF0IHRoZSBzeW1tZXRyaWMga2V5IGZvciB0
aGUgSldFIGVuY3J5cHRpb24gaXMgdGhlDQo+Pj4+ICAgICAgICAgY29ycmVjdCBvbmUgaWYgdGhl
IEpXRSBpcyB1c2luZyBzeW1tZXRyaWMgZW5jcnlwdGlvbi4NCj4+Pj4NCj4+Pj4gU2ltaWxhcmx5
IHRvIHRoZSBwcmV2aW91cyBwb2ludCwgeW91IGFsc28gbmVlZCB0byBjaGVjayB0aGUgDQo+Pj4+
IHNpZ25hdHVyZSwgd2hpY2ggd2lsbCBhbHdheXMgYmUgdGhlcmUuDQo+Pj4+DQo+Pj4+ICAgIChk
KSAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaXMgcHJvdmlkaW5nIGFuIGVuZHBvaW50IHRoYXQgcHJv
dmlkZXMgYQ0KPj4+PiAgICAgICAgIFJlcXVlc3QgT2JqZWN0IFVSSSBpbiBleGNoYW5nZSBmb3Ig
YSBSZXF1ZXN0IE9iamVjdC4gIEluIA0KPj4+PiB0aGlzDQo+Pj4+DQo+Pj4+IEkgZG9uJ3QgdGhp
bmsgdGhpcyBpcyBhIGNvbXBsZXRlIHNlbnRlbmNlIChhbmQgaXQncyBkZWZpbml0ZWx5IG5vdCAN
Cj4+Pj4gYSBwYXJhbGxlbCBjb25zdHJ1Y3Rpb24gd2l0aCAoYSktKGMpISkuICBJIHRoaW5rIHBl
cmhhcHMgYSBjcmlzcCANCj4+Pj4gb25lLWxpbmUgc3VtbWFyeSBvZiB0aGlzIG1ldGhvZCB3b3Vs
ZCBiZSAiRGVsZWdhdGluZyB0aGUgDQo+Pj4+IGF1dGhvcml6YXRpb24gY2hlY2sgdG8NCj4+IGEN
Cj4+Pj4gc2VwYXJhdGUgIlJlcXVlc3QgT2JqZWN0IHRvIFJlcXVlc3QgT2JqZWN0IFVSSSIgZW5k
cG9pbnQgb24gdGhlIA0KPj4+PiBBdXRob3JpemF0aW9uIFNlcnZlciIuICAoVGhlIHdyaXRpbmcg
aW4gdGhlIHJlc3Qgb2YgdGhpcyBwYXJhZ3JhcGgNCj4+IGNvdWxkDQo+Pj4+IGFsc28gdXNlIGFu
IGVkaXRpbmcgcGFzcy4pDQo+Pj4+DQo+Pj4+ICAgIChlKSAgQSB0aGlyZCBwYXJ0eSwgc3VjaCBh
cyBhIFRydXN0IEZyYW1ld29yayBQcm92aWRlciwgcHJvdmlkZXMgYW4NCj4+Pj4gICAgICAgICBl
bmRwb2ludCB0aGF0IHByb3ZpZGVzIGEgUmVxdWVzdCBPYmplY3QgVVJJIGluIGV4Y2hhbmdlIGZv
ciBhDQo+Pj4+ICAgICAgICAgUmVxdWVzdCBPYmplY3QuICBUaGUgc2FtZSByZXF1aXJlbWVudHMg
YXMgKGIpIGFib3ZlIGFwcGx5LiAgSW4NCj4+Pj4gICAgICAgICBhZGRpdGlvbiwgdGhlIEF1dGhv
cml6YXRpb24gU2VydmVyIE1VU1Qga25vdyBvdXQtb2YtYmFuZCB0aGF0DQo+Pj4+ICAgICAgICAg
dGhlIENsaWVudCB1dGlsaXplcyB0aGUgVHJ1c3QgRnJhbWV3b3JrIE9wZXJhdG9yLg0KPj4+Pg0K
Pj4+PiBUaGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYWxzbyBoYXMgdG8gdHJ1c3QgdGhlIHRoaXJk
LXBhcnR5IHByb3ZpZGVyIA0KPj4+PiB0byBhY3R1YWxseSBkbyBpdHMgam9iIGFuZCBub3QgbWlz
YmVoYXZlLCByaWdodD8NCj4+Pj4NCj4+Pj4gU2VjdGlvbiAxMC4zDQo+Pj4+DQo+Pj4+IEknbSBu
b3QgZW50aXJlbHkgc3VyZSB3aGF0ICJbdF1oZSBlbmRwb2ludHMgaXRoYXQgY29tZSBpbnRvIA0K
Pj4+PiBxdWVzdGlvbiBpbiB0aGlzIHNwZWNpZmljYXRpb24iIGlzIHN1cHBvc2VkIHRvIG1lYW4g
LS0gaXMgaXQganVzdCANCj4+Pj4gInRoZSBPQXV0aCAyLjAgZW5kcG9pbnRzIHByZXNlbnRseSBk
ZWZpbmVkIGluIFN0YW5kYXJkcy1UcmFjayBSRkNzIj8NCj4+Pj4NCj4+Pj4gICAgSW4gW1JGQzY3
NDldLCB3aGlsZSBSZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQsIG90aGVycyBhcmUgbm90DQo+
Pj4+ICAgIGluY2x1ZGVkIGluIHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3QuICBBcyB0aGUgcmVz
dWx0LCB0aGUgc2FtZQ0KPj4+PiAgICBhcHBsaWVzIHRvIEF1dGhvcml6YXRpb24gUmVxdWVzdCBP
YmplY3QuDQo+Pj4+DQo+Pj4+IG5pdDogaW5jbHVkZWQgaW4gd2hhdD8NCj4+Pj4NCj4+Pj4gU2Vj
dGlvbiAxMC40DQo+Pj4+DQo+Pj4+IEl0J3MgcHJvYmFibHkgYWxzbyB3b3J0aCBjaXRpbmcgdGhl
IGdlbmVyaWMgVVJJIHNlY3VyaXR5IA0KPj4+PiBjb25zaWRlcmF0aW9ucyBmcm9tIFJGQyAzOTg2
LCBoZXJlLg0KPj4+Pg0KPj4+PiBTZWN0aW9uIDEwLjQuMQ0KPj4+Pg0KPj4+PiAgICAicmVxdWVz
dF91cmkiLCBhbmQgKGQpIGRvIG5vdCBwZXJmb3JtIHJlY3Vyc2l2ZSBHRVQgb24gdGhlDQo+Pj4+
ICAgICJyZXF1ZXN0X3VyaSIuDQo+Pj4+DQo+Pj4+IG5pdDogcmVtb3ZlIHRoZSAiZG8iIGluIG9y
ZGVyIHRvIG1ha2UgdGhlIGNvbnN0cnVjdGlvbiBwYXJhbGxlbC4NCj4+Pj4NCj4+Pj4gU2VjdGlv
biAxMi4xDQo+Pj4+DQo+Pj4+ICAgIEl0IGlzIG9mdGVuIGhhcmQgZm9yIHRoZSB1c2VyIHRvIGZp
bmQgb3V0IGlmIHRoZSBwZXJzb25hbCBkYXRhIGFza2VkDQo+Pj4+ICAgIGZvciBpcyBzdHJpY3Rs
eSBuZWNlc3NhcnkuICBBIFRydXN0IEZyYW1ld29yayBQcm92aWRlciBjYW4gaGVscCB0aGUNCj4+
Pj4gICAgdXNlciBieSBleGFtaW5pbmcgdGhlIENsaWVudCByZXF1ZXN0IGFuZCBjb21wYXJpbmcg
dG8gdGhlIHByb3Bvc2VkDQo+Pj4+ICAgIHByb2Nlc3NpbmcgYnkgdGhlIENsaWVudCBhbmQgY2Vy
dGlmeWluZyB0aGUgcmVxdWVzdC4gIEFmdGVyIHRoZQ0KPj4+PiAgICBjZXJ0aWZpY2F0aW9uLCB0
aGUgQ2xpZW50LCB3aGVuIG1ha2luZyBhbiBBdXRob3JpemF0aW9uIFJlcXVlc3QsIGNhbg0KPj4+
PiAgICBzdWJtaXQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IHRvIHRoZSBUcnVzdCBGcmFtZXdvcmsg
UHJvdmlkZXIgdG8NCj4+Pj4gICAgb2J0YWluIHRoZSBSZXF1ZXN0IE9iamVjdCBVUkkuDQo+Pj4+
DQo+Pj4+IHNpZGUgbm90ZTogSW4gbXkgaGVhZCB0aGUgYWN0IG9mIGNlcnRpZmljYXRpb24gd2Fz
IHRoZSBhY3Qgb2YgDQo+Pj4+IG1ha2luZw0KPj4gdGhlDQo+Pj4+IHRyYW5zbGF0aW9uIHRvIGEg
UmVxdWVzdCBPYmplY3QgVVJJLCBzbyBJJ20ga2luZCBvZiBjdXJpb3VzIHdoZXJlIA0KPj4+PiBt
eSB2aXNpb24gZGlmZmVycyBmcm9tIHJlYWxpdHkuDQo+Pj4+DQo+Pj4+IFRoZSB0aGlyZCBwYXJh
Z3JhcGggc2VlbXMgdG8gbW9zdGx5IGp1c3QgYmUgZGVzY3JpYmluZyB0aGUgDQo+Pj4+IHByb2Nl
ZHVyZSBvZiBob3cgdGhpcyBmbG93IHdvcmtzLCB3aGljaCB3b3VsZCBub3QgbmVjZXNzYXJpbHkg
YmUgDQo+Pj4+IHNwZWNpZmljIHRvIHRoZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24u
DQo+Pj4+DQo+Pj4+IFNlY3Rpb24gMTIuMi4yDQo+Pj4+DQo+Pj4+ICAgIEV2ZW4gaWYgdGhlIHBy
b3RlY3RlZCByZXNvdXJjZSBkb2VzIG5vdCBpbmNsdWRlIGEgcGVyc29uYWxseQ0KPj4+PiAgICBp
ZGVudGlmaWFibGUgaW5mb3JtYXRpb24sIGl0IGlzIHNvbWV0aW1lcyBwb3NzaWJsZSB0byBpZGVu
dGlmeSB0aGUNCj4+Pj4gICAgdXNlciB0aHJvdWdoIHRoZSBSZXF1ZXN0IE9iamVjdCBVUkkgaWYg
cGVyc2lzdGVudCBwZXItdXNlciBSZXF1ZXN0DQo+Pj4+ICAgIE9iamVjdCBVUkkgaXMgdXNlZC4g
IEEgdGhpcmQgcGFydHkgbWF5IG9ic2VydmUgaXQgdGhyb3VnaCANCj4+Pj4gYnJvd3Nlcg0KPj4+
Pg0KPj4+PiBuaXQ6IG5lZWQgYW4gYXJ0aWNsZSBmb3IgInBlcnNpc3RlbnQgcGVyLXVzZXIgUmVx
dWVzdCBPYmplY3QgVVJJIiANCj4+Pj4gKG9yIG1ha2UgaXQgcGx1cmFsLCBhcyAiVVJJcyBhcmUg
dXNlZCIpLg0KPj4+Pg0KPj4+PiAgICBUaGVyZWZvcmUsIHBlci11c2VyIFJlcXVlc3QgT2JqZWN0
IFVSSSBzaG91bGQgYmUgYXZvaWRlZC4NCj4+Pj4NCj4+Pj4gbml0OiBJIHRoaW5rIHRoaXMgaXMg
YmV0dGVyIGFzICJzdGF0aWMgcGVyLXVzZXIgUmVxdWVzdGUgT2JqZWN0IFVSSXMiDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJG
bGlzdGluZm8lMkZvYXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jv
c29mdC5jb20lN0M2NTkxMjdjZWRkNWE0MmVjYmZlZDA4ZDdhNjU5NjYxMiU3QzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjA3NzUyMTg2NzY3NDAmYW1wO3Nk
YXRhPTU1SGR0NlcxdUVMQ0MlMkJoRnJGdk9jUEROJTJGNXpwY1NOUW1KRm9neEFvaTlnJTNEJmFt
cDtyZXNlcnZlZD0wDQo=


From nobody Fri Jan 31 06:39: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 7BD17120804 for ; Fri, 31 Jan 2020 06:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EplQFxUhmuV for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST)
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 98BF81201C6 for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id g195so6669778qke.13 for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SkygXKwWCVaFG7iEQtI04gx2ROTdb+WduEzYvuJLBNA=; b=toIiGWHL8lUjPQ1z8KWEc9+Y0DRvPcbd+4oqDT18FrIaz1c/MKdAwgKA+3wnM3Stb0 ApXDewqzO/nNdcu55oS0EE8E0l3Zq5xiQRwm6AXcqx8LZP3Tg81lMn9Q+9QQyuEEzOgb u5E8zcCxGZ3ld6t4XMWacUZJkpuVLh3boDiV3X2sjrZBzEg/maRe81t8Q6SnsUeOt7E1 ajHXcQDDyl7qbPTzP6l00OunvpKjsARMDSTMKfcpznGvQeBK37nQVINXtk0pnKgKkNqR VkMQasfsPHcUaTgtTmGthH7SSBgvPtZzB7VnXKoYUjuzyU793pVpA18zN+Lc9INHDJNR MqHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=SkygXKwWCVaFG7iEQtI04gx2ROTdb+WduEzYvuJLBNA=; b=l1QC8lRa0UdSqN3GI9gVTItXwi4ts1A9QK4KLCo6+xwZcWWeJ21NBbT06uEoS1WoXK 8vuFFhw9vTtUfTThjBweBcJCqMBP1d+x61Up7ECTzT/Ry/py67DzVPJoPBgA6p7tj589 KDrvPJQPxIu59Ohp6HO84c/ysb6uhU4ngPWuQvVtahmT9HFwMGImeK2ikEzHWtkp3M4G xfL09XTcpwAX7Y0J3z19wjYMLy9YUpS5/BjnRHtI5fSpEJC1NRjPwvnny9VNVn5GmBPF b4uh+4GHZYbKEuJhmoAD/zEUtkww4nL2WtgSk//VN0WnSukKjVlaYmAQsgwUS+QGfVg4 Jaww==
X-Gm-Message-State: APjAAAUAMvKCs+yJIskQRULsvceG3wzCtrP9Lpi5Wyd6ZCHcWxS7tQYG Zs6udScCmx4NcsG00TqGHicmyZTl6ZbFvg==
X-Google-Smtp-Source: APXvYqybbC8alSxVhZB0LFDWUUonTktDiVfVbVdfSfKhgjPBrnhGb/K9M9rGUM4J5yY2Q7uNmChYKA==
X-Received: by 2002:a05:620a:9c7:: with SMTP id y7mr10822565qky.393.1580481588814;  Fri, 31 Jan 2020 06:39:48 -0800 (PST)
Received: from [192.168.8.103] ([190.107.226.39]) by smtp.gmail.com with ESMTPSA id t38sm5233378qta.78.2020.01.31.06.39.36 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:39:37 -0800 (PST)
To: oauth@ietf.org
References:  <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com>  <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>   
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: 
Date: Fri, 31 Jan 2020 11:39:36 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B0EA313B44139C1AFF46A01F"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Jan 2020 14:39:53 -0000

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

I remember the fight to have diffrent keys defined for signing and
encryption.

I am glad times have changed.=C2=A0=C2=A0

You can use difffent keys now with a JWKS URI that allows you to
separate the private keys.

The question is if you want the verifier to be able to differentiate the
purpose.

One way might be to encode some context into the keyID, but it is
probably better to have separate JWKS URI.

John B.



On 1/30/2020 4:27 PM, Dick Hardt wrote:
> Rephrasing Annabelle's description to highlight the issue:
>
> The AS says "here are the keys to use to verify all of the tokens that
> *we* have signed"
>
> Separating duties in a large system is good cryptographic hygiene, IE,
> one component signs ID Tokens, another signs access tokens.
>
>
> On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle
>  > wrote:
>
>     This could be nice, but it=E2=80=99s solving a different problem. T=
he
>     issue I=E2=80=99m drawing attention to is about how an AS indicates=
 that a
>     given key is valid. That=E2=80=99s what the jwks_uri AS metadata pr=
operty
>     is for, and it does a great job. The problem is that it does not
>     allow enough granularity. Currently all an AS can do is say =E2=80=9C=
here
>     are the keys to use to verify stuff I signed.=E2=80=9D It can=E2=80=
=99t say =E2=80=9Chere
>     are the keys to use to verify ID Tokens, and here is a different
>     set of keys to use to verify access tokens.=E2=80=9D
>
>     =E2=80=94
>     Annabelle Backman
>     AWS Identity
>
>     > On Jan 28, 2020, at 10:51 PM, Manger, James
>          > wrote:
>     >
>     > =EF=BB=BF
>     >>
>     >>> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on=
 a URL-based
>     >>> addressing format for individual keys within the set, but that
>     ship=E2=80=99s sailed.
>     >
>     > Using the fragment on a JWKS URL to indicate the key id would be
>     good.
>     > Then a single URL by itself can identify a specific key.
>     >
>     > https://example.com/keys.jwks#2011-04-29
>     >
>     > This would have worked particularly well if a JWKS was a JSON
>     object with key-ids as the member names, instead of an array. That
>     is presumably too late to fix. But defining the fragment format
>     for application/jwk-set+json to be a kid value should be possible.
>     >
>     > If you put multiple keys with the same key-id in a JWKS you are
>     asking for trouble -- just call that a non-interoperable corner
>     for people to avoid.
>     >
>     > --
>     > James Manger
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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


  
    
  
  
    
I remember the fight to have diffrent keys defined for signing
      and encryption.

    

    
I am glad times have changed.  

    
You can use difffent keys now with a JWKS URI that allows you to
      separate the private keys.

    
The question is if you want the verifier to be able to
      differentiate the purpose.

    
One way might be to encode some context into the keyID, but it is
      probably better to have separate JWKS URI.

    
John B.

    

    


    

    


    

    
On 1/30/2020 4:27 PM, Dick Hardt wrote:

    

    

      
      
Rephrasing Annabelle's description to highlight the
        issue:
        


          
The AS says "here are the keys to use to verify all of
            the tokens that we have signed"

        

        


        

        
Separating duties in a large system is good cryptographic
          hygiene, IE, one component signs ID Tokens, another signs
          access tokens.

        


        

      

      

      

        
On Wed, Jan 29, 2020 at 1:36
          PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org>
          wrote:

        

        
This
          could be nice, but it’s solving a different problem. The issue
          I’m drawing attention to is about how an AS indicates that a
          given key is valid. That’s what the jwks_uri AS metadata
          property is for, and it does a great job. The problem is that
          it does not allow enough granularity. Currently all an AS can
          do is say “here are the keys to use to verify stuff I signed.”
          It can’t say “here are the keys to use to verify ID Tokens,
          and here is a different set of keys to use to verify access
          tokens.”

          

          —

          Annabelle Backman

          AWS Identity

          

          > On Jan 28, 2020, at 10:51 PM, Manger, James <James.H.Manger@team.telstra.com>
          wrote:

          > 

          > 

          >> 

          >>> It would’ve been nice if JWK could’ve agreed on a
          URL-based 

          >>> addressing format for individual keys within the
          set, but that ship’s sailed.

          > 

          > Using the fragment on a JWKS URL to indicate the key id
          would be good.

          > Then a single URL by itself can identify a specific key.

          > 

          > https://example.com/keys.jwks#2011-04-29

          > 

          > This would have worked particularly well if a JWKS was a
          JSON object with key-ids as the member names, instead of an
          array. That is presumably too late to fix. But defining the
          fragment format for application/jwk-set+json to be a kid value
          should be possible.

          > 

          > If you put multiple keys with the same key-id in a JWKS
          you are asking for trouble -- just call that a
          non-interoperable corner for people to avoid.

          > 

          > --

          > James Manger

          > _______________________________________________

          > OAuth mailing list

          > OAuth@ietf.org

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

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

        

      

      

      

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


    

  


--------------B0EA313B44139C1AFF46A01F--


From nobody Fri Jan 31 06:46: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 B769E120804; Fri, 31 Jan 2020 06:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 3pLKBdelYLwt; Fri, 31 Jan 2020 06:46:48 -0800 (PST)
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 873A312007C; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id f129so8972410wmf.2; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
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:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=SiyCNKtEE350zJsS+BB1rEKU+aMjWjtueKdmo7VlbuBau6Vu86r7fvpO22AEAhA0RM ju1hZPL2EU6VGHLEcCFgUpVMPsSvvj6FU4XbpCUqLXyvkI3zEQhp+c8Md7IkbGQzNJ8O qmWJp1bS3RpGtMs+llajgdaW2DV3683R/gLhg/SBHJFki/EvovQtbLMaIduY3y+Wq7PQ I2xFpbr2aZ5pINKXdKhUKF8KFaGNazEsrK7T1DWSdNvm6Zhyc/dV5VqhIbrGmaiXH/cu 05vxZXHVXYdiePBKdpHrolpu/oNqWGd+YKHmV3alvxFRNMhkIjyj6WLuc0feBgy34SjP dL3w==
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:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=cjZRhMuQnJfroZ2UyVx92Fkb400lB/TEq/7MdgeVPQ4Yyuz9uM9He3WXed48nLdcrZ s02jxvZfGA6C0SJpwu/ia/QfGhesF3fY6ixpk0tbh2r5HSo2K0M0WW+I1X6edczPZ3sV zk4BEdjjQqhf+4cv4Ex99/JApykUa9sHIiz8PzIPjtIM0AfSUSiDFBMgJIMdhqpkrxlv i0G4lZ1HE81t5FjWQ5PzDkIBqPxbrTj6xfdez9qiqpSLouiutZ6hsA2J+sXlyskMlVxH cZZPBRsJMVjT0KjY0YrVmM3m/h/NMygyQ5SEPSTdPI7S3ZZ3e6ByYdimbNbMxR8d9RHv 2Iag==
X-Gm-Message-State: APjAAAU0OoxDTBpTa3JfdVO0g+qRF0EadAKuio3WPsAZm5iGCNXbCyZr qr4NlfVBHD0otUpxzLSSjw==
X-Google-Smtp-Source: APXvYqyGf15WyfNmCrugFRFXn5awUao7hl4g7lLNUDzzKF26BM0rIH/jDma/2tAA74LUGSIqpHGcPw==
X-Received: by 2002:a05:600c:2207:: with SMTP id z7mr12724086wml.138.1580482005713;  Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Received: from [192.0.2.1] ([8.40.30.20]) by smtp.gmail.com with ESMTPSA id e8sm11937489wrt.7.2020.01.31.06.46.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Filip Skokan 
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jan 2020 15:46:44 +0100
Message-Id: <8D83F40F-3E17-427D-9606-3453BA00DDFC@gmail.com>
References: 
In-Reply-To: 
To: Benjamin Kaduk , The IESG , "draft-ietf-oauth-jwsreq@ietf.org" , oauth , "oauth-chairs@ietf.org" 
X-Mailer: iPhone Mail (17C54)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Jan 2020 14:46:52 -0000

I also agree and support that client_id outside of the request object be usa=
ble for the purposes described earlier, given that it is also a MUST it be p=
resent in the request object with the same value as outside.=20

Odesl=C3=A1no z iPhonu

> 31. 1. 2020 v 15:31, Mike Jones :
>=20
> =EF=BB=BFI also agree that we must allow client_id to be expressed outside=
 of the signed request, as described by Nat.
>=20
>                -- Mike
>=20
> -----Original Message-----
> From: OAuth  On Behalf Of John Bradley
> Sent: Friday, January 31, 2020 6:25 AM
> To: Nat Sakimura ; Benjamin Kaduk 
> Cc: oauth ; oauth-chairs@ietf.org; The IESG ; draft-ietf-oauth-jwsreq@ietf.org
> Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-=
oauth-jwsreq-19: (with DISCUSS and COMMENT)
>=20
>> =46rom the discussions I have had, I agree with Nat's assment.
>=20
> John B.
>=20
>> On 1/31/2020 12:06 AM, Nat Sakimura wrote:
>> Hi
>>=20
>> Re: JWT
>> I understand your concern and we can put some explanatory notes.=20
>> Having said that, JAR is still a valid JWT, I think :-)
>>=20
>> Re: client_id
>> We actually discussed client_id issues with OpenID Connect WG Call=20
>> yesterday as well.
>> I hear a pretty strong voice from the developer community that they=20
>> want client_id as a query parameter and it should not pose a security=20
>> issue as long as it is required to match what is in the JWT. In fact,=20
>> that was the position taken in the WG last call. So, in effect, WG is=20
>> actually pushing back the change IESG wanted.
>>=20
>> As I understand it, there are two points to be made:
>> (1) If client_id is not in the query parameter, then it MUST be in the=20=

>> JWT header OR MUST be supplied as a query parameter in some encrypted=20
>> JAR case
>> (2) To check if requst_uri is a registered and valid URI, not having=20
>> client_id in the query parameter will have performance impacts in a=20
>> large AS.
>>=20
>> The encryption case (1) can be solved by adding client_id in the JWT=20
>> Header but it will not solve (2).
>> So, IMHO, putting client_id back to the query parameter (and MUST=20
>> match the value in JWT) is a way to go.
>> Since that was the position by the WG at the WG Last Call, I do not=20
>> feel that it needs to be brought back to the WG last call, but that is=20=

>> your call.
>>=20
>> Best,
>>=20
>> Nat Sakimura
>>=20
>>> On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk  wrote:
>>>=20
>>> Hi Nat,
>>>=20
>>> Now it is my turn to apologize for taking a long time.
>>>=20
>>> I think I see the general direction these changes are going in, and=20
>>> it's a reasonable approach to the unfortunate situation we find=20
>>> ourselves in with respect to JWT claims vs. OAuth parameters.  In=20
>>> effect, what we're doing is making a "profile" (for lack of a better=20
>>> term) of JWT, that leverages the mechanisms and algorithms of JWT but=20=

>>> uses a different registry for interpreting the claims in the token=20
>>> (that is, OAuth Parameters vs. JWT Claims).  We can tell that this=20
>>> "profile" of JWT is being used because of the context in which the JWT i=
s transferred/received: if it's the "request"
>>> parameter, that's part of the definition of the OAuth Parameter, and=20
>>> if it's the result of dereferencing a "request_uri", the=20
>>> application/oauth.authz.req+jwt media-type clearly indicates how the=20
>>> contents should be interpreted.
>>>=20
>>> However, the changes in the -20 do not give the reader much of any=20
>>> hint as to this being what's expected to happen, and that stock RFC=20
>>> 7519 JWT is
>>> *not* what's in use.  So I'd request that we take a close look at how=20=

>>> the document uses "JWT" vs. "JWT encoding" (etc.); add an explicit=20
>>> statement that while the JWT encoding is in use, the contents are to=20
>>> be interpreted by interpreting the JWT claims as OAuth Parameters=20
>>> (and not as per the IANA registry of JWT claims); and add some=20
>>> discussion (similar to the above) about how the application context=20
>>> makes it unambiguous whether the JWT-encoded claims are standard JWT=20
>>> claims or OAuth Parmaters as per this document.
>>>=20
>>> With respect to my second ("discuss discuss") point, Nat and I did=20
>>> have a discussion in-person and I accept that there may be some=20
>>> scenarios in which skipping the authorization dialogue is=20
>>> appropriate, so the example can remain.
>>>=20
>>>=20
>>> Moving on from my Discuss position, I do get the sense from the=20
>>> ongoing discussion on the list that there's not clear agreement about=20=

>>> the current formulation that requires all parameters (but "request"=20
>>> and "request_uri") to be in the JAR, especially with respect to=20
>>> "client_id" that might be needed to unpack the JAR in some cases!  So=20=

>>> I'm not sure whether the WG wants to bring the document back to the=20
>>> WG to iron out those issues before it returns to the IESG.  I'm a=20
>>> little reluctant to switch my position to "No Objection" until we=20
>>> have a clearer picture of what the WG wants to do on this front -- in=20=

>>> my understanding, we can't really publish the document without at=20
>>> least some solution ("client_id") for the encrypted-request key-lookup c=
ase.
>>>=20
>>> Thanks,
>>>=20
>>> Ben
>>>=20
>>>=20
>>> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
>>>> Hi
>>>>=20
>>>> Took a long time but finally all the changes needed to resolve the
>>> DISCUSS
>>>> comments are (hopefully) applied as -20.
>>>>=20
>>>> There is one change that impacts the process: the draft now has IANA=20=

>>>> request so it needs to be referred back to IANA.
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>>=20
>>>> Best,
>>>>=20
>>>> Nat Sakimura
>>>>=20
>>>> 2019=E5=B9=B47=E6=9C=883=E6=97=A5(=E6=B0=B4) 4:21 Benjamin Kaduk via Da=
tatracker :
>>>>=20
>>>>> Benjamin Kaduk has entered the following ballot position for
>>>>> draft-ietf-oauth-jwsreq-19: Discuss
>>>>>=20
>>>>> When responding, please keep the subject line intact and reply to=20
>>>>> all email addresses included in the To and CC lines. (Feel free to=20
>>>>> cut this introductory paragraph, however.)
>>>>>=20
>>>>>=20
>>>>> Please refer to
>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>>> .ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=3D02%7C01
>>> %7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7
>>> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sd
>>> ata=3D6ZSWckU9w8S1oDEUz%2BgKPguV2UFjyfzKrOIt9V4qXRQ%3D&reserved=3D0
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>=20
>>>>>=20
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fd
>>>>> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-jwsreq%2F&data=3D02%
>>>>> 7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a659
>>>>> 6612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63716077521867674
>>>>> 0&sdata=3DeaeSN%2BgKTCDiy502GPNm459JjYuOj5o77Tp%2B6QAw3HY%3D&
>>>>> reserved=3D0
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> DISCUSS:
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>>=20
>>>>> This is a "discuss discuss" -- it's an important question and I'd=20
>>>>> like to talk about it, but it's not clear that any change to the=20
>>>>> document will be needed.
>>>>>=20
>>>>> Once this (and some of the more substantive items in the Comment
>>>>> section) is resolved, I'd be happy to ballot Yes.
>>>>>=20
>>>>> The introduction notes as an advantage of JWT that:
>>>>>=20
>>>>>   (d)  (collection minimization) The request can be signed by a third
>>>>>        party attesting that the authorization request is compliant
>>> with
>>>>>        a certain policy.  For example, a request can be=20
>>>>> pre-examined
>>> by
>>>>>        a third party that all the personal data requested is strictly
>>>>>        necessary to perform the process that the end-user asked for,
>>>>>        and statically signed by that third party.  The authorization
>>>>>        server then examines the signature and shows the conformance
>>>>>        status to the end-user, who would have some assurance as to the=

>>>>>        legitimacy of the request when authorizing it.  In some cases,
>>>>>        it may even be desirable to skip the authorization dialogue
>>>>>        under such circumstances.
>>>>>=20
>>>>> I'm pretty uncomfortable about suggesting that the authorization=20
>>>>> dialogue can/should be skipped; do we need to keep this example?
>>>>> Maybe just talking about what an expected use case could be would=20
>>>>> help alleviate my unease.
>>>>>=20
>>>>>=20
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>> COMMENT:
>>>>> -------------------------------------------------------------------
>>>>> ---
>>>>>=20
>>>>> Section 1
>>>>>=20
>>>>>   While it is easy to implement, the encoding in the URI does not
>>> allow
>>>>>   application layer security with confidentiality and integrity
>>>>>   protection to be used.  While TLS is used to offer communication
>>>>>=20
>>>>> nit: this wording is a little hard to read; it might be easier to=20
>>>>> reorder to "does not allow application layer security to be used to=20=

>>>>> provide confidentiality and integrity protection".
>>>>>=20
>>>>>   The use of application layer security allows requests to be prepared=

>>>>>   by a third party so that a client application cannot request more
>>>>>   permissions than previously agreed.  This offers an additional
>>> degree
>>>>>   of privacy protection.
>>>>>=20
>>>>> (side note) what would an example of such a third party be.  (We
>>> already
>>>>> have the resource owner, the client, and the authorization server ...
>>>>> maybe it's a fourth party?)
>>>>>=20
>>>>>   Furthermore, the request by reference allows the reduction of over-
>>>>>   the-wire overhead.
>>>>>=20
>>>>> We only barely mentioned by-reference at this point (one line in=20
>>>>> the Abstract), so I'd suggest "passing the request by reference".
>>>>>=20
>>>>>   (4)  its development status that it is an RFC and so is its
>>>>>        associated signing and encryption methods as [RFC7515] and
>>>>>        [RFC7516]
>>>>>=20
>>>>> nit: I'd suggest "its development status as a Proposed Standard,=20
>>>>> along with the associated signing and encryption methods [RFC7515]
>>> [RFC7516]."
>>>>>   (c)  (confidentiality protection) The request can be encrypted so
>>>>>        that end-to-end confidentiality can be provided even if the TLS=

>>>>>        connection is terminated at one point or another.
>>>>>=20
>>>>> nit: TLS is always terminated at or before the user-agent, though. =20=

>>>>> So maybe the user agent needs to get called out here as well (there=20=

>>>>> could of course be TLS termination earlier than the user-agent in=20
>>>>> some cases, too).
>>>>>=20
>>>>>   2.  When the client does not want to do the crypto.  The
>>>>>       Authorization Server may provide an endpoint to accept the
>>>>>       Authorization Request through direct communication with the
>>>>>       Client so that the Client is authenticated and the channel=20
>>>>> is
>>> TLS
>>>>>       protected.
>>>>>=20
>>>>> How can you "not want to do [the] crypto" but still be doing TLS=20
>>>>> (with crypto)?  Perhaps we're looking for "not want to pay the=20
>>>>> additional overhead of JWS/JWE cryptography on top of TLS"?
>>>>>=20
>>>>> Section 1.1
>>>>>=20
>>>>> RFC 8174 has updated BCP 14 boilerplate text to use.
>>>>>=20
>>>>> Section 3
>>>>>=20
>>>>> nit: should this section be 2.3 to get wrapped into "terminology"?
>>>>>=20
>>>>> It might also be worth putting references in for the terms, though=20
>>>>> they are largely common knowledge at this point.
>>>>>=20
>>>>> Section 4
>>>>>=20
>>>>>   A Request Object (Section 2.1) is used to provide authorization
>>>>>   request parameters for an OAuth 2.0 authorization request.  It MUST
>>>>>   contains all the OAuth 2.0 [RFC6749] authorization request
>>> parameters
>>>>>   including extension parameters.  The parameters are represented=20
>>>>> as
>>>>>=20
>>>>> nit: "all the parameters" kind of sounds like "all that are defined".
>>>>> But I think the intent here is "any parameter used to process the=20
>>>>> request must come from the request object and URL query parameters=20
>>>>> are ignored", so maybe "MUST contain all the parameters (including
>>> extension
>>>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization=20
>>>>> request; parameters from other sources MUST NOT be used", akin to=20
>>>>> what we say down in Sections 5 and 6.3.
>>>>> But we need to be careful about the wording to not exclude the=20
>>>>> usage of the "request" and "request_uri" query parameters to  find=20
>>>>> the Request Object!
>>>>>=20
>>>>>   the JWT claims.  Parameter names and string values MUST be=20
>>>>> included
>>>>>=20
>>>>> nit: maybe "the JWT claims of the object"?
>>>>>=20
>>>>>   any extension parameters.  This JSON [RFC7159] constitutes the JWT
>>>>>   Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>>>>>   signed or signed and encrypted.
>>>>>=20
>>>>> nit: I  think we want "This JSON [RFC7159] object".
>>>>>=20
>>>>> (Long quote incoming)
>>>>>=20
>>>>>   The following is an example of the Claims in a Request Object before=

>>>>>   base64url encoding and signing.  Note that it includes extension
>>>>>   variables such as "nonce" and "max_age".
>>>>>=20
>>>>>     {
>>>>>      "iss": "s6BhdRkqt3",
>>>>>      "aud": "https://nam06.safelinks.protection.outlook.com/?url=3Dhtt=
ps%3A%2F%2Fserver.example.com&data=3D02%7C01%7CMichael.Jones%40microsoft=
.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7=
C1%7C0%7C637160775218676740&sdata=3DL2bwEdfW4tbnTI5FSJTCC%2BkI3EA6CqNNqZ=
5FzT0JnRs%3D&reserved=3D0",
>>>>>      "response_type": "code id_token",
>>>>>      "client_id": "s6BhdRkqt3",
>>>>>      "redirect_uri": "https://nam06.safelinks.protection.outlook.com/?=
url=3Dhttps%3A%2F%2Fclient.example.org%2Fcb&data=3D02%7C01%7CMichael.Jon=
es%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab=
2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=3DXBvLTF0JuNuz7I3c7pBel0=
GNSN0lcYqvoHCNagAwrSU%3D&reserved=3D0",
>>>>>      "scope": "openid",
>>>>>      "state": "af0ifjsldkj",
>>>>>      "nonce": "n-0S6_WzA2Mj",
>>>>>      "max_age": 86400
>>>>>     }
>>>>>=20
>>>>>   Signing it with the "RS256" algorithm results in this Request Object=

>>>>>   value (with line wraps within values for display purposes only):
>>>>>=20
>>>>>     eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3=

>>>>>     F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl=

>>>>>     c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk=

>>>>>     JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w=

>>>>>     bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW=

>>>>>     Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog=

>>>>>     ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ=

>>>>>     ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p=

>>>>>     Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS=

>>>>>     wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg=

>>>>>     ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH=

>>>>>     sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu=

>>>>>     dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm=

>>>>>     luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs=

>>>>>     F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>>>>>     KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx=

>>>>>     0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K=

>>>>>     ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG=

>>>>>     iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>>>>>=20
>>>>> Decoding the base64 of the body, we see:
>>>>> {
>>>>> "iss": "s6BhdRkqt3",
>>>>> "aud":=20
>>>>> "https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F
>>>>> server.example.com&data=3D02%7C01%7CMichael.Jones%40microsoft.com
>>>>> %7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d
>>>>> b47%7C1%7C0%7C637160775218676740&sdata=3DL2bwEdfW4tbnTI5FSJTCC%2B
>>>>> kI3EA6CqNNqZ5FzT0JnRs%3D&reserved=3D0",
>>>>> "response_type": "code id_token",
>>>>> "client_id": "s6BhdRkqt3",
>>>>> "redirect_uri":=20
>>>>> "https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F
>>>>> client.example.org%2Fcb&data=3D02%7C01%7CMichael.Jones%40microsof
>>>>> t.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7c
>>>>> d011db47%7C1%7C0%7C637160775218676740&sdata=3DXBvLTF0JuNuz7I3c7pB
>>>>> el0GNSN0lcYqvoHCNagAwrSU%3D&reserved=3D0",
>>>>> "scope": "openid",
>>>>> "state": "af0ifjsldkj",
>>>>> "nonce": "n-0S6_WzA2Mj",
>>>>> "max_age": 86400,
>>>>> "claims":
>>>>>  {
>>>>>   "userinfo":
>>>>>    {
>>>>>     "given_name": {"essential": true},
>>>>>     "nickname": null,
>>>>>     "email": {"essential": true},
>>>>>     "email_verified": {"essential": true},
>>>>>     "picture": null
>>>>>    },
>>>>>   "id_token":
>>>>>    {
>>>>>     "gender": null,
>>>>>     "birthdate": {"essential": true},
>>>>>     "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>>>>>    }
>>>>>  }
>>>>> }
>>>>>=20
>>>>> I'm not sure where the "claims" claim is coming from -- 6749=20
>>>>> doesn't seem to talk about it.  (Note that this example is used=20
>>>>> later on as
>>>>> well.)
>>>>>=20
>>>>> Section 5.2.1
>>>>>=20
>>>>>   It is possible for the Request Object to include values that are to
>>>>>   be revealed only to the Authorization Server.  As such, the
>>>>>   "request_uri" MUST have appropriate entropy for its lifetime.  For
>>>>>   the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
>>>>>   that it be removed after a reasonable timeout unless access control
>>>>>   measures are taken.
>>>>>=20
>>>>> It sounds like a link to=20
>>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww=
w.w3.org%2FTR%2Fcapability-urls%2F&data=3D02%7C01%7CMichael.Jones%40micr=
osoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d=
b47%7C1%7C0%7C637160775218676740&sdata=3DQtofXDXbUc2U2ieJYh0wFHXGivLFuU6=
4GhsxCW9pD9M%3D&reserved=3D0 might also be useful.
>>>>>=20
>>>>> Section 5.2.2
>>>>>=20
>>>>> Do we want to remind the reader that the other query parameters are
>>> just
>>>>> for backwards compatibility?
>>>>>=20
>>>>> Section 5.2.3
>>>>>=20
>>>>>   The following is an example of this fetch process:
>>>>>=20
>>>>>     GET /request.jwt HTTP/1.1
>>>>>     Host: tfp.example.org
>>>>>=20
>>>>> It's useful to show good hygeine in examples; can we get the extra=20
>>>>> entropy in this request that we have in the previous example(s)?
>>>>>=20
>>>>> Section 6.2
>>>>>=20
>>>>>   The Authorization Server MUST perform the signature validation=20
>>>>> of
>>> the
>>>>>   JSON Web Signature [RFC7515] signed request object.  For this, the
>>>>>   "alg" Header Parameter in its JOSE Header MUST match the value=20
>>>>> of
>>> the
>>>>>   pre-registered algorithm.  The signature MUST be validated against
>>>>>   the appropriate key for that "client_id" and algorithm.
>>>>>=20
>>>>> Does "the pre-registered algorithm" concept exist in the specs=20
>>>>> outside of draft-ietf-oauth-jwt-bcp?
>>>>>=20
>>>>> Section 9
>>>>>=20
>>>>> The error codes we list in Section 7 are already registered, for the
>>>>> OIDC usage.  Do we want to say anything about that?   (I guess it woul=
d
>>>>> be disallowed by process to try to update the existing registration=20=

>>>>> to also point at this document.)
>>>>>=20
>>>>> Section 10
>>>>>=20
>>>>> We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>>>>=20
>>>>> Section 10.1
>>>>>=20
>>>>>   When sending the authorization request object through "request"
>>>>>   parameter, it MUST either be signed using JWS [RFC7515] or encrypted=

>>>>>   using JWE [RFC7516] with then considered appropriate algorithm.
>>>>>=20
>>>>> Up in Section 5 we only allow (a) signed and (b) signed then=20
>>>>> encrypted; similarly, in Section 4 we reiterate "signed then=20
>>>>> encrypted".  Why is
>>> it
>>>>> okay to talk about just "signed or encrypted" here?
>>>>>=20
>>>>> Section 10.2
>>>>>=20
>>>>>   (b)  Verifying that the symmetric key for the JWE encryption is the
>>>>>        correct one if the JWE is using symmetric encryption.
>>>>>=20
>>>>> Similarly to the previous point, you also need to check the=20
>>>>> signature, which will always be there.
>>>>>=20
>>>>>   (d)  Authorization Server is providing an endpoint that provides a
>>>>>        Request Object URI in exchange for a Request Object.  In=20
>>>>> this
>>>>>=20
>>>>> I don't think this is a complete sentence (and it's definitely not=20
>>>>> a parallel construction with (a)-(c)!).  I think perhaps a crisp=20
>>>>> one-line summary of this method would be "Delegating the=20
>>>>> authorization check to
>>> a
>>>>> separate "Request Object to Request Object URI" endpoint on the=20
>>>>> Authorization Server".  (The writing in the rest of this paragraph
>>> could
>>>>> also use an editing pass.)
>>>>>=20
>>>>>   (e)  A third party, such as a Trust Framework Provider, provides an
>>>>>        endpoint that provides a Request Object URI in exchange for a
>>>>>        Request Object.  The same requirements as (b) above apply.  In
>>>>>        addition, the Authorization Server MUST know out-of-band that
>>>>>        the Client utilizes the Trust Framework Operator.
>>>>>=20
>>>>> The Authorization Server also has to trust the third-party provider=20=

>>>>> to actually do its job and not misbehave, right?
>>>>>=20
>>>>> Section 10.3
>>>>>=20
>>>>> I'm not entirely sure what "[t]he endpoints ithat come into=20
>>>>> question in this specification" is supposed to mean -- is it just=20
>>>>> "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"?
>>>>>=20
>>>>>   In [RFC6749], while Redirection URI is included, others are not
>>>>>   included in the Authorization Request.  As the result, the same
>>>>>   applies to Authorization Request Object.
>>>>>=20
>>>>> nit: included in what?
>>>>>=20
>>>>> Section 10.4
>>>>>=20
>>>>> It's probably also worth citing the generic URI security=20
>>>>> considerations from RFC 3986, here.
>>>>>=20
>>>>> Section 10.4.1
>>>>>=20
>>>>>   "request_uri", and (d) do not perform recursive GET on the
>>>>>   "request_uri".
>>>>>=20
>>>>> nit: remove the "do" in order to make the construction parallel.
>>>>>=20
>>>>> Section 12.1
>>>>>=20
>>>>>   It is often hard for the user to find out if the personal data asked=

>>>>>   for is strictly necessary.  A Trust Framework Provider can help the
>>>>>   user by examining the Client request and comparing to the proposed
>>>>>   processing by the Client and certifying the request.  After the
>>>>>   certification, the Client, when making an Authorization Request, can=

>>>>>   submit Authorization Request to the Trust Framework Provider to
>>>>>   obtain the Request Object URI.
>>>>>=20
>>>>> side note: In my head the act of certification was the act of=20
>>>>> making
>>> the
>>>>> translation to a Request Object URI, so I'm kind of curious where=20
>>>>> my vision differs from reality.
>>>>>=20
>>>>> The third paragraph seems to mostly just be describing the=20
>>>>> procedure of how this flow works, which would not necessarily be=20
>>>>> specific to the privacy considerations section.
>>>>>=20
>>>>> Section 12.2.2
>>>>>=20
>>>>>   Even if the protected resource does not include a personally
>>>>>   identifiable information, it is sometimes possible to identify the
>>>>>   user through the Request Object URI if persistent per-user Request
>>>>>   Object URI is used.  A third party may observe it through=20
>>>>> browser
>>>>>=20
>>>>> nit: need an article for "persistent per-user Request Object URI"=20
>>>>> (or make it plural, as "URIs are used").
>>>>>=20
>>>>>   Therefore, per-user Request Object URI should be avoided.
>>>>>=20
>>>>> nit: I think this is better as "static per-user Requeste Object URIs"
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40mic=
rosoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011=
db47%7C1%7C0%7C637160775218676740&sdata=3D55Hdt6W1uELCC%2BhFrFvOcPDN%2F5=
zpcSNQmJFogxAoi9g%3D&reserved=3D0
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


On 16 Jan 2020, at 16:44, Filip Skokan <panva.ip@gmail.com> =
wrote:

A 30x redirect to what is =
designed to be an authenticated backend client call? Doesn't seem right =
to me.

S =
pozdravem,
Filip Skokan


On Thu, 16 Jan 2020 at 17:37, Neil =
Madden <neil.madden@forgerock.com> wrote:
Why not have the PAR endpoint return a 30x =
redirect with the full URL to the authorization endpoint in the Location =
header? That way the AS can decide for itself how to communicate any id =
from the PAR endpoint to the authorization endpoint.

This also has the side effect that you =
can kick off an OAuth2 flow with a simple HTML form pointed at the PAR =
endpoint (with hidden fields for state/code_challenge etc).

If actually performing =
the redirect is a bit problematic then at least the idea of returning a =
full URL for the authorization endpoint (hyperlink) rather than =
returning an id/URI and requiring the client to construct one seems =
reasonable to me and would seem to avoid some of the difficulties being =
discussed with JAR etc as the exact mechanism of communication becomes =
an implementation detail that the client needn't know about.

-- Neil



On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> =
wrote:

I just thought about another =
option. What if we change PAR to not use the request_uri parameter but a =
new parameter, e.g. request_id?

That would decouple both =
specs. The reason why we use request_uri was to make the life of clients =
easier since they can use the standard library function for request =
objects to pass the PAR reference to the AS. Is this worth the =
trouble?

Am 16.01.2020 um 16:48 schrieb Justin Richer =
<jricher@mit.edu>:

=EF=BB=BF+1 to this approach, and it sounds like =
JAR might need to come back to go through another round anyway thanks to =
the breaking changes the IESG pushed into it after it left WGLC.

I=E2=80=99d rather see =
us get this right than publish something many of us think is =
broken. 

Maybe PAR and JAR (and JARM?) end up going out as a bundle of =
specs.

 =E2=
=80=94 Justin

On Jan 15, 2020, at 8:30 PM, =
Richard Backman, Annabelle <richanna@amazon.com> wrote:

The =
problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
 
My =
preference remains the former. It strikes me as bad form for one =
extension to override normative requirements laid out in another =
document. Granted, the incompatibility scenarios introduced by this =
retcon are edge-case at best, but that just raises the question of why =
we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been =
published yet.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Vladimir =
Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id =
Ltd..
Date: Wednesday, January 15, 2020 at 12:34 PM
To: Justin =
Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] =
[UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
 
On =
13/01/2020 19:32, Justin Richer wrote:
To be =
clear, I=E2=80=99m not saying we suggest a particular form, and I agree =
that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a JWT=E2=80=9D=
 or something of that nature. But if we call the result of PAR =E2=80=9Cth=
ing X=E2=80=9D and the target of request_uri =E2=80=9Cthing X=E2=80=9D =
in JAR, then we=E2=80=99re compatible without saying what =E2=80=9Cthing =
X=E2=80=9D needs to be in all cases. 
Good, =
we're on the same page then.
How about simply saying that the result of PAR is an URI =
referencing the pushed authZ request; at the authZ endpoint its =
processing is completed.
No need is both clear and abstract enough to not require a =
form to be specified.
 
In =
cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D =
to be formatted as a JWT.
But why?
Both PAR and =
authZ endpoints belong to the AS, which makes that impl specific. The =
URI is the contract, between client and AS.
The AS, if uService based, could =
choose to implement that as CBOR Web Token, or some other verifiable =
blob, resulting in the same essential function, and this isn't affecting =
the client <-> AS contract in any way.
 
We =
had a case of similarly unintentional limiting in JAR previously, saying =
that you had to do an HTTP lookup on the request_uri, but I believe =
that=E2=80=99s been backed off now and made conditional.
That was precisely my point.
Vladimir
 
 
 =E2=80=94 Justin


On =
Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
 
My =
suggestion is to abstain from specifying the concrete form of the =
resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
In =
the Connect2id implementation of PAR the returned URI doesn't point to a =
request object and it doesn't point to a JWT either. It points to an =
internally stored "pre-processed" authZ request, which the authZ =
endpoint then picks up to complete the authZ.
Even =
if we eventually end up in microservice world, or allow the PAR endpoint =
to be managed by some external entity, the PAR URI - its interpretation, =
validation and potentially resource retrieval (JWT or other blob), is an =
"internal contract" on the AS side. This doesn't concern the client, and =
in OAuth 2.0 the role of AS is indivisible.
 
I =
see PAR request + authZ request as one logical OAuth 2.0 authZ request: =
the client submits an authZ request and gets an authZ response at the =
end. The URI is necessary for the client to proceed from the 1st to the =
2nd step. If we manage to frame / word the PAR URI in this logical way, =
without getting stuck in the JAR definition / framing of what the =
request_uri / object is, it would be great.
 
The=
 normative language I think should focus on maintaining the OAuth 2.0 =
contract for the entire logical authZ request, together with the basic =
contracts of 1) JAR and the 2) authZ endpoint.
 
Vladimir
 
On =
10/01/2020 22:55, Justin Richer wrote:
So we =
could solve this by saying the resulting data object of a PAR is a =
request object. Which might also contain a request object internally as =
well. In that case JAR should back off from saying it=E2=80=99s a JWT =
and instead say it=E2=80=99s a request object. Or we define a new term =
for this authorization request blob thing. 
 
Or =
PAR could at least say that if it=E2=80=99s dereferenced over a remote =
protocol then it MUST be a JWT, but otherwise it can be whatever you =
want. That=E2=80=99s where the real interop concerns come in.
 
 =E2=80=94 Justin


On =
Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
Correct. The problem becomes pretty clear in the context of =
PAR, where the AS is generating and vending out the URI at the PAR =
endpoint, and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, =
2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt =
<torsten@lodderstedt.net>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] =
Re: [OAUTH-WG] PAR: pushed requests must become JWTs
 
If we assume the client posts a JAR and gets =
back a reference.  Then the reference is to a JAR. 
 
I =
think I see the problem.  If the server providing the reference is =
associated with the AS then the server dosen't need to dereference the =
object via HTTP, so it could be a URN as an example. 
 
So =
yes it is not a interoperability issue for the client.  
 
I will think about how I can finesse that. 
 
I =
agree it is not a change in intent. 
 
I =
will see if I can get our AD to accept that.
 
John =
B. 
 
 
 
 
On =
Fri, Jan 10, 2020, 4:57 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Sure =
but the text proposed (or something like it) qualifies it such that =
there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
 
On =
Fri, Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It =
may be a challenge to change text saying that the contents of the =
resource could be something other than a request object. 
 
If =
not a request object then what and how is that interoperable are likely =
AD questions. 
 
I =
could perhaps see changing it to must be a request object, or other =
format defined by a profile.

John =
B.  
 
 
On =
Fri, Jan 10, 2020, 3:45 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree =
and agree. But given that the change suggested by Annabelle has no =
impact on the client or interoperability, perhaps Nat or John could work =
the change into the draft during the edits that happen during the final =
stages of things?
 
On =
Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I =
would assume given the status of JAR, we don=E2=80=99t want to change =
it. And as I said, this difference does not impact interoperability from =
client perspective.



Am 09.01.2020 um =
00:58 schrieb Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:
It would be =
more appropriate to add the text to JAR rather than PAR. It doesn't seem =
right for PAR to retcon rules in JAR. Moving the text to JAR also =
highlights the weirdness of giving PAR special treatment.
 
What if we =
changed this sentence in Section 5.2 of JAR:
The=
 contents of the resource referenced by the URI MUST be a =
Request
Object.
 
To: 
The=
 contents of the resource referenced by the URI MUST be a =
Request
Object, unless the URI was provided to the client by the =
Authorization
Server.
 
This would =
allow for use cases such as an AS that provides pre-defined request =
URIs, or vends request URIs via a client management console, or bakes =
them into their client apps.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 
    Hi, 
    
    you are right, PAR does not require =
the AS to represent the request as a JWT-based request object. The URI =
is used as internal reference only. That why the draft states
    
    "There is no need to make the
          =
authorization request data available to other parties via this
          =
URI.=E2=80=9D
    
    This difference matters from an AS =
implementation perspective, it doesn't matter from a client's (interop) =
perspective.
    
    We may add a statement to PAR saying =
that request_uris issued by the PAR mechanism (MAY) deviate from the JAR =
definition.
    
    best regards,
    Torsten.  
    
    > On 8. Jan 2020, at 23:42, =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
    > 
    > Hi all,
    >  
    > The current drafts of PAR (-00) =
and JAR (-20) require that the AS transform all pushed requests into =
JWTs. This requirement arises from the following:
    > =
        =E2=80=A2 PAR uses the =
request_uri parameter defined in JAR to communicate the pushed request =
to the authorization endpoint.
    > =
        =E2=80=A2 According to JAR, =
the resource referenced by request_uri MUST be a Request Object. =
(Section 5.2)
    > =
        =E2=80=A2 Request Object is =
defined to be a JWT containing all the authorization request parameters. =
(Section 2.1)
    >  
    > There is no need for this =
requirement to support interoperability, as this is internal to the AS. =
It is also inconsistent with the rest of JAR, which avoids attempting to =
define the internal communications between the two AS endpoints. Worse, =
this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the =
state or outcome of that work must be forced into the JWT format (or =
retrieved via a subsequent service call or database lookup).
    >  
    > =E2=80=93 
    > Annabelle Richard Backman
    > AWS Identity
    >  
    > =
_______________________________________________
    > OAuth mailing list
    > OAuth@ietf..org
    
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


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

Vladimir Dzhuvinov
 
--=
 
Vladimir Dzhuvinov

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Well, embedding a client_id claim in the JWE header in order to achieve "request parameters outs=
ide the request object should not be referred to" is like "puttin=
g the cart before the horse". Why do we have to avoid using the tradit=
ional client_id request parameter so stubbo=
rnly?

The last paragraph of Section 3.2.1 of RFC 6749 says as fol=
lows.

A client MAY use the "client_id" request paramete=
r to identify itself when sending requests to the token endpoint.=C2=A0 In =
the "authorization_code" "grant_type" request to the to=
ken endpoint, an unauthenticated client MUST send its "client_id&qu=
ot; to prevent itself from inadvertently accepting a code intended for a cl=
ient with a different "client_id". =C2=A0This protects the cl=
ient from substitution of the authentication code. =C2=A0(It provides no ad=
ditional security for the protected resource.)
<=
div>
If the same reasoning applies, a client_id must always be sent with reques=
t / request_uri because client authe=
ntication is not performed at the authorization endpoint. In other words, <=
b>an unauthenticated client (every client is unauthenticated at the auth=
orization endpoint) MUST send its "client_id" to prevent itself f=
rom inadvertently accepting a request object for a client with a different =
"client_id".


=E2=80=94 Neil

On 16 Jan 2020, at 08:15, Dominick Baier <dbaier@leastprivilege.co=
m> wrote:

=EF=BB=BF





Hi all, 


 


as part of the standards work on OAuth we have creat=
ed several registries, see

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml. Adding and modifying entries in that registry often requires expert revi=
ewers to verify changes.



 


We need volunteers to become expert reviewers for th=
e different registries.



 


Please drop us an email if you are interested. =



 


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. IMPORTANT NOTIC=
E: The contents of this email and any attachments are confidential and may =
also be privileged. If you are not the intended recipient, please notify th=
e sender immediately and do not
 disclose the contents to any other person, use it for any purpose, or stor=
e or copy the information in any medium. Thank you.



--_000_AM6PR08MB4423D231813E22BD390FE49AFA360AM6PR08MB4423eurp_--


From nobody Thu Jan 16 05:40: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 CBEC3120026 for ; Thu, 16 Jan 2020 05:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3lhvFeGUFGw for ; Thu, 16 Jan 2020 05:40:43 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDD0120018 for ; Thu, 16 Jan 2020 05:40:43 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id k6so19084364qki.5 for ; Thu, 16 Jan 2020 05:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=y+68h/NwTMXzy82CLd2y9PuQRS3FH7dQvjswQbEIKVw=; b=eXhQdXlswDyxxDQrW17os2sr83F5lmcWiu9rOc5FGtPLW0+xvLr4xJHmoww9Fddl98 lWPa4XEEL4k/ScIktyw0RzkBF7wZ+hyNV/twZx8zn0W87YxPZhuB3Q8/ZO3Eui1zF6za GnzBE2mA9wbTBmsk8/RBppnd3KnzGTs4TakykM0MDbwgNMYFMEIKxHiUiARJcCq9l5vv /vSJhMN2jikoUBXzq1ByoNXfQ9DNOReEJgzeo/BP6grOt3QOTyLPNH14tFESqtTzQ8hw sDRg9DWCIRWcp/kRwSrvjqFZ0caXy5Ls/sZ+DV6GlunwdzyaOA3WzSW1mKyTctxEAw+Q GtWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=y+68h/NwTMXzy82CLd2y9PuQRS3FH7dQvjswQbEIKVw=; b=jrXpn4MbhiTNftFAavvwJGC1gqhCpVBA+TfbM8nJEbiUe64eWxiW5bATLB4oVQaFt6 G8bsXToUtaddXcUS1xue9OG4zDsK/jgODboruDr/viW2nnV4Qb3PKJOYamuS4Pcxp+NF stv5ve2tJIu9m6Xy4oXkeFPaU4eXIexiJkoYqphf9b0dcmSNWnzDS33Y2N11FTB3hmWd upanvCqfxFvvCH7EMy7c+A28KTT6QKo3EqibqdPv1+ZmnDHAG+o1uXO/x92GKQfBia2y buF6kwnWOYPzrXuim6ZrwVkLqDihWNYP19Hbw3YNvXaxbZLIbfyFZFoINY3CkVgviw3J GKvw==
X-Gm-Message-State: APjAAAXmsXw5PVSibsUdJ8AbUMWnvZXn6e/g/VFFOZKSEiJP8oo2KGn1 zDvAlLmFiPbEv+rPczlyBY4hWr5Pv2D+71MC
X-Google-Smtp-Source: APXvYqw+uchUiIG+DxudSCEyOprFzMd2JNMjE0PAKhQkrtN8Q8U3jwr+yEjYEITRfjTY9wVmS9DE/A==
X-Received: by 2002:a05:620a:1509:: with SMTP id i9mr26641769qkk.447.1579182041383;  Thu, 16 Jan 2020 05:40:41 -0800 (PST)
Received: from [192.168.8.104] ([181.203.98.179]) by smtp.gmail.com with ESMTPSA id k9sm11209735qtq.75.2020.01.16.05.40.39 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 05:40:40 -0800 (PST)
To: oauth@ietf.org
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu>
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Thu, 16 Jan 2020 10:40:39 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <20200116045302.GG80030@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 13:40:49 -0000

I agree with the IESG reasoning that merging is problimatic.=C2=A0 Once w=
e
allow that given a unknown list of possible paramaters with diffrent
security properties it would be quite difficult to specify safely.

Query paramaters can still be sent outside the JAR, but if they are in
the OAuth registry the AS MUST ignore them.

Puting the iss in the JWE headder addresses the encryption issue without
merging.

I understand that some existing servers have dependencys on getting the
clientID as a query paramater.

Is that the only paramater that people have a issue with as oposed to a
nice to have?

Would allowing the AS to not ignore the clientID as a query paramater as
long as it matches the one inside the JAR, basicly the same as Connect
request object but for just the one paramater make life easier for the
servers?

I am not promising a change but gathering info before proposing something=
=2E

John B.


On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>> Well, embedding a client_id claim in the JWE header in order to
>>> achieve "request parameters outside the request object should not be
>>> referred to" is like "putting the cart before the horse". Why do we
>>> have to avoid using the traditional client_id request parameter so
>>> stubbornly?
>>>
>>> The last paragraph of Section 3.2.1
>>>  of RFC 6749 says
>>> as follows.
>>>
>>>     /A client MAY use the "client_id" request parameter to identify
>>>     itself when sending requests to the token endpoint.=C2=A0 In the
>>>     "authorization_code" "grant_type" request to the token endpoint,
>>>     *an unauthenticated client MUST send its "client_id" to prevent
>>>     itself from inadvertently accepting a code intended for a client
>>>     with a different "client_id".* =C2=A0This protects the client fro=
m
>>>     substitution of the authentication code. =C2=A0(It provides no
>>>     additional security for the protected resource.)/
>>>
>>>
>>> If the same reasoning applies, a client_id must always be sent with
>>> request / request_uri because client authentication is not performed
>>> at the authorization endpoint. In other words, */an unauthenticated
>>> client (every client is unauthenticated at the authorization endpoint=
)
>>> MUST send its "client_id" to prevent itself from inadvertently
>>> accepting a request object for a client with a different "client_id".=
/*
>>>
>> Identifying the client in JAR request_uri requests can be really usefu=
l
>> so that an AS which requires request_uri registration to prevent DDoS
>> attacks and other checks can do those without having to index all
>> request_uris individually. I mentioned this before.
>>
>> I really wonder what the reasoning of the IESG reviewers was to insist=

>> on no params outside the JAR JWT / request_uri.
>>
>> I'm beginning to realise this step of the review process isn't
>> particularly transparent to WG members.
> Could you expand on that a bit more?  My understanding is that the IESG=

> ballot mail gets copied to the WG precisely so that there is transparen=
cy,
> e.g., the thread starting at
> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI=

> Which admittely is from almost three years ago, but that's the earliest=

> that I found that could be seen as the source of this behavior.
>
> -Ben
>
> P.S. some other discussion at
> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8=
 and
> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY=
 and
> so on.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jan 16 06:01: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 CC696120018 for ; Thu, 16 Jan 2020 06:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 Am8BsyHEW-Xi for ; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
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 622B212007C for ; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id b6so19293904wrq.0 for ; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/COalwJ6Vj2cYBcASX7/J/u3QuHGRixgyPFq2zuRN5k=; b=O5FCdxf5Ztjlfqe5yIgEXNERz9FImv5KomM4lglU7Mgyz/XSh7lRgUYV9I/oF9n8ZH 9IYblUF3UzbmqCfjuW+6NdLwwEXyLEp6rG5TY8NUT+x2D2FvraDmhV3XrNjHxi8s+S10 w+alScKJQJ5XdXwZbTKrtRAV5VT4bedz81it0=
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=/COalwJ6Vj2cYBcASX7/J/u3QuHGRixgyPFq2zuRN5k=; b=tAzhJNFrRXzEFowgV/P/ZybET0eR6hNcrW2RcNeL3YSmOpD2qiRl8L757f/ONToEMC w8WjY22LmSMwOXJwp0g7QZLJblTL/qslUidbaQBj8nw3Qyzl4Vk0HA9eyHshxDsbeMJn Qi0gj9PQQz3DR1IzQoKuZUBqCqKdY94LH1/3Cp4dtbc7V/u5Y7lgrPXoVOlU/gJBl3S8 2GZ5hubT/+kjxBr/BJilqz+ShQTa2yM6/DDhMqNRZpfKs2SC6lEzXO7fFfpm1ZJJxmQh Z5p8U5Uks+34u0uRN9EnR3hSTYAYzSCjuLktkqKMpjLyfGO5P59FJxN+tIHYL0dSIyhc I2ow==
X-Gm-Message-State: APjAAAWAkyRZJJP49LvauCDjlZKsmOSOLGur88jrw9bnCooy2IwUHK+q Wr1gS4f1vizlcxStz32wLZawNQ4i54w=
X-Google-Smtp-Source: APXvYqzfr4a3Mq0gEYkxGmv4MMmz4hK2umcrITaiF7+AKgZgWgXhCl8ZltESr+KEGRiIjbFpdphyJw==
X-Received: by 2002:adf:fc0c:: with SMTP id i12mr3741456wrr.74.1579183280787;  Thu, 16 Jan 2020 06:01:20 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id y7sm49847wmd.1.2020.01.16.06.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 06:01:20 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden 
In-Reply-To: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Thu, 16 Jan 2020 14:01:18 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E514281-F4A5-48B1-940E-62315F46F6DB@forgerock.com>
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com>    <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>  <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 14:01:28 -0000

I believe just client_id would be sufficient for us, so I'd support a =
compromise position in which that is the only additional query parameter =
allowed.

-- Neil

> On 16 Jan 2020, at 13:40, John Bradley  wrote:
>=20
> I agree with the IESG reasoning that merging is problimatic.  Once we
> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.
>=20
> Query paramaters can still be sent outside the JAR, but if they are in
> the OAuth registry the AS MUST ignore them.
>=20
> Puting the iss in the JWE headder addresses the encryption issue =
without
> merging.
>=20
> I understand that some existing servers have dependencys on getting =
the
> clientID as a query paramater.
>=20
> Is that the only paramater that people have a issue with as oposed to =
a
> nice to have?
>=20
> Would allowing the AS to not ignore the clientID as a query paramater =
as
> long as it matches the one inside the JAR, basicly the same as Connect
> request object but for just the one paramater make life easier for the
> servers?
>=20
> I am not promising a change but gathering info before proposing =
something.
>=20
> John B.
>=20
>=20
> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>> Well, embedding a client_id claim in the JWE header in order to
>>>> achieve "request parameters outside the request object should not =
be
>>>> referred to" is like "putting the cart before the horse". Why do we
>>>> have to avoid using the traditional client_id request parameter so
>>>> stubbornly?
>>>>=20
>>>> The last paragraph of Section 3.2.1
>>>>  of RFC 6749 =
says
>>>> as follows.
>>>>=20
>>>>    /A client MAY use the "client_id" request parameter to identify
>>>>    itself when sending requests to the token endpoint.  In the
>>>>    "authorization_code" "grant_type" request to the token endpoint,
>>>>    *an unauthenticated client MUST send its "client_id" to prevent
>>>>    itself from inadvertently accepting a code intended for a client
>>>>    with a different "client_id".*  This protects the client from
>>>>    substitution of the authentication code.  (It provides no
>>>>    additional security for the protected resource.)/
>>>>=20
>>>>=20
>>>> If the same reasoning applies, a client_id must always be sent with
>>>> request / request_uri because client authentication is not =
performed
>>>> at the authorization endpoint. In other words, */an unauthenticated
>>>> client (every client is unauthenticated at the authorization =
endpoint)
>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>> accepting a request object for a client with a different =
"client_id"./*
>>>>=20
>>> Identifying the client in JAR request_uri requests can be really =
useful
>>> so that an AS which requires request_uri registration to prevent =
DDoS
>>> attacks and other checks can do those without having to index all
>>> request_uris individually. I mentioned this before.
>>>=20
>>> I really wonder what the reasoning of the IESG reviewers was to =
insist
>>> on no params outside the JAR JWT / request_uri.
>>>=20
>>> I'm beginning to realise this step of the review process isn't
>>> particularly transparent to WG members.
>> Could you expand on that a bit more?  My understanding is that the =
IESG
>> ballot mail gets copied to the WG precisely so that there is =
transparency,
>> e.g., the thread starting at
>> =
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>> Which admittely is from almost three years ago, but that's the =
earliest
>> that I found that could be seen as the source of this behavior.
>>=20
>> -Ben
>>=20
>> P.S. some other discussion at
>> =
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 =
and
>> =
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY =
and
>> so on.
>>=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 Jan 16 06:32: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 61C2B12004F for ; Thu, 16 Jan 2020 06:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 oOgExz2JBMZ9 for ; Thu, 16 Jan 2020 06:32:45 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9512A120043 for ; Thu, 16 Jan 2020 06:32:45 -0800 (PST)
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 00GEWXiJ016344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 09:32:36 -0500
Date: Thu, 16 Jan 2020 06:32:33 -0800
From: Benjamin Kaduk 
To: Neil Madden 
Cc: Dominick Baier , IETF oauth WG 
Message-ID: <20200116143233.GJ80030@kduck.mit.edu>
References:  
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] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC 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, 16 Jan 2020 14:32:50 -0000

It is not too late to add to the security considerations.

It seems that the new application/oauth.authz.req+jwt media-type is helpful
in this regard, in that if an AS can require that content-type from
dereferencing the request_uri, then seeing anything else indicates that the
request was bogus (or an attack).  I guess existing OIDC deployments aren't
exactly in a position to do that, though.

-Ben

On Thu, Jan 16, 2020 at 08:34:06AM +0000, Neil Madden wrote:
> Is it too late to add it to the security considerations for JAR? 
> 
> — Neil
> 
> > On 16 Jan 2020, at 08:15, Dominick Baier  wrote:
> > 
> > 
> > Agreed - that’s why we disabled request_uri by default and added extensibility points to implement validation.
> > 
> > I thought it is odd that this was not mentioned in the typical “security considerations” in the OIDC spec..
> > 
> > ———
> > Dominick Baier
> > 
> >> On 16. January 2020 at 08:07:44, Neil Madden (neil.madden@forgerock.com) wrote:
> >> 
> >> If the AS can’t validate the request_uri it may also open itself up to SSRF attacks where a malicious client uses the request_uri to probe/attack resources inside the AS’s private network. This was a crucial part of the recent Capital One breach for example [1].  ForgeRock currently requires strict validation of request_uris against a client-specific whitelist for exactly this reason. 
> >> 
> >> NB some clients might legitimately be on that private network (eg microservices) so changing to a global whitelist for all clients is undesirable. 
> >> 
> >> [1]: https://ejj.io/blog/capital-one
> >> 
> >> — Neil
> >> 
> >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov  wrote:
> >>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> >>>> Well, embedding a client_id claim in the JWE header in order to achieve "request parameters outside the request object should not be referred to" is like "putting the cart before the horse". Why do we have to avoid using the traditional client_id request parameter so stubbornly?
> >>>> 
> >>>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
> >>>> 
> >>>> A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.  In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id".  This protects the client from substitution of the authentication code.  (It provides no additional security for the protected resource.)
> >>>> 
> >>>> If the same reasoning applies, a client_id must always be sent with request / request_uri because client authentication is not performed at the authorization endpoint. In other words, an unauthenticated client (every client is unauthenticated at the authorization endpoint) MUST send its "client_id" to prevent itself from inadvertently accepting a request object for a client with a different "client_id".
> >>>> 
> >>> Identifying the client in JAR request_uri requests can be really useful so that an AS which requires request_uri registration to prevent DDoS attacks and other checks can do those without having to index all request_uris individually. I mentioned this before.
> >>> 
> >>> I really wonder what the reasoning of the IESG reviewers was to insist on no params outside the JAR JWT / request_uri.
> >>> 
> >>> I'm beginning to realise this step of the review process isn't particularly transparent to WG members.
> >>> 
> >>> Vladimir
> >>> 
> >>> 
> >>> 
> >>>> Best Regards,
> >>>> Taka
> >>>> 
> >>>> 
> >>>> 
> >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov  wrote:
> >>>>> John, thanks, much appreciated!
> >>>>> 
> >>>>>> On 11/01/2020 21:36, John Bradley wrote:
> >>>>>> Yes JAR is not prohibiting paramater replication in the header. 
> >>>>>> 
> >>>>>> I will see if i can add something in final edits to call that out.
> >>>>>> 
> >>>>>> John B.
> >>>>>> 
> >>>>>>> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter replication be used for client_id or the client_id ass "iss" even though it isn't explicitly mentioned in the JAR spec?
> >>>>>>> 
> >>>>>>>> On 11/01/2020 02:58, John Bradley wrote:
> >>>>>>>> Right we just don't say to put the iss there in OIDC if it's symetricly encrypted.
> >>>>>>> OIDC doesn't have the symmetric key selection issue, I suppose that why the possibility to replicate params to the JWE header isn't mentioned at all. OIDC requires the top-level query params to represent a valid OAuth 2.0 request, and there client_id is required. If the client_id is present the client registration together with any present client_secret can be retrieved.
> >>>>>>> 
> >>>>>>> I reread the JAR spec, this is the only place that mentions handling of symmetric JWE.
> >>>>>>> 
> >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
> >>>>>>> 
> >>>>>>>> (b)  Verifying that the symmetric key for the JWE encryption is the
> >>>>>>>>         correct one if the JWE is using symmetric encryption.
> >>>>>>> 
> >>>>>>> Vladimir
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  wrote:
> >>>>>>>>> The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>>                                                        -- Mike
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> From: OAuth  On Behalf Of John Bradley
> >>>>>>>>> Sent: Friday, January 10, 2020 2:15 PM
> >>>>>>>>> To: Vladimir Dzhuvinov 
> >>>>>>>>> Cc: IETF oauth WG 
> >>>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> The intent was to do that, but specs change once the OAuth WG and IESG get there hands on them.  
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> Being backwards compatible with OIDC is not a compelling argument to the IESG.
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> We were mostly thinking of asymmetric encryption.  
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> Specifying puting the issuer and or the audience in the headder has come up in the past but probably is not documented.  
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> John B 
> >>>>>>>>> 
> >>>>>>>>>  
> >>>>>>>>> 
> >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov  wrote:
> >>>>>>>>> 
> >>>>>>>>> Yes, putting the client_id into the JWE header is a way around the need
> >>>>>>>>> to have the client_id outside the JWE as top-level authZ request parameter.
> >>>>>>>>> 
> >>>>>>>>> Unfortunately this work around isn't mentioned anywhere, I just checked
> >>>>>>>>> the most recent draft-ietf-oauth-jwsreq-20.
> >>>>>>>>> 
> >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies on the
> >>>>>>>>> presence of client_id as top-level parameter, together with requiring
> >>>>>>>>> RPs to register their request_uri's (so that we don't need to build and
> >>>>>>>>> store an index of all request_uri's). I just had a look at "DDoS Attack
> >>>>>>>>> on the Authorization Server" and also realised the request_uri
> >>>>>>>>> registration isn't explicitly mentioned as attack prevention ("the
> >>>>>>>>> server should (a) check that the value of "request_uri" parameter does
> >>>>>>>>> not point to an unexpected location").
> >>>>>>>>> 
> >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> >>>>>>>>> 
> >>>>>>>>> To be honest, I feel quite bad about the situation with JAR we are in
> >>>>>>>>> now. For some reason I had the impression that OAuth JAR was going to be
> >>>>>>>>> the OIDC request / request_uri for general OAuth 2.0 use, as with other
> >>>>>>>>> OIDC bits that later became general purpose OAuth 2.0 specs.
> >>>>>>>>> 
> >>>>>>>>> I find it unfortunate I didn't notice this when I was reviewing the spec
> >>>>>>>>> in the past.
> >>>>>>>>> 
> >>>>>>>>> Vladimir
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> On 10/01/2020 22:39, Filip Skokan wrote:
> >>>>>>>>> > Vladimir,
> >>>>>>>>> >
> >>>>>>>>> > For that very case the payload claims may be repeated in the JWE protected header. An implementation wanting to handle this may look for iss/client_id there.
> >>>>>>>>> >
> >>>>>>>>> > Odesláno z iPhonu
> >>>>>>>>> >
> >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
> >>>>>>>>> >>
> >>>>>>>>> >> I just realised there is one class of JARs where it's practially
> >>>>>>>>> >> impossible to process the request if merge isn't supported:
> >>>>>>>>> >>
> >>>>>>>>> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
> >>>>>>>>> >> for that and specs a method for deriving the shared key from the
> >>>>>>>>> >> client_secret:
> >>>>>>>>> >>
> >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
> >>>>>>>>> >>
> >>>>>>>>> >> If the JAR is encrypted with the client_secret, and there is no
> >>>>>>>>> >> top-level client_id parameter, there's no good way for the OP to find
> >>>>>>>>> >> out which client_secret to get to try to decrypt the JWE. Unless the OP
> >>>>>>>>> >> keeps an index of all issued client_secret's.
> >>>>>>>>> >>
> >>>>>>>>> >>
> >>>>>>>>> >> OP servers which require request_uri registration
> >>>>>>>>> >> (require_request_uri_registration=true) and don't want to index all
> >>>>>>>>> >> registered request_uri's, also have no good way to process a request_uri
> >>>>>>>>> >> if the client_id isn't present as top-level parameter.
> >>>>>>>>> >>
> >>>>>>>>> >>
> >>>>>>>>> >> Vladimir
> >>>>>>>>> >>
> >>>>>>>>> >>
> >>>>>>>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> >>>>>>>>> >>>
> >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
> >>>>>>>>> >>>> I think Torsten is speculating that is not a feature people use.   
> >>>>>>>>> >>> I’m still trying to understand the use case for merging signed and unsigned parameters. Nat once explained a use case, where a client uses parameters signed by a 3rd party (some „certification authority“) in combination with transaction-specific parameters. Is this being done in the wild?
> >>>>>>>>> >>>
> >>>>>>>>> >>> PS: PAR would work with both modes.
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> _______________________________________________
> >>>>>>>>> OAuth mailing list
> >>>>>>>>> OAuth@ietf.org
> >>>>>>>>> https://
> >>>>>>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>> --  
> >>> Vladimir Dzhuvinov
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________ 
> >> OAuth mailing list 
> >> OAuth@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/oauth 

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


From nobody Thu Jan 16 07:48: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 6ECAC1208F0 for ; Thu, 16 Jan 2020 07:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4C8Mzkz3XnZ for ; Thu, 16 Jan 2020 07:47:58 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0D61208EE for ; Thu, 16 Jan 2020 07:47:48 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00GFl8pY009531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 10:47:12 -0500
From: Justin Richer 
Message-Id: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_80407108-E82E-4DC4-B995-9D97421FB10B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 16 Jan 2020 10:47:08 -0500
In-Reply-To: <05BEC41F-8709-41B7-A691-3B679618E854@amazon.com>
Cc: Vladimir Dzhuvinov , oauth , Nat Sakimura , "Richard Backman, Annabelle" 
To: "Richard Backman, Annabelle" 
References: <8D1DD3BF-97B5-416A-B914-6867FD3553B0@amazon.com> <72A27E43-72C6-44D0-8D95-07FBF8CE332F@lodderstedt.net>      <1A5C82C9-383D-4C09-8233-3C9D0C85A1F6@mit.edu>    <05BEC41F-8709-41B7-A691-3B679618E854@amazon.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-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, 16 Jan 2020 15:48:03 -0000

--Apple-Mail=_80407108-E82E-4DC4-B995-9D97421FB10B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 to this approach, and it sounds like JAR might need to come back to =
go through another round anyway thanks to the breaking changes the IESG =
pushed into it after it left WGLC.

I=E2=80=99d rather see us get this right than publish something many of =
us think is broken.=20

Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

 =E2=80=94 Justin

> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
 wrote:
>=20
> The problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
> =20
> My preference remains the former. It strikes me as bad form for one =
extension to override normative requirements laid out in another =
document. Granted, the incompatibility scenarios introduced by this =
retcon are edge-case at best, but that just raises the question of why =
we can=E2=80=99t fix the draft that hasn=E2=80=99t actually been =
published yet.
> =20
> =E2=80=93=20
> Annabelle Richard Backman
> AWS Identity
> =20
> =20
> From: OAuth > =
on behalf of Vladimir Dzhuvinov >
> Organization: Connect2id Ltd.
> Date: Wednesday, January 15, 2020 at 12:34 PM
> To: Justin Richer 
> Cc: oauth , Nat Sakimura , "Richard =
Backman, Annabelle" 
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests =
must become JWTs
> =20
> On 13/01/2020 19:32, Justin Richer wrote:
>> To be clear, I=E2=80=99m not saying we suggest a particular form, and =
I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=99s a =
JWT=E2=80=9D or something of that nature. But if we call the result of =
PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =E2=80=9Cthing=
 X=E2=80=9D in JAR, then we=E2=80=99re compatible without saying what =
=E2=80=9Cthing X=E2=80=9D needs to be in all cases.=20
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing =
the pushed authZ request; at the authZ endpoint its processing is =
completed.
> No need is both clear and abstract enough to not require a form to be =
specified.
> =20
>> In cases where you do a remote look up, we want =E2=80=9Cthing X=E2=80=9D=
 to be formatted as a JWT.
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl =
specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web =
Token, or some other verifiable blob, resulting in the same essential =
function, and this isn't affecting the client <-> AS contract in any =
way.
> =20
>> We had a case of similarly unintentional limiting in JAR previously, =
saying that you had to do an HTTP lookup on the request_uri, but I =
believe that=E2=80=99s been backed off now and made conditional.
> That was precisely my point.
> Vladimir
> =20
> =20
>>  =E2=80=94 Justin
>>=20
>>=20
>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov =
> wrote:
>>> =20
>>> My suggestion is to abstain from specifying the concrete form of the =
resource pointed to by the PAR URI. Regardless of URI type (URN, =
downloadable https URL or something else), and even if the PAR endpoint =
and the authZ endpoint are managed by two different entities =
(microservice or other scenario).
>>> In the Connect2id implementation of PAR the returned URI doesn't =
point to a request object and it doesn't point to a JWT either. It =
points to an internally stored "pre-processed" authZ request, which the =
authZ endpoint then picks up to complete the authZ.
>>> Even if we eventually end up in microservice world, or allow the PAR =
endpoint to be managed by some external entity, the PAR URI - its =
interpretation, validation and potentially resource retrieval (JWT or =
other blob), is an "internal contract" on the AS side. This doesn't =
concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>> =20
>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ =
request: the client submits an authZ request and gets an authZ response =
at the end. The URI is necessary for the client to proceed from the 1st =
to the 2nd step. If we manage to frame / word the PAR URI in this =
logical way, without getting stuck in the JAR definition / framing of =
what the request_uri / object is, it would be great.
>>> =20
>>> The normative language I think should focus on maintaining the OAuth =
2.0 contract for the entire logical authZ request, together with the =
basic contracts of 1) JAR and the 2) authZ endpoint.
>>> =20
>>> Vladimir
>>> =20
>>> On 10/01/2020 22:55, Justin Richer wrote:
>>>> So we could solve this by saying the resulting data object of a PAR =
is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing.=20
>>>> =20
>>>> Or PAR could at least say that if it=E2=80=99s dereferenced over a =
remote protocol then it MUST be a JWT, but otherwise it can be whatever =
you want. That=E2=80=99s where the real interop concerns come in.
>>>> =20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>=20
>>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle =
> wrote:
>>>>> =20
>>>>> Correct. The problem becomes pretty clear in the context of PAR, =
where the AS is generating and vending out the URI at the PAR endpoint, =
and consuming it at the authorization endpoint. =46rom an =
interoperability standpoint, it=E2=80=99s analogous to the AS vending an =
authorization code at the authorization endpoint and consuming it at the =
token endpoint.
>>>>> =E2=80=93=20
>>>>> Annabelle Richard Backman
>>>>> AWS Identity
>>>>> =20
>>>>> =20
>>>>> From: John Bradley >
>>>>> Date: Friday, January 10, 2020 at 12:29 PM
>>>>> To: Brian Campbell >
>>>>> Cc: Torsten Lodderstedt >, Nat Sakimura >, "Richard Backman, Annabelle" =
>, oauth =
>
>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests =
must become JWTs
>>>>> =20
>>>>> If we assume the client posts a JAR and gets back a reference.  =
Then the reference is to a JAR.=20
>>>>> =20
>>>>> I think I see the problem.  If the server providing the reference =
is associated with the AS then the server dosen't need to dereference =
the object via HTTP, so it could be a URN as an example.=20
>>>>> =20
>>>>> So yes it is not a interoperability issue for the client. =20
>>>>> =20
>>>>> I will think about how I can finesse that.=20
>>>>> =20
>>>>> I agree it is not a change in intent.=20
>>>>> =20
>>>>> I will see if I can get our AD to accept that.
>>>>> =20
>>>>> John B.=20
>>>>> =20
>>>>> =20
>>>>> =20
>>>>> =20
>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell =
> wrote:
>>>>>> Sure but the text proposed (or something like it) qualifies it =
such that there aren't interoperability questions because it's only an =
implementation detail to the AS who both produces the URI and consumes =
its content.
>>>>>> =20
>>>>>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley > wrote:
>>>>>>> It may be a challenge to change text saying that the contents of =
the resource could be something other than a request object.=20
>>>>>>> =20
>>>>>>> If not a request object then what and how is that interoperable =
are likely AD questions.=20
>>>>>>> =20
>>>>>>> I could perhaps see changing it to must be a request object, or =
other format defined by a profile.
>>>>>>>=20
>>>>>>> John B. =20
>>>>>>> =20
>>>>>>> =20
>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell =
> wrote:
>>>>>>>> Agree and agree. But given that the change suggested by =
Annabelle has no impact on the client or interoperability, perhaps Nat =
or John could work the change into the draft during the edits that =
happen during the final stages of things?
>>>>>>>> =20
>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt =
> wrote:
>>>>>>>>> I would assume given the status of JAR, we don=E2=80=99t want =
to change it. And as I said, this difference does not impact =
interoperability from client perspective.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle =
>:
>>>>>>>>>>=20
>>>>>>>>>> It would be more appropriate to add the text to JAR rather =
than PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving =
the text to JAR also highlights the weirdness of giving PAR special =
treatment.
>>>>>>>>>> =20
>>>>>>>>>> What if we changed this sentence in Section 5.2 of JAR:
>>>>>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>>>>> Object.
>>>>>>>>>> =20
>>>>>>>>>> To:=20
>>>>>>>>>> The contents of the resource referenced by the URI MUST be a =
Request
>>>>>>>>>> Object, unless the URI was provided to the client by the =
Authorization
>>>>>>>>>> Server.
>>>>>>>>>> =20
>>>>>>>>>> This would allow for use cases such as an AS that provides =
pre-defined request URIs, or vends request URIs via a client management =
console, or bakes them into their client apps.
>>>>>>>>>> =20
>>>>>>>>>> =E2=80=93=20
>>>>>>>>>> Annabelle Richard Backman
>>>>>>>>>> AWS Identity
>>>>>>>>>> =20
>>>>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" =
> wrote:
>>>>>>>>>> =20
>>>>>>>>>>     Hi,=20
>>>>>>>>>>    =20
>>>>>>>>>>     you are right, PAR does not require the AS to represent =
the request as a JWT-based request object. The URI is used as internal =
reference only. That why the draft states
>>>>>>>>>>    =20
>>>>>>>>>>     "There is no need to make the
>>>>>>>>>>           authorization request data available to other =
parties via this
>>>>>>>>>>           URI.=E2=80=9D
>>>>>>>>>>    =20
>>>>>>>>>>     This difference matters from an AS implementation =
perspective, it doesn't matter from a client's (interop) perspective.
>>>>>>>>>>    =20
>>>>>>>>>>     We may add a statement to PAR saying that request_uris =
issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>>>>    =20
>>>>>>>>>>     best regards,
>>>>>>>>>>     Torsten. =20
>>>>>>>>>>    =20
>>>>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle =
> wrote:
>>>>>>>>>>     >=20
>>>>>>>>>>     > Hi all,
>>>>>>>>>>     > =20
>>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require =
that the AS transform all pushed requests into JWTs. This requirement =
arises from the following:
>>>>>>>>>>     >         =E2=80=A2 PAR uses the request_uri parameter =
defined in JAR to communicate the pushed request to the authorization =
endpoint.
>>>>>>>>>>     >         =E2=80=A2 According to JAR, the resource =
referenced by request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>>>>     >         =E2=80=A2 Request Object is defined to be a JWT =
containing all the authorization request parameters. (Section 2.1)
>>>>>>>>>>     > =20
>>>>>>>>>>     > There is no need for this requirement to support =
interoperability, as this is internal to the AS. It is also inconsistent =
with the rest of JAR, which avoids attempting to define the internal =
communications between the two AS endpoints. Worse, this restriction =
makes it harder for the authorization endpoint to leverage validation =
and other work performed at the PAR endpoint, as the state or outcome of =
that work must be forced into the JWT format (or retrieved via a =
subsequent service call or database lookup).
>>>>>>>>>>     > =20
>>>>>>>>>>     > =E2=80=93=20
>>>>>>>>>>     > Annabelle Richard Backman
>>>>>>>>>>     > AWS Identity
>>>>>>>>>>     > =20
>>>>>>>>>>     > _______________________________________________
>>>>>>>>>>     > OAuth mailing list
>>>>>>>>>>     > OAuth@ietf.org 
>>>>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>> =20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =
--=20
>>> Vladimir Dzhuvinov
>>=20
>> =20
> --=20
> Vladimir Dzhuvinov


--Apple-Mail=_80407108-E82E-4DC4-B995-9D97421FB10B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 =
to this approach, and it sounds like JAR might need to come back to go =
through another round anyway thanks to the breaking changes the IESG =
pushed into it after it left WGLC.

I=E2=80=99d rather see us get this =
right than publish something many of us think is broken. 

Maybe PAR and JAR (and =
JARM?) end up going out as a bundle of specs.

 =E2=80=94 Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle =
<richanna@amazon.com> wrote:

The =
problem is the JWT requirement in JAR, not how we talk about PAR =
request_uri values in PAR. We need to either change the language in JAR =
(see my suggestions elsewhere in this thread), or add text in PAR that =
explicitly exempts PAR request_uri values (or preferably all AS-provided =
request_uri values) from this requirement (also see my suggestions =
elsewhere in this thread).
 
My preference remains the former. It =
strikes me as bad form for one extension to override normative =
requirements laid out in another document. Granted, the incompatibility =
scenarios introduced by this retcon are edge-case at best, but that just =
raises the question of why we can=E2=80=99t fix the draft that hasn=E2=80=99=
t actually been published yet.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> =
on behalf of Vladimir Dzhuvinov <vladimir@connect2id.com>Organization: Connect2id Ltd.
Date: Wednesday, January 15, =
2020 at 12:34 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>, Nat =
Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] =
[UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
 
On 13/01/2020 19:32, Justin Richer =
wrote:
To be clear, I=E2=80=99m not saying we suggest a particular =
form, and I agree that we shouldn=E2=80=99t specify that =E2=80=9Cit=E2=80=
=99s a JWT=E2=80=9D or something of that nature. But if we call the =
result of PAR =E2=80=9Cthing X=E2=80=9D and the target of request_uri =
=E2=80=9Cthing X=E2=80=9D in JAR, then we=E2=80=99re compatible without =
saying what =E2=80=9Cthing X=E2=80=9D needs to be in all cases. 
Good, we're on the =
same page then.
How about =
simply saying that the result of PAR is an URI referencing the pushed =
authZ request; at the authZ endpoint its processing is completed.
No need is both clear and =
abstract enough to not require a form to be specified.
 
In cases where you do a remote look up, =
we want =E2=80=9Cthing X=E2=80=9D to be formatted as a JWT.
But why?
Both PAR and authZ endpoints =
belong to the AS, which makes that impl specific. The URI is the =
contract, between client and AS.
The AS, if uService based, could choose to implement that as =
CBOR Web Token, or some other verifiable blob, resulting in the same =
essential function, and this isn't affecting the client <-> AS =
contract in any way.
 
We had a case of similarly =
unintentional limiting in JAR previously, saying that you had to do an =
HTTP lookup on the request_uri, but I believe that=E2=80=99s been backed =
off now and made conditional.
That was =
precisely my point.
Vladimir
 
 
 =E2=80=94 Justin


On Jan 11, 2020, at 5:28 AM, Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:
 
My suggestion is to abstain from =
specifying the concrete form of the resource pointed to by the PAR URI. =
Regardless of URI type (URN, downloadable https URL or something else), =
and even if the PAR endpoint and the authZ endpoint are managed by two =
different entities (microservice or other scenario).
In the =
Connect2id implementation of PAR the returned URI doesn't point to a =
request object and it doesn't point to a JWT either. It points to an =
internally stored "pre-processed" authZ request, which the authZ =
endpoint then picks up to complete the authZ.
Even if =
we eventually end up in microservice world, or allow the PAR endpoint to =
be managed by some external entity, the PAR URI - its interpretation, =
validation and potentially resource retrieval (JWT or other blob), is an =
"internal contract" on the AS side. This doesn't concern the client, and =
in OAuth 2.0 the role of AS is indivisible.
 
I see PAR =
request + authZ request as one logical OAuth 2.0 authZ request: the =
client submits an authZ request and gets an authZ response at the end. =
The URI is necessary for the client to proceed from the 1st to the 2nd =
step. If we manage to frame / word the PAR URI in this logical way, =
without getting stuck in the JAR definition / framing of what the =
request_uri / object is, it would be great.
 
The =
normative language I think should focus on maintaining the OAuth 2.0 =
contract for the entire logical authZ request, together with the basic =
contracts of 1) JAR and the 2) authZ endpoint.
 
Vladimir
 
On 10/01/2020 22:55, Justin Richer =
wrote:
So we could solve this by saying the resulting data object of =
a PAR is a request object. Which might also contain a request object =
internally as well. In that case JAR should back off from saying it=E2=80=99=
s a JWT and instead say it=E2=80=99s a request object. Or we define a =
new term for this authorization request blob thing. 
 
Or PAR could at least say that if =
it=E2=80=99s dereferenced over a remote protocol then it MUST be a JWT, =
but otherwise it can be whatever you want. That=E2=80=99s where the real =
interop concerns come in.
 
 =E2=80=94 Justin


On Jan 10, 2020, at 3:41 PM, Richard =
Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
Correct. The problem becomes pretty =
clear in the context of PAR, where the AS is generating and vending out =
the URI at the PAR endpoint, and consuming it at the authorization =
endpoint. =46rom an interoperability standpoint, it=E2=80=99s analogous =
to the AS vending an authorization code at the authorization endpoint =
and consuming it at the token endpoint.
=E2=80=93 
Annabelle Richard Backman
AWS =
Identity
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, January 10, =
2020 at 12:29 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Torsten Lodderstedt =
<torsten@lodderstedt.net>, =
Nat Sakimura <nat@sakimura.org>, =
"Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: =
[OAUTH-WG] PAR: pushed requests must become JWTs
 
If we assume the client =
posts a JAR and gets back a reference.  Then the reference is to a =
JAR. 
 
I think I see the problem.  If the =
server providing the reference is associated with the AS then the server =
dosen't need to dereference the object via HTTP, so it could be a URN as =
an example. 
 
So yes it is not a interoperability =
issue for the client.  
 
I will think about how I can finesse =
that. 
 
I agree it is not a change in =
intent. 
 
I will see if I can get our AD to =
accept that.
 
John B. 
 
 
 
 
On Fri, Jan 10, 2020, 4:57 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Sure but the text proposed (or =
something like it) qualifies it such that there aren't interoperability =
questions because it's only an implementation detail to the AS who both =
produces the URI and consumes its content.
 
On Fri, =
Jan 10, 2020 at 12:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
It may be a challenge to =
change text saying that the contents of the resource could be something =
other than a request object. 
 
If not a request object then what and =
how is that interoperable are likely AD questions. 
 
I could perhaps see changing it to must =
be a request object, or other format defined by a profile.

John B.  
 
 
On Fri, Jan 10, 2020, 3:45 =
PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Agree and agree. But given =
that the change suggested by Annabelle has no impact on the client or =
interoperability, perhaps Nat or John could work the change into the =
draft during the edits that happen during the final stages of =
things?
 
On Thu, Jan 9, 2020 at =
1:56 AM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
I would assume given the =
status of JAR, we don=E2=80=99t want to change it. And as I said, this =
difference does not impact interoperability from client perspective.



Am 09.01.2020 um 00:58 schrieb =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:
It would be =
more appropriate to add the text to JAR rather than PAR. It doesn't seem =
right for PAR to retcon rules in JAR. Moving the text to JAR also =
highlights the weirdness of giving PAR special treatment.
 
What if we changed this =
sentence in Section 5.2 of JAR:
The contents of the resource referenced by the =
URI MUST be a Request
Object.
 
To: 
The contents of the resource referenced by the =
URI MUST be a Request
Object, unless the URI =
was provided to the client by the Authorization
Server.
 
This would allow for use cases =
such as an AS that provides pre-defined request URIs, or vends request =
URIs via a client management console, or bakes them into their client =
apps.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
 
    Hi, 
    
    you are right, PAR does not require =
the AS to represent the request as a JWT-based request object. The URI =
is used as internal reference only. That why the draft states
    
    "There is no need to make the
          =
authorization request data available to other parties via this
          =
URI.=E2=80=9D
    
    This difference matters from an AS =
implementation perspective, it doesn't matter from a client's (interop) =
perspective.
    
    We may add a statement to PAR saying =
that request_uris issued by the PAR mechanism (MAY) deviate from the JAR =
definition.
    
    best regards,
    Torsten.  
    
    > On 8. Jan 2020, at 23:42, =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
    > 
    > Hi all,
    >  
    > The current drafts of PAR (-00) =
and JAR (-20) require that the AS transform all pushed requests into =
JWTs. This requirement arises from the following:
    > =
        =E2=80=A2 PAR uses the =
request_uri parameter defined in JAR to communicate the pushed request =
to the authorization endpoint.
    > =
        =E2=80=A2 According to JAR, =
the resource referenced by request_uri MUST be a Request Object. =
(Section 5.2)
    > =
        =E2=80=A2 Request Object is =
defined to be a JWT containing all the authorization request parameters. =
(Section 2.1)
    >  
    > There is no need for this =
requirement to support interoperability, as this is internal to the AS. =
It is also inconsistent with the rest of JAR, which avoids attempting to =
define the internal communications between the two AS endpoints. Worse, =
this restriction makes it harder for the authorization endpoint to =
leverage validation and other work performed at the PAR endpoint, as the =
state or outcome of that work must be forced into the JWT format (or =
retrieved via a subsequent service call or database lookup).
    >  
    > =E2=80=93 
    > Annabelle Richard Backman
    > AWS Identity
    >  
    > =
_______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


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