From nobody Tue Oct 1 14:40:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F711200F4 for ; Tue, 1 Oct 2019 14:40:48 -0700 (PDT) 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=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 s8lge9HBkzlZ for ; Tue, 1 Oct 2019 14:40:46 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C36120089 for ; Tue, 1 Oct 2019 14:40:46 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h144so51910319iof.7 for ; Tue, 01 Oct 2019 14:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2aXIuHdyhjtgrTnXbbA6VL5BweB9wTzk6n0lU4jMQg=; b=AAzNLCcQAcM2W7o+rZn4ZcqwwCMF0R7mWkQIBWG/cIJLGKdGo+Nd2pBrRCuqbABJl/ zs1KleakZ17e724dUkutqwQ6B9wU28+ZPDjB5OO1MBXWujMEUS1eOO4X8J11VAUnbPjL mbKbhux5DfJBf0OY5tOgYi/ioEajmky5dv1B4= 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=s2aXIuHdyhjtgrTnXbbA6VL5BweB9wTzk6n0lU4jMQg=; b=WenJYbpVrnk+WkKAjnrskGfTsnLlMJnE688z+si0QvOyC9xmThPNTlqklmuHtnf8Ot o4e6Tbi40Ni5ahjphcPImKRh86uytlhL3Hgx5La/6jmu58rCabBwYV30gkP/zfRzmOyH JGnpc1mS/EFG/JE5MZqjshx69I8H3TvsES8cpXXM7LpAasBdxZ+oqa9ewUnNsUUHhPg7 R+ZJ14r6AAmExzV204iP740LWFY25RFflnAWSXv7YPPvyCUuJ8eKOtpvNTfKVEQfKFSA qAsQ/103UECkoeqM+pAn6EHUOv89WKWq8d4PSHoaKvdrKZNP23uF0acgYtKaF+GhrL20 36CA== X-Gm-Message-State: APjAAAUKMR5tfPPl3D+Qx6yfNMK7imV1ykGUgvsoUihvwGiCy6sxvIaZ 7oamirE5AwJL6krjYcLy+DOdA7vMU4Vn+l5sZ/5WdcDhYHajpKtzxMK/pMy9pzpoRcilRhTFCcg yshTaGAHs8xzSmQ== X-Google-Smtp-Source: APXvYqyh0LEYhXucDSHAB7+xLlORC0WGZVHQuFg/TL7I3FHnjBK5gAOzOPZJHKB1fAc1+3qCHNKWUC2N+Nw8/wtp3Wg= X-Received: by 2002:a6b:cd81:: with SMTP id d123mr383095iog.78.1569966045579; Tue, 01 Oct 2019 14:40:45 -0700 (PDT) MIME-Version: 1.0 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Tue, 1 Oct 2019 15:40:19 -0600 Message-ID: To: Justin Richer Cc: George Fletcher , oauth Content-Type: multipart/alternative; boundary="00000000000074eaa20593e034b2" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 21:40:49 -0000 --00000000000074eaa20593e034b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not entirely sold on the draft attempting to define this set of common data elements in the first place. But that said, I think (similar to George?) I'm struggling with "data" more than the others. The definition in the -02 draft is an "array of strings representing the kinds of data being requested from the resource" and I'm honestly having a hard time understanding what that actually means or how it would be used in practice. And I'm not sure roughly equating it to =E2=80=9Cwhat kind of thing I want= =E2=80=9D helped me understand any better. On Tue, Sep 24, 2019 at 5:34 PM Justin Richer wrote: > The idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80= =9D, =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data > element types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D used= for in the wild. They > roughly equate to =E2=80=9Cwhere something is=E2=80=9D, =E2=80=9Cwhat I w= ant to do with it=E2=80=9D, =E2=80=9Cwhat > kind of thing I want=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80= =9D, respectively. I=E2=80=99m > completely open for better names, and have even been thinking =E2=80=9Cda= tatype=E2=80=9D > might be better than just =E2=80=9Cdata=E2=80=9D for the third one. > > As for encoding, I think that form encoding makes sense because it=E2=80= =99s the > simplest possible encoding that will work. I personally don=E2=80=99t see= a need to > armor this part of the request with base64, as it is in JOSE, and doing s= o > would make it one more step removed from easy developer understanding. > > -- Justin Richer > > Bespoke Engineering > +1 (617) 564-3801 > https://bspk.io/ > > > > On Sep 24, 2019, at 1:45 PM, George Fletcher wrote: > > Just two questions... > > 1. What is the rationale that 'data' is really an array of arbitrary > top-level claims? I find looking at the spec and not finding a 'data' > section a little confusing. > > 2. What is the rationale for sending the JSON object as a urlencoded JSON > string rather than a base64url encoded JSON string? The later would likel= y > be smaller and easier to read:) > > Thanks, > George > > On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: > > Hi all,?? > > I just published a draft about ???OAuth 2.0 Rich Authorization Requests??= ? > (formerly known as ???structured scopes???).?? > > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > > It specifies a new parameter?????authorization_details"??that is used to > carry fine grained authorization data in the OAuth authorization request. > This mechanisms was designed based on experiences gathered in the field o= f > open banking, e.g. PSD2, and is intended to make the implementation of ri= ch > and transaction oriented authorization requests much easier than with > current OAuth 2.0. > > I???m happy that Justin Richer and Brian Campbell joined me as authors of > this draft. We would would like to thank Daniel Fett, Sebastian Ebling, > Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable > feedback during the preparation of this draft. > > We look forward to getting your feedback.?? > > kind regards, > Torsten.?? > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-lodderstedt-oauth-rar-02.txt* > *Date: *21. September 2019 at 16:10:48 CEST > *To: *"Justin Richer" , "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Brian Campbell" > > > A new version of I-D, draft-lodderstedt-oauth-rar-02.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-rar > Revision: 02 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-09-20 > Group: Individual Submission > Pages: 16 > URL: ?????????????????????? > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt > Status: ???????????????? > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ > Htmlized: ???????????? > https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 > Htmlized: ???????????? > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar > Diff: ???????????????????? > https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02 > > Abstract: > ????This document specifies a new parameter "authorization_details" that > ????is used to carry fine grained authorization data in the OAuth > ????authorization request. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --00000000000074eaa20593e034b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not entirely sold on the draft attempting to = define this set of common data elements in the first place. But that said, = I think (similar to George?) I'm struggling with "data" more = than the others. The definition in the -02 draft is an "array of strin= gs representing the kinds of data being requested from the resource" a= nd I'm honestly having a hard time understanding what that actually mea= ns=20 or how it would be used in practice. And I'm not sure roughly equating = it to =E2=80=9Cwhat kind of thing I want=E2=80=9D helped me understand any = better.

On Tue, Sep 24, 2019 at 5:34 PM Justin Richer <justin@bspk.io> wrote:<= br>
The idea be= hind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80=9D, =E2=80=9Cd= ata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data element types mirrors w= hat I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D used for in the wild. They ro= ughly equate to =E2=80=9Cwhere something is=E2=80=9D, =E2=80=9Cwhat I want = to do with it=E2=80=9D, =E2=80=9Cwhat kind of thing I want=E2=80=9D, and = =E2=80=9Cthe exact thing I want=E2=80=9D, respectively. I=E2=80=99m complet= ely open for better names, and have even been thinking =E2=80=9Cdatatype=E2= =80=9D might be better than just =E2=80=9Cdata=E2=80=9D for the third one.<= div>
As for encoding, I think that form encoding makes sense = because it=E2=80=99s the simplest possible encoding that will work. I perso= nally don=E2=80=99t see a need to armor this part of the request with base6= 4, as it is in JOSE, and doing so would make it one more step removed from = easy developer understanding.=C2=A0

-- Justin Richer

Besp= oke Engineering
+1 (617) 564-380= 1



On Sep 24, 2019, at 1:45 PM, George= Fletcher <gffletc= h@aol.com> wrote:

=20 =20 =20
Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary top-level claims? I find looking at the spec and not finding a 'data' section a little confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON string rather than a base64url encoded JSON string? The later would likely be smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
=20 Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).??


It specifies a new parameter?????authorization_details"??that is used to carry fi= ne grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.

We look forward to getting your feedback.??

kind regards,
Torsten.??

Begin forwarded message:

Subject: = New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02 Title: OAuth 2.0 Rich Authorization Requests
Document date: = 2019-09-20
Group: Individual Submission
Pages: 16
URL: ??????????????????????https= ://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status: ????????????????https://datatracke= r.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized: ????????????https://tools.ietf.org/= html/draft-lodderstedt-oauth-rar-02
Htmlized: ????????????https://datatrac= ker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
Diff: ????????????????????https://www= .ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02

Abstract:
????This document specifies a new parameter "authorization_details" that
????is used to carry fine grained authorization data in the OAuth
????authorization request.




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

The IETF Secretariat



_______________________________________________
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. --00000000000074eaa20593e034b2-- From nobody Tue Oct 1 15:33:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99B412012C for ; Tue, 1 Oct 2019 15:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrClD0b47ZdQ for ; Tue, 1 Oct 2019 15:33:47 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DAA120168 for ; Tue, 1 Oct 2019 15:33:46 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x91MXYnd032548; Tue, 1 Oct 2019 18:33:43 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 1 Oct 2019 18:32:37 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 1 Oct 2019 18:33:30 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 1 Oct 2019 18:33:30 -0400 From: Justin Richer To: Brian Campbell CC: George Fletcher , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt Thread-Index: AQHVeKg/bN/Pzd6dz0mSFm0p6lxHYQ== Date: Tue, 1 Oct 2019 22:33:29 +0000 Message-ID: <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.207.105.98] Content-Type: multipart/alternative; boundary="_000_5AD68F4C837A453297D11FE65FEC32D2mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 22:33:51 -0000 --_000_5AD68F4C837A453297D11FE65FEC32D2mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZGVmaW5lIDpzb21lOiBjb21tb24gc2V0IHRvIGRhdGEg ZWxlbWVudHMgaW4gdGhpcyBzcGVjLCBpbiBvcmRlciB0byBoZWxwIHBlb3BsZSB3aG8gYXJlIHVz aW5nIHRoaXMgYW5kIHRyeWluZyB0byBhcHBseSBpdCB0byB0aGVpciBBUElzIGRvIHNvIGluIHZh Z3VlbHkgY29uc2lzdGVudCB3YXlzLiBUaGUgZGV0YWlscyBvZiB3aGljaCBwYXJ0cyB3ZSBzdGFu ZGFyZGl6ZSBvbiBhcmUgc3RpbGwsIEkgdGhpbmssIHVwIGZvciBncmFicy4gSeKAmWQgYmUgaGFw cHkgdG8gaGF2ZSBhIGJldHRlciBuYW1lIHRoYW4g4oCcZGF0YeKAnSBmb3IgdGhpcyBhc3BlY3Qs IGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyB2YWx1ZSBpbiBkZWZpbmluZyB0aGlzIGtpbmQgb2YgdGhp bmcuIExpa2UgaW4gdGhlIGZpbmFuY2lhbCBzcGFjZSwgaXTigJlzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4g4oCcdHJhbnNhY3Rpb25z4oCdIGFuZCDigJxhY2NvdW50c+KAnS4gT3IgaW4gdGhlIG1l ZGljYWwgc3BhY2UsIHRoZXJl4oCZcyDigJxkZW1vZ3JhcGhpY3PigJ0gYW5kIOKAnGFwcG9pbnRt ZW50c+KAnSBhbmQg4oCcdGVzdFJlc3VsdHPigJ0uIFRoaXMgaXMgYSB2ZXJ5LCB2ZXJ5LCB2ZXJ5 IGNvbW1vbiB3YXkgdG8gc2xpY2UgdXAgT0F1dGgtcHJvdGVjdGVkIHJlc291cmNlcywgYW5kIHdl 4oCZZCBiZSByZW1pc3MgdG8gbGVhdmUgaXQgdW5kZWZpbmVkIGFuZCBqdXN0IGhhdmUgZXZlcnkg QVBJIGRldmVsb3BlciBuZWVkIHRvIGNvbWUgdXAgd2l0aCB0aGVpciBvd24gdmVyc2lvbiBvZiB0 aGUgc2FtZSB0aGluZy4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBPY3QgMSwgMjAxOSwgYXQgMjo0MCBQ TSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KDQpJJ20gbm90IGVudGlyZWx5IHNvbGQg b24gdGhlIGRyYWZ0IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoaXMgc2V0IG9mIGNvbW1vbiBkYXRh IGVsZW1lbnRzIGluIHRoZSBmaXJzdCBwbGFjZS4gQnV0IHRoYXQgc2FpZCwgSSB0aGluayAoc2lt aWxhciB0byBHZW9yZ2U/KSBJJ20gc3RydWdnbGluZyB3aXRoICJkYXRhIiBtb3JlIHRoYW4gdGhl IG90aGVycy4gVGhlIGRlZmluaXRpb24gaW4gdGhlIC0wMiBkcmFmdCBpcyBhbiAiYXJyYXkgb2Yg c3RyaW5ncyByZXByZXNlbnRpbmcgdGhlIGtpbmRzIG9mIGRhdGEgYmVpbmcgcmVxdWVzdGVkIGZy b20gdGhlIHJlc291cmNlIiBhbmQgSSdtIGhvbmVzdGx5IGhhdmluZyBhIGhhcmQgdGltZSB1bmRl cnN0YW5kaW5nIHdoYXQgdGhhdCBhY3R1YWxseSBtZWFucyBvciBob3cgaXQgd291bGQgYmUgdXNl ZCBpbiBwcmFjdGljZS4gQW5kIEknbSBub3Qgc3VyZSByb3VnaGx5IGVxdWF0aW5nIGl0IHRvIOKA nHdoYXQga2luZCBvZiB0aGluZyBJIHdhbnTigJ0gaGVscGVkIG1lIHVuZGVyc3RhbmQgYW55IGJl dHRlci4NCg0KT24gVHVlLCBTZXAgMjQsIDIwMTkgYXQgNTozNCBQTSBKdXN0aW4gUmljaGVyIDxq dXN0aW5AYnNway5pbzxtYWlsdG86anVzdGluQGJzcGsuaW8+PiB3cm90ZToNClRoZSBpZGVhIGJl aGluZCB0aGUg4oCcbG9jYXRpb25z4oCdLCDigJxhY3Rpb25z4oCdLCDigJxkYXRh4oCdLCBhbmQg 4oCcaWRlbnRpZmllcuKAnSBkYXRhIGVsZW1lbnQgdHlwZXMgbWlycm9ycyB3aGF0IEnigJl2ZSBz ZWVuIOKAnHNjb3Bl4oCdIHVzZWQgZm9yIGluIHRoZSB3aWxkLiBUaGV5IHJvdWdobHkgZXF1YXRl IHRvIOKAnHdoZXJlIHNvbWV0aGluZyBpc+KAnSwg4oCcd2hhdCBJIHdhbnQgdG8gZG8gd2l0aCBp dOKAnSwg4oCcd2hhdCBraW5kIG9mIHRoaW5nIEkgd2FudOKAnSwgYW5kIOKAnHRoZSBleGFjdCB0 aGluZyBJIHdhbnTigJ0sIHJlc3BlY3RpdmVseS4gSeKAmW0gY29tcGxldGVseSBvcGVuIGZvciBi ZXR0ZXIgbmFtZXMsIGFuZCBoYXZlIGV2ZW4gYmVlbiB0aGlua2luZyDigJxkYXRhdHlwZeKAnSBt aWdodCBiZSBiZXR0ZXIgdGhhbiBqdXN0IOKAnGRhdGHigJ0gZm9yIHRoZSB0aGlyZCBvbmUuDQoN CkFzIGZvciBlbmNvZGluZywgSSB0aGluayB0aGF0IGZvcm0gZW5jb2RpbmcgbWFrZXMgc2Vuc2Ug YmVjYXVzZSBpdOKAmXMgdGhlIHNpbXBsZXN0IHBvc3NpYmxlIGVuY29kaW5nIHRoYXQgd2lsbCB3 b3JrLiBJIHBlcnNvbmFsbHkgZG9u4oCZdCBzZWUgYSBuZWVkIHRvIGFybW9yIHRoaXMgcGFydCBv ZiB0aGUgcmVxdWVzdCB3aXRoIGJhc2U2NCwgYXMgaXQgaXMgaW4gSk9TRSwgYW5kIGRvaW5nIHNv IHdvdWxkIG1ha2UgaXQgb25lIG1vcmUgc3RlcCByZW1vdmVkIGZyb20gZWFzeSBkZXZlbG9wZXIg dW5kZXJzdGFuZGluZy4NCg0KLS0gSnVzdGluIFJpY2hlcg0KDQpCZXNwb2tlIEVuZ2luZWVyaW5n DQorMSAoNjE3KSA1NjQtMzgwMQ0KaHR0cHM6Ly9ic3BrLmlvLw0KDQoNCg0KT24gU2VwIDI0LCAy MDE5LCBhdCAxOjQ1IFBNLCBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb208bWFpbHRv OmdmZmxldGNoQGFvbC5jb20+PiB3cm90ZToNCg0KSnVzdCB0d28gcXVlc3Rpb25zLi4uDQoNCjEu IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSB0aGF0ICdkYXRhJyBpcyByZWFsbHkgYW4gYXJyYXkgb2Yg YXJiaXRyYXJ5IHRvcC1sZXZlbCBjbGFpbXM/IEkgZmluZCBsb29raW5nIGF0IHRoZSBzcGVjIGFu ZCBub3QgZmluZGluZyBhICdkYXRhJyBzZWN0aW9uIGEgbGl0dGxlIGNvbmZ1c2luZy4NCg0KMi4g V2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBzZW5kaW5nIHRoZSBKU09OIG9iamVjdCBhcyBhIHVy bGVuY29kZWQgSlNPTiBzdHJpbmcgcmF0aGVyIHRoYW4gYSBiYXNlNjR1cmwgZW5jb2RlZCBKU09O IHN0cmluZz8gVGhlIGxhdGVyIHdvdWxkIGxpa2VseSBiZSBzbWFsbGVyIGFuZCBlYXNpZXIgdG8g cmVhZDopDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiA5LzIxLzE5IDE6NTEgUE0sIFRvcnN0ZW4g TG9kZGVyc3RlZHQgd3JvdGU6DQpIaSBhbGwsPz8NCg0KSSBqdXN0IHB1Ymxpc2hlZCBhIGRyYWZ0 IGFib3V0ID8/P09BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRpb24gUmVxdWVzdHM/Pz8gKGZvcm1l cmx5IGtub3duIGFzID8/P3N0cnVjdHVyZWQgc2NvcGVzPz8/KS4/Pw0KDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyDQoNCkl0IHNwZWNp ZmllcyBhIG5ldyBwYXJhbWV0ZXI/Pz8/P2F1dGhvcml6YXRpb25fZGV0YWlscyI/P3RoYXQgaXMg dXNlZCB0byBjYXJyeSBmaW5lIGdyYWluZWQgYXV0aG9yaXphdGlvbiBkYXRhIGluIHRoZSBPQXV0 aCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoaXMgbWVjaGFuaXNtcyB3YXMgZGVzaWduZWQgYmFz ZWQgb24gZXhwZXJpZW5jZXMgZ2F0aGVyZWQgaW4gdGhlIGZpZWxkIG9mIG9wZW4gYmFua2luZywg ZS5nLiBQU0QyLCBhbmQgaXMgaW50ZW5kZWQgdG8gbWFrZSB0aGUgaW1wbGVtZW50YXRpb24gb2Yg cmljaCBhbmQgdHJhbnNhY3Rpb24gb3JpZW50ZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyBtdWNo IGVhc2llciB0aGFuIHdpdGggY3VycmVudCBPQXV0aCAyLjAuDQoNCkk/Pz9tIGhhcHB5IHRoYXQg SnVzdGluIFJpY2hlciBhbmQgQnJpYW4gQ2FtcGJlbGwgam9pbmVkIG1lIGFzIGF1dGhvcnMgb2Yg dGhpcyBkcmFmdC4gV2Ugd291bGQgd291bGQgbGlrZSB0byB0aGFuayBEYW5pZWwgRmV0dCwgU2Vi YXN0aWFuIEVibGluZywgRGF2ZSBUb25nZSwgTWlrZSBKb25lcywgTmF0IFNha2ltdXJhLCBhbmQg Um9iIE90dG8gZm9yIHRoZWlyIHZhbHVhYmxlIGZlZWRiYWNrIGR1cmluZyB0aGUgcHJlcGFyYXRp b24gb2YgdGhpcyBkcmFmdC4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVk YmFjay4/Pw0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLj8/DQoNCkJlZ2luIGZvcndhcmRlZCBt ZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dA0KRGF0ZTogMjEuIFNlcHRlbWJlciAy MDE5IGF0IDE2OjEwOjQ4IENFU1QNClRvOiAiSnVzdGluIFJpY2hlciIgPGlldGZAanVzdGluLnJp Y2hlci5vcmc8bWFpbHRvOmlldGZAanVzdGluLnJpY2hlci5vcmc+PiwgIlRvcnN0ZW4gTG9kZGVy c3RlZHQiIDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+PiwgIkJyaWFuIENhbXBiZWxsIiA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBUb3JzdGVuIExvZGRlcnN0ZWR0IGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhcg0KUmV2 aXNpb246IDAyDQpUaXRsZTogT0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0cw0K RG9jdW1lbnQgZGF0ZTogMjAxOS0wOS0yMA0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6IDE2DQpVUkw6ID8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz9odHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dA0KU3Rh dHVzOiA/Pz8/Pz8/Pz8/Pz8/Pz8/aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLw0KSHRtbGl6ZWQ6ID8/Pz8/Pz8/Pz8/P2h0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDINCkh0bWxp emVkOiA/Pz8/Pz8/Pz8/Pz9odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhcg0KRGlmZjogPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz9odHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFy LTAyDQoNCkFic3RyYWN0Og0KPz8/P1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IHBhcmFt ZXRlciAiYXV0aG9yaXphdGlvbl9kZXRhaWxzIiB0aGF0DQo/Pz8/aXMgdXNlZCB0byBjYXJyeSBm aW5lIGdyYWluZWQgYXV0aG9yaXphdGlvbiBkYXRhIGluIHRoZSBPQXV0aA0KPz8/P2F1dGhvcml6 YXRpb24gcmVxdWVzdC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS4NCg0K --_000_5AD68F4C837A453297D11FE65FEC32D2mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <13F97A309B28314693915F1D6C56B4C1@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGRlZmlu ZSA6c29tZTogY29tbW9uIHNldCB0byBkYXRhIGVsZW1lbnRzIGluIHRoaXMgc3BlYywgaW4gb3Jk ZXIgdG8gaGVscCBwZW9wbGUgd2hvIGFyZSB1c2luZyB0aGlzIGFuZCB0cnlpbmcgdG8gYXBwbHkg aXQgdG8gdGhlaXIgQVBJcyBkbyBzbyBpbiB2YWd1ZWx5IGNvbnNpc3RlbnQgd2F5cy4gVGhlIGRl dGFpbHMgb2Ygd2hpY2ggcGFydHMgd2Ugc3RhbmRhcmRpemUgb24gYXJlIHN0aWxsLCBJIHRoaW5r LA0KIHVwIGZvciBncmFicy4gSeKAmWQgYmUgaGFwcHkgdG8gaGF2ZSBhIGJldHRlciBuYW1lIHRo YW4g4oCcZGF0YeKAnSBmb3IgdGhpcyBhc3BlY3QsIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyB2YWx1 ZSBpbiBkZWZpbmluZyB0aGlzIGtpbmQgb2YgdGhpbmcuIExpa2UgaW4gdGhlIGZpbmFuY2lhbCBz cGFjZSwgaXTigJlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g4oCcdHJhbnNhY3Rpb25z4oCdIGFu ZCDigJxhY2NvdW50c+KAnS4gT3IgaW4gdGhlIG1lZGljYWwgc3BhY2UsIHRoZXJl4oCZcw0KIOKA nGRlbW9ncmFwaGljc+KAnSBhbmQg4oCcYXBwb2ludG1lbnRz4oCdIGFuZCDigJx0ZXN0UmVzdWx0 c+KAnS4gVGhpcyBpcyBhIHZlcnksIHZlcnksIHZlcnkgY29tbW9uIHdheSB0byBzbGljZSB1cCBP QXV0aC1wcm90ZWN0ZWQgcmVzb3VyY2VzLCBhbmQgd2XigJlkIGJlIHJlbWlzcyB0byBsZWF2ZSBp dCB1bmRlZmluZWQgYW5kIGp1c3QgaGF2ZSBldmVyeSBBUEkgZGV2ZWxvcGVyIG5lZWQgdG8gY29t ZSB1cCB3aXRoIHRoZWlyIG93biB2ZXJzaW9uIG9mIHRoZSBzYW1lDQogdGhpbmcuJm5ic3A7DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQri gJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCAxLCAyMDE5LCBhdCAy OjQwIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tIiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SSdt IG5vdCBlbnRpcmVseSBzb2xkIG9uIHRoZSBkcmFmdCBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGlz IHNldCBvZiBjb21tb24gZGF0YSBlbGVtZW50cyBpbiB0aGUgZmlyc3QgcGxhY2UuIEJ1dCB0aGF0 IHNhaWQsIEkgdGhpbmsgKHNpbWlsYXIgdG8gR2VvcmdlPykgSSdtIHN0cnVnZ2xpbmcgd2l0aCAm cXVvdDtkYXRhJnF1b3Q7IG1vcmUgdGhhbiB0aGUgb3RoZXJzLiBUaGUgZGVmaW5pdGlvbiBpbiB0 aGUgLTAyIGRyYWZ0IGlzIGFuICZxdW90O2FycmF5DQogb2Ygc3RyaW5ncyByZXByZXNlbnRpbmcg dGhlIGtpbmRzIG9mIGRhdGEgYmVpbmcgcmVxdWVzdGVkIGZyb20gdGhlIHJlc291cmNlJnF1b3Q7 IGFuZCBJJ20gaG9uZXN0bHkgaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgd2hhdCB0 aGF0IGFjdHVhbGx5IG1lYW5zIG9yIGhvdyBpdCB3b3VsZCBiZSB1c2VkIGluIHByYWN0aWNlLiBB bmQgSSdtIG5vdCBzdXJlIHJvdWdobHkgZXF1YXRpbmcgaXQgdG8g4oCcd2hhdCBraW5kIG9mIHRo aW5nIEkgd2FudOKAnQ0KIGhlbHBlZCBtZSB1bmRlcnN0YW5kIGFueSBiZXR0ZXIuPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIFNlcCAyNCwg MjAxOSBhdCA1OjM0IFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqdXN0aW5A YnNway5pbyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmp1c3RpbkBic3BrLmlvPC9hPiZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGNsYXNzPSIiPlRoZSBp ZGVhIGJlaGluZCB0aGUg4oCcbG9jYXRpb25z4oCdLCDigJxhY3Rpb25z4oCdLCDigJxkYXRh4oCd LCBhbmQg4oCcaWRlbnRpZmllcuKAnSBkYXRhIGVsZW1lbnQgdHlwZXMgbWlycm9ycyB3aGF0IEni gJl2ZSBzZWVuIOKAnHNjb3Bl4oCdIHVzZWQgZm9yIGluIHRoZSB3aWxkLiBUaGV5IHJvdWdobHkg ZXF1YXRlIHRvIOKAnHdoZXJlIHNvbWV0aGluZyBpc+KAnSwg4oCcd2hhdCBJIHdhbnQgdG8gZG8g d2l0aCBpdOKAnSwg4oCcd2hhdCBraW5kIG9mIHRoaW5nIEkgd2FudOKAnSwNCiBhbmQg4oCcdGhl IGV4YWN0IHRoaW5nIEkgd2FudOKAnSwgcmVzcGVjdGl2ZWx5LiBJ4oCZbSBjb21wbGV0ZWx5IG9w ZW4gZm9yIGJldHRlciBuYW1lcywgYW5kIGhhdmUgZXZlbiBiZWVuIHRoaW5raW5nIOKAnGRhdGF0 eXBl4oCdIG1pZ2h0IGJlIGJldHRlciB0aGFuIGp1c3Qg4oCcZGF0YeKAnSBmb3IgdGhlIHRoaXJk IG9uZS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkFzIGZvciBlbmNvZGluZywgSSB0aGluayB0aGF0IGZvcm0gZW5jb2RpbmcgbWFrZXMgc2Vuc2Ug YmVjYXVzZSBpdOKAmXMgdGhlIHNpbXBsZXN0IHBvc3NpYmxlIGVuY29kaW5nIHRoYXQgd2lsbCB3 b3JrLiBJIHBlcnNvbmFsbHkgZG9u4oCZdCBzZWUgYSBuZWVkIHRvIGFybW9yIHRoaXMgcGFydCBv ZiB0aGUgcmVxdWVzdCB3aXRoIGJhc2U2NCwgYXMgaXQgaXMgaW4gSk9TRSwgYW5kIGRvaW5nIHNv IHdvdWxkIG1ha2UgaXQgb25lIG1vcmUNCiBzdGVwIHJlbW92ZWQgZnJvbSBlYXN5IGRldmVsb3Bl ciB1bmRlcnN0YW5kaW5nLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KLS0gSnVzdGluIFJpY2hlcjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQpCZXNwb2tlIEVu Z2luZWVyaW5nPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQomIzQzOzEgKDYxNykgNTY0LTM4MDE8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vYnNway5p by8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2JzcGsuaW8vPC9hPjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIFNlcCAyNCwgMjAxOSwgYXQgMTo0NSBQTSwgR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBo cmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmdm ZmxldGNoQGFvbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPjxmb250IGZhY2U9Ikhl bHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiIGNsYXNzPSIiPkp1c3QgdHdvIHF1ZXN0aW9ucy4u LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjEuIFdoYXQgaXMgdGhlIHJhdGlvbmFsZSB0 aGF0ICdkYXRhJyBpcyByZWFsbHkgYW4gYXJyYXkgb2YgYXJiaXRyYXJ5IHRvcC1sZXZlbCBjbGFp bXM/IEkgZmluZCBsb29raW5nIGF0IHRoZSBzcGVjIGFuZCBub3QgZmluZGluZyBhICdkYXRhJyBz ZWN0aW9uIGEgbGl0dGxlIGNvbmZ1c2luZy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoy LiBXaGF0IGlzIHRoZSByYXRpb25hbGUgZm9yIHNlbmRpbmcgdGhlIEpTT04gb2JqZWN0IGFzIGEg dXJsZW5jb2RlZCBKU09OIHN0cmluZyByYXRoZXIgdGhhbiBhIGJhc2U2NHVybCBlbmNvZGVkIEpT T04gc3RyaW5nPyBUaGUgbGF0ZXIgd291bGQgbGlrZWx5IGJlIHNtYWxsZXIgYW5kIGVhc2llciB0 byByZWFkOik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIi Pg0KR2VvcmdlPGJyIGNsYXNzPSIiPg0KPC9mb250PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gOS8yMS8xOSAxOjUxIFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IHdyb3RlOjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SGkgYWxsLD8/ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGp1 c3QgcHVibGlzaGVkIGEgZHJhZnQgYWJvdXQgPz8/T0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlv biBSZXF1ZXN0cz8/PyAoZm9ybWVybHkga25vd24gYXMgPz8/c3RydWN0dXJlZCBzY29wZXM/Pz8p Lj8/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3Rl ZHQtb2F1dGgtcmFyLTAyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMjwvYT48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IHNwZWNp ZmllcyBhIG5ldyBwYXJhbWV0ZXI/Pz8/P2F1dGhvcml6YXRpb25fZGV0YWlscyZxdW90Oz8/dGhh dCBpcyB1c2VkIHRvIGNhcnJ5IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhl IE9BdXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhpcyBtZWNoYW5pc21zIHdhcyBkZXNpZ25l ZCBiYXNlZCBvbiBleHBlcmllbmNlcyBnYXRoZXJlZCBpbiB0aGUgZmllbGQgb2Ygb3BlbiBiYW5r aW5nLCBlLmcuIFBTRDIsDQogYW5kIGlzIGludGVuZGVkIHRvIG1ha2UgdGhlIGltcGxlbWVudGF0 aW9uIG9mIHJpY2ggYW5kIHRyYW5zYWN0aW9uIG9yaWVudGVkIGF1dGhvcml6YXRpb24gcmVxdWVz dHMgbXVjaCBlYXNpZXIgdGhhbiB3aXRoIGN1cnJlbnQgT0F1dGggMi4wLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ST8/P20gaGFwcHkg dGhhdCBKdXN0aW4gUmljaGVyIGFuZCBCcmlhbiBDYW1wYmVsbCBqb2luZWQgbWUgYXMgYXV0aG9y cyBvZiB0aGlzIGRyYWZ0LiBXZSB3b3VsZCB3b3VsZCBsaWtlIHRvIHRoYW5rIERhbmllbCBGZXR0 LCBTZWJhc3RpYW4gRWJsaW5nLCBEYXZlIFRvbmdlLCBNaWtlIEpvbmVzLCBOYXQgU2FraW11cmEs IGFuZCBSb2IgT3R0byBmb3IgdGhlaXIgdmFsdWFibGUgZmVlZGJhY2sgZHVyaW5nIHRoZSBwcmVw YXJhdGlvbg0KIG9mIHRoaXMgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5b3Vy IGZlZWRiYWNrLj8/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5raW5kIHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvcnN0ZW4u Pz88YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5CZWdpbiBmb3J3YXJkZWQgbWVz c2FnZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1mb250LCZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7LEhlbHZldGljYSxzYW5zLXNlcmlmIiBjbGFzcz0iIj48YiBjbGFz cz0iIj5Gcm9tOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1z eXN0ZW0tZm9udCxIZWx2ZXRpY2EgTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+ PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCwmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 OyxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwv Yj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQsSGVs dmV0aWNhIE5ldWUsSGVsdmV0aWNhLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPk5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAy LnR4dDwvYj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MHB4IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9u dCwmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9 IiI+PGIgY2xhc3M9IiI+RGF0ZToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 Oi13ZWJraXQtc3lzdGVtLWZvbnQsSGVsdmV0aWNhIE5ldWUsSGVsdmV0aWNhLHNhbnMtc2VyaWYi IGNsYXNzPSIiPjIxLiBTZXB0ZW1iZXIgMjAxOSBhdCAxNjoxMDo0OCBDRVNUPGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQsJnF1b3Q7SGVsdmV0aWNhIE5l dWUmcXVvdDssSGVsdmV0aWNhLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRvOg0K PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCxI ZWx2ZXRpY2EgTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+JnF1b3Q7SnVzdGlu IFJpY2hlciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAanVzdGluLnJpY2hlci5vcmci IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pZXRmQGp1c3Rpbi5yaWNoZXIub3JnPC9hPiZndDss ICZxdW90O1RvcnN0ZW4gTG9kZGVyc3RlZHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiZndDssDQogJnF1b3Q7QnJpYW4gQ2FtcGJlbGwmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVyc3Rl ZHQtb2F1dGgtcmFyLTAyLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZTxiciBjbGFz cz0iIj4NCklFVEYgcmVwb3NpdG9yeS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYW1l OjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj48c3Bh biBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPjwvc3Bhbj5kcmFmdC1sb2Rk ZXJzdGVkdC1vYXV0aC1yYXI8YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjo8c3BhbiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPiA8L3NwYW4+MDI8YnIgY2xhc3M9IiI+DQpUaXRs ZTo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPiA8L3NwYW4+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj48L3NwYW4+T0F1dGggMi4w IFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0czxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6 PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjIwMTkt MDktMjA8YnIgY2xhc3M9IiI+DQpHcm91cDo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdy YXAiIGNsYXNzPSIiPiA8L3NwYW4+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBj bGFzcz0iIj48L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KUGFnZXM6 PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjxzcGFu IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+PC9zcGFuPjE2PGJyIGNsYXNz PSIiPg0KVVJMOiA/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMi50eHQi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dDwvYT48YnIgY2xhc3M9IiI+ DQpTdGF0dXM6ID8/Pz8/Pz8/Pz8/Pz8/Pz88YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXIvIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVyc3Rl ZHQtb2F1dGgtcmFyLzwvYT48YnIgY2xhc3M9IiI+DQpIdG1saXplZDogPz8/Pz8/Pz8/Pz8/PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRo LXJhci0wMiIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDI8L2E+PGJyIGNsYXNzPSIiPg0KSHRt bGl6ZWQ6ID8/Pz8/Pz8/Pz8/PzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sb2RkZXJz dGVkdC1vYXV0aC1yYXI8L2E+PGJyIGNsYXNzPSIiPg0KRGlmZjogPz8/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz88YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9kZGVy c3RlZHQtb2F1dGgtcmFyLTAyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMjwvYT48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQo/Pz8/ VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgcGFyYW1ldGVyICZxdW90O2F1dGhvcml6YXRp b25fZGV0YWlscyZxdW90OyB0aGF0PGJyIGNsYXNzPSIiPg0KPz8/P2lzIHVzZWQgdG8gY2Fycnkg ZmluZSBncmFpbmVkIGF1dGhvcml6YXRpb24gZGF0YSBpbiB0aGUgT0F1dGg8YnIgY2xhc3M9IiI+ DQo/Pz8/YXV0aG9yaXphdGlvbiByZXF1ZXN0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGZpZWxkc2V0IGNsYXNzPSIiPjwvZmllbGRzZXQ+ DQo8cHJlIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8aSBzdHlsZT0ibWFyZ2luOjBw eDtwYWRkaW5nOjBweDtib3JkZXI6MHB4O291dGxpbmU6MHB4O3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lO2JhY2tncm91bmQ6cmdiKDI1NSwyNTUsMjU1KTtmb250LWZhbWlseTpwcm94aW1hLW5vdmEt emVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxzeXN0ZW0tdWksJnF1b3Q7U2Vnb2UgVUkm cXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJlbGwsJnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDssQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjpyZ2IoODUsODUsODUpIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtwYWRkaW5nOjBweDtib3JkZXI6MHB4O291dGxpbmU6 MHB4O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO2JhY2tncm91bmQ6dHJhbnNwYXJlbnQ7Zm9udC1m YW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sQmxpbmtN YWNTeXN0ZW1Gb250LCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVu dHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2VyaWY7 Zm9udC13ZWlnaHQ6NjAwIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5DT05GSURF TlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQogdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZp bGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9mb250Pjwvc3Bh bj48L2k+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5AD68F4C837A453297D11FE65FEC32D2mitedu_-- From nobody Tue Oct 1 15:36:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9279A120168 for ; Tue, 1 Oct 2019 15:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLRWhfvF5YMt for ; Tue, 1 Oct 2019 15:36:08 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 13990120100 for ; Tue, 1 Oct 2019 15:36:07 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x91MZ2Im002531; Tue, 1 Oct 2019 18:35:32 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 1 Oct 2019 18:35:00 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 1 Oct 2019 18:35:52 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 1 Oct 2019 18:35:52 -0400 From: Justin Richer To: Dick Hardt CC: Dave Tonge , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVdIpZnL295fl8/UWM1oDH5BpdI6c+cqkAgABIogCAAU7VAIAEOYQAgABfIYCAAghcgA== Date: Tue, 1 Oct 2019 22:35:52 +0000 Message-ID: <48D64799-1A80-40D0-B5A0-D90F9BD42DA5@mit.edu> References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.207.105.98] Content-Type: multipart/alternative; boundary="_000_48D647991A8040D0B5A0D90F9BD42DA5mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 22:36:13 -0000 --_000_48D647991A8040D0B5A0D90F9BD42DA5mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgY2xlYXIsIFBBUiBpcyBub3QgdGhlIHNhbWUgYXMgWFlaLiBCb3RoIGFyZSBnb2luZyB0 byBiZSBpbnB1dHMgaW50byB0aGUgY29udmVyc2F0aW9uIHVuZGVyIHR4YXV0aCwgYW5kIHRoZXJl IGFyZSBzaW1pbGFyaXRpZXMsIGJ1dCB0aGV5IHNob3VsZG7igJl0IGJlIGNvbmZsYXRlZC4NCg0K SW4gUEFSLCB0aGUgcmVzdWx0IGhhcyB0byBiZSBhIFVSSSBiZWNhdXNlIHRoYXTigJlzIHdoYXQg SkFSIGRlZmluZXMgYXMgdGhlIGlucHV0LiBXaXRoIFhZWiwgeW91IGdldCByZXR1cm5lZCB0d28g dGhpbmdzOiBhIHRyYW5zYWN0aW9uIGhhbmRsZSBhbmQgYW4gaW50ZXJhY3Rpb24gVVJJLiBUaGVz ZSBhcmUgYm90aCBvcGFxdWUgdG8gdGhlIGNsaWVudC4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBTZXAg MzAsIDIwMTksIGF0IDg6MzMgQU0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIGNhbiB1bmRlcnN0YW5kIHRo ZSByZXF1ZXN0IFVSSSBiZWluZyBhIFVSSSB0aGF0IHRoZSBjbGllbnQgaXMgcHJvdmlkaW5nIHRo ZSBBUywgYnV0IHdoeSB3b3VsZCB0aGUgY2xpZW50J3MgcmVxdWVzdCBVUkkgYmUgYXQgdGhlIEFT Pw0KDQpBcyBKdXN0aW4gaGFzIGV4cGxhaW5lZCBpdCBpbiB0aGUgcGFzdCwgdGhlIEFTIGlzIHJl dHVybmluZyBhIGhhbmRsZSB0byB0aGUgdHJhbnNhY3Rpb24uIFRoZSBvbmx5IHBhcnR5IHRoYXQg dW5kZXJzdGFuZHMgdGhhdCBoYW5kbGUgYXMgZmFyIGFzIEkga25vdyBpcyB0aGUgQVMuIEl0IGlz IG1lYW5pbmdsZXNzIHRvIHRoZSBjbGllbnQuIFBlcmhhcHMgSSBhbSBtaXNzaW5nIHNvbWV0aGlu ZyBlbHNlPw0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5 NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD0xMzg5ZGQyZi1l NjJhLTRmYWMtYTE5YS1hNTNmMzI3N2FhMjRd4ZCnDQoNCk9uIE1vbiwgU2VwIDMwLCAyMDE5IGF0 IDI6NTMgQU0gRGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPG1haWx0bzpk YXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWs+PiB3cm90ZToNClNvIGFsdGhvdWdoIGZvciB0aGlz IHNwZWMsIHJlcXVlc3RfdXJpIGlzIGp1c3QgYW4gb3BhcXVlIHN0cmluZywgaXQgaXMgZGVmaW5l ZCBtb3JlIGdlbmVyYWxseSBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1qd3NyZXEtMTkjc2VjdGlvbi0yLjIgYXMgYW46DQoNCiBBYnNvbHV0ZSBVUkkgZnJv bSB3aGljaCB0aGUgUmVxdWVzdCBPYmplY3QgKFNlY3Rpb24gMi4xKSBjYW4gYmUgb2J0YWluZWQN Cg0KQW5kIGluIHNlY3Rpb24gNS4yIGFzOg0KDQpUaGUgInJlcXVlc3RfdXJpIiB2YWx1ZSBNVVNU IGJlIGVpdGhlciBVUk4gYXMgZGVmaW5lZCBpbg0KICAgUkZDODE0MSBbUkZDODE0MV0gb3IgImh0 dHBzIiBVUkksIGFzIGRlZmluZWQgaW4gMi43LjIgb2YgUkZDNzIzMA0KICAgW1JGQzcyMzBdIC4g IFRoZSAicmVxdWVzdF91cmkiIHZhbHVlIE1VU1QgYmUgcmVhY2hhYmxlIGJ5IHRoZQ0KICAgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIuDQoNClNvIHRoaXMgaXMgd2h5IGluIHRoZSBzcGVjIHdlIGhhdmUg ZXhhbXBsZSBvZiBhIFVSTiBhbmQgd2UgaGF2ZSBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYXMgdG8g d2hldGhlciB3ZSBzaG91bGQgaGF2ZSBhIHN0YW5kYXJkIHVybiBuYW1lc3BhY2UgdGhhdCB3ZSBy ZWNvbW1lbmQgaW1wbGVtZW50ZXJzIHVzZS4NCg0KSW4gdGhlIGludGVyZXN0IG9mIGtlZXBpbmcg dGhlIHNwZWNzIGluIHN5bmMgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBrZWVwIGl0IGEgVVJO IGZvciB0aGlzIHNwZWMsIGJ1dCB3aXRoIG1vcmUgb2YgYW4gZXhwbGFuYXRpb24gYXMgdG8gd2h5 Pw0KDQpEYXZlDQoNCk9uIEZyaSwgMjcgU2VwIDIwMTkgYXQgMTk6MjIsIERpY2sgSGFyZHQgPGRp Y2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0K SWYgSSB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCBjb3JyZWN0bHksIHRoZSByZXF1ZXN0IFVSSSBp cyBvcGFxdWUgdG8gdGhlIGNsaWVudC4gQ29ycmVjdD8NCg0KSWYgc28sIHdoeSBub3QganVzdCB0 cmVhdCBpdCBhcyBhbiBvcGFxdWUgc3RyaW5nPw0KDQpJZiBJIHdlcmUgaW1wbGVtZW50aW5nIHRo ZSBwcm90b2NvbCwgSSB3b3VsZCBoYXZlIHRoZSBibG9iIGJlIGEgc2lnbmVkIHRva2VuIHNvIHRo YXQgSSBjb3VsZCB2ZXJpZnkgdGhlIGludGVncml0eSBiZWZvcmUgbWFraW5nIGEgZGF0YWJhc2Ug Y2FsbC4gSXQgbXVjaCBlYXNpZXIgdG8gdGhyb3cgY29tcHV0ZSBhdCBhIERET1MgYXR0YWNrIHRv IHZlcmlmeSBhIHNpZ25hdHVyZSwgdGhhbiBEQiBjYXBhY2l0eS4NCg0KW2h0dHBzOi8vbWFpbGZv b2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNE JnR5cGU9emVyb2NvbnRlbnQmZ3VpZD00MzJjYTJmYi1jMWQ1LTQxMWYtYWE4NC0yMzU0MmViYWI3 ZTFd4ZCnDQoNCk9uIFRodSwgU2VwIDI2LCAyMDE5IGF0IDI6MjQgUE0gSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNClllcywgdGhl IHJlcXVlc3Qgb2JqZWN0IGlzIEpXVC1iYXNlZCwgYnV0IHRoZSByZXF1ZXN0IFVSSSBpcyBub3Qu IEluIG90aGVyIHdvcmRzLCB5b3UgY2FuIHBvc3QgYSBKV1QgYnV0IHdoYXQgeW91IGdldCBiYWNr IGlzIGEgVVJJLCBub3QgdGhlIEpXVCBpdHNlbGYuICBUaGUgcmVxdWVzdCBVUkkgd2FzIGFsd2F5 cyBtZWFudCB0byBiZSBhIHJlZmVyZW5jZSwgYW5kIG9yaWdpbmFsbHkgaXQgd2FzIGV4cGxpY2l0 bHkgYSByZWZlcmVuY2UgdG8gYSBzaWduZWQgcmVxdWVzdCBvYmplY3QuDQoNCuKAlCBKdXN0aW4N Cg0KT24gU2VwIDI2LCAyMDE5LCBhdCAxMDowMyBBTSwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFy ZWNraS5jb208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6DQoNClRoZSBVUkkgaXMg aW50ZW5kZWQgdG8gYmUgYSByZWZlcmVuY2Ugbm90IGEgdmFsdWUuLiBJZiB0aGUgY2xpZW50IGNv dWxkIHNlbmQgYSBKV1QgaXQgd291bGQganVzdCBzZW5kIGEgcmVxdWVzdCBvYmplY3QgaW5zdGVh ZCBvZiBhIHJlcXVlc3QgVVJJIGluIHRoZSBmaXJzdCBwbGFjZS4gU28gdGhlIGludGVudCBpcyB0 aGF0IGl04oCZcyByYW5kb20sIGFuZCBtYXliZSB3ZSBzaG91bGQganVzdCBzYXkgdGhhdCBleHBs aWNpdGx5Lg0KDQpJIHRob3VnaHQgdGhpcyBsYW5ndWFnZSB3YXMgZXhwbGljaXRseSB0byBhbGxv dyB0aGUgdXNlIG9mIHN0cnVjdHVyZWQNCnZhbHVlcyBmb3IgdGhlIHJlcXVlc3RfdXJpPyBGcm9t IHRoZSBpbnRyb2R1Y3Rpb246DQoNCmJ1dCBpdCBhbHNvIGFsbG93cyBjbGllbnRzIHJlcXVpcmlu ZyBhbiBldmVuDQpoaWdoZXIgc2VjdXJpdHkgbGV2ZWwsIGVzcGVjaWFsbHkgY3J5cHRvZ3JhcGhp Y2FsbHkgY29uZmlybWVkIG5vbi0NCnJlcHVkaWF0aW9uLCB0byBleHBsaWNpdGx5IGFkb3B0IEpX VC1iYXNlZCByZXF1ZXN0IG9iamVjdHMuDQoNCi0tLS0NCkFhcm9uIFBhcmVja2kNCmFhcm9ucGFy ZWNraS5jb208aHR0cDovL2Fhcm9ucGFyZWNraS5jb20vPg0KDQpPbiBUaHUsIFNlcCAyNiwgMjAx OSBhdCA2OjQ5IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hl ckBtaXQuZWR1Pj4gd3JvdGU6DQoNCkFhcm9uLCBzb21lIGNvbW1lbnRzIGlubGluZS4NCg0K4oCU IEp1c3Rpbg0KDQpPbiBTZXAgMjYsIDIwMTksIGF0IDg6MzAgQU0sIEFhcm9uIFBhcmVja2kgPGFh cm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KDQpIaSBU b3JzdGVuLA0KDQpJJ20gdmVyeSBnbGFkIHRvIHNlZSB0aGlzIGRyYWZ0LCBJIHRoaW5rIGl0J3Mg ZGVmaW5pdGVseSBuZWVkZWQgaW4NCnRoaXMgc3BhY2UuIEhlcmUgYXJlIHNvbWUgb2YgbXkgdGhv dWdodHMgb24gdGhlIGRyYWZ0Lg0KDQoicmVxdWVzdF91cmkiOiAidXJuOmV4YW1wbGU6YndjNEpL LUVTQzB3OGFjYzE5MWUtWTFMVEMyIg0KDQoNCklzIGl0IGFjY2VwdGFibGUgZm9yIHRoZSBBUyB0 byByZXR1cm4ganVzdCBhbiBvcGFxdWUgc3RyaW5nLCByYXRoZXINCnRoYW4gc29tZXRoaW5nIHBy ZWZpeGVkIHdpdGggInVyaToqIj8gSSBkb24ndCB0aGluayBhbnlvbmUgd291bGQgYmUNCmNvbmZ1 c2VkIGFib3V0IGNvcHlwYXN0aW5nIHRoZSBleGFjdCBzdHJpbmcgZnJvbSB0aGUgInJlcXVlc3Rf dXJpIg0KcmVzcG9uc2UgaW50byB0aGUgInJlcXVlc3RfdXJpIiBwYXJhbWV0ZXIgZXZlbiBpZiBp dCBkaWRuJ3Qgc3RhcnQgd2l0aA0KInVybjoiLiBJZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgaXQg aXMgcmVxdWlyZWQgdGhhdCB0aGlzIHZhbHVlIGlzDQphY3R1YWxseSBhIFVSSSwgaXMgdGhlcmUg c29tZSBleHBlY3RlZCBuYW1lc3BhY2UgdG8gdXNlIG90aGVyIHRoYW4NCiJleGFtcGxlIj8gSSB3 b3JyeSB0aGF0IGlmIGFsbCB0aGUgZXhhbXBsZXMgaW4gdGhlIHNwZWMgYXJlIGp1c3QNCiJ1cm46 ZXhhbXBsZTpid2M0SkstRVNDMHc4YWNjMTkxZS1ZMUxUQzIiIHRoZW4gZGV2ZWxvcGVycyB3aWxs IGVuZCB1cA0KdXNpbmcgdGhlIHRleHQgImV4YW1wbGUiIGJlY2F1c2UgdGhleSBkb24ndCB1bmRl cnN0YW5kIHdoeSBpdCdzIHRoZXJlLA0KYW5kIHRoZW4gaXQgc2VydmVzIG5vIHB1cnBvc2UgcmVh bGx5LuKAmQ0KDQoNClRoaXMgZmllbGQgbXVzdCBiZSBhIFVSSSwgYXMgcGVyIEpBUjoNCg0KICBy ZXF1ZXN0X3VyaSAgVGhlIGFic29sdXRlIFVSSSBhcyBkZWZpbmVkIGJ5IFJGQzM5ODYgW1JGQzM5 ODZdIHRoYXQNCiAgICAgcG9pbnRzIHRvIHRoZSBSZXF1ZXN0IE9iamVjdCAoU2VjdGlvbiAyLjEp IHRoYXQgaG9sZHMNCiAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHBhcmFtZXRlcnMgc3RhdGVk IGluIHNlY3Rpb24gNCBvZiBPQXV0aCAyLjANCiAgICAgW1JGQzY3NDldLg0KDQpTb21ld2hhdCBh d2t3YXJkbHksIHRoZSBKQVIgc3BlYyBjdXJyZW50bHkgc3RhdGVzIHRoYXQgdGhlIEFTIGhhcyB0 byBkbyBhbiBIVFRQIEdFVCBvbiB0aGUgcmVxdWVzdCBVUkksIHNvIHRoYXQgd2lsbCBuZWVkIHRv IGJlIGZpeGVkIGluIEpBUiBiZWZvcmUgaXQgZ29lcyBmb3J3YXJkLiBJIGRvbuKAmXQgdGhpbmsg dGhhdCB3YXMgYWx3YXlzIHRoZSBjYXNlIHRob3VnaCwgYW5kIEnigJltIG5vdCBzdXJlIGhvdyB0 aGF0IGNoYW5nZWQuDQoNCkFzIGZvciB0aGUgbmFtZXNwYWNlLCDigJxleGFtcGxl4oCdIGlzIG9r IGZvciBhbiBleGFtcGxlIFVSTi4gVGhlIHByb2JsZW0gd2l0aCBVUk5zIGlzIHRoYXQgbm9ib2R5 IHJlYWxseSB1bmRlcnN0YW5kcyBob3cgdG8gZG8gZG9tYWluLXNhZmUgZnVsbHkgY29tcGxpYW50 IFVSTnMuIFNvIHBlcmhhcHMgd2Ugc2hvdWxkIGluc3RlYWQgdXNlIOKAnHVybjpmZGM6ZXhhbXBs ZS5jb208aHR0cDovL2V4YW1wbGUuY29tPjrigKYu4oCdIEluc3RlYWQgKGFzIHBlciBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDE5OCkuDQoNCg0KVGhlIHB1c2hlZCBhdXRob3JpemF0 aW9uIHJlcXVlc3QgZW5kcG9pbnQgc2hhbGwgYmUgYSBSRVNUZnVsIEFQSQ0KDQoNCkkgd291bGQg ZHJvcCB0aGUgdGVybSBSRVNUZnVsIGFuZCBqdXN0IHNheSAiSFRUUCBBUEkiLCBhcyB0aGlzDQpk ZXNjcmlwdGlvbiBpcyBhcmd1YWJseSBSRVNUZnVsIGF0IGJlc3QuDQoNCkRlcGVuZGluZyBvbiBj bGllbnQgdHlwZSBhbmQgYXV0aGVudGljYXRpb24gbWV0aG9kLCB0aGUgcmVxdWVzdCBtaWdodA0K YWxzbyBpbmNsdWRlIHRoZSAiY2xpZW50X2lkIiBwYXJhbWV0ZXIuDQoNCg0KSSBhc3N1bWUgdGhp cyBpcyBoaW50aW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHMNCnNl bmRpbmcgb25seSB0aGUgImNsaWVudF9pZCIgcGFyYW1ldGVyIGFuZCBjb25maWRlbnRpYWwgY2xp ZW50cw0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRpb24gaGVhZGVyIHdo aWNoIGluY2x1ZGVzIGJvdGgNCnRoZSBjbGllbnQgSUQgYW5kIHNlY3JldD8gSXQgd291bGQgcHJv YmFibHkgYmUgaGVscGZ1bCB0byBjYWxsIG91dA0KdGhlc2UgdHdvIGNvbW1vbiBleGFtcGxlcyBp ZiBJIGFtIHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksDQpvdGhlcndpc2UgaXQgc2VlbXMg cHJldHR5IHZhZ3VlLg0KDQoNCk5vdCBxdWl0ZSwgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIGZvciB0 aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCB0aGlzIGlzIGNhcHR1cmluZyB0aGluZ3MgZnJvbSB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludC4gSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGRp ZmZlcmVudGlhdGlvbiBsaXN0ZWQgaGVyZSBlaXRoZXIsIHRob3VnaC4NCg0KDQpUaGUgInJlcXVl c3RfdXJpIiB2YWx1ZSBNVVNUIGJlIGdlbmVyYXRlZCB1c2luZyBhIGNyeXB0b2dyYXBoaWNhbGx5 DQpzdHJvbmcgcHNldWRvcmFuZG9tIGFsZ29yaXRobQ0KDQoNCkkgYXNzdW1lIHRoaXMgaW5jbHVk ZXMgdGhlIHVzZSBvZiBhIHJhbmRvbSBudW1iZXIgaW5zaWRlIG9mIGEgSldULCBpbg0KY2FzZSB0 aGUgQVMgd2FudHMgdG8gdXNlIEpXVHMgYXMgdGhlICJyZXF1ZXN0X3VyaSIgcGFyYW1ldGVyIj8g SWYgc28sDQppdCdzIHByb2JhYmx5IHdvcnRoIHNwZWxsaW5nIHRoYXQgb3V0IGFzIGl0IGtpbmQg b2YgcmVhZHMgbGlrZSBpdCBoYXMNCnRvIGJlIGxpdGVyYWxseSBhIHJhbmRvbSBzdHJpbmcgYXQg Zmlyc3QgZ2xhbmNlLg0KDQoNClRoZSBVUkkgaXMgaW50ZW5kZWQgdG8gYmUgYSByZWZlcmVuY2Ug bm90IGEgdmFsdWUuIElmIHRoZSBjbGllbnQgY291bGQgc2VuZCBhIEpXVCBpdCB3b3VsZCBqdXN0 IHNlbmQgYSByZXF1ZXN0IG9iamVjdCBpbnN0ZWFkIG9mIGEgcmVxdWVzdCBVUkkgaW4gdGhlIGZp cnN0IHBsYWNlLiBTbyB0aGUgaW50ZW50IGlzIHRoYXQgaXTigJlzIHJhbmRvbSwgYW5kIG1heWJl IHdlIHNob3VsZCBqdXN0IHNheSB0aGF0IGV4cGxpY2l0bHkuDQoNCg0KVGhhdCdzIGFsbCBmb3Ig bm93LCB0aGFua3MhDQoNCi0tLS0NCkFhcm9uIFBhcmVja2kNCmFhcm9ucGFyZWNraS5jb208aHR0 cDovL2Fhcm9ucGFyZWNraS5jb20vPg0KQGFhcm9ucGsNCg0KT24gU2F0LCBTZXAgMjEsIDIwMTkg YXQgMTowMiBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0DQo8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQoNCg0KSGkgYWxsLA0KDQpJ IGp1c3QgcHVibGlzaGVkIGEgbmV3IGRyYWZ0IHRoYXQgQnJpYW4gQ2FtcGJlbGwsIERhdmUgVG9u Z2UsIEZpbGlwIFNrb2thbiwgTmF0IFNha2ltdXJhIGFuZCBJIHdyb3RlLg0KDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAwDQoNCkl0IHBy b3Bvc2VzIGEgbmV3IGVuZHBvaW50LCBjYWxsZWQgInB1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVl c3QgZW5kcG9pbnTigJ0sIHRoYXQgYWxsb3dzIHRoZSBjbGllbnQgdG8gcHVzaCB0aGUgQXV0aG9y aXphdGlvbiBSZXF1ZXN0IHBheWxvYWQgd2l0aCB0aGUgQVMgb24gYSBiYWNrY2hhbm5lbCBjb25u ZWN0aW9uIGluc3RlYWQgb2YgYSBmcm9udCBjaGFubmVsIGludGVyYWN0aW9uLiBUaGUgQVMgcHJv dmlkZXMgdGhlIGNsaWVudCB3aXRoIGEgcmVxdWVzdCBVUkkgKGFjY29yZGluZyB0byBkcmFmdC1p ZXRmLW9hdXRoLWp3c3JlcSkgdGhhdCB0aGUgY2xpZW50IHVzZXMgaW4gYSBzdWJzZXF1ZW50IGF1 dGhvcml6YXRpb24gcmVxdWVzdHMgdG8gcmVmZXIgdG8gdGhlIHB1c2hlZCByZXF1ZXN0IGRhdGEu DQoNCldlIGJlbGlldmUgdGhpcyBzaW1wbGUgbWVjaGFuaXNtIHdpbGwgc2lnbmlmaWNhbnRseSBp bmNyZWFzZSBPQXV0aCBzZWN1cml0eSBhbmQgcm9idXN0bmVzcyBzaW5jZSBhbnkgYXBwbGljYXRp b24gY2FuIHVzZSBpdCBieSBqdXN0IHNlbmRpbmcgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIHNhbWUg ZW5jb2RpbmcgYXMgdXNlZCBhdCB0aGUgYXV0aG9yaXNhdGlvbiBlbmRwb2ludCBvdmVyIGEgSFRU UFMtcHJvdGVjdGVkIGFuZCAoZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzKSBtdXR1YWxseSBhdXRo ZW50aWNhdGVkIGNvbm5lY3Rpb24gdG8gdGhlIEFTLiBJdCBjYW4gYWxzbyBiZSB1c2VkIHRvIHB1 c2ggc2lnbmVkIGFuZCBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3RzIHRvIHRoZSBBUywgaS5lLiBp dCBwcm92aWRlcyBhbiBpbnRlcm9wZXJhYmxlIHdheSB0byB1c2UgcmVxdWVzdCBvYmplY3RzIG1h bmFnZWQgYXQgdGhlIEFTIGZvciB1c2UgY2FzZXMgcmVxdWlyaW5nIGFuIGV2ZW4gaGlnaGVyIHNl Y3VyaXR5IGxldmVsLg0KDQpXZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5b3VyIGZlZWRiYWNr Lg0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToN Cg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxv ZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQNCkRhdGU6IDIxLiBTZXB0ZW1iZXIgMjAxOSBhdCAx Mjo0NzoyOCBDRVNUDQpUbzogIk5hdCBTYWtpbXVyYSIgPG5hdEBzYWtpbXVyYS5vcmc8bWFpbHRv Om5hdEBzYWtpbXVyYS5vcmc+PiwgIkJyaWFuIENhbXBiZWxsIiA8YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4sICJUb3JzdGVuIExv ZGRlcnN0ZWR0IiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Pj4sICJEYXZlIFRvbmdlIiA8ZGF2ZUB0b25nZS5vcmc8bWFpbHRvOmRhdmVAdG9u Z2Uub3JnPj4sICJGaWxpcCBTa29rYW4iIDxwYW52YS5pcEBnbWFpbC5jb208bWFpbHRvOnBhbnZh LmlwQGdtYWlsLmNvbT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxvZGRlcnN0 ZWR0LW9hdXRoLXBhci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg VG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOiBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXINClJldmlzaW9uOiAwMA0KVGl0bGU6 IE9BdXRoIDIuMCBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0cw0KRG9jdW1lbnQgZGF0ZTog MjAxOS0wOS0yMQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEyDQpVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxv ZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXIvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9h dXRoLXBhci0wMDxodHRwczovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0 LW9hdXRoLXBhci0wMD4NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhcg0KDQoNCkFic3RyYWN0Og0K VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGVu ZHBvaW50LA0Kd2hpY2ggYWxsb3dzIGNsaWVudHMgdG8gcHVzaCB0aGUgcGF5bG9hZCBvZiBhbiBP QXV0aCAyLjANCmF1dGhvcml6YXRpb24gcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdmlhIGEgZGlyZWN0DQpyZXF1ZXN0IGFuZCBwcm92aWRlcyB0aGVtIHdpdGggYSByZXF1ZXN0 IFVSSSB0aGF0IGlzIHVzZWQgYXMNCnJlZmVyZW5jZSB0byB0aGUgZGF0YSBpbiBhIHN1YnNlcXVl bnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZy8+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQoNCg0KLS0NCg0KDQo= --_000_48D647991A8040D0B5A0D90F9BD42DA5mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <938BC3A1503A6D4192F1F7C200F6E89E@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRvIGJlIGNsZWFyLCBQQVIgaXMgbm90IHRoZSBz YW1lIGFzIFhZWi4gQm90aCBhcmUgZ29pbmcgdG8gYmUgaW5wdXRzIGludG8gdGhlIGNvbnZlcnNh dGlvbiB1bmRlciB0eGF1dGgsIGFuZCB0aGVyZSBhcmUgc2ltaWxhcml0aWVzLCBidXQgdGhleSBz aG91bGRu4oCZdCBiZSBjb25mbGF0ZWQuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBQQVIsIHRoZSByZXN1bHQgaGFzIHRvIGJlIGEg VVJJIGJlY2F1c2UgdGhhdOKAmXMgd2hhdCBKQVIgZGVmaW5lcyBhcyB0aGUgaW5wdXQuIFdpdGgg WFlaLCB5b3UgZ2V0IHJldHVybmVkIHR3byB0aGluZ3M6IGEgdHJhbnNhY3Rpb24gaGFuZGxlIGFu ZCBhbiBpbnRlcmFjdGlvbiBVUkkuIFRoZXNlIGFyZSBib3RoIG9wYXF1ZSB0byB0aGUgY2xpZW50 LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMzAs IDIwMTksIGF0IDg6MzMgQU0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbSIgY2xhc3M9IiI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SSBjYW4gdW5kZXJzdGFuZCB0aGUgcmVx dWVzdCBVUkkgYmVpbmcgYSBVUkkgdGhhdCB0aGUgY2xpZW50IGlzIHByb3ZpZGluZyB0aGUgQVMs IGJ1dCB3aHkgd291bGQgdGhlIGNsaWVudCdzIHJlcXVlc3QgVVJJIGJlIGF0IHRoZSBBUz8NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFzIEp1c3Rp biBoYXMgZXhwbGFpbmVkIGl0IGluIHRoZSBwYXN0LCB0aGUgQVMgaXMgcmV0dXJuaW5nJm5ic3A7 YSBoYW5kbGUgdG8gdGhlIHRyYW5zYWN0aW9uLiBUaGUgb25seSBwYXJ0eSB0aGF0IHVuZGVyc3Rh bmRzIHRoYXQgaGFuZGxlIGFzIGZhciBhcyBJIGtub3cgaXMgdGhlIEFTLiBJdCBpcyBtZWFuaW5n bGVzcyB0byB0aGUgY2xpZW50LiBQZXJoYXBzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgZWxzZT88 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBoc3BhY2U9InN0cmVhay1wdC1tYXJrIiBzdHlsZT0ibWF4LWhl aWdodDoxcHgiIGNsYXNzPSIiPjxpbWcgYWx0PSIiIHN0eWxlPSJ3aWR0aDowcHg7bWF4LWhlaWdo dDowcHg7b3ZlcmZsb3c6aGlkZGVuIiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9j b250ZW50JmFtcDtndWlkPTEzODlkZDJmLWU2MmEtNGZhYy1hMTlhLWE1M2YzMjc3YWEyNCIgY2xh c3M9IiI+PGZvbnQgY29sb3I9IiNmZmZmZmYiIHNpemU9IjEiIGNsYXNzPSIiPuGQpzwvZm9udD48 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIFNlcCAzMCwgMjAxOSBhdCAyOjUzIEFN IERhdmUgVG9uZ2UgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlLnRvbmdlQG1vbWVudHVtZnQuY28u dWsiIGNsYXNzPSIiPmRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDt0cmVidWNoZXQgbXMmcXVvdDssc2Fucy1zZXJpZiI+U28gYWx0 aG91Z2ggZm9yIHRoaXMgc3BlYywgcmVxdWVzdF91cmkgaXMganVzdCBhbiBvcGFxdWUgc3RyaW5n LCBpdCBpcyBkZWZpbmVkIG1vcmUgZ2VuZXJhbGx5IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE5I3NlY3Rpb24tMi4y IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtandzcmVxLTE5I3NlY3Rpb24tMi4yPC9hPg0KIGFzIGFuOjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O3RyZWJ1 Y2hldCBtcyZxdW90OyxzYW5zLXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4N CjxpIGNsYXNzPSIiPiZuYnNwO0Fic29sdXRlIFVSSSBmcm9tIHdoaWNoIHRoZSBSZXF1ZXN0IE9i amVjdCAoU2VjdGlvbiAyLjEpIGNhbiBiZSBvYnRhaW5lZDwvaT48L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0 IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O3RyZWJ1Y2hldCBtcyZxdW90 OyxzYW5zLXNlcmlmIj5BbmQgaW4gc2VjdGlvbiA1LjIgYXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7 LHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQs MjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGkgY2xhc3M9IiI+ VGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7IHZhbHVlIE1VU1QgYmUgZWl0aGVyIFVSTiBhcyBk ZWZpbmVkIGluPGJyIGNsYXNzPSIiPg0KPC9pPjxpIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtSRkM4 MTQxIFtSRkM4MTQxXSBvciAmcXVvdDtodHRwcyZxdW90OyBVUkksIGFzIGRlZmluZWQgaW4gMi43 LjIgb2YgUkZDNzIzMDxiciBjbGFzcz0iIj4NCjwvaT48aSBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7 W1JGQzcyMzBdIC4mbmJzcDsgVGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7IHZhbHVlIE1VU1Qg YmUgcmVhY2hhYmxlIGJ5IHRoZTxiciBjbGFzcz0iIj4NCjwvaT48aSBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7QXV0aG9yaXphdGlvbiBTZXJ2ZXIuPC9pPjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDt0cmVidWNoZXQgbXMmcXVv dDssc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMt c2VyaWYiPlNvIHRoaXMgaXMgd2h5IGluIHRoZSBzcGVjIHdlIGhhdmUgZXhhbXBsZSBvZiBhIFVS TiBhbmQgd2UgaGF2ZSBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYXMgdG8gd2hldGhlciB3ZSBzaG91 bGQgaGF2ZSBhIHN0YW5kYXJkIHVybiBuYW1lc3BhY2UgdGhhdCB3ZSByZWNvbW1lbmQgaW1wbGVt ZW50ZXJzIHVzZS48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDt0cmVidWNoZXQgbXMmcXVvdDssc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBpbnRlcmVzdCBvZiBr ZWVwaW5nIHRoZSBzcGVjcyBpbiBzeW5jIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8ga2VlcCBp dCBhIFVSTiBmb3IgdGhpcyBzcGVjLCBidXQgd2l0aCBtb3JlIG9mIGFuIGV4cGxhbmF0aW9uIGFz IHRvIHdoeT88L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDt0cmVidWNoZXQgbXMmcXVvdDssc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPkRhdmU8L2Rpdj4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9ImdtYWlsX2F0dHIiPk9uIEZyaSwgMjcgU2VwIDIwMTkgYXQgMTk6MjIsIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5JZiBJIHVuZGVyc3Rh bmQgdGhlIHByb3Bvc2FsIGNvcnJlY3RseSwgdGhlIHJlcXVlc3QgVVJJIGlzIG9wYXF1ZSB0byB0 aGUgY2xpZW50LiBDb3JyZWN0Pw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SWYgc28sIHdoeSBub3QganVzdCB0cmVhdCBpdCBhcyBhbiBvcGFxdWUg c3RyaW5nPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SWYgSSB3ZXJlIGltcGxlbWVudGluZyB0aGUgcHJvdG9jb2wsIEkgd291bGQgaGF2 ZSB0aGUgYmxvYiBiZSBhIHNpZ25lZCB0b2tlbiBzbyB0aGF0IEkgY291bGQgdmVyaWZ5IHRoZSBp bnRlZ3JpdHkgYmVmb3JlIG1ha2luZyBhIGRhdGFiYXNlIGNhbGwuIEl0IG11Y2ggZWFzaWVyIHRv IHRocm93IGNvbXB1dGUgYXQgYSBERE9TIGF0dGFjayB0byB2ZXJpZnkgYSBzaWduYXR1cmUsIHRo YW4gREIgY2FwYWNpdHkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGhzcGFjZT0ic3RyZWFrLXB0LW1hcmsiIHN0eWxlPSJtYXgtaGVpZ2h0 OjFweCIgY2xhc3M9IiI+PGltZyBhbHQ9IiIgc3R5bGU9IndpZHRoOiAwcHg7IG1heC1oZWlnaHQ6 IDBweDsgb3ZlcmZsb3c6IGhpZGRlbjsiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVy b2NvbnRlbnQmYW1wO2d1aWQ9NDMyY2EyZmItYzFkNS00MTFmLWFhODQtMjM1NDJlYmFiN2UxIiBj bGFzcz0iIj48Zm9udCBjb2xvcj0iI2ZmZmZmZiIgc2l6ZT0iMSIgY2xhc3M9IiI+4ZCnPC9mb250 PjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgU2VwIDI2LCAyMDE5IGF0IDI6MjQg UE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg Y2xhc3M9IiI+WWVzLCB0aGUgcmVxdWVzdCBvYmplY3QgaXMgSldULWJhc2VkLCBidXQgdGhlIHJl cXVlc3QgVVJJIGlzIG5vdC4gSW4gb3RoZXIgd29yZHMsIHlvdSBjYW4gcG9zdCBhIEpXVCBidXQg d2hhdCB5b3UgZ2V0IGJhY2sgaXMgYSBVUkksIG5vdCB0aGUgSldUIGl0c2VsZi4mbmJzcDsgVGhl IHJlcXVlc3QgVVJJIHdhcyBhbHdheXMgbWVhbnQgdG8gYmUgYSByZWZlcmVuY2UsIGFuZCBvcmln aW5hbGx5IGl0IHdhcyBleHBsaWNpdGx5IGEgcmVmZXJlbmNlDQogdG8gYSBzaWduZWQgcmVxdWVz dCBvYmplY3QuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQri gJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAyNiwg MjAxOSwgYXQgMTA6MDMgQU0sIEFhcm9uIFBhcmVja2kgJmx0OzxhIGhyZWY9Im1haWx0bzphYXJv bkBwYXJlY2tpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFhcm9uQHBhcmVja2kuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlRoZSBVUkkgaXMg aW50ZW5kZWQgdG8gYmUgYSByZWZlcmVuY2Ugbm90IGEgdmFsdWUuLiBJZiB0aGUgY2xpZW50IGNv dWxkIHNlbmQgYSBKV1QgaXQgd291bGQganVzdCBzZW5kIGEgcmVxdWVzdCBvYmplY3QgaW5zdGVh ZCBvZiBhIHJlcXVlc3QgVVJJIGluIHRoZSBmaXJzdCBwbGFjZS4gU28gdGhlIGludGVudCBpcyB0 aGF0IGl04oCZcyByYW5kb20sIGFuZCBtYXliZSB3ZSBzaG91bGQganVzdA0KIHNheSB0aGF0IGV4 cGxpY2l0bHkuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSB0 aG91Z2h0IHRoaXMgbGFuZ3VhZ2Ugd2FzIGV4cGxpY2l0bHkgdG8gYWxsb3cgdGhlIHVzZSBvZiBz dHJ1Y3R1cmVkPGJyIGNsYXNzPSIiPg0KdmFsdWVzIGZvciB0aGUgcmVxdWVzdF91cmk/IEZyb20g dGhlIGludHJvZHVjdGlvbjo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5idXQgaXQgYWxzbyBhbGxvd3MgY2xpZW50cyByZXF1aXJp bmcgYW4gZXZlbjxiciBjbGFzcz0iIj4NCmhpZ2hlciBzZWN1cml0eSBsZXZlbCwgZXNwZWNpYWxs eSBjcnlwdG9ncmFwaGljYWxseSBjb25maXJtZWQgbm9uLTxiciBjbGFzcz0iIj4NCnJlcHVkaWF0 aW9uLCB0byBleHBsaWNpdGx5IGFkb3B0IEpXVC1iYXNlZCByZXF1ZXN0IG9iamVjdHMuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KLS0tLTxiciBjbGFzcz0iIj4N CkFhcm9uIFBhcmVja2k8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tp LmNvbS8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5hYXJvbnBhcmVja2kuY29tPC9hPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFRodSwgU2VwIDI2LCAyMDE5IGF0IDY6NDkgUE0g SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkFh cm9uLCBzb21lIGNvbW1lbnRzIGlubGluZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQri gJQgSnVzdGluPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gU2VwIDI2LCAyMDE5LCBh dCA4OjMwIEFNLCBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNr aS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIFRvcnN0ZW4sPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSSdtIHZlcnkgZ2xhZCB0byBzZWUgdGhpcyBkcmFmdCwgSSB0 aGluayBpdCdzIGRlZmluaXRlbHkgbmVlZGVkIGluPGJyIGNsYXNzPSIiPg0KdGhpcyBzcGFjZS4g SGVyZSBhcmUgc29tZSBvZiBteSB0aG91Z2h0cyBvbiB0aGUgZHJhZnQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDs6ICZxdW90O3VybjpleGFtcGxl OmJ3YzRKSy1FU0MwdzhhY2MxOTFlLVkxTFRDMiZxdW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIGl0IGFjY2VwdGFibGUgZm9yIHRoZSBBUyB0byByZXR1 cm4ganVzdCBhbiBvcGFxdWUgc3RyaW5nLCByYXRoZXI8YnIgY2xhc3M9IiI+DQp0aGFuIHNvbWV0 aGluZyBwcmVmaXhlZCB3aXRoICZxdW90O3VyaToqJnF1b3Q7PyBJIGRvbid0IHRoaW5rIGFueW9u ZSB3b3VsZCBiZTxiciBjbGFzcz0iIj4NCmNvbmZ1c2VkIGFib3V0IGNvcHlwYXN0aW5nIHRoZSBl eGFjdCBzdHJpbmcgZnJvbSB0aGUgJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDs8YnIgY2xhc3M9IiI+ DQpyZXNwb25zZSBpbnRvIHRoZSAmcXVvdDtyZXF1ZXN0X3VyaSZxdW90OyBwYXJhbWV0ZXIgZXZl biBpZiBpdCBkaWRuJ3Qgc3RhcnQgd2l0aDxiciBjbGFzcz0iIj4NCiZxdW90O3VybjomcXVvdDsu IElmLCBmb3Igd2hhdGV2ZXIgcmVhc29uLCBpdCBpcyByZXF1aXJlZCB0aGF0IHRoaXMgdmFsdWUg aXM8YnIgY2xhc3M9IiI+DQphY3R1YWxseSBhIFVSSSwgaXMgdGhlcmUgc29tZSBleHBlY3RlZCBu YW1lc3BhY2UgdG8gdXNlIG90aGVyIHRoYW48YnIgY2xhc3M9IiI+DQomcXVvdDtleGFtcGxlJnF1 b3Q7PyBJIHdvcnJ5IHRoYXQgaWYgYWxsIHRoZSBleGFtcGxlcyBpbiB0aGUgc3BlYyBhcmUganVz dDxiciBjbGFzcz0iIj4NCiZxdW90O3VybjpleGFtcGxlOmJ3YzRKSy1FU0MwdzhhY2MxOTFlLVkx TFRDMiZxdW90OyB0aGVuIGRldmVsb3BlcnMgd2lsbCBlbmQgdXA8YnIgY2xhc3M9IiI+DQp1c2lu ZyB0aGUgdGV4dCAmcXVvdDtleGFtcGxlJnF1b3Q7IGJlY2F1c2UgdGhleSBkb24ndCB1bmRlcnN0 YW5kIHdoeSBpdCdzIHRoZXJlLDxiciBjbGFzcz0iIj4NCmFuZCB0aGVuIGl0IHNlcnZlcyBubyBw dXJwb3NlIHJlYWxseS7igJk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGlzIGZpZWxkIG11c3QgYmUgYSBVUkksIGFzIHBlciBKQVI6PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7cmVxdWVzdF91cmkgJm5ic3A7VGhlIGFic29sdXRl IFVSSSBhcyBkZWZpbmVkIGJ5IFJGQzM5ODYgW1JGQzM5ODZdIHRoYXQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwb2ludHMgdG8gdGhlIFJlcXVlc3QgT2JqZWN0 IChTZWN0aW9uIDIuMSkgdGhhdCBob2xkczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2F1dGhvcml6YXRpb24gcmVxdWVzdCBwYXJhbWV0ZXJzIHN0YXRlZCBpbiBz ZWN0aW9uIDQgb2YgT0F1dGggMi4wPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7W1JGQzY3NDldLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvbWV3aGF0 IGF3a3dhcmRseSwgdGhlIEpBUiBzcGVjIGN1cnJlbnRseSBzdGF0ZXMgdGhhdCB0aGUgQVMgaGFz IHRvIGRvIGFuIEhUVFAgR0VUIG9uIHRoZSByZXF1ZXN0IFVSSSwgc28gdGhhdCB3aWxsIG5lZWQg dG8gYmUgZml4ZWQgaW4gSkFSIGJlZm9yZSBpdCBnb2VzIGZvcndhcmQuIEkgZG9u4oCZdCB0aGlu ayB0aGF0IHdhcyBhbHdheXMgdGhlIGNhc2UgdGhvdWdoLCBhbmQgSeKAmW0gbm90IHN1cmUgaG93 IHRoYXQgY2hhbmdlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyBmb3IgdGhlIG5h bWVzcGFjZSwg4oCcZXhhbXBsZeKAnSBpcyBvayBmb3IgYW4gZXhhbXBsZSBVUk4uIFRoZSBwcm9i bGVtIHdpdGggVVJOcyBpcyB0aGF0IG5vYm9keSByZWFsbHkgdW5kZXJzdGFuZHMgaG93IHRvIGRv IGRvbWFpbi1zYWZlIGZ1bGx5IGNvbXBsaWFudCBVUk5zLiBTbyBwZXJoYXBzIHdlIHNob3VsZCBp bnN0ZWFkIHVzZSDigJx1cm46ZmRjOjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSIgY2xhc3M9 IiI+ZXhhbXBsZS5jb208L2E+OuKApi7igJ0NCiBJbnN0ZWFkIChhcyBwZXIgPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxOTgiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTk4PC9hPikuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHB1c2hlZCBhdXRob3JpemF0aW9u IHJlcXVlc3QgZW5kcG9pbnQgc2hhbGwgYmUgYSBSRVNUZnVsIEFQSTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgd291bGQgZHJvcCB0aGUgdGVybSBSRVNUZnVs IGFuZCBqdXN0IHNheSAmcXVvdDtIVFRQIEFQSSZxdW90OywgYXMgdGhpczxiciBjbGFzcz0iIj4N CmRlc2NyaXB0aW9uIGlzIGFyZ3VhYmx5IFJFU1RmdWwgYXQgYmVzdC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpEZXBlbmRpbmcgb24gY2xpZW50IHR5cGUgYW5kIGF1dGhlbnRpY2F0aW9u IG1ldGhvZCwgdGhlIHJlcXVlc3QgbWlnaHQ8YnIgY2xhc3M9IiI+DQphbHNvIGluY2x1ZGUgdGhl ICZxdW90O2NsaWVudF9pZCZxdW90OyBwYXJhbWV0ZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhc3N1bWUgdGhpcyBpcyBoaW50aW5nIGF0IHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHM8YnIgY2xhc3M9IiI+DQpzZW5kaW5nIG9ubHkg dGhlICZxdW90O2NsaWVudF9pZCZxdW90OyBwYXJhbWV0ZXIgYW5kIGNvbmZpZGVudGlhbCBjbGll bnRzPGJyIGNsYXNzPSIiPg0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRp b24gaGVhZGVyIHdoaWNoIGluY2x1ZGVzIGJvdGg8YnIgY2xhc3M9IiI+DQp0aGUgY2xpZW50IElE IGFuZCBzZWNyZXQ/IEl0IHdvdWxkIHByb2JhYmx5IGJlIGhlbHBmdWwgdG8gY2FsbCBvdXQ8YnIg Y2xhc3M9IiI+DQp0aGVzZSB0d28gY29tbW9uIGV4YW1wbGVzIGlmIEkgYW0gdW5kZXJzdGFuZGlu ZyB0aGlzIGNvcnJlY3RseSw8YnIgY2xhc3M9IiI+DQpvdGhlcndpc2UgaXQgc2VlbXMgcHJldHR5 IHZhZ3VlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdCBx dWl0ZSwgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIGZvciB0aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCB0 aGlzIGlzIGNhcHR1cmluZyB0aGluZ3MgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4g SSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudGlhdGlvbiBsaXN0ZWQgaGVy ZSBlaXRoZXIsIHRob3VnaC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGUgJnF1b3Q7cmVxdWVzdF91cmkmcXVvdDsgdmFsdWUgTVVTVCBiZSBnZW5lcmF0ZWQg dXNpbmcgYSBjcnlwdG9ncmFwaGljYWxseTxiciBjbGFzcz0iIj4NCnN0cm9uZyBwc2V1ZG9yYW5k b20gYWxnb3JpdGhtPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SSBhc3N1bWUgdGhpcyBpbmNsdWRlcyB0aGUgdXNlIG9mIGEgcmFuZG9tIG51bWJlciBpbnNpZGUg b2YgYSBKV1QsIGluPGJyIGNsYXNzPSIiPg0KY2FzZSB0aGUgQVMgd2FudHMgdG8gdXNlIEpXVHMg YXMgdGhlICZxdW90O3JlcXVlc3RfdXJpJnF1b3Q7IHBhcmFtZXRlciZxdW90Oz8gSWYgc28sPGJy IGNsYXNzPSIiPg0KaXQncyBwcm9iYWJseSB3b3J0aCBzcGVsbGluZyB0aGF0IG91dCBhcyBpdCBr aW5kIG9mIHJlYWRzIGxpa2UgaXQgaGFzPGJyIGNsYXNzPSIiPg0KdG8gYmUgbGl0ZXJhbGx5IGEg cmFuZG9tIHN0cmluZyBhdCBmaXJzdCBnbGFuY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KVGhlIFVSSSBpcyBpbnRlbmRlZCB0byBiZSBhIHJlZmVyZW5jZSBu b3QgYSB2YWx1ZS4gSWYgdGhlIGNsaWVudCBjb3VsZCBzZW5kIGEgSldUIGl0IHdvdWxkIGp1c3Qg c2VuZCBhIHJlcXVlc3Qgb2JqZWN0IGluc3RlYWQgb2YgYSByZXF1ZXN0IFVSSSBpbiB0aGUgZmly c3QgcGxhY2UuIFNvIHRoZSBpbnRlbnQgaXMgdGhhdCBpdOKAmXMgcmFuZG9tLCBhbmQgbWF5YmUg d2Ugc2hvdWxkIGp1c3Qgc2F5IHRoYXQgZXhwbGljaXRseS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGF0J3MgYWxsIGZvciBub3csIHRoYW5rcyE8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tPGJyIGNsYXNzPSIiPg0KQWFyb24gUGFyZWNraTxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9hYXJvbnBhcmVja2kuY29tLyIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPmFhcm9ucGFyZWNraS5jb208L2E+PGJyIGNsYXNzPSIiPg0KQGFhcm9u cGs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBTYXQsIFNlcCAyMSwgMjAxOSBhdCAx OjAyIFBNIFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBhbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyBkcmFmdCB0aGF0IEJyaWFuIENhbXBiZWxsLCBEYXZl IFRvbmdlLCBGaWxpcCBTa29rYW4sIE5hdCBTYWtpbXVyYSBhbmQgSSB3cm90ZS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAwIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0w MDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBwcm9wb3NlcyBhIG5ldyBlbmRw b2ludCwgY2FsbGVkICZxdW90O3B1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVlc3QgZW5kcG9pbnTi gJ0sIHRoYXQgYWxsb3dzIHRoZSBjbGllbnQgdG8gcHVzaCB0aGUgQXV0aG9yaXphdGlvbiBSZXF1 ZXN0IHBheWxvYWQgd2l0aCB0aGUgQVMgb24gYSBiYWNrY2hhbm5lbCBjb25uZWN0aW9uIGluc3Rl YWQgb2YgYSBmcm9udCBjaGFubmVsIGludGVyYWN0aW9uLiBUaGUgQVMgcHJvdmlkZXMgdGhlIGNs aWVudCB3aXRoIGEgcmVxdWVzdA0KIFVSSSAoYWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtb2F1dGgt andzcmVxKSB0aGF0IHRoZSBjbGllbnQgdXNlcyBpbiBhIHN1YnNlcXVlbnQgYXV0aG9yaXphdGlv biByZXF1ZXN0cyB0byByZWZlciB0byB0aGUgcHVzaGVkIHJlcXVlc3QgZGF0YS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpXZSBiZWxpZXZlIHRoaXMgc2ltcGxlIG1lY2hhbmlzbSB3aWxs IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgT0F1dGggc2VjdXJpdHkgYW5kIHJvYnVzdG5lc3Mgc2lu Y2UgYW55IGFwcGxpY2F0aW9uIGNhbiB1c2UgaXQgYnkganVzdCBzZW5kaW5nIHRoZSBwYXJhbWV0 ZXJzIGluIHRoZSBzYW1lIGVuY29kaW5nIGFzIHVzZWQgYXQgdGhlIGF1dGhvcmlzYXRpb24gZW5k cG9pbnQgb3ZlciBhIEhUVFBTLXByb3RlY3RlZCBhbmQgKGZvciBjb25maWRlbnRpYWwNCiBjbGll bnRzKSBtdXR1YWxseSBhdXRoZW50aWNhdGVkIGNvbm5lY3Rpb24gdG8gdGhlIEFTLiBJdCBjYW4g YWxzbyBiZSB1c2VkIHRvIHB1c2ggc2lnbmVkIGFuZCBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3Rz IHRvIHRoZSBBUywgaS5lLiBpdCBwcm92aWRlcyBhbiBpbnRlcm9wZXJhYmxlIHdheSB0byB1c2Ug cmVxdWVzdCBvYmplY3RzIG1hbmFnZWQgYXQgdGhlIEFTIGZvciB1c2UgY2FzZXMgcmVxdWlyaW5n IGFuIGV2ZW4gaGlnaGVyIHNlY3VyaXR5DQogbGV2ZWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KV2UgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVkYmFjay48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpraW5kIHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KVG9yc3Rlbi48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAwLnR4dDxiciBjbGFzcz0iIj4N CkRhdGU6IDIxLiBTZXB0ZW1iZXIgMjAxOSBhdCAxMjo0NzoyOCBDRVNUPGJyIGNsYXNzPSIiPg0K VG86ICZxdW90O05hdCBTYWtpbXVyYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hdEBzYWtp bXVyYS5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5uYXRAc2FraW11cmEub3JnPC9hPiZn dDssICZxdW90O0JyaWFuIENhbXBiZWxsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5iY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7LCAmcXVvdDtUb3JzdGVuIExvZGRlcnN0ZWR0JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7LA0KICZxdW90O0Rh dmUgVG9uZ2UmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlQHRvbmdlLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPmRhdmVAdG9uZ2Uub3JnPC9hPiZndDssICZxdW90O0ZpbGlwIFNr b2thbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMC50eHQ8YnIgY2xhc3M9IiI+DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5kIHBvc3RlZCB0 byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmFtZTogZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyPGJyIGNsYXNzPSIiPg0K UmV2aXNpb246IDAwPGJyIGNsYXNzPSIiPg0KVGl0bGU6IE9BdXRoIDIuMCBQdXNoZWQgQXV0aG9y aXphdGlvbiBSZXF1ZXN0czxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6IDIwMTktMDktMjE8 YnIgY2xhc3M9IiI+DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0K UGFnZXM6IDEyPGJyIGNsYXNzPSIiPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcGFyLTAw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1wYXItMDAudHh0PC9hPjxiciBjbGFz cz0iIj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9k ZGVyc3RlZHQtb2F1dGgtcGFyLyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci88L2E+PGJy IGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQt b2F1dGgtcGFyLTAwIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhci0wMDwvYT48YnIgY2xhc3M9IiI+ DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1v YXV0aC1wYXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXBhcjwvYT48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+ DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHB1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVlc3Qg ZW5kcG9pbnQsPGJyIGNsYXNzPSIiPg0Kd2hpY2ggYWxsb3dzIGNsaWVudHMgdG8gcHVzaCB0aGUg cGF5bG9hZCBvZiBhbiBPQXV0aCAyLjA8YnIgY2xhc3M9IiI+DQphdXRob3JpemF0aW9uIHJlcXVl c3QgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHZpYSBhIGRpcmVjdDxiciBjbGFzcz0iIj4N CnJlcXVlc3QgYW5kIHByb3ZpZGVzIHRoZW0gd2l0aCBhIHJlcXVlc3QgVVJJIHRoYXQgaXMgdXNl ZCBhczxiciBjbGFzcz0iIj4NCnJlZmVyZW5jZSB0byB0aGUgZGF0YSBpbiBhIHN1YnNlcXVlbnQg YXV0aG9yaXphdGlvbiByZXF1ZXN0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCi0tIDxiciBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOjFlbTtmb250LXdlaWdodDpib2xkO2xpbmUtaGVpZ2h0OjEuNCIgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoOTcsOTcsOTcpO2ZvbnQtZmFtaWx5OiZxdW90O09wZW4gU2Fu cyZxdW90Oztmb250LXNpemU6MTRweDtmb250LXdlaWdodDpub3JtYWw7bGluZS1oZWlnaHQ6MjFw eCIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6MC45MjVlbTtsaW5lLWhlaWdodDoxLjQ7Y29sb3I6cmdiKDIyMCw0 MSwzMCk7Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6 MTRweDtmb250LXdlaWdodDpub3JtYWw7Y29sb3I6cmdiKDUxLDUxLDUxKTtmb250LWZhbWlseTps YXRvLCZxdW90O29wZW4gc2FucyZxdW90OyxhcmlhbCxzYW5zLXNlcmlmO2xpbmUtaGVpZ2h0Om5v cm1hbCIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwxNjQsMTgzKTtmb250LXdl aWdodDpib2xkO2ZvbnQtc2l6ZToxZW07bGluZS1oZWlnaHQ6MS40IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImZvbnQtd2VpZ2h0OjQwMDtjb2xvcjpyZ2IoNTEsNTEsNTEpO2xpbmUtaGVpZ2h0Om5v cm1hbCIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwxNjQsMTgzKTtmb250LXdl aWdodDpib2xkO2ZvbnQtc2l6ZToxZW07bGluZS1oZWlnaHQ6MS40IiBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_48D647991A8040D0B5A0D90F9BD42DA5mitedu_-- From nobody Tue Oct 1 15:43:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC33C12012C for ; Tue, 1 Oct 2019 15:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd1E5xS-GP8y for ; Tue, 1 Oct 2019 15:43:46 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 A0808120100 for ; Tue, 1 Oct 2019 15:43:46 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x91MiKBm023362; Tue, 1 Oct 2019 18:44:21 -0400 Received: from w92expo8.exchange.mit.edu (18.7.74.62) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 1 Oct 2019 18:42:48 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo8.exchange.mit.edu (18.7.74.62) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 1 Oct 2019 18:43:44 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 1 Oct 2019 18:43:44 -0400 From: Justin Richer To: Benjamin J Kaduk CC: Travis Spencer , oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt Thread-Index: AQHVb67qwr2PBijQ2k+ejJTM3X6l2qc9/KaAgAJzIQCABkdDgA== Date: Tue, 1 Oct 2019 22:43:44 +0000 Message-ID: References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> <20190927225106.GE6424@kduck.mit.edu> In-Reply-To: <20190927225106.GE6424@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.207.105.98] Content-Type: multipart/alternative; boundary="_000_E19B32EEDE864EBA8CDE1BB78F400C4Amitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 22:43:49 -0000 --_000_E19B32EEDE864EBA8CDE1BB78F400C4Amitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGFuZCB3aXRoIEJlbuKAmXMgY29udGVudGlvbiB0aGF0IGludHJvc3BlY3Rpb24gc2hvdWxk IGJlIGFib3V0IGdldHRpbmcgaW5mb3JtYXRpb24gOmFib3V0OiBhIHRva2VuLCBhbmQgbm90IGFi b3V0IGdldHRpbmcgYSBuZXcgdG9rZW4uIEluIGZhY3QsIHRoaXMgd2FzIG9uZSBvZiB0aGUgY29y ZSBpc3N1ZXMgdGhhdCBJIGhhZCB3aXRoIHRoZSBkcmFmdCBhcyBvcmlnaW5hbGx5IHByb3Bvc2Vk Lg0KDQpJZiB0aGVyZSBhcmUgcHJvYmxlbXMgd2l0aCB0b2tlbiBleGNoYW5nZSwgdGhleSBzaG91 bGQgYmUgZml4ZWQgd2l0aCB0b2tlbiBleGNoYW5nZSBhbmQgbm90IHBpZ2d5YmFja2VkIGFzIGFu IGFmdGVyLXRob3VnaHQgb24gdGhpcyB3b3JrLg0KDQrigJQgSnVzdGluDQoNCk9uIFNlcCAyNywg MjAxOSwgYXQgMzo1MSBQTSwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU8bWFpbHRvOmth ZHVrQG1pdC5lZHU+PiB3cm90ZToNCg0KT24gVGh1LCBTZXAgMjYsIDIwMTkgYXQgMTE6MjY6MzFB TSArMDIwMCwgVHJhdmlzIFNwZW5jZXIgd3JvdGU6DQoqIExhc3QgYnV0IGNlcnRhaW5seSBub3Qg bGVhc3QgaXMgdGhlIHJlc3RyaWN0aW9uIHRoYXQgdGhlIGN1cnJlbnQNCnZlcnNpb24gcGxhY2Vz IG9uIGRpc2FsbG93aW5nIG9mIHRoZSBpbnRyb3NwZWN0aW9uIEpXVCByZXNwb25zZSBhcyBhbg0K YWNjZXNzIHRva2VuLiBUaGlzIGlzIGRvbmUgaW4gbnVtZXJvdXMgcGxhY2VzICh0aGUgbm90ZSBp biBzZWN0aW9uIDUsDQo4LjEsIGV0Yy4pLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBhcmUgc29t ZSBvYmplY3Rpb24gdG8gdGhpcyB1c2FnZSwNCmJ1dCB3ZSBoYXZlIGhhZCB0aGlzIHByb3RvY29s IGRlcGxveWVkIGZvciB5ZWFycywgYW5kIGl0J3MgcnVubmluZyBpbg0KZG96ZW5zIG9mIGN1c3Rv bWVyJ3MgZmFjaWxpdGllcy4gVGhpcyB3aWxsIGJyZWFrIHJlYWwgYXBwbGljYXRpb25zIG9mDQp0 aGlzIHNwZWNpZmljYXRpb24gd2l0aG91dCBhIGNsZWFyIGFsdGVybmF0aXZlLiBBcyB3ZSBkaXNj dXNzZWQgaW4NCkxvbmRvbiBsYXN0IHllYXIgYXQgdGhlIElFVEYgbWVldGluZywgdG9rZW4gZXhj aGFuZ2UgaXNuJ3QgYSB2aWFibGUNCmFsdGVybmF0aXZlIChldmVuIHN0aWxsIGluIGl0cyBjdXJy ZW50IGRyYWZ0IGZvcm0gdG8gdGhlIGJlc3Qgb2YgbXkNCmtub3dsZWRnZSkuIFdpdGhvdXQgYSB3 b3JrYWJsZSBhbHRlcm5hdGl2ZSB0byBtb3ZlIHRvLCBJIGVtcGhhdGljYWxseQ0KYnV0IGh1bWJs eSByZXF1ZXN0IHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIHJlbW92ZSB0aGlzIHJlc3RyaWN0aW9u Lg0KDQpJIGRvbid0IHRoaW5rIEkgd2FzIGluIHRoZSBMb25kb24gc2Vzc2lvbiwgc28gd291bGQg eW91IG1pbmQgc2F5aW5nIGEgYml0DQptb3JlIGFib3V0IHdoeSB0b2tlbiBleGNoYW5nZSBpc24n dCB2aWFibGUgZm9yIHlvdXIgc2NlbmFyaW8/DQpBcyBhbiBBRCwgSSBzdXBwb3J0IHRoZSBlZmZv cnRzIHRvIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQgdG9rZW4gZmxvdy91c2FnZQ0KaXMgYmVpbmcg ZGVmaW5lZCwgd2hpY2ggaW4gZWZmZWN0IG1lYW5zIGtlZXBpbmcgaW50cm9zcGVjdGlvbiBqdXN0 DQppbnRyb3NwZWN0aW9uIGFuZCBub3QgInByb2R1Y2luZyBuZXcgdG9rZW5zIi4NCg0KVGhhbmtz LA0KDQpCZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_E19B32EEDE864EBA8CDE1BB78F400C4Amitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <6669D01CF1C70449910D883C7AB77B76@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgc3RhbmQgd2l0aCBCZW7igJlzIGNvbnRlbnRp b24gdGhhdCBpbnRyb3NwZWN0aW9uIHNob3VsZCBiZSBhYm91dCBnZXR0aW5nIGluZm9ybWF0aW9u IDphYm91dDogYSB0b2tlbiwgYW5kIG5vdCBhYm91dCBnZXR0aW5nIGEgbmV3IHRva2VuLiBJbiBm YWN0LCB0aGlzIHdhcyBvbmUgb2YgdGhlIGNvcmUgaXNzdWVzIHRoYXQgSSBoYWQgd2l0aCB0aGUg ZHJhZnQgYXMgb3JpZ2luYWxseSBwcm9wb3NlZC4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHRoZXJlIGFyZSBwcm9ibGVtcyB3aXRo IHRva2VuIGV4Y2hhbmdlLCB0aGV5IHNob3VsZCBiZSBmaXhlZCB3aXRoIHRva2VuIGV4Y2hhbmdl IGFuZCBub3QgcGlnZ3liYWNrZWQgYXMgYW4gYWZ0ZXItdGhvdWdodCBvbiB0aGlzIHdvcmsuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAyNywgMjAx OSwgYXQgMzo1MSBQTSwgQmVuamFtaW4gS2FkdWsgJmx0OzxhIGhyZWY9Im1haWx0bzprYWR1a0Bt aXQuZWR1IiBjbGFzcz0iIj5rYWR1a0BtaXQuZWR1PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+T24gVGh1LCBTZXAgMjYsIDIwMTkgYXQgMTE6MjY6MzFBTSAmIzQzOzAyMDAsIFRy YXZpcyBTcGVuY2VyIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPiogTGFzdCBidXQgY2VydGFpbmx5IG5vdCBsZWFzdCBpcyB0aGUgcmVzdHJpY3Rp b24gdGhhdCB0aGUgY3VycmVudDxiciBjbGFzcz0iIj4NCnZlcnNpb24gcGxhY2VzIG9uIGRpc2Fs bG93aW5nIG9mIHRoZSBpbnRyb3NwZWN0aW9uIEpXVCByZXNwb25zZSBhcyBhbjxiciBjbGFzcz0i Ij4NCmFjY2VzcyB0b2tlbi4gVGhpcyBpcyBkb25lIGluIG51bWVyb3VzIHBsYWNlcyAodGhlIG5v dGUgaW4gc2VjdGlvbiA1LDxiciBjbGFzcz0iIj4NCjguMSwgZXRjLikuIEkgdW5kZXJzdGFuZCB0 aGF0IHRoZXJlIGFyZSBzb21lIG9iamVjdGlvbiB0byB0aGlzIHVzYWdlLDxiciBjbGFzcz0iIj4N CmJ1dCB3ZSBoYXZlIGhhZCB0aGlzIHByb3RvY29sIGRlcGxveWVkIGZvciB5ZWFycywgYW5kIGl0 J3MgcnVubmluZyBpbjxiciBjbGFzcz0iIj4NCmRvemVucyBvZiBjdXN0b21lcidzIGZhY2lsaXRp ZXMuIFRoaXMgd2lsbCBicmVhayByZWFsIGFwcGxpY2F0aW9ucyBvZjxiciBjbGFzcz0iIj4NCnRo aXMgc3BlY2lmaWNhdGlvbiB3aXRob3V0IGEgY2xlYXIgYWx0ZXJuYXRpdmUuIEFzIHdlIGRpc2N1 c3NlZCBpbjxiciBjbGFzcz0iIj4NCkxvbmRvbiBsYXN0IHllYXIgYXQgdGhlIElFVEYgbWVldGlu ZywgdG9rZW4gZXhjaGFuZ2UgaXNuJ3QgYSB2aWFibGU8YnIgY2xhc3M9IiI+DQphbHRlcm5hdGl2 ZSAoZXZlbiBzdGlsbCBpbiBpdHMgY3VycmVudCBkcmFmdCBmb3JtIHRvIHRoZSBiZXN0IG9mIG15 PGJyIGNsYXNzPSIiPg0Ka25vd2xlZGdlKS4gV2l0aG91dCBhIHdvcmthYmxlIGFsdGVybmF0aXZl IHRvIG1vdmUgdG8sIEkgZW1waGF0aWNhbGx5PGJyIGNsYXNzPSIiPg0KYnV0IGh1bWJseSByZXF1 ZXN0IHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIHJlbW92ZSB0aGlzIHJlc3RyaWN0aW9uLjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgZG9uJ3QgdGhpbmsgSSB3 YXMgaW4gdGhlIExvbmRvbiBzZXNzaW9uLCBzbyB3b3VsZCB5b3UgbWluZCBzYXlpbmcgYSBiaXQ8 YnIgY2xhc3M9IiI+DQptb3JlIGFib3V0IHdoeSB0b2tlbiBleGNoYW5nZSBpc24ndCB2aWFibGUg Zm9yIHlvdXIgc2NlbmFyaW8/PGJyIGNsYXNzPSIiPg0KQXMgYW4gQUQsIEkgc3VwcG9ydCB0aGUg ZWZmb3J0cyB0byBiZSBleHBsaWNpdCBhYm91dCB3aGF0IHRva2VuIGZsb3cvdXNhZ2U8YnIgY2xh c3M9IiI+DQppcyBiZWluZyBkZWZpbmVkLCB3aGljaCBpbiBlZmZlY3QgbWVhbnMga2VlcGluZyBp bnRyb3NwZWN0aW9uIGp1c3Q8YnIgY2xhc3M9IiI+DQppbnRyb3NwZWN0aW9uIGFuZCBub3QgJnF1 b3Q7cHJvZHVjaW5nIG5ldyB0b2tlbnMmcXVvdDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KVGhhbmtzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlbjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E19B32EEDE864EBA8CDE1BB78F400C4Amitedu_-- From nobody Wed Oct 2 08:45:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32B11208F3 for ; Wed, 2 Oct 2019 08:45:48 -0700 (PDT) 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=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 YHkaMR3qeM4c for ; Wed, 2 Oct 2019 08:45:42 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88E41208D2 for ; Wed, 2 Oct 2019 08:45:41 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id b136so57973309iof.3 for ; Wed, 02 Oct 2019 08:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kft1R8BsWOtShwgU4pTcohg0MsEf999W+iZY+LIWZbU=; b=W7OluPqg5XQL6Pt1VRQrFLeBpWm4uSmUZzUrZd2tlDNT4SydWeXhSxFwzaR5hb5rsl IRkZD97aQssgXikmTyGFjuMvv221N5oHk4RxE9g3GqQDbFvycfBnawE5lPV7JnK8zH4I Lj0Ih7Wzf0DAbXwJ0ww15SscWQY5HUszR4Ufs= 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=Kft1R8BsWOtShwgU4pTcohg0MsEf999W+iZY+LIWZbU=; b=MM/buAJ6Zdyfc//Q7IWH4KL7EBc8UHnkpT0xdFqg3cPAZYDeStnkAOw1LxJc5+AHEM wjZmSFpkjqpkeIcF3MBVoV2vkD+HuI1NFVd/kMF/doBAwDu+bYqUsxOsW/fYOh+Dwmt7 siNbWVhm3TzMFE51PqNHr0Is44YfWXww0F0IMPPXpS8jusnkFr3LxVX9F9DrPsLotq9n mrGaQYwUpl47lmx6MBgs57UWcUwObBgX5fzBxPcB34gx6QSZOJ3h/cUYqeosfOIXKIX3 DwdZ84bumeXZtd3VzM6unxsM4acWfm+Vhc7kNjg4zugrjswBGTxugKDIovDXe6OlAbNB 4FLQ== X-Gm-Message-State: APjAAAVUprlq/+roIY0N+PI5ifQ6EmreYthTy4M/ayNkONirexMUXuJg LVM/EotpKu2Isw30BFmQ2UnP8WudIisepJrB+N0eNsg4StPQbmnIsR2eOYtt0aOciNj2dXC/d+u liscMNPt96lGPEg== X-Google-Smtp-Source: APXvYqyNT36PyeFKFpkUPrmaRPtUPjc2IiB2DNKO4gFYHhdNgMT7btcv5ybz3UE/VVQaPnHOThCi7FOkVfhzsKUkmag= X-Received: by 2002:a6b:cd81:: with SMTP id d123mr4153880iog.78.1570031140958; Wed, 02 Oct 2019 08:45:40 -0700 (PDT) MIME-Version: 1.0 References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> In-Reply-To: <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> From: Brian Campbell Date: Wed, 2 Oct 2019 09:45:14 -0600 Message-ID: To: Justin Richer Cc: George Fletcher , oauth Content-Type: multipart/alternative; boundary="000000000000718dc70593ef5c80" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 15:45:54 -0000 --000000000000718dc70593ef5c80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess we differ in our opinion of how remiss that would be. But given what you've got in there now, the more narrow point I was trying to make was to say that I don't think "data" is defined or explained well enough to be helpful. On Tue, Oct 1, 2019 at 4:33 PM Justin Richer wrote: > I think that we need to define :some: common set to data elements in this > spec, in order to help people who are using this and trying to apply it t= o > their APIs do so in vaguely consistent ways. The details of which parts w= e > standardize on are still, I think, up for grabs. I=E2=80=99d be happy to = have a > better name than =E2=80=9Cdata=E2=80=9D for this aspect, but I think ther= e=E2=80=99s value in > defining this kind of thing. Like in the financial space, it=E2=80=99s th= e > difference between =E2=80=9Ctransactions=E2=80=9D and =E2=80=9Caccounts= =E2=80=9D. Or in the medical space, > there=E2=80=99s =E2=80=9Cdemographics=E2=80=9D and =E2=80=9Cappointments= =E2=80=9D and =E2=80=9CtestResults=E2=80=9D. This is a > very, very, very common way to slice up OAuth-protected resources, and we= =E2=80=99d > be remiss to leave it undefined and just have every API developer need to > come up with their own version of the same thing. > > =E2=80=94 Justin > > On Oct 1, 2019, at 2:40 PM, Brian Campbell > wrote: > > I'm not entirely sold on the draft attempting to define this set of commo= n > data elements in the first place. But that said, I think (similar to > George?) I'm struggling with "data" more than the others. The definition = in > the -02 draft is an "array of strings representing the kinds of data bein= g > requested from the resource" and I'm honestly having a hard time > understanding what that actually means or how it would be used in practic= e. > And I'm not sure roughly equating it to =E2=80=9Cwhat kind of thing I wan= t=E2=80=9D helped > me understand any better. > > On Tue, Sep 24, 2019 at 5:34 PM Justin Richer wrote: > >> The idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80= =9D, =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data >> element types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D use= d for in the wild. They >> roughly equate to =E2=80=9Cwhere something is=E2=80=9D, =E2=80=9Cwhat I = want to do with it=E2=80=9D, =E2=80=9Cwhat >> kind of thing I want=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80= =9D, respectively. I=E2=80=99m >> completely open for better names, and have even been thinking =E2=80=9Cd= atatype=E2=80=9D >> might be better than just =E2=80=9Cdata=E2=80=9D for the third one. >> >> As for encoding, I think that form encoding makes sense because it=E2=80= =99s the >> simplest possible encoding that will work. I personally don=E2=80=99t se= e a need to >> armor this part of the request with base64, as it is in JOSE, and doing = so >> would make it one more step removed from easy developer understanding. >> >> -- Justin Richer >> >> Bespoke Engineering >> +1 (617) 564-3801 >> https://bspk.io/ >> >> >> >> On Sep 24, 2019, at 1:45 PM, George Fletcher wrote: >> >> Just two questions... >> >> 1. What is the rationale that 'data' is really an array of arbitrary >> top-level claims? I find looking at the spec and not finding a 'data' >> section a little confusing. >> >> 2. What is the rationale for sending the JSON object as a urlencoded JSO= N >> string rather than a base64url encoded JSON string? The later would like= ly >> be smaller and easier to read:) >> >> Thanks, >> George >> >> On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: >> >> Hi all,?? >> >> I just published a draft about ???OAuth 2.0 Rich Authorization >> Requests??? (formerly known as ???structured scopes???).?? >> >> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> >> It specifies a new parameter?????authorization_details"??that is used to >> carry fine grained authorization data in the OAuth authorization request= . >> This mechanisms was designed based on experiences gathered in the field = of >> open banking, e.g. PSD2, and is intended to make the implementation of r= ich >> and transaction oriented authorization requests much easier than with >> current OAuth 2.0. >> >> I???m happy that Justin Richer and Brian Campbell joined me as authors o= f >> this draft. We would would like to thank Daniel Fett, Sebastian Ebling, >> Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable >> feedback during the preparation of this draft. >> >> We look forward to getting your feedback.?? >> >> kind regards, >> Torsten.?? >> >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-lodderstedt-oauth-rar-02.txt* >> *Date: *21. September 2019 at 16:10:48 CEST >> *To: *"Justin Richer" , "Torsten Lodderstedt" < >> torsten@lodderstedt.net>, "Brian Campbell" >> >> >> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-rar >> Revision: 02 >> Title: OAuth 2.0 Rich Authorization Requests >> Document date: 2019-09-20 >> Group: Individual Submission >> Pages: 16 >> URL: ?????????????????????? >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >> Status: ???????????????? >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> Htmlized: ???????????? >> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >> Htmlized: ???????????? >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >> Diff: ???????????????????? >> https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-rar-02 >> >> Abstract: >> ????This document specifies a new parameter "authorization_details" that >> ????is used to carry fine grained authorization data in the OAuth >> ????authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended 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._ --000000000000718dc70593ef5c80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess we differ in our opinion of how remiss that w= ould be. But given what you've got in there now, the more narrow point = I was trying to make was to say that I don't think "data" is = defined or explained well enough to be helpful.

On Tue, Oct 1, 20= 19 at 4:33 PM Justin Richer <jricher@= mit.edu> wrote:
I think that we need to define :some: common set to data elements in this s= pec, in order to help people who are using this and trying to apply it to t= heir APIs do so in vaguely consistent ways. The details of which parts we s= tandardize on are still, I think, up for grabs. I=E2=80=99d be happy to have a better name than =E2=80=9Cdat= a=E2=80=9D for this aspect, but I think there=E2=80=99s value in defining t= his kind of thing. Like in the financial space, it=E2=80=99s the difference= between =E2=80=9Ctransactions=E2=80=9D and =E2=80=9Caccounts=E2=80=9D. Or = in the medical space, there=E2=80=99s =E2=80=9Cdemographics=E2=80=9D and =E2=80=9Cappointments=E2=80=9D and =E2= =80=9CtestResults=E2=80=9D. This is a very, very, very common way to slice = up OAuth-protected resources, and we=E2=80=99d be remiss to leave it undefi= ned and just have every API developer need to come up with their own versio= n of the same thing.=C2=A0

=E2=80=94 Justin

On Oct 1, 2019, at 2:40 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:

I'm not entirely sold on the draft attempting to define this set o= f common data elements in the first place. But that said, I think (similar = to George?) I'm struggling with "data" more than the others. = The definition in the -02 draft is an "array of strings representing the kinds of data being requested from the resourc= e" and I'm honestly having a hard time understanding what that act= ually means or how it would be used in practice. And I'm not sure rough= ly equating it to =E2=80=9Cwhat kind of thing I want=E2=80=9D helped me understand any better.

On Tue, Sep 24, 2019 at 5:34 PM Justi= n Richer <justin@bsp= k.io> wrote:
The idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2= =80=9D, =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data eleme= nt types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D used for in= the wild. They roughly equate to =E2=80=9Cwhere something is=E2=80=9D, =E2= =80=9Cwhat I want to do with it=E2=80=9D, =E2=80=9Cwhat kind of thing I wan= t=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80=9D, respectively. I=E2=80=99m co= mpletely open for better names, and have even been thinking =E2=80=9Cdataty= pe=E2=80=9D might be better than just =E2=80=9Cdata=E2=80=9D for the third = one.

As for encoding, I think that form encoding makes sense because it=E2= =80=99s the simplest possible encoding that will work. I personally don=E2= =80=99t see a need to armor this part of the request with base64, as it is = in JOSE, and doing so would make it one more step removed from easy developer understanding.=C2=A0

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801



On Sep 24, 2019, at 1:45 PM, George Fletcher <gffletch@aol.com> wrote:

Just t= wo questions...

1. What is the rationale that 'data' is really an array of arbitrar= y top-level claims? I find looking at the spec and not finding a 'data&= #39; section a little confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON s= tring rather than a base64url encoded JSON string? The later would likely b= e smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Request= s??? (formerly known as ???structured scopes???).??


It specifies a new parameter?????authorization_details"??that is = used to carry fine grained authorization data in the OAuth authorization re= quest. This mechanisms was designed based on experiences gathered in the fi= eld of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriente= d authorization requests much easier than with current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors= of this draft. We would would like to thank Daniel Fett, Sebastian Ebling,= Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feed= back during the preparation of this draft.

We look forward to getting your feedback.??

kind regards,
Torsten.??

Begin forwarded message:

Subject: New Version Notification for draft-lodderstedt-oauth= -rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <ietf@justin.richer.org>, "To= rsten Lodderstedt" <torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com>


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL: ??????????????????????https://www.ietf.org/= internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status: ????????????????https://datatracker.ietf.org/doc/d= raft-lodderstedt-oauth-rar/
Htmlized: ????????????https://tools.ietf.org/html/draft-lodde= rstedt-oauth-rar-02
Htmlized: ????????????https://datatracker.ietf.org/doc= /html/draft-lodderstedt-oauth-rar
Diff: ????????????????????https://www.ietf.org/rfcdif= f?url2=3Ddraft-lodderstedt-oauth-rar-02

Abstract:
????This document specifies a new parameter "authorization_details&quo= t; that
????is used to carry fine grained authorization data in the OAuth
????authorization request.




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

The IETF Secretariat



_______________________________________________
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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited.=C2=A0 If you have received 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.


<= 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. --000000000000718dc70593ef5c80-- From nobody Fri Oct 4 11:08:07 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E85DE12008D; Fri, 4 Oct 2019 11:08:03 -0700 (PDT) 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, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2019 11:08:03 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 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, 04 Oct 2019 18:08:04 -0000 A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: acme tls rats sipcore anima Technology Overlap: ace secevent teep suit core tokbind saag People who must be present: Roman Danyliw Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 4 14:09:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CDD12001E; Fri, 4 Oct 2019 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 EAflZ4MiNA2p; Fri, 4 Oct 2019 14:09:36 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) (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 45475120013; Fri, 4 Oct 2019 14:09:35 -0700 (PDT) Received: from [216.9.110.6] (helo=[172.31.212.59]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iGUpQ-0006Te-Lk; Fri, 04 Oct 2019 23:09:32 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-1E5A4214-F76D-481F-BCD6-FA35C54879B8; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Fri, 4 Oct 2019 14:09:30 -0700 Message-Id: References: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> In-Reply-To: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> To: oauth-chairs@ietf.org, oauth@ietf.org X-Mailer: iPad Mail (17A844) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Oct 2019 21:09:40 -0000 --Apple-Mail-1E5A4214-F76D-481F-BCD6-FA35C54879B8 Content-Type: multipart/alternative; boundary=Apple-Mail-4339A2BA-E83B-41E2-B33E-644C2BBD2A44 Content-Transfer-Encoding: 7bit --Apple-Mail-4339A2BA-E83B-41E2-B33E-644C2BBD2A44 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi chairs, I would like to request the following slots: - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar - https://tools.ietf.org/html/draft-lodderstedt-oauth-par - Security BCP=20 kind regards, Torsten. > Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool : >=20 > =EF=BB=BF >=20 > A new meeting session request has just been submitted by Hannes Tschofenig= , a Chair of the oauth working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Web Authorization Protocol > Area Name: Security Area > Session Requester: Hannes Tschofenig >=20 > Number of Sessions: 2 > Length of Session(s): 1.5 Hours, 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid:=20 > Chair Conflict: acme tls rats sipcore anima > Technology Overlap: ace secevent teep suit core tokbind saag >=20 >=20 >=20 > People who must be present: > Roman Danyliw > Hannes Tschofenig > Rifaat Shekh-Yusef >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4339A2BA-E83B-41E2-B33E-644C2BBD2A44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi chairs,

I would like to request the following slots= :
- Security BCP 

kind regards,
Torsten= .

Am 04.10.2019 um 11:08= schrieb IETF Meeting Session Request Tool <session-request@ietf.org>:=

=EF=BB= =BF

A new meeting session request has= just been submitted by Hannes Tschofenig, a Chair of the oauth working grou= p.


-----------------------= ----------------------------------
Working Group Name: Web A= uthorization Protocol
Area Name: Security Area
Session Requester: Hannes Tschofenig

Num= ber of Sessions: 2
Length of Session(s):  1.5 Hours, 1.= 5 Hours
Number of Attendees: 50
Conflicts to= Avoid:
Chair Conflict: acme tls rats sipcore anima=
Technology Overlap: ace secevent teep suit core tokbind saag



People who mu= st be present:
 Roman Danyliw
 H= annes Tschofenig
 Rifaat Shekh-Yusef
<= /span>
Resources Requested:

Specia= l Requests:

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

________________= _______________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth
= --Apple-Mail-4339A2BA-E83B-41E2-B33E-644C2BBD2A44-- --Apple-Mail-1E5A4214-F76D-481F-BCD6-FA35C54879B8 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCnQw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBTowggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0G CSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0x ODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSm v9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+pUy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7 P3GcYleN1waJRH981U81XzH2clCg9+YRnIUpvof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UO VblWAeQvGCvsV2TlPNCOXOtphvG137/0s048LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5 sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btpWfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb 2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCCAekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCB iwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA67MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZby CyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQkoKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/u U092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0n NI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQb k4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJeQ0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggPJ MIIDxQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwDQYJYIZIAWUDBAIBBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE5MTAwNDIxMDkzMFowLwYJKoZIhvcNAQkEMSIEIGZgM3I4Fuxv0l7o p6pkPfIizQUUfXJqoO7R86iBNj3DMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBaMNH91EE8eB04yE0RzIg57iGZIU8hr2UAjCiq nKLcLf9V4LEDcf607/eNznXAKd92fQKjymq7Q5+4dIzF5XTdWS+JlAP66ZS8Z5BXBrdzKTeKgZ1Y UnrwVIZ1BWAFI/IgjYkZL4SeWo9MYDRvI85sMeDT9nBhMWEDEGP6yzT3xQa0Nv7Wpeu4N7UFg6nz 0K/wKT5s1HAycyTQK9z0ESp1NTJZaN/bQ+nx8wwB6SJ//ag5GIe00472ub1MH/qgrG1dbnUwQArZ D74gJ8jsmUjHIgo1b5CqmEEB1Eth2ogteho+MvDHcCSYEYzmS5TBQvFWILckGdhf6r4ch13hD0NL AAAAAAAA --Apple-Mail-1E5A4214-F76D-481F-BCD6-FA35C54879B8-- From nobody Fri Oct 4 14:12:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D7120088 for ; Fri, 4 Oct 2019 14:12:47 -0700 (PDT) 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=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 FMn3Rm2UhBlL for ; Fri, 4 Oct 2019 14:12:44 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1FB120025 for ; Fri, 4 Oct 2019 14:12:44 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b136so16557873iof.3 for ; Fri, 04 Oct 2019 14:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WpA+1rJxzTwPjm5v8w3gpkm7BHFJkRhIPt+5hrd1X9U=; b=LyLf/X0PQiUGNZU9UY2GuAtk/3kOyfzeLYd+6cK2gMu/nrImPKo7m4mTfRQ5DBjDi4 TGqRx3taw6OfFw/nCqwVF8gpDziN/Ydazwlaf5nJYrzh60scoEQ2vTxKhkQTr1LEZUlm EBorLsoW0bQVs33lwleOPfdnLlRQ4AiLaLL6I= 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=WpA+1rJxzTwPjm5v8w3gpkm7BHFJkRhIPt+5hrd1X9U=; b=OOAP1IyXoWWYYvquQ1CHsOBDTJm2aMvZkRUW5psFOnl9TxlH7XBqt+rl8J8L59tRYI jOUBRm+eZUOPXdJYsgq9yacypi5M8C1PqtQ9lZjbFnHNJvcslUhERXaDDGlNAPqOJAWy FjLfiKRmP+rvrLzC9/Wf3SUaMVizEnCfGJ9ubYYdcjd9/DSn/qTd0n0t10khElKBkZf6 ebYDsSBazcNWwatnd71BwhfrX+m4lYZZ44jvMTALnEn9aDhyzsiiCj/RDoQA3jNc1B9O XQiRMADh1tGhAntnffRp02/ibTYdSkny2kvA3jK9mHVBsVxSpOI0qbwilypxr/fFTldi d96g== X-Gm-Message-State: APjAAAXr8+3Q42eVv0KOWAgLkMM0AyIMBssOnoaSZ/zuHve7GAEXC2ou hL5esm7UywFSci8r8Afghcv4P0sWjuVKNrAz5q91HkjuuWcmw5ivkDLr+9m1sShR44+7hkJ5ZSw al4d9E0uNyk+Ozw== X-Google-Smtp-Source: APXvYqwe2Hhy2/tsolBibUGrBMcXDwMb433KR+8LtzAcy5BEPZ+DjH+onP5AdTRZGyZAtuel6qu7OsIzgZka1Gpih5A= X-Received: by 2002:a6b:cd81:: with SMTP id d123mr15943835iog.78.1570223563951; Fri, 04 Oct 2019 14:12:43 -0700 (PDT) MIME-Version: 1.0 References: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 4 Oct 2019 15:12:17 -0600 Message-ID: To: Torsten Lodderstedt Cc: oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000bf74d905941c2918" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Oct 2019 21:12:47 -0000 --000000000000bf74d905941c2918 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello chairs, I'd like to request some agenda time to present on: https://tools.ietf.org/html/draft-fett-oauth-dpop Thank you, Brian On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt wrote: > Hi chairs, > > I would like to request the following slots: > - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar > > - https://tools.ietf.org/html/draft-lodderstedt-oauth-par > > - Security BCP > > kind regards, > Torsten.. > > Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool < > session-request@ietf.org>: > > =EF=BB=BF > > A new meeting session request has just been submitted by Hannes > Tschofenig, a Chair of the oauth working group. > > > --------------------------------------------------------- > Working Group Name: Web Authorization Protocol > Area Name: Security Area > Session Requester: Hannes Tschofenig > > Number of Sessions: 2 > Length of Session(s): 1.5 Hours, 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid: > Chair Conflict: acme tls rats sipcore anima > Technology Overlap: ace secevent teep suit core tokbind saag > > > > People who must be present: > Roman Danyliw > Hannes Tschofenig > Rifaat Shekh-Yusef > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > OAuth mailing 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._ --000000000000bf74d905941c2918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello chairs,

I'd like t= o request some agenda time to present on:

Thank you,
Brian

On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt <<= a href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net> w= rote:
Hi chairs,

I would like to request the following slots:
- Security BCP= =C2=A0

kind regards,
=
Torsten..

Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool <session-request= @ietf.org>:

=EF=BB=BF

A new meeting= session request has just been submitted by Hannes Tschofenig, a Chair of t= he oauth working group.


-= --------------------------------------------------------
Wo= rking Group Name: Web Authorization Protocol
Area Name: Sec= urity Area
Session Requester: Hannes Tschofenig
<= span>
Number of Sessions: 2
Length of Sessi= on(s): =C2=A01.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
Chair Conflict: acme t= ls rats sipcore anima
Technology Overlap: ace secevent tee= p suit core tokbind saag


=
People who must be present:
=C2=A0Roman D= anyliw
=C2=A0Hannes Tschofenig
=C2=A0Rifa= at Shekh-Yusef

Resources Requested:=

Special Requests:

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

_______________________________________________OAuth mailing 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. --000000000000bf74d905941c2918-- From nobody Fri Oct 4 14:15:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D80120025; Fri, 4 Oct 2019 14:15:38 -0700 (PDT) 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 CliXRqYcCvlW; Fri, 4 Oct 2019 14:15:35 -0700 (PDT) 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 E08C312001E; Fri, 4 Oct 2019 14:15:34 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id q12so465386lfc.11; Fri, 04 Oct 2019 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Atcf5YXw0DjVzzu0mqw7rma4BATeBoMsjgCU+tQp2M=; b=M7UOGilqrHKc/zyiSxIYtTxyz8zbdM/Y2tB6kll+npSbb3eY2mPVysT+MgifVvVOkF x8YuF/qxnZHKNhbUhbTcOA2nDJtUH8cW044IRimmibu+DRlxVcJelSkan/Q9/NNb3Xs3 myC4tAjh7mcpD/r5QqYByRIeDAAXHc0WoRhI9wwftSKlqxuDOA4RcsDSV32kWV7cGiLD L3Uh2MDdlXZYT2JhGTo6PLo131vkcMxZd576/9oxMi5rCEdwdtre+Su/eFehG0yLf4XD E2FaZ8y2uzKPBjV4tbpPAZn0NNNSztNnvLVbs6JzhR24DhXRO9xQn5dgk2gW05bdxiHl 0A0Q== 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=6Atcf5YXw0DjVzzu0mqw7rma4BATeBoMsjgCU+tQp2M=; b=UOUptS473UFA6So2zOJIzRS4IUADmEIvVBOS5dhbKsw58DVbbfTa9J64lIZXHWEozp 8UpYZ5Jas+Fmsb7XzkTLwzmuhdA+a8+EcKLRvMSayBbTNszG1LWYPC84BxF/OlPX6cnq cyh+FkWzG/MNFqBlb2gV6Ftxo/vT2VJuw4KCaTMWIvLKORDQE5Jb8a3NRv/6xU5sSlWU L+LSPnqopbazWSsd3ieuWqharMgA3nBJyfOqZRqKqih92nfSymqEi1BWeWQfKZ1uRWyo S7I7rf39T2qBmC1CXJblg/1CZZnPb3w7Ewdu5vNv5VwM9ct+8o6+/Hotz1bYsGdxgH/g 3Ttw== X-Gm-Message-State: APjAAAUuHQsit4c2RKzLKYLoTfOnPs0VBBYHv2RyM8AyvPfstuOnwcue VNldAYS4J4951fDzXABP9wsw/MhEetGysPkaMXy0OYhc X-Google-Smtp-Source: APXvYqyr1t6qkd1PUoQNG0GLGkvuNOXYfWglkWOaIaFJh2iQ4zphSnN8q+2hA4VMsPM1WWPiTcBE4eUQwD5jnvYduU8= X-Received: by 2002:a05:6512:75:: with SMTP id i21mr9975380lfo.95.1570223732840; Fri, 04 Oct 2019 14:15:32 -0700 (PDT) MIME-Version: 1.0 References: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> In-Reply-To: From: Dick Hardt Date: Fri, 4 Oct 2019 14:15:21 -0700 Message-ID: To: Brian Campbell Cc: Torsten Lodderstedt , oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000d05dbe05941c33db" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Oct 2019 21:15:38 -0000 --000000000000d05dbe05941c33db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like a slot to provide an update on Reciprocal OAuth. =E1=90=A7 On Fri, Oct 4, 2019 at 2:12 PM Brian Campbell wrote: > Hello chairs, > > I'd like to request some agenda time to present on: > https://tools.ietf.org/html/draft-fett-oauth-dpop > > Thank you, > Brian > > On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi chairs, >> >> I would like to request the following slots: >> - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar >> >> - https://tools.ietf.org/html/draft-lodderstedt-oauth-par >> >> - Security BCP >> >> kind regards, >> Torsten.. >> >> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool < >> session-request@ietf.org>: >> >> =EF=BB=BF >> >> A new meeting session request has just been submitted by Hannes >> Tschofenig, a Chair of the oauth working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Web Authorization Protocol >> Area Name: Security Area >> Session Requester: Hannes Tschofenig >> >> Number of Sessions: 2 >> Length of Session(s): 1.5 Hours, 1.5 Hours >> Number of Attendees: 50 >> Conflicts to Avoid: >> Chair Conflict: acme tls rats sipcore anima >> Technology Overlap: ace secevent teep suit core tokbind saag >> >> >> >> People who must be present: >> Roman Danyliw >> Hannes Tschofenig >> Rifaat Shekh-Yusef >> >> Resources Requested: >> >> Special Requests: >> >> --------------------------------------------------------- >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d05dbe05941c33db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like a slot to provide an update on Reciprocal OAu= th.
=3D""=E1=90=A7

On Fri, Oct 4, 2019 at 2:12 PM Brian Ca= mpbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Hello chairs,
=

I'd like to request some agenda time to present on:=

Thank you,
Brian

On F= ri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:=
Hi chairs,

I would like to request the following slots:
- Security BCP=C2=A0=

kind regards,
Torsten..

Am= 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool <session-request@ietf= .org>:

=EF=BB=BF

A new meeting ses= sion request has just been submitted by Hannes Tschofenig, a Chair of the o= auth working group.


-----= ----------------------------------------------------
Workin= g Group Name: Web Authorization Protocol
Area Name: Securit= y Area
Session Requester: Hannes Tschofenig

Number of Sessions: 2
Length of Session(s= ): =C2=A01.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
Chair Conflict: acme tls r= ats sipcore anima
Technology Overlap: ace secevent teep su= it core tokbind saag



People who must be present:
=C2=A0Roman Danyl= iw
=C2=A0Hannes Tschofenig
=C2=A0Rifaat S= hekh-Yusef

Resources Requested:
=
Special Requests:

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d05dbe05941c33db-- From nobody Fri Oct 4 17:11:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5812006B for ; Fri, 4 Oct 2019 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 FAeSi-sjh5Gc for ; Fri, 4 Oct 2019 17:11:20 -0700 (PDT) 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 C9158120052 for ; Fri, 4 Oct 2019 17:11:19 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id v17so7381420wml.4 for ; Fri, 04 Oct 2019 17:11:19 -0700 (PDT) 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=KAENUjNiwUfTd2wlo+ocVpLLEzQ8MYYpu7moZzXzo4E=; b=nkteiGbuX4GTK7ebMU2eZ4U0uPW20q1aUR429c5za86aTYtzJbzzjHDrsoO8SoOgFF POhEPKwM6UyLJ6QptkvYCwi0k7xTTR+bMjCa/4Uiadf5EGDAjQbp/CTF17sXKpkoj3// Y1Ws4avgBu5SQqquzI1H1VBrlAz4NkT+cApgQ8b5ZegH/p5ck6D5iCue6zf14Tw9nV1d Sh7QQgSbV7yUdHGG2L6S9vi0W/q+ErPaLyQhAUymNyu8Danwwgst/qkyjiwL47SC9BMH 654foiUamGXzXnraQtcVDK5AOG9jdzG9P5l9+NmjhJQmGTrxntIRg1W2KIkMfEgOC2cr TJOw== 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=KAENUjNiwUfTd2wlo+ocVpLLEzQ8MYYpu7moZzXzo4E=; b=g18qBl6q2w4dEe4ktoB5Rs7BKhbClv/4jG4pOdro95tN9m4wVOrrFdeEIlEKg4800k ZKA3SRK00bgbJjdbS0GPgaegrVusfXQoHLYLYeXH7G9uECohRds4+vBY8gf/AIw536Fs 76KA6Tkt4gYji5PH8Mc5wjDClFPsYeKyx0Az+gLy5bqtL+kbHUxQsq8KQfthPFyLdZ+9 jaL47yz07iC2Q9cRedKXgrMR802YBbDsxJKuZ/D+jWrQbRgMrigPvEwNbAX5KCxNKFPr oUCR89YOWFlnAAnH8Bi5N443zcuafOPMjzEb3Ktxk6SGjamj3fcxyTrH72243GiXGbQU 7PXQ== X-Gm-Message-State: APjAAAXvAWWSlreGpeiR9Awnpdsv0+cEQmmNIL6sE5FNwoYh3X+VMM19 5KDgmw+698icSzI95kYR2TWZdZViuDre8qOTUvfCdefLuGE= X-Google-Smtp-Source: APXvYqxYCkRaz2D+HiAAuViCR1Jv8lcPtSJpHyO3ASGNdPC3bbaPX4t5pNc54oz5zOgsyaznm+Bz84BNu/5Xwcwvhak= X-Received: by 2002:a7b:cd99:: with SMTP id y25mr12613009wmj.152.1570234277943; Fri, 04 Oct 2019 17:11:17 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <48D64799-1A80-40D0-B5A0-D90F9BD42DA5@mit.edu> In-Reply-To: <48D64799-1A80-40D0-B5A0-D90F9BD42DA5@mit.edu> From: Takahiko Kawasaki Date: Fri, 4 Oct 2019 17:11:06 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="00000000000059f35605941ea829" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 00:11:24 -0000 --00000000000059f35605941ea829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, >2.3.1.5. Request entity too large > > If the request size was beyond the upper bound that the authorization > server allows, the authorization server shall return a "413 Request > Entity Too Large" HTTP error response. "413 Request Entity Too Large" should be changed to "413 Payload Too Large"= . c.f. https://bitbucket.org/openid/fapi/issues/256/pushed-request-object-payload-= too-large > Depending on client type and authentication method, the request might > also include the "client_id" parameter. The "request_uri" > authorization request parameter MUST NOT be provided in this case > (see Section 3). How about changing to: *the request might also include other request parameters such as the "client_id" parameter, the "client_secret" parameter, the "client_assertion" parameter, and so on.* Taka On Tue, Oct 1, 2019 at 3:36 PM Justin Richer wrote: > To be clear, PAR is not the same as XYZ. Both are going to be inputs into > the conversation under txauth, and there are similarities, but they > shouldn=E2=80=99t be conflated. > > In PAR, the result has to be a URI because that=E2=80=99s what JAR define= s as the > input. With XYZ, you get returned two things: a transaction handle and an > interaction URI. These are both opaque to the client. > > =E2=80=94 Justin > > On Sep 30, 2019, at 8:33 AM, Dick Hardt wrote: > > I can understand the request URI being a URI that the client is providing > the AS, but why would the client's request URI be at the AS? > > As Justin has explained it in the past, the AS is returning a handle to > the transaction. The only party that understands that handle as far as I > know is the AS. It is meaningless to the client. Perhaps I am missing > something else? > =E1=90=A7 > > On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge > wrote: > >> So although for this spec, request_uri is just an opaque string, it is >> defined more generally in >> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an= : >> >> * Absolute URI from which the Request Object (Section 2.1) can be >>> obtained* >> >> >> And in section 5.2 as: >> >> >>> *The "request_uri" value MUST be either URN as defined in * >>> * RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 * >>> * [RFC7230] . The "request_uri" value MUST be reachable by the ** >>> Authorization Server.* >> >> >> So this is why in the spec we have example of a URN and we have an >> ongoing discussion as to whether we should have a standard urn namespace >> that we recommend implementers use. >> >> In the interest of keeping the specs in sync I think it makes sense to >> keep it a URN for this spec, but with more of an explanation as to why? >> >> Dave >> >> On Fri, 27 Sep 2019 at 19:22, Dick Hardt wrote: >> >>> If I understand the proposal correctly, the request URI is opaque to th= e >>> client. Correct? >>> >>> If so, why not just treat it as an opaque string? >>> >>> If I were implementing the protocol, I would have the blob be a signed >>> token so that I could verify the integrity before making a database cal= l. >>> It much easier to throw compute at a DDOS attack to verify a signature, >>> than DB capacity. >>> >>> =E1=90=A7 >>> >>> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer wrote: >>> >>>> Yes, the request object is JWT-based, but the request URI is not. In >>>> other words, you can post a JWT but what you get back is a URI, not th= e JWT >>>> itself. The request URI was always meant to be a reference, and origi= nally >>>> it was explicitly a reference to a signed request object. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Sep 26, 2019, at 10:03 AM, Aaron Parecki wrote: >>>> >>>> The URI is intended to be a reference not a value.. If the client coul= d >>>> send a JWT it would just send a request object instead of a request UR= I in >>>> the first place. So the intent is that it=E2=80=99s random, and maybe = we should >>>> just say that explicitly. >>>> >>>> >>>> I thought this language was explicitly to allow the use of structured >>>> values for the request_uri? From the introduction: >>>> >>>> but it also allows clients requiring an even >>>> higher security level, especially cryptographically confirmed non- >>>> repudiation, to explicitly adopt JWT-based request objects. >>>> >>>> >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> >>>> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer wrote: >>>> >>>> >>>> Aaron, some comments inline. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Sep 26, 2019, at 8:30 AM, Aaron Parecki wrote: >>>> >>>> Hi Torsten, >>>> >>>> I'm very glad to see this draft, I think it's definitely needed in >>>> this space. Here are some of my thoughts on the draft. >>>> >>>> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" >>>> >>>> >>>> Is it acceptable for the AS to return just an opaque string, rather >>>> than something prefixed with "uri:*"? I don't think anyone would be >>>> confused about copypasting the exact string from the "request_uri" >>>> response into the "request_uri" parameter even if it didn't start with >>>> "urn:". If, for whatever reason, it is required that this value is >>>> actually a URI, is there some expected namespace to use other than >>>> "example"? I worry that if all the examples in the spec are just >>>> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up >>>> using the text "example" because they don't understand why it's there, >>>> and then it serves no purpose really.=E2=80=99 >>>> >>>> >>>> This field must be a URI, as per JAR: >>>> >>>> request_uri The absolute URI as defined by RFC3986 [RFC3986] that >>>> points to the Request Object (Section 2.1) that holds >>>> authorization request parameters stated in section 4 of OAuth 2.0 >>>> [RFC6749]. >>>> >>>> Somewhat awkwardly, the JAR spec currently states that the AS has to d= o >>>> an HTTP GET on the request URI, so that will need to be fixed in JAR b= efore >>>> it goes forward. I don=E2=80=99t think that was always the case though= , and I=E2=80=99m not >>>> sure how that changed. >>>> >>>> As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example U= RN. The problem >>>> with URNs is that nobody really understands how to do domain-safe full= y >>>> compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:exam= ple.com:=E2=80=A6.=E2=80=9D >>>> Instead (as per https://tools.ietf.org/html/rfc4198). >>>> >>>> >>>> The pushed authorization request endpoint shall be a RESTful API >>>> >>>> >>>> I would drop the term RESTful and just say "HTTP API", as this >>>> description is arguably RESTful at best. >>>> >>>> Depending on client type and authentication method, the request might >>>> also include the "client_id" parameter. >>>> >>>> >>>> I assume this is hinting at the difference between public clients >>>> sending only the "client_id" parameter and confidential clients >>>> sending only the HTTP Basic Authorization header which includes both >>>> the client ID and secret? It would probably be helpful to call out >>>> these two common examples if I am understanding this correctly, >>>> otherwise it seems pretty vague. >>>> >>>> >>>> Not quite, those differences are for the token endpoint, and this is >>>> capturing things from the authorization endpoint. I don=E2=80=99t quit= e understand >>>> the differentiation listed here either, though. >>>> >>>> >>>> The "request_uri" value MUST be generated using a cryptographically >>>> strong pseudorandom algorithm >>>> >>>> >>>> I assume this includes the use of a random number inside of a JWT, in >>>> case the AS wants to use JWTs as the "request_uri" parameter"? If so, >>>> it's probably worth spelling that out as it kind of reads like it has >>>> to be literally a random string at first glance. >>>> >>>> >>>> The URI is intended to be a reference not a value. If the client could >>>> send a JWT it would just send a request object instead of a request UR= I in >>>> the first place. So the intent is that it=E2=80=99s random, and maybe = we should >>>> just say that explicitly. >>>> >>>> >>>> That's all for now, thanks! >>>> >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt >>>> wrote: >>>> >>>> >>>> Hi all, >>>> >>>> I just published a new draft that Brian Campbell, Dave Tonge, Filip >>>> Skokan, Nat Sakimura and I wrote. >>>> >>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >>>> >>>> It proposes a new endpoint, called "pushed authorization request >>>> endpoint=E2=80=9D, that allows the client to push the Authorization Re= quest payload >>>> with the AS on a backchannel connection instead of a front channel >>>> interaction. The AS provides the client with a request URI (according = to >>>> draft-ietf-oauth-jwsreq) that the client uses in a subsequent authoriz= ation >>>> requests to refer to the pushed request data. >>>> >>>> We believe this simple mechanism will significantly increase OAuth >>>> security and robustness since any application can use it by just sendi= ng >>>> the parameters in the same encoding as used at the authorisation endpo= int >>>> over a HTTPS-protected and (for confidential clients) mutually >>>> authenticated connection to the AS. It can also be used to push signed= and >>>> encrypted request objects to the AS, i.e. it provides an interoperable= way >>>> to use request objects managed at the AS for use cases requiring an ev= en >>>> higher security level. >>>> >>>> We look forward to getting your feedback. >>>> >>>> kind regards, >>>> Torsten. >>>> >>>> Begin forwarded message: >>>> >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.t= xt >>>> Date: 21. September 2019 at 12:47:28 CEST >>>> To: "Nat Sakimura" , "Brian Campbell" < >>>> bcampbell@pingidentity.com>, "Torsten Lodderstedt" < >>>> torsten@lodderstedt.net>, "Dave Tonge" , "Filip >>>> Skokan" >>>> >>>> >>>> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >>>> has been successfully submitted by Torsten Lodderstedt and posted to t= he >>>> IETF repository. >>>> >>>> Name: draft-lodderstedt-oauth-par >>>> Revision: 00 >>>> Title: OAuth 2.0 Pushed Authorization Requests >>>> Document date: 2019-09-21 >>>> Group: Individual Submission >>>> Pages: 12 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.tx= t >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >>>> >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >>>> >>>> >>>> Abstract: >>>> This document defines the pushed authorization request endpoint, >>>> which allows clients to push the payload of an OAuth 2.0 >>>> authorization request to the authorization server via a direct >>>> request and provides them with a request URI that is used as >>>> reference to the data in a subsequent authorization request. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000059f35605941ea829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten,

>2.3.1.5.=C2=A0 Request = entity too large
>
> =C2=A0 If the request size was beyond the = upper bound that the authorization
> =C2=A0 server allows, the author= ization server shall return a "413 Request
> =C2=A0 Entity Too L= arge" HTTP error response.

"413 Request Entity Too Large&q= uot; should be changed to "413 Payload Too Large".

= > =C2=A0 Depending on client type and authentication method, the request= might
> =C2=A0 also include the "client_id" parameter.=C2= =A0 The "request_uri"
> =C2=A0 authorization request parame= ter MUST NOT be provided in this case
> =C2=A0 (see Section 3).

How about changing to:

= the request might also include other request parameters such as the "c= lient_id" parameter, the "client_secret" parameter, the &quo= t;client_assertion" parameter, and so on.

Taka


On Tue, Oct 1, 2019 at 3:36 PM Justin Richer <= jricher@mit.edu>= ; wrote:
To be clear, PAR is not the same as XYZ. Both are going to be inputs into t= he conversation under txauth, and there are similarities, but they shouldn= =E2=80=99t be conflated.=C2=A0

In PAR, the result has to be a URI because that=E2=80=99s what JAR def= ines as the input. With XYZ, you get returned two things: a transaction han= dle and an interaction URI. These are both opaque to the client.

=E2=80=94 Justin

On Sep 30, 2019, at 8:33 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

I can understand the request URI being a URI that the clie= nt is providing the AS, but why would the client's request URI be at th= e AS?

As Justin has explained it in the past, the AS is returning=C2=A0a han= dle to the transaction. The only party that understands that handle as far = as I know is the AS. It is meaningless to the client. Perhaps I am missing = something else?
3D""=E1=90=A7

On Mon, Sep 30, 2019 at 2:53 AM Dave = Tonge <= dave.tonge@momentumft.co.uk> wrote:
So although for this spec, request_uri is just an opaque string= , it is defined more generally in=C2=A0https://tools.= ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:

=C2=A0Absolute URI from which the Request Object (Section 2.1) can be ob= tained

And in section 5.2 as:

The "request_uri" value MUST be either URN as defined in
=C2=A0 =C2=A0RFC8141 [RFC8141] or "https" URI, as defined = in 2.7.2 of RFC7230
=C2=A0 =C2=A0[RFC7230] .=C2=A0 The "request_uri" value MUS= T be reachable by the
=C2=A0 =C2=A0Authorization Server.

So this is why in the spec we have example of a URN and we have= an ongoing discussion as to whether we should have a standard urn namespac= e that we recommend implementers use.

In the interest of keeping the specs in sync I think it makes s= ense to keep it a URN for this spec, but with more of an explanation as to = why?

Dave

On Fri, 27 Sep 2019 at 19:22, Dick Ha= rdt <dick.hard= t@gmail.com> wrote:
If I understand the proposal correctly, the request URI is= opaque to the client. Correct?

If so, why not just treat it as an opaque string?

If I were implementing the protocol, I would have the blob be a signed= token so that I could verify the integrity before making a database call. = It much easier to throw compute at a DDOS attack to verify a signature, tha= n DB capacity.

3D""=E1=90=A7

On Thu, Sep 26, 2019 at 2:24 PM Justi= n Richer <jricher@m= it.edu> wrote:
Yes, the request object is JWT-based, but the request URI is not. In o= ther words, you can post a JWT but what you get back is a URI, not the JWT = itself.=C2=A0 The request URI was always meant to be a reference, and origi= nally it was explicitly a reference to a signed request object.=C2=A0

=E2=80=94 Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aaron@parecki.com> wrote:

The URI is intended to be a reference not a value= .. If the client could send a JWT it would just send a request object inste= ad of a request URI in the first place. So the intent is that it=E2=80=99s = random, and maybe we should just say that explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com=

On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jricher@mit.edu> wrote:

Aaron, some comments inline.

=E2=80=94 Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in<= br> this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"= ;


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone wo= uld be
confused about copypasting the exact string from the "request_uri"= ;
response into the "request_uri" parameter even if it didn't s= tart with
"urn:". If, for whatever reason, it is required that this value i= s
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just<= br> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will en= d up
using the text "example" because they don't understand why it= 's there,
and then it serves no purpose really.=E2=80=99


This field must be a URI, as per JAR:

=C2=A0=C2=A0request_uri =C2=A0The absolute URI as defined by RFC3986 [RFC39= 86] that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0points to the Request Object (Section 2.1) th= at holds
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0authorization request parameters stated in se= ction 4 of OAuth 2.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an = HTTP GET on the request URI, so that will need to be fixed in JAR before it= goes forward. I don=E2=80=99t think that was always the case though, and I= =E2=80=99m not sure how that changed.

As for the namespace, =E2=80=9Cexample=E2=80=9D is ok for an example URN. T= he problem with URNs is that nobody really understands how to do domain-saf= e fully compliant URNs. So perhaps we should instead use =E2=80=9Curn:fdc:<= a href=3D"http://example.com" target=3D"_blank">example.com:=E2=80=A6.= =E2=80=9D Instead (as per https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API


I would drop the term RESTful and just say "HTTP API", as this description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.


I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.


Not quite, those differences are for the token endpoint, and this is captur= ing things from the authorization endpoint. I don=E2=80=99t quite understan= d the differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographical= ly
strong pseudorandom algorithm


I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"= ;? If so,
it's probably worth spelling that out as it kind of reads like it has to be literally a random string at first glance.


The URI is intended to be a reference not a value. If the client could send= a JWT it would just send a request object instead of a request URI in the = first place. So the intent is that it=E2=80=99s random, and maybe we should= just say that explicitly.


That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com=
@aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:


Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan,= Nat Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpo= int=E2=80=9D, that allows the client to push the Authorization Request payl= oad with the AS on a backchannel connection instead of a front channel inte= raction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subse= quent authorization requests to refer to the pushed request data.

We believe this simple mechanism will significantly increase OAuth security= and robustness since any application can use it by just sending the parame= ters in the same encoding as used at the authorisation endpoint over a HTTP= S-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used = to push signed and encrypted request objects to the AS, i.e. it provides an= interoperable way to use request objects managed at the AS for use cases r= equiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: interne= t-drafts@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sakimura" <nat@sakimura.org>, "Brian Campbell" <bcampbell@pingide= ntity.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>, "Dave Tonge" <dave@tonge.org>, "Filip Skokan" <panva.ip@gmail.com>


A new version of I-D, draft-lodderstedt-oauth-par-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Name: draft-lodderstedt-oauth-par
Revision: 00
Title: OAuth 2.0 Pushed Authorization Requests
Document date: 2019-09-21
Group: Individual Submission
Pages: 12
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-par-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.= ietf.org/html/draft-lodderstedt-oauth-par-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par


Abstract:
This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct
request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request.




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

The IETF Secretariat


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


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



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


--


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000059f35605941ea829-- From nobody Sun Oct 6 05:11:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3740C12008F for ; Sun, 6 Oct 2019 05:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 QlmEnHxMC1dB for ; Sun, 6 Oct 2019 05:11:37 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (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 859E1120013 for ; Sun, 6 Oct 2019 05:11:37 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iH5Nt-0000EV-La; Sun, 06 Oct 2019 14:11:33 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_08475336-BFC8-49B2-8F1A-E36212ED5D84"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <70C7BCB5-348E-4FF1-8611-FAE1755A805F@lodderstedt.net> Date: Sun, 6 Oct 2019 14:11:32 +0200 Cc: oauth To: Aaron Parecki X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 12:11:40 -0000 --Apple-Mail=_08475336-BFC8-49B2-8F1A-E36212ED5D84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > This is absolutely something that needs to be mentioned in the > security & privacy considerations. >=20 > My worry is that by leading with an example of account numbers in the > request URL, we're sending the wrong message. >=20 > I do see the value in rich authorization requests with no PII like > George described, so I would be happy if: >=20 > * the example in this draft of the GET request was an example with no = PII > * there was an additional example using PAR that includes the full > bank account transfer in the current draft Hi Aaron,=20 I fully agree with you. The examples need to be reworked.=20 Please note: the privacy considerations section = (https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02#section-6) = already contains text regarding protection of PII. Does this address = your concerns? best regards, Torsten.=20 PS: sorry for not swiftly reacting on your posts, my e-mail provider=E2=80= =99s spam filter has swallowed the whole thread :-(= --Apple-Mail=_08475336-BFC8-49B2-8F1A-E36212ED5D84 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 Fw0xOTEwMDYxMjExMzNaMC8GCSqGSIb3DQEJBDEiBCBVCRfekZw5lvMAloyS22LMbRU/mctJsw9R dEobyAvIfTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAB6ps5iOZRvEuiIdWuDx11Dv4IxuriIZwoI//3ypip2DIBpcH3oXyp4fsone WIdV0uFH2d0BdWD+UgJbaFZmpx0TfJwWHSHja4TZaekWLigTRPpUlhm0j7K4v1CSfI6XdB7HjvqN hGtqK/zBkxDFYw9Qf38e3GJ1QPbAFw8KSpagM9f/BdXIVmTmDLXSxFtL2XQCkJgEQVDinAA49Eyq 9LWe6oLRkLSpL137pzH4Xa3A9V+3guNGO2W7l0eHSOHcaOuLPvLCVtrRZdpJp+V6VZoRRZyVN4db YmyyNt4CBY0UKzQnHD03jCAZlljKTnPZSd/OOc8DLO98uQHclmFyawMAAAAAAAA= --Apple-Mail=_08475336-BFC8-49B2-8F1A-E36212ED5D84-- From nobody Sun Oct 6 06:31:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC42120058 for ; Sun, 6 Oct 2019 06:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 u1tXJn9yZy97 for ; Sun, 6 Oct 2019 06:31:26 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 3F37412003F for ; Sun, 6 Oct 2019 06:31:26 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iH6d8-0001Bb-SP; Sun, 06 Oct 2019 15:31:22 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_454B83DF-2FCD-4657-978C-6BF513C25693"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> Date: Sun, 6 Oct 2019 15:31:22 +0200 Cc: oauth To: Travis Spencer X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 13:31:30 -0000 --Apple-Mail=_454B83DF-2FCD-4657-978C-6BF513C25693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Travis, thanks for your feedback!=20 > On 26. Sep 2019, at 11:26, Travis Spencer = wrote: >=20 > Some feedback on this draft compared to the last one that I read: >=20 > * The acronym RS and the term "resource server" are used > inconsistently. It would read better IMO if the acronym was always > used after being defined or if resource server was always spelled out. > Same for AS, but less so. Maybe this is just me, so take it as you > will. I will check, especially the plural of RS (RSs?) looks weird to my eyes = so I would like to prefer to sometime not to go with the acronym. Do others have an opinion about this? >=20 > * In section 3, is it saying that JWE is MTI? =46rom the end of = section > 5, it seems not. If so, this statement should be clarified IMO: >=20 >> To support encrypted token introspection response JWTs, the = authorization server MUST also be provided with the respective resource = server encryption keys and algorithms. >=20 > Maybe just change it to "If the AS supports encrypted token > introspection response JWTs=E2=80=A6" It wasn=E2=80=99t meant as MTI sind we just provide the conceptual = underpinning of the draft in section 3 and I would like to keep that = focus.=20 I turned the normative into editorial language and softened the wording = of the whole paragraph.=20 =E2=80=9CIn order to process the introspection requests in a secure and privacy-preserving manner, the authorization server must be able to = identify,=20 authenticate and authorize resource servers. If the token = introspection=20 responses shall be encrypted, the authorization server must also be = provided with=20 the respective resource server encryption keys and algorithms.=E2=80=9D= =20 >=20 > * Instead of issuing an expired JWT (or in addition) I think it should > be valid for the AS to reply with a 201, no content. For this reason, > I think that section 5 should be updated thusly: >=20 >> If the access token is invalid, expired, has been revoked, or is not = intended to be consumed by the calling resource server (audience), the = authorization server MUST set the value of the response claim > "active" to "false" if it chooses to issue a JWT. Otherwise, this > claim is set to "true". If it does not issue a JWT, the AS MUST reply > with an HTTP 204, no content, status code. If it does include a JWT > with an "active" claim of "false", the AS MAY reply with an HTTP 204, > no content, status code. >=20 > The rational is that the AS may not want to exert effort to make a > signed/encrypted JWT that is expired. Not having the token is usually > as good or better than having an expired one. Inline with RFC 7662, the AS always provides data to the RS even in case = the introspected access token is expired.=20 >=20 > * This statement makes the audience sound too narrow IMO: >=20 >> The value of the "aud" claims MUST identify the resource server = receiving the token introspection response. >=20 > Because the AS's policy may stipulate that the audience could be > others in addition to the RS some wording should be added like "the > 'aud' claim MUST identify the resource server receiving the token > introspection response and MAY contain other values based on its > policy.=E2=80=9D We intentionally specified it that way to make prevent abuse of the = token introspection response. See below my thoughts on your use case. >=20 > * The "M" in email in section 5 should not be capitalized IINM. Good catch, changed it.=20 >=20 > * In section 5, this is very broad. >=20 >> The AS determines based on the RS-specific policy what claims about = the resource owner to return in the token introspection response. The AS = MUST ensure that the release of any privacy-sensitive data is legally = based. >=20 > So, an AS must follow the law? Is that all that it's saying? Section 9 > seems to restate this point. Is conformance to the law really up to > this doc to stipulate? If the AS breaks the law, it don't conform to > the protocol. This seems very meta. It is a direct response to IESG review comments. People worry about = handling of privacy sensitive data what I totally understand. Instead of = adding normative language given concrete advice (which does not belong = into a technical specification) or prohibiting privacy sensitive data at = all (which some might prefer) we added this general advice to remind = implementers of their obligation. I removed the duplication by replacing the sentence you cited with = =E2=80=9CSee Section 9 for further considerations." >=20 > * 1st in section 9 should be spelled out as "first" and IINM it should > be "first-party" since it's being used as an adjective. You are the native speaker :-) I changed as you proposed. >=20 > * Last but certainly not least is the restriction that the current > version places on disallowing of the introspection JWT response as an > access token. This is done in numerous places (the note in section 5, > 8.1, etc.). I understand that there are some objection to this usage, > but we have had this protocol deployed for years, and it's running in > dozens of customer's facilities. This will break real applications of > this specification without a clear alternative. As we discussed in > London last year at the IETF meeting, token exchange isn't a viable > alternative (even still in its current draft form to the best of my > knowledge). Without a workable alternative to move to, I emphatically > but humbly request that this specification remove this restriction. We clarified the intention of this draft due to various feedback (IESG = review and other postings on the list). It is supposed to provide a JWT = encoded introspection response and not a transformed access token. The = main differences lay in the existence of the =E2=80=9Cactive=E2=80=9C = claim and the different =E2=80=9Eiat=E2=80=9C values.=20 In order to prevent JWT confusion, the JWT shall be restricted to the = originator of the introspection call. This prevents your use case, but = how should we distinguish this from access token replay/abuse? Also, the JWT produced cannot be sender constrained, which even more = makes its use as an access token unadvisable. In my perception, your proxy transforms the token to make it easier = consumable by the target RS.=20 I see two ways to approach it: 1) There is a (yet to be specified) function at the AS that transforms = an opaque access token into an JWT-based access token while preserving = its audience and other properties (like sender constraints). The proxy = itself requires authorization to request that functionality but is not = an audience. The access token might even be encrypted for the target RS = and be unreadable for the proxy.=20 Open: How would one implement sender constrained access tokens in that = case? I=E2=80=99m asking since the receiving RS obviously has no access = to the information from the TLS handshake since TLS termination happens = at the proxy (or even in before the request hits the proxy). The RS = would need to get provided with the cert fingerprint via a trustworthy = header, i.e. the RS must be aware of the fact it sits behind a proxy. 2) If that=E2=80=99s the case, the RS could also process the token = introspection response as received by the proxy. In order to check the = audience restriction, the introspection response would need to contain = another claim containing the original audience claims of the = introspected access token. You could build that on top of = draft-ietf-oauth-jwt-introspection-response. What would it take? - the originator of the call would need permission to act on behalf of a = RS (implementation detail of your authorization module) - the JWT would need to contain an additional claim, e.g. =E2=80=9Cat_aud=E2= =80=9D, carrying the access token=E2=80=99s audience.=20 - use a new header to carry the JWT introspection response to the RS = (just beside the header carrying the cert fingerprint) best regards, Torsten. >=20 >=20 >=20 > On Fri, Sep 20, 2019 at 2:28 PM wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >>=20 >> Title : JWT Response for OAuth Token Introspection >> Authors : Torsten Lodderstedt >> Vladimir Dzhuvinov >> Filename : = draft-ietf-oauth-jwt-introspection-response-08.txt >> Pages : 18 >> Date : 2019-09-20 >>=20 >> Abstract: >> This specification proposes an additional JSON Web Token (JWT) >> secured response for OAuth 2.0 Token Introspection. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08= >> = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-r= esponse-08 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-res= ponse-08 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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=_454B83DF-2FCD-4657-978C-6BF513C25693 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 Fw0xOTEwMDYxMzMxMjJaMC8GCSqGSIb3DQEJBDEiBCDM5xUkh3dKzWdDrm67YKTC3Y5c8QLxArHj b9+/Doua2TCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBACFiuUx14UFkscXJOZAgvU3PsnvyRkxujhh78I3cxlKmF5EaIvJuGuvqXTX1 HZJVpZeZzZ+WovA0uO35Bv/sLC3H/8UFxSPGAygdolJwlc0HhlOShmfLCQy4pGbtS0d8jd27y/FE ykQzVwuGhAHwqWHoucvR/cm69or9nEuZswxBto/irGTtpva5iDD6UeAFAkfy/RA2eR0obIuKL4Ip gnDh8YcjydaWPdeuP1vhcN3UJbbfwiKbyZn8xqtTwTJtZryi3n+qoGibabS73KDP7kCLMEF85WvB QO4DOjeNp8HBW12s/2f+1Sy17zJZtVz3rRT2TdvhIXH70iuGVsyehv8AAAAAAAA= --Apple-Mail=_454B83DF-2FCD-4657-978C-6BF513C25693-- From nobody Tue Oct 8 07:49:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02A6120883 for ; Tue, 8 Oct 2019 07:49:56 -0700 (PDT) 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=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDzF-gKsor2w for ; Tue, 8 Oct 2019 07:49:53 -0700 (PDT) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E241C120878 for ; Tue, 8 Oct 2019 07:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1570546189; bh=K3t6aKV6kRHGhVbdjMOoZAaWZGjSoYbJaVIqxvXRGeo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=q//Aw2dj28BlwK2pudPuUUte9GLbUzX+s2MdcSH25ymc3QuuANuueHQUsp425PJmg061arJvPuIJRJkHq24vajE4NBAU7c6IoaviLb0FYn1DfResfYq8XQOZhFYhapw3Iqstm0m8BLaMiZ+YJEgQdhoHmzwjjqcXh6xgU/4PytfSNeLgKCKsESYJe7LcOSRpwUQNMUdH/Fudlm7wbsN9GjPFd6dPxwlOC06uRY/cId2V0moUYMiX6jC8tkbYDpFSJ3TQ42a1ShvnJfG8KyIedoyvAMf7148D+Vj8zgql5tP+TyzGQ58taxetfW8qhfAa6HG3j2WgbACNPqwocamLLQ== X-YMail-OSG: VmOF2LcVM1l..c6V_urAnMYMKGRsYOcj7xdHr2q2rgg7os8gdvQIku3w6hwBvb3 UIC68GzCdOTDIpM0hH.1V1DfuoYv6dzO9Y1Pbc3SeT5DZ5hMEUJxseH1zhqeXof7N3B2Dl_utIr0 v7PbVdlS6GLT9xbh4zbwVez3WJQ7AiYsiY_xzs8H7FY3zRK4ulri3yxQTFhUO90bIDLpc6ZWpPBG UwyM27yfjWPfmfh1oHw8npDcdDs56AGAEx_kpNQTZF.Z.5Ni0003tEnF2GOTheZ_9pEfABwwxP7K q_UhjrD9LUmS0N3ET8JGZWtLfKUGc0vPG.mH2AdF.wjvFtApFqMgPMQSiTU1XzE5M6t7Q7oxfdgg TnblyPeGDtSJLC5p_EseHt7fXodUPkgffWg__6_opL_2_9V_WF.jUU1nLLm_qIzQehOcY5XB1hcl 0njGf1LhQfo6qgZLr2mrq_a.KKqky0AIcIx1z5Get2MNlwT1BcrugcJaj9r0TY7YB2Oo20Nmo_X7 3fP0XcDIpQmdJT.UbNZ33MG6Tf8daJvXTicfLKpXbds.H5wJ7WAwaGnAHVF0CNKctlRycpUC7EKZ 4JhRmy4AHQDt5XksBbeqlIi2V8wKFRYlSnFpqe8HdpTkL6IQesAugU.DnLWjd9NkKDgfE8XjyI5Y zw8dxVwgdz3MfSigZdlqz7RBo9TBYEHRJUkhS7T2mxLhMTXjPWa.JKx.rzjs.joUEcgr6ZcDnxd0 w_GjH0k08C3AhabRENIn56Ct67T75hR_wvNcgO2iZsOCbKu9aSzDDk5HJyAgMeHgc64SONrkevI8 KkwMt1zH7MrcOoTOWx3Ktx_CZUWwtUAQGkpfTmcpUdG9itDLSK094FdJfPuo3l3gsBOQHlDwH8YO 71h1Puqr1G0bwhsWQ_o_y9aEu7reNEoTLub89k1RUm7MX8gz.k2oPOkZtxuOZGnhTsvGyABMsWAU GAA8fqYOjwSSjkTu3OTWpI5pLLtFaVllL9DH1Np2G2Uh6gJXEM0AZBgUZnxxbmZw342dJC1gk2GZ u6OLEc.BvfCkTvf5xM5XHO1PahiCXJGi13Ad_psSKjPvM0SwKysHYW46nWD9n.jL.iXlUGt7BX.S 4WT.pIDNhrLxP5tKXmczN9C_xVBILSh1M6nh97KjsRvQyxZQmdXu6k_fhBupPNKohXkt5xunm9me UQ5KdyyVbKhvZ6LFF56f.kQ.5JlteyikRkENg2CJ3gUItQ.905HKOyg6v1G0xxX8Q_BVDeXIIjue P2xDj5sovBgdfIxzW4zp.AKPjz4Y82ygwmw2UG6fkCa.vCkqkpykXsZwrJXmOkaRvhwI0mLD.jtu j_6oagrgxqFjGrA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Oct 2019 14:49:49 +0000 Received: by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 862aa4e7f60c29114def36585dbec3ad; Tue, 08 Oct 2019 14:49:44 +0000 (UTC) To: Brian Campbell , Justin Richer Cc: oauth References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> From: George Fletcher Organization: AOL LLC Message-ID: <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com> Date: Tue, 8 Oct 2019 10:49:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------585333E9228E7E2201E367AD" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 14:49:57 -0000 This is a multi-part message in MIME format. --------------585333E9228E7E2201E367AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In general, it's difficult to determine how to extend for new types or if they should be wrapped up in "data" somehow. |{ "type":"https://example.com/my_field", "actions":[ "read" ], "my_field": { "id": "" } }| I'm assuming the above is perfectly legit and the intended way for the spec to be extended? If not, what is the expected extension mechanism? Thanks, George On 10/2/19 11:45 AM, Brian Campbell wrote: > I guess we differ in our opinion of how remiss that would be. But > given what you've got in there now, the more narrow point I was trying > to make was to say that I don't think "data" is defined or explained > well enough to be helpful. > > On Tue, Oct 1, 2019 at 4:33 PM Justin Richer > wrote: > > I think that we need to define :some: common set to data elements > in this spec, in order to help people who are using this and > trying to apply it to their APIs do so in vaguely consistent ways. > The details of which parts we standardize on are still, I think, > up for grabs. I???d be happy to have a better name than ???data??? for > this aspect, but I think there???s value in defining this kind of > thing. Like in the financial space, it???s the difference between > ???transactions??? and ???accounts???. Or in the medical space, there???s > ???demographics??? and ???appointments??? and ???testResults???. This is a > very, very, very common way to slice up OAuth-protected resources, > and we???d be remiss to leave it undefined and just have every API > developer need to come up with their own version of the same thing. > > ??? Justin > >> On Oct 1, 2019, at 2:40 PM, Brian Campbell >> > >> wrote: >> >> I'm not entirely sold on the draft attempting to define this set >> of common data elements in the first place. But that said, I >> think (similar to George?) I'm struggling with "data" more than >> the others. The definition in the -02 draft is an "array of >> strings representing the kinds of data being requested from the >> resource" and I'm honestly having a hard time understanding what >> that actually means or how it would be used in practice. And I'm >> not sure roughly equating it to ???what kind of thing I want??? >> helped me understand any better. >> >> On Tue, Sep 24, 2019 at 5:34 PM Justin Richer > > wrote: >> >> The idea behind the ???locations???, ???actions???, ???data???, and >> ???identifier??? data element types mirrors what I???ve seen >> ???scope??? used for in the wild. They roughly equate to ???where >> something is???, ???what I want to do with it???, ???what kind of >> thing I want???, and ???the exact thing I want???, respectively. >> I???m completely open for better names, and have even been >> thinking ???datatype??? might be better than just ???data??? for the >> third one. >> >> As for encoding, I think that form encoding makes sense >> because it???s the simplest possible encoding that will work. I >> personally don???t see a need to armor this part of the request >> with base64, as it is in JOSE, and doing so would make it one >> more step removed from easy developer understanding. >> >> -- Justin Richer >> >> Bespoke Engineering >> +1 (617) 564-3801 >> https://bspk.io/ >> >> >> >>> On Sep 24, 2019, at 1:45 PM, George Fletcher >>> > wrote: >>> >>> Just two questions... >>> >>> 1. What is the rationale that 'data' is really an array of >>> arbitrary top-level claims? I find looking at the spec and >>> not finding a 'data' section a little confusing. >>> >>> 2. What is the rationale for sending the JSON object as a >>> urlencoded JSON string rather than a base64url encoded JSON >>> string? The later would likely be smaller and easier to read:) >>> >>> Thanks, >>> George >>> >>> On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: >>>> Hi all,?? >>>> >>>> I just published a draft about ???OAuth 2.0 Rich >>>> Authorization Requests??? (formerly known as ???structured >>>> scopes???).?? >>>> >>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>> >>>> It specifies a new >>>> parameter?????authorization_details"??that is used to carry >>>> fine grained authorization data in the OAuth authorization >>>> request. This mechanisms was designed based on experiences >>>> gathered in the field of open banking, e.g. PSD2, and is >>>> intended to make the implementation of rich and transaction >>>> oriented authorization requests much easier than with >>>> current OAuth 2.0. >>>> >>>> I???m happy that Justin Richer and Brian Campbell joined me >>>> as authors of this draft. We would would like to thank >>>> Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat >>>> Sakimura, and Rob Otto for their valuable feedback during >>>> the preparation of this draft. >>>> >>>> We look forward to getting your feedback.?? >>>> >>>> kind regards, >>>> Torsten.?? >>>> >>>>> Begin forwarded message: >>>>> >>>>> *From: *internet-drafts@ietf.org >>>>> >>>>> *Subject: **New Version Notification for >>>>> draft-lodderstedt-oauth-rar-02.txt* >>>>> *Date: *21. September 2019 at 16:10:48 CEST >>>>> *To: *"Justin Richer" >>>> >, "Torsten Lodderstedt" >>>>> >>>> >, "Brian Campbell" >>>>> >>>> > >>>>> >>>>> >>>>> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >>>>> has been successfully submitted by Torsten Lodderstedt and >>>>> posted to the >>>>> IETF repository. >>>>> >>>>> Name:draft-lodderstedt-oauth-rar >>>>> Revision:02 >>>>> Title:OAuth 2.0 Rich Authorization Requests >>>>> Document date:2019-09-20 >>>>> Group:Individual Submission >>>>> Pages:16 >>>>> URL: >>>>> ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >>>>> Status: >>>>> ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >>>>> Htmlized: >>>>> ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>>> Htmlized: >>>>> ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >>>>> Diff: >>>>> ????????????????????https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02 >>>>> >>>>> Abstract: >>>>> ????This document specifies a new parameter >>>>> "authorization_details" that >>>>> ????is used to carry fine grained authorization data in >>>>> the OAuth >>>>> ????authorization request. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the >>>>> time of submission >>>>> until the htmlized version and diff are available at >>>>> tools.ietf.org . >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing 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./ --------------585333E9228E7E2201E367AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgSW4gZ2VuZXJhbCwgaXQncyBk aWZmaWN1bHQgdG8gZGV0ZXJtaW5lIGhvdyB0byBleHRlbmQgZm9yIG5ldyB0eXBlcwogICAg b3IgaWYgdGhleSBzaG91bGQgYmUgd3JhcHBlZCB1cCBpbiAiZGF0YSIgc29tZWhvdy48YnI+ CiAgICA8YnI+CiAgICA8cHJlIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBmb250 LWZhbWlseTogU0ZNb25vLVJlZ3VsYXIsIENvbnNvbGFzLCAmcXVvdDtMaWJlcmF0aW9uIE1v bm8mcXVvdDssIE1lbmxvLCBDb3VyaWVyLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTEuOXB4 OyBtYXJnaW4tYm90dG9tOiAxNnB4OyBtYXJnaW4tdG9wOiAwcHg7IG92ZXJmbG93LXdyYXA6 IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NiwgMjQ4LCAyNTApOyBib3JkZXIt cmFkaXVzOiAzcHg7IGxpbmUtaGVpZ2h0OiAxLjQ1OyBvdmVyZmxvdzogYXV0bzsgcGFkZGlu ZzogMTZweDsgY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQt ZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPjxjb2RlIHN0eWxlPSJib3gtc2l6aW5nOiBi b3JkZXItYm94OyBmb250LWZhbWlseTogU0ZNb25vLVJlZ3VsYXIsIENvbnNvbGFzLCAmcXVv dDtMaWJlcmF0aW9uIE1vbm8mcXVvdDssIE1lbmxvLCBDb3VyaWVyLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTEuOXB4OyBiYWNrZ3JvdW5kOiB0cmFuc3BhcmVudDsgYm9yZGVyLXJhZGl1 czogM3B4OyBtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgd2hpdGUt c3BhY2U6IHByZTsgd29yZC1icmVhazogbm9ybWFsOyBkaXNwbGF5OiBpbmxpbmU7IGxpbmUt aGVpZ2h0OiBpbmhlcml0OyBvdmVyZmxvdzogdmlzaWJsZTsgb3ZlcmZsb3ctd3JhcDogbm9y bWFsOyI+ewogICAgInR5cGUiOjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhy ZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vbXlfZmllbGQiPiJodHRwczovL2V4YW1wbGUuY29t L215X2ZpZWxkIjwvYT4sCiAgICAiYWN0aW9ucyI6WwogICAgICAgICJyZWFkIgogICAgXSwK ICAgICJteV9maWVsZCI6IHsKICAgICAgICAiaWQiOiAiJmx0O2lkX3ZhbHVlJmd0OyIKICAg IH0KfTwvY29kZT48L3ByZT4KICAgIEknbSBhc3N1bWluZyB0aGUgYWJvdmUgaXMgcGVyZmVj dGx5IGxlZ2l0IGFuZCB0aGUgaW50ZW5kZWQgd2F5IGZvcgogICAgdGhlIHNwZWMgdG8gYmUg ZXh0ZW5kZWQ/IElmIG5vdCwgd2hhdCBpcyB0aGUgZXhwZWN0ZWQgZXh0ZW5zaW9uCiAgICBt ZWNoYW5pc20/PGJyPgogICAgPGJyPgogICAgVGhhbmtzLDxicj4KICAgIEdlb3JnZTxicj4K ICAgIDxicj4KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMTAvMi8xOSAx MTo0NSBBTSwgQnJpYW4gQ2FtcGJlbGwKICAgICAgd3JvdGU6PGJyPgogICAgPC9kaXY+CiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIgpjaXRlPSJtaWQ6Q0ErazNlQ1Q9WUdzcEc5c2dY blYxQis2Wk1KQ1FHVUppdVdXMEwxMnRQb2RkcUhucnZnQG1haWwuZ21haWwuY29tIj4KICAg ICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9VVRGLTgiPgogICAgICA8ZGl2IGRpcj0ibHRyIj4KICAgICAgICA8ZGl2Pkkg Z3Vlc3Mgd2UgZGlmZmVyIGluIG91ciBvcGluaW9uIG9mIGhvdyByZW1pc3MgdGhhdCB3b3Vs ZAogICAgICAgICAgYmUuIEJ1dCBnaXZlbiB3aGF0IHlvdSd2ZSBnb3QgaW4gdGhlcmUgbm93 LCB0aGUgbW9yZSBuYXJyb3cKICAgICAgICAgIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtl IHdhcyB0byBzYXkgdGhhdCBJIGRvbid0IHRoaW5rCiAgICAgICAgICAiZGF0YSIgaXMgZGVm aW5lZCBvciBleHBsYWluZWQgd2VsbCBlbm91Z2ggdG8gYmUgaGVscGZ1bC4gPGJyPgogICAg ICAgIDwvZGl2PgogICAgICA8L2Rpdj4KICAgICAgPGJyPgogICAgICA8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+CiAgICAgICAgPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIi Pk9uIFR1ZSwgT2N0IDEsIDIwMTkgYXQgNDozMyBQTQogICAgICAgICAgSnVzdGluIFJpY2hl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIKICAgICAgICAgICAgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+ CiAgICAgICAgPC9kaXY+CiAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4CiAgICAgICAgICAwLjhleDtib3JkZXItbGVm dDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KICAgICAg ICAgIDxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ij4KICAgICAgICAg ICAgSSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZGVmaW5lIDpzb21lOiBjb21tb24gc2V0IHRv IGRhdGEKICAgICAgICAgICAgZWxlbWVudHMgaW4gdGhpcyBzcGVjLCBpbiBvcmRlciB0byBo ZWxwIHBlb3BsZSB3aG8gYXJlIHVzaW5nCiAgICAgICAgICAgIHRoaXMgYW5kIHRyeWluZyB0 byBhcHBseSBpdCB0byB0aGVpciBBUElzIGRvIHNvIGluIHZhZ3VlbHkKICAgICAgICAgICAg Y29uc2lzdGVudCB3YXlzLiBUaGUgZGV0YWlscyBvZiB3aGljaCBwYXJ0cyB3ZSBzdGFuZGFy ZGl6ZQogICAgICAgICAgICBvbiBhcmUgc3RpbGwsIEkgdGhpbmssIHVwIGZvciBncmFicy4g SeKAmWQgYmUgaGFwcHkgdG8gaGF2ZSBhCiAgICAgICAgICAgIGJldHRlciBuYW1lIHRoYW4g 4oCcZGF0YeKAnSBmb3IgdGhpcyBhc3BlY3QsIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcwogICAg ICAgICAgICB2YWx1ZSBpbiBkZWZpbmluZyB0aGlzIGtpbmQgb2YgdGhpbmcuIExpa2UgaW4g dGhlIGZpbmFuY2lhbAogICAgICAgICAgICBzcGFjZSwgaXTigJlzIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4g4oCcdHJhbnNhY3Rpb25z4oCdIGFuZAogICAgICAgICAgICDigJxhY2NvdW50 c+KAnS4gT3IgaW4gdGhlIG1lZGljYWwgc3BhY2UsIHRoZXJl4oCZcyDigJxkZW1vZ3JhcGhp Y3PigJ0KICAgICAgICAgICAgYW5kIOKAnGFwcG9pbnRtZW50c+KAnSBhbmQg4oCcdGVzdFJl c3VsdHPigJ0uIFRoaXMgaXMgYSB2ZXJ5LCB2ZXJ5LAogICAgICAgICAgICB2ZXJ5IGNvbW1v biB3YXkgdG8gc2xpY2UgdXAgT0F1dGgtcHJvdGVjdGVkIHJlc291cmNlcywgYW5kCiAgICAg ICAgICAgIHdl4oCZZCBiZSByZW1pc3MgdG8gbGVhdmUgaXQgdW5kZWZpbmVkIGFuZCBqdXN0 IGhhdmUgZXZlcnkgQVBJCiAgICAgICAgICAgIGRldmVsb3BlciBuZWVkIHRvIGNvbWUgdXAg d2l0aCB0aGVpciBvd24gdmVyc2lvbiBvZiB0aGUgc2FtZQogICAgICAgICAgICB0aGluZy7C oAogICAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgICAgICA8ZGl2PgogICAgICAgICAg ICAgICAgPGRpdgpzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpIZWx2ZXRp Y2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSI+4oCU CiAgICAgICAgICAgICAgICAgIEp1c3RpbjwvZGl2PgogICAgICAgICAgICAgIDwvZGl2Pgog ICAgICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+CiAgICAgICAgICAgICAgICAgIDxkaXY+T24gT2N0IDEsIDIwMTksIGF0IDI6 NDAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YQogICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIgogICAgICAgICAgICAgICAg ICAgICAgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OwogICAgICAgICAgICAgICAgICAgIHdyb3RlOjwv ZGl2PgogICAgICAgICAgICAgICAgICA8YnI+CiAgICAgICAgICAgICAgICAgIDxkaXY+CiAg ICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+CiAgICAgICAgICAgICAgICAgICAg ICA8ZGl2PkknbSBub3QgZW50aXJlbHkgc29sZCBvbiB0aGUgZHJhZnQgYXR0ZW1wdGluZwog ICAgICAgICAgICAgICAgICAgICAgICB0byBkZWZpbmUgdGhpcyBzZXQgb2YgY29tbW9uIGRh dGEgZWxlbWVudHMgaW4KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGZpcnN0IHBsYWNl LiBCdXQgdGhhdCBzYWlkLCBJIHRoaW5rIChzaW1pbGFyCiAgICAgICAgICAgICAgICAgICAg ICAgIHRvIEdlb3JnZT8pIEknbSBzdHJ1Z2dsaW5nIHdpdGggImRhdGEiIG1vcmUgdGhhbgog ICAgICAgICAgICAgICAgICAgICAgICB0aGUgb3RoZXJzLiBUaGUgZGVmaW5pdGlvbiBpbiB0 aGUgLTAyIGRyYWZ0IGlzCiAgICAgICAgICAgICAgICAgICAgICAgIGFuICJhcnJheSBvZiBz dHJpbmdzIHJlcHJlc2VudGluZyB0aGUga2luZHMgb2YKICAgICAgICAgICAgICAgICAgICAg ICAgZGF0YSBiZWluZyByZXF1ZXN0ZWQgZnJvbSB0aGUgcmVzb3VyY2UiIGFuZCBJJ20KICAg ICAgICAgICAgICAgICAgICAgICAgaG9uZXN0bHkgaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVy c3RhbmRpbmcgd2hhdAogICAgICAgICAgICAgICAgICAgICAgICB0aGF0IGFjdHVhbGx5IG1l YW5zIG9yIGhvdyBpdCB3b3VsZCBiZSB1c2VkIGluCiAgICAgICAgICAgICAgICAgICAgICAg IHByYWN0aWNlLiBBbmQgSSdtIG5vdCBzdXJlIHJvdWdobHkgZXF1YXRpbmcgaXQKICAgICAg ICAgICAgICAgICAgICAgICAgdG8g4oCcd2hhdCBraW5kIG9mIHRoaW5nIEkgd2FudOKAnSBo ZWxwZWQgbWUKICAgICAgICAgICAgICAgICAgICAgICAgdW5kZXJzdGFuZCBhbnkgYmV0dGVy Ljxicj4KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAg IDwvZGl2PgogICAgICAgICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAgICA8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVHVlLCBTZXAgMjQsCiAgICAgICAgICAg ICAgICAgICAgICAgIDIwMTkgYXQgNTozNCBQTSBKdXN0aW4gUmljaGVyICZsdDs8YQogICAg ICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpqdXN0aW5AYnNway5pbyIgdGFy Z2V0PSJfYmxhbmsiCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5qdXN0aW5AYnNway5pbzwvYT4mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOjxicj4KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAg ICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweAogICAgICAgICAgICAgICAgICAgICAgICAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZAogICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPgogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZSBpZGVh IGJlaGluZCB0aGUg4oCcbG9jYXRpb25z4oCdLCDigJxhY3Rpb25z4oCdLAogICAgICAgICAg ICAgICAgICAgICAgICAgIOKAnGRhdGHigJ0sIGFuZCDigJxpZGVudGlmaWVy4oCdIGRhdGEg ZWxlbWVudCB0eXBlcwogICAgICAgICAgICAgICAgICAgICAgICAgIG1pcnJvcnMgd2hhdCBJ 4oCZdmUgc2VlbiDigJxzY29wZeKAnSB1c2VkIGZvciBpbiB0aGUKICAgICAgICAgICAgICAg ICAgICAgICAgICB3aWxkLiBUaGV5IHJvdWdobHkgZXF1YXRlIHRvIOKAnHdoZXJlIHNvbWV0 aGluZwogICAgICAgICAgICAgICAgICAgICAgICAgIGlz4oCdLCDigJx3aGF0IEkgd2FudCB0 byBkbyB3aXRoIGl04oCdLCDigJx3aGF0IGtpbmQKICAgICAgICAgICAgICAgICAgICAgICAg ICBvZiB0aGluZyBJIHdhbnTigJ0sIGFuZCDigJx0aGUgZXhhY3QgdGhpbmcgSQogICAgICAg ICAgICAgICAgICAgICAgICAgIHdhbnTigJ0sIHJlc3BlY3RpdmVseS4gSeKAmW0gY29tcGxl dGVseSBvcGVuIGZvcgogICAgICAgICAgICAgICAgICAgICAgICAgIGJldHRlciBuYW1lcywg YW5kIGhhdmUgZXZlbiBiZWVuIHRoaW5raW5nCiAgICAgICAgICAgICAgICAgICAgICAgICAg 4oCcZGF0YXR5cGXigJ0gbWlnaHQgYmUgYmV0dGVyIHRoYW4ganVzdCDigJxkYXRh4oCdCiAg ICAgICAgICAgICAgICAgICAgICAgICAgZm9yIHRoZSB0aGlyZCBvbmUuCiAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9k aXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5BcyBmb3IgZW5jb2RpbmcsIEkg dGhpbmsgdGhhdCBmb3JtCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbmNvZGluZyBt YWtlcyBzZW5zZSBiZWNhdXNlIGl04oCZcyB0aGUKICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNpbXBsZXN0IHBvc3NpYmxlIGVuY29kaW5nIHRoYXQgd2lsbCB3b3JrLiBJCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwZXJzb25hbGx5IGRvbuKAmXQgc2VlIGEgbmVlZCB0 byBhcm1vciB0aGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJ0IG9mIHRoZSBy ZXF1ZXN0IHdpdGggYmFzZTY0LCBhcyBpdCBpcyBpbgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgSk9TRSwgYW5kIGRvaW5nIHNvIHdvdWxkIG1ha2UgaXQgb25lIG1vcmUKICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHN0ZXAgcmVtb3ZlZCBmcm9tIGVhc3kgZGV2ZWxvcGVy CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlcnN0YW5kaW5nLsKgPC9kaXY+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2CnN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXIt c3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+LS0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK dXN0aW4gUmljaGVyPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYK c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxl Om5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xl dHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0 ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O3RleHQtZGVjb3JhdGlvbjpub25lIj48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2CnN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFu c2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+QmVzcG9rZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVuZ2luZWVyaW5nPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYK c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxl Om5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xl dHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0 ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 O3RleHQtZGVjb3JhdGlvbjpub25lIj4rMQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICg2MTcpIDU2NC0zODAxPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYKc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250 LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIj48YQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9ic3BrLmlvLyIKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUi Pmh0dHBzOi8vYnNway5pby88L2E+PC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYKc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw YWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIj48YnI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2Pk9uIFNlcCAyNCwgMjAxOSwgYXQgMTo0NSBQTSwgR2VvcmdlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBGbGV0Y2hlciAmbHQ7PGEKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmdm ZmxldGNoQGFvbC5jb208L2E+Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgd3JvdGU6PC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2IGJnY29sb3I9IiNGRkZGRkYiPjxmb250CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlmIj5KdXN0 IHR3byBxdWVzdGlvbnMuLi48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuIFdo YXQgaXMgdGhlIHJhdGlvbmFsZSB0aGF0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJ2RhdGEnIGlzIHJlYWxseSBhbiBhcnJheSBvZgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFyYml0cmFyeSB0b3AtbGV2ZWwgY2xhaW1zPyBJIGZp bmQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb29raW5nIGF0IHRo ZSBzcGVjIGFuZCBub3QKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm aW5kaW5nIGEgJ2RhdGEnIHNlY3Rpb24gYSBsaXR0bGUKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25mdXNpbmcuPGJyPgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAyLiBXaGF0IGlzIHRoZSByYXRpb25hbGUgZm9yCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc2VuZGluZyB0aGUgSlNPTiBvYmplY3QgYXMgYQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVybGVuY29kZWQgSlNPTiBzdHJpbmcg cmF0aGVyIHRoYW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIGJh c2U2NHVybCBlbmNvZGVkIEpTT04gc3RyaW5nPwogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoZSBsYXRlciB3b3VsZCBsaWtlbHkgYmUgc21hbGxlcgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBlYXNpZXIgdG8gcmVhZDopPGJy PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsPGJyPgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEdlb3JnZTxicj4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9mb250Pjxicj4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdj5PbiA5LzIxLzE5IDE6NTEgUE0sIFRvcnN0ZW4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMb2RkZXJzdGVkdCB3cm90ZTo8YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5IaSBhbGws Pz8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PkkganVzdCBwdWJsaXNoZWQgYSBkcmFm dAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJvdXQgPz8/T0F1 dGggMi4wIFJpY2gKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1 dGhvcml6YXRpb24gUmVxdWVzdHM/Pz8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChmb3JtZXJseSBrbm93biBhcyA/Pz9zdHJ1Y3R1cmVkCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY29wZXM/Pz8pLj8/PC9kaXY+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdj48YQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyIgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyPC9hPjwvZGl2 PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SXQgc3BlY2lmaWVzIGEgbmV3CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXI/Pz8/P2F1dGhv cml6YXRpb25fZGV0YWlscyI/P3RoYXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGlzIHVzZWQgdG8gY2FycnkgZmluZSBncmFpbmVkCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhlIE9B dXRoCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemF0 aW9uIHJlcXVlc3QuIFRoaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG1lY2hhbmlzbXMgd2FzIGRlc2lnbmVkIGJhc2VkIG9uCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBleHBlcmllbmNlcyBnYXRoZXJlZCBpbiB0aGUKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZpZWxkIG9mIG9wZW4gYmFu a2luZywgZS5nLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUFNE MiwgYW5kIGlzIGludGVuZGVkIHRvIG1ha2UKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiByaWNoIGFuZAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJhbnNhY3Rpb24gb3JpZW50ZWQKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVx dWVzdHMgbXVjaAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWFz aWVyIHRoYW4gd2l0aCBjdXJyZW50IE9BdXRoCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAyLjAuPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5J Pz8/bSBoYXBweSB0aGF0IEp1c3RpbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmljaGVyIGFuZCBCcmlhbiBDYW1wYmVsbCBqb2luZWQKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lIGFzIGF1dGhvcnMgb2YgdGhpcyBkcmFm dC4gV2UKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIHdv dWxkIGxpa2UgdG8gdGhhbmsgRGFuaWVsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGZXR0LCBTZWJhc3RpYW4gRWJsaW5nLCBEYXZlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUb25nZSwgTWlrZSBKb25lcywgTmF0IFNha2lt dXJhLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIFJvYiBP dHRvIGZvciB0aGVpciB2YWx1YWJsZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZmVlZGJhY2sgZHVyaW5nIHRoZSBwcmVwYXJhdGlvbgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhpcyBkcmFmdC48L2Rpdj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2PldlIGxvb2sgZm9yd2FyZCB0byBnZXR0aW5nCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3VyIGZlZWRiYWNrLj8/PC9k aXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5raW5kIHJlZ2FyZHMsPC9kaXY+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5Ub3JzdGVuLj8/PGJy PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXY+QmVnaW4gZm9yd2FyZGVkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtZXNzYWdlOjwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJtYXJnaW46MHB4Ij48c3BhbgpzdHlsZT0iZm9u dC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCwmcXVvdDtIZWx2ZXRpY2EKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV1ZSZxdW90OyxIZWx2 ZXRpY2Esc2Fucy1zZXJpZiI+PGI+RnJvbToKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9iPjwvc3Bhbj48c3BhbgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6LXdl YmtpdC1zeXN0ZW0tZm9udCxIZWx2ZXRpY2EKTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+ PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9k aXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBz dHlsZT0ibWFyZ2luOjBweCI+PHNwYW4Kc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lz dGVtLWZvbnQsJnF1b3Q7SGVsdmV0aWNhCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE5ldWUmcXVvdDssSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxi PlN1YmplY3Q6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvYj48L3NwYW4+PHNwYW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQs SGVsdmV0aWNhCk5ldWUsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiPk5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0PC9iPjxicj4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48 L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IHN0eWxlPSJtYXJnaW46MHB4Ij48c3BhbgpzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1z eXN0ZW0tZm9udCwmcXVvdDtIZWx2ZXRpY2EKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTmV1ZSZxdW90OyxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+ PGI+RGF0ZToKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9iPjwvc3Bhbj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCxI ZWx2ZXRpY2EKTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+MjEuIFNlcHRlbWJlciAyMDE5 IGF0IDE2OjEwOjQ4IENFU1Q8YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L3NwYW4+PC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0ibWFyZ2luOjBweCI+PHNwYW4Kc3R5bGU9 ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQsJnF1b3Q7SGVsdmV0aWNhCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldWUmcXVvdDss SGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiPlRvOgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L2I+PC9zcGFuPjxzcGFuCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTot d2Via2l0LXN5c3RlbS1mb250LEhlbHZldGljYQpOZXVlLEhlbHZldGljYSxzYW5zLXNlcmlm Ij4iSnVzdGluIFJpY2hlciIgJmx0OzxhCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmlldGZAanVzdGluLnJpY2hlci5v cmciCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGFyZ2V0PSJfYmxhbmsiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5pZXRmQGp1c3Rpbi5yaWNoZXIu b3JnPC9hPiZndDssCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICJUb3JzdGVuIExvZGRlcnN0ZWR0IgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGFyZ2V0PSJfYmxhbmsiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj50b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldDwvYT4mZ3Q7LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAiQnJpYW4gQ2FtcGJlbGwiICZsdDs8YQpocmVmPSJtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozxicj4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L2Rpdj4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBIG5ldyB2ZXJzaW9uIG9m IEktRCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dDxicj4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Ym1p dHRlZCBieSBUb3JzdGVuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIExvZGRlcnN0ZWR0IGFuZCBwb3N0ZWQKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gdGhlPGJyPgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRVRGIHJlcG9zaXRvcnkuPGJyPgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5hbWU6PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PC9zcGFuPmRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJh cjxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UmV2aXNpb246PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4gPC9zcGFuPjAy PGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU aXRsZTo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPiA8L3NwYW4+PHNwYW4g c3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48L3NwYW4+T0F1dGgKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4wIFJpY2ggQXV0aG9yaXph dGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS ZXF1ZXN0czxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRG9jdW1lbnQgZGF0ZTo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAi PiA8L3NwYW4+MjAxOS0wOS0yMDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgR3JvdXA6PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwIj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PC9zcGFu PkluZGl2aWR1YWwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3VibWlzc2lvbjxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUGFnZXM6PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFw Ij4gPC9zcGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PC9zcGFuPjE2 PGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBV Ukw6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8/ Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz88YQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyLnR4dCIKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9i bGFuayIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0PC9hPjxicj4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RhdHVzOiA/ Pz8/Pz8/Pz8/Pz8/Pz8/PGEKaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLyIKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl bmQ9InRydWUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvZGRl cnN0ZWR0LW9hdXRoLXJhci88L2E+PGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBIdG1saXplZDogPz8/Pz8/Pz8/Pz8/PGEKaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0w MiIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 YXJnZXQ9Il9ibGFuayIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDI8L2E+PGJyPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdG1saXplZDogPz8/ Pz8/Pz8/Pz8/PGEKaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXIiCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxv ZGRlcnN0ZWR0LW9hdXRoLXJhcjwvYT48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIERpZmY6CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PGEKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFy LTAyIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRhcmdldD0iX2JsYW5rIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMjwvYT48YnI+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWJzdHJh Y3Q6PGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA/Pz8/VGhpcyBkb2N1bWVudAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzcGVjaWZpZXMgYSBuZXcKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJhdXRob3JpemF0aW9uX2RldGFpbHMiCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQ8YnI+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8/Pz9p cyB1c2VkIHRvIGNhcnJ5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGZpbmUgZ3JhaW5lZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGRhdGEgaW4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIE9BdXRoPGJyPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/Pz8/YXV0aG9yaXph dGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy ZXF1ZXN0Ljxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJvbSB0aGUgdGltZSBv ZgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWJt aXNzaW9uPGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdmVyc2lvbiBhbmQgZGlmZiBhcmUKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXZhaWxhYmxlIGF0IDxhCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnLyIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvb2xz LmlldGYub3JnPC9hPi48YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGZpZWxkc2V0PjwvZmllbGRz ZXQ+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHByZT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0aCBtYWlsaW5n IGxpc3QKPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5PQXV0aEBpZXRmLm9yZzwvYT4KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT4KPC9wcmU+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPgogICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAg ICAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+CiAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRoIG1haWxp bmcgbGlzdDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIKICAgICAgICAgICAgICAgICAgICAgICAg ICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk9BdXRoQGlldGYub3JnPC9hPjxicj4KICAgICAg ICAgICAgICAgICAgICAgICAgPGEKICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIgogICAgICAgICAg ICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiCiAgICAg ICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4KICAgICAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAg ICAgICAgICAgICAgICAgICA8YnI+CiAgICAgICAgICAgICAgICAgICAgPGkgc3R5bGU9Im1h cmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweAogICAgICAgICAgICAgICAgICAgICAg bm9uZTtvdXRsaW5lOmN1cnJlbnRjb2xvciBub25lCiAgICAgICAgICAgICAgICAgICAgICAw cHg7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUp CiAgICAgICAgICAgICAgICAgICAgICBub25lIHJlcGVhdCBzY3JvbGwgMCUKMCU7Zm9udC1m YW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sc3lz dGVtLXVpLCZxdW90O1NlZ29lClVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVudHUs Q2FudGFyZWxsLCZxdW90O0hlbHZldGljYQogICAgICAgICAgICAgICAgICAgICAgTmV1ZSZx dW90OyxBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOnJnYig4NSw4NSw4NSkiPjxzcGFuCiAgICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRl cjowcHgKICAgICAgICAgICAgICAgICAgICAgICAgbm9uZTtvdXRsaW5lOmN1cnJlbnRjb2xv ciBub25lCiAgICAgICAgICAgICAgICAgICAgICAgIDBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNl bGluZTtiYWNrZ3JvdW5kOnRyYW5zcGFyZW50CiAgICAgICAgICAgICAgICAgICAgICAgIG5v bmUgcmVwZWF0IHNjcm9sbCAwJQowJTtmb250LWZhbWlseTpwcm94aW1hLW5vdmEtemVuZGVz ayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJnF1b3Q7U2Vn b2UKVUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJlbGwsJnF1b3Q7 SGVsdmV0aWNhCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldWUmcXVvdDssQXJpYWwsc2Fu cy1zZXJpZjtmb250LXdlaWdodDo2MDAiPjxmb250CiAgICAgICAgICAgICAgICAgICAgICAg ICAgc2l6ZT0iMiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbAogICAgICAg ICAgICAgICAgICAgICAgICAgIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZAogICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkCiAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvcgogICAgICAgICAgICAgICAg ICAgICAgICAgIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu wqAKICAgICAgICAgICAgICAgICAgICAgICAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4KICAgICAgICAgICAgICAgICAgICAgICAgICBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5CiAgICAgICAgICAgICAgICAg ICAgICAgICAgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlCiAg ICAgICAgICAgICAgICAgICAgICAgICAgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9mb250Pjwvc3Bhbj48L2k+PC9kaXY+CiAgICAgICAgICAgICAgICA8 L2Jsb2NrcXVvdGU+CiAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgPGJyPgog ICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDwvZGl2PgogICAgICAgIDwvYmxvY2txdW90 ZT4KICAgICAgPC9kaXY+CiAgICAgIDxicj4KICAgICAgPGkKc3R5bGU9Im1hcmdpbjowcHg7 cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNl bGluZTtiYWNrZ3JvdW5kOnJnYigyNTUsMjU1LDI1NSk7Zm9udC1mYW1pbHk6cHJveGltYS1u b3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sc3lzdGVtLXVpLCZxdW90O1Nl Z29lCiAgICAgICAgVUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJl bGwsJnF1b3Q7SGVsdmV0aWNhCiAgICAgICAgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNlcmlm O2NvbG9yOnJnYig4NSw4NSw4NSkiPjxzcGFuCnN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6 MHB4O2JvcmRlcjowcHg7b3V0bGluZTowcHg7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7YmFj a2dyb3VuZDp0cmFuc3BhcmVudDtmb250LWZhbWlseTpwcm94aW1hLW5vdmEtemVuZGVzayxz eXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJnF1b3Q7U2Vnb2UK ICAgICAgICAgIFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVudHUsQ2FudGFyZWxs LCZxdW90O0hlbHZldGljYQogICAgICAgICAgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNlcmlm O2ZvbnQtd2VpZ2h0OjYwMCI+PGZvbnQgc2l6ZT0iMiI+Q09ORklERU5USUFMSVRZCiAgICAg ICAgICAgIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k IHByaXZpbGVnZWQKICAgICAgICAgICAgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkKICAgICAgICAgICAgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcwogICAgICAgICAgICBz dHJpY3RseSBwcm9oaWJpdGVkLsKgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMKICAgICAg ICAgICAgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5CiAgICAgICAgICAgIGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cwogICAgICAgICAgICBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+PC9zcGFuPjwvaT4KICAgIDwvYmxvY2txdW90ZT4K ICAgIDxicj4KICA8L2JvZHk+CjwvaHRtbD4K --------------585333E9228E7E2201E367AD-- From nobody Tue Oct 8 08:36:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CF12009E for ; Tue, 8 Oct 2019 08:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGD3dsE_Arm8 for ; Tue, 8 Oct 2019 08:36:35 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (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 AE8AF1200DE for ; Tue, 8 Oct 2019 08:36:34 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iHrXK-0007Ma-Nf; Tue, 08 Oct 2019 17:36:30 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CCCBD399-E9C7-444A-9EC2-ED9F26F346DA"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 8 Oct 2019 17:36:29 +0200 In-Reply-To: <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com> Cc: Brian Campbell , Justin Richer , oauth To: George Fletcher References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 15:36:38 -0000 --Apple-Mail=_CCCBD399-E9C7-444A-9EC2-ED9F26F346DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8. Oct 2019, at 16:49, George Fletcher = wrote: >=20 > In general, it's difficult to determine how to extend for new types or = if they should be wrapped up in "data" somehow. >=20 > { > "type": > "https://example.com/my_field" > , > "actions":[ > "read" > ], > "my_field": { > "id": "" > } > } >=20 > I'm assuming the above is perfectly legit and the intended way for the = spec to be extended? That=E2=80=99s the intended way to go. Do you have an idea how we could = convey that even better in the text? > If not, what is the expected extension mechanism? >=20 > Thanks, > George >=20 > On 10/2/19 11:45 AM, Brian Campbell wrote: >> I guess we differ in our opinion of how remiss that would be. But = given what you've got in there now, the more narrow point I was trying = to make was to say that I don't think "data" is defined or explained = well enough to be helpful.=20 >>=20 >> On Tue, Oct 1, 2019 at 4:33 PM Justin Richer wrote: >> I think that we need to define :some: common set to data elements in = this spec, in order to help people who are using this and trying to = apply it to their APIs do so in vaguely consistent ways. The details of = which parts we standardize on are still, I think, up for grabs. I=E2=80=99= d be happy to have a better name than =E2=80=9Cdata=E2=80=9D for this = aspect, but I think there=E2=80=99s value in defining this kind of = thing. Like in the financial space, it=E2=80=99s the difference between = =E2=80=9Ctransactions=E2=80=9D and =E2=80=9Caccounts=E2=80=9D. Or in the = medical space, there=E2=80=99s =E2=80=9Cdemographics=E2=80=9D and = =E2=80=9Cappointments=E2=80=9D and =E2=80=9CtestResults=E2=80=9D. This = is a very, very, very common way to slice up OAuth-protected resources, = and we=E2=80=99d be remiss to leave it undefined and just have every API = developer need to come up with their own version of the same thing.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 1, 2019, at 2:40 PM, Brian Campbell = wrote: >>>=20 >>> I'm not entirely sold on the draft attempting to define this set of = common data elements in the first place. But that said, I think (similar = to George?) I'm struggling with "data" more than the others. The = definition in the -02 draft is an "array of strings representing the = kinds of data being requested from the resource" and I'm honestly having = a hard time understanding what that actually means or how it would be = used in practice. And I'm not sure roughly equating it to =E2=80=9Cwhat = kind of thing I want=E2=80=9D helped me understand any better. >>>=20 >>> On Tue, Sep 24, 2019 at 5:34 PM Justin Richer = wrote: >>> The idea behind the =E2=80=9Clocations=E2=80=9D, =E2=80=9Cactions=E2=80= =9D, =E2=80=9Cdata=E2=80=9D, and =E2=80=9Cidentifier=E2=80=9D data = element types mirrors what I=E2=80=99ve seen =E2=80=9Cscope=E2=80=9D = used for in the wild. They roughly equate to =E2=80=9Cwhere something = is=E2=80=9D, =E2=80=9Cwhat I want to do with it=E2=80=9D, =E2=80=9Cwhat = kind of thing I want=E2=80=9D, and =E2=80=9Cthe exact thing I want=E2=80=9D= , respectively. I=E2=80=99m completely open for better names, and have = even been thinking =E2=80=9Cdatatype=E2=80=9D might be better than just = =E2=80=9Cdata=E2=80=9D for the third one. >>>=20 >>> As for encoding, I think that form encoding makes sense because = it=E2=80=99s the simplest possible encoding that will work. I personally = don=E2=80=99t see a need to armor this part of the request with base64, = as it is in JOSE, and doing so would make it one more step removed from = easy developer understanding.=20 >>>=20 >>> -- Justin Richer >>>=20 >>> Bespoke Engineering >>> +1 (617) 564-3801 >>> https://bspk.io/ >>>=20 >>>=20 >>>=20 >>>> On Sep 24, 2019, at 1:45 PM, George Fletcher = wrote: >>>>=20 >>>> Just two questions... >>>>=20 >>>> 1. What is the rationale that 'data' is really an array of = arbitrary top-level claims? I find looking at the spec and not finding a = 'data' section a little confusing. >>>>=20 >>>> 2. What is the rationale for sending the JSON object as a = urlencoded JSON string rather than a base64url encoded JSON string? The = later would likely be smaller and easier to read:) >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>> On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: >>>>> Hi all,?? >>>>>=20 >>>>> I just published a draft about ???OAuth 2.0 Rich Authorization = Requests??? (formerly known as ???structured scopes???).?? >>>>>=20 >>>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>>>=20 >>>>> It specifies a new parameter?????authorization_details"??that is = used to carry fine grained authorization data in the OAuth authorization = request. This mechanisms was designed based on experiences gathered in = the field of open banking, e.g. PSD2, and is intended to make the = implementation of rich and transaction oriented authorization requests = much easier than with current OAuth 2.0. >>>>>=20 >>>>> I???m happy that Justin Richer and Brian Campbell joined me as = authors of this draft. We would would like to thank Daniel Fett, = Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for = their valuable feedback during the preparation of this draft. >>>>>=20 >>>>> We look forward to getting your feedback.?? >>>>>=20 >>>>> kind regards, >>>>> Torsten.?? >>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for = draft-lodderstedt-oauth-rar-02.txt >>>>>> Date: 21. September 2019 at 16:10:48 CEST >>>>>> To: "Justin Richer" , "Torsten = Lodderstedt" , "Brian Campbell" = >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >>>>>> has been successfully submitted by Torsten Lodderstedt and posted = to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Name: draft-lodderstedt-oauth-rar >>>>>> Revision: 02 >>>>>> Title: OAuth 2.0 Rich Authorization Requests >>>>>> Document date: 2019-09-20 >>>>>> Group: Individual Submission >>>>>> Pages: 16 >>>>>> URL: = ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderste= dt-oauth-rar-02.txt >>>>>> Status: = ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-r= ar/ >>>>>> Htmlized: = ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>>>> Htmlized: = ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-= rar >>>>>> Diff: = ????????????????????https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-= oauth-rar-02 >>>>>>=20 >>>>>> Abstract: >>>>>> ????This document specifies a new parameter = "authorization_details" that >>>>>> ????is used to carry fine grained authorization data in the OAuth >>>>>> ????authorization request. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of = submission >>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>>=20 >>>>> 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. >>=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 --Apple-Mail=_CCCBD399-E9C7-444A-9EC2-ED9F26F346DA 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 Fw0xOTEwMDgxNTM2MzBaMC8GCSqGSIb3DQEJBDEiBCDfJDJXK3lv/5IyyxRaeQxAhTWVOaoUum48 mTgW5jgokTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBACO04ezkgk1LR4f/uW1ogrG9a9mPoFYvKMOtPMap+lHHwv5qpIgbxp3yitX4 2qOR90NcKnBr7K4KWEx1DlYzqrvB2HHugLqfKzGA8s4qZpEd6jWyaf9KlXjsckzlelYzhxZ4VZku dVuwuAkFjXjgLKfU31l9DyXVpZl1B9c56o3o5EnMTL8QJt8TkZ1+G3RTVvz35mQS6L1KXncyYr64 MBsnMUL2pm3uUTTH9MX3cH8J3P541COy0pix9389yy0Fq0Feu3PPxxq4O2y0E/i3QzBWqT5usHge /h6gPNzbGaXcqVXs1J7UUX1hDt9sgOtP80PEYJLwuHhqytEdXJGIcnwAAAAAAAA= --Apple-Mail=_CCCBD399-E9C7-444A-9EC2-ED9F26F346DA-- From nobody Wed Oct 9 18:12:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32618120020 for ; Wed, 9 Oct 2019 18:12:42 -0700 (PDT) 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 W5D5TnaVVzkP for ; Wed, 9 Oct 2019 18:12:40 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B699C120044 for ; Wed, 9 Oct 2019 18:12:39 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x9A1Cav7030103; Wed, 9 Oct 2019 21:12:36 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Oct 2019 21:12:36 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 Oct 2019 21:12:36 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 9 Oct 2019 21:12:36 -0400 From: Justin Richer To: Brian Campbell CC: Aaron Parecki , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVfwfNzZ3+8oU6oUeuCpMp7hKgZQ== Date: Thu, 10 Oct 2019 01:12:36 +0000 Message-ID: <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_53D85F8532034E368A8EB0FC9AB3D1AEmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 01:12:42 -0000 --_000_53D85F8532034E368A8EB0FC9AB3D1AEmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gaW4gZG9pbmcgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcywgSSByYW4gaW50byB0aGlzIHBy b2JsZW0gYXMgd2VsbC4gU3BlY2lmaWNhbGx5LCB3ZSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50 IHdl4oCZcmUgZGVhbGluZyB3aXRoIHRvIGZ1bGx5IHZhbGlkYXRlIHRoZSBlbmNyeXB0ZWQgcmVx dWVzdCBvYmplY3QgYXMgd2VsbCBhcyBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlvbi4gQ3VycmVu dGx5LCB0aGluZ3MgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lmaWVkLCBhbmQgcGFydCBvZiB0aGF0 IGNvbWVzIGZyb20gdGhlIGhpc3Rvcnkgb2YgdGhpcyBkb2N1bWVudDogaW4gdGhlIHByZXZpb3Vz IEZBUEkgc3BlYywgdGhlIChyZXF1aXJlZCkgc2lnbmF0dXJlIG9mIHRoZSByZXF1ZXN0IG9iamVj dCBhY3RlZCBhcyBkZS1mYWN0byBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIGNsaWVudC4gSW4gUEFS LCB3ZSBub3Qgb25seSBjYW7igJl0IHJlbHkgb24gdGhlIHJlcXVlc3QgaXRzZWxmIGJlaW5nIHNp Z25lZCwgd2UgYWxzbyByZXF1aXJlIGhhbmRsaW5nIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBp biBpdHMgbWFueSBmb3Jtcy4gVGhhdCBtZWFucyB0aGUgY2xpZW50IElEIGNvdWxkIHNob3cgdXAg aW4gYW55IGNvbWJpbmF0aW9uIG9mOg0KDQogLSBGb3JtIHBhcmFtZXRlcg0KIC0gQXV0aG9yaXph dGlvbiBoZWFkZXINCiAtIENsaWVudCBhc3NlcnRpb27igJlzIOKAnGlzcyIgZmllbGQNCiAtIFJl cXVlc3Qgb2JqZWN04oCZcyDigJxjbGllbnRfaWTigJ0gKGFuZCDigJxpc3PigJ0pIGZpZWxkDQoN CklmIHNldmVyYWwgb2YgdGhlc2UgYXJlIHNlbnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50 LiBBbmQgd2hhdGV2ZXIgdmFsdWUgY29tZXMgb3V0IG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0 aCB0aGUgY2xpZW504oCZcyBhdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkJ1dCBiZWNhdXNlIEpB UiBhbGxvd3MgeW91IHRvIHNlbmQgaW4gYSByZXF1ZXN0IHRoYXQgaXMgb25seSBhIHJlcXVlc3Qg b2JqZWN0LCBpdCBhbHNvIHNlZW1zIGxpa2UgeW91IGNvdWxkIHBhc3MgaW4ganVzdCB0aGUgcmVx dWVzdCBvYmplY3Qgd2l0aCBubyBvdGhlciBwYXJhbWV0ZXJzLCBpZiBJ4oCZbSByZWFkaW5nIHRo aXMgcmlnaHQsIHdoaWNoIHdvdWxkIGltcGx5IHRoYXQgeW91IGNvdWxkIGJlIGV4cGVjdGVkIHRv IGdsZWFuIHRoZSBjbGllbnQgSUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhv dXQgaXQgYmVpbmcgaW4gZWl0aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0 aGUgcmVxdWVzdCB0aGF04oCZcyBlYXNpbHkgYWNjZXNzZWQuDQoNClNvIGhlcmVpbiBsaWVzIHRo ZSBwcm9ibGVtLiBJbiBvcmRlciB0byBwcm9wZXJseSBwcm9jZXNzIHRoZSByZXF1ZXN0IG9iamVj dCwgeW91IG5lZWQgdG8ga25vdyB3aGljaCBjbGllbnQgeW914oCZcmUgZGVhbGluZyB3aXRoIHNv IHlvdSBjYW4gdmFsaWRhdGUgdGhlIHNpZ25pbmcgYWxncywga2V5cywgYW5kIGFsbCB0aGF0LiBG b3Igc2lnbmVkIHJlcXVlc3RzIHRoYXTigJlzIHNpbXBsZSBlbm91Z2gg4oCUIHBhcnNlIGluIG9u ZSBzdGVwLCB0aGVuIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCB0aGVuIHZhbGlkYXRlIHRoZSBz aWduYXR1cmVzLiBCdXQgZm9yIGVuY3J5cHRlZCBKV1RzIGl04oCZcyBsZXNzIGNsZWFyOiBzb21l IG1ldGhvZHMgd291bGQgdXNlIG9ubHkgdGhlIHNlcnZlcuKAmXMgcHVibGljIGtleSwgYnV0IHN5 bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29yaXRobS9lbmNvZGluZyBwYWlycyB3b3VsZCB1c2UgdGhl IGNsaWVudCBzZWNyZXQgYXMgdGhlIHBhaXJ3aXNlIHNlY3JldCBmb3IgdGhlIGVuY3J5cHRpb24u IFdoaWNoIG1lYW5zIHRoYXQgd2UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCBzZW50IHRoZSBy ZXF1ZXN0IGJlZm9yZSB0aGUgZGVjcnlwdGlvbiBoYXBwZW5zLg0KDQpXaGljaCBpbiB0dXJuIGlt cGxpZXMgb25lIG9mIHR3byB0aGluZ3MgYXJlIHRydWU6DQoNCiAtIFlvdSBjYW7igJl0IGRvIGEg cmVxdWVzdCBvYmplY3Qgd2hlbiBpdOKAmXMgZW5jcnlwdGVkIHVzaW5nIGEgc3ltbWV0cmljIGFs Z29yaXRobQ0KIC0gWW91IGhhdmUgdG8gcmVxdWlyZSB0aGUgY2xpZW50IElEIGZyb20gc29tZSBv dGhlciBwYXJ0IG9mIHRoZSByZXF1ZXN0LCBzdWNoIGFzIGEgZm9ybSBwYXJhbWV0ZXIsIGF1dGgg aGVhZGVyLCBvciBjbGllbnQgYXNzZXJ0aW9uOyB0aGUgY2xpZW50X2lkIGluIHRoZSByZXF1ZXN0 IG9iamVjdCBjYW5ub3QgYmUgY291bnRlZCBvbiBhcyBiZWluZyBzdWZmaWNpZW50DQoNCkluIG91 ciBjdXJyZW50IGRyYWZ0IGltcGxlbWVudGF0aW9uIG9mIFBBUiwgSeKAmW0gdHVybmluZyBvZmYg c3VwcG9ydCBmb3Igc3ltbWV0cmljIGVuY3J5cHRpb24gaW4gdGhpcyBvbmUgY29kZSBwYXRoLiBJ ZiB3ZSBjYW4gc29tZWhvdyBjb3VudCBvbiBiZWluZyBhYmxlIHRvIGZpbmQgYSBjbGllbnRfaWQg ZXZlcnkgdGltZSwgdGhlbiB3ZSBjYW4gcmVmYWN0b3Igb3VyIGltcGxlbWVudGF0aW9uIHRvIHBh cnNlIGFuZCBoYW5kbGUgYWxsIHRoZSBjbGllbnQgc3R1ZmYgOmJlZm9yZTogaGFuZGxpbmcgdGhl IHJlcXVlc3Qgb2JqZWN0IGl0c2VsZi4gSW4gb3RoZXIgd29yZHMsIGlmIEkgYWx3YXlzIGhhdmUg dG8gc2VuZCBzb21ldGhpbmcgdGhhdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgaW4gYWRkaXRpb24g dG8gdGhlIHJlcXVlc3Qgb2JqZWN0LCB0aGVuIEkgY2FuIGNvdW50IG9uIHRoYXQuDQoNClRob3Vn aHRzPw0KDQrigJQgSnVzdGluDQoNCk9uIFNlcCAzMCwgMjAxOSwgYXQgMTE6MjEgQU0sIEJyaWFu IENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQoNCg0KDQpPbiBUaHUsIFNlcCAyNiwgMjAxOSBhdCA5OjMwIEFNIEFhcm9uIFBhcmVja2kgPGFh cm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KPiBEZXBl bmRpbmcgb24gY2xpZW50IHR5cGUgYW5kIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCwgdGhlIHJlcXVl c3QgbWlnaHQNCj4gICBhbHNvIGluY2x1ZGUgdGhlICJjbGllbnRfaWQiIHBhcmFtZXRlci4NCg0K SSBhc3N1bWUgdGhpcyBpcyBoaW50aW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHVibGlj IGNsaWVudHMNCnNlbmRpbmcgb25seSB0aGUgImNsaWVudF9pZCIgcGFyYW1ldGVyIGFuZCBjb25m aWRlbnRpYWwgY2xpZW50cw0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRp b24gaGVhZGVyIHdoaWNoIGluY2x1ZGVzIGJvdGgNCnRoZSBjbGllbnQgSUQgYW5kIHNlY3JldD8g SXQgd291bGQgcHJvYmFibHkgYmUgaGVscGZ1bCB0byBjYWxsIG91dA0KdGhlc2UgdHdvIGNvbW1v biBleGFtcGxlcyBpZiBJIGFtIHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksDQpvdGhlcndp c2UgaXQgc2VlbXMgcHJldHR5IHZhZ3VlLg0KDQpXaGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGNvbnZl eSBpcyB0aGF0IGJlY2F1c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGF0IHRoaXMgUHVzaGVkIEF1 dGhvcml6YXRpb24gUmVxdWVzdCBFbmRwb2ludCBoYXBwZW5zIHRoZSBzYW1lIHdheSBhcyBhdCB0 aGUgdG9rZW4gZW5kcG9pbnQgKGFuZCBvdGhlciBlbmRwb2ludHMgY2FsbGVkIGRpcmVjdGx5IGJ5 IHRoZSBjbGllbnQpIHRoZSBjbGllbnRfaWQgcGFyYW1ldGVyIHdpbGwgc29tZXRpbWVzIGJlIHBy ZXNlbnQgYnV0IG5vdCBuZWNlc3NhcmlseSBhcyBzb21lIHR5cGVzIG9mIGNsaWVudCBhdXRoIHVz ZSB0aGUgY2xpZW50X2lkIHBhcmFtZXRlciAobm9uZSwgY2xpZW50X3NlY3JldF9wb3N0LCB0bHNf Y2xpZW50X2F1dGgsIHNlbGZfc2lnbmVkX3Rsc19jbGllbnRfYXV0aCkgYW5kIHNvbWUgZG9uJ3Qg KGNsaWVudF9zZWNyZXRfYmFzaWMsIGNsaWVudF9zZWNyZXRfand0LCBwcml2YXRlX2tleV9qd3Qp Lg0KDQpBbHRob3VnaCB0aGUgZHJhZnQgZG9lcyBsYXRlciBzYXkgIlRoZSBBUyBNVVNUIHZhbGlk YXRlIHRoZSByZXF1ZXN0IHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCIgd2hpY2ggSSB0aGluayBjb3VsZCByZWFzb25hYmx5IGJlIGludGVycHJldGVkIGFzIHJl cXVpcmluZyBjbGllbnRfaWQuICBlLmcuLCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njc0OT8jc2VjdGlvbi00Li4xLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/ I3NlY3Rpb24tNC4xLjE+ICYgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3Nl Y3Rpb24tNC4yLjENCg0KU28gcGVyaGFwcyB0aGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gc2hvdWxk IGJlIHJlbW92ZWQgYW5kIGhhdmUgY2xpZW50X2lkIGJlIGEgcmVxdWlyZWQgcGFyYW1ldGVyIGF0 IHRoZSBQQVIgZW5kcG9pbnQuDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_53D85F8532034E368A8EB0FC9AB3D1AEmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClNvIGluIGRvaW5nIGFuIGltcGxlbWVudGF0aW9u IG9mIHRoaXMsIEkgcmFuIGludG8gdGhpcyBwcm9ibGVtIGFzIHdlbGwuIFNwZWNpZmljYWxseSwg d2UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCB3ZeKAmXJlIGRlYWxpbmcgd2l0aCB0byBmdWxs eSB2YWxpZGF0ZSB0aGUgZW5jcnlwdGVkIHJlcXVlc3Qgb2JqZWN0IGFzIHdlbGwgYXMgcGVyZm9y bSB0aGUgYXV0aGVudGljYXRpb24uIEN1cnJlbnRseSwgdGhpbmdzIGFyZSBhIGxpdHRsZSB1bmRl cnNwZWNpZmllZCwNCiBhbmQgcGFydCBvZiB0aGF0IGNvbWVzIGZyb20gdGhlIGhpc3Rvcnkgb2Yg dGhpcyBkb2N1bWVudDogaW4gdGhlIHByZXZpb3VzIEZBUEkgc3BlYywgdGhlIChyZXF1aXJlZCkg c2lnbmF0dXJlIG9mIHRoZSByZXF1ZXN0IG9iamVjdCBhY3RlZCBhcyBkZS1mYWN0byBhdXRoZW50 aWNhdGlvbiBmb3IgdGhlIGNsaWVudC4gSW4gUEFSLCB3ZSBub3Qgb25seSBjYW7igJl0IHJlbHkg b24gdGhlIHJlcXVlc3QgaXRzZWxmIGJlaW5nIHNpZ25lZCwgd2UgYWxzbw0KIHJlcXVpcmUgaGFu ZGxpbmcgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIGl0cyBtYW55IGZvcm1zLiBUaGF0IG1l YW5zIHRoZSBjbGllbnQgSUQgY291bGQgc2hvdyB1cCBpbiBhbnkgY29tYmluYXRpb24gb2Y6DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDst IEZvcm0gcGFyYW1ldGVyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOy0gQXV0aG9yaXphdGlv biBoZWFkZXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7LSBDbGllbnQgYXNzZXJ0aW9u4oCZ cyDigJxpc3MmcXVvdDsgZmllbGQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7LSBSZXF1ZXN0 IG9iamVjdOKAmXMg4oCcY2xpZW50X2lk4oCdIChhbmQg4oCcaXNz4oCdKSBmaWVsZDxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PklmIHNldmVyYWwgb2YgdGhlc2UgYXJlIHNlbnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50 LiBBbmQgd2hhdGV2ZXIgdmFsdWUgY29tZXMgb3V0IG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0 aCB0aGUgY2xpZW504oCZcyBhdXRoZW50aWNhdGlvbiBtZXRob2QuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CdXQgYmVjYXVzZSBKQVIg YWxsb3dzIHlvdSB0byBzZW5kIGluIGEgcmVxdWVzdCB0aGF0IGlzIG9ubHkgYSByZXF1ZXN0IG9i amVjdCwgaXQgYWxzbyBzZWVtcyBsaWtlIHlvdSBjb3VsZCBwYXNzIGluIGp1c3QgdGhlIHJlcXVl c3Qgb2JqZWN0IHdpdGggbm8gb3RoZXIgcGFyYW1ldGVycywgaWYgSeKAmW0gcmVhZGluZyB0aGlz IHJpZ2h0LCB3aGljaCB3b3VsZCBpbXBseSB0aGF0IHlvdSBjb3VsZCBiZSBleHBlY3RlZCB0byBn bGVhbg0KIHRoZSBjbGllbnQgSUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhv dXQgaXQgYmVpbmcgaW4gZWl0aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0 aGUgcmVxdWVzdCB0aGF04oCZcyBlYXNpbHkgYWNjZXNzZWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TbyBoZXJlaW4gbGll cyB0aGUgcHJvYmxlbS4gSW4gb3JkZXIgdG8gcHJvcGVybHkgcHJvY2VzcyB0aGUgcmVxdWVzdCBv YmplY3QsIHlvdSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50IHlvdeKAmXJlIGRlYWxpbmcgd2l0 aCBzbyB5b3UgY2FuIHZhbGlkYXRlIHRoZSBzaWduaW5nIGFsZ3MsIGtleXMsIGFuZCBhbGwgdGhh dC4gRm9yIHNpZ25lZCByZXF1ZXN0cyB0aGF04oCZcyBzaW1wbGUgZW5vdWdoIOKAlCBwYXJzZSBp biBvbmUgc3RlcCwNCiB0aGVuIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCB0aGVuIHZhbGlkYXRl IHRoZSBzaWduYXR1cmVzLiBCdXQgZm9yIGVuY3J5cHRlZCBKV1RzIGl04oCZcyBsZXNzIGNsZWFy OiBzb21lIG1ldGhvZHMgd291bGQgdXNlIG9ubHkgdGhlIHNlcnZlcuKAmXMgcHVibGljIGtleSwg YnV0IHN5bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29yaXRobS9lbmNvZGluZyBwYWlycyB3b3VsZCB1 c2UgdGhlIGNsaWVudCBzZWNyZXQgYXMgdGhlIHBhaXJ3aXNlIHNlY3JldCBmb3INCiB0aGUgZW5j cnlwdGlvbi4gV2hpY2ggbWVhbnMgdGhhdCB3ZSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50IHNl bnQgdGhlIHJlcXVlc3QgYmVmb3JlIHRoZSBkZWNyeXB0aW9uIGhhcHBlbnMuJm5ic3A7PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPldoaWNoIGluIHR1cm4gaW1wbGllcyBvbmUgb2YgdHdvIHRoaW5n cyBhcmUgdHJ1ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOy0gWW91IGNhbuKAmXQgZG8gYSByZXF1ZXN0IG9iamVjdCB3aGVu IGl04oCZcyBlbmNyeXB0ZWQgdXNpbmcgYSBzeW1tZXRyaWMgYWxnb3JpdGhtPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOy0gWW91IGhhdmUgdG8gcmVxdWlyZSB0aGUgY2xpZW50IElEIGZyb20g c29tZSBvdGhlciBwYXJ0IG9mIHRoZSByZXF1ZXN0LCBzdWNoIGFzIGEgZm9ybSBwYXJhbWV0ZXIs IGF1dGggaGVhZGVyLCBvciBjbGllbnQgYXNzZXJ0aW9uOyB0aGUgY2xpZW50X2lkIGluIHRoZSBy ZXF1ZXN0IG9iamVjdCBjYW5ub3QgYmUgY291bnRlZCBvbiBhcyBiZWluZyBzdWZmaWNpZW50PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J biBvdXIgY3VycmVudCBkcmFmdCBpbXBsZW1lbnRhdGlvbiBvZiBQQVIsIEnigJltIHR1cm5pbmcg b2ZmIHN1cHBvcnQgZm9yIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGluIHRoaXMgb25lIGNvZGUgcGF0 aC4gSWYgd2UgY2FuIHNvbWVob3cgY291bnQgb24gYmVpbmcgYWJsZSB0byBmaW5kIGEgY2xpZW50 X2lkIGV2ZXJ5IHRpbWUsIHRoZW4gd2UgY2FuIHJlZmFjdG9yIG91ciBpbXBsZW1lbnRhdGlvbiB0 byBwYXJzZSBhbmQgaGFuZGxlDQogYWxsIHRoZSBjbGllbnQgc3R1ZmYgOmJlZm9yZTogaGFuZGxp bmcgdGhlIHJlcXVlc3Qgb2JqZWN0IGl0c2VsZi4gSW4gb3RoZXIgd29yZHMsIGlmIEkgYWx3YXlz IGhhdmUgdG8gc2VuZCBzb21ldGhpbmcgdGhhdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgaW4gYWRk aXRpb24gdG8gdGhlIHJlcXVlc3Qgb2JqZWN0LCB0aGVuIEkgY2FuIGNvdW50IG9uIHRoYXQuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aG91Z2h0cz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g U2VwIDMwLCAyMDE5LCBhdCAxMToyMSBBTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiBjbGFzcz0i Ij5iY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1LCBTZXAg MjYsIDIwMTkgYXQgOTozMCBBTSBBYXJvbiBQYXJlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86YWFy b25AcGFyZWNraS5jb20iIGNsYXNzPSIiPmFhcm9uQHBhcmVja2kuY29tPC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQomZ3Q7IERlcGVuZGluZyBvbiBjbGllbnQg dHlwZSBhbmQgYXV0aGVudGljYXRpb24gbWV0aG9kLCB0aGUgcmVxdWVzdCBtaWdodDxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7YWxzbyBpbmNsdWRlIHRoZSAmcXVvdDtjbGllbnRfaWQm cXVvdDsgcGFyYW1ldGVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgYXNzdW1lIHRo aXMgaXMgaGludGluZyBhdCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHB1YmxpYyBjbGllbnRzPGJy IGNsYXNzPSIiPg0Kc2VuZGluZyBvbmx5IHRoZSAmcXVvdDtjbGllbnRfaWQmcXVvdDsgcGFyYW1l dGVyIGFuZCBjb25maWRlbnRpYWwgY2xpZW50czxiciBjbGFzcz0iIj4NCnNlbmRpbmcgb25seSB0 aGUgSFRUUCBCYXNpYyBBdXRob3JpemF0aW9uIGhlYWRlciB3aGljaCBpbmNsdWRlcyBib3RoPGJy IGNsYXNzPSIiPg0KdGhlIGNsaWVudCBJRCBhbmQgc2VjcmV0PyBJdCB3b3VsZCBwcm9iYWJseSBi ZSBoZWxwZnVsIHRvIGNhbGwgb3V0PGJyIGNsYXNzPSIiPg0KdGhlc2UgdHdvIGNvbW1vbiBleGFt cGxlcyBpZiBJIGFtIHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksPGJyIGNsYXNzPSIiPg0K b3RoZXJ3aXNlIGl0IHNlZW1zIHByZXR0eSB2YWd1ZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5X aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGNvbnZleSBpcyB0aGF0IGJlY2F1c2UgY2xpZW50IGF1dGhl bnRpY2F0aW9uIGF0IHRoaXMgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVzdCBFbmRwb2ludCBo YXBwZW5zIHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgdG9rZW4gZW5kcG9pbnQgKGFuZCBvdGhlciBl bmRwb2ludHMgY2FsbGVkIGRpcmVjdGx5IGJ5IHRoZSBjbGllbnQpIHRoZSBjbGllbnRfaWQgcGFy YW1ldGVyIHdpbGwgc29tZXRpbWVzDQogYmUgcHJlc2VudCBidXQgbm90IG5lY2Vzc2FyaWx5IGFz IHNvbWUgdHlwZXMgb2YgY2xpZW50IGF1dGggdXNlIHRoZSBjbGllbnRfaWQgcGFyYW1ldGVyIChu b25lLCBjbGllbnRfc2VjcmV0X3Bvc3QsIHRsc19jbGllbnRfYXV0aCwgc2VsZl9zaWduZWRfdGxz X2NsaWVudF9hdXRoKSBhbmQgc29tZSBkb24ndCAoY2xpZW50X3NlY3JldF9iYXNpYywgY2xpZW50 X3NlY3JldF9qd3QsIHByaXZhdGVfa2V5X2p3dCkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbHRob3VnaCB0aGUgZHJhZnQgZG9lcyBs YXRlciBzYXkgJnF1b3Q7VGhlIEFTIE1VU1QgdmFsaWRhdGUgdGhlIHJlcXVlc3QgdGhlIHNhbWUg d2F5IGFzIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50JnF1b3Q7IHdoaWNoIEkgdGhpbmsg Y291bGQgcmVhc29uYWJseSBiZSBpbnRlcnByZXRlZCBhcyByZXF1aXJpbmcgY2xpZW50X2lkLiZu YnNwOyBlLmcuLA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/ I3NlY3Rpb24tNC4xLjEiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 NzQ5PyNzZWN0aW9uLTQuLjEuMTwvYT4gJmFtcDsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2NzQ5PyNzZWN0aW9uLTQuMi4xIiBjbGFzcz0iIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlvbi00LjIuMTwvYT4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+U28gcGVyaGFwcyB0aGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gc2hvdWxkIGJlIHJlbW92ZWQg YW5kIGhhdmUgY2xpZW50X2lkIGJlIGEgcmVxdWlyZWQgcGFyYW1ldGVyIGF0IHRoZSBQQVIgZW5k cG9pbnQuDQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGkgc3R5bGU9Im1hcmdp bjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTtiYWNrZ3JvdW5kOnJnYigyNTUsMjU1LDI1NSk7Zm9udC1mYW1pbHk6cHJveGltYS1u b3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sc3lzdGVtLXVpLCZxdW90O1NlZ29l IFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDg1LDg1LDg1KSIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRs aW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnRyYW5zcGFyZW50O2Zv bnQtZmFtaWx5OnByb3hpbWEtbm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLEJs aW5rTWFjU3lzdGVtRm9udCwmcXVvdDtTZWdvZSBVSSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMs VWJ1bnR1LENhbnRhcmVsbCwmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNl cmlmO2ZvbnQtd2VpZ2h0OjYwMCIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+Q09O RklERU5USUFMSVRZDQogTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkNCiB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+ PC9zcGFuPjwvaT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53D85F8532034E368A8EB0FC9AB3D1AEmitedu_-- From nobody Wed Oct 9 18:15:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85543120044 for ; Wed, 9 Oct 2019 18:15:04 -0700 (PDT) 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 wUmgmTk6D2Cq for ; Wed, 9 Oct 2019 18:15:01 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 4F5CC120020 for ; Wed, 9 Oct 2019 18:15:01 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x9A1FT8U030813; Wed, 9 Oct 2019 21:15:41 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Oct 2019 21:14:40 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 Oct 2019 21:14:42 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 9 Oct 2019 21:14:42 -0400 From: Justin Richer To: George Fletcher CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt Thread-Index: AQHVeKhAROPC6SDTRkqA/kQ9Ac2qtadHwoAAgAlebICAAkECAA== Date: Thu, 10 Oct 2019 01:14:42 +0000 Message-ID: <4276332C-C858-4D4D-907D-0139A9A42415@mit.edu> References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com> In-Reply-To: <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_4276332CC8584D4D907D0139A9A42415mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 01:15:05 -0000 --_000_4276332CC8584D4D907D0139A9A42415mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIHRoYXTigJlzIHRoZSBpZGVhIOKAlCBzY2hlbWEgYnkgZmlhdCBhdCB0aGUgdmVyeSBsZWFz dC4gVGhpcyBzdHJ1Y3R1cmUgc2hvdWxkIGJlIGEgZmxleGlibGUgSlNPTiBvYmplY3QgdGhhdCBj YW4gdGFrZSB3aGF0ZXZlciBzaGFwZSBpdHMgYXR0ZW5kYW50IEFQSSB3b3VsZCBuZWVkIGl0IHRv IGhhdmUuIFRoZSBnb2FsIG9mIHRoZSDigJxjb21tb24gZGF0YSBlbGVtZW50c+KAnSBpcyB0byBw cm92aWRlIGp1c3QgZW5vdWdoIHN0cnVjdHVyZSB0byBiZSBnZW5lcmFsbHkgdXNlZnVsLCBhbmQg aXTigJlzIGJhc2VkIG9uIHdoYXQgZGltZW5zaW9ucyBJ4oCZdmUgc2VlbiDigJxzY29wZeKAnSB1 c2VkIGZvciBpbiB0aGUgd2lsZCBtb3N0IG9mdGVuLiBJZiB5b3XigJl2ZSBnb3QgeW91ciBvd24g ZmllbGRzIGFuZCBkaW1lbnNpb25zLCB0aGVuIHRob3NlIGRlZmluaXRlbHkgc2hvdWxkIGJlIHRo ZWlyIG93biBzcGFjZSBhbmQgbm90IGNyYW1tZWQgaW50byB0aGUgZXhpc3Rpbmcgb25lcy4gQnV0 IGlmIHlvdeKAmXZlIGdvdCBzb21ldGhpbmcgdGhhdCBmZWVscyBsaWtlIGFuIOKAnGFjdGlvbuKA nT8gVXNlIHRoYXQgc3BhY2UuDQoNCg0K4oCUIEp1c3Rpbg0KDQpPbiBPY3QgOCwgMjAxOSwgYXQg MTA6NDkgQU0sIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0 Y2hAYW9sLmNvbT4+IHdyb3RlOg0KDQpJbiBnZW5lcmFsLCBpdCdzIGRpZmZpY3VsdCB0byBkZXRl cm1pbmUgaG93IHRvIGV4dGVuZCBmb3IgbmV3IHR5cGVzIG9yIGlmIHRoZXkgc2hvdWxkIGJlIHdy YXBwZWQgdXAgaW4gImRhdGEiIHNvbWVob3cuDQoNCg0Kew0KICAgICJ0eXBlIjoiaHR0cHM6Ly9l eGFtcGxlLmNvbS9teV9maWVsZCI8aHR0cHM6Ly9leGFtcGxlLmNvbS9teV9maWVsZD4sDQogICAg ImFjdGlvbnMiOlsNCiAgICAgICAgInJlYWQiDQogICAgXSwNCiAgICAibXlfZmllbGQiOiB7DQog ICAgICAgICJpZCI6ICI8aWRfdmFsdWU+Ig0KICAgIH0NCn0NCg0KSSdtIGFzc3VtaW5nIHRoZSBh Ym92ZSBpcyBwZXJmZWN0bHkgbGVnaXQgYW5kIHRoZSBpbnRlbmRlZCB3YXkgZm9yIHRoZSBzcGVj IHRvIGJlIGV4dGVuZGVkPyBJZiBub3QsIHdoYXQgaXMgdGhlIGV4cGVjdGVkIGV4dGVuc2lvbiBt ZWNoYW5pc20/DQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiAxMC8yLzE5IDExOjQ1IEFNLCBCcmlh biBDYW1wYmVsbCB3cm90ZToNCkkgZ3Vlc3Mgd2UgZGlmZmVyIGluIG91ciBvcGluaW9uIG9mIGhv dyByZW1pc3MgdGhhdCB3b3VsZCBiZS4gQnV0IGdpdmVuIHdoYXQgeW91J3ZlIGdvdCBpbiB0aGVy ZSBub3csIHRoZSBtb3JlIG5hcnJvdyBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSB3YXMgdG8g c2F5IHRoYXQgSSBkb24ndCB0aGluayAiZGF0YSIgaXMgZGVmaW5lZCBvciBleHBsYWluZWQgd2Vs bCBlbm91Z2ggdG8gYmUgaGVscGZ1bC4NCg0KT24gVHVlLCBPY3QgMSwgMjAxOSBhdCA0OjMzIFBN IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g d3JvdGU6DQpJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBkZWZpbmUgOnNvbWU6IGNvbW1vbiBzZXQg dG8gZGF0YSBlbGVtZW50cyBpbiB0aGlzIHNwZWMsIGluIG9yZGVyIHRvIGhlbHAgcGVvcGxlIHdo byBhcmUgdXNpbmcgdGhpcyBhbmQgdHJ5aW5nIHRvIGFwcGx5IGl0IHRvIHRoZWlyIEFQSXMgZG8g c28gaW4gdmFndWVseSBjb25zaXN0ZW50IHdheXMuIFRoZSBkZXRhaWxzIG9mIHdoaWNoIHBhcnRz IHdlIHN0YW5kYXJkaXplIG9uIGFyZSBzdGlsbCwgSSB0aGluaywgdXAgZm9yIGdyYWJzLiBJ4oCZ ZCBiZSBoYXBweSB0byBoYXZlIGEgYmV0dGVyIG5hbWUgdGhhbiDigJxkYXRh4oCdIGZvciB0aGlz IGFzcGVjdCwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIHZhbHVlIGluIGRlZmluaW5nIHRoaXMga2lu ZCBvZiB0aGluZy4gTGlrZSBpbiB0aGUgZmluYW5jaWFsIHNwYWNlLCBpdOKAmXMgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiDigJx0cmFuc2FjdGlvbnPigJ0gYW5kIOKAnGFjY291bnRz4oCdLiBPciBp biB0aGUgbWVkaWNhbCBzcGFjZSwgdGhlcmXigJlzIOKAnGRlbW9ncmFwaGljc+KAnSBhbmQg4oCc YXBwb2ludG1lbnRz4oCdIGFuZCDigJx0ZXN0UmVzdWx0c+KAnS4gVGhpcyBpcyBhIHZlcnksIHZl cnksIHZlcnkgY29tbW9uIHdheSB0byBzbGljZSB1cCBPQXV0aC1wcm90ZWN0ZWQgcmVzb3VyY2Vz LCBhbmQgd2XigJlkIGJlIHJlbWlzcyB0byBsZWF2ZSBpdCB1bmRlZmluZWQgYW5kIGp1c3QgaGF2 ZSBldmVyeSBBUEkgZGV2ZWxvcGVyIG5lZWQgdG8gY29tZSB1cCB3aXRoIHRoZWlyIG93biB2ZXJz aW9uIG9mIHRoZSBzYW1lIHRoaW5nLg0KDQrigJQgSnVzdGluDQoNCk9uIE9jdCAxLCAyMDE5LCBh dCAyOjQwIFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoNCkknbSBub3QgZW50aXJl bHkgc29sZCBvbiB0aGUgZHJhZnQgYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhpcyBzZXQgb2YgY29t bW9uIGRhdGEgZWxlbWVudHMgaW4gdGhlIGZpcnN0IHBsYWNlLiBCdXQgdGhhdCBzYWlkLCBJIHRo aW5rIChzaW1pbGFyIHRvIEdlb3JnZT8pIEknbSBzdHJ1Z2dsaW5nIHdpdGggImRhdGEiIG1vcmUg dGhhbiB0aGUgb3RoZXJzLiBUaGUgZGVmaW5pdGlvbiBpbiB0aGUgLTAyIGRyYWZ0IGlzIGFuICJh cnJheSBvZiBzdHJpbmdzIHJlcHJlc2VudGluZyB0aGUga2luZHMgb2YgZGF0YSBiZWluZyByZXF1 ZXN0ZWQgZnJvbSB0aGUgcmVzb3VyY2UiIGFuZCBJJ20gaG9uZXN0bHkgaGF2aW5nIGEgaGFyZCB0 aW1lIHVuZGVyc3RhbmRpbmcgd2hhdCB0aGF0IGFjdHVhbGx5IG1lYW5zIG9yIGhvdyBpdCB3b3Vs ZCBiZSB1c2VkIGluIHByYWN0aWNlLiBBbmQgSSdtIG5vdCBzdXJlIHJvdWdobHkgZXF1YXRpbmcg aXQgdG8g4oCcd2hhdCBraW5kIG9mIHRoaW5nIEkgd2FudOKAnSBoZWxwZWQgbWUgdW5kZXJzdGFu ZCBhbnkgYmV0dGVyLg0KDQpPbiBUdWUsIFNlcCAyNCwgMjAxOSBhdCA1OjM0IFBNIEp1c3RpbiBS aWNoZXIgPGp1c3RpbkBic3BrLmlvPG1haWx0bzpqdXN0aW5AYnNway5pbz4+IHdyb3RlOg0KVGhl IGlkZWEgYmVoaW5kIHRoZSDigJxsb2NhdGlvbnPigJ0sIOKAnGFjdGlvbnPigJ0sIOKAnGRhdGHi gJ0sIGFuZCDigJxpZGVudGlmaWVy4oCdIGRhdGEgZWxlbWVudCB0eXBlcyBtaXJyb3JzIHdoYXQg SeKAmXZlIHNlZW4g4oCcc2NvcGXigJ0gdXNlZCBmb3IgaW4gdGhlIHdpbGQuIFRoZXkgcm91Z2hs eSBlcXVhdGUgdG8g4oCcd2hlcmUgc29tZXRoaW5nIGlz4oCdLCDigJx3aGF0IEkgd2FudCB0byBk byB3aXRoIGl04oCdLCDigJx3aGF0IGtpbmQgb2YgdGhpbmcgSSB3YW504oCdLCBhbmQg4oCcdGhl IGV4YWN0IHRoaW5nIEkgd2FudOKAnSwgcmVzcGVjdGl2ZWx5LiBJ4oCZbSBjb21wbGV0ZWx5IG9w ZW4gZm9yIGJldHRlciBuYW1lcywgYW5kIGhhdmUgZXZlbiBiZWVuIHRoaW5raW5nIOKAnGRhdGF0 eXBl4oCdIG1pZ2h0IGJlIGJldHRlciB0aGFuIGp1c3Qg4oCcZGF0YeKAnSBmb3IgdGhlIHRoaXJk IG9uZS4NCg0KQXMgZm9yIGVuY29kaW5nLCBJIHRoaW5rIHRoYXQgZm9ybSBlbmNvZGluZyBtYWtl cyBzZW5zZSBiZWNhdXNlIGl04oCZcyB0aGUgc2ltcGxlc3QgcG9zc2libGUgZW5jb2RpbmcgdGhh dCB3aWxsIHdvcmsuIEkgcGVyc29uYWxseSBkb27igJl0IHNlZSBhIG5lZWQgdG8gYXJtb3IgdGhp cyBwYXJ0IG9mIHRoZSByZXF1ZXN0IHdpdGggYmFzZTY0LCBhcyBpdCBpcyBpbiBKT1NFLCBhbmQg ZG9pbmcgc28gd291bGQgbWFrZSBpdCBvbmUgbW9yZSBzdGVwIHJlbW92ZWQgZnJvbSBlYXN5IGRl dmVsb3BlciB1bmRlcnN0YW5kaW5nLg0KDQotLSBKdXN0aW4gUmljaGVyDQoNCkJlc3Bva2UgRW5n aW5lZXJpbmcNCisxICg2MTcpIDU2NC0zODAxDQpodHRwczovL2JzcGsuaW8vDQoNCg0KDQpPbiBT ZXAgMjQsIDIwMTksIGF0IDE6NDUgUE0sIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNv bTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+IHdyb3RlOg0KDQpKdXN0IHR3byBxdWVzdGlvbnMu Li4NCg0KMS4gV2hhdCBpcyB0aGUgcmF0aW9uYWxlIHRoYXQgJ2RhdGEnIGlzIHJlYWxseSBhbiBh cnJheSBvZiBhcmJpdHJhcnkgdG9wLWxldmVsIGNsYWltcz8gSSBmaW5kIGxvb2tpbmcgYXQgdGhl IHNwZWMgYW5kIG5vdCBmaW5kaW5nIGEgJ2RhdGEnIHNlY3Rpb24gYSBsaXR0bGUgY29uZnVzaW5n Lg0KDQoyLiBXaGF0IGlzIHRoZSByYXRpb25hbGUgZm9yIHNlbmRpbmcgdGhlIEpTT04gb2JqZWN0 IGFzIGEgdXJsZW5jb2RlZCBKU09OIHN0cmluZyByYXRoZXIgdGhhbiBhIGJhc2U2NHVybCBlbmNv ZGVkIEpTT04gc3RyaW5nPyBUaGUgbGF0ZXIgd291bGQgbGlrZWx5IGJlIHNtYWxsZXIgYW5kIGVh c2llciB0byByZWFkOikNCg0KVGhhbmtzLA0KR2VvcmdlDQoNCk9uIDkvMjEvMTkgMTo1MSBQTSwg VG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCkhpIGFsbCw/Pw0KDQpJIGp1c3QgcHVibGlzaGVk IGEgZHJhZnQgYWJvdXQgPz8/T0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0cz8/ PyAoZm9ybWVybHkga25vd24gYXMgPz8/c3RydWN0dXJlZCBzY29wZXM/Pz8pLj8/DQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDINCg0K SXQgc3BlY2lmaWVzIGEgbmV3IHBhcmFtZXRlcj8/Pz8/YXV0aG9yaXphdGlvbl9kZXRhaWxzIj8/ dGhhdCBpcyB1c2VkIHRvIGNhcnJ5IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4g dGhlIE9BdXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhpcyBtZWNoYW5pc21zIHdhcyBkZXNp Z25lZCBiYXNlZCBvbiBleHBlcmllbmNlcyBnYXRoZXJlZCBpbiB0aGUgZmllbGQgb2Ygb3BlbiBi YW5raW5nLCBlLmcuIFBTRDIsIGFuZCBpcyBpbnRlbmRlZCB0byBtYWtlIHRoZSBpbXBsZW1lbnRh dGlvbiBvZiByaWNoIGFuZCB0cmFuc2FjdGlvbiBvcmllbnRlZCBhdXRob3JpemF0aW9uIHJlcXVl c3RzIG11Y2ggZWFzaWVyIHRoYW4gd2l0aCBjdXJyZW50IE9BdXRoIDIuMC4NCg0KST8/P20gaGFw cHkgdGhhdCBKdXN0aW4gUmljaGVyIGFuZCBCcmlhbiBDYW1wYmVsbCBqb2luZWQgbWUgYXMgYXV0 aG9ycyBvZiB0aGlzIGRyYWZ0LiBXZSB3b3VsZCB3b3VsZCBsaWtlIHRvIHRoYW5rIERhbmllbCBG ZXR0LCBTZWJhc3RpYW4gRWJsaW5nLCBEYXZlIFRvbmdlLCBNaWtlIEpvbmVzLCBOYXQgU2FraW11 cmEsIGFuZCBSb2IgT3R0byBmb3IgdGhlaXIgdmFsdWFibGUgZmVlZGJhY2sgZHVyaW5nIHRoZSBw cmVwYXJhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpXZSBsb29rIGZvcndhcmQgdG8gZ2V0dGluZyB5 b3VyIGZlZWRiYWNrLj8/DQoNCmtpbmQgcmVnYXJkcywNClRvcnN0ZW4uPz8NCg0KQmVnaW4gZm9y d2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0DQpEYXRlOiAyMS4gU2Vw dGVtYmVyIDIwMTkgYXQgMTY6MTA6NDggQ0VTVA0KVG86ICJKdXN0aW4gUmljaGVyIiA8aWV0ZkBq dXN0aW4ucmljaGVyLm9yZzxtYWlsdG86aWV0ZkBqdXN0aW4ucmljaGVyLm9yZz4+LCAiVG9yc3Rl biBMb2RkZXJzdGVkdCIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldD4+LCAiQnJpYW4gQ2FtcGJlbGwiIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgt cmFyDQpSZXZpc2lvbjogMDINClRpdGxlOiBPQXV0aCAyLjAgUmljaCBBdXRob3JpemF0aW9uIFJl cXVlc3RzDQpEb2N1bWVudCBkYXRlOiAyMDE5LTA5LTIwDQpHcm91cDogSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczogMTYNClVSTDogPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/P2h0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIu dHh0DQpTdGF0dXM6ID8/Pz8/Pz8/Pz8/Pz8/Pz9odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXIvDQpIdG1saXplZDogPz8/Pz8/Pz8/Pz8/ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0w Mg0KSHRtbGl6ZWQ6ID8/Pz8/Pz8/Pz8/P2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyDQpEaWZmOiA/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8/P2h0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sb2RkZXJzdGVkdC1v YXV0aC1yYXItMDINCg0KQWJzdHJhY3Q6DQo/Pz8/VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBu ZXcgcGFyYW1ldGVyICJhdXRob3JpemF0aW9uX2RldGFpbHMiIHRoYXQNCj8/Pz9pcyB1c2VkIHRv IGNhcnJ5IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhlIE9BdXRoDQo/Pz8/ YXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZy8+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5P VElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQg bWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1t YWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20g eW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS4NCg0KDQo= --_000_4276332CC8584D4D907D0139A9A42415mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <815A5467F3EA3747906884A26F08B110@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiYjNDM7MSwgdGhhdOKAmXMgdGhlIGlkZWEg4oCU IHNjaGVtYSBieSBmaWF0IGF0IHRoZSB2ZXJ5IGxlYXN0LiBUaGlzIHN0cnVjdHVyZSBzaG91bGQg YmUgYSBmbGV4aWJsZSBKU09OIG9iamVjdCB0aGF0IGNhbiB0YWtlIHdoYXRldmVyIHNoYXBlIGl0 cyBhdHRlbmRhbnQgQVBJIHdvdWxkIG5lZWQgaXQgdG8gaGF2ZS4gVGhlIGdvYWwgb2YgdGhlIOKA nGNvbW1vbiBkYXRhIGVsZW1lbnRz4oCdIGlzIHRvIHByb3ZpZGUganVzdCBlbm91Z2ggc3RydWN0 dXJlIHRvIGJlIGdlbmVyYWxseQ0KIHVzZWZ1bCwgYW5kIGl04oCZcyBiYXNlZCBvbiB3aGF0IGRp bWVuc2lvbnMgSeKAmXZlIHNlZW4g4oCcc2NvcGXigJ0gdXNlZCBmb3IgaW4gdGhlIHdpbGQgbW9z dCBvZnRlbi4gSWYgeW914oCZdmUgZ290IHlvdXIgb3duIGZpZWxkcyBhbmQgZGltZW5zaW9ucywg dGhlbiB0aG9zZSBkZWZpbml0ZWx5IHNob3VsZCBiZSB0aGVpciBvd24gc3BhY2UgYW5kIG5vdCBj cmFtbWVkIGludG8gdGhlIGV4aXN0aW5nIG9uZXMuIEJ1dCBpZiB5b3XigJl2ZSBnb3Qgc29tZXRo aW5nIHRoYXQNCiBmZWVscyBsaWtlIGFuIOKAnGFjdGlvbuKAnT8gVXNlIHRoYXQgc3BhY2UuJm5i c3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3QgOCwgMjAxOSwgYXQgMTA6NDkgQU0sIEdlb3Jn ZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iIGNsYXNzPSIi PmdmZmxldGNoQGFvbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw IiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj5JbiBnZW5lcmFsLCBpdCdzIGRpZmZpY3VsdCB0 byBkZXRlcm1pbmUgaG93IHRvIGV4dGVuZCBmb3IgbmV3IHR5cGVzIG9yIGlmIHRoZXkgc2hvdWxk IGJlIHdyYXBwZWQgdXAgaW4gJnF1b3Q7ZGF0YSZxdW90OyBzb21laG93LjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxwcmUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGZvbnQt ZmFtaWx5OiBTRk1vbm8tUmVndWxhciwgQ29uc29sYXMsICZxdW90O0xpYmVyYXRpb24gTW9ubyZx dW90OywgTWVubG8sIENvdXJpZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMS45cHg7IG1hcmdp bi1ib3R0b206IDE2cHg7IG1hcmdpbi10b3A6IDBweDsgb3ZlcmZsb3ctd3JhcDogbm9ybWFsOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ2LCAyNDgsIDI1MCk7IGJvcmRlci1yYWRpdXM6IDNweDsg bGluZS1oZWlnaHQ6IDEuNDU7IG92ZXJmbG93OiBhdXRvOyBwYWRkaW5nOiAxNnB4OyBjb2xvcjog cmdiKDM2LCA0MSwgNDYpOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyIgY2xhc3M9 IiI+PGNvZGUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGZvbnQtZmFtaWx5OiBTRk1v bm8tUmVndWxhciwgQ29uc29sYXMsICZxdW90O0xpYmVyYXRpb24gTW9ubyZxdW90OywgTWVubG8s IENvdXJpZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMS45cHg7IGJhY2tncm91bmQ6IHRyYW5z cGFyZW50OyBib3JkZXItcmFkaXVzOiAzcHg7IG1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJv cmRlcjogMHB4OyB3aGl0ZS1zcGFjZTogcHJlOyB3b3JkLWJyZWFrOiBub3JtYWw7IGRpc3BsYXk6 IGlubGluZTsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IG92ZXJmbG93OiB2aXNpYmxlOyBvdmVyZmxv dy13cmFwOiBub3JtYWw7IiBjbGFzcz0iIj57DQogICAgJnF1b3Q7dHlwZSZxdW90Ozo8YSBjbGFz cz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL215X2Zp ZWxkIj4mcXVvdDtodHRwczovL2V4YW1wbGUuY29tL215X2ZpZWxkJnF1b3Q7PC9hPiwNCiAgICAm cXVvdDthY3Rpb25zJnF1b3Q7OlsNCiAgICAgICAgJnF1b3Q7cmVhZCZxdW90Ow0KICAgIF0sDQog ICAgJnF1b3Q7bXlfZmllbGQmcXVvdDs6IHsNCiAgICAgICAgJnF1b3Q7aWQmcXVvdDs6ICZxdW90 OyZsdDtpZF92YWx1ZSZndDsmcXVvdDsNCiAgICB9DQp9PC9jb2RlPjwvcHJlPg0KSSdtIGFzc3Vt aW5nIHRoZSBhYm92ZSBpcyBwZXJmZWN0bHkgbGVnaXQgYW5kIHRoZSBpbnRlbmRlZCB3YXkgZm9y IHRoZSBzcGVjIHRvIGJlIGV4dGVuZGVkPyBJZiBub3QsIHdoYXQgaXMgdGhlIGV4cGVjdGVkIGV4 dGVuc2lvbiBtZWNoYW5pc20/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzLDxi ciBjbGFzcz0iIj4NCkdlb3JnZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9Im1vei1jaXRlLXByZWZpeCI+T24gMTAvMi8xOSAxMTo0NSBBTSwgQnJpYW4gQ2FtcGJlbGwg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRl PSJtaWQ6Q0EmIzQzO2szZUNUPVlHc3BHOXNnWG5WMUImIzQzOzZaTUpDUUdVSml1V1cwTDEydFBv ZGRxSG5ydmdAbWFpbC5nbWFpbC5jb20iIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPkkgZ3Vlc3Mgd2UgZGlmZmVyIGluIG91ciBvcGluaW9uIG9mIGhv dyByZW1pc3MgdGhhdCB3b3VsZCBiZS4gQnV0IGdpdmVuIHdoYXQgeW91J3ZlIGdvdCBpbiB0aGVy ZSBub3csIHRoZSBtb3JlIG5hcnJvdyBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSB3YXMgdG8g c2F5IHRoYXQgSSBkb24ndCB0aGluayAmcXVvdDtkYXRhJnF1b3Q7IGlzIGRlZmluZWQgb3IgZXhw bGFpbmVkIHdlbGwgZW5vdWdoIHRvIGJlIGhlbHBmdWwuDQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFR1ZSwgT2N0IDEsIDIwMTkgYXQgNDozMyBQ TSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3Rl OjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQogICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJv dmVyZmxvdy13cmFwOiBicmVhay13b3JkOyIgY2xhc3M9IiI+SSB0aGluayB0aGF0IHdlIG5lZWQg dG8gZGVmaW5lIDpzb21lOiBjb21tb24gc2V0IHRvIGRhdGEgZWxlbWVudHMgaW4gdGhpcyBzcGVj LCBpbiBvcmRlciB0byBoZWxwIHBlb3BsZSB3aG8gYXJlIHVzaW5nIHRoaXMgYW5kIHRyeWluZyB0 byBhcHBseSBpdCB0byB0aGVpciBBUElzIGRvIHNvIGluIHZhZ3VlbHkgY29uc2lzdGVudCB3YXlz LiBUaGUgZGV0YWlscyBvZg0KIHdoaWNoIHBhcnRzIHdlIHN0YW5kYXJkaXplIG9uIGFyZSBzdGls bCwgSSB0aGluaywgdXAgZm9yIGdyYWJzLiBJ4oCZZCBiZSBoYXBweSB0byBoYXZlIGEgYmV0dGVy IG5hbWUgdGhhbiDigJxkYXRh4oCdIGZvciB0aGlzIGFzcGVjdCwgYnV0IEkgdGhpbmsgdGhlcmXi gJlzIHZhbHVlIGluIGRlZmluaW5nIHRoaXMga2luZCBvZiB0aGluZy4gTGlrZSBpbiB0aGUgZmlu YW5jaWFsIHNwYWNlLCBpdOKAmXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiDigJx0cmFuc2FjdGlv bnPigJ0NCiBhbmQg4oCcYWNjb3VudHPigJ0uIE9yIGluIHRoZSBtZWRpY2FsIHNwYWNlLCB0aGVy ZeKAmXMg4oCcZGVtb2dyYXBoaWNz4oCdIGFuZCDigJxhcHBvaW50bWVudHPigJ0gYW5kIOKAnHRl c3RSZXN1bHRz4oCdLiBUaGlzIGlzIGEgdmVyeSwgdmVyeSwgdmVyeSBjb21tb24gd2F5IHRvIHNs aWNlIHVwIE9BdXRoLXByb3RlY3RlZCByZXNvdXJjZXMsIGFuZCB3ZeKAmWQgYmUgcmVtaXNzIHRv IGxlYXZlIGl0IHVuZGVmaW5lZCBhbmQganVzdCBoYXZlIGV2ZXJ5IEFQSSBkZXZlbG9wZXIgbmVl ZA0KIHRvIGNvbWUgdXAgd2l0aCB0aGVpciBvd24gdmVyc2lvbiBvZiB0aGUgc2FtZSB0aGluZy4m bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDEsIDIwMTksIGF0IDI6 NDAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNz PSIiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkknbSBub3QgZW50aXJlbHkgc29sZCBvbiB0aGUgZHJhZnQgYXR0ZW1wdGluZyB0 byBkZWZpbmUgdGhpcyBzZXQgb2YgY29tbW9uIGRhdGEgZWxlbWVudHMgaW4gdGhlIGZpcnN0IHBs YWNlLiBCdXQgdGhhdCBzYWlkLCBJIHRoaW5rIChzaW1pbGFyIHRvIEdlb3JnZT8pIEknbSBzdHJ1 Z2dsaW5nIHdpdGggJnF1b3Q7ZGF0YSZxdW90OyBtb3JlIHRoYW4gdGhlIG90aGVycy4gVGhlIGRl ZmluaXRpb24gaW4gdGhlIC0wMiBkcmFmdCBpcyBhbiAmcXVvdDthcnJheQ0KIG9mIHN0cmluZ3Mg cmVwcmVzZW50aW5nIHRoZSBraW5kcyBvZiBkYXRhIGJlaW5nIHJlcXVlc3RlZCBmcm9tIHRoZSBy ZXNvdXJjZSZxdW90OyBhbmQgSSdtIGhvbmVzdGx5IGhhdmluZyBhIGhhcmQgdGltZSB1bmRlcnN0 YW5kaW5nIHdoYXQgdGhhdCBhY3R1YWxseSBtZWFucyBvciBob3cgaXQgd291bGQgYmUgdXNlZCBp biBwcmFjdGljZS4gQW5kIEknbSBub3Qgc3VyZSByb3VnaGx5IGVxdWF0aW5nIGl0IHRvIOKAnHdo YXQga2luZCBvZiB0aGluZyBJIHdhbnTigJ0NCiBoZWxwZWQgbWUgdW5kZXJzdGFuZCBhbnkgYmV0 dGVyLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24g VHVlLCBTZXAgMjQsIDIwMTkgYXQgNTozNCBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anVzdGluQGJzcGsuaW8iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiIGNsYXNzPSIiPmp1c3RpbkBic3BrLmlvPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 DQogICAgICAgICAgICAgICAgICAgICAgICAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBz b2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IiI+VGhlIGlkZWEgYmVoaW5kIHRoZSDigJxsb2NhdGlvbnPi gJ0sIOKAnGFjdGlvbnPigJ0sIOKAnGRhdGHigJ0sIGFuZCDigJxpZGVudGlmaWVy4oCdIGRhdGEg ZWxlbWVudCB0eXBlcyBtaXJyb3JzIHdoYXQgSeKAmXZlIHNlZW4g4oCcc2NvcGXigJ0gdXNlZCBm b3IgaW4gdGhlIHdpbGQuIFRoZXkgcm91Z2hseSBlcXVhdGUgdG8g4oCcd2hlcmUgc29tZXRoaW5n IGlz4oCdLCDigJx3aGF0IEkgd2FudCB0byBkbyB3aXRoIGl04oCdLCDigJx3aGF0IGtpbmQgb2Yg dGhpbmcgSSB3YW504oCdLA0KIGFuZCDigJx0aGUgZXhhY3QgdGhpbmcgSSB3YW504oCdLCByZXNw ZWN0aXZlbHkuIEnigJltIGNvbXBsZXRlbHkgb3BlbiBmb3IgYmV0dGVyIG5hbWVzLCBhbmQgaGF2 ZSBldmVuIGJlZW4gdGhpbmtpbmcg4oCcZGF0YXR5cGXigJ0gbWlnaHQgYmUgYmV0dGVyIHRoYW4g anVzdCDigJxkYXRh4oCdIGZvciB0aGUgdGhpcmQgb25lLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgZm9yIGVuY29kaW5nLCBJIHRoaW5rIHRo YXQgZm9ybSBlbmNvZGluZyBtYWtlcyBzZW5zZSBiZWNhdXNlIGl04oCZcyB0aGUgc2ltcGxlc3Qg cG9zc2libGUgZW5jb2RpbmcgdGhhdCB3aWxsIHdvcmsuIEkgcGVyc29uYWxseSBkb27igJl0IHNl ZSBhIG5lZWQgdG8gYXJtb3IgdGhpcyBwYXJ0IG9mIHRoZSByZXF1ZXN0IHdpdGggYmFzZTY0LCBh cyBpdCBpcyBpbiBKT1NFLCBhbmQgZG9pbmcgc28gd291bGQgbWFrZSBpdCBvbmUgbW9yZQ0KIHN0 ZXAgcmVtb3ZlZCBmcm9tIGVhc3kgZGV2ZWxvcGVyIHVuZGVyc3RhbmRpbmcuJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246 bm9uZSIgY2xhc3M9IiI+DQotLSBKdXN0aW4gUmljaGVyPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3 aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0i Ij4NCkJlc3Bva2UgRW5naW5lZXJpbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4N CiYjNDM7MSAoNjE3KSA1NjQtMzgwMTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6 bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly9ic3BrLmlvLyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgY2xhc3M9IiI+aHR0cHM6Ly9ic3BrLmlvLzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5n Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpu b25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpu b25lIiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjQsIDIwMTksIGF0IDE6NDUgUE0sIEdl b3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmdmZmxldGNoQGFvbC5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGJnY29sb3I9IiNGRkZGRkYiIGNsYXNzPSIiPjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJp YWwsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNhbnMtc2VyaWYiIGNs YXNzPSIiPkp1c3QgdHdvIHF1ZXN0aW9ucy4uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjEuIFdoYXQgaXMgdGhlIHJhdGlvbmFsZSB0aGF0ICdkYXRhJyBpcyByZWFsbHkgYW4gYXJyYXkg b2YgYXJiaXRyYXJ5IHRvcC1sZXZlbCBjbGFpbXM/IEkgZmluZCBsb29raW5nIGF0IHRoZSBzcGVj IGFuZCBub3QgZmluZGluZyBhICdkYXRhJyBzZWN0aW9uIGEgbGl0dGxlIGNvbmZ1c2luZy48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoyLiBXaGF0IGlzIHRoZSByYXRpb25hbGUgZm9yIHNl bmRpbmcgdGhlIEpTT04gb2JqZWN0IGFzIGEgdXJsZW5jb2RlZCBKU09OIHN0cmluZyByYXRoZXIg dGhhbiBhIGJhc2U2NHVybCBlbmNvZGVkIEpTT04gc3RyaW5nPyBUaGUgbGF0ZXIgd291bGQgbGlr ZWx5IGJlIHNtYWxsZXIgYW5kIGVhc2llciB0byByZWFkOik8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KR2VvcmdlPGJyIGNsYXNzPSIiPg0KPC9mb250 PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gOS8yMS8xOSAxOjUxIFBNLCBUb3JzdGVu IExvZGRlcnN0ZWR0IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+SGkgYWxsLD8/DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGp1c3QgcHVibGlzaGVkIGEgZHJhZnQgYWJvdXQgPz8/ T0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0cz8/PyAoZm9ybWVybHkga25vd24g YXMgPz8/c3RydWN0dXJlZCBzY29wZXM/Pz8pLj8/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyIiB0YXJnZXQ9Il9ibGFu ayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyLTAyPC9hPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgc3BlY2lmaWVzIGEg bmV3IHBhcmFtZXRlcj8/Pz8/YXV0aG9yaXphdGlvbl9kZXRhaWxzJnF1b3Q7Pz90aGF0IGlzIHVz ZWQgdG8gY2FycnkgZmluZSBncmFpbmVkIGF1dGhvcml6YXRpb24gZGF0YSBpbiB0aGUgT0F1dGgg YXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGlzIG1lY2hhbmlzbXMgd2FzIGRlc2lnbmVkIGJhc2Vk IG9uIGV4cGVyaWVuY2VzIGdhdGhlcmVkIGluIHRoZSBmaWVsZCBvZiBvcGVuIGJhbmtpbmcsIGUu Zy4gUFNEMiwNCiBhbmQgaXMgaW50ZW5kZWQgdG8gbWFrZSB0aGUgaW1wbGVtZW50YXRpb24gb2Yg cmljaCBhbmQgdHJhbnNhY3Rpb24gb3JpZW50ZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0cyBtdWNo IGVhc2llciB0aGFuIHdpdGggY3VycmVudCBPQXV0aCAyLjAuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JPz8/bSBoYXBweSB0aGF0IEp1 c3RpbiBSaWNoZXIgYW5kIEJyaWFuIENhbXBiZWxsIGpvaW5lZCBtZSBhcyBhdXRob3JzIG9mIHRo aXMgZHJhZnQuIFdlIHdvdWxkIHdvdWxkIGxpa2UgdG8gdGhhbmsgRGFuaWVsIEZldHQsIFNlYmFz dGlhbiBFYmxpbmcsIERhdmUgVG9uZ2UsIE1pa2UgSm9uZXMsIE5hdCBTYWtpbXVyYSwgYW5kIFJv YiBPdHRvIGZvciB0aGVpciB2YWx1YWJsZSBmZWVkYmFjayBkdXJpbmcgdGhlIHByZXBhcmF0aW9u DQogb2YgdGhpcyBkcmFmdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPldlIGxvb2sgZm9yd2FyZCB0byBnZXR0aW5nIHlvdXIgZmVlZGJh Y2suPz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPmtpbmQgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VG9yc3Rlbi4/PzxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBweCIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQsJnF1b3Q7SGVsdmV0aWNh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXVlJnF1 b3Q7LEhlbHZldGljYSxzYW5zLXNlcmlmIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5Gcm9tOg0KPC9i Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCxIZWx2 ZXRpY2ENCk5ldWUsSGVsdmV0aWNhLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNl bmQ9InRydWUiIGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MHB4IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCwmcXVvdDtIZWx2ZXRpY2EN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldWUmcXVv dDssSGVsdmV0aWNhLHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1YmplY3Q6DQo8 L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1mb250LEhl bHZldGljYQ0KTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+ TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXIt MDIudHh0PC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjowcHgiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1m b250LCZxdW90O0hlbHZldGljYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTmV1ZSZxdW90OyxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGIg Y2xhc3M9IiI+RGF0ZToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oi13ZWJr aXQtc3lzdGVtLWZvbnQsSGVsdmV0aWNhDQpOZXVlLEhlbHZldGljYSxzYW5zLXNlcmlmIiBjbGFz cz0iIj4yMS4gU2VwdGVtYmVyIDIwMTkgYXQgMTY6MTA6NDggQ0VTVDxiciBjbGFzcz0iIj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowcHgiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1mb250LCZxdW90O0hlbHZldGljYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV1ZSZxdW90OyxIZWx2 ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+VG86DQo8L2I+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1mb250LEhlbHZldGljYQ0KTmV1 ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+JnF1b3Q7SnVzdGluIFJpY2hlciZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAanVzdGluLnJpY2hlci5vcmciIHRhcmdldD0iX2Js YW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmlldGZAanVzdGluLnJpY2hlci5v cmc8L2E+Jmd0OywgJnF1b3Q7VG9yc3RlbiBMb2RkZXJzdGVkdCZxdW90Ow0KICZsdDs8YSBocmVm PSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8t bm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDss ICZxdW90O0JyaWFuIENhbXBiZWxsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUi IGNsYXNzPSIiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVyc3Rl ZHQtb2F1dGgtcmFyLTAyLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZTxiciBjbGFz cz0iIj4NCklFVEYgcmVwb3NpdG9yeS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYW1l OjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj48c3Bh biBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPjwvc3Bhbj5kcmFmdC1sb2Rk ZXJzdGVkdC1vYXV0aC1yYXI8YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjo8c3BhbiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPiA8L3NwYW4+MDI8YnIgY2xhc3M9IiI+DQpUaXRs ZTo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPiA8L3NwYW4+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj48L3NwYW4+T0F1dGggMi4w IFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0czxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6 PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjIwMTkt MDktMjA8YnIgY2xhc3M9IiI+DQpHcm91cDo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdy YXAiIGNsYXNzPSIiPiA8L3NwYW4+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBj bGFzcz0iIj48L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KUGFnZXM6 PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjxzcGFu IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+PC9zcGFuPjE2PGJyIGNsYXNz PSIiPg0KVVJMOiA/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhci0wMi50eHQi IHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXIt MDIudHh0PC9hPjxiciBjbGFzcz0iIj4NClN0YXR1czogPz8/Pz8/Pz8/Pz8/Pz8/PzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRo LXJhci8iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJh ci88L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ID8/Pz8/Pz8/Pz8/PzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIiIHRh cmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDI8L2E+PGJyIGNs YXNzPSIiPg0KSHRtbGl6ZWQ6ID8/Pz8/Pz8/Pz8/PzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmFyIiB0YXJnZXQ9 Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXJhcjwvYT48YnIg Y2xhc3M9IiI+DQpEaWZmOiA/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDIiIHRh cmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yYXItMDI8L2E+ PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KPz8/ P1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IHBhcmFtZXRlciAmcXVvdDthdXRob3JpemF0 aW9uX2RldGFpbHMmcXVvdDsgdGhhdDxiciBjbGFzcz0iIj4NCj8/Pz9pcyB1c2VkIHRvIGNhcnJ5 IGZpbmUgZ3JhaW5lZCBhdXRob3JpemF0aW9uIGRhdGEgaW4gdGhlIE9BdXRoPGJyIGNsYXNzPSIi Pg0KPz8/P2F1dGhvcml6YXRpb24gcmVxdWVzdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJn ZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYu b3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGZpZWxk c2V0IGNsYXNzPSIiPjwvZmllbGRzZXQ+DQo8cHJlIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxpIHN0eWxlPSJtYXJnaW46 MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHgNCiAgICAgICAgICAgICAgICAgICAgICBub25lO291 dGxpbmU6Y3VycmVudGNvbG9yIG5vbmUNCiAgICAgICAgICAgICAgICAgICAgICAwcHg7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUpDQogICAgICAgICAg ICAgICAgICAgICAgbm9uZSByZXBlYXQgc2Nyb2xsIDAlDQowJTtmb250LWZhbWlseTpwcm94aW1h LW5vdmEtemVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxzeXN0ZW0tdWksJnF1b3Q7U2Vn b2UNClVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVudHUsQ2FudGFyZWxsLCZxdW90O0hl bHZldGljYQ0KICAgICAgICAgICAgICAgICAgICAgIE5ldWUmcXVvdDssQXJpYWwsc2Fucy1zZXJp Zjtjb2xvcjpyZ2IoODUsODUsODUpIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtw YWRkaW5nOjBweDtib3JkZXI6MHB4DQogICAgICAgICAgICAgICAgICAgICAgICBub25lO291dGxp bmU6Y3VycmVudGNvbG9yIG5vbmUNCiAgICAgICAgICAgICAgICAgICAgICAgIDBweDt2ZXJ0aWNh bC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnRyYW5zcGFyZW50DQogICAgICAgICAgICAgICAg ICAgICAgICBub25lIHJlcGVhdCBzY3JvbGwgMCUNCjAlO2ZvbnQtZmFtaWx5OnByb3hpbWEtbm92 YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwmcXVv dDtTZWdvZQ0KVUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJlbGwsJnF1 b3Q7SGVsdmV0aWNhDQogICAgICAgICAgICAgICAgICAgICAgICBOZXVlJnF1b3Q7LEFyaWFsLHNh bnMtc2VyaWY7Zm9udC13ZWlnaHQ6NjAwIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0i Ij5DT05GSURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlz Y2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQog dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9m b250Pjwvc3Bhbj48L2k+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxpIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHg7b3V0bGluZTowcHg7 dmVydGljYWwtYWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUpO2ZvbnQt ZmFtaWx5OnByb3hpbWEtbm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLHN5c3Rl bS11aSwmcXVvdDtTZWdvZQ0KICAgICAgICBVSSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMsVWJ1 bnR1LENhbnRhcmVsbCwmcXVvdDtIZWx2ZXRpY2ENCiAgICAgICAgTmV1ZSZxdW90OyxBcmlhbCxz YW5zLXNlcmlmO2NvbG9yOnJnYig4NSw4NSw4NSkiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJtYXJn aW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHg7b3V0bGluZTowcHg7dmVydGljYWwtYWxpZ246 YmFzZWxpbmU7YmFja2dyb3VuZDp0cmFuc3BhcmVudDtmb250LWZhbWlseTpwcm94aW1hLW5vdmEt emVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJnF1b3Q7 U2Vnb2UNCiAgICAgICAgICBVSSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMsVWJ1bnR1LENhbnRh cmVsbCwmcXVvdDtIZWx2ZXRpY2ENCiAgICAgICAgICBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2Vy aWY7Zm9udC13ZWlnaHQ6NjAwIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5DT05G SURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQogdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9mb250Pjwv c3Bhbj48L2k+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4276332CC8584D4D907D0139A9A42415mitedu_-- From nobody Thu Oct 10 00:07:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8892E12004D for ; Thu, 10 Oct 2019 00:07:22 -0700 (PDT) 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 rsd7Zy6mLpEx for ; Thu, 10 Oct 2019 00:07:19 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D782120033 for ; Thu, 10 Oct 2019 00:07:19 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id x3so4026454oig.2 for ; Thu, 10 Oct 2019 00:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CCSHvmEl97ZZqXLcOi5Io1E0tRHRIiyUg1S6Ex6ZzEk=; b=K1C22S+QJWua3jIsD7k1NNMiP9+PNptSNqfLG5k8p6EvUrNrv68CNtXnFuvou/ZXUa PdS2GtRJ0dAq540RbxrElTPKd9mCWklpgVRlu0GIpJOVJ48CJzbjhSz209QVGhEUBSjz lhjFMjru3XQ0R8uM1Pmf7pIhl38QX1BGZuH9gFNZsh0bqhER9F16PSoZ7e69nq7jNcM6 1yAwnXkzfz4zbZbWt3wHZz2iml4sNRwbgMV368JKmGD7YRy5ljOVeVxtEvNYJwZfCFMx D07l47k7DXMHOxElTzMIQMeb8KSw7PGpDKcMBtls4yolBhUFMskzHE6j8ENb7HV8OLUa Lzng== 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=CCSHvmEl97ZZqXLcOi5Io1E0tRHRIiyUg1S6Ex6ZzEk=; b=pXn9EAE6P8O0ZN/BiFbnWkmfKv2NVoAxY/MFahd6ZMss0Fu1I3XgILc8AGnD5IXk2h sT9FP4dIyID6RBKPkNA6empXx9QeIHmio2zRRAqFBv9FLJw+ogCUVgz0KyIq9gyAGSLA hvZy6Nekd3P+1z3xLQJJniC0/uOGUq/vDzsgmAVEFUu03TLzx0X4NWzPCW7LPcIWEGeq uYVd4a2RudjBtyeEFRDX38jJSuqH5IkjEBw1t32EEEXw9ZlM1b0N7F6QslYkh5KTmk6m M1YWEAfCiYrAfD9SqEanLDuiNYL9PfBoeN+4gZzmMRIfMSHRuMe2ZasBykC2ymiqO4w7 SkgQ== X-Gm-Message-State: APjAAAXbCduG6L6dqBmLSiL46BMngcRyYP5/cAde/PXFMqQ3Z3VQg6Cz GiiMKmwabNYm1zGnId09uptPAhzojXtFdTp5YA== X-Google-Smtp-Source: APXvYqyzJT7qChBSvyMwo40AS8UX0idjyrNA0QnAEAsSxd3M6CceRwb10IB/+mSf/Z+2tifq2rNypGLJ35ynl3+/t8I= X-Received: by 2002:aca:5ed4:: with SMTP id s203mr6028388oib.149.1570691238447; Thu, 10 Oct 2019 00:07:18 -0700 (PDT) MIME-Version: 1.0 References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> In-Reply-To: <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> From: Filip Skokan Date: Thu, 10 Oct 2019 09:07:00 +0200 Message-ID: To: Justin Richer Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000051cfc70594890da0" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 07:07:22 -0000 --00000000000051cfc70594890da0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If several of these are sent, they need to be consistent. Given that client authentication precedes processing the rest of the request, if several client authentication methods are provided (header + secret or secret + assertion, etc) you generally reject the request, don't you? Then there's the requirement for the client_id given by authentication method (none is still an "authentication" method - client_id in the body) to match the `iss` and `client_id` in the request object. That's already required by JAR processing rules and also PAR. > But because JAR allows you to send in a request that is only a request object, it also seems like you could pass in just the request object with no other parameters, if I=E2=80=99m reading this right, which would imply t= hat you could be expected to glean the client ID from the request object itself without it being in either a parameter or in another part of the request that=E2=80=99s easily accessed. It was only in the original FAPI revision of PAR that allowed the request object's signature to substitute client authentication, in the individual draft published to IETF that's not the case anymore - hence if "only" a request object is passed - with no client authentication (header, client_id in body, mtls) you fail the request. As far as requiring client_id, here's what my implementation does > When providing form-encoded parameters - client_id must be present in the form. > When providing signed/encrypted request object - client_id must be present in the request object. I wouldn't mind always requiring client_id, and i'm not worried about it not matching e.g. the authorization header because the client authentication middleware in place already takes care of that. S pozdravem, *Filip Skokan* On Thu, 10 Oct 2019 at 03:13, Justin Richer wrote: > So in doing an implementation of this, I ran into this problem as well. > Specifically, we need to know which client we=E2=80=99re dealing with to = fully > validate the encrypted request object as well as perform the > authentication. Currently, things are a little underspecified, and part o= f > that comes from the history of this document: in the previous FAPI spec, > the (required) signature of the request object acted as de-facto > authentication for the client. In PAR, we not only can=E2=80=99t rely on = the > request itself being signed, we also require handling of client > authentication in its many forms. That means the client ID could show up = in > any combination of: > > - Form parameter > - Authorization header > - Client assertion=E2=80=99s =E2=80=9Ciss" field > - Request object=E2=80=99s =E2=80=9Cclient_id=E2=80=9D (and =E2=80=9Ciss= =E2=80=9D) field > > If several of these are sent, they need to be consistent. And whatever > value comes out needs to be consistent with the client=E2=80=99s authenti= cation > method. > > But because JAR allows you to send in a request that is only a request > object, it also seems like you could pass in just the request object with > no other parameters, if I=E2=80=99m reading this right, which would imply= that you > could be expected to glean the client ID from the request object itself > without it being in either a parameter or in another part of the request > that=E2=80=99s easily accessed. > > So herein lies the problem. In order to properly process the request > object, you need to know which client you=E2=80=99re dealing with so you = can > validate the signing algs, keys, and all that. For signed requests that= =E2=80=99s > simple enough =E2=80=94 parse in one step, then authenticate the client, = then > validate the signatures. But for encrypted JWTs it=E2=80=99s less clear: = some > methods would use only the server=E2=80=99s public key, but symmetric enc= ryption > algorithm/encoding pairs would use the client secret as the pairwise secr= et > for the encryption. Which means that we need to know which client sent th= e > request before the decryption happens. > > Which in turn implies one of two things are true: > > - You can=E2=80=99t do a request object when it=E2=80=99s encrypted usin= g a symmetric > algorithm > - You have to require the client ID from some other part of the request, > such as a form parameter, auth header, or client assertion; the client_id > in the request object cannot be counted on as being sufficient > > In our current draft implementation of PAR, I=E2=80=99m turning off suppo= rt for > symmetric encryption in this one code path. If we can somehow count on > being able to find a client_id every time, then we can refactor our > implementation to parse and handle all the client stuff :before: handling > the request object itself. In other words, if I always have to send > something that identifies the client in addition to the request object, > then I can count on that. > > Thoughts? > > =E2=80=94 Justin > > On Sep 30, 2019, at 11:21 AM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > > > On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote: > >> > Depending on client type and authentication method, the request might >> > also include the "client_id" parameter. >> >> I assume this is hinting at the difference between public clients >> sending only the "client_id" parameter and confidential clients >> sending only the HTTP Basic Authorization header which includes both >> the client ID and secret? It would probably be helpful to call out >> these two common examples if I am understanding this correctly, >> otherwise it seems pretty vague. >> > > What this is trying to convey is that because client authentication at > this Pushed Authorization Request Endpoint happens the same way as at the > token endpoint (and other endpoints called directly by the client) the > client_id parameter will sometimes be present but not necessarily as some > types of client auth use the client_id parameter (none, client_secret_pos= t, > tls_client_auth, self_signed_tls_client_auth) and some don't > (client_secret_basic, client_secret_jwt, private_key_jwt). > > Although the draft does later say "The AS MUST validate the request the > same way as at the authorization endpoint" which I think could reasonably > be interpreted as requiring client_id. e.g., > https://tools.ietf.org/html/rfc6749?#section-4..1.1 > & > https://tools.ietf.org/html/rfc6749?#section-4.2.1 > > So perhaps the sentence in question should be removed and have client_id > be a required parameter at the PAR endpoint. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended 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 > --00000000000051cfc70594890da0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0If several= of these are sent, they need to be consistent.

Given that client authentication=C2=A0precedes=C2=A0processing the rest of the request, if several client a= uthentication methods are provided (header=C2=A0+ secret or secret=C2=A0+ a= ssertion, etc)=C2=A0you generally reject the request, don't you?=

Then there's the requirement for the client_id = given by authentication method (none is still an "authentication"= method - client_id in the body) to match the `iss` and `client_id` in the = request object. That's already required by JAR processing rules and als= o PAR.

<= div>>=C2=A0But because JAR allows you to send in a request that is only a = request object, it also seems like you could pass in just the request objec= t with no other parameters, if I=E2=80=99m reading this right, which would = imply that you could be expected to glean the client ID from the request ob= ject itself without it being in either a parameter or in another part of th= e request that=E2=80=99s easily accessed.=C2=A0

It was only in the original FAPI revision of PAR that allowed the reques= t object's signature to substitute client authentication, in the indivi= dual draft published to IETF that's not the case anymore - hence if &qu= ot;only" a request object is passed - with no client authentication (h= eader, client_id in body, mtls) you fail the request.

As far as requiring client_id, here's what my implementation d= oes

> When providing form-encoded parameters - clie= nt_id must be present in the form.
> When providing signed/encrypted request object - client_id must be pr= esent in the request object.

<= /font>
I wouldn't mind always requiri= ng client_id, and i'm not worried about it not matching e.g. the author= ization header because the client authentication middleware in place alread= y takes care of that.

S pozdravem,
Filip Skokan


On Thu, 10 Oct 2019 at 03:13, Justin Riche= r <jricher@mit.edu> wrote:
=
So in doing an implementation of this, I ran into this problem as well. Spe= cifically, we need to know which client we=E2=80=99re dealing with to fully= validate the encrypted request object as well as perform the authenticatio= n. Currently, things are a little underspecified, and part of that comes from the history of this document: in the previous = FAPI spec, the (required) signature of the request object acted as de-facto= authentication for the client. In PAR, we not only can=E2=80=99t rely on t= he request itself being signed, we also require handling of client authentication in its many forms. That means th= e client ID could show up in any combination of:

=C2=A0- Form parameter
=C2=A0- Authorization header
=C2=A0- Client assertion=E2=80=99s =E2=80=9Ciss" field
=C2=A0- Request object=E2=80=99s =E2=80=9Cclient_id=E2=80=9D (and =E2= =80=9Ciss=E2=80=9D) field

If several of these are sent, they need to be consistent. And whatever= value comes out needs to be consistent with the client=E2=80=99s authentic= ation method.

But because JAR allows you to send in a request that is only a request= object, it also seems like you could pass in just the request object with = no other parameters, if I=E2=80=99m reading this right, which would imply t= hat you could be expected to glean the client ID from the request object itself without it being in either a = parameter or in another part of the request that=E2=80=99s easily accessed.= =C2=A0

So herein lies the problem. In order to properly process the request o= bject, you need to know which client you=E2=80=99re dealing with so you can= validate the signing algs, keys, and all that. For signed requests that=E2= =80=99s simple enough =E2=80=94 parse in one step, then authenticate the client, then validate the signatures. But for encryp= ted JWTs it=E2=80=99s less clear: some methods would use only the server=E2= =80=99s public key, but symmetric encryption algorithm/encoding pairs would= use the client secret as the pairwise secret for the encryption. Which means that we need to know which client sent the req= uest before the decryption happens.=C2=A0

Which in turn implies one of two things are true:

=C2=A0- You can=E2=80=99t do a request object when it=E2=80=99s encryp= ted using a symmetric algorithm
=C2=A0- You have to require the client ID from some other part of the = request, such as a form parameter, auth header, or client assertion; the cl= ient_id in the request object cannot be counted on as being sufficient

In our current draft implementation of PAR, I=E2=80=99m turning off su= pport for symmetric encryption in this one code path. If we can somehow cou= nt on being able to find a client_id every time, then we can refactor our i= mplementation to parse and handle all the client stuff :before: handling the request object itself. In other= words, if I always have to send something that identifies the client in ad= dition to the request object, then I can count on that.

Thoughts?

=E2=80=94 Justin

On Sep 30, 2019, at 11:21 AM, Brian Campbell <bcampbell=3D4= 0pingidentity.com@dmarc.ietf.org> wrote:



On Thu, Sep 26, 2019 at 9:30 AM Aaron= Parecki <aaron@p= arecki.com> wrote:
> Depending on client type and authentication method, the request might<= br> >=C2=A0 =C2=A0also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

What this is trying to convey is that because client authentication at= this Pushed Authorization Request Endpoint happens the same way as at the = token endpoint (and other endpoints called directly by the client) the clie= nt_id parameter will sometimes be present but not necessarily as some types of client auth use the client= _id parameter (none, client_secret_post, tls_client_auth, self_signed_tls_c= lient_auth) and some don't (client_secret_basic, client_secret_jwt, pri= vate_key_jwt).

Although the draft does later say "The AS MUST validate the reque= st the same way as at the authorization endpoint" which I think could = reasonably be interpreted as requiring client_id.=C2=A0 e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1 & https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_= id be a required parameter at the PAR endpoint.


<= 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 confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000051cfc70594890da0-- From nobody Thu Oct 10 02:15:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AF9120013 for ; Thu, 10 Oct 2019 02:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K-QDRMKCl1T for ; Thu, 10 Oct 2019 02:15:22 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::602]) (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 B59B6120090 for ; Thu, 10 Oct 2019 02:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUOFLiET+8Sf6mvYCBmyVehnrr7XXOaZvUUv9f/rBadwzQx0SqY6uv1PKlLO5q8b5XDQblNUYPY6V2BPN8kNFLnPKng7Gy2VAZ/6gRuxJHZVJASjHNFyJnGRlAfdt//XjQ3s8kjnkJCZ/Gbfz5U7CrXmemeQtvEUnjBjsLTvUdb90eta5rmjL7L7Ff64mqD5s8hg3Y9Rp4lU+ctjTeHLImi2cAYxrwcpdQSyxEJLALH/X+w5tk/yDDPmIMpL5FGjuLhjNNfrNPG6WlcjGHEMxLbvLGeFgVn5Pl4Kl4EslxFchrb9J0qD/uXbRLaz41FLF9RjVD67pchDW8uNT+5bOA== 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=MeDIwxL5w0tOdQunXEZsUAYn8ZAKaspztoaC7sqMOe8=; b=byngLTMS4qWNcxVIpWXCRbz+QQtkrxznKnX5R+q8WRMvEMeVnFPpF/b26beyU8oHpAQrvgy3zFCdNifCHENRDyuzT5LIHDoMRZivynwEkfpKjpf6ShCXXyA4RYe99hHv//emecoZeZDH74EVOCzWthF8qrc/ThD2AksJhdwbBx//HLSTADXG+r2PY5nKCREPdYahCeK4A0nuJafXBOkVt1OyZYpP/WjHvFz5RsOLDGyhYgpnvDbHJQCK3bmtKFluDofkwXRgPlX5lQJu7ymghBGuDfWvgGNC0OkfcA48XmSb6wADDeRRjmgQwgIRszG83Gn+DV/S6DLh0DomcPwjUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MeDIwxL5w0tOdQunXEZsUAYn8ZAKaspztoaC7sqMOe8=; b=Ksj6EVIZV8aDYq5SuE8A6lwhJrCCfDHiMYlceFJ15AguTuJsIFZXCQ2mxFEfKGK7x8GqIhaCAPdYcMkqY+8cy54Mp7xUoomIiZgWlblwa27hl7OCir2fMHzLJw3Qoh8PVwFhL7cSaMVgm7pwIVdNCbM6p5w6pxC5tfEFGuTgrfw= Received: from HE1P189CA0021.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::34) by AM5P189MB0449.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:23::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 10 Oct 2019 09:15:18 +0000 Received: from VE1EUR02FT032.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e06::207) by HE1P189CA0021.outlook.office365.com (2603:10a6:7:53::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Thu, 10 Oct 2019 09:15:18 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by VE1EUR02FT032.mail.protection.outlook.com (10.152.12.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2347.16 via Frontend Transport; Thu, 10 Oct 2019 09:15:17 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Thu, 10 Oct 2019 11:15:17 +0200 To: "oauth@ietf.org" From: Ludwig Seitz Message-ID: <08fd478d-233b-25e8-cb53-e2546596c329@ri.se> Date: Thu, 10 Oct 2019 11:15:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010408070707050608040208" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(346002)(396003)(376002)(199004)(189003)(476003)(33964004)(486006)(386003)(26005)(316002)(2351001)(44832011)(7736002)(2616005)(356004)(31696002)(106002)(6116002)(3846002)(336012)(16576012)(16526019)(305945005)(126002)(86362001)(186003)(5640700003)(568964002)(40036005)(22756006)(14444005)(5024004)(2906002)(36756003)(70586007)(478600001)(6306002)(8936002)(70206006)(5660300002)(8676002)(6916009)(1730700003)(966005)(2501003)(22746008)(81156014)(81166006)(58126008)(31686004)(16586007)(71190400001)(65806001)(65956001)(235185007)(5000100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0449; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e1a41fd-55cd-44fb-a235-08d74d625e1c X-MS-TrafficTypeDiagnostic: AM5P189MB0449: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 018632C080 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qcLa51URHnJnr9Ht5qs6MA9emHBWyxssokr7PmvpZRLpoX37FYYdDzl8Etdw8SaKP8XolGu0PEXWJF2a5a4zokndaijQJColwZJMycKRerip9ClOVCrig/OG99Mta9uOkAgC9ecl8HcYOgsWO267zcK26AA6JJcEIFxSqYMGNkjKikPtkNMFCr+vLqoEwXo/gdT6Mg19FlUek3dHyGAoiSCg6BFiNxGJIyhpvLDLepcMPDJYkTXb01kuu/Z3FdWBp8AZkaho/JYdqJL19wfNAXjG298YLdRYGWvVBPH2foZCyGDuJMYdyXgk8eOVmiJwmvVuLhrZvFJ2AxU6/b/J/+pL5nlJ310qrrh0l0C2u2ZWFP+04XI5DPldh5L8bNs5lqW/ijhmNwdH+rB/tgv3BE/nh3zcwxUVhRPuS+n7PZo= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2019 09:15:17.6432 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5e1a41fd-55cd-44fb-a235-08d74d625e1c X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P189MB0449 Archived-At: Subject: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Oct 2019 09:15:25 -0000 --------------ms010408070707050608040208 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello OAuth WG, while addressing some AD review comments on draft-ietf-ace-oauth-authz,=20 I've come across a question I think you can help me with: I was previously laboring under the misconception that the error codes=20 defined in https://tools.ietf.org/html/rfc6749#section-5.2 are registered here: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= extensions-error Which is apparently not the case. Is there another registry that one=20 should use (e.g. if one needs to add new error codes)? If there is none (which seems to be the case), should we create one? Regards, Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms010408070707050608040208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAxMDA5 MTUxNlowLwYJKoZIhvcNAQkEMSIEIEGfQbP1PAl70TTskWpGBuv2m1x51fmFxgktdkgXBqlI MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAiJkRKxQVjCLHR42Gs1Dz1/OGvIjbpRiMWSnNOGMsQ1j3 jYicCu4YLSoLYrjXJ27jvx3xQ/7eq+CS1JYzQKWr6MPY3ikT0vRx3yUrZt87HVd+9tgjsZFx W3sHB3l9ASbbCdL2MQXOYhDZvv0yycGxu4+1LPWodFoHccQVJT8yqnZNJnJxvG73R3/Obzbs fK/vETBn8pDYt5uXPCu8QDLHNVFaz9QaZaDD9UoxEpmZtSZp26ydVzL7NNaVShU+/NmVQMrU ZW2I7nsDOmWeTYjWDTqHCYwkWIf8OrJ5g39pMiYhRt4/dU/u42B1TrzvaUcbcq9Z0/zmt8dc XeYwFyBR2QAAAAAAAA== --------------ms010408070707050608040208-- From nobody Thu Oct 10 08:03:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE32120119 for ; Thu, 10 Oct 2019 08:02:58 -0700 (PDT) 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 zxeqGpiw922L for ; Thu, 10 Oct 2019 08:02:56 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CFE12001A for ; Thu, 10 Oct 2019 08:02:56 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x9AF2cQo015000; Thu, 10 Oct 2019 11:02:54 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 10 Oct 2019 11:02:25 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Oct 2019 11:02:29 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 10 Oct 2019 11:02:29 -0400 From: Justin Richer To: Ludwig Seitz CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2? Thread-Index: AQHVf0tExLJXeLc6JU+rXDVO16K0Z6dUO+4A Date: Thu, 10 Oct 2019 15:02:28 +0000 Message-ID: References: <08fd478d-233b-25e8-cb53-e2546596c329@ri.se> In-Reply-To: <08fd478d-233b-25e8-cb53-e2546596c329@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_FAAA32AB8EAB405E9AEE4E78A53018CDmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Oct 2019 15:02:59 -0000 --_000_FAAA32AB8EAB405E9AEE4E78A53018CDmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhleSBhcmUgaW4gdGhhdCByZWdpc3RyeSBhcyB0aGUg4oCcdG9rZW4gZW5kcG9pbnQgcmVzcG9u c2XigJ0gZXJyb3IgY29kZXMuIFJGQzg2MjggYWRkcyBuZXcgb25lcy4NCg0KSSB0aGluayB0aGF0 IDY3NDkgZmFpbGVkIHRvIHB1dCBpbiB0aGUgYmFzZSBvbmVzLg0KDQrigJQgSnVzdGluDQoNCk9u IE9jdCAxMCwgMjAxOSwgYXQgNToxNSBBTSwgTHVkd2lnIFNlaXR6IDxsdWR3aWcuc2VpdHpAcmku c2U8bWFpbHRvOmx1ZHdpZy5zZWl0ekByaS5zZT4+IHdyb3RlOg0KDQpIZWxsbyBPQXV0aCBXRywN Cg0Kd2hpbGUgYWRkcmVzc2luZyBzb21lIEFEIHJldmlldyBjb21tZW50cyBvbiBkcmFmdC1pZXRm LWFjZS1vYXV0aC1hdXRoeiwgSSd2ZSBjb21lIGFjcm9zcyBhIHF1ZXN0aW9uIEkgdGhpbmsgeW91 IGNhbiBoZWxwIG1lIHdpdGg6DQoNCkkgd2FzIHByZXZpb3VzbHkgbGFib3JpbmcgdW5kZXIgdGhl IG1pc2NvbmNlcHRpb24gdGhhdCB0aGUgZXJyb3IgY29kZXMgZGVmaW5lZCBpbg0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTUuMg0KDQphcmUgcmVnaXN0ZXJl ZCBoZXJlOg0KDQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0 ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjZXh0ZW5zaW9ucy1lcnJvcg0KDQpXaGljaCBpcyBh cHBhcmVudGx5IG5vdCB0aGUgY2FzZS4gSXMgdGhlcmUgYW5vdGhlciByZWdpc3RyeSB0aGF0IG9u ZSBzaG91bGQgdXNlIChlLmcuIGlmIG9uZSBuZWVkcyB0byBhZGQgbmV3IGVycm9yIGNvZGVzKT8N Cg0KSWYgdGhlcmUgaXMgbm9uZSAod2hpY2ggc2VlbXMgdG8gYmUgdGhlIGNhc2UpLCBzaG91bGQg d2UgY3JlYXRlIG9uZT8NCg0KUmVnYXJkcywNCg0KTHVkd2lnDQoNCi0tDQpMdWR3aWcgU2VpdHos IFBoRA0KU2VjdXJpdHkgTGFiLCBSSVNFDQpQaG9uZSArNDYoMCk3MC0zNDkgOTIgNTENCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0K --_000_FAAA32AB8EAB405E9AEE4E78A53018CDmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <832AB2296A1A6C4281DA8F6CAFB6C623@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoZXkgYXJlIGluIHRoYXQgcmVnaXN0cnkgYXMg dGhlIOKAnHRva2VuIGVuZHBvaW50IHJlc3BvbnNl4oCdIGVycm9yIGNvZGVzLiBSRkM4NjI4IGFk ZHMgbmV3IG9uZXMuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JIHRoaW5rIHRoYXQgNjc0OSBmYWlsZWQgdG8gcHV0IGluIHRoZSBiYXNl IG9uZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9j dCAxMCwgMjAxOSwgYXQgNToxNSBBTSwgTHVkd2lnIFNlaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86 bHVkd2lnLnNlaXR6QHJpLnNlIiBjbGFzcz0iIj5sdWR3aWcuc2VpdHpAcmkuc2U8L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IZWxsbyBPQXV0aCBXRyw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQp3aGlsZSBhZGRyZXNzaW5nIHNvbWUgQUQgcmV2aWV3IGNvbW1lbnRzIG9u IGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LCBJJ3ZlIGNvbWUgYWNyb3NzIGEgcXVlc3Rpb24g SSB0aGluayB5b3UgY2FuIGhlbHAgbWUgd2l0aDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJIHdhcyBwcmV2aW91c2x5IGxhYm9yaW5nIHVuZGVyIHRoZSBtaXNjb25jZXB0aW9uIHRoYXQg dGhlIGVycm9yIGNvZGVzIGRlZmluZWQgaW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTUuMiIg Y2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi01LjI8 L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KYXJlIHJlZ2lzdGVyZWQgaGVyZTo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjZXh0ZW5zaW9ucy1lcnJv cjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoaWNoIGlzIGFwcGFyZW50bHkgbm90IHRo ZSBjYXNlLiBJcyB0aGVyZSBhbm90aGVyIHJlZ2lzdHJ5IHRoYXQgb25lIHNob3VsZCB1c2UgKGUu Zy4gaWYgb25lIG5lZWRzIHRvIGFkZCBuZXcgZXJyb3IgY29kZXMpPzxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklmIHRoZXJlIGlzIG5vbmUgKHdoaWNoIHNlZW1zIHRvIGJlIHRoZSBjYXNl KSwgc2hvdWxkIHdlIGNyZWF0ZSBvbmU/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVn YXJkcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpMdWR3aWc8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQpMdWR3aWcgU2VpdHosIFBoRDxiciBjbGFz cz0iIj4NClNlY3VyaXR5IExhYiwgUklTRTxiciBjbGFzcz0iIj4NClBob25lICYjNDM7NDYoMCk3 MC0zNDkgOTIgNTE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCk9BdXRoQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_FAAA32AB8EAB405E9AEE4E78A53018CDmitedu_-- From nobody Thu Oct 10 10:00:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A812012006E for ; Thu, 10 Oct 2019 10:00:04 -0700 (PDT) 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 QsAFQ7AeiC39 for ; Thu, 10 Oct 2019 10:00:01 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B0D1200CC for ; Thu, 10 Oct 2019 10:00:01 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x9AGxp4L001593; Thu, 10 Oct 2019 12:59:57 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 10 Oct 2019 12:59:27 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Oct 2019 12:59:31 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 10 Oct 2019 12:59:31 -0400 From: Justin Richer To: Filip Skokan CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVfwfNa3xPxCQlOEmJVjaFyUAiTKdTt50AgACliwA= Date: Thu, 10 Oct 2019 16:59:30 +0000 Message-ID: References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_CDEA2590FD944D849252D22610461F35mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 17:00:05 -0000 --_000_CDEA2590FD944D849252D22610461F35mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuIE15IGNvbmNlcm4gaXMgdGhhdCBpbnRlcnByZXRhdGlv biBvZiB0aGUgcmVxdWlyZW1lbnQgdG8g4oCcYXV0aGVudGljYXRlIHRoZSBjbGllbnTigJ0gY291 bGQgYmUgaW50ZXJwcmV0ZWQgaW4gdGhlIEZBUEkgZHJhZnTigJlzIHNlbnNlLCB3aGljaCBpcyB0 byBzYXkgdmFsaWRhdGluZyB0aGUgc2lnbmF0dXJlIG9uIHRoZSByZXF1ZXN0IG9iamVjdCBhbmQg bm90IGRvaW5nIGFueXRoaW5nIGVsc2UuDQoNClRoZSBwcm9ibGVtIGNvbWVzIGZyb20gdGhlIGZh Y3QgdGhhdCB3ZeKAmXJlIGVmZmVjdGl2ZWx5IHNtYXNoaW5nIHRvZ2V0aGVyIHRoZSBjb25kaXRp b25zIGFuZCBhc3N1bXB0aW9ucyBvZiBib3RoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFu ZCB0b2tlbiBlbmRwb2ludCBpbnRvIGEgbmV3IGVuZHBvaW50LiBJdOKAmXMgZ29pbmcgdG8gYmUg bWVzc3ksIGFuZCB3ZSBuZWVkIHRvIGJlIHZlcnkgcGVkYW50aWMgYWJvdXQgd2hhdCB3ZSBtZWFu IGlmIHRoaXMgZHJhZnQgaXMgZ29pbmcgdG8gYmUgaW1wbGVtZW50YWJsZS4NCg0K4oCUIEp1c3Rp bg0KDQpPbiBPY3QgMTAsIDIwMTksIGF0IDM6MDcgQU0sIEZpbGlwIFNrb2thbiA8cGFudmEuaXBA Z21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBJZiBzZXZl cmFsIG9mIHRoZXNlIGFyZSBzZW50LCB0aGV5IG5lZWQgdG8gYmUgY29uc2lzdGVudC4NCg0KR2l2 ZW4gdGhhdCBjbGllbnQgYXV0aGVudGljYXRpb24gcHJlY2VkZXMgcHJvY2Vzc2luZyB0aGUgcmVz dCBvZiB0aGUgcmVxdWVzdCwgaWYgc2V2ZXJhbCBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9k cyBhcmUgcHJvdmlkZWQgKGhlYWRlciArIHNlY3JldCBvciBzZWNyZXQgKyBhc3NlcnRpb24sIGV0 YykgeW91IGdlbmVyYWxseSByZWplY3QgdGhlIHJlcXVlc3QsIGRvbid0IHlvdT8NCg0KVGhlbiB0 aGVyZSdzIHRoZSByZXF1aXJlbWVudCBmb3IgdGhlIGNsaWVudF9pZCBnaXZlbiBieSBhdXRoZW50 aWNhdGlvbiBtZXRob2QgKG5vbmUgaXMgc3RpbGwgYW4gImF1dGhlbnRpY2F0aW9uIiBtZXRob2Qg LSBjbGllbnRfaWQgaW4gdGhlIGJvZHkpIHRvIG1hdGNoIHRoZSBgaXNzYCBhbmQgYGNsaWVudF9p ZGAgaW4gdGhlIHJlcXVlc3Qgb2JqZWN0LiBUaGF0J3MgYWxyZWFkeSByZXF1aXJlZCBieSBKQVIg cHJvY2Vzc2luZyBydWxlcyBhbmQgYWxzbyBQQVIuDQoNCj4gQnV0IGJlY2F1c2UgSkFSIGFsbG93 cyB5b3UgdG8gc2VuZCBpbiBhIHJlcXVlc3QgdGhhdCBpcyBvbmx5IGEgcmVxdWVzdCBvYmplY3Qs IGl0IGFsc28gc2VlbXMgbGlrZSB5b3UgY291bGQgcGFzcyBpbiBqdXN0IHRoZSByZXF1ZXN0IG9i amVjdCB3aXRoIG5vIG90aGVyIHBhcmFtZXRlcnMsIGlmIEnigJltIHJlYWRpbmcgdGhpcyByaWdo dCwgd2hpY2ggd291bGQgaW1wbHkgdGhhdCB5b3UgY291bGQgYmUgZXhwZWN0ZWQgdG8gZ2xlYW4g dGhlIGNsaWVudCBJRCBmcm9tIHRoZSByZXF1ZXN0IG9iamVjdCBpdHNlbGYgd2l0aG91dCBpdCBi ZWluZyBpbiBlaXRoZXIgYSBwYXJhbWV0ZXIgb3IgaW4gYW5vdGhlciBwYXJ0IG9mIHRoZSByZXF1 ZXN0IHRoYXTigJlzIGVhc2lseSBhY2Nlc3NlZC4NCg0KSXQgd2FzIG9ubHkgaW4gdGhlIG9yaWdp bmFsIEZBUEkgcmV2aXNpb24gb2YgUEFSIHRoYXQgYWxsb3dlZCB0aGUgcmVxdWVzdCBvYmplY3Qn cyBzaWduYXR1cmUgdG8gc3Vic3RpdHV0ZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGluIHRoZSBp bmRpdmlkdWFsIGRyYWZ0IHB1Ymxpc2hlZCB0byBJRVRGIHRoYXQncyBub3QgdGhlIGNhc2UgYW55 bW9yZSAtIGhlbmNlIGlmICJvbmx5IiBhIHJlcXVlc3Qgb2JqZWN0IGlzIHBhc3NlZCAtIHdpdGgg bm8gY2xpZW50IGF1dGhlbnRpY2F0aW9uIChoZWFkZXIsIGNsaWVudF9pZCBpbiBib2R5LCBtdGxz KSB5b3UgZmFpbCB0aGUgcmVxdWVzdC4NCg0KQXMgZmFyIGFzIHJlcXVpcmluZyBjbGllbnRfaWQs IGhlcmUncyB3aGF0IG15IGltcGxlbWVudGF0aW9uIGRvZXMNCg0KPiBXaGVuIHByb3ZpZGluZyBm b3JtLWVuY29kZWQgcGFyYW1ldGVycyAtIGNsaWVudF9pZCBtdXN0IGJlIHByZXNlbnQgaW4gdGhl IGZvcm0uDQo+IFdoZW4gcHJvdmlkaW5nIHNpZ25lZC9lbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3Qg LSBjbGllbnRfaWQgbXVzdCBiZSBwcmVzZW50IGluIHRoZSByZXF1ZXN0IG9iamVjdC4NCg0KSSB3 b3VsZG4ndCBtaW5kIGFsd2F5cyByZXF1aXJpbmcgY2xpZW50X2lkLCBhbmQgaSdtIG5vdCB3b3Jy aWVkIGFib3V0IGl0IG5vdCBtYXRjaGluZyBlLmcuIHRoZSBhdXRob3JpemF0aW9uIGhlYWRlciBi ZWNhdXNlIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWlkZGxld2FyZSBpbiBwbGFjZSBhbHJl YWR5IHRha2VzIGNhcmUgb2YgdGhhdC4NCg0KUyBwb3pkcmF2ZW0sDQpGaWxpcCBTa29rYW4NCg0K DQpPbiBUaHUsIDEwIE9jdCAyMDE5IGF0IDAzOjEzLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KU28gaW4gZG9pbmcgYW4gaW1w bGVtZW50YXRpb24gb2YgdGhpcywgSSByYW4gaW50byB0aGlzIHByb2JsZW0gYXMgd2VsbC4gU3Bl Y2lmaWNhbGx5LCB3ZSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50IHdl4oCZcmUgZGVhbGluZyB3 aXRoIHRvIGZ1bGx5IHZhbGlkYXRlIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3QgYXMgd2Vs bCBhcyBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlvbi4gQ3VycmVudGx5LCB0aGluZ3MgYXJlIGEg bGl0dGxlIHVuZGVyc3BlY2lmaWVkLCBhbmQgcGFydCBvZiB0aGF0IGNvbWVzIGZyb20gdGhlIGhp c3Rvcnkgb2YgdGhpcyBkb2N1bWVudDogaW4gdGhlIHByZXZpb3VzIEZBUEkgc3BlYywgdGhlIChy ZXF1aXJlZCkgc2lnbmF0dXJlIG9mIHRoZSByZXF1ZXN0IG9iamVjdCBhY3RlZCBhcyBkZS1mYWN0 byBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIGNsaWVudC4gSW4gUEFSLCB3ZSBub3Qgb25seSBjYW7i gJl0IHJlbHkgb24gdGhlIHJlcXVlc3QgaXRzZWxmIGJlaW5nIHNpZ25lZCwgd2UgYWxzbyByZXF1 aXJlIGhhbmRsaW5nIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBpdHMgbWFueSBmb3Jtcy4g VGhhdCBtZWFucyB0aGUgY2xpZW50IElEIGNvdWxkIHNob3cgdXAgaW4gYW55IGNvbWJpbmF0aW9u IG9mOg0KDQogLSBGb3JtIHBhcmFtZXRlcg0KIC0gQXV0aG9yaXphdGlvbiBoZWFkZXINCiAtIENs aWVudCBhc3NlcnRpb27igJlzIOKAnGlzcyIgZmllbGQNCiAtIFJlcXVlc3Qgb2JqZWN04oCZcyDi gJxjbGllbnRfaWTigJ0gKGFuZCDigJxpc3PigJ0pIGZpZWxkDQoNCklmIHNldmVyYWwgb2YgdGhl c2UgYXJlIHNlbnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50LiBBbmQgd2hhdGV2ZXIgdmFs dWUgY29tZXMgb3V0IG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2xpZW504oCZcyBh dXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkJ1dCBiZWNhdXNlIEpBUiBhbGxvd3MgeW91IHRvIHNl bmQgaW4gYSByZXF1ZXN0IHRoYXQgaXMgb25seSBhIHJlcXVlc3Qgb2JqZWN0LCBpdCBhbHNvIHNl ZW1zIGxpa2UgeW91IGNvdWxkIHBhc3MgaW4ganVzdCB0aGUgcmVxdWVzdCBvYmplY3Qgd2l0aCBu byBvdGhlciBwYXJhbWV0ZXJzLCBpZiBJ4oCZbSByZWFkaW5nIHRoaXMgcmlnaHQsIHdoaWNoIHdv dWxkIGltcGx5IHRoYXQgeW91IGNvdWxkIGJlIGV4cGVjdGVkIHRvIGdsZWFuIHRoZSBjbGllbnQg SUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhvdXQgaXQgYmVpbmcgaW4gZWl0 aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0aGUgcmVxdWVzdCB0aGF04oCZ cyBlYXNpbHkgYWNjZXNzZWQuDQoNClNvIGhlcmVpbiBsaWVzIHRoZSBwcm9ibGVtLiBJbiBvcmRl ciB0byBwcm9wZXJseSBwcm9jZXNzIHRoZSByZXF1ZXN0IG9iamVjdCwgeW91IG5lZWQgdG8ga25v dyB3aGljaCBjbGllbnQgeW914oCZcmUgZGVhbGluZyB3aXRoIHNvIHlvdSBjYW4gdmFsaWRhdGUg dGhlIHNpZ25pbmcgYWxncywga2V5cywgYW5kIGFsbCB0aGF0LiBGb3Igc2lnbmVkIHJlcXVlc3Rz IHRoYXTigJlzIHNpbXBsZSBlbm91Z2gg4oCUIHBhcnNlIGluIG9uZSBzdGVwLCB0aGVuIGF1dGhl bnRpY2F0ZSB0aGUgY2xpZW50LCB0aGVuIHZhbGlkYXRlIHRoZSBzaWduYXR1cmVzLiBCdXQgZm9y IGVuY3J5cHRlZCBKV1RzIGl04oCZcyBsZXNzIGNsZWFyOiBzb21lIG1ldGhvZHMgd291bGQgdXNl IG9ubHkgdGhlIHNlcnZlcuKAmXMgcHVibGljIGtleSwgYnV0IHN5bW1ldHJpYyBlbmNyeXB0aW9u IGFsZ29yaXRobS9lbmNvZGluZyBwYWlycyB3b3VsZCB1c2UgdGhlIGNsaWVudCBzZWNyZXQgYXMg dGhlIHBhaXJ3aXNlIHNlY3JldCBmb3IgdGhlIGVuY3J5cHRpb24uIFdoaWNoIG1lYW5zIHRoYXQg d2UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCBzZW50IHRoZSByZXF1ZXN0IGJlZm9yZSB0aGUg ZGVjcnlwdGlvbiBoYXBwZW5zLg0KDQpXaGljaCBpbiB0dXJuIGltcGxpZXMgb25lIG9mIHR3byB0 aGluZ3MgYXJlIHRydWU6DQoNCiAtIFlvdSBjYW7igJl0IGRvIGEgcmVxdWVzdCBvYmplY3Qgd2hl biBpdOKAmXMgZW5jcnlwdGVkIHVzaW5nIGEgc3ltbWV0cmljIGFsZ29yaXRobQ0KIC0gWW91IGhh dmUgdG8gcmVxdWlyZSB0aGUgY2xpZW50IElEIGZyb20gc29tZSBvdGhlciBwYXJ0IG9mIHRoZSBy ZXF1ZXN0LCBzdWNoIGFzIGEgZm9ybSBwYXJhbWV0ZXIsIGF1dGggaGVhZGVyLCBvciBjbGllbnQg YXNzZXJ0aW9uOyB0aGUgY2xpZW50X2lkIGluIHRoZSByZXF1ZXN0IG9iamVjdCBjYW5ub3QgYmUg Y291bnRlZCBvbiBhcyBiZWluZyBzdWZmaWNpZW50DQoNCkluIG91ciBjdXJyZW50IGRyYWZ0IGlt cGxlbWVudGF0aW9uIG9mIFBBUiwgSeKAmW0gdHVybmluZyBvZmYgc3VwcG9ydCBmb3Igc3ltbWV0 cmljIGVuY3J5cHRpb24gaW4gdGhpcyBvbmUgY29kZSBwYXRoLiBJZiB3ZSBjYW4gc29tZWhvdyBj b3VudCBvbiBiZWluZyBhYmxlIHRvIGZpbmQgYSBjbGllbnRfaWQgZXZlcnkgdGltZSwgdGhlbiB3 ZSBjYW4gcmVmYWN0b3Igb3VyIGltcGxlbWVudGF0aW9uIHRvIHBhcnNlIGFuZCBoYW5kbGUgYWxs IHRoZSBjbGllbnQgc3R1ZmYgOmJlZm9yZTogaGFuZGxpbmcgdGhlIHJlcXVlc3Qgb2JqZWN0IGl0 c2VsZi4gSW4gb3RoZXIgd29yZHMsIGlmIEkgYWx3YXlzIGhhdmUgdG8gc2VuZCBzb21ldGhpbmcg dGhhdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgaW4gYWRkaXRpb24gdG8gdGhlIHJlcXVlc3Qgb2Jq ZWN0LCB0aGVuIEkgY2FuIGNvdW50IG9uIHRoYXQuDQoNClRob3VnaHRzPw0KDQrigJQgSnVzdGlu DQoNCk9uIFNlcCAzMCwgMjAxOSwgYXQgMTE6MjEgQU0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpiY2FtcGJlbGw9NDBw aW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCg0KDQpPbiBUaHUsIFNl cCAyNiwgMjAxOSBhdCA5OjMwIEFNIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1h aWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KPiBEZXBlbmRpbmcgb24gY2xpZW50IHR5 cGUgYW5kIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCwgdGhlIHJlcXVlc3QgbWlnaHQNCj4gICBhbHNv IGluY2x1ZGUgdGhlICJjbGllbnRfaWQiIHBhcmFtZXRlci4NCg0KSSBhc3N1bWUgdGhpcyBpcyBo aW50aW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHMNCnNlbmRpbmcg b25seSB0aGUgImNsaWVudF9pZCIgcGFyYW1ldGVyIGFuZCBjb25maWRlbnRpYWwgY2xpZW50cw0K c2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRpb24gaGVhZGVyIHdoaWNoIGlu Y2x1ZGVzIGJvdGgNCnRoZSBjbGllbnQgSUQgYW5kIHNlY3JldD8gSXQgd291bGQgcHJvYmFibHkg YmUgaGVscGZ1bCB0byBjYWxsIG91dA0KdGhlc2UgdHdvIGNvbW1vbiBleGFtcGxlcyBpZiBJIGFt IHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksDQpvdGhlcndpc2UgaXQgc2VlbXMgcHJldHR5 IHZhZ3VlLg0KDQpXaGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGNvbnZleSBpcyB0aGF0IGJlY2F1c2Ug Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGF0IHRoaXMgUHVzaGVkIEF1dGhvcml6YXRpb24gUmVxdWVz dCBFbmRwb2ludCBoYXBwZW5zIHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgdG9rZW4gZW5kcG9pbnQg KGFuZCBvdGhlciBlbmRwb2ludHMgY2FsbGVkIGRpcmVjdGx5IGJ5IHRoZSBjbGllbnQpIHRoZSBj bGllbnRfaWQgcGFyYW1ldGVyIHdpbGwgc29tZXRpbWVzIGJlIHByZXNlbnQgYnV0IG5vdCBuZWNl c3NhcmlseSBhcyBzb21lIHR5cGVzIG9mIGNsaWVudCBhdXRoIHVzZSB0aGUgY2xpZW50X2lkIHBh cmFtZXRlciAobm9uZSwgY2xpZW50X3NlY3JldF9wb3N0LCB0bHNfY2xpZW50X2F1dGgsIHNlbGZf c2lnbmVkX3Rsc19jbGllbnRfYXV0aCkgYW5kIHNvbWUgZG9uJ3QgKGNsaWVudF9zZWNyZXRfYmFz aWMsIGNsaWVudF9zZWNyZXRfand0LCBwcml2YXRlX2tleV9qd3QpLg0KDQpBbHRob3VnaCB0aGUg ZHJhZnQgZG9lcyBsYXRlciBzYXkgIlRoZSBBUyBNVVNUIHZhbGlkYXRlIHRoZSByZXF1ZXN0IHRo ZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCIgd2hpY2ggSSB0aGlu ayBjb3VsZCByZWFzb25hYmx5IGJlIGludGVycHJldGVkIGFzIHJlcXVpcmluZyBjbGllbnRfaWQu ICBlLmcuLCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlvbi00Li4x LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3NlY3Rpb24tNC4xLjE+ICYg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3NlY3Rpb24tNC4yLjENCg0KU28g cGVyaGFwcyB0aGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gc2hvdWxkIGJlIHJlbW92ZWQgYW5kIGhh dmUgY2xpZW50X2lkIGJlIGEgcmVxdWlyZWQgcGFyYW1ldGVyIGF0IHRoZSBQQVIgZW5kcG9pbnQu DQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0K --_000_CDEA2590FD944D849252D22610461F35mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <56A9AFC1A4F43B4084811C3118B6C27B@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiBNeSBj b25jZXJuIGlzIHRoYXQgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHJlcXVpcmVtZW50IHRvIOKAnGF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW504oCdIGNvdWxkIGJlIGludGVycHJldGVkIGluIHRoZSBGQVBJ IGRyYWZ04oCZcyBzZW5zZSwgd2hpY2ggaXMgdG8gc2F5IHZhbGlkYXRpbmcgdGhlIHNpZ25hdHVy ZSBvbiB0aGUgcmVxdWVzdCBvYmplY3QgYW5kIG5vdCBkb2luZyBhbnl0aGluZyBlbHNlLiZuYnNw Ow0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhl IHByb2JsZW0gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHdl4oCZcmUgZWZmZWN0aXZlbHkgc21h c2hpbmcgdG9nZXRoZXIgdGhlIGNvbmRpdGlvbnMgYW5kIGFzc3VtcHRpb25zIG9mIGJvdGggdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIHRva2VuIGVuZHBvaW50IGludG8gYSBuZXcgZW5k cG9pbnQuIEl04oCZcyBnb2luZyB0byBiZSBtZXNzeSwgYW5kIHdlIG5lZWQgdG8gYmUgdmVyeSBw ZWRhbnRpYyBhYm91dCB3aGF0DQogd2UgbWVhbiBpZiB0aGlzIGRyYWZ0IGlzIGdvaW5nIHRvIGJl IGltcGxlbWVudGFibGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIE9jdCAxMCwgMjAxOSwgYXQgMzowNyBBTSwgRmlsaXAgU2tva2FuICZsdDs8 YSBocmVmPSJtYWlsdG86cGFudmEuaXBAZ21haWwuY29tIiBjbGFzcz0iIj5wYW52YS5pcEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPiZndDsmbmJzcDs8c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj5JZiBzZXZlcmFsIG9m IHRoZXNlIGFyZSBzZW50LCB0aGV5IG5lZWQgdG8gYmUgY29uc2lzdGVudC48L3NwYW4+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+R2l2ZW4g dGhhdCBjbGllbnQgYXV0aGVudGljYXRpb24mbmJzcDs8L3NwYW4+cHJlY2VkZXM8c3BhbiBzdHls ZT0iIiBjbGFzcz0iIj4mbmJzcDtwcm9jZXNzaW5nIHRoZSByZXN0IG9mIHRoZSByZXF1ZXN0LCBp ZiBzZXZlcmFsIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGFyZSBwcm92aWRlZCAoaGVh ZGVyJm5ic3A7JiM0Mzsgc2VjcmV0IG9yIHNlY3JldCZuYnNwOyYjNDM7IGFzc2VydGlvbiwgZXRj KSZuYnNwO3lvdSBnZW5lcmFsbHkNCiByZWplY3QgdGhlIHJlcXVlc3QsIGRvbid0IHlvdT88L3Nw YW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9 IiI+VGhlbiB0aGVyZSdzIHRoZSByZXF1aXJlbWVudCBmb3IgdGhlIGNsaWVudF9pZCBnaXZlbiBi eSBhdXRoZW50aWNhdGlvbiBtZXRob2QgKG5vbmUgaXMgc3RpbGwgYW4gJnF1b3Q7YXV0aGVudGlj YXRpb24mcXVvdDsgbWV0aG9kIC0gY2xpZW50X2lkIGluIHRoZSBib2R5KSB0byBtYXRjaCB0aGUg YGlzc2AgYW5kIGBjbGllbnRfaWRgIGluIHRoZSByZXF1ZXN0IG9iamVjdC4gVGhhdCdzIGFscmVh ZHkgcmVxdWlyZWQNCiBieSBKQVIgcHJvY2Vzc2luZyBydWxlcyBhbmQgYWxzbyBQQVIuPC9zcGFu PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIi PiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+QnV0IGJlY2F1c2UgSkFS IGFsbG93cyB5b3UgdG8gc2VuZCBpbiBhIHJlcXVlc3QgdGhhdCBpcyBvbmx5IGEgcmVxdWVzdCBv YmplY3QsIGl0IGFsc28gc2VlbXMgbGlrZSB5b3UgY291bGQgcGFzcyBpbiBqdXN0IHRoZSByZXF1 ZXN0IG9iamVjdCB3aXRoIG5vIG90aGVyIHBhcmFtZXRlcnMsIGlmIEnigJltIHJlYWRpbmcgdGhp cw0KIHJpZ2h0LCB3aGljaCB3b3VsZCBpbXBseSB0aGF0IHlvdSBjb3VsZCBiZSBleHBlY3RlZCB0 byBnbGVhbiB0aGUgY2xpZW50IElEIGZyb20gdGhlIHJlcXVlc3Qgb2JqZWN0IGl0c2VsZiB3aXRo b3V0IGl0IGJlaW5nIGluIGVpdGhlciBhIHBhcmFtZXRlciBvciBpbiBhbm90aGVyIHBhcnQgb2Yg dGhlIHJlcXVlc3QgdGhhdOKAmXMgZWFzaWx5IGFjY2Vzc2VkLiZuYnNwOzwvc3Bhbj48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9z cGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj5JdCB3YXMg b25seSBpbiB0aGUgb3JpZ2luYWwgRkFQSSByZXZpc2lvbiBvZiBQQVIgdGhhdCBhbGxvd2VkIHRo ZSByZXF1ZXN0IG9iamVjdCdzIHNpZ25hdHVyZSB0byBzdWJzdGl0dXRlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiwgaW4gdGhlIGluZGl2aWR1YWwgZHJhZnQgcHVibGlzaGVkIHRvIElFVEYgdGhhdCdz IG5vdCB0aGUgY2FzZSBhbnltb3JlIC0gaGVuY2UgaWYgJnF1b3Q7b25seSZxdW90OyBhDQogcmVx dWVzdCBvYmplY3QgaXMgcGFzc2VkIC0gd2l0aCBubyBjbGllbnQgYXV0aGVudGljYXRpb24gKGhl YWRlciwgY2xpZW50X2lkIGluIGJvZHksIG10bHMpIHlvdSBmYWlsIHRoZSByZXF1ZXN0Ljwvc3Bh bj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0i Ij5BcyBmYXIgYXMgcmVxdWlyaW5nIGNsaWVudF9pZCwgaGVyZSdzIHdoYXQgbXkgaW1wbGVtZW50 YXRpb24gZG9lczwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIj4mZ3Q7IFdoZW4gcHJvdmlkaW5nIGZvcm0tZW5jb2RlZCBwYXJhbWV0ZXJzIC0gY2xp ZW50X2lkIG11c3QgYmUgcHJlc2VudCBpbiB0aGUgZm9ybS48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiPiZndDsgV2hlbiBwcm92aWRpbmcgc2lnbmVkL2VuY3J5cHRl ZCByZXF1ZXN0IG9iamVjdCAtIGNsaWVudF9pZCBtdXN0IGJlIHByZXNlbnQgaW4gdGhlIHJlcXVl c3Qgb2JqZWN0LjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj5J IHdvdWxkbid0IG1pbmQgYWx3YXlzIHJlcXVpcmluZyBjbGllbnRfaWQsIGFuZCBpJ20gbm90IHdv cnJpZWQgYWJvdXQgaXQgbm90IG1hdGNoaW5nIGUuZy4gdGhlIGF1dGhvcml6YXRpb24gaGVhZGVy IGJlY2F1c2UgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtaWRkbGV3YXJlIGluIHBsYWNlIGFs cmVhZHkgdGFrZXMgY2FyZSBvZiB0aGF0LjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+UyBwb3pk cmF2ZW0sPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RmlsaXAgU2tva2FuPC9iPjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUs IDEwIE9jdCAyMDE5IGF0IDAzOjEzLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86 anJpY2hlckBtaXQuZWR1IiBjbGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6 IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj5TbyBpbiBkb2luZyBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0 aGlzLCBJIHJhbiBpbnRvIHRoaXMgcHJvYmxlbSBhcyB3ZWxsLiBTcGVjaWZpY2FsbHksIHdlIG5l ZWQgdG8ga25vdyB3aGljaCBjbGllbnQgd2XigJlyZSBkZWFsaW5nIHdpdGggdG8gZnVsbHkgdmFs aWRhdGUgdGhlIGVuY3J5cHRlZCByZXF1ZXN0IG9iamVjdCBhcyB3ZWxsIGFzIHBlcmZvcm0gdGhl IGF1dGhlbnRpY2F0aW9uLg0KIEN1cnJlbnRseSwgdGhpbmdzIGFyZSBhIGxpdHRsZSB1bmRlcnNw ZWNpZmllZCwgYW5kIHBhcnQgb2YgdGhhdCBjb21lcyBmcm9tIHRoZSBoaXN0b3J5IG9mIHRoaXMg ZG9jdW1lbnQ6IGluIHRoZSBwcmV2aW91cyBGQVBJIHNwZWMsIHRoZSAocmVxdWlyZWQpIHNpZ25h dHVyZSBvZiB0aGUgcmVxdWVzdCBvYmplY3QgYWN0ZWQgYXMgZGUtZmFjdG8gYXV0aGVudGljYXRp b24gZm9yIHRoZSBjbGllbnQuIEluIFBBUiwgd2Ugbm90IG9ubHkgY2Fu4oCZdCByZWx5DQogb24g dGhlIHJlcXVlc3QgaXRzZWxmIGJlaW5nIHNpZ25lZCwgd2UgYWxzbyByZXF1aXJlIGhhbmRsaW5n IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBpdHMgbWFueSBmb3Jtcy4gVGhhdCBtZWFucyB0 aGUgY2xpZW50IElEIGNvdWxkIHNob3cgdXAgaW4gYW55IGNvbWJpbmF0aW9uIG9mOg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7LSBGb3Jt IHBhcmFtZXRlcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDstIEF1dGhvcml6YXRpb24gaGVh ZGVyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOy0gQ2xpZW50IGFzc2VydGlvbuKAmXMg4oCc aXNzJnF1b3Q7IGZpZWxkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOy0gUmVxdWVzdCBvYmpl Y3TigJlzIOKAnGNsaWVudF9pZOKAnSAoYW5kIOKAnGlzc+KAnSkgZmllbGQ8YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiBz ZXZlcmFsIG9mIHRoZXNlIGFyZSBzZW50LCB0aGV5IG5lZWQgdG8gYmUgY29uc2lzdGVudC4gQW5k IHdoYXRldmVyIHZhbHVlIGNvbWVzIG91dCBuZWVkcyB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhl IGNsaWVudOKAmXMgYXV0aGVudGljYXRpb24gbWV0aG9kLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnV0IGJlY2F1c2UgSkFSIGFsbG93 cyB5b3UgdG8gc2VuZCBpbiBhIHJlcXVlc3QgdGhhdCBpcyBvbmx5IGEgcmVxdWVzdCBvYmplY3Qs IGl0IGFsc28gc2VlbXMgbGlrZSB5b3UgY291bGQgcGFzcyBpbiBqdXN0IHRoZSByZXF1ZXN0IG9i amVjdCB3aXRoIG5vIG90aGVyIHBhcmFtZXRlcnMsIGlmIEnigJltIHJlYWRpbmcgdGhpcyByaWdo dCwgd2hpY2ggd291bGQgaW1wbHkgdGhhdCB5b3UgY291bGQgYmUgZXhwZWN0ZWQgdG8gZ2xlYW4N CiB0aGUgY2xpZW50IElEIGZyb20gdGhlIHJlcXVlc3Qgb2JqZWN0IGl0c2VsZiB3aXRob3V0IGl0 IGJlaW5nIGluIGVpdGhlciBhIHBhcmFtZXRlciBvciBpbiBhbm90aGVyIHBhcnQgb2YgdGhlIHJl cXVlc3QgdGhhdOKAmXMgZWFzaWx5IGFjY2Vzc2VkLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28gaGVyZWluIGxpZXMgdGhl IHByb2JsZW0uIEluIG9yZGVyIHRvIHByb3Blcmx5IHByb2Nlc3MgdGhlIHJlcXVlc3Qgb2JqZWN0 LCB5b3UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCB5b3XigJlyZSBkZWFsaW5nIHdpdGggc28g eW91IGNhbiB2YWxpZGF0ZSB0aGUgc2lnbmluZyBhbGdzLCBrZXlzLCBhbmQgYWxsIHRoYXQuIEZv ciBzaWduZWQgcmVxdWVzdHMgdGhhdOKAmXMgc2ltcGxlIGVub3VnaCDigJQgcGFyc2UgaW4gb25l IHN0ZXAsDQogdGhlbiBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgdGhlbiB2YWxpZGF0ZSB0aGUg c2lnbmF0dXJlcy4gQnV0IGZvciBlbmNyeXB0ZWQgSldUcyBpdOKAmXMgbGVzcyBjbGVhcjogc29t ZSBtZXRob2RzIHdvdWxkIHVzZSBvbmx5IHRoZSBzZXJ2ZXLigJlzIHB1YmxpYyBrZXksIGJ1dCBz eW1tZXRyaWMgZW5jcnlwdGlvbiBhbGdvcml0aG0vZW5jb2RpbmcgcGFpcnMgd291bGQgdXNlIHRo ZSBjbGllbnQgc2VjcmV0IGFzIHRoZSBwYWlyd2lzZSBzZWNyZXQgZm9yDQogdGhlIGVuY3J5cHRp b24uIFdoaWNoIG1lYW5zIHRoYXQgd2UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCBzZW50IHRo ZSByZXF1ZXN0IGJlZm9yZSB0aGUgZGVjcnlwdGlvbiBoYXBwZW5zLiZuYnNwOzxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5XaGljaCBpbiB0dXJuIGltcGxpZXMgb25lIG9mIHR3byB0aGluZ3MgYXJl IHRydWU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDstIFlvdSBjYW7igJl0IGRvIGEgcmVxdWVzdCBvYmplY3Qgd2hlbiBpdOKA mXMgZW5jcnlwdGVkIHVzaW5nIGEgc3ltbWV0cmljIGFsZ29yaXRobTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDstIFlvdSBoYXZlIHRvIHJlcXVpcmUgdGhlIGNsaWVudCBJRCBmcm9tIHNvbWUg b3RoZXIgcGFydCBvZiB0aGUgcmVxdWVzdCwgc3VjaCBhcyBhIGZvcm0gcGFyYW1ldGVyLCBhdXRo IGhlYWRlciwgb3IgY2xpZW50IGFzc2VydGlvbjsgdGhlIGNsaWVudF9pZCBpbiB0aGUgcmVxdWVz dCBvYmplY3QgY2Fubm90IGJlIGNvdW50ZWQgb24gYXMgYmVpbmcgc3VmZmljaWVudDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gb3Vy IGN1cnJlbnQgZHJhZnQgaW1wbGVtZW50YXRpb24gb2YgUEFSLCBJ4oCZbSB0dXJuaW5nIG9mZiBz dXBwb3J0IGZvciBzeW1tZXRyaWMgZW5jcnlwdGlvbiBpbiB0aGlzIG9uZSBjb2RlIHBhdGguIElm IHdlIGNhbiBzb21laG93IGNvdW50IG9uIGJlaW5nIGFibGUgdG8gZmluZCBhIGNsaWVudF9pZCBl dmVyeSB0aW1lLCB0aGVuIHdlIGNhbiByZWZhY3RvciBvdXIgaW1wbGVtZW50YXRpb24gdG8gcGFy c2UgYW5kIGhhbmRsZQ0KIGFsbCB0aGUgY2xpZW50IHN0dWZmIDpiZWZvcmU6IGhhbmRsaW5nIHRo ZSByZXF1ZXN0IG9iamVjdCBpdHNlbGYuIEluIG90aGVyIHdvcmRzLCBpZiBJIGFsd2F5cyBoYXZl IHRvIHNlbmQgc29tZXRoaW5nIHRoYXQgaWRlbnRpZmllcyB0aGUgY2xpZW50IGluIGFkZGl0aW9u IHRvIHRoZSByZXF1ZXN0IG9iamVjdCwgdGhlbiBJIGNhbiBjb3VudCBvbiB0aGF0LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhvdWdo dHM/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVz dGluPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAzMCwgMjAxOSwg YXQgMTE6MjEgQU0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxs PTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgU2VwIDI2LCAyMDE5IGF0IDk6MzAgQU0gQWFy b24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29tIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+YWFyb25AcGFyZWNraS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQs MjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiZndDsgRGVwZW5kaW5nIG9uIGNsaWVudCB0eXBlIGFu ZCBhdXRoZW50aWNhdGlvbiBtZXRob2QsIHRoZSByZXF1ZXN0IG1pZ2h0PGJyIGNsYXNzPSIiPg0K Jmd0OyZuYnNwOyAmbmJzcDthbHNvIGluY2x1ZGUgdGhlICZxdW90O2NsaWVudF9pZCZxdW90OyBw YXJhbWV0ZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhc3N1bWUgdGhpcyBpcyBo aW50aW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHM8YnIgY2xhc3M9 IiI+DQpzZW5kaW5nIG9ubHkgdGhlICZxdW90O2NsaWVudF9pZCZxdW90OyBwYXJhbWV0ZXIgYW5k IGNvbmZpZGVudGlhbCBjbGllbnRzPGJyIGNsYXNzPSIiPg0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQ IEJhc2ljIEF1dGhvcml6YXRpb24gaGVhZGVyIHdoaWNoIGluY2x1ZGVzIGJvdGg8YnIgY2xhc3M9 IiI+DQp0aGUgY2xpZW50IElEIGFuZCBzZWNyZXQ/IEl0IHdvdWxkIHByb2JhYmx5IGJlIGhlbHBm dWwgdG8gY2FsbCBvdXQ8YnIgY2xhc3M9IiI+DQp0aGVzZSB0d28gY29tbW9uIGV4YW1wbGVzIGlm IEkgYW0gdW5kZXJzdGFuZGluZyB0aGlzIGNvcnJlY3RseSw8YnIgY2xhc3M9IiI+DQpvdGhlcndp c2UgaXQgc2VlbXMgcHJldHR5IHZhZ3VlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQgdGhp cyBpcyB0cnlpbmcgdG8gY29udmV5IGlzIHRoYXQgYmVjYXVzZSBjbGllbnQgYXV0aGVudGljYXRp b24gYXQgdGhpcyBQdXNoZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IEVuZHBvaW50IGhhcHBlbnMg dGhlIHNhbWUgd2F5IGFzIGF0IHRoZSB0b2tlbiBlbmRwb2ludCAoYW5kIG90aGVyIGVuZHBvaW50 cyBjYWxsZWQgZGlyZWN0bHkgYnkgdGhlIGNsaWVudCkgdGhlIGNsaWVudF9pZCBwYXJhbWV0ZXIg d2lsbCBzb21ldGltZXMNCiBiZSBwcmVzZW50IGJ1dCBub3QgbmVjZXNzYXJpbHkgYXMgc29tZSB0 eXBlcyBvZiBjbGllbnQgYXV0aCB1c2UgdGhlIGNsaWVudF9pZCBwYXJhbWV0ZXIgKG5vbmUsIGNs aWVudF9zZWNyZXRfcG9zdCwgdGxzX2NsaWVudF9hdXRoLCBzZWxmX3NpZ25lZF90bHNfY2xpZW50 X2F1dGgpIGFuZCBzb21lIGRvbid0IChjbGllbnRfc2VjcmV0X2Jhc2ljLCBjbGllbnRfc2VjcmV0 X2p3dCwgcHJpdmF0ZV9rZXlfand0KS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFsdGhvdWdoIHRoZSBkcmFmdCBkb2VzIGxhdGVyIHNh eSAmcXVvdDtUaGUgQVMgTVVTVCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCB0aGUgc2FtZSB3YXkgYXMg YXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQmcXVvdDsgd2hpY2ggSSB0aGluayBjb3VsZCBy ZWFzb25hYmx5IGJlIGludGVycHJldGVkIGFzIHJlcXVpcmluZyBjbGllbnRfaWQuJm5ic3A7IGUu Zy4sDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlv bi00LjEuMSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY3NDk/I3NlY3Rpb24tNC4uMS4xPC9hPiAmYW1wOyA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlvbi00LjIuMSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3NlY3Rp b24tNC4yLjE8L2E+IDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28gcGVyaGFwcyB0aGUgc2VudGVuY2UgaW4g cXVlc3Rpb24gc2hvdWxkIGJlIHJlbW92ZWQgYW5kIGhhdmUgY2xpZW50X2lkIGJlIGEgcmVxdWly ZWQgcGFyYW1ldGVyIGF0IHRoZSBQQVIgZW5kcG9pbnQuDQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGkgc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweDtv dXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnJnYigyNTUsMjU1 LDI1NSk7Zm9udC1mYW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1z eXN0ZW0sc3lzdGVtLXVpLCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxV YnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2Vy aWY7Y29sb3I6cmdiKDg1LDg1LDg1KSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7 cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTtiYWNrZ3JvdW5kOnRyYW5zcGFyZW50O2ZvbnQtZmFtaWx5OnByb3hpbWEtbm92YS16ZW5kZXNr LHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwmcXVvdDtTZWdvZSBV SSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMsVWJ1bnR1LENhbnRhcmVsbCwmcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtd2VpZ2h0OjYwMCIgY2xhc3M9IiI+ PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+Q09ORklERU5USUFMSVRZDQogTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkNCiB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+PC9zcGFuPjwvaT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcg bGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDEA2590FD944D849252D22610461F35mitedu_-- From nobody Thu Oct 10 10:01:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527C712006E for ; Thu, 10 Oct 2019 10:01:46 -0700 (PDT) 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 nxTB-VYwg20D for ; Thu, 10 Oct 2019 10:01:43 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893821200CC for ; Thu, 10 Oct 2019 10:01:43 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x9AH1drG001704; Thu, 10 Oct 2019 13:01:40 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 10 Oct 2019 13:01:38 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Oct 2019 13:01:39 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 10 Oct 2019 13:01:39 -0400 From: Justin Richer To: Filip Skokan CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt Thread-Index: AQHVfwfNa3xPxCQlOEmJVjaFyUAiTKdTt50AgACliwCAAACagA== Date: Thu, 10 Oct 2019 17:01:39 +0000 Message-ID: <5F376EBC-866B-4E06-AEA9-0FFCB3625074@mit.edu> References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_5F376EBC866B4E06AEA90FFCB3625074mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 17:01:46 -0000 --_000_5F376EBC866B4E06AEA90FFCB3625074mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gYSByZWxhdGVkIG5vdGUsIEpBUiBjdXJyZW50bHkgYWxsb3dzIOKAnGNsaWVudF9pZOKAnSB0 byBiZSBvcHRpb25hbCBmb3IgZXhhY3RseSB0aGUgcmVhc29uIG9mIGl0IGJlaW5nIGluY2x1ZGVk IGluIHRoZSByZXF1ZXN0IG9iamVjdC4gSG93ZXZlciwgaXQgZmFsbHMgaW50byB0aGUgc2FtZSBp c3N1ZSB3aGVyZSB5b3UgY2Fu4oCZdCBkZWNyeXB0IHRoZSByZXF1ZXN0IG9iamVjdCB3aXRob3V0 IGtub3dpbmcgd2hpY2ggY2xpZW504oCZcyBrZXlzIHRvIHVzZSwgYW5kIHlvdSBjYW7igJl0IGtu b3cgd2hpY2ggY2xpZW50IHlvdeKAmXJlIGRlYWxpbmcgd2l0aCB3aXRob3V0IGRlY3J5cHRpbmcg dGhlIG9iamVjdC4gSSB0aGluayB0aGF0IHByb2JhYmx5IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBp biBKQVIuDQoNCuKAlCBKdXN0aW4NCg0KT24gT2N0IDEwLCAyMDE5LCBhdCAxMjo1OSBQTSwgSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90 ZToNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuIE15IGNvbmNlcm4gaXMgdGhhdCBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQgdG8g4oCcYXV0aGVudGljYXRlIHRoZSBjbGllbnTi gJ0gY291bGQgYmUgaW50ZXJwcmV0ZWQgaW4gdGhlIEZBUEkgZHJhZnTigJlzIHNlbnNlLCB3aGlj aCBpcyB0byBzYXkgdmFsaWRhdGluZyB0aGUgc2lnbmF0dXJlIG9uIHRoZSByZXF1ZXN0IG9iamVj dCBhbmQgbm90IGRvaW5nIGFueXRoaW5nIGVsc2UuDQoNClRoZSBwcm9ibGVtIGNvbWVzIGZyb20g dGhlIGZhY3QgdGhhdCB3ZeKAmXJlIGVmZmVjdGl2ZWx5IHNtYXNoaW5nIHRvZ2V0aGVyIHRoZSBj b25kaXRpb25zIGFuZCBhc3N1bXB0aW9ucyBvZiBib3RoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBv aW50IGFuZCB0b2tlbiBlbmRwb2ludCBpbnRvIGEgbmV3IGVuZHBvaW50LiBJdOKAmXMgZ29pbmcg dG8gYmUgbWVzc3ksIGFuZCB3ZSBuZWVkIHRvIGJlIHZlcnkgcGVkYW50aWMgYWJvdXQgd2hhdCB3 ZSBtZWFuIGlmIHRoaXMgZHJhZnQgaXMgZ29pbmcgdG8gYmUgaW1wbGVtZW50YWJsZS4NCg0K4oCU IEp1c3Rpbg0KDQpPbiBPY3QgMTAsIDIwMTksIGF0IDM6MDcgQU0sIEZpbGlwIFNrb2thbiA8cGFu dmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBJ ZiBzZXZlcmFsIG9mIHRoZXNlIGFyZSBzZW50LCB0aGV5IG5lZWQgdG8gYmUgY29uc2lzdGVudC4N Cg0KR2l2ZW4gdGhhdCBjbGllbnQgYXV0aGVudGljYXRpb24gcHJlY2VkZXMgcHJvY2Vzc2luZyB0 aGUgcmVzdCBvZiB0aGUgcmVxdWVzdCwgaWYgc2V2ZXJhbCBjbGllbnQgYXV0aGVudGljYXRpb24g bWV0aG9kcyBhcmUgcHJvdmlkZWQgKGhlYWRlciArIHNlY3JldCBvciBzZWNyZXQgKyBhc3NlcnRp b24sIGV0YykgeW91IGdlbmVyYWxseSByZWplY3QgdGhlIHJlcXVlc3QsIGRvbid0IHlvdT8NCg0K VGhlbiB0aGVyZSdzIHRoZSByZXF1aXJlbWVudCBmb3IgdGhlIGNsaWVudF9pZCBnaXZlbiBieSBh dXRoZW50aWNhdGlvbiBtZXRob2QgKG5vbmUgaXMgc3RpbGwgYW4gImF1dGhlbnRpY2F0aW9uIiBt ZXRob2QgLSBjbGllbnRfaWQgaW4gdGhlIGJvZHkpIHRvIG1hdGNoIHRoZSBgaXNzYCBhbmQgYGNs aWVudF9pZGAgaW4gdGhlIHJlcXVlc3Qgb2JqZWN0LiBUaGF0J3MgYWxyZWFkeSByZXF1aXJlZCBi eSBKQVIgcHJvY2Vzc2luZyBydWxlcyBhbmQgYWxzbyBQQVIuDQoNCj4gQnV0IGJlY2F1c2UgSkFS IGFsbG93cyB5b3UgdG8gc2VuZCBpbiBhIHJlcXVlc3QgdGhhdCBpcyBvbmx5IGEgcmVxdWVzdCBv YmplY3QsIGl0IGFsc28gc2VlbXMgbGlrZSB5b3UgY291bGQgcGFzcyBpbiBqdXN0IHRoZSByZXF1 ZXN0IG9iamVjdCB3aXRoIG5vIG90aGVyIHBhcmFtZXRlcnMsIGlmIEnigJltIHJlYWRpbmcgdGhp cyByaWdodCwgd2hpY2ggd291bGQgaW1wbHkgdGhhdCB5b3UgY291bGQgYmUgZXhwZWN0ZWQgdG8g Z2xlYW4gdGhlIGNsaWVudCBJRCBmcm9tIHRoZSByZXF1ZXN0IG9iamVjdCBpdHNlbGYgd2l0aG91 dCBpdCBiZWluZyBpbiBlaXRoZXIgYSBwYXJhbWV0ZXIgb3IgaW4gYW5vdGhlciBwYXJ0IG9mIHRo ZSByZXF1ZXN0IHRoYXTigJlzIGVhc2lseSBhY2Nlc3NlZC4NCg0KSXQgd2FzIG9ubHkgaW4gdGhl IG9yaWdpbmFsIEZBUEkgcmV2aXNpb24gb2YgUEFSIHRoYXQgYWxsb3dlZCB0aGUgcmVxdWVzdCBv YmplY3QncyBzaWduYXR1cmUgdG8gc3Vic3RpdHV0ZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGlu IHRoZSBpbmRpdmlkdWFsIGRyYWZ0IHB1Ymxpc2hlZCB0byBJRVRGIHRoYXQncyBub3QgdGhlIGNh c2UgYW55bW9yZSAtIGhlbmNlIGlmICJvbmx5IiBhIHJlcXVlc3Qgb2JqZWN0IGlzIHBhc3NlZCAt IHdpdGggbm8gY2xpZW50IGF1dGhlbnRpY2F0aW9uIChoZWFkZXIsIGNsaWVudF9pZCBpbiBib2R5 LCBtdGxzKSB5b3UgZmFpbCB0aGUgcmVxdWVzdC4NCg0KQXMgZmFyIGFzIHJlcXVpcmluZyBjbGll bnRfaWQsIGhlcmUncyB3aGF0IG15IGltcGxlbWVudGF0aW9uIGRvZXMNCg0KPiBXaGVuIHByb3Zp ZGluZyBmb3JtLWVuY29kZWQgcGFyYW1ldGVycyAtIGNsaWVudF9pZCBtdXN0IGJlIHByZXNlbnQg aW4gdGhlIGZvcm0uDQo+IFdoZW4gcHJvdmlkaW5nIHNpZ25lZC9lbmNyeXB0ZWQgcmVxdWVzdCBv YmplY3QgLSBjbGllbnRfaWQgbXVzdCBiZSBwcmVzZW50IGluIHRoZSByZXF1ZXN0IG9iamVjdC4N Cg0KSSB3b3VsZG4ndCBtaW5kIGFsd2F5cyByZXF1aXJpbmcgY2xpZW50X2lkLCBhbmQgaSdtIG5v dCB3b3JyaWVkIGFib3V0IGl0IG5vdCBtYXRjaGluZyBlLmcuIHRoZSBhdXRob3JpemF0aW9uIGhl YWRlciBiZWNhdXNlIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWlkZGxld2FyZSBpbiBwbGFj ZSBhbHJlYWR5IHRha2VzIGNhcmUgb2YgdGhhdC4NCg0KUyBwb3pkcmF2ZW0sDQpGaWxpcCBTa29r YW4NCg0KDQpPbiBUaHUsIDEwIE9jdCAyMDE5IGF0IDAzOjEzLCBKdXN0aW4gUmljaGVyIDxqcmlj aGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KU28gaW4gZG9pbmcg YW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcywgSSByYW4gaW50byB0aGlzIHByb2JsZW0gYXMgd2Vs bC4gU3BlY2lmaWNhbGx5LCB3ZSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50IHdl4oCZcmUgZGVh bGluZyB3aXRoIHRvIGZ1bGx5IHZhbGlkYXRlIHRoZSBlbmNyeXB0ZWQgcmVxdWVzdCBvYmplY3Qg YXMgd2VsbCBhcyBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlvbi4gQ3VycmVudGx5LCB0aGluZ3Mg YXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lmaWVkLCBhbmQgcGFydCBvZiB0aGF0IGNvbWVzIGZyb20g dGhlIGhpc3Rvcnkgb2YgdGhpcyBkb2N1bWVudDogaW4gdGhlIHByZXZpb3VzIEZBUEkgc3BlYywg dGhlIChyZXF1aXJlZCkgc2lnbmF0dXJlIG9mIHRoZSByZXF1ZXN0IG9iamVjdCBhY3RlZCBhcyBk ZS1mYWN0byBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIGNsaWVudC4gSW4gUEFSLCB3ZSBub3Qgb25s eSBjYW7igJl0IHJlbHkgb24gdGhlIHJlcXVlc3QgaXRzZWxmIGJlaW5nIHNpZ25lZCwgd2UgYWxz byByZXF1aXJlIGhhbmRsaW5nIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBpdHMgbWFueSBm b3Jtcy4gVGhhdCBtZWFucyB0aGUgY2xpZW50IElEIGNvdWxkIHNob3cgdXAgaW4gYW55IGNvbWJp bmF0aW9uIG9mOg0KDQogLSBGb3JtIHBhcmFtZXRlcg0KIC0gQXV0aG9yaXphdGlvbiBoZWFkZXIN CiAtIENsaWVudCBhc3NlcnRpb27igJlzIOKAnGlzcyIgZmllbGQNCiAtIFJlcXVlc3Qgb2JqZWN0 4oCZcyDigJxjbGllbnRfaWTigJ0gKGFuZCDigJxpc3PigJ0pIGZpZWxkDQoNCklmIHNldmVyYWwg b2YgdGhlc2UgYXJlIHNlbnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50LiBBbmQgd2hhdGV2 ZXIgdmFsdWUgY29tZXMgb3V0IG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2xpZW50 4oCZcyBhdXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCkJ1dCBiZWNhdXNlIEpBUiBhbGxvd3MgeW91 IHRvIHNlbmQgaW4gYSByZXF1ZXN0IHRoYXQgaXMgb25seSBhIHJlcXVlc3Qgb2JqZWN0LCBpdCBh bHNvIHNlZW1zIGxpa2UgeW91IGNvdWxkIHBhc3MgaW4ganVzdCB0aGUgcmVxdWVzdCBvYmplY3Qg d2l0aCBubyBvdGhlciBwYXJhbWV0ZXJzLCBpZiBJ4oCZbSByZWFkaW5nIHRoaXMgcmlnaHQsIHdo aWNoIHdvdWxkIGltcGx5IHRoYXQgeW91IGNvdWxkIGJlIGV4cGVjdGVkIHRvIGdsZWFuIHRoZSBj bGllbnQgSUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhvdXQgaXQgYmVpbmcg aW4gZWl0aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0aGUgcmVxdWVzdCB0 aGF04oCZcyBlYXNpbHkgYWNjZXNzZWQuDQoNClNvIGhlcmVpbiBsaWVzIHRoZSBwcm9ibGVtLiBJ biBvcmRlciB0byBwcm9wZXJseSBwcm9jZXNzIHRoZSByZXF1ZXN0IG9iamVjdCwgeW91IG5lZWQg dG8ga25vdyB3aGljaCBjbGllbnQgeW914oCZcmUgZGVhbGluZyB3aXRoIHNvIHlvdSBjYW4gdmFs aWRhdGUgdGhlIHNpZ25pbmcgYWxncywga2V5cywgYW5kIGFsbCB0aGF0LiBGb3Igc2lnbmVkIHJl cXVlc3RzIHRoYXTigJlzIHNpbXBsZSBlbm91Z2gg4oCUIHBhcnNlIGluIG9uZSBzdGVwLCB0aGVu IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCB0aGVuIHZhbGlkYXRlIHRoZSBzaWduYXR1cmVzLiBC dXQgZm9yIGVuY3J5cHRlZCBKV1RzIGl04oCZcyBsZXNzIGNsZWFyOiBzb21lIG1ldGhvZHMgd291 bGQgdXNlIG9ubHkgdGhlIHNlcnZlcuKAmXMgcHVibGljIGtleSwgYnV0IHN5bW1ldHJpYyBlbmNy eXB0aW9uIGFsZ29yaXRobS9lbmNvZGluZyBwYWlycyB3b3VsZCB1c2UgdGhlIGNsaWVudCBzZWNy ZXQgYXMgdGhlIHBhaXJ3aXNlIHNlY3JldCBmb3IgdGhlIGVuY3J5cHRpb24uIFdoaWNoIG1lYW5z IHRoYXQgd2UgbmVlZCB0byBrbm93IHdoaWNoIGNsaWVudCBzZW50IHRoZSByZXF1ZXN0IGJlZm9y ZSB0aGUgZGVjcnlwdGlvbiBoYXBwZW5zLg0KDQpXaGljaCBpbiB0dXJuIGltcGxpZXMgb25lIG9m IHR3byB0aGluZ3MgYXJlIHRydWU6DQoNCiAtIFlvdSBjYW7igJl0IGRvIGEgcmVxdWVzdCBvYmpl Y3Qgd2hlbiBpdOKAmXMgZW5jcnlwdGVkIHVzaW5nIGEgc3ltbWV0cmljIGFsZ29yaXRobQ0KIC0g WW91IGhhdmUgdG8gcmVxdWlyZSB0aGUgY2xpZW50IElEIGZyb20gc29tZSBvdGhlciBwYXJ0IG9m IHRoZSByZXF1ZXN0LCBzdWNoIGFzIGEgZm9ybSBwYXJhbWV0ZXIsIGF1dGggaGVhZGVyLCBvciBj bGllbnQgYXNzZXJ0aW9uOyB0aGUgY2xpZW50X2lkIGluIHRoZSByZXF1ZXN0IG9iamVjdCBjYW5u b3QgYmUgY291bnRlZCBvbiBhcyBiZWluZyBzdWZmaWNpZW50DQoNCkluIG91ciBjdXJyZW50IGRy YWZ0IGltcGxlbWVudGF0aW9uIG9mIFBBUiwgSeKAmW0gdHVybmluZyBvZmYgc3VwcG9ydCBmb3Ig c3ltbWV0cmljIGVuY3J5cHRpb24gaW4gdGhpcyBvbmUgY29kZSBwYXRoLiBJZiB3ZSBjYW4gc29t ZWhvdyBjb3VudCBvbiBiZWluZyBhYmxlIHRvIGZpbmQgYSBjbGllbnRfaWQgZXZlcnkgdGltZSwg dGhlbiB3ZSBjYW4gcmVmYWN0b3Igb3VyIGltcGxlbWVudGF0aW9uIHRvIHBhcnNlIGFuZCBoYW5k bGUgYWxsIHRoZSBjbGllbnQgc3R1ZmYgOmJlZm9yZTogaGFuZGxpbmcgdGhlIHJlcXVlc3Qgb2Jq ZWN0IGl0c2VsZi4gSW4gb3RoZXIgd29yZHMsIGlmIEkgYWx3YXlzIGhhdmUgdG8gc2VuZCBzb21l dGhpbmcgdGhhdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgaW4gYWRkaXRpb24gdG8gdGhlIHJlcXVl c3Qgb2JqZWN0LCB0aGVuIEkgY2FuIGNvdW50IG9uIHRoYXQuDQoNClRob3VnaHRzPw0KDQrigJQg SnVzdGluDQoNCk9uIFNlcCAzMCwgMjAxOSwgYXQgMTE6MjEgQU0sIEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpiY2FtcGJl bGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCg0KDQpPbiBU aHUsIFNlcCAyNiwgMjAxOSBhdCA5OjMwIEFNIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVja2ku Y29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KPiBEZXBlbmRpbmcgb24gY2xp ZW50IHR5cGUgYW5kIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCwgdGhlIHJlcXVlc3QgbWlnaHQNCj4g ICBhbHNvIGluY2x1ZGUgdGhlICJjbGllbnRfaWQiIHBhcmFtZXRlci4NCg0KSSBhc3N1bWUgdGhp cyBpcyBoaW50aW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcHVibGljIGNsaWVudHMNCnNl bmRpbmcgb25seSB0aGUgImNsaWVudF9pZCIgcGFyYW1ldGVyIGFuZCBjb25maWRlbnRpYWwgY2xp ZW50cw0Kc2VuZGluZyBvbmx5IHRoZSBIVFRQIEJhc2ljIEF1dGhvcml6YXRpb24gaGVhZGVyIHdo aWNoIGluY2x1ZGVzIGJvdGgNCnRoZSBjbGllbnQgSUQgYW5kIHNlY3JldD8gSXQgd291bGQgcHJv YmFibHkgYmUgaGVscGZ1bCB0byBjYWxsIG91dA0KdGhlc2UgdHdvIGNvbW1vbiBleGFtcGxlcyBp ZiBJIGFtIHVuZGVyc3RhbmRpbmcgdGhpcyBjb3JyZWN0bHksDQpvdGhlcndpc2UgaXQgc2VlbXMg cHJldHR5IHZhZ3VlLg0KDQpXaGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGNvbnZleSBpcyB0aGF0IGJl Y2F1c2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGF0IHRoaXMgUHVzaGVkIEF1dGhvcml6YXRpb24g UmVxdWVzdCBFbmRwb2ludCBoYXBwZW5zIHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgdG9rZW4gZW5k cG9pbnQgKGFuZCBvdGhlciBlbmRwb2ludHMgY2FsbGVkIGRpcmVjdGx5IGJ5IHRoZSBjbGllbnQp IHRoZSBjbGllbnRfaWQgcGFyYW1ldGVyIHdpbGwgc29tZXRpbWVzIGJlIHByZXNlbnQgYnV0IG5v dCBuZWNlc3NhcmlseSBhcyBzb21lIHR5cGVzIG9mIGNsaWVudCBhdXRoIHVzZSB0aGUgY2xpZW50 X2lkIHBhcmFtZXRlciAobm9uZSwgY2xpZW50X3NlY3JldF9wb3N0LCB0bHNfY2xpZW50X2F1dGgs IHNlbGZfc2lnbmVkX3Rsc19jbGllbnRfYXV0aCkgYW5kIHNvbWUgZG9uJ3QgKGNsaWVudF9zZWNy ZXRfYmFzaWMsIGNsaWVudF9zZWNyZXRfand0LCBwcml2YXRlX2tleV9qd3QpLg0KDQpBbHRob3Vn aCB0aGUgZHJhZnQgZG9lcyBsYXRlciBzYXkgIlRoZSBBUyBNVVNUIHZhbGlkYXRlIHRoZSByZXF1 ZXN0IHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCIgd2hpY2gg SSB0aGluayBjb3VsZCByZWFzb25hYmx5IGJlIGludGVycHJldGVkIGFzIHJlcXVpcmluZyBjbGll bnRfaWQuICBlLmcuLCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlv bi00Li4xLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3NlY3Rpb24tNC4x LjE+ICYgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk/I3NlY3Rpb24tNC4yLjEN Cg0KU28gcGVyaGFwcyB0aGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gc2hvdWxkIGJlIHJlbW92ZWQg YW5kIGhhdmUgY2xpZW50X2lkIGJlIGEgcmVxdWlyZWQgcGFyYW1ldGVyIGF0IHRoZSBQQVIgZW5k cG9pbnQuDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQo= --_000_5F376EBC866B4E06AEA90FFCB3625074mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <2BFCA183DCDE814E8B775A2354FF1E61@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkluIGEgcmVsYXRlZCBub3RlLCBKQVIgY3VycmVu dGx5IGFsbG93cyDigJxjbGllbnRfaWTigJ0gdG8gYmUgb3B0aW9uYWwgZm9yIGV4YWN0bHkgdGhl IHJlYXNvbiBvZiBpdCBiZWluZyBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdCBvYmplY3QuIEhvd2V2 ZXIsIGl0IGZhbGxzIGludG8gdGhlIHNhbWUgaXNzdWUgd2hlcmUgeW91IGNhbuKAmXQgZGVjcnlw dCB0aGUgcmVxdWVzdCBvYmplY3Qgd2l0aG91dCBrbm93aW5nIHdoaWNoIGNsaWVudOKAmXMga2V5 cyB0byB1c2UsDQogYW5kIHlvdSBjYW7igJl0IGtub3cgd2hpY2ggY2xpZW50IHlvdeKAmXJlIGRl YWxpbmcgd2l0aCB3aXRob3V0IGRlY3J5cHRpbmcgdGhlIG9iamVjdC4gSSB0aGluayB0aGF0IHBy b2JhYmx5IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbiBKQVIuDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCAxMCwgMjAxOSwgYXQgMTI6NTkgUE0sIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIGNsYXNzPSIiPmpyaWNo ZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLiBNeSBjb25jZXJu IGlzIHRoYXQgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHJlcXVpcmVtZW50IHRvIOKAnGF1dGhlbnRp Y2F0ZSB0aGUgY2xpZW504oCdIGNvdWxkIGJlIGludGVycHJldGVkIGluIHRoZSBGQVBJIGRyYWZ0 4oCZcyBzZW5zZSwgd2hpY2ggaXMgdG8gc2F5IHZhbGlkYXRpbmcgdGhlIHNpZ25hdHVyZSBvbiB0 aGUgcmVxdWVzdCBvYmplY3QgYW5kIG5vdCBkb2luZyBhbnl0aGluZyBlbHNlLiZuYnNwOw0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHByb2Js ZW0gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHdl4oCZcmUgZWZmZWN0aXZlbHkgc21hc2hpbmcg dG9nZXRoZXIgdGhlIGNvbmRpdGlvbnMgYW5kIGFzc3VtcHRpb25zIG9mIGJvdGggdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgYW5kIHRva2VuIGVuZHBvaW50IGludG8gYSBuZXcgZW5kcG9pbnQu IEl04oCZcyBnb2luZyB0byBiZSBtZXNzeSwgYW5kIHdlIG5lZWQgdG8gYmUgdmVyeSBwZWRhbnRp YyBhYm91dCB3aGF0DQogd2UgbWVhbiBpZiB0aGlzIGRyYWZ0IGlzIGdvaW5nIHRvIGJlIGltcGxl bWVudGFibGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g T2N0IDEwLCAyMDE5LCBhdCAzOjA3IEFNLCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpwYW52YS5pcEBnbWFpbC5jb20iIGNsYXNzPSIiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jmd0 OyZuYnNwOzxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPklmIHNldmVyYWwgb2YgdGhlc2UgYXJlIHNl bnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50Ljwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj5HaXZlbiB0aGF0IGNsaWVudCBh dXRoZW50aWNhdGlvbiZuYnNwOzwvc3Bhbj5wcmVjZWRlczxzcGFuIHN0eWxlPSIiIGNsYXNzPSIi PiZuYnNwO3Byb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlIHJlcXVlc3QsIGlmIHNldmVyYWwgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYXJlIHByb3ZpZGVkIChoZWFkZXImbmJzcDsmIzQz OyBzZWNyZXQgb3Igc2VjcmV0Jm5ic3A7JiM0MzsgYXNzZXJ0aW9uLCBldGMpJm5ic3A7eW91IGdl bmVyYWxseQ0KIHJlamVjdCB0aGUgcmVxdWVzdCwgZG9uJ3QgeW91Pzwvc3Bhbj48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFu PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj5UaGVuIHRoZXJl J3MgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgY2xpZW50X2lkIGdpdmVuIGJ5IGF1dGhlbnRpY2F0 aW9uIG1ldGhvZCAobm9uZSBpcyBzdGlsbCBhbiAmcXVvdDthdXRoZW50aWNhdGlvbiZxdW90OyBt ZXRob2QgLSBjbGllbnRfaWQgaW4gdGhlIGJvZHkpIHRvIG1hdGNoIHRoZSBgaXNzYCBhbmQgYGNs aWVudF9pZGAgaW4gdGhlIHJlcXVlc3Qgb2JqZWN0LiBUaGF0J3MgYWxyZWFkeSByZXF1aXJlZA0K IGJ5IEpBUiBwcm9jZXNzaW5nIHJ1bGVzIGFuZCBhbHNvIFBBUi48L3NwYW4+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+Jmd0OyZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj5CdXQgYmVjYXVzZSBKQVIgYWxsb3dzIHlvdSB0 byBzZW5kIGluIGEgcmVxdWVzdCB0aGF0IGlzIG9ubHkgYSByZXF1ZXN0IG9iamVjdCwgaXQgYWxz byBzZWVtcyBsaWtlIHlvdSBjb3VsZCBwYXNzIGluIGp1c3QgdGhlIHJlcXVlc3Qgb2JqZWN0IHdp dGggbm8gb3RoZXIgcGFyYW1ldGVycywgaWYgSeKAmW0gcmVhZGluZyB0aGlzDQogcmlnaHQsIHdo aWNoIHdvdWxkIGltcGx5IHRoYXQgeW91IGNvdWxkIGJlIGV4cGVjdGVkIHRvIGdsZWFuIHRoZSBj bGllbnQgSUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhvdXQgaXQgYmVpbmcg aW4gZWl0aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0aGUgcmVxdWVzdCB0 aGF04oCZcyBlYXNpbHkgYWNjZXNzZWQuJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPkl0IHdhcyBvbmx5IGluIHRoZSBv cmlnaW5hbCBGQVBJIHJldmlzaW9uIG9mIFBBUiB0aGF0IGFsbG93ZWQgdGhlIHJlcXVlc3Qgb2Jq ZWN0J3Mgc2lnbmF0dXJlIHRvIHN1YnN0aXR1dGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCBpbiB0 aGUgaW5kaXZpZHVhbCBkcmFmdCBwdWJsaXNoZWQgdG8gSUVURiB0aGF0J3Mgbm90IHRoZSBjYXNl IGFueW1vcmUgLSBoZW5jZSBpZiAmcXVvdDtvbmx5JnF1b3Q7IGENCiByZXF1ZXN0IG9iamVjdCBp cyBwYXNzZWQgLSB3aXRoIG5vIGNsaWVudCBhdXRoZW50aWNhdGlvbiAoaGVhZGVyLCBjbGllbnRf aWQgaW4gYm9keSwgbXRscykgeW91IGZhaWwgdGhlIHJlcXVlc3QuPC9zcGFuPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPkFzIGZhciBhcyBy ZXF1aXJpbmcgY2xpZW50X2lkLCBoZXJlJ3Mgd2hhdCBteSBpbXBsZW1lbnRhdGlvbiBkb2VzPC9z cGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiPiZndDsg V2hlbiBwcm92aWRpbmcgZm9ybS1lbmNvZGVkIHBhcmFtZXRlcnMgLSBjbGllbnRfaWQgbXVzdCBi ZSBwcmVzZW50IGluIHRoZSBmb3JtLjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiI+Jmd0OyBXaGVuIHByb3ZpZGluZyBzaWduZWQvZW5jcnlwdGVkIHJlcXVlc3Qgb2Jq ZWN0IC0gY2xpZW50X2lkIG11c3QgYmUgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCBvYmplY3QuPC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiPkkgd291bGRuJ3QgbWlu ZCBhbHdheXMgcmVxdWlyaW5nIGNsaWVudF9pZCwgYW5kIGknbSBub3Qgd29ycmllZCBhYm91dCBp dCBub3QgbWF0Y2hpbmcgZS5nLiB0aGUgYXV0aG9yaXphdGlvbiBoZWFkZXIgYmVjYXVzZSB0aGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1pZGRsZXdhcmUgaW4gcGxhY2UgYWxyZWFkeSB0YWtlcyBj YXJlIG9mIHRoYXQuPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0 dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj5TIHBvemRyYXZlbSw8YnIgY2xh c3M9IiI+DQo8YiBjbGFzcz0iIj5GaWxpcCBTa29rYW48L2I+PC9kaXY+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgMTAgT2N0IDIwMTkg YXQgMDM6MTMsIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l ZHUiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsi IGNsYXNzPSIiPlNvIGluIGRvaW5nIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMsIEkgcmFuIGlu dG8gdGhpcyBwcm9ibGVtIGFzIHdlbGwuIFNwZWNpZmljYWxseSwgd2UgbmVlZCB0byBrbm93IHdo aWNoIGNsaWVudCB3ZeKAmXJlIGRlYWxpbmcgd2l0aCB0byBmdWxseSB2YWxpZGF0ZSB0aGUgZW5j cnlwdGVkIHJlcXVlc3Qgb2JqZWN0IGFzIHdlbGwgYXMgcGVyZm9ybSB0aGUgYXV0aGVudGljYXRp b24uDQogQ3VycmVudGx5LCB0aGluZ3MgYXJlIGEgbGl0dGxlIHVuZGVyc3BlY2lmaWVkLCBhbmQg cGFydCBvZiB0aGF0IGNvbWVzIGZyb20gdGhlIGhpc3Rvcnkgb2YgdGhpcyBkb2N1bWVudDogaW4g dGhlIHByZXZpb3VzIEZBUEkgc3BlYywgdGhlIChyZXF1aXJlZCkgc2lnbmF0dXJlIG9mIHRoZSBy ZXF1ZXN0IG9iamVjdCBhY3RlZCBhcyBkZS1mYWN0byBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIGNs aWVudC4gSW4gUEFSLCB3ZSBub3Qgb25seSBjYW7igJl0IHJlbHkNCiBvbiB0aGUgcmVxdWVzdCBp dHNlbGYgYmVpbmcgc2lnbmVkLCB3ZSBhbHNvIHJlcXVpcmUgaGFuZGxpbmcgb2YgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGluIGl0cyBtYW55IGZvcm1zLiBUaGF0IG1lYW5zIHRoZSBjbGllbnQgSUQg Y291bGQgc2hvdyB1cCBpbiBhbnkgY29tYmluYXRpb24gb2Y6DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDstIEZvcm0gcGFyYW1ldGVyPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOy0gQXV0aG9yaXphdGlvbiBoZWFkZXI8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Jm5ic3A7LSBDbGllbnQgYXNzZXJ0aW9u4oCZcyDigJxpc3MmcXVvdDsgZmll bGQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7LSBSZXF1ZXN0IG9iamVjdOKAmXMg4oCcY2xp ZW50X2lk4oCdIChhbmQg4oCcaXNz4oCdKSBmaWVsZDxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHNldmVyYWwgb2YgdGhl c2UgYXJlIHNlbnQsIHRoZXkgbmVlZCB0byBiZSBjb25zaXN0ZW50LiBBbmQgd2hhdGV2ZXIgdmFs dWUgY29tZXMgb3V0IG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2xpZW504oCZcyBh dXRoZW50aWNhdGlvbiBtZXRob2QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CdXQgYmVjYXVzZSBKQVIgYWxsb3dzIHlvdSB0byBzZW5k IGluIGEgcmVxdWVzdCB0aGF0IGlzIG9ubHkgYSByZXF1ZXN0IG9iamVjdCwgaXQgYWxzbyBzZWVt cyBsaWtlIHlvdSBjb3VsZCBwYXNzIGluIGp1c3QgdGhlIHJlcXVlc3Qgb2JqZWN0IHdpdGggbm8g b3RoZXIgcGFyYW1ldGVycywgaWYgSeKAmW0gcmVhZGluZyB0aGlzIHJpZ2h0LCB3aGljaCB3b3Vs ZCBpbXBseSB0aGF0IHlvdSBjb3VsZCBiZSBleHBlY3RlZCB0byBnbGVhbg0KIHRoZSBjbGllbnQg SUQgZnJvbSB0aGUgcmVxdWVzdCBvYmplY3QgaXRzZWxmIHdpdGhvdXQgaXQgYmVpbmcgaW4gZWl0 aGVyIGEgcGFyYW1ldGVyIG9yIGluIGFub3RoZXIgcGFydCBvZiB0aGUgcmVxdWVzdCB0aGF04oCZ cyBlYXNpbHkgYWNjZXNzZWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TbyBoZXJlaW4gbGllcyB0aGUgcHJvYmxlbS4gSW4g b3JkZXIgdG8gcHJvcGVybHkgcHJvY2VzcyB0aGUgcmVxdWVzdCBvYmplY3QsIHlvdSBuZWVkIHRv IGtub3cgd2hpY2ggY2xpZW50IHlvdeKAmXJlIGRlYWxpbmcgd2l0aCBzbyB5b3UgY2FuIHZhbGlk YXRlIHRoZSBzaWduaW5nIGFsZ3MsIGtleXMsIGFuZCBhbGwgdGhhdC4gRm9yIHNpZ25lZCByZXF1 ZXN0cyB0aGF04oCZcyBzaW1wbGUgZW5vdWdoIOKAlCBwYXJzZSBpbiBvbmUgc3RlcCwNCiB0aGVu IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCB0aGVuIHZhbGlkYXRlIHRoZSBzaWduYXR1cmVzLiBC dXQgZm9yIGVuY3J5cHRlZCBKV1RzIGl04oCZcyBsZXNzIGNsZWFyOiBzb21lIG1ldGhvZHMgd291 bGQgdXNlIG9ubHkgdGhlIHNlcnZlcuKAmXMgcHVibGljIGtleSwgYnV0IHN5bW1ldHJpYyBlbmNy eXB0aW9uIGFsZ29yaXRobS9lbmNvZGluZyBwYWlycyB3b3VsZCB1c2UgdGhlIGNsaWVudCBzZWNy ZXQgYXMgdGhlIHBhaXJ3aXNlIHNlY3JldCBmb3INCiB0aGUgZW5jcnlwdGlvbi4gV2hpY2ggbWVh bnMgdGhhdCB3ZSBuZWVkIHRvIGtub3cgd2hpY2ggY2xpZW50IHNlbnQgdGhlIHJlcXVlc3QgYmVm b3JlIHRoZSBkZWNyeXB0aW9uIGhhcHBlbnMuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PldoaWNoIGluIHR1cm4gaW1wbGllcyBvbmUgb2YgdHdvIHRoaW5ncyBhcmUgdHJ1ZTo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw Oy0gWW91IGNhbuKAmXQgZG8gYSByZXF1ZXN0IG9iamVjdCB3aGVuIGl04oCZcyBlbmNyeXB0ZWQg dXNpbmcgYSBzeW1tZXRyaWMgYWxnb3JpdGhtPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOy0g WW91IGhhdmUgdG8gcmVxdWlyZSB0aGUgY2xpZW50IElEIGZyb20gc29tZSBvdGhlciBwYXJ0IG9m IHRoZSByZXF1ZXN0LCBzdWNoIGFzIGEgZm9ybSBwYXJhbWV0ZXIsIGF1dGggaGVhZGVyLCBvciBj bGllbnQgYXNzZXJ0aW9uOyB0aGUgY2xpZW50X2lkIGluIHRoZSByZXF1ZXN0IG9iamVjdCBjYW5u b3QgYmUgY291bnRlZCBvbiBhcyBiZWluZyBzdWZmaWNpZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBvdXIgY3VycmVudCBkcmFm dCBpbXBsZW1lbnRhdGlvbiBvZiBQQVIsIEnigJltIHR1cm5pbmcgb2ZmIHN1cHBvcnQgZm9yIHN5 bW1ldHJpYyBlbmNyeXB0aW9uIGluIHRoaXMgb25lIGNvZGUgcGF0aC4gSWYgd2UgY2FuIHNvbWVo b3cgY291bnQgb24gYmVpbmcgYWJsZSB0byBmaW5kIGEgY2xpZW50X2lkIGV2ZXJ5IHRpbWUsIHRo ZW4gd2UgY2FuIHJlZmFjdG9yIG91ciBpbXBsZW1lbnRhdGlvbiB0byBwYXJzZSBhbmQgaGFuZGxl DQogYWxsIHRoZSBjbGllbnQgc3R1ZmYgOmJlZm9yZTogaGFuZGxpbmcgdGhlIHJlcXVlc3Qgb2Jq ZWN0IGl0c2VsZi4gSW4gb3RoZXIgd29yZHMsIGlmIEkgYWx3YXlzIGhhdmUgdG8gc2VuZCBzb21l dGhpbmcgdGhhdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgaW4gYWRkaXRpb24gdG8gdGhlIHJlcXVl c3Qgb2JqZWN0LCB0aGVuIEkgY2FuIGNvdW50IG9uIHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaG91Z2h0cz88L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDMwLCAyMDE5LCBhdCAxMToyMSBBTSwg QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRp dHkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YmNhbXBiZWxs PTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21h aWxfYXR0ciI+T24gVGh1LCBTZXAgMjYsIDIwMTkgYXQgOTozMCBBTSBBYXJvbiBQYXJlY2tpICZs dDs8YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5hYXJvbkBwYXJlY2tpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KJmd0OyBEZXBlbmRpbmcgb24gY2xpZW50IHR5cGUgYW5kIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZCwgdGhlIHJlcXVlc3QgbWlnaHQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZu YnNwO2Fsc28gaW5jbHVkZSB0aGUgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IHBhcmFtZXRlci48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFzc3VtZSB0aGlzIGlzIGhpbnRpbmcgYXQgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiBwdWJsaWMgY2xpZW50czxiciBjbGFzcz0iIj4NCnNlbmRpbmcg b25seSB0aGUgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IHBhcmFtZXRlciBhbmQgY29uZmlkZW50aWFs IGNsaWVudHM8YnIgY2xhc3M9IiI+DQpzZW5kaW5nIG9ubHkgdGhlIEhUVFAgQmFzaWMgQXV0aG9y aXphdGlvbiBoZWFkZXIgd2hpY2ggaW5jbHVkZXMgYm90aDxiciBjbGFzcz0iIj4NCnRoZSBjbGll bnQgSUQgYW5kIHNlY3JldD8gSXQgd291bGQgcHJvYmFibHkgYmUgaGVscGZ1bCB0byBjYWxsIG91 dDxiciBjbGFzcz0iIj4NCnRoZXNlIHR3byBjb21tb24gZXhhbXBsZXMgaWYgSSBhbSB1bmRlcnN0 YW5kaW5nIHRoaXMgY29ycmVjdGx5LDxiciBjbGFzcz0iIj4NCm90aGVyd2lzZSBpdCBzZWVtcyBw cmV0dHkgdmFndWUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hhdCB0aGlzIGlzIHRyeWluZyB0 byBjb252ZXkgaXMgdGhhdCBiZWNhdXNlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhdCB0aGlzIFB1 c2hlZCBBdXRob3JpemF0aW9uIFJlcXVlc3QgRW5kcG9pbnQgaGFwcGVucyB0aGUgc2FtZSB3YXkg YXMgYXQgdGhlIHRva2VuIGVuZHBvaW50IChhbmQgb3RoZXIgZW5kcG9pbnRzIGNhbGxlZCBkaXJl Y3RseSBieSB0aGUgY2xpZW50KSB0aGUgY2xpZW50X2lkIHBhcmFtZXRlciB3aWxsIHNvbWV0aW1l cw0KIGJlIHByZXNlbnQgYnV0IG5vdCBuZWNlc3NhcmlseSBhcyBzb21lIHR5cGVzIG9mIGNsaWVu dCBhdXRoIHVzZSB0aGUgY2xpZW50X2lkIHBhcmFtZXRlciAobm9uZSwgY2xpZW50X3NlY3JldF9w b3N0LCB0bHNfY2xpZW50X2F1dGgsIHNlbGZfc2lnbmVkX3Rsc19jbGllbnRfYXV0aCkgYW5kIHNv bWUgZG9uJ3QgKGNsaWVudF9zZWNyZXRfYmFzaWMsIGNsaWVudF9zZWNyZXRfand0LCBwcml2YXRl X2tleV9qd3QpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+QWx0aG91Z2ggdGhlIGRyYWZ0IGRvZXMgbGF0ZXIgc2F5ICZxdW90O1RoZSBB UyBNVVNUIHZhbGlkYXRlIHRoZSByZXF1ZXN0IHRoZSBzYW1lIHdheSBhcyBhdCB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCZxdW90OyB3aGljaCBJIHRoaW5rIGNvdWxkIHJlYXNvbmFibHkgYmUg aW50ZXJwcmV0ZWQgYXMgcmVxdWlyaW5nIGNsaWVudF9pZC4mbmJzcDsgZS5nLiwNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5PyNzZWN0aW9uLTQuMS4xIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0 OT8jc2VjdGlvbi00Li4xLjE8L2E+ICZhbXA7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ5PyNzZWN0aW9uLTQuMi4xIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT8jc2VjdGlvbi00LjIuMTwvYT4g PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5TbyBwZXJoYXBzIHRoZSBzZW50ZW5jZSBpbiBxdWVzdGlvbiBzaG91 bGQgYmUgcmVtb3ZlZCBhbmQgaGF2ZSBjbGllbnRfaWQgYmUgYSByZXF1aXJlZCBwYXJhbWV0ZXIg YXQgdGhlIFBBUiBlbmRwb2ludC4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 aSBzdHlsZT0ibWFyZ2luOjBweDtwYWRkaW5nOjBweDtib3JkZXI6MHB4O291dGxpbmU6MHB4O3Zl cnRpY2FsLWFsaWduOmJhc2VsaW5lO2JhY2tncm91bmQ6cmdiKDI1NSwyNTUsMjU1KTtmb250LWZh bWlseTpwcm94aW1hLW5vdmEtemVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxzeXN0ZW0t dWksJnF1b3Q7U2Vnb2UgVUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJl bGwsJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjpyZ2Io ODUsODUsODUpIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtwYWRkaW5nOjBweDti b3JkZXI6MHB4O291dGxpbmU6MHB4O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO2JhY2tncm91bmQ6 dHJhbnNwYXJlbnQ7Zm9udC1mYW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1h cHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90 byxPeHlnZW4tU2FucyxVYnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 LEFyaWFsLHNhbnMtc2VyaWY7Zm9udC13ZWlnaHQ6NjAwIiBjbGFzcz0iIj48Zm9udCBzaXplPSIy IiBjbGFzcz0iIj5DT05GSURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRp b24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7 IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeQ0KIHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh bmsgeW91LjwvZm9udD48L3NwYW4+PC9pPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcg bGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5F376EBC866B4E06AEA90FFCB3625074mitedu_-- From nobody Thu Oct 10 13:41:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6A120125 for ; Thu, 10 Oct 2019 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4HLqUBFzJze for ; Thu, 10 Oct 2019 13:41:18 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BD9120127 for ; Thu, 10 Oct 2019 13:41:02 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id y19so9460039wrd.3 for ; Thu, 10 Oct 2019 13:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=hrgBKCnpZ49w4KcS42TagE0RvfVmbxY0b0LUSKBO1Ac=; b=LwTMqOJ3j1GH5Etfepc8Cx6RQCDwq9LaZGl6WrtmA2p30va1DN6NvIGocktEo3Poyj 2UAio1d/vilceSz31ZGUS6aONXirFL/AWEFaV5bAaMPi4cFnr2R5reh7wzhO3sl8a0v6 cDQDDDwyj/ivf54LlAGmrCOTrbivZ1D1z51/sPWPFSqPdLHXho7PDFbK4U9/AbeWTTzk Xg6qZrTKvZSwCux2vCpTJCivrVaXm6sDr3XW2JjiKC/kGEDV15lO/C/Vbnqu/1bWwGtI UB1P8JQPbbdzXTKDVDn0vz9/qN0TEOeFJFnhbR6hSE0OCr2O5SuniwNnYE6Q4kyNTmbR i2Yg== 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:date :subject:message-id:cc:to; bh=hrgBKCnpZ49w4KcS42TagE0RvfVmbxY0b0LUSKBO1Ac=; b=eIlQ4yvO3qKr4wAsK+V1hstudRucO1cPDJ+chbWq16ReZhF2odRjUfsOQ+cp4WmCv9 O6jSO2LNDsxPsXWp4cezhr5LSmr0zkand+HRqUzCuygC5Vjz4sQDWZj+QoVvFNuJH70X AnT+XnJ2loCORNdXZZ1PRFq54j1lZaUTDMXlNgzwI+EZR/1fj119JXgt3xOLZ61fRnjP UDXWqb+I+4CQwFWnoxCjjateFHhdSvNpPMgS/2/B9ABqs/OutPLIh6nfuo4TnSq26n4E RcQQ95I/yQArNAqVTqdbzKRkrnKmRxXYa3SNwylqb37KxSeWc9NtHklBGcT2ozH+3s4D fiuQ== X-Gm-Message-State: APjAAAUZOIq36aEYRBqM0sxWRau6E7ijXZSM2R0hUGg/SBxQZOtv1AdL SfNFchYoxzf8karEwbNuSQ== X-Google-Smtp-Source: APXvYqzVanDnYnbTeMO73ANUmmvgYozbQXc8D/regMCDXNobMwCA3QojgkPRNorjIXpzVLbMWeZ8vA== X-Received: by 2002:adf:a516:: with SMTP id i22mr10859126wrb.273.1570740060985; Thu, 10 Oct 2019 13:41:00 -0700 (PDT) Received: from [192.168.0.199] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id y14sm10048416wrd.84.2019.10.10.13.40.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Oct 2019 13:40:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Thu, 10 Oct 2019 22:40:58 +0200 Message-Id: Cc: Brian Campbell , oauth To: Justin Richer X-Mailer: iPhone Mail (17A860) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 20:41:20 -0000 That=E2=80=99s already kind of dealt with in JWE by having claims required f= or decryption duplicated in the JWE header. Odesl=C3=A1no z iPhonu > 10. 10. 2019 v 19:01, Justin Richer : >=20 From nobody Thu Oct 10 23:17:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833541200CD for ; Thu, 10 Oct 2019 23:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrFGOPedjSg8 for ; Thu, 10 Oct 2019 23:17:22 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (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 51596120091 for ; Thu, 10 Oct 2019 23:17:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XOnR++IOC8jkl3o0ppKW9zCWk3WAKHx9Yz7agISBwV/aAKBmxM03YgdOYCSqnWTgNIXthEqv1PV9xwryvRNJL5Ov8B7L9UnMvKmG5nd4sdo+ldEFT0V10b42ERYF2lKKJhx4+m85n3MhLsID5DUNmRfx6mKtyq/gHHJSrf/5tPncUhdaVjVyha0kuIcfhQkqN5YicpAvsQngh+g35BvGJO8fA2Ci0DDa0o4s1wCgmzxBK+AblX3ILBo6jvFzRY9fqo5NHwkrNoprpldxJhnnpVFYmOCb5JBRhmlcqoOmCJ9UHsbEP7pVn60wj/4hpW3JWWYuVc2bCrVRGmW0yn3yDQ== 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=Lg04PQ+0AasZkr851Mafw2nC+h74rBDSWeWzgEFdWJ0=; b=ZuJqmbaDAKvOJ+HAY1kIlht8XlrP0prmxwCnNRqgsvuKpwfBChoL8A3zyHUTniCyIcC6BZaDN6jcaUdysByTa0U68LpS1bFP218EFm7KSSEj5jEa55eNU9fDwmBwgv5KOGLiWxhmVw3E5dv2ZgCD/Z1p6by0NIlxiL7ysw8tc7nNJBSJabxO+0Btu/qKIkDXN71FMhCz3rA8w+w3xgss/k8beOdq7BjtcZk9/8wDiwq8hQDpDnZTYHH3yfLiT6upK3yd4QG4n1i6igJFDckDq7CY7KGENwFVi0LsOe0LoXCPDX5LYuuuOPzBQ1IrD3ECPkRr10Pdg0GQztAEsX3DUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lg04PQ+0AasZkr851Mafw2nC+h74rBDSWeWzgEFdWJ0=; b=lWPMsl+plGLhlTWuqVE2lEjWXWTUZdr5vAAR9o038IqQ9HiuVTBSIkxLHIa3j/G/BndrrNQ+vF1oFxx3DHz7iCrGt0iEzVXZtEQyRY1Ed0d87tn+keBBVk6Wb0RmZOp0C8zb/wNBW1mcZwmQloO/Su7q018mFPKMvxkoim6ELMw= Received: from HE1P18901CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::20) by VI1P18901MB0128.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Fri, 11 Oct 2019 06:17:18 +0000 Received: from HE1EUR02FT049.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::201) by HE1P18901CA0010.outlook.office365.com (2603:10a6:3:8b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Fri, 11 Oct 2019 06:17:18 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT049.mail.protection.outlook.com (10.152.11.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2347.16 via Frontend Transport; Fri, 11 Oct 2019 06:17:18 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Fri, 11 Oct 2019 08:17:17 +0200 To: Justin Richer CC: "oauth@ietf.org" References: <08fd478d-233b-25e8-cb53-e2546596c329@ri.se> From: Ludwig Seitz Message-ID: <16a411cd-c50a-1827-cfef-82b53cc7101e@ri.se> Date: Fri, 11 Oct 2019 08:17:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010103000600050408090202" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(39860400002)(396003)(199004)(189003)(51444003)(33964004)(235185007)(53546011)(5000100001)(386003)(16576012)(106002)(16586007)(22756006)(6666004)(40036005)(356004)(36756003)(58126008)(76176011)(305945005)(2906002)(316002)(6916009)(2171002)(478600001)(229853002)(7736002)(446003)(11346002)(2616005)(486006)(6246003)(8676002)(8936002)(65956001)(44832011)(6116002)(81156014)(81166006)(71190400001)(3846002)(16526019)(70206006)(26005)(65806001)(70586007)(14444005)(5024004)(186003)(31696002)(5660300002)(4326008)(31686004)(336012)(86362001)(126002)(568964002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0128; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fbaa3ec0-1ede-48d8-7a8d-08d74e12ab02 X-MS-TrafficTypeDiagnostic: VI1P18901MB0128: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-Forefront-PRVS: 0187F3EA14 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CMboh6hVo4e462PfEr6Ah7zKG+ENrJlU8pJPBRODDcz/992x/a7bMn1awQeod9LOuenlryqKg5prQ5yozkFNb2/tVngmrV92m1nyPlDqEpqBwnBSWyLVuLBWFDulo1fVeMkQPo/choGHb0aBIamcBzrS8V07wWDk/GYTaP4ytTXyHGMgeoqeBknmSc7VS+Iz1HP+QKj5xvVmsk+8TTws2uFr/qBp5Jky/pv/WcVgUDDH7oi5NIcj6CGjGWYDSPHCZI5cyCdivgfMaEB1v+wmmot1mQ6po4EzCPjq0YEfsq463+vHvdUpSUvNhke/GKdRTEkUo7r1SNyTpEJmsf1d9qNImH//8HGtGMPPvZt5p0e5ZvUGkL+6TumRDCEfkMTbwjArmfIWaBUOBo1kAZwLM4bd6ons+l3w97CSEezfavQ= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2019 06:17:18.0968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fbaa3ec0-1ede-48d8-7a8d-08d74e12ab02 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0128 Archived-At: Subject: Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2? X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Oct 2019 06:17:26 -0000 --------------ms010103000600050408090202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/10/2019 17:02, Justin Richer wrote: > They are in that registry as the =E2=80=9Ctoken endpoint response=E2=80= =9D error codes.=20 > RFC8628 adds new ones. >=20 > I think that 6749 failed to put in the base ones. >=20 > =E2=80=94 Justin That would explain my confusion. Errata-worthy? /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms010103000600050408090202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAxMTA2 MTcwOFowLwYJKoZIhvcNAQkEMSIEIEk27zFqbGDgNaqeJr9g5IfZOZqBOcmUWXBAJHqGsy1K MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAQusy1xSKM/jx7ZiTxCtLXK60EghHm73Tg9xCsG73TB4B ofQmc+8TrrVHW351t23PeOdmj1czrdCKCzJloZ0IEd+LFy5FpTp7vbACm1SaiF4dykMZOo/Q niBEXWxDw1s1KVNqNrM27CxIsHVNXyzEIP5uALahHTjNn3sE+Yjv+wqc4RpAT37xdHSwROit /CiYRo2MeHFC/Y2bD1xb8+yiCTmPJ3vd6APOQhL3oEKapiRz4B7Q7xvUmT2gBdSFSoTwiYm4 p3eNhzGFg4gUVVjNRBY01QWKKiHBUR3RLv6g5Xjt/16WmW7MsIEBlQmFAQajc6QvHoma7Gx4 AlJCwbmzBwAAAAAAAA== --------------ms010103000600050408090202-- From nobody Fri Oct 11 00:13:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC431200F7 for ; Fri, 11 Oct 2019 00:13:16 -0700 (PDT) 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 DqcJWKzigtUA for ; Fri, 11 Oct 2019 00:13:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBC312008B for ; Fri, 11 Oct 2019 00:13:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 861CDB80C94; Fri, 11 Oct 2019 00:13:04 -0700 (PDT) To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ludwig.seitz@ri.se, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191011071304.861CDB80C94@rfc-editor.org> Date: Fri, 11 Oct 2019 00:13:04 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5873) X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Oct 2019 07:13:16 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5873 -------------------------------------- Type: Technical Reported by: Ludwig Seitz Section: 11.4 Original Text ------------- Corrected Text -------------- 11.4.2 Initial Registry Contents The OAuth Extensions Error registry's initial contents are: o Error name: invalid_request o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unauthorized_client o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: access_denied o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unsupported_response_type o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_scope o Error usage location: authorization code grant error response, implicit grant error response, token error response o Related protocol extension: authorization code grant, implicit grant, any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: server_error o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit grant o Change controller: IETF o Specification document(s): RFC 6749 o Error name: temporarily_unavailable o Error usage location: authorization code grant error response, implicit grant error response o Related protocol extension: authorization code grant, implicit granto Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_client o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: invalid_grant o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749 o Error name: unsupported_grant_type o Error usage location: token error response o Related protocol extension: any access token type o Change controller: IETF o Specification document(s): RFC 6749 Notes ----- It seems that the values specified in sections 4.1.2.1.,4.2.2.1. and 5.2. should have been added to the registry but were forgotten. This errata suggests "any access token type" for "Related protocol extension" for the error codes of 5.2 since they seem to apply to any errors returned from the token endpoint, no matter which access token type is involved. 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. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Oct 11 07:45:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276A4120073 for ; Fri, 11 Oct 2019 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=fbk-eu.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 uqyuKyBgZkiQ for ; Fri, 11 Oct 2019 07:44:58 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A9E120052 for ; Fri, 11 Oct 2019 07:44:58 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id x4so5164792qkx.5 for ; Fri, 11 Oct 2019 07:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fbk-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ahi6R9Y2FNO4EdUxAoX9yYooCS65HhID9m0X1/owdcU=; b=hKkBIbtpLuLJ3CaaoOxhFtF/69/9ahP/uJgG74mvXf+D0DBLudK5g51SZwriKI89gG DTbZzi5PScD7XspPFJMLuiQYBAL2NldCoRZoZDzBHwD3iXWcpxAHkBcptQtjlVmfWnto VkzeBIFxa1dx9wC/Y6HpS4NsZFkCuT9VuJu/2JI0C7pWl+Z0zWCm9E9zs1VnoA6Gx/VZ BG6IUUpLqK2gLmf9RBF/iJ0MyfuyB8TWD1aif6N94Fsm8GD3B8elvoQrlnVu7fOXFPKS FsUPfP1FOQ2iMVzXOrGmIM5na2v2MJX10/k44B9T+VoDYnIo/sTmAJWSnj6dWIP0yLBh YyZg== 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=ahi6R9Y2FNO4EdUxAoX9yYooCS65HhID9m0X1/owdcU=; b=X5ruqfL+oQvnSDnEUMAS6r5baNmqg1l1pYOBVlbIceTeGblaJtD25Pb9l4+e13wk1v o15rah/fvmSBn18lSaT5lcskYMaer/KSl2XCBImefpJ0alJarVNcoZ52dokTWjEo0L5u FC1HfheyzfyMzma6/eVna1moFlwPcu/lv2qhiE8MloyocJD/wui2N+ORYRSlDyxxqEak UEmf1KP2thMAtN0fpr/hSnoLSR8zwn59Np15DNLDOB1efc4WqVgOm1WKmkgXiGIS4q9B z6goCZ0KN4X3D+axyPZINqsNKdZKpQFiMWEsnhYWJ2hgGG231Y1bW4s7BWACoq4bYJ6O 9HpA== X-Gm-Message-State: APjAAAXYm6wLB5Hzd7JK8xxIqWUjqIODrOICvJttgdAV3H3noRdpRn4/ rsi1670bCR4fb4lok9L8aSZre4wtMpKLEVhypeva5ZfJlBgMkn4bb75S1te8u5+bXViQ5YEbT6J 1RqJyoJL68oowdaQXwg== X-Google-Smtp-Source: APXvYqxK8lPzRK698ln8OkDafnEwQwo0OhmoD2z99jPEIeC2bU6WRrMDqibaj1gxM410JsRwy/jfEgOiu3i82l1pzUA= X-Received: by 2002:a05:620a:785:: with SMTP id 5mr16128174qka.114.1570805097022; Fri, 11 Oct 2019 07:44:57 -0700 (PDT) MIME-Version: 1.0 From: Giada Sciarretta Date: Fri, 11 Oct 2019 16:44:45 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1e0f40594a38f7c" Archived-At: Subject: [OAUTH-WG] embedded UA detection X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Oct 2019 14:45:02 -0000 --000000000000d1e0f40594a38f7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, We are working on a project that involves mobile native applications. The OAuth for native apps (RFC8252) spec "requires that native apps MUST NOT use embedded user-agents to perform authorization requests and allows that authorization endpoints MAY take steps to detect and block authorization requests in embedded user-agents". We would like to integrate in our AS the state-of-the-art techniques for detecting and blocking authorization requests in embedded user-agents. We are aware of the following techniques (link ): - doing a string checking on the User agent string value. In the chromium based-WebView - in the older versions it adds the =E2=80=9CVersion/X.X=E2=80=9D str= ing into the UA field. For example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 - in the newer version it will add, =E2=80=9C;wv=E2=80=9D. For exampl= e: Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36 - checking the presence of X-Requested-With HTTP header, the value of this header will be the application's name that is running the webview. but we know that these detection methods can be bypassed by an attacker. Do you have any suggestions in this regard? Thank you in advance for your response. Kind regards, Giada Sciarretta --=20 -- Le informazioni contenute nella presente comunicazione sono di natura=C2=A0 privata e come tali sono da considerarsi riservate ed indirizzate=C2=A0 esclusivamente ai destinatari indicati e per le finalit=C3=A0 strettamente= =C2=A0 legate al relativo contenuto. Se avete ricevuto questo messaggio per=C2=A0 errore, vi preghiamo di eliminarlo e di inviare una comunicazione=C2=A0 all=E2=80=99indirizzo e-mail del mittente. -- The information transmitted is=20 intended only for the person or entity to which it is addressed and may=20 contain confidential and/or privileged material. If you received this in=20 error, please contact the sender and delete the material. --000000000000d1e0f40594a38f7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Hello,

=C2=A0

We are working on a project that involves mobile native applications.

=C2=A0

The OAuth for native apps (RFC8252) spec "requires that native apps MUST NOT use embedded user-agents=C2=A0 to perform authorization requests and allows that authorization endpoints MAY take steps to detect and block authorization requests=C2=A0 i= n embedded user-agents".

=C2=A0

We would like to integrate in our AS the state-of-the-art techniques for detecting and block= ing authorization requests in embedded user-agents. We are aware of the followi= ng techniques (link):

  • doing a string check= ing on the User agent string value. In the chromium based-WebView
    • =
    • in the olde= r versions it adds the =E2=80=9CVersion/X.X=E2=80=9D string into the UA field. For = example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/5= 33.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • in the newer version it will add, =E2=80=9C;wv=E2=80=9D. For example: Mozilla/5.0 (Linux; Android = 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
  • checking the presence of X-Requested-With HTTP header, the value of this header will be the application's name that is running the webview.

=C2=A0

but we know that these detection methods can be bypassed by an attacker. Do you have any sug= gestions in this regard?

=C2=A0

Tha= nk you in advance for your response.

=C2= =A0

Kin= d regards,

Gia= da Sciarretta

=C2=A0

<= /div>
--
Le informazioni contenute nell= a presente comunicazione sono di natura=C2=A0privata e come tali sono da considerarsi ri= servate ed indirizzate=C2=A0esclusivamente ai destinatari indicati e per le finalit=C3= =A0 strettamente=C2=A0legate al relativo contenuto. Se avete ricevuto questo messaggio p= er=C2=A0error= e, vi preghiamo di eliminarlo e di inviare una comunicazione=C2=A0all=E2=80=99indirizzo = e-mail del mittente.
--
The information transmitted is intended only for the pers= on or entity to which it is addressed and may contain confidential and/or p= rivileged material. If you received this in error, please contact the sende= r and delete the material.
--000000000000d1e0f40594a38f7c-- From nobody Fri Oct 11 09:33:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A79120018 for ; Fri, 11 Oct 2019 09:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=fbk-eu.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 PzWFClmb7p12 for ; Fri, 11 Oct 2019 09:33:52 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C633120013 for ; Fri, 11 Oct 2019 09:33:52 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id a22so10477028ljd.0 for ; Fri, 11 Oct 2019 09:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fbk-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ozu1XQ19VmMFtKhc9k7LUR+fDtsQ9A1+nzrWikV6jzs=; b=0erd6/nZnjJJ22aWVlYoQnKznAeRg0P6+cXT8mupum32aPYhtcZWXGDJ5pqgYzDnsx A1kud6CY1Uvd0IhLp4549FW+LiwAeUTDzQniLYIbtZkHfc9lV5OpS7HOxbwYviqgZXI+ UM4RCepBM5B36tSg6vmhNal5TcaguYm3nAj8zOyVHBpZZ+ceG7wocUKLFAForfCf5zGQ SJ+JFMC7a8zTebdg+pGb9EE+1vWKgwmv+RbREsWKB6bM3kapV+s4dsyuAT1YbYJv0zAt MbGZbcHtLWWDDHp8UrEQnOu64K7+U+mSrefzndNFKK8vbeJE+8CfRDugj1NGFVCRlROy Pmrw== 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=ozu1XQ19VmMFtKhc9k7LUR+fDtsQ9A1+nzrWikV6jzs=; b=E4xfgURBSHxrUbPRaEpY18jxUXTSCP+22Lp2v7T2limc7XHk9gp6+BnvCpNCo98cGW 3jAQbawEGP3rnmxXf9y/l3w6QWsbgI4rOArp3m6Aj7+8+ra+DFRmLYkWnpQGQc1US/4p qbuVpQrpV3XB+vnRBoP0+JDx5kTZzD1Vm3i8U/yd+PtkwnYgikH3RlrZtDNt34cSPC/h VrVXizC26b7aqaLVwedN+/msOREwdXyHofs4SqCkwq0M9veHpcOOFMY/3oFIZsf1wzQD BimVDawFP059mWA4ydHucvNarFRbiv2AwiQWlxNloTZVU5sDrZerR2uCyLh1YWa3P2wN wfkw== X-Gm-Message-State: APjAAAVtP7TK0/x7Y/HeXyymy7tAbwB5cwsAeAhvtSI9oj9p9mZuSJUf Yh2lM3RCmwCbV9fudVm/vZa5viOWzGr1r6RDV2MjnhLbJcHuFah55u2AH2z1fJNNrbCHsrjtxMO 7C7Rd1dM5oIFxTTHKVEgm X-Google-Smtp-Source: APXvYqzgIimSqNAM+vjBiE6DgVmbOxqWjeSx33mRqEklWJos38iuInOpfFPDEsEoiR76hDJmb8lrlnHWM2P9Ky0zhJs= X-Received: by 2002:a2e:b053:: with SMTP id d19mr10064675ljl.143.1570811630206; Fri, 11 Oct 2019 09:33:50 -0700 (PDT) MIME-Version: 1.0 From: Amir Sharif Date: Fri, 11 Oct 2019 18:33:39 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000003a59240594a51534" Archived-At: Subject: [OAUTH-WG] iGov Implementation X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Oct 2019 16:33:55 -0000 --0000000000003a59240594a51534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I have a question with regard to the OpenID connect iGov profile. I would like to know whether there is any SDK that supports iGov for Android mobile Apps or I have to use the AppAuth library and make some changes to make it compatible. Indeed, I found the AppAuth library (at the following link ) supporting iGov profile for ios, but the android version is not provided. Thank you in advance for your help. Best regards Amir Sharif --=20 -- Le informazioni contenute nella presente comunicazione sono di natura=C2=A0 privata e come tali sono da considerarsi riservate ed indirizzate=C2=A0 esclusivamente ai destinatari indicati e per le finalit=C3=A0 strettamente= =C2=A0 legate al relativo contenuto. Se avete ricevuto questo messaggio per=C2=A0 errore, vi preghiamo di eliminarlo e di inviare una comunicazione=C2=A0 all=E2=80=99indirizzo e-mail del mittente. -- The information transmitted is=20 intended only for the person or entity to which it is addressed and may=20 contain confidential and/or privileged material. If you received this in=20 error, please contact the sender and delete the material. --0000000000003a59240594a51534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

I have a question with reg= ard to the OpenID connect iGov profile. I would like to know whether there = is=C2=A0any SDK that supports iGov for Android mobile Apps or I have to use= the AppAuth library and make some changes to make it compatible. Indeed, I= found the AppAuth library (at the following link) supporting iGov profile for ios, but the a= ndroid version is not provided.=C2=A0

Thank you in= =C2=A0advance for your help.=C2=A0

Best regards

Amir Sharif


=C2=A0=C2=A0

--
Le informazioni contenute nell= a presente comunicazione sono di natura=C2=A0privata e come tali sono da considerarsi ri= servate ed indirizzate=C2=A0esclusivamente ai destinatari indicati e per le finalit=C3= =A0 strettamente=C2=A0legate al relativo contenuto. Se avete ricevuto questo messaggio p= er=C2=A0error= e, vi preghiamo di eliminarlo e di inviare una comunicazione=C2=A0all=E2=80=99indirizzo = e-mail del mittente.
--
The information transmitted is intended only for the pers= on or entity to which it is addressed and may contain confidential and/or p= rivileged material. If you received this in error, please contact the sende= r and delete the material.
--0000000000003a59240594a51534-- From nobody Sun Oct 13 07:03:08 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6654120033; Sun, 13 Oct 2019 07:02:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <157097537879.20900.13204180726421645375@ietfa.amsl.com> Date: Sun, 13 Oct 2019 07:02:58 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 14:03:00 -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 : JSON Web Token Best Current Practices Authors : Yaron Sheffer Dick Hardt Michael B. Jones Filename : draft-ietf-oauth-jwt-bcp-07.txt Pages : 16 Date : 2019-10-13 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 13 07:59:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56512004A for ; Sun, 13 Oct 2019 07:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, 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 7NdV9mI8PXGs for ; Sun, 13 Oct 2019 07:59:35 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BEF12000F for ; Sun, 13 Oct 2019 07:59:34 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id o18so16736251wrv.13 for ; Sun, 13 Oct 2019 07:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=4pGmkbh0+DeS1q40Dv32GRtVUqK0myJUxjoDkCaoYsE=; b=lFfjsXJXiBzQziBbCwM4R1fBhXO8vDhV3UXqYPdsAK2uEZTUy/7N3fQAeD/d1afyEC QqTeiYVdhAXJoxDU6JSu8u1T0O7tuycd6hxHis3fF4miEpzs1fHe5qFEuwDP3tVJSEql GUlAzlkCEsw/986K2yMjhhou2UqkIW6GNQuWZ85XTxCmawXsip6+tTeNjgd0pz/RowvO WAI6Gy1U3T0Z+jw94EE7/+tw1SFjMdocwbmCrOfbB7SLizMTbzDre9pvU8IUpJACgD+F KgTeNRQAK/35IQWJgqs8MOeTcBFoK8oZmNKvvT8sPLbNcEifeWL7KO6nQTJjMEuDPHHV tgzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=4pGmkbh0+DeS1q40Dv32GRtVUqK0myJUxjoDkCaoYsE=; b=gIAhSSKYB9HlyVPmxyChfFIVbOb2yyAqMdNKvuk0h8h4ZWezMESD76Iz/hTRH9Z73m q85MOMoMEOL2orRAkj1dcLsDFBlcjA04one8Ua+a8Zpi/MWOrbN8m8FBPFfHFD0Sbe8h p1L6TKh62wYZXi5mGIWIKcGK7VFpiYktUz5nF2mYnx7uf+sucVOjmm7myXBFdOhLDssj 4wNSTD1vX18Z+hpaViF7vG60Z33dYptpL31NpePqTZP6DlRurJpZlykcz7RN0zZveda9 d9irRyIY0/B3DgDSulAD8pkln428fsS2nvhbF0s49wQlg+kE9ISSO+aOBsUygt4f64Zg JbQw== X-Gm-Message-State: APjAAAXaUYIM7xldEkoRO6XEHWCNhfoL/GOU6g+SaVLlb3IzNjlnzjkY vu/7wK78ydm49o558h04HRuXCRja X-Google-Smtp-Source: APXvYqwRpyWHoLjGgWFS4GVQ+xf1IiWXuBNx4xALlqCHB+WwPsY9HhWhe6eCxST+58SwQF3Q7O/xFQ== X-Received: by 2002:a5d:67c5:: with SMTP id n5mr18117819wrw.72.1570978773195; Sun, 13 Oct 2019 07:59:33 -0700 (PDT) Received: from [10.0.0.147] (bzq-79-182-74-87.red.bezeqint.net. [79.182.74.87]) by smtp.gmail.com with ESMTPSA id t13sm34925239wra.70.2019.10.13.07.59.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Oct 2019 07:59:32 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.1d.0.190908 Date: Sun, 13 Oct 2019 17:59:31 +0300 From: Yaron Sheffer To: oauth Message-ID: <2969219C-1F0D-4AD5-9CE4-A15E91065284@gmail.com> Thread-Topic: New Version Notification for draft-ietf-oauth-jwt-bcp-07.txt References: <157097537922.20900.9964280625544036041.idtracker@ietfa.amsl.com> In-Reply-To: <157097537922.20900.9964280625544036041.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-jwt-bcp-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 14:59:37 -0000 This should address all IESG review comments, including Ben's Discuss. We w= ill follow with detailed responses to the reviewers. Thanks, Yaron =EF=BB=BFOn 13/10/2019, 17:02, "internet-drafts@ietf.org" wrote: =20 A new version of I-D, draft-ietf-oauth-jwt-bcp-07.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. =20 Name: draft-ietf-oauth-jwt-bcp Revision: 07 Title: JSON Web Token Best Current Practices Document date: 2019-10-13 Group: oauth Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-j= wt-bcp-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-b= cp/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-= jwt-bcp Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-= bcp-07 =20 Abstract: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based securit= y tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both i= n the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionabl= e guidance leading to secure implementation and deployment of JWTs. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 From nobody Sun Oct 13 09:50:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF912004A; Sun, 13 Oct 2019 09:50:57 -0700 (PDT) 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, MALFORMED_FREEMAIL=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=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 ooqY4jvJr-wq; Sun, 13 Oct 2019 09:50:55 -0700 (PDT) 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 B166612000F; Sun, 13 Oct 2019 09:50:54 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id a6so14785771wma.5; Sun, 13 Oct 2019 09:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=zyjTqbDYJGc/F1yxVaT2OBn7PyXF9q1u6RihIktqgaQ=; b=MDNWnr9/rCuisJ66pKBAIQIctIozd7f8tEgnVthXAnxiVIndMxZXYpqzPl7GPYucVx ie14G/BshCKWueyxXz/JzEeOTaUX+OzlwPn+bFv3EuBIcyBM+fW/c7NgGzISkNrZfA5g c39LV+R6AretmEiwQyYyDTaRQuNJeCmYTeXR/qesMB5YRiM5AJVw/CTr8M/v9D6N1yuY WjAEnPZNH2RY+4GUvkHEyLsZcriLC28sL1pKgGHiH9gt+mQOEkx46HIgPq9csWHeuWjj nOTnU6A5M0o6zHD72obAyP8VMdcKTRlxx52HXtjWczd3mDrdgRTk1T2r1AGS7nDAdSfP 4lgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=zyjTqbDYJGc/F1yxVaT2OBn7PyXF9q1u6RihIktqgaQ=; b=j/lq/bVoQXReizF1yfM6UIQi4IzNgH1V85jPnIFN6+I/lSzYYX2I+bx1RGKAqIg6v/ ucOpyeLXJ08EzF/alpPwunsYA64L4FupBtOkAZEhq1N9ie++YnOo7CkSJ4XYP5tlLaaB 0MeQP8CDnWwH6+W/Z2a5+f+x7emRpMszSgEHmwU0nbtrCaxvam8qOBxlelwaaDtpfxZA N68IvqTzaKb7z+4aFeVUKWWEqxkSFWi0yjAt7eLFPUflXvh42ezNVE9KK2C03SYotDs9 TAm8f0SiHp2/AUMik+5Fl8lLoHfnRuXRJLEi/295y1/o3K5xu1oEXzP6Rcbg6DKSKG8a XUog== X-Gm-Message-State: APjAAAXnmMPSlwR3E8BJS6GfeqIzQQpJEKiGLFoty5Gyl80fXderDbd+ h8JrQnvB+w3Anfwtzj7vwX0= X-Google-Smtp-Source: APXvYqzaAe6kUYpjG6PgJNP0UAP8xiAtWC5Xli3R/8BoM7ZLLP038c3nzCgQ7dPkbKSsdmC6vFOh8w== X-Received: by 2002:a05:600c:34b:: with SMTP id u11mr11960964wmd.176.1570985453029; Sun, 13 Oct 2019 09:50:53 -0700 (PDT) Received: from [10.0.0.147] (bzq-79-182-74-87.red.bezeqint.net. [79.182.74.87]) by smtp.gmail.com with ESMTPSA id 79sm24909290wmb.7.2019.10.13.09.50.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Oct 2019 09:50:52 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.1d.0.190908 Date: Sun, 13 Oct 2019 19:50:50 +0300 From: Yaron Sheffer To: Benjamin Kaduk , The IESG CC: , Hannes Tschofenig , , Message-ID: <1E4BB923-8254-4DAB-ABF2-118946077304@gmail.com> Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT) References: <156141841569.17730.5307482163620594441.idtracker@ietfa.amsl.com> In-Reply-To: <156141841569.17730.5307482163620594441.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (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: Sun, 13 Oct 2019 16:50:58 -0000 Hi Ben, Sorry the responding to you retroactively (and with such delay). As you can= imagine, most of the changes in the latest version are related to your revi= ew. See below for detailed comments. Thanks, Yaron =EF=BB=BFOn 25/06/2019, 2:20, "Benjamin Kaduk via Datatracker" = wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Discuss =20 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.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 Thank you for assembling this document; it will be very valuable to the community. I intend to ballot Yes once the following items are resolved: =20 Section 2.6 notes: Previous versions of the JSON format such as the obsoleted [RFC7159] allowed several different character encodings: UTF-8, UTF-16 and UTF= - 32. This is not the case anymore, with the latest standard [RFC8259= ] only allowing UTF-8. [...] =20 The actual situation is a bit more subtle than this text makes it seem; interoperable JSON can only use non-UTF-8 with explicit mutual prearrangement in a closed ecosystem. So, while this statement is true for Internet JWT usage, it may not be true for *all* JWT usage. (I do see that in Section 3.7 of this document we do mandate UTF-8 for JWT, which makes things unambiguous, even if this text here is not correct.) Fixed. =20 Section 3.2 notes: JWT libraries SHOULD NOT generate JWTs using "none" unless explicitl= y requested to do by the caller. =20 I couldn't find anywhere where we have matching guidance about "SHOULD NOT consume JWTs using 'none' unless explicitly requested"; this seems important enough to get called out explicitly. Fixed. =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 I also have some non-Discuss-level substantive comments in the section-= by-section notes, in addition to the usual editorial nits. =20 Section 1 =20 and/or encrypted. The JWT specification has seen rapid adoption because it encapsulates security-relevant information in one, easy t= o protect location, and because it is easy to implement using widely- =20 nit: "one easy-to-protect location". OK =20 Section 2.2 =20 I'd consider rewording the text here to make it more poignant; perhaps: =20 In addition, some applications use a keyed MAC algorithm such as "HS256" to sign tokens, but supply a weak symmetric key with insufficient entropy (such as a human memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an attacker possesses such a token. OK =20 Section 2.4 =20 I'd suggest noting that the compression attacks are particularly powerful when there is attacker-controlled data in the same compression space as secret data. OK =20 Section 3.2 =20 Therefore, applications MUST only allow the use of cryptographically current algorithms that meet the security requirements of the application. This set will vary over time as new algorithms are introduced and existing algorithms are deprecated due to discovered cryptographic weaknesses. Applications MUST therefore be designed t= o enable cryptographic agility. =20 This seems to have high overlap with BCP 201; a reference is probably i= n order. Since the JWT format itself enables crypto agility, we decided that a furth= er reference to BCP 201 would not add clarity. =20 Section 3.4 =20 Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agreement ("ECDH-ES") take inputs that may contain invalid values, such as points not on the specified elliptic curve or other invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE library itself must validate these inputs before using them or it must use underlying cryptographic libraries that do so (or both!). =20 side note: A phrasing like "JWS/JWE libraries MUST ensure that such input validation occurs" would leave the same wiggle room for the validation to occur at the underlying crypto layer, while leaving it crystal clear what entity is responsible for ensuring that the checks occur". But since I don't expect a change of this nature to actually cause different behavior by implementors, I'm not very tied to it. Left unchanged. =20 Section 3.8 =20 When we say "[o]ther applications may use different means of binding keys to issuers", is there any value in noting that certification by a trusted authority is a common way to perform this binding (in some contexts)? We couldn't find related use cases in the JWT space, left the text as-is. =20 Section 3.9 =20 If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. Furthermore, the relying party or application MUST validate the audience value and if the audience value is not present or not associated with the recipient, it MUST reject the JWT= . =20 (grammar nit?) Is the "Furthermore" sentence supposed to still be scope= d to the case where the issuer can issue JWTs for more than one audience? If not, it seems like we're requiring the rejection of all "aud"-less JWTs but not requiring "aud" to be present when generating them. Clarified. =20 Section 3.10 =20 Applications should protect against such attacks, e.g., by matching the URL to a whitelist of allowed locations, and ensuring no cookies are sent in the GET request. =20 This could probably be a SHOULD (or even a MUST?). Went for a SHOULD. =20 Section 3.11 =20 When applying explicit typing to a Nested JWT, the "typ" header parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set). The same "typ" header parameter value MAY be present in the outer JWT as well, to explicitly type the entire Nested JWT. =20 This is an interesting recommendation, as it is in some sense *introducing* type confusion by using the same type name for JWTs with different structures (the inner and outer JWTs)! My sense is that it i= s not practical to change current usage, though, so I think this should b= e treated as a side note and not an actionable recommendation. We discussed it, agree with your assessment and reworded a bit, indeed as a= side-note. =20 Section 3.12 =20 - Use different keys for different kinds of JWTs. Then the keys used to validate one kind of JWT will fail to validate other kind= s of JWTs. =20 It might be worth calling back an analogy to RFC 8037's security considerations (where we advise to keep an association between key material and key algorithm), in effect extending the scope of "algorithm" to include application usage. We felt this would be more confusing than clarifying for our target audienc= e. =20 Given the broad diversity of JWT usage and applications, the best combination of types, required claims, values, header parameters, ke= y usages, and issuers to differentiate among different kinds of JWTs will, in general, be application specific. For new JWT applications= , the use of explicit typing is RECOMMENDED. =20 This last recommendation seems to duplicate one from the end of Section 3.11. While it's important and worth reiterating, we do usually try to avoiding using normative RFC 2119 language when repeating ourselves, to make it very clear which requirement is the binding one. Added a reference to 3.11 to clarify. =20 =20 =20 From nobody Sun Oct 13 20:58:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B743D12008F for ; Sun, 13 Oct 2019 20:58:38 -0700 (PDT) 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 dS8I6v1r8mwA for ; Sun, 13 Oct 2019 20:58:37 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3BD12001A for ; Sun, 13 Oct 2019 20:58:36 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9E3wWA8012565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Oct 2019 23:58:35 -0400 Date: Sun, 13 Oct 2019 20:58:32 -0700 From: Benjamin Kaduk To: Ludwig Seitz Cc: Justin Richer , "oauth@ietf.org" Message-ID: <20191014035832.GE61805@kduck.mit.edu> References: <08fd478d-233b-25e8-cb53-e2546596c329@ri.se> <16a411cd-c50a-1827-cfef-82b53cc7101e@ri.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16a411cd-c50a-1827-cfef-82b53cc7101e@ri.se> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2? X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Oct 2019 03:58:39 -0000 On Fri, Oct 11, 2019 at 08:17:07AM +0200, Ludwig Seitz wrote: > On 10/10/2019 17:02, Justin Richer wrote: > > They are in that registry as the “token endpoint response” error codes. > > RFC8628 adds new ones. > > > > I think that 6749 failed to put in the base ones. > > > > — Justin > > That would explain my confusion. > > Errata-worthy? I think it's not strictly necessary; we can just register the values using the Specification Required procedure (I sent mail to kick things off already: https://mailarchive.ietf.org/arch/msg/oauth-ext-review/4WaM6n6JetFsLI6_T9S8wNVqP74 -Ben From nobody Mon Oct 14 02:10:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB2120025 for ; Mon, 14 Oct 2019 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Dic9vZk63DeL for ; Mon, 14 Oct 2019 02:09:58 -0700 (PDT) Received: from mx.stet.eu (mx.stet.eu [85.233.205.208]) (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 4A4CB1200FF for ; Mon, 14 Oct 2019 02:09:57 -0700 (PDT) Received: from mail.stet.eu ([10.17.2.22]) by mx.stet.eu with ESMTP id x9E99tdV030914-x9E99tdX030914 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=CAFAIL); Mon, 14 Oct 2019 11:09:55 +0200 Received: from STEMES002.steteu.corp (10.17.2.22) by STEMES002.steteu.corp (10.17.2.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 11:09:54 +0200 Received: from STEMES002.steteu.corp ([::1]) by STEMES002.steteu.corp ([fe80::1c47:3ef0:f04e:a256%14]) with mapi id 15.00.1473.003; Mon, 14 Oct 2019 11:09:54 +0200 From: =?utf-8?B?Um9iYWNoZSBIZXJ2w6k=?= To: Travis Spencer CC: "oauth@ietf.org" , Mark Dobrinic Thread-Topic: [OAUTH-WG] Question regarding RFC 7592 Thread-Index: AdVuAgKteMknwUzTRQafucaFZ8aETAUbPCPg Date: Mon, 14 Oct 2019 09:09:54 +0000 Message-ID: <7f5b0068bcc74a21a00b578adb7fdbc3@STEMES002.steteu.corp> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.17.2.170] x-tm-as-product-ver: SMEX-12.5.0.1684-8.5.1010-24974.005 x-tm-as-result: No-29.711900-8.000000-10 x-tmase-matchedrid: mHCEnrG40p6eGXFpAoGIoe5i6weAmSDKqr0Np6cKdO5fQRiqw0gT4DcI a9gjeLdiWRv4gMq+CegHdptXFFME7wRytbWF0BphCgHQMFomsrRv+B0owAW3BpcDGDiTFmuGs03 PiUbxvvhR1tTDNqr8dVjZYFGVYSCavqDeDn7UX95DO9NSmfde1K6IBbSnfz+3CwWRLqiC/UqTvZ kBseIwt0mu4uFjBmMBf9krIFPI8jVu7xCoxCPC8oDcpVWyPxAMWw/S0HB7eoMwMfxyID/dnTRGW ZgDtiVIqFfaBbOImZGfQhSbnKRVoH9AG+WpDI5oIj0zFI5DoJLAtpDNMLs81qTsE8Z/jrr+6xul wEB2dGdaQN+9A7oQtKuCM8s//NPh6MXlf8pDjmVFM72aEhcbjZl/lu28zzkBPOKOd0uttLlj8Xz dqXhnXljObZLGdDchTwW1n+jptHH+TmbsPRhNL7zK9RGVgYIhGrSmht4ssAdW1jLbx3/rulVnDj aOMLuAu1M8Acf4eaQK22LlvS+nvvR3YoE94O3m8KGJCiV+3/L17lqbebntfaTEIOgFcjqDmvpO+ rpPHAI+ofczduaJpjrkB/ka/EmKb4fnpkHsS7ueAiCmPx4NwFkMvWAuahr8AQ2nhIcp8pyov4gz E3CFDp5xKu8owaw2278kU8dMGJfi2GwNWnOlsgKkgvnxqgcoftwZ3X11IV0= x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No x-tmase-result: 10--29.711900-8.000000 x-tmase-version: SMEX-12.5.0.1684-8.5.1010-24974.005 x-tm-snts-smtp: D8A14BC549B788FE089E3BBCC50A6DF53BC1AE999DDC15FF6182C2265E057BFA2000:9 Content-Type: multipart/alternative; boundary="_000_7f5b0068bcc74a21a00b578adb7fdbc3STEMES002steteucorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Oct 2019 09:10:01 -0000 --_000_7f5b0068bcc74a21a00b578adb7fdbc3STEMES002steteucorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwNCg0KVGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuIEkgdW5kZXJzdGFuZCB0aGF0IFJG Qzc1OTIvwqczIHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgZm9yIGVuaGFuY2luZyB0aGUg Q2xpZW50IEluZm9ybWF0aW9uIFJlc3BvbnNlIG9mIFJGQzc1OTEuDQoNCkJlc3QgcmVnYXJkcw0K DQpIZXJ2w6kNCg0KRGUgOiBUcmF2aXMgU3BlbmNlciBbbWFpbHRvOnRyYXZpcy5zcGVuY2VyQGN1 cml0eS5pb10NCkVudm95w6kgOiBtZXJjcmVkaSAxOCBzZXB0ZW1icmUgMjAxOSAxMDo1Ng0Kw4Ag OiBSb2JhY2hlIEhlcnbDqQ0KQ2MgOiBvYXV0aEBpZXRmLm9yZzsgTWFyayBEb2JyaW5pYw0KT2Jq ZXQgOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBSRkMgNzU5Mg0KDQpPbiBGcmksIFNl cCAxMywgMjAxOSBhdCAzOjE4IFBNIFRyYXZpcyBTcGVuY2VyIDx0cmF2aXMuc3BlbmNlckBjdXJp dHkuaW88bWFpbHRvOnRyYXZpcy5zcGVuY2VyQGN1cml0eS5pbz4+IHdyb3RlOg0KWWEsIHRoaXMg cGFydCBpcyBjb25mdXNpbmcuIEkgZGlkbid0IGdldCBpdCBhdCBmaXJzdCBlaXRoZXIuDQoNClNl ZW1zIEknbSBzdGlsbCBhIGJpdCBjb25mdXNlZCA7LSkNCg0KdGhpcyBtZXRhZGF0YSBpc24ndCBk ZWZpbmVkIGluIFJGQyA3NTkxIGJ1dCBkaXNjdXNzZWQgaW4gc2VjdGlvbiAxLjM7IHRoYXQgc3Bl YyBsZWF2ZXMgdGhlIG1ldGFkYXRhIG91dCBvZiBzY29wZS4gSXQgaXMsIGhvd2V2ZXIsIHByb2Zp bGVkIGluIHNlY3Rpb24gMy4yIG9mIE9JREMgRENSIChzZWUgcmVnaXN0cmF0aW9uX2FjY2Vzc190 b2tlbiBpbiBzZWN0aW9uIDMuMg0KDQpNYXJrIERvYnJpbmljIHBvaW50ZWQgb3V0IHRvIG1lIHRo aXMgbW9ybmluZyB0aGF0IFJGQyA3NTkxIChEQ1IpIGlzIHVwZGF0ZWQgYnkgNzU5MiAoRENSTSkg aW4gc2VjdGlvbiAzIHRvIGluY2x1ZGUgdGhlIHNhbWUgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tl biByZXNwb25zZSBtZXRhZGF0YSB0aGF0IE9JREMgZGVmaW5lcy4NCg0KDQpDZSBtZXNzYWdlIGV0 IHRvdXRlcyBsZXMgcGnDqGNlcyBqb2ludGVzIHNvbnQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24g ZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzIGV0IHNvbnQgY29uZmlkZW50aWVscy4NClNp IHZvdXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIgb3UgcydpbCBuZSB2b3VzIGVzdCBw YXMgZGVzdGluw6ksIG1lcmNpIGRlIGxlIGTDqXRydWlyZSBhaW5zaSBxdWUgdG91dGUgY29waWUg ZGUgdm90cmUgc3lzdMOobWUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lk aXRldXIuDQpUb3V0ZSBsZWN0dXJlIG5vbiBhdXRvcmlzw6llLCB0b3V0ZSB1dGlsaXNhdGlvbiBk ZSBjZSBtZXNzYWdlIHF1aSBuJ2VzdCBwYXMgY29uZm9ybWUgw6Agc2EgZGVzdGluYXRpb24sIHRv dXRlIGRpZmZ1c2lvbiBvdSB0b3V0ZSBwdWJsaWNhdGlvbiwgdG90YWxlIG91IHBhcnRpZWxsZSwg ZXN0IGludGVyZGl0ZS4NCkwnSW50ZXJuZXQgbmUgcGVybWV0dGFudCBwYXMgZCdhc3N1cmVyIGwn aW50w6lncml0w6kgZGUgY2UgbWVzc2FnZSDDqWxlY3Ryb25pcXVlIHN1c2NlcHRpYmxlIGQnYWx0 w6lyYXRpb24sIFNURVQgZMOpY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRl IGNlIG1lc3NhZ2UgZGFucyBsJ2h5cG90aMOoc2Ugb8O5IGlsIGF1cmFpdCDDqXTDqSBtb2RpZmnD qSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCk4naW1wcmltZXogY2UgbWVzc2FnZSBxdWUgc2kg bsOpY2Vzc2FpcmUsIHBlbnNleiDDoCBsJ2Vudmlyb25uZW1lbnQuDQoNClRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGludGVuZGVkIGFk ZHJlc3NlZXMgYW5kIGlzIGNvbmZpZGVudGlhbC4NCklmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2Fn ZSBpbiBlcnJvciwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLCBwbGVhc2Ug ZGVsZXRlIGl0IGFuZCBhbnkgY29waWVzIGZyb20geW91ciBzeXN0ZW1zIGFuZCBpbW1lZGlhdGVs eSBub3RpZnkgdGhlIHNlbmRlci4NCkFueSB1bmF1dGhvcml6ZWQgdmlldywgdXNlIHRoYXQgZG9l cyBub3QgY29tcGx5IHdpdGggaXRzIHB1cnBvc2UsIGRpc3NlbWluYXRpb24gb3IgZGlzY2xvc3Vy ZSwgZWl0aGVyIHdob2xlIG9yIHBhcnRpYWwsIGlzIHByb2hpYml0ZWQuDQpTaW5jZSB0aGUgaW50 ZXJuZXQgY2Fubm90IGd1YXJhbnRlZSB0aGUgaW50ZWdyaXR5IG9mIHRoaXMgbWVzc2FnZSB3aGlj aCBtYXkgbm90IGJlIHJlbGlhYmxlLCBTVEVUIHNoYWxsIG5vdCBiZSBsaWFibGUgZm9yIHRoZSBt ZXNzYWdlIGlmIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCkRvIG5vdCBwcmludCB0 aGlzIG1lc3NhZ2UgdW5sZXNzIGl0IGlzIG5lY2Vzc2FyeSwgcGxlYXNlIGNvbnNpZGVyIHRoZSBl bnZpcm9ubWVudC4NCg== --_000_7f5b0068bcc74a21a00b578adb7fdbc3STEMES002steteucorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1 cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuIEkgdW5kZXJzdGFuZCB0aGF0IFJGQzc1OTIvwqczIHNo b3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgZm9yIGVuaGFuY2luZyB0aGUgQ2xpZW50IEluZm9y bWF0aW9uIFJlc3BvbnNlIG9mIFJGQzc1OTEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I ZXJ2w6k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gVHJhdmlzIFNwZW5jZXIgW21haWx0bzp0cmF2aXMuc3BlbmNlckBjdXJpdHkuaW9d DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTggc2VwdGVtYnJlIDIwMTkg MTA6NTY8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IFJvYmFjaGUgSGVydsOpPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBvYXV0aEBpZXRmLm9yZzsgTWFyayBEb2JyaW5pYzxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gW09BVVRILVdHXSBRdWVzdGlvbiByZWdhcmRpbmcgUkZDIDc1OTI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIFNlcCAxMywgMjAxOSBhdCAzOjE4IFBN IFRyYXZpcyBTcGVuY2VyICZsdDs8YSBocmVmPSJtYWlsdG86dHJhdmlzLnNwZW5jZXJAY3VyaXR5 LmlvIj50cmF2aXMuc3BlbmNlckBjdXJpdHkuaW88L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ZYSwgdGhpcyBwYXJ0IGlzIGNvbmZ1c2luZy4gSSBkaWRuJ3QgZ2V0IGl0IGF0IGZpcnN0IGVp dGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWVtcyBJJ20gc3RpbGwgYSBiaXQgY29uZnVzZWQg Oy0pIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaXMgbWV0YWRhdGEgaXNuJ3QgZGVmaW5lZCBpbiBSRkMg NzU5MSBidXQgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMS4zOyB0aGF0IHNwZWMgbGVhdmVzIHRoZSBt ZXRhZGF0YSBvdXQgb2Ygc2NvcGUuIEl0IGlzLCBob3dldmVyLCBwcm9maWxlZCBpbiBzZWN0aW9u IDMuMiBvZiBPSURDIERDUiAoc2VlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4gaW4gc2VjdGlv biAzLjINCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcmsgRG9icmluaWMgcG9pbnRlZCBvdXQgdG8g bWUgdGhpcyBtb3JuaW5nIHRoYXQgUkZDIDc1OTEgKERDUikgaXMgdXBkYXRlZCBieSA3NTkyIChE Q1JNKSBpbiBzZWN0aW9uIDMgdG8gaW5jbHVkZSB0aGUgc2FtZSByZWdpc3RyYXRpb25fYWNjZXNz X3Rva2VuIHJlc3BvbnNlIG1ldGFkYXRhIHRoYXQgT0lEQyBkZWZpbmVzLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkNlIG1lc3NhZ2UgZXQgdG91dGVz IGxlcyBwacOoY2VzIGpvaW50ZXMgc29udCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNp dmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLjxicj4NClNpIHZv dXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIgb3UgcydpbCBuZSB2b3VzIGVzdCBwYXMg ZGVzdGluw6ksIG1lcmNpIGRlIGxlIGTDqXRydWlyZSBhaW5zaSBxdWUgdG91dGUgY29waWUgZGUg dm90cmUgc3lzdMOobWUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lkaXRl dXIuPGJyPg0KVG91dGUgbGVjdHVyZSBub24gYXV0b3Jpc8OpZSwgdG91dGUgdXRpbGlzYXRpb24g ZGUgY2UgbWVzc2FnZSBxdWkgbidlc3QgcGFzIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0 b3V0ZSBkaWZmdXNpb24gb3UgdG91dGUgcHVibGljYXRpb24sIHRvdGFsZSBvdSBwYXJ0aWVsbGUs IGVzdCBpbnRlcmRpdGUuPGJyPg0KTCdJbnRlcm5ldCBuZSBwZXJtZXR0YW50IHBhcyBkJ2Fzc3Vy ZXIgbCdpbnTDqWdyaXTDqSBkZSBjZSBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgc3VzY2VwdGlibGUg ZCdhbHTDqXJhdGlvbiwgU1RFVCBkw6ljbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0 cmUgZGUgY2UgbWVzc2FnZSBkYW5zIGwnaHlwb3Row6hzZSBvw7kgaWwgYXVyYWl0IMOpdMOpIG1v ZGlmacOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLjxicj4NCk4naW1wcmltZXogY2UgbWVzc2Fn ZSBxdWUgc2kgbsOpY2Vzc2FpcmUsIHBlbnNleiDDoCBsJ2Vudmlyb25uZW1lbnQuPGJyPg0KPGJy Pg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlcyBhbmQgaXMgY29uZmlkZW50aWFsLjxicj4NCklmIHlv dSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBhbnkgY29waWVzIGZyb20geW91ciBz eXN0ZW1zIGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpBbnkgdW5hdXRo b3JpemVkIHZpZXcsIHVzZSB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIGl0cyBwdXJwb3NlLCBk aXNzZW1pbmF0aW9uIG9yIGRpc2Nsb3N1cmUsIGVpdGhlciB3aG9sZSBvciBwYXJ0aWFsLCBpcyBw cm9oaWJpdGVkLjxicj4NClNpbmNlIHRoZSBpbnRlcm5ldCBjYW5ub3QgZ3VhcmFudGVlIHRoZSBp bnRlZ3JpdHkgb2YgdGhpcyBtZXNzYWdlIHdoaWNoIG1heSBub3QgYmUgcmVsaWFibGUsIFNURVQg c2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxicj4NCkRvIG5vdCBwcmludCB0aGlzIG1lc3NhZ2UgdW5sZXNzIGl0IGlz IG5lY2Vzc2FyeSwgcGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudC48YnI+DQo8L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7f5b0068bcc74a21a00b578adb7fdbc3STEMES002steteucorp_-- From nobody Mon Oct 14 02:20:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9FF12013C for ; Mon, 14 Oct 2019 02:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEKffuHUGA2m for ; Mon, 14 Oct 2019 02:19:57 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED36412013B for ; Mon, 14 Oct 2019 02:19:56 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id y204so5198194yby.10 for ; Mon, 14 Oct 2019 02:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=W6ddebrJhnwo7LRg7DhFI+DwOVNlLMJn9XLzNTNITjY=; b=z0CyyjJuthYEL2ZwlapIKMbvE8dBqETQvrLtF04koYGayKfHQgog/vepp+w3BGQdO9 JHuX7TkOO7yv0+QBkWavjoT5Ok9/MFAioyQCUsidJiB08LLmrH248iVHb7Li0W+HOyrx Jxojv2H4Y62uUU4YOU2i+YTsCBN0Tc9fUlqO027FUfCyJxItY/7L8NrhvcPEyetjpe87 Sg6Zq9mmQmC1ve2T4lXZsd+zd2ctVbDzVjPuU9opUqHWBCGCkiIUvAWMCdBk+z01Oy9B 5qod9ip6foPH+rlnVbM57sOMiraZdIIyKVKyAjaiUasouISGzz7BL82/E3TB/qwuXae9 Kyyg== 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=W6ddebrJhnwo7LRg7DhFI+DwOVNlLMJn9XLzNTNITjY=; b=O3ih72jGKXKCG5mN54hrgjcRMGZJ2REHR+kwr541ErqK2JzbfMgxvAL646Dmu4bLD1 bYrVElSuDJ2O6LeEm9oWo9UpLkmWNBVDWpyptnBHH/CUE8j1iXh2S9myX1WBWRwF+je5 ZsysBTuF45cik0QWw88MBzrD1wUMtN5KPy/A+9xyA22D/qXgBoZB8YzJ0/8QTaVyoP7N QLGbxbelXfPEqhkO6aOe/ByOpLDDViGPdYRbJLmSMbdyjLjjuZUETVt6ifKFlF7tiRjz X7BEaEgjDbHVNBsn27gq9/+FytbQdW0JBNpamhNaYzRn+NQ/XXbRAEAsd3y4lgeCTpOV mRcw== X-Gm-Message-State: APjAAAVCOXdbv7Kb6RS1bBRaQHW/n/U+mh2iwNeafJe8i2GLkrwaVx+g xH9LAd7AHNX2GNcOJhyiS0SveQZziCRhioWLkb3znXQkQLI= X-Google-Smtp-Source: APXvYqwdAcyM5TCe5KhWtCDhn4ylf+WxV5l+p9ZsiBIXhlnpXQHjHbDzGbWKbtDDWoaFoHnBlZsaULq2CcDR1GsqVus= X-Received: by 2002:a5b:708:: with SMTP id g8mr18750506ybq.98.1571044795950; Mon, 14 Oct 2019 02:19:55 -0700 (PDT) MIME-Version: 1.0 References: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> In-Reply-To: From: Travis Spencer Date: Mon, 14 Oct 2019 11:19:45 +0200 Message-ID: To: oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000fd43880594db5e9c" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Oct 2019 09:20:00 -0000 --000000000000fd43880594db5e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like a slot to talk about a new draft I'm going to submit in the coming weeks related to claims (i.e., structured scopes). Would that be possible? On Fri, Oct 4, 2019 at 11:15 PM Dick Hardt wrote: > I'd like a slot to provide an update on Reciprocal OAuth. > =E1=90=A7 > > On Fri, Oct 4, 2019 at 2:12 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Hello chairs, >> >> I'd like to request some agenda time to present on: >> https://tools.ietf.org/html/draft-fett-oauth-dpop >> >> Thank you, >> Brian >> >> On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi chairs, >>> >>> I would like to request the following slots: >>> - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar >>> >>> - https://tools.ietf.org/html/draft-lodderstedt-oauth-par >>> >>> - Security BCP >>> >>> kind regards, >>> Torsten.. >>> >>> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool < >>> session-request@ietf..org >: >>> >>> =EF=BB=BF >>> >>> A new meeting session request has just been submitted by Hannes >>> Tschofenig, a Chair of the oauth working group. >>> >>> >>> --------------------------------------------------------- >>> Working Group Name: Web Authorization Protocol >>> Area Name: Security Area >>> Session Requester: Hannes Tschofenig >>> >>> Number of Sessions: 2 >>> Length of Session(s): 1.5 Hours, 1.5 Hours >>> Number of Attendees: 50 >>> Conflicts to Avoid: >>> Chair Conflict: acme tls rats sipcore anima >>> Technology Overlap: ace secevent teep suit core tokbind saag >>> >>> >>> >>> People who must be present: >>> Roman Danyliw >>> Hannes Tschofenig >>> Rifaat Shekh-Yusef >>> >>> Resources Requested: >>> >>> Special Requests: >>> >>> --------------------------------------------------------- >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000fd43880594db5e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like a slot to talk about a new draft I'm goin= g to submit in the coming weeks related to claims (i.e., structured scopes)= . Would that be possible?

On Fri, Oct 4, 2019 at 11:15 PM Dick Hardt &l= t;dick.hardt@gmail.com> wrot= e:
I'd like a slot to provide an update on Reciprocal OAuth.
3D""=E1=90=A7

On Fri, Oct 4, 2019 at 2:12 PM Brian Campbell= <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Hello c= hairs,

I'd like to request some agenda time to= present on:

Thank you,
Brian

On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi chairs,

=
I would like to request the following slots:
- Security= BCP=C2=A0

kind regards,
Torsten..

Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool = <session-r= equest@ietf..org>:

=EF=BB=BF

A new = meeting session request has just been submitted by Hannes Tschofenig, a Cha= ir of the oauth working group.


= ---------------------------------------------------------
<= span>Working Group Name: Web Authorization Protocol
Area Na= me: Security Area
Session Requester: Hannes Tschofenig

Number of Sessions: 2
Length o= f Session(s): =C2=A01.5 Hours, 1.5 Hours
Number of Attendee= s: 50
Conflicts to Avoid:
Chair Conflict:= acme tls rats sipcore anima
Technology Overlap: ace secev= ent teep suit core tokbind saag


People who must be present:
=C2=A0= Roman Danyliw
=C2=A0Hannes Tschofenig
=C2= =A0Rifaat Shekh-Yusef

Resources Requested:=

Special Requests:
=
---------------------------------------------------------<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you._= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000fd43880594db5e9c-- From nobody Mon Oct 14 04:02:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3357120043 for ; Mon, 14 Oct 2019 04:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGTld1VDVcce for ; Mon, 14 Oct 2019 04:01:56 -0700 (PDT) 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 C534212001E for ; Mon, 14 Oct 2019 04:01:56 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id r68so5281375ybf.5 for ; Mon, 14 Oct 2019 04:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qwcy2xxBaTeQ8rqSocbhdcLE+qzt4ByluouLIj00Uus=; b=kItiJlfrABaYim2AAzAoeUMTx2KLPWKEONmNA90XyjePT5vkdeejBWK87A9keUAgin e0glUsTCk+lS4enDOHCGmqRNQvSa1SnYx+LaOJ5AJexydgdC78B7p0gUsfQxlU/JibAl fZAMrRuA2WC6fOdeoA7TmAwCFQs3BOObGfbzbMxVl7f7xDHFiMTOcqLDgwinfmksG4cZ lBcuIH98mmIDf+GDvyI1stfJlWZCI8xjG1pLIqYJSLquX6h1C6pvZ4W3A+Yx7EFHILe/ FvvkfDFlwfHDlJeAtJo8E8Psi5vXFHJcOGJBgYgee2ySFxAldsAHU10oYBK+VcZwZfmf sATQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Qwcy2xxBaTeQ8rqSocbhdcLE+qzt4ByluouLIj00Uus=; b=Iuixi2f7LmMCT09pob0TLPv2w/AK80mJu56HH7ScEz+KNvSX8xtXhKw+SEr3F0ry9+ +FRywfOyfl/PEJ3Ukhtj5x4mljVZ6Q50fw3/mujm+4SOOnK7LsjdKhJCJePyHKbIHaPf HlePnNfADv0xD2IirhcMoNhsrqs6m66ThhBiz+jkGfCEsNGdNuW5S33wUczI288aXskV +zdRXaase/wmTISID/bJ5hC+vxB7plloQ8GkgHCgWGJrQheJQvtdahf3nHS5UrXg8ArF 5wYDTWazNtQzAo0hxIv0BGodvLvvuhaQaRnbdquOmP7+isg7+rCJpvgiV7OhnxbHtGoG DB/Q== X-Gm-Message-State: APjAAAVypHoit5iLIgxOvKO4IhAynEQqnQq3bo0b2vyKlCWCXxIAfFMK ceqBummzACu89gkxIc63mcjJ9uvcY5/3D2pq0vGCNQ== X-Google-Smtp-Source: APXvYqyQ9MQZAzBhPAfktJjg/Elv3HHbJnl/dI7WxD9j5SqA4+NsrCUcfzBP0oVtDg57AZkwtfMIGQxjcOvQTbaMpU8= X-Received: by 2002:a25:1802:: with SMTP id 2mr17668405yby.369.1571050915887; Mon, 14 Oct 2019 04:01:55 -0700 (PDT) MIME-Version: 1.0 References: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> In-Reply-To: From: Travis Spencer Date: Mon, 14 Oct 2019 13:01:44 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , =?UTF-8?Q?Robache_Herv=C3=A9?= , "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Question regarding RFC 7592 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Oct 2019 11:01:59 -0000 On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt wrote: > > What happens if the access token is lost or compromised? Does the app nee= d to be completely re-registered? Yes. Re-registration breaks many things though, so it's often not an option. In these cases, the client is pretty much stuck with only bad choices :-/ The token lifecycle of DCR(M) is one of the areas that would be great to improve IMO. We originally had planned to always issue a dynamic client a secret that it could use to get a DCRM scoped token using the CC flow. We opted not to do that in the end because the client could be using certs, for example, and a secret for management would lower the security of the client. Using the credential (like a signed JWT using an asymmetric key as you mention, Dick) could be a good way to handle this. Perhaps RFC 7592 (DCRM) should be updated with some info about allowing the client to use the CC flow with whatever credential it registers with, just for the purpose of obtaining a new DCRM-scoped registration management token. Justin mentioned this though: > Why not use the client=E2=80=99s credentials? Because not all clients ar= e set up to have credentials, plus we=E2=80=99d be spreading the requiremen= t to support different kinds of client credentials to another endpoint. IMO, the dynamic client should go to the token endpoint with whatever credential it registered with using the CC flow and a scope of "dcrm". So, the last concern about spreading the need to authenticate to other endpoints would be moot. I'm not sure what to say about public clients. ATM, in our product at least, we don't support public clients registering, so this wouldn't pose an issue for us. Could for others I suppose. Short of CC though, I can't think of a good way to get a new registration management token. From nobody Tue Oct 15 08:44:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77A1200F8 for ; Tue, 15 Oct 2019 08:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=armh.onmicrosoft.com header.b=tIBszEBx; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=Pe24iTpB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHwBMDD72gxb for ; Tue, 15 Oct 2019 08:44:41 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40083.outbound.protection.outlook.com [40.107.4.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF751200F3 for ; Tue, 15 Oct 2019 08:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=acij60cwH9PQS3jJx/rGnehqzi2UxSk+H8BfRIDl4nc=; b=tIBszEBx/9A48bYFlgB/gl/oZnxUuYusQ6xMUDLfCFjYYIOvhclM7MiZy732SCw2HzqcVJlLEMTduueoLCcQyh3FX5TXcGTUOsSFiuOq19d/zxgT3PvbZS0WaEdpevr6WJbnyyfSjoPR58PXta5Qti1XIvKwBCbT0xYb2IbDykw= Received: from AM6PR08CA0019.eurprd08.prod.outlook.com (2603:10a6:20b:b2::31) by AM0PR08MB3508.eurprd08.prod.outlook.com (2603:10a6:208:e1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 15:44:37 +0000 Received: from VE1EUR03FT051.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::206) by AM6PR08CA0019.outlook.office365.com (2603:10a6:20b:b2::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Tue, 15 Oct 2019 15:44:37 +0000 Authentication-Results: spf=temperror (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=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT051.mail.protection.outlook.com (10.152.19.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Tue, 15 Oct 2019 15:44:35 +0000 Received: ("Tessian outbound 0cf06bf5c60e:v33"); Tue, 15 Oct 2019 15:44:35 +0000 X-CR-MTA-TID: 64aa7808 Received: from ee77cae2a639.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.13.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3B28D5EB-51B4-4028-B131-C74DC94BC353.1; Tue, 15 Oct 2019 15:44:30 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2055.outbound.protection.outlook.com [104.47.13.55]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ee77cae2a639.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 15 Oct 2019 15:44:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P/uS6vYvRd5JaayUlECY7/cnSnO8eLBn7fPCKX12pbZx5O1M7qXeNddHf/KDnLg6Ufhxe/z6BnGTOljAOzLwSV8JgYFHKH05MJNSaROHkxeUyIx6p8P9bveQJjk8cmyM5XrUiUiKyUbYbPR76IKzIxUB4BTqlxV8ihjeaQKVibgh75QmCQqZ+8r5JzO7YFIFlJkj7Pl061gPe3GkcRJNlYLd9hNzNcaEb8/sLvzYXjgIjnmWZlvgQyVChPEeRLDyPmKrFxj4SEocvSxepgTWegRyKj6hEDtBI66lc/K0OyJTk12sq270SpqcJ9NV8pWht+K2G2eYU787TxsKKcwIuQ== 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=54yEPu6N8rHJ4gO59TJ/psoBG0OoparWYqKY+j4kGM4=; b=dRYxf5iJiov15Wz5C58FdQdr9omL4CK7Zf6sRAdUvFjQV85W4cUj1uEeKYFphK3SUnRl58UeERZb//E03dJboqZXE6DWXJ32G+9bFFh9gX3j/ebRp8D29oAmNPp8mnLa6LF0QnohoBtBpxi21zTUgmLjn3n+ivO7LDjFMtqObRdiUB646BTaTGwiuzQ/ybFxm+ELjZUa+GqrvXB6qu/dWcuB6NENU2ZuTc7+xdYBqC7KtsEFWSHoYJFLqx2FYcm8Z1TWGfUKgJ6p4VMFibdFvTSBySr6EnUhLdk35Yh3xNNagKCpwdrboeyX4mXiT4B89GsVpwca3eMzUhawHbxpSw== 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=54yEPu6N8rHJ4gO59TJ/psoBG0OoparWYqKY+j4kGM4=; b=Pe24iTpBcP+yz65OpSJbq1UWFCbWuf8fJPAHzYu4TDO0twFhvnN7qyF4d0slp5auaBp7gYOKtumJWixpJE419bey6AcnT3GeN9geQqxAn5IOOSui81mgToB0OIGN/m+dJALcjiZFSRXyLYKYyXu5uqefA91k9u2KMmfcZTUKc3Y= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB2879.eurprd08.prod.outlook.com (10.175.242.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 15:44:29 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2347.023; Tue, 15 Oct 2019 15:44:29 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Virtual Interim Meeting - Nov. 4th Thread-Index: AdWDbpqflo6aRETARQGD6EEMjvhjAw== Date: Tue, 15 Oct 2019 15:44:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 6eaf627c-bc00-4538-860a-4275bd0a84c5.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.83] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 4b5e3e95-4c08-489f-64fb-08d7518694c2 X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: VI1PR08MB2879:|AM0PR08MB3508: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 01917B1794 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(199004)(189003)(53754006)(38314003)(7696005)(4743002)(55016002)(52536014)(6116002)(3846002)(81166006)(81156014)(5660300002)(8676002)(99286004)(102836004)(6506007)(66476007)(64756008)(66446008)(7736002)(478600001)(66946007)(66556008)(14444005)(256004)(8936002)(2906002)(9686003)(6306002)(476003)(25786009)(86362001)(186003)(4744005)(76116006)(74316002)(33656002)(66066001)(305945005)(316002)(14454004)(26005)(6436002)(71200400001)(71190400001)(6916009)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB2879; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 3AU22eQu1KplMhdOiXtaNEs7oj+9sR+ihH0DAfoD4WCAwseN1dPFEqScCecXyHGF1deTIG4CxTHWnPpkrmoyMxeRqdtfBljUHExnBoAPOcVRis1RzvaU8g9eOpbg28j0SEdrFrPgBH2/3u8MMBsVEycLoRiiUIzu7RdrT/PMSeg/TqiD6k+keKxGc3a8ECpVm7wXxQMK5gtQWIyU3H2oeALVYqMEuStFDPPN7I7CzeteZg8D9wSp8Na+wmsLc2kxFX/rFTZil88HYNWKhLnxdJxno41HGX8qbuiI8Vvn/C94tF2CO14bpf9dpuosl/1zl+CU5Eb/ycQBqzwDUSJgKRb5eHNqwLoH5iNpxsuF8EC//TdueKxA1pCx1KcfaUNtc1tMa3nTFfEyKYRpmqD4Bx/u0RSug6zmWufNzPp1oEXdz2JpKLLBYOqrguYq5wlP1QlPKTE+msrC7ybmBaPG+w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2879 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT051.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)(376002)(346002)(39860400002)(396003)(136003)(38314003)(53754006)(189003)(199004)(40434004)(6916009)(356004)(33656002)(6306002)(66066001)(7736002)(305945005)(9686003)(14444005)(5024004)(14454004)(55016002)(22756006)(478600001)(26826003)(97756001)(47776003)(74316002)(36906005)(316002)(26005)(5660300002)(336012)(70586007)(70206006)(6116002)(3846002)(23726003)(63350400001)(6506007)(4744005)(99286004)(7696005)(86362001)(476003)(76130400001)(186003)(46406003)(8746002)(50466002)(8936002)(25786009)(486006)(126002)(4743002)(52536014)(2906002)(81166006)(81156014)(8676002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3508; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; 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: 2293ff2c-96a7-4524-763d-08d7518690ca X-Forefront-PRVS: 01917B1794 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VQ1/vy8ZuLON8i706nCyUniFnP/u+JWsnL7XuAmGr8eqVXL2/GF2GkpU4mVN++ZvRzXibpOXbF7/gheVmvDhEu68DcqNf6+YfF74VLbuZMU96OUGtxNLsciUyes574wGJZgaNEdRXsxZTisnQ+DhSnzdayx0czvQVIB/12MAlltWZZSjMBfhIx1kaiBnUjT7Tw2/TY15+otgnLz3unNzl1QQmH1F2wmQC2Xxt7YqiszDTBSiAQwTat4U62c3jteOvhRHUAuNxbH0AbWDNqRscwJO7xMTc3b40CG1KaBKoxGY2PVjOg0kQKjNqpNF5rgYFTd3i5S0WhxO/ImCCZ+Bdx0mSYFGn3oegpYjnVYcvFlJiAf5X3LgziS9+F9PD5KaKzF9a/wGFmA3f7wFppUURqOT2Q19xlujO5vW5cKRtylK+f/p0oW8wRgN18V3CBkdRQyuEFSfWRYNh1SgM0UfIQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2019 15:44:35.7978 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b5e3e95-4c08-489f-64fb-08d7518694c2 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: AM0PR08MB3508 Archived-At: Subject: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Oct 2019 15:44:45 -0000 Hi all, we would like to hold a virtual interim meeting to discuss the next steps r= egarding the OAuth 2.0 Security Best Current Practice (https://datatracker.= ietf.org/doc/draft-ietf-oauth-security-topics/) draft. Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:00 PM= to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna). Please let us know if you are interested in the call. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Oct 16 00:16:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E757A120847 for ; Wed, 16 Oct 2019 00:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvjP1tQQeYMe for ; Wed, 16 Oct 2019 00:16:16 -0700 (PDT) Received: from esa8.hc1106-67.c3s2.iphmx.com (esa8.hc1106-67.c3s2.iphmx.com [139.138.36.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220C21200A3 for ; Wed, 16 Oct 2019 00:16:15 -0700 (PDT) IronPort-SDR: x3qvKMgq3WAsl7icC+H4XIZK6omg1V92w/NBGSX+KppHvJnrd5lTOwbG4NfHxieAUG2tKee3bQ hfwuUGXETX5IKSE/t32HeNUdD0METImFdIAzc/0ITwsyDHmGeOlg2toF0s2Vs8rYE+ky4RRZ1m BfsqAQN6MwtMrHbWV5zbi+W35tmCIRt7VgtxCohJj5t84PPfyCk9+n6tkIaQkofwJm7NQwjo2a 6vFzHXzF0nqA8IsWQ69hNNIsQwBvDunX6CrQpR9g+hH4RxXoosaMzrabSk3GTJD+HRFfFB+VJF NDw= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.102]) by esa8.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 16 Oct 2019 07:16:12 +0000 Received: from CHRP5014.corp.gwpnet.com (10.53.3.186) by edge.swissre.com (193.246.239.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 09:16:13 +0200 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5014.corp.gwpnet.com (10.53.3.186) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 09:16:11 +0200 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1473.003; Wed, 16 Oct 2019 09:16:11 +0200 From: Lee McGovern To: "oauth@ietf.org" Thread-Topic: Virtual Office Hours Thread-Index: AdWD8YULnLl4sPKFSu6UQAym05ITSg== Date: Wed, 16 Oct 2019 07:16:10 +0000 Message-ID: <482352dd12ed4f5fb2b7992dfe08ca71@CHRP5009.corp.gwpnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2019-10-16T07:16:08.9078940Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.10] x-rcom-deduphash: 114874c3-39bf-4830-9edd-b6d162d1cf4e Content-Type: multipart/alternative; boundary="_000_482352dd12ed4f5fb2b7992dfe08ca71CHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: Cp/xjltkJtKf69q45xWNxE7qjSwCdurtOXAQvw66XVo= Archived-At: Subject: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 07:16:19 -0000 --_000_482352dd12ed4f5fb2b7992dfe08ca71CHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable How does a newcomer get the meeting invite/dial in info for this call? This e-mail, including attachments, is intended for the person(s) or compan= y named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful= and is prohibited. If you are not the intended recipient, please delete th= is message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electr= onic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re= , we strongly advise you not to use the Swiss Re e-mail account for any pri= vate, non-business related communications. --_000_482352dd12ed4f5fb2b7992dfe08ca71CHRP5009corpgwpnetcom_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

How does a newcomer get the mee= ting invite/dial in info for this call?


This e-mail, including attachments, is intended for the person(s) = or company named and may contain confidential and/or legally privileged inf= ormation.
Unauthorized disclosure, copying or use of this information = may be unlawful and is prohibited. If you are not the intended recipient, p= lease delete this message and notify the sender.
All incoming and outgoi= ng e-mail messages are stored in the Swiss Re Electronic Message Repository= .
If you do not wish the retention of potentially private e-mails by Swi= ss Re, we strongly advise you not to use the Swiss Re e-mail account for an= y private, non-business related communications. --_000_482352dd12ed4f5fb2b7992dfe08ca71CHRP5009corpgwpnetcom_-- From nobody Wed Oct 16 03:54:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2212012E for ; Wed, 16 Oct 2019 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0mXUqKnOJXo for ; Wed, 16 Oct 2019 03:54:01 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0756D12012A for ; Wed, 16 Oct 2019 03:54:00 -0700 (PDT) Received: from [77.247.85.102] (helo=[192.168.47.200]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iKgwH-0006Xd-Qn; Wed, 16 Oct 2019 12:53:58 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7E917F46-4507-4DC0-BD7F-A759470621D9"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 16 Oct 2019 12:53:56 +0200 In-Reply-To: Cc: oauth To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 10:54:03 -0000 --Apple-Mail=_7E917F46-4507-4DC0-BD7F-A759470621D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m interested.=20 kind regards,=20 Torsten.=20 > On 15. Oct 2019, at 17:44, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > we would like to hold a virtual interim meeting to discuss the next = steps regarding the OAuth 2.0 Security Best Current Practice = (https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) = draft. >=20 > Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., = 6:00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, = Stockholm, Vienna). >=20 > Please let us know if you are interested in the call. >=20 > Ciao > Hannes & Rifaat >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7E917F46-4507-4DC0-BD7F-A759470621D9 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 Fw0xOTEwMTYxMDUzNTZaMC8GCSqGSIb3DQEJBDEiBCDVDYZ502aSKE8wjs3NJVSPCYU+YArbKXA1 MSO+scDD4zCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAHRzaFfMJb2LBN8+aXe1MgWgvM4lRegtIWHx+ZYWeCjBNEfYkZWCO84TPaC6 +XCtlACjTcB29y86yzjoRTjOAtzLCu2CmWMWeYs5rfxvIRJRw40SpZJ6jBh1HntiW43o2lnS/xXM CDe5dt8Dm6JPWEh3xV4tfXToox+U3M+6aeX57CEaUjWmltF1E26ZPtmsfCLkZToh/kX4MdiY76Kv nAMpXHtst4Y1iL0zwEKb30a69BvRilLEtnHmkd5ZJJ/2z4WsxTKTDlbuntbVuimNkNXrpyVK+phe JbWX0oh56WGx+9ZKeKWkNq67DOSv7yev7qVZlTpU4yV0NitxmVCN/bUAAAAAAAA= --Apple-Mail=_7E917F46-4507-4DC0-BD7F-A759470621D9-- From nobody Wed Oct 16 06:36:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74318120103 for ; Wed, 16 Oct 2019 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 rAEONj8ML10W for ; Wed, 16 Oct 2019 06:36:15 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63DD1200F9 for ; Wed, 16 Oct 2019 06:36:15 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id w12so53750765iol.11 for ; Wed, 16 Oct 2019 06:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7vtXBQxpoSQA4XZ5MfQYx9UjHH1otjOb2Up3kQUCXcg=; b=tWh0ZVheo0gSBOTjdNNJigmtHYFLacpHUrjVXrY4KQFbWSE9zWrttexPzv0IxqyKNb SxWKGpLlssIQgHMjlYp0WHgBsc4HcP8m9V8N72k87KFXi4H+rNvtA4CGgwHMoZXnYugm kdePxgug6fgHBDejSakbl2sKHQmSdSTBeFh84O4JKOL/3MLH1dODrSYjyX0i/Jg8QfLh ktREs3FajOvo5XC+goT9nUo4GxNoXA8saVtYVhZ9KAB3FdvejdutrHG4v+7PiBO9GC06 c1LhNbw/3pOwNVgm+DcTBno6Tgf4HpSW4jpZhiVu23FvIBXNRKAzHfCaMlEiGuwMciwz zKfg== 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=7vtXBQxpoSQA4XZ5MfQYx9UjHH1otjOb2Up3kQUCXcg=; b=jVZWHE4gwi1RmfnqJJfvWIi+qTFfm1qoD4pXevHGQKgFdB/NEggd6JvKQHDvt8HEOI Ovt73WcJFJ8XrYIw+EVe47kAadl3FGZatSbBlcJTQ6KZIMg8z9h7B7YUQz3ogmoL9pin 5uMGIqR//Tnij9o2Nvx26gAW8XncdcK5Fvw6cgux2oWi1GGgf2h45rrXtC5fi9inLZoN cPL8r4BYuTRBkcz0E7JVRhaH4jgIwDLBaWPy2I1pUQ2uTIPjZW3Y6UwQOX5ZW1jOp41y +BoWSl8Z+CRhH67P/kiAB3hUGJLDc4zy37Deb9eeopO9dujw/oxE6s7LHeNhUOiGQtaM 71Ww== X-Gm-Message-State: APjAAAUKa33wLvjza8/wlz/LyydZfMKvvggaHjI9OSyZvBUQiuOE+6xS uojSb7f6ABlJm3j5iWzgRQAlWu8VCTg= X-Google-Smtp-Source: APXvYqx/4TJJ1tHOIDPhCQOrDouuK4Xf4XTjNAC5peWrGbn2zDtXBdCEWjo2FCG+dyFTQU9RRl4tSg== X-Received: by 2002:a6b:e415:: with SMTP id u21mr11980135iog.144.1571232974536; Wed, 16 Oct 2019 06:36:14 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id l3sm15591721ioj.7.2019.10.16.06.36.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Oct 2019 06:36:12 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id q1so53883771ion.1 for ; Wed, 16 Oct 2019 06:36:12 -0700 (PDT) X-Received: by 2002:a02:661d:: with SMTP id k29mr45999647jac.35.1571232972544; Wed, 16 Oct 2019 06:36:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 16 Oct 2019 06:36:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="0000000000003020e60595072fce" Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 13:36:19 -0000 --0000000000003020e60595072fce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm interested as well. Aaron Parecki On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt wrote: > Hi, > > I=E2=80=99m interested. > > kind regards, > Torsten. > > > On 15. Oct 2019, at 17:44, Hannes Tschofenig > wrote: > > > > Hi all, > > > > we would like to hold a virtual interim meeting to discuss the next > steps regarding the OAuth 2.0 Security Best Current Practice ( > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) draft= . > > > > Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:0= 0 > PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, > Vienna). > > > > Please let us know if you are interested in the call. > > > > Ciao > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. 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 ---- Aaron Parecki aaronparecki.com @aaronpk --0000000000003020e60595072fce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm interested as well.

Aaron Parecki

<= /div>


On Wed, Oct 16, 2019 at 3:54 AM Torsten Lod= derstedt <torsten@lodderstedt= .net> wrote:
Hi,

I=E2=80=99m interested.

kind regards,
Torsten.

> On 15. Oct 2019, at 17:44, Hannes Tschofenig <Hannes.Tschofenig@arm.com>= wrote:
>
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next st= eps regarding the OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/draft-ietf-oauth= -security-topics/) draft.
>
> Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:= 00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vie= nna).
>
> Please let us know if you are interested in the call.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--0000000000003020e60595072fce-- From nobody Wed Oct 16 07:19:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3012011F for ; Wed, 16 Oct 2019 07:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljM_jMcEvkft for ; Wed, 16 Oct 2019 07:19:42 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE701200F4 for ; Wed, 16 Oct 2019 07:19:42 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id j31so36320030qta.5 for ; Wed, 16 Oct 2019 07:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iv2Wr5xKgBh565vr5DVOGzyi9jpba5ymNbj7nP3+3YA=; b=E+zWfILtiCWWYI8Yj/IwSZ3M4aCp8Z8Fce+K/jon6boYs4oNIBzd1qvSeb05DxDURL iKpx3x+Q7W1PTCBqeBYLl8qdmfzZAg4QxTNwq3OnZFq59vADBmXwbnBD7dpgmVja3jKc Ei3oSSZsN8r/CBMexlL6P7onhhxyqbRQjlEQkFQsjpzmOiqbsiEWMdc4aZ2CsLWKkWz4 tNm/fNTPqmK5YbPihTcTx9FXiHmAwm/+h9FBxJqG60vwj/jTJAc4trarKODP62uO2HnJ ychu2p2AV8wJpKNA0kUuyUqGsfWY7A/JqY35L55dp4fsTTsHCte38Qlb7GF1mkWs8Chq 2UEw== 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=iv2Wr5xKgBh565vr5DVOGzyi9jpba5ymNbj7nP3+3YA=; b=Q8uaYNfTi3C9AWmtShEa1DtXnapbrx2HN4Rhk0/Oxu21wBveeIxGMPvEaOrebxsF2B LVBdAXsxPuVraI+PzEUR8I9MZU+zRTXAYCgoAFgWR6coZ0c3TVuU7/cxc77PWkE+DDdE 1UVZRGTSaY3CEeWhTecEWBeOK2X0bFOeJkycLawrDW6RJaHkpRoWPgSYBzHpSyfdgNWQ FVGEVep/A3PheV87mnWwQiEWAH7kgVg9rKuzJmuxofGWEeAAMaw0APFV34RKTXD/9Ffc x+NMgmc/UKt/1jkYYwF7nzWnpw5xNfpyftXIWiVHw60hOAuw4fm3yP04qZDSdzKK+1bh cuxQ== X-Gm-Message-State: APjAAAUjK0oJp2NtbCAzr17s3DvrMtv0QXTAymjQsIoM9wLHGsHkYfDf 2mvSzQedKMVlf9u4b4UgJIqh1AchZsZ/l3hK+0zh4w== X-Google-Smtp-Source: APXvYqwcr4yMVXitZGo9U0XFfOIxwCRkuDRF3PZ9DXfKC0gEVvSvKUhtOH0DvHZzzd+6KuVnLPPmKgtzlo+iEbQsPeg= X-Received: by 2002:ac8:4052:: with SMTP id j18mr45084100qtl.281.1571235580824; Wed, 16 Oct 2019 07:19:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vineet Banga Date: Wed, 16 Oct 2019 07:19:28 -0700 Message-ID: To: Aaron Parecki Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000a7d14b059507ca5d" Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 14:19:45 -0000 --000000000000a7d14b059507ca5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to attend as well. Vineet On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki wrote: > I'm interested as well. > > Aaron Parecki > > > > On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt < > torsten@lodderstedt..net > wrote: > >> Hi, >> >> I=E2=80=99m interested. >> >> kind regards, >> Torsten. >> >> > On 15. Oct 2019, at 17:44, Hannes Tschofenig >> wrote: >> > >> > Hi all, >> > >> > we would like to hold a virtual interim meeting to discuss the next >> steps regarding the OAuth 2.0 Security Best Current Practice ( >> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) >> draft. >> > >> > Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., >> 6:00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm= , >> Vienna). >> > >> > Please let us know if you are interested in the call. >> > >> > Ciao >> > Hannes & Rifaat >> > >> > IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. 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 >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a7d14b059507ca5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to attend as well.

Vineet<= /div>

On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki <aaron@parecki.com> wrote:
I'm interested= as well.

Aaron Pa= recki


On Wed, O= ct 16, 2019 at 3:54 AM Torsten Lodderstedt <torsten@lodderstedt..net> wrote:
Hi,

I=E2=80=99m interested.

kind regards,
Torsten.

> On 15. Oct 2019, at 17:44, Hannes Tschofenig <Hannes.Tschofenig@arm.com>= wrote:
>
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next st= eps regarding the OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/draft-ietf-oauth= -security-topics/) draft.
>
> Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:= 00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vie= nna).
>
> Please let us know if you are interested in the call.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a7d14b059507ca5d-- From nobody Wed Oct 16 07:24:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D8C12086F for ; Wed, 16 Oct 2019 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T95Jm3wr4vPP for ; Wed, 16 Oct 2019 07:24:08 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5927120890 for ; Wed, 16 Oct 2019 07:24:08 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id e205so8703828ywc.7 for ; Wed, 16 Oct 2019 07:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vnaMHLoNaRhKZGPp6VFA1kyxdCAPhiGTfGKxPZcWDYo=; b=Izd0KAokeRlkgjgJI3b7czRmeUPwjcZ2IP03yQf5axgSc2hOL23jMHSVWapbAfzMFi RNSPgEc+ycl+J4UtNzyQ6494t8USNmThFcGK4uxdOOsv/BnPBFQ9HJVuG7OP+2UO+Uj5 LmLxQvK61gcuRgPzV0XS9f/gt4ZOovrEIKzPfHT65+AU3ZUoo3HTM30tcqR1PPbhajo/ 2wLoBF7ORow31zbwVE22pfzkiop8C+Q+tXEZsrxZ3Y8dpCHTJzZDLaEEcqYE/vK226aP 69iQYEM6zZUs3rJf3uAy7GhAmU/uVyA9b1o3LgN4xWKyn64tcAyLOq0b5hfmHMnlmOqj mHwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vnaMHLoNaRhKZGPp6VFA1kyxdCAPhiGTfGKxPZcWDYo=; b=AYh5j1L+WSdqiJNn4ybVaraE3Sx5GB6VXu4u207Ajs1iCb74YMKUDaQpKIrNCrApvX 6U+q7ho+yOEmX59Dz+z2RHLJoB0FhlTTHmfQTAa6WqObMi4fq04lwAhcUWHnNnEnZGoM jjdVi85MfTZtJKE/yuRAn1h2UlPaCPPbkL5KX1mDQ45Sw0pXvVs6sq+VmZrIWI+34pxk 6ycCg9Mj2/cu7lLki4+mIejLt8ucYTA1VHKUdW5rHy9LhbtLlLr+vvOSdC8YzgUJXJdU RqB5C2cbcJroCCaBLVkuTtGabQoFa1rIuuUGO7lGqLLlPijkNT1f0NhXx7Dzic0buaYj fVpw== X-Gm-Message-State: APjAAAWhtl1ZEuM2ZpnZaOUrNhFtsCuKY6tpG3mxbq6TDz59ltDteNRs grz5umuLpwjX2068hMKdyZgC3L4ISwFqxGvU3yGbk3wjM4/CEg== X-Google-Smtp-Source: APXvYqy/Pm5QOdqr8Hh0NR1ohWYL/8eGxNe18MEzVeLOqQPlYDb2ym9+VmtLXdNqeOIIRCgnKBMmILCWy2M7rGQ+lIA= X-Received: by 2002:a81:f201:: with SMTP id i1mr19796504ywm.69.1571235847520; Wed, 16 Oct 2019 07:24:07 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> In-Reply-To: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> From: Travis Spencer Date: Wed, 16 Oct 2019 16:23:56 +0200 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 14:24:11 -0000 On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt wrote: > Hi Travis, Hey there, Torsten. Sorry for the slow reply. Still jet lagged ;-) > > On 26. Sep 2019, at 11:26, Travis Spencer wr= ote: > Do others have an opinion about this? https://tools.ietf.org/html/rfc7322#section-3.6 > > * Instead of issuing an expired JWT (or in addition) I think it should > > be valid for the AS to reply with a 201, no content. > Inline with RFC 7662, the AS always provides data to the RS even in case = the introspected access token is expired. Sure, but is that a good line to follow? The client said it accepts application/jwt, but the server returns application/json. This breaks HTTP. (I know that that HTTP allows the server to return a different media type than the one that was requested if there is only one representation of the resource, but this is not the case here.) So, to do this in a way that doesn't break (my understanding of) HTTP, the client would have to accept both application/jwt and application/json. Because the status code isn't helpful in determining which, the body has to parsed based on the content-type response header value. I think this makes it harder on the consumer than it needs to be and undoubtedly slower. > We clarified the intention of this draft due to various feedback (IESG re= view and other postings on the list). It is supposed to provide a JWT encod= ed introspection response and not a transformed access token. I continue (perhaps out of will, I admit) not to see how what I'm asking for a transformation and not a re-encoding of the same. > The main differences lay in the existence of the =E2=80=9Cactive=E2=80=9C= claim and the different =E2=80=9Eiat=E2=80=9C values. The addition of the active claim is a change, I admit that. The iat claim could be the same as the original though. > In order to prevent JWT confusion, the JWT shall be restricted to the ori= ginator of the introspection call. In section 5, the draft has this: "The value of the 'aud' claims MUST identify the resource server receiving the token introspection response." By resource server here, does it mean, literally, the caller? RFC 6749 seems to pin that down to one "server" so I think so. If so, this is different from what's commonly used for audience (or at least "common" among my experiences). As defined in the JWT spec (https://tools.ietf.org/html/rfc7519#section-4.1.3), "[t]he 'aud' (audience) claim identifies the recipients that the JWT is intended for....The interpretation of audience values is generally application specific." This divergence is confusing. I didn't notice it on first (or second) read, and highly recommend converging these. I think the JWT definition makes this spec more useful. > This prevents your use case, but how should we distinguish this from acce= ss token replay/abuse? As you say in section 8.1: "such an attack can be prevented like any other token substitution attack by restricting the audience of the JWT." I just think the audience that is defined in this spec is too narrow. Audience is more like a domain than a web service client (e.g., the introspection API client). I see the gateway and the microservices behind it as the same Resource Server with the same audience if they are all in the security domain. I see the gateway as being able to straddle multiple audiences though because it could be fronting multiple clusters of microservices that are in different domains (i.e., have different audiences). This straddling of different domains means the gateway either has a different audience or multiple. > Also, the JWT produced cannot be sender constrained, which even more make= s its use as an access token unadvisable. Sender constrained tokens do provide additional security properties that are desirable in some cases, but they are not the only kind that are advisable. It depends on the situation, right? > In my perception, your proxy transforms the token to make it easier consu= mable by the target RS. This is one of the drivers for what I'm advocating: simple API development. > I see two ways to approach it: > > 1) There is a (yet to be specified) function at the AS that transforms an= opaque access token into an JWT-based access token while preserving its au= dience and other properties (like sender constraints). The proxy itself req= uires authorization to request that functionality but is not an audience. T= he access token might even be encrypted for the target RS and be unreadable= for the proxy. This hypothetical spec would vary from this one in what ways exactly? That's not a facetious question, but something I think we should honestly catalog. You listed some ideas below, but I need to think more about these. That gap will help us make informed decisions and relates to Justin's question about the gap to Token Exchange as well. See my concern below about how we fill this gap. > Open: How would one implement sender constrained access tokens in that ca= se? I=E2=80=99m asking since the receiving RS obviously has no access to th= e information from the TLS handshake since TLS termination happens at the p= roxy (or even in before the request hits the proxy). The RS would need to g= et provided with the cert fingerprint via a trustworthy header, i.e. the RS= must be aware of the fact it sits behind a proxy. This is unfortunately the typical case even with the mTLS draft. This is because SSL is almost never terminated by the AS; in my experience, TLS termination is instead handled by some very fast proxy.[1] In such cases, the proxy will pass the cert through to the AS in some undefined HTTP header with some undefined encoding. The mTLS spec should have defined this IMO, as it prevents interop for a primary use case -- sender constrained tokens. In the case of introspection, I think this verification of the confirmation method is another aid the proxy could provide to the microservice. The proxy climbed the chain as it terminated SSL, fetched CRLs/OCSPs, called LDAP server to get intermediate certs, etc. Verifying the hash of the cert is not hard for it do as well. If the proxy doesn't want to parse the body of the introspection HTTP response though, it will have to forward the cert. The HTTP header and encoding used is undefined, and that is unfortunate for the sake of interop. For proxy auth though, we have the HTTP spec, so that could be leveraged. > 2) If that=E2=80=99s the case, the RS could also process the token intros= pection response as received by the proxy. In order to check the audience r= estriction, the introspection response would need to contain another claim = containing the original audience claims of the introspected access token. Y= ou could build that on top of draft-ietf-oauth-jwt-introspection-response. = What would it take? This is my concern: we end up with a lot of specs: 1. Introspection RFC 2. JWT introspection RFC 3. Token exchange 4. This hypothetical RFC that profiles #1, #2 and/or #3 Seems overkill. Can't we make more general specs that cover more use cases? If we don't, the cannon will be so extensive that it'll be unpredictable for many. This could impede adoption. [1] I have only come across a situation where the AS terminated SSL one time, and that was because its mutual TLS impl of the AS didn't allow for cert-based auth unless it did. (This wasn't Curity which allows for proxy-based mTLS but some other product.) The customer reluctantly allowed it and only did TLS-based routing in the proxy. From nobody Wed Oct 16 07:32:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97CF1200FB for ; Wed, 16 Oct 2019 07:32:51 -0700 (PDT) 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=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 5iJKKhQOlkHk for ; Wed, 16 Oct 2019 07:32:50 -0700 (PDT) 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 848AD1200EF for ; Wed, 16 Oct 2019 07:32:43 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id 7so24272215ljw.7 for ; Wed, 16 Oct 2019 07:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LDx5qnTSYLrDjPrppkQH6eOzNPQGe3ynxpKfZqEi4pA=; b=ngysrUTdEPtvXI7JRuSBf3xcgKKCfIDyaF0xDB0JkceWFtEkVkpAEEaapTZn6SZ0L2 p5ly1OmwWMeTshNNQXoEBenEWkmWZejXrdcvVsoMxxAjbonm0njlKjd8/jrbnNE6eUxb tO1SxoYyCBZAGndIoBmg4g6V9D3Z0zU1t4zr4= 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=LDx5qnTSYLrDjPrppkQH6eOzNPQGe3ynxpKfZqEi4pA=; b=REnNextoXYWhp2sGLK2n6i9J6wsOYiOUZY+x/YxCc5rU9DbwlvG+CXcLaGqT5+kENL o8yqLnBbphRRBa+rB6k+W+H6V1xj3r17uQMYtIYEVyUYu+txKVtwQB8+Yzs3eDfIUhAy NLCebOc7qx6QnENeMVS9w2TaGTDzQoiUrlG2JX7iAUn3IkbulkyKgmhRmI/d2lF5uFVD tDuqwv35sCrEeC4MeaJPZoFOKVNXhrF9dzqi1Q8JkzEuvB45FYoBT4qFjGr2tyZWrKCr Y9GctOVsJ7j7rejzND7OY5q7kuqjRN+XwApi5i5cwklrgnn+dYKfwstGzvqrRNykstBE qh3g== X-Gm-Message-State: APjAAAX4/7u8r/chd7XAulVBTWFoOqlqGRz25zrmZj6129VMbQWCO4Qp UZW+h/JGEgshzT8T/Q6wlyukaXSiRhm1cQ+Jx8N0HT8nO4RN8SBlr72E+fb24IOvbcgqUV79Qun umgOv+Uw5wEUXWw== X-Google-Smtp-Source: APXvYqwQbuvTI/HPVPoow2x08mwNqYqJh0FhM/z2xUi0PGt8cWCnqDf85HFeu6E+bNiUjh9ybPe3fp6UVAVb2aDHoxI= X-Received: by 2002:a2e:9ec2:: with SMTP id h2mr22781685ljk.85.1571236361193; Wed, 16 Oct 2019 07:32:41 -0700 (PDT) MIME-Version: 1.0 References: <482352dd12ed4f5fb2b7992dfe08ca71@CHRP5009.corp.gwpnet.com> In-Reply-To: <482352dd12ed4f5fb2b7992dfe08ca71@CHRP5009.corp.gwpnet.com> From: Brian Campbell Date: Wed, 16 Oct 2019 08:32:14 -0600 Message-ID: To: Lee McGovern Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002af10b059507f95e" Archived-At: Subject: Re: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 14:32:52 -0000 --0000000000002af10b059507f95e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The chairs might want to or be able to give a more official response to this but the latest meeting info I'm aware of was sent out in January in this message https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU On Wed, Oct 16, 2019 at 1:16 AM Lee McGovern wrote: > How does a newcomer get the meeting invite/dial in info for this call? > > This e-mail, including attachments, is intended for the person(s) or > company named and may contain confidential and/or legally privileged > information. > Unauthorized disclosure, copying or use of this information may be > unlawful and is prohibited. If you are not the intended recipient, please > delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re > Electronic Message Repository.. > If you do not wish the retention of potentially private e-mails by Swiss > Re, we strongly advise you not to use the Swiss Re e-mail account for any > private, non-business related communications. > _______________________________________________ > 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._ --0000000000002af10b059507f95e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The chairs might want to or be able to give a more officia= l response to this but the latest meeting info I'm aware of was sent ou= t in January in this message https://mailarchive.ietf.org/arch/msg= /oauth/v8sUMEBGMC24AdWLewAymP-X4kU

=
On Wed, Oct 16, 2019 at 1:16 AM Lee M= cGovern <Lee_McGovern@swissr= e.com> wrote:

How does a newcomer get the mee= ting invite/dial in info for this call?


This e-mail, including attachments, is intended for the person(s) = or company named and may contain confidential and/or legally privileged inf= ormation.
Unauthorized disclosure, copying or use of this information = may be unlawful and is prohibited. If you are not the intended recipient, p= lease delete this message and notify the sender.
All incoming and outgoi= ng e-mail messages are stored in the Swiss Re Electronic Message Repository= ..
If you do not wish the retention of potentially private e-mails by Sw= iss Re, we strongly advise you not to use the Swiss Re e-mail account for a= ny private, non-business related communications.
_______________________________________________
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. --0000000000002af10b059507f95e-- From nobody Wed Oct 16 13:46:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504F412007C for ; Wed, 16 Oct 2019 13:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no 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 kLGl1jqwjvQW for ; Wed, 16 Oct 2019 13:46:40 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650098.outbound.protection.outlook.com [40.107.65.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED1712012A for ; Wed, 16 Oct 2019 13:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eKtsYx7j5K/7F2+guoMT21Q89dtFzr0vCkZeVodYxyyWsBkWdHjZ+Te4XmAfmrPppwqZ0Y6fMAvEVVGwQpd1wznjj9hyUoZFU6J5CYtZ2u/YUcUyROakPS3TNnAlpFqQVPuDd0E61xbzD9AQugdWmmzTtsYXnGofgnl96+9oLDGSvWHgE2or7ySbp9HxE1FBOsYEiWPfIsl2M11WsM6bLk+EV7N7br6jK3qG+yCCBndlgZqmUmkel3UTG2tc6Gxk0Dk89f8zgDQWvPr6kdwEbbSQzMCUU4JKf5U3Wf023lT67X6sCrgmlhADY4tmOIwMbQ0azZzm3bVpwoA8ascbAQ== 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=HItYo7uIZ+R4L9sDQxOAjoqMwSC4sdFI8nf+L4I4rRA=; b=epYYD0fAnJyomOZuHroVj9UE4qgS/lf2aIJLdNZ5k9Xny0RX7GHAqpa3QDyTZKX4HI1ii1fN1UydajicbYRXC/Gs0CEE4ce/dw7IdXnCu+LR6XMTNak/Q7TBNB6HP2Y6K8MOHTve0LFUQcCsA1RJxiwQ5cXms0f0blwjDJmjDlggzb5XeYMo7TRya0cIgCiYVLRQQSTLxFaVi2DkYTwkhxQzhEphR5vqAtbuRECt4+MiBSwuMAfNqx52W9xQLRY2mAnAYD98Qr4gIBQK6KgV4iHI2mlzZHhgF/STEtJCOyUDsbMgu9R9tYbsxhGZjL2lyqJbj5ADsAGIKCsqijaRVA== 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=HItYo7uIZ+R4L9sDQxOAjoqMwSC4sdFI8nf+L4I4rRA=; b=ci+DTXhVKehBpVnrDo5ZgQiOgS/36IhKoJ2F4uHnfgKiY/xeCLPFGpUIhzejY/VwlARUUflJiS0GsJ+e6/gtpctmx7koqOhXjLK2BTBnP1h9Fa0id956MauCwZOQKCGb/KdOpmV+KLDMRYL+uIvFQIuioDwxaejz86b2/PvBqw4= Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0618.namprd00.prod.outlook.com (20.179.49.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2401.0; Wed, 16 Oct 2019 20:46:37 +0000 Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::9196:77fa:83c0:9418%7]) with mapi id 15.20.2405.000; Wed, 16 Oct 2019 20:46:37 +0000 From: Mike Jones To: Vineet Banga , Aaron Parecki CC: oauth Thread-Topic: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th Thread-Index: AdWDbpqflo6aRETARQGD6EEMjvhjAwAoWcQAAAWpI4AAAYR5AAANgt0g Date: Wed, 16 Oct 2019 20:46:37 +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=0ff8224d-247b-4780-a68b-00006d3a6e67; 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=2019-10-16T20:46:20Z; 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:98d9:5a0a:3425:3ebe] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1697d19-3a79-4c0b-8459-08d75279f0b4 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DM6PR00MB0618: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(38314003)(189003)(199004)(53754006)(40434004)(11346002)(102836004)(186003)(55016002)(5024004)(9686003)(6306002)(6246003)(52536014)(54896002)(8990500004)(236005)(2906002)(33656002)(10090500001)(53546011)(6506007)(5660300002)(446003)(6436002)(14444005)(74316002)(476003)(46003)(7696005)(76176011)(7736002)(486006)(256004)(99286004)(8936002)(606006)(81156014)(8676002)(4326008)(229853002)(6116002)(71200400001)(22452003)(66446008)(81166006)(316002)(790700001)(25786009)(478600001)(71190400001)(66476007)(10290500003)(66556008)(966005)(64756008)(110136005)(66946007)(76116006)(14454004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0618; H:DM6PR00MB0569.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: tI2/4qAJP+dYRTKB4fGTCTeEprTilRDA0KD1XqAcDT7pB+BSkRqKrcPj51SNnpHKjXYUoForFl2wWrCURVTL1b2Pv5JSSyh76cItNlwC/oT5D3WGx+3qgtZT3waVaDv0viqvfPdMuvEZKn+UEfESjcdUXgM5io3nGDdOJDECFCEZBCAbMLZGAY9k42KxeGlcIk66gSNcq4sANWaMTfQJfhHoamWYaVr45OUQIeliUID17NAO7BrofH5WMHee/foklMGOPkHzWpW7xBWMDC0g18nnThJ1JcsmYeVFui/kB67Nz3wbfl4uNMB+pUk4JmSV5FJiVX1wYw7Hr2eBx7bJzL1Ysv3TSS1YAnu4S+tocbesjJGU4FJCW7NLjShPnjMHx5UVQxTkd51VWizLXZo8wHDWiJ6p9ZspqQpyZI27JS4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0569CDE7D8FE9C250AFEA5D0F5920DM6PR00MB0569namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1697d19-3a79-4c0b-8459-08d75279f0b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 20:46:37.8057 (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: a3SV6Hq7W6q4Z41qyazqZdLyPKEDB9WGaqY8wfo3sumGtg0juzjHK7eqsnUUyz2ZuwP36EsoL7+butmxvA6YXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0618 Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 20:46:43 -0000 --_000_DM6PR00MB0569CDE7D8FE9C250AFEA5D0F5920DM6PR00MB0569namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBwYXJ0aWNpcGF0ZS4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBWaW5lZXQgQmFuZ2ENClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAx NiwgMjAxOSA3OjE5IEFNDQpUbzogQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+DQpD Yzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVmlydHVh bCBJbnRlcmltIE1lZXRpbmcgLSBOb3YuIDR0aA0KDQpJIHdvdWxkIGxpa2UgdG8gYXR0ZW5kIGFz IHdlbGwuDQoNClZpbmVldA0KDQpPbiBXZWQsIE9jdCAxNiwgMjAxOSBhdCA2OjM2IEFNIEFhcm9u IFBhcmVja2kgPGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdy b3RlOg0KSSdtIGludGVyZXN0ZWQgYXMgd2VsbC4NCg0KQWFyb24gUGFyZWNraQ0KDQoNCg0KT24g V2VkLCBPY3QgMTYsIDIwMTkgYXQgMzo1NCBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVu QGxvZGRlcnN0ZWR0Li5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6 DQpIaSwNCg0KSeKAmW0gaW50ZXJlc3RlZC4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0K PiBPbiAxNS4gT2N0IDIwMTksIGF0IDE3OjQ0LCBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRz Y2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3Rl Og0KPg0KPiBIaSBhbGwsDQo+DQo+IHdlIHdvdWxkIGxpa2UgdG8gaG9sZCBhIHZpcnR1YWwgaW50 ZXJpbSBtZWV0aW5nIHRvIGRpc2N1c3MgdGhlIG5leHQgc3RlcHMgcmVnYXJkaW5nIHRoZSBPQXV0 aCAyLjAgU2VjdXJpdHkgQmVzdCBDdXJyZW50IFByYWN0aWNlIChodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy88aHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG ZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRv cGljcyUyRiZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzJl OWJmMmNhOTcxYTQwNTIxNzgxMDhkNzUyNDNlZjgxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMSU3QzYzNzA2ODMyNDA1ODM0ODg5MyZzZGF0YT1Od0dFV09VWVhock9z cXdtcXJVbnBoRkZlOGsxWHNuTHpIeUlNbXZDZVhRJTNEJnJlc2VydmVkPTA+KSBkcmFmdC4NCj4N Cj4gVGltZSB3b3VsZCBiZSBhdCBvdXIgYmktd2Vla2x5IE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNl IEhvdXJzIChpLmUuLCA2OjAwIFBNIHRvIDY6MzAgUE0sIChVVEMrMDE6MDApIEFtc3RlcmRhbSwg QmVybGluLCBCZXJuLCBSb21lLCBTdG9ja2hvbG0sIFZpZW5uYSkuDQo+DQo+IFBsZWFzZSBsZXQg dXMga25vdyBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gdGhlIGNhbGwuDQo+DQo+IENpYW8NCj4g SGFubmVzICYgUmlmYWF0DQo+DQo+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0 aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Us IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZkYXRhPTAyJTdD MDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzJlOWJmMmNhOTcxYTQwNTIxNzgx MDhkNzUyNDNlZjgxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3 QzYzNzA2ODMyNDA1ODM1ODg4NSZzZGF0YT1CJTJCbnZNalhVSWNYazZTSjZUOFdPcE5BOWklMkJI ZUFDSEZZQmt1MGhPUW9YWSUzRCZyZXNlcnZlZD0wPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRm9hdXRoJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD MmU5YmYyY2E5NzFhNDA1MjE3ODEwOGQ3NTI0M2VmODElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MxJTdDNjM3MDY4MzI0MDU4MzY4ODc1JnNkYXRhPSUyRm1LV00lMkJx TDlsNnNWdFVmVFglMkJDSHhiJTJGVEF6WDdSaUJNUHduTTVMZDZKZyUzRCZyZXNlcnZlZD0wPg0K LS0NCi0tLS0NCkFhcm9uIFBhcmVja2kNCmFhcm9ucGFyZWNraS5jb208aHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZhYXJvbnBh cmVja2kuY29tJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdD MmU5YmYyY2E5NzFhNDA1MjE3ODEwOGQ3NTI0M2VmODElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MxJTdDNjM3MDY4MzI0MDU4Mzc4ODcxJnNkYXRhPVJvMllISG01T0lW dXdmd3RTamh0ZjdZVTBJcmF1RXRDNiUyQnltNTJDMXRTVSUzRCZyZXNlcnZlZD0wPg0KQGFhcm9u cGs8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZ0d2l0dGVyLmNvbSUyRmFhcm9ucGsmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN0MyZTliZjJjYTk3MWE0MDUyMTc4MTA4ZDc1MjQzZWY4MSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwNjgzMjQwNTgz Nzg4NzEmc2RhdGE9ejcxMGEyM1dYS1hTQnFWanBFJTJCSUhxTXducFJ1SG0lMkJWdWFkZERTTm5W TlklM0QmcmVzZXJ2ZWQ9MD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZkYXRh PTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzJlOWJmMmNhOTcxYTQw NTIxNzgxMDhkNzUyNDNlZjgxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMSU3QzYzNzA2ODMyNDA1ODM4ODg2NiZzZGF0YT1jdVNFMnNPdVpteXFjN0dUbUFCMWNDJTJC UnZPUzd0R1UxMWpnT2hqZUhDbXclM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_DM6PR00MB0569CDE7D8FE9C250AFEA5D0F5920DM6PR00MB0569namp_ 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 cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSB3b3VsZCBwYXJ0aWNpcGF0ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhh bGYgT2YgPC9iPg0KVmluZWV0IEJhbmdhPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0 b2JlciAxNiwgMjAxOSA3OjE5IEFNPGJyPg0KPGI+VG86PC9iPiBBYXJvbiBQYXJlY2tpICZsdDth YXJvbkBwYXJlY2tpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gVmlydHVhbCBJbnRl cmltIE1lZXRpbmcgLSBOb3YuIDR0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 b3VsZCBsaWtlIHRvIGF0dGVuZCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VmluZWV0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE2LCAyMDE5IGF0IDY6MzYgQU0gQWFy b24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29tIj5hYXJvbkBw YXJlY2tpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaW50ZXJlc3RlZCBh cyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBPY3QgMTYsIDIwMTkgYXQgMzo1NCBB TSBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Li5uZXQ8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCknigJltIGludGVyZXN0ZWQuIDxicj4NCjxicj4NCmtp bmQgcmVnYXJkcywgPGJyPg0KVG9yc3Rlbi4gPGJyPg0KPGJyPg0KJmd0OyBPbiAxNS4gT2N0IDIw MTksIGF0IDE3OjQ0LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5l cy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQom Z3Q7IDxicj4NCiZndDsgd2Ugd291bGQgbGlrZSB0byBob2xkIGEgdmlydHVhbCBpbnRlcmltIG1l ZXRpbmcgdG8gZGlzY3VzcyB0aGUgbmV4dCBzdGVwcyByZWdhcmRpbmcgdGhlIE9BdXRoIDIuMCBT ZWN1cml0eSBCZXN0IEN1cnJlbnQgUHJhY3RpY2UgKDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFj a2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MlMkYm YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDMmU5YmYy Y2E5NzFhNDA1MjE3ODEwOGQ3NTI0M2VmODElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MxJTdDNjM3MDY4MzI0MDU4MzQ4ODkzJmFtcDtzZGF0YT1Od0dFV09VWVhock9z cXdtcXJVbnBoRkZlOGsxWHNuTHpIeUlNbXZDZVhRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0 aC1zZWN1cml0eS10b3BpY3MvPC9hPikNCiBkcmFmdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGlt ZSB3b3VsZCBiZSBhdCBvdXIgYmktd2Vla2x5IE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJz IChpLmUuLCA2OjAwIFBNIHRvIDY6MzAgUE0sIChVVEMmIzQzOzAxOjAwKSBBbXN0ZXJkYW0sIEJl cmxpbiwgQmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVubmEpLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRoZSBjYWxsLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXMgJmFtcDsgUmlmYWF0PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55DQogcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3QzJlOWJmMmNhOTcxYTQwNTIxNzgxMDhkNzUyNDNlZjgxJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNzA2ODMyNDA1ODM1ODg4NSZhbXA7 c2RhdGE9QiUyQm52TWpYVUljWGs2U0o2VDhXT3BOQTlpJTJCSGVBQ0hGWUJrdTBoT1FvWFklM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJG bGlzdGluZm8lMkZvYXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN0MyZTliZjJjYTk3MWE0MDUyMTc4MTA4ZDc1MjQzZWY4MSU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzcwNjgzMjQwNTgzNjg4NzUmYW1wO3Nk YXRhPSUyRm1LV00lMkJxTDlsNnNWdFVmVFglMkJDSHhiJTJGVEF6WDdSaUJNUHduTTVMZDZKZyUz RCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJG JTJGYWFyb25wYXJlY2tpLmNvbSZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1p Y3Jvc29mdC5jb20lN0MyZTliZjJjYTk3MWE0MDUyMTc4MTA4ZDc1MjQzZWY4MSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzcwNjgzMjQwNTgzNzg4NzEmYW1w O3NkYXRhPVJvMllISG01T0lWdXdmd3RTamh0ZjdZVTBJcmF1RXRDNiUyQnltNTJDMXRTVSUzRCZh bXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9ucGFyZWNraS5jb208L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz QSUyRiUyRnR3aXR0ZXIuY29tJTJGYWFyb25wayZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN0MyZTliZjJjYTk3MWE0MDUyMTc4MTA4ZDc1MjQzZWY4MSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwNjgzMjQwNTgz Nzg4NzEmYW1wO3NkYXRhPXo3MTBhMjNXWEtYU0JxVmpwRSUyQklIcU13bnBSdUhtJTJCVnVhZGRE U05uVk5ZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+QGFhcm9ucGs8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNo YWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzJlOWJmMmNhOTcxYTQwNTIxNzgxMDhkNzUyNDNl ZjgxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNzA2ODMy NDA1ODM4ODg2NiZhbXA7c2RhdGE9Y3VTRTJzT3VabXlxYzdHVG1BQjFjQyUyQlJ2T1M3dEdVMTFq Z09oamVIQ213JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB0569CDE7D8FE9C250AFEA5D0F5920DM6PR00MB0569namp_-- From nobody Wed Oct 16 16:51:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99A1200F7 for ; Wed, 16 Oct 2019 16:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQqzXh5RCDOl for ; Wed, 16 Oct 2019 16:51:47 -0700 (PDT) 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 54FAD120086 for ; Wed, 16 Oct 2019 16:51:47 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id b20so534545ljj.5 for ; Wed, 16 Oct 2019 16:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=b552H+HOkLxsG0aLNrB+tpNloySGCdrH34GYq5evzmo=; b=kcSGPiFFAW9hdnVsvwlv8VVR+mw+wBCzai9zaVHBtE/I+CrN+3JKXpHpL8b9wAR2XK 52GHNcvYxFas0JYvBb55hBE+7EuQPkOGiVqhtbGooA6dOqYVd9w7+/sR0MCQEKnOx4J3 G7aRqzP1sOgpdtEyNE9UAH1Vw7etaY1RRkaBU= 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:cc; bh=b552H+HOkLxsG0aLNrB+tpNloySGCdrH34GYq5evzmo=; b=mpjXlEgab4TOzDSZIqNYBvNZo8qub/0I6V+1+ew3F1qVtNmtwNOmRFsLTVdJfdzpRZ LqU74hy5ciSgOG1AEMJNwWGlQnbixiGe+FiN6F6MB2TfreqHz6KMYZFkhAT1X3aZsEg1 0Lgfx+nkS5Qqhv67P2FXL1ap0KKUW8zzLOjR7JGlfPTrpKGuMO0vAt8qVfXZEfnAO4BQ oPVXS4O+K+JgdSja7Z/+1xGe8ntu1QYU1bsBpHp2fyOrmKozzRzWUo8yf6Qvh3ixOcg4 FN4W3OSjd8v+ywsBE5zP4JbVcghHXwsJlg4Hhr2Qh4Sg5H5SBtaAmAU3oPFNXgVosXhB p/LA== X-Gm-Message-State: APjAAAWrJ05XQBkBTd7PqlyFTRsXld/ODRX0q+60LSTr0oOZgcW0XJlJ kwTRI2NCGyrS9u+U5vwHuRo85eD/Gi3ZMa0LZMzY0W+ToJdfgzh64UGlGqRDAjCmtV3vrMm0vzC l3mB6D75pmEn+VFyQ X-Google-Smtp-Source: APXvYqwGnZY+LZ06me36uzWS5A2n/LQWp2WGYMa7WUs45Lgx3QT93zPNanDm7SIfJWlmMfr85N51PFjBs3VBzwme42Q= X-Received: by 2002:a2e:9bd2:: with SMTP id w18mr446385ljj.140.1571269904767; Wed, 16 Oct 2019 16:51:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 16 Oct 2019 17:51:18 -0600 Message-ID: Cc: oauth Content-Type: multipart/alternative; boundary="000000000000852c7605950fc804" Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Oct 2019 23:51:50 -0000 --000000000000852c7605950fc804 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm interested but it looks like I've got a potential conflict so will have to see if I can make it work. On Wed, Oct 16, 2019 at 2:47 PM Mike Jones wrote: > I would participate. > > > > *From:* OAuth *On Behalf Of * Vineet Banga > *Sent:* Wednesday, October 16, 2019 7:19 AM > *To:* Aaron Parecki > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th > > > > I would like to attend as well. > > > > Vineet > > > > On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki wrote: > > I'm interested as well. > > > > Aaron Parecki > > > > > > > > On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt < > torsten@lodderstedt..net > wrote: > > Hi, > > I=E2=80=99m interested. > > kind regards, > Torsten. > > > On 15. Oct 2019, at 17:44, Hannes Tschofenig > wrote: > > > > Hi all, > > > > we would like to hold a virtual interim meeting to discuss the next > steps regarding the OAuth 2.0 Security Best Current Practice ( > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > ) > draft. > > > > Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:0= 0 > PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, > Vienna). > > > > Please let us know if you are interested in the call. > > > > Ciao > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. 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 > > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > > @aaronpk > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --000000000000852c7605950fc804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm interested but it looks like I've got a potent= ial conflict so will have to see if I can make it work.

On Wed, Oct 16,= 2019 at 2:47 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I would participa= te.

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Vineet Banga
Sent: Wednesday, October 16, 2019 7:19 AM
To: Aaron Parecki <aaron@parecki.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th=

=C2=A0

I would like to attend as well.

=C2=A0

Vineet

=C2=A0

On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki <aaron@parecki.com&= gt; wrote:

I'm interested as well.

=C2=A0

Aaron Parecki

=C2=A0

=C2=A0

=C2=A0

On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt = <torsten@lo= dderstedt..net> wrote:

Hi,

I=E2=80=99m interested.

kind regards,
Torsten.

> On 15. Oct 2019, at 17:44, Hannes Tschofenig <Hannes.Tschofenig@arm.com>= wrote:
>
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next st= eps regarding the OAuth 2.0 Security Best Current Practice (h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) draft.
>
> Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:= 00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vie= nna).
>
> Please let us know if you are interested in the call.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> 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

--

----

Aaron Parecki

=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

<= 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. --000000000000852c7605950fc804-- From nobody Wed Oct 16 23:13:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6C12083F for ; Wed, 16 Oct 2019 23:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=P+w3Qx7n; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=TlkQdG4n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L6our8hTTAk for ; Wed, 16 Oct 2019 23:13:15 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20083.outbound.protection.outlook.com [40.107.2.83]) (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 6170612082D for ; Wed, 16 Oct 2019 23:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l4YDlwivvid7LQAFYKh3v8Jg97ZU4C0Z74zNvtk+g0w=; b=P+w3Qx7nQ2bnQPvrPOJusY/UAwrIk4MYMtnPPRBc4a1/CbkiSBuXo4ZBoVmyUZIzcBsePgBgDS0uMPKQscEzPBwo9F8e8NBH2ziQhmmtn/9wBbKaXwpHGcdczYiJN5f+7926lMaNKRQN8tyMe8ZoTnMjNPBF63Jr17ebXzKG+zc= Received: from VI1PR08CA0245.eurprd08.prod.outlook.com (2603:10a6:803:dc::18) by AM0PR08MB4434.eurprd08.prod.outlook.com (2603:10a6:208:143::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 06:13:10 +0000 Received: from DB5EUR03FT033.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::202) by VI1PR08CA0245.outlook.office365.com (2603:10a6:803:dc::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.17 via Frontend Transport; Thu, 17 Oct 2019 06:13:10 +0000 Authentication-Results: spf=temperror (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=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT033.mail.protection.outlook.com (10.152.20.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Thu, 17 Oct 2019 06:13:09 +0000 Received: ("Tessian outbound 081de437afc7:v33"); Thu, 17 Oct 2019 06:13:07 +0000 X-CR-MTA-TID: 64aa7808 Received: from a73eda94a7ef.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.5.56]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 43C323F8-CA3C-4EB2-B96C-B47228D57DE4.1; Thu, 17 Oct 2019 06:13:02 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp2056.outbound.protection.outlook.com [104.47.5.56]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a73eda94a7ef.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 17 Oct 2019 06:13:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q7/uS/a3ZnVWuSnJDSVT1t5jg4Pa9dN0krirX+dyRR+BQ5/WUh2L5JzNW3AjjXexQAa6zg7r3qLX1K4gK8aAyWbh5ehD3Y1RM3YkFrRqebp21L0Y14my0nX85QD0aTRJbd76raWQpUiFU+2wHw49laitfcGvv/7GnqphRH6GQjH64Hr88vxbD0Y0yeKduLMlAuxx+JBYrbzg/lHvpG28RtWPLVjnUxcHbcRGHJwZDO706HJJiE7Kgp2r9YsFFVIq+8esFPb1lVazZZMhr8YNgoE4x5a8UIiWEkd/9R2nI8MEqWOV3Oog1U9Ls1gD2Nr8coeOGWZftFO4zW8J1DvtPA== 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=a5C7CleUjfDIpZCvxslyfLRHoYz+cmI0u8pcXZ2Wiac=; b=dROZDbfsnCDjD8ZHRN1Prqvh2cjrfP5TIjoV4RfExjaAlIE6cI/w8x4XvhWo5qrWuOJQzEuFWMiBiyqjI5cyz8q7ocpgDYzgoRtGHwad4x6xgyfDuzGCarf3qyGIpJ0tFtXRZs+bgpSxproDCuEzoryAiaNE2N/LqEYDYZiMnKuLDG/NlLAUHI24o5jPZI5bz0WeepZd5yyh7tx2X3ReiLNTfjIy/vX0lfXCiVbZhjeVjqJRXnbgsd/C+HmrsvYJjI013NWsak2SqKXyp4ha4ddTTBhNaqjUhtmHBqouKUgymUVBRmvpyvQ8Yfi+jTgCgH3bFCUu/aq1fIsdIa+nwg== 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=a5C7CleUjfDIpZCvxslyfLRHoYz+cmI0u8pcXZ2Wiac=; b=TlkQdG4nrfGwSLzAypYDPPvmjOYZOoTSwtX1D1uX8MF3+QrExXZ4vFZzzO47AAqhv81Rr0x3zWzXa+WOAR+bT5iymzxI0g0AOdluowBwwoF0rfT1aREtrjjVacP4s1hvzz7NgVXP9uEpsMKnP/x8woyhkkb1fXgGnYNzaAhOR0I= Received: from AM0PR08MB5345.eurprd08.prod.outlook.com (52.132.215.213) by AM0PR08MB4578.eurprd08.prod.outlook.com (20.178.22.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Thu, 17 Oct 2019 06:13:00 +0000 Received: from AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::f009:c530:6569:cf6f]) by AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::f009:c530:6569:cf6f%4]) with mapi id 15.20.2347.023; Thu, 17 Oct 2019 06:13:00 +0000 From: Hannes Tschofenig To: Brian Campbell , Lee McGovern CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Virtual Office Hours Thread-Index: AdWD8YULnLl4sPKFSu6UQAym05ITSgAPPuoAACDSONA= Date: Thu, 17 Oct 2019 06:13:00 +0000 Message-ID: References: <482352dd12ed4f5fb2b7992dfe08ca71@CHRP5009.corp.gwpnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 3094a356-ba34-4a8d-ada5-0447d36b172b.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.83] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 5d3dc91b-6af9-4bf9-9bc6-08d752c91510 X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: AM0PR08MB4578:|AM0PR08MB4434: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:4714;OLM:4714; x-forefront-prvs: 01930B2BA8 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(38314003)(189003)(199004)(8936002)(74316002)(446003)(11346002)(53546011)(229853002)(476003)(33656002)(6246003)(9686003)(236005)(26005)(6506007)(99286004)(81156014)(54896002)(6306002)(8676002)(7736002)(486006)(5660300002)(102836004)(71200400001)(71190400001)(6116002)(3846002)(790700001)(81166006)(66446008)(6436002)(25786009)(2906002)(256004)(5024004)(14444005)(52536014)(66066001)(478600001)(316002)(110136005)(76176011)(55016002)(7696005)(76116006)(186003)(966005)(86362001)(14454004)(4326008)(66556008)(66946007)(606006)(66476007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4578; H:AM0PR08MB5345.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: IiYCJLV9rWFE7nftuH4nEb0dHMI1kH/DKauRPU+GnEfH/7ns8P9Qs3Ao6ctlUsXZcd/+bwc5ByFTKBkoSG3x9Sbgcx825JK8TpQUYc3VyDZzSr1ikAnC2CQDhBsXMsQJbj43czGHUgDuJsBzeFckDnZRHVrTcTv5n4c1nOsX+bFr4wT0QRyuFQAiHZFh6JLYL316I2JtgROOZG50LchHzqIVjcAljWplfDcFGdvPlGoWWJYEJGnxTZR0z2sfGLOVdCzIZOkjnyKNRnSONvA2r8VczOq+D//PLyMKtdAoJhuRVu8yl7ZOBsXsyg6k0VB93QXf++7Ncyrtj40hl5kBgP6XiRjiHwMAW/cWd38LAk8WCOu4QfsFtitMLZJH+OW8xD9Bm1IoCslhxoiZ9vspJ+GTM6mpJwtB2H5xmJHn+u7Ek98ODuxR3Nt/7vHuo3h8Y5ZbfRrCwPFAqS7wSgm69g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB53456AF774D5E634A23A8A55FA6D0AM0PR08MB5345eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4578 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT033.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)(39860400002)(346002)(136003)(396003)(376002)(189003)(199004)(40434004)(38314003)(5660300002)(336012)(66066001)(71190400001)(8676002)(55016002)(14454004)(966005)(33656002)(99286004)(63350400001)(790700001)(81166006)(11346002)(81156014)(52536014)(7696005)(6116002)(4326008)(446003)(236005)(6506007)(33964004)(53546011)(76176011)(102836004)(606006)(186003)(8936002)(54896002)(26005)(6246003)(126002)(476003)(9686003)(6306002)(3846002)(486006)(22756006)(7736002)(86362001)(70586007)(70206006)(25786009)(316002)(229853002)(16586007)(74316002)(2906002)(110136005)(26826003)(478600001)(14444005)(356004)(76130400001)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4434; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; 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: beca3e7b-0ad4-47c8-543c-08d752c90fd6 X-Forefront-PRVS: 01930B2BA8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 81uA8Rew8p1f8JJ+5gJwy+f6QUdZ7Tsjnz40sEYBoxXjjjbTA/AkD12ZmAHlqpGb7Cj4qFXr2t7dTMonQUkLICcW8nOAMbSxC/tYhmWcAUW26xdHJrQJBYb/ihv9LSHeOO+aakZvcLg+PpD3DsDEbtti5oynRQDYt7+hESbfSCE7DFP8ayj5ST0hQoa0xERgQACtReCrixgGPKvNNO7/SrhOKe41fZhCA4xzk4IqEix6lXPOqmMLtAcfk23myMfGpJ97abkvgXVsM8ok1kgiDLAmZ+ot5C2jBabdat+TvfYa9itlx5t8yd/fLGW1xK7ZqQ+aCq9z1bhJD0bkFtVIWz7parswsfAPvo8Y4Nogt1I47AgKlUd/a6zN5Vmb3RE0y07YYHtYjNqvshWhu5h3Qg4oaJG4gM6tQD6h/qZBH9TnVKQ4TYMSF32KEf/6sIzc80yyStvIW6uKxYW2DtqILw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2019 06:13:09.0848 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5d3dc91b-6af9-4bf9-9bc6-08d752c91510 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: AM0PR08MB4434 Archived-At: Subject: Re: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Oct 2019 06:13:21 -0000 --_000_AM0PR08MB53456AF774D5E634A23A8A55FA6D0AM0PR08MB5345eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sIEhpIExlZSwNCg0KdGhlIHNlY3JldGFyeSB3aWxsIGRpc3RyaWJ1dGUgdGhlIGlu Zm9ybWF0aW9uIGluIGFuIOKAnG9mZmljaWFsIHdheeKAnS4NCkkgZXhwZWN0IHRoaXMgdG8gaGFw cGVuIGluIHRoZSBuZXh0IGZldyBkYXlzLg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogT0F1dGgg PG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2Vu dDogTWl0dHdvY2gsIDE2LiBPa3RvYmVyIDIwMTkgMTY6MzINClRvOiBMZWUgTWNHb3Zlcm4gPExl ZV9NY0dvdmVybkBzd2lzc3JlLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gVmlydHVhbCBPZmZpY2UgSG91cnMNCg0KVGhlIGNoYWlycyBtaWdodCB3YW50 IHRvIG9yIGJlIGFibGUgdG8gZ2l2ZSBhIG1vcmUgb2ZmaWNpYWwgcmVzcG9uc2UgdG8gdGhpcyBi dXQgdGhlIGxhdGVzdCBtZWV0aW5nIGluZm8gSSdtIGF3YXJlIG9mIHdhcyBzZW50IG91dCBpbiBK YW51YXJ5IGluIHRoaXMgbWVzc2FnZSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL29hdXRoL3Y4c1VNRUJHTUMyNEFkV0xld0F5bVAtWDRrVQ0KDQpPbiBXZWQsIE9jdCAxNiwg MjAxOSBhdCAxOjE2IEFNIExlZSBNY0dvdmVybiA8TGVlX01jR292ZXJuQHN3aXNzcmUuY29tPG1h aWx0bzpMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb20+PiB3cm90ZToNCkhvdyBkb2VzIGEgbmV3Y29t ZXIgZ2V0IHRoZSBtZWV0aW5nIGludml0ZS9kaWFsIGluIGluZm8gZm9yIHRoaXMgY2FsbD8NCg0K VGhpcyBlLW1haWwsIGluY2x1ZGluZyBhdHRhY2htZW50cywgaXMgaW50ZW5kZWQgZm9yIHRoZSBw ZXJzb24ocykgb3IgY29tcGFueSBuYW1lZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZC9vciBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uDQpVbmF1dGhvcml6ZWQgZGlzY2xv c3VyZSwgY29weWluZyBvciB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5sYXdmdWwg YW5kIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCkFsbCBp bmNvbWluZyBhbmQgb3V0Z29pbmcgZS1tYWlsIG1lc3NhZ2VzIGFyZSBzdG9yZWQgaW4gdGhlIFN3 aXNzIFJlIEVsZWN0cm9uaWMgTWVzc2FnZSBSZXBvc2l0b3J5Li4uDQpJZiB5b3UgZG8gbm90IHdp c2ggdGhlIHJldGVudGlvbiBvZiBwb3RlbnRpYWxseSBwcml2YXRlIGUtbWFpbHMgYnkgU3dpc3Mg UmUsIHdlIHN0cm9uZ2x5IGFkdmlzZSB5b3Ugbm90IHRvIHVzZSB0aGUgU3dpc3MgUmUgZS1tYWls IGFjY291bnQgZm9yIGFueSBwcml2YXRlLCBub24tYnVzaW5lc3MgcmVsYXRlZCBjb21tdW5pY2F0 aW9ucy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2ht ZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM0PR08MB53456AF774D5E634A23A8A55FA6D0AM0PR08MB5345eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJy aWFuLCBIaSBMZWUsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgc2VjcmV0YXJ5IHdpbGwg ZGlzdHJpYnV0ZSB0aGUgaW5mb3JtYXRpb24gaW4gYW4g4oCcb2ZmaWNpYWwgd2F54oCdLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGV4cGVjdCB0aGlzIHRvIGhhcHBl biBpbiB0aGUgbmV4dCBmZXcgZGF5cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDE2LiBP a3RvYmVyIDIwMTkgMTY6MzI8YnI+DQo8Yj5Ubzo8L2I+IExlZSBNY0dvdmVybiAmbHQ7TGVlX01j R292ZXJuQHN3aXNzcmUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gVmlydHVhbCBPZmZpY2UgSG91cnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2hhaXJzIG1pZ2h0IHdhbnQg dG8gb3IgYmUgYWJsZSB0byBnaXZlIGEgbW9yZSBvZmZpY2lhbCByZXNwb25zZSB0byB0aGlzIGJ1 dCB0aGUgbGF0ZXN0IG1lZXRpbmcgaW5mbyBJJ20gYXdhcmUgb2Ygd2FzIHNlbnQgb3V0IGluIEph bnVhcnkgaW4gdGhpcyBtZXNzYWdlDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL29hdXRoL3Y4c1VNRUJHTUMyNEFkV0xld0F5bVAtWDRrVSI+DQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL3Y4c1VNRUJHTUMyNEFkV0xld0F5 bVAtWDRrVTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFdlZCwgT2N0IDE2LCAyMDE5IGF0IDE6MTYgQU0gTGVlIE1jR292ZXJuICZsdDs8YSBocmVm PSJtYWlsdG86TGVlX01jR292ZXJuQHN3aXNzcmUuY29tIj5MZWVfTWNHb3Zlcm5Ac3dpc3NyZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgZG9lcyBhIG5ld2NvbWVyIGdl dCB0aGUgbWVldGluZyBpbnZpdGUvZGlhbCBpbiBpbmZvIGZvciB0aGlzIGNhbGw/PHNwYW4gbGFu Zz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERS1DSCI+VGhpcyBlLW1haWws IGluY2x1ZGluZyBhdHRhY2htZW50cywgaXMgaW50ZW5kZWQgZm9yIHRoZSBwZXJzb24ocykgb3Ig Y29tcGFueSBuYW1lZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5 IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERS1DSCI+VW5hdXRob3JpemVkIGRpc2Ns b3N1cmUsIGNvcHlpbmcgb3IgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gbWF5IGJlIHVubGF3ZnVs IGFuZCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0K QWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlLW1haWwgbWVzc2FnZXMgYXJlIHN0b3JlZCBpbiB0 aGUgU3dpc3MgUmUgRWxlY3Ryb25pYyBNZXNzYWdlIFJlcG9zaXRvcnkuLi48YnI+DQpJZiB5b3Ug ZG8gbm90IHdpc2ggdGhlIHJldGVudGlvbiBvZiBwb3RlbnRpYWxseSBwcml2YXRlIGUtbWFpbHMg YnkgU3dpc3MgUmUsIHdlIHN0cm9uZ2x5IGFkdmlzZSB5b3Ugbm90IHRvIHVzZSB0aGUgU3dpc3Mg UmUgZS1tYWlsIGFjY291bnQgZm9yIGFueSBwcml2YXRlLCBub24tYnVzaW5lc3MgcmVsYXRlZCBj b21tdW5pY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_AM0PR08MB53456AF774D5E634A23A8A55FA6D0AM0PR08MB5345eurp_-- From nobody Thu Oct 17 00:13:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61F3120073 for ; Thu, 17 Oct 2019 00:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=zmartzone-eu.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 aX8MWavzAEA2 for ; Thu, 17 Oct 2019 00:13:27 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AAD12001A for ; Thu, 17 Oct 2019 00:13:27 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id u184so959491qkd.4 for ; Thu, 17 Oct 2019 00:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yK/dIcFzoCjYe8esAwrGhL1mBEMx9a8f9UQ1mZRQepk=; b=PiLuLSPsdD/RtnPus4m6pAADdMfeE0gy+AT7Jk/Cb4vsEvkKRfnx+niymrdp/H6mb2 Mo3kk/VzpGXYpsua75O1M/fTNMpGmmyDagEk7DGqTxqQTsFINKcoSC4JarKPDFGGGrQG 2zXAmtpF7BBggbqh1ENmNDUvv4D/GDEYERF5dG+mJ9gjKuxWxb72FVYPsc1Q7NpYtgAH VOtiCm6fk4bd6YzsYd5cJhbAj5QPwRiyN2h70cXd2yuW1DJy48Nxu+MAMb8e1m3VQTRs lnCHhhh+Zhb887F1wnfPiPh8gRWb3bpZNaoX4e5b7xi/If2noDXSRNNMKN//18aqFC1v mapw== 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=yK/dIcFzoCjYe8esAwrGhL1mBEMx9a8f9UQ1mZRQepk=; b=XRzAcJi1uJvtsEzCr/+1DzcAQfccmkJQ/qTJLf8RBhyXPWg3FZpCJ6sbgaIfTbBdfk zqfXPyT88i/yNua8JhvqGjA3RjLtJ+kV+2cjbJW1Avr7F22aiLQzpZodxHnejly6Fg2i t6wSgSCIyR/7Knn6y3y1LYoUQBXQQG5obO4oY0dBwdUvTJOY6YzT18mb4OTfnKPH0fah H/YeZ37AyDzvqUzbP3/aXVsgu3SozZvhIsJRtqGbMuA175yBMbkKl2wuUyeelNJeOPkk LXWVXdV4TK2tidN4Pe9rg4Sq6TsmyCnPkh6njwV/Cl2gGNwIL0+jAnHPig5lAwemwG2+ mXCQ== X-Gm-Message-State: APjAAAXZ2QKqsOa4+aioK1fb+Sp/hCegy0gXnzQG6vCw+q88zivt5h7h pvWKUvLl/sAAbAF3j45H052dteLVJSdUSsYpzI3yRnhu X-Google-Smtp-Source: APXvYqxMQ4icj8Ci0bBu/sh451Ywoy+DTfyyQlOHxEta8LB7Y4HoN8Ak1Mv3WzSFdVCpHE1ujlWX5ucWmV0Tp12D294= X-Received: by 2002:a37:278f:: with SMTP id n137mr1842745qkn.423.1571296406245; Thu, 17 Oct 2019 00:13:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Thu, 17 Oct 2019 09:13:15 +0200 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="00000000000021aae9059515f4f4" Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Oct 2019 07:13:30 -0000 --00000000000021aae9059515f4f4 Content-Type: text/plain; charset="UTF-8" I am interested and should be able to make it. Hans. On Tue, Oct 15, 2019 at 5:45 PM Hannes Tschofenig wrote: > Hi all, > > we would like to hold a virtual interim meeting to discuss the next steps > regarding the OAuth 2.0 Security Best Current Practice ( > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) draft. > > Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:00 > PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, > Vienna). > > Please let us know if you are interested in the call. > > Ciao > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --00000000000021aae9059515f4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am interested and should be able to make it.

Hans.

On Tue, Oct 15, 2019 at 5:45 PM Hannes Tschofenig <Hannes.Tschofenig@arm.com>= ; wrote:
Hi all,=

we would like to hold a virtual interim meeting to discuss the next steps r= egarding the OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/draft-ietf-oauth-secu= rity-topics/) draft.

Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:00 PM= to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna).=

Please let us know if you are interested in the call.

Ciao
Hannes & Rifaat

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

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


--
--00000000000021aae9059515f4f4-- From nobody Thu Oct 17 03:35:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED66F120867 for ; Thu, 17 Oct 2019 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.537 X-Spam-Level: * X-Spam-Status: No, score=1.537 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, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75ArKps5gs1r for ; Thu, 17 Oct 2019 03:35:45 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C40A120866 for ; Thu, 17 Oct 2019 03:35:45 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id m13so1957031ljj.11 for ; Thu, 17 Oct 2019 03:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=SYOzLVrPbtfJS8vajrlNwBQB42Ke0FqIxIvUd6CPlLE=; b=NCyWahpWmKoAC4dvxXKjMBH7//fyWg/Jdz8aLTUNJseU617JxRUBRo/SI+15Mgbej7 JrkaDqnF5/p3rzcw5tHv6Y1k6EMTgD11aMceOoQwiYEQExO/rGoo+tfutN6o1ZvO3OeL E4p+KXRtdhYAFEGn6R7oN1koNKsuiHWfgGFlPKsitgJ98X41YcU3RCL0hbrQYBEnaHud fM7J2KRqc6EC+SNvauD155t5fQxCelHA9yzhvr8aV5JdT1m9AvYK1a4V9H/INnqyVs4x nJod97Xi1YFVItz1FORjCJTrYhk6Uh6u2bYqmPo4gIXLZGx3zhzRna2Od51SsWNfNjo4 2GKg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=SYOzLVrPbtfJS8vajrlNwBQB42Ke0FqIxIvUd6CPlLE=; b=XzVGyWsN1u1aGfcYC/qsH5IAueC1E5uJSjBoibe6r8WpoLSlg9u3aGPx4/gxQBJQNA Oea6NtBndeS6BBMGv1fgrpeB7RZ7vV90bHZZJIxmhepvbfG2854G4wQTIW0LR2nPWJV/ nON0r6WOD79E6PG3NcwhA/f8IowUczCxaAXTrWeKdR5nwDPObqOuYXg1bIHDyzeHamUV iDnJ2F2vpU+nOAFbN9k/8FVm18mDIRqtb6OGbf1ykfQJvhe8D8wV2wB9CLxGXoY+wYpd QFtOJBxu3QH3lHVKiKpSVWU/3SS7e0cASVvB8fniIRP8yOCp0G69znt5f13Uwq8jahFi wQqg== X-Gm-Message-State: APjAAAVn+JfCZ6PcYt/j1Elr8qU1GeDR49qOTcuBub4Nz3V7TAGi5il5 kkSIoWGLYtELhXvzTO4doE2zyaIKIoMGUQ== X-Google-Smtp-Source: APXvYqwsCCzlFBj37uYTSOAv9lLGj5BRuF5oBauo7JGSrhy06YLI438lLR3HMi8ZYUf2OjUG/+Tn7w== X-Received: by 2002:a2e:8505:: with SMTP id j5mr2024516lji.154.1571308543009; Thu, 17 Oct 2019 03:35:43 -0700 (PDT) Received: from [10.93.15.148] ([85.19.219.182]) by smtp.gmail.com with ESMTPSA id o5sm1044998lfn.42.2019.10.17.03.35.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2019 03:35:42 -0700 (PDT) To: oauth@ietf.org References: From: Daniel Fett Message-ID: <726efad4-a76c-c4dd-8a6e-b1097ac519c5@yes.com> Date: Thu, 17 Oct 2019 12:35:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFFB413976BA35D566D021F6" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Oct 2019 10:35:48 -0000 This is a multi-part message in MIME format. --------------EFFB413976BA35D566D021F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I'm in as well. Am 16.10.19 um 22:46 schrieb Mike Jones: > > I would participate. > >   > > *From:* OAuth *On Behalf Of * Vineet Banga > *Sent:* Wednesday, October 16, 2019 7:19 AM > *To:* Aaron Parecki > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th > >   > > I would like to attend as well. > >   > > Vineet > >   > > On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki > wrote: > > I'm interested as well. > >   > > Aaron Parecki > >   > >   > >   > > On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt > > wrote: > > Hi, > > I’m interested. > > kind regards, > Torsten. > > > On 15. Oct 2019, at 17:44, Hannes Tschofenig > > > wrote: > > > > Hi all, > > > > we would like to hold a virtual interim meeting to discuss > the next steps regarding the OAuth 2.0 Security Best Current > Practice > (https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > ) > draft. > > > > Time would be at our bi-weekly OAuth WG Virtual Office Hours > (i.e., 6:00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, > Bern, Rome, Stockholm, Vienna). > > > > Please let us know if you are interested in the call. > > > > Ciao > > Hannes & Rifaat > > > > IMPORTANT NOTICE: The contents of this email and any > attachments are confidential and may also be privileged. If > you are not the intended recipient, please notify the sender > immediately and do not disclose the contents to any other > person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > > ---- > > Aaron Parecki > > aaronparecki.com > > > @aaronpk > > >   > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------EFFB413976BA35D566D021F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm in as well.

Am 16.10.19 um 22:46 schrieb Mike Jones:

I would participate.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Vineet Banga
Sent: Wednesday, October 16, 2019 7:19 AM
To: Aaron Parecki <aaron@parecki.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th

 

I would like to attend as well.

 

Vineet

 

On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki <aaron@parecki.com> wrote:

I'm interested as well.

 

Aaron Parecki

 

 

 

On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt <torsten@lodderstedt..net> wrote:

Hi,

I’m interested.

kind regards,
Torsten.

> On 15. Oct 2019, at 17:44, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next steps regarding the OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) draft.
>
> Time would be at our bi-weekly OAuth WG Virtual Office Hours (i.e., 6:00 PM to 6:30 PM, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna).
>
> Please let us know if you are interested in the call.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--

----

Aaron Parecki

 

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


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


--------------EFFB413976BA35D566D021F6-- From nobody Thu Oct 17 10:18:35 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC98120B55; Thu, 17 Oct 2019 10:18:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157133271343.10206.12697042949233111458@ietfa.amsl.com> Date: Thu, 17 Oct 2019 10:18:33 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2019-11-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 17:18:34 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2019-11-04 from 18:00 to 19:00 Europe/Vienna. Agenda: The purpose of the meeting is to discuss the next steps regarding the OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/) draft. While our OAuth WG Virtual Office Hours is only 30 minutes long, I have extended the meeting invite to an one hour (in case we need more time). Webex info: https://ietf.webex.com/ietf/j.php?MTID=ma9109b49231ef3fee527bbc24b6a285b Meeting number (access code): 643 148 548 Host key: 317086 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=ma9109b49231ef3fee527bbc24b6a285b From nobody Fri Oct 18 18:44:03 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54E120105; Fri, 18 Oct 2019 18:44:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, hannes.tschofenig@arm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157144944157.4000.14542028166053199709.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2019 18:44:01 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-jwt-bcp-07: (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, 19 Oct 2019 01:44:02 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-07: Yes 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-bcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment) points! From nobody Sun Oct 20 19:05:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D16E120074 for ; Sun, 20 Oct 2019 19:05:55 -0700 (PDT) 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 h9Q0A38U1INq for ; Sun, 20 Oct 2019 19:05:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E0312006B for ; Sun, 20 Oct 2019 19:05:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9L25kug013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 20 Oct 2019 22:05:49 -0400 Date: Sun, 20 Oct 2019 19:05:46 -0700 From: Benjamin Kaduk To: Travis Spencer Cc: Torsten Lodderstedt , oauth Message-ID: <20191021020546.GZ43312@kduck.mit.edu> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> 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] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 02:05:55 -0000 Just on one narrow point: On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote: > On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt > > Open: How would one implement sender constrained access tokens in that case? I’m asking since the receiving RS obviously has no access to the information from the TLS handshake since TLS termination happens at the proxy (or even in before the request hits the proxy). The RS would need to get provided with the cert fingerprint via a trustworthy header, i.e. the RS must be aware of the fact it sits behind a proxy. > > This is unfortunately the typical case even with the mTLS draft. This > is because SSL is almost never terminated by the AS; in my experience, > TLS termination is instead handled by some very fast proxy.[1] In such > cases, the proxy will pass the cert through to the AS in some > undefined HTTP header with some undefined encoding. The mTLS spec > should have defined this IMO, as it prevents interop for a primary use > case -- sender constrained tokens. It's not clear to me that mTLS should have defined a protocol from proxy to backend; that seems like it could be a fairly generic thing and I know of several people that are working on similar things, to one degree or another. draft-schwartz-tls-lb is the example that I can most easily find in my archives; though it's working with non-TLS-terminating cases, there is probably some commonality with TLS-terminating cases as well. -Ben From nobody Mon Oct 21 08:50:39 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0B1200B9; Mon, 21 Oct 2019 08:50:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, draft-ietf-oauth-jwt-bcp@ietf.org, The IESG , Hannes Tschofenig , oauth@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157167303740.31854.3658812972923333005.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2019 08:50:37 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'JSON Web Token Best Current Practices' to Best Current Practice (draft-ietf-oauth-jwt-bcp-07.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 15:50:38 -0000 The IESG has approved the following document: - 'JSON Web Token Best Current Practices' (draft-ietf-oauth-jwt-bcp-07.txt) as Best Current Practice This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ Technical Summary JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. Working Group Summary This document has been written in response to reports about insecure implementations and deployments of JWT. The working group is in agreement that this document provides value to the community. Document Quality The document has received substantial review and suggestions for threat mitigations to cover. Many of the recommendations have been provided by researchers and implementers outside the working group. Personnel The document shepherd is Hannes Tschofenig. The responsible Area Director is Roman Danyliw (and was previously Eric Rescorla). From nobody Mon Oct 21 17:52:06 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E80120048; Mon, 21 Oct 2019 17:51:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <157170551775.11688.10400044483062776745@ietfa.amsl.com> Date: Mon, 21 Oct 2019 17:51:57 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-20.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, 22 Oct 2019 00:51:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-20.txt Pages : 31 Date : 2019-10-21 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 22 09:43:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A342312009E for ; Tue, 22 Oct 2019 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hWK6KHtqenMY for ; Tue, 22 Oct 2019 09:43:18 -0700 (PDT) Received: from p3plsmtpa11-03.prod.phx3.secureserver.net (p3plsmtpa11-03.prod.phx3.secureserver.net [68.178.252.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B83712004A for ; Tue, 22 Oct 2019 09:43:18 -0700 (PDT) Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id MxFaicVvieKc0MxFciZbph; Tue, 22 Oct 2019 09:43:17 -0700 To: oauth@ietf.org References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <53D85F85-3203-4E36-8A8E-B0FC9AB3D1AE@mit.edu> <5F376EBC-866B-4E06-AEA9-0FFCB3625074@mit.edu> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Organization: Connect2id Ltd. Message-ID: <6cc98c4b-2ec6-1823-f4ba-54c14b49eced@connect2id.com> Date: Tue, 22 Oct 2019 19:43:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5F376EBC-866B-4E06-AEA9-0FFCB3625074@mit.edu> Content-Type: multipart/alternative; boundary="------------B1F5927A64FD1E249A7C8CA4" Content-Language: en-US X-CMAE-Envelope: MS4wfEoNO0UapKwMOCgXMOLH1h0o/ids7pyuREnJBUiKVWhjmFGCyWGa3eF51eB7nBle7GgsE51fMvEdBA7irgM7CU9OHr8zfXaEyDKsvGWfdLNJecGKYFMk +1bujY36gIHx1I/iHAabBiG+W5/tUg58gQKqm7NFSlm8WMzAy8geuUp/ Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 16:43:23 -0000 This is a multi-part message in MIME format. --------------B1F5927A64FD1E249A7C8CA4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you Justin for pointing this out. We had the exact same issue when we implemented encrypted JAR  - and ended up requiring the client_id. In the absence of a client_id as top level parameter symmetric encryption cannot be handled because there's no good way to find out the client_client secret (unless we try all possible secrets, which is not feasible). We also have a policy to require_request_uri_registration=true and to avoid creating indices also require the client_id for request_uri requests. Vladimir On 10/10/2019 20:01, Justin Richer wrote: > In a related note, JAR currently allows “client_id” to be optional for > exactly the reason of it being included in the request object. > However, it falls into the same issue where you can’t decrypt the > request object without knowing which client’s keys to use, and you > can’t know which client you’re dealing with without decrypting the > object. I think that probably needs to be addressed in JAR. > > — Justin > >> On Oct 10, 2019, at 12:59 PM, Justin Richer > > wrote: >> >> Thanks for the response. My concern is that interpretation of the >> requirement to “authenticate the client” could be interpreted in the >> FAPI draft’s sense, which is to say validating the signature on the >> request object and not doing anything else.  >> >> The problem comes from the fact that we’re effectively smashing >> together the conditions and assumptions of both the authorization >> endpoint and token endpoint into a new endpoint. It’s going to be >> messy, and we need to be very pedantic about what we mean if this >> draft is going to be implementable.  >> >> — Justin >> >>> On Oct 10, 2019, at 3:07 AM, Filip Skokan >> > wrote: >>> >>> > If several of these are sent, they need to be consistent. >>> >>> Given that client authentication precedes processing the rest of the >>> request, if several client authentication methods are provided >>> (header + secret or secret + assertion, etc) you generally reject >>> the request, don't you? >>> >>> Then there's the requirement for the client_id given by >>> authentication method (none is still an "authentication" method - >>> client_id in the body) to match the `iss` and `client_id` in the >>> request object. That's already required by JAR processing rules and >>> also PAR. >>> >>> > But because JAR allows you to send in a request that is only a >>> request object, it also seems like you could pass in just the >>> request object with no other parameters, if I’m reading this right, >>> which would imply that you could be expected to glean the client ID >>> from the request object itself without it being in either a >>> parameter or in another part of the request that’s easily accessed.  >>> >>> It was only in the original FAPI revision of PAR that allowed the >>> request object's signature to substitute client authentication, in >>> the individual draft published to IETF that's not the case anymore - >>> hence if "only" a request object is passed - with no client >>> authentication (header, client_id in body, mtls) you fail the request. >>> >>> As far as requiring client_id, here's what my implementation does >>> >>> > When providing form-encoded parameters - client_id must be present >>> in the form. >>> > When providing signed/encrypted request object - client_id must be >>> present in the request object. >>> >>> I wouldn't mind always requiring client_id, and i'm not worried >>> about it not matching e.g. the authorization header because the >>> client authentication middleware in place already takes care of that. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 10 Oct 2019 at 03:13, Justin Richer >> > wrote: >>> >>> So in doing an implementation of this, I ran into this problem >>> as well. Specifically, we need to know which client we’re >>> dealing with to fully validate the encrypted request object as >>> well as perform the authentication. Currently, things are a >>> little underspecified, and part of that comes from the history >>> of this document: in the previous FAPI spec, the (required) >>> signature of the request object acted as de-facto authentication >>> for the client. In PAR, we not only can’t rely on the request >>> itself being signed, we also require handling of client >>> authentication in its many forms. That means the client ID could >>> show up in any combination of: >>> >>>  - Form parameter >>>  - Authorization header >>>  - Client assertion’s “iss" field >>>  - Request object’s “client_id” (and “iss”) field >>> >>> If several of these are sent, they need to be consistent. And >>> whatever value comes out needs to be consistent with the >>> client’s authentication method. >>> >>> But because JAR allows you to send in a request that is only a >>> request object, it also seems like you could pass in just the >>> request object with no other parameters, if I’m reading this >>> right, which would imply that you could be expected to glean the >>> client ID from the request object itself without it being in >>> either a parameter or in another part of the request that’s >>> easily accessed.  >>> >>> So herein lies the problem. In order to properly process the >>> request object, you need to know which client you’re dealing >>> with so you can validate the signing algs, keys, and all that. >>> For signed requests that’s simple enough — parse in one step, >>> then authenticate the client, then validate the signatures. But >>> for encrypted JWTs it’s less clear: some methods would use only >>> the server’s public key, but symmetric encryption >>> algorithm/encoding pairs would use the client secret as the >>> pairwise secret for the encryption. Which means that we need to >>> know which client sent the request before the decryption happens.  >>> >>> Which in turn implies one of two things are true: >>> >>>  - You can’t do a request object when it’s encrypted using a >>> symmetric algorithm >>>  - You have to require the client ID from some other part of the >>> request, such as a form parameter, auth header, or client >>> assertion; the client_id in the request object cannot be counted >>> on as being sufficient >>> >>> In our current draft implementation of PAR, I’m turning off >>> support for symmetric encryption in this one code path. If we >>> can somehow count on being able to find a client_id every time, >>> then we can refactor our implementation to parse and handle all >>> the client stuff :before: handling the request object itself. In >>> other words, if I always have to send something that identifies >>> the client in addition to the request object, then I can count >>> on that. >>> >>> Thoughts? >>> >>> — Justin >>> >>>> On Sep 30, 2019, at 11:21 AM, Brian Campbell >>>> >>> > wrote: >>>> >>>> >>>> >>>> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki >>>> > wrote: >>>> >>>> > Depending on client type and authentication method, the >>>> request might >>>> >   also include the "client_id" parameter. >>>> >>>> I assume this is hinting at the difference between public >>>> clients >>>> sending only the "client_id" parameter and confidential clients >>>> sending only the HTTP Basic Authorization header which >>>> includes both >>>> the client ID and secret? It would probably be helpful to >>>> call out >>>> these two common examples if I am understanding this correctly, >>>> otherwise it seems pretty vague. >>>> >>>> >>>> What this is trying to convey is that because client >>>> authentication at this Pushed Authorization Request Endpoint >>>> happens the same way as at the token endpoint (and other >>>> endpoints called directly by the client) the client_id >>>> parameter will sometimes be present but not necessarily as some >>>> types of client auth use the client_id parameter (none, >>>> client_secret_post, tls_client_auth, >>>> self_signed_tls_client_auth) and some don't >>>> (client_secret_basic, client_secret_jwt, private_key_jwt). >>>> >>>> Although the draft does later say "The AS MUST validate the >>>> request the same way as at the authorization endpoint" which I >>>> think could reasonably be interpreted as requiring client_id.  >>>> e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1 >>>> & >>>> https://tools.ietf.org/html/rfc6749?#section-4.2.1 >>>> >>>> So perhaps the sentence in question should be removed and have >>>> client_id be a required parameter at the PAR endpoint. >>>> >>>> >>>> /CONFIDENTIALITY NOTICE: This email may contain confidential >>>> and privileged material for the sole use of the intended >>>> recipient(s). Any review, use, distribution or disclosure by >>>> others is strictly prohibited..  If you have received this >>>> communication in error, please notify the sender immediately by >>>> e-mail and delete the message and any file attachments from >>>> your computer. Thank >>>> you./_______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf --------------B1F5927A64FD1E249A7C8CA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you Justin for pointing this out. We had the exact same issue when we implemented encrypted JAR  - and ended up requiring the client_id. In the absence of a client_id as top level parameter symmetric encryption cannot be handled because there's no good way to find out the client_client secret (unless we try all possible secrets, which is not feasible).

We also have a policy to require_request_uri_registration=true and to avoid creating indices also require the client_id for request_uri requests.

Vladimir

On 10/10/2019 20:01, Justin Richer wrote:
In a related note, JAR currently allows “client_id” to be optional for exactly the reason of it being included in the request object. However, it falls into the same issue where you can’t decrypt the request object without knowing which client’s keys to use, and you can’t know which client you’re dealing with without decrypting the object. I think that probably needs to be addressed in JAR.

— Justin

On Oct 10, 2019, at 12:59 PM, Justin Richer <jricher@mit.edu> wrote:

Thanks for the response. My concern is that interpretation of the requirement to “authenticate the client” could be interpreted in the FAPI draft’s sense, which is to say validating the signature on the request object and not doing anything else. 

The problem comes from the fact that we’re effectively smashing together the conditions and assumptions of both the authorization endpoint and token endpoint into a new endpoint. It’s going to be messy, and we need to be very pedantic about what we mean if this draft is going to be implementable. 

— Justin

On Oct 10, 2019, at 3:07 AM, Filip Skokan <panva.ip@gmail.com> wrote:

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the request, if several client authentication methods are provided (header + secret or secret + assertion, etc) you generally reject the request, don't you?

Then there's the requirement for the client_id given by authentication method (none is still an "authentication" method - client_id in the body) to match the `iss` and `client_id` in the request object. That's already required by JAR processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request object, it also seems like you could pass in just the request object with no other parameters, if I’m reading this right, which would imply that you could be expected to glean the client ID from the request object itself without it being in either a parameter or in another part of the request that’s easily accessed. 

It was only in the original FAPI revision of PAR that allowed the request object's signature to substitute client authentication, in the individual draft published to IETF that's not the case anymore - hence if "only" a request object is passed - with no client authentication (header, client_id in body, mtls) you fail the request.

As far as requiring client_id, here's what my implementation does

> When providing form-encoded parameters - client_id must be present in the form.
> When providing signed/encrypted request object - client_id must be present in the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it not matching e.g. the authorization header because the client authentication middleware in place already takes care of that.

S pozdravem,
Filip Skokan


On Thu, 10 Oct 2019 at 03:13, Justin Richer <jricher@mit.edu> wrote:
So in doing an implementation of this, I ran into this problem as well. Specifically, we need to know which client we’re dealing with to fully validate the encrypted request object as well as perform the authentication. Currently, things are a little underspecified, and part of that comes from the history of this document: in the previous FAPI spec, the (required) signature of the request object acted as de-facto authentication for the client. In PAR, we not only can’t rely on the request itself being signed, we also require handling of client authentication in its many forms. That means the client ID could show up in any combination of:

 - Form parameter
 - Authorization header
 - Client assertion’s “iss" field
 - Request object’s “client_id” (and “iss”) field

If several of these are sent, they need to be consistent. And whatever value comes out needs to be consistent with the client’s authentication method.

But because JAR allows you to send in a request that is only a request object, it also seems like you could pass in just the request object with no other parameters, if I’m reading this right, which would imply that you could be expected to glean the client ID from the request object itself without it being in either a parameter or in another part of the request that’s easily accessed. 

So herein lies the problem. In order to properly process the request object, you need to know which client you’re dealing with so you can validate the signing algs, keys, and all that. For signed requests that’s simple enough — parse in one step, then authenticate the client, then validate the signatures. But for encrypted JWTs it’s less clear: some methods would use only the server’s public key, but symmetric encryption algorithm/encoding pairs would use the client secret as the pairwise secret for the encryption. Which means that we need to know which client sent the request before the decryption happens. 

Which in turn implies one of two things are true:

 - You can’t do a request object when it’s encrypted using a symmetric algorithm
 - You have to require the client ID from some other part of the request, such as a form parameter, auth header, or client assertion; the client_id in the request object cannot be counted on as being sufficient

In our current draft implementation of PAR, I’m turning off support for symmetric encryption in this one code path. If we can somehow count on being able to find a client_id every time, then we can refactor our implementation to parse and handle all the client stuff :before: handling the request object itself. In other words, if I always have to send something that identifies the client in addition to the request object, then I can count on that.

Thoughts?

— Justin

On Sep 30, 2019, at 11:21 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:



On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki <aaron@parecki.com> wrote:
> Depending on client type and authentication method, the request might
>   also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

What this is trying to convey is that because client authentication at this Pushed Authorization Request Endpoint happens the same way as at the token endpoint (and other endpoints called directly by the client) the client_id parameter will sometimes be present but not necessarily as some types of client auth use the client_id parameter (none, client_secret_post, tls_client_auth, self_signed_tls_client_auth) and some don't (client_secret_basic, client_secret_jwt, private_key_jwt).

Although the draft does later say "The AS MUST validate the request the same way as at the authorization endpoint" which I think could reasonably be interpreted as requiring client_id.  e.g., https://tools.ietf.org/html/rfc6749?#section-4..1.1 & https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_id be a required parameter at the PAR endpoint.


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

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

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


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

--------------B1F5927A64FD1E249A7C8CA4-- From nobody Tue Oct 22 16:37:29 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC379120152 for ; Tue, 22 Oct 2019 16:37:26 -0700 (PDT) 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 wrKR5049CT7a for ; Tue, 22 Oct 2019 16:37:24 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650124.outbound.protection.outlook.com [40.107.65.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE0D12006A for ; Tue, 22 Oct 2019 16:37:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=alTcShy/eJRs+qVoFzHyf+3efX+jScLhopO0sMuKrUv8GIdP37JJcHo4x3EIii1QspDKMvPc8uEmz4714W2l04e1Jpbeb9Tr9b3ZkSrCDqt81ML/XPIj4FjBnzr1ObpBDKI6hrr3O3E5Tvlmg+hw/PS2TCAuBtWFmLWQca+3NBYkAehXsCENJP9zCxutKcPGoTDUYhuMDzWORP4blOj3WhrPk1/YYIcaE+8U9mmDWVqPSDF3czy25eruTppJmWWD0PvZp4LJNnMA9e5NRBF1QCwmZYXJ5unyu4vxqzC7XIGV+tAg9rFKenCV+nvQykIgp8r2GvgQJy68NlPiZVrp7g== 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=KnkJrO35K3Dhs4/c4lV3R6B9O6/dlL9YbrJ5dZgD70w=; b=jUJn3ArwKvAaJLnO4ehpKIrxqvPzFEpi3zQVjgEB85jKIUSRvmYNw4z23eRyvUi0r4Ma1DHbPAgAGxCIhumylR7bS22VxmU7LmiHeuHQd2J1yorMNFKZ3tD9bfycfeibTpHwtkr4YFwGyMMdKP/VouhIW23ZeEHjMj89u/LQiJAaUEUXeiyq0m/uHyqkX7hYSug0CIBsL4oUS8HcryMW8qj13J4pvwRCuBCf8IXvVECuWCp+cwZXKai3D54RF9tKJ+S90h1nM41FD0vLhWrz7+GkRYLGKffCgO2IzAQ1U0ButYqm5BCJTj69LuQpQpvcQPbQ+3Iw0e4MeGUZZLloaQ== 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=KnkJrO35K3Dhs4/c4lV3R6B9O6/dlL9YbrJ5dZgD70w=; b=SihLoW9KhkPITIiGN+ANeoZliryqrmoGB0EfFRIBfFWAPAf9sNu+UEWfI31ENQEUAZBFRkO1+s1AW+lhlYczhFaSHTpbNGCOSUpiULMEZRFPQvE9hTcQsBJvI3BYfPHI1+mG0xj6yCRfIbMcH6EmXDc1olFvMktxWH+bv2xLQOE= Received: from MN2PR00MB0574.namprd00.prod.outlook.com (20.178.255.147) by MN2PR00MB0558.namprd00.prod.outlook.com (20.178.255.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2418.0; Tue, 22 Oct 2019 23:37:22 +0000 Received: from MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::9045:7aad:269b:eb01]) by MN2PR00MB0574.namprd00.prod.outlook.com ([fe80::9045:7aad:269b:eb01%8]) with mapi id 15.20.2425.000; Tue, 22 Oct 2019 23:37:22 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JSON Web Token Best Current Practices sent to the RFC Editor Thread-Index: AdWJME9LD3rjQ6NpQ0C4kW1Vhkt1bw== Date: Tue, 22 Oct 2019 23:37:21 +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=274a692e-96e8-4aac-8705-0000a62b3254; 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=2019-10-22T23:27:43Z; 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:f46e:6954:41c7:f992] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 02e0349c-6ead-4ddc-18b2-08d75748c939 x-ms-traffictypediagnostic: MN2PR00MB0558: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(209900001)(199004)(189003)(256004)(14444005)(476003)(7696005)(966005)(186003)(606006)(46003)(14454004)(486006)(6506007)(21615005)(66574012)(99286004)(25786009)(790700001)(102836004)(7736002)(6116002)(74316002)(2906002)(478600001)(10290500003)(86362001)(9686003)(8990500004)(55016002)(236005)(6306002)(54896002)(8936002)(6436002)(1730700003)(81156014)(8676002)(5640700003)(81166006)(316002)(10090500001)(2351001)(22452003)(76116006)(52536014)(33656002)(66446008)(66946007)(66476007)(6916009)(66556008)(2501003)(5660300002)(71200400001)(71190400001)(64756008)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0558; H:MN2PR00MB0574.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: nRj8BFPrJoRoUd37Wza6qJoPbj9jc7swEZugxjgMltVsOASSGsikZSxj35+qjtQG+RZZDxn/uqWOZ7LllmK0MbKBu6cX99t/mVW/GKIvJySEEf8uynjjrjDqoxyVT5w1N/F6hgC8AMXfSx9bYWnNof7RffwRPH23PCMv6ucYOlhgekxJTlnfUqQWTdWwseWRU+CcbQYgS0CLSjGMKfvyZLMT28X6PivAy/aScapIDVCBc8V+38K3K2wLDD+CI/JzOPDZcod+XY8+5ijDBvHAyOxQrAgc8NAg9rdpdguBe9JAVd8QYQSzajVn2lA0vmCQaQdpzuNG7Ot+r/fthGBcOKa2uvrrv70sc1P9HcAPmlYRJggA7nT6O8tJLwmZ21AS7T/LMpFbfdGRZxxDLi7S6oV/tKTpe+6sRUlLh2Kl1m26eZFkwxyCEUy7B4W/z17b x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB05740FA9132A20C134688BF1F5680MN2PR00MB0574namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02e0349c-6ead-4ddc-18b2-08d75748c939 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 23:37:21.9949 (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: G6gr4zn7PBr46E845csf2jL83EFjcvBYzSOc1O4HJPQWBBE371a2J0TatByhhgSNq5RbxrMMZlgDH8FsHUuEGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0558 Archived-At: Subject: [OAUTH-WG] JSON Web Token Best Current Practices sent to the RFC Editor X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Oct 2019 23:37:27 -0000 --_000_MN2PR00MB05740FA9132A20C134688BF1F5680MN2PR00MB0574namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm pleased to report that the JSON Web Token (JWT) Best Current Practices = (BCP) specification is now technically stable and will shortly be an RFC - = an Internet standard. Specifically, it has now progressed to the RFC Edito= r queue, meaning that the only remaining step before finalization is editor= ial due diligence. Thus, implementations can now utilize the draft specifi= cation with confidence that that breaking changes will not occur as it is f= inalized. The abstract of the specification is: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security token= s that contain a set of claims that can be signed and/or encrypted. JWTs ar= e being widely used and deployed as a simple security token format in numer= ous protocols and applications, both in the area of digital identity, and i= n other application areas. The goal of this Best Current Practices document= is to provide actionable guidance leading to secure implementation and dep= loyment of JWTs. Thanks to the OAuth working group for completing this important specification. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-07.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D2020 and as= @selfissued. --_000_MN2PR00MB05740FA9132A20C134688BF1F5680MN2PR00MB0574namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m pleased to report that the JSON Web Token = (JWT) Best Current Practices (BCP) specification is now technically stable = and will shortly be an RFC – an Internet standard.  Specifically= , it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligenc= e.  Thus, implementations can now utilize the draft specification with= confidence that that breaking changes will not occur as it is finalized.

 

The abstract of the specification is:

JSON Web Tokens, al= so known as JWTs, are URL-safe JSON-based security tokens that contain a se= t of claims that can be signed and/or encrypted. JWTs are being widely used= and deployed as a simple security token format in numerous protocols and applications, both in the area of digital= identity, and in other application areas. The goal of this Best Current Pr= actices document is to provide actionable guidance leading to secure implem= entation and deployment of JWTs.

 

Thanks to the OAuth working group for completing this important specification.

 

The specification is available at:

--_000_MN2PR00MB05740FA9132A20C134688BF1F5680MN2PR00MB0574namp_-- From nobody Wed Oct 23 05:11:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DB9120837 for ; Wed, 23 Oct 2019 05:11:30 -0700 (PDT) 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=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 aFOFMGd8sHo6 for ; Wed, 23 Oct 2019 05:11:27 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866BB120815 for ; Wed, 23 Oct 2019 05:11:27 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id u22so2838509lji.7 for ; Wed, 23 Oct 2019 05:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qu+nAApTvA5AnN1mDhhdfayx0Ac8pHfTWkC29jwIkD0=; b=LM0d+v5fS1DRNwVjm0YFEegvjTjHcui7j6zRBeFsJk12w/faARXrtjQi4hvZGB32TC U277/oOXK8YY7+qM7daPz+vgrUOMQ44pCUBX8iShjjwEJ2tRemMJ+HHDZbvx80JUEEVS 4ibGY5r6QgVqKWPLf2pw0U9w5T0+r4HTTKcqI= 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=qu+nAApTvA5AnN1mDhhdfayx0Ac8pHfTWkC29jwIkD0=; b=VPfbi+p/vOroAjy39NRCBUjon3870dgOY+yB+/S47pPJvLQbejGI6pOEfRv4RxnBAn gb/ga5Q9003pj7QRztM7m5zbUjh5hM+hqSl0hc+v5vZgSLfeDW7s6+vqtOQuDJIOzdZq iWhT+OCVz6UiZZbfk5U1QbBRRsuDLEJOPWvIcXkaZ5rbcdWItdTIQ7xBD2dZ94ElU/la +XEljQdDtbz6h0DcfkL666cxfTTJa2lS+MvS7dt/Hd7gaQl9ypppdECRwSOUBsHRncTL DHPAHnEFhnu+1dhqE/QVTgpB5zD6RYAtj+7E5or91GuQDqP+otYQBgimX6YrXeR0ROSC +RjQ== X-Gm-Message-State: APjAAAXeUzj02FsTR+6aOdIcRa4zCuqFKNJ46YnDvb3uZql8SY4+MB5k lsSnRm0m5/2OKp6xF0D4LRTaBjePwNN8jEtGpEfs6SDgokmWz0JAk+uymy6P+EyJOMyhjaf/8bd jm62oCduxEKJLcg== X-Google-Smtp-Source: APXvYqy1/VfT/2uAk5MQdvPvwVA90QIKKFjN8i2Hj1ITELto+u28w5obqac3XERlq2unno3xvdorpIX9t5S6Mn8i9nc= X-Received: by 2002:a2e:8204:: with SMTP id w4mr22344439ljg.3.1571832685504; Wed, 23 Oct 2019 05:11:25 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> In-Reply-To: <20191021020546.GZ43312@kduck.mit.edu> From: Brian Campbell Date: Wed, 23 Oct 2019 06:10:59 -0600 Message-ID: To: Benjamin Kaduk Cc: Travis Spencer , oauth Content-Type: multipart/alternative; boundary="000000000000ddd32f059592d09b" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 12:11:30 -0000 --000000000000ddd32f059592d09b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Ben here that it's not at all clear that the OAuth MTLS document should have defined a protocol from proxy to backend. I'd go so far as to say it's well outside the scope of the document and even the working group. Admittedly It would be nice if such a thing existed but it would have much wider applicability than one narrow profile of OAuth. On Sun, Oct 20, 2019 at 8:06 PM Benjamin Kaduk wrote: > Just on one narrow point: > > On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote: > > On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt > > > Open: How would one implement sender constrained access tokens in tha= t > case? I=E2=80=99m asking since the receiving RS obviously has no access t= o the > information from the TLS handshake since TLS termination happens at the > proxy (or even in before the request hits the proxy). The RS would need t= o > get provided with the cert fingerprint via a trustworthy header, i.e. the > RS must be aware of the fact it sits behind a proxy. > > > > This is unfortunately the typical case even with the mTLS draft. This > > is because SSL is almost never terminated by the AS; in my experience, > > TLS termination is instead handled by some very fast proxy.[1] In such > > cases, the proxy will pass the cert through to the AS in some > > undefined HTTP header with some undefined encoding. The mTLS spec > > should have defined this IMO, as it prevents interop for a primary use > > case -- sender constrained tokens. > > It's not clear to me that mTLS should have defined a protocol from proxy = to > backend; that seems like it could be a fairly generic thing and I know of > several people that are working on similar things, to one degree or > another. draft-schwartz-tls-lb is the example that I can most easily fin= d > in my archives; though it's working with non-TLS-terminating cases, there > is probably some commonality with TLS-terminating cases as well. > > -Ben > > _______________________________________________ > 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._ --000000000000ddd32f059592d09b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Ben here that it's not at all clear that = the OAuth MTLS document should have defined a protocol from proxy to backen= d. I'd go so far as to say it's well outside the scope of the docum= ent and even the working group. Admittedly It would be nice if such a thing= existed but it would have much wider applicability than one narrow profile= of OAuth.

On Sun, Oct 20, 2019 at 8:06 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Just on one narrow= point:

On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in= that case? I=E2=80=99m asking since the receiving RS obviously has no acce= ss to the information from the TLS handshake since TLS termination happens = at the proxy (or even in before the request hits the proxy). The RS would n= eed to get provided with the cert fingerprint via a trustworthy header, i.e= . the RS must be aware of the fact it sits behind a proxy.
>
> This is unfortunately the typical case even with the mTLS draft. This<= br> > is because SSL is almost never terminated by the AS; in my experience,=
> TLS termination is instead handled by some very fast proxy.[1] In such=
> cases, the proxy will pass the cert through to the AS in some
> undefined HTTP header with some undefined encoding. The mTLS spec
> should have defined this IMO, as it prevents interop for a primary use=
> case -- sender constrained tokens.

It's not clear to me that mTLS should have defined a protocol from prox= y to
backend; that seems like it could be a fairly generic thing and I know of several people that are working on similar things, to one degree or
another.=C2=A0 draft-schwartz-tls-lb is the example that I can most easily = find
in my archives; though it's working with non-TLS-terminating cases, the= re
is probably some commonality with TLS-terminating cases as well.

-Ben

_______________________________________________
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. --000000000000ddd32f059592d09b-- From nobody Wed Oct 23 07:13:19 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB21201EA for ; Wed, 23 Oct 2019 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEhp528t6uo7 for ; Wed, 23 Oct 2019 07:13:16 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B63412082E for ; Wed, 23 Oct 2019 07:13:16 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x9NED20W021807; Wed, 23 Oct 2019 10:13:15 -0400 Received: from oc11expo8.exchange.mit.edu (18.9.4.13) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 23 Oct 2019 10:12:59 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo8.exchange.mit.edu (18.9.4.13) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 Oct 2019 10:13:04 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 23 Oct 2019 10:13:04 -0400 From: Justin Richer To: Brian Campbell CC: Benjamin J Kaduk , oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt Thread-Index: AQHVfEpgATAtVF2gR02iNTFB3cSWYKddpSkAgAcNagCAA83CgIAAIhuA Date: Wed, 23 Oct 2019 14:13:04 +0000 Message-ID: <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [212.123.202.115] Content-Type: multipart/alternative; boundary="_000_8A8B88929D164210BC1347B5D7859976mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 14:13:18 -0000 --_000_8A8B88929D164210BC1347B5D7859976mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlLiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBnZXQgdGhpcyBwdXNoZWQgdG8g aHR0cCBvciB0bHM/IEl0IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgdGhlcmUsIGFuZCB2ZXJ5 IGhlbHBmdWwgdG8gaGF2ZSBhIGdlbmVyYWwgc3BlYyBmb3IgdGhpcy4NCg0K4oCUIEp1c3Rpbg0K DQpPbiBPY3QgMjMsIDIwMTksIGF0IDI6MTAgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9 NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpiY2FtcGJlbGw9NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBCZW4g aGVyZSB0aGF0IGl0J3Mgbm90IGF0IGFsbCBjbGVhciB0aGF0IHRoZSBPQXV0aCBNVExTIGRvY3Vt ZW50IHNob3VsZCBoYXZlIGRlZmluZWQgYSBwcm90b2NvbCBmcm9tIHByb3h5IHRvIGJhY2tlbmQu IEknZCBnbyBzbyBmYXIgYXMgdG8gc2F5IGl0J3Mgd2VsbCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGUgZG9jdW1lbnQgYW5kIGV2ZW4gdGhlIHdvcmtpbmcgZ3JvdXAuIEFkbWl0dGVkbHkgSXQgd291 bGQgYmUgbmljZSBpZiBzdWNoIGEgdGhpbmcgZXhpc3RlZCBidXQgaXQgd291bGQgaGF2ZSBtdWNo IHdpZGVyIGFwcGxpY2FiaWxpdHkgdGhhbiBvbmUgbmFycm93IHByb2ZpbGUgb2YgT0F1dGguDQoN Ck9uIFN1biwgT2N0IDIwLCAyMDE5IGF0IDg6MDYgUE0gQmVuamFtaW4gS2FkdWsgPGthZHVrQG1p dC5lZHU8bWFpbHRvOmthZHVrQG1pdC5lZHU+PiB3cm90ZToNCkp1c3Qgb24gb25lIG5hcnJvdyBw b2ludDoNCg0KT24gV2VkLCBPY3QgMTYsIDIwMTkgYXQgMDQ6MjM6NTZQTSArMDIwMCwgVHJhdmlz IFNwZW5jZXIgd3JvdGU6DQo+IE9uIFN1biwgT2N0IDYsIDIwMTkgYXQgMzozMSBQTSBUb3JzdGVu IExvZGRlcnN0ZWR0DQo+ID4gT3BlbjogSG93IHdvdWxkIG9uZSBpbXBsZW1lbnQgc2VuZGVyIGNv bnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgaW4gdGhhdCBjYXNlPyBJ4oCZbSBhc2tpbmcgc2luY2Ug dGhlIHJlY2VpdmluZyBSUyBvYnZpb3VzbHkgaGFzIG5vIGFjY2VzcyB0byB0aGUgaW5mb3JtYXRp b24gZnJvbSB0aGUgVExTIGhhbmRzaGFrZSBzaW5jZSBUTFMgdGVybWluYXRpb24gaGFwcGVucyBh dCB0aGUgcHJveHkgKG9yIGV2ZW4gaW4gYmVmb3JlIHRoZSByZXF1ZXN0IGhpdHMgdGhlIHByb3h5 KS4gVGhlIFJTIHdvdWxkIG5lZWQgdG8gZ2V0IHByb3ZpZGVkIHdpdGggdGhlIGNlcnQgZmluZ2Vy cHJpbnQgdmlhIGEgdHJ1c3R3b3J0aHkgaGVhZGVyLCBpLmUuLiB0aGUgUlMgbXVzdCBiZSBhd2Fy ZSBvZiB0aGUgZmFjdCBpdCBzaXRzIGJlaGluZCBhIHByb3h5Lg0KPg0KPiBUaGlzIGlzIHVuZm9y dHVuYXRlbHkgdGhlIHR5cGljYWwgY2FzZSBldmVuIHdpdGggdGhlIG1UTFMgZHJhZnQuIFRoaXMN Cj4gaXMgYmVjYXVzZSBTU0wgaXMgYWxtb3N0IG5ldmVyIHRlcm1pbmF0ZWQgYnkgdGhlIEFTOyBp biBteSBleHBlcmllbmNlLA0KPiBUTFMgdGVybWluYXRpb24gaXMgaW5zdGVhZCBoYW5kbGVkIGJ5 IHNvbWUgdmVyeSBmYXN0IHByb3h5LlsxXSBJbiBzdWNoDQo+IGNhc2VzLCB0aGUgcHJveHkgd2ls bCBwYXNzIHRoZSBjZXJ0IHRocm91Z2ggdG8gdGhlIEFTIGluIHNvbWUNCj4gdW5kZWZpbmVkIEhU VFAgaGVhZGVyIHdpdGggc29tZSB1bmRlZmluZWQgZW5jb2RpbmcuIFRoZSBtVExTIHNwZWMNCj4g c2hvdWxkIGhhdmUgZGVmaW5lZCB0aGlzIElNTywgYXMgaXQgcHJldmVudHMgaW50ZXJvcCBmb3Ig YSBwcmltYXJ5IHVzZQ0KPiBjYXNlIC0tIHNlbmRlciBjb25zdHJhaW5lZCB0b2tlbnMuDQoNCkl0 J3Mgbm90IGNsZWFyIHRvIG1lIHRoYXQgbVRMUyBzaG91bGQgaGF2ZSBkZWZpbmVkIGEgcHJvdG9j b2wgZnJvbSBwcm94eSB0bw0KYmFja2VuZDsgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGEg ZmFpcmx5IGdlbmVyaWMgdGhpbmcgYW5kIEkga25vdyBvZg0Kc2V2ZXJhbCBwZW9wbGUgdGhhdCBh cmUgd29ya2luZyBvbiBzaW1pbGFyIHRoaW5ncywgdG8gb25lIGRlZ3JlZSBvcg0KYW5vdGhlci4g IGRyYWZ0LXNjaHdhcnR6LXRscy1sYiBpcyB0aGUgZXhhbXBsZSB0aGF0IEkgY2FuIG1vc3QgZWFz aWx5IGZpbmQNCmluIG15IGFyY2hpdmVzOyB0aG91Z2ggaXQncyB3b3JraW5nIHdpdGggbm9uLVRM Uy10ZXJtaW5hdGluZyBjYXNlcywgdGhlcmUNCmlzIHByb2JhYmx5IHNvbWUgY29tbW9uYWxpdHkg d2l0aCBUTFMtdGVybWluYXRpbmcgY2FzZXMgYXMgd2VsbC4NCg0KLUJlbg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5k IGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNv bXB1dGVyLiBUaGFuayB5b3UuX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQo= --_000_8A8B88929D164210BC1347B5D7859976mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWxzbyBhZ3JlZS4gV291bGQgaXQgYmUgcG9z c2libGUgdG8gZ2V0IHRoaXMgcHVzaGVkIHRvIGh0dHAgb3IgdGxzPyBJdCB3b3VsZCBiZSBtb3Jl IGFwcHJvcHJpYXRlIHRoZXJlLCBhbmQgdmVyeSBoZWxwZnVsIHRvIGhhdmUgYSBnZW5lcmFsIHNw ZWMgZm9yIHRoaXMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9j dCAyMywgMjAxOSwgYXQgMjoxMCBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0 bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiBjbGFzcz0iIj5i Y2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkkgYWdyZWUgd2l0aCBCZW4gaGVyZSB0aGF0 IGl0J3Mgbm90IGF0IGFsbCBjbGVhciB0aGF0IHRoZSBPQXV0aCBNVExTIGRvY3VtZW50IHNob3Vs ZCBoYXZlIGRlZmluZWQgYSBwcm90b2NvbCBmcm9tIHByb3h5IHRvIGJhY2tlbmQuIEknZCBnbyBz byBmYXIgYXMgdG8gc2F5IGl0J3Mgd2VsbCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1l bnQgYW5kIGV2ZW4gdGhlIHdvcmtpbmcgZ3JvdXAuIEFkbWl0dGVkbHkNCiBJdCB3b3VsZCBiZSBu aWNlIGlmIHN1Y2ggYSB0aGluZyBleGlzdGVkIGJ1dCBpdCB3b3VsZCBoYXZlIG11Y2ggd2lkZXIg YXBwbGljYWJpbGl0eSB0aGFuIG9uZSBuYXJyb3cgcHJvZmlsZSBvZiBPQXV0aC4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFN1biwgT2N0IDIwLCAyMDE5IGF0 IDg6MDYgUE0gQmVuamFtaW4gS2FkdWsgJmx0OzxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+a2FkdWtAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KSnVzdCBvbiBvbmUgbmFycm93IHBvaW50Ojxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFdlZCwgT2N0IDE2LCAyMDE5IGF0IDA0OjIz OjU2UE0gJiM0MzswMjAwLCBUcmF2aXMgU3BlbmNlciB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7 IE9uIFN1biwgT2N0IDYsIDIwMTkgYXQgMzozMSBQTSBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7IE9wZW46IEhvdyB3b3VsZCBvbmUgaW1wbGVtZW50IHNlbmRlciBj b25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGluIHRoYXQgY2FzZT8gSeKAmW0gYXNraW5nIHNpbmNl IHRoZSByZWNlaXZpbmcgUlMgb2J2aW91c2x5IGhhcyBubyBhY2Nlc3MgdG8gdGhlIGluZm9ybWF0 aW9uIGZyb20gdGhlIFRMUyBoYW5kc2hha2Ugc2luY2UgVExTIHRlcm1pbmF0aW9uIGhhcHBlbnMg YXQgdGhlIHByb3h5IChvciBldmVuIGluIGJlZm9yZSB0aGUgcmVxdWVzdCBoaXRzDQogdGhlIHBy b3h5KS4gVGhlIFJTIHdvdWxkIG5lZWQgdG8gZ2V0IHByb3ZpZGVkIHdpdGggdGhlIGNlcnQgZmlu Z2VycHJpbnQgdmlhIGEgdHJ1c3R3b3J0aHkgaGVhZGVyLCBpLmUuLiB0aGUgUlMgbXVzdCBiZSBh d2FyZSBvZiB0aGUgZmFjdCBpdCBzaXRzIGJlaGluZCBhIHByb3h5LjxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBUaGlzIGlzIHVuZm9ydHVuYXRlbHkgdGhlIHR5cGljYWwg Y2FzZSBldmVuIHdpdGggdGhlIG1UTFMgZHJhZnQuIFRoaXM8YnIgY2xhc3M9IiI+DQomZ3Q7IGlz IGJlY2F1c2UgU1NMIGlzIGFsbW9zdCBuZXZlciB0ZXJtaW5hdGVkIGJ5IHRoZSBBUzsgaW4gbXkg ZXhwZXJpZW5jZSw8YnIgY2xhc3M9IiI+DQomZ3Q7IFRMUyB0ZXJtaW5hdGlvbiBpcyBpbnN0ZWFk IGhhbmRsZWQgYnkgc29tZSB2ZXJ5IGZhc3QgcHJveHkuWzFdIEluIHN1Y2g8YnIgY2xhc3M9IiI+ DQomZ3Q7IGNhc2VzLCB0aGUgcHJveHkgd2lsbCBwYXNzIHRoZSBjZXJ0IHRocm91Z2ggdG8gdGhl IEFTIGluIHNvbWU8YnIgY2xhc3M9IiI+DQomZ3Q7IHVuZGVmaW5lZCBIVFRQIGhlYWRlciB3aXRo IHNvbWUgdW5kZWZpbmVkIGVuY29kaW5nLiBUaGUgbVRMUyBzcGVjPGJyIGNsYXNzPSIiPg0KJmd0 OyBzaG91bGQgaGF2ZSBkZWZpbmVkIHRoaXMgSU1PLCBhcyBpdCBwcmV2ZW50cyBpbnRlcm9wIGZv ciBhIHByaW1hcnkgdXNlPGJyIGNsYXNzPSIiPg0KJmd0OyBjYXNlIC0tIHNlbmRlciBjb25zdHJh aW5lZCB0b2tlbnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXQncyBub3QgY2xlYXIg dG8gbWUgdGhhdCBtVExTIHNob3VsZCBoYXZlIGRlZmluZWQgYSBwcm90b2NvbCBmcm9tIHByb3h5 IHRvPGJyIGNsYXNzPSIiPg0KYmFja2VuZDsgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGEg ZmFpcmx5IGdlbmVyaWMgdGhpbmcgYW5kIEkga25vdyBvZjxiciBjbGFzcz0iIj4NCnNldmVyYWwg cGVvcGxlIHRoYXQgYXJlIHdvcmtpbmcgb24gc2ltaWxhciB0aGluZ3MsIHRvIG9uZSBkZWdyZWUg b3I8YnIgY2xhc3M9IiI+DQphbm90aGVyLiZuYnNwOyBkcmFmdC1zY2h3YXJ0ei10bHMtbGIgaXMg dGhlIGV4YW1wbGUgdGhhdCBJIGNhbiBtb3N0IGVhc2lseSBmaW5kPGJyIGNsYXNzPSIiPg0KaW4g bXkgYXJjaGl2ZXM7IHRob3VnaCBpdCdzIHdvcmtpbmcgd2l0aCBub24tVExTLXRlcm1pbmF0aW5n IGNhc2VzLCB0aGVyZTxiciBjbGFzcz0iIj4NCmlzIHByb2JhYmx5IHNvbWUgY29tbW9uYWxpdHkg d2l0aCBUTFMtdGVybWluYXRpbmcgY2FzZXMgYXMgd2VsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQotQmVuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGkgc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7 Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5k OnJnYigyNTUsMjU1LDI1NSk7Zm9udC1mYW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVt LXVpLC1hcHBsZS1zeXN0ZW0sc3lzdGVtLXVpLCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90byxP eHlnZW4tU2FucyxVYnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LEFy aWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDg1LDg1LDg1KSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnRyYW5zcGFyZW50O2ZvbnQtZmFtaWx5OnByb3hpbWEt bm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwm cXVvdDtTZWdvZSBVSSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMsVWJ1bnR1LENhbnRhcmVsbCwm cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtd2VpZ2h0OjYw MCIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+Q09ORklERU5USUFMSVRZDQogTk9U SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFu eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkNCiB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+PC9zcGFuPjwvaT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9B dXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_8A8B88929D164210BC1347B5D7859976mitedu_-- From nobody Thu Oct 24 03:01:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063C01207FC for ; Thu, 24 Oct 2019 03:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 yIuGdnGViXnk for ; Thu, 24 Oct 2019 03:01:02 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8829112086B for ; Thu, 24 Oct 2019 03:01:02 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id s1so16590213wro.0 for ; Thu, 24 Oct 2019 03:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rKirueFTG604vXhQIEzGISZRGajzjcHJocZGaVP0Snc=; b=wBdCvJks9PyJWD+uAMoECR+IpRHtTGP9XVDS8uQsfP7VqQya/97zpbBYxdD0d0+ju0 ZkUuPB3EDwAHS9oLKMPuknsRBZlpe3U7jmhr5UaFGtOYsg51xLHUYvoJAfhzqZ28ayM5 K5G6Nva0yUUq4mHCyuK2EBc4a6Cfe4bSpe6ONlKtrKF0puGRBib5HOavNVJD1kfptc6w jm7HOXQSgDFcKQvn6RVu6Qme7JSocX/tNfIQGd/1ZWlj7nvFag9T1cFnHr1yfjnyaCZ0 Pj1NfrryYVyeD/MINVjrHEOM5ydaxE4kCgoIbUXgzF3iJ52Xrd4hCrA3i0I991eHi3hS RQrg== 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=rKirueFTG604vXhQIEzGISZRGajzjcHJocZGaVP0Snc=; b=SbLxgSNW71t3Hj0CjnNnStTFyi8dmBmm4gaVhECtjsw53fHnidI5lNfEqgPGSaVXnl TmCZJyPTGgP5OQy7qDgfpFSFZNCDWlG1umVx9DiLlE1ou8PMN62x6tUBAYPjIrMCsUgz P9lWF4tpcmHr5mymdmRDV/4TA96s9CEs1giBToJrkcASZQFiVUWtptsf+FFBn5WuOQyE LrhCxwbGaK5Ft3LS7x5wvJH5Mu3Y5xYfOFwQGQRi3s83PhL6XylvWGpZGIeQb/yRhmMT jZEXtw+mrIpGZAK4YEtT4ahpsI6nicHX1bBEnSbuCxyFcO1+SV/zQn0B1RxuS+wm2DRl kgRQ== X-Gm-Message-State: APjAAAVGT3x02/srII6Vpkfm54uKkcCybMt07OySYk+/SFs3yIHIN/by CBD9YsHWUwaBCv6kPtPSEk8oFA== X-Google-Smtp-Source: APXvYqysz/eSiTzhNa4vzSWpr2n/OpikIGpVvlHWbj7uN/M91fSYVFnIfL9T7CHHJ5XhS8i1X+Ygfw== X-Received: by 2002:a5d:5707:: with SMTP id a7mr3121165wrv.177.1571911260736; Thu, 24 Oct 2019 03:01:00 -0700 (PDT) Received: from [192.168.78.154] (glasgow.emobix.co.uk. [87.117.93.88]) by smtp.gmail.com with ESMTPSA id n17sm1773985wmc.41.2019.10.24.03.00.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Oct 2019 03:00:59 -0700 (PDT) From: Joseph Heenan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8600065B-F8D6-4B6D-B268-C3BBA5155D08" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 24 Oct 2019 11:00:59 +0100 In-Reply-To: Cc: oauth@ietf.org To: Giada Sciarretta References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] embedded UA detection X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Oct 2019 10:01:06 -0000 --Apple-Mail=_8600065B-F8D6-4B6D-B268-C3BBA5155D08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Giada, All methods can be bypassed by an attacker that has control of the app = in question, it=E2=80=99s just a matter of effort. I believe many AS=E2=80= =99s use client side javascript to provide a harder to bypass = implementation. Your aim here is probably mainly to prevent naive developers = =E2=80=9Caccidentally=E2=80=9D (or with good but misplaced intentions) = using an embedded user agent. In general the real state of the art would be for the party that owns = the AS to have an associated first-party native mobile app, as that = improves the user experience and greatly reduces the associated risks. I = wrote about the pattern for doing this here: = https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authoris= ation.html That said all the choices and risks here are very complex and interact = with each other - from the information given I definitely can=E2=80=99t = say whether app2app is a good approach in your use case. Cheers Joseph > On 11 Oct 2019, at 15:44, Giada Sciarretta = wrote: >=20 > Hello, > =20 > We are working on a project that involves mobile native applications. > =20 > The OAuth for native apps (RFC8252) spec "requires that native apps = MUST NOT use embedded user-agents to perform authorization requests and = allows that authorization endpoints MAY take steps to detect and block = authorization requests in embedded user-agents". > =20 > We would like to integrate in our AS the state-of-the-art techniques = for detecting and blocking authorization requests in embedded = user-agents. We are aware of the following techniques (link = ): > doing a string checking on the User agent string value. In the = chromium based-WebView > in the older versions it adds the =E2=80=9CVersion/X.X=E2=80=9D string = into the UA field. For example: Mozilla/5.0 (Linux; U; Android 2.2.1; = en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) = Version/4.0 Mobile Safari/533.1 > in the newer version it will add, =E2=80=9C;wv=E2=80=9D. For example: = Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv) = AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 = Mobile Safari/537.36 > checking the presence of X-Requested-With HTTP header, the value of = this header will be the application's name that is running the webview. > =20 > but we know that these detection methods can be bypassed by an = attacker. Do you have any suggestions in this regard? > =20 > Thank you in advance for your response. > =20 > Kind regards, > Giada Sciarretta > =20 >=20 > -- > Le informazioni contenute nella presente comunicazione sono di natura = privata e come tali sono da considerarsi riservate ed indirizzate = esclusivamente ai destinatari indicati e per le finalit=C3=A0 = strettamente legate al relativo contenuto. Se avete ricevuto questo = messaggio per errore, vi preghiamo di eliminarlo e di inviare una = comunicazione all=E2=80=99indirizzo e-mail del mittente. > -- > The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential and/or privileged = material. If you received this in error, please contact the sender and = delete the material. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8600065B-F8D6-4B6D-B268-C3BBA5155D08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Giada,

All methods = can be bypassed by an attacker that has control of the app in question, = it=E2=80=99s just a matter of effort. I believe many AS=E2=80=99s use = client side javascript to provide a harder to bypass = implementation.

Your aim here is probably mainly to prevent naive developers = =E2=80=9Caccidentally=E2=80=9D (or with good but misplaced intentions) = using an embedded user agent.

In general the real state of the art = would be for the party that owns the AS to have an associated = first-party native mobile app, as that improves the user experience and = greatly reduces the associated risks. I wrote about the pattern for = doing this here:

https://josephheenan.blogspot.com/2019/08/implementing-app-to-a= pp-authorisation.html

That said all the choices and risks here are very complex and = interact with each other - from the information given I definitely = can=E2=80=99t say whether app2app is a good approach in your use = case.

Cheers

Joseph


On 11 = Oct 2019, at 15:44, Giada Sciarretta <giada.sciarretta@fbk.eu> wrote:

Hello,

 

We are working on a project = that involves mobile native applications.

 

The OAuth for native apps (RFC8252) = spec "requires that native apps MUST NOT use embedded user-agents  to perform authorization requests and allows that authorization endpoints MAY take steps to detect and block authorization = requests  in embedded user-agents".

 

We would like to integrate in our AS the state-of-the-art techniques for detecting and = blocking authorization requests in embedded user-agents. We are aware of the = following techniques (link):
  • doing a string = checking on the User agent string value. In the chromium = based-WebView
    • in the older versions it adds the =E2=80=9CVersion/X.X=E2=80=9D string into the UA field. = For example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) = AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • in the newer = version it will add, =E2=80=9C;wv=E2=80=9D. For example: Mozilla/5.0 (Linux; = Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) = Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
  • checking the = presence of X-Requested-With HTTP header, the value of this header will be the application's name that is running the webview.

 

but we know that these detection methods can be bypassed by an attacker. Do you have any = suggestions in this regard?

 

Thank you in advance for your = response.

 

Kind regards,
Giada Sciarretta

 


--
Le = informazioni contenute nella presente comunicazione sono di = natura privata e come tali sono da considerarsi riservate ed = indirizzate esclusivamente= ai destinatari indicati e per le finalit=C3=A0 = strettamente legate al = relativo contenuto. Se avete ricevuto questo messaggio = per errore, vi preghiamo di eliminarlo e di inviare una = comunicazione all=E2=80=99indirizzo e-mail del = mittente.
--
The information transmitted is intended only for = the person or entity to which it is addressed and may contain = confidential and/or privileged material. If you received this in error, = please contact the sender and delete the = material.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_8600065B-F8D6-4B6D-B268-C3BBA5155D08-- From nobody Thu Oct 24 10:03:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D901112004D for ; Thu, 24 Oct 2019 10:03:32 -0700 (PDT) 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 JqlqTIT2ixph for ; Thu, 24 Oct 2019 10:03:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01732120033 for ; Thu, 24 Oct 2019 10:03:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9OH3Qoq031747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 13:03:29 -0400 Date: Thu, 24 Oct 2019 10:03:26 -0700 From: Benjamin Kaduk To: Justin Richer Cc: Brian Campbell , oauth Message-ID: <20191024170326.GO69013@kduck.mit.edu> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 17:03:33 -0000 On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: > I also agree. Would it be possible to get this pushed to http or tls? It > would be more appropriate there, and very helpful to have a general spec > for this. I think it's possible to get such work done in one of those places, but first someone has to actually write a draft. Barring that, a HotRFC or secdispatch slot in Singapore would probably be good for drumming up interest. In related news, I am told that draft-duke-quic-load-balancers had some time in the QUIC interim this month, and may be moving towards adoption, so time may be short if we want to have a fully general solution. -Ben From nobody Fri Oct 25 07:02:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B86B120884 for ; Fri, 25 Oct 2019 07:02:56 -0700 (PDT) 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 S27AsdzqzIPq for ; Fri, 25 Oct 2019 07:02:53 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C0212007C for ; Fri, 25 Oct 2019 07:02:53 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id p6so2522209iod.7 for ; Fri, 25 Oct 2019 07:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aWBxxtpOyFBW/s1vMq8rTHpMWLH2i+0Osw1c42KjKLA=; b=T5VQuN4yinUP1isWwfTZSD/RWaBIWYPRjS4+8auzctg8RXJLHVMFPgLcCHNmv9KM34 VUou6UU5xp18/9117Dn0uWnSj5FWL+cDkRnY6i2UMdQ+DEFdWyzf13LG7VSc4Ue4rsZY a7LJb0V4LGGbI6TcSp+cjpl09VWWZF8dutmcSuUSfpsxwch9gdumyQVWY8yqfcXVD2fj qQe7eJreK2QgEr+hUSLqntT+LAqZGCBL+P+OeP5xn52oA4BY6DQ0pp7vRye/8HR1ykFO Nj9rNbAMglFaiQCrUvR7s2DFKS0w4aNMAwrVNt5Md7Q51C3/FHf8HG+JS2eCwc61Cwit NSUA== 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=aWBxxtpOyFBW/s1vMq8rTHpMWLH2i+0Osw1c42KjKLA=; b=GI1dmhNWj7gQz/cgSnkuzlLFW6eMvRHDl8jmy2LgO5hLKGu+AzTpnczIP8FYwDBK6l +PHkTuhHGjfkNT2ZFlDBjGE2f50NG7YokoHio/hAZbyolh+p+XTUN7DumsBp/L4D3+az RCFqimvpxNGBgMQmCFmq+iHcqbwYyJPiEqTfbOLcA3FKVjnx3AFc7iq/hkzAVsLTstdR guw3DbxUmmOFIIseODSgymUuMyNZHd6Jc5lBMLED/T5/9yTDZG2r7ZkhuRi6a0aKKfq3 PPWgJ5mbL3yTyalRTgGXybaQ+5R3Pndt96PjjcVjmDAwDWbHYuR+ahDEAJrH1b7qvyit f+CA== X-Gm-Message-State: APjAAAV14/Bfs/iCY3iIQhhrDty+r3hDMvLcZIKC8sB1SOD5bqQ8U0oR FxaIFr1vP6B4aX83KbBaPH0XMUTYTP01aP5suCYyuKeNr3U= X-Google-Smtp-Source: APXvYqwH7dxWkUcWE98BFFTnZZTU+9pjIYiKT8PGju2H855lZSCFZAwBVLjomvPqiduMmIOaznrnAEYSFP4u44dPNHM= X-Received: by 2002:a5d:87ce:: with SMTP id q14mr3660676ios.278.1572012172983; Fri, 25 Oct 2019 07:02:52 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: <20191024170326.GO69013@kduck.mit.edu> From: Rifaat Shekh-Yusef Date: Fri, 25 Oct 2019 10:02:41 -0400 Message-ID: To: Benjamin Kaduk Cc: Justin Richer , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000002746d60595bc9b9c" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:02:56 -0000 --0000000000002746d60595bc9b9c Content-Type: text/plain; charset="UTF-8" You might want to look at RFC7239, which is trying to address the issue of the loss of information by proxies. https://tools.ietf.org/html/rfc7239 The document does not have a parameter to carry the client certificate information, but it allows for new parameters to be defined. Would that help in this case? Regards, Rifaat On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk wrote: > On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: > > I also agree. Would it be possible to get this pushed to http or tls? > It > > would be more appropriate there, and very helpful to have a general > spec > > for this. > > I think it's possible to get such work done in one of those places, but > first someone has to actually write a draft. Barring that, a HotRFC or > secdispatch slot in Singapore would probably be good for drumming up > interest. In related news, I am told that draft-duke-quic-load-balancers > had some time in the QUIC interim this month, and may be moving towards > adoption, so time may be short if we want to have a fully general solution. > > -Ben > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000002746d60595bc9b9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You might want to look at RFC7239, which is trying to addr= ess the issue of the loss of information by proxies.
https://tools.ietf.org/html/rfc7239

The document does not have a parameter=C2=A0to carr= y the client certificate information, but it allows for new parameters to b= e defined.

Would that help in this case?

Regards,
=C2=A0Rifaat

<= br>
On Thu,= Oct 24, 2019 at 1:03 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrot= e:
>=C2=A0 =C2=A0 I also agree. Would it be possible to get this pushed to = http or tls? It
>=C2=A0 =C2=A0 would be more appropriate there, and very helpful to have= a general spec
>=C2=A0 =C2=A0 for this.

I think it's possible to get such work done in one of those places, but=
first someone has to actually write a draft.=C2=A0 Barring that, a HotRFC o= r
secdispatch slot in Singapore would probably be good for drumming up
interest.=C2=A0 In related news, I am told that draft-duke-quic-load-balanc= ers
had some time in the QUIC interim this month, and may be moving towards
adoption, so time may be short if we want to have a fully general solution.=

-Ben

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002746d60595bc9b9c-- From nobody Fri Oct 25 12:47:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972CB120044 for ; Fri, 25 Oct 2019 12:47:06 -0700 (PDT) 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=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 6BKkw_xoSQU6 for ; Fri, 25 Oct 2019 12:47:04 -0700 (PDT) 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 963B512003E for ; Fri, 25 Oct 2019 12:47:03 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id l21so4067692lje.4 for ; Fri, 25 Oct 2019 12:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wVnfHTKLXRITjv+Fh98Y3QJsM2tu4tKkSgHCOhMLEyw=; b=i0LqZHzZJSiTMz1uf5iKjwsKAgE+hIkX/OPVWG/Law2p1wwV3JklOhokhPf/keVIqk ZolWlZ0LKsqzPlXxcVJAWQb3JSdNswKAPskK7OQJWePDeuUn1w1rS6poE4Czhn/moxvX xYfPX5JozJdcB45/MpqVdqtYGpecnl5raKBuI= 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=wVnfHTKLXRITjv+Fh98Y3QJsM2tu4tKkSgHCOhMLEyw=; b=CABbyMbzagbozKc184U0gsGIME61acvXVGoOQ799w67Oe9Q4WsB3v4KGodWEgBHeQl +dcmLXQVIaywaBX/7PBPaBmWILVi0JCf0IlE5MTp962ED5BouKdfuXGnYaBgimEmMsyl Ccq/IN4sVC5vIeMyo6Xwdoy4Fi5OnVX3UF2Klt/EtlydeNRvK1rrDvzreu1dvC5thIaQ kBisEP0rqquZZSnx4IKoplZih06Vd4Kffv2u//y9FEw2MLQXVf4kSf8XcbjADNVzWscw DnfQbGVJV3/U4c9lbp9fnsCO0YRmZ9xfYQlEM8A3o+updtQN0T9+iEDgQXaJ7bkTz1D3 PZ9Q== X-Gm-Message-State: APjAAAX2zwbwn8WBoguVR0cymSTWJ2gBcZeL8TWP09LeHbOKGK5EpLz7 JvVUqS6sRQEs1VhwRxKoDYm1tnv6ySBCNuV9K+J0MygSpdO5tZCNRuZzxEYy/ufY6elRGmVFTYa pNQl4U64ufZLtfw== X-Google-Smtp-Source: APXvYqzr6i/0KDIVIvwE+ebhz1zIuooDW4X5kzGe2Hj+pQCKupQVc+RXk/Cc6tGZU+NFF7LMOKn0NRNA39kxGrbWFY4= X-Received: by 2002:a2e:8204:: with SMTP id w4mr3652721ljg.3.1572032821754; Fri, 25 Oct 2019 12:47:01 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Fri, 25 Oct 2019 13:46:35 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000ea92e80595c1696f" Archived-At: Subject: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 19:47:07 -0000 --000000000000ea92e80595c1696f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Few thoughts, comments, & questions. I've always kind of assumed that the ship had already sailed on doing anything standards related with this because implementations out in the wild like Apache, NGNIX, IIS, etc. were already providing ad hoc solutions and had been doing so for a long time. But this thread at least hints that there may yet be an appetite for such a standardization effort? I'll be in Singapore but my (long) flight is scheduled to land about the time when HotRFC starts. I could perhaps do something for secdispatch though. Ben, is a draft needed for that or can secdispatch be engaged with some slides amounting to a problem statement? I'm just not confident a draft could be published in the next week or so before the cut off. I did put it some work on a conceptually similar issue around token binding with "HTTPS Token Binding with TLS Terminating Reverse Proxies" - https:// datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ not too long ago. It was a WG item that had gone through WGLC but kinda stalled out waiting on the chair(s) for the shepard writeup when adoption questions around token binding came up. There are lots of ways to approach the problem and solution but I think perhaps a lot could be taken from that document and applied to the similar client cert situation. I did look at RFC7239 when doing that and it could have been made to work but felt the fit wasn't quite right and would have been more cumbersome to use than not. On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef wrote: > You might want to look at RFC7239, which is trying to address the issue o= f > the loss of information by proxies. > https://tools.ietf.org/html/rfc7239 > > The document does not have a parameter to carry the client certificate > information, but it allows for new parameters to be defined. > > Would that help in this case? > > Regards, > Rifaat > > > On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk wrote: > >> On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: >> > I also agree. Would it be possible to get this pushed to http or >> tls? It >> > would be more appropriate there, and very helpful to have a general >> spec >> > for this. >> >> I think it's possible to get such work done in one of those places, but >> first someone has to actually write a draft. Barring that, a HotRFC or >> secdispatch slot in Singapore would probably be good for drumming up >> interest. In related news, I am told that draft-duke-quic-load-balancer= s >> had some time in the QUIC interim this month, and may be moving towards >> adoption, so time may be short if we want to have a fully general >> solution. >> >> -Ben >> >> _______________________________________________ >> 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._ --000000000000ea92e80595c1696f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Few thoughts, comments, & questi= ons.

I've always kind of assumed that the= ship had already sailed on doing anything standards related with this beca= use implementations out in the wild like Apache, NGNIX, IIS= , etc. were already providing ad hoc solutions and had been doing so for a long time. But this= thread at least hints that there may yet be an appetite for such a standar= dization effort?

I'll be in Singapore but my (= long) flight is scheduled to land about the time when HotRFC starts. I coul= d perhaps do something for secdispatch though. Ben, is a draft needed for t= hat or can secdispatch be engaged with some slides amounting to a problem s= tatement? I'm just not confident a draft could be published in the next= week or so before the cut off.

I did put it = some work on a conceptually similar issue around token binding with "H= TTPS Token Binding with TLS Terminating Reverse Proxies" - https://datatracker.ietf.org/doc/draft-ietf-tok= bind-ttrp/ not too = long ago. It was a WG item that had gone through WGLC but kinda stalled out= waiting on the chair(s) for the shepard writeup when adoption questions ar= ound token binding came up.

There are lots of= ways to approach the problem and solution but I think perhaps a lot could = be taken from that document and applied to the similar client cert situatio= n.

I did look at RFC7239 when doing that and = it could have been made to work but felt the fit wasn't quite right and= would have been more cumbersome to use than not.=C2=A0

=


On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef <= ;rifaat.ietf@gma= il.com> wrote:
You might want to look at RFC7239, which is trying t= o address the issue of the loss of information by proxies.

The document does not have = a parameter=C2=A0to carry the client certificate information, but it allows= for new parameters to be defined.

Would that help= in this case?

Regards,
=C2=A0Rifaat


On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Wed, Oct 23, 20= 19 at 10:13:04AM -0400, Justin Richer wrote:
>=C2=A0 =C2=A0 I also agree. Would it be possible to get this pushed to = http or tls? It
>=C2=A0 =C2=A0 would be more appropriate there, and very helpful to have= a general spec
>=C2=A0 =C2=A0 for this.

I think it's possible to get such work done in one of those places, but=
first someone has to actually write a draft.=C2=A0 Barring that, a HotRFC o= r
secdispatch slot in Singapore would probably be good for drumming up
interest.=C2=A0 In related news, I am told that draft-duke-quic-load-balanc= ers
had some time in the QUIC interim this month, and may be moving towards
adoption, so time may be short if we want to have a fully general solution.=

-Ben

_______________________________________________
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. --000000000000ea92e80595c1696f-- From nobody Fri Oct 25 14:16:40 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2691209EC; Fri, 25 Oct 2019 14:12:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793183.2724.10916622607080570814.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:11 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 106 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, 25 Oct 2019 21:12:22 -0000 Dear Hannes Tschofenig, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30 requested) Wednesday, 20 November 2019, Afternoon Session I 1330-1500 Room Name: Olivia size: 150 --------------------------------------------- oauth Session 2 (1:30 requested) Thursday, 21 November 2019, Afternoon Session II 1550-1720 Room Name: Hullet size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: acme tls rats sipcore anima Technology Overlap: ace secevent teep suit core tokbind saag People who must be present: Roman Danyliw Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 25 15:38:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F29120071 for ; Fri, 25 Oct 2019 15:38:13 -0700 (PDT) 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 hF9uiVquAeNH for ; Fri, 25 Oct 2019 15:38:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3C4120020 for ; Fri, 25 Oct 2019 15:38:12 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9PMc6bE023495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 18:38:08 -0400 Date: Fri, 25 Oct 2019 15:38:05 -0700 From: Benjamin Kaduk To: Rifaat Shekh-Yusef Cc: Justin Richer , Brian Campbell , oauth Message-ID: <20191025223805.GM69013@kduck.mit.edu> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 22:38:14 -0000 On Fri, Oct 25, 2019 at 10:02:41AM -0400, Rifaat Shekh-Yusef wrote: > You might want to look at RFC7239, which is trying to address the issue of > the loss of information by proxies. > https://tools.ietf.org/html/rfc7239 > > The document does not have a parameter to carry the client certificate > information, but it allows for new parameters to be defined. > > Would that help in this case? That is interesting and related, though the proposed work I remember hearing about recently is not quite in the same space. Specifically, it wanted to have a secure protocol between proxy and backend, and it's not clear that reusing https for that is the right thing. -Ben From nobody Sat Oct 26 14:55:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3774812003E for ; Sat, 26 Oct 2019 14:55:11 -0700 (PDT) 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 JhVg2H6JOcmC for ; Sat, 26 Oct 2019 14:55:08 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7570120013 for ; Sat, 26 Oct 2019 14:55:08 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id r144so6371786iod.8 for ; Sat, 26 Oct 2019 14:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i5xo+oarvKfvVIv8cUkCreo2kG2Z1CdL+S2uPKatspk=; b=e3tTSJ86eDADYk7pzM1WcZdUnZSLy47C8MM5B02EQ3SPPwOBhLfRnWCVv8cJJw3Nm6 i0GTRXCe+eqUpLFBlW8syHo3QYppBq78c7TUFxRDU/nTRa1INCWJDv/yua7CtH250ZFB f349xceDxYLR6Pt8A4rEujVa5u8HBt2Upc8sdYWw7v6qAi4d90NL8NLMcrSUhUFbWi/7 UDFnXHbe9+qQoOs33Y0lBRaE8FtyaPMYTW6mtXKwIn3RdLBRcpgJ1xKflnOaeSlIwSyN LDl6id07jN06PTBEMRaxNY/KbQyFAoWk7OA9oUGiHwyO7/ow4w/NFqNRPVoR2Gxe+I82 57Fg== 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=i5xo+oarvKfvVIv8cUkCreo2kG2Z1CdL+S2uPKatspk=; b=P1zHvRl0y5S5m5zil9ySAjl+V4BKBDsOQDs2ZsTfuRE1ZwNmD7mUwpnKynKizfA+wH RcSnT1Q+UF+R6dC+mOLDohz7fFY0jVcz7Guxa2cKrG2i9UiOt0kBoLWuhVUjZYscZmCD J+6nBYuCQLLkWnRwQmPEhOA9bBbZSO7Wll48dSnjGCoYnBSZtliCrmH4NylXYm8Wg0dC m/uH2ozAs7J65RHv/9x0biRatDQM5LU7/76yKjOdNsbEDfM+qqevcdZbMlJpS6ZXOweF 8pA3Z9Pl8+EEgNlKhntKSDEKWXN+T+m+mo1f2JBB9GLoTiEi3QwV1WjhEbZODWIs4HvA Gckw== X-Gm-Message-State: APjAAAWvkkJyz8LoYbsxo3GDtMPsrzixoPprpZfy7iZlmsNypxY81A54 7yJUrPAtq4lwid7MQ/LHOnBxUMqDaJMJjrmReRs= X-Google-Smtp-Source: APXvYqxNmwdQIBIezh5x/kskwyjX9zgZkKa3xTJm20z5e/bPo3uMMKTAWuq5OgNmr3TJSx4FRKYCGujJrzZj+9y86CE= X-Received: by 2002:a6b:5908:: with SMTP id n8mr11246168iob.31.1572126908050; Sat, 26 Oct 2019 14:55:08 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Sat, 26 Oct 2019 17:54:58 -0400 Message-ID: To: Brian Campbell Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000e573a40595d751cb" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 21:55:12 -0000 --000000000000e573a40595d751cb Content-Type: text/plain; charset="UTF-8" On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell wrote: > Few thoughts, comments, & questions. > > I've always kind of assumed that the ship had already sailed on doing > anything standards related with this because implementations out in the > wild like Apache, NGNIX, IIS, etc. were already providing ad hoc > solutions and had been doing so for a long time. But this thread at least > hints that there may yet be an appetite for such a standardization effort? > > I'll be in Singapore but my (long) flight is scheduled to land about the > time when HotRFC starts. I could perhaps do something for secdispatch > though. Ben, is a draft needed for that or can secdispatch be engaged with > some slides amounting to a problem statement? I'm just not confident a > draft could be published in the next week or so before the cut off. > > I did put it some work on a conceptually similar issue around token > binding with "HTTPS Token Binding with TLS Terminating Reverse Proxies" - > https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ not too long > ago. It was a WG item that had gone through WGLC but kinda stalled out > waiting on the chair(s) for the shepard writeup when adoption questions > around token binding came up. > > There are lots of ways to approach the problem and solution but I think > perhaps a lot could be taken from that document and applied to the similar > client cert situation. > > I did look at RFC7239 when doing that and it could have been made to work > but felt the fit wasn't quite right and would have been more cumbersome to > use than not. > > Can you elaborate on this? These days, with the zero trust model in mind, there are orchestration tools, e.g. Istio, that easily allows you to establish an MTLS channel between the reverse proxy/load balancer/API GW and the backend servers. Why is that not sufficient? Which part is cumbersome? Regards, Rifaat > > > On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef > wrote: > >> You might want to look at RFC7239, which is trying to address the issue >> of the loss of information by proxies. >> https://tools.ietf.org/html/rfc7239 >> >> The document does not have a parameter to carry the client certificate >> information, but it allows for new parameters to be defined. >> >> Would that help in this case? >> >> Regards, >> Rifaat >> >> >> On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk wrote: >> >>> On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: >>> > I also agree. Would it be possible to get this pushed to http or >>> tls? It >>> > would be more appropriate there, and very helpful to have a general >>> spec >>> > for this. >>> >>> I think it's possible to get such work done in one of those places, but >>> first someone has to actually write a draft. Barring that, a HotRFC or >>> secdispatch slot in Singapore would probably be good for drumming up >>> interest. In related news, I am told that draft-duke-quic-load-balancers >>> had some time in the QUIC interim this month, and may be moving towards >>> adoption, so time may be short if we want to have a fully general >>> solution. >>> >>> -Ben >>> >>> _______________________________________________ >>> 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.* --000000000000e573a40595d751cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 25, 2019 at 3:47 PM Brian = Campbell <bcampbell@pingid= entity.com> wrote:
Few thoughts, comments, &= amp; questions.

I've always kind of assum= ed that the ship had already sailed on doing anything standards related wit= h this because implementations out in the wild like Apache, NGNIX, IIS, e= tc. were already providing ad hoc solutions and had been doing so for a lo= ng time. But this thread at least hints that there may yet be an appetite f= or such a standardization effort?

I'll be in S= ingapore but my (long) flight is scheduled to land about the time when HotR= FC starts. I could perhaps do something for secdispatch though. Ben, is a d= raft needed for that or can secdispatch be engaged with some slides amounti= ng to a problem statement? I'm just not confident a draft could be publ= ished in the next week or so before the cut off.

<= div>I did put it some work on a conceptually similar issue around token bin= ding with "HTTPS Token Binding with TLS Terminating Reverse Proxies&qu= ot; - https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ not to= o long ago. It was a WG item that had gone through WGLC but kinda stalled o= ut waiting on the chair(s) for the shepard writeup when adoption questions = around token binding came up.

There are lots = of ways to approach the problem and solution but I think perhaps a lot coul= d be taken from that document and applied to the similar client cert situat= ion.

I did look at RFC7239 when doing that an= d it could have been made to work but felt the fit wasn't quite right a= nd would have been more cumbersome to use than not.=C2=A0

Can you elaborate on t= his?
These days, with the zero trust model in mind, there are orc= hestration tools, e.g. Istio, that easily allows you to establish an MTLS c= hannel between the reverse proxy/load balancer/API GW and the backend serve= rs.
Why is that not sufficient?=C2=A0
Which part is= cumbersome?

Regards,
=C2=A0Rifaat
=


=C2=A0

On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>= wrote:
You might want to look at RFC7239, which is trying to address the = issue of the loss of information by proxies.

The document does not have a parameter=C2= =A0to carry the client certificate information, but it allows for new param= eters to be defined.

Would that help in this case?=

Regards,
=C2=A0Rifaat


On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Wed, Oct 23, 2019 at 10:13:04= AM -0400, Justin Richer wrote:
>=C2=A0 =C2=A0 I also agree. Would it be possible to get this pushed to = http or tls? It
>=C2=A0 =C2=A0 would be more appropriate there, and very helpful to have= a general spec
>=C2=A0 =C2=A0 for this.

I think it's possible to get such work done in one of those places, but=
first someone has to actually write a draft.=C2=A0 Barring that, a HotRFC o= r
secdispatch slot in Singapore would probably be good for drumming up
interest.=C2=A0 In related news, I am told that draft-duke-quic-load-balanc= ers
had some time in the QUIC interim this month, and may be moving towards
adoption, so time may be short if we want to have a fully general solution.=

-Ben

_______________________________________________
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.
--000000000000e573a40595d751cb-- From nobody Sun Oct 27 02:13:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3112006F; Sun, 27 Oct 2019 02:13:12 -0700 (PDT) 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 aCFlIDsvcDrO; Sun, 27 Oct 2019 02:13:08 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99F9120104; Sun, 27 Oct 2019 02:13:04 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id g24so6365651wmh.5; Sun, 27 Oct 2019 02:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/oRU6sT0Wg/77pLF3VQRPl9E0Z4rZiL/hiFXeaw2cdA=; b=sOFPOmbzbv3v7/TZkZK4nYDQkEFnxnhU4dYjeA5l80K5pxkOXhk5/zwG0T2YbP0OAX 87Ta7C9UlqTeYAEbl/5xufJJcmb6NOiI/wpFs1TkMdyu5q+1Y0sfBPc72foY5F77VDgx dQJ3HfEr7msHDLvJV0hksYV2a1o1sgfMM4PXAEu+tDlwEToALTOK09bR2Ou+mGYURpQV HdD9OkU3oWgXxcWwKyvS+HjzV1JxCisA86HFvSDT3Ds5MFddGIgIyXEE5KwSwf33lkyR M6FR4JFMtKF1XiTXYFWWGNqo3WvKcel0lnEDK5b7DEWFsGhWfZ5cy9BPk9Uk+MU8JbFh 2Crw== 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=/oRU6sT0Wg/77pLF3VQRPl9E0Z4rZiL/hiFXeaw2cdA=; b=YTrlpqVo/EtTUh05FHNstKbpGW6A0go8pAcY0YAP2KxxUURh3V2EEH9lGnuUGTybmP dysHnuraMuX2mBV5/MUSYjt1wj4yDTo8sKfJrHk4Nmxy2TyvH5ki6eib2aBD+CPZboKz EAAK+brQ7RXK/bKNHPzJaXU7dzZLbqYnPOb5wott7JWb9OXtboe/Dq4MNyxSr/CJhHuR tNeX8srx4kTT3QrRXhoq8w9tbg6RPqxsItZukqJNhzHoQ7cghC1CGq1dgTZMskBNveoK J4m2XyDbdglYeboYQzfwugULxZC6GGHx+o57hs2+CUxkxIKudGxOm5b1D9HznJ9x5oU+ uJXA== X-Gm-Message-State: APjAAAUQSg0gVHF8HQd3ONO74eLhwSktPYDYGf3KyNrB0GV8FIR69abq EtR/LXB8mITmzk/sNw8cAjtXOfslBIRixoJpbOOXLwy/YeU= X-Google-Smtp-Source: APXvYqwqzUR5EXfcVbmr67lEVBR/tMNoSj39uwb5FYwtNG6Yt5cFgv2FBJmXy+58wNzTeLrOaIc1UfEh8jFI38eGyhQ= X-Received: by 2002:a05:600c:2255:: with SMTP id a21mr4130335wmm.148.1572167582565; Sun, 27 Oct 2019 02:13:02 -0700 (PDT) MIME-Version: 1.0 References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> In-Reply-To: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> From: Nat Sakimura Date: Sun, 27 Oct 2019 10:12:50 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000494aea0595e0ca6f" 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: Sun, 27 Oct 2019 09:13:13 -0000 --000000000000494aea0595e0ca6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Datatr= acker : > 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 > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000494aea0595e0ca6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

Took a long time but finally all the changes needed to resolv= e the DISCUSS comments are (hopefully) applied as -20.=C2=A0

There is one change that impacts the = process: the draft now has IANA request so it needs to be referred back to = IANA.=C2=A0

The IE= TF datatracker status page for this draft is:
datatracker.ietf.org/doc/draft-ietf-oauth-jw= sreq/
=

Be= st,=C2=A0

Nat Sakimura

2019=E5=B9=B47=E6=9C=883=E6=97=A5(=E6=B0=B4) 4:21 Benjamin Kaduk via Dat= atracker <noreply@ietf.org>:<= br>
Benjamin Kaduk has entered the foll= owing 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/s= tatement/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-ie= tf-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:

=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 party attesting that the authorization request = is compliant with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a certain policy.=C2=A0 For example, a request = can be pre-examined by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a third party that all the personal data reques= ted is strictly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 necessary to perform the process that the end-u= ser asked for,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and statically signed by that third party.=C2= =A0 The authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server then examines the signature and shows th= e conformance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status to the end-user, who would have some ass= urance as to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimacy of the request when authorizing it.= =C2=A0 In some cases,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it may even be desirable to skip the authorizat= ion dialogue
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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

=C2=A0 =C2=A0While it is easy to implement, the encoding in the URI does no= t allow
=C2=A0 =C2=A0application layer security with confidentiality and integrity<= br> =C2=A0 =C2=A0protection to be used.=C2=A0 While TLS is used to offer commun= ication

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=A0The use of application layer security allows requests to be pr= epared
=C2=A0 =C2=A0by a third party so that a client application cannot request m= ore
=C2=A0 =C2=A0permissions than previously agreed.=C2=A0 This offers an addit= ional degree
=C2=A0 =C2=A0of privacy protection.

(side note) what would an example of such a third party be.=C2=A0 (We alrea= dy
have the resource owner, the client, and the authorization server ...
maybe it's a fourth party?)

=C2=A0 =C2=A0Furthermore, the request by reference allows the reduction of = over-
=C2=A0 =C2=A0the-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".=

=C2=A0 =C2=A0(4)=C2=A0 its development status that it is an RFC and so is i= ts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 associated signing and encryption methods as [R= FC7515] and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7516]

nit: I'd suggest "its development status as a Proposed Standard, a= long
with the associated signing and encryption methods [RFC7515] [RFC7516].&quo= t;

=C2=A0 =C2=A0(c)=C2=A0 (confidentiality protection) The request can be encr= ypted so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that end-to-end confidentiality can be provided= even if the TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection is terminated at one point or anothe= r.

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=A02.=C2=A0 When the client does not want to do the crypto.=C2=A0= The
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Server may provide an endpoint to = accept the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Request through direct communicati= on with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0Client so that the Client is authenticated and t= he channel is TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0protected.

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 pay the addi= tional
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

=C2=A0 =C2=A0A Request Object (Section 2.1) is used to provide authorizatio= n
=C2=A0 =C2=A0request parameters for an OAuth 2.0 authorization request.=C2= =A0 It MUST
=C2=A0 =C2=A0contains all the OAuth 2.0 [RFC6749] authorization request par= ameters
=C2=A0 =C2=A0including extension parameters.=C2=A0 The parameters are repre= sented 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 ex= tension
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=C2= =A0 find the Request
Object!

=C2=A0 =C2=A0the JWT claims.=C2=A0 Parameter names and string values MUST b= e included

nit: maybe "the JWT claims of the object"?

=C2=A0 =C2=A0any extension parameters.=C2=A0 This JSON [RFC7159] constitute= s the JWT
=C2=A0 =C2=A0Claims Set defined in JWT [RFC7519].=C2=A0 The JWT Claims Set = is then
=C2=A0 =C2=A0signed or signed and encrypted.

nit: I=C2=A0 think we want "This JSON [RFC7159] object".

(Long quote incoming)

=C2=A0 =C2=A0The following is an example of the Claims in a Request Object = before
=C2=A0 =C2=A0base64url encoding and signing.=C2=A0 Note that it includes ex= tension
=C2=A0 =C2=A0variables such as "nonce" and "max_age".
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 "iss": "s6BhdRkqt3",
=C2=A0 =C2=A0 =C2=A0 "aud": "https://server.example.com= ",
=C2=A0 =C2=A0 =C2=A0 "response_type": "code id_token",<= br> =C2=A0 =C2=A0 =C2=A0 "client_id": "s6BhdRkqt3",
=C2=A0 =C2=A0 =C2=A0 "redirect_uri": "https://client.exa= mple.org/cb",
=C2=A0 =C2=A0 =C2=A0 "scope": "openid",
=C2=A0 =C2=A0 =C2=A0 "state": "af0ifjsldkj",
=C2=A0 =C2=A0 =C2=A0 "nonce": "n-0S6_WzA2Mj",
=C2=A0 =C2=A0 =C2=A0 "max_age": 86400
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0Signing it with the "RS256" algorithm results in thi= s Request Object
=C2=A0 =C2=A0value (with line wraps within values for display purposes only= ):

=C2=A0 =C2=A0 =C2=A0eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA= iczZCaGRSa3
=C2=A0 =C2=A0 =C2=A0F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvb= SIsDQogInJl
=C2=A0 =C2=A0 =C2=A0c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9= pZCI6ICJzNk
=C2=A0 =C2=A0 =C2=A0JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZ= W50LmV4YW1w
=C2=A0 =C2=A0 =C2=A0bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGU= iOiAiYWYwaW
=C2=A0 =C2=A0 =C2=A0Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtY= XhfYWdlIjog
=C2=A0 =C2=A0 =C2=A0ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiA= NCiAgICB7DQ
=C2=A0 =C2=A0 =C2=A0ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNC= iAgICAgIm5p
=C2=A0 =C2=A0 =C2=A0Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWw= iOiB0cnVlfS
=C2=A0 =C2=A0 =C2=A0wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0c= nVlfSwNCiAg
=C2=A0 =C2=A0 =C2=A0ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI= 6IA0KICAgIH
=C2=A0 =C2=A0 =C2=A0sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiO= iB7ImVzc2Vu
=C2=A0 =C2=A0 =C2=A0dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInV= ybjptYWNlOm
=C2=A0 =C2=A0 =C2=A0luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnN= sk1-Zkbmnvs
=C2=A0 =C2=A0 =C2=A0F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9= Emo_wHwajyF
=C2=A0 =C2=A0 =C2=A0KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68Pkg= jDVTrG1uRTx
=C2=A0 =C2=A0 =C2=A00GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfq= KnRlrRscc8K
=C2=A0 =C2=A0 =C2=A0ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pX= fLSjLLlxmPG
=C2=A0 =C2=A0 =C2=A0iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwU= sAlMGzw

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"userinfo":
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0"given_name": {"essential": true},<= br> =C2=A0 =C2=A0 =C2=A0"nickname": null,
=C2=A0 =C2=A0 =C2=A0"email": {"essential": true},
=C2=A0 =C2=A0 =C2=A0"email_verified": {"essential": tru= e},
=C2=A0 =C2=A0 =C2=A0"picture": null
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0"id_token":
=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:i= ncommon:iap:silver"]}
=C2=A0 =C2=A0 }
=C2=A0 }
}

I'm not sure where the "claims" claim is coming from -- 6749 = doesn't
seem to talk about it.=C2=A0 (Note that this example is used later on as well.)

Section 5.2.1

=C2=A0 =C2=A0It is possible for the Request Object to include values that a= re to
=C2=A0 =C2=A0be revealed only to the Authorization Server.=C2=A0 As such, t= he
=C2=A0 =C2=A0"request_uri" MUST have appropriate entropy for its = lifetime.=C2=A0 For
=C2=A0 =C2=A0the guidance, refer to 5.1.4.2.2 of [RFC6819].=C2=A0 It is REC= OMMENDED
=C2=A0 =C2=A0that it be removed after a reasonable timeout unless access co= ntrol
=C2=A0 =C2=A0measures 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

=C2=A0 =C2=A0The following is an example of this fetch process:

=C2=A0 =C2=A0 =C2=A0GET /request.jwt HTTP/1.1
=C2=A0 =C2=A0 =C2=A0Host: 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

=C2=A0 =C2=A0The Authorization Server MUST perform the signature validation= of the
=C2=A0 =C2=A0JSON 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=A0pre-registered algorithm.=C2=A0 The signature MUST be validate= d against
=C2=A0 =C2=A0the appropriate key for that "client_id" and algorit= hm.

Does "the pre-registered algorithm" concept exist in the specs ou= tside
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 gue= ss 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

=C2=A0 =C2=A0When sending the authorization request object through "re= quest"
=C2=A0 =C2=A0parameter, it MUST either be signed using JWS [RFC7515] or enc= rypted
=C2=A0 =C2=A0using 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".=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 JWE encrypt= ion is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 correct one if the JWE is using symmetric encry= ption.

Similarly to the previous point, you also need to check the signature,
which will always be there.

=C2=A0 =C2=A0(d)=C2=A0 Authorization Server is providing an endpoint that p= rovides a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object URI in exchange for a Request Ob= ject.=C2=A0 In this

I don't think this is a complete sentence (and it's definitely not = a
parallel construction with (a)-(c)!).=C2=A0 I think perhaps a crisp one-lin= e
summary of this method would be "Delegating the authorization check to= a
separate "Request Object to Request Object URI" endpoint on the Authorization Server".=C2=A0 (The writing in the rest of this paragrap= h could
also use an editing pass.)

=C2=A0 =C2=A0(e)=C2=A0 A third party, such as a Trust Framework Provider, p= rovides an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoint that provides a Request Object URI in = exchange for a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object.=C2=A0 The same requirements as = (b) above apply.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addition, the Authorization Server MUST know ou= t-of-band that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the Client utilizes the Trust Framework Operato= r.

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 questi= on in
this specification" is supposed to mean -- is it just "the OAuth = 2.0
endpoints presently defined in Standards-Track RFCs"?

=C2=A0 =C2=A0In [RFC6749], while Redirection URI is included, others are no= t
=C2=A0 =C2=A0included in the Authorization Request.=C2=A0 As the result, th= e same
=C2=A0 =C2=A0applies 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

=C2=A0 =C2=A0"request_uri", and (d) do not perform recursive GET = on the
=C2=A0 =C2=A0"request_uri".

nit: remove the "do" in order to make the construction parallel.<= br>
Section 12.1

=C2=A0 =C2=A0It is often hard for the user to find out if the personal data= asked
=C2=A0 =C2=A0for is strictly necessary.=C2=A0 A Trust Framework Provider ca= n help the
=C2=A0 =C2=A0user by examining the Client request and comparing to the prop= osed
=C2=A0 =C2=A0processing by the Client and certifying the request.=C2=A0 Aft= er the
=C2=A0 =C2=A0certification, the Client, when making an Authorization Reques= t, can
=C2=A0 =C2=A0submit Authorization Request to the Trust Framework Provider t= o
=C2=A0 =C2=A0obtain 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

=C2=A0 =C2=A0Even if the protected resource does not include a personally =C2=A0 =C2=A0identifiable information, it is sometimes possible to identify= the
=C2=A0 =C2=A0user through the Request Object URI if persistent per-user Req= uest
=C2=A0 =C2=A0Object 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=A0Therefore, per-user Request Object URI should be avoided.

nit: I think this is better as "static per-user Requeste Object URIs&q= uot;.

Section 13

Are there two different paragraphs for "contributions from the OAuth W= G
members"?=C2=A0 Are they reflecting different types of contribution?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=3Dnat)
Chairman, Open= ID Foundation
htt= p://nat.sakimura.org/
@_nat_en
--000000000000494aea0595e0ca6f-- From nobody Mon Oct 28 05:42:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3712004C for ; Mon, 28 Oct 2019 05:42:18 -0700 (PDT) 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=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 IaKJM8slPxdq for ; Mon, 28 Oct 2019 05:42:17 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93301120018 for ; Mon, 28 Oct 2019 05:42:16 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id t8so7647822lfc.13 for ; Mon, 28 Oct 2019 05:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jfWhc/v9Dzrocbha/NNEIP0LaLKceVQH1WriBG2LJxc=; b=cHACZvOExtu3lGKExiJF9G+Nx2oQukyeiU+XkoszsEZs08a+LJKBmUN8CFC6Dx3J6y QOINVjSYiJmM/K6aAL1k44cE5QeBERbKhGi+8bBBuk8zoJPk//ERiGRcGEuxYm4j65xF RkCefBQbKsLOGdIhyIcAbotzFmP3YH7ZX+XYE= 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=jfWhc/v9Dzrocbha/NNEIP0LaLKceVQH1WriBG2LJxc=; b=I8NiVdmMKjuovfQV68vHuwKyN/hfprcl6cpY9R4yAQK4RkIMVHJsbFl5gNTJHGqvhA c5WVyq/ud+oAbux/X1TBWUBKYYEUvrMlkPsQQ80v6iGXPoA+XwLaH3qgQomd0QK1F7dY GaKH4J59nsHq79Qk/NlvlFeDltXDqBKeB1tIioRgc8paUGCpU9age0ZnosRC6yFbcoTP z4rjMxa0LP3Paa3JnhDzLkWVEa0RR918y9zwnK2He/LT5epxMo4razsLGmbvo8ZyJskL WA6GVonqdP0WGPEsoDxF7D+5w70pz/8hza1Bj4W4kgM9LnKVM8x7qXLpyjUviiVZHyXl dcZw== X-Gm-Message-State: APjAAAVhErsglUkaolfdWepWDDpJ1MXEtPT19ExdMqxqXgFz1RLxT2RK 7P8/M4RY0sJbAcv1LLs9lo4WoQxR4BGnpQqdMvvkZfdEyG8n0oaUHOdVSP8XHX5QA4CuHkjbb3B vCFcW9ZCWgtZq7g== X-Google-Smtp-Source: APXvYqwp+MRb2uQgZ0RLhW/XO/ss6ibK6aDe3Dinkg1o6f4A8bVtwr9lP+n7C6qn4G5TMxWeT0nwKqlLOynRQLeM1dI= X-Received: by 2002:a19:f811:: with SMTP id a17mr1874691lff.132.1572266534597; Mon, 28 Oct 2019 05:42:14 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Mon, 28 Oct 2019 06:41:48 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="00000000000049972b0595f7d49c" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 12:42:19 -0000 --00000000000049972b0595f7d49c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef wrote: > > On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell > wrote: > >> >> I did look at RFC7239 when doing that and it could have been made to wor= k >> but felt the fit wasn't quite right and would have been more cumbersome = to >> use than not. >> >> > Can you elaborate on this? > These days, with the zero trust model in mind, there are orchestration > tools, e.g. Istio, that easily allows you to establish an MTLS channel > between the reverse proxy/load balancer/API GW and the backend servers. > Why is that not sufficient? > Which part is cumbersome? > What I meant was only that in the course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to define HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, it seemed more straightforward and sufficient for the use-case to use new HTTP headers to carry the information rather than to use new fields in the Forwarded header framework from RFC7239. --=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._ --00000000000049972b0595f7d49c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Oct 26, 2019 at 3:55 PM Rifaa= t Shekh-Yusef <rifaat.ietf@gmai= l.com> wrote:

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:

I did look at = RFC7239 when doing that and it could have been made to work but felt the fi= t wasn't quite right and would have been more cumbersome to use than no= t.=C2=A0


<= div>Can you elaborate on this?
These days, with the zero trust mo= del in mind, there are orchestration tools, e.g. Istio, that easily allows = you to establish an MTLS channel between the reverse proxy/load balancer/AP= I GW and the backend servers.
Why is that not sufficient?=C2= =A0
Which part is cumbersome?
=
What I meant was only that in the course of writing https://tools.i= etf.org/html/draft-ietf-tokbind-ttrp-09, which aims to define HTTP head= er fields that enable a TLS terminating reverse proxy to convey information= to a backend server about the validated Token Binding Message received fro= m a client, it seemed more straightforward and sufficient for the use-case = to use new HTTP headers to carry the information rather than to use new fie= lds in the Forwarded header framework from RFC7239.=C2=A0 =C2=A0
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000049972b0595f7d49c-- From nobody Mon Oct 28 08:05:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1F12010F for ; Mon, 28 Oct 2019 08:05:25 -0700 (PDT) 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 XxoGugxT3QjB for ; Mon, 28 Oct 2019 08:05:23 -0700 (PDT) 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 6D399120071 for ; Mon, 28 Oct 2019 08:05:23 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id c11so11019808iom.10 for ; Mon, 28 Oct 2019 08:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=10KSBIH1v3R7um9wuUay5yTEXOHJp0agh39XNBpsXHU=; b=DO4lcsuK8ir7p2ddYkGbroqnmLr4KpQPPBH9kAzwX4SQI98/Gn6svoVsCjUeqMYcKH f5w4trLS0LZOC16skL+TB9ajGHBZSiPGxrQqH6Cc1n42GLpbWjcxfi6x0rq+UvNJ2p1d JT9Lp8tF2lB6+9qaENCaY7X8LYdi81mVIPcXDwB+fF6aH8J8dk0k3OIqgi5UqLWZHGXE VDNwRIqEyRNG1OErpP970vWHUt5V2O4a5NTpJCw2SIuNEboMe1/iQIfLlLqtFhSiSW12 Vz9d2LJibuZimXR2e+NcdPTvGkZUYNHw5ge/t2wa2q/Kr9eO3q7oY8bcjdEv2sdD/+RY 45bg== 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=10KSBIH1v3R7um9wuUay5yTEXOHJp0agh39XNBpsXHU=; b=ga+w8zDrlPmJ6WumywSDwVHrGJyfdLo6BuICSQIIae2J2Utm9juWdWJcVyVNjDNvIH fg07n+uKkcdonTwvkphfVwuLArochrf/SlWpDTUgPH+qGUNDT9IQ3R4HxMhEXGbEXcC+ v6LBbtk0VhNHYSqQWy5r+XTNV6r9Wb2aJUYtwKnBMYmwKkZWqaVF2hBxkGOvNKEPt01U jIJj5QoLKy9z/Tf7y2BkjWRFOhclto0ZRMcQ5qhpWKwEvFcBrz1FtDpEwIytWEXPzw1B T1guGKcoyH9k/cJ847l0lM3mlb8tskSkSoydidJTsyPD3eFU67s4oFnwCdmqRk/aO+ky vOnA== X-Gm-Message-State: APjAAAVGr78iAkyqM8OtTrbeqoNlzRv1zLspy9ynKcINtSi6W6WpHlS6 2g4v7vjTN9EIRKLh9or3A8hfx1+UHWU63appHoM= X-Google-Smtp-Source: APXvYqyK3Hn5Ie3NWFJzLKB9LzVjldTnkwxLEWLrHQnZY76q0aAmVx5tlLMAgadraHjM1hJyF1H/fjtcTP7HYQVS7JE= X-Received: by 2002:a02:c48e:: with SMTP id t14mr10167720jam.121.1572275122695; Mon, 28 Oct 2019 08:05:22 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 28 Oct 2019 11:05:10 -0400 Message-ID: To: Brian Campbell Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000002d71610595f9d47f" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 15:05:25 -0000 --0000000000002d71610595f9d47f Content-Type: text/plain; charset="UTF-8" Thanks Brian, I guess my question is: given RFC7239 and the fact that it is straightforward to secure the channel between the terminating reverse proxy and the backend service in a cluster, is there anything, from a standard perspective, that we need to do beyond defining a new parameter to carry the client certificate information? You seem suggest that the answer is yes. If so, can you please elaborate on why is that? Regards, Rifaat On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell wrote: > > > On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef > wrote: > >> >> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> >>> I did look at RFC7239 when doing that and it could have been made to >>> work but felt the fit wasn't quite right and would have been more >>> cumbersome to use than not. >>> >>> >> Can you elaborate on this? >> These days, with the zero trust model in mind, there are orchestration >> tools, e.g. Istio, that easily allows you to establish an MTLS channel >> between the reverse proxy/load balancer/API GW and the backend servers. >> Why is that not sufficient? >> Which part is cumbersome? >> > > What I meant was only that in the course of writing > https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to > define HTTP header fields that enable a TLS terminating reverse proxy to > convey information to a backend server about the validated Token Binding > Message received from a client, it seemed more straightforward and > sufficient for the use-case to use new HTTP headers to carry the > information rather than to use new fields in the Forwarded header framework > from RFC7239. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --0000000000002d71610595f9d47f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Brian,

I guess my= question is: given RFC7239 and the fact that it is straightforward=C2=A0to= secure the channel=C2=A0between the terminating reverse proxy and the back= end service in a cluster, is there anything, from a standard perspective, t= hat we need to do beyond defining a new parameter to carry the client certi= ficate information?
You seem suggest that the answer is yes. If so, can= you please elaborate on why is that?

Regards,
=
=C2=A0Rifaat



On Mon, Oct 28, = 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:


On S= at, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com&g= t; wrote:

I did look at RFC7239 when doing that = and it could have been made to work but felt the fit wasn't quite right= and would have been more cumbersome to use than not.=C2=A0
=

Can you elaborate on= this?
These days, with the zero trust model in mind, there are o= rchestration tools, e.g. Istio, that easily allows you to establish an MTLS= channel between the reverse proxy/load balancer/API GW and the backend ser= vers.
Why is that not sufficient?=C2=A0
Which part = is cumbersome?

What I mea= nt was only that in the course of writing https://tools.ietf.org/= html/draft-ietf-tokbind-ttrp-09, which aims to define HTTP header field= s that enable a TLS terminating reverse proxy to convey information to a ba= ckend server about the validated Token Binding Message received from a clie= nt, it seemed more straightforward and sufficient for the use-case to use n= ew HTTP headers to carry the information rather than to use new fields in t= he Forwarded header framework from RFC7239.=C2=A0 =C2=A0
=C2=A0<= /div>

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--0000000000002d71610595f9d47f-- From nobody Mon Oct 28 08:33:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB7912091C for ; Mon, 28 Oct 2019 08:32:58 -0700 (PDT) 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=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 sAeKqaURvfoS for ; Mon, 28 Oct 2019 08:32:56 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8D61208D4 for ; Mon, 28 Oct 2019 08:32:55 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id f5so8154101lfp.1 for ; Mon, 28 Oct 2019 08:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GR0bXEeJUl15OSIA3MTmDl86iBJDKFM1XmPqzMFFE0g=; b=bIEdiYuwFeN6oGeaa2GKpeX0ZeFcKlEY5lTrGiscimfGCi+BBz8osCwdOrAl+N42s6 Eh5Yzy+EOmVhqW+Vzq/ejFabYWfda+qtqejd+CjvSX/9sVm+Ng5RdxRqjsmbfBM4iWLw IkPD+6S6VACg5LjS8MCOKAaWUFIMA7GrCuUH4= 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=GR0bXEeJUl15OSIA3MTmDl86iBJDKFM1XmPqzMFFE0g=; b=sS8MNTvxUJtP9OX2XOIOwNRBor4XiJzD87dfQRiJnGSSvk0DEMcCRJbcwzNm9XHUFd s/mUE9FSJA8hTV9VQUQakOmUvk8Frvy0J5//L1CnOYjvFL3ywIWBmxwG1eo0wrSNHYoV dp6CsMj451ujfdnUpq4/oF0oRuG55oaOlHX9CrLv/tKGuDYKgRinybek6meeocylNdLH 8Kj/DwSucFYdICnVDyVLCrep9IaJFo6LPqkalh4q4cVmS2ENjPeSGKgtq01ARmkz6RtQ 582A4bQ8kHrybYKiY62922+8t6j6O0rq6OKo/VuyRB+ENudOhbfJcHDVMl/NmVObyX0f K9BQ== X-Gm-Message-State: APjAAAWT+iA+DrM1Yt6hUY+3C2s+KeFTBqDByoz8L0nfiNrEGXKGqLWP bZ1zXlcAAMGUfLFEsVLnJNoUjLHBwTXVZHhFmb4Vz1tWByZ4+/tsAOVX2Jl+4yDU+X10WpP9NK4 wk/3U4Zv00bnVTw== X-Google-Smtp-Source: APXvYqyIzm01ot5Z9f//S7Gj+orrS+6IwWHfPQ48c7Tl12clkQoUufvU/PduEl9Sb3S6C1xZHdY0PmKXAqscN9tHIWA= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr10895560lff.17.1572276773970; Mon, 28 Oct 2019 08:32:53 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Mon, 28 Oct 2019 09:32:27 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000009a03490595fa3616" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 15:33:02 -0000 --0000000000009a03490595fa3616 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think there's anything beyond defining something to carry the client certificate information (including the format and encoding). And it could well be a new RFC7239 parameter. Or it might just be a new HTTP header on its own. On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef wrote: > Thanks Brian, > > I guess my question is: given RFC7239 and the fact that it is > straightforward to secure the channel between the terminating reverse pro= xy > and the backend service in a cluster, is there anything, from a standard > perspective, that we need to do beyond defining a new parameter to carry > the client certificate information? > You seem suggest that the answer is yes. If so, can you please elaborate > on why is that? > > Regards, > Rifaat > > > > On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell > wrote: > >> >> >> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef >> wrote: >> >>> >>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> >>>> I did look at RFC7239 when doing that and it could have been made to >>>> work but felt the fit wasn't quite right and would have been more >>>> cumbersome to use than not. >>>> >>>> >>> Can you elaborate on this? >>> These days, with the zero trust model in mind, there are orchestration >>> tools, e.g. Istio, that easily allows you to establish an MTLS channel >>> between the reverse proxy/load balancer/API GW and the backend servers. >>> Why is that not sufficient? >>> Which part is cumbersome? >>> >> >> What I meant was only that in the course of writing >> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to >> define HTTP header fields that enable a TLS terminating reverse proxy to >> convey information to a backend server about the validated Token Binding >> Message received from a client, it seemed more straightforward and >> sufficient for the use-case to use new HTTP headers to carry the >> information rather than to use new fields in the Forwarded header framew= ork >> from RFC7239. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended 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._ --0000000000009a03490595fa3616 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think there's anything beyond defining som= ething to carry the client certificate information (including the format an= d encoding). And it could well be a new RFC7239 parameter. Or it might just= be a new HTTP header on its own.=C2=A0

On Mon, Oct 28, 2019 at 9:05 AM Rif= aat Shekh-Yusef <rifaat.ietf@gm= ail.com> wrote:
Thanks=C2=A0Brian,

I g= uess my question is: given RFC7239 and the fact that it is straightforward= =C2=A0to secure the channel=C2=A0between the terminating reverse proxy and = the backend service in a cluster, is there anything, from a standard perspe= ctive, that we need to do beyond defining a new parameter to carry the clie= nt certificate information?
You seem suggest that the answer is yes. If= so, can you please elaborate on why is that?

Regard= s,
=C2=A0Rifaat


On Mon, = Oct 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
=


On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <= ;rifaat.ietf@gma= il.com> wrote:

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbel= l <bcamp= bell@pingidentity.com> wrote:

I did look = at RFC7239 when doing that and it could have been made to work but felt the= fit wasn't quite right and would have been more cumbersome to use than= not.=C2=A0


Can you elaborate on this?
These days, with the zero trust= model in mind, there are orchestration tools, e.g. Istio, that easily allo= ws you to establish an MTLS channel between the reverse proxy/load balancer= /API GW and the backend servers.
Why is that not sufficient?= =C2=A0
Which part is cumbersome?

What I meant was only that in the course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims= to define HTTP header fields that enable a TLS terminating reverse proxy t= o convey information to a backend server about the validated Token Binding = Message received from a client, it seemed more straightforward and sufficie= nt for the use-case to use new HTTP headers to carry the information rather= than to use new fields in the Forwarded header framework from RFC7239.=C2= =A0 =C2=A0
=C2=A0

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. --0000000000009a03490595fa3616-- From nobody Mon Oct 28 08:39:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33FF1208C5; Mon, 28 Oct 2019 08:39:47 -0700 (PDT) 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 tjHcI8Anwg_p; Mon, 28 Oct 2019 08:39:46 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880C71208C4; Mon, 28 Oct 2019 08:39:46 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id c4so11837132lja.11; Mon, 28 Oct 2019 08:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0KnNIvOUY1Ci7eKqxUvXLJTMfR8oJZJNmbzm1YKNiyU=; b=KbPraKkil9NxxLmu5r4MTxuEzhAV+nbkcBvoS81GO2xsoKHByXESCuRr7jTg/UAdUi 8N8lYn+X9DKxRlm4Bn2EgpdqT8r7O4SFkBvRw798G0iw5OACnKjrhhvGxW7rU2yX1jsX kXKYmNrUzEnRDx0KpQo8QswNymAV1MYXyE/fxb1ixlQIbsnD6FhV3soW3+Tq9psF77RW 6vfpTKRNNvdcHD8GYJGna2d7E6BYd301ZiyCtBMrDWPB1DHWhG8H57JP3yAUlG9aGUj3 VVFR0UoMg59s7CLqgscnzFFfoAbx7RgOijbFEJFrJrYoqP6SjU1Z3iiXnsEyFA+YfSip uoOA== 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=0KnNIvOUY1Ci7eKqxUvXLJTMfR8oJZJNmbzm1YKNiyU=; b=DPP6JwhI8WdZsorqOkWMsQHjc3xY+8xuOZ8Tc4p6bUteYs5BMiRvK5i3ISahQAt/Qp TQKuCG+RtkDA7A847f3D3vl56Q3cqKN6Pyi9QCrxUeIslWqyLHdCYnFJ8tOq58vAb9Uj c+p4uIQng06Cr8eW/N5dvgjQL+bWMxpXRTMDlnO1CTszlSLQ+79J+4rUvk3K5Vaxd6q9 aX7Qebjc0J5W9mzaPJ/B1jCyrh2ke3R1gt5ebanC620RN/vpB+Rq42feXKnsXXicuXiL JShpBs60ygoG2/ZzubwjhMeixhuyFywXaU40iX1I0kVfvBSTeMv94+E+DJE5ndiCCA/q BUgw== X-Gm-Message-State: APjAAAXHktwcn6gfcppe56UJlLf9nDHgbd7mzi32bN2S0vaKNPpwV43S lVPH93TuWQGHd+UoZt+LgWjHwE0VcPFkWKtcyUXIlW/nhAc= X-Google-Smtp-Source: APXvYqyzmAhoPu8SDLGqgmLQinRqhBlREOQ4UntrAOJTrKC0e5hhWW0vrADEl/wDOzYhujrhm/laxRYGp45Oy1MG5LA= X-Received: by 2002:a2e:9112:: with SMTP id m18mr12720217ljg.75.1572277184527; Mon, 28 Oct 2019 08:39:44 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 28 Oct 2019 08:39:33 -0700 Message-ID: To: oauth@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000001282d40595fa4f09" Archived-At: Subject: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 15:39:48 -0000 --0000000000001282d40595fa4f09 Content-Type: text/plain; charset="UTF-8" Hey OAuthers As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday Afternoon, I'm gathering who would be interested in making presentations, and how much time you would like. /Dick --0000000000001282d40595fa4f09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey OAuthers

As chair of the Tx BOF coming up in Singapore on Nov 1= 8 @ 5:30-7:30PM Monday Afternoon, I&= #39;m gathering who would be interested in making presentations, and how mu= ch time you would like.

/Dick
--0000000000001282d40595fa4f09-- From nobody Mon Oct 28 09:00:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CA71201E4 for ; Mon, 28 Oct 2019 09:00:25 -0700 (PDT) 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 waEF-XMdOuTb for ; Mon, 28 Oct 2019 09:00:15 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB65120098 for ; Mon, 28 Oct 2019 09:00:15 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k20so1231912ior.0 for ; Mon, 28 Oct 2019 09:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vPRQAtsMnxcvosIaiWPHje8mBV7Vy5w3bG1CRMpVkyU=; b=Tnj92cC0l4qsn5VuseZUngIXWs1fQ2tPMGEUlxM+YP1A9nEp5i/C+q/BCOO0q7oIZC rCSBst5W0aoHjsH6Hs0V/VQxnRI2UOb76eeDDG+UV/qkIAoD1wjFuGKbsQcbwMJlRJBX 1uMKkZTEZa1HxovGJ9SRtO98rSaYfdu7pTP4A8DS5TTOuudaqeDjUh9J8UpXKF3f00Zy Ne80DxowgfsNLXUGiI5THz1xBnf3OSkDy6twcJaXpxLCitr0iWjhNYFzc12G3bnvZBvj WCnSIjj4YXoJg4YiWkezI89PTYJaZbBUbYdVTfouQ6V7Mr5vxrpancfVk8mYlp6fvR4d S3Pw== 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=vPRQAtsMnxcvosIaiWPHje8mBV7Vy5w3bG1CRMpVkyU=; b=YX7gpKG0dEO9Vv1xjp4zre6mkwonBHwzmq46XTJCi3mtfC1ZdHXftoRjPvGY40yvhx kR1g1EfwStK4/RX8wu/kqRu4Bq31RfJhyTftA89G76mgOGcW9m/0r8dI6QFMzBDQmx5w M1AyKQHqzKMu0MCazzX21mrIJqJcjD3L1SZotGT4rS6njWMi2xIaYUiitLuRDXz6A9og DxeRiNN50jvRor71WpUk50EWjfsyR3r8aNDSd24Prq1XsJsNEK9TR5+wYGEmV4ofW/3Y JL8+ipnK7wusXBC68MTLC9TQdWrRFbe9HnOcJKtf0BJ/Zlu1KktCoAH40/A360EJBeNg uwAA== X-Gm-Message-State: APjAAAUryQTy5ZuV93VDDOBgshFPfaeRfmWIiKq5rVgygHDkmkxydb9r kQ5mfeQVivmO9W9oeG5jID1pgZCIKk/jbGTXQhk= X-Google-Smtp-Source: APXvYqzoV7i5xhPno1QHfwTC8PRLOhU7zlIDhtauS8hS8o0qJsAyoJJLZHDuQUQsfK4D65S1V3m/g0jZA/8CJxQndpU= X-Received: by 2002:a02:1c41:: with SMTP id c62mr15907563jac.132.1572278414573; Mon, 28 Oct 2019 09:00:14 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 28 Oct 2019 12:00:02 -0400 Message-ID: To: Brian Campbell Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="0000000000006385690595fa983b" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 16:00:26 -0000 --0000000000006385690595fa983b Content-Type: text/plain; charset="UTF-8" Ok, then we are on the same page. The reason I am asking is that I have a use case where I need such a mechanism. What is the advantage you see for defining a new HTTP header over extending RFC7239? Regards, Rifaat On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell wrote: > I don't think there's anything beyond defining something to carry the > client certificate information (including the format and encoding). And it > could well be a new RFC7239 parameter. Or it might just be a new HTTP > header on its own. > > On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef > wrote: > >> Thanks Brian, >> >> I guess my question is: given RFC7239 and the fact that it is >> straightforward to secure the channel between the terminating reverse proxy >> and the backend service in a cluster, is there anything, from a standard >> perspective, that we need to do beyond defining a new parameter to carry >> the client certificate information? >> You seem suggest that the answer is yes. If so, can you please elaborate >> on why is that? >> >> Regards, >> Rifaat >> >> >> >> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> >>> >>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>>> >>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> >>>>> I did look at RFC7239 when doing that and it could have been made to >>>>> work but felt the fit wasn't quite right and would have been more >>>>> cumbersome to use than not. >>>>> >>>>> >>>> Can you elaborate on this? >>>> These days, with the zero trust model in mind, there are orchestration >>>> tools, e.g. Istio, that easily allows you to establish an MTLS channel >>>> between the reverse proxy/load balancer/API GW and the backend servers. >>>> Why is that not sufficient? >>>> Which part is cumbersome? >>>> >>> >>> What I meant was only that in the course of writing >>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to >>> define HTTP header fields that enable a TLS terminating reverse proxy to >>> convey information to a backend server about the validated Token Binding >>> Message received from a client, it seemed more straightforward and >>> sufficient for the use-case to use new HTTP headers to carry the >>> information rather than to use new fields in the Forwarded header framework >>> from RFC7239. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this 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.* --0000000000006385690595fa983b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, then we are on the same page.=C2=A0
The= reason I am asking is that I have a use case where I need such a mechanism= .

What is the advantage you see for defining a new= HTTP header over extending RFC7239?

Regards,
=C2=A0Rifaat



On Mon, Oct 28, 2019 at 11:= 32 AM Brian Campbell <bcam= pbell@pingidentity.com> wrote:
I don't think there's anythi= ng beyond defining something to carry the client certificate information (i= ncluding the format and encoding). And it could well be a new RFC7239 param= eter. Or it might just be a new HTTP header on its own.=C2=A0

On Mon, Oct 2= 8, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thanks= =C2=A0Brian,

I guess my question is: given RFC7239 = and the fact that it is straightforward=C2=A0to secure the channel=C2=A0bet= ween the terminating reverse proxy and the backend service in a cluster, is= there anything, from a standard perspective, that we need to do beyond def= ining a new parameter to carry the client certificate information?
You = seem suggest that the answer is yes. If so, can you please elaborate on why= is that?

Regards,
=C2=A0Rifaat
=


On Mon, Oct 28, 2019 at 8:42 AM Brian Campbe= ll <bcam= pbell@pingidentity.com> wrote:


On Sat, Oct 26,= 2019 at 3:55 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

On Fri, = Oct 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
=

I did look at RFC7239 when doing that and it coul= d have been made to work but felt the fit wasn't quite right and would = have been more cumbersome to use than not.=C2=A0

<= /div>

Can you elaborate on this?
These days, with the zero trust model in mind, there are orchestratio= n tools, e.g. Istio, that easily allows you to establish an MTLS channel be= tween the reverse proxy/load balancer/API GW and the backend servers.
Why is that not sufficient?=C2=A0
Which part is cumberso= me?

What I meant was only= that in the course of writing https://tools.ietf.org/html/draft-= ietf-tokbind-ttrp-09, which aims to define HTTP header fields that enab= le a TLS terminating reverse proxy to convey information to a backend serve= r about the validated Token Binding Message received from a client, it seem= ed more straightforward and sufficient for the use-case to use new HTTP hea= ders to carry the information rather than to use new fields in the Forwarde= d header framework from RFC7239.=C2=A0 =C2=A0
=C2=A0
=

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.
--0000000000006385690595fa983b-- From nobody Mon Oct 28 09:32:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8725E1208C4 for ; Mon, 28 Oct 2019 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kHPMwgyQ4McU for ; Mon, 28 Oct 2019 09:32:41 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CC31208AA for ; Mon, 28 Oct 2019 09:32:41 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id z11so10557518wro.11 for ; Mon, 28 Oct 2019 09:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AJI0el2iuMpvwMfg1CwFHUL2u9OyUOCiMJhtJSYwnro=; b=RhfdMn4QmcDyNlSCK+8+tpAUPvFTItJI0qR4aS080GmSju2x6U4knkJBFwJKZHIdfb pvxJrboDW7TeyKqkrW2bQ7m00T5/zjc1ZKjcZBIdQVPsr6/deAkAbsC+nBi8csF1auDw 4hH/XA3OIT7o1ilS8RBJr1QZOgJ1bbGrWHbDg= 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=AJI0el2iuMpvwMfg1CwFHUL2u9OyUOCiMJhtJSYwnro=; b=belkbd8SxKKZw5CWEN4Hf1KmbNUfExjnwos451BUTnHtlqQKG1o/vIr3sMQTqEXg6z rUkp1KSooe6u3myRXCkNTbfLNTNCmsmuQrcfjvC36ghe6W8KfSOL/Spta6ASbk7nV62I bDCBFZxKZKUaOxnQOJil7Hphs8+YFgtnQXBs2vmbmnrMLBVTJq902OWYmXWzPIA0z9Kf 4uLX5247Jrl4Va+XJ7xuDHSyzjj1DEl4AvV9pMXY8RS+2Y39vJmnya90UXZe8lpf2OG4 U076uJipcWIZpreDPj7ZOT5DTKlbX6a+W1sdTuKC2mvvcCN9LVCSbmTatma/zUfaawOX PCdA== X-Gm-Message-State: APjAAAXkqEEjMK6TUx0hPe0cDHGd+2F6E1vQxn3WGW3GGr6jl/UznIMb oLdVSxWZO7WPcXKuC9DnPyGzaw== X-Google-Smtp-Source: APXvYqxi6oLgQDIQKkabqnGE2zhTgdFNeB2QfYQxqK2XAUuucSlj4vBcU1ZcbipXDMAPFVZ83yMDPQ== X-Received: by 2002:a5d:678e:: with SMTP id v14mr15207924wru.393.1572280359661; Mon, 28 Oct 2019 09:32:39 -0700 (PDT) Received: from [192.168.1.64] (227.249.143.150.dyn.plus.net. [150.143.249.227]) by smtp.gmail.com with ESMTPSA id r188sm100878wmr.17.2019.10.28.09.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 09:32:38 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EC53E624-EF68-497D-AB57-76068DD10846" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 28 Oct 2019 16:32:37 +0000 In-Reply-To: Cc: Rifaat Shekh-Yusef , oauth To: Brian Campbell References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 16:32:44 -0000 --Apple-Mail=_EC53E624-EF68-497D-AB57-76068DD10846 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While there are some benefits to standardizing headers for this kind of = communication, there are some significant downsides - particularly when = using headers to communicate critical security information like certs. = It is *very* easy to misconfigure a reverse proxy to not strip Forwarded = (or whatever) headers from incoming requests, allowing a client to = simply supply a certificate as a header without authenticating the TLS = connection with the corresponding private key. One good practice to = prevent this is to pick a random and unguessable header name = (configurable per installation) to be used for communicating the = certificate, rather than using something fixed and standard. That way = even if you misconfigure the proxy an attacker still has to try and = guess the correct header name. I suppose the same thing could be accomplished by having an extension = for including a shared secret (or HMAC tag) in the header to = authenticate it. -- Neil > On 28 Oct 2019, at 15:32, Brian Campbell = wrote: >=20 > I don't think there's anything beyond defining something to carry the = client certificate information (including the format and encoding). And = it could well be a new RFC7239 parameter. Or it might just be a new HTTP = header on its own. =20 >=20 > On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef = > wrote: > Thanks Brian, >=20 > I guess my question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating reverse = proxy and the backend service in a cluster, is there anything, from a = standard perspective, that we need to do beyond defining a new parameter = to carry the client certificate information? > You seem suggest that the answer is yes. If so, can you please = elaborate on why is that? >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell = > wrote: >=20 >=20 > On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef = > wrote: >=20 > On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell = > wrote: >=20 > I did look at RFC7239 when doing that and it could have been made to = work but felt the fit wasn't quite right and would have been more = cumbersome to use than not. =20 >=20 >=20 > Can you elaborate on this? > These days, with the zero trust model in mind, there are orchestration = tools, e.g. Istio, that easily allows you to establish an MTLS channel = between the reverse proxy/load balancer/API GW and the backend servers. > Why is that not sufficient?=20 > Which part is cumbersome? >=20 > What I meant was only that in the course of writing = https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09 = , which aims to = define HTTP header fields that enable a TLS terminating reverse proxy to = convey information to a backend server about the validated Token Binding = Message received from a client, it seemed more straightforward and = sufficient for the use-case to use new HTTP headers to carry the = information rather than to use new fields in the Forwarded header = framework from RFC7239. =20 > =20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=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=_EC53E624-EF68-497D-AB57-76068DD10846 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii While= there are some benefits to standardizing headers for this kind of = communication, there are some significant downsides - particularly when = using headers to communicate critical security information like certs. = It is *very* easy to misconfigure a reverse proxy to not strip Forwarded = (or whatever) headers from incoming requests, allowing a client to = simply supply a certificate as a header without authenticating the TLS = connection with the corresponding private key. One good practice to = prevent this is to pick a random and unguessable header name = (configurable per installation) to be used for communicating the = certificate, rather than using something fixed and standard. That way = even if you misconfigure the proxy an attacker still has to try and = guess the correct header name.

I suppose the same thing could be accomplished by having an = extension for including a shared secret (or HMAC tag) in the header to = authenticate it.

-- Neil

On 28 Oct 2019, at 15:32, Brian = Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I don't think there's anything beyond defining = something to carry the client certificate information (including the = format and encoding). And it could well be a new RFC7239 parameter. Or = it might just be a new HTTP header on its own.  

On Mon, = Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thanks Brian,

I guess my = question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating = reverse proxy and the backend service in a cluster, is there anything, = from a standard perspective, that we need to do beyond defining a new = parameter to carry the client certificate information?
You = seem suggest that the answer is yes. If so, can you please elaborate on = why is that?

Regards,
 Rifaat



On Mon, Oct = 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

On Fri, Oct = 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

I did look at RFC7239 when doing that and it could have been = made to work but felt the fit wasn't quite right and would have been = more cumbersome to use than not.  


Can you elaborate on = this?
These days, with the zero trust model in = mind, there are orchestration tools, e.g. Istio, that easily allows you = to establish an MTLS channel between the reverse proxy/load balancer/API = GW and the backend servers.
Why is = that not sufficient? 
Which part is = cumbersome?

What I meant was only that in the = course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, = which aims to define HTTP header fields that enable a TLS terminating = reverse proxy to convey information to a backend server about the = validated Token Binding Message received from a client, it seemed more = straightforward and sufficient for the use-case to use new HTTP headers = to carry the information rather than to use new fields in the Forwarded = header framework from RFC7239.    
 

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

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

= --Apple-Mail=_EC53E624-EF68-497D-AB57-76068DD10846-- From nobody Mon Oct 28 09:48:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FC81200F5 for ; Mon, 28 Oct 2019 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJbn1mipHiIC for ; Mon, 28 Oct 2019 09:48:43 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4A76B120113 for ; Mon, 28 Oct 2019 09:48:43 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9SGlZLo009346; Mon, 28 Oct 2019 16:48:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=QmVBdS5Xlbzv6Dyvc0Zw9RVq8PNSOIwL8HatfPCntQU=; b=kauVUgNI5jrdF+2X3lovwkXLgT37pAVU0DrYV+1CIWk5zhCq0aTfoaNR5vZYLYM0JAr2 2wBBpRXrvtUxdMLzygv7GQJD06mr7iCOlG+lgPAqSZExXGuLvYRieahFbqJV23WqnsVn eU1kdg57j2t4kMPfYn2CIZuk3nnrQQEfIbSy0Kk2gjm1oZMLcaqmnE27ORf8JOUZRl/2 NFhZTNH3F+BxF29N8q+OiWmtlaRfA/Hl+xDDgRjgKlA8qkLZIc/1mtgPkK7gORTu5K9z dJIjlsqDlPTVKV/WOnd/rrylNDcHPrmWjXHRqgnOJgUvACjqLx7UlBbcEYUMt3LRpvti Iw== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vvb0u331t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 16:48:38 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9SGVx0m021890; Mon, 28 Oct 2019 12:48:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vvhfwu2xp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 12:48:36 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 28 Oct 2019 12:48:34 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Mon, 28 Oct 2019 12:48:34 -0400 From: "Salz, Rich" To: Neil Madden , Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4D//8FmgA== Date: Mon, 28 Oct 2019 16:48:34 +0000 Message-ID: References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.37] Content-Type: multipart/alternative; boundary="_000_BE6B1D4A26CB42B089F988588E47E773akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=876 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910280162 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-28_06:2019-10-28,2019-10-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 clxscore=1011 spamscore=0 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 mlxlogscore=864 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910280163 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 16:48:45 -0000 --_000_BE6B1D4A26CB42B089F988588E47E773akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIGp1bXBpbmcgaW50byB0aGlzIGxhdGUuDQoNCkNsaWVudCA8LS0+IHByb3h5IDwt LT4gYmFja2VuZA0KDQpUaGUgQy9QIHNpZGUgaXMgcHJvdGVjdGVkIGJ5IFRMUy4gIFRoZXJlIG11 c3QgYmUgc2ltaWxhciBwcm90ZWN0aW9uIG9uIHRoZSBQL0Igc2lkZSwgc3VjaCBhcyBjbGllbnQt Y2VydCwgb3IgYSBzaWduYXR1cmUgb3ZlciB0aGUgY2VydGlmaWNhdGUgYmVpbmcgZm9yd2FyZGVk LCByaWdodD8NCg== --_000_BE6B1D4A26CB42B089F988588E47E773akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <973CF3ED918CC940884A10E720D769A6@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBmb3IganVtcGluZyBpbnRvIHRoaXMgbGF0ZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50ICZsdDstLSZndDsgcHJveHkgJmx0Oy0tJmd0 OyBiYWNrZW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBDL1Agc2lkZSBpcyBwcm90ZWN0 ZWQgYnkgVExTLiZuYnNwOyBUaGVyZSBtdXN0IGJlIHNpbWlsYXIgcHJvdGVjdGlvbiBvbiB0aGUg UC9CIHNpZGUsIHN1Y2ggYXMgY2xpZW50LWNlcnQsIG9yIGEgc2lnbmF0dXJlIG92ZXIgdGhlIGNl cnRpZmljYXRlIGJlaW5nIGZvcndhcmRlZCwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BE6B1D4A26CB42B089F988588E47E773akamaicom_-- From nobody Mon Oct 28 10:44:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4212008B; Mon, 28 Oct 2019 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 JraDYkx4oTQN; Mon, 28 Oct 2019 10:44:47 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.107]) (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 EC72912007A; Mon, 28 Oct 2019 10:44:46 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iP94O-00067q-5l; Mon, 28 Oct 2019 18:44:44 +0100 From: Torsten Lodderstedt Message-Id: <213B6F9D-5737-4C20-AA87-1581C0F401ED@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_3414B679-7311-4680-AE36-5F8F4BC37BE6"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 28 Oct 2019 18:44:43 +0100 In-Reply-To: Cc: oauth , txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 17:44:50 -0000 --Apple-Mail=_3414B679-7311-4680-AE36-5F8F4BC37BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dick,=20 Justin asked me to shed some light on the rationale and current status = of the work on OAuth Rich & Pushed Authorization Requests. I think I = will need 20 min. best regards, Torsten.=20 > On 28. Oct 2019, at 16:39, Dick Hardt wrote: >=20 > Hey OAuthers >=20 > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM = Monday Afternoon, I'm gathering who would be interested in making = presentations, and how much time you would like. >=20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3414B679-7311-4680-AE36-5F8F4BC37BE6 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 Fw0xOTEwMjgxNzQ0NDNaMC8GCSqGSIb3DQEJBDEiBCDaELD9mVLAYp4zRfEbcb/95QWlherMxoC5 7NIdQTmawDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAHysi4jNPiva8gJ0aQqRnzyWeVqmtNUtvJECp1Lwg+X8jmr0CV8445VjYy1s 5JbTA7nSil9c7VBtSchDpYW/sPHP1FZL+ZdoTAfisU+pI/VMRl1EE3is3oP7Jwq++l5zENdo4tiy CpkjQ0WIkv+L9mIRjyQcpJP2ZGq3Rgm7Qphrd8LXE6EsXN5bxKfsQK6P8xj+n5X8CZnxnzlBnWf1 T67NsyKygnUhuxrQFmGJo0B0bveaPEaG1C+vf/MVI5PKSwNj9hgKBlAwGZ/LJ5/92j9tO+GJ7eAu ugHnI4ENxUnbbha/DOFhjLIGRj/v/YFTfV4OPwxhboZvDW2FOsqUGIAAAAAAAAA= --Apple-Mail=_3414B679-7311-4680-AE36-5F8F4BC37BE6-- From nobody Mon Oct 28 10:46:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95D120856; Mon, 28 Oct 2019 10:46:08 -0700 (PDT) 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 hef6x7GOUYyA; Mon, 28 Oct 2019 10:46:06 -0700 (PDT) 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 566B912013A; Mon, 28 Oct 2019 10:46:05 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id a21so12283359ljh.9; Mon, 28 Oct 2019 10:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/KCOV63036fIfxB3ty/ywqNXvKHLwhwz8r6FotLvhDY=; b=sPD66nf4upyGaeXCVD3dlncFRVpPzAMJMHoeHJdHsVJfX8BxdwugcKgnkuaXFem4rn kX374CucsMJAc9CpX9i2yom0T8sn+ks0Y91RUK1WDDGUK3D4JT8vHjK022kn4TVov9YT yGfm56bkmeUevyhEK5SnGUtuJ8zEdq/J3sT0P2dEDpfFih0alr5XtzZ+Ir4KZsbTKqCQ htHlfW4hyty4sgNY7PjP8/uTLQMs9jmsY52osmgoFpKKUiu9rKuvMo4IKjr8IjCwb6MA Br9rq8BBiXnIkCdLrgdk1o/lA8mez6f5qZLMK5ZYicCW3NSovJAcQJtE+pD+Hu3I0gEM /a9w== 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=/KCOV63036fIfxB3ty/ywqNXvKHLwhwz8r6FotLvhDY=; b=gR46YofKy4Vxgxjv51BsCwziF8iBMeaYb3Pm9NY4L4QoZnN/UspJjVMj+AV12HrM0x LAobSRPpNqGoySnqL4wjxhtUlaxhyDWNfB/KjKHF1S6o0qxqVEfgrUK54sHlDHx8pQTR A/2KWPEc48nj2LH1iOszVsNy96w6V2AfzR9o/7y6GLPnIOy8/+FHBWaxrYIXDlFaxRsH 7rxm0gM8+U35rKsh30uspEV+OY9tkohYNDmfySNQWOGLCFi1aSPHJ20B82lOh8FPx1FJ RtR/hD7LMLWKX+5I3g6yJGuaaC7iaBOpNux2/eeHC29E2+N18xlDQvIjzxy60jmtzlc/ OEPg== X-Gm-Message-State: APjAAAWN+Zk8v0WRFu88ursrB8mMCOxlXDvUQHV9OxwrmcWCZ2IyscWi oOWpfOpC8P0KrRcgtZnaQ0Q6G/kJLivJXY6sNVE= X-Google-Smtp-Source: APXvYqwMo1un4EzkaCl9TPmoulEex5mVn3LIJYc8KTtnGXRS0ymFv/nzSM7Bu6veQjluTnmBgvRGBfs/TOKfqKVvSZs= X-Received: by 2002:a2e:7811:: with SMTP id t17mr12755085ljc.254.1572284763625; Mon, 28 Oct 2019 10:46:03 -0700 (PDT) MIME-Version: 1.0 References: <213B6F9D-5737-4C20-AA87-1581C0F401ED@lodderstedt.net> In-Reply-To: <213B6F9D-5737-4C20-AA87-1581C0F401ED@lodderstedt.net> From: Dick Hardt Date: Mon, 28 Oct 2019 10:45:52 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth , txauth@ietf.org, Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000d25e330595fc12de" Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 17:46:15 -0000 --000000000000d25e330595fc12de Content-Type: text/plain; charset="UTF-8" Got it. Thanks Torsten! On Mon, Oct 28, 2019 at 10:44 AM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > Justin asked me to shed some light on the rationale and current status of > the work on OAuth Rich & Pushed Authorization Requests. I think I will need > 20 min. > > best regards, > Torsten. > > > On 28. Oct 2019, at 16:39, Dick Hardt wrote: > > > > Hey OAuthers > > > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM > Monday Afternoon, I'm gathering who would be interested in making > presentations, and how much time you would like. > > > > /Dick > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000d25e330595fc12de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it. Thanks Torsten!

On Mon, Oct 28, 2019 at 10:44 AM To= rsten Lodderstedt <torsten@lo= dderstedt.net> wrote:
Hi Dick,

Justin asked me to shed some light on the rationale and current status of t= he work on OAuth Rich & Pushed Authorization Requests. I think I will n= eed 20 min.

best regards,
Torsten.

> On 28. Oct 2019, at 16:39, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hey OAuthers
>
> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM = Monday Afternoon, I'm gathering who would be interested in making prese= ntations, and how much time you would like.
>
> /Dick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--000000000000d25e330595fc12de-- From nobody Mon Oct 28 10:56:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267BF120125 for ; Mon, 28 Oct 2019 10:55:50 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvJ-Yqnxefl1 for ; Mon, 28 Oct 2019 10:55:48 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B41B12007A for ; Mon, 28 Oct 2019 10:55:48 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id d12so4355916ybn.7 for ; Mon, 28 Oct 2019 10:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lNBQTadQFiA4VQRvLXhGqCtLrgBi7CBnJExSBU174js=; b=bgcvAcmcmct9lpJZLmKWdYnCTY2AujOyXuY3yisnCyIbHFA81UymIMQ3TU1Mdd1DVA yvEXvQRc0PtYhnHdOnT1EYg/IyH7n8UU6NpyZh4Oss8TnDEPtdeIQU/ZBSt696rPHSHJ rOGoxWUbN6d27+2lHe2uA5u01NQILDao/D+Oc= 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=lNBQTadQFiA4VQRvLXhGqCtLrgBi7CBnJExSBU174js=; b=qC6KNW9cuA+poOheXgFyOI0EOzDhtOq+TBhF+TE83bTwbVOhf0/t6/29JsgMbeBz16 wd2OZ33ywC4JeT//7ae2I/2jP0G0NHiX0FvkFZLFSvP7EwU+V3RA4y2iZxeT4PPiY5dc 04UZMzYuUwdcLEqmyAunJxk4K8XcoPf3v3laJ794U/jfNY31t/4gYdsMyoMwhVDBosBK haz+kVMqq+ujtZsjvIuELDVv8SXelW2YtQQN2BRfS2Fzvk6xZdBW6T1Dg5OGf3gNPqKR AHvh2A9sitIb/x81/5nXDExi6wiBjjYy0vTsodCS6sgqVMSoYyIW7RzInleyl/tqtOrc 1Prw== X-Gm-Message-State: APjAAAUTlSn0JvFeIV5hfbG9uigpFQLXpL7l6ta3K7H10HK4d4sbOm4R GzywOQphU0dRJMJc0nsJit86h5Uo57s/qjeofwbgvw== X-Google-Smtp-Source: APXvYqyAnjWEtmYedGJP6P39RB4AzHQ1VW7zQkPsnDpHPPJf6FEhywIgoa3uFSswQiNgH/6vx/bCrTbwPSDJAcj3u9s= X-Received: by 2002:a25:414f:: with SMTP id o76mr13650962yba.401.1572285346910; Mon, 28 Oct 2019 10:55:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Rose Date: Mon, 28 Oct 2019 13:55:28 -0400 Message-ID: To: Dick Hardt Cc: oauth@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000096ab9e0595fc35f4" Archived-At: Subject: Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 17:55:51 -0000 --00000000000096ab9e0595fc35f4 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt wrote: > Hey OAuthers > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday > Afternoon, I'm gathering who would be interested in making presentations, > and how much time you would like. > Is this BoF limited to authorization, or would something like end-to-end authentication of transaction request/response via a less trusted intermediary (e.g., an API gateway or CDN) for purposes of limiting transitive trust be in scope? I'm thinking of something akin to OSCORE-style transactions, but more general (e.g., not specific to constrained computing environments, not forcing the use of CBOR). Thanks, Kyle --00000000000096ab9e0595fc35f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt &= lt;dick.hardt@gmail.com> wro= te:
Hey OAuthers

As = chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday Afternoon, I'm gathering who= would be interested in making presentations, and how much time you would l= ike.=C2=A0

Is this BoF limited = to authorization, or would something like end-to-end authentication of tran= saction request/response via a less trusted intermediary (e.g., an API gate= way or CDN) for purposes of limiting transitive trust be in scope? I'm = thinking of something akin to OSCORE-style transactions, but more general (= e.g., not specific to constrained computing environments, not forcing the u= se of CBOR).

Thanks,
Kyle
<= /div>
--00000000000096ab9e0595fc35f4-- From nobody Mon Oct 28 11:03:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71512007A; Mon, 28 Oct 2019 11:03:09 -0700 (PDT) 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 dWOhRbw49Kth; Mon, 28 Oct 2019 11:03:08 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9172120072; Mon, 28 Oct 2019 11:03:07 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id v4so5085338lfd.11; Mon, 28 Oct 2019 11:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vIG7iNOwuQwG8jMui0VjAqXMrzT9KWr3IxYaJxLv8e8=; b=i2i+Ep0XLN3Fqir9F3StWHJ43dTbyy4Gspamf8RIEatyATMIQMLZ37YjEfzOMtaskq 1A9vArjM7ihCy+HMZAKGvxaqZuYVIXet/YeAAr82bC6AIX4QrUO9ob87IdfXjBco0LPV CWYqqXp6MddYodW4t6cQrXqa45gKy+8hO8IdfxdyUh9bvBvj281QDPgM6d/dWSbDg58p f94oLB4KVh7ozhsWb18TxQHDClKK3hi4NPe1Je23J2o7bZcHmlTIubO4uaukh8Tk20GA VEd/bWpVFOlfJtVNI733s4ay+lQGYteLqySa5eXGfXc0/v2WcOiU2VVvceePSj7Pg2mc Gs0A== 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=vIG7iNOwuQwG8jMui0VjAqXMrzT9KWr3IxYaJxLv8e8=; b=HOptZMEx/5yJZyWdWzrZ3GF3j6q2N94jYV1ug+dZdOC4eVvO0oLe7HqPHvXYkVp7QO Z7byFK1drCLwQA2E3jY+rq+BAbKLwFNahX+z7zMwmh+6uQFcJs5il1rQN62Zxqepq4ba u0HwyaLs1639sAGGauHi8Nj3NaCqlSj6/8ho2bZZkZexJ6nm80lHVQHdrSAnm+NzCwC2 nCp+LggAPa+2Hfx1YJydem067OJSVpJQJXjRaF5HC1dbSmCxaL19yscSO2BnBprNMW0i ieQto6qrm07ixrRWqUquUAH1DfePkb0vSb1HfhHBD7CgZV7r3mWlYxjvgVU6VoysISAe kLMQ== X-Gm-Message-State: APjAAAWs2stBT0Gob9Sp2HzaqEZVNCwWXxuZdX/SQzsngSD1kxUBY7DB tOT1A8gbnOpeE7RT3KgeK81WbQ0yh/uKECr/fjo= X-Google-Smtp-Source: APXvYqwiH2dl1ShahlTmBK9AgN8pgBgUu9EbcrKDs3DzqwwvKUL3Q9EZOQV+NLZz8ONy9Khmjq5Sm2EJzUrGjwEnfos= X-Received: by 2002:ac2:42c7:: with SMTP id n7mr12220096lfl.138.1572285785804; Mon, 28 Oct 2019 11:03:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 28 Oct 2019 11:02:54 -0700 Message-ID: To: Kyle Rose Cc: oauth@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bf93b60595fc4fa3" Archived-At: Subject: Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 18:03:10 -0000 --000000000000bf93b60595fc4fa3 Content-Type: text/plain; charset="UTF-8" My understanding was it was transaction authorization. (it is unfortunate that authorization and authentication both start with 'auth' in english - 'authN' and 'authZ' are preferred to 'auth' IMHO) On Mon, Oct 28, 2019 at 10:55 AM Kyle Rose wrote: > On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt wrote: > >> Hey OAuthers >> >> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday >> Afternoon, I'm gathering who would be interested in making presentations, >> and how much time you would like. >> > > Is this BoF limited to authorization, or would something like end-to-end > authentication of transaction request/response via a less trusted > intermediary (e.g., an API gateway or CDN) for purposes of limiting > transitive trust be in scope? I'm thinking of something akin to > OSCORE-style transactions, but more general (e.g., not specific to > constrained computing environments, not forcing the use of CBOR). > > Thanks, > Kyle > --000000000000bf93b60595fc4fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding=C2=A0was it was transaction authorization= .=C2=A0

(it is unfortunate that authorization and authen= tication both start with 'auth' in english - 'authN' and &#= 39;authZ' are preferred to 'auth' IMHO)

On Mon, Oct 28, 20= 19 at 10:55 AM Kyle Rose <krose@krose= .org> wrote:
On Mon, Oct 28, 2019 at 11:39 AM Dick Har= dt <dick.hardt= @gmail.com> wrote:
Hey OAuthers

As chair of the Tx BOF coming up in Singapore on Nov 18= @ 5:30-7:30PM Monday Afternoon= , I'm gathering who would be interested in making presentations, and ho= w much time you would like.=C2=A0

Is this BoF limited to authorization, or would something like end-to-end= authentication of transaction request/response via a less trusted intermed= iary (e.g., an API gateway or CDN) for purposes of limiting transitive trus= t be in scope? I'm thinking of something akin to OSCORE-style transacti= ons, but more general (e.g., not specific to constrained computing environm= ents, not forcing the use of CBOR).

Thanks,
Kyle
--000000000000bf93b60595fc4fa3-- From nobody Mon Oct 28 11:51:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CC5120125 for ; Mon, 28 Oct 2019 11:51:15 -0700 (PDT) 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 FVA46j6ho5kO for ; Mon, 28 Oct 2019 11:51:14 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061A612026E for ; Mon, 28 Oct 2019 11:51:14 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id t5so9100479ilh.10 for ; Mon, 28 Oct 2019 11:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oWpTqZ+hMa6iz6v8lThuKD/pK6aNq3VGD3i5TEK41jg=; b=bNW1OUPDxDMT1MFITsHoA+h5h5cafGzQqfWFb3ZuTAgi35PfxxTTmKwcKsP7j6V8fJ GgkX5xAspyG3SbkyrWsCAKoXakHe/b7JkWnJAyMwf8SFOI0QsOFZphLGAuSLDyDAGqqd Zq5SXjrbCAaitn2jWnxVOK3IalCDm7tLXHLqe5zPpfVpS5qF/Uqwsv2mQ5pXHh2/XUqk AbrmqAail9uiNbafS7ExLZF39QwHfehb0DvDn3KfygIuh1wzSfzhuRZsjsrRVw7WnU7C Y83DeDCqSgnpv7uhcbzDnTyZBDKkV0mHp8kSR+K6Jp2zy4alX8NSM4KXqWz3N9JvP7KM rRjA== 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=oWpTqZ+hMa6iz6v8lThuKD/pK6aNq3VGD3i5TEK41jg=; b=s2WG+ultdumHnJEj5XGQ8gTfSH5mKGX/CwBbhSCOMWGo49oodxQLgbhuTLh5CbfCNd BHFfsxIhqz925y7z7FFJ2ZImFI3ZTFocAPgHKrpQiGPw4WM5arBIhl+3VmEDYdRki7fn 6uhA5Yz5hLup4JH4u/MBmaAVTX7sxKqeFQ11SdTrXxPlFj0nyIwmmaJccle/Nk5vP6+g IIRuUZV7TmV7fLWd7uF7urPpQnCkQ+1Kk1ddyYMLFrOWbaU229qlDAL9DCIIIvUVgpk4 UQeZPi1WfKWCd7izP4073z7EWaJeyeffko0dERKWihSdesZxAf8kQrCaO04tKxL/EDG4 wKSg== X-Gm-Message-State: APjAAAVXX1gWbJAJTCvMAf6U2PMbstMsgos1LcTpcmQV8KIYIVKSxMAd iRPFhWZEEbSwMUQXDvNE84rmOIVCUuL3MwqxZ94= X-Google-Smtp-Source: APXvYqyOFzAf7FKx4zXpPF4jo1kVo63mWBvveunPIQ5XNM1tqp1zNdGDsZbydE4U9hjmE3FP8t7XY6TW0vN1AV+dMr8= X-Received: by 2002:a92:9cce:: with SMTP id x75mr22378461ill.31.1572288673322; Mon, 28 Oct 2019 11:51:13 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 28 Oct 2019 14:51:01 -0400 Message-ID: To: "Salz, Rich" Cc: Neil Madden , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000db9a910595fcfb64" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 18:51:16 -0000 --000000000000db9a910595fcfb64 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 28, 2019 at 12:48 PM Salz, Rich wrote: > Sorry for jumping into this late. > > > > Client <--> proxy <--> backend > > > > The C/P side is protected by TLS. There must be similar protection on the > P/B side, such as client-cert, or a signature over the certificate being > forwarded, right? > To avoid the misconfiguration issue Neil raised, you probably need both: a client-cert *and* a signature over the certificate being forwarded, This could still be achieve by extending RFC7239 with new parameter(s). Regards, Rifaat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000db9a910595fcfb64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 28, 2019 at 12:48 PM Salz= , Rich <rsalz@akamai.com> wro= te:

Sorry for jumping into this late.

=C2=A0

Client <--> proxy <--> backend=

=C2=A0

The C/P side is protected by TLS.=C2=A0 There must b= e similar protection on the P/B side, such as client-cert, or a signature o= ver the certificate being forwarded, right?


To avoid=C2=A0the misconfiguration issue Neil raised, you = probably need both: a client-cert=C2=A0and a signature over the cert= ificate being forwarded,
This could still be achieve by extendin= g RFC7239 with new parameter(s).

Regards,
=C2=A0Rifaat


=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000db9a910595fcfb64-- From nobody Mon Oct 28 11:55:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCDE1200D6 for ; Mon, 28 Oct 2019 11:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS5GOVfWHXVR for ; Mon, 28 Oct 2019 11:55:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A8BFC1200C7 for ; Mon, 28 Oct 2019 11:55:28 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9SIrNPq025118; Mon, 28 Oct 2019 18:55:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=p+p/SW/Ayu/sPx3FCpVRvKuPoFBziyIraY4aAOukqZU=; b=EaagjjL8kdAJOJQhCXBXZf/lxq2DJ0wNONAbvJaVbBw5ytxiQIEXaVj2I8cokBqBZ6gZ aQ3DESfCKGXSdpNAA5gQQyaPrMmS/yEwPEQCFKz+Fj29lsDrTTvF4KSoWDgbAAEqnGVr oc4p1FhEeFbITleC++e112Duo99LT6cS2GrbjCjVYsL2xuflSvnlw/YkC4NHaZhbPD/N maR6IHdVyGkR6Q1AFN8YX7tKATrFfxf3U2ueUSqu1WiH3v059MlsHQ8g2EIpbKtYmK9W maqcxApCChYvZH2mY1ZleEVC+BHWW4mHg6mYDyqal/2YBjCoHPrQyvFFdqJaAeCzyt1Z TA== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vvdsvaxpn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 18:55:22 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9SIlCR0030657; Mon, 28 Oct 2019 14:55:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 2vvhfw32ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 14:55:21 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 28 Oct 2019 14:55:20 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Mon, 28 Oct 2019 14:55:20 -0400 From: "Salz, Rich" To: Rifaat Shekh-Yusef CC: Neil Madden , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4D//8FmgIAAZUaA//++JYA= Date: Mon, 28 Oct 2019 18:55:19 +0000 Message-ID: <045A61A9-A5E3-4700-8669-A74931D4E7FB@akamai.com> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.37] Content-Type: multipart/alternative; boundary="_000_045A61A9A5E347008669A74931D4E7FBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-28_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=836 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910280178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-28_07:2019-10-28,2019-10-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=825 suspectscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 spamscore=0 clxscore=1015 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910280179 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 18:55:30 -0000 --_000_045A61A9A5E347008669A74931D4E7FBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVG8gYXZvaWQgdGhlIG1pc2NvbmZpZ3VyYXRpb24gaXNzdWUgTmVpbCByYWlzZWQsIHlv dSBwcm9iYWJseSBuZWVkIGJvdGg6IGEgY2xpZW50LWNlcnQgYW5kIGEgc2lnbmF0dXJlIG92ZXIg dGhlIGNlcnRpZmljYXRlIGJlaW5nIGZvcndhcmRlZCwNCg0KSSBhbSBub3Qgc28gc3VyZS4gIE9u ZSBjYW4gYXJndWUgdGhhdCB0cmFuc3BvcnQtbGV2ZWwgaWRlbnRpdHkgc2hvdWxkIGJlIHNlY3Vy ZWQgYnkgdHJhbnNwb3J0LWxldmVsLiAgQnV0IGluc3RhbGxpbmcgYSBjbGllbnQgY2VydGlmaWNh dGUgb24gYSByZXZlcnNlIHByb3h5IGNhbiBiZSBkaWZmaWN1bHQuICAoTm90IGlmIHRoZSByZXZl cnNlIHByb3h5IGlzIGEgQ0ROLCBvZiBjb3Vyc2UgOikgQW5kIEkgZG9u4oCZdCBzZWUgaG93IGhh dmluZyBib3RoIHByZXZlbnRzIG1pc2NvbmZpZ3VyYXRpb24sIGJ1dCB0aGF0IG1pZ2h0IGJlIG15 IGZhdWx0Lg0KDQoNCiAgKiAgIFRoaXMgY291bGQgc3RpbGwgYmUgYWNoaWV2ZSBieSBleHRlbmRp bmcgUkZDNzIzOSB3aXRoIG5ldyBwYXJhbWV0ZXIocykuDQoNCkkgaGF2ZSBubyBvcGluaW9uIG9u IHRoaXMgcGFydCBvZiBpdC4NCg0K --_000_045A61A9A5E347008669A74931D4E7FBakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E286DAE386BF44695B018E3EEEF7F84@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MDUxMjE2MzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1NjE1NDMwMjQgODYwMDE5NjgwIDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+VG8gYXZvaWQmbmJzcDt0aGUgbWlzY29uZmlndXJhdGlvbiBpc3N1ZSBO ZWlsIHJhaXNlZCwgeW91IHByb2JhYmx5IG5lZWQgYm90aDogYSBjbGllbnQtY2VydCZuYnNwOzxi PmFuZDwvYj4gYSBzaWduYXR1cmUgb3ZlciB0aGUgY2VydGlmaWNhdGUgYmVpbmcgZm9yd2FyZGVk LA0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHNvIHN1cmUuJm5ic3A7 IE9uZSBjYW4gYXJndWUgdGhhdCB0cmFuc3BvcnQtbGV2ZWwgaWRlbnRpdHkgc2hvdWxkIGJlIHNl Y3VyZWQgYnkgdHJhbnNwb3J0LWxldmVsLiZuYnNwOyBCdXQgaW5zdGFsbGluZyBhIGNsaWVudCBj ZXJ0aWZpY2F0ZSBvbiBhIHJldmVyc2UgcHJveHkgY2FuIGJlIGRpZmZpY3VsdC4mbmJzcDsgKE5v dCBpZiB0aGUgcmV2ZXJzZSBwcm94eSBpcyBhIENETiwgb2YgY291cnNlIDopIEFuZCBJIGRvbuKA mXQNCiBzZWUgaG93IGhhdmluZyBib3RoIHByZXZlbnRzIG1pc2NvbmZpZ3VyYXRpb24sIGJ1dCB0 aGF0IG1pZ2h0IGJlIG15IGZhdWx0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlRoaXMgY291bGQgc3RpbGwgYmUg YWNoaWV2ZSBieSBleHRlbmRpbmcgUkZDNzIzOSB3aXRoIG5ldyBwYXJhbWV0ZXIocykuPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBubyBvcGluaW9uIG9uIHRoaXMgcGFydCBv ZiBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_045A61A9A5E347008669A74931D4E7FBakamaicom_-- From nobody Mon Oct 28 12:35:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9185312006D for ; Mon, 28 Oct 2019 12:35:20 -0700 (PDT) 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=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 9NlQlHBq5a2T for ; Mon, 28 Oct 2019 12:35:18 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ACA120120 for ; Mon, 28 Oct 2019 12:35:18 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id c4so12606595lja.11 for ; Mon, 28 Oct 2019 12:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ToDrQu7Xr820Vw5Fnkrd2s/HOjXfXsSNhig591mhJf8=; b=FNTeA+SwZzNX05hvPn3/bX9GZJw0EG1QXjFoNZuyHwDrLwaQ5RufzFSwT6WoE0XLoV qyQH3Fwzq4Aaj69sKc1BReC7OWLWwlJLOLfhnmqxh7yR+no6/I03IxUvDWTX8N6HI8KL GNS2S6/LMFDbozVOhoFJgsjbPso5F3THD5zU8= 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=ToDrQu7Xr820Vw5Fnkrd2s/HOjXfXsSNhig591mhJf8=; b=AYG4qMWJwBAEcRUBl6Slb8cXD/wWFKLdxl6preGchu69L0KYyD4qdkQEzdE8Ck7pF4 9ioeNIKXXcACZsymVi7RBZHLnjaE5EETseVAVr7Vt9p2hHjeD5GHZdx9+fgC3wKsoD1e y+jieAG+VsSVGsdGN3FtszYG4Ah71d+G8yzHtHZHS/Py/ybpkJ0ZvZITQ9loC9YqQ1aG Vy2SpNbtbnEykc+2OtMRMpnf7KGo+c9cgu2LOoCQSPw1a/X6WW43DBk6CrJ/teHABOiU 6EVRi1FHZACAqPwt9OJ0b/n6Yhzuiz5YdNCK9uQ3qxsr3jakXqV/hchiEnvrESGH4kzS PLIw== X-Gm-Message-State: APjAAAXRYshW12b8T0GX3ZMBRwVPcK0qNQOTd0eg8K91Joki3PpGAfIt DNHq2GBBNOXAz8Qb2Sm+8qjM1skgvQqMOFtem55eo3i5YOft+wmgAh7Ixe00JcAx19ocy5CYNRT dWm/rBMBiV+4xbg== X-Google-Smtp-Source: APXvYqxE8RB8BsiG7XmP2WzXGA32IROiSXvrpTIZJZRWzYotbnnMr4q1dYkGVhwB2TzLGyoKTWfrxMKsOkhWrXSLO60= X-Received: by 2002:a2e:9bd2:: with SMTP id w18mr13056837ljj.140.1572291316342; Mon, 28 Oct 2019 12:35:16 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Mon, 28 Oct 2019 13:34:49 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Benjamin Kaduk , Justin Richer , oauth Content-Type: multipart/alternative; boundary="00000000000064fa9d0595fd9979" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 19:35:20 -0000 --00000000000064fa9d0595fd9979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When working on the Token Binding TTRP draft I guess I saw the advantage as being the simplicity or setting, sanitizing, and reading an independent header that's only conveying the token binding info about the TLS connection between the "outside" client/browser and the proxy, (which is the application/service from that client's perspective). That simplicity comes at the cost of not being able to represent that information about multiple hops as would be the case extending RFC7239. The simplicity won the day in that particular tradeoff. I suspect that would be the case with client cert info too. But that's admittedly just conjecture at this point. Although it is, as far as I know, inline with the capabilities of the popular reverse proxies. On Mon, Oct 28, 2019 at 10:00 AM Rifaat Shekh-Yusef wrote: > Ok, then we are on the same page. > The reason I am asking is that I have a use case where I need such a > mechanism. > > What is the advantage you see for defining a new HTTP header over > extending RFC7239? > > Regards, > Rifaat > > > > On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I don't think there's anything beyond defining something to carry the >> client certificate information (including the format and encoding). And = it >> could well be a new RFC7239 parameter. Or it might just be a new HTTP >> header on its own. >> >> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef >> wrote: >> >>> Thanks Brian, >>> >>> I guess my question is: given RFC7239 and the fact that it is >>> straightforward to secure the channel between the terminating reverse p= roxy >>> and the backend service in a cluster, is there anything, from a standar= d >>> perspective, that we need to do beyond defining a new parameter to carr= y >>> the client certificate information? >>> You seem suggest that the answer is yes. If so, can you please elaborat= e >>> on why is that? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> >>>> >>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>>> >>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> >>>>>> I did look at RFC7239 when doing that and it could have been made to >>>>>> work but felt the fit wasn't quite right and would have been more >>>>>> cumbersome to use than not. >>>>>> >>>>>> >>>>> Can you elaborate on this? >>>>> These days, with the zero trust model in mind, there are orchestratio= n >>>>> tools, e.g. Istio, that easily allows you to establish an MTLS channe= l >>>>> between the reverse proxy/load balancer/API GW and the backend server= s. >>>>> Why is that not sufficient? >>>>> Which part is cumbersome? >>>>> >>>> >>>> What I meant was only that in the course of writing >>>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to >>>> define HTTP header fields that enable a TLS terminating reverse proxy = to >>>> convey information to a backend server about the validated Token Bindi= ng >>>> Message received from a client, it seemed more straightforward and >>>> sufficient for the use-case to use new HTTP headers to carry the >>>> information rather than to use new fields in the Forwarded header fram= ework >>>> from RFC7239. >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the 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._ --00000000000064fa9d0595fd9979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When working on the Token Binding TTRP draft I guess I saw= the advantage as being the simplicity or setting, sanitizing, and reading = an independent header that's only conveying the token binding info abou= t the TLS connection between the "outside" client/browser and the= proxy, (which is the application/service from that client's perspectiv= e). That simplicity comes at the cost of not being able to represent that i= nformation about multiple hops as would be the case extending RFC7239. The = simplicity won the day in that particular tradeoff. I suspect that would be= the case with client cert info too. But that's admittedly just conject= ure at this point. Although it is, as far as I know, inline with the capabi= lities of the popular reverse proxies.

On Mon, Oct 28, 2019 at 10:00 AM= Rifaat Shekh-Yusef <rifaat.iet= f@gmail.com> wrote:
Ok, then we are on the same page.=C2=A0
The reason I am asking is that I have a use case where I need such = a mechanism.

What is the advantage you see for def= ining a new HTTP header over extending RFC7239?

Re= gards,
=C2=A0Rifaat



On Mon, Oct 28, = 2019 at 11:32 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
I don&#= 39;t think there's anything beyond defining something to carry the clie= nt certificate information (including the format and encoding). And it coul= d well be a new RFC7239 parameter. Or it might just be a new HTTP header on= its own.=C2=A0

On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.co= m> wrote:
Thanks=C2=A0Brian,

I guess m= y question is: given RFC7239 and the fact that it is straightforward=C2=A0t= o secure the channel=C2=A0between the terminating reverse proxy and the bac= kend service in a cluster, is there anything, from a standard perspective, = that we need to do beyond defining a new parameter to carry the client cert= ificate information?
You seem suggest that the answer is yes. If so, ca= n you please elaborate on why is that?

Regards,
=C2=A0Rifaat



On Mon, Oct 28,= 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.co= m> wrote:

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

I did look at RFC7= 239 when doing that and it could have been made to work but felt the fit wa= sn't quite right and would have been more cumbersome to use than not.= =C2=A0


Can you elaborate on this?
These days, with the zero trust mode= l in mind, there are orchestration tools, e.g. Istio, that easily allows yo= u to establish an MTLS channel between the reverse proxy/load balancer/API = GW and the backend servers.
Why is that not sufficient?=C2=A0=
Which part is cumbersome?
What I meant was only that in the course of writing h= ttps://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to de= fine HTTP header fields that enable a TLS terminating reverse proxy to conv= ey information to a backend server about the validated Token Binding Messag= e received from a client, it seemed more straightforward and sufficient for= the use-case to use new HTTP headers to carry the information rather than = to use new fields in the Forwarded header framework from RFC7239.=C2=A0 =C2= =A0
=C2=A0

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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in 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. --00000000000064fa9d0595fd9979-- From nobody Mon Oct 28 13:57:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E7F120072; Mon, 28 Oct 2019 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XKgRLMH8Ycg; Mon, 28 Oct 2019 13:57:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F64120024; Mon, 28 Oct 2019 13:57:22 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9SKvIoM008870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 16:57:19 -0400 From: Justin Richer Message-Id: <2348A854-97C5-45E3-BA4E-3E641B0D6DDE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_EB174CE9-782C-4C0A-BC1B-D4AE5F9E7A22" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 28 Oct 2019 16:57:18 -0400 In-Reply-To: Cc: Dick Hardt , oauth@ietf.org, txauth@ietf.org To: Kyle Rose References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 20:57:24 -0000 --Apple-Mail=_EB174CE9-782C-4C0A-BC1B-D4AE5F9E7A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The intended scope is to provide a transactional model for doing = authorization delegation, not for authenticating a transaction itself. I = can understand the confusion! Naming things is hard.=20 =E2=80=94 Justin > On Oct 28, 2019, at 1:55 PM, Kyle Rose wrote: >=20 > On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt > wrote: > Hey OAuthers >=20 > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM = Monday Afternoon, I'm gathering who would be interested in making = presentations, and how much time you would like.=20 >=20 > Is this BoF limited to authorization, or would something like = end-to-end authentication of transaction request/response via a less = trusted intermediary (e.g., an API gateway or CDN) for purposes of = limiting transitive trust be in scope? I'm thinking of something akin to = OSCORE-style transactions, but more general (e.g., not specific to = constrained computing environments, not forcing the use of CBOR). >=20 > Thanks, > Kyle > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_EB174CE9-782C-4C0A-BC1B-D4AE5F9E7A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = intended scope is to provide a transactional model for doing = authorization delegation, not for authenticating a transaction itself. I = can understand the confusion! Naming things is hard. 

 =E2=80=94 = Justin

On Oct 28, 2019, at 1:55 PM, Kyle Rose <krose@krose.org> = wrote:

On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey OAuthers

As chair of the Tx BOF = coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday Afternoon, = I'm gathering who would be interested in making presentations, and how = much time you would like. 

Is this BoF limited to = authorization, or would something like end-to-end authentication of = transaction request/response via a less trusted intermediary (e.g., an = API gateway or CDN) for purposes of limiting transitive trust be in = scope? I'm thinking of something akin to OSCORE-style transactions, but = more general (e.g., not specific to constrained computing environments, = not forcing the use of CBOR).

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

= --Apple-Mail=_EB174CE9-782C-4C0A-BC1B-D4AE5F9E7A22-- From nobody Mon Oct 28 14:02:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637EF120096 for ; Mon, 28 Oct 2019 14:02:29 -0700 (PDT) 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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WC8F4RAhtRG for ; Mon, 28 Oct 2019 14:02:26 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B07D120086 for ; Mon, 28 Oct 2019 14:02:26 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id d12so4585678ybn.7 for ; Mon, 28 Oct 2019 14:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MfB80EVlyKBwZhgn9SnOsWsEsBH4+rOB0uomqTcNt8o=; b=i09gY5MI0lrGg1J022wE4MDffvIyj3yxcOFizQuTnrBXvHU4PK43B9bHSgdDzbXkx/ 0O7wDIe2go9FvSTZrK1ZFA+IUjFEte/WH+IqwhOtWbK2xQWAfQ5HanPHBIxES0KmTTNo ImPH7QPUt+UYvMfabCvZPhyBSm6r9ATKxzEPM= 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=MfB80EVlyKBwZhgn9SnOsWsEsBH4+rOB0uomqTcNt8o=; b=tAcUZKFT8ZLpy3otjYBTgE0y/+P52WkaJhg7lcyJ8TRuAgZY8lHpyjZam6Q+nzd3KL FaA8mlXTk5PYyUvJsJIcBFo7GZML9c6x2BdkmS/qsyiuFijE4WPk2xcF1kDHg89v5vPX pvBdx2RNdJVrcy/lHXjUgnjfFMvkvEWAwMK1HWHGcuJFiLOQL0+dWFnd80k3TGfJzOIx IluhssEsGF3mSC6NEHq+tN6pxQsCwCvrba9Egd/we4efUqRLhM8+3LFtr1Gixvwhz3rY y+1G+O1B28CXxkH/5D0PnHYMDe6xWwmC1AD+pxUpd15W4sjWTOKb+R5yuT5y0l4fwIfh QhKQ== X-Gm-Message-State: APjAAAXg/Glc6a0aT3j4LJQ2hxizRIdK6Hdo74KAwlokA93xtUOV8EIF hGibhEmmCXVla1tYxCVcol54eLisNXEGUPrPxnc6RA== X-Google-Smtp-Source: APXvYqzz6xwnGMTe2PLcAvlCswLbT26sr3yavS6zK6r+RZkM0XBvz66GZ1j3rvDtoOyA9AOlsAC4LUlATwyd4uAldAc= X-Received: by 2002:a25:bdd4:: with SMTP id g20mr15146086ybk.127.1572296545196; Mon, 28 Oct 2019 14:02:25 -0700 (PDT) MIME-Version: 1.0 References: <2348A854-97C5-45E3-BA4E-3E641B0D6DDE@mit.edu> In-Reply-To: <2348A854-97C5-45E3-BA4E-3E641B0D6DDE@mit.edu> From: Kyle Rose Date: Mon, 28 Oct 2019 17:02:10 -0400 Message-ID: To: Justin Richer Cc: Dick Hardt , oauth@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000efc590595fed198" Archived-At: Subject: Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 21:02:29 -0000 --0000000000000efc590595fed198 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it. Thanks. I'll shop around for another venue. On Mon, Oct 28, 2019, 4:57 PM Justin Richer wrote: > The intended scope is to provide a transactional model for doing > authorization delegation, not for authenticating a transaction itself. I > can understand the confusion! Naming things is hard. > > =E2=80=94 Justin > > On Oct 28, 2019, at 1:55 PM, Kyle Rose wrote: > > On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt wrote: > >> Hey OAuthers >> >> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Mo= nday >> Afternoon, I'm gathering who would be interested in making presentations= , >> and how much time you would like. >> > > Is this BoF limited to authorization, or would something like end-to-end > authentication of transaction request/response via a less trusted > intermediary (e.g., an API gateway or CDN) for purposes of limiting > transitive trust be in scope? I'm thinking of something akin to > OSCORE-style transactions, but more general (e.g., not specific to > constrained computing environments, not forcing the use of CBOR). > > Thanks, > Kyle > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000000efc590595fed198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it. Thanks. I'll shop around for another venue.
On= Mon, Oct 28, 2019, 4:57 PM Justin Richer <jricher@mit.edu> wrote:
The inte= nded scope is to provide a transactional model for doing authorization dele= gation, not for authenticating a transaction itself. I can understand the c= onfusion! Naming things is hard.=C2=A0

=C2=A0=E2=80=94 J= ustin

On Oct 28, 2019, at 1:55 P= M, Kyle Rose <krose@krose.org> wrote:

On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt <dick.hard= t@gmail.com> wrote:
Hey OAuthers

As chair of the Tx BOF coming up in Singapore on Nov 18= @ 5:30-7:30PM Monday Afternoon= , I'm gathering who would be interested in making presentations, and ho= w much time you would like.=C2=A0

Is this BoF limited to authorization, or would something like end-to-end= authentication of transaction request/response via a less trusted intermed= iary (e.g., an API gateway or CDN) for purposes of limiting transitive trus= t be in scope? I'm thinking of something akin to OSCORE-style transacti= ons, but more general (e.g., not specific to constrained computing environm= ents, not forcing the use of CBOR).

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

=
--0000000000000efc590595fed198-- From nobody Mon Oct 28 14:09:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55DD120086; Mon, 28 Oct 2019 14:09:48 -0700 (PDT) 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 cqmc0XR82rJf; Mon, 28 Oct 2019 14:09:46 -0700 (PDT) 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 D8F4D120072; Mon, 28 Oct 2019 14:09:45 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id c4so12874487lja.11; Mon, 28 Oct 2019 14:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zZoGw0xPl0wSg8LhkZlPgFLkfSkMPC0OOJL9qG/+msA=; b=XPwcDPvTQlgz/lIJ7uBcWIHAjQDKj61fO0nNXj9jO+rrhKpu4G3uc5RDMF0CjrJs7+ TXHCjf7OFrzljLadCrxTDkcX6VbbnpoGs3WNq1y7j4pF7rTc4KTL2+oSTNtCsZmSsySs KqkiM/Aaw3rRxt/tpmvkqHqKOUF+j86f2C/TZfgDLl7ySVJbUfFACdTNQyONNOWf/yaZ x7azFY0AErHZf63j9fut9+W7aRC+GZ99ZItojX43ektX/QiqaZg7MGEuT4tGmmqpP7tn Nou6zQdUHKiDf4znkVEr+DIGJ/vVWPP+rZ/v+322J7GG0njhjbQgfKuGwR5PD2AK/GmS 3jPw== 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=zZoGw0xPl0wSg8LhkZlPgFLkfSkMPC0OOJL9qG/+msA=; b=ElBm4HSHqLzH4qn55fCfPPWh3fjXJcdpGf95tpRaEv32ArGngfFJ0V3jaCbyVbgpka o6SfrG5ORwUiH+iSH8bqwb0WmkuOiJa/hXhMTBRgd+UVHh+blTB/E5fwRo3OQkg56A9t /E9hEZM132k8/heT2sJqNGO501QCD7gPH6m9WS4KcO0/rhcfD/gkSvRg2DLrJUAUnBOW C2leRE0iqVyoaScGFP3dN4nxrXvOw7VGmWO8OBpJRQSoEFs85Db0RNjZ+xdkj6rfrhuw B0d05rnHmCVvRC99GWuHTYx+HCY/KHGVBcYv+6fG4pJKCDdmCfmD6jLVV2p41ORU/uLt 73jg== X-Gm-Message-State: APjAAAVKsofN0OYG7VChYPKrCzZpHHMyzbqs6t1o3ZEVmZnpAzdx04RA c+bs6GD9vL1E0fqY9yUMqi+ffHMOpLhvqOp6ENQn4L1rw3w= X-Google-Smtp-Source: APXvYqxEyrOm87HvmF2Slk4T9GqkJbZFsV6Q06jbdZABYj0uWOq6rcNmGKXDWkK0LEqDQZmJG7wDqsLpyl35TDMpgM0= X-Received: by 2002:a2e:9112:: with SMTP id m18mr617151ljg.75.1572296983240; Mon, 28 Oct 2019 14:09:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 28 Oct 2019 14:09:30 -0700 Message-ID: To: oauth@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ae6840595feeb95" Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 21:09:49 -0000 --0000000000002ae6840595feeb95 Content-Type: text/plain; charset="UTF-8" Unclear what I was smoking when I said when the BoF was. It is at 13:30-15:30 per https://datatracker.ietf.org/meeting/106/agenda Sorry for any confusion. On Mon, Oct 28, 2019 at 8:39 AM Dick Hardt wrote: > Hey OAuthers > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday > Afternoon, I'm gathering who would be interested in making presentations, > and how much time you would like. > > /Dick > --0000000000002ae6840595feeb95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unclear what I was smoking when I said wh= en the BoF was. It is at 13:30-15:30 per=C2=A0https://datatracker.ietf.org/meeting/106/age= nda

Sorry for any confusion.
=

= On Mon, Oct 28, 2019 at 8:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey OAut= hers

As chair of the Tx BO= F coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday Afternoon, I'm gathering who would be interest= ed in making presentations, and how much time you would like.

/Dick
--0000000000002ae6840595feeb95-- From nobody Mon Oct 28 14:32:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF83120098; Mon, 28 Oct 2019 14:31:59 -0700 (PDT) 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 pheGOn0VKUal; Mon, 28 Oct 2019 14:31:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A8312008A; Mon, 28 Oct 2019 14:31:57 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9SLVtFp019953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 17:31:56 -0400 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, 28 Oct 2019 17:31:55 -0400 Cc: oauth@ietf.org, txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dick Hardt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 21:31:59 -0000 I would like to discuss XYZ, to give a quick background and update to = the project. I project that to take about 20 min if we dive right into = the gritty details. I can also do a level-set for the BoF, like 10min. =E2=80=94 Justin > On Oct 28, 2019, at 11:39 AM, Dick Hardt wrote: >=20 > Hey OAuthers >=20 > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM = Monday Afternoon, I'm gathering who would be interested in making = presentations, and how much time you would like. >=20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 28 14:35:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688D0120144; Mon, 28 Oct 2019 14:35:31 -0700 (PDT) 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 7ACxwZFHyraC; Mon, 28 Oct 2019 14:35:29 -0700 (PDT) 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 676631200B2; Mon, 28 Oct 2019 14:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1572298529; x=1603834529; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=J5toSSColI6KMAZU0aajSkalyabDZ9d9aXkmSawGxRE=; b=lK12CBcXNwcrWc4+vCdncS36IhBbM8NM5CyzOGPs96BholrzRjmVjzZp pl8Z40ynblKFuvJcaN1k0feG87qU9YOUS9U/BR/iQ8P+8XkDHbmXvhEQx M0eRac/gg9giOOWaE1y878nVnkCncA4ReSBlhLi07vPtYa3qVrEJQD9Vz U=; IronPort-SDR: eTq82gac59RlMe7j0jr3pOMXTFqSpodN6OC/W3q0qZFoezhBcvsRiTzk1qj9QJ6SLzGVLnuUs7 1eaWpSLRBFjg== X-IronPort-AV: E=Sophos;i="5.68,241,1569283200"; d="scan'208,217";a="787541" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2b-859fe132.us-west-2.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 28 Oct 2019 21:35:26 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-859fe132.us-west-2.amazon.com (Postfix) with ESMTPS id 18B56221FC9; Mon, 28 Oct 2019 21:35:26 +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, 28 Oct 2019 21:35:25 +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, 28 Oct 2019 21:35:25 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 28 Oct 2019 21:35:25 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , "oauth@ietf.org" , "txauth@ietf.org" Thread-Topic: [OAUTH-WG] Tx Auth BOF agenda items Thread-Index: AQHVjaYpdVSCywrmg0i8RAscAQ0FF6dwHpKA Date: Mon, 28 Oct 2019 21:35:25 +0000 Message-ID: <67339BE2-E7EF-4AC3-8ED8-9443246CE293@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.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.115] Content-Type: multipart/alternative; boundary="_000_67339BE2E7EF4AC38ED89443246CE293amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 21:35:31 -0000 --_000_67339BE2E7EF4AC38ED89443246CE293amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluIGhhZCByZXF1ZXN0ZWQgdGhhdCBJIHByZXNlbnQgb24gc29tZSBub24tYXV0aG9yaXph dGlvbiB1c2UgY2FzZXMgZm9yIHNvbWV0aGluZyBsaWtlIFhZWi4gVGhpcyBzaG91bGRu4oCZdCB0 YWtlIG1vcmUgdGhhbiAxNSBtaW51dGVzLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpEYXRlOiBN b25kYXksIE9jdG9iZXIgMjgsIDIwMTkgYXQgODo0MSBBTQ0KVG86ICJvYXV0aEBpZXRmLm9yZyIg PG9hdXRoQGlldGYub3JnPiwgInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFtPQVVUSC1XR10gVHggQXV0aCBCT0YgYWdlbmRhIGl0ZW1zDQoNCkhleSBPQXV0aGVy cw0KDQpBcyBjaGFpciBvZiB0aGUgVHggQk9GIGNvbWluZyB1cCBpbiBTaW5nYXBvcmUgb24gTm92 IDE4IEAgNTozMC03OjMwUE0NCk1vbmRheSBBZnRlcm5vb24sIEknbSBnYXRoZXJpbmcgd2hvIHdv dWxkIGJlIGludGVyZXN0ZWQgaW4gbWFraW5nIHByZXNlbnRhdGlvbnMsIGFuZCBob3cgbXVjaCB0 aW1lIHlvdSB3b3VsZCBsaWtlLg0KDQovRGljaw0K --_000_67339BE2E7EF4AC38ED89443246CE293amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6B965C1FC44FD34798CD39422B902E02@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 Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Rp biBoYWQgcmVxdWVzdGVkIHRoYXQgSSBwcmVzZW50IG9uIHNvbWUgbm9uLWF1dGhvcml6YXRpb24g dXNlIGNhc2VzIGZvciBzb21ldGhpbmcgbGlrZSBYWVouIFRoaXMgc2hvdWxkbuKAmXQgdGFrZSBt b3JlIHRoYW4gMTUgbWludXRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5u YWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRo LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhh cmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBPY3RvYmVyIDI4LCAy MDE5IGF0IDg6NDEgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O29hdXRoQGlldGYub3JnJnF1b3Q7 ICZsdDtvYXV0aEBpZXRmLm9yZyZndDssICZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7 dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bT0FVVEgtV0ddIFR4IEF1 dGggQk9GIGFnZW5kYSBpdGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhleSBPQXV0aGVyczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBjaGFpciBvZiB0aGUg VHggQk9GIGNvbWluZyB1cCBpbiBTaW5nYXBvcmUgb24gTm92IDE4IEAgNTozMC03OjMwUE08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vbmRheSBBZnRlcm5vb24sIEknbSBn YXRoZXJpbmcgd2hvIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gbWFraW5nIHByZXNlbnRhdGlvbnMs IGFuZCBob3cgbXVjaCB0aW1lIHlvdSB3b3VsZCBsaWtlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_67339BE2E7EF4AC38ED89443246CE293amazoncom_-- From nobody Mon Oct 28 14:36:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED873120131; Mon, 28 Oct 2019 14:36:40 -0700 (PDT) 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 naxBiy5XdkX4; Mon, 28 Oct 2019 14:36:39 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2382E12012D; Mon, 28 Oct 2019 14:36:39 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q78so12987396lje.5; Mon, 28 Oct 2019 14:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VDKIngzbn3m6A/0bOf2q9W21tPmblacMTNI1cDxa2ds=; b=sDclScAgU8uoKQ/bFwW2wEjJjCxdy1Dm4Hw3cGt/4upul6IhRxTiUt904wvNu31Q0O 4LGbLqbtgHALjtsN5Bov1KALZ8gpB841KRQxDRM7tqGpktU++aVMrm3LvIMux6o/ZhW3 bwozOaplAaxgLWXXibd57MdhuXa8GGtj/J5sIFYZl7puu9ZhpfEiVI1P5RhCLU9JVGQw y3HEbJT/w1fvfkFE26WoOz1OhQ5GKAnIODk6ISMUXS3cuxNyMHy0NyYXrr/6uQLAkghd mm7xmMhLTeJmhP5mxNKhHau6acBvDkBUHwAuG6PcxFoxuIpFrW0OsDGiGRqhY37KcfY2 16aA== 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=VDKIngzbn3m6A/0bOf2q9W21tPmblacMTNI1cDxa2ds=; b=KY+N+D/Kh30+LS0JaEwGzXZB719KRbeYcyiisf0W63FwZF3+qAjaF8e9xcaExDyfqv Xb1o/n2RsO8XhRQhONW6TRaiXl5ts4Eqtvubr6ln1W0BO0i/hm1pR148Wv3AMUcXmktt ZqZbVlJMPHOuIhjnfwMpH1xuRbgnFubdnVes06MxxfQiTIXGYRkXq5qpE3IczPtTrM2M kWCiw2QcfEGx3XzMn/TbryCZZdMy4cB4QSZozfBktgyuO5dgN0qQ0jhWwtr8B+fD+xMF xxqamv8S8VhrsLyFrPk0MZF2GgEWfYr3WMap99i/22YUIOwE708lLcXyj7KEgNUI8MmT yM7g== X-Gm-Message-State: APjAAAX8NiULNralzM5aKTHJYWU9vdQzL8HT5fp3lqF/W4aERMiOwT0a jD1EqHP3eJw7qi3gM9pcVUJyBidwoOadnUnETJ8= X-Google-Smtp-Source: APXvYqzYEzZgpSjL9QMyYjJykJlQGSa0jGmHTmJ1h/H+BRuRFAfPktLidP+es+a6LQjRyR5Ryc7Zp7I7LQz75r7T5RI= X-Received: by 2002:a2e:8959:: with SMTP id b25mr9467ljk.240.1572298597078; Mon, 28 Oct 2019 14:36:37 -0700 (PDT) MIME-Version: 1.0 References: <67339BE2-E7EF-4AC3-8ED8-9443246CE293@amazon.com> In-Reply-To: <67339BE2-E7EF-4AC3-8ED8-9443246CE293@amazon.com> From: Dick Hardt Date: Mon, 28 Oct 2019 14:36:25 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "oauth@ietf.org" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005c1c8e0595ff4ba2" Archived-At: Subject: Re: [OAUTH-WG] Tx Auth BOF agenda items X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Oct 2019 21:36:41 -0000 --0000000000005c1c8e0595ff4ba2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin & Annabelle! On Mon, Oct 28, 2019 at 2:35 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Justin had requested that I present on some non-authorization use cases > for something like XYZ. This shouldn=E2=80=99t take more than 15 minutes. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, October 28, 2019 at 8:41 AM > *To: *"oauth@ietf.org" , "txauth@ietf.org" < > txauth@ietf.org> > *Subject: *[OAUTH-WG] Tx Auth BOF agenda items > > > > Hey OAuthers > > > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM > > Monday Afternoon, I'm gathering who would be interested in making > presentations, and how much time you would like. > > > > /Dick > --0000000000005c1c8e0595ff4ba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Justin & Annabelle!

On Mon, Oct 28, 2019 at 2:35= PM Richard Backman, Annabelle <r= ichanna@amazon.com> wrote:

Justin had requested that I present on some non-auth= orization use cases for something like XYZ. This shouldn=E2=80=99t take mor= e than 15 minutes.

=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 Dick Hardt <dick.hardt@gmail.com>
Date: Monday, October 28, 2019 at 8:41 AM
To: "oauth@= ietf.org" <= oauth@ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Subject: [OAUTH-WG] Tx Auth BOF agenda items

=C2=A0

Hey OAuthers

=C2=A0

As chair of the Tx BOF coming up in Singapore on Nov= 18 @ 5:30-7:30PM

Monday Afternoon, I'm gathering who would be int= erested in making presentations, and how much time you would like.

=C2=A0

/Dick

--0000000000005c1c8e0595ff4ba2-- From nobody Tue Oct 29 04:57:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9C120041 for ; Tue, 29 Oct 2019 04:57:39 -0700 (PDT) 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 U0MM4cbd18Tr for ; Tue, 29 Oct 2019 04:57:37 -0700 (PDT) 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 5645B12016E for ; Tue, 29 Oct 2019 04:57:37 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id d83so11077119ilk.7 for ; Tue, 29 Oct 2019 04:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HV7w/3Lic3wc8O///KhsiiDVUIXs1LC2MjZcBpmDl7s=; b=epjEEU20qvWgru8DYzTigV9iWtQywZ5HwdEFT4hRanovzdx94xNlXZ87FMkrXAgksQ pZgBtwRfrMbIPejs6M2tPawdVXeE3pH+W/0SMggdPn9K0cF9qUR2nVO2BE57ZiFUXlET J5Rsk7aboFo/tmGNZ5PEmNb/PUN1hetyoO1gb3y8bcqphS12akY1+3DSL0gkGPEtVw9d 3sAabezNKxErwTzcNa6zJXAyWZv0ih4yB/TIaaiWv8RuLvIY/PQ0+R1VAWbmmhIJYB2B 8wHz74CuT2d9eTZSxWqdkFHZeJKpfDo0FufSBClUSvPEB4ICit/1xAJjSSwasrd84a4U 9Hxg== 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=HV7w/3Lic3wc8O///KhsiiDVUIXs1LC2MjZcBpmDl7s=; b=U26stFheEcuOwR0YIF6GxRyhY2T57at71UU66IM+tTq8/Obr0pl235ENB+tsoNRRgk j7z5QH7Tot8oC7S6CQdJJgKyesLaUI7dJ976sbrrHvDxfZfCyomdF1Ai4+3FuHlBsPwn kl9dK91Sr6Fvm3+ZI1qKxiuV4VkyfsvwwGP8C1J7sxBExfkFgjI7DYtdXuyuFoMzQk/Q ZXjexrMPo7u0iP3ZXaL7dAI5WmFlTPAYOsx2YgiVa4EEchJMvLnx4KvMgiqdE3iDNaxD HeZaYPrv3WljkkMaKOYXCCd4+rCBz6wixaYZb9bscIgbaZUzLIKykFkf8JscrsaQk0L5 QT4A== X-Gm-Message-State: APjAAAWka8RnfE0sbIr6BhZMAvKBQdJ9lNzvc40WzICLmzRRw+HY9V77 llPyeNe+Iw2D2EYqCVUi6HJsUOzVxyVSSLFQjL4= X-Google-Smtp-Source: APXvYqx7RcIzkdOxWXRaAgsQgLAWNA+6InMM2Uwi6CcyF+KTJzx2AL9KFL5LV5dyW4rkXG0B1gbZJABElMDkTK4UzEk= X-Received: by 2002:a92:8897:: with SMTP id m23mr23342740ilh.36.1572350256648; Tue, 29 Oct 2019 04:57:36 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <045A61A9-A5E3-4700-8669-A74931D4E7FB@akamai.com> In-Reply-To: <045A61A9-A5E3-4700-8669-A74931D4E7FB@akamai.com> From: Rifaat Shekh-Yusef Date: Tue, 29 Oct 2019 07:57:25 -0400 Message-ID: To: "Salz, Rich" Cc: Neil Madden , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000082976b05960b521a" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 11:57:40 -0000 --00000000000082976b05960b521a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe I misunderstood what you meant by "client-cert". If you meant the proxy client certificate, then that is obviously not enough. You seem to suggest that you meant the remote client certificate to be installed on the proxy to be used with the backend system; if this is the case, then this would work and you would not need the signature, but the issue I see with this approach is that you need to reconfigure the proxy every time you change the client certificate, which is not practical if the certificate is short lived. Regards, Rifaat On Mon, Oct 28, 2019 at 2:55 PM Salz, Rich wrote: > > - To avoid the misconfiguration issue Neil raised, you probably need > both: a client-cert *and* a signature over the certificate being > forwarded, > > > > I am not so sure. One can argue that transport-level identity should be > secured by transport-level. But installing a client certificate on a > reverse proxy can be difficult. (Not if the reverse proxy is a CDN, of > course :) And I don=E2=80=99t see how having both prevents misconfigurati= on, but > that might be my fault. > > > > - This could still be achieve by extending RFC7239 with new > parameter(s). > > > > I have no opinion on this part of it. > > > --00000000000082976b05960b521a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe I misunderstood what you meant by "client-= cert". If you meant the proxy client certificate, then that is obvious= ly not enough. You seem to suggest that you meant the remote client certifi= cate to be installed on the proxy to be used with the backend system; if th= is is the case, then this would work and you would not need the signature, = but the issue I see with this approach is that you need to reconfigure the = proxy every time you change the client certificate, which is not practical = if the certificate=C2=A0is short lived.

Regards,
=C2=A0Rifaat


On Mon, Oct 28, 2019 at 2:55 PM Salz, R= ich <rsalz@akamai.com> wrote:=
  • To avoid=C2=A0the misconfiguration issue Neil raised, you probably= need both: a client-cert=C2=A0and a signature over the certificate = being forwarded,

=C2=A0

I am not so sure.=C2=A0 One can argue that transport= -level identity should be secured by transport-level.=C2=A0 But installing = a client certificate on a reverse proxy can be difficult.=C2=A0 (Not if the= reverse proxy is a CDN, of course :) And I don=E2=80=99t see how having both prevents misconfiguration, but that might be my fault.=

=C2=A0

  • This could still be achieve by extending RFC7239 with new paramete= r(s).

=C2=A0

I have no opinion on this part of it.<= /p>

=C2=A0

--00000000000082976b05960b521a-- From nobody Tue Oct 29 05:07:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0336212029C for ; Tue, 29 Oct 2019 05:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB3OpWABvBZO for ; Tue, 29 Oct 2019 05:07:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 C2ED9120041 for ; Tue, 29 Oct 2019 05:07:37 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9TC7QKv026147; Tue, 29 Oct 2019 12:07:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=JCm4lgWorb+LjEMbWAQLkVYQhYx/+utp22X8uZCWZ6g=; b=QKRk5GxCh+EYck3v0J6FH1NO5N+L4A8Di78tEmSitPVEkLSpJhAyR51tYjJvSL8Fyaup 1kfmMeQwI9jp12hX4hhQnNILw/haMq6ObUHDlKnza93azuz+IcgTqTGYJ3eOgJ+3o6cq nTiCLDaEzu4IMfWeU0ze5q5Y47z6ZRyKRgYwYrxguaAK/TNsk+d08jugRgRERxcV0Pjd gXy/dp1Sf7ijrrpXOk1JRjXUceNfZxx0qR71gpUJOtYdgIRGTeST2DRmJawK8xjn/+KX qsSaaaDZCWzYmvJdinrKFvroj1/D6KZOBwvpP1Gk09sDi+xaONppyZR/kjonWjgDgDLn Og== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vvej8pxru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 12:07:33 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9TC2k8K006907; Tue, 29 Oct 2019 08:07:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vvhfwvvx0-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 08:07:01 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 29 Oct 2019 08:05:57 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 29 Oct 2019 08:05:57 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 29 Oct 2019 08:05:57 -0400 From: "Salz, Rich" To: Rifaat Shekh-Yusef CC: Neil Madden , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4D//8FmgIAAZUaA//++JYCAAWCggP//v1WA Date: Tue, 29 Oct 2019 12:05:57 +0000 Message-ID: <4FB4BBA3-5553-4AA7-AF33-5CF1F64B1A8F@akamai.com> References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <045A61A9-A5E3-4700-8669-A74931D4E7FB@akamai.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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.45] Content-Type: multipart/alternative; boundary="_000_4FB4BBA355534AA7AF335CF1F64B1A8Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910290121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-29_04:2019-10-28,2019-10-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 clxscore=1015 suspectscore=0 spamscore=0 malwarescore=0 priorityscore=1501 phishscore=0 adultscore=0 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910290122 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 12:07:45 -0000 --_000_4FB4BBA355534AA7AF335CF1F64B1A8Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtZWFuIHRoZSBjZXJ0IHRoYXQgdGhlIE9SSUdJTkFMIGNsaWVudCBwcmVzZW50ZWQgdG8gdGhl IHByb3h5Lg0KDQpGcm9tOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNv bT4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMjksIDIwMTkgYXQgNzo1NyBBTQ0KVG86IFJpY2gg U2FseiA8cnNhbHpAYWthbWFpLmNvbT4NCkNjOiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9y Z2Vyb2NrLmNvbT4sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnPiwgb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gY2xpZW50IGNlcnRzIGFuZCBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94aWVz ICh3YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24t cmVzcG9uc2UtMDgudHh0KQ0KDQpNYXliZSBJIG1pc3VuZGVyc3Rvb2Qgd2hhdCB5b3UgbWVhbnQg YnkgImNsaWVudC1jZXJ0Ii4gSWYgeW91IG1lYW50IHRoZSBwcm94eSBjbGllbnQgY2VydGlmaWNh dGUsIHRoZW4gdGhhdCBpcyBvYnZpb3VzbHkgbm90IGVub3VnaC4gWW91IHNlZW0gdG8gc3VnZ2Vz dCB0aGF0IHlvdSBtZWFudCB0aGUgcmVtb3RlIGNsaWVudCBjZXJ0aWZpY2F0ZSB0byBiZSBpbnN0 YWxsZWQgb24gdGhlIHByb3h5IHRvIGJlIHVzZWQgd2l0aCB0aGUgYmFja2VuZCBzeXN0ZW07IGlm IHRoaXMgaXMgdGhlIGNhc2UsIHRoZW4gdGhpcyB3b3VsZCB3b3JrIGFuZCB5b3Ugd291bGQgbm90 IG5lZWQgdGhlIHNpZ25hdHVyZSwgYnV0IHRoZSBpc3N1ZSBJIHNlZSB3aXRoIHRoaXMgYXBwcm9h Y2ggaXMgdGhhdCB5b3UgbmVlZCB0byByZWNvbmZpZ3VyZSB0aGUgcHJveHkgZXZlcnkgdGltZSB5 b3UgY2hhbmdlIHRoZSBjbGllbnQgY2VydGlmaWNhdGUsIHdoaWNoIGlzIG5vdCBwcmFjdGljYWwg aWYgdGhlIGNlcnRpZmljYXRlIGlzIHNob3J0IGxpdmVkLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0K DQoNCk9uIE1vbiwgT2N0IDI4LCAyMDE5IGF0IDI6NTUgUE0gU2FseiwgUmljaCA8cnNhbHpAYWth bWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4+IHdyb3RlOg0KDQogICogICBUbyBhdm9p ZCB0aGUgbWlzY29uZmlndXJhdGlvbiBpc3N1ZSBOZWlsIHJhaXNlZCwgeW91IHByb2JhYmx5IG5l ZWQgYm90aDogYSBjbGllbnQtY2VydCBhbmQgYSBzaWduYXR1cmUgb3ZlciB0aGUgY2VydGlmaWNh dGUgYmVpbmcgZm9yd2FyZGVkLA0KDQpJIGFtIG5vdCBzbyBzdXJlLiAgT25lIGNhbiBhcmd1ZSB0 aGF0IHRyYW5zcG9ydC1sZXZlbCBpZGVudGl0eSBzaG91bGQgYmUgc2VjdXJlZCBieSB0cmFuc3Bv cnQtbGV2ZWwuICBCdXQgaW5zdGFsbGluZyBhIGNsaWVudCBjZXJ0aWZpY2F0ZSBvbiBhIHJldmVy c2UgcHJveHkgY2FuIGJlIGRpZmZpY3VsdC4gIChOb3QgaWYgdGhlIHJldmVyc2UgcHJveHkgaXMg YSBDRE4sIG9mIGNvdXJzZSA6KSBBbmQgSSBkb27igJl0IHNlZSBob3cgaGF2aW5nIGJvdGggcHJl dmVudHMgbWlzY29uZmlndXJhdGlvbiwgYnV0IHRoYXQgbWlnaHQgYmUgbXkgZmF1bHQuDQoNCg0K ICAqICAgVGhpcyBjb3VsZCBzdGlsbCBiZSBhY2hpZXZlIGJ5IGV4dGVuZGluZyBSRkM3MjM5IHdp dGggbmV3IHBhcmFtZXRlcihzKS4NCg0KSSBoYXZlIG5vIG9waW5pb24gb24gdGhpcyBwYXJ0IG9m IGl0Lg0KDQo= --_000_4FB4BBA355534AA7AF335CF1F64B1A8Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <21842896A178AD45866695ACEE58270A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFp bC1tNTA5MjMwMDQ3NjE3NDg4OTg5OG1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW01MDkyMzAw NDc2MTc0ODg5ODk4bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW01MDkyMzAwNDc2MTc0ODg5 ODk4bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzUwOTIzMDA0NzYx NzQ4ODk4OThtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoyOTMwOTEwMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk0MTMxNDMyO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI2MDQwODI3NTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTk3ODQ0NjU3MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBtZWFuIHRoZSBjZXJ0IHRoYXQg dGhlIE9SSUdJTkFMIGNsaWVudCBwcmVzZW50ZWQgdG8gdGhlIHByb3h5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZh YXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE9jdG9iZXIg MjksIDIwMTkgYXQgNzo1NyBBTTxicj4NCjxiPlRvOiA8L2I+UmljaCBTYWx6ICZsdDtyc2FsekBh a2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+TmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVu QGZvcmdlcm9jay5jb20mZ3Q7LCBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDssIG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gY2xpZW50IGNlcnRzIGFuZCBU TFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94aWVzICh3YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDgudHh0KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1heWJlIEkgbWlzdW5kZXJzdG9vZCB3aGF0IHlvdSBtZWFudCBieSAmcXVvdDtjbGllbnQtY2Vy dCZxdW90Oy4gSWYgeW91IG1lYW50IHRoZSBwcm94eSBjbGllbnQgY2VydGlmaWNhdGUsIHRoZW4g dGhhdCBpcyBvYnZpb3VzbHkgbm90IGVub3VnaC4gWW91IHNlZW0gdG8gc3VnZ2VzdCB0aGF0IHlv dSBtZWFudCB0aGUgcmVtb3RlIGNsaWVudCBjZXJ0aWZpY2F0ZSB0byBiZSBpbnN0YWxsZWQgb24g dGhlIHByb3h5IHRvIGJlIHVzZWQNCiB3aXRoIHRoZSBiYWNrZW5kIHN5c3RlbTsgaWYgdGhpcyBp cyB0aGUgY2FzZSwgdGhlbiB0aGlzIHdvdWxkIHdvcmsgYW5kIHlvdSB3b3VsZCBub3QgbmVlZCB0 aGUgc2lnbmF0dXJlLCBidXQgdGhlIGlzc3VlIEkgc2VlIHdpdGggdGhpcyBhcHByb2FjaCBpcyB0 aGF0IHlvdSBuZWVkIHRvIHJlY29uZmlndXJlIHRoZSBwcm94eSBldmVyeSB0aW1lIHlvdSBjaGFu Z2UgdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZSwgd2hpY2ggaXMgbm90IHByYWN0aWNhbCBpZg0KIHRo ZSBjZXJ0aWZpY2F0ZSZuYnNwO2lzIHNob3J0IGxpdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDI4LCAy MDE5IGF0IDI6NTUgUE0gU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1h aS5jb20iPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJnbWFpbC1tNTA5MjMwMDQ3NjE3NDg4OTg5OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUbyBhdm9pZCZuYnNwO3RoZSBtaXNjb25maWd1cmF0 aW9uIGlzc3VlIE5laWwgcmFpc2VkLCB5b3UgcHJvYmFibHkgbmVlZCBib3RoOiBhIGNsaWVudC1j ZXJ0Jm5ic3A7PGI+YW5kPC9iPiBhIHNpZ25hdHVyZSBvdmVyIHRoZSBjZXJ0aWZpY2F0ZSBiZWlu ZyBmb3J3YXJkZWQsDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gbm90 IHNvIHN1cmUuJm5ic3A7IE9uZSBjYW4gYXJndWUgdGhhdCB0cmFuc3BvcnQtbGV2ZWwgaWRlbnRp dHkgc2hvdWxkIGJlIHNlY3VyZWQgYnkgdHJhbnNwb3J0LWxldmVsLiZuYnNwOyBCdXQgaW5zdGFs bGluZyBhIGNsaWVudCBjZXJ0aWZpY2F0ZSBvbiBhIHJldmVyc2UgcHJveHkgY2FuIGJlIGRpZmZp Y3VsdC4mbmJzcDsgKE5vdA0KIGlmIHRoZSByZXZlcnNlIHByb3h5IGlzIGEgQ0ROLCBvZiBjb3Vy c2UgOikgQW5kIEkgZG9u4oCZdCBzZWUgaG93IGhhdmluZyBib3RoIHByZXZlbnRzIG1pc2NvbmZp Z3VyYXRpb24sIGJ1dCB0aGF0IG1pZ2h0IGJlIG15IGZhdWx0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9ImdtYWlsLW01MDkyMzAwNDc2MTc0ODg5ODk4bXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NClRoaXMgY291bGQgc3Rp bGwgYmUgYWNoaWV2ZSBieSBleHRlbmRpbmcgUkZDNzIzOSB3aXRoIG5ldyBwYXJhbWV0ZXIocyku PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgbm8gb3BpbmlvbiBvbiB0 aGlzIHBhcnQgb2YgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4FB4BBA355534AA7AF335CF1F64B1A8Fakamaicom_-- From nobody Tue Oct 29 12:13:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3212085E for ; Tue, 29 Oct 2019 12:13:45 -0700 (PDT) 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 OQpWZhOrh_YQ for ; Tue, 29 Oct 2019 12:13:44 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC181200F5 for ; Tue, 29 Oct 2019 12:13:43 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9TJDdQX026401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 15:13:40 -0400 From: Justin Richer Message-Id: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E846CCF8-F72C-4984-BE00-F7807C85DE8F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 29 Oct 2019 15:13:38 -0400 In-Reply-To: Cc: Brian Campbell , oauth To: Neil Madden References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 19:13:46 -0000 --Apple-Mail=_E846CCF8-F72C-4984-BE00-F7807C85DE8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would argue that making this standard would actually increase the = likelihood of developers getting this right, as now instead of following = some copy-pasted recipe for NGINX or Apache that they found on the web, = they could turn on a standard setting that would take care of both = stripping out incoming headers and injecting the appropriate values. And = all of that can be covered in the security considerations with a bunch = of normative text on top to make sure inbound headers are stripped. What = you=E2=80=99re describing below is clever, but ultimately it=E2=80=99s = just a small bit of obscurity more than anything real.=20 The way things are today, you=E2=80=99ve got to not only pick a header = and figure out its format, but also do the injection protection step = yourself. Since all of these are disconnected, there are a lot more = places that it could fall over. Even a typo where you throw out incoming = =E2=80=9CCLIENT_CERT=E2=80=9D but inject =E2=80=9CCLIENT_CERTS=E2=80=9D = or something like that would be disastrous.=20 All in all, I am in favor of this being defined in one standard way, in = addition to secure communication between proxies and backends being = standardized =E2=80=94 but this latter bit really seems like a separate = problem. =E2=80=94 Justin > On Oct 28, 2019, at 12:32 PM, Neil Madden = wrote: >=20 > While there are some benefits to standardizing headers for this kind = of communication, there are some significant downsides - particularly = when using headers to communicate critical security information like = certs. It is *very* easy to misconfigure a reverse proxy to not strip = Forwarded (or whatever) headers from incoming requests, allowing a = client to simply supply a certificate as a header without authenticating = the TLS connection with the corresponding private key. One good practice = to prevent this is to pick a random and unguessable header name = (configurable per installation) to be used for communicating the = certificate, rather than using something fixed and standard. That way = even if you misconfigure the proxy an attacker still has to try and = guess the correct header name. >=20 > I suppose the same thing could be accomplished by having an extension = for including a shared secret (or HMAC tag) in the header to = authenticate it. >=20 > -- Neil >=20 >> On 28 Oct 2019, at 15:32, Brian Campbell = > wrote: >>=20 >> I don't think there's anything beyond defining something to carry the = client certificate information (including the format and encoding). And = it could well be a new RFC7239 parameter. Or it might just be a new HTTP = header on its own. =20 >>=20 >> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef = > wrote: >> Thanks Brian, >>=20 >> I guess my question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating reverse = proxy and the backend service in a cluster, is there anything, from a = standard perspective, that we need to do beyond defining a new parameter = to carry the client certificate information? >> You seem suggest that the answer is yes. If so, can you please = elaborate on why is that? >>=20 >> Regards, >> Rifaat >>=20 >>=20 >>=20 >> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell = > wrote: >>=20 >>=20 >> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef = > wrote: >>=20 >> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell = > wrote: >>=20 >> I did look at RFC7239 when doing that and it could have been made to = work but felt the fit wasn't quite right and would have been more = cumbersome to use than not. =20 >>=20 >>=20 >> Can you elaborate on this? >> These days, with the zero trust model in mind, there are = orchestration tools, e.g. Istio, that easily allows you to establish an = MTLS channel between the reverse proxy/load balancer/API GW and the = backend servers. >> Why is that not sufficient?=20 >> Which part is cumbersome? >>=20 >> What I meant was only that in the course of writing = https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09 = , which aims to = define HTTP header fields that enable a TLS terminating reverse proxy to = convey information to a backend server about the validated Token Binding = Message received from a client, it seemed more straightforward and = sufficient for the use-case to use new HTTP headers to carry the = information rather than to use new fields in the Forwarded header = framework from RFC7239. =20 >> =20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>=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=_E846CCF8-F72C-4984-BE00-F7807C85DE8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would argue that making this standard would actually increase the = likelihood of developers getting this right, as now instead of following = some copy-pasted recipe for NGINX or Apache that they found on the web, = they could turn on a standard setting that would take care of both = stripping out incoming headers and injecting the appropriate values. And = all of that can be covered in the security considerations with a bunch = of normative text on top to make sure inbound headers are stripped. What = you=E2=80=99re describing below is clever, but ultimately it=E2=80=99s = just a small bit of obscurity more than anything real. 

The way things are = today, you=E2=80=99ve got to not only pick a header and figure out its = format, but also do the injection protection step yourself. Since all of = these are disconnected, there are a lot more places that it could fall = over. Even a typo where you throw out incoming =E2=80=9CCLIENT_CERT=E2=80=9D= but inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that would = be disastrous. 

All in all, I am in favor of this being defined in one = standard way, in addition to secure communication between proxies and = backends being standardized =E2=80=94 but this latter bit really seems = like a separate problem.

 =E2=80=94 Justin

On Oct = 28, 2019, at 12:32 PM, Neil Madden <neil.madden@forgerock.com> wrote:

While= there are some benefits to standardizing headers for this kind of = communication, there are some significant downsides - particularly when = using headers to communicate critical security information like certs. = It is *very* easy to misconfigure a reverse proxy to not strip Forwarded = (or whatever) headers from incoming requests, allowing a client to = simply supply a certificate as a header without authenticating the TLS = connection with the corresponding private key. One good practice to = prevent this is to pick a random and unguessable header name = (configurable per installation) to be used for communicating the = certificate, rather than using something fixed and standard. That way = even if you misconfigure the proxy an attacker still has to try and = guess the correct header name.

I suppose the same thing could be accomplished by having an = extension for including a shared secret (or HMAC tag) in the header to = authenticate it.

-- Neil

On 28 = Oct 2019, at 15:32, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I don't think there's anything beyond defining = something to carry the client certificate information (including the = format and encoding). And it could well be a new RFC7239 parameter. Or = it might just be a new HTTP header on its own.  

On Mon, = Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thanks Brian,

I guess my = question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating = reverse proxy and the backend service in a cluster, is there anything, = from a standard perspective, that we need to do beyond defining a new = parameter to carry the client certificate information?
You = seem suggest that the answer is yes. If so, can you please elaborate on = why is that?

Regards,
 Rifaat



On Mon, Oct = 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

On Fri, Oct = 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

I did look at RFC7239 when doing that and it could have been = made to work but felt the fit wasn't quite right and would have been = more cumbersome to use than not.  


Can you elaborate on = this?
These days, with the zero trust model in = mind, there are orchestration tools, e.g. Istio, that easily allows you = to establish an MTLS channel between the reverse proxy/load balancer/API = GW and the backend servers.
Why is = that not sufficient? 
Which part is = cumbersome?

What I meant was only that in the = course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, = which aims to define HTTP header fields that enable a TLS terminating = reverse proxy to convey information to a backend server about the = validated Token Binding Message received from a client, it seemed more = straightforward and sufficient for the use-case to use new HTTP headers = to carry the information rather than to use new fields in the Forwarded = header framework from RFC7239.    
 

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this 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

= --Apple-Mail=_E846CCF8-F72C-4984-BE00-F7807C85DE8F-- From nobody Tue Oct 29 14:56:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322931200F7 for ; Tue, 29 Oct 2019 14:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7JVon-rMiIv for ; Tue, 29 Oct 2019 14:55:57 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B39212001E for ; Tue, 29 Oct 2019 14:55:56 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id v8so11687101lfa.12 for ; Tue, 29 Oct 2019 14:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOAokZg54zwslNVdHm5rkaiQCL0ysMnNeg/iy4IZQOM=; b=YyOIrYtXKsOdiOiSaTPhBg1vTTV+qzAGvsWRwORrJPzHxpsQmh0gE66KNR4dB7YHY6 dehcsHPFSQ1RTZjTJQhjcMS0adcBXmkkq6nSlPHIbzO5KFNSDiSyc2/Nvb9HgxiQL3Zh MhKOLgEKDPP9dT+3qmDquQXmvjLbZggCIjaqU= 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=jOAokZg54zwslNVdHm5rkaiQCL0ysMnNeg/iy4IZQOM=; b=IgDm4FNYiBmgCY4YaswdawyfxD4QLx612Ep0OMy2Ks7EF07pTZiRvBMhleY/LhUCPT bjsBMaZc3eDLHJTuSauGm1GRXkVUM5VRDwcgaO9ifFbAGBGiNkH1gyTtSH2m1Nk/VEKV JOTR/alllNdqJj5jkZgYSKcnSmoqJGW3f5tmtBzhZuBws8UnVqZIW6EiCLDJTOKWhbqq M+pvx7QX/zod2wTy1iI6rJ7BdJV4DgHXPBbbhegsJu+dG0i+hEAN5jle7UcwAGvi8z9H eEnBdg/4cYihXnsHrBEv51yNYH7+uf2fhqL04kDjeUJjkmMxhhUqybX411eIlJruxxMA zXVg== X-Gm-Message-State: APjAAAWtmZYtzsPrBlR71xZuPVmnlSgyuCVLPmfDjCaecHnJV2uhQoCh 01Z7ystFBrqOsBvREc29D/gN1yosbx514qt5O3EgPbjuc5Hqmp7wTAiSCtSgXhoInns4Qrk5XeL g9WhpV2xp6n9Z5w== X-Google-Smtp-Source: APXvYqzgTRDfNunDvnY7b22zVdRKs4tWYWcGopSVjuwQ2OyWUIGPtQx7duA3n/oRbgsvKReMTwyXcWW0xptCbe9ZhE0= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr3533484lff.17.1572386154663; Tue, 29 Oct 2019 14:55:54 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> In-Reply-To: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> From: Brian Campbell Date: Tue, 29 Oct 2019 15:55:27 -0600 Message-ID: To: Justin Richer Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="00000000000032ed28059613aed2" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 21:56:00 -0000 --00000000000032ed28059613aed2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to pretty much everything Justin said there. With some facilitating assistance from Ben it looks like there's now an agenda slot for this in the upcoming secdispatch meeting in Singapore. I'll attempt to articulate the situation and see if there's interest in finding a home for the perspective work. Folks that'll be in Singapore and interested in the topic would be encouraged to attend to the secdispatch meeting during the Afternoon Session III 1710-1840 on Tuesday. On Tue, Oct 29, 2019 at 1:13 PM Justin Richer wrote: > I would argue that making this standard would actually increase the > likelihood of developers getting this right, as now instead of following > some copy-pasted recipe for NGINX or Apache that they found on the web, > they could turn on a standard setting that would take care of both > stripping out incoming headers and injecting the appropriate values. And > all of that can be covered in the security considerations with a bunch of > normative text on top to make sure inbound headers are stripped. What > you=E2=80=99re describing below is clever, but ultimately it=E2=80=99s ju= st a small bit of > obscurity more than anything real. > > The way things are today, you=E2=80=99ve got to not only pick a header an= d figure > out its format, but also do the injection protection step yourself. Since > all of these are disconnected, there are a lot more places that it could > fall over. Even a typo where you throw out incoming =E2=80=9CCLIENT_CERT= =E2=80=9D but > inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that would be dis= astrous. > > All in all, I am in favor of this being defined in one standard way, in > addition to secure communication between proxies and backends being > standardized =E2=80=94 but this latter bit really seems like a separate p= roblem. > > =E2=80=94 Justin > > On Oct 28, 2019, at 12:32 PM, Neil Madden > wrote: > > While there are some benefits to standardizing headers for this kind of > communication, there are some significant downsides - particularly when > using headers to communicate critical security information like certs. It > is *very* easy to misconfigure a reverse proxy to not strip Forwarded (or > whatever) headers from incoming requests, allowing a client to simply > supply a certificate as a header without authenticating the TLS connectio= n > with the corresponding private key. One good practice to prevent this is = to > pick a random and unguessable header name (configurable per installation) > to be used for communicating the certificate, rather than using something > fixed and standard. That way even if you misconfigure the proxy an attack= er > still has to try and guess the correct header name. > > I suppose the same thing could be accomplished by having an extension for > including a shared secret (or HMAC tag) in the header to authenticate it. > > -- Neil > > On 28 Oct 2019, at 15:32, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > I don't think there's anything beyond defining something to carry the > client certificate information (including the format and encoding). And i= t > could well be a new RFC7239 parameter. Or it might just be a new HTTP > header on its own. > > On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef > wrote: > >> Thanks Brian, >> >> I guess my question is: given RFC7239 and the fact that it is >> straightforward to secure the channel between the terminating reverse pr= oxy >> and the backend service in a cluster, is there anything, from a standard >> perspective, that we need to do beyond defining a new parameter to carry >> the client certificate information? >> You seem suggest that the answer is yes. If so, can you please elaborate >> on why is that? >> >> Regards, >> Rifaat >> >> >> >> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> >>> >>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>>> >>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> >>>>> I did look at RFC7239 when doing that and it could have been made to >>>>> work but felt the fit wasn't quite right and would have been more >>>>> cumbersome to use than not. >>>>> >>>>> >>>> Can you elaborate on this? >>>> These days, with the zero trust model in mind, there are orchestration >>>> tools, e.g. Istio, that easily allows you to establish an MTLS channel >>>> between the reverse proxy/load balancer/API GW and the backend servers= . >>>> Why is that not sufficient? >>>> Which part is cumbersome? >>>> >>> >>> What I meant was only that in the course of writing >>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to >>> define HTTP header fields that enable a TLS terminating reverse proxy t= o >>> convey information to a backend server about the validated Token Bindin= g >>> Message received from a client, it seemed more straightforward and >>> sufficient for the use-case to use new HTTP headers to carry the >>> information rather than to use new fields in the Forwarded header frame= work >>> from RFC7239. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may 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.*_______________________________________________ > OAuth mailing 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._ --00000000000032ed28059613aed2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to pretty much everything Justin said there.
<= /div>

With some facilitating assistance from Ben it look= s like there's now an agenda slot for this in the upcoming secdispatch = meeting in Singapore. I'll attempt to articulate the situation and see = if there's interest in finding a home for the perspective work. Folks t= hat'll be in Singapore and interested in the topic would be encouraged = to attend to the secdispatch meeting during the Afternoon Session III 1710= -1840 on Tuesday.


On Tue, Oct 29, 2019 at 1:13 PM = Justin Richer <jric= her@mit.edu> wrote:
I would argue that making this standard would actually incr= ease the likelihood of developers getting this right, as now instead of fol= lowing some copy-pasted recipe for NGINX or Apache that they found on the w= eb, they could turn on a standard setting that would take care of both stri= pping out incoming headers and injecting the appropriate values. And all of= that can be covered in the security considerations with a bunch of normati= ve text on top to make sure inbound headers are stripped. What you=E2=80=99= re describing below is clever, but ultimately it=E2=80=99s just a small bit= of obscurity more than anything real.=C2=A0

The way thi= ngs are today, you=E2=80=99ve got to not only pick a header and figure out = its format, but also do the injection protection step yourself. Since all o= f these are disconnected, there are a lot more places that it could fall ov= er. Even a typo where you throw out incoming =E2=80=9CCLIENT_CERT=E2=80=9D = but inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that would be d= isastrous.=C2=A0

All in all, I am in favor of this= being defined in one standard way, in addition to secure communication bet= ween proxies and backends being standardized =E2=80=94 but this latter bit = really seems like a separate problem.

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

On Oct 28, 2019, at 1= 2:32 PM, Neil Madden <neil.madden@forgerock.com> wrote:

While there are some benefits to standardizing headers for this kind o= f communication, there are some significant downsides - particularly when u= sing headers to communicate critical security information like certs. It is= *very* easy to misconfigure a reverse proxy to not strip Forwarded (or wha= tever) headers from incoming requests, allowing a client to simply supply a= certificate as a header without authenticating the TLS connection with the= corresponding private key. One good practice to prevent this is to pick a = random and unguessable header name (configurable per installation) to be us= ed for communicating the certificate, rather than using something fixed and= standard. That way even if you misconfigure the proxy an attacker still ha= s to try and guess the correct header name.

I suppose th= e same thing could be accomplished by having an extension for including a s= hared secret (or HMAC tag) in the header to authenticate it.

-- Neil

On 28 Oct 2019, at 15:32, Brian Campbell <bcampbe= ll=3D40pingidentity.com@dmarc.ietf.org> wrote:

I don't think there's anything beyond= defining something to carry the client certificate information (including = the format and encoding). And it could well be a new RFC7239 parameter. Or = it might just be a new HTTP header on its own.=C2=A0=C2=A0
On Mon, Oct 28, 2019 at 9:05 AM Rifaat = Shekh-Yusef <= rifaat.ietf@gmail.com> wrote:
Thanks=C2=A0Brian,

I guess my question is: given RFC7239 and the fact that it is st= raightforward=C2=A0to secure the channel=C2=A0between the terminating rever= se proxy and the backend service in a cluster, is there anything, from a st= andard perspective, that we need to do beyond defining a new parameter to c= arry the client certificate information?
You seem suggest that the answ= er is yes. If so, can you please elaborate on why is that?

Regards,
=C2=A0Rifaat


<= /div>

On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com= > wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat Sh= ekh-Yusef <ri= faat.ietf@gmail.com> wrote:

On Fri, Oct 25, 2019 at 3:47 PM Br= ian Campbell <bcampbell@pingidentity.com> wrote:

I did look at RFC7239 when doing that and it could have been made to work = but felt the fit wasn't quite right and would have been more cumbersome= to use than not.=C2=A0=C2=A0


Can you elaborate on this?
T= hese days, with the zero trust model in mind, there are orchestration tools= , e.g. Istio, that easily allows you to establish an MTLS channel between t= he reverse proxy/load balancer/API GW and the backend servers.
Why is that not sufficient?=C2=A0
Which part is cumbersome?

What I meant was only that i= n the course of writing=C2=A0https://tools.ietf.org/= html/draft-ietf-tokbind-ttrp-09, which aims to define HTTP header field= s that enable a TLS terminating reverse proxy to convey information to a ba= ckend server about the validated Token Binding Message received from a clie= nt, it seemed more straightforward and sufficient for the use-case to use n= ew HTTP headers to carry the information rather than to use new fields in t= he Forwarded header framework from RFC7239.=C2=A0 =C2=A0=C2=A0=
=C2=A0

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

CONFIDENTIALITY NOTICE: This email may contain confi= dential 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 noti= fy the sender immediately by e-mail and delete the message and any file att= achments from your computer. Thank you._________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


<= 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. --00000000000032ed28059613aed2-- From nobody Tue Oct 29 16:35:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684711200F7 for ; Tue, 29 Oct 2019 16:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 xs2wwcKKrrhL for ; Tue, 29 Oct 2019 16:35:55 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3343C12006D for ; Tue, 29 Oct 2019 16:35:55 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id t5so447378ilh.10 for ; Tue, 29 Oct 2019 16:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XRMYu/xAQ76Zndd2qLqWCtzxzJe8PpOYoZVsfy2mSM=; b=lCuqGuF9u97wncWCqYTWTTN0OCYpG06WBHKgT9+kGMh16VQshzUi4ZxhRcaexzoa4W /IQCFGHZ7O+w9b46+p2U511u4HTgN4lZaYNo2vrjK2lpdacq6I4v+8vX6xz0KWrv/jH/ y6EXcRDBhqXfFjAW64cXFh6T6WHwLag6fWgnJ5eWK8+7jTlvg983GR5H12vdcdzmkD7n w59cpnBl0eEAdqgC+6xeOcTKz2c8eRvJ6QgA+YQXz4LFjQB01i1vz6LBtClNQYSAk5iY SvR74tH4cpxnb274Y/1yKzO3IwCVQrWPscjJDS9/Tnr7tYRp1f9zm0AoszWeGxdCfoiY eFFA== 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=5XRMYu/xAQ76Zndd2qLqWCtzxzJe8PpOYoZVsfy2mSM=; b=oyf4Vrrewms4qxGH8Gcai+vWkzKoUBWqG4giy1+6X2x9W8Orgh4JWg/niVDRChO92q 6Iq+Wm2VJ7fbRQ57xjQfhK9T6FKvFn/7XdZ32JaGP9lppD6w0ZS0kypr2Cr+zlmQcpnZ 2fiMCzR7PrbDHHaAUGt+UnYstkDefTXWsrfT7NByJo+9qT1L9cBOGMnuf+GDCP7o9ko7 mhUXOfII/1ee7R57afIJR4Xf5i/VCFZ/l+S2Mes2rU2FAP4J4tklaQMqko5+BpJstSy7 INtcYpDreMryKdtVOPk7O/+0LDO/xkbLDqRZyCjipMKxu/LzDR6cLk2nawszcRuIKmzi STmw== X-Gm-Message-State: APjAAAVVNuV7Rdu1aQ+lYBlgKtFOGqi0QZ47Ww2fXWU0iUzr/xptbBBs wVSjE9kZZdOPB5K9/hF+hpm9Hg== X-Google-Smtp-Source: APXvYqw9dEtNzz0kHyYCnWDxxghFeDxWTij36p+7QPhpBDiyP4Pph0NQY53KXwdbEnMRHoBlbpsBvA== X-Received: by 2002:a92:d64a:: with SMTP id x10mr29016031ilp.305.1572392154269; Tue, 29 Oct 2019 16:35:54 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id b14sm48042iob.74.2019.10.29.16.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Oct 2019 16:35:53 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id n13so474914ilt.4; Tue, 29 Oct 2019 16:35:53 -0700 (PDT) X-Received: by 2002:a92:af99:: with SMTP id v25mr31642098ill.167.1572392153172; Tue, 29 Oct 2019 16:35:53 -0700 (PDT) MIME-Version: 1.0 References: <157021248387.1396.8889788139399592188.idtracker@ietfa.amsl.com> In-Reply-To: From: Aaron Parecki Date: Tue, 29 Oct 2019 16:35:41 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "oauth-chairs@ietf.org" Cc: oauth Content-Type: multipart/alternative; boundary="000000000000bcd47f0596151304" Archived-At: Subject: Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106 X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Oct 2019 23:35:57 -0000 --000000000000bcd47f0596151304 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello chairs, I would like to request time to discuss these two items: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04 https://tools.ietf.org/html/draft-parecki-oauth-client-intermediary-metadat= a-00 I will be attending in person. Thanks! ---- Aaron Parecki aaronparecki.com @aaronpk On Fri, Oct 4, 2019 at 2:13 PM Brian Campbell wrote: > > Hello chairs, > > I'd like to request some agenda time to present on: > https://tools.ietf.org/html/draft-fett-oauth-dpop > > Thank you, > Brian > > On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: >> >> Hi chairs, >> >> I would like to request the following slots: >> - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar >> - https://tools.ietf.org/html/draft-lodderstedt-oauth-par >> - Security BCP >> >> kind regards, >> Torsten.. >> >> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool < session-request@ietf.org>: >> >> =EF=BB=BF >> >> A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Web Authorization Protocol >> Area Name: Security Area >> Session Requester: Hannes Tschofenig >> >> Number of Sessions: 2 >> Length of Session(s): 1.5 Hours, 1.5 Hours >> Number of Attendees: 50 >> Conflicts to Avoid: >> Chair Conflict: acme tls rats sipcore anima >> Technology Overlap: ace secevent teep suit core tokbind saag >> >> >> >> People who must be present: >> Roman Danyliw >> Hannes Tschofenig >> Rifaat Shekh-Yusef >> >> Resources Requested: >> >> Special Requests: >> >> --------------------------------------------------------- >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000bcd47f0596151304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello chairs,

I would like to request time to discuss these two items:

https://tools.ietf.org/html/draft-= ietf-oauth-browser-based-apps-04

https://tools.ietf.or= g/html/draft-parecki-oauth-client-intermediary-metadata-00

I will be attending in person. Thanks!=C2=A0
----
Aaron Parecki
aa= ronparecki.com
@aaronpk




On Fri, Oct 4, 2019 at 2:13 PM Brian Campbell <bcampbell=3D40pingidentity.co= m@dmarc.ietf.org> wrote:
>
> Hello chairs,
>
> I'd like to request some agenda time to present on:
> https://tools.ietf.org/html/draft-fett-oauth-d= pop
>
> Thank you,
> Brian
>
> On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:
>>
>> Hi chairs,
>>
>> I would like to request the following slots:
>> - https://tools.ietf.org/html/draft-= lodderstedt-oauth-rar
>> - https://tools.ietf.org/html/draft-= lodderstedt-oauth-par
>> - Security BCP
>>
>> kind regards,
>> Torsten..
>>
>> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool &= lt;session-re= quest@ietf.org>:
>>
>> =EF=BB=BF
>>
>> A new meeting session request has just been submitted by Hannes Ts= chofenig, a Chair of the oauth working group.
>>
>>
>> ---------------------------------------------------------
>> Working Group Name: Web Authorization Protocol
>> Area Name: Security Area
>> Session Requester: Hannes Tschofenig
>>
>> Number of Sessions: 2
>> Length of Session(s):=C2=A0 1.5 Hours, 1.5 Hours
>> Number of Attendees: 50
>> Conflicts to Avoid:
>> Chair Conflict: acme tls rats sipcore anima
>> Technology Overlap: ace secevent teep suit core tokbind saag
>>
>>
>>
>> People who must be present:
>>=C2=A0 Roman Danyliw
>>=C2=A0 Hannes Tschofenig
>>=C2=A0 Rifaat Shekh-Yusef
>>
>> Resources Requested:
>>
>> Special Requests:
>>
>> ---------------------------------------------------------
>>
>> _______________________________________________
>> 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<= br> >
>
> 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
--
----
Aaron Parecki
=
--000000000000bcd47f0596151304-- From nobody Tue Oct 29 17:52:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE080120052 for ; Tue, 29 Oct 2019 17:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, 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=zmartzone-eu.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 u9s0OyMMPOMs for ; Tue, 29 Oct 2019 17:52:42 -0700 (PDT) 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 70F7B12009E for ; Tue, 29 Oct 2019 17:52:42 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id l3so928361qtp.2 for ; Tue, 29 Oct 2019 17:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PP2XVRVhxjMxJUVeGmFg6P5VZyGo8bXWjGu6Bixt9Lc=; b=jdRcycxIUGQZDXBsH2Pi9fNt4JbMkRTuogeKCJqtp6eSlmBazSy39NCDBYNbjOQO/K s5XlDVm940fH5spPcPeH5oVcIC83ZO1MJCTRzoegN7dGXYIqcGPPzVf5j2x5P1F5yNPw HQ+YVKxFeFmZY67sAKVefaGI9yhadlcd4S5qBafHqMAr//GryIZd1vKl+g6toakhtCfa jmyMcwxYETkmkeuz99YnwjDrsraxQPaODsuyO7DxmANNZ4qXOUP374J0/rxWzLQ9uzeD g6D99uSLX0K9TtnK9uczHLyw+8Cvak/kaafKuz5xWmyr3abshIOMtFNMbkbetiCcFrVA iozg== 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=PP2XVRVhxjMxJUVeGmFg6P5VZyGo8bXWjGu6Bixt9Lc=; b=hBXfPAHZY0E2enIwZ+jBIGKf2PJo5HqJG4omq1QYPSkFju1IwjGV2ffd/ISZGCAUgv 7cA1Mn7MkLYhco2QqA5SJ2DguJ5wIDkzHHJGT56JraPdxI+N4nJjzOdweFeRuu5uOfum O17daegSxXWwEslFS/eiSgjS3UGnDgpGEHmUm0IOwWMFs38RcTZh+sEfXx76RlJTnXvR sYWFonkObRyoouYDt/W9xvJLNxMjVAM9UdUTUUJcd9ROfxtjqyO+pg1YZ8NslVD0mOOp vxEZwA4LISbANuOK/K8dUWq8BGdwZQ1oieHbsVV57TK0XWyk1+YQLaQineW1ZYuKUed/ tUrQ== X-Gm-Message-State: APjAAAUFFf6f2q+oMWULC0lCEMYCLMDSzo6f5Zupg8GQC6Rxfp/3uins r0nRxVoPkkzDnpyXnDFcQGV7rYzeg0sKj69Lq6uavw== X-Google-Smtp-Source: APXvYqxs/l8ObXGAaK1ttNNp0WmKP9q35SgXc/TJcVf8PgMeh2POk/VcYjHn3QKL2DERNah4xLxmqugkWiTjOcaRT6o= X-Received: by 2002:ac8:4149:: with SMTP id e9mr2258210qtm.321.1572396760359; Tue, 29 Oct 2019 17:52:40 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> In-Reply-To: From: Hans Zandbelt Date: Wed, 30 Oct 2019 01:52:29 +0100 Message-ID: To: Brian Campbell Cc: Justin Richer , oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000058fc9505961626b1" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 00:52:45 -0000 --00000000000058fc9505961626b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to Justin's and Brian's comments, I am interested to contribute and I will try and be there in person as well Hans. On Tue, Oct 29, 2019, 22:56 Brian Campbell wrote: > +1 to pretty much everything Justin said there. > > With some facilitating assistance from Ben it looks like there's now an > agenda slot for this in the upcoming secdispatch meeting in Singapore. I'= ll > attempt to articulate the situation and see if there's interest in findin= g > a home for the perspective work. Folks that'll be in Singapore and > interested in the topic would be encouraged to attend to the secdispatch > meeting during the Afternoon Session III 1710-1840 on Tuesday. > > > On Tue, Oct 29, 2019 at 1:13 PM Justin Richer wrote: > >> I would argue that making this standard would actually increase the >> likelihood of developers getting this right, as now instead of following >> some copy-pasted recipe for NGINX or Apache that they found on the web, >> they could turn on a standard setting that would take care of both >> stripping out incoming headers and injecting the appropriate values. And >> all of that can be covered in the security considerations with a bunch o= f >> normative text on top to make sure inbound headers are stripped. What >> you=E2=80=99re describing below is clever, but ultimately it=E2=80=99s j= ust a small bit of >> obscurity more than anything real. >> >> The way things are today, you=E2=80=99ve got to not only pick a header a= nd figure >> out its format, but also do the injection protection step yourself. Sinc= e >> all of these are disconnected, there are a lot more places that it could >> fall over. Even a typo where you throw out incoming =E2=80=9CCLIENT_CERT= =E2=80=9D but >> inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that would be di= sastrous. >> >> All in all, I am in favor of this being defined in one standard way, in >> addition to secure communication between proxies and backends being >> standardized =E2=80=94 but this latter bit really seems like a separate = problem. >> >> =E2=80=94 Justin >> >> On Oct 28, 2019, at 12:32 PM, Neil Madden >> wrote: >> >> While there are some benefits to standardizing headers for this kind of >> communication, there are some significant downsides - particularly when >> using headers to communicate critical security information like certs. I= t >> is *very* easy to misconfigure a reverse proxy to not strip Forwarded (o= r >> whatever) headers from incoming requests, allowing a client to simply >> supply a certificate as a header without authenticating the TLS connecti= on >> with the corresponding private key. One good practice to prevent this is= to >> pick a random and unguessable header name (configurable per installation= ) >> to be used for communicating the certificate, rather than using somethin= g >> fixed and standard. That way even if you misconfigure the proxy an attac= ker >> still has to try and guess the correct header name. >> >> I suppose the same thing could be accomplished by having an extension fo= r >> including a shared secret (or HMAC tag) in the header to authenticate it= . >> >> -- Neil >> >> On 28 Oct 2019, at 15:32, Brian Campbell < >> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: >> >> I don't think there's anything beyond defining something to carry the >> client certificate information (including the format and encoding). And = it >> could well be a new RFC7239 parameter. Or it might just be a new HTTP >> header on its own. >> >> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef >> wrote: >> >>> Thanks Brian, >>> >>> I guess my question is: given RFC7239 and the fact that it is >>> straightforward to secure the channel between the terminating reverse p= roxy >>> and the backend service in a cluster, is there anything, from a standar= d >>> perspective, that we need to do beyond defining a new parameter to carr= y >>> the client certificate information? >>> You seem suggest that the answer is yes. If so, can you please elaborat= e >>> on why is that? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> >>>> >>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>>> >>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> >>>>>> I did look at RFC7239 when doing that and it could have been made to >>>>>> work but felt the fit wasn't quite right and would have been more >>>>>> cumbersome to use than not. >>>>>> >>>>>> >>>>> Can you elaborate on this? >>>>> These days, with the zero trust model in mind, there are orchestratio= n >>>>> tools, e.g. Istio, that easily allows you to establish an MTLS channe= l >>>>> between the reverse proxy/load balancer/API GW and the backend server= s. >>>>> Why is that not sufficient? >>>>> Which part is cumbersome? >>>>> >>>> >>>> What I meant was only that in the course of writing >>>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to >>>> define HTTP header fields that enable a TLS terminating reverse proxy = to >>>> convey information to a backend server about the validated Token Bindi= ng >>>> Message received from a client, it seemed more straightforward and >>>> sufficient for the use-case to use new HTTP headers to carry the >>>> information rather than to use new fields in the Forwarded header fram= ework >>>> from RFC7239. >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended 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 > --00000000000058fc9505961626b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to Justin's and Brian's comments, I am in= terested to contribute and I will try and be there in person as well
<= div dir=3D"auto">
Hans.

On Tue, Oct 29= , 2019, 22:56 Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
=
+1 to pretty muc= h everything Justin said there.

With some fac= ilitating assistance from Ben it looks like there's now an agenda slot = for this in the upcoming secdispatch meeting in Singapore. I'll attempt= to articulate the situation and see if there's interest in finding a h= ome for the perspective work. Folks that'll be in Singapore and interes= ted in the topic would be encouraged to attend to the secdispatch meeting d= uring the Afternoon Session III 1710-1840 on Tuesday.

<= /div>

On Tue, Oct 29, 2019 at 1:13 PM Justin Richer <jricher@mit.edu>= wrote:
I w= ould argue that making this standard would actually increase the likelihood= of developers getting this right, as now instead of following some copy-pa= sted recipe for NGINX or Apache that they found on the web, they could turn= on a standard setting that would take care of both stripping out incoming = headers and injecting the appropriate values. And all of that can be covere= d in the security considerations with a bunch of normative text on top to m= ake sure inbound headers are stripped. What you=E2=80=99re describing below= is clever, but ultimately it=E2=80=99s just a small bit of obscurity more = than anything real.=C2=A0

The way things are today, you= =E2=80=99ve got to not only pick a header and figure out its format, but al= so do the injection protection step yourself. Since all of these are discon= nected, there are a lot more places that it could fall over. Even a typo wh= ere you throw out incoming =E2=80=9CCLIENT_CERT=E2=80=9D but inject =E2=80= =9CCLIENT_CERTS=E2=80=9D or something like that would be disastrous.=C2=A0<= /div>

All in all, I am in favor of this being defined in= one standard way, in addition to secure communication between proxies and = backends being standardized =E2=80=94 but this latter bit really seems like= a separate problem.

=C2=A0=E2=80=94 Justin

On Oct 28, 2019, at 12:32 PM, Neil Mad= den <neil.madden@forgerock.com> wrote:

While there are some benefits to standardizing headers for this kind o= f communication, there are some significant downsides - particularly when u= sing headers to communicate critical security information like certs. It is= *very* easy to misconfigure a reverse proxy to not strip Forwarded (or wha= tever) headers from incoming requests, allowing a client to simply supply a= certificate as a header without authenticating the TLS connection with the= corresponding private key. One good practice to prevent this is to pick a = random and unguessable header name (configurable per installation) to be us= ed for communicating the certificate, rather than using something fixed and= standard. That way even if you misconfigure the proxy an attacker still ha= s to try and guess the correct header name.

I suppose th= e same thing could be accomplished by having an extension for including a s= hared secret (or HMAC tag) in the header to authenticate it.

-- Neil

On 28 Oct 2019, at 15:32, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
I don't think there= 9;s anything beyond defining something to carry the client certificate info= rmation (including the format and encoding). And it could well be a new RFC= 7239 parameter. Or it might just be a new HTTP header on its own.=C2=A0=C2=A0

On Mon, Oct 28, 2019= at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= br>
Thanks=C2=A0Brian,

I guess my question is: gi= ven RFC7239 and the fact that it is straightforward=C2=A0to secure the chan= nel=C2=A0between the terminating reverse proxy and the backend service in a= cluster, is there anything, from a standard perspective, that we need to d= o beyond defining a new parameter to carry the client certificate informati= on?
You seem suggest that the answer is yes. If so, can you please elab= orate on why is that?

Regards,
=C2=A0Rifaa= t



On Mon, Oct 28, 2019 at 8:42 AM = Brian Campbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com> wrote:

On Fri, Oct 25, 2019 at 3:47 PM B= rian Campbell <bcampbell@pingidentity.com> wrote:

I did look at RFC7239 when doing that and it could have= been made to work but felt the fit wasn't quite right and would have b= een more cumbersome to use than not.=C2=A0=C2=A0


Can you elaborate o= n this?
These days, with the zero trust model in mind, there are = orchestration tools, e.g. Istio, that easily allows you to establish an MTL= S channel between the reverse proxy/load balancer/API GW and the backend se= rvers.
Why is that not sufficient?=C2=A0
Which part= is cumbersome?

What I me= ant was only that in the course of writing=C2=A0https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09,= which aims to define HTTP header fields that enable a TLS terminating reve= rse proxy to convey information to a backend server about the validated Tok= en Binding Message received from a client, it seemed more straightforward a= nd sufficient for the use-case to use new HTTP headers to carry the informa= tion rather than to use new fields in the Forwarded header framework from R= FC7239.=C2=A0 =C2=A0=C2=A0
=C2=A0
<= br>= CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.=C2=A0 If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you.

CONFIDENTIALI= TY NOTICE: This email may contain 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 t= his communication in error, please notify the sender immediately by e-mail = and delete the message and any file attachments from your computer. Thank y= ou.__= _____________________________________________
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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000058fc9505961626b1-- From nobody Wed Oct 30 00:44:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46DF120878 for ; Wed, 30 Oct 2019 00:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, 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 (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 NthdAWfuc2Qs for ; Wed, 30 Oct 2019 00:43:55 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD26120088 for ; Wed, 30 Oct 2019 00:43:54 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id t16so1112691wrr.1 for ; Wed, 30 Oct 2019 00:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=JPbpBcvKrmn5eZTH0zsKjaUUKXnktXq5/u1gbM0R9TU=; b=J01xHTLp2WRN52FleVPVZMMaixnrVR80KHdNDzecPQZZeWKfX2/avMw/394U7qHwYV dX6gV0pRE0QqtM7UoGT2wrU2k2kipaO7qKZesPCzJDmTm7OZ94aZzBl6RovaXyUZNj+t Yac+LKHjZeStztRCQvPDMpKcOAuBV9T9SNPjA= 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=JPbpBcvKrmn5eZTH0zsKjaUUKXnktXq5/u1gbM0R9TU=; b=m/5NYtN3Z7F1sC102C9vWYzKW731CMjSEOTgGrUNp3nHaoQxiGM6K6ngKK7vJ+P4be 41jk4l4BHzKGs9VausVvks0IbSjBoow+WICAAd5dJZ7wxXfdI2nuid4UtUjSZREdlt2n sE4upuY8UEU29os+D9dxiaTFjxZYj6lUXlL46VyDLrvS9y/p/P/s6UyxLgHkiMwrluDv M2FK+vnx7b3SGJnsdpXvCiP7ncZcOuGnui+7Ru+nXRN/PFQkhYzH/yDqvcE63unaTuQt OfyBjiQz0ulzAN3zyfQFvFHwTxCnHxNFE4cLmNyejNKJRX4Y4oi5K48W4KcrqzyrRcRp zcpQ== X-Gm-Message-State: APjAAAVPZwN1z30nuTEB6SJRarjBM+WKBcA5Xu0ePXxFPqs0nNqIO/Rh rWZQYENUkUNTLHETlOVSiGj3cA== X-Google-Smtp-Source: APXvYqyzhreSpw7z6XpzIv7mIWszxTmRwbCTDkvatsxwovZ/lsdY7j0Sp4mder9NqW4rAS2jLfXCJg== X-Received: by 2002:a5d:4208:: with SMTP id n8mr785680wrq.136.1572421433116; Wed, 30 Oct 2019 00:43:53 -0700 (PDT) Received: from ?IPv6:2a01:4c8:1e:73aa:79ca:a0ea:5919:c17b? ([2a01:4c8:1e:73aa:79ca:a0ea:5919:c17b]) by smtp.gmail.com with ESMTPSA id q15sm1494319wrr.82.2019.10.30.00.43.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 00:43:51 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0F24FA45-F540-4269-9891-07ADD36CA4DC Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Wed, 30 Oct 2019 07:43:50 +0000 Message-Id: References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> Cc: Brian Campbell , oauth In-Reply-To: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 07:43:59 -0000 --Apple-Mail-0F24FA45-F540-4269-9891-07ADD36CA4DC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Replies below. > On 29 Oct 2019, at 19:13, Justin Richer wrote: >=20 > =EF=BB=BFI would argue that making this standard would actually increase t= he likelihood of developers getting this right, as now instead of following s= ome copy-pasted recipe for NGINX or Apache that they found on the web, they c= ould turn on a standard setting that would take care of both stripping out i= ncoming headers and injecting the appropriate values. And all of that can be= covered in the security considerations with a bunch of normative text on to= p to make sure inbound headers are stripped. What you=E2=80=99re describing b= elow is clever, but ultimately it=E2=80=99s just a small bit of obscurity mo= re than anything real.=20 Not really. If the header is cryptographically unguessable (eg includes a 12= 8-bit base32-encoded string) then it provides a real security improvement. T= he header name becomes a bearer token effectively. There are many ways that a= reverse proxy can be misconfigured in a way that compromises the security o= f trusted headers: 1. There is the simple misconfiguration where you fail to strip trusted head= ers from incoming requests. For example in HAProxy this is the difference be= tween set-header and add-header directives (and the add-header docs list pas= sing a client cert to the backend as an example use case [1] despite this be= ing insecure). Naive functional testing will still pass, but fairly basic ad= versarial tests would catch this. A standard header/config option might help= with this simple case.=20 2. Scoping issues cause rules to not be applied where you expect them to. Fo= r example, nginx has multiple levels of scope that you can define header rul= es (http, server, location). But if you define *any* proxy_set_header direct= ive at the location level (for example) it will ignore *all* such directives= at the server or http levels, which can cause header-stripping rules to be s= ilently disabled.=20 3. More advanced attacks exploit differences in how individual reverse proxi= es and application servers parse headers to smuggle headers or even whole re= quests past the RP [2].=20 Using unguessable header names for transmitting security-critical informatio= n between the RP and the app server provides an effective defense in depth a= gainst all of these attacks. (They are all forms of confused deputy attack a= nd the unguessable header acts in the same way as an anti-CSRF token to prev= ent these systematically).=20 (I had thought the random header name pattern was widely known, as I=E2=80=99= ve heard it mentioned in conversations several times. But now I come to look= for a definitive reference to it I can only find it mentioned in our own do= cs [3] and connect2id=E2=80=99s [4]).=20 [1]: http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-http-r= equest%20add-header [2]: https://portswigger.net/web-security/request-smuggling [3]: https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provide-mtls-= certs [4]: https://connect2id.com/products/server/docs/guides/tls-proxy=20 >=20 > The way things are today, you=E2=80=99ve got to not only pick a header and= figure out its format, but also do the injection protection step yourself. S= ince all of these are disconnected, there are a lot more places that it coul= d fall over. Even a typo where you throw out incoming =E2=80=9CCLIENT_CERT=E2= =80=9D but inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that woul= d be disastrous.=20 Most load balancers and reverse proxies support some way of setting headers t= hat also strips the incoming header in one directive. Unless the standard ge= ts rid of all the other ways they support to configure this (and removes all= the old Stack Overflow recipes) then it won=E2=80=99t necessarily improve t= hings.=20 A standard that provides an explicit field for including a secret (heck, we c= ould even call it an access token :-) that SHOULD be used might provide a si= gnificant improvement in security.=20 >=20 > All in all, I am in favor of this being defined in one standard way, in ad= dition to secure communication between proxies and backends being standardiz= ed =E2=80=94 but this latter bit really seems like a separate problem. I agree that that is a separate issue.=20 =E2=80=94 Neil >=20 > =E2=80=94 Justin >=20 >>> On Oct 28, 2019, at 12:32 PM, Neil Madden wr= ote: >>>=20 >>> While there are some benefits to standardizing headers for this kind of c= ommunication, there are some significant downsides - particularly when using= headers to communicate critical security information like certs. It is *ver= y* easy to misconfigure a reverse proxy to not strip Forwarded (or whatever)= headers from incoming requests, allowing a client to simply supply a certif= icate as a header without authenticating the TLS connection with the corresp= onding private key. One good practice to prevent this is to pick a random an= d unguessable header name (configurable per installation) to be used for com= municating the certificate, rather than using something fixed and standard. T= hat way even if you misconfigure the proxy an attacker still has to try and g= uess the correct header name. >>>=20 >>> I suppose the same thing could be accomplished by having an extension fo= r including a shared secret (or HMAC tag) in the header to authenticate it. >>>=20 >>> -- Neil >>>=20 >>=20 >>> On 28 Oct 2019, at 15:32, Brian Campbell wrote: >>>=20 >>> I don't think there's anything beyond defining something to carry the cl= ient certificate information (including the format and encoding). And it cou= ld well be a new RFC7239 parameter. Or it might just be a new HTTP header on= its own. =20 >>>=20 >>> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef wrote: >>>> Thanks Brian, >>>>=20 >>>> I guess my question is: given RFC7239 and the fact that it is straightf= orward to secure the channel between the terminating reverse proxy and the b= ackend service in a cluster, is there anything, from a standard perspective,= that we need to do beyond defining a new parameter to carry the client cert= ificate information? >>>> You seem suggest that the answer is yes. If so, can you please elaborat= e on why is that? >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>>=20 >>>>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell wrote: >>>>>=20 >>>>>=20 >>>>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef wrote: >>>>>>=20 >>>>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell wrote: >>>>>>>=20 >>>>>>> I did look at RFC7239 when doing that and it could have been made to= work but felt the fit wasn't quite right and would have been more cumbersom= e to use than not. =20 >>>>>>>=20 >>>>>>=20 >>>>>> Can you elaborate on this? >>>>>> These days, with the zero trust model in mind, there are orchestratio= n tools, e.g. Istio, that easily allows you to establish an MTLS channel bet= ween the reverse proxy/load balancer/API GW and the backend servers. >>>>>> Why is that not sufficient?=20 >>>>>> Which part is cumbersome? >>>>>=20 >>>>> What I meant was only that in the course of writing https://tools.ietf= .org/html/draft-ietf-tokbind-ttrp-09, which aims to define HTTP header field= s that enable a TLS terminating reverse proxy to convey information to a bac= kend server about the validated Token Binding Message received from a client= , it seemed more straightforward and sufficient for the use-case to use new H= TTP headers to carry the information rather than to use new fields in the Fo= rwarded header framework from RFC7239. =20 >>>>> =20 >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-0F24FA45-F540-4269-9891-07ADD36CA4DC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Replies below.

On 29 Oct 2019, at 19:13, Justin Ri= cher <jricher@mit.edu> wrote:

=EF=BB=BFI would argue that making this standard w= ould actually increase the likelihood of developers getting this right, as n= ow instead of following some copy-pasted recipe for NGINX or Apache that the= y found on the web, they could turn on a standard setting that would take ca= re of both stripping out incoming headers and injecting the appropriate valu= es. And all of that can be covered in the security considerations with a bun= ch of normative text on top to make sure inbound headers are stripped. What y= ou=E2=80=99re describing below is clever, but ultimately it=E2=80=99s just a= small bit of obscurity more than anything real. 

Not really. If the header is cryptographically unguessable (= eg includes a 128-bit base32-encoded string) then it provides a real securit= y improvement. The header name becomes a bearer token effectively. There are= many ways that a reverse proxy can be misconfigured in a way that compromis= es the security of trusted headers:

1. There is the= simple misconfiguration where you fail to strip trusted headers from incomi= ng requests. For example in HAProxy this is the difference between set-heade= r and add-header directives (and the add-header docs list passing a client c= ert to the backend as an example use case [1] despite this being insecure). N= aive functional testing will still pass, but fairly basic adversarial tests w= ould catch this. A standard header/config option might help with this simple= case. 

2. Scoping issues cause rules to not b= e applied where you expect them to. For example, nginx has multiple levels o= f scope that you can define header rules (http, server, location). But if yo= u define *any* proxy_set_header directive at the location level (for example= ) it will ignore *all* such directives at the server or http levels, which c= an cause header-stripping rules to be silently disabled. 
3. More advanced attacks exploit differences in how individual r= everse proxies and application servers parse headers to smuggle headers or e= ven whole requests past the RP [2]. 

Using ung= uessable header names for transmitting security-critical information between= the RP and the app server provides an effective defense in depth against al= l of these attacks. (They are all forms of confused deputy attack and the un= guessable header acts in the same way as an anti-CSRF token to prevent these= systematically). 

(I had thought the random h= eader name pattern was widely known, as I=E2=80=99ve heard it mentioned in c= onversations several times. But now I come to look for a definitive referenc= e to it I can only find it mentioned in our own docs [3] and connect2id=E2=80= =99s [4]). 

[4]: https://co= nnect2id.com/products/server/docs/guides/tls-proxy 


The way things are today, you=E2=80=99ve got to not only pick a= header and figure out its format, but also do the injection protection step= yourself. Since all of these are disconnected, there are a lot more places t= hat it could fall over. Even a typo where you throw out incoming =E2=80=9CCL= IENT_CERT=E2=80=9D but inject =E2=80=9CCLIENT_CERTS=E2=80=9D or something li= ke that would be disastrous. 

Most load balancers and reverse proxies support some way of setting heade= rs that also strips the incoming header in one directive. Unless the standar= d gets rid of all the other ways they support to configure this (and removes= all the old Stack Overflow recipes) then it won=E2=80=99t necessarily impro= ve things. 

A standard that provides an explic= it field for including a secret (heck, we could even call it an access token= :-) that SHOULD be used might provide a significant improvement in security= . 

=
All in all, I am in favor of this being= defined in one standard way, in addition to secure communication between pr= oxies and backends being standardized =E2=80=94 but this latter bit really s= eems like a separate problem.

I a= gree that that is a separate issue. 

=E2=80=94= Neil

 =E2=80=94 Justin

On Oct 2= 8, 2019, at 12:32 PM, Neil Madden <neil.madden@forgerock.com> wrote:

While there are some benefits to sta= ndardizing headers for this kind of communication, there are some significan= t downsides - particularly when using headers to communicate critical securi= ty information like certs. It is *very* easy to misconfigure a reverse proxy= to not strip Forwarded (or whatever) headers from incoming requests, allowi= ng a client to simply supply a certificate as a header without authenticatin= g the TLS connection with the corresponding private key. One good practice t= o prevent this is to pick a random and unguessable header name (configurable= per installation) to be used for communicating the certificate, rather than= using something fixed and standard. That way even if you misconfigure the p= roxy an attacker still has to try and guess the correct header name.

I suppose the same thing could b= e accomplished by having an extension for including a shared secret (or HMAC= tag) in the header to authenticate it.

-- Neil
=

On 28 Oct 2019, at 15:32, Bria= n Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:<= /div>
I don't think there's anything beyond de= fining something to carry the client certificate information (including the f= ormat and encoding). And it could well be a new RFC7239 parameter. Or it mig= ht just be a new HTTP header on its own.  

On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thanks Brian,

I guess my question is: given RFC7239 and the fact that it is strai= ghtforward to secure the channel between the terminating reverse p= roxy and the backend service in a cluster, is there anything, from a standar= d perspective, that we need to do beyond defining a new parameter to carry t= he client certificate information?
You seem suggest that the a= nswer is yes. If so, can you please elaborate on why is that?
=

Regards,
 Rifaat



=
On Mon, Oct 28, 2019 at 8:42 AM Brian C= ampbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yuse= f <= rifaat.ietf@gmail.com> wrote:

On Fri, Oct 25,= 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com> wrote:=
<= div dir=3D"ltr" class=3D"">
I did look at RFC7= 239 when doing that and it could have been made to work but felt the fit was= n't quite right and would have been more cumbersome to use than not.  


Can you elaborate on this?
These days, with the zero trust model in mind, there are orchestration to= ols, e.g. Istio, that easily allows you to establish an MTLS channel between= the reverse proxy/load balancer/API GW and the backend servers.
Why is that not sufficient? 
Which part is cumbersome?
<= br class=3D"">
What I meant was only that in the course= of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims= to define HTTP header fields that enable a TLS terminating reverse proxy to= convey information to a backend server about the validated Token Binding Me= ssage received from a client, it seemed more straightforward and sufficient f= or the use-case to use new HTTP headers to carry the information rather than= to use new fields in the Forwarded header framework from RFC7239.  &nb= sp; 
=  

CONFIDENTIALITY NOTICE: T= his email may contain confidential and privileged material for the sole use o= f the intended recipient(s). Any review, use, distribution or disclosure by o= thers is strictly prohibited.  If you have received this communication i= n error, please notify the sender immediately by e-mail and delete the messa= ge and any file attachments from your computer. Thank you.=

CONFIDENTIALITY NOTICE: This email may con= tain confidential and privileged material for the sole use of the intended r= ecipient(s). Any review, use, distribution or disclosure by others is strict= ly prohibited..  If you have received this communication in error, plea= se notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.________= _______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-0F24FA45-F540-4269-9891-07ADD36CA4DC-- From nobody Wed Oct 30 06:24:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778712006F for ; Wed, 30 Oct 2019 06:24:40 -0700 (PDT) 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 Yk9CBO7hyPiC for ; Wed, 30 Oct 2019 06:24:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF39D12081A for ; Wed, 30 Oct 2019 06:24:37 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9UDOXFh004635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 09:24:34 -0400 From: Justin Richer Message-Id: <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_37D00C09-41F8-45E7-A039-D644BD13BB2D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 30 Oct 2019 09:24:32 -0400 In-Reply-To: Cc: Brian Campbell , oauth To: Neil Madden References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 13:24:40 -0000 --Apple-Mail=_37D00C09-41F8-45E7-A039-D644BD13BB2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. And one of the best things about a standard is that you=E2=80=99re still = free to completely ignore it if you want to, so people can and will keep = following whatever proprietary patterns they want to. But at least a = standard mechanism would give us a way to say to newcomers and veterans = alike =E2=80=9CNo really, here=E2=80=99s a way that we all agree works = and has these properties=E2=80=9D.=20 =E2=80=94 Justin > On Oct 30, 2019, at 3:43 AM, Neil Madden = wrote: >=20 > Replies below. >=20 >> On 29 Oct 2019, at 19:13, Justin Richer wrote: >>=20 >> =EF=BB=BFI would argue that making this standard would actually = increase the likelihood of developers getting this right, as now instead = of following some copy-pasted recipe for NGINX or Apache that they found = on the web, they could turn on a standard setting that would take care = of both stripping out incoming headers and injecting the appropriate = values. And all of that can be covered in the security considerations = with a bunch of normative text on top to make sure inbound headers are = stripped. What you=E2=80=99re describing below is clever, but ultimately = it=E2=80=99s just a small bit of obscurity more than anything real.=20 >=20 > Not really. If the header is cryptographically unguessable (eg = includes a 128-bit base32-encoded string) then it provides a real = security improvement. The header name becomes a bearer token = effectively. There are many ways that a reverse proxy can be = misconfigured in a way that compromises the security of trusted headers: >=20 > 1. There is the simple misconfiguration where you fail to strip = trusted headers from incoming requests. For example in HAProxy this is = the difference between set-header and add-header directives (and the = add-header docs list passing a client cert to the backend as an example = use case [1] despite this being insecure). Naive functional testing will = still pass, but fairly basic adversarial tests would catch this. A = standard header/config option might help with this simple case.=20 >=20 > 2. Scoping issues cause rules to not be applied where you expect them = to. For example, nginx has multiple levels of scope that you can define = header rules (http, server, location). But if you define *any* = proxy_set_header directive at the location level (for example) it will = ignore *all* such directives at the server or http levels, which can = cause header-stripping rules to be silently disabled.=20 >=20 > 3. More advanced attacks exploit differences in how individual reverse = proxies and application servers parse headers to smuggle headers or even = whole requests past the RP [2].=20 >=20 > Using unguessable header names for transmitting security-critical = information between the RP and the app server provides an effective = defense in depth against all of these attacks. (They are all forms of = confused deputy attack and the unguessable header acts in the same way = as an anti-CSRF token to prevent these systematically).=20 >=20 > (I had thought the random header name pattern was widely known, as = I=E2=80=99ve heard it mentioned in conversations several times. But now = I come to look for a definitive reference to it I can only find it = mentioned in our own docs [3] and connect2id=E2=80=99s [4]).=20 >=20 > [1]: = http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-http-requ= est%20add-header = > [2]: https://portswigger.net/web-security/request-smuggling = > [3]: = https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provide-mtls-cer= ts = [4]: https://connect2id.com/products/server/docs/guides/tls-proxy = =20 >=20 >>=20 >> The way things are today, you=E2=80=99ve got to not only pick a = header and figure out its format, but also do the injection protection = step yourself. Since all of these are disconnected, there are a lot more = places that it could fall over. Even a typo where you throw out incoming = =E2=80=9CCLIENT_CERT=E2=80=9D but inject =E2=80=9CCLIENT_CERTS=E2=80=9D = or something like that would be disastrous.=20 >=20 > Most load balancers and reverse proxies support some way of setting = headers that also strips the incoming header in one directive. Unless = the standard gets rid of all the other ways they support to configure = this (and removes all the old Stack Overflow recipes) then it won=E2=80=99= t necessarily improve things.=20 >=20 > A standard that provides an explicit field for including a secret = (heck, we could even call it an access token :-) that SHOULD be used = might provide a significant improvement in security.=20 >=20 >>=20 >> All in all, I am in favor of this being defined in one standard way, = in addition to secure communication between proxies and backends being = standardized =E2=80=94 but this latter bit really seems like a separate = problem. >=20 > I agree that that is a separate issue.=20 >=20 > =E2=80=94 Neil >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 28, 2019, at 12:32 PM, Neil Madden > wrote: >>>=20 >>> While there are some benefits to standardizing headers for this kind = of communication, there are some significant downsides - particularly = when using headers to communicate critical security information like = certs. It is *very* easy to misconfigure a reverse proxy to not strip = Forwarded (or whatever) headers from incoming requests, allowing a = client to simply supply a certificate as a header without authenticating = the TLS connection with the corresponding private key. One good practice = to prevent this is to pick a random and unguessable header name = (configurable per installation) to be used for communicating the = certificate, rather than using something fixed and standard. That way = even if you misconfigure the proxy an attacker still has to try and = guess the correct header name. >>>=20 >>> I suppose the same thing could be accomplished by having an = extension for including a shared secret (or HMAC tag) in the header to = authenticate it. >>>=20 >>> -- Neil >>>=20 >>>> On 28 Oct 2019, at 15:32, Brian Campbell = > wrote: >>>>=20 >>>> I don't think there's anything beyond defining something to carry = the client certificate information (including the format and encoding). = And it could well be a new RFC7239 parameter. Or it might just be a new = HTTP header on its own. =20 >>>>=20 >>>> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef = > wrote: >>>> Thanks Brian, >>>>=20 >>>> I guess my question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating reverse = proxy and the backend service in a cluster, is there anything, from a = standard perspective, that we need to do beyond defining a new parameter = to carry the client certificate information? >>>> You seem suggest that the answer is yes. If so, can you please = elaborate on why is that? >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell = > wrote: >>>>=20 >>>>=20 >>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef = > wrote: >>>>=20 >>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell = > wrote: >>>>=20 >>>> I did look at RFC7239 when doing that and it could have been made = to work but felt the fit wasn't quite right and would have been more = cumbersome to use than not. =20 >>>>=20 >>>>=20 >>>> Can you elaborate on this? >>>> These days, with the zero trust model in mind, there are = orchestration tools, e.g. Istio, that easily allows you to establish an = MTLS channel between the reverse proxy/load balancer/API GW and the = backend servers. >>>> Why is that not sufficient?=20 >>>> Which part is cumbersome? >>>>=20 >>>> What I meant was only that in the course of writing = https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09 = , which aims to = define HTTP header fields that enable a TLS terminating reverse proxy to = convey information to a backend server about the validated Token Binding = Message received from a client, it seemed more straightforward and = sufficient for the use-case to use new HTTP headers to carry the = information rather than to use new fields in the Forwarded header = framework from RFC7239. =20 >>>> =20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>=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 >>=20 --Apple-Mail=_37D00C09-41F8-45E7-A039-D644BD13BB2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All = of these problems can be solved, and I think solved better, by securing = the connection between the proxy and the back-end. That way the back end = will be able look not only for a specific header, but verify that the = header came from the proxy itself. An obscure header name is one way to = do that, but it has a lot of issues with it, especially since it=E2=80=99s= likely to be selected once during set-up and never changed throughout = the lifetime of the deployment. I think there are likely much better = solutions here, and they=E2=80=99d address this issue without things = getting weird.

And = one of the best things about a standard is that you=E2=80=99re still = free to completely ignore it if you want to, so people can and will keep = following whatever proprietary patterns they want to. But at least a = standard mechanism would give us a way to say to newcomers and veterans = alike =E2=80=9CNo really, here=E2=80=99s a way that we all agree works = and has these properties=E2=80=9D. 
 =E2=80=94 Justin

On Oct 30, 2019, at 3:43 AM, Neil Madden <neil.madden@forgerock.com> wrote:

Replies below.

On 29 Oct 2019, at = 19:13, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFI would argue that making this standard = would actually increase the likelihood of developers getting this right, = as now instead of following some copy-pasted recipe for NGINX or Apache = that they found on the web, they could turn on a standard setting that = would take care of both stripping out incoming headers and injecting the = appropriate values. And all of that can be covered in the security = considerations with a bunch of normative text on top to make sure = inbound headers are stripped. What you=E2=80=99re describing below is = clever, but ultimately it=E2=80=99s just a small bit of obscurity more = than anything real. 

Not really. If the header is = cryptographically unguessable (eg includes a 128-bit base32-encoded = string) then it provides a real security improvement. The header name = becomes a bearer token effectively. There are many ways that a reverse = proxy can be misconfigured in a way that compromises the security of = trusted headers:

1. There is the simple misconfiguration where you fail to = strip trusted headers from incoming requests. For example in HAProxy = this is the difference between set-header and add-header directives (and = the add-header docs list passing a client cert to the backend as an = example use case [1] despite this being insecure). Naive functional = testing will still pass, but fairly basic adversarial tests would catch = this. A standard header/config option might help with this simple = case. 

2. = Scoping issues cause rules to not be applied where you expect them to. = For example, nginx has multiple levels of scope that you can define = header rules (http, server, location). But if you define *any* = proxy_set_header directive at the location level (for example) it will = ignore *all* such directives at the server or http levels, which can = cause header-stripping rules to be silently disabled. 

3. More advanced attacks = exploit differences in how individual reverse proxies and application = servers parse headers to smuggle headers or even whole requests past the = RP [2]. 

Using unguessable header names for transmitting = security-critical information between the RP and the app server provides = an effective defense in depth against all of these attacks. (They are = all forms of confused deputy attack and the unguessable header acts in = the same way as an anti-CSRF token to prevent these = systematically). 

(I had thought the random header name pattern was widely = known, as I=E2=80=99ve heard it mentioned in conversations several = times. But now I come to look for a definitive reference to it I can = only find it mentioned in our own docs [3] and connect2id=E2=80=99s = [4]). 

[1]: http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.= 2-http-request%20add-header
[2]: https://portswigger.net/web-security/request-smuggling
[3]: https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provi= de-mtls-certs
[4]: https://connect2id.com/products/server/docs/guides/tls-proxy 


The way things are today, you=E2=80=99ve = got to not only pick a header and figure out its format, but also do the = injection protection step yourself. Since all of these are disconnected, = there are a lot more places that it could fall over. Even a typo where = you throw out incoming =E2=80=9CCLIENT_CERT=E2=80=9D but inject = =E2=80=9CCLIENT_CERTS=E2=80=9D or something like that would be = disastrous. 

Most load balancers and reverse proxies = support some way of setting headers that also strips the incoming header = in one directive. Unless the standard gets rid of all the other ways = they support to configure this (and removes all the old Stack Overflow = recipes) then it won=E2=80=99t necessarily improve = things. 

A = standard that provides an explicit field for including a secret (heck, = we could even call it an access token :-) that SHOULD be used might = provide a significant improvement in security. 


All in = all, I am in favor of this being defined in one standard way, in = addition to secure communication between proxies and backends being = standardized =E2=80=94 but this latter bit really seems like a separate = problem.

I agree that that is a separate issue. 

=E2=80=94 Neil


 =E2=80= =94 Justin

On Oct 28, 2019, at 12:32 PM, = Neil Madden <neil.madden@forgerock.com> wrote:

While there are some benefits = to standardizing headers for this kind of communication, there are some = significant downsides - particularly when using headers to communicate = critical security information like certs. It is *very* easy to = misconfigure a reverse proxy to not strip Forwarded (or whatever) = headers from incoming requests, allowing a client to simply supply a = certificate as a header without authenticating the TLS connection with = the corresponding private key. One good practice to prevent this is to = pick a random and unguessable header name (configurable per = installation) to be used for communicating the certificate, rather than = using something fixed and standard. That way even if you misconfigure = the proxy an attacker still has to try and guess the correct header = name.

I suppose the = same thing could be accomplished by having an extension for including a = shared secret (or HMAC tag) in the header to authenticate it.

-- Neil

On 28 Oct 2019, at 15:32, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I don't think there's anything beyond defining = something to carry the client certificate information (including the = format and encoding). And it could well be a new RFC7239 parameter. Or = it might just be a new HTTP header on its own.  

On Mon, = Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thanks Brian,

I guess my = question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating = reverse proxy and the backend service in a cluster, is there anything, = from a standard perspective, that we need to do beyond defining a new = parameter to carry the client certificate information?
You = seem suggest that the answer is yes. If so, can you please elaborate on = why is that?

Regards,
 Rifaat



On Mon, Oct = 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com> wrote:


On Sat, Oct 26, 2019 at 3:55 PM Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

On Fri, Oct = 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

I did look at RFC7239 when doing that and it could have been = made to work but felt the fit wasn't quite right and would have been = more cumbersome to use than not.  


Can you elaborate on = this?
These days, with the zero trust model in = mind, there are orchestration tools, e.g. Istio, that easily allows you = to establish an MTLS channel between the reverse proxy/load balancer/API = GW and the backend servers.
Why is = that not sufficient? 
Which part is = cumbersome?

What I meant was only that in the = course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, = which aims to define HTTP header fields that enable a TLS terminating = reverse proxy to convey information to a backend server about the = validated Token Binding Message received from a client, it seemed more = straightforward and sufficient for the use-case to use new HTTP headers = to carry the information rather than to use new fields in the Forwarded = header framework from RFC7239.    
 

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this 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

<= br class=3D"">
= --Apple-Mail=_37D00C09-41F8-45E7-A039-D644BD13BB2D-- From nobody Wed Oct 30 06:46:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAAB120A19 for ; Wed, 30 Oct 2019 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 PST6J70RUUDd for ; Wed, 30 Oct 2019 06:46:45 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.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 A935D120A3A for ; Wed, 30 Oct 2019 06:46:43 -0700 (PDT) Received: from [80.187.103.147] (helo=[172.20.10.2]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iPoIm-0003x1-6o; Wed, 30 Oct 2019 14:46:36 +0100 From: Torsten Lodderstedt Message-Id: <7874B7EA-7310-46CD-99A7-F639FB3B6F8B@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_F7518842-D78C-42F7-B54F-CFD329AF93A0"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 30 Oct 2019 14:46:05 +0100 In-Reply-To: <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> Cc: Neil Madden , Brian Campbell , oauth To: Justin Richer References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> X-Mailer: Apple Mail (2.3601.0.10) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 13:46:49 -0000 --Apple-Mail=_F7518842-D78C-42F7-B54F-CFD329AF93A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On 30. Oct 2019, at 14:24, Justin Richer wrote: >=20 > All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. >=20 > And one of the best things about a standard is that you=E2=80=99re = still free to completely ignore it if you want to, so people can and = will keep following whatever proprietary patterns they want to. But at = least a standard mechanism would give us a way to say to newcomers and = veterans alike =E2=80=9CNo really, here=E2=80=99s a way that we all = agree works and has these properties=E2=80=9D.=20 >=20 > =E2=80=94 Justin >=20 >> On Oct 30, 2019, at 3:43 AM, Neil Madden = wrote: >>=20 >> Replies below. >>=20 >>> On 29 Oct 2019, at 19:13, Justin Richer wrote: >>>=20 >>> =EF=BB=BFI would argue that making this standard would actually = increase the likelihood of developers getting this right, as now instead = of following some copy-pasted recipe for NGINX or Apache that they found = on the web, they could turn on a standard setting that would take care = of both stripping out incoming headers and injecting the appropriate = values. And all of that can be covered in the security considerations = with a bunch of normative text on top to make sure inbound headers are = stripped. What you=E2=80=99re describing below is clever, but ultimately = it=E2=80=99s just a small bit of obscurity more than anything real.=20 >>=20 >> Not really. If the header is cryptographically unguessable (eg = includes a 128-bit base32-encoded string) then it provides a real = security improvement. The header name becomes a bearer token = effectively. There are many ways that a reverse proxy can be = misconfigured in a way that compromises the security of trusted headers: >>=20 >> 1. There is the simple misconfiguration where you fail to strip = trusted headers from incoming requests. For example in HAProxy this is = the difference between set-header and add-header directives (and the = add-header docs list passing a client cert to the backend as an example = use case [1] despite this being insecure). Naive functional testing will = still pass, but fairly basic adversarial tests would catch this. A = standard header/config option might help with this simple case.=20 >>=20 >> 2. Scoping issues cause rules to not be applied where you expect them = to. For example, nginx has multiple levels of scope that you can define = header rules (http, server, location). But if you define *any* = proxy_set_header directive at the location level (for example) it will = ignore *all* such directives at the server or http levels, which can = cause header-stripping rules to be silently disabled.=20 >>=20 >> 3. More advanced attacks exploit differences in how individual = reverse proxies and application servers parse headers to smuggle headers = or even whole requests past the RP [2].=20 >>=20 >> Using unguessable header names for transmitting security-critical = information between the RP and the app server provides an effective = defense in depth against all of these attacks. (They are all forms of = confused deputy attack and the unguessable header acts in the same way = as an anti-CSRF token to prevent these systematically).=20 >>=20 >> (I had thought the random header name pattern was widely known, as = I=E2=80=99ve heard it mentioned in conversations several times. But now = I come to look for a definitive reference to it I can only find it = mentioned in our own docs [3] and connect2id=E2=80=99s [4]).=20 >>=20 >> [1]: = http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-http-requ= est%20add-header >> [2]: https://portswigger.net/web-security/request-smuggling >> [3]: = https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provide-mtls-cer= ts >> [4]: https://connect2id.com/products/server/docs/guides/tls-proxy=20 >>=20 >>>=20 >>> The way things are today, you=E2=80=99ve got to not only pick a = header and figure out its format, but also do the injection protection = step yourself. Since all of these are disconnected, there are a lot more = places that it could fall over. Even a typo where you throw out incoming = =E2=80=9CCLIENT_CERT=E2=80=9D but inject =E2=80=9CCLIENT_CERTS=E2=80=9D = or something like that would be disastrous.=20 >>=20 >> Most load balancers and reverse proxies support some way of setting = headers that also strips the incoming header in one directive. Unless = the standard gets rid of all the other ways they support to configure = this (and removes all the old Stack Overflow recipes) then it won=E2=80=99= t necessarily improve things.=20 >>=20 >> A standard that provides an explicit field for including a secret = (heck, we could even call it an access token :-) that SHOULD be used = might provide a significant improvement in security.=20 >>=20 >>>=20 >>> All in all, I am in favor of this being defined in one standard way, = in addition to secure communication between proxies and backends being = standardized =E2=80=94 but this latter bit really seems like a separate = problem. >>=20 >> I agree that that is a separate issue.=20 >>=20 >> =E2=80=94 Neil >>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Oct 28, 2019, at 12:32 PM, Neil Madden = wrote: >>>>=20 >>>> While there are some benefits to standardizing headers for this = kind of communication, there are some significant downsides - = particularly when using headers to communicate critical security = information like certs. It is *very* easy to misconfigure a reverse = proxy to not strip Forwarded (or whatever) headers from incoming = requests, allowing a client to simply supply a certificate as a header = without authenticating the TLS connection with the corresponding private = key. One good practice to prevent this is to pick a random and = unguessable header name (configurable per installation) to be used for = communicating the certificate, rather than using something fixed and = standard. That way even if you misconfigure the proxy an attacker still = has to try and guess the correct header name. >>>>=20 >>>> I suppose the same thing could be accomplished by having an = extension for including a shared secret (or HMAC tag) in the header to = authenticate it. >>>>=20 >>>> -- Neil >>>>=20 >>>>> On 28 Oct 2019, at 15:32, Brian Campbell = wrote: >>>>>=20 >>>>> I don't think there's anything beyond defining something to carry = the client certificate information (including the format and encoding). = And it could well be a new RFC7239 parameter. Or it might just be a new = HTTP header on its own. =20 >>>>>=20 >>>>> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef = wrote: >>>>> Thanks Brian, >>>>>=20 >>>>> I guess my question is: given RFC7239 and the fact that it is = straightforward to secure the channel between the terminating reverse = proxy and the backend service in a cluster, is there anything, from a = standard perspective, that we need to do beyond defining a new parameter = to carry the client certificate information? >>>>> You seem suggest that the answer is yes. If so, can you please = elaborate on why is that? >>>>>=20 >>>>> Regards, >>>>> Rifaat >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell = wrote: >>>>>=20 >>>>>=20 >>>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef = wrote: >>>>>=20 >>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell = wrote: >>>>>=20 >>>>> I did look at RFC7239 when doing that and it could have been made = to work but felt the fit wasn't quite right and would have been more = cumbersome to use than not. =20 >>>>>=20 >>>>>=20 >>>>> Can you elaborate on this? >>>>> These days, with the zero trust model in mind, there are = orchestration tools, e.g. Istio, that easily allows you to establish an = MTLS channel between the reverse proxy/load balancer/API GW and the = backend servers. >>>>> Why is that not sufficient?=20 >>>>> Which part is cumbersome? >>>>>=20 >>>>> What I meant was only that in the course of writing = https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to = define HTTP header fields that enable a TLS terminating reverse proxy to = convey information to a backend server about the validated Token Binding = Message received from a client, it seemed more straightforward and = sufficient for the use-case to use new HTTP headers to carry the = information rather than to use new fields in the Forwarded header = framework from RFC7239. =20 >>>>> =20 >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F7518842-D78C-42F7-B54F-CFD329AF93A0 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 Fw0xOTEwMzAxMzQ2MDVaMC8GCSqGSIb3DQEJBDEiBCC8IU5IVpzg1/KnP03pIyeELWhTdmDGG0zl rj4Y1Zf1azCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAEhMB8KBlNZN0T0Dt5JTvv1Me4x1sFA5LJJA9Zm786h6s4dKXqJbIHghhD+t 4umdMoxacYCzhDqU96Ge0JxQgV7KAqclSolZLNvSkGWcAWYzJJW7rXt6VJBdoP5KAPiYCHsEoVhb BK1BG5jvtqttYfFyJpCBW2ZSmHIZcjmc0NjPl3MVjDT6cqTZwLoqTERzGLe7IXwbdUsw9yxju7cA jGvNpCx+7hAQBLzrYvqd5I6Q4KdhDdKrq4wcYCle6uxxrcrfx/D7eccsQzgcFSUNaIsLAJgoHcXx PMNjYtKIgBSFCviXblKNy5+21KYx5lf0P5A9lKvh8tp0StP68ueYnYUAAAAAAAA= --Apple-Mail=_F7518842-D78C-42F7-B54F-CFD329AF93A0-- From nobody Wed Oct 30 06:57:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5816D1200DE for ; Wed, 30 Oct 2019 06:57:00 -0700 (PDT) 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 WEBQ_pYKhnkU for ; Wed, 30 Oct 2019 06:56:58 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461A0120112 for ; Wed, 30 Oct 2019 06:56:58 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id e6so581749wrw.1 for ; Wed, 30 Oct 2019 06:56:58 -0700 (PDT) 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=b5jJphLtmg2ct2t5Y7i47pSCbt8a7aysVosXPEk0B/I=; b=XrDq/00VAWvcHvosHzUuNfjs3Z5y/EjBtWkbr6nhJCG9IB1LYOfOvNdvBnYCqxRFAh moGbZbzM26pVC4aTHJpJNJzpTQPA3PSfyTdtF39rMs6Hzf6d4VjA1vc2k8oaOUZYeUXs 3vdNB+BsBDUA9sqvctAr6Jio7f5+4aUA+8inA= 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=b5jJphLtmg2ct2t5Y7i47pSCbt8a7aysVosXPEk0B/I=; b=BW/wC9B/cBrU5IVDWwpBCgmdZYvYPKZLsxN2Sa2AXTX5x/bCCsogZ3YRRRuBwLN6xT w+IImMQoZLjo24NhQkXNNNKNgqE73xxXyG0WhpPH33hjfND3hSA55JNd4xI17gw5/m74 TP6f9uGqAZACTUOialOGz/IaBnmdbscorhHEUKtHoJRqhvrY7k8k39oLXx7NP5Ql908t Gw0mRDBPYfdvdGkc9roA2QnE5sugrAzfhEZ18ECF3dKuWzXkWHeL5FEx/IHoDkUsMbst dOlHHdc06t9f7aFoGk0aLB81cvC3+zuhd1Gw9Xc/3Kwj8AzaWrnkB2jLP11u5jB26eIj mgOg== X-Gm-Message-State: APjAAAU5XEBTb/EiNmNHz4MiOComuk6VzxjL7qPLyIJIZSCmzHfRIBW1 Y/sHFO5iUE7pqQVyug8GrvAQTQ== X-Google-Smtp-Source: APXvYqzyU3ZBLt/Wm5iOYKnhJjm05pVFnQroiyVm8cM6Iq1qvdwLVNbbkRLeDxIajUS1rGmSu9tTDw== X-Received: by 2002:adf:fbc4:: with SMTP id d4mr6941683wrs.265.1572443816587; Wed, 30 Oct 2019 06:56:56 -0700 (PDT) Received: from [192.168.2.134] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id u10sm161808wmj.0.2019.10.30.06.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 06:56:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Neil Madden In-Reply-To: <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> Date: Wed, 30 Oct 2019 13:56:54 +0000 Cc: Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 13:57:00 -0000 On 30 Oct 2019, at 13:24, Justin Richer wrote: >=20 > All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. The issue has nothing to do with the security of the connection between = the proxy and the backend. It is to do with data origin authentication = of the headers themselves. All of the headers arrive at the backend over = the same connection, but only some of them were created by the proxy. = There are undoubtedly better alternatives - e.g. using a shared secret = to compute a HMAC over security sensitive headers and include that as an = additional header or field. But an unguessable header name is *simple* = and effective and works right now with widely implemented functionality.=20= There's no need for the header name to ever change - the secret is not = exposed to untrusted parties and is a defense-in-depth rather than a = primary defense. I also don't know why you consider this a "weird" = solution - it's a simple pragmatic solution to a fairly widespread class = of security vulnerabilities. It also has the benefit that it forces the = backend to "validate" the secret, because it won't find the header if it = gets it wrong, whereas it is much easier to forget to validate a HMAC = tag. I'll take simple and weird over missing and broken any day. >=20 > And one of the best things about a standard is that you=E2=80=99re = still free to completely ignore it if you want to, so people can and = will keep following whatever proprietary patterns they want to. But at = least a standard mechanism would give us a way to say to newcomers and = veterans alike =E2=80=9CNo really, here=E2=80=99s a way that we all = agree works and has these properties=E2=80=9D.=20 I'm not arguing against a standard, just against a standard that makes = it harder to mitigate known security vulnerabilities. -- Neil= From nobody Wed Oct 30 07:05:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2572A120130 for ; Wed, 30 Oct 2019 07:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Gr_sVojNh701 for ; Wed, 30 Oct 2019 07:05:52 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A300A1200F3 for ; Wed, 30 Oct 2019 07:05:52 -0700 (PDT) Received: from [80.187.103.147] (helo=[172.20.10.2]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iPobd-0004O7-DT; Wed, 30 Oct 2019 15:05:49 +0100 From: Torsten Lodderstedt Message-Id: <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_1802A977-F8B1-4B33-8F12-3B5590397B9F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 30 Oct 2019 15:05:48 +0100 In-Reply-To: <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> Cc: Justin Richer , Brian Campbell , oauth To: Neil Madden References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> X-Mailer: Apple Mail (2.3601.0.10) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:05:55 -0000 --Apple-Mail=_1802A977-F8B1-4B33-8F12-3B5590397B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30. Oct 2019, at 14:56, Neil Madden = wrote: >=20 > On 30 Oct 2019, at 13:24, Justin Richer wrote: >>=20 >> All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. >=20 > The issue has nothing to do with the security of the connection = between the proxy and the backend. It is to do with data origin = authentication of the headers themselves. All of the headers arrive at = the backend over the same connection, but only some of them were created = by the proxy. There are undoubtedly better alternatives - e.g. using a = shared secret to compute a HMAC over security sensitive headers and = include that as an additional header or field. But an unguessable header = name is *simple* and effective and works right now with widely = implemented functionality.=20 >=20 > There's no need for the header name to ever change - the secret is not = exposed to untrusted parties If the proxy sends certs via an header X to service A and B and someone = impersonates A it will find out the secret and use it to inject certs in = a connection towards B. We have learned that it is sometime hard to use = different secret header names for the same purpose with different = request targets. In those cases, a way to authenticate the proxy might = by a good solution. =20 > and is a defense-in-depth rather than a primary defense. I also don't = know why you consider this a "weird" solution - it's a simple pragmatic = solution to a fairly widespread class of security vulnerabilities. It = also has the benefit that it forces the backend to "validate" the = secret, because it won't find the header if it gets it wrong, whereas it = is much easier to forget to validate a HMAC tag. I'll take simple and = weird over missing and broken any day. >=20 >>=20 >> And one of the best things about a standard is that you=E2=80=99re = still free to completely ignore it if you want to, so people can and = will keep following whatever proprietary patterns they want to. But at = least a standard mechanism would give us a way to say to newcomers and = veterans alike =E2=80=9CNo really, here=E2=80=99s a way that we all = agree works and has these properties=E2=80=9D.=20 >=20 > I'm not arguing against a standard, just against a standard that makes = it harder to mitigate known security vulnerabilities. >=20 > -- Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1802A977-F8B1-4B33-8F12-3B5590397B9F 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 Fw0xOTEwMzAxNDA1NDhaMC8GCSqGSIb3DQEJBDEiBCA1hk8fIjgBXbqxGsvANTj3ynqz9y+6fzcz hHnEQ/2PPjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALAOnl4D7DLL2rVS1/30LvYN1rFNY60agUVUomJx/CQ76GX9Mbz9V6IK/NXb gCizK6bSPkf9sg6rHWtlMjuw1umxkaaMh2EehFuS6yYFQUVx16nUZ6lxwl+VWsJFr+q45I0pI9l3 l/EiShRp9hzTXghV/kHakEqRaQP2hwOlHhjIzWEeBjj87IdyfAVqLOc+hIXSzvP4wdgNZfRme2lH YmdNT1FE/asoxsS1eTWCdMq8+sVVPuGSZwWnKO5Hr8YY7c71RDof/LiRmLezRq66SukY5eM66fWv qXeBPI3Am+g/dMKp1H/wgDCXsIa867x3TheNUDG8Qchw79UqKdM7xGYAAAAAAAA= --Apple-Mail=_1802A977-F8B1-4B33-8F12-3B5590397B9F-- From nobody Wed Oct 30 07:07:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC1120BDC for ; Wed, 30 Oct 2019 07:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF76wl-ov-HT for ; Wed, 30 Oct 2019 07:07:42 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 94948120B60 for ; Wed, 30 Oct 2019 07:07:41 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9UE6lri031165; Wed, 30 Oct 2019 14:07:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QIt0vsytREflTee+YzYCs0nbl3y3pfXvvh13A0OLIRI=; b=dH7zN7OdeSedcx5dcMe/qjBWFzcoYz1B6BN+jiWiOW6InzrwFT6QVHjK+FauzUIaPArL 5MD+/XAedu6yGdsyx8XRadOtKDMbg1SA8g6UhZcBfDYSIeRwef2YTbORxuHXoyQkcYUE FVSCs+UZVM1vJ5GivA3+R9xi4ymOZGeu9kqdxz6sguexnvx0xwv2yYeKrsgCBFaRl2Op nuxE24y0kgumkND/0IBlco7aO8l+PwcKmB9i4AjCoor/cJ1xk3YzbwCDLOiYen0QCGR9 qgF3aHpu1OkHSiHAIf/8Eo3a4WSx4NljWnI4AG4QuOjgE63tTvwqj140dZ8EsW0217xn fg== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vxwgjkfv8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 14:07:36 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9UE2h1k021787; Wed, 30 Oct 2019 10:07:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint6.akamai.com with ESMTP id 2vxwfn12sd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 10:07:35 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 10:07:34 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 10:07:34 -0400 From: "Salz, Rich" To: Neil Madden , Justin Richer CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAA0ZsAgABfMACAAAkLAP//v+yA Date: Wed, 30 Oct 2019 14:07:33 +0000 Message-ID: <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> In-Reply-To: <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.207] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=813 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910300134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_06:2019-10-30,2019-10-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=797 clxscore=1011 lowpriorityscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910300135 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:07:47 -0000 PiBCdXQgYW4gdW5ndWVzc2FibGUgaGVhZGVyIG5hbWUgaXMgKnNpbXBsZSogYW5kIGVmZmVjdGl2 ZSBhbmQgd29ya3MgcmlnaHQgbm93IHdpdGggd2lkZWx5IGltcGxlbWVudGVkIGZ1bmN0aW9uYWxp dHkuIA0KDQpZb3UgbWVhbiBsaWtlIGFkbWluL2FkbWluIGZvciBhZG1pbmlzdHJhdG9yIGFjY2Vz cz8gIFRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gdW5ndWVzc2FibGUgbmFtZS4gWW91IGNs YWltIHRoZSBuYW1lIHdpbGwgbmV2ZXIgYmUgZXhwb3NlZCB0byB1bnRydXN0ZWQgcGFydGllcy4g IEhvdyBzbz8gIFlvdSBhcmUgbm93IHRlbGxpbmcgYWRtaW5pc3RyYXRvcnMgdG8gdHJlYXQgYSAq bmFtZSogYXMgc2VjdXJlbHkgYXMgdGhleSB0cmVhdCBhICprZXkqIChvciBwYXNzd29yZCkuICBJ ZiBpdCBtdXN0IGJlIHByb3RlY3RlZCBsaWtlIGtleSBtYXRlcmlhbCwgdGhlbiB1c2UgaXQgbGlr ZSBrZXkgbWF0ZXJpYWwuDQoNClRoZSBwcm94eS1iYWNrZW5kIHNob3VsZCBiZSBUTFMsIGlkZWFs bHkgYXV0aGVudGljYXRpbmcgdGhlIHByb3h5Lg0KIA0KDQo= From nobody Wed Oct 30 07:15:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259C120A36 for ; Wed, 30 Oct 2019 07:15:44 -0700 (PDT) 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 Yy0vCjWwAdNP for ; Wed, 30 Oct 2019 07:15:42 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE86A120077 for ; Wed, 30 Oct 2019 07:15:41 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id p4so2484900wrm.8 for ; Wed, 30 Oct 2019 07:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UHF7aR45aNy7YK+dechnPFv21wn6Gw/WR2znco84WYk=; b=cUQyV0U3g0EGUlBzF4HdqRZ5yvv2GMGxLmESJb7f4kfGSdjlgAJRugP6wDjMZkjKsy ELBHhpnaBTOoK/Ty88WfmclZzM2IMlz0z1sD5a8CWcql3SfJ/974wRpDFHlpZq66H1QW ta+d712QNn9lm5ezO2+IfQ719to2DDQuRMILc= 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=UHF7aR45aNy7YK+dechnPFv21wn6Gw/WR2znco84WYk=; b=lLEt2lNLyaGFrJhbTWfng+vYFoyh/8mgV7NSttwVNRHl4EEGght7zkqNtieFX1R561 mvD+F4WSoO19nG0Dm0iPaoE8VZv8RoUtyyEOSZj2+W+qBcDe82JYJd3DczohV66dSj5Q T5gxYTfG9tE90Sjha8s33oiIbP09/Vduef6e/+4cWJ9nB9j2XlSfP5cSKDkhh9t4ePu3 julu07c1GxKeYGyYbvNg2Yjiv34i27m0libA+/aD7FbA1eZBmfLLEj7hQs3urFdN0XDp oCeUxsnwm/BRE6M9GLwAfltGMRO0Ibt+qDPj8cB3gBy95x03G9kwylVwIg/PyiiKW+Qz kw7g== X-Gm-Message-State: APjAAAW8a84WJfKzCp9O9S9d4sSYEQWTOPmjLbIaDmVNaNAVy93Jspfk 4qkkGNfOvhGoSyotcpQ8UfwpeQ== X-Google-Smtp-Source: APXvYqxKXCgja1r/+sskhLP6NZq16OEkzmoBegZU2qL2Ao8OazoVjsv9NOsSt88kYzEvSquP8wUDeA== X-Received: by 2002:adf:f685:: with SMTP id v5mr103503wrp.246.1572444940108; Wed, 30 Oct 2019 07:15:40 -0700 (PDT) Received: from [192.168.2.134] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id u187sm193374wme.15.2019.10.30.07.15.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 07:15:39 -0700 (PDT) From: Neil Madden Message-Id: <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AEDECF20-6DC6-41D1-87A9-64EA0957C592" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 30 Oct 2019 14:15:34 +0000 In-Reply-To: <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net> Cc: Justin Richer , Brian Campbell , oauth To: Torsten Lodderstedt References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:15:44 -0000 --Apple-Mail=_AEDECF20-6DC6-41D1-87A9-64EA0957C592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Oct 2019, at 14:05, Torsten Lodderstedt = wrote: >> On 30. Oct 2019, at 14:56, Neil Madden = wrote: >>=20 >> On 30 Oct 2019, at 13:24, Justin Richer wrote: >>>=20 >>> All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. >>=20 >> The issue has nothing to do with the security of the connection = between the proxy and the backend. It is to do with data origin = authentication of the headers themselves. All of the headers arrive at = the backend over the same connection, but only some of them were created = by the proxy. There are undoubtedly better alternatives - e.g. using a = shared secret to compute a HMAC over security sensitive headers and = include that as an additional header or field. But an unguessable header = name is *simple* and effective and works right now with widely = implemented functionality.=20 >>=20 >> There's no need for the header name to ever change - the secret is = not exposed to untrusted parties >=20 > If the proxy sends certs via an header X to service A and B and = someone impersonates A it will find out the secret and use it to inject = certs in a connection towards B. Being able to impersonate A suggests that the attacker is already on the = trusted side of the network and that you are employing zero additional = network security controls between the RP and service A and B (e.g., TLS, = firewalls, VLAN/switches, etc). Remember, this is intended to mitigate = against accidental misconfiguration of the RP and header spoofing tricks = coming from the external network. I'm not suggesting it as an = alternative to basic network security on the trusted network. > We have learned that it is sometime hard to use different secret = header names for the same purpose with different request targets. In = those cases, a way to authenticate the proxy might by a good solution. =20= Do you have an example? The RPs and load balancers I'm familiar that = support multiple backends all support sending different headers to each = of them. Again though, security against attackers inside the trusted = network is not part of what the solution is preventing. Again, authenticating the *connection* from the RP to the backend = services is good, but is completely orthogonal to authenticating the = headers themselves. -- Neil --Apple-Mail=_AEDECF20-6DC6-41D1-87A9-64EA0957C592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 30 Oct 2019, at 14:05, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
On 30. Oct 2019, at 14:56, Neil = Madden <neil.madden@forgerock.com> wrote:

On 30 Oct 2019, at 13:24, Justin Richer <jricher@mit.edu> = wrote:

All of these problems can be solved, and I think solved = better, by securing the connection between the proxy and the back-end. = That way the back end will be able look not only for a specific header, = but verify that the header came from the proxy itself. An obscure header = name is one way to do that, but it has a lot of issues with it, = especially since it=E2=80=99s likely to be selected once during set-up = and never changed throughout the lifetime of the deployment. I think = there are likely much better solutions here, and they=E2=80=99d address = this issue without things getting weird.

The issue has nothing to do with the security of the = connection between the proxy and the backend. It is to do with data = origin authentication of the headers themselves. All of the headers = arrive at the backend over the same connection, but only some of them = were created by the proxy. There are undoubtedly better alternatives - = e.g. using a shared secret to compute a HMAC over security sensitive = headers and include that as an additional header or field. But an = unguessable header name is *simple* and effective and works right now = with widely implemented functionality. 

There's no need for the header name to ever change - the = secret is not exposed to untrusted parties

If the proxy = sends certs via an header X to service A and B and someone impersonates = A it will find out the secret and use it to inject certs in a connection = towards B.

Being = able to impersonate A suggests that the attacker is already on the = trusted side of the network and that you are employing zero additional = network security controls between the RP and service A and B (e.g., TLS, = firewalls, VLAN/switches, etc). Remember, this is intended to mitigate = against accidental misconfiguration of the RP and header spoofing tricks = coming from the external network. I'm not suggesting it as an = alternative to basic network security on the trusted network.

We have = learned that it is sometime hard to use different secret header names = for the same purpose with different request targets. In those cases, a = way to authenticate the proxy might by a good solution.  

Do you = have an example? The RPs and load balancers I'm familiar that support = multiple backends all support sending different headers to each of them. = Again though, security against attackers inside the trusted network is = not part of what the solution is preventing.

Again, authenticating the *connection* from the RP = to the backend services is good, but is completely orthogonal to = authenticating the headers themselves.

-- Neil


= --Apple-Mail=_AEDECF20-6DC6-41D1-87A9-64EA0957C592-- From nobody Wed Oct 30 07:18:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF92120077 for ; Wed, 30 Oct 2019 07:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0WlKZl_FV01 for ; Wed, 30 Oct 2019 07:18:32 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5A048120AAF for ; Wed, 30 Oct 2019 07:18:32 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9UE6mtA028146; Wed, 30 Oct 2019 14:18:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=rgHIF0w2uITzWLb+z6lZ4pTUWjL3/wWKSEffNvTiB+Y=; b=Ucs0+lQ4niN+HLi9/xuevRF+IiukPqjUXnSrWB89cDZtrC4rrKz8HO6a/nYac6U+narm XuWPOUm3kgiu0u5BnizLa30sdAiE419mD3GxfdRJcRLO4fCXfbHwXByTHKrv2aQHKZ1x /fhOiMHhTmjUvWwCqjosM1RM+q3DgGhkTi6HgJfVPK7XUVnkugRC4PyERF04JDCr+GSI IfHoh/GdfgE26IvCPSZ37TOyzTPeniwv7+kkaBN+Ifo+0lCz6IdVgVX/QfpqBgJbfyYe KvzGWUViwJbvLo4dW/K3d2dOyEx9HBBAZOfghvwEjcQZsr+PQITrCd1snDiixQG5Xx9V TA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2vxwgfuert-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 14:18:28 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9UEHGYq012713; Wed, 30 Oct 2019 07:18:27 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint5.akamai.com with ESMTP id 2vxwfns8ed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 07:18:27 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 10:18:26 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 10:18:26 -0400 From: "Salz, Rich" To: Neil Madden , Torsten Lodderstedt CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAA0ZsAgABfMACAAAkLAIAAAn0AgAACuwD//729gA== Date: Wed, 30 Oct 2019 14:18:25 +0000 Message-ID: References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net> <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com> In-Reply-To: <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.207] Content-Type: multipart/alternative; boundary="_000_D8A9138E22074783BB2B75B79E12DED2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=519 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910300135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_06:2019-10-30,2019-10-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 mlxlogscore=507 phishscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910300135 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:18:34 -0000 --_000_D8A9138E22074783BB2B75B79E12DED2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQWdhaW4sIGF1dGhlbnRpY2F0aW5nIHRoZSAqY29ubmVjdGlvbiogZnJvbSB0aGUgUlAg dG8gdGhlIGJhY2tlbmQgc2VydmljZXMgaXMgZ29vZCwgYnV0IGlzIGNvbXBsZXRlbHkgb3J0aG9n b25hbCB0byBhdXRoZW50aWNhdGluZyB0aGUgaGVhZGVycyB0aGVtc2VsdmVzLg0KDQpJIHN0cm9u Z2x5IGRpc2FncmVlLiAgQXV0aGVudGljYXRpbmcgdGhlIHNlbmRlciBhbGxvd3MgdGhlIHJlY2Vp dmVyIHRvIG1ha2UgYSB0cnVzdCBkZWNpc2lvbiBpbiB0aGUgcHJvdmVuYW5jZSBhbmQgcXVhbGl0 eSBvZiB0aGUgZGF0YSBpdCBnZXRzIGZyb20gdGhlIHNlbmRlci4gIERvIHlvdSBkaXNhZ3JlZSB3 aXRoIHRoYXQ/DQo= --_000_D8A9138E22074783BB2B75B79E12DED2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTk0NjUwMDA4NjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc2MDk3MDk0 OCAtMTQ2NjUxODU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGli cmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MjA2MTU4NzM4MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTY1Mzg3NjI2NiA4OTkzNDI1MzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5BZ2Fp biwgYXV0aGVudGljYXRpbmcgdGhlICpjb25uZWN0aW9uKiBmcm9tIHRoZSBSUCB0byB0aGUgYmFj a2VuZCBzZXJ2aWNlcyBpcyBnb29kLCBidXQgaXMgY29tcGxldGVseSBvcnRob2dvbmFsIHRvIGF1 dGhlbnRpY2F0aW5nIHRoZSBoZWFkZXJzIHRoZW1zZWx2ZXMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5IGRpc2FncmVlLiZuYnNwOyBBdXRoZW50aWNhdGlu ZyB0aGUgc2VuZGVyIGFsbG93cyB0aGUgcmVjZWl2ZXIgdG8gbWFrZSBhIHRydXN0IGRlY2lzaW9u IGluIHRoZSBwcm92ZW5hbmNlIGFuZCBxdWFsaXR5IG9mIHRoZSBkYXRhIGl0IGdldHMgZnJvbSB0 aGUgc2VuZGVyLiZuYnNwOyBEbyB5b3UgZGlzYWdyZWUgd2l0aCB0aGF0PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D8A9138E22074783BB2B75B79E12DED2akamaicom_-- From nobody Wed Oct 30 07:30:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E9120108 for ; Wed, 30 Oct 2019 07:30:52 -0700 (PDT) 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 7_pdtMA2eB7e for ; Wed, 30 Oct 2019 07:30:48 -0700 (PDT) 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 865091208EA for ; Wed, 30 Oct 2019 07:30:48 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id v9so2554177wrq.5 for ; Wed, 30 Oct 2019 07:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tRHEaJ63MjMW0dy6pd/R7WikLOwqR0KpYT9maVd5aT8=; b=bbftEINNle9pMin+ErLszmvMa4yvLV1JzZqkFVi670lpqQBJuebFOl71dFt6lxbPws +dIkTzjl+Wgwv2V/ZV8uYjFvqJPjv930PRF49YIhx1L2EWoy2Bcj31nO5anjjSHgTWIK /bXC9D2NW4NOfyuOJYhxCGARjUVQ5zWPg97kY= 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=tRHEaJ63MjMW0dy6pd/R7WikLOwqR0KpYT9maVd5aT8=; b=ICtmll7sW9pBegvhZT1elVMKU00ddc8kWx6spVy5gYP7s9fDaVnbVcHIQWryl+CAVn UHE8d2v6Kuea/qjSMf87o1/NxoyumpqVz0HLBd6GGrAqyBhLQEAzx+mdd+HvoFbhs3+R DNADBS/YaHYN6qqaXm55YA4nqCmVtDUDCsRfr9vWKZ5U0thyyiYQ2eFVEUJES1OWMeMi hjTOfD69e3aFQ92E4LnlLXepOAAAjFzj4JkcPs51jgCWw4OsGtqUHUWuAyB0dJKh35ld 4sExnhwhE6zF0zO6xWqAixLAkfcNtfYCMFCwbgSQCKUqtYH1FzUBgA60wKscTIo2aYvw 6B+A== X-Gm-Message-State: APjAAAW0VqhIB0ZgWLibXtlrY22/3wkKdds+A6ulYuIrpPAr2Xhg0byL hx1nb92Imab57PkmXzojwe/dqw== X-Google-Smtp-Source: APXvYqxv7tBHaK1gNT9/xsP5fCs2v3FkFwihtPaK9rZBwEGkEU7Oqyd9+EbbMkMfT0xd4aBO+kqGFg== X-Received: by 2002:a5d:674f:: with SMTP id l15mr181515wrw.80.1572445846916; Wed, 30 Oct 2019 07:30:46 -0700 (PDT) Received: from [192.168.2.134] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id m3sm407378wrb.67.2019.10.30.07.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 07:30:46 -0700 (PDT) From: Neil Madden Message-Id: <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EA28FE-15F5-4D14-B97E-779C7074B10D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 30 Oct 2019 14:30:45 +0000 In-Reply-To: <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> Cc: Justin Richer , Brian Campbell , oauth To: "Salz, Rich" References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:30:52 -0000 --Apple-Mail=_D8EA28FE-15F5-4D14-B97E-779C7074B10D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Combining responses to related messages (429 error): On 30 Oct 2019, at 14:07, Salz, Rich wrote: >=20 >> But an unguessable header name is *simple* and effective and works = right now with widely implemented functionality.=20 >=20 > You mean like admin/admin for administrator access? There is no such = thing as an unguessable name. I'm thinking of a uniformly random 16 byte name right now. Have at it. > You claim the name will never be exposed to untrusted parties. How = so? You are now telling administrators to treat a *name* as securely as = they treat a *key* (or password). If it must be protected like key = material, then use it like key material. Again, this is a defense in depth measure. A config file is fine. > The proxy-backend should be TLS, ideally authenticating the proxy. I agree - but completely irrelevant to the current discussion, which is = about how the backend distinguishes security-critical headers that the = proxy set from security-critical headers that were sneaked past the = proxy by a client (through misconfiguration or parsing bug). > On 30 Oct 2019, at 14:18, Salz, Rich wrote: >=20 > Again, authenticating the *connection* from the RP to the backend = services is good, but is completely orthogonal to authenticating the = headers themselves. > =20 > I strongly disagree. Authenticating the sender allows the receiver to = make a trust decision in the provenance and quality of the data it gets = from the sender. Do you disagree with that? Yes, see: https://en.wikipedia.org/wiki/Confused_deputy_problem = https://en.wikipedia.org/wiki/Cross-site_request_forgery = https://en.wikipedia.org/wiki/Server-side_request_forgery = and so on and so on. Authenticating the other side of a communication = pipe is not sufficient to authenticate the origin of the data contained = within those messages. The whole point of a proxy is that it forwards = requests from clients. In the face of misconfigurations and parsing bugs = the backend cannot distinguish headers that were set by the proxy from = headers that were spoofed by the client. *This is the entire problem I = have been discussing*.=20 -- Neil= --Apple-Mail=_D8EA28FE-15F5-4D14-B97E-779C7074B10D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Combining responses to related messages (429 = error):

On 30 Oct 2019, at = 14:07, Salz, Rich <rsalz@akamai.com> wrote:

But an = unguessable header name is *simple* and effective and works right now = with widely implemented functionality.

You mean like admin/admin for administrator access? =  There is no such thing as an unguessable = name.

I'm = thinking of a uniformly random 16 byte name right now. Have at = it.

You claim the name will never be exposed to = untrusted parties.  How so?  You are now telling = administrators to treat a *name* as securely as they treat a *key* (or = password).  If it must be protected like key material, then use it = like key material.

Again, this is a defense in depth measure. A = config file is fine.

The = proxy-backend should be TLS, ideally authenticating the proxy.

I = agree - but completely irrelevant to the current discussion, which is = about how the backend distinguishes security-critical headers that the = proxy set from security-critical headers that were sneaked past the = proxy by a client (through misconfiguration or parsing = bug).


On 30 Oct 2019, at 14:18, Salz, Rich <rsalz@akamai.com> = wrote:

  • Again, authenticating the *connection* from the RP to the = backend services is good, but is completely orthogonal to authenticating = the headers themselves.
 
I strongly = disagree.  Authenticating the sender allows the receiver to make a = trust decision in the provenance and quality of the data it gets from = the sender.  Do you disagree with = that?

Yes, see:

 https://en.wikipedia.org/wiki/Confused_deputy_problem
=
https://en.wikipedia.org/wiki/Cross-site_request_forgery
https://en.wikipedia.org/wiki/Server-side_request_forgery

and so on and = so on. Authenticating the other side of a communication pipe is not = sufficient to authenticate the origin of the data contained within those = messages. The whole point of a proxy is that it forwards requests from = clients. In the face of misconfigurations and parsing bugs the backend = cannot distinguish headers that were set by the proxy from headers that = were spoofed by the client. *This is the entire problem I have been = discussing*. 

-- Neil
= --Apple-Mail=_D8EA28FE-15F5-4D14-B97E-779C7074B10D-- From nobody Wed Oct 30 09:41:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99771200EC for ; Wed, 30 Oct 2019 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NIYTPECR3Hv for ; Wed, 30 Oct 2019 09:41:28 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 50939120073 for ; Wed, 30 Oct 2019 09:41:28 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9UGXtIw024594; Wed, 30 Oct 2019 16:41:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=tYlnhiunII4cwFCHMoaRiqVZ+4sy6SlVFIFny98I4rU=; b=hiM6TpHrISlaO0Zf/bx+nySKLeaohi7oLlj/BltbM5ljo8glUpKSR9iTSizgkzh+OQgQ leTT2FjtJGLrL1wilCaLWktBrDLBG6z9dqqINrHc428WRCF3bLz674+/LFVPyAjTPA67 ITPRICsNfJaCRtZC1SEbD+mhbOWoXGsEOGEWpmHvYF3ibydxwcUxr6TfxGFqeUGnI65q f0n3fwTmOGNQH3gi/ecqs7ZCe1IYRjGbWp+Iv4SpC2vTPjByKBDcMDmx2DHPa5/AX2tK eCaooLf6Jzq6GzySA1OSm/ubQKsQwy8g7Vzs0Uf0LJYDZx1GSmaolGayf43hAuT94t0n uw== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vxwghbya4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 16:41:25 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9UGWusG019555; Wed, 30 Oct 2019 12:41:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vxwfnqw2y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 12:41:24 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 12:41:23 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 12:41:23 -0400 From: "Salz, Rich" To: Neil Madden CC: Justin Richer , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAA0ZsAgABfMACAAAkLAP//v+yAgABJiYD//+FxAA== Date: Wed, 30 Oct 2019 16:41:22 +0000 Message-ID: <011AB6F2-F178-4D8F-8589-70A4C9CEC47A@akamai.com> References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com> In-Reply-To: <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.191] Content-Type: multipart/alternative; boundary="_000_011AB6F2F1784D8F858970A4C9CEC47Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910300150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_07:2019-10-30,2019-10-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 adultscore=0 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910300150 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 16:41:30 -0000 --_000_011AB6F2F1784D8F858970A4C9CEC47Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSdtIHRoaW5raW5nIG9mIGEgdW5pZm9ybWx5IHJhbmRvbSAxNiBieXRlIG5hbWUgcmln aHQgbm93LiBIYXZlIGF0IGl0Lg0KQ3V0ZSBidXQgbWlzc2luZyB0aGUgcG9pbnQuICBJIGRvbuKA mXQgaGF2ZSB0byBndWVzcyBpdC4gIFlPVSBoYXZlIHRvIHNlY3VyZWx5IGRlcGxveSBpdCBhY3Jv c3MgeW91ciBwcm94eSAoaG93ZXZlciBtYW55IHN0YWZmKSwgeW91ciBiYWNrZW5kIChob3dldmVy IG1hbnkgc3RhZmYpLCB5b3VyIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgKGhvd2V2ZXIgbWFueSks IGFuZCBwZXJoYXBzIHlvdXIgZGlhZ25vc2luZyBvciBkZWJ1ZyB0ZWFtcyBpZiB0aGV5IGFyZSBk aWZmZXJlbnQuICBBbmQgdGhlbiB5b3UgbXVzdCBtYWtlIHN1cmUgdGhhdCBpZiBBTllPTkUgZXZl ciB0YWtlcyBhIHBhY2tldCB0cmFjZSwgb3IgbWFrZXMgYSBzbGlkZSBvdXQgb2YgYSBzYW1wbGUg bWVzc2FnZSwgdGhhdCB0aGV5IGRvbuKAmXQgZGlzY2xvc2UgdGhlIGhlYWRlciwgc3VjaCBhcyBi eSBzaG93aW5nIOKAnGhlcmXigJlzIGhvdyB3ZSBkbyBPQVVUSOKAnSBhdCBhIHVzZXIgZ3JvdXAg bWVldGluZy4NCg0KICAqICAgQWdhaW4sIHRoaXMgaXMgYSBkZWZlbnNlIGluIGRlcHRoIG1lYXN1 cmUuIEEgY29uZmlnIGZpbGUgaXMgZmluZS4NCk5vLCBpdOKAmXMgbm90LiAgSXTigJlzIGEgbXVs dGktcGFydHkgc2hhcmVkIHNlY3JldCB0aGF0IGlzbuKAmXQgaWRlbnRpZmllZCBhcyBhIHNlY3Jl dC4gIEl04oCZcyBub3QgZGVmZW5zZSBpbiBkZXB0aCwgaXTigJlzIGEgZm91bmRhdGlvbiBvZiBz YW5kLg0KDQogICogICBpcnJlbGV2YW50IHRvIHRoZSBjdXJyZW50IGRpc2N1c3Npb24sIHdoaWNo IGlzIGFib3V0IGhvdyB0aGUgYmFja2VuZCBkaXN0aW5ndWlzaGVzIHNlY3VyaXR5LWNyaXRpY2Fs IGhlYWRlcnMgdGhhdCB0aGUgcHJveHkgc2V0IGZyb20gc2VjdXJpdHktY3JpdGljYWwgaGVhZGVy cyB0aGF0IHdlcmUgc25lYWtlZCBwYXN0IHRoZSBwcm94eSBieSBhIGNsaWVudCAodGhyb3VnaCBt aXNjb25maWd1cmF0aW9uIG9yIHBhcnNpbmcgYnVnKS4NClRoZSBiYWNrZW5kIG11c3QgdHJ1c3Qg dGhlIHByb3h5LiAgSWYgeW91IHRlbGwgdGhlIHByb3h5IHRvIOKAnHVzZSBGT09CQVIxMjPigJ0g YXMgdGhlIGhlYWRlciBvZiB0aGUgY2xpZW50IGNlcnRpZmljYXRlLCBob3cgZG8geW91IGtub3cg dGhhdCB0aGUgcHJveHkgcHJvcGVybHkgcHJvdmlkZWQgdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZT8g IFByZXRlbmRpbmcgdGhhdCB0aGUgYmFja2VuZCBvbmx5IGhhcyB0byB0cnVzdCAqcGFydCogb2Yg dGhlIHByb3h5LCBiZWNhdXNlIHdlIHVzZSBhIHNla3JpdCBoZWFkZXIgdmFsdWUgaXMganVzdCB0 aGF0LCBwcmV0ZW5kaW5nLg0KDQpZb3VyIGxpbmtzIHRvIGNvbmZ1c2VkIGRlcHV0eSBhbmQgQ1NS RiBkbyBub3QgYWRkcmVzcyB0aGUgaXNzdWVzIEkgcmFpc2VkLg0KDQoNCiAgKiAgIEF1dGhlbnRp Y2F0aW5nIHRoZSBvdGhlciBzaWRlIG9mIGEgY29tbXVuaWNhdGlvbiBwaXBlIGlzIG5vdCBzdWZm aWNpZW50IHRvIGF1dGhlbnRpY2F0ZSB0aGUgb3JpZ2luIG9mIHRoZSBkYXRhIGNvbnRhaW5lZCB3 aXRoaW4gdGhvc2UgbWVzc2FnZXMuIFRoZSB3aG9sZSBwb2ludCBvZiBhIHByb3h5IGlzIHRoYXQg aXQgZm9yd2FyZHMgcmVxdWVzdHMgZnJvbSBjbGllbnRzLiBJbiB0aGUgZmFjZSBvZiBtaXNjb25m aWd1cmF0aW9ucyBhbmQgcGFyc2luZyBidWdzIHRoZSBiYWNrZW5kIGNhbm5vdCBkaXN0aW5ndWlz aCBoZWFkZXJzIHRoYXQgd2VyZSBzZXQgYnkgdGhlIHByb3h5IGZyb20gaGVhZGVycyB0aGF0IHdl cmUgc3Bvb2ZlZCBieSB0aGUgY2xpZW50LiAqVGhpcyBpcyB0aGUgZW50aXJlIHByb2JsZW0gSSBo YXZlIGJlZW4gZGlzY3Vzc2luZyouDQpBbmQgeW91IGJlbGlldmUgdGhhdCBjb25maWd1cmluZyBh IHByb3h5LCBvZiB3aGljaCB5b3UgYXJlIHNrZXB0aWNhbCwgYWRkcmVzc2VzIHRoYXQgY29uY2Vy bj8NCg0K --_000_011AB6F2F1784D8F858970A4C9CEC47Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <60922579673FBF4D9BB625CE08834347@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzQ3NDU5NjM0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTk0ODA2ODQ0Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIxMzcwOTU1 NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzA3 ODQzNTcyIDE2OTc1MjA1OTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj5JJ20g dGhpbmtpbmcgb2YgYSB1bmlmb3JtbHkgcmFuZG9tIDE2IGJ5dGUgbmFtZSByaWdodCBub3cuIEhh dmUgYXQgaXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DdXRl IGJ1dCBtaXNzaW5nIHRoZSBwb2ludC4mbmJzcDsgSSBkb27igJl0IGhhdmUgdG8gZ3Vlc3MgaXQu Jm5ic3A7IFlPVSBoYXZlIHRvIHNlY3VyZWx5IGRlcGxveSBpdCBhY3Jvc3MgeW91ciBwcm94eSAo aG93ZXZlciBtYW55IHN0YWZmKSwgeW91ciBiYWNrZW5kIChob3dldmVyIG1hbnkgc3RhZmYpLCB5 b3VyIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgKGhvd2V2ZXIgbWFueSksIGFuZCBwZXJoYXBzIHlv dXIgZGlhZ25vc2luZyBvcg0KIGRlYnVnIHRlYW1zIGlmIHRoZXkgYXJlIGRpZmZlcmVudC4mbmJz cDsgQW5kIHRoZW4geW91IG11c3QgbWFrZSBzdXJlIHRoYXQgaWYgQU5ZT05FIGV2ZXIgdGFrZXMg YSBwYWNrZXQgdHJhY2UsIG9yIG1ha2VzIGEgc2xpZGUgb3V0IG9mIGEgc2FtcGxlIG1lc3NhZ2Us IHRoYXQgdGhleSBkb27igJl0IGRpc2Nsb3NlIHRoZSBoZWFkZXIsIHN1Y2ggYXMgYnkgc2hvd2lu ZyDigJxoZXJl4oCZcyBob3cgd2UgZG8gT0FVVEjigJ0gYXQgYSB1c2VyIGdyb3VwIG1lZXRpbmcu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkFnYWluLCB0aGlz IGlzIGEgZGVmZW5zZSBpbiBkZXB0aCBtZWFzdXJlLiBBIGNvbmZpZyBmaWxlIGlzIGZpbmUuPG86 cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O bywgaXTigJlzIG5vdC4mbmJzcDsgSXTigJlzIGEgbXVsdGktcGFydHkgc2hhcmVkIHNlY3JldCB0 aGF0IGlzbuKAmXQgaWRlbnRpZmllZCBhcyBhIHNlY3JldC4mbmJzcDsgSXTigJlzIG5vdCBkZWZl bnNlIGluIGRlcHRoLCBpdOKAmXMgYSBmb3VuZGF0aW9uIG9mIHNhbmQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+aXJyZWxldmFudCB0byB0aGUg Y3VycmVudCBkaXNjdXNzaW9uLCB3aGljaCBpcyBhYm91dCBob3cgdGhlIGJhY2tlbmQgZGlzdGlu Z3Vpc2hlcyBzZWN1cml0eS1jcml0aWNhbCBoZWFkZXJzIHRoYXQgdGhlIHByb3h5IHNldCBmcm9t IHNlY3VyaXR5LWNyaXRpY2FsIGhlYWRlcnMgdGhhdCB3ZXJlIHNuZWFrZWQgcGFzdCB0aGUgcHJv eHkgYnkgYQ0KIGNsaWVudCAodGhyb3VnaCBtaXNjb25maWd1cmF0aW9uIG9yIHBhcnNpbmcgYnVn KS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBiYWNrZW5kIG11c3QgdHJ1c3QgdGhlIHByb3h5LiZuYnNwOyBJZiB5b3UgdGVsbCB0 aGUgcHJveHkgdG8g4oCcdXNlIEZPT0JBUjEyM+KAnSBhcyB0aGUgaGVhZGVyIG9mIHRoZSBjbGll bnQgY2VydGlmaWNhdGUsIGhvdyBkbyB5b3Uga25vdyB0aGF0IHRoZSBwcm94eSBwcm9wZXJseSBw cm92aWRlZCB0aGUgY2xpZW50IGNlcnRpZmljYXRlPyZuYnNwOyBQcmV0ZW5kaW5nIHRoYXQgdGhl IGJhY2tlbmQgb25seSBoYXMgdG8gdHJ1c3QNCiAqPGI+cGFydDwvYj4qIG9mIHRoZSBwcm94eSwg YmVjYXVzZSB3ZSB1c2UgYSBzZWtyaXQgaGVhZGVyIHZhbHVlIGlzIGp1c3QgdGhhdCwgcHJldGVu ZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91ciBsaW5rcyB0 byBjb25mdXNlZCBkZXB1dHkgYW5kIENTUkYgZG8gbm90IGFkZHJlc3MgdGhlIGlzc3VlcyBJIHJh aXNlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj5BdXRo ZW50aWNhdGluZyB0aGUgb3RoZXIgc2lkZSBvZiBhIGNvbW11bmljYXRpb24gcGlwZSBpcyBub3Qg c3VmZmljaWVudCB0byBhdXRoZW50aWNhdGUgdGhlIG9yaWdpbiBvZiB0aGUgZGF0YSBjb250YWlu ZWQgd2l0aGluIHRob3NlIG1lc3NhZ2VzLiBUaGUgd2hvbGUgcG9pbnQgb2YgYSBwcm94eSBpcyB0 aGF0IGl0IGZvcndhcmRzIHJlcXVlc3RzDQogZnJvbSBjbGllbnRzLiBJbiB0aGUgZmFjZSBvZiBt aXNjb25maWd1cmF0aW9ucyBhbmQgcGFyc2luZyBidWdzIHRoZSBiYWNrZW5kIGNhbm5vdCBkaXN0 aW5ndWlzaCBoZWFkZXJzIHRoYXQgd2VyZSBzZXQgYnkgdGhlIHByb3h5IGZyb20gaGVhZGVycyB0 aGF0IHdlcmUgc3Bvb2ZlZCBieSB0aGUgY2xpZW50LiAqVGhpcyBpcyB0aGUgZW50aXJlIHByb2Js ZW0gSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyouJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgeW91IGJlbGlldmUgdGhhdCBj b25maWd1cmluZyBhIHByb3h5LCBvZiB3aGljaCB5b3UgYXJlIHNrZXB0aWNhbCwgYWRkcmVzc2Vz IHRoYXQgY29uY2Vybj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_011AB6F2F1784D8F858970A4C9CEC47Aakamaicom_-- From nobody Wed Oct 30 10:03:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E543D120074 for ; Wed, 30 Oct 2019 10:03:57 -0700 (PDT) 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 ie-cjcfJ6cN7 for ; Wed, 30 Oct 2019 10:03:56 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA730120111 for ; Wed, 30 Oct 2019 10:03:55 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id g24so2899148wmh.5 for ; Wed, 30 Oct 2019 10:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3GHy9BenAp6ShBHu3TdXdrvRdUpJCJgNX3RP1w2iFSo=; b=F+exeNAfYUi0kF3wllYrslTqRlQMc1G8D5xjszePGuIW6n9ZvazRFjnM32NxuUtomq 7IzKY+J1suTLbZSIJ9XQ8kHupZ6HQQtLmlNcaKOyZ7v4iQ1j+how5icp/b2hKhe0AvUK T2Dw0myFO4P1uQGdiWrGzVbzVPQbwEtL5ZFfc= 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=3GHy9BenAp6ShBHu3TdXdrvRdUpJCJgNX3RP1w2iFSo=; b=I8wTMeoJKtOQNs6s4SRVhjLMCQzdPDQDiWAQowVSBLRbtWwY/0q5BVwNABsnGYWUkG BsowjU2befwW3jlfaue19OUtfHfbYXuRYVE/bYc/KqTaD+vxO8m41Mv/7G29y04Gn9Ym VimNQzU5GBgWoUe6UUSLBcMUNzQRH0OjKqq/pefB7pL22wn+AcQo3++s8TaA6IIH6e2l R6aTuMNdUuQPEdx/Jo1W8tqc5CRBMwlnYGOcfRqWZYdFl0TsduidwER23/0xCbphU2bK ucoF9yHarbGjX6qXtVvXDrYEnpKEebrdz8aGmFKCT087RMkH5FB44Q4Fiv6IGn1DIzOg WmBA== X-Gm-Message-State: APjAAAUy7IMG7yUqEvgtBwkZQROVOP3r2JEus7Vgl1xOaY4AEDis2sUX UcIjFX48iT82F45RGd4HhxwfdA== X-Google-Smtp-Source: APXvYqywCoizyq+L7xZSuwTCesD3xNSraUpR6j8i/0yFB4hYb5dJToZT1kWMe5ixReDTx5yZfpHb4Q== X-Received: by 2002:a1c:7406:: with SMTP id p6mr496878wmc.64.1572455034381; Wed, 30 Oct 2019 10:03:54 -0700 (PDT) Received: from [192.168.2.134] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id 76sm684807wma.0.2019.10.30.10.03.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 10:03:53 -0700 (PDT) From: Neil Madden Message-Id: <68653C2D-E8BB-40F9-9C40-941B6A92E68A@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80020BA6-6DD1-4F38-A77F-5BD4E31899F6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 30 Oct 2019 17:03:49 +0000 In-Reply-To: <011AB6F2-F178-4D8F-8589-70A4C9CEC47A@akamai.com> Cc: Justin Richer , Brian Campbell , oauth To: "Salz, Rich" References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com> <011AB6F2-F178-4D8F-8589-70A4C9CEC47A@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 17:03:58 -0000 --Apple-Mail=_80020BA6-6DD1-4F38-A77F-5BD4E31899F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Oct 2019, at 16:41, Salz, Rich wrote: >=20 > I'm thinking of a uniformly random 16 byte name right now. Have at it. > Cute but missing the point. I don=E2=80=99t have to guess it.=20 To quote your previous claim: "There is no such thing as an unguessable = name." > YOU have to securely deploy it across your proxy (however many staff), = your backend (however many staff), your application developers (however = many), and perhaps your diagnosing or debug teams if they are different. = And then you must make sure that if ANYONE ever takes a packet trace, = or makes a slide out of a sample message, that they don=E2=80=99t = disclose the header, such as by showing =E2=80=9Chere=E2=80=99s how we = do OAUTH=E2=80=9D at a user group meeting. Even if your deployment team had such staggeringly bad operational = security practices as to allow people to take packet captures from an = internal network and show them on public slides without any kind of = questions being asked, if this actually happens *YOU ARE NO WORSE OFF = THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*! I don't know how many different ways I can say that this is a defense in = depth *in addition to* everything else you would normally do to secure = traffic between your RP and backend servers. As with all defense in = depth, the aim is to be more than 1 configuration mistake away from = total compromise. -- Neil= --Apple-Mail=_80020BA6-6DD1-4F38-A77F-5BD4E31899F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 30 Oct 2019, at 16:41, Salz, Rich <rsalz@akamai.com> wrote:

  • I'm thinking of a uniformly random 16 = byte name right now. Have at it.
Cute but missing the point.  I = don=E2=80=99t have to guess it.  =

To quote = your previous claim: "There is no such thing as an unguessable = name."

YOU have to securely deploy it across = your proxy (however many staff), your backend (however many staff), your = application developers (however many), and perhaps your diagnosing or = debug teams if they are different.  And then you must make sure = that if ANYONE ever takes a packet trace, or makes a slide out of a = sample message, that they don=E2=80=99t disclose the header, such as by = showing =E2=80=9Chere=E2=80=99s how we do OAUTH=E2=80=9D at a user group = meeting.

Even= if your deployment team had such staggeringly bad operational security = practices as to allow people to take packet captures from an internal = network and show them on public slides without any kind of questions = being asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE = SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*!

I don't know how many different ways I can say = that this is a defense in depth *in addition to* everything else you = would normally do to secure traffic between your RP and backend servers. = As with all defense in depth, the aim is to be more than 1 configuration = mistake away from total compromise.

-- Neil
= --Apple-Mail=_80020BA6-6DD1-4F38-A77F-5BD4E31899F6-- From nobody Wed Oct 30 10:19:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF59120111 for ; Wed, 30 Oct 2019 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0LNDrnIwrj0 for ; Wed, 30 Oct 2019 10:19:41 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 027D812080D for ; Wed, 30 Oct 2019 10:19:41 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9UHCZiH020148; Wed, 30 Oct 2019 17:19:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hotyJF4yxx4uhI4Px2GMsVwXjkXl50DfKq9hiDfqJPQ=; b=F3A8kRukGCWtSsw753f/CeFV0smQ1s22QmhYw1CAJ260F5Wn6/+Jsorz3yzkV+3qvKTa HgCf5i6yKe+uColZm6Z5S0bO4rv2Vg7FWn2SQT/jWUazeOM06J6RWd1ch3X1sphVNdJt ruvu8pIJ0eAtQgChkifDl46M/inSDgthErSNzy2RN7naZSQmhPsAU9jLd+PPzk6zI2DW lPhoY3PhJFnMOruhwY2+vyF6kne4n8R8ZNZwAw7S525jKiKs5FrlJfLur3DV4m3qA/oY +FZzuYv4fbLrKgX3BNhTWshjhXCq7OlRrWsyCckyCZEZyF8Su5jDAEHS8yWV6RzXZH8j 6g== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vxwgfc724-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 17:19:38 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9UHI2i1018426; Wed, 30 Oct 2019 10:19:36 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint5.akamai.com with ESMTP id 2vxwfnsryx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 10:19:36 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 13:19:35 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 13:19:35 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 13:19:35 -0400 From: "Salz, Rich" To: Neil Madden CC: Justin Richer , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAA0ZsAgABfMACAAAkLAP//v+yAgABJiYD//+FxAIAASVSA///BWAA= Date: Wed, 30 Oct 2019 17:19:34 +0000 Message-ID: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com> References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com> <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com> <011AB6F2-F178-4D8F-8589-70A4C9CEC47A@akamai.com> <68653C2D-E8BB-40F9-9C40-941B6A92E68A@forgerock.com> In-Reply-To: <68653C2D-E8BB-40F9-9C40-941B6A92E68A@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.191] Content-Type: multipart/alternative; boundary="_000_4D4F6A3874ED4243A1BCCE1823FC1ED9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=843 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910300152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_07:2019-10-30,2019-10-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=832 spamscore=0 malwarescore=0 priorityscore=1501 phishscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 mlxscore=0 suspectscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910300152 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 17:19:42 -0000 --_000_4D4F6A3874ED4243A1BCCE1823FC1ED9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVG8gcXVvdGUgeW91ciBwcmV2aW91cyBjbGFpbTogIlRoZXJlIGlzIG5vIHN1Y2ggdGhp bmcgYXMgYW4gdW5ndWVzc2FibGUgbmFtZS4iDQpSaWdodC4gIFRoYXQgZG9lc27igJl0IG1lYW4g KkkqIGhhdmUgdG8gZ3Vlc3MgaXQuDQoNCg0KICAqICAgRXZlbiBpZiB5b3VyIGRlcGxveW1lbnQg dGVhbSBoYWQgc3VjaCBzdGFnZ2VyaW5nbHkgYmFkIG9wZXJhdGlvbmFsIHNlY3VyaXR5IHByYWN0 aWNlcyBhcyB0byBhbGxvdyBwZW9wbGUgdG8gdGFrZSBwYWNrZXQgY2FwdHVyZXMgZnJvbSBhbiBp bnRlcm5hbCBuZXR3b3JrIGFuZCBzaG93IHRoZW0gb24gcHVibGljIHNsaWRlcyB3aXRob3V0IGFu eSBraW5kIG9mIHF1ZXN0aW9ucyBiZWluZyBhc2tlZCwgaWYgdGhpcyBhY3R1YWxseSBoYXBwZW5z ICpZT1UgQVJFIE5PIFdPUlNFIE9GRiBUSEFOIElOIFRIRSBTSVRVQVRJT04gV0hFUkUgWU9VIFVT RUQgQSBXRUxMLUtOT1dOIEhFQURFUiBOQU1FKiENClllcyB5b3UgYXJlIHdvcnNlIG9mZi4gIEJl Y2F1c2UgdGhhdCBub3ctZXhwb3NlZCBoZWFkZXIgdmFsdWUgY2FuIGJlIHVzZWQgZm9yIHNwb29m aW5nLiAgQXMgb3Bwb3NlZCB0byBwcm90ZWN0aW9uIGJ5IFRMUywgYW5kIHRoZW4gc2VuZGluZyB0 aGUgcGxhaW50ZXh0IG1lc3NhZ2UgYXJvdW5kLg0KDQoNCiAgKiAgIEkgZG9uJ3Qga25vdyBob3cg bWFueSBkaWZmZXJlbnQgd2F5cyBJIGNhbiBzYXkgdGhhdCB0aGlzIGlzIGEgZGVmZW5zZSBpbiBk ZXB0aA0KQmVjYXVzZSBpdCBpcyBub3QuICBJdCBpcyB0YWtpbmcgYW4gYXBwbGljYXRpb24tbGV2 ZWwgcGllY2Ugb2YgY29uZmlndXJhdGlvbiBkYXRhIGFuZCByZXF1aXJpbmcgaXQgdG8gYmUgdHJl YXRlZCBhcyBpZiBpdCB3ZXJlIGNyeXB0byBtYXRlcmlhbC4gV2hpY2ggaXQgY2Fubm90IGJlLCBi ZWNhdXNlIG11bHRpcGxlIHBhcnRpZXMgbmVlZCB0byBrbm93IGl0IChhcyBJIHNhaWQsIHRoZSBw cm94eSwgdGhlIGJhY2tlbmQsIHRoZSBhcHAgZGV2ZWxvcGVycywgdGhlIHN1cHBvcnQgdGVhbSwg ZXRjKS4gIEl04oCZcyBkZWZlbnNlIGJ5IOKAnGNvbGxhcHNpbmcgbGF5ZXJz4oCdIHJhdGhlciB0 aGFuIOKAnGluIGRlcHRoLuKAnQ0KDQoNCiAgKiAgIEFzIHdpdGggYWxsIGRlZmVuc2UgaW4gZGVw dGgsIHRoZSBhaW0gaXMgdG8gYmUgbW9yZSB0aGFuIDEgY29uZmlndXJhdGlvbiBtaXN0YWtlIGF3 YXkgZnJvbSB0b3RhbCBjb21wcm9taXNlLg0KQnV0IHRoYXQgaXMgZXhhY3RseSB3aGF0IHlvdSBh cmUgcHJvcG9zaW5nLiBFeHBvc2luZyB0aGUgaGVhZGVyICppcyogYSB0b3RhbCBjb21wcm9taXNl IGFuZCBtdWx0aXBsZSBlbnRpdGllcyB3aWxsIG5lZWQgdG8ga25vdyB0aGF0IGhlYWRlciB2YWx1 ZS4NCg0KQXQgYW55IHJhdGUsICBJIHRoaW5rIHdl4oCZcmUgZG9uZSBoZXJlLg0KDQo= --_000_4D4F6A3874ED4243A1BCCE1823FC1ED9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3DFAD4C8B80C2C4CBF63B1B2E374A0CB@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMzcwNzIxNzg7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MTQzMDkyMTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoxNTg4NDE1NzY2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxMTYxMzU3OTg0IC0xOTczMjU4MzEyIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlz dDpsMSBsZXZlbDEgbGZvMiI+VG8gcXVvdGUgeW91ciBwcmV2aW91cyBjbGFpbTogJnF1b3Q7VGhl cmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiB1bmd1ZXNzYWJsZSBuYW1lLiZxdW90OzxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQuJm5ic3A7IFRoYXQgZG9l c27igJl0IG1lYW4gKjxiPkk8L2I+KiBoYXZlIHRvIGd1ZXNzIGl0Ljxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj5FdmVuIGlmIHlvdXIgZGVw bG95bWVudCB0ZWFtIGhhZCBzdWNoIHN0YWdnZXJpbmdseSBiYWQgb3BlcmF0aW9uYWwgc2VjdXJp dHkgcHJhY3RpY2VzIGFzIHRvIGFsbG93IHBlb3BsZSB0byB0YWtlIHBhY2tldCBjYXB0dXJlcyBm cm9tIGFuIGludGVybmFsIG5ldHdvcmsgYW5kIHNob3cgdGhlbSBvbiBwdWJsaWMgc2xpZGVzIHdp dGhvdXQgYW55DQoga2luZCBvZiBxdWVzdGlvbnMgYmVpbmcgYXNrZWQsIGlmIHRoaXMgYWN0dWFs bHkgaGFwcGVucyAqWU9VIEFSRSBOTyBXT1JTRSBPRkYgVEhBTiBJTiBUSEUgU0lUVUFUSU9OIFdI RVJFIFlPVSBVU0VEIEEgV0VMTC1LTk9XTiBIRUFERVIgTkFNRSohPG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgeW91IGFyZSB3b3Jz ZSBvZmYuJm5ic3A7IEJlY2F1c2UgdGhhdCBub3ctZXhwb3NlZCBoZWFkZXIgdmFsdWUgY2FuIGJl IHVzZWQgZm9yIHNwb29maW5nLiZuYnNwOyBBcyBvcHBvc2VkIHRvIHByb3RlY3Rpb24gYnkgVExT LCBhbmQgdGhlbiBzZW5kaW5nIHRoZSBwbGFpbnRleHQgbWVzc2FnZSBhcm91bmQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj5JIGRvbid0IGtub3cgaG93IG1hbnkgZGlm ZmVyZW50IHdheXMgSSBjYW4gc2F5IHRoYXQgdGhpcyBpcyBhIGRlZmVuc2UgaW4gZGVwdGg8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgaXQgaXMgbm90 LiZuYnNwOyBJdCBpcyB0YWtpbmcgYW4gYXBwbGljYXRpb24tbGV2ZWwgcGllY2Ugb2YgY29uZmln dXJhdGlvbiBkYXRhIGFuZCByZXF1aXJpbmcgaXQgdG8gYmUgdHJlYXRlZCBhcyBpZiBpdCB3ZXJl IGNyeXB0byBtYXRlcmlhbC4gV2hpY2ggaXQgY2Fubm90IGJlLCBiZWNhdXNlIG11bHRpcGxlIHBh cnRpZXMgbmVlZCB0byBrbm93IGl0IChhcyBJIHNhaWQsIHRoZSBwcm94eSwgdGhlIGJhY2tlbmQs DQogdGhlIGFwcCBkZXZlbG9wZXJzLCB0aGUgc3VwcG9ydCB0ZWFtLCBldGMpLiZuYnNwOyBJdOKA mXMgZGVmZW5zZSBieSDigJxjb2xsYXBzaW5nIGxheWVyc+KAnSByYXRoZXIgdGhhbiDigJxpbiBk ZXB0aC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPkFzIHdpdGggYWxsIGRlZmVuc2UgaW4gZGVwdGgsIHRoZSBhaW0gaXMgdG8gYmUg bW9yZSB0aGFuIDEgY29uZmlndXJhdGlvbiBtaXN0YWtlIGF3YXkgZnJvbSB0b3RhbCBjb21wcm9t aXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCB0aGF0IGlzIGV4YWN0bHkgd2hhdCB5b3UgYXJlIHByb3Bvc2luZy4gRXhwb3NpbmcgdGhlIGhl YWRlciAqPGI+aXM8L2I+KiBhIHRvdGFsIGNvbXByb21pc2UgYW5kIG11bHRpcGxlIGVudGl0aWVz IHdpbGwgbmVlZCB0byBrbm93IHRoYXQgaGVhZGVyIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BdCBhbnkgcmF0ZSwgJm5ic3A7SSB0aGluayB3ZeKAmXJlIGRvbmUgaGVyZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4D4F6A3874ED4243A1BCCE1823FC1ED9akamaicom_-- From nobody Wed Oct 30 12:18:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7F4120866 for ; Wed, 30 Oct 2019 12:18:33 -0700 (PDT) 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 ZswbP5V3m5Un for ; Wed, 30 Oct 2019 12:18:31 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A923120255 for ; Wed, 30 Oct 2019 12:18:31 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id q70so3310271wme.1 for ; Wed, 30 Oct 2019 12:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Pr6/9Rai4XnQmEkrUSlPN9I3I95MkU2RJxLYZnbX1oU=; b=CE+RUpP0BZ76bbw9PhCXbYznrjbNzHufCekRAtHHU8QI7uy8VRh2kFh8zRz8gdmfju Nof8qzk3C83gQ9IiO8QXpIEcceqFyLVs6D0yBvXsf14itFlvTREF3itgWd8n2H5gmngI axv2eH+kSRdFCeF8Z5d+c0zU8n8EakABMGiwM= 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=Pr6/9Rai4XnQmEkrUSlPN9I3I95MkU2RJxLYZnbX1oU=; b=GpHXTboS12KlQzLkFe78OlQX2BfESCs6byxv/ZbKc2ZC+02WSGdIswY1HdsPU93WFY IrrdPDWY/ArAwmqQ0yBSHxV3RYKdiSvHgQdMHeh2nbrZTqmJs6+AvpyUR2ElV6uBsQpB dkM3C8LpAISchO7sWE+hHjI/90Yucwwxj4+AtukHGf0pkhViDvFA7DU9s1/zKQFl4FZR hzhKRS7txZv/ECAKXxFpJyZHPIgCOsumNpQfFKjFbXi7jLTj9Q80iLXyar3cZZ+r4sSD 5Cn+HJtqm92SHLiCzveQFXyi8LBRigQXU3RBF3Ak2BgHPAHFyuhgMrvbkhQfCV0WXslX ZVlg== X-Gm-Message-State: APjAAAX1azjCf+kk1UbWnhsTjWEMBA87Gfde4+r5XE1Rbxum9f1+9ImP /8FerBWPvejbVi/YG7KMrM6ZIw== X-Google-Smtp-Source: APXvYqxAFdFrEuelOna571ukE9K4cqKN5q6TYVvLOM+rFEm6hHStzIqEEyDKhyBhDHA39drQsmTxhw== X-Received: by 2002:a1c:67d7:: with SMTP id b206mr1007901wmc.68.1572463109928; Wed, 30 Oct 2019 12:18:29 -0700 (PDT) Received: from ?IPv6:2a01:4c8:9:46ab:edd0:36d9:9264:132d? ([2a01:4c8:9:46ab:edd0:36d9:9264:132d]) by smtp.gmail.com with ESMTPSA id v6sm1473394wru.72.2019.10.30.12.18.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 12:18:28 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E6C615FD-1991-4CFA-8594-62B336B2042E Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Wed, 30 Oct 2019 19:18:27 +0000 Message-Id: <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com> References: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com> Cc: Justin Richer , Brian Campbell , oauth In-Reply-To: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com> To: "Salz, Rich" X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 19:18:34 -0000 --Apple-Mail-E6C615FD-1991-4CFA-8594-62B336B2042E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you can point out where I recommended disabling TLS or not bothering to s= trip headers from incoming requests, or anything else along those lines then= please let me know. Otherwise, yes we=E2=80=99re done here.=20 > On 30 Oct 2019, at 17:19, Salz, Rich wrote: >=20 > =EF=BB=BF > To quote your previous claim: "There is no such thing as an unguessable na= me." > Right. That doesn=E2=80=99t mean *I* have to guess it. >=20 > Even if your deployment team had such staggeringly bad operational securit= y practices as to allow people to take packet captures from an internal netw= ork and show them on public slides without any kind of questions being asked= , if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION WHERE= YOU USED A WELL-KNOWN HEADER NAME*! > Yes you are worse off. Because that now-exposed header value can be used f= or spoofing. As opposed to protection by TLS, and then sending the plaintex= t message around. > =20 > I don't know how many different ways I can say that this is a defense in d= epth > Because it is not. It is taking an application-level piece of configurati= on data and requiring it to be treated as if it were crypto material. Which i= t cannot be, because multiple parties need to know it (as I said, the proxy,= the backend, the app developers, the support team, etc). It=E2=80=99s defe= nse by =E2=80=9Ccollapsing layers=E2=80=9D rather than =E2=80=9Cin depth.=E2= =80=9D > =20 > As with all defense in depth, the aim is to be more than 1 configuration m= istake away from total compromise. > But that is exactly what you are proposing. Exposing the header *is* a tot= al compromise and multiple entities will need to know that header value. > =20 > At any rate, I think we=E2=80=99re done here. > =20 --Apple-Mail-E6C615FD-1991-4CFA-8594-62B336B2042E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you can point out where= I recommended disabling TLS or not bothering to strip headers from incoming= requests, or anything else along those lines then please let me know. Other= wise, yes we=E2=80=99re done here. 

On 30 Oct 2019, at 17:19, Salz, Rich <rsalz@akamai.com&g= t; wrote:

=EF=BB=BF
  • To quote yo= ur previous claim: "There is no such thing as an unguessable name."

Right.  That doesn=E2=80=99t mean *I* hav= e to guess it.

  • Even if you= r deployment team had such staggeringly bad operational security practices a= s to allow people to take packet captures from an internal network and show t= hem on public slides without any kind of questions being asked, if this actually happens *YOU ARE NO WORSE O= FF THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*!

Yes you are worse off.  Because that now-exposed= header value can be used for spoofing.  As opposed to protection by TL= S, and then sending the plaintext message around.

 

  • I don't kno= w how many different ways I can say that this is a defense in depth

Because it is not.  It is taking an application-= level piece of configuration data and requiring it to be treated as if it we= re crypto material. Which it cannot be, because multiple parties need to kno= w it (as I said, the proxy, the backend, the app developers, the support team, etc).  It=E2=80=99s defense by =E2= =80=9Ccollapsing layers=E2=80=9D rather than =E2=80=9Cin depth.=E2=80=9D

 

  • As with all defense in depth, the aim is to be more than 1 configuratio= n mistake away from total compromise.

But that is exactly what you are proposing. Exposing t= he header *is* a total compromise and multiple entities will need to k= now that header value.

 

At any rate,  I think we=E2=80=99re done here.

 

= --Apple-Mail-E6C615FD-1991-4CFA-8594-62B336B2042E-- From nobody Wed Oct 30 12:22:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B10120A32 for ; Wed, 30 Oct 2019 12:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgjxlSUyvy-D for ; Wed, 30 Oct 2019 12:22:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D8C7B120AA4 for ; Wed, 30 Oct 2019 12:22:11 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9UJM9Ph030868; Wed, 30 Oct 2019 19:22:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=isvxoLdx5JSXNLNPlucF/JigKHQAMzeaMBhMCbIXlN0=; b=LGWxmnIgzGNCvdUhwsmlXjtEJD1oS99LfR8zJajc73LkV/2Vte4hTqq17wl9sGrpDl9n HWxrFTdlb0pfxkVMeWHUwnXKQmXGel17xQ2ePQJOvJYuq5FTD6mwU9B1nyfcpcCXM9GZ y0A9Y6zjXfkReWlj/rEQ8oRIKRLxPgUQxTln6EOy9UkReGNA2nkfEf/jsOcPWdCowkCN Sg6c2IXaFI2AE03Eab48pv30NHGvwXvF+7ObW6omLsTr6XLRvMmy5sJTMC322DewYzZ7 V6fr01/f+DV6jPCCZdGqgX5H/1CLUpuvDJuqzTkSkW+mzGCNWOOj4XjBvJxpKVRCvVhU xQ== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2vxwgfvppb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 19:22:09 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9UJHEAV020051; Wed, 30 Oct 2019 15:22:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2vxwfre8ha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 15:22:07 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 15:22:05 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 15:22:05 -0400 From: "Salz, Rich" To: Neil Madden CC: Justin Richer , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAA0ZsAgABfMACAAAkLAP//v+yAgABJiYD//+FxAIAASVSA///BWAAADIi8gP//vfWA Date: Wed, 30 Oct 2019 19:22:05 +0000 Message-ID: <586BE278-76E8-4DCE-BA4D-0A901FB91BFF@akamai.com> References: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com> <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com> In-Reply-To: <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.191] Content-Type: multipart/alternative; boundary="_000_586BE27876E84DCEBA4D0A901FB91BFFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-30_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=490 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910300166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_08:2019-10-30,2019-10-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 mlxlogscore=479 phishscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910300167 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 19:22:17 -0000 --_000_586BE27876E84DCEBA4D0A901FB91BFFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IHN0cmlwIG9mZiB0aGUgVExTLCB5b3UgKnN0aWxsKiBjYW5ub3QgcGFzcyBtZXNzYWdl cyBhcm91bmQgd2l0aG91dCBwcm90ZWN0aW5nIHRoZW0gYXMgaWYgdGhleSBoYWQgc2VjcmV0cyBi ZWNhdXNlLCB3ZWxsLCB0aGUgaGVhZGVyIG5hbWUgeW91IGFyZSB1c2luZyBpcyBzZWNyZXQuICBU aGlzIGlzIG5vdCBhIGRlZmVuc2UgaW4gZGVwdGguDQo= --_000_586BE27876E84DCEBA4D0A901FB91BFFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <322AFDCE31D202409AE80A8BC9B0A10F@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxODI0MDA4MTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MjcyNzQ1 ODI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0MTQ0Nzg5MjY7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi04ODg3NzkxNzQ7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDo3MjUyNTMwMjk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzc4NzcyMTA4O30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTU4ODQxNTc2NjsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE2MTM1Nzk4NCAtMTk3MzI1ODMxMiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwz OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE1 ODk3MzM1Mzg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjg5MTEzODQ0O30NCkBsaXN0IGw0 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3Ugc3RyaXAgb2ZmIHRoZSBUTFMsIHlvdSAqPGI+c3RpbGw8L2I+KiBjYW5ub3QgcGFz cyBtZXNzYWdlcyBhcm91bmQgd2l0aG91dCBwcm90ZWN0aW5nIHRoZW0gYXMgaWYgdGhleSBoYWQg c2VjcmV0cyBiZWNhdXNlLCB3ZWxsLCB0aGUgaGVhZGVyIG5hbWUgeW91IGFyZSB1c2luZyBpcyBz ZWNyZXQuJm5ic3A7IFRoaXMgaXMgbm90IGEgZGVmZW5zZSBpbiBkZXB0aC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_586BE27876E84DCEBA4D0A901FB91BFFakamaicom_-- From nobody Wed Oct 30 13:04:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3E120106 for ; Wed, 30 Oct 2019 13:04:50 -0700 (PDT) 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 jp9gxtN9KKRR for ; Wed, 30 Oct 2019 13:04:47 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFE2120018 for ; Wed, 30 Oct 2019 13:04:47 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id 205so2843413qkk.1 for ; Wed, 30 Oct 2019 13:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WLTqSL5AFTDCIYyNLOr89qM++DwgmbKAF2nLGtPPtwI=; b=OcvHlFDD0fCjzJoLwgOk/9Tvssl4tTou7G02WBOk0uJu2MoHIZI4YWDvgnSO8ut7gB e6LRQrkF3+pEw9hRaGXlzcf3yHfqsp5L2HDaKa6GsVJ9NZa0pz+LVxE4vQubfQE1+iyu kWmQWIfbAuFfAmBDDR6Yiph+zsbIbBbOleP1jIyXroOi83TXptaeaByzCSykhQGT0D+L 2Oy0kXv2aLRT2kh8uv4j28A3waPwF3eryspcOT3xgES9pSZzhEpZ89kFyJU0yEC5Plvd 4wlC/P5F3/prr5bQQo/g0iz9OvLbIgE442TtYRx6CyNyYC5rzZgrxBIZMjni954mmHCX JGXQ== 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=WLTqSL5AFTDCIYyNLOr89qM++DwgmbKAF2nLGtPPtwI=; b=lDU+T+BHbtPPnQ+vCX9Sk4KWDVHoaFdymu0DvSGEtJNf8EITb7BmfQJNBzGkqbYgCv 8NVHrkzCtcGl178qw40mZAgExTu2KJTak9c3XDq07y0b7vFKBfD0ZwxecR0iLYh0JZUz 6MqRQRa/CNTEhJTB29wOZbcE7isattHaEJfSuTZmckSVk3xQjZmtPkemWX/HR8ZBgZtH BgUpgd1OmQuos40BNdaKWwkwqdJZQPEN/HkgEo3BVRwVkRloZiesJkSv9v8Ce7YI7eiW 92gjfo2AvSADwl/jff6lUvNsFAXjecN4tjqQTA6i9CbDwPNfQZ+FW00sV7aNRuyK5//x bAsw== X-Gm-Message-State: APjAAAXoAUva1EG+/sTemWqZRhfh0yuSOK+lt04Tzuie18EeByWkfGJN MADdC2R0Lv31ElZRFFK/h0+dOg== X-Google-Smtp-Source: APXvYqwNODeUYQ2XSekrrYA8gp3bIiodsRQcGT+P2D3omfFaqtFENUidfduJRx/u6BbKdnCX6EMQUg== X-Received: by 2002:a37:7705:: with SMTP id s5mr1790660qkc.145.1572465886359; Wed, 30 Oct 2019 13:04:46 -0700 (PDT) Received: from [10.70.216.108] (mobile-166-171-185-187.mycingular.net. [166.171.185.187]) by smtp.gmail.com with ESMTPSA id f35sm699080qtd.35.2019.10.30.13.04.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 13:04:45 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-451963F3-A7E3-442D-84D8-513DCB5D0E97 Content-Transfer-Encoding: 7bit From: Jim Manico Mime-Version: 1.0 (1.0) Date: Wed, 30 Oct 2019 16:04:44 -0400 Message-Id: <8096E863-0022-4F98-BE88-E56941A7892E@manicode.com> References: <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com> Cc: "Salz, Rich" , Brian Campbell , oauth In-Reply-To: <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com> To: Neil Madden X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 20:04:50 -0000 --Apple-Mail-451963F3-A7E3-442D-84D8-513DCB5D0E97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I love you Neil. -- Jim Manico @Manicode > On Oct 30, 2019, at 3:18 PM, Neil Madden wrote= : >=20 > =EF=BB=BF > If you can point out where I recommended disabling TLS or not bothering to= strip headers from incoming requests, or anything else along those lines th= en please let me know. Otherwise, yes we=E2=80=99re done here.=20 >=20 >>> On 30 Oct 2019, at 17:19, Salz, Rich wrote: >>>=20 >> =EF=BB=BF >> To quote your previous claim: "There is no such thing as an unguessable n= ame." >> Right. That doesn=E2=80=99t mean *I* have to guess it. >>=20 >> Even if your deployment team had such staggeringly bad operational securi= ty practices as to allow people to take packet captures from an internal net= work and show them on public slides without any kind of questions being aske= d, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION WHER= E YOU USED A WELL-KNOWN HEADER NAME*! >> Yes you are worse off. Because that now-exposed header value can be used= for spoofing. As opposed to protection by TLS, and then sending the plaint= ext message around. >> =20 >> I don't know how many different ways I can say that this is a defense in d= epth >> Because it is not. It is taking an application-level piece of configurat= ion data and requiring it to be treated as if it were crypto material. Which= it cannot be, because multiple parties need to know it (as I said, the prox= y, the backend, the app developers, the support team, etc). It=E2=80=99s de= fense by =E2=80=9Ccollapsing layers=E2=80=9D rather than =E2=80=9Cin depth.=E2= =80=9D >> =20 >> As with all defense in depth, the aim is to be more than 1 configuration m= istake away from total compromise. >> But that is exactly what you are proposing. Exposing the header *is* a to= tal compromise and multiple entities will need to know that header value. >> =20 >> At any rate, I think we=E2=80=99re done here. >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-451963F3-A7E3-442D-84D8-513DCB5D0E97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I love you Neil.

<= div>--
Jim Manico
@Manicode
=
On Oct 30, 2019, at 3:18 PM, Neil Madden <n= eil.madden@forgerock.com> wrote:

=EF=BB=BF
If you can point out whe= re I recommended disabling TLS or not bothering to strip headers from incomi= ng requests, or anything else along those lines then please let me know. Oth= erwise, yes we=E2=80=99re done here. 

On 30 Oct 2019, at 17:19, Salz, Rich <rsalz@akamai.com= > wrote:

=EF=BB=BF
  • To quote yo= ur previous claim: "There is no such thing as an unguessable name."

Right.  That doesn=E2=80=99t mean *I* hav= e to guess it.

  • Even if you= r deployment team had such staggeringly bad operational security practices a= s to allow people to take packet captures from an internal network and show t= hem on public slides without any kind of questions being asked, if this actually happens *YOU ARE NO WORSE O= FF THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*!

Yes you are worse off.  Because that now-exposed= header value can be used for spoofing.  As opposed to protection by TL= S, and then sending the plaintext message around.

 

  • I don't kno= w how many different ways I can say that this is a defense in depth

Because it is not.  It is taking an application-= level piece of configuration data and requiring it to be treated as if it we= re crypto material. Which it cannot be, because multiple parties need to kno= w it (as I said, the proxy, the backend, the app developers, the support team, etc).  It=E2=80=99s defense by =E2= =80=9Ccollapsing layers=E2=80=9D rather than =E2=80=9Cin depth.=E2=80=9D

 

  • As with all defense in depth, the aim is to be more than 1 configuratio= n mistake away from total compromise.

But that is exactly what you are proposing. Exposing t= he header *is* a total compromise and multiple entities will need to k= now that header value.

 

At any rate,  I think we=E2=80=99re done here.

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= = --Apple-Mail-451963F3-A7E3-442D-84D8-513DCB5D0E97-- From nobody Thu Oct 31 03:36:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE501200FE for ; Thu, 31 Oct 2019 03:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 eMkulxBuW2DI for ; Thu, 31 Oct 2019 03:36:54 -0700 (PDT) Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.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 2ECE51200F6 for ; Thu, 31 Oct 2019 03:36:54 -0700 (PDT) Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q7owiFuyIyg8JQ7oyiMO47; Thu, 31 Oct 2019 03:36:52 -0700 To: oauth@ietf.org References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Organization: Connect2id Ltd. Message-ID: Date: Thu, 31 Oct 2019 12:36:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------110BC3B770F4B2B4411903F1" Content-Language: en-US X-CMAE-Envelope: MS4wfIll0R9Jh/8PW0sdT8G/D286d9BV/SRFUwZi0bkafbmgqedxFlem7LRV7Y4jvCaYjSg/ZyNAl39TiUJcbbVxIh5Tr2D7hCM2cDcuypUhuW93LWbvD1BG BvobKTZcQdb3gv3UgStCKvgXfcqSORt22giMUtvudAi/jmseSfnQXq6U Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 10:36:56 -0000 This is a multi-part message in MIME format. --------------110BC3B770F4B2B4411903F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit > All in all, I am in favor of this being defined in one standard way, > in addition to secure communication between proxies and backends being > standardized — but this latter bit really seems like a separate problem. > >  — Justin -1 for devising a well known header +1 for a simple way to authenticate a reverse proxy with a web server With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. And if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight. Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>= 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far. https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed. Here is an example Apache httpd config, to illustrate my point: RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "" RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s" (the first line strips the inbound headers) Vladimir -- Vladimir Dzhuvinov --------------110BC3B770F4B2B4411903F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
All in all, I am in favor of this being defined in one standard way, in addition to secure communication between proxies and backends being standardized — but this latter bit really seems like a separate problem.

 — Justin

-1 for devising a well known header

+1 for a simple way to authenticate a reverse proxy with a web server

With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. And if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight.

Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>= 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far.

https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader

Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed.

Here is an example Apache httpd config, to illustrate my point:

RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"

(the first line strips the inbound headers)


Vladimir

-- 
Vladimir Dzhuvinov
--------------110BC3B770F4B2B4411903F1-- From nobody Thu Oct 31 03:49:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB11200F6 for ; Thu, 31 Oct 2019 03:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=zmartzone-eu.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 7kRrixzQu7-2 for ; Thu, 31 Oct 2019 03:48:58 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4049B1200E6 for ; Thu, 31 Oct 2019 03:48:58 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 15so6477177qkh.6 for ; Thu, 31 Oct 2019 03:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYmUv4W5+wbHMnMvQMYskBzah5zwKRUeh0W8IhcExIQ=; b=IccRVxhmiB/l80fX8IVXzjhau1g8uS9F5FuLd//efQuH08C3pQCpIVO+b1/IKgkL6Z ZKfU4PEG1hhIxlDHDheGoemAHb7IjIqRv2djINdNxtfeV0yPIcxDMFucH589Te72nMWw 93LAZDZhqc0D/Fm/Ax+xEZ5hKBr/z2QqcNu3lnFHOFMbYvT4m+yxqdSgNcJRmk2SCBY4 Te3bYSSt5yWfVjNQuhPhrQ7ScWfJD6mELzQFkNlVsZ+a/z7Gt0xM0ydMBTL5QqlpFWPW 0d1En2TN4EInD8QF1aSsMt4gGI+jidpHnU35UVjbkJnpisnoNeOrnl+fyc7GlhPJ0Vo8 nf/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=XYmUv4W5+wbHMnMvQMYskBzah5zwKRUeh0W8IhcExIQ=; b=Lb//FjHe3aDGcEvy33f6XeKi+LajJj8DOTaIurMrl8nIfsWeD/6ci4ac+neqSfhiUJ ASoLGgsAkVGuZF5deymMBppPassxui6QdH+BV8vsbOuNMf1iNtVU4DYqLLyKuCOYlmtx ixddW0xXCJ8PRzGg30I3YGjcOGmFG8ohucuChhsKa+U1yB4ngc4nuTDdAWCa+y+Z/srY Px3r8Avsq/vxbYq8Hp+k9tMQbleGn44svknUyIK1Adb176SAntnGj4eMWyhmD9yO63Bu svLJYPVQktSaQyuDGHv7HcQ5wX8aU1T59vFJaihd6LGvx2SP0WfzGyniCsybaDH6bair yg1g== X-Gm-Message-State: APjAAAWmRSh5IZTYe6YP6irEEBpqjXa/O8mlaZ2OwQ5wenOzimUXC++q U2yXzzwjZykkson7dotYtbfPyQBO4/Bsm9mabV5UYQ== X-Google-Smtp-Source: APXvYqzNk3miHwpMYpaNzzvAOMzdhKbyXdiAW1HcY1UqotEpT5qN5rL0pqYxcuHhpoirwrPm8ShM5MkQrldgAmrEIjE= X-Received: by 2002:a37:e40d:: with SMTP id y13mr4575871qkf.478.1572518937129; Thu, 31 Oct 2019 03:48:57 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> In-Reply-To: From: Hans Zandbelt Date: Thu, 31 Oct 2019 11:48:46 +0100 Message-ID: To: Vladimir Dzhuvinov Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a68da40596329806" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 10:49:01 -0000 --000000000000a68da40596329806 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable the way I see this is that stripping and setting the headers must be part of the implementation of the protocol itself, it should not be something left to a non-atomic piece of configuration by an administrator; I implemented it like this in the Apache implementation of Brian's TTRP spec [1] and have been doing this for the OIDC and OAuth Apache modules that set headers for backends to consume [2]; and yes, I have made mistakes [3], but IMHO it should not be a problem to use a well known header and make the implementer (not the admin) get it right by pointing this out in the spec, as is done for many other pitfalls Hans. [1] https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_bi= nding.c#L481-L483 [2] https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_open= idc.c#L164-L175 [3] https://www.cvedetails.com/cve/CVE-2017-6413/ On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov wrote: > All in all, I am in favor of this being defined in one standard way, in > addition to secure communication between proxies and backends being > standardized =E2=80=94 but this latter bit really seems like a separate p= roblem. > > =E2=80=94 Justin > > -1 for devising a well known header > > +1 for a simple way to authenticate a reverse proxy with a web server > > With a well known name, in a attack this will get probed first. The well > known header name doesn't guarantee a correct config. And if we have a ne= w > standard for sec headers that must be stripped automatically from inbound > HTTP requests, we cannot expect that will get implemented in all reverse > proxy software overnight. > > Because a correct config is not practical as the only line of defense, > when we implemented mTLS we decided to add a length (>=3D 32 chars) and > randomness check to the header config. I saw some concerns that this may > cause deployment issues. Nobody has complained about that so far. > > > https://connect2id.com/products/server/docs/config/core#op-tls-clientX509= CertHeader > > Regarding mistyping, this can be an issue, but has little to no effect if > a long random header gets misstyped (from the inbound strip directive). > With a well known header this will result in a immediate security hole, > which can theoretically go unnoticed. > > Here is an example Apache httpd config, to illustrate my point: > > RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "= " > RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "= %{SSL_CLIENT_CERT}s" > > (the first line strips the inbound headers) > > > Vladimir > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000a68da40596329806 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the way I see this is that stripping and = setting the headers must be part of the implementation of the protocol itse= lf, it should not be something left to a non-atomic piece of configuration = by an administrator; I implemented it like this in the Apache implementatio= n of Brian's TTRP spec [1] and have been doing this for the OIDC and OA= uth Apache modules that set headers for backends to consume [2]; and yes, I= have made mistakes [3], but IMHO it should not be a problem to use a well = known header and make the implementer (not the admin) get it right by point= ing this out in the spec, as is done for many other pitfalls

=
Hans.


On T= hu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20
All in all, I am in favor of this being defined in one standard way, in addition to secure communication between proxies and backends being standardized =E2=80=94 but this latter b= it really seems like a separate problem.

=C2=A0=E2=80=94 Justin

-1 for devising a well known header

+1 for a simple way to authenticate a reverse proxy with a web server

With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. An= d if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight.

Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>=3D 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far.

https://connect2id.com/produc= ts/server/docs/config/core#op-tls-clientX509CertHeader

Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed.

Here is an example Apache httpd config, to illustrate my point:

RequestHeader set Sec-Client-X509-Cert-liede=
5vaePeeMiYie0xu2jaudauleing ""
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing &qu=
ot;%{SSL_CLIENT_CERT}s"

(the first line strips the inbound headers)


Vladimir

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


--
--000000000000a68da40596329806-- From nobody Thu Oct 31 04:01:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD501201DC for ; Thu, 31 Oct 2019 04:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 f7V_myeBiZTD for ; Thu, 31 Oct 2019 04:00:58 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) (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 747B21200FE for ; Thu, 31 Oct 2019 04:00:58 -0700 (PDT) Received: from [84.158.231.244] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iQ8CB-0005eq-Do; Thu, 31 Oct 2019 12:00:51 +0100 From: Torsten Lodderstedt Message-Id: <9046A7E3-4917-4213-8947-888D428EF2F4@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_B6ACEA9F-1D11-4FB5-B757-4E6DA0B247B4"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Thu, 31 Oct 2019 12:00:50 +0100 In-Reply-To: <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com> Cc: Justin Richer , Brian Campbell , oauth To: Neil Madden References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net> <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com> X-Mailer: Apple Mail (2.3601.0.10) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 11:01:02 -0000 --Apple-Mail=_B6ACEA9F-1D11-4FB5-B757-4E6DA0B247B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30. Oct 2019, at 15:15, Neil Madden = wrote: >=20 > On 30 Oct 2019, at 14:05, Torsten Lodderstedt = wrote: >>> On 30. Oct 2019, at 14:56, Neil Madden = wrote: >>>=20 >>> On 30 Oct 2019, at 13:24, Justin Richer wrote: >>>>=20 >>>> All of these problems can be solved, and I think solved better, by = securing the connection between the proxy and the back-end. That way the = back end will be able look not only for a specific header, but verify = that the header came from the proxy itself. An obscure header name is = one way to do that, but it has a lot of issues with it, especially since = it=E2=80=99s likely to be selected once during set-up and never changed = throughout the lifetime of the deployment. I think there are likely much = better solutions here, and they=E2=80=99d address this issue without = things getting weird. >>>=20 >>> The issue has nothing to do with the security of the connection = between the proxy and the backend. It is to do with data origin = authentication of the headers themselves. All of the headers arrive at = the backend over the same connection, but only some of them were created = by the proxy. There are undoubtedly better alternatives - e.g. using a = shared secret to compute a HMAC over security sensitive headers and = include that as an additional header or field. But an unguessable header = name is *simple* and effective and works right now with widely = implemented functionality.=20 >>>=20 >>> There's no need for the header name to ever change - the secret is = not exposed to untrusted parties >>=20 >> If the proxy sends certs via an header X to service A and B and = someone impersonates A it will find out the secret and use it to inject = certs in a connection towards B. >=20 > Being able to impersonate A suggests that the attacker is already on = the trusted side of the network and that you are employing zero = additional network security controls between the RP and service A and B = (e.g., TLS, firewalls, VLAN/switches, etc). Remember, this is intended = to mitigate against accidental misconfiguration of the RP and header = spoofing tricks coming from the external network. I'm not suggesting it = as an alternative to basic network security on the trusted network. Is there such a thing as a trusted network? I=E2=80=99m not sure what = you mean but micro services call each other so network segregation would = not help to prevent replay of a leaked security header. But (see below) = different secret headers can be used to mitigate the threat I raised (at = least limit the impact to an individual service). >=20 >> We have learned that it is sometime hard to use different secret = header names for the same purpose with different request targets. In = those cases, a way to authenticate the proxy might by a good solution. =20= >=20 > Do you have an example? I checked back and it seems I had misunderstood. It=E2=80=99s possible = to use different secret header names, one per proxy-to-service = connection.=20 > The RPs and load balancers I'm familiar that support multiple backends = all support sending different headers to each of them. Again though, = security against attackers inside the trusted network is not part of = what the solution is preventing. >=20 > Again, authenticating the *connection* from the RP to the backend = services is good, but is completely orthogonal to authenticating the = headers themselves. >=20 > -- Neil >=20 >=20 --Apple-Mail=_B6ACEA9F-1D11-4FB5-B757-4E6DA0B247B4 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 Fw0xOTEwMzExMTAwNTBaMC8GCSqGSIb3DQEJBDEiBCDA9oyODwnfONLkWJAWUGdE8ctRShMl4g9c DnqWYQpluzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAFAhJVWwnlBUkfGBq54t5HWUbMAKRpIq02Ze1meoIs2+EQ3jxIB2ypQYoOEZ 5cIUiB5sLipN0muL8xDyaOZis7rWgrI1ryqY2lw1VBbN2BcL7Qsmo48vw0VmeaF3aDmocTcwLVIL QNcvKdu9x+jTClM48ACRr+oDCmKrkYupiChfSLQuC/thIVgnJxs2Ia4rPYDFIWNI7qHKb9h6NrS5 2IG4jR8r+xNUd+Y7WRN5oghlNgho7NHFyOAYSgvA1BT4wRsBRpwl5PM+ttu9HXFOr5CPT+FUYKGh hufG5qBTsgWBzjxFe7ykzSYgEvobKZXy/69fvt9Vg4i92qSaNjup0S8AAAAAAAA= --Apple-Mail=_B6ACEA9F-1D11-4FB5-B757-4E6DA0B247B4-- From nobody Thu Oct 31 04:26:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F3120142 for ; Thu, 31 Oct 2019 04:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IMhNUtP_Yxn4 for ; Thu, 31 Oct 2019 04:26:03 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8C612001E for ; Thu, 31 Oct 2019 04:26:03 -0700 (PDT) Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q8aUii6363heuQ8aXi3FwW; Thu, 31 Oct 2019 04:26:02 -0700 To: "oauth@ietf.org" References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Organization: Connect2id Ltd. Message-ID: <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> Date: Thu, 31 Oct 2019 13:25:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9D7F0DEFFF4C959964304F95" Content-Language: en-US X-CMAE-Envelope: MS4wfAntFSfCUt1ev6VNT8sT6k5Wc9cMYUd0Vflc8iKN4J/Y2y6LMYVhG7noXw2LXtZ2hufyHAnQRc+ubiEm9+An67UdcHverZSiZbyki9rlcFMaZcvRuGOf DFn03YgYWgMsh3s4yHqg+TFYMmv4k17AwDEIl48brGIAgC9l+PEz4fl0 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 11:26:05 -0000 This is a multi-part message in MIME format. --------------9D7F0DEFFF4C959964304F95 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is a good story. How about requiring reverse proxies to automatically scrub all inbound HTTP headers that start with "Sec-"? If a sec header has the format "Sec-[NAME]-[random-chars]" we get: * The "Sec-" prefix will  cause new compliant reserve proxies to automatically scrub the inbound HTTP header. * The NAME part still makes the header easily identifiable (I think Rich Salz had this concern). * The random chars part, potentially optional, will provide a line of defence against config errors in old legacy reverse proxies. All concerns should then get covered. Vladimir On 31/10/2019 12:48, Hans Zandbelt wrote: > the way I see this is that stripping and setting the headers must be > part of the implementation of the protocol itself, it should not be > something left to a non-atomic piece of configuration by an > administrator; I implemented it like this in the Apache implementation > of Brian's TTRP spec [1] and have been doing this for the OIDC and > OAuth Apache modules that set headers for backends to consume [2]; and > yes, I have made mistakes [3], but IMHO it should not be a problem to > use a well known header and make the implementer (not the admin) get > it right by pointing this out in the spec, as is done for many other > pitfalls > > Hans. > > [1] https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483 > [2] https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175 > [3] https://www.cvedetails.com/cve/CVE-2017-6413/ > > On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov > > wrote: > >> All in all, I am in favor of this being defined in one standard >> way, in addition to secure communication between proxies and >> backends being standardized — but this latter bit really seems >> like a separate problem. >> >>  — Justin > > -1 for devising a well known header > > +1 for a simple way to authenticate a reverse proxy with a web server > > With a well known name, in a attack this will get probed first. > The well known header name doesn't guarantee a correct config. And > if we have a new standard for sec headers that must be stripped > automatically from inbound HTTP requests, we cannot expect that > will get implemented in all reverse proxy software overnight. > > Because a correct config is not practical as the only line of > defense, when we implemented mTLS we decided to add a length (>= > 32 chars) and randomness check to the header config. I saw some > concerns that this may cause deployment issues. Nobody has > complained about that so far. > > https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader > > Regarding mistyping, this can be an issue, but has little to no > effect if a long random header gets misstyped (from the inbound > strip directive). With a well known header this will result in a > immediate security hole, which can theoretically go unnoticed. > > Here is an example Apache httpd config, to illustrate my point: > > RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "" > RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s" > > (the first line strips the inbound headers) > > > Vladimir > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu -- Vladimir Dzhuvinov --------------9D7F0DEFFF4C959964304F95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This is a good story.

How about requiring reverse proxies to automatically scrub all inbound HTTP headers that start with "Sec-"?

If a sec header has the format "Sec-[NAME]-[random-chars]" we get:

* The "Sec-" prefix will  cause new compliant reserve proxies to automatically scrub the inbound HTTP header.

* The NAME part still makes the header easily identifiable (I think Rich Salz had this concern).

* The random chars part, potentially optional, will provide a line of defence against config errors in old legacy reverse proxies.

All concerns should then get covered.

Vladimir

On 31/10/2019 12:48, Hans Zandbelt wrote:
the way I see this is that stripping and setting the headers must be part of the implementation of the protocol itself, it should not be something left to a non-atomic piece of configuration by an administrator; I implemented it like this in the Apache implementation of Brian's TTRP spec [1] and have been doing this for the OIDC and OAuth Apache modules that set headers for backends to consume [2]; and yes, I have made mistakes [3], but IMHO it should not be a problem to use a well known header and make the implementer (not the admin) get it right by pointing this out in the spec, as is done for many other pitfalls

Hans.


On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
All in all, I am in favor of this being defined in one standard way, in addition to secure communication between proxies and backends being standardized — but this latter bit really seems like a separate problem.

 — Justin

-1 for devising a well known header

+1 for a simple way to authenticate a reverse proxy with a web server

With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. And if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight.

Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>= 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far.

https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader

Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed.

Here is an example Apache httpd config, to illustrate my point:

RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"

(the first line strips the inbound headers)


Vladimir

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


-- 
-- 
Vladimir Dzhuvinov
--------------9D7F0DEFFF4C959964304F95-- From nobody Thu Oct 31 04:38:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B07120099 for ; Thu, 31 Oct 2019 04:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=zmartzone-eu.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 BplJiuKKxyL1 for ; Thu, 31 Oct 2019 04:38:28 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2126120074 for ; Thu, 31 Oct 2019 04:38:27 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id t26so8081610qtr.5 for ; Thu, 31 Oct 2019 04:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PvHm3gzqS+xhaK7B42AKQhn1w9C1/EReD70liZPY5sw=; b=SBPJXpsCP6Ef/EE4S3dLTp3ZW30ci9+lM7QjQUU27LhSjcte9DuZRBUbJr9oTogM32 VCkYP+fVDyb+oUaZk3FZ2TZn1kbGQVFQcWW/TYNzLJ+5WvMxaxIa+dhbb3D8DnjFMOEB 6Ur11eCmWgsjF/Y6Em0Ub5D+6GDit1sDkpPbR0vAadq9YEhg95reXS9WMMCBMqTW4bc0 hrE2DR+CCGfkOGyEqwIXqR01qCJKtM8dFGK1vH0rzMQNccF7PQeSGtdHGxQ3237MRzM9 nUn06JV8EftRPaxMgksSBdczc9zXnlqjOOfMXDurqtaqDaMSAZIRUUu0Cko/ceeRjqgN 7ymA== 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=PvHm3gzqS+xhaK7B42AKQhn1w9C1/EReD70liZPY5sw=; b=uYJQvs0pdtE9xmkcvUSXeDkjOxwQqrvE3jgIeaNtTV79PUwBxZfaAg4gr7C8rJiIWq CN4BE+oYwaLlDxa9jEDpxY9t3qcT+PWFX5Q7jY7asPxBm0zF3d0ADYc1w6JsXjPAOr5S IUYK92NyZtBc6BzA+CyweK+J3p7pvHvlkHMCpICBdHjJwUc0+243kaoLVIk+2yAxwRBo G2v0njicrukxcSi988s6tpf4vZB8CR06tNJHO3T8/Fg6MDXQSPi/RByU3PhUu78LofkA XTtmLWe80/CY6hQM8D+JWTZYOyHhXA6f6+stEt8xfK7SYr7JvWdI0foDyT/UjtGQbhYo 4PqQ== X-Gm-Message-State: APjAAAWwAnY/VwHjv0W90mXeqvrYcoaNAoeGGkoES6fNB6jA6OGbVg+3 8w9Dby3csDVeViwh/aE/+KsOwyhoQreNw4hk1yegE2nG1MU= X-Google-Smtp-Source: APXvYqxv1j/3tR1r/9jO/vRS53pfPad34jDjxkGv8Jsvsrz6fTQ/xA0SakF6Tj08Tu/pUwfRvVByx7Qb4EEQSjgQI7M= X-Received: by 2002:ac8:4149:: with SMTP id e9mr4834617qtm.321.1572521906766; Thu, 31 Oct 2019 04:38:26 -0700 (PDT) MIME-Version: 1.0 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> In-Reply-To: <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> From: Hans Zandbelt Date: Thu, 31 Oct 2019 12:38:15 +0100 Message-ID: To: Vladimir Dzhuvinov Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a79b3a05963349b5" Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 11:38:31 -0000 --000000000000a79b3a05963349b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +10 On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov wrote: > This is a good story. > > How about requiring reverse proxies to automatically scrub all inbound > HTTP headers that start with "Sec-"? > > If a sec header has the format "Sec-[NAME]-[random-chars]" we get: > > * The "Sec-" prefix will cause new compliant reserve proxies to > automatically scrub the inbound HTTP header. > > * The NAME part still makes the header easily identifiable (I think Rich > Salz had this concern). > > * The random chars part, potentially optional, will provide a line of > defence against config errors in old legacy reverse proxies. > > All concerns should then get covered. > > Vladimir > On 31/10/2019 12:48, Hans Zandbelt wrote: > > the way I see this is that stripping and setting the headers must be part > of the implementation of the protocol itself, it should not be something > left to a non-atomic piece of configuration by an administrator; I > implemented it like this in the Apache implementation of Brian's TTRP spe= c > [1] and have been doing this for the OIDC and OAuth Apache modules that s= et > headers for backends to consume [2]; and yes, I have made mistakes [3], b= ut > IMHO it should not be a problem to use a well known header and make the > implementer (not the admin) get it right by pointing this out in the spec= , > as is done for many other pitfalls > > Hans. > > [1] > https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_= binding.c#L481-L483 > [2] > https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_op= enidc.c#L164-L175 > [3] https://www.cvedetails.com/cve/CVE-2017-6413/ > > On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> All in all, I am in favor of this being defined in one standard way, in >> addition to secure communication between proxies and backends being >> standardized =E2=80=94 but this latter bit really seems like a separate = problem. >> >> =E2=80=94 Justin >> >> -1 for devising a well known header >> >> +1 for a simple way to authenticate a reverse proxy with a web server >> >> With a well known name, in a attack this will get probed first. The well >> known header name doesn't guarantee a correct config. And if we have a n= ew >> standard for sec headers that must be stripped automatically from inboun= d >> HTTP requests, we cannot expect that will get implemented in all reverse >> proxy software overnight. >> >> Because a correct config is not practical as the only line of defense, >> when we implemented mTLS we decided to add a length (>=3D 32 chars) and >> randomness check to the header config. I saw some concerns that this may >> cause deployment issues. Nobody has complained about that so far. >> >> >> https://connect2id.com/products/server/docs/config/core#op-tls-clientX50= 9CertHeader >> >> Regarding mistyping, this can be an issue, but has little to no effect i= f >> a long random header gets misstyped (from the inbound strip directive). >> With a well known header this will result in a immediate security hole, >> which can theoretically go unnoticed. >> >> Here is an example Apache httpd config, to illustrate my point: >> >> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing = "" >> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing = "%{SSL_CLIENT_CERT}s" >> >> (the first line strips the inbound headers) >> >> >> Vladimir >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000a79b3a05963349b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+10

On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov= <vladimir@connect2id.com= > wrote:
=20 =20 =20

This is a good story.

How about requiring reverse proxies to automatically scrub all inbound HTTP headers that start with "Sec-"?

If a sec header has the format "Sec-[NAME]-[random-chars]"= we get:

* The "Sec-" prefix will=C2=A0 cause new compliant reserve= proxies to automatically scrub the inbound HTTP header.

* The NAME part still makes the header easily identifiable (I think Rich Salz had this concern).

* The random chars part, potentially optional, will provide a line of defence against config errors in old legacy reverse proxies.

All concerns should then get covered.

Vladimir

On 31/10/2019 12:48, Hans Zandbelt wrote:
=20
the way I see this is that stripping and setting the headers must be part of the implementation of the protocol itself, it should not be something left to a non-atomic piece of configuration by an administrator; I implemented it like this in the Apache implementation of Brian's TTRP spec [1] an= d have been doing this for the OIDC and OAuth Apache modules that set headers for backends to consume [2]; and yes, I have made mistakes [3], but IMHO it should not be a problem to use a well known header and make the implementer (not the admin) get it right by pointing this out in the spec, as is done for many other pitfalls

Hans.


On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
All in all, I am in favor of this being defined in one standard way, in addition to secure communication between proxies and backends being standardized =E2=80=94= but this latter bit really seems like a separate problem.

=C2=A0=E2=80=94 Justin

-1 for devising a well known header

+1 for a simple way to authenticate a reverse proxy with a web server

With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. And if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight.

Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>=3D 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far.

https://connect2id.= com/products/server/docs/config/core#op-tls-clientX509CertHeader

Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed.

Here is an example Apache httpd config, to illustrate my point:

RequestHeader set Sec-Client-X509-=
Cert-liede5vaePeeMiYie0xu2jaudauleing ""
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing &qu=
ot;%{SSL_CLIENT_CERT}s"

(the first line strips the inbound headers)


Vladimir

--=20
Vladimir Dzhuvinov
_______________________________________________
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


--
--000000000000a79b3a05963349b5-- From nobody Thu Oct 31 06:13:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC8F1201EA for ; Thu, 31 Oct 2019 06:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVwWh-TeNDIF for ; Thu, 31 Oct 2019 06:13:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9E9A7120288 for ; Thu, 31 Oct 2019 06:13:15 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9VDCeUn032214; Thu, 31 Oct 2019 13:13:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=2ZxLOEmLIpts1spC0Z51gjQJ+CgJ+jFMYowaI+kpmNY=; b=Ht7mEZeuNUq4ag7AMF9SlsxfMdFyFsxgVaqqk8a2bRGbxapR5OJV7l8KGNoFbcz5ikld l/xZLALtMuLa2Fk4KPp3n3aOXlrDUAmEP3Ke2kJZkMUcVbiYZrgNlHNFEgvzif0SfDID wwxLxHkwjAUVOUaE9dFamSsxwEsklSTElRkJSTyhlFJClzZF+HmXRJsAaNqZxZLUPoFT EqPBYySbVgEcAUvBZbaFEOJubhxJkQChE/ZOKjdmfjo2ZSpsP9ARZAmpKNtOgnl6nNmW TbgnNFLU8jK+2Wuu4+aPye8/FCOCOtzTMW2Bl39T6oshzSotvf+y8nvzpLM6STGv6wzi Lg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vxwgjrr4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 13:13:09 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9VD5qkG003706; Thu, 31 Oct 2019 09:13:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2vxwfp14tp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 09:13:07 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 31 Oct 2019 09:13:06 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 31 Oct 2019 09:13:06 -0400 From: "Salz, Rich" To: Hans Zandbelt , Vladimir Dzhuvinov CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAALTaAgAJnDoCAAANXAIAACmUAgAADboD//9dyAA== Date: Thu, 31 Oct 2019 13:13:06 +0000 Message-ID: References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.234] Content-Type: multipart/alternative; boundary="_000_AE622747BB014275A626C19D2681D0E2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-31_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=627 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910310135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-31_05:2019-10-30,2019-10-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=615 clxscore=1011 lowpriorityscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910310137 Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 13:13:18 -0000 --_000_AE622747BB014275A626C19D2681D0E2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0IHJlcXVpcmluZyByZXZlcnNlIHByb3hpZXMgdG8gYXV0b21hdGljYWxseSBzY3J1 YiBhbGwgaW5ib3VuZCBIVFRQIGhlYWRlcnMgdGhhdCBzdGFydCB3aXRoICJTZWMtIj8NCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWh0dHBiaXMtY2xpZW50LWhpbnRzLTA3 DQoNCk1ha2luZyBhIGhlYWRlciB2YWx1ZSDigJxzZWNyZXTigJ0gd2lsbCBub3QgcHJvdGVjdCBh bnl0aGluZy4NCg== --_000_AE622747BB014275A626C19D2681D0E2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwPkhvdyBhYm91dCByZXF1 aXJpbmcgcmV2ZXJzZSBwcm94aWVzIHRvIGF1dG9tYXRpY2FsbHkgc2NydWIgYWxsIGluYm91bmQg SFRUUCBoZWFkZXJzIHRoYXQgc3RhcnQgd2l0aCAmcXVvdDtTZWMtJnF1b3Q7PzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWh0dHBiaXMtY2xpZW50LWhpbnRzLTA3 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1odHRwYmlzLWNsaWVudC1o aW50cy0wNzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1ha2luZyBhIGhlYWRl ciB2YWx1ZSDigJxzZWNyZXTigJ0gd2lsbCBub3QgcHJvdGVjdCBhbnl0aGluZy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AE622747BB014275A626C19D2681D0E2akamaicom_-- From nobody Thu Oct 31 09:45:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861EA120052 for ; Thu, 31 Oct 2019 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 h7rB_apqXV2a for ; Thu, 31 Oct 2019 09:45:27 -0700 (PDT) Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.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 32E0312002F for ; Thu, 31 Oct 2019 09:45:27 -0700 (PDT) Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id QDZbiH8wcyg8JQDZdiMnX7; Thu, 31 Oct 2019 09:45:26 -0700 References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191024170326.GO69013@kduck.mit.edu> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> To: "oauth@ietf.org" From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Organization: Connect2id Ltd. Message-ID: <5e8f7135-0b3a-fa06-a536-fa92f58aff4b@connect2id.com> Date: Thu, 31 Oct 2019 18:45:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3044A5F75AA64748C344A917" Content-Language: en-US X-CMAE-Envelope: MS4wfNWTCpBwxijzkTbyYl27T1t8JSBSW8qoI4JmCq7AijscpOVEg7fz33oRALUlTHcMzu5OmIzx9OLipLBrcuRkrqGyMbuMXqqxDlrsYuh6aqQxPOOOfTQT e5cxLJ9F82jSMDwSZ9yUxzhITq3VWFtt5Wn+0s6tGoJHhHi2jt/pVa5W Archived-At: Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 16:45:30 -0000 This is a multi-part message in MIME format. --------------3044A5F75AA64748C344A917 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks for this note. According to the abstract the advertising is intended for "request headers for proactive content negotiation" (Accept-*), which should exclude all other types of header. I looked at the Security Considerations and wrote to the author with the suggestion to note that implementations must be careful not to advertise any other names, e.g. the names of headers intended to be set by the proxy for use by a web server. Vladimir On 31/10/2019 15:13, Salz, Rich wrote: > > How about requiring reverse proxies to automatically scrub all inbound > HTTP headers that start with "Sec-"? > > https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07 > >   > > Making a header value “secret” will not protect anything. > --------------3044A5F75AA64748C344A917 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks for this note. According to the abstract the advertising is intended for "request headers for proactive content negotiation" (Accept-*), which should exclude all other types of header. I looked at the Security Considerations and wrote to the author with the suggestion to note that implementations must be careful not to advertise any other names, e.g. the names of headers intended to be set by the proxy for use by a web server.

Vladimir

On 31/10/2019 15:13, Salz, Rich wrote:

How about requiring reverse proxies to automatically scrub all inbound HTTP headers that start with "Sec-"?

https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07

 

Making a header value “secret” will not protect anything.


  


--------------3044A5F75AA64748C344A917--


From nobody Thu Oct 31 11:55:41 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EDC12000F for ; Thu, 31 Oct 2019 11:55:39 -0700 (PDT)
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 I8E7BaVZGoMg for ; Thu, 31 Oct 2019 11:55:36 -0700 (PDT)
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 D044312006A for ; Thu, 31 Oct 2019 11:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1572548134; x=1604084134; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9KIBbfXDeLG44nEMJtAM79/UOJN4cB1sS9iJEa98bOo=; b=UvsfvBisvO4WQfAEH+fIvdg+8rcjWdYpPECiYQ7phDdB4SDBCktV12Ij E8ruFiXG/0uLMS7g2XiNy4VeOmCcSUqyaAAjoq60C4lOTr7FEURUqZPZp TMMuoIyI91yL7KhrxGmLDWdOjDjouuoFKSSVc3ttzTRZkf3ddleD8+RHk c=;
IronPort-SDR: GEeAu+XnJ90BUHTMvaCYXxqhmA7hWWC5gd0hU+oKNmSI3xAMja1bYoo2dgq8SnbpdtcvO4ZRBj XDmfH2gc9NEQ==
X-IronPort-AV: E=Sophos;i="5.68,252,1569283200"; d="scan'208,217";a="2421032"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 31 Oct 2019 18:55:29 +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-c7131dcf.us-west-2.amazon.com (Postfix) with ESMTPS id 06B8FA338D for ; Thu, 31 Oct 2019 18:55:28 +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, 31 Oct 2019 18:55:28 +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, 31 Oct 2019 18:55:28 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 31 Oct 2019 18:55:28 +0000
From: "Richard Backman, Annabelle" 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
Thread-Index: AQHVi20khjnyTeh9jkqsJQFVhb6GPqdteSoAgAKKHACAACgOAIAAB6CAgAAQz4CAAb9SAIAALTaAgAJnDoCAAANWAIAACmUAgAAIPgA=
Date: Thu, 31 Oct 2019 18:55:28 +0000
Message-ID: 
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu>  <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu>        <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu>    <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>
In-Reply-To: <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1b.0.190715
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.223]
Content-Type: multipart/alternative; boundary="_000_E70795A45BC74450A1B4FFC3D332F1DCamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 18:55:39 -0000

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

UmVseWluZyBvbiBhIGZpeGVkLCByYW5kb20gaGVhZGVyIG5hbWUgZm9yIHNlY3VyaXR5LCBldmVu
IGFzIGEg4oCcZGVmZW5zZSBpbiBkZXB0aOKAnSBtZWFzdXJlLCBpcyBkYW5nZXJvdXMuIEluIG9y
ZGVyIGZvciB0aGlzIG1lY2hhbmlzbSB0byBiZSBlZmZlY3RpdmUsIHRoZSBoZWFkZXIgbmFtZSBt
dXN0IGJlIHJhbmRvbSAoaW4gdGhlIGNyeXB0b2dyYXBoaWMgc2Vuc2UpIGFuZCBtdXN0IGJlIGtl
cHQgc2VjcmV0LiBJdCBuZWVkcyB0byBiZSB3aXRoaGVsZCBmcm9tIHJlcXVlc3QgbG9ncyBvciBl
cnJvciBsb2dzLCBlaXRoZXIgb24gdGhlIHJldmVyc2UgcHJveHkgb3Igb24gdGhlIHNlcnZpY2Uu
IEl0IGNhbm5vdCBiZSBjb21taXR0ZWQgdG8gY29kZSByZXBvc2l0b3JpZXMuIEluY2x1ZGluZyBp
dCBhcyBhIHNpZ25lZCBoZWFkZXIgaW4gcmVxdWVzdCBzaWduaW5nIGFsZ29yaXRobXMgdGhhdCBy
ZXF1aXJlIGFuIGV4cGxpY2l0IGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMgKHN1Y2ggYXMgQVdTIFNp
Z25hdHVyZSBWZXJzaW9uIDQ8aHR0cHM6Ly9kb2NzLmF3cy5hbWF6b24uY29tL2dlbmVyYWwvbGF0
ZXN0L2dyL3NpZ25hdHVyZS12ZXJzaW9uLTQuaHRtbD4sIGRyYWZ0LWNhdmFnZS1odHRwLXNpZ25h
dHVyZXM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25h
dHVyZXMtMTI+LCBkcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3Q8aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVzdD4p
IHR1cm5zIHRoYXQgc2lnbmF0dXJlIG1ldGFkYXRhIGludG8gYSBzZWNyZXQsIG1lYW5pbmcgdGhh
dCBpdCBjYW5ub3QgYmUgbG9nZ2VkLCBldGMuIElmIHNpZ25hdHVyZXMgYXJlIHNlbnQgdG8gYSBj
ZW50cmFsIGF1dGhvcml0eSBmb3IgcHJvY2Vzc2luZywgdGhhdCBhdXRob3JpdHkgbXVzdCBhbHNv
IGtub3cgbm90IHRvIGxvZyB0aGUgbGlzdCBvZiBzaWduZWQgaGVhZGVycy4gSSBjb3VsZCBnbyBv
biwgYnV0IEkgaG9wZSB0aGlzIGlzIGVub3VnaCB0byBleHByZXNzIHRoYXQgdGhlcmUgYXJlIFNP
IE1BTlkgd2F5cyB0aGF0IGhlYWRlciBuYW1lcyBjYW4gYW5kIHdpbGwgYmUgcmV2ZWFsZWQsIGFu
ZCB0aGV5IGFyZW7igJl0IGFsd2F5cyBvYnZpb3VzLg0KDQpXaGF0IHdlIGFyZSB0YWxraW5nIGFi
b3V0IGlzIGEgbWVzc2FnZSBhdXRoZW50aWNpdHkgcHJvYmxlbS4gVGhlIGJlc3QgcHJhY3RpY2Vz
IGZvciBwcm92aWRpbmcgbWVzc2FnZSBhdXRoZW50aWNpdHkgaW52b2x2ZSBhcHBsaWVkIGNyeXB0
bywgZS5nLiwgYW4gSE1BQyBvciBkaWdpdGFsIHNpZ25hdHVyZSBvdmVyIHRoZSBoZWFkZXIgY29u
dGVudHMuIElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgdGhhdCwgdGhlbiB0aGUgcmFuZG9tIGhl
YWRlciBuYW1lIGlzIHVubmVjZXNzYXJ5LiBUaGlzIGFwcHJvYWNoIGlzIGltbXVuZSB0byB0aGUg
c29ydCBvZiBtaXNjb25maWd1cmF0aW9uIHNjZW5hcmlvcyB0aGF0IGhhdmUgYmVlbiBkaXNjdXNz
ZWQgaW4gdGhpcyB0aHJlYWQsIGFzIHRoZXkgd291bGQgcmVzdWx0IGluIHRoZSByZXZlcnNlIHBy
b3h5IGZhaWxpbmcgdG8gcHJvdmlkZSBhIHByb3Blcmx5IHNpZ25lZCBoZWFkZXIgdG8gdGhlIHNl
cnZpY2UuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoN
Cg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBWbGFk
aW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPg0KT3JnYW5pemF0aW9uOiBD
b25uZWN0MmlkIEx0ZC4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDMxLCAyMDE5IGF0IDQ6Mjcg
QU0NClRvOiAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIGNsaWVudCBjZXJ0cyBhbmQgVExTIFRlcm1pbmF0aW5nIFJldmVyc2UgUHJveGll
cyAod2FzIFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9u
LXJlc3BvbnNlLTA4LnR4dCkNCg0KDQpUaGlzIGlzIGEgZ29vZCBzdG9yeS4NCg0KSG93IGFib3V0
IHJlcXVpcmluZyByZXZlcnNlIHByb3hpZXMgdG8gYXV0b21hdGljYWxseSBzY3J1YiBhbGwgaW5i
b3VuZCBIVFRQIGhlYWRlcnMgdGhhdCBzdGFydCB3aXRoICJTZWMtIj8NCg0KSWYgYSBzZWMgaGVh
ZGVyIGhhcyB0aGUgZm9ybWF0ICJTZWMtW05BTUVdLVtyYW5kb20tY2hhcnNdIiB3ZSBnZXQ6DQoN
CiogVGhlICJTZWMtIiBwcmVmaXggd2lsbCAgY2F1c2UgbmV3IGNvbXBsaWFudCByZXNlcnZlIHBy
b3hpZXMgdG8gYXV0b21hdGljYWxseSBzY3J1YiB0aGUgaW5ib3VuZCBIVFRQIGhlYWRlci4NCg0K
KiBUaGUgTkFNRSBwYXJ0IHN0aWxsIG1ha2VzIHRoZSBoZWFkZXIgZWFzaWx5IGlkZW50aWZpYWJs
ZSAoSSB0aGluayBSaWNoIFNhbHogaGFkIHRoaXMgY29uY2VybikuDQoNCiogVGhlIHJhbmRvbSBj
aGFycyBwYXJ0LCBwb3RlbnRpYWxseSBvcHRpb25hbCwgd2lsbCBwcm92aWRlIGEgbGluZSBvZiBk
ZWZlbmNlIGFnYWluc3QgY29uZmlnIGVycm9ycyBpbiBvbGQgbGVnYWN5IHJldmVyc2UgcHJveGll
cy4NCg0KQWxsIGNvbmNlcm5zIHNob3VsZCB0aGVuIGdldCBjb3ZlcmVkLg0KDQpWbGFkaW1pcg0K
T24gMzEvMTAvMjAxOSAxMjo0OCwgSGFucyBaYW5kYmVsdCB3cm90ZToNCnRoZSB3YXkgSSBzZWUg
dGhpcyBpcyB0aGF0IHN0cmlwcGluZyBhbmQgc2V0dGluZyB0aGUgaGVhZGVycyBtdXN0IGJlIHBh
cnQgb2YgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBwcm90b2NvbCBpdHNlbGYsIGl0IHNob3Vs
ZCBub3QgYmUgc29tZXRoaW5nIGxlZnQgdG8gYSBub24tYXRvbWljIHBpZWNlIG9mIGNvbmZpZ3Vy
YXRpb24gYnkgYW4gYWRtaW5pc3RyYXRvcjsgSSBpbXBsZW1lbnRlZCBpdCBsaWtlIHRoaXMgaW4g
dGhlIEFwYWNoZSBpbXBsZW1lbnRhdGlvbiBvZiBCcmlhbidzIFRUUlAgc3BlYyBbMV0gYW5kIGhh
dmUgYmVlbiBkb2luZyB0aGlzIGZvciB0aGUgT0lEQyBhbmQgT0F1dGggQXBhY2hlIG1vZHVsZXMg
dGhhdCBzZXQgaGVhZGVycyBmb3IgYmFja2VuZHMgdG8gY29uc3VtZSBbMl07IGFuZCB5ZXMsIEkg
aGF2ZSBtYWRlIG1pc3Rha2VzIFszXSwgYnV0IElNSE8gaXQgc2hvdWxkIG5vdCBiZSBhIHByb2Js
ZW0gdG8gdXNlIGEgd2VsbCBrbm93biBoZWFkZXIgYW5kIG1ha2UgdGhlIGltcGxlbWVudGVyIChu
b3QgdGhlIGFkbWluKSBnZXQgaXQgcmlnaHQgYnkgcG9pbnRpbmcgdGhpcyBvdXQgaW4gdGhlIHNw
ZWMsIGFzIGlzIGRvbmUgZm9yIG1hbnkgb3RoZXIgcGl0ZmFsbHMNCg0KSGFucy4NCg0KWzFdIGh0
dHBzOi8vZ2l0aHViLmNvbS96bWFydHpvbmUvbW9kX3Rva2VuX2JpbmRpbmcvYmxvYi9tYXN0ZXIv
c3JjL21vZF90b2tlbl9iaW5kaW5nLmMjTDQ4MS1MNDgzDQpbMl0gaHR0cHM6Ly9naXRodWIuY29t
L3ptYXJ0em9uZS9tb2RfYXV0aF9vcGVuaWRjL2Jsb2IvbWFzdGVyL3NyYy9tb2RfYXV0aF9vcGVu
aWRjLmMjTDE2NC1MMTc1DQpbM10gaHR0cHM6Ly93d3cuY3ZlZGV0YWlscy5jb20vY3ZlL0NWRS0y
MDE3LTY0MTMvDQoNCk9uIFRodSwgT2N0IDMxLCAyMDE5IGF0IDExOjM3IEFNIFZsYWRpbWlyIER6
aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3Qy
aWQuY29tPj4gd3JvdGU6DQpBbGwgaW4gYWxsLCBJIGFtIGluIGZhdm9yIG9mIHRoaXMgYmVpbmcg
ZGVmaW5lZCBpbiBvbmUgc3RhbmRhcmQgd2F5LCBpbiBhZGRpdGlvbiB0byBzZWN1cmUgY29tbXVu
aWNhdGlvbiBiZXR3ZWVuIHByb3hpZXMgYW5kIGJhY2tlbmRzIGJlaW5nIHN0YW5kYXJkaXplZCDi
gJQgYnV0IHRoaXMgbGF0dGVyIGJpdCByZWFsbHkgc2VlbXMgbGlrZSBhIHNlcGFyYXRlIHByb2Js
ZW0uDQoNCiDigJQgSnVzdGluDQoNCi0xIGZvciBkZXZpc2luZyBhIHdlbGwga25vd24gaGVhZGVy
DQoNCisxIGZvciBhIHNpbXBsZSB3YXkgdG8gYXV0aGVudGljYXRlIGEgcmV2ZXJzZSBwcm94eSB3
aXRoIGEgd2ViIHNlcnZlcg0KDQpXaXRoIGEgd2VsbCBrbm93biBuYW1lLCBpbiBhIGF0dGFjayB0
aGlzIHdpbGwgZ2V0IHByb2JlZCBmaXJzdC4gVGhlIHdlbGwga25vd24gaGVhZGVyIG5hbWUgZG9l
c24ndCBndWFyYW50ZWUgYSBjb3JyZWN0IGNvbmZpZy4gQW5kIGlmIHdlIGhhdmUgYSBuZXcgc3Rh
bmRhcmQgZm9yIHNlYyBoZWFkZXJzIHRoYXQgbXVzdCBiZSBzdHJpcHBlZCBhdXRvbWF0aWNhbGx5
IGZyb20gaW5ib3VuZCBIVFRQIHJlcXVlc3RzLCB3ZSBjYW5ub3QgZXhwZWN0IHRoYXQgd2lsbCBn
ZXQgaW1wbGVtZW50ZWQgaW4gYWxsIHJldmVyc2UgcHJveHkgc29mdHdhcmUgb3Zlcm5pZ2h0Lg0K
DQpCZWNhdXNlIGEgY29ycmVjdCBjb25maWcgaXMgbm90IHByYWN0aWNhbCBhcyB0aGUgb25seSBs
aW5lIG9mIGRlZmVuc2UsIHdoZW4gd2UgaW1wbGVtZW50ZWQgbVRMUyB3ZSBkZWNpZGVkIHRvIGFk
ZCBhIGxlbmd0aCAoPj0gMzIgY2hhcnMpIGFuZCByYW5kb21uZXNzIGNoZWNrIHRvIHRoZSBoZWFk
ZXIgY29uZmlnLiBJIHNhdyBzb21lIGNvbmNlcm5zIHRoYXQgdGhpcyBtYXkgY2F1c2UgZGVwbG95
bWVudCBpc3N1ZXMuIE5vYm9keSBoYXMgY29tcGxhaW5lZCBhYm91dCB0aGF0IHNvIGZhci4NCg0K
aHR0cHM6Ly9jb25uZWN0MmlkLmNvbS9wcm9kdWN0cy9zZXJ2ZXIvZG9jcy9jb25maWcvY29yZSNv
cC10bHMtY2xpZW50WDUwOUNlcnRIZWFkZXINCg0KUmVnYXJkaW5nIG1pc3R5cGluZywgdGhpcyBj
YW4gYmUgYW4gaXNzdWUsIGJ1dCBoYXMgbGl0dGxlIHRvIG5vIGVmZmVjdCBpZiBhIGxvbmcgcmFu
ZG9tIGhlYWRlciBnZXRzIG1pc3N0eXBlZCAoZnJvbSB0aGUgaW5ib3VuZCBzdHJpcCBkaXJlY3Rp
dmUpLiBXaXRoIGEgd2VsbCBrbm93biBoZWFkZXIgdGhpcyB3aWxsIHJlc3VsdCBpbiBhIGltbWVk
aWF0ZSBzZWN1cml0eSBob2xlLCB3aGljaCBjYW4gdGhlb3JldGljYWxseSBnbyB1bm5vdGljZWQu
DQoNCkhlcmUgaXMgYW4gZXhhbXBsZSBBcGFjaGUgaHR0cGQgY29uZmlnLCB0byBpbGx1c3RyYXRl
IG15IHBvaW50Og0KDQpSZXF1ZXN0SGVhZGVyIHNldCBTZWMtQ2xpZW50LVg1MDktQ2VydC1saWVk
ZTV2YWVQZWVNaVlpZTB4dTJqYXVkYXVsZWluZyAiIg0KDQpSZXF1ZXN0SGVhZGVyIHNldCBTZWMt
Q2xpZW50LVg1MDktQ2VydC1saWVkZTV2YWVQZWVNaVlpZTB4dTJqYXVkYXVsZWluZyAiJXtTU0xf
Q0xJRU5UX0NFUlR9cyINCg0KKHRoZSBmaXJzdCBsaW5lIHN0cmlwcyB0aGUgaW5ib3VuZCBoZWFk
ZXJzKQ0KDQoNCg0KVmxhZGltaXINCg0KLS0NCg0KVmxhZGltaXIgRHpodXZpbm92DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs
aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1h
cnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJ
QU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93d3cuem1hcnR6b25lLmV1Pg0KDQotLQ0KDQpW
bGFkaW1pciBEemh1dmlub3YNCg==

--_000_E70795A45BC74450A1B4FFC3D332F1DCamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <76276C4543CB444DBD23435083BBB107@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy
IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvOw0KCXBhbm9zZS0x
OjIgMTEgNiA5IDMgOCA0IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v
cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFs
MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y
bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbHlpbmcg
b24gYSBmaXhlZCwgcmFuZG9tIGhlYWRlciBuYW1lIGZvciBzZWN1cml0eSwgZXZlbiBhcyBhIOKA
nGRlZmVuc2UgaW4gZGVwdGjigJ0gbWVhc3VyZSwgaXMgZGFuZ2Vyb3VzLiBJbiBvcmRlciBmb3Ig
dGhpcyBtZWNoYW5pc20gdG8gYmUgZWZmZWN0aXZlLCB0aGUgaGVhZGVyIG5hbWUgbXVzdCBiZSBy
YW5kb20gKGluIHRoZSBjcnlwdG9ncmFwaGljIHNlbnNlKSBhbmQgbXVzdCBiZSBrZXB0IHNlY3Jl
dC4gSXQNCiBuZWVkcyB0byBiZSB3aXRoaGVsZCBmcm9tIHJlcXVlc3QgbG9ncyBvciBlcnJvciBs
b2dzLCBlaXRoZXIgb24gdGhlIHJldmVyc2UgcHJveHkgb3Igb24gdGhlIHNlcnZpY2UuIEl0IGNh
bm5vdCBiZSBjb21taXR0ZWQgdG8gY29kZSByZXBvc2l0b3JpZXMuIEluY2x1ZGluZyBpdCBhcyBh
IHNpZ25lZCBoZWFkZXIgaW4gcmVxdWVzdCBzaWduaW5nIGFsZ29yaXRobXMgdGhhdCByZXF1aXJl
IGFuIGV4cGxpY2l0IGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMNCiAoc3VjaCBhcyA8YSBocmVmPSJo
dHRwczovL2RvY3MuYXdzLmFtYXpvbi5jb20vZ2VuZXJhbC9sYXRlc3QvZ3Ivc2lnbmF0dXJlLXZl
cnNpb24tNC5odG1sIj4NCkFXUyBTaWduYXR1cmUgVmVyc2lvbiA0PC9hPiwgPGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25hdHVyZXMtMTIi
Pg0KZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlczwvYT4sIDxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3QiPg0K
ZHJhZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0PC9hPikgdHVybnMgdGhhdCBzaWdu
YXR1cmUgbWV0YWRhdGEgaW50byBhIHNlY3JldCwgbWVhbmluZyB0aGF0DQo8aT5pdDwvaT4gY2Fu
bm90IGJlIGxvZ2dlZCwgZXRjLiBJZiBzaWduYXR1cmVzIGFyZSBzZW50IHRvIGEgY2VudHJhbCBh
dXRob3JpdHkgZm9yIHByb2Nlc3NpbmcsIHRoYXQgYXV0aG9yaXR5IG11c3QgYWxzbyBrbm93IG5v
dCB0byBsb2cgdGhlIGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMuIEkgY291bGQgZ28gb24sIGJ1dCBJ
IGhvcGUgdGhpcyBpcyBlbm91Z2ggdG8gZXhwcmVzcyB0aGF0IHRoZXJlIGFyZSBTTyBNQU5ZIHdh
eXMgdGhhdCBoZWFkZXIgbmFtZXMNCiBjYW4gYW5kIHdpbGwgYmUgcmV2ZWFsZWQsIGFuZCB0aGV5
IGFyZW7igJl0IGFsd2F5cyBvYnZpb3VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdl
IGFyZSB0YWxraW5nIGFib3V0IGlzIGEgbWVzc2FnZSBhdXRoZW50aWNpdHkgcHJvYmxlbS4gVGhl
IGJlc3QgcHJhY3RpY2VzIGZvciBwcm92aWRpbmcgbWVzc2FnZSBhdXRoZW50aWNpdHkgaW52b2x2
ZSBhcHBsaWVkIGNyeXB0bywgZS5nLiwgYW4gSE1BQyBvciBkaWdpdGFsIHNpZ25hdHVyZSBvdmVy
IHRoZSBoZWFkZXIgY29udGVudHMuIElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgdGhhdCwgdGhl
bg0KIHRoZSByYW5kb20gaGVhZGVyIG5hbWUgaXMgdW5uZWNlc3NhcnkuIFRoaXMgYXBwcm9hY2gg
aXMgaW1tdW5lIHRvIHRoZSBzb3J0IG9mIG1pc2NvbmZpZ3VyYXRpb24gc2NlbmFyaW9zIHRoYXQg
aGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZCwgYXMgdGhleSB3b3VsZCByZXN1bHQg
aW4gdGhlIHJldmVyc2UgcHJveHkgZmFpbGluZyB0byBwcm92aWRlIGEgcHJvcGVybHkgc2lnbmVk
IGhlYWRlciB0byB0aGUgc2VydmljZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29h
dXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBWbGFkaW1pciBEemh1dmlub3Yg
Jmx0O3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tJmd0Ozxicj4NCjxiPk9yZ2FuaXphdGlvbjogPC9i
PkNvbm5lY3QyaWQgTHRkLjxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciAzMSwg
MjAxOSBhdCA0OjI3IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90
OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgt
V0ddIGNsaWVudCBjZXJ0cyBhbmQgVExTIFRlcm1pbmF0aW5nIFJldmVyc2UgUHJveGllcyAod2Fz
IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3Bv
bnNlLTA4LnR4dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+VGhpcyBpcyBh
IGdvb2Qgc3RvcnkuPG86cD48L286cD48L3A+DQo8cD5Ib3cgYWJvdXQgcmVxdWlyaW5nIHJldmVy
c2UgcHJveGllcyB0byBhdXRvbWF0aWNhbGx5IHNjcnViIGFsbCBpbmJvdW5kIEhUVFAgaGVhZGVy
cyB0aGF0IHN0YXJ0IHdpdGggJnF1b3Q7U2VjLSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxwPklm
IGEgc2VjIGhlYWRlciBoYXMgdGhlIGZvcm1hdCAmcXVvdDtTZWMtW05BTUVdLVtyYW5kb20tY2hh
cnNdJnF1b3Q7IHdlIGdldDo8bzpwPjwvbzpwPjwvcD4NCjxwPiogVGhlICZxdW90O1NlYy0mcXVv
dDsgcHJlZml4IHdpbGwmbmJzcDsgY2F1c2UgbmV3IGNvbXBsaWFudCByZXNlcnZlIHByb3hpZXMg
dG8gYXV0b21hdGljYWxseSBzY3J1YiB0aGUgaW5ib3VuZCBIVFRQIGhlYWRlci48bzpwPjwvbzpw
PjwvcD4NCjxwPiogVGhlIE5BTUUgcGFydCBzdGlsbCBtYWtlcyB0aGUgaGVhZGVyIGVhc2lseSBp
ZGVudGlmaWFibGUgKEkgdGhpbmsgUmljaCBTYWx6IGhhZCB0aGlzIGNvbmNlcm4pLjxvOnA+PC9v
OnA+PC9wPg0KPHA+KiBUaGUgcmFuZG9tIGNoYXJzIHBhcnQsIHBvdGVudGlhbGx5IG9wdGlvbmFs
LCB3aWxsIHByb3ZpZGUgYSBsaW5lIG9mIGRlZmVuY2UgYWdhaW5zdCBjb25maWcgZXJyb3JzIGlu
IG9sZCBsZWdhY3kgcmV2ZXJzZSBwcm94aWVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWxsIGNvbmNl
cm5zIHNob3VsZCB0aGVuIGdldCBjb3ZlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+VmxhZGltaXI8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMS8xMC8yMDE5
IDEyOjQ4LCBIYW5zIFphbmRiZWx0IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIHdheSBJIHNlZSB0aGlzIGlzIHRo
YXQgc3RyaXBwaW5nIGFuZCBzZXR0aW5nIHRoZSBoZWFkZXJzIG11c3QgYmUgcGFydCBvZiB0aGUg
aW1wbGVtZW50YXRpb24gb2YgdGhlIHByb3RvY29sIGl0c2VsZiwgaXQgc2hvdWxkIG5vdCBiZSBz
b21ldGhpbmcgbGVmdCB0byBhIG5vbi1hdG9taWMgcGllY2Ugb2YgY29uZmlndXJhdGlvbiBieSBh
biBhZG1pbmlzdHJhdG9yOyBJIGltcGxlbWVudGVkIGl0IGxpa2UgdGhpcw0KIGluIHRoZSBBcGFj
aGUgaW1wbGVtZW50YXRpb24gb2YgQnJpYW4ncyBUVFJQIHNwZWMgWzFdIGFuZCBoYXZlIGJlZW4g
ZG9pbmcgdGhpcyBmb3IgdGhlIE9JREMgYW5kIE9BdXRoIEFwYWNoZSBtb2R1bGVzIHRoYXQgc2V0
IGhlYWRlcnMgZm9yIGJhY2tlbmRzIHRvIGNvbnN1bWUgWzJdOyBhbmQgeWVzLCBJIGhhdmUgbWFk
ZSBtaXN0YWtlcyBbM10sIGJ1dCBJTUhPIGl0IHNob3VsZCBub3QgYmUgYSBwcm9ibGVtIHRvIHVz
ZSBhIHdlbGwga25vd24gaGVhZGVyDQogYW5kIG1ha2UgdGhlIGltcGxlbWVudGVyIChub3QgdGhl
IGFkbWluKSBnZXQgaXQgcmlnaHQgYnkgcG9pbnRpbmcgdGhpcyBvdXQgaW4gdGhlIHNwZWMsIGFz
IGlzIGRvbmUgZm9yIG1hbnkgb3RoZXIgcGl0ZmFsbHMNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRo
dWIuY29tL3ptYXJ0em9uZS9tb2RfdG9rZW5fYmluZGluZy9ibG9iL21hc3Rlci9zcmMvbW9kX3Rv
a2VuX2JpbmRpbmcuYyNMNDgxLUw0ODMiPmh0dHBzOi8vZ2l0aHViLmNvbS96bWFydHpvbmUvbW9k
X3Rva2VuX2JpbmRpbmcvYmxvYi9tYXN0ZXIvc3JjL21vZF90b2tlbl9iaW5kaW5nLmMjTDQ4MS1M
NDgzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+WzJdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3ptYXJ0em9uZS9tb2RfYXV0
aF9vcGVuaWRjL2Jsb2IvbWFzdGVyL3NyYy9tb2RfYXV0aF9vcGVuaWRjLmMjTDE2NC1MMTc1Ij5o
dHRwczovL2dpdGh1Yi5jb20vem1hcnR6b25lL21vZF9hdXRoX29wZW5pZGMvYmxvYi9tYXN0ZXIv
c3JjL21vZF9hdXRoX29wZW5pZGMuYyNMMTY0LUwxNzU8L2E+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bM10mbmJzcDs8YSBocmVmPSJodHRwczov
L3d3dy5jdmVkZXRhaWxzLmNvbS9jdmUvQ1ZFLTIwMTctNjQxMy8iPmh0dHBzOi8vd3d3LmN2ZWRl
dGFpbHMuY29tL2N2ZS9DVkUtMjAxNy02NDEzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMzEsIDIwMTkgYXQgMTE6
MzcgQU0gVmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29u
bmVjdDJpZC5jb20iPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QWxsIGluIGFsbCwgSSBhbSBpbiBmYXZvciBvZiB0aGlzIGJlaW5nIGRlZmlu
ZWQgaW4gb25lIHN0YW5kYXJkIHdheSwgaW4gYWRkaXRpb24gdG8gc2VjdXJlIGNvbW11bmljYXRp
b24gYmV0d2VlbiBwcm94aWVzIGFuZCBiYWNrZW5kcyBiZWluZyBzdGFuZGFyZGl6ZWQg4oCUIGJ1
dCB0aGlzIGxhdHRlciBiaXQgcmVhbGx5IHNlZW1zIGxpa2UgYSBzZXBhcmF0ZSBwcm9ibGVtLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPi0x
IGZvciBkZXZpc2luZyBhIHdlbGwga25vd24gaGVhZGVyPG86cD48L286cD48L3A+DQo8cD4mIzQz
OzEgZm9yIGEgc2ltcGxlIHdheSB0byBhdXRoZW50aWNhdGUgYSByZXZlcnNlIHByb3h5IHdpdGgg
YSB3ZWIgc2VydmVyPG86cD48L286cD48L3A+DQo8cD5XaXRoIGEgd2VsbCBrbm93biBuYW1lLCBp
biBhIGF0dGFjayB0aGlzIHdpbGwgZ2V0IHByb2JlZCBmaXJzdC4gVGhlIHdlbGwga25vd24gaGVh
ZGVyIG5hbWUgZG9lc24ndCBndWFyYW50ZWUgYSBjb3JyZWN0IGNvbmZpZy4gQW5kIGlmIHdlIGhh
dmUgYSBuZXcgc3RhbmRhcmQgZm9yIHNlYyBoZWFkZXJzIHRoYXQgbXVzdCBiZSBzdHJpcHBlZCBh
dXRvbWF0aWNhbGx5IGZyb20gaW5ib3VuZCBIVFRQIHJlcXVlc3RzLCB3ZSBjYW5ub3QgZXhwZWN0
DQogdGhhdCB3aWxsIGdldCBpbXBsZW1lbnRlZCBpbiBhbGwgcmV2ZXJzZSBwcm94eSBzb2Z0d2Fy
ZSBvdmVybmlnaHQuPG86cD48L286cD48L3A+DQo8cD5CZWNhdXNlIGEgY29ycmVjdCBjb25maWcg
aXMgbm90IHByYWN0aWNhbCBhcyB0aGUgb25seSBsaW5lIG9mIGRlZmVuc2UsIHdoZW4gd2UgaW1w
bGVtZW50ZWQgbVRMUyB3ZSBkZWNpZGVkIHRvIGFkZCBhIGxlbmd0aCAoJmd0Oz0gMzIgY2hhcnMp
IGFuZCByYW5kb21uZXNzIGNoZWNrIHRvIHRoZSBoZWFkZXIgY29uZmlnLiBJIHNhdyBzb21lIGNv
bmNlcm5zIHRoYXQgdGhpcyBtYXkgY2F1c2UgZGVwbG95bWVudCBpc3N1ZXMuIE5vYm9keSBoYXMg
Y29tcGxhaW5lZA0KIGFib3V0IHRoYXQgc28gZmFyLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGEgaHJl
Zj0iaHR0cHM6Ly9jb25uZWN0MmlkLmNvbS9wcm9kdWN0cy9zZXJ2ZXIvZG9jcy9jb25maWcvY29y
ZSNvcC10bHMtY2xpZW50WDUwOUNlcnRIZWFkZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Nv
bm5lY3QyaWQuY29tL3Byb2R1Y3RzL3NlcnZlci9kb2NzL2NvbmZpZy9jb3JlI29wLXRscy1jbGll
bnRYNTA5Q2VydEhlYWRlcjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPlJlZ2FyZGluZyBtaXN0eXBp
bmcsIHRoaXMgY2FuIGJlIGFuIGlzc3VlLCBidXQgaGFzIGxpdHRsZSB0byBubyBlZmZlY3QgaWYg
YSBsb25nIHJhbmRvbSBoZWFkZXIgZ2V0cyBtaXNzdHlwZWQgKGZyb20gdGhlIGluYm91bmQgc3Ry
aXAgZGlyZWN0aXZlKS4gV2l0aCBhIHdlbGwga25vd24gaGVhZGVyIHRoaXMgd2lsbCByZXN1bHQg
aW4gYSBpbW1lZGlhdGUgc2VjdXJpdHkgaG9sZSwgd2hpY2ggY2FuIHRoZW9yZXRpY2FsbHkgZ28g
dW5ub3RpY2VkLg0KPG86cD48L286cD48L3A+DQo8cD5IZXJlIGlzIGFuIGV4YW1wbGUgQXBhY2hl
IGh0dHBkIGNvbmZpZywgdG8gaWxsdXN0cmF0ZSBteSBwb2ludDo8bzpwPjwvbzpwPjwvcD4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjVGNztib3JkZXItcmFkaXVzOjNweDtvdmVyZmxvdy14
OmF1dG87Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1k
ZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMTcyQjREIj5SZXF1ZXN0SGVh
ZGVyIHNldCBTZWMtQ2xpZW50LVg1MDktQ2VydC1saWVkZTV2YWVQZWVNaVlpZTB4dTJqYXVkYXVs
ZWluZyAmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6I0Y0RjVGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpNZW5sbztjb2xvcjojMTcyQjREIj5SZXF1ZXN0SGVhZGVyIHNldCBTZWMtQ2xpZW50LVg1MDkt
Q2VydC1saWVkZTV2YWVQZWVNaVlpZTB4dTJqYXVkYXVsZWluZyAmcXVvdDsle1NTTF9DTElFTlRf
Q0VSVH1zJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cD4odGhlIGZpcnN0IGxpbmUg
c3RyaXBzIHRoZSBpbmJvdW5kIGhlYWRlcnMpPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwPlZsYWRpbWlyPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlZsYWRpbWlyIER6aHV2aW5vdjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij48YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUiIHRh
cmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1hcnRab25lIElBTSAtIDxhIGhyZWY9Imh0dHA6Ly93d3cu
em1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+DQp3d3cuem1hcnR6b25lLmV1PC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5WbGFkaW1pciBEemh1dmlub3Y8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_E70795A45BC74450A1B4FFC3D332F1DCamazoncom_--


From nobody Thu Oct 31 12:00:59 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7547D1209EB for ; Thu, 31 Oct 2019 12:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsZ-SlEIIXzL for ; Thu, 31 Oct 2019 12:00:53 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 53C4E120847 for ; Thu, 31 Oct 2019 12:00:53 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9VIvVx9000582; Thu, 31 Oct 2019 19:00:48 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=CMyTzU0Tj2oh9IHYMNyn9WH4hwv/7cDBTZXNvxUHx9U=; b=ier/BGiFq6nVlus4P38THk9lFwx+Y2vww4kQCL7Zf5rCUroflZ8/f+VElhAQIr8LemJt mOcXo8k9fd8Mgr56WYTvPIOOiY7cKIu4qfNNOH0Xm9cG/0GBbRQIznYEpioLioKruRGn dFPIw9uuHSM3tOWyNaMa6nr5IBUCIvLYv+JtmsRV/wKv/qcSjmENWhT/IIxA41qEZo9t q4ZVJZ+Z+WiCKgI7uQuIGwMpYuNypIMCBRAIicTDywEJwtQBAMkVOaCCsHnsq4PdDa3i rg7Q7gnAinZB4A/1sszuXQtPb6ce4i7t68xxNhG6vAM67yiVef6SYy1ykclTmmWxoKLR cQ== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vxwgg1uhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 19:00:48 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9VIl9al019532; Thu, 31 Oct 2019 15:00:47 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vxwfnuy1n-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 15:00:46 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 31 Oct 2019 15:00:33 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 31 Oct 2019 15:00:33 -0400
From: "Salz, Rich" 
To: "Richard Backman, Annabelle" , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
Thread-Index: AQHVi20DwSDixrsmwUqaChyBzydqk6dtvDgAgAKKHACAACgPAIAAB5+AgAAQz4CAAb9SAIAALTaAgAJnDoCAAANXAIAACmUAgAB9lgD//75egA==
Date: Thu, 31 Oct 2019 19:00:33 +0000
Message-ID: 
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <20191021020546.GZ43312@kduck.mit.edu>  <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu>        <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu>    <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@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.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.97]
Content-Type: multipart/alternative; boundary="_000_A1E7A8D81DE6460AA44F48A3FDC2A41Eakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-31_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=686 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910310186
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-31_07:2019-10-30,2019-10-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1011 priorityscore=1501 mlxscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 mlxlogscore=661 suspectscore=0 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910310188
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 19:00:58 -0000

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

ICAqICAgUmVseWluZyBvbiBhIGZpeGVkLCByYW5kb20gaGVhZGVyIG5hbWUgZm9yIHNlY3VyaXR5
LCBldmVuIGFzIGEg4oCcZGVmZW5zZSBpbiBkZXB0aOKAnSBtZWFzdXJlLCBpcyBkYW5nZXJvdXMu
DQoNClRoYW5rIHlvdS4gICsxDQo=

--_000_A1E7A8D81DE6460AA44F48A3FDC2A41Eakamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <07E962BDC384A540A9CA0C6FBA8BF9E1@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx
LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u
TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv
bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk
aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv
cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t
bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNv
bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z
by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ
Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww
DQoJe21zby1saXN0LWlkOjk2NjI3OTQ4OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6OTAyMTkwNTk4IDE3MTI0NjU0ODIgNjc2OTg2OTEgNjc2OTg2OTMg
Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K
QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m
b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6
bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N
Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJn
aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlJlbHlpbmcgb24g
YSBmaXhlZCwgcmFuZG9tIGhlYWRlciBuYW1lIGZvciBzZWN1cml0eSwgZXZlbiBhcyBhIOKAnGRl
ZmVuc2UgaW4gZGVwdGjigJ0gbWVhc3VyZSwgaXMgZGFuZ2Vyb3VzLjxvOnA+PC9vOnA+PC9saT48
L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UuJm5ic3A7ICYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A1E7A8D81DE6460AA44F48A3FDC2A41Eakamaicom_--


From nobody Thu Oct 31 12:21:27 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805371208D9 for ; Thu, 31 Oct 2019 12:21:25 -0700 (PDT)
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=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 QuX24M5yQoWD for ; Thu, 31 Oct 2019 12:21:22 -0700 (PDT)
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 DBE901209D0 for ; Thu, 31 Oct 2019 12:21:00 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id f5so5581544lfp.1 for ; Thu, 31 Oct 2019 12:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=08INO1NIUPggKWaEWJ9kXne8YAazlD9kNcbfxk0vi5s=; b=kjXzp0C4RNLgQRtRmXsJgzeYUxd44KVhA3N8Z52pu5XmvNiN9XtjnZNm3d1D3dMsyY sKcvEo6nA0hoY+fiSs/76IHGjxhF4MSmoh7SqF12PK8mX0Ac07A/M+/8G5VjICN4wZJD P1pRK97/JBLyTM+bXLAOyEwpj0YwSQefvAmFI=
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=08INO1NIUPggKWaEWJ9kXne8YAazlD9kNcbfxk0vi5s=; b=iFPkW4ZBk7YXj6Bp60yZVy/ON2bZEYR/Plei47Lwh+qKbPVVCYQOrgAEjQ7IphdwXo srXGK+SizT2PvCThm9prXrdsprUrPFDw+3ZJfoOJhrTYqPskSAnMRBlPH0Bn1d56X/Zd TjhtZa4vgTKsVUUcINOIgt4j440BAXb3rCNVcH0cMq2ei3KhUqwz4tpS42blbhNBHA25 Yt1jMwN84ZFJ/ibIUXFU79ODJ1jANLIpUR/apaZy+ZbkePpg/PLEundSN0WMgdFF42jj ++z5UfoCoFqhKQ9uSSOshJ/Tig2+CzeSIOwmjpo0aacaDYJHmDR7TPl80fuHTFBmTKRH xGiQ==
X-Gm-Message-State: APjAAAXI0DDMOwAQKGjztJx7Povxjur4ovgdo3ODCBo/pvNzJk76ZtJ2 stZdrafilZfT1UvWvsQiRTDbQgpyVYJa2yDWw0qCY/+11blmmEJMhy9aEhE8SQmHKv53O6mExP2 rrr7jRQqG7/rJOfwtFrk=
X-Google-Smtp-Source: APXvYqyRLGj+5yz7NMQ9G0wey7JZhUYI4Om0BYAd9BLn4wBmPg7O6rM2JEoZyod6a4kKG23eEzvhF1EBVYXaOEMkUPQ=
X-Received: by 2002:a19:7d06:: with SMTP id y6mr4821712lfc.120.1572549658694;  Thu, 31 Oct 2019 12:20:58 -0700 (PDT)
MIME-Version: 1.0
References: <157254438077.30463.2012864551682668420.idtracker@ietfa.amsl.com>
In-Reply-To: <157254438077.30463.2012864551682668420.idtracker@ietfa.amsl.com>
From: Brian Campbell 
Date: Thu, 31 Oct 2019 13:20:32 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000cc715a059639bf44"
Archived-At: 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-fett-oauth-dpop-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 19:21:25 -0000

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

Hello WG,

Just a quick note to let folks know that -03 of the DPoP draft was
published earlier today. The usual various document links are in the
forwarded message below and the relevant snippet from the doc history with
a summary of the changes is included here for convenience.

Hopefully folks will have time to read the (relativity) short document
before the meeting(s) in Singapore where (spoiler alert) I plan to ask that
the WG consider adoption of the draft.

Thanks,

 -03
   o  rework the text around uniqueness requirements on the jti claim in
      the DPoP proof JWT
   o  make tokens a bit smaller by using "htm", "htu", and "jkt" rather
      than "http_method", "http_uri", and "jkt#S256" respectively
   o  more explicit recommendation to use mTLS if that is available
   o  added David Waite as co-author
   o  editorial updates

---------- Forwarded message ---------
From: 
Date: Thu, Oct 31, 2019 at 11:53 AM
Subject: New Version Notification for draft-fett-oauth-dpop-03.txt
To: Torsten Lodderstedt , Michael Jones <
mbj@microsoft.com>, John Bradley , Brian Campbell <
bcampbell@pingidentity.com>, David Waite ,
Daniel Fett 



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

Name:           draft-fett-oauth-dpop
Revision:       03
Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
Application Layer (DPoP)
Document date:  2019-10-30
Group:          Individual Submission
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-fett-oauth-dpop-03.txt
Status:         https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
Htmlized:       https://tools.ietf.org/html/draft-fett-oauth-dpop-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fett-oauth-dpop
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-fett-oauth-dpop-0=
3

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




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

The IETF Secretariat

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

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


Hello WG, 

Just a quick =
note to let folks know that -03 of the DPoP draft was published earlier tod=
ay. The usual various document links are in the forwarded message below and=
 the relevant snippet from the doc history with a summary of the changes is=
 included here for convenience. 

Hopefully fol=
ks will have time to read the (relativity) short document before the meetin=
g(s) in Singapore where (spoiler alert) I plan to ask that the WG consider =
adoption of the draft. 

Thanks,

=
=C2=A0-03
=C2=A0 =C2=A0o =C2=A0rework the text around uniqueness require=
ments on the jti claim in
=C2=A0 =C2=A0 =C2=A0 the DPoP proof JWT
=C2=
=A0 =C2=A0o =C2=A0make tokens a bit smaller by using "htm", "=
;htu", and "jkt" rather
=C2=A0 =C2=A0 =C2=A0 than "h=
ttp_method", "http_uri", and "jkt#S256" respective=
ly
=C2=A0 =C2=A0o =C2=A0more explicit recommendation to use mTLS if that=
 is available
=C2=A0 =C2=A0o =C2=A0added David Waite as co-author
=C2=
=A0 =C2=A0o =C2=A0editorial updates

---------- Forwarded message -=
--------
From: <internet-drafts@ietf.org>
Date=
: Thu, Oct 31, 2019 at 11:53 AM
Subject: New Version Notification for dr=
aft-fett-oauth-dpop-03.txt
To: Torsten Lodderstedt <torsten@lodderstedt.net>=
, Michael Jones <=
mbj@microsoft.com>, John Bradley <ve7jtb@ve7jtb.com>, Brian Campbell <bcampbell@pingid=
entity.com>, David Waite <david@alkaline-solutions.com>, Daniel Fet=
t <mail@danielfe=
tt.de>




A new version of I-D, draft-fett-oauth-dpop-03.txt

has been successfully submitted by Brian Campbell and posted to the

IETF repository.



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

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003

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

Document date:=C2=A0 2019-10-30

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15

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

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

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

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

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



Abstract:

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

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

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

=C2=A0 =C2=A0and refresh tokens.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat








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


From nobody Thu Oct 31 13:00:17 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F79120142 for ; Thu, 31 Oct 2019 13:00:15 -0700 (PDT)
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 d1nL09XemKBQ for ; Thu, 31 Oct 2019 13:00:14 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8BB12021C for ; Thu, 31 Oct 2019 13:00:13 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id y23so7569528ljc.5 for ; Thu, 31 Oct 2019 13:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=wp3HxP+gJNYahX2+1dYiQJXEHQeZfBmdYidW9y38dn8=; b=s91e44tXaXEvRGps0xJaHvUCHxpPwvV+Dglk3wMZzkhhSBsM/dvBTw5uWUpCoIpsqB J9+8JXmOGA++tCy4iJ2SsHBoroG4SrukFGLjMrNxBZVti0SNDKysV3HFuu+DruRBNowo SEsQgU8/UJ0wGKhNf/+NE9x6hUP0jvdc9ecgvxqjtqRCpQrM88WoO6rKIy3aiikn6B5s d/zq6KafiOzMdsf5xwt71SoR/ZlmlswptTgYd3yNxmvbQtDocbl6CGKLL69Zx9uEL1BS 1gVH6zzr+9BlohqFqCO7mZwPP54tlYv6RQfit/rZvIJ/gLY049nN3s1OPWwPqoWaClGU aX1w==
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=wp3HxP+gJNYahX2+1dYiQJXEHQeZfBmdYidW9y38dn8=; b=I5v9STUY1cvHbIyC6x4eTTan1O1msdOALJO9e7tZ+O/EjRtuouTlgm0H4t4WMH1fMO i1Fpui+uZYa2ebBuMmTMlx7ORP1QDB+ssB7ZZXBL3Nvw4PWedNkgnApXubD1YL19t+Dz WFGFg+UqdIVleGR/V2ZNyVnRFeEuifUkqCn7wtwJ8HdZnjJn/Jqh565j3JCGFMotN1XK 5AHWfcROipq2HsNAs+m5obPKJbaqadCowH/r3QmU3UvXjr9DXxZ5Stxb1VG6f4RblvdJ C3raJggY7e5S70kaU2wxs7s8pYSxrqp8TEr28qfeZ3XRk8aXLj8jdc2Dmzg/gNHPZMbi u6zg==
X-Gm-Message-State: APjAAAW6LyaejqBBElAM8iH8PMW7eYKAvIkc9kMPsW/Rf+7SG+z7bBAS 2j3t8Iim8yW2tmIR9Si9sE4JSKohUDvLCyJf0je2hVkFITo=
X-Google-Smtp-Source: APXvYqy7YpwTryzdNnk1omn6NuqtRvYZ30qM7CWwIDxbho6i7EmDYCl1CDrcPFWXLUC3rBWtTNUAtn7gH3my36XNi+Q=
X-Received: by 2002:a2e:a409:: with SMTP id p9mr5580672ljn.186.1572552011138;  Thu, 31 Oct 2019 13:00:11 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Thu, 31 Oct 2019 12:59:59 -0700
Message-ID: 
To: oauth@ietf.org
Cc: Annabelle Richard , "McAdams, Darin" ,  Adam Dawes , William Denniss ,  "Kumar, Bharath" 
Content-Type: multipart/alternative; boundary="00000000000003d71e05963a4c5d"
Archived-At: 
Subject: [OAUTH-WG] Interest in Reciprocal OAuth?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 31 Oct 2019 20:00:16 -0000

--00000000000003d71e05963a4c5d
Content-Type: text/plain; charset="UTF-8"

Hello OAuth people

Before I tune up the Reciprocal OAuth document per feedback, I'm checking
to see who is interested in the specification, and who is considering
deploying.

Alexa had the requirement originally, but I no longer work there, and I
have not seen any input from them.

Latest draft ...

https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-04

/Dick

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


Hello OAuth people

Bef=
ore I tune up the Reciprocal OAuth document per feedback, I'm checking =
to see who is interested in the specification, and who is considering deplo=
ying.=C2=A0

Alexa had the requirement originally, =
but I no longer work there, and I have not seen any input from them.
<=
div>
Latest draft ...=C2=A0


/Dick


--00000000000003d71e05963a4c5d--


From nobody Thu Oct 31 13:16:49 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEAF120255 for ; Thu, 31 Oct 2019 13:16:46 -0700 (PDT)
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 (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 8q1kE5e-ktIs for ; Thu, 31 Oct 2019 13:16:43 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF6112022C for ; Thu, 31 Oct 2019 13:16:42 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id p21so7314536wmg.2 for ; Thu, 31 Oct 2019 13:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Mxxe9b7GXhVZ5GL8mKfpLoIDLyfUoub34jS1HQ6utis=; b=DpCIgA0p5ZRtoA18nH7CG2eyjvET2EPNR7lYupocuSq403ka5CaybzkZXd7875F83y A35zn2i07xVbLDwEGio3Owu+jlIzceIQ3GPJl36HYkg3F06TmMTPEdmTokmW1dMaqPTA Ef7YqeMAsAmkQskRsbZ06YpRUvePtawQ8ok4g=
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=Mxxe9b7GXhVZ5GL8mKfpLoIDLyfUoub34jS1HQ6utis=; b=Yyesjb8e3mFfdPz9pcAjyRgy3SYnmvnHYN/xEvpaI9UUbNz6I3XwcdQIa/m5bKCpiu fUQUMTz7f4aM+xc9ED8WkKN2ljAFqcmGGix7lhc9E2IIw9dwuEpreRNyd9DUHDiWqkeJ bcIc5n0UT4XA24g4nP4zi1sVsaTC9+SofWZthpZS76BJ47ES+cUAcTKyPcW169HnTEYw KWlHsIP94s2nBr/WEp00GPK8Mi54QFgKHSXoZiu21z8ItiOD0oM3vtlz+USxzVkpy6Nl 3PseCpMT1X9PlAdhbeXkpUJpY7fYBcv6S2fBERNpjJLD82Uxedia4fITj3020yD4AFnp zwRA==
X-Gm-Message-State: APjAAAUy0p+xZNvn9nuqHMOLMf5EcdYpQsm7hKi++x7XSX2EZi/xUTC2 qHSb3454eyOoIr1i52/hZ/JI+g==
X-Google-Smtp-Source: APXvYqyF1cfbHVlrGrn87F9e8qf5Ux6TzfoIGKd2ukguAbGIPpn8Nysbc6c86enC3ZQsAEaNxxSjxQ==
X-Received: by 2002:a1c:544e:: with SMTP id p14mr6696996wmi.17.1572553001123;  Thu, 31 Oct 2019 13:16:41 -0700 (PDT)
Received: from ?IPv6:2a01:4c8:f:b76f:8df3:da5f:6b92:be99? ([2a01:4c8:f:b76f:8df3:da5f:6b92:be99]) by smtp.gmail.com with ESMTPSA id x7sm7941620wrg.63.2019.10.31.13.16.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Oct 2019 13:16:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2AEC8239-D615-4BC0-B7E5-97B29305D9DA
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Thu, 31 Oct 2019 20:16:39 +0000
Message-Id: <01E27CED-383F-4E5A-B092-4D176A217C6C@forgerock.com>
References: 
Cc: "oauth@ietf.org" 
In-Reply-To: 
To: "Richard Backman, Annabelle" 
X-Mailer: iPhone Mail (17A878)
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 20:16:47 -0000

--Apple-Mail-2AEC8239-D615-4BC0-B7E5-97B29305D9DA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 31 Oct 2019, at 18:55, Richard Backman, Annabelle  wrote:
>=20
> =EF=BB=BF
> Relying on a fixed, random header name for security, even as a =E2=80=9Cde=
fense in depth=E2=80=9D measure, is dangerous. In order for this mechanism t=
o be effective, the header name must be random (in the cryptographic sense) a=
nd must be kept secret. It needs to be withheld from request logs or error l=
ogs, either on the reverse proxy or on the service. It cannot be committed t=
o code repositories.

Just like any other bearer token. I mean this is the *OAuth* WG, right? Wher=
e we regularly recommend people send bearer tokens in headers? I don=E2=80=99=
t really understand how that can be considered secure to send over the inter=
net to a cloud service, but suddenly becomes insecure when done inside the f=
irewall within a datacenter between a reverse proxy and an app server.=20

I mean, are people honestly suggesting that randomizing header names introdu=
ces *new* vulnerabilities that aren=E2=80=99t present when you use a well-kn=
own name? =E2=80=9CDangerous=E2=80=9D even!=20

> Including it as a signed header in request signing algorithms that require=
 an explicit list of signed headers (such as AWS Signature Version 4, draft-=
cavage-http-signatures, draft-ietf-oauth-signed-http-request) turns that sig=
nature metadata into a secret, meaning that it cannot be logged, etc. If sig=
natures are sent to a central authority for processing, that authority must a=
lso know not to log the list of signed headers. I could go on, but I hope th=
is is enough to express that there are SO MANY ways that header names can an=
d will be revealed, and they aren=E2=80=99t always obvious.
> =20
> What we are talking about is a message authenticity problem. The best prac=
tices for providing message authenticity involve applied crypto, e.g., an HM=
AC or digital signature over the header contents. If an implementation does t=
hat, then the random header name is unnecessary. This approach is immune to t=
he sort of misconfiguration scenarios that have been discussed in this threa=
d, as they would result in the reverse proxy failing to provide a properly s=
igned header to the service.

I agree that HMAC signatures are generally better, but which reverse proxies=
 support signing headers?

Actually HMAC signatures do have one significant downside compared to using a=
 random header name - if you forget to validate the signature *nothing fails=
*. If you mess up the name of a random header then your app doesn=E2=80=99t s=
ee any credentials and fails noisily.=20

=E2=80=94 Neil=

--Apple-Mail-2AEC8239-D615-4BC0-B7E5-97B29305D9DA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 31 Oct 2019, at 18:55, R=
ichard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wro=
te:

<=
blockquote type=3D"cite">
=EF=BB=BF









Relying on a fixed, random header name for security, e=
ven as a =E2=80=9Cdefense in depth=E2=80=9D measure, is dangerous. In order f=
or this mechanism to be effective, the header name must be random (in the cr=
yptographic sense) and must be kept secret. It
 needs to be withheld from request logs or error logs, either on the reverse=
 proxy or on the service. It cannot be committed to code repositories. 
<=
/div>

Just like any other bearer token=
. I mean this is the *OAuth* WG, right? Where we regularly recommend people s=
end bearer tokens in headers? I don=E2=80=99t really understand how that can=
 be considered secure to send over the internet to a cloud service, but sudd=
enly becomes insecure when done inside the firewall within a datacenter betw=
een a reverse proxy and an app server. 

I mean=
, are people honestly suggesting that randomizing header names introduces *n=
ew* vulnerabilities that aren=E2=80=99t present when you use a well-known na=
me? =E2=80=9CDangerous=E2=80=9D even! 

Inclu=
ding it as a signed header in request signing algorithms that require an exp=
licit list of signed headers
 (such as 
AWS Signature Version 4, 
draft-cavage-http-signatures, 
draft-ietf-oauth-signed-http-request) turns that signature metadata into=
 a secret, meaning that
it cannot be logged, etc. If signatures are sent to a central authori=
ty for processing, that authority must also know not to log the list of sign=
ed headers. I could go on, but I hope this is enough to express that there a=
re SO MANY ways that header names
 can and will be revealed, and they aren=E2=80=99t always obvious.
=



 


What we are talking about is a message authenticity p=
roblem. The best practices for providing message authenticity involve applie=
d crypto, e.g., an HMAC or digital signature over the header contents. If an=
 implementation does that, then
 the random header name is unnecessary. This approach is immune to the sort o=
f misconfiguration scenarios that have been discussed in this thread, as the=
y would result in the reverse proxy failing to provide a properly signed hea=
der to the service.

I agree t=
hat HMAC signatures are generally better, but which reverse proxies support s=
igning headers?

Actually HMAC signatures do have on=
e significant downside compared to using a random header name - if you forge=
t to validate the signature *nothing fails*. If you mess up the name of a ra=
ndom header then your app doesn=E2=80=99t see any credentials and fails nois=
ily. 

=E2=80=94 Neil
=

--Apple-Mail-2AEC8239-D615-4BC0-B7E5-97B29305D9DA--


From nobody Thu Oct 31 13:48:42 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75751200D5 for ; Thu, 31 Oct 2019 13:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 bj63TT7ZejD5 for ; Thu, 31 Oct 2019 13:48:37 -0700 (PDT)
Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.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 3647E120826 for ; Thu, 31 Oct 2019 13:48:37 -0700 (PDT)
Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id QHMtiu4uUnaIyQHMwizPFA; Thu, 31 Oct 2019 13:48:35 -0700
To: oauth@ietf.org
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu>        <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu>    <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> 
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Organization: Connect2id Ltd.
Message-ID: <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com>
Date: Thu, 31 Oct 2019 22:48:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------28BACAD22C56612523513F3C"
Content-Language: en-US
X-CMAE-Envelope: MS4wfNh0zfx9ULV9tqZjhoAe1IhsBIkUD7zHItaATL6M7zrM1RVrC/o+78GL5EjZmlNGkqSCN4JTrnh0FFb5QyCs1eEQvjmrQxXbVvZVXfQDAEjdLF4vm32p OFKzvQsQ04son6zTdYiljJkm232EydcjYgY/5bmN2veSo7AFBw4CDl3v
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 20:48:41 -0000

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

I agree wholeheartedly that an HMAC or even signature is preferable.
With HMAC vs signature having their relative pros / cons, in terms of
computation and key distribution. If a standard for that is created, and
I am a web application developer, I'll be able to handle the header
checks in the application layer code relatively easily. But I have much
less control over how / where the application is going to be deployed,
and if the reverse proxy has this header security implemented. Software
and cloud vendors can sometimes be significantly behind in such
developments. Even basic handling of self-signed client certificates has
been an issue for us in popular cloud environments.

With that in mind, the "secret" headers can be configured with most
currently available reverse proxy software. I see it as a useful
intermediate step, until a standard for authenticated headers gets
agreed on and eventually implemented in reverse proxies. Can you comment
on that from this perspective?

Over the years I have come to the conclusion that standards which can be
implemented in the application layer or as a simple config stand a
better chance. Standards which rely on other layers or on broad vendor
or developer support to become useful run the risk of not getting
adopted in practice. Token binding suffered from that.

Vladimir

On 31/10/2019 20:55, Richard Backman, Annabelle wrote:
>
> Relying on a fixed, random header name for security, even as a
> “defense in depth” measure, is dangerous. In order for this mechanism
> to be effective, the header name must be random (in the cryptographic
> sense) and must be kept secret. It needs to be withheld from request
> logs or error logs, either on the reverse proxy or on the service. It
> cannot be committed to code repositories. Including it as a signed
> header in request signing algorithms that require an explicit list of
> signed headers (such as AWS Signature Version 4
> ,
> draft-cavage-http-signatures
> ,
> draft-ietf-oauth-signed-http-request
> )
> turns that signature metadata into a secret, meaning that /it/ cannot
> be logged, etc. If signatures are sent to a central authority for
> processing, that authority must also know not to log the list of
> signed headers. I could go on, but I hope this is enough to express
> that there are SO MANY ways that header names can and will be
> revealed, and they aren’t always obvious.
>
>  
>
> What we are talking about is a message authenticity problem. The best
> practices for providing message authenticity involve applied crypto,
> e.g., an HMAC or digital signature over the header contents. If an
> implementation does that, then the random header name is unnecessary.
> This approach is immune to the sort of misconfiguration scenarios that
> have been discussed in this thread, as they would result in the
> reverse proxy failing to provide a properly signed header to the service.
>
>  
>
> – 
>
> Annabelle Richard Backman
>
> AWS Identity
>
>  
>
>  
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov
> 
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>  
>
> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will  cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think
> Rich Salz had this concern).
>
> * The random chars part, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
>
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
>     the way I see this is that stripping and setting the headers must
>     be part of the implementation of the protocol itself, it should
>     not be something left to a non-atomic piece of configuration by an
>     administrator; I implemented it like this in the Apache
>     implementation of Brian's TTRP spec [1] and have been doing this
>     for the OIDC and OAuth Apache modules that set headers for
>     backends to consume [2]; and yes, I have made mistakes [3], but
>     IMHO it should not be a problem to use a well known header and
>     make the implementer (not the admin) get it right by pointing this
>     out in the spec, as is done for many other pitfalls
>
>      
>
>     Hans.
>
>      
>
>     [1] https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483
>
>     [2] https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175
>
>     [3] https://www.cvedetails.com/cve/CVE-2017-6413/
>
>      
>
>     On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov
>     > wrote:
>
>             All in all, I am in favor of this being defined in one
>             standard way, in addition to secure communication between
>             proxies and backends being standardized — but this latter
>             bit really seems like a separate problem.
>
>              
>
>              — Justin
>
>         -1 for devising a well known header
>
>         +1 for a simple way to authenticate a reverse proxy with a web
>         server
>
>         With a well known name, in a attack this will get probed
>         first. The well known header name doesn't guarantee a correct
>         config. And if we have a new standard for sec headers that
>         must be stripped automatically from inbound HTTP requests, we
>         cannot expect that will get implemented in all reverse proxy
>         software overnight.
>
>         Because a correct config is not practical as the only line of
>         defense, when we implemented mTLS we decided to add a length
>         (>= 32 chars) and randomness check to the header config. I saw
>         some concerns that this may cause deployment issues. Nobody
>         has complained about that so far.
>
>         https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader
>
>         Regarding mistyping, this can be an issue, but has little to
>         no effect if a long random header gets misstyped (from the
>         inbound strip directive). With a well known header this will
>         result in a immediate security hole, which can theoretically
>         go unnoticed.
>
>         Here is an example Apache httpd config, to illustrate my point:
>
>         RequestHeader set
>         Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
>
>         RequestHeader set
>         Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing
>         "%{SSL_CLIENT_CERT}s"
>
>         (the first line strips the inbound headers)
>
>          
>
>         Vladimir
>
>         -- 
>
>         Vladimir Dzhuvinov
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org 
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>      
>
>     -- 
>
>     hans.zandbelt@zmartzone.eu 
>
>     ZmartZone IAM - www.zmartzone.eu 
>
> -- 
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
I agree wholeheartedly that an HMAC or even signature is
      preferable. With HMAC vs signature having their relative pros /
      cons, in terms of computation and key distribution. If a standard
      for that is created, and I am a web application developer, I'll be
      able to handle the header checks in the application layer code
      relatively easily. But I have much less control over how / where
      the application is going to be deployed, and if the reverse proxy
      has this header security implemented. Software and cloud vendors
      can sometimes be significantly behind in such developments. Even
      basic handling of self-signed client certificates has been an
      issue for us in popular cloud environments.

    

    
With that in mind, the "secret" headers can be configured with
      most currently available reverse proxy software. I see it as a
      useful intermediate step, until a standard for authenticated
      headers gets agreed on and eventually implemented in reverse
      proxies. Can you comment on that from this perspective?

    
Over the years I have come to the conclusion that standards which
      can be implemented in the application layer or as a simple config
      stand a better chance. Standards which rely on other layers or on
      broad vendor or developer support to become useful run the risk of
      not getting adopted in practice. Token binding suffered from that.

    

    
Vladimir

    

    
On 31/10/2019 20:55, Richard Backman,
      Annabelle wrote:

    

    

      
      
      
      

        
Relying on a fixed, random header name for
          security, even as a “defense in depth” measure, is dangerous.
          In order for this mechanism to be effective, the header name
          must be random (in the cryptographic sense) and must be kept
          secret. It needs to be withheld from request logs or error
          logs, either on the reverse proxy or on the service. It cannot
          be committed to code repositories. Including it as a signed
          header in request signing algorithms that require an explicit
          list of signed headers (such as 
            AWS Signature Version 4, 
            draft-cavage-http-signatures, 
            draft-ietf-oauth-signed-http-request) turns that
          signature metadata into a secret, meaning that
          it cannot be logged, etc. If signatures are sent to a
          central authority for processing, that authority must also
          know not to log the list of signed headers. I could go on, but
          I hope this is enough to express that there are SO MANY ways
          that header names can and will be revealed, and they aren’t
          always obvious.

        
 

        
What we are talking about is a message
          authenticity problem. The best practices for providing message
          authenticity involve applied crypto, e.g., an HMAC or digital
          signature over the header contents. If an implementation does
          that, then the random header name is unnecessary. This
          approach is immune to the sort of misconfiguration scenarios
          that have been discussed in this thread, as they would result
          in the reverse proxy failing to provide a properly signed
          header to the service.

        

          
 

          
– 

          
Annabelle
              Richard Backman

          
AWS
              Identity

        

        
 

        
 

        

          
From: OAuth
              <oauth-bounces@ietf.org> on behalf of Vladimir
              Dzhuvinov <vladimir@connect2id.com>

              Organization: Connect2id Ltd.

              Date: Thursday, October 31, 2019 at 4:27 AM

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

              Subject: Re: [OAUTH-WG] client certs and TLS
              Terminating Reverse Proxies (was Re: I-D Action:
              draft-ietf-oauth-jwt-introspection-response-08.txt)

        

        

          
 

        

        
This is a good story.

        
How about requiring reverse proxies to automatically scrub
          all inbound HTTP headers that start with "Sec-"?

        
If a sec header has the format "Sec-[NAME]-[random-chars]" we
          get:

        
* The "Sec-" prefix will  cause new compliant reserve proxies
          to automatically scrub the inbound HTTP header.

        
* The NAME part still makes the header easily identifiable (I
          think Rich Salz had this concern).

        
* The random chars part, potentially optional, will provide a
          line of defence against config errors in old legacy reverse
          proxies.

        
All concerns should then get covered.

        
Vladimir

        

          
On 31/10/2019 12:48, Hans Zandbelt wrote:

        

        

          

            

              
the way I see this is that stripping
                and setting the headers must be part of the
                implementation of the protocol itself, it should not be
                something left to a non-atomic piece of configuration by
                an administrator; I implemented it like this in the
                Apache implementation of Brian's TTRP spec [1] and have
                been doing this for the OIDC and OAuth Apache modules
                that set headers for backends to consume [2]; and yes, I
                have made mistakes [3], but IMHO it should not be a
                problem to use a well known header and make the
                implementer (not the admin) get it right by pointing
                this out in the spec, as is done for many other pitfalls
                

              

                
 

              

              

                
Hans.

              

              

                
 

              

              
              
              
            

            
 

            

              

                
On Thu, Oct 31, 2019 at 11:37 AM
                  Vladimir Dzhuvinov <vladimir@connect2id.com>
                  wrote:

              

              

                

                  

                    

                      
All in all, I am in favor of
                        this being defined in one standard way, in
                        addition to secure communication between proxies
                        and backends being standardized — but this
                        latter bit really seems like a separate problem.

                    

                    

                      
 

                    

                    

                      
 — Justin

                    

                  

                  
-1 for devising a well known header

                  
+1 for a simple way to authenticate a reverse proxy
                    with a web server

                  
With a well known name, in a attack this will get
                    probed first. The well known header name doesn't
                    guarantee a correct config. And if we have a new
                    standard for sec headers that must be stripped
                    automatically from inbound HTTP requests, we cannot
                    expect that will get implemented in all reverse
                    proxy software overnight.

                  
Because a correct config is not practical as the
                    only line of defense, when we implemented mTLS we
                    decided to add a length (>= 32 chars) and
                    randomness check to the header config. I saw some
                    concerns that this may cause deployment issues.
                    Nobody has complained about that so far.

                  
https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader

                  
Regarding mistyping, this can be an issue, but has
                    little to no effect if a long random header gets
                    misstyped (from the inbound strip directive). With a
                    well known header this will result in a immediate
                    security hole, which can theoretically go unnoticed.
                    

                  
Here is an example Apache httpd config, to
                    illustrate my point:

                  
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""

                  
RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"

                  
(the first line strips the inbound headers)

                  
 

                  
Vladimir

                  
-- 

                  
Vladimir Dzhuvinov

                

                
_______________________________________________

                  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


    

    

  


--------------28BACAD22C56612523513F3C--


From nobody Thu Oct 31 14:09:17 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6809D120826 for ; Thu, 31 Oct 2019 14:09:15 -0700 (PDT)
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 MCwQZ9sqTB2D for ; Thu, 31 Oct 2019 14:09:13 -0700 (PDT)
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 CB4C6120090 for ; Thu, 31 Oct 2019 14:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1572556153; x=1604092153; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YTYBy8HlAjjVjG+U4dzvWlrnAkTrDfPRwbukg0BqRUs=; b=FB1piUWsNFKiNNVKPdFs4623DZ0NtOjDo2hha8lf7nThGgOMjQ5TBXS4 jCoBJug3N/ZVGHfTUeVwFXePqRSaIKDTZzpbyeVXtMErgS1cZJNdLThWr HvN1YrXkaGKUooxtNC88xb4v8In/yBd51RV5sWeVW+PwE+epd6d7CgC3z E=;
IronPort-SDR: ukw5nlKt/np/WyicLy9LG2em68d15AX0PZmPG73k7Zp3PoCXbgAXAxAwFIfARLmQHgqLOEEEto EqlON3YoYmoA==
X-IronPort-AV: E=Sophos;i="5.68,253,1569283200"; d="scan'208,217";a="2463338"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-67b371d8.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 31 Oct 2019 21:08:55 +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-67b371d8.us-east-1.amazon.com (Postfix) with ESMTPS id E4E37A1701; Thu, 31 Oct 2019 21:08:53 +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, 31 Oct 2019 21:08:53 +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, 31 Oct 2019 21:08:52 +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, 31 Oct 2019 21:08:52 +0000
From: "Richard Backman, Annabelle" 
To: Neil Madden 
CC: "oauth@ietf.org" 
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
Thread-Index: AQHVi20khjnyTeh9jkqsJQFVhb6GPqdteSoAgAKKHACAACgOAIAAB6CAgAAQz4CAAb9SAIAALTaAgAJnDoCAAANWAIAACmUAgAAIPgCAAIwIgP//mT4A
Date: Thu, 31 Oct 2019 21:08:52 +0000
Message-ID: 
References:  <01E27CED-383F-4E5A-B092-4D176A217C6C@forgerock.com>
In-Reply-To: <01E27CED-383F-4E5A-B092-4D176A217C6C@forgerock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1b.0.190715
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.5]
Content-Type: multipart/alternative; boundary="_000_CF72E390C79D4CA98DEE546B992F91B6amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 21:09:15 -0000

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

VGhlIGNvbXBhcmlzb24gdGhlIGJlYXJlciB0b2tlbnMgaXMgaWxsdXN0cmF0aXZlIG9mIHRoZSBw
cm9ibGVtcyBJIGFuZCBvdGhlcnMgYXJlIHBvaW50aW5nIG91dDoNCg0KICAqICAgQmVhcmVyIHRv
a2VucyBhcmUgZW1iZWRkZWQgaW4gdGhlIHZhbHVlIG9mIHRoZSBoZWFkZXIsIG5vdCB0aGUgaGVh
ZGVyIGl0c2VsZiwgd2hpY2ggcGFydGlhbGx5IGFsbGV2aWF0ZXMgdGhlIGNvbmNlcm4gSSByYWlz
ZWQgcmVnYXJkaW5nIHJlcXVlc3Qgc2lnbmluZyBhbGdvcml0aG1zLg0KICAqICAgQmVhcmVyIHRv
a2VucyBhcmUgdHlwaWNhbGx5IHJlbGF0aXZlbHkgc2hvcnQtbGl2ZWQsIHByb3ZpZGluZyBzb21l
IG1pdGlnYXRpb24gYWdhaW5zdCBleGZpbHRyYXRpb24gdGhyb3VnaCBsb2dzLg0KICAqICAgQmVh
cmVyIHRva2VucyBhcmUgdHlwaWNhbGx5IGR5bmFtaWNhbGx5IGdlbmVyYXRlZCwgYW5kIGFyZSB0
aGVyZWZvcmUgbGVzcyBsaWtlbHkgdG8gYmUgZW1iZWRkZWQgaW4gc291cmNlIGNvZGUgb3IgY29u
ZmlnIGZpbGVzIGluIGEgcHJvamVjdOKAmXMgcmVwb3NpdG9yeS4NCiAgKiAgIEJlYXJlciB0b2tl
bnMgYXJlIGNhbGxlZCB0b2tlbnMsIGFuZCBhcmUgcHJlc2VudGVkIGFzIHNlY3JldHMgYW5kIGFy
ZSBhbHdheXMgZXhwZWN0ZWQgdG8gYmUgdHJlYXRlZCBhcyBzZWNyZXRzLg0KDQpUaGUgcmFuZG9t
IGhlYWRlciBuYW1lIGlzIGVmZmVjdGl2ZWx5IGFuIGluZmluaXRlLWxpZmV0aW1lLCBzdGF0aWNh
bGx5IGRlZmluZWQgYmVhcmVyIHRva2VuIHByZXNlbnRlZCBpbiBhIHdheSB0aGF0IGRvZXMgbm90
IGF0IGFsbCBtYWtlIGNsZWFyIGFuZCBvYnZpb3VzIHRoYXQgaXQgaXMgYSBzZWNyZXQgdGhhdCBt
dXN0IGJlIHByb3RlY3RlZCwgYW5kIGluIGZhY3QgbWFrZXMgaXQgbW9yZSBsaWtlbHkgdGhhdCBp
dCB3aWxsIGJlIHJldmVhbGVkLCByZW5kZXJpbmcgaXQgdXNlbGVzcy4gQW5kIGxpa2UgYWxsIGJl
YXJlciB0b2tlbnMsIGV2ZW4gdW5kZXIgaWRlYWwgY29uZGl0aW9ucyBpdCBieSBkZWZpbml0aW9u
IENBTk5PVCBCRSBVU0VEIFRPIEFVVEhFTlRJQ0FURSBUSEUgU0VOREVSLg0KDQpUaGVyZSBpcyBh
IGNlcnRhaW4gYW1vdW50IG9mIGlyb255IGluIHRoZSBpZGVhIG9mIHRoZSBzZWN1cml0eSBvZiBh
IE11dHVhbCBUTFMgZGVwbG95bWVudCB1bHRpbWF0ZWx5IGNvbWluZyBkb3duIHRvIGEgYmVhcmVy
LXRva2VuIGhlYWRlciBuYW1lIHBhc3NlZCBiZXR3ZWVuIHRoZSByZXZlcnNlIHByb3h5IGFuZCB0
aGUgcHJvdGVjdGVkIHNlcnZpY2UuIPCfmIINCg0KPiBpZiB5b3UgZm9yZ2V0IHRvIHZhbGlkYXRl
IHRoZSBzaWduYXR1cmUgKm5vdGhpbmcgZmFpbHMqDQoNClJlcGxhY2UgdGhlIEhNQUMgd2l0aCBl
bmNyeXB0aW9uIGFuZCB5b3Ugc29sdmUgdGhhdCBwcm9ibGVtLCBhcyBpdCBmb3JjZXMgdGhlIHNl
cnZpY2UgdG8gZGVjcnlwdCB0aGUgdmFsdWUgdXNpbmcgdGhlIGNvcnJlY3Qga2V5IGluIG9yZGVy
IHRvIGFjY2VzcyB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGRhdGEuIFdoZXRoZXIgb3Igbm90IHRo
YXTigJlzIHdvcnRoIGRvaW5nIGlzIHNvbWV0aGluZyB3ZSBjYW4gZGViYXRlIGluIHRoZSBjb250
ZXh0IG9mIGFuIGFjdHVhbCBwcm9wb3NhbC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNr
bWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9y
Z2Vyb2NrLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDMxLCAyMDE5IGF0IDE6MTcgUE0N
ClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0K
Q2M6ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW1VOVkVSSUZJ
RUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBjbGllbnQgY2VydHMgYW5kIFRMUyBUZXJtaW5hdGlu
ZyBSZXZlcnNlIFByb3hpZXMgKHdhcyBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1q
d3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wOC50eHQpDQoNCk9uIDMxIE9jdCAyMDE5LCBhdCAx
ODo1NSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBk
bWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNClJlbHlpbmcgb24gYSBmaXhlZCwgcmFuZG9tIGhlYWRl
ciBuYW1lIGZvciBzZWN1cml0eSwgZXZlbiBhcyBhIOKAnGRlZmVuc2UgaW4gZGVwdGjigJ0gbWVh
c3VyZSwgaXMgZGFuZ2Vyb3VzLiBJbiBvcmRlciBmb3IgdGhpcyBtZWNoYW5pc20gdG8gYmUgZWZm
ZWN0aXZlLCB0aGUgaGVhZGVyIG5hbWUgbXVzdCBiZSByYW5kb20gKGluIHRoZSBjcnlwdG9ncmFw
aGljIHNlbnNlKSBhbmQgbXVzdCBiZSBrZXB0IHNlY3JldC4gSXQgbmVlZHMgdG8gYmUgd2l0aGhl
bGQgZnJvbSByZXF1ZXN0IGxvZ3Mgb3IgZXJyb3IgbG9ncywgZWl0aGVyIG9uIHRoZSByZXZlcnNl
IHByb3h5IG9yIG9uIHRoZSBzZXJ2aWNlLiBJdCBjYW5ub3QgYmUgY29tbWl0dGVkIHRvIGNvZGUg
cmVwb3NpdG9yaWVzLg0KDQpKdXN0IGxpa2UgYW55IG90aGVyIGJlYXJlciB0b2tlbi4uIEkgbWVh
biB0aGlzIGlzIHRoZSAqT0F1dGgqIFdHLCByaWdodD8gV2hlcmUgd2UgcmVndWxhcmx5IHJlY29t
bWVuZCBwZW9wbGUgc2VuZCBiZWFyZXIgdG9rZW5zIGluIGhlYWRlcnM/IEkgZG9u4oCZdCByZWFs
bHkgdW5kZXJzdGFuZCBob3cgdGhhdCBjYW4gYmUgY29uc2lkZXJlZCBzZWN1cmUgdG8gc2VuZCBv
dmVyIHRoZSBpbnRlcm5ldCB0byBhIGNsb3VkIHNlcnZpY2UsIGJ1dCBzdWRkZW5seSBiZWNvbWVz
IGluc2VjdXJlIHdoZW4gZG9uZSBpbnNpZGUgdGhlIGZpcmV3YWxsIHdpdGhpbiBhIGRhdGFjZW50
ZXIgYmV0d2VlbiBhIHJldmVyc2UgcHJveHkgYW5kIGFuIGFwcCBzZXJ2ZXIuDQoNCkkgbWVhbiwg
YXJlIHBlb3BsZSBob25lc3RseSBzdWdnZXN0aW5nIHRoYXQgcmFuZG9taXppbmcgaGVhZGVyIG5h
bWVzIGludHJvZHVjZXMgKm5ldyogdnVsbmVyYWJpbGl0aWVzIHRoYXQgYXJlbuKAmXQgcHJlc2Vu
dCB3aGVuIHlvdSB1c2UgYSB3ZWxsLWtub3duIG5hbWU/IOKAnERhbmdlcm91c+KAnSBldmVuIQ0K
DQoNCkluY2x1ZGluZyBpdCBhcyBhIHNpZ25lZCBoZWFkZXIgaW4gcmVxdWVzdCBzaWduaW5nIGFs
Z29yaXRobXMgdGhhdCByZXF1aXJlIGFuIGV4cGxpY2l0IGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMg
KHN1Y2ggYXMgQVdTIFNpZ25hdHVyZSBWZXJzaW9uIDQ8aHR0cHM6Ly9kb2NzLmF3cy5hbWF6b24u
Y29tL2dlbmVyYWwvbGF0ZXN0L2dyL3NpZ25hdHVyZS12ZXJzaW9uLTQuaHRtbD4sIGRyYWZ0LWNh
dmFnZS1odHRwLXNpZ25hdHVyZXM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh
dmFnZS1odHRwLXNpZ25hdHVyZXMtMTI+LCBkcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJl
cXVlc3Q8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2lnbmVk
LWh0dHAtcmVxdWVzdD4pIHR1cm5zIHRoYXQgc2lnbmF0dXJlIG1ldGFkYXRhIGludG8gYSBzZWNy
ZXQsIG1lYW5pbmcgdGhhdCBpdCBjYW5ub3QgYmUgbG9nZ2VkLCBldGMuIElmIHNpZ25hdHVyZXMg
YXJlIHNlbnQgdG8gYSBjZW50cmFsIGF1dGhvcml0eSBmb3IgcHJvY2Vzc2luZywgdGhhdCBhdXRo
b3JpdHkgbXVzdCBhbHNvIGtub3cgbm90IHRvIGxvZyB0aGUgbGlzdCBvZiBzaWduZWQgaGVhZGVy
cy4gSSBjb3VsZCBnbyBvbiwgYnV0IEkgaG9wZSB0aGlzIGlzIGVub3VnaCB0byBleHByZXNzIHRo
YXQgdGhlcmUgYXJlIFNPIE1BTlkgd2F5cyB0aGF0IGhlYWRlciBuYW1lcyBjYW4gYW5kIHdpbGwg
YmUgcmV2ZWFsZWQsIGFuZCB0aGV5IGFyZW7igJl0IGFsd2F5cyBvYnZpb3VzLg0KDQpXaGF0IHdl
IGFyZSB0YWxraW5nIGFib3V0IGlzIGEgbWVzc2FnZSBhdXRoZW50aWNpdHkgcHJvYmxlbS4gVGhl
IGJlc3QgcHJhY3RpY2VzIGZvciBwcm92aWRpbmcgbWVzc2FnZSBhdXRoZW50aWNpdHkgaW52b2x2
ZSBhcHBsaWVkIGNyeXB0bywgZS5nLiwgYW4gSE1BQyBvciBkaWdpdGFsIHNpZ25hdHVyZSBvdmVy
IHRoZSBoZWFkZXIgY29udGVudHMuIElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgdGhhdCwgdGhl
biB0aGUgcmFuZG9tIGhlYWRlciBuYW1lIGlzIHVubmVjZXNzYXJ5LiBUaGlzIGFwcHJvYWNoIGlz
IGltbXVuZSB0byB0aGUgc29ydCBvZiBtaXNjb25maWd1cmF0aW9uIHNjZW5hcmlvcyB0aGF0IGhh
dmUgYmVlbiBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGFzIHRoZXkgd291bGQgcmVzdWx0IGlu
IHRoZSByZXZlcnNlIHByb3h5IGZhaWxpbmcgdG8gcHJvdmlkZSBhIHByb3Blcmx5IHNpZ25lZCBo
ZWFkZXIgdG8gdGhlIHNlcnZpY2UuDQoNCkkgYWdyZWUgdGhhdCBITUFDIHNpZ25hdHVyZXMgYXJl
IGdlbmVyYWxseSBiZXR0ZXIsIGJ1dCB3aGljaCByZXZlcnNlIHByb3hpZXMgc3VwcG9ydCBzaWdu
aW5nIGhlYWRlcnM/DQoNCkFjdHVhbGx5IEhNQUMgc2lnbmF0dXJlcyBkbyBoYXZlIG9uZSBzaWdu
aWZpY2FudCBkb3duc2lkZSBjb21wYXJlZCB0byB1c2luZyBhIHJhbmRvbSBoZWFkZXIgbmFtZSAt
IGlmIHlvdSBmb3JnZXQgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSAqbm90aGluZyBmYWlscyou
IElmIHlvdSBtZXNzIHVwIHRoZSBuYW1lIG9mIGEgcmFuZG9tIGhlYWRlciB0aGVuIHlvdXIgYXBw
IGRvZXNu4oCZdCBzZWUgYW55IGNyZWRlbnRpYWxzIGFuZCBmYWlscyBub2lzaWx5Lg0KDQrigJQg
TmVpbA0K

--_000_CF72E390C79D4CA98DEE546B992F91B6amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3ACFD559D550084C9C63D73A55331AC4@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6
MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg
NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z
b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0
eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0
b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5t
c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt
ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp
bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u
dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu
LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg
UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUy
MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEwNzA0MzUyNTsNCgltc28tbGlzdC10
eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODEzMDc4ODYwIC00Mzk5ODQwMzYg
Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2
OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Ik1TIE1p
bmNobyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg
bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs
Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb21wYXJpc29uIHRoZSBiZWFyZXIgdG9rZW5z
IGlzIGlsbHVzdHJhdGl2ZSBvZiB0aGUgcHJvYmxlbXMgSSBhbmQgb3RoZXJzIGFyZSBwb2ludGlu
ZyBvdXQ6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk
aXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp
bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QmVhcmVyIHRva2VucyBhcmUgZW1iZWRkZWQgaW4g
dGhlIHZhbHVlIG9mIHRoZSBoZWFkZXIsIG5vdCB0aGUgaGVhZGVyIGl0c2VsZiwgd2hpY2ggcGFy
dGlhbGx5IGFsbGV2aWF0ZXMgdGhlIGNvbmNlcm4gSSByYWlzZWQgcmVnYXJkaW5nIHJlcXVlc3Qg
c2lnbmluZyBhbGdvcml0aG1zLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh
Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkJl
YXJlciB0b2tlbnMgYXJlIHR5cGljYWxseSByZWxhdGl2ZWx5IHNob3J0LWxpdmVkLCBwcm92aWRp
bmcgc29tZSBtaXRpZ2F0aW9uIGFnYWluc3QgZXhmaWx0cmF0aW9uIHRocm91Z2ggbG9ncy48bzpw
PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5CZWFyZXIgdG9rZW5zIGFyZSB0eXBpY2Fs
bHkgZHluYW1pY2FsbHkgZ2VuZXJhdGVkLCBhbmQgYXJlIHRoZXJlZm9yZSBsZXNzIGxpa2VseSB0
byBiZSBlbWJlZGRlZCBpbiBzb3VyY2UgY29kZSBvciBjb25maWcgZmlsZXMgaW4gYSBwcm9qZWN0
4oCZcyByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh
cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkJlYXJl
ciB0b2tlbnMgYXJlIGNhbGxlZA0KPGk+dG9rZW5zPC9pPiwgYW5kIGFyZSBwcmVzZW50ZWQgYXMg
c2VjcmV0cyBhbmQgYXJlIGFsd2F5cyBleHBlY3RlZCB0byBiZSB0cmVhdGVkIGFzIHNlY3JldHMu
DQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJhbmRvbSBoZWFkZXIgbmFtZSBp
cyBlZmZlY3RpdmVseSBhbiBpbmZpbml0ZS1saWZldGltZSwgc3RhdGljYWxseSBkZWZpbmVkIGJl
YXJlciB0b2tlbiBwcmVzZW50ZWQgaW4gYSB3YXkgdGhhdCBkb2VzIG5vdCBhdCBhbGwgbWFrZSBj
bGVhciBhbmQgb2J2aW91cyB0aGF0IGl0IGlzIGEgc2VjcmV0IHRoYXQgbXVzdCBiZSBwcm90ZWN0
ZWQsIGFuZCBpbiBmYWN0IG1ha2VzIGl0IG1vcmUgbGlrZWx5IHRoYXQNCiBpdCB3aWxsIGJlIHJl
dmVhbGVkLCByZW5kZXJpbmcgaXQgdXNlbGVzcy4gQW5kIGxpa2UgYWxsIGJlYXJlciB0b2tlbnMs
IGV2ZW4gdW5kZXIgaWRlYWwgY29uZGl0aW9ucyBpdCBieSBkZWZpbml0aW9uIENBTk5PVCBCRSBV
U0VEIFRPIEFVVEhFTlRJQ0FURSBUSEUgU0VOREVSLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGVyZSBpcyBhIGNlcnRhaW4gYW1vdW50IG9mIGlyb255IGluIHRoZSBpZGVhIG9mIHRoZSBzZWN1
cml0eSBvZiBhIE11dHVhbCBUTFMgZGVwbG95bWVudCB1bHRpbWF0ZWx5IGNvbWluZyBkb3duIHRv
IGEgYmVhcmVyLXRva2VuIGhlYWRlciBuYW1lIHBhc3NlZCBiZXR3ZWVuIHRoZSByZXZlcnNlIHBy
b3h5IGFuZCB0aGUgcHJvdGVjdGVkIHNlcnZpY2UuDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTE0Ozwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jmd0OyBpZiB5b3UgZm9yZ2V0IHRvIHZhbGlkYXRlIHRoZSBzaWduYXR1
cmUgKm5vdGhpbmcgZmFpbHMqPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlcGxhY2UgdGhlIEhN
QUMgd2l0aCBlbmNyeXB0aW9uIGFuZCB5b3Ugc29sdmUgdGhhdCBwcm9ibGVtLCBhcyBpdCBmb3Jj
ZXMgdGhlIHNlcnZpY2UgdG8gZGVjcnlwdCB0aGUgdmFsdWUgdXNpbmcgdGhlIGNvcnJlY3Qga2V5
IGluIG9yZGVyIHRvIGFjY2VzcyB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGRhdGEuIFdoZXRoZXIg
b3Igbm90IHRoYXTigJlzIHdvcnRoIGRvaW5nIGlzIHNvbWV0aGluZyB3ZSBjYW4gZGViYXRlDQog
aW4gdGhlIGNvbnRleHQgb2YgYW4gYWN0dWFsIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G
cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr
Ij5OZWlsIE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDs8YnI+DQo8Yj5E
YXRlOiA8L2I+VGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTkgYXQgMToxNyBQTTxicj4NCjxiPlRv
OiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5h
QGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90
OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVE
IFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gY2xpZW50IGNlcnRzIGFuZCBUTFMgVGVybWluYXRpbmcg
UmV2ZXJzZSBQcm94aWVzICh3YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtand0
LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDgudHh0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMzEgT2N0IDIwMTksIGF0IDE4
OjU1LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9NDBhbWF6b24uY29t
QGRtYXJjLmlldGYub3JnJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbHlpbmcgb24gYSBm
aXhlZCwgcmFuZG9tIGhlYWRlciBuYW1lIGZvciBzZWN1cml0eSwgZXZlbiBhcyBhIOKAnGRlZmVu
c2UgaW4gZGVwdGjigJ0gbWVhc3VyZSwgaXMgZGFuZ2Vyb3VzLiBJbiBvcmRlciBmb3IgdGhpcyBt
ZWNoYW5pc20gdG8gYmUgZWZmZWN0aXZlLCB0aGUgaGVhZGVyIG5hbWUgbXVzdCBiZSByYW5kb20g
KGluIHRoZSBjcnlwdG9ncmFwaGljIHNlbnNlKSBhbmQgbXVzdCBiZSBrZXB0IHNlY3JldC4gSXQN
CiBuZWVkcyB0byBiZSB3aXRoaGVsZCBmcm9tIHJlcXVlc3QgbG9ncyBvciBlcnJvciBsb2dzLCBl
aXRoZXIgb24gdGhlIHJldmVyc2UgcHJveHkgb3Igb24gdGhlIHNlcnZpY2UuIEl0IGNhbm5vdCBi
ZSBjb21taXR0ZWQgdG8gY29kZSByZXBvc2l0b3JpZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBsaWtl
IGFueSBvdGhlciBiZWFyZXIgdG9rZW4uLiBJIG1lYW4gdGhpcyBpcyB0aGUgKk9BdXRoKiBXRywg
cmlnaHQ/IFdoZXJlIHdlIHJlZ3VsYXJseSByZWNvbW1lbmQgcGVvcGxlIHNlbmQgYmVhcmVyIHRv
a2VucyBpbiBoZWFkZXJzPyBJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgaG93IHRoYXQgY2Fu
IGJlIGNvbnNpZGVyZWQgc2VjdXJlIHRvIHNlbmQgb3ZlciB0aGUgaW50ZXJuZXQgdG8gYSBjbG91
ZA0KIHNlcnZpY2UsIGJ1dCBzdWRkZW5seSBiZWNvbWVzIGluc2VjdXJlIHdoZW4gZG9uZSBpbnNp
ZGUgdGhlIGZpcmV3YWxsIHdpdGhpbiBhIGRhdGFjZW50ZXIgYmV0d2VlbiBhIHJldmVyc2UgcHJv
eHkgYW5kIGFuIGFwcCBzZXJ2ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbWVhbiwgYXJlIHBlb3BsZSBob25lc3RseSBzdWdn
ZXN0aW5nIHRoYXQgcmFuZG9taXppbmcgaGVhZGVyIG5hbWVzIGludHJvZHVjZXMgKm5ldyogdnVs
bmVyYWJpbGl0aWVzIHRoYXQgYXJlbuKAmXQgcHJlc2VudCB3aGVuIHlvdSB1c2UgYSB3ZWxsLWtu
b3duIG5hbWU/IOKAnERhbmdlcm91c+KAnSBldmVuISZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluY2x1ZGluZyBpdCBhcyBhIHNpZ25lZCBoZWFk
ZXIgaW4gcmVxdWVzdCBzaWduaW5nIGFsZ29yaXRobXMgdGhhdCByZXF1aXJlIGFuIGV4cGxpY2l0
IGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMgKHN1Y2ggYXMNCjxhIGhyZWY9Imh0dHBzOi8vZG9jcy5h
d3MuYW1hem9uLmNvbS9nZW5lcmFsL2xhdGVzdC9nci9zaWduYXR1cmUtdmVyc2lvbi00Lmh0bWwi
Pg0KQVdTIFNpZ25hdHVyZSBWZXJzaW9uIDQ8L2E+LCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlcy0xMiI+DQpkcmFmdC1jYXZh
Z2UtaHR0cC1zaWduYXR1cmVzPC9hPiwgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb2F1dGgtc2lnbmVkLWh0dHAtcmVxdWVzdCI+DQpkcmFmdC1pZXRmLW9h
dXRoLXNpZ25lZC1odHRwLXJlcXVlc3Q8L2E+KSB0dXJucyB0aGF0IHNpZ25hdHVyZSBtZXRhZGF0
YSBpbnRvIGEgc2VjcmV0LCBtZWFuaW5nIHRoYXQNCjxpPml0PC9pPiBjYW5ub3QgYmUgbG9nZ2Vk
LCBldGMuIElmIHNpZ25hdHVyZXMgYXJlIHNlbnQgdG8gYSBjZW50cmFsIGF1dGhvcml0eSBmb3Ig
cHJvY2Vzc2luZywgdGhhdCBhdXRob3JpdHkgbXVzdCBhbHNvIGtub3cgbm90IHRvIGxvZyB0aGUg
bGlzdCBvZiBzaWduZWQgaGVhZGVycy4gSSBjb3VsZCBnbyBvbiwgYnV0IEkgaG9wZSB0aGlzIGlz
IGVub3VnaCB0byBleHByZXNzIHRoYXQgdGhlcmUgYXJlIFNPIE1BTlkgd2F5cyB0aGF0IGhlYWRl
ciBuYW1lcw0KIGNhbiBhbmQgd2lsbCBiZSByZXZlYWxlZCwgYW5kIHRoZXkgYXJlbuKAmXQgYWx3
YXlzIG9idmlvdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+V2hhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCBpcyBhIG1lc3NhZ2UgYXV0aGVu
dGljaXR5IHByb2JsZW0uIFRoZSBiZXN0IHByYWN0aWNlcyBmb3IgcHJvdmlkaW5nIG1lc3NhZ2Ug
YXV0aGVudGljaXR5IGludm9sdmUgYXBwbGllZCBjcnlwdG8sIGUuZy4sIGFuIEhNQUMgb3IgZGln
aXRhbCBzaWduYXR1cmUgb3ZlciB0aGUgaGVhZGVyIGNvbnRlbnRzLiBJZiBhbiBpbXBsZW1lbnRh
dGlvbiBkb2VzIHRoYXQsIHRoZW4NCiB0aGUgcmFuZG9tIGhlYWRlciBuYW1lIGlzIHVubmVjZXNz
YXJ5LiBUaGlzIGFwcHJvYWNoIGlzIGltbXVuZSB0byB0aGUgc29ydCBvZiBtaXNjb25maWd1cmF0
aW9uIHNjZW5hcmlvcyB0aGF0IGhhdmUgYmVlbiBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGFz
IHRoZXkgd291bGQgcmVzdWx0IGluIHRoZSByZXZlcnNlIHByb3h5IGZhaWxpbmcgdG8gcHJvdmlk
ZSBhIHByb3Blcmx5IHNpZ25lZCBoZWFkZXIgdG8gdGhlIHNlcnZpY2UuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
YWdyZWUgdGhhdCBITUFDIHNpZ25hdHVyZXMgYXJlIGdlbmVyYWxseSBiZXR0ZXIsIGJ1dCB3aGlj
aCByZXZlcnNlIHByb3hpZXMgc3VwcG9ydCBzaWduaW5nIGhlYWRlcnM/PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5IEhNQUMgc2ln
bmF0dXJlcyBkbyBoYXZlIG9uZSBzaWduaWZpY2FudCBkb3duc2lkZSBjb21wYXJlZCB0byB1c2lu
ZyBhIHJhbmRvbSBoZWFkZXIgbmFtZSAtIGlmIHlvdSBmb3JnZXQgdG8gdmFsaWRhdGUgdGhlIHNp
Z25hdHVyZSAqbm90aGluZyBmYWlscyouIElmIHlvdSBtZXNzIHVwIHRoZSBuYW1lIG9mIGEgcmFu
ZG9tIGhlYWRlciB0aGVuIHlvdXIgYXBwIGRvZXNu4oCZdCBzZWUgYW55IGNyZWRlbnRpYWxzDQog
YW5kIGZhaWxzIG5vaXNpbHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBOZWlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CF72E390C79D4CA98DEE546B992F91B6amazoncom_--


From nobody Thu Oct 31 14:34:34 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FD4120052 for ; Thu, 31 Oct 2019 14:34:32 -0700 (PDT)
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 t1maMLuEMQxf for ; Thu, 31 Oct 2019 14:34:28 -0700 (PDT)
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 B855F1200FF for ; Thu, 31 Oct 2019 14:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1572557669; x=1604093669; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ND/YWYT1pgULiBPsopNKGpnD1C9Ul5hOuZL7kSFcDms=; b=ubZv8OSuwzN58gF4QTaYktAqPmHWj6VaI+zBPztWF6ZNu05Pb5AlyiAb jJBevbbE7VwmiRhY3Nva0Gkx/aNJxpH88s7DZRPxA/uBf9ZXzKWkVb7g8 7Y+QGJtqdtuMrLOxz2jcaeJnFna3CfixlAtS4Y+b/O1A+2oV7IIiA829k k=;
IronPort-SDR: 8+U90gmOKMKJHdxeW5x/7tKd5LGZbwg6lyE87/J9h7wit1iP/qtUDjX/JAYQmobLKYqIo3D5GI AnRDd8ilNkKw==
X-IronPort-AV: E=Sophos;i="5.68,253,1569283200"; d="scan'208,217";a="2469996"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 31 Oct 2019 21:34:22 +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-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS id 5E8D9A219D; Thu, 31 Oct 2019 21:34:21 +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, 31 Oct 2019 21:34:20 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 31 Oct 2019 21:34:20 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 31 Oct 2019 21:34:20 +0000
From: "Richard Backman, Annabelle" 
To: Vladimir Dzhuvinov , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
Thread-Index: AQHVi20khjnyTeh9jkqsJQFVhb6GPqdteSoAgAKKHACAACgOAIAAB6CAgAAQz4CAAb9SAIAALTaAgAJnDoCAAANWAIAACmUAgAAIPgCAAJTvgP//l3QA
Date: Thu, 31 Oct 2019 21:34:20 +0000
Message-ID: 
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu>        <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu>    <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>  <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com>
In-Reply-To: <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1b.0.190715
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.5]
Content-Type: multipart/alternative; boundary="_000_D5621F8B53754BD0B83D7C2D17BC8D53amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 21:34:32 -0000

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

SSB0aGluayB0aGUgSE1BQy9zaWduYXR1cmUgYXBwcm9hY2ggaXMgYWN0dWFsbHkgZWFzaWVyIGZv
ciBjbG91ZCB2ZW5kb3JzIHRvIGltcGxlbWVudC4gVGhlIHRocmVhdCBtb2RlbCBpcyBtdWNoIHNp
bXBsZXIgdG8gdW5kZXJzdGFuZCwgYW5kIHJpc2sgbWl0aWdhdGlvbiBtb3N0bHkgYm9pbHMgZG93
biB0byB3ZWxsLXVuZGVyc3Rvb2QgY3J5cHRvZ3JhcGhpYyBoeWdpZW5lIHBhdHRlcm5zLiBBbmQg
YWdhaW4sIGl04oCZcyBvYnZpb3VzIHdoYXQgdmFsdWVzIGFyZSBzZWNyZXRzIGFuZCB3aGF0IHZh
bHVlcyBhcmVu4oCZdC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRl
bnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm
IG9mIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQpPcmdhbml6
YXRpb246IENvbm5lY3QyaWQgTHRkLg0KRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTkg
YXQgMTo1MCBQTQ0KVG86ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVj
dDogUmU6IFtPQVVUSC1XR10gY2xpZW50IGNlcnRzIGFuZCBUTFMgVGVybWluYXRpbmcgUmV2ZXJz
ZSBQcm94aWVzICh3YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJv
c3BlY3Rpb24tcmVzcG9uc2UtMDgudHh0KQ0KDQoNCkkgYWdyZWUgd2hvbGVoZWFydGVkbHkgdGhh
dCBhbiBITUFDIG9yIGV2ZW4gc2lnbmF0dXJlIGlzIHByZWZlcmFibGUuIFdpdGggSE1BQyB2cyBz
aWduYXR1cmUgaGF2aW5nIHRoZWlyIHJlbGF0aXZlIHByb3MgLyBjb25zLCBpbiB0ZXJtcyBvZiBj
b21wdXRhdGlvbiBhbmQga2V5IGRpc3RyaWJ1dGlvbi4gSWYgYSBzdGFuZGFyZCBmb3IgdGhhdCBp
cyBjcmVhdGVkLCBhbmQgSSBhbSBhIHdlYiBhcHBsaWNhdGlvbiBkZXZlbG9wZXIsIEknbGwgYmUg
YWJsZSB0byBoYW5kbGUgdGhlIGhlYWRlciBjaGVja3MgaW4gdGhlIGFwcGxpY2F0aW9uIGxheWVy
IGNvZGUgcmVsYXRpdmVseSBlYXNpbHkuIEJ1dCBJIGhhdmUgbXVjaCBsZXNzIGNvbnRyb2wgb3Zl
ciBob3cgLyB3aGVyZSB0aGUgYXBwbGljYXRpb24gaXMgZ29pbmcgdG8gYmUgZGVwbG95ZWQsIGFu
ZCBpZiB0aGUgcmV2ZXJzZSBwcm94eSBoYXMgdGhpcyBoZWFkZXIgc2VjdXJpdHkgaW1wbGVtZW50
ZWQuIFNvZnR3YXJlIGFuZCBjbG91ZCB2ZW5kb3JzIGNhbiBzb21ldGltZXMgYmUgc2lnbmlmaWNh
bnRseSBiZWhpbmQgaW4gc3VjaCBkZXZlbG9wbWVudHMuIEV2ZW4gYmFzaWMgaGFuZGxpbmcgb2Yg
c2VsZi1zaWduZWQgY2xpZW50IGNlcnRpZmljYXRlcyBoYXMgYmVlbiBhbiBpc3N1ZSBmb3IgdXMg
aW4gcG9wdWxhciBjbG91ZCBlbnZpcm9ubWVudHMuDQoNCldpdGggdGhhdCBpbiBtaW5kLCB0aGUg
InNlY3JldCIgaGVhZGVycyBjYW4gYmUgY29uZmlndXJlZCB3aXRoIG1vc3QgY3VycmVudGx5IGF2
YWlsYWJsZSByZXZlcnNlIHByb3h5IHNvZnR3YXJlLiBJIHNlZSBpdCBhcyBhIHVzZWZ1bCBpbnRl
cm1lZGlhdGUgc3RlcCwgdW50aWwgYSBzdGFuZGFyZCBmb3IgYXV0aGVudGljYXRlZCBoZWFkZXJz
IGdldHMgYWdyZWVkIG9uIGFuZCBldmVudHVhbGx5IGltcGxlbWVudGVkIGluIHJldmVyc2UgcHJv
eGllcy4gQ2FuIHlvdSBjb21tZW50IG9uIHRoYXQgZnJvbSB0aGlzIHBlcnNwZWN0aXZlPw0KDQpP
dmVyIHRoZSB5ZWFycyBJIGhhdmUgY29tZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHN0YW5kYXJk
cyB3aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gdGhlIGFwcGxpY2F0aW9uIGxheWVyIG9yIGFz
IGEgc2ltcGxlIGNvbmZpZyBzdGFuZCBhIGJldHRlciBjaGFuY2UuIFN0YW5kYXJkcyB3aGljaCBy
ZWx5IG9uIG90aGVyIGxheWVycyBvciBvbiBicm9hZCB2ZW5kb3Igb3IgZGV2ZWxvcGVyIHN1cHBv
cnQgdG8gYmVjb21lIHVzZWZ1bCBydW4gdGhlIHJpc2sgb2Ygbm90IGdldHRpbmcgYWRvcHRlZCBp
biBwcmFjdGljZS4gVG9rZW4gYmluZGluZyBzdWZmZXJlZCBmcm9tIHRoYXQuDQoNClZsYWRpbWly
DQpPbiAzMS8xMC8yMDE5IDIwOjU1LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZToN
ClJlbHlpbmcgb24gYSBmaXhlZCwgcmFuZG9tIGhlYWRlciBuYW1lIGZvciBzZWN1cml0eSwgZXZl
biBhcyBhIOKAnGRlZmVuc2UgaW4gZGVwdGjigJ0gbWVhc3VyZSwgaXMgZGFuZ2Vyb3VzLiBJbiBv
cmRlciBmb3IgdGhpcyBtZWNoYW5pc20gdG8gYmUgZWZmZWN0aXZlLCB0aGUgaGVhZGVyIG5hbWUg
bXVzdCBiZSByYW5kb20gKGluIHRoZSBjcnlwdG9ncmFwaGljIHNlbnNlKSBhbmQgbXVzdCBiZSBr
ZXB0IHNlY3JldC4gSXQgbmVlZHMgdG8gYmUgd2l0aGhlbGQgZnJvbSByZXF1ZXN0IGxvZ3Mgb3Ig
ZXJyb3IgbG9ncywgZWl0aGVyIG9uIHRoZSByZXZlcnNlIHByb3h5IG9yIG9uIHRoZSBzZXJ2aWNl
LiBJdCBjYW5ub3QgYmUgY29tbWl0dGVkIHRvIGNvZGUgcmVwb3NpdG9yaWVzLiBJbmNsdWRpbmcg
aXQgYXMgYSBzaWduZWQgaGVhZGVyIGluIHJlcXVlc3Qgc2lnbmluZyBhbGdvcml0aG1zIHRoYXQg
cmVxdWlyZSBhbiBleHBsaWNpdCBsaXN0IG9mIHNpZ25lZCBoZWFkZXJzIChzdWNoIGFzIEFXUyBT
aWduYXR1cmUgVmVyc2lvbiA0PGh0dHBzOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9nZW5lcmFsL2xh
dGVzdC9nci9zaWduYXR1cmUtdmVyc2lvbi00Lmh0bWw+LCBkcmFmdC1jYXZhZ2UtaHR0cC1zaWdu
YXR1cmVzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXZhZ2UtaHR0cC1zaWdu
YXR1cmVzLTEyPiwgZHJhZnQtaWV0Zi1vYXV0aC1zaWduZWQtaHR0cC1yZXF1ZXN0PGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3Q+
KSB0dXJucyB0aGF0IHNpZ25hdHVyZSBtZXRhZGF0YSBpbnRvIGEgc2VjcmV0LCBtZWFuaW5nIHRo
YXQgaXQgY2Fubm90IGJlIGxvZ2dlZCwgZXRjLiBJZiBzaWduYXR1cmVzIGFyZSBzZW50IHRvIGEg
Y2VudHJhbCBhdXRob3JpdHkgZm9yIHByb2Nlc3NpbmcsIHRoYXQgYXV0aG9yaXR5IG11c3QgYWxz
byBrbm93IG5vdCB0byBsb2cgdGhlIGxpc3Qgb2Ygc2lnbmVkIGhlYWRlcnMuIEkgY291bGQgZ28g
b24sIGJ1dCBJIGhvcGUgdGhpcyBpcyBlbm91Z2ggdG8gZXhwcmVzcyB0aGF0IHRoZXJlIGFyZSBT
TyBNQU5ZIHdheXMgdGhhdCBoZWFkZXIgbmFtZXMgY2FuIGFuZCB3aWxsIGJlIHJldmVhbGVkLCBh
bmQgdGhleSBhcmVu4oCZdCBhbHdheXMgb2J2aW91cy4NCg0KV2hhdCB3ZSBhcmUgdGFsa2luZyBh
Ym91dCBpcyBhIG1lc3NhZ2UgYXV0aGVudGljaXR5IHByb2JsZW0uIFRoZSBiZXN0IHByYWN0aWNl
cyBmb3IgcHJvdmlkaW5nIG1lc3NhZ2UgYXV0aGVudGljaXR5IGludm9sdmUgYXBwbGllZCBjcnlw
dG8sIGUuZy4sIGFuIEhNQUMgb3IgZGlnaXRhbCBzaWduYXR1cmUgb3ZlciB0aGUgaGVhZGVyIGNv
bnRlbnRzLiBJZiBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzIHRoYXQsIHRoZW4gdGhlIHJhbmRvbSBo
ZWFkZXIgbmFtZSBpcyB1bm5lY2Vzc2FyeS4gVGhpcyBhcHByb2FjaCBpcyBpbW11bmUgdG8gdGhl
IHNvcnQgb2YgbWlzY29uZmlndXJhdGlvbiBzY2VuYXJpb3MgdGhhdCBoYXZlIGJlZW4gZGlzY3Vz
c2VkIGluIHRoaXMgdGhyZWFkLCBhcyB0aGV5IHdvdWxkIHJlc3VsdCBpbiB0aGUgcmV2ZXJzZSBw
cm94eSBmYWlsaW5nIHRvIHByb3ZpZGUgYSBwcm9wZXJseSBzaWduZWQgaGVhZGVyIHRvIHRoZSBz
ZXJ2aWNlLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K
DQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91
bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJA
Y29ubmVjdDJpZC5jb20+PG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4NCk9yZ2FuaXph
dGlvbjogQ29ubmVjdDJpZCBMdGQuDQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciAzMSwgMjAxOSBh
dCA0OjI3IEFNDQpUbzogIm9hdXRoQGlldGYub3JnIjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxv
YXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU
SC1XR10gY2xpZW50IGNlcnRzIGFuZCBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94aWVzICh3
YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVz
cG9uc2UtMDgudHh0KQ0KDQoNClRoaXMgaXMgYSBnb29kIHN0b3J5Lg0KDQpIb3cgYWJvdXQgcmVx
dWlyaW5nIHJldmVyc2UgcHJveGllcyB0byBhdXRvbWF0aWNhbGx5IHNjcnViIGFsbCBpbmJvdW5k
IEhUVFAgaGVhZGVycyB0aGF0IHN0YXJ0IHdpdGggIlNlYy0iPw0KDQpJZiBhIHNlYyBoZWFkZXIg
aGFzIHRoZSBmb3JtYXQgIlNlYy1bTkFNRV0tW3JhbmRvbS1jaGFyc10iIHdlIGdldDoNCg0KKiBU
aGUgIlNlYy0iIHByZWZpeCB3aWxsICBjYXVzZSBuZXcgY29tcGxpYW50IHJlc2VydmUgcHJveGll
cyB0byBhdXRvbWF0aWNhbGx5IHNjcnViIHRoZSBpbmJvdW5kIEhUVFAgaGVhZGVyLg0KDQoqIFRo
ZSBOQU1FIHBhcnQgc3RpbGwgbWFrZXMgdGhlIGhlYWRlciBlYXNpbHkgaWRlbnRpZmlhYmxlIChJ
IHRoaW5rIFJpY2ggU2FseiBoYWQgdGhpcyBjb25jZXJuKS4NCg0KKiBUaGUgcmFuZG9tIGNoYXJz
IHBhcnQsIHBvdGVudGlhbGx5IG9wdGlvbmFsLCB3aWxsIHByb3ZpZGUgYSBsaW5lIG9mIGRlZmVu
Y2UgYWdhaW5zdCBjb25maWcgZXJyb3JzIGluIG9sZCBsZWdhY3kgcmV2ZXJzZSBwcm94aWVzLg0K
DQpBbGwgY29uY2VybnMgc2hvdWxkIHRoZW4gZ2V0IGNvdmVyZWQuDQoNClZsYWRpbWlyDQpPbiAz
MS8xMC8yMDE5IDEyOjQ4LCBIYW5zIFphbmRiZWx0IHdyb3RlOg0KdGhlIHdheSBJIHNlZSB0aGlz
IGlzIHRoYXQgc3RyaXBwaW5nIGFuZCBzZXR0aW5nIHRoZSBoZWFkZXJzIG11c3QgYmUgcGFydCBv
ZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIHByb3RvY29sIGl0c2VsZiwgaXQgc2hvdWxkIG5v
dCBiZSBzb21ldGhpbmcgbGVmdCB0byBhIG5vbi1hdG9taWMgcGllY2Ugb2YgY29uZmlndXJhdGlv
biBieSBhbiBhZG1pbmlzdHJhdG9yOyBJIGltcGxlbWVudGVkIGl0IGxpa2UgdGhpcyBpbiB0aGUg
QXBhY2hlIGltcGxlbWVudGF0aW9uIG9mIEJyaWFuJ3MgVFRSUCBzcGVjIFsxXSBhbmQgaGF2ZSBi
ZWVuIGRvaW5nIHRoaXMgZm9yIHRoZSBPSURDIGFuZCBPQXV0aCBBcGFjaGUgbW9kdWxlcyB0aGF0
IHNldCBoZWFkZXJzIGZvciBiYWNrZW5kcyB0byBjb25zdW1lIFsyXTsgYW5kIHllcywgSSBoYXZl
IG1hZGUgbWlzdGFrZXMgWzNdLCBidXQgSU1ITyBpdCBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSB0
byB1c2UgYSB3ZWxsIGtub3duIGhlYWRlciBhbmQgbWFrZSB0aGUgaW1wbGVtZW50ZXIgKG5vdCB0
aGUgYWRtaW4pIGdldCBpdCByaWdodCBieSBwb2ludGluZyB0aGlzIG91dCBpbiB0aGUgc3BlYywg
YXMgaXMgZG9uZSBmb3IgbWFueSBvdGhlciBwaXRmYWxscw0KDQpIYW5zLg0KDQpbMV0gaHR0cHM6
Ly9naXRodWIuY29tL3ptYXJ0em9uZS9tb2RfdG9rZW5fYmluZGluZy9ibG9iL21hc3Rlci9zcmMv
bW9kX3Rva2VuX2JpbmRpbmcuYyNMNDgxLUw0ODMNClsyXSBodHRwczovL2dpdGh1Yi5jb20vem1h
cnR6b25lL21vZF9hdXRoX29wZW5pZGMvYmxvYi9tYXN0ZXIvc3JjL21vZF9hdXRoX29wZW5pZGMu
YyNMMTY0LUwxNzUNClszXSBodHRwczovL3d3dy5jdmVkZXRhaWxzLmNvbS9jdmUvQ1ZFLTIwMTct
NjQxMy8NCg0KT24gVGh1LCBPY3QgMzEsIDIwMTkgYXQgMTE6MzcgQU0gVmxhZGltaXIgRHpodXZp
bm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5j
b20+PiB3cm90ZToNCkFsbCBpbiBhbGwsIEkgYW0gaW4gZmF2b3Igb2YgdGhpcyBiZWluZyBkZWZp
bmVkIGluIG9uZSBzdGFuZGFyZCB3YXksIGluIGFkZGl0aW9uIHRvIHNlY3VyZSBjb21tdW5pY2F0
aW9uIGJldHdlZW4gcHJveGllcyBhbmQgYmFja2VuZHMgYmVpbmcgc3RhbmRhcmRpemVkIOKAlCBi
dXQgdGhpcyBsYXR0ZXIgYml0IHJlYWxseSBzZWVtcyBsaWtlIGEgc2VwYXJhdGUgcHJvYmxlbS4N
Cg0KIOKAlCBKdXN0aW4NCg0KLTEgZm9yIGRldmlzaW5nIGEgd2VsbCBrbm93biBoZWFkZXINCg0K
KzEgZm9yIGEgc2ltcGxlIHdheSB0byBhdXRoZW50aWNhdGUgYSByZXZlcnNlIHByb3h5IHdpdGgg
YSB3ZWIgc2VydmVyDQoNCldpdGggYSB3ZWxsIGtub3duIG5hbWUsIGluIGEgYXR0YWNrIHRoaXMg
d2lsbCBnZXQgcHJvYmVkIGZpcnN0LiBUaGUgd2VsbCBrbm93biBoZWFkZXIgbmFtZSBkb2Vzbid0
IGd1YXJhbnRlZSBhIGNvcnJlY3QgY29uZmlnLiBBbmQgaWYgd2UgaGF2ZSBhIG5ldyBzdGFuZGFy
ZCBmb3Igc2VjIGhlYWRlcnMgdGhhdCBtdXN0IGJlIHN0cmlwcGVkIGF1dG9tYXRpY2FsbHkgZnJv
bSBpbmJvdW5kIEhUVFAgcmVxdWVzdHMsIHdlIGNhbm5vdCBleHBlY3QgdGhhdCB3aWxsIGdldCBp
bXBsZW1lbnRlZCBpbiBhbGwgcmV2ZXJzZSBwcm94eSBzb2Z0d2FyZSBvdmVybmlnaHQuDQoNCkJl
Y2F1c2UgYSBjb3JyZWN0IGNvbmZpZyBpcyBub3QgcHJhY3RpY2FsIGFzIHRoZSBvbmx5IGxpbmUg
b2YgZGVmZW5zZSwgd2hlbiB3ZSBpbXBsZW1lbnRlZCBtVExTIHdlIGRlY2lkZWQgdG8gYWRkIGEg
bGVuZ3RoICg+PSAzMiBjaGFycykgYW5kIHJhbmRvbW5lc3MgY2hlY2sgdG8gdGhlIGhlYWRlciBj
b25maWcuIEkgc2F3IHNvbWUgY29uY2VybnMgdGhhdCB0aGlzIG1heSBjYXVzZSBkZXBsb3ltZW50
IGlzc3Vlcy4gTm9ib2R5IGhhcyBjb21wbGFpbmVkIGFib3V0IHRoYXQgc28gZmFyLg0KDQpodHRw
czovL2Nvbm5lY3QyaWQuY29tL3Byb2R1Y3RzL3NlcnZlci9kb2NzL2NvbmZpZy9jb3JlI29wLXRs
cy1jbGllbnRYNTA5Q2VydEhlYWRlcg0KDQpSZWdhcmRpbmcgbWlzdHlwaW5nLCB0aGlzIGNhbiBi
ZSBhbiBpc3N1ZSwgYnV0IGhhcyBsaXR0bGUgdG8gbm8gZWZmZWN0IGlmIGEgbG9uZyByYW5kb20g
aGVhZGVyIGdldHMgbWlzc3R5cGVkIChmcm9tIHRoZSBpbmJvdW5kIHN0cmlwIGRpcmVjdGl2ZSku
IFdpdGggYSB3ZWxsIGtub3duIGhlYWRlciB0aGlzIHdpbGwgcmVzdWx0IGluIGEgaW1tZWRpYXRl
IHNlY3VyaXR5IGhvbGUsIHdoaWNoIGNhbiB0aGVvcmV0aWNhbGx5IGdvIHVubm90aWNlZC4NCg0K
SGVyZSBpcyBhbiBleGFtcGxlIEFwYWNoZSBodHRwZCBjb25maWcsIHRvIGlsbHVzdHJhdGUgbXkg
cG9pbnQ6DQoNClJlcXVlc3RIZWFkZXIgc2V0IFNlYy1DbGllbnQtWDUwOS1DZXJ0LWxpZWRlNXZh
ZVBlZU1pWWllMHh1MmphdWRhdWxlaW5nICIiDQoNClJlcXVlc3RIZWFkZXIgc2V0IFNlYy1DbGll
bnQtWDUwOS1DZXJ0LWxpZWRlNXZhZVBlZU1pWWllMHh1MmphdWRhdWxlaW5nICIle1NTTF9DTElF
TlRfQ0VSVH1zIg0KDQoodGhlIGZpcnN0IGxpbmUgc3RyaXBzIHRoZSBpbmJvdW5kIGhlYWRlcnMp
DQoNCg0KDQpWbGFkaW1pcg0KDQotLQ0KDQpWbGFkaW1pciBEemh1dmlub3YNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN
Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpv
bmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAt
IHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+DQoNCi0tDQoNClZsYWRp
bWlyIER6aHV2aW5vdg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aA0K

--_000_D5621F8B53754BD0B83D7C2D17BC8D53amazoncom_
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
IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvOw0KCXBhbm9zZS0x
OjIgMTEgNiA5IDMgOCA0IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v
cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFs
MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y
bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgSE1BQy9z
aWduYXR1cmUgYXBwcm9hY2ggaXMgYWN0dWFsbHkgZWFzaWVyIGZvciBjbG91ZCB2ZW5kb3JzIHRv
IGltcGxlbWVudC4gVGhlIHRocmVhdCBtb2RlbCBpcyBtdWNoIHNpbXBsZXIgdG8gdW5kZXJzdGFu
ZCwgYW5kIHJpc2sgbWl0aWdhdGlvbiBtb3N0bHkgYm9pbHMgZG93biB0byB3ZWxsLXVuZGVyc3Rv
b2QgY3J5cHRvZ3JhcGhpYyBoeWdpZW5lIHBhdHRlcm5zLiBBbmQgYWdhaW4sIGl04oCZcw0KIG9i
dmlvdXMgd2hhdCB2YWx1ZXMgYXJlIHNlY3JldHMgYW5kIHdoYXQgdmFsdWVzIGFyZW7igJl0Ljxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsg
b24gYmVoYWxmIG9mIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7dmxhZGltaXJAY29ubmVjdDJpZC5j
b20mZ3Q7PGJyPg0KPGI+T3JnYW5pemF0aW9uOiA8L2I+Q29ubmVjdDJpZCBMdGQuPGJyPg0KPGI+
RGF0ZTogPC9iPlRodXJzZGF5LCBPY3RvYmVyIDMxLCAyMDE5IGF0IDE6NTAgUE08YnI+DQo8Yj5U
bzogPC9iPiZxdW90O29hdXRoQGlldGYub3JnJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gY2xpZW50IGNlcnRzIGFuZCBUTFMg
VGVybWluYXRpbmcgUmV2ZXJzZSBQcm94aWVzICh3YXMgUmU6IEktRCBBY3Rpb246IGRyYWZ0LWll
dGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDgudHh0KTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5JIGFncmVlIHdob2xlaGVhcnRlZGx5IHRoYXQgYW4gSE1B
QyBvciBldmVuIHNpZ25hdHVyZSBpcyBwcmVmZXJhYmxlLiBXaXRoIEhNQUMgdnMgc2lnbmF0dXJl
IGhhdmluZyB0aGVpciByZWxhdGl2ZSBwcm9zIC8gY29ucywgaW4gdGVybXMgb2YgY29tcHV0YXRp
b24gYW5kIGtleSBkaXN0cmlidXRpb24uIElmIGEgc3RhbmRhcmQgZm9yIHRoYXQgaXMgY3JlYXRl
ZCwgYW5kIEkgYW0gYSB3ZWIgYXBwbGljYXRpb24gZGV2ZWxvcGVyLCBJJ2xsIGJlDQogYWJsZSB0
byBoYW5kbGUgdGhlIGhlYWRlciBjaGVja3MgaW4gdGhlIGFwcGxpY2F0aW9uIGxheWVyIGNvZGUg
cmVsYXRpdmVseSBlYXNpbHkuIEJ1dCBJIGhhdmUgbXVjaCBsZXNzIGNvbnRyb2wgb3ZlciBob3cg
LyB3aGVyZSB0aGUgYXBwbGljYXRpb24gaXMgZ29pbmcgdG8gYmUgZGVwbG95ZWQsIGFuZCBpZiB0
aGUgcmV2ZXJzZSBwcm94eSBoYXMgdGhpcyBoZWFkZXIgc2VjdXJpdHkgaW1wbGVtZW50ZWQuIFNv
ZnR3YXJlIGFuZCBjbG91ZCB2ZW5kb3JzDQogY2FuIHNvbWV0aW1lcyBiZSBzaWduaWZpY2FudGx5
IGJlaGluZCBpbiBzdWNoIGRldmVsb3BtZW50cy4gRXZlbiBiYXNpYyBoYW5kbGluZyBvZiBzZWxm
LXNpZ25lZCBjbGllbnQgY2VydGlmaWNhdGVzIGhhcyBiZWVuIGFuIGlzc3VlIGZvciB1cyBpbiBw
b3B1bGFyIGNsb3VkIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwPldpdGggdGhhdCBp
biBtaW5kLCB0aGUgJnF1b3Q7c2VjcmV0JnF1b3Q7IGhlYWRlcnMgY2FuIGJlIGNvbmZpZ3VyZWQg
d2l0aCBtb3N0IGN1cnJlbnRseSBhdmFpbGFibGUgcmV2ZXJzZSBwcm94eSBzb2Z0d2FyZS4gSSBz
ZWUgaXQgYXMgYSB1c2VmdWwgaW50ZXJtZWRpYXRlIHN0ZXAsIHVudGlsIGEgc3RhbmRhcmQgZm9y
IGF1dGhlbnRpY2F0ZWQgaGVhZGVycyBnZXRzIGFncmVlZCBvbiBhbmQgZXZlbnR1YWxseSBpbXBs
ZW1lbnRlZCBpbiByZXZlcnNlIHByb3hpZXMuDQogQ2FuIHlvdSBjb21tZW50IG9uIHRoYXQgZnJv
bSB0aGlzIHBlcnNwZWN0aXZlPzxvOnA+PC9vOnA+PC9wPg0KPHA+T3ZlciB0aGUgeWVhcnMgSSBo
YXZlIGNvbWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBzdGFuZGFyZHMgd2hpY2ggY2FuIGJlIGlt
cGxlbWVudGVkIGluIHRoZSBhcHBsaWNhdGlvbiBsYXllciBvciBhcyBhIHNpbXBsZSBjb25maWcg
c3RhbmQgYSBiZXR0ZXIgY2hhbmNlLiBTdGFuZGFyZHMgd2hpY2ggcmVseSBvbiBvdGhlciBsYXll
cnMgb3Igb24gYnJvYWQgdmVuZG9yIG9yIGRldmVsb3BlciBzdXBwb3J0IHRvIGJlY29tZSB1c2Vm
dWwgcnVuIHRoZQ0KIHJpc2sgb2Ygbm90IGdldHRpbmcgYWRvcHRlZCBpbiBwcmFjdGljZS4gVG9r
ZW4gYmluZGluZyBzdWZmZXJlZCBmcm9tIHRoYXQuPG86cD48L286cD48L3A+DQo8cD5WbGFkaW1p
cjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMxLzEwLzIw
MTkgMjA6NTUsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbHlpbmcgb24gYSBmaXhlZCwgcmFu
ZG9tIGhlYWRlciBuYW1lIGZvciBzZWN1cml0eSwgZXZlbiBhcyBhIOKAnGRlZmVuc2UgaW4gZGVw
dGjigJ0gbWVhc3VyZSwgaXMgZGFuZ2Vyb3VzLiBJbiBvcmRlciBmb3IgdGhpcyBtZWNoYW5pc20g
dG8gYmUgZWZmZWN0aXZlLCB0aGUgaGVhZGVyIG5hbWUgbXVzdCBiZSByYW5kb20gKGluIHRoZSBj
cnlwdG9ncmFwaGljIHNlbnNlKSBhbmQgbXVzdCBiZSBrZXB0IHNlY3JldC4gSXQNCiBuZWVkcyB0
byBiZSB3aXRoaGVsZCBmcm9tIHJlcXVlc3QgbG9ncyBvciBlcnJvciBsb2dzLCBlaXRoZXIgb24g
dGhlIHJldmVyc2UgcHJveHkgb3Igb24gdGhlIHNlcnZpY2UuIEl0IGNhbm5vdCBiZSBjb21taXR0
ZWQgdG8gY29kZSByZXBvc2l0b3JpZXMuIEluY2x1ZGluZyBpdCBhcyBhIHNpZ25lZCBoZWFkZXIg
aW4gcmVxdWVzdCBzaWduaW5nIGFsZ29yaXRobXMgdGhhdCByZXF1aXJlIGFuIGV4cGxpY2l0IGxp
c3Qgb2Ygc2lnbmVkIGhlYWRlcnMNCiAoc3VjaCBhcyA8YSBocmVmPSJodHRwczovL2RvY3MuYXdz
LmFtYXpvbi5jb20vZ2VuZXJhbC9sYXRlc3QvZ3Ivc2lnbmF0dXJlLXZlcnNpb24tNC5odG1sIj4N
CkFXUyBTaWduYXR1cmUgVmVyc2lvbiA0PC9hPiwgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25hdHVyZXMtMTIiPg0KZHJhZnQtY2F2YWdl
LWh0dHAtc2lnbmF0dXJlczwvYT4sIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLW9hdXRoLXNpZ25lZC1odHRwLXJlcXVlc3QiPg0KZHJhZnQtaWV0Zi1vYXV0
aC1zaWduZWQtaHR0cC1yZXF1ZXN0PC9hPikgdHVybnMgdGhhdCBzaWduYXR1cmUgbWV0YWRhdGEg
aW50byBhIHNlY3JldCwgbWVhbmluZyB0aGF0DQo8aT5pdDwvaT4gY2Fubm90IGJlIGxvZ2dlZCwg
ZXRjLiBJZiBzaWduYXR1cmVzIGFyZSBzZW50IHRvIGEgY2VudHJhbCBhdXRob3JpdHkgZm9yIHBy
b2Nlc3NpbmcsIHRoYXQgYXV0aG9yaXR5IG11c3QgYWxzbyBrbm93IG5vdCB0byBsb2cgdGhlIGxp
c3Qgb2Ygc2lnbmVkIGhlYWRlcnMuIEkgY291bGQgZ28gb24sIGJ1dCBJIGhvcGUgdGhpcyBpcyBl
bm91Z2ggdG8gZXhwcmVzcyB0aGF0IHRoZXJlIGFyZSBTTyBNQU5ZIHdheXMgdGhhdCBoZWFkZXIg
bmFtZXMNCiBjYW4gYW5kIHdpbGwgYmUgcmV2ZWFsZWQsIGFuZCB0aGV5IGFyZW7igJl0IGFsd2F5
cyBvYnZpb3VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdlIGFyZSB0YWxraW5nIGFi
b3V0IGlzIGEgbWVzc2FnZSBhdXRoZW50aWNpdHkgcHJvYmxlbS4gVGhlIGJlc3QgcHJhY3RpY2Vz
IGZvciBwcm92aWRpbmcgbWVzc2FnZSBhdXRoZW50aWNpdHkgaW52b2x2ZSBhcHBsaWVkIGNyeXB0
bywgZS5nLiwgYW4gSE1BQyBvciBkaWdpdGFsIHNpZ25hdHVyZSBvdmVyIHRoZSBoZWFkZXIgY29u
dGVudHMuIElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgdGhhdCwgdGhlbg0KIHRoZSByYW5kb20g
aGVhZGVyIG5hbWUgaXMgdW5uZWNlc3NhcnkuIFRoaXMgYXBwcm9hY2ggaXMgaW1tdW5lIHRvIHRo
ZSBzb3J0IG9mIG1pc2NvbmZpZ3VyYXRpb24gc2NlbmFyaW9zIHRoYXQgaGF2ZSBiZWVuIGRpc2N1
c3NlZCBpbiB0aGlzIHRocmVhZCwgYXMgdGhleSB3b3VsZCByZXN1bHQgaW4gdGhlIHJldmVyc2Ug
cHJveHkgZmFpbGluZyB0byBwcm92aWRlIGEgcHJvcGVybHkgc2lnbmVkIGhlYWRlciB0byB0aGUg
c2VydmljZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIFJpY2hh
cmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGgNCjxhIGhyZWY9Im1haWx0bzpvYXV0
aC1ib3VuY2VzQGlldGYub3JnIj4mbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9u
IGJlaGFsZiBvZiBWbGFkaW1pciBEemh1dmlub3YNCjxhIGhyZWY9Im1haWx0bzp2bGFkaW1pckBj
b25uZWN0MmlkLmNvbSI+Jmx0O3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tJmd0OzwvYT48YnI+DQo8
Yj5Pcmdhbml6YXRpb246IDwvYj5Db25uZWN0MmlkIEx0ZC48YnI+DQo8Yj5EYXRlOiA8L2I+VGh1
cnNkYXksIE9jdG9iZXIgMzEsIDIwMTkgYXQgNDoyNyBBTTxicj4NCjxiPlRvOiA8L2I+PGEgaHJl
Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4mcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OzwvYT4g
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4NCiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
L2E+PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIGNsaWVudCBjZXJ0cyBhbmQg
VExTIFRlcm1pbmF0aW5nIFJldmVyc2UgUHJveGllcyAod2FzIFJlOiBJLUQgQWN0aW9uOiBkcmFm
dC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA4LnR4dCk8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+VGhpcyBpcyBhIGdvb2Qgc3RvcnkuPG86cD48L286
cD48L3A+DQo8cD5Ib3cgYWJvdXQgcmVxdWlyaW5nIHJldmVyc2UgcHJveGllcyB0byBhdXRvbWF0
aWNhbGx5IHNjcnViIGFsbCBpbmJvdW5kIEhUVFAgaGVhZGVycyB0aGF0IHN0YXJ0IHdpdGggJnF1
b3Q7U2VjLSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxwPklmIGEgc2VjIGhlYWRlciBoYXMgdGhl
IGZvcm1hdCAmcXVvdDtTZWMtW05BTUVdLVtyYW5kb20tY2hhcnNdJnF1b3Q7IHdlIGdldDo8bzpw
PjwvbzpwPjwvcD4NCjxwPiogVGhlICZxdW90O1NlYy0mcXVvdDsgcHJlZml4IHdpbGwmbmJzcDsg
Y2F1c2UgbmV3IGNvbXBsaWFudCByZXNlcnZlIHByb3hpZXMgdG8gYXV0b21hdGljYWxseSBzY3J1
YiB0aGUgaW5ib3VuZCBIVFRQIGhlYWRlci48bzpwPjwvbzpwPjwvcD4NCjxwPiogVGhlIE5BTUUg
cGFydCBzdGlsbCBtYWtlcyB0aGUgaGVhZGVyIGVhc2lseSBpZGVudGlmaWFibGUgKEkgdGhpbmsg
UmljaCBTYWx6IGhhZCB0aGlzIGNvbmNlcm4pLjxvOnA+PC9vOnA+PC9wPg0KPHA+KiBUaGUgcmFu
ZG9tIGNoYXJzIHBhcnQsIHBvdGVudGlhbGx5IG9wdGlvbmFsLCB3aWxsIHByb3ZpZGUgYSBsaW5l
IG9mIGRlZmVuY2UgYWdhaW5zdCBjb25maWcgZXJyb3JzIGluIG9sZCBsZWdhY3kgcmV2ZXJzZSBw
cm94aWVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWxsIGNvbmNlcm5zIHNob3VsZCB0aGVuIGdldCBj
b3ZlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+VmxhZGltaXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMS8xMC8yMDE5IDEyOjQ4LCBIYW5zIFphbmRiZWx0
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+dGhlIHdheSBJIHNlZSB0aGlzIGlzIHRoYXQgc3RyaXBwaW5nIGFuZCBzZXR0
aW5nIHRoZSBoZWFkZXJzIG11c3QgYmUgcGFydCBvZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhl
IHByb3RvY29sIGl0c2VsZiwgaXQgc2hvdWxkIG5vdCBiZSBzb21ldGhpbmcgbGVmdCB0byBhIG5v
bi1hdG9taWMgcGllY2Ugb2YgY29uZmlndXJhdGlvbiBieSBhbiBhZG1pbmlzdHJhdG9yOyBJIGlt
cGxlbWVudGVkIGl0IGxpa2UgdGhpcw0KIGluIHRoZSBBcGFjaGUgaW1wbGVtZW50YXRpb24gb2Yg
QnJpYW4ncyBUVFJQIHNwZWMgWzFdIGFuZCBoYXZlIGJlZW4gZG9pbmcgdGhpcyBmb3IgdGhlIE9J
REMgYW5kIE9BdXRoIEFwYWNoZSBtb2R1bGVzIHRoYXQgc2V0IGhlYWRlcnMgZm9yIGJhY2tlbmRz
IHRvIGNvbnN1bWUgWzJdOyBhbmQgeWVzLCBJIGhhdmUgbWFkZSBtaXN0YWtlcyBbM10sIGJ1dCBJ
TUhPIGl0IHNob3VsZCBub3QgYmUgYSBwcm9ibGVtIHRvIHVzZSBhIHdlbGwga25vd24gaGVhZGVy
DQogYW5kIG1ha2UgdGhlIGltcGxlbWVudGVyIChub3QgdGhlIGFkbWluKSBnZXQgaXQgcmlnaHQg
YnkgcG9pbnRpbmcgdGhpcyBvdXQgaW4gdGhlIHNwZWMsIGFzIGlzIGRvbmUgZm9yIG1hbnkgb3Ro
ZXIgcGl0ZmFsbHMNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SGFucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3ptYXJ0em9uZS9tb2Rf
dG9rZW5fYmluZGluZy9ibG9iL21hc3Rlci9zcmMvbW9kX3Rva2VuX2JpbmRpbmcuYyNMNDgxLUw0
ODMiPmh0dHBzOi8vZ2l0aHViLmNvbS96bWFydHpvbmUvbW9kX3Rva2VuX2JpbmRpbmcvYmxvYi9t
YXN0ZXIvc3JjL21vZF90b2tlbl9iaW5kaW5nLmMjTDQ4MS1MNDgzPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJdJm5ic3A7PGEgaHJlZj0i
aHR0cHM6Ly9naXRodWIuY29tL3ptYXJ0em9uZS9tb2RfYXV0aF9vcGVuaWRjL2Jsb2IvbWFzdGVy
L3NyYy9tb2RfYXV0aF9vcGVuaWRjLmMjTDE2NC1MMTc1Ij5odHRwczovL2dpdGh1Yi5jb20vem1h
cnR6b25lL21vZF9hdXRoX29wZW5pZGMvYmxvYi9tYXN0ZXIvc3JjL21vZF9hdXRoX29wZW5pZGMu
YyNMMTY0LUwxNzU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5bM10mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5jdmVkZXRhaWxzLmNvbS9j
dmUvQ1ZFLTIwMTctNjQxMy8iPmh0dHBzOi8vd3d3LmN2ZWRldGFpbHMuY29tL2N2ZS9DVkUtMjAx
Ny02NDEzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gVGh1LCBPY3QgMzEsIDIwMTkgYXQgMTE6MzcgQU0gVmxhZGltaXIgRHpodXZp
bm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iPnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCBpbiBhbGwsIEkgYW0gaW4gZmF2b3Igb2Yg
dGhpcyBiZWluZyBkZWZpbmVkIGluIG9uZSBzdGFuZGFyZCB3YXksIGluIGFkZGl0aW9uIHRvIHNl
Y3VyZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gcHJveGllcyBhbmQgYmFja2VuZHMgYmVpbmcgc3Rh
bmRhcmRpemVkIOKAlCBidXQgdGhpcyBsYXR0ZXIgYml0IHJlYWxseSBzZWVtcyBsaWtlIGEgc2Vw
YXJhdGUgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8cD4tMSBmb3IgZGV2aXNpbmcgYSB3ZWxsIGtub3duIGhlYWRlcjxvOnA+PC9v
OnA+PC9wPg0KPHA+JiM0MzsxIGZvciBhIHNpbXBsZSB3YXkgdG8gYXV0aGVudGljYXRlIGEgcmV2
ZXJzZSBwcm94eSB3aXRoIGEgd2ViIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPHA+V2l0aCBhIHdl
bGwga25vd24gbmFtZSwgaW4gYSBhdHRhY2sgdGhpcyB3aWxsIGdldCBwcm9iZWQgZmlyc3QuIFRo
ZSB3ZWxsIGtub3duIGhlYWRlciBuYW1lIGRvZXNuJ3QgZ3VhcmFudGVlIGEgY29ycmVjdCBjb25m
aWcuIEFuZCBpZiB3ZSBoYXZlIGEgbmV3IHN0YW5kYXJkIGZvciBzZWMgaGVhZGVycyB0aGF0IG11
c3QgYmUgc3RyaXBwZWQgYXV0b21hdGljYWxseSBmcm9tIGluYm91bmQgSFRUUCByZXF1ZXN0cywg
d2UgY2Fubm90IGV4cGVjdA0KIHRoYXQgd2lsbCBnZXQgaW1wbGVtZW50ZWQgaW4gYWxsIHJldmVy
c2UgcHJveHkgc29mdHdhcmUgb3Zlcm5pZ2h0LjxvOnA+PC9vOnA+PC9wPg0KPHA+QmVjYXVzZSBh
IGNvcnJlY3QgY29uZmlnIGlzIG5vdCBwcmFjdGljYWwgYXMgdGhlIG9ubHkgbGluZSBvZiBkZWZl
bnNlLCB3aGVuIHdlIGltcGxlbWVudGVkIG1UTFMgd2UgZGVjaWRlZCB0byBhZGQgYSBsZW5ndGgg
KCZndDs9IDMyIGNoYXJzKSBhbmQgcmFuZG9tbmVzcyBjaGVjayB0byB0aGUgaGVhZGVyIGNvbmZp
Zy4gSSBzYXcgc29tZSBjb25jZXJucyB0aGF0IHRoaXMgbWF5IGNhdXNlIGRlcGxveW1lbnQgaXNz
dWVzLiBOb2JvZHkgaGFzIGNvbXBsYWluZWQNCiBhYm91dCB0aGF0IHNvIGZhci48bzpwPjwvbzpw
PjwvcD4NCjxwPjxhIGhyZWY9Imh0dHBzOi8vY29ubmVjdDJpZC5jb20vcHJvZHVjdHMvc2VydmVy
L2RvY3MvY29uZmlnL2NvcmUjb3AtdGxzLWNsaWVudFg1MDlDZXJ0SGVhZGVyIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly9jb25uZWN0MmlkLmNvbS9wcm9kdWN0cy9zZXJ2ZXIvZG9jcy9jb25maWcv
Y29yZSNvcC10bHMtY2xpZW50WDUwOUNlcnRIZWFkZXI8L2E+PG86cD48L286cD48L3A+DQo8cD5S
ZWdhcmRpbmcgbWlzdHlwaW5nLCB0aGlzIGNhbiBiZSBhbiBpc3N1ZSwgYnV0IGhhcyBsaXR0bGUg
dG8gbm8gZWZmZWN0IGlmIGEgbG9uZyByYW5kb20gaGVhZGVyIGdldHMgbWlzc3R5cGVkIChmcm9t
IHRoZSBpbmJvdW5kIHN0cmlwIGRpcmVjdGl2ZSkuIFdpdGggYSB3ZWxsIGtub3duIGhlYWRlciB0
aGlzIHdpbGwgcmVzdWx0IGluIGEgaW1tZWRpYXRlIHNlY3VyaXR5IGhvbGUsIHdoaWNoIGNhbiB0
aGVvcmV0aWNhbGx5IGdvIHVubm90aWNlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+SGVyZSBpcyBh
biBleGFtcGxlIEFwYWNoZSBodHRwZCBjb25maWcsIHRvIGlsbHVzdHJhdGUgbXkgcG9pbnQ6PG86
cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY1Rjc7Ym9yZGVyLXJhZGl1
czozcHg7b3ZlcmZsb3cteDphdXRvO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQt
dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtZGVjb3JhdGlvbi1zdHls
ZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzowcHgi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzE3
MkI0RCI+UmVxdWVzdEhlYWRlciBzZXQgU2VjLUNsaWVudC1YNTA5LUNlcnQtbGllZGU1dmFlUGVl
TWlZaWUweHUyamF1ZGF1bGVpbmcgJnF1b3Q7JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY1RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzE3MkI0RCI+UmVxdWVzdEhlYWRlciBzZXQg
U2VjLUNsaWVudC1YNTA5LUNlcnQtbGllZGU1dmFlUGVlTWlZaWUweHUyamF1ZGF1bGVpbmcgJnF1
b3Q7JXtTU0xfQ0xJRU5UX0NFUlR9cyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHA+
KHRoZSBmaXJzdCBsaW5lIHN0cmlwcyB0aGUgaW5ib3VuZCBoZWFkZXJzKTxvOnA+PC9vOnA+PC9w
Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5WbGFkaW1pcjxvOnA+PC9vOnA+PC9wPg0K
PHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1dmlub3Y8bzpwPjwv
bzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo
QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRA
em1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8
L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLSA8YSBo
cmVmPSJodHRwOi8vd3d3LnptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPg0Kd3d3LnptYXJ0
em9uZS5ldTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwcmU+LS0g
PG86cD48L286cD48L3ByZT4NCjxwcmU+VmxhZGltaXIgRHpodXZpbm92PG86cD48L286cD48L3By
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHBy
ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_D5621F8B53754BD0B83D7C2D17BC8D53amazoncom_--


From nobody Thu Oct 31 14:50:07 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A19120847 for ; Thu, 31 Oct 2019 14:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=zmartzone-eu.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 SObZ3chrl51N for ; Thu, 31 Oct 2019 14:50:02 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465AA12080E for ; Thu, 31 Oct 2019 14:50:02 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id m4so8637560qke.9 for ; Thu, 31 Oct 2019 14:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sNK+HV5/Wrud1vZbBsW2W6LccbZ0FRImlczlUwxuk+I=; b=zHU9KlLfK37wHS+P2oUkqGrIkdn6c/k3rGQYVpAqjMxVt5IpFpl0v/UQGIHNBEr2gL O6HnNtScaGgrhAvksueOtHAgG4dnpHVY5dg50WnPcCmr5RtCyfFGkzkg8If99q8bYfyE r/dn9Z7bnAK61W/kQ3fW+M7ikllUECNQKzuY5+eoli+bb+ukXuL+O5qjeqvtmBsW8I2C 7BqqyhPmiBZNEpzJXKXCXgAtK3mLyfQdXCw63J5rhU5tvGzGKP0yWuO3lKUQ2AYLMZTf A4Tqe4T9Bxh/RB5MPbZkFiRK3CzZvdDyLEIEFlG9qXeBu7xe3nvFAjA4r35KYi7kmQKe 9PWQ==
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=sNK+HV5/Wrud1vZbBsW2W6LccbZ0FRImlczlUwxuk+I=; b=tSwMpsUU0aop4D9tw0qUgIkfB14qk/9fVvv7BXcMM1oHafhYBlvR2K1oYZAeZZxTDc 9UHj99R8ARZDfvdCmory2rzHW313Ox9he/J5PAD6OH30um0ak3m4NARIhuvTIQSS/UO/ UUOyxcPOnVfN3HEsi1/+JTx2xeZxQCivHsQH5AzxIkj8Qg+DsptctZtLh1tfevr9aPc3 SuDRonbHmKIORuYTBxNwkQn3fgHC4aKCAAWJ1tHKJbjssS8xxNBDM+xAdz3NtMQef4Sc xQIFr8EimKhk5PrQusYiihuvojCqEI3kC/1mCp1xAHCqWmSayKXav5+sF9Dccty0+TFU 9+xA==
X-Gm-Message-State: APjAAAUe5si1Bjbey8cjoI22xuU5K+/nVtrX1/5IVyhAXOZpTdKZugBj Hy9i9uVeYSBa+E0YYagbAQDlCg0NBLsfiqKjzkCU/2Vr
X-Google-Smtp-Source: APXvYqyaWQPM3kaHNqUVkoReBYbrT+jzqlqCoUc6j1VPqUTzJ2mn6gAVnaBrasi53yG2BhivE4VQuE7NfuYCk4nbobc=
X-Received: by 2002:ae9:f80d:: with SMTP id x13mr3337185qkh.63.1572558601090;  Thu, 31 Oct 2019 14:50:01 -0700 (PDT)
MIME-Version: 1.0
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu>        <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu>    <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>  <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com> 
In-Reply-To: 
From: Hans Zandbelt 
Date: Thu, 31 Oct 2019 22:49:49 +0100
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Vladimir Dzhuvinov , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ce939e05963bd4ed"
Archived-At: 
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 21:50:06 -0000

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

for me this thread is running a bit wild: if we don't believe that
implementers get incoming header removal right, why do we believe the same
implementers get randomizing and/or HMAC signing right
setting headers on a trusted leg between proxies and origin servers has
been a best practice for decades, regardless of implementation bugs (which
similarly exist in crypto implementations)
catering for non-trusted legs is fine, but don't let it stand in the way of
the obvious

Hans.

On Thu, Oct 31, 2019 at 10:35 PM Richard Backman, Annabelle  wrote:

> I think the HMAC/signature approach is actually easier for cloud vendors
> to implement. The threat model is much simpler to understand, and risk
> mitigation mostly boils down to well-understood cryptographic hygiene
> patterns. And again, it=E2=80=99s obvious what values are secrets and wha=
t values
> aren=E2=80=99t.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 1:50 PM
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>
>
> I agree wholeheartedly that an HMAC or even signature is preferable. With
> HMAC vs signature having their relative pros / cons, in terms of
> computation and key distribution. If a standard for that is created, and =
I
> am a web application developer, I'll be able to handle the header checks =
in
> the application layer code relatively easily. But I have much less contro=
l
> over how / where the application is going to be deployed, and if the
> reverse proxy has this header security implemented. Software and cloud
> vendors can sometimes be significantly behind in such developments. Even
> basic handling of self-signed client certificates has been an issue for u=
s
> in popular cloud environments.
>
> With that in mind, the "secret" headers can be configured with most
> currently available reverse proxy software. I see it as a useful
> intermediate step, until a standard for authenticated headers gets agreed
> on and eventually implemented in reverse proxies. Can you comment on that
> from this perspective?
>
> Over the years I have come to the conclusion that standards which can be
> implemented in the application layer or as a simple config stand a better
> chance. Standards which rely on other layers or on broad vendor or
> developer support to become useful run the risk of not getting adopted in
> practice. Token binding suffered from that.
>
> Vladimir
>
> On 31/10/2019 20:55, Richard Backman, Annabelle wrote:
>
> Relying on a fixed, random header name for security, even as a =E2=80=9Cd=
efense in
> depth=E2=80=9D measure, is dangerous. In order for this mechanism to be e=
ffective,
> the header name must be random (in the cryptographic sense) and must be
> kept secret. It needs to be withheld from request logs or error logs,
> either on the reverse proxy or on the service. It cannot be committed to
> code repositories. Including it as a signed header in request signing
> algorithms that require an explicit list of signed headers (such as AWS
> Signature Version 4
> ,
> draft-cavage-http-signatures
> ,
> draft-ietf-oauth-signed-http-request
> ) turns
> that signature metadata into a secret, meaning that *it* cannot be
> logged, etc. If signatures are sent to a central authority for processing=
,
> that authority must also know not to log the list of signed headers. I
> could go on, but I hope this is enough to express that there are SO MANY
> ways that header names can and will be revealed, and they aren=E2=80=99t =
always
> obvious.
>
>
>
> What we are talking about is a message authenticity problem. The best
> practices for providing message authenticity involve applied crypto, e.g.=
,
> an HMAC or digital signature over the header contents. If an implementati=
on
> does that, then the random header name is unnecessary. This approach is
> immune to the sort of misconfiguration scenarios that have been discussed
> in this thread, as they would result in the reverse proxy failing to
> provide a properly signed header to the service.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth   on behalf
> of Vladimir Dzhuvinov  
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"oauth@ietf.org"   
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>
>
> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will  cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think Rich
> Salz had this concern).
>
> * The random chars part, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
>
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
> the way I see this is that stripping and setting the headers must be part
> of the implementation of the protocol itself, it should not be something
> left to a non-atomic piece of configuration by an administrator; I
> implemented it like this in the Apache implementation of Brian's TTRP spe=
c
> [1] and have been doing this for the OIDC and OAuth Apache modules that s=
et
> headers for backends to consume [2]; and yes, I have made mistakes [3], b=
ut
> IMHO it should not be a problem to use a well known header and make the
> implementer (not the admin) get it right by pointing this out in the spec=
,
> as is done for many other pitfalls
>
>
>
> Hans.
>
>
>
> [1]
> https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_=
binding.c#L481-L483
>
> [2]
> https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_op=
enidc.c#L164-L175
>
> [3] https://www.cvedetails.com/cve/CVE-2017-6413/
>
>
>
> On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
>
> All in all, I am in favor of this being defined in one standard way, in
> addition to secure communication between proxies and backends being
> standardized =E2=80=94 but this latter bit really seems like a separate p=
roblem.
>
>
>
>  =E2=80=94 Justin
>
> -1 for devising a well known header
>
> +1 for a simple way to authenticate a reverse proxy with a web server
>
> With a well known name, in a attack this will get probed first. The well
> known header name doesn't guarantee a correct config. And if we have a ne=
w
> standard for sec headers that must be stripped automatically from inbound
> HTTP requests, we cannot expect that will get implemented in all reverse
> proxy software overnight.
>
> Because a correct config is not practical as the only line of defense,
> when we implemented mTLS we decided to add a length (>=3D 32 chars) and
> randomness check to the header config. I saw some concerns that this may
> cause deployment issues. Nobody has complained about that so far.
>
>
> https://connect2id.com/products/server/docs/config/core#op-tls-clientX509=
CertHeader
>
> Regarding mistyping, this can be an issue, but has little to no effect if
> a long random header gets misstyped (from the inbound strip directive).
> With a well known header this will result in a immediate security hole,
> which can theoretically go unnoticed.
>
> Here is an example Apache httpd config, to illustrate my point:
>
> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "=
"
>
> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "=
%{SSL_CLIENT_CERT}s"
>
> (the first line strips the inbound headers)
>
>
>
> Vladimir
>
> --
>
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
> --
>
> 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
>


--=20
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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


for me this thread is running a bit wild:=
 if we don't believe that implementers get incoming header removal righ=
t, why do we believe the same implementers get randomizing and/or HMAC sign=
ing right
setting headers on a trusted leg between proxies and origin s=
ervers has been a best practice for decades, regardless of implementation b=
ugs (which similarly exist in crypto implementations)
catering fo=
r non-trusted legs is fine, but don't let it stand in the way of the ob=
vious

Hans.

On Thu, Oct 31, 2019 at 10:35 PM =
Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:











I think the HMAC/signature approach is actually easi=
er for cloud vendors to implement. The threat model is much simpler to unde=
rstand, and risk mitigation mostly boils down to well-understood cryptograp=
hic hygiene patterns. And again, it=E2=80=99s
 obvious what values are secrets and what values aren=E2=80=99t.<=
/u>


=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 Vladimir Dzhuvinov <vladimir@connect2id.com>

Organization: Connect2id Ltd.

Date: Thursday, October 31, 2019 at 1:50 PM

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

Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Pro=
xies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.tx=
t)






=C2=A0




I agree wholeheartedly that an HMAC or even signature is preferable. Wit=
h HMAC vs signature having their relative pros / cons, in terms of computat=
ion and key distribution. If a standard for that is created, and I am a web=
 application developer, I'll be
 able to handle the header checks in the application layer code relatively =
easily. But I have much less control over how / where the application is go=
ing to be deployed, and if the reverse proxy has this header security imple=
mented. Software and cloud vendors
 can sometimes be significantly behind in such developments. Even basic han=
dling of self-signed client certificates has been an issue for us in popula=
r cloud environments.


With that in mind, the "secret" headers can be configured with=
 most currently available reverse proxy software. I see it as a useful inte=
rmediate step, until a standard for authenticated headers gets agreed on an=
d eventually implemented in reverse proxies.
 Can you comment on that from this perspective?


Over the years I have come to the conclusion that standards which can be=
 implemented in the application layer or as a simple config stand a better =
chance. Standards which rely on other layers or on broad vendor or develope=
r support to become useful run the
 risk of not getting adopted in practice. Token binding suffered from that.=



Vladimir




On 31/10/2019 20:55, Richard Backman, Annabelle wrot=
e:






Relying on a fixed, random header name for security,=
 even as a =E2=80=9Cdefense in depth=E2=80=9D measure, is dangerous. In ord=
er for this mechanism to be effective, the header name must be random (in t=
he cryptographic sense) and must be kept secret. It
 needs to be withheld from request logs or error logs, either on the revers=
e proxy or on the service. It cannot be committed to code repositories. Inc=
luding it as a signed header in request signing algorithms that require an =
explicit list of signed headers
 (such as 
AWS Signature Version 4, 
draft-cavage-http-signatures, 
draft-ietf-oauth-signed-http-request) turns that signature metadata int=
o a secret, meaning that
it cannot be logged, etc. If signatures are sent to a central author=
ity for processing, that authority must also know not to log the list of si=
gned headers. I could go on, but I hope this is enough to express that ther=
e are SO MANY ways that header names
 can and will be revealed, and they aren=E2=80=99t always obvious.


=C2=A0


What we are talking about is a message authenticity =
problem. The best practices for providing message authenticity involve appl=
ied crypto, e.g., an HMAC or digital signature over the header contents. If=
 an implementation does that, then
 the random header name is unnecessary. This approach is immune to the sort=
 of misconfiguration scenarios that have been discussed in this thread, as =
they would result in the reverse proxy failing to provide a properly signed=
 header to the service.




=C2=A0


=E2=80=93=C2=A0


Annabelle Richard Bac=
kman


AWS Identity




=C2=A0


=C2=A0




From: =
OAuth
<oauth-bounc=
es@ietf.org> on behalf of Vladimir Dzhuvinov
<vladimir@c=
onnect2id.com>

Organization: Connect2id Ltd.

Date: Thursday, October 31, 2019 at 4:27 AM

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

Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Pro=
xies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.tx=
t)






=C2=A0




This is a good story.


How about requiring reverse proxies to automatically scrub all inbound H=
TTP headers that start with "Sec-"?


If a sec header has the format "Sec-[NAME]-[random-chars]" we =
get:


* The "Sec-" prefix will=C2=A0 cause new compliant reserve pro=
xies to automatically scrub the inbound HTTP header.


* The NAME part still makes the header easily identifiable (I think Rich=
 Salz had this concern).


* The random chars part, potentially optional, will provide a line of de=
fence against config errors in old legacy reverse proxies.

All concerns should then get covered.


Vladimir




On 31/10/2019 12:48, Hans Zandbelt wrote:<=
/u>










the way I see this is that stripping and setting the=
 headers must be part of the implementation of the protocol itself, it shou=
ld not be something left to a non-atomic piece of configuration by an admin=
istrator; I implemented it like this
 in the Apache implementation of Brian's TTRP spec [1] and have been do=
ing this for the OIDC and OAuth Apache modules that set headers for backend=
s to consume [2]; and yes, I have made mistakes [3], but IMHO it should not=
 be a problem to use a well known header
 and make the implementer (not the admin) get it right by pointing this out=
 in the spec, as is done for many other pitfalls





=C2=A0






Hans.






=C2=A0









=C2=A0






On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov =
<vladimir@c=
onnect2id.com> wrote:












All in all, I am in favor of this being defined in o=
ne standard way, in addition to secure communication between proxies and ba=
ckends being standardized =E2=80=94 but this latter bit really seems like a=
 separate problem.






=C2=A0






=C2=A0=E2=80=94 Justin






-1 for devising a well known header


+1 for a simple way to authenticate a reverse proxy with a web server=



With a well known name, in a attack this will get probed first. The well=
 known header name doesn't guarantee a correct config. And if we have a=
 new standard for sec headers that must be stripped automatically from inbo=
und HTTP requests, we cannot expect
 that will get implemented in all reverse proxy software overnight.<=
u>


Because a correct config is not practical as the only line of defense, w=
hen we implemented mTLS we decided to add a length (>=3D 32 chars) and r=
andomness check to the header config. I saw some concerns that this may cau=
se deployment issues. Nobody has complained
 about that so far.


https://connect2id.com/products/s=
erver/docs/config/core#op-tls-clientX509CertHeader


Regarding mistyping, this can be an issue, but has little to no effect i=
f a long random header gets misstyped (from the inbound strip directive). W=
ith a well known header this will result in a immediate security hole, whic=
h can theoretically go unnoticed.



Here is an example Apache httpd config, to illustrate my point:


Reques=
tHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "&qu=
ot;


RequestHeader set Sec-Client-X509-Cert-=
liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"<=
/u>


(the first line strips the inbound headers)


=C2=A0


Vladimir


-- 


Vladimir Dzhuvinov




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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













=C2=A0




-- 







-- 


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




-- 


--000000000000ce939e05963bd4ed--