From nobody Mon Jun 1 05:27:16 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04793A087C; Mon, 1 Jun 2020 05:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D/Kv0VA9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g/+Dnjos Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzh3-XhJYjWB; Mon, 1 Jun 2020 05:27:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A653A087B; Mon, 1 Jun 2020 05:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3161; q=dns/txt; s=iport; t=1591014432; x=1592224032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/0qb8kYHEY25chwzeF25hJ5KGIo2pkwDv1XedlfYmz0=; b=D/Kv0VA9m+qhGCiCQJds/S6N1RJqvUmyXDOF3ySM2b8z9cUA5kaKmsM7 EwXVWg04KdtgCDplTiubLYkvCl8gr0dv+5mcRwfF8l9S15XrE+Wli1HiM x7z5kqYANNNybRKOkR73l9I6GbwQ/T6QfOlC/JHVSvrPxp3dwqtN4VB8W A=; IronPort-PHdr: =?us-ascii?q?9a23=3A5bqK5BM9z3aaX0Mif9Il6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13lrIQcPW5+8Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoNElJXsvyeg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAACe89Re/5xdJa1mDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBQIFKgVBSB29YLywKh2EDjUKYTIJ?= =?us-ascii?q?SA1ULAQEBDAEBIwoCBAEBhEQCgiUCJDgTAgMBAQsBAQUBAQECAQYEbYVZDIV?= =?us-ascii?q?yAQEBAQMSKAYBATcBCwQCAQgRBAEBAR4QMh0IAgQBDQUIGoMFgksDLgEOoks?= =?us-ascii?q?CgTmIYXSBNIMBAQEFhQgYgg4JgTgBgmOJYxqBQT+BEUOCTT6BBIEaSQOBZjC?= =?us-ascii?q?DFYItjmqCUKIZCoJXmQ2CZpsykF+BXphugy4CBAIEBQIOAQEFgWoigUAPB3A?= =?us-ascii?q?VGhcPex2BIykJRxcCDZBAg3KEWTuFBD50AjUCBggBAQMJfItjAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,460,1583193600"; d="scan'208";a="766567744" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 12:27:11 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 051CRB7j030541 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Jun 2020 12:27:11 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 07:27:11 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 07:27:10 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Jun 2020 07:27:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlkgoeNX+SovZO+CLiG1/wPXzmCO/5NVxtCkpocBKcahclWI06SniDknl28+/rBO8kQMVDB9Hjcx7jTI/4yXe7HMbaogJgVPdfagMHi6XzhIxroGt9Pf3Rqsitmva3ZqQ72Vb9lBZZFc9GUQhlPUrXWcqJc5o+MgWKD1PP17Ps7Sxg7xwJzemdgLZZWL/HAZo0yxiR/k5yjt64HVfG8vwjz384yP+DxICRy+FkVY+72+QfSOsjFoUmPXPNFkrSn6WIxcRST+/9dMsMkNdaQZMR2MaCUN/rOh3+ZcH/VgWzQ8TL8GOK6X/So89/GRj0OgH8MPtRSMtZk9ALags2XXlA== 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=71a0V/6Ub57K+IWSC1CMOeQU8Y923y8xKNXyZSPZ2x8=; b=AOZuKl9W5VGuzyuclsia0pbzKuRaMx3wtuOPwc6HUkOqgb3xLT13JiNsdNRRGjPJs0A49nXTnHL0BFu+e8YmaIqEYF+xzzrUnp0yWQEyVD/oFFmTGTFDVvwPsixAxMAZS2LDRbZWx3kh6QxsjLLzFqCfk+0DGjpn0z+JHA39QO4Mxb7GgaIWmS6cC2nubUEpBUWmOV/j7cFsqIsg8nwMtU0JOiPMlKRd31sH7NR3nDbf9q2wTJ/CFbsmlnnjizhNLbZ9+FgFtHjAkaWf/L7FeyWPtcBkpyceF9X5drX5ohDn7OrB1OaqAHej+FM5hj1o34K+vHFAPWruOytDFU1ajg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=71a0V/6Ub57K+IWSC1CMOeQU8Y923y8xKNXyZSPZ2x8=; b=g/+DnjosIR1EX9XLlW0R744KKjElHUjOjnTSb5zOiixcGRLk9irtxQzB6Jc9HhMvmzNLjVGvHGhlp+Z+Ii8JDIGbaH5pgWGNVSHDzA70yndpp2YQFfo57zRPCpKRUSQPgGuc2sLUANycZ6rE4s9gv4x/S3hqCQCkoJ+/V0oQ9IA= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4647.namprd11.prod.outlook.com (2603:10b6:208:262::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Mon, 1 Jun 2020 12:27:10 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3045.024; Mon, 1 Jun 2020 12:27:09 +0000 From: "Rob Wilton (rwilton)" To: Benjamin Kaduk , Pete Resnick CC: "mbj@microsoft.com" , "iesg@ietf.org" , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" , "oauth@ietf.org" , "RFC Errata System" Thread-Topic: [Errata Verified] RFC7800 (6187) Thread-Index: AQHWNuulQReviV4PKkaVPVtDH4tsaqjBkK2AgAAEBACAAhv7EA== Date: Mon, 1 Jun 2020 12:27:09 +0000 Message-ID: References: <20200531013404.4528BF40721@rfc-editor.org> <20200531040924.GM58497@kduck.mit.edu> In-Reply-To: <20200531040924.GM58497@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc5c4492-504e-49d5-6643-08d806271b07 x-ms-traffictypediagnostic: MN2PR11MB4647: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vHdzUXi0k0ExSUJO5pgSPtAuHz+PLyhntv/4QrmX2kV4FwoqGV0wnMkkRrxyrTsBAuHflqsPmt75yAmWz3eiKKI1/EOegacnt2ifoKGqKZEXxwoPTRsUEarGr2aiyOLmmxGG1PrICj6be8RBC1LL2Buscw1T7dMd3ZJMHwbUepLfcYlEFl3Yzg3XnycT5S/7UByiRfIPAY8fyBWW86obduPnrNAxTB7ohRpkDZSHvVs/+YnwELlpi8kti5FMwa4456DBykdWP8Pd7xMTpFdKDDF4hpRU+eT39zPJMiiyTr8pymVV/Kw+ExUlRQzzoWY51NWpfBN+TnLpfVHG8aHMFk15GzeUjoof68KpIbc+qpYD2LwHoAAkGOGNaaglHOzAoOcEdSVht77VfD+F2gVS0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(366004)(346002)(396003)(39860400002)(186003)(45080400002)(5660300002)(6506007)(2906002)(86362001)(26005)(8676002)(8936002)(83380400001)(52536014)(478600001)(966005)(76116006)(64756008)(66476007)(66946007)(66556008)(33656002)(66446008)(110136005)(316002)(54906003)(71200400001)(15650500001)(4326008)(7696005)(9686003)(53546011)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6sd+wyPLHgVWVqrCF731oS6S1OrlENF1DTPHZ/XvlJdVod506QPsdJxPc/h21xMWMzrYa4wLpkTkjVYJsr5ecITCrCW7HX/sqVqUODJu+YPLNgxDKsnVIFyV+H4ROCbzQSAmKBOF0t7JYTqHgfQ1m014oKWYtu72WK3IxsNi1sxvio17+QidSz0z0glwzr++k8+MH/cYe4TrClx1o8dbjPahq0jzUWzHa/k5fMlm3fiyaHbpmOPZ3ESZMZZne+4Zm3XRZMDhZTvlxiT7P2WvsOUA0JmfJvrGGjZAlmmhUj5AcbCwIOsWI96Qx0y/CgVDVvvxoAQ4HPZdjYs9CaOlwnkj9IBmEkKh5rT6XkEudwKluFL4IAiEieZka2I64wTbVct2rzNz6k67FxcaBDUakqeKMwFWIAS3J+jY1wPbaL8Yx5Le7K1qMEy4wFZiA8NYnXUk9sKOnq4y4yzmjyKAy+67poWWNbYJXXM8eHHqL8I= 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-CrossTenant-Network-Message-Id: fc5c4492-504e-49d5-6643-08d806271b07 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 12:27:09.7137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hCWCXEtS8bzymRHoM/Fo8eXPEpc/4FM2k3bAs8FlYaYGF+W2/5NqVkBwWnbY1JnRRx+tW2e6sXCRLYJ1g4Ag/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4647 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 12:27:15 -0000 > -----Original Message----- > From: iesg On Behalf Of Benjamin Kaduk > Sent: 31 May 2020 05:09 > To: Pete Resnick > Cc: mbj@microsoft.com; iesg@ietf.org; ve7jtb@ve7jtb.com; > Hannes.Tschofenig@gmx.net; oauth@ietf.org; RFC Errata System editor@rfc-editor.org> > Subject: Re: [Errata Verified] RFC7800 (6187) >=20 > The new text is clearly the right thing, and there is no need > to debate it if/when the document gets updated. "Don't hold > it; do it now", so to speak -- and noting that (my > understanding/recollection of) the plan for > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only > verified errata, not those in other states, will be displayed. [RW]=20 If this ends up being the plan, then I think that we may wish to modify the= RFC guidance, or possibly have two different verified states: (i) Verified, could impact implementations (ii) Verified, editorial only. Certainly, it seems to be makes sense for these sorts of errata to be displ= ayed. Regards, Rob >=20 > (Yes, that link 404s at the moment, I assume a caching issue.) >=20 > -Ben >=20 > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote: > > "Verified", not "Hold For Document Update"? > > > > pr > > > > On 30 May 2020, at 20:34, RFC Errata System wrote: > > > > > The following errata report has been verified for RFC7800, > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > https://www.rfc-editor.org/errata/eid6187 > > > > > > -------------------------------------- > > > Status: Verified > > > Type: Editorial > > > > > > Reported by: Pete Resnick > > > Date Reported: 2020-05-26 > > > Verified by: Benjamin Kaduk (IESG) > > > > > > Section: 7.1 > > > > > > Original Text > > > ------------- > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > DOI 10.17487/RFC7157, May 2015, > > > . > > > > > > > > > Corrected Text > > > -------------- > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > DOI 10.17487/RFC7517, May 2015, > > > . > > > > > > > > > Notes > > > ----- > > > DOI has a typo: 7157 instead of 7517. > > > > > > -------------------------------------- > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11) > > > -------------------------------------- > > > Title : Proof-of-Possession Key Semantics for JSON Web > > > Tokens (JWTs) > > > Publication Date : April 2016 > > > Author(s) : M. Jones, J. Bradley, H. Tschofenig > > > Category : PROPOSED STANDARD > > > Source : Web Authorization Protocol > > > Area : Security > > > Stream : IETF > > > Verifying Party : IESG > > > > > > -- > > Pete Resnick https://www.episteme.net/ > > All connections to the world are tenuous at best From nobody Mon Jun 1 06:16:36 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261863A10BD; Mon, 1 Jun 2020 06:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPOgq5xHf9Aa; Mon, 1 Jun 2020 06:16:29 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097463A1074; Mon, 1 Jun 2020 06:16:27 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id q8so6811821iow.7; Mon, 01 Jun 2020 06:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xhW2vOBis1SSm4HFGJPSTd4/vKCSE4+dhrA7DW5AOZA=; b=SuthbdXdUDFLJgUunOh+t4kIHsOt1hR3a5HoUV2LXcir7sowkwNrckBi4v55nvn+QO gyeKXq4OUZWlnypsxCbT6iAgakroloJzJCuR0S1EzlGERweAZa4AOPfoGX+M8YFn8x8S Aa2+O0Qcu/hT9dTRThkcJNJRr01bSWJmg7ZWqxUHfMU9w/MoSkED4ZzHPjx8KJd+CM+p OfWMKsMMsTxJq6pxr1DOd7x52U3KoPrjrirOckVxQJ3ZPce2IFYoCI1cRd6su23M+QhZ y2wcsr6XIW6YdQyW2K1amTqSxidmGoFw/6AKUs9nK0sYTDO3HT4aiX8Y/iRehGgKvs/i Vz+A== X-Gm-Message-State: AOAM532EQAd0FlL+zlg7h3xbasmfT/51nGY6t7KI0bkELa7hrTUAkXCK ta1gy7l6wATU0I4alza68Crd0gEyRoKKtlY4TRw= X-Google-Smtp-Source: ABdhPJxKk2GRvIRAo6zHjDlP5OZpfsclxZQ/e1JarMeYyhYIfaS7oOcZDA7dnRI7/dJLoTWuTqbLL1QOVJyZ8QyXuqI= X-Received: by 2002:a6b:8b12:: with SMTP id n18mr18737545iod.160.1591017385892; Mon, 01 Jun 2020 06:16:25 -0700 (PDT) MIME-Version: 1.0 References: <20200531013404.4528BF40721@rfc-editor.org> <20200531040924.GM58497@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Mon, 1 Jun 2020 09:16:14 -0400 Message-ID: To: "Rob Wilton (rwilton)" Cc: Benjamin Kaduk , Pete Resnick , "mbj@microsoft.com" , "iesg@ietf.org" , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" , "oauth@ietf.org" , RFC Errata System Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:16:32 -0000 That's what the "technical" vs "editorial" distinction is supposed to be for. Barry On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton) wrote: > > > > > -----Original Message----- > > From: iesg On Behalf Of Benjamin Kaduk > > Sent: 31 May 2020 05:09 > > To: Pete Resnick > > Cc: mbj@microsoft.com; iesg@ietf.org; ve7jtb@ve7jtb.com; > > Hannes.Tschofenig@gmx.net; oauth@ietf.org; RFC Errata System > editor@rfc-editor.org> > > Subject: Re: [Errata Verified] RFC7800 (6187) > > > > The new text is clearly the right thing, and there is no need > > to debate it if/when the document gets updated. "Don't hold > > it; do it now", so to speak -- and noting that (my > > understanding/recollection of) the plan for > > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only > > verified errata, not those in other states, will be displayed. > [RW] > > If this ends up being the plan, then I think that we may wish to modify the RFC guidance, or possibly have two different verified states: > (i) Verified, could impact implementations > (ii) Verified, editorial only. > > Certainly, it seems to be makes sense for these sorts of errata to be displayed. > > Regards, > Rob > > > > > > (Yes, that link 404s at the moment, I assume a caching issue.) > > > > -Ben > > > > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote: > > > "Verified", not "Hold For Document Update"? > > > > > > pr > > > > > > On 30 May 2020, at 20:34, RFC Errata System wrote: > > > > > > > The following errata report has been verified for RFC7800, > > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > https://www.rfc-editor.org/errata/eid6187 > > > > > > > > -------------------------------------- > > > > Status: Verified > > > > Type: Editorial > > > > > > > > Reported by: Pete Resnick > > > > Date Reported: 2020-05-26 > > > > Verified by: Benjamin Kaduk (IESG) > > > > > > > > Section: 7.1 > > > > > > > > Original Text > > > > ------------- > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > > DOI 10.17487/RFC7157, May 2015, > > > > . > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > > DOI 10.17487/RFC7517, May 2015, > > > > . > > > > > > > > > > > > Notes > > > > ----- > > > > DOI has a typo: 7157 instead of 7517. > > > > > > > > -------------------------------------- > > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11) > > > > -------------------------------------- > > > > Title : Proof-of-Possession Key Semantics for JSON Web > > > > Tokens (JWTs) > > > > Publication Date : April 2016 > > > > Author(s) : M. Jones, J. Bradley, H. Tschofenig > > > > Category : PROPOSED STANDARD > > > > Source : Web Authorization Protocol > > > > Area : Security > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > > -- > > > Pete Resnick https://www.episteme.net/ > > > All connections to the world are tenuous at best > From nobody Mon Jun 1 06:24:04 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECC3A1044; Mon, 1 Jun 2020 06:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFmZ3tvsfv8W; Mon, 1 Jun 2020 06:23:47 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FC53A0F2E; Mon, 1 Jun 2020 06:23:47 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id s18so6879314ioe.2; Mon, 01 Jun 2020 06:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vergsmrEDhSPZr4q5947Ns/Zsr3xwbZ+d+iFtoPgZ4Y=; b=Dxy7Y4gmJXN4iJKiXXuoCA7IhRRLEPZCHiDuOUGsl3aKA6vjgMSLi7fKNlb4V4RmJe baJC/AuGh5/GjAp4C3iBZII6jLjiFzf84PjdpDuBflCzkGhgvmoZjNnU5ienUp/moge2 p1nu8ltHm7VjI6jt5DS9L6A8d2mdqss++K9Gf0klwB7M4H5khcC4SPQzCiy9t0M7y+cI kmCgOKHd54CcKXWmmOCr/TVoXk+2PMEQDk1f0fzo0d+ke8hTFafmwA7Hefjkq1VoBLxG 0L86oM6LCUMmqb5lQzceE0v4h0SfucpfREU2HkByTv8EoKxltzOPUx/dwgyjBMpRzHNQ W2yQ== X-Gm-Message-State: AOAM533/I9zeyJcQk8xtjo1GJoPelL20m+X0euAuH8IQhGC9v1mFC7Ea c0c4uLwvbcPbcH6M0yq+blaTrL/B2vTe0Oh4mf0U7A== X-Google-Smtp-Source: ABdhPJxSBYl60Q20F3qJsx6Dvq/3JNiN6CMe/HWwmijNk8toi9ahAo9EKvdmkmzAJyhUOtreDpUYwyE1WlV7lPdcug0= X-Received: by 2002:a05:6602:2817:: with SMTP id d23mr18664098ioe.206.1591017826395; Mon, 01 Jun 2020 06:23:46 -0700 (PDT) MIME-Version: 1.0 References: <20200531013404.4528BF40721@rfc-editor.org> <20200531040924.GM58497@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Mon, 1 Jun 2020 09:23:35 -0400 Message-ID: To: "Rob Wilton (rwilton)" Cc: Benjamin Kaduk , Pete Resnick , "mbj@microsoft.com" , "iesg@ietf.org" , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" , "oauth@ietf.org" , RFC Errata System Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:23:49 -0000 Further on this: In the "editorial" realm, there are two classes of "correct" errata reports: 1. Trivial and obvious typos, such as spelling "and" as "adn". 2. Others, such as a number with transposed digits, which could, indeed, be confusing. The guideline that we're discussing is meant to separate those out, saying that class 1 should go to HFDU, while class 2 might qualify as Verified. Whether a particular report falls into class 1 or 2 is usually clear, but sometimes a matter of judgment. And then whether a class 2 report rates Verified or HFDU is also sometimes a matter of judgment. I'm personally happy with leaving that to judgment, rather than trying to be overly rigorous about making rules for it. I'm also happy with the idea of clarifying or altering the guidelines, if someone wants to make a specific proposal. One thing we have talked about is having the RPC handle editorial class 1 reports, and we can discuss that again if we like. Should we do that, it might make sense to have a separate handling code for those that the RPC resolves. Barry On Mon, Jun 1, 2020 at 9:16 AM Barry Leiba wrote: > > That's what the "technical" vs "editorial" distinction is supposed to be for. > > Barry > > On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton) > wrote: > > > > > > > > > -----Original Message----- > > > From: iesg On Behalf Of Benjamin Kaduk > > > Sent: 31 May 2020 05:09 > > > To: Pete Resnick > > > Cc: mbj@microsoft.com; iesg@ietf.org; ve7jtb@ve7jtb.com; > > > Hannes.Tschofenig@gmx.net; oauth@ietf.org; RFC Errata System > > editor@rfc-editor.org> > > > Subject: Re: [Errata Verified] RFC7800 (6187) > > > > > > The new text is clearly the right thing, and there is no need > > > to debate it if/when the document gets updated. "Don't hold > > > it; do it now", so to speak -- and noting that (my > > > understanding/recollection of) the plan for > > > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only > > > verified errata, not those in other states, will be displayed. > > [RW] > > > > If this ends up being the plan, then I think that we may wish to modify the RFC guidance, or possibly have two different verified states: > > (i) Verified, could impact implementations > > (ii) Verified, editorial only. > > > > Certainly, it seems to be makes sense for these sorts of errata to be displayed. > > > > Regards, > > Rob > > > > > > > > > > (Yes, that link 404s at the moment, I assume a caching issue.) > > > > > > -Ben > > > > > > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote: > > > > "Verified", not "Hold For Document Update"? > > > > > > > > pr > > > > > > > > On 30 May 2020, at 20:34, RFC Errata System wrote: > > > > > > > > > The following errata report has been verified for RFC7800, > > > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > https://www.rfc-editor.org/errata/eid6187 > > > > > > > > > > -------------------------------------- > > > > > Status: Verified > > > > > Type: Editorial > > > > > > > > > > Reported by: Pete Resnick > > > > > Date Reported: 2020-05-26 > > > > > Verified by: Benjamin Kaduk (IESG) > > > > > > > > > > Section: 7.1 > > > > > > > > > > Original Text > > > > > ------------- > > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > > > DOI 10.17487/RFC7157, May 2015, > > > > > . > > > > > > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > > > > > DOI 10.17487/RFC7517, May 2015, > > > > > . > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > DOI has a typo: 7157 instead of 7517. > > > > > > > > > > -------------------------------------- > > > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11) > > > > > -------------------------------------- > > > > > Title : Proof-of-Possession Key Semantics for JSON Web > > > > > Tokens (JWTs) > > > > > Publication Date : April 2016 > > > > > Author(s) : M. Jones, J. Bradley, H. Tschofenig > > > > > Category : PROPOSED STANDARD > > > > > Source : Web Authorization Protocol > > > > > Area : Security > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > > > > > > > -- > > > > Pete Resnick https://www.episteme.net/ > > > > All connections to the world are tenuous at best > > From nobody Mon Jun 1 06:24:12 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4A03A1076; Mon, 1 Jun 2020 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MprjY3xe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tJ5eLj00 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICmtRJdLmbEP; Mon, 1 Jun 2020 06:24:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEFF3A1070; Mon, 1 Jun 2020 06:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6466; q=dns/txt; s=iport; t=1591017842; x=1592227442; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U+j3EdO5RgwgR9poknD9BnGi9XE1WAOWOvYGUiOoNO8=; b=MprjY3xeFNRGx96i5EtlnhLLZeD5HK8M02dHmRJM3jaXapMHXMBceB3t UoBIqWgfVdYI8v1Bc3pYYK5umBMnIhNLZjDbLLlLNOP2dhleK5Ur2OdnQ 4wCMYvtDdTSXQYcqQssh2ByusHtMaJCHc57ISammhh74RXOa6t3SNrUJk Y=; IronPort-PHdr: =?us-ascii?q?9a23=3Asrd+jB0EevGGvlGWsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFvadmi1rRQJnW8bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGE8H7f0DOr2f06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKEgCTANVe/5NdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgVBSB29YLywKhBuDRgOLFoIsmEyCUgN?= =?us-ascii?q?VCwEBAQwBASUIAgQBAYREAhc1AQSBVAIkOBMCAwEBCwEBBQEBAQIBBgRthVk?= =?us-ascii?q?MgimDSQEBAQEDEhERDAEBNwELBAIBCBEEAQEBAgImAgICMBUICAIEDgUIGoM?= =?us-ascii?q?FgksDLgEOolUCgTmIYXaBMoMBAQEFhRMYgg4JgQ4qgmSJPSYagUE/gRFDgk0?= =?us-ascii?q?+gQSBGkkBAQEBgWWDEjOCLY5qglA8oV0KgleZDYJmmzKSPZhugy4CBAIEBQI?= =?us-ascii?q?OAQEFgWoigSUbDwdwFRoXD3sdgRgBAQEIKQlHFwINkECDcoRZO4VCdAI1AgY?= =?us-ascii?q?IAQEDCXyLYwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,460,1583193600"; d="scan'208";a="685998615" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 13:24:00 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 051DO0g0011819 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Jun 2020 13:24:00 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 08:24:00 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 08:23:59 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Jun 2020 09:23:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SAkb0DnN27wESnWpV3kc6FR8ii0Hawtbh7INYmAxa69cm/bQQaOPgV+gSmyDuh8Ejh8FozKWfv/iaoLI2WOaIxfeqM2/IONXaXuvA/YHilgXE+TNyf1ZcjJ7HRlzbT7a8lMIboo0lstto+YKmfidrUhhR2oJgQXpDgApLMCoEjGLZUMVWUjqXLAqzI0NHgMq48A7TbgOpY/dlMNmXIwKcALqw0m4VAlXVtrk2N89W6Esu0U1s6Jqgl+OL7+huEWXWzl7B6CbBaCWiaySR3P4vgPAzbRAMSxFyjeeWmE7xulv2NsYVnmvXr5wTJR8U2TTtIygCA3E1wmqU4SXUSnCSQ== 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=U+j3EdO5RgwgR9poknD9BnGi9XE1WAOWOvYGUiOoNO8=; b=dO6fXMCsnRBWHUGExwPVOqC11NqYjMzbcxUENfApkaQ1cfUiLW8fuiXSJMM2TlEkBLPpTfq+oc5tz4BNPtmvjuzxa0potfImkYr4OhZ8i93e9aYRdxWhFIrh/LvU2y41Xha+MkO5qYaEjEz9IgkuOtCaKbLzh+lVegh+IW2UVQfH71/45uTpvdwjdmQoscGF7PTWh3UK3Lbxgty1HAidaA3MDRQUv9Gjw/DcdrcNbptWv7IoiGE5JCJ7x4mJ+Enb026gF88Dfpcq4iUAQYeOfh+Qhgj1pBZSFT/R1/TlMaougOADrRJ/EsRuHzi7Vh4fELWQ5yyVh86/vdKRV3RdQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+j3EdO5RgwgR9poknD9BnGi9XE1WAOWOvYGUiOoNO8=; b=tJ5eLj00mv0kgnRJ0tc/vqsaDVZ0pJQlWUjyvk3hUDaZCazP31ckpVSK4CWVAqlMMXgL7kmavs2kZDgLgengz+8LPqNUZH16ZZs7ftenlpONJ6XMLAktM6Eu85vc3FvQ56Bfk2wbhfq4Woo8Zd07EjbJDplgtkV10N3UQCbhz6A= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4661.namprd11.prod.outlook.com (2603:10b6:208:26b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Mon, 1 Jun 2020 13:23:58 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3045.024; Mon, 1 Jun 2020 13:23:58 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba CC: Benjamin Kaduk , Pete Resnick , "mbj@microsoft.com" , "iesg@ietf.org" , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" , "oauth@ietf.org" , "RFC Errata System" Thread-Topic: [Errata Verified] RFC7800 (6187) Thread-Index: AQHWNuulQReviV4PKkaVPVtDH4tsaqjBkK2AgAAEBACAAhv7EIAADyMAgAAAtuA= Date: Mon, 1 Jun 2020 13:23:58 +0000 Message-ID: References: <20200531013404.4528BF40721@rfc-editor.org> <20200531040924.GM58497@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 681fe323-b838-49d7-8586-08d8062f0a8b x-ms-traffictypediagnostic: MN2PR11MB4661: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BG92FEcWldduMK4VZ7fdfg5payoUeuL0piHed+Zq9YhJ0ztwoeUNAlf/yJRtHpzN0REjHG05gldWy7wrvxDHM8B5r5W2k9hQqZfwmb5i77yJ85vNETzISdwYkY/pekNhdZ21n1goH0dOru4cjTDmZDdKaVX52kknA5iuaLKi3w1dl8wupNyXS7CuMZLN2spRm4/8qhMOeOo7Mb+q03YpJy7S+nJ2u1XcDUEK1krjZ7vzlCaq3YMcnJsIpr7aO/BYYwrV5GYsjrJFlc3Kv059n8tX4VaCca7357OYcEPkT/RRhuCCtL1iOKAbTe/z+sCxJs++pjri9bq2tAkWGs+gwdx2UXALMLPdQaK1DrgEbzrLcwbLxi+fZeDqrofAtimB35jc7phd11sgR057losslA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(366004)(136003)(346002)(86362001)(2906002)(83380400001)(66476007)(15650500001)(26005)(53546011)(6506007)(66946007)(76116006)(478600001)(9686003)(966005)(71200400001)(52536014)(54906003)(66446008)(45080400002)(316002)(8676002)(5660300002)(186003)(55016002)(66556008)(33656002)(7696005)(64756008)(6916009)(8936002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ebTBX1p54jllt8B7VyvlQgMLi2tlYDySeh3F2mpUl6TZJTEYsLwXtBnE0Xp/Jj96z6OPU9S32dow+6to1sb+QTX5n5/5jSyzyNpgGOf5RwpHLRU5lfnNVmfSIVNPBOOyn7Meob5UgN8H3cSormf+HEsaRyQuwmnAzZ0I1E994CqPSocs/GKaJs/EldFeghAgSDe3gu9zNGlb1DCJsp+t88b9p5ACW71R+Ye509/hO27vu6numcBwjp5w+uNNh7jDG0SA6QUWckRZ4E54JUjSyM2Z2zS1WmCORh3OX8EUKE+tTb1fHZEOlh72OmF5qS8/QfkvumwtDUOjH4o4ZEGJp5SOwMrTtt0XWdtn1Pb6AeruelrCnE0vAoo5xAB9pIr4rmqNYugZ8M7DpfxTUM4atKNhaaH+QlAwJ1XsXtSAwp5bKELgaPb5RI+v5qF4E0UxX8V8tvPSeNEcJg3p3XyQ6BC9J3D5OoJypLr+FIbsq7U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 681fe323-b838-49d7-8586-08d8062f0a8b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 13:23:58.1391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5Drp+3b1ccw7gpW5YpstUGdV/VTZAJkSRuzVdUDVKH1uD0sj0SQp4ixWr/mnDbrnSk8NKq2pkMkaKVbdBWoAkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4661 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:24:12 -0000 T2theSwgc28gdGhlIGRpc3RpbmN0aW9uIGlzIGFscmVhZHkgdGhlcmUuDQoNCkFzIHRoZSBlcnJh dGEgcnVsZXMgYXJlIHdyaXR0ZW4gdGhlbiBJIHdvdWxkIGhhdmUgZG9uZSB0aGUgc2FtZSBhcyBQ ZXRlIHN1Z2dlc3RlZCBhbmQgbWFya2VkIHRoaXMgYXMgSEZEVSB1bmRlciBwb2ludCAoMikgb2Yg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYWJvdXQvZ3JvdXBzL2llc2cvc3RhdGVtZW50cy9wcm9jZXNz aW5nLXJmYy1lcnJhdGEvLg0KDQpIb3dldmVyLCBJIGFsc28gdGFrZSBCZW4ncyBwb2ludCB0aGF0 IGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB0aGlzIGVycmF0YSBzaG93ZWQgdXAgaW5saW5lIChhcyBw ZXIgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL2lubGluZS1lcnJhdGEvcmZjNzgwMC5o dG1sKSwgd2hpY2ggaXMgd2h5IEkgdGhpbmsgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGNoYW5nZSB0 aGUgZ3VpZGFuY2UgZm9yIHBvaW50ICgyKSBzbyB0aGF0IHRoZXkgYmVjb21lIHZlcmlmaWVkIChl ZGl0b3JpYWwpIHJhdGhlciB0aGFuIEhGRFUuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNv bXB1dGVyLm9yZz4NCj4gU2VudDogMDEgSnVuZSAyMDIwIDE0OjE2DQo+IFRvOiBSb2IgV2lsdG9u IChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+IENjOiBCZW5qYW1pbiBLYWR1ayA8a2Fk dWtAbWl0LmVkdT47IFBldGUgUmVzbmljayA8cmVzbmlja0BlcGlzdGVtZS5uZXQ+Ow0KPiBtYmpA bWljcm9zb2Z0LmNvbTsgaWVzZ0BpZXRmLm9yZzsgdmU3anRiQHZlN2p0Yi5jb207DQo+IEhhbm5l cy5Uc2Nob2ZlbmlnQGdteC5uZXQ7IG9hdXRoQGlldGYub3JnOyBSRkMgRXJyYXRhIFN5c3RlbSA8 cmZjLQ0KPiBlZGl0b3JAcmZjLWVkaXRvci5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbRXJyYXRhIFZl cmlmaWVkXSBSRkM3ODAwICg2MTg3KQ0KPiANCj4gVGhhdCdzIHdoYXQgdGhlICJ0ZWNobmljYWwi IHZzICJlZGl0b3JpYWwiIGRpc3RpbmN0aW9uIGlzIHN1cHBvc2VkIHRvIGJlDQo+IGZvci4NCj4g DQo+IEJhcnJ5DQo+IA0KPiBPbiBNb24sIEp1biAxLCAyMDIwIGF0IDg6MjcgQU0gUm9iIFdpbHRv biAocndpbHRvbikNCj4gPHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3Rl Og0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ IEZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJlbmphbWlu IEthZHVrDQo+ID4gPiBTZW50OiAzMSBNYXkgMjAyMCAwNTowOQ0KPiA+ID4gVG86IFBldGUgUmVz bmljayA8cmVzbmlja0BlcGlzdGVtZS5uZXQ+DQo+ID4gPiBDYzogbWJqQG1pY3Jvc29mdC5jb207 IGllc2dAaWV0Zi5vcmc7IHZlN2p0YkB2ZTdqdGIuY29tOw0KPiA+ID4gSGFubmVzLlRzY2hvZmVu aWdAZ214Lm5ldDsgb2F1dGhAaWV0Zi5vcmc7IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtDQo+ID4g PiBlZGl0b3JAcmZjLWVkaXRvci5vcmc+DQo+ID4gPiBTdWJqZWN0OiBSZTogW0VycmF0YSBWZXJp ZmllZF0gUkZDNzgwMCAoNjE4NykNCj4gPiA+DQo+ID4gPiBUaGUgbmV3IHRleHQgaXMgY2xlYXJs eSB0aGUgcmlnaHQgdGhpbmcsIGFuZCB0aGVyZSBpcyBubyBuZWVkDQo+ID4gPiB0byBkZWJhdGUg aXQgaWYvd2hlbiB0aGUgZG9jdW1lbnQgZ2V0cyB1cGRhdGVkLiAgIkRvbid0IGhvbGQNCj4gPiA+ IGl0OyBkbyBpdCBub3ciLCBzbyB0byBzcGVhayAtLSBhbmQgbm90aW5nIHRoYXQgKG15DQo+ID4g PiB1bmRlcnN0YW5kaW5nL3JlY29sbGVjdGlvbiBvZikgdGhlIHBsYW4gZm9yDQo+ID4gPiBodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvaW5saW5lLWVycmF0YS9yZmM3ODAwLmh0bWwgaXMg dGhhdCBvbmx5DQo+ID4gPiB2ZXJpZmllZCBlcnJhdGEsIG5vdCB0aG9zZSBpbiBvdGhlciBzdGF0 ZXMsIHdpbGwgYmUgZGlzcGxheWVkLg0KPiA+IFtSV10NCj4gPg0KPiA+IElmIHRoaXMgZW5kcyB1 cCBiZWluZyB0aGUgcGxhbiwgdGhlbiBJIHRoaW5rIHRoYXQgd2UgbWF5IHdpc2ggdG8gbW9kaWZ5 DQo+IHRoZSBSRkMgZ3VpZGFuY2UsIG9yIHBvc3NpYmx5IGhhdmUgdHdvIGRpZmZlcmVudCB2ZXJp ZmllZCBzdGF0ZXM6DQo+ID4gIChpKSBWZXJpZmllZCwgY291bGQgaW1wYWN0IGltcGxlbWVudGF0 aW9ucw0KPiA+ICAoaWkpIFZlcmlmaWVkLCBlZGl0b3JpYWwgb25seS4NCj4gPg0KPiA+IENlcnRh aW5seSwgaXQgc2VlbXMgdG8gYmUgbWFrZXMgc2Vuc2UgZm9yIHRoZXNlIHNvcnRzIG9mIGVycmF0 YSB0byBiZQ0KPiBkaXNwbGF5ZWQuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFJvYg0KPiA+DQo+ ID4NCj4gPiA+DQo+ID4gPiAoWWVzLCB0aGF0IGxpbmsgNDA0cyBhdCB0aGUgbW9tZW50LCBJIGFz c3VtZSBhIGNhY2hpbmcgaXNzdWUuKQ0KPiA+ID4NCj4gPiA+IC1CZW4NCj4gPiA+DQo+ID4gPiBP biBTYXQsIE1heSAzMCwgMjAyMCBhdCAxMDo1NTowMVBNIC0wNTAwLCBQZXRlIFJlc25pY2sgd3Jv dGU6DQo+ID4gPiA+ICJWZXJpZmllZCIsIG5vdCAiSG9sZCBGb3IgRG9jdW1lbnQgVXBkYXRlIj8N Cj4gPiA+ID4NCj4gPiA+ID4gcHINCj4gPiA+ID4NCj4gPiA+ID4gT24gMzAgTWF5IDIwMjAsIGF0 IDIwOjM0LCBSRkMgRXJyYXRhIFN5c3RlbSB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGUg Zm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gdmVyaWZpZWQgZm9yIFJGQzc4MDAsDQo+ ID4gPiA+ID4gIlByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3IgSlNPTiBXZWIg VG9rZW5zIChKV1RzKSIuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQg YmVsb3cgYW5kIGF0Og0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0 YS9laWQ2MTg3DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+IFN0YXR1czogVmVyaWZpZWQNCj4gPiA+ID4gPiBUeXBl OiBFZGl0b3JpYWwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFJlcG9ydGVkIGJ5OiBQZXRlIFJlc25p Y2sgPHJlc25pY2tAZXBpc3RlbWUubmV0Pg0KPiA+ID4gPiA+IERhdGUgUmVwb3J0ZWQ6IDIwMjAt MDUtMjYNCj4gPiA+ID4gPiBWZXJpZmllZCBieTogQmVuamFtaW4gS2FkdWsgKElFU0cpDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uOiA3LjENCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9yaWdp bmFsIFRleHQNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gICAgW0pXS10gICAg ICBKb25lcywgTS4sICJKU09OIFdlYiBLZXkgKEpXSykiLCBSRkMgNzUxNywNCj4gPiA+ID4gPiAg ICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MTU3LCBNYXkgMjAxNSwNCj4gPiA+ID4gPiAg ICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzUxNz4uDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENvcnJlY3RlZCBUZXh0DQo+ID4gPiA+ID4g LS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiAgICBbSldLXSAgICAgIEpvbmVzLCBNLiwgIkpTT04g V2ViIEtleSAoSldLKSIsIFJGQyA3NTE3LA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgRE9JIDEw LjE3NDg3L1JGQzc1MTcsIE1heSAyMDE1LA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgPGh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NTE3Pi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gTm90ZXMNCj4gPiA+ID4gPiAtLS0tLQ0KPiA+ID4gPiA+IERPSSBoYXMgYSB0 eXBvOiA3MTU3IGluc3RlYWQgb2YgNzUxNy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gUkZDNzgwMCAoZHJhZnQt aWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTExKQ0KPiA+ID4gPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gVGl0bGUgICAgICAgICAgICAg ICA6IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3IgSlNPTg0KPiBXZWINCj4g PiA+ID4gPiBUb2tlbnMgKEpXVHMpDQo+ID4gPiA+ID4gUHVibGljYXRpb24gRGF0ZSAgICA6IEFw cmlsIDIwMTYNCj4gPiA+ID4gPiBBdXRob3IocykgICAgICAgICAgIDogTS4gSm9uZXMsIEouIEJy YWRsZXksIEguIFRzY2hvZmVuaWcNCj4gPiA+ID4gPiBDYXRlZ29yeSAgICAgICAgICAgIDogUFJP UE9TRUQgU1RBTkRBUkQNCj4gPiA+ID4gPiBTb3VyY2UgICAgICAgICAgICAgIDogV2ViIEF1dGhv cml6YXRpb24gUHJvdG9jb2wNCj4gPiA+ID4gPiBBcmVhICAgICAgICAgICAgICAgIDogU2VjdXJp dHkNCj4gPiA+ID4gPiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPiA+ID4gPiA+IFZlcmlm eWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tDQo+ID4g PiA+IFBldGUgUmVzbmljayBodHRwczovL3d3dy5lcGlzdGVtZS5uZXQvDQo+ID4gPiA+IEFsbCBj b25uZWN0aW9ucyB0byB0aGUgd29ybGQgYXJlIHRlbnVvdXMgYXQgYmVzdA0KPiA+DQo= From nobody Mon Jun 1 06:55:32 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0523A1088; Mon, 1 Jun 2020 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H+qM1RV2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TIRUjJsx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06dcJzEtAuLD; Mon, 1 Jun 2020 06:55:22 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1743A1086; Mon, 1 Jun 2020 06:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8606; q=dns/txt; s=iport; t=1591019722; x=1592229322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZsONauRMpu8T0y4rFxFFqUUVAHiWEYl7rVq9SpLttSU=; b=H+qM1RV2GS/qfSSOWG1QFFfuypIW+2EvFK2UQUvPjWzPOFQyrb86YuzM vZ1uvN6ABweKcx+w8q0VAorjhCS5nEL3IgsIaRUSIEZ+HISoa5R8KEsq1 NS0nQboRkJ2eDtZGHAFrkDdmha0VqEfEpvfqvNtenDfVzWq2xWlRsCuhf E=; IronPort-PHdr: =?us-ascii?q?9a23=3AsBTL5xwkTKT3W3/XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaHt/5qiUfUQYjBrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteH8PmekHfuDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAABsB9Ve/5FdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgVBSB29YLywKhBuDRgONQ5hMglIDVQs?= =?us-ascii?q?BAQEMAQEjCgIEAQGERAIXgg4CJDgTAgMBAQsBAQUBAQECAQYEbYVZDIVyAQE?= =?us-ascii?q?BAQIBEhERDAEBNwELBAIBCBEEAQEBAgImAgICMBUICAIEDgUIGoMFgksDDiA?= =?us-ascii?q?BDqJyAoE5iGF2gTKDAQEBBYUfGIIOCYEOKoJkiWMagUE/gRFDgk0+gQSBGkk?= =?us-ascii?q?DAYFlgxIzgi2OZgSCUDyRNJApCoJXmQ2CZpsykj2YboMuAgQCBAUCDgEBBYF?= =?us-ascii?q?qIoFADwdwFRoXD3sdgSMpCUcXAg2QQINyhFk7hUJ0AjUCBggBAQMJfItjAYE?= =?us-ascii?q?PAQE?= X-IronPort-AV: E=Sophos;i="5.73,461,1583193600"; d="scan'208";a="505441864" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jun 2020 13:55:21 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 051DtLUF002916 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Jun 2020 13:55:21 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 08:55:21 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 08:55:20 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Jun 2020 09:55:20 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=doU/kNzqkZvmbgq9x+j8fj4HOlqzhwWnvWBFC/q/6xys0HI4ANqknBCzN/XA8Pu4jICJlsg0cKW2IGVYF97ar6P42QZn0xhu5/ddEdYJ01qR6BM8CHLIZAgXkcZLOFDfWAx/ZIgBJ2iP8wEaWERFPxoIEt+6nFdNgLUIoaJw5/IYqx+2ncBFx3rlmTdg9v1rfskNMv6CdPNNmgEluo82+po4x6wD7XZXYMvzqHwR65ukAHEwde9KMwUYj3qKpyxx/U57HOgGlqC6ZyA3ZTbKdbh0uTJ2R1SQXPYDdHdL9NBTU29YqXViXvpJIhlxsOfqhkVk954XHP/ewUQEyDF6OA== 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=ZsONauRMpu8T0y4rFxFFqUUVAHiWEYl7rVq9SpLttSU=; b=X1gqxGtSHBMuLU4IqR1c5OI5DwOzWQvDeJY5t+GwUtL+LfpKxKgxII4suwOCV9QHTNQhFXpGB2NouhS+2bIpMGUcFFalCDqkQcJd7IPOldg1fq1EJ9H2VlhthUHy/1qSptbtLRi2+u0dgcanOELMqf+KIGMyU8KrpADIYqZJA4YxNJjE8sSz8v8yy9/x7iVbrFFCDlg2imPj8kDaB1dMwZnVNFRZJQfQDvKQhZDx8e4lxdRF58xtA1UNRUnyCERE2VtdeAKsPfF8aoOSX90xGf1hkERuMlbB5bDHDfjH44xxxv9TkMlQWjL7P182sqm3LWzjdAPqXzL33ZQVutwaXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZsONauRMpu8T0y4rFxFFqUUVAHiWEYl7rVq9SpLttSU=; b=TIRUjJsxmWOph1ebleydnOlw5IukR8YYysiuB0OfEyyGrQujk6iSX8v0DxDlYagwxS9emC3TdXozr6Czz3AGf9ljkM88PYX3nh8a1474p6RqEaPXi6ME9uH+uKAhcwX2pXTTH49yxQEtD313S0oxzTzsyat/CGTle4Fwz5Tycfs= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4062.namprd11.prod.outlook.com (2603:10b6:208:150::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.21; Mon, 1 Jun 2020 13:55:19 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3045.024; Mon, 1 Jun 2020 13:55:18 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba CC: RFC Errata System , "mbj@microsoft.com" , Benjamin Kaduk , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" , "oauth@ietf.org" , Pete Resnick , "iesg@ietf.org" Thread-Topic: [Errata Verified] RFC7800 (6187) Thread-Index: AQHWNuulQReviV4PKkaVPVtDH4tsaqjBkK2AgAAEBACAAhv7EIAADyMAgAACDoCAAAINQA== Date: Mon, 1 Jun 2020 13:55:18 +0000 Message-ID: References: <20200531013404.4528BF40721@rfc-editor.org> <20200531040924.GM58497@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2e5632f-8590-4889-2a57-08d806336b82 x-ms-traffictypediagnostic: MN2PR11MB4062: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B9HQnqWJliaSI1ZOTNm+05yqNRwtVn7FarKQ2Kqn/H9I4VwOu8u5XiExMa9GcUeVvZ4eSJRhbXxuPYNX//FLsD3C81iHF8CmuuAcygPqFKMLf+Q+48IooybdttXe2LeOFUZrMVwBwZCnVDS875dfPnfSX2nWUnGNQhgOpPnbRJ4ePorWIa/GUsIWiunCoQV7zAcAvA3JW1JD2cRpY+g+XbekH35uYGw5yHwMuCXGiVUsy2SitWUi1OLwDqDDtV49Z31GOXw5MbSPp5BoKUc47n3t8W8te/gf/163IXC0OxvMcG6pI7t0V+t/urUOIv9vO2lty8/mri7g7ZytYg5LBQVbBsJpWYS2vB9hECtE82eAE5avLgQyHGtLIRf41uKtFnz4RDALQ9vcaQAs1pl87Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(71200400001)(33656002)(186003)(6916009)(478600001)(316002)(7696005)(52536014)(966005)(15650500001)(86362001)(54906003)(5660300002)(83380400001)(4326008)(76116006)(8676002)(8936002)(66476007)(2906002)(6506007)(55016002)(66556008)(64756008)(45080400002)(26005)(66446008)(66946007)(53546011)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Vasrum7CdLggb4EFjEwDkvFxB5P/ipehmux4CAJmYmUxQdxQKx7xSGUk8etiMifkjvCY9ooUMZww4EXoGxeA9dkCKE++cii9ylDcZcmYgp8AOUasfMBqfB0B3IxoEw9OUcO00Lc/VcOO/7zBB43u8086i9SWkXO6ciEaudq/2nrjik8aNuyjRPorcGOT/L3UtQa1gnm7p9g1flsLYvw3LOSKQAtYA+y4BcdrR28qOsR7mmX6IgZhi9MfOeSH3jplatr/5gSbotNPVWkFY9j60N3diFryNSLrbt4tvOkMbgboXBJ6VXbUSpj4WwT6GLxBjKJxg7CvbFxAFGuDNZgtUnDzeIu/yOo23PWkgZB0IygvOzSGvLwX2ng/vEy1XA4+tJKd+px4e/foVlkIIm2XqtGXY0y9Ms0spqg57vt2QxwHVPp1c2d1zHOBxqS/yNPPahnfx9bwFAHuY3+K3amg/2aI00rSP9K91TsdCyZz/SY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2e5632f-8590-4889-2a57-08d806336b82 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 13:55:18.7867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aLsWD80YBYkpIvDcCXGFXru6mDWoeIuldOU2WBN6V3z7ZlHUclFSJyVny79PTC12JmmdnyUcxZ4ekI1rLIr2gg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4062 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:55:26 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQmFycnkgTGVpYmENCj4gU2VudDogMDEgSnVuZSAy MDIwIDE0OjI0DQo+IFRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbj00MGNpc2NvLmNv bUBkbWFyYy5pZXRmLm9yZz4NCj4gQ2M6IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnPjsgbWJqQG1pY3Jvc29mdC5jb207DQo+IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1PjsgdmU3anRiQHZlN2p0Yi5jb207DQo+IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u ZXQ7IG9hdXRoQGlldGYub3JnOyBQZXRlIFJlc25pY2sNCj4gPHJlc25pY2tAZXBpc3RlbWUubmV0 PjsgaWVzZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0VycmF0YSBWZXJpZmllZF0gUkZDNzgw MCAoNjE4NykNCj4gDQo+IEZ1cnRoZXIgb24gdGhpczoNCj4gDQo+IEluIHRoZSAiZWRpdG9yaWFs IiByZWFsbSwgdGhlcmUgYXJlIHR3byBjbGFzc2VzIG9mICJjb3JyZWN0IiBlcnJhdGENCj4gcmVw b3J0czoNCj4gDQo+IDEuIFRyaXZpYWwgYW5kIG9idmlvdXMgdHlwb3MsIHN1Y2ggYXMgc3BlbGxp bmcgImFuZCIgYXMgImFkbiIuDQo+IA0KPiAyLiBPdGhlcnMsIHN1Y2ggYXMgYSBudW1iZXIgd2l0 aCB0cmFuc3Bvc2VkIGRpZ2l0cywgd2hpY2ggY291bGQsDQo+IGluZGVlZCwgYmUgY29uZnVzaW5n Lg0KW1JXXSANCg0KVGhpcyBzZWVtcyBlbnRpcmVseSByZWFzb25hYmxlLg0KDQo+IA0KPiBUaGUg Z3VpZGVsaW5lIHRoYXQgd2UncmUgZGlzY3Vzc2luZyBpcyBtZWFudCB0byBzZXBhcmF0ZSB0aG9z ZSBvdXQsDQo+IHNheWluZyB0aGF0IGNsYXNzIDEgc2hvdWxkIGdvIHRvIEhGRFUsIHdoaWxlIGNs YXNzIDIgbWlnaHQgcXVhbGlmeSBhcw0KPiBWZXJpZmllZC4gIFdoZXRoZXIgYSBwYXJ0aWN1bGFy IHJlcG9ydCBmYWxscyBpbnRvIGNsYXNzIDEgb3IgMiBpcw0KPiB1c3VhbGx5IGNsZWFyLCBidXQg c29tZXRpbWVzIGEgbWF0dGVyIG9mIGp1ZGdtZW50LiAgQW5kIHRoZW4gd2hldGhlciBhDQo+IGNs YXNzIDIgcmVwb3J0IHJhdGVzIFZlcmlmaWVkIG9yIEhGRFUgaXMgYWxzbyBzb21ldGltZXMgYSBt YXR0ZXIgb2YNCj4ganVkZ21lbnQuICBJJ20gcGVyc29uYWxseSBoYXBweSB3aXRoIGxlYXZpbmcg dGhhdCB0byBqdWRnbWVudCwgcmF0aGVyDQo+IHRoYW4gdHJ5aW5nIHRvIGJlIG92ZXJseSByaWdv cm91cyBhYm91dCBtYWtpbmcgcnVsZXMgZm9yIGl0LiAgSSdtIGFsc28NCj4gaGFwcHkgd2l0aCB0 aGUgaWRlYSBvZiBjbGFyaWZ5aW5nIG9yIGFsdGVyaW5nIHRoZSBndWlkZWxpbmVzLCBpZg0KPiBz b21lb25lIHdhbnRzIHRvIG1ha2UgYSBzcGVjaWZpYyBwcm9wb3NhbC4NCltSV10gDQoNClBlcnNv bmFsbHksIGF0IGxlYXN0IGZvciBuZXcgQURzLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgcHJvYmFi bHkgYmUgdXNlZnVsIHRvIGNsYXJpZnkgdGhlIGd1aWRlbGluZXMuDQoNCkkgY291bGQgcHJvcG9z ZSBzb21lIHRleHQsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIGZpcnN0IHF1ZXN0aW9uIHRvIGFuc3dl ciByZWFsbHkgcmVsYXRlcyB0byB0aGUgaW5saW5lLWVycmF0YSBvdXRwdXQuICBJdCB3b3VsZCBi ZSBuaWNlIGlmIHNwZWxsaW5nIGFuZCBncmFtbWF0aWNhbCBtaXN0YWtlcyB3ZXJlIGluY2x1ZGVk IGluIHRoZSBpbmxpbmUtZXJyYXRhLCBzaW5jZSB0aGVyZSBzZWVtcyB0byBiZSBubyBnb29kIHJl YXNvbiB3aHkgdGhleSBzaG91bGQgbm90IGJlIGFuZCB0aGV5IG1heSBiZSBoZWxwZnVsIHRvIGEg bm9uLW5hdGl2ZSBzcGVha2VyLiAgSWYgb25seSAidmVyaWZpZWQiIGVycmF0YSBjYW4gYmUgaW5j bHVkZWQgaW5saW5lIHRoZW4gaXQgbWlnaHQgYmUgYW4gaWRlYSB0byBjbGFzc2lmeSB0aGVzZSBh cyBzb21ldGhpbmcgbGlrZSAidmVyaWZpZWQsIGluY29uc2VxdWVudGlhbCIuDQoNClRoYW5rcywN ClJvYg0KDQoNCj4gDQo+IE9uZSB0aGluZyB3ZSBoYXZlIHRhbGtlZCBhYm91dCBpcyBoYXZpbmcg dGhlIFJQQyBoYW5kbGUgZWRpdG9yaWFsDQo+IGNsYXNzIDEgcmVwb3J0cywgYW5kIHdlIGNhbiBk aXNjdXNzIHRoYXQgYWdhaW4gaWYgd2UgbGlrZS4gIFNob3VsZCB3ZQ0KPiBkbyB0aGF0LCBpdCBt aWdodCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBzZXBhcmF0ZSBoYW5kbGluZyBjb2RlIGZvcg0KPiB0 aG9zZSB0aGF0IHRoZSBSUEMgcmVzb2x2ZXMuDQo+IA0KPiBCYXJyeQ0KPiANCj4gT24gTW9uLCBK dW4gMSwgMjAyMCBhdCA5OjE2IEFNIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9y Zz4NCj4gd3JvdGU6DQo+ID4NCj4gPiBUaGF0J3Mgd2hhdCB0aGUgInRlY2huaWNhbCIgdnMgImVk aXRvcmlhbCIgZGlzdGluY3Rpb24gaXMgc3VwcG9zZWQgdG8gYmUNCj4gZm9yLg0KPiA+DQo+ID4g QmFycnkNCj4gPg0KPiA+IE9uIE1vbiwgSnVuIDEsIDIwMjAgYXQgODoyNyBBTSBSb2IgV2lsdG9u IChyd2lsdG9uKQ0KPiA+IDxyd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+ID4gRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgQmVuamFtaW4gS2FkdWsNCj4gPiA+ID4gU2VudDogMzEgTWF5IDIwMjAgMDU6MDkNCj4gPiA+ ID4gVG86IFBldGUgUmVzbmljayA8cmVzbmlja0BlcGlzdGVtZS5uZXQ+DQo+ID4gPiA+IENjOiBt YmpAbWljcm9zb2Z0LmNvbTsgaWVzZ0BpZXRmLm9yZzsgdmU3anRiQHZlN2p0Yi5jb207DQo+ID4g PiA+IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ7IG9hdXRoQGlldGYub3JnOyBSRkMgRXJyYXRh IFN5c3RlbSA8cmZjLQ0KPiA+ID4gPiBlZGl0b3JAcmZjLWVkaXRvci5vcmc+DQo+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbRXJyYXRhIFZlcmlmaWVkXSBSRkM3ODAwICg2MTg3KQ0KPiA+ID4gPg0KPiA+ ID4gPiBUaGUgbmV3IHRleHQgaXMgY2xlYXJseSB0aGUgcmlnaHQgdGhpbmcsIGFuZCB0aGVyZSBp cyBubyBuZWVkDQo+ID4gPiA+IHRvIGRlYmF0ZSBpdCBpZi93aGVuIHRoZSBkb2N1bWVudCBnZXRz IHVwZGF0ZWQuICAiRG9uJ3QgaG9sZA0KPiA+ID4gPiBpdDsgZG8gaXQgbm93Iiwgc28gdG8gc3Bl YWsgLS0gYW5kIG5vdGluZyB0aGF0IChteQ0KPiA+ID4gPiB1bmRlcnN0YW5kaW5nL3JlY29sbGVj dGlvbiBvZikgdGhlIHBsYW4gZm9yDQo+ID4gPiA+IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L3JmYy9pbmxpbmUtZXJyYXRhL3JmYzc4MDAuaHRtbCBpcyB0aGF0DQo+IG9ubHkNCj4gPiA+ID4g dmVyaWZpZWQgZXJyYXRhLCBub3QgdGhvc2UgaW4gb3RoZXIgc3RhdGVzLCB3aWxsIGJlIGRpc3Bs YXllZC4NCj4gPiA+IFtSV10NCj4gPiA+DQo+ID4gPiBJZiB0aGlzIGVuZHMgdXAgYmVpbmcgdGhl IHBsYW4sIHRoZW4gSSB0aGluayB0aGF0IHdlIG1heSB3aXNoIHRvDQo+IG1vZGlmeSB0aGUgUkZD IGd1aWRhbmNlLCBvciBwb3NzaWJseSBoYXZlIHR3byBkaWZmZXJlbnQgdmVyaWZpZWQgc3RhdGVz Og0KPiA+ID4gIChpKSBWZXJpZmllZCwgY291bGQgaW1wYWN0IGltcGxlbWVudGF0aW9ucw0KPiA+ ID4gIChpaSkgVmVyaWZpZWQsIGVkaXRvcmlhbCBvbmx5Lg0KPiA+ID4NCj4gPiA+IENlcnRhaW5s eSwgaXQgc2VlbXMgdG8gYmUgbWFrZXMgc2Vuc2UgZm9yIHRoZXNlIHNvcnRzIG9mIGVycmF0YSB0 byBiZQ0KPiBkaXNwbGF5ZWQuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFJvYg0KPiA+ ID4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IChZZXMsIHRoYXQgbGluayA0MDRzIGF0IHRoZSBt b21lbnQsIEkgYXNzdW1lIGEgY2FjaGluZyBpc3N1ZS4pDQo+ID4gPiA+DQo+ID4gPiA+IC1CZW4N Cj4gPiA+ID4NCj4gPiA+ID4gT24gU2F0LCBNYXkgMzAsIDIwMjAgYXQgMTA6NTU6MDFQTSAtMDUw MCwgUGV0ZSBSZXNuaWNrIHdyb3RlOg0KPiA+ID4gPiA+ICJWZXJpZmllZCIsIG5vdCAiSG9sZCBG b3IgRG9jdW1lbnQgVXBkYXRlIj8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IHByDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBPbiAzMCBNYXkgMjAyMCwgYXQgMjA6MzQsIFJGQyBFcnJhdGEgU3lzdGVtIHdy b3RlOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQg aGFzIGJlZW4gdmVyaWZpZWQgZm9yIFJGQzc4MDAsDQo+ID4gPiA+ID4gPiAiUHJvb2Ytb2YtUG9z c2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKU09OIFdlYiBUb2tlbnMgKEpXVHMpIi4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+ID4gPiA+ID4gWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+ ID4gPiA+ID4gPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjE4Nw0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPiA+ID4gPiBTdGF0dXM6IFZlcmlmaWVkDQo+ID4gPiA+ID4gPiBUeXBlOiBFZGl0 b3JpYWwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBSZXBvcnRlZCBieTogUGV0ZSBSZXNuaWNr IDxyZXNuaWNrQGVwaXN0ZW1lLm5ldD4NCj4gPiA+ID4gPiA+IERhdGUgUmVwb3J0ZWQ6IDIwMjAt MDUtMjYNCj4gPiA+ID4gPiA+IFZlcmlmaWVkIGJ5OiBCZW5qYW1pbiBLYWR1ayAoSUVTRykNCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTZWN0aW9uOiA3LjENCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiBPcmlnaW5hbCBUZXh0DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4g PiAgICBbSldLXSAgICAgIEpvbmVzLCBNLiwgIkpTT04gV2ViIEtleSAoSldLKSIsIFJGQyA3NTE3 LA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNzE1NywgTWF5IDIw MTUsDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjNzUxNz4uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IENv cnJlY3RlZCBUZXh0DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gICAg W0pXS10gICAgICBKb25lcywgTS4sICJKU09OIFdlYiBLZXkgKEpXSykiLCBSRkMgNzUxNywNCj4g PiA+ID4gPiA+ICAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc1MTcsIE1heSAyMDE1LA0K PiA+ID4gPiA+ID4gICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzc1MTc+Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBOb3Rlcw0K PiA+ID4gPiA+ID4gLS0tLS0NCj4gPiA+ID4gPiA+IERPSSBoYXMgYSB0eXBvOiA3MTU3IGluc3Rl YWQgb2YgNzUxNy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gUkZDNzgwMCAoZHJhZnQtaWV0Zi1vYXV0 aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTExKQ0KPiA+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiA+IFRpdGxlICAgICAgICAgICAgICAgOiBQ cm9vZi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpTT04NCj4gV2ViDQo+ID4gPiA+ ID4gPiBUb2tlbnMgKEpXVHMpDQo+ID4gPiA+ID4gPiBQdWJsaWNhdGlvbiBEYXRlICAgIDogQXBy aWwgMjAxNg0KPiA+ID4gPiA+ID4gQXV0aG9yKHMpICAgICAgICAgICA6IE0uIEpvbmVzLCBKLiBC cmFkbGV5LCBILiBUc2Nob2ZlbmlnDQo+ID4gPiA+ID4gPiBDYXRlZ29yeSAgICAgICAgICAgIDog UFJPUE9TRUQgU1RBTkRBUkQNCj4gPiA+ID4gPiA+IFNvdXJjZSAgICAgICAgICAgICAgOiBXZWIg QXV0aG9yaXphdGlvbiBQcm90b2NvbA0KPiA+ID4gPiA+ID4gQXJlYSAgICAgICAgICAgICAgICA6 IFNlY3VyaXR5DQo+ID4gPiA+ID4gPiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPiA+ID4g PiA+ID4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gLS0NCj4gPiA+ID4gPiBQZXRlIFJlc25pY2sgaHR0cHM6Ly93d3cuZXBpc3RlbWUu bmV0Lw0KPiA+ID4gPiA+IEFsbCBjb25uZWN0aW9ucyB0byB0aGUgd29ybGQgYXJlIHRlbnVvdXMg YXQgYmVzdA0KPiA+ID4NCg0K From nobody Mon Jun 1 09:37:07 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0A3A0911 for ; Mon, 1 Jun 2020 09:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMJyavp4yIu8 for ; Mon, 1 Jun 2020 09:37:04 -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 2E2283A005C for ; Mon, 1 Jun 2020 09:37:04 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id l10so455481wrr.10 for ; Mon, 01 Jun 2020 09:37: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=BSrIWfma8sp6ieEqn7qLhoPWAqVOlvAFwnv/toxE/oI=; b=mtH/AnDpuJjzmyQXqTx4XXoQPr7HVOqPJdRJa22oHZesiXnNyuQdtzIpGAOHNsJbT4 V2ESvf8Hms5G44GVBXutS0Z0XUuxAeYRI7LFXTRnV3fQBa9zmUqf+Ba/kWeZQdl4o+5q p+S1XwjSN0xgGvsjwAlWBQwuVpwfpiQC3hm3xfFxMkpyRoxjy8656UK5yrH4RXAPLuBi E/XzjQOwMGNHv88fNp+UKHj3USgIaFwvCNpxMGBUa4RPRxLE+AS/kzSI7opmayOg5ug5 1U+rTDI/2EnXr+rjAK2loEnXzJxeYuWIvtqBpX78Dczl9ttmI3eRlSy01E64sg9U2bNk rnpQ== 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=BSrIWfma8sp6ieEqn7qLhoPWAqVOlvAFwnv/toxE/oI=; b=BWw7Bf9QbyLi5Ootc+V5NJX2Syp0nOSpfgHsKORNyDO9PIe5BLKOik/nWIhxXMzoa/ YbM13DZYOqM9sOo+awJJ8t+nFeMUv4m5c0TG3XFE+uI6zE5uwqcKprsfC1aknFaQUCPC sjlUxJt8tcE/HONIjxG4+KaNoaPM7RKlGKHmIHzZoTqi5tZEeKVp5+s2TxX/oPD9AIYZ OrWMV9iqHyb2a7aBWJvFTjDOch3s1CmLMmcA2rqgFz8HhNGcgJEruk0wngaglcukJ5Bf z2SCwfXnK91MeIjdX/VP4Vg5tKA2LhY0JKmafslAGInXNyFXfLRJCgb4g/ozsFODvSo4 yuuQ== X-Gm-Message-State: AOAM5337nlB07uCpU6JHcV+s6k9pTgffjmLZ1i6SJGhTskWfLPNzNnqX H9ahjk06OZEUDsugek2CFvbCfyiZ1UXflPHk5tA= X-Google-Smtp-Source: ABdhPJz/R4S/wLU2qtpF5T4wi9zIPxlejm01jS8Fvlm56TOIv5lUw2S9T6HgrrOHMVm/JjJLRQm3AHVeQuKT2AF1J20= X-Received: by 2002:a5d:468d:: with SMTP id u13mr24245509wrq.73.1591029418939; Mon, 01 Jun 2020 09:36:58 -0700 (PDT) MIME-Version: 1.0 References: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <20200530205522.GV58497@kduck.mit.edu> In-Reply-To: <20200530205522.GV58497@kduck.mit.edu> From: Janak Amarasena Date: Mon, 1 Jun 2020 22:06:22 +0530 Message-ID: To: Benjamin Kaduk Cc: Denis , oauth , Vittorio Bertocci Content-Type: multipart/alternative; boundary="00000000000057d75c05a7086724" Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 16:37:06 -0000 --00000000000057d75c05a7086724 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, My apologies, if this was already discussed. In section *4*. Validating JWT Access Tokens it is stated; The resource server MUST handle errors as described in section 3.1 of [RFC6750] . In particular, in case of any failure in the validation checks listed above the *authorization server* response MUST include the error code "invalid_token". Should this be; ... above the *resource server* response MUST include the error code "invalid_token". If that is not the case, which kind of scenarios would occur for an AS to respond with the error code "invalid_token"? Best Regards, Janak Amarasena On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk wrote: > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > > Hi Benjamin, > > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > > >> Since then, I questioned myself how a client would be able to reques= t > an > > >> access token that would be > > >> *strictly compliant with this Profile*. > > > I don't understand why this is an interesting question to ask. The > access > > > token and interpretation thereof is (AIUI) generally seen as an > internal > > > matter between AS and RS, with the client having no need to care abou= t > the > > > specifics. > > > > This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not > > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. > > Sure. But (in my understanding), in common usage, the contents and > interpretation of the access token is set by common agreement between AS > and RS, with the client serving only as a "dumb" channel for transporting > the token. That is, we're providing a token format that an RS and AS can > agree to use, most likely for all tokens issued by the AS for that RS. I > don't know of any existing mechanisms, or desire for such mechanisms by > deployments, for using a different token format for different tokens issu= ed > by a given AS for a given RS. Attempting to have the client provide inpu= t > that would affect such a mechanism seems like complexity with no market > demand; a "solution in search of a problem" as it were. Is there some > pent-up demand among OAuth deployments that I'm not aware of? I freely > admit to not being very on top of the broad spectrum of what's deployed..= . > > > 1) A client may wish to obtain an Access Token that corresponds to this > > Profile because, for example, > > this document mandates the "sub" claim to be present". Hence, the > > content of the Access Token is not > > totally "/an internal matter between AS and RS/". > > > > However, I have not understood how a client could request an Access > > Token that corresponds to *_this_***Profile, > > since there is no mandatory parameter in the request (both the "scope" > > parameter and the "resource" parameter are optional). > > > > In the future, we could define _*another*_**Profile. Hence, there is th= e > > same question: How could a client request an Access Token > > that corresponds to *_that other_***Profile ? > > > > 2) When getting a JWT, how can the client make sure that the access > > token it got is compliant with this Profile ? > > > > RFC 8725 states in section 3.11 : > > > > 3.11. Use Explicit Typing > > Sometimes, one kind of JWT can be confused for another. If a > > particular kind of JWT is subject to such confusion, > > that JWT can include an explicit JWT type value, and the validation > > rules can specify checking the type (...). > > Explicit JWT typing is accomplished by using the "typ" Header > > Parameter. > > > > Wouldn't be wise to include an explicit JWT type value for JWTs > > conformant to this Profile ? > > In the model where the client is a "dumb" communications channel, this > question does not seem interesting. But the related question of "how can > the RS make sure that the access token it got was generated according to > this profile?" does seem interesting, and seems like it would benefit fro= m > the same proposed solution. > > > This relates to an email posted by Dominick Baier under the topic "JAR: > > JWT typ" on May 19 : > > > > This has been brought up before - but no response. > > > > Either I can=E2=80=99t find it - or it is missing. But is the setti= ng the > > JWT typ explicitly mentioned somewhere? > > It is fairly likely that I will remember to ask about explicit "typ" usag= e > if I'm still on the IESG when this document gets there: I think I've been > making a habit of doing so. > > Thanks, > > Ben > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000057d75c05a7086724 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

My apologies, if this was alrea= dy discussed.

In section=C2=A04. Validating JWT = Access Tokens=C2=A0it is stated;

The resource server MUST hand=
le errors as described in section=C2=A03.1 of
   [RFC6750].  In particular, in case of any failure in the validation
   checks listed above the authorization server response MUST includ=
e
   the error code "invalid_token".



Should this be;
... above the resource server resp=
onse MUST include the error code "invalid_token".

If that is not the case, which kind of scenarios would occu= r for an AS to respond with the error code "invalid_token"?
=

Best Regards,
Janak Amarasena

=
On Sun, Ma= y 31, 2020 at 2:25 AM Benjamin Kaduk <k= aduk@mit.edu> wrote:
On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> Hi Benjamin,
> > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> >> Since then, I questioned myself how a client would be able to= request an
> >> access token that would be
> >> *strictly compliant with this Profile*.
> > I don't understand why this is an interesting question to ask= .=C2=A0 The access
> > token and interpretation thereof is (AIUI) generally seen as an i= nternal
> > matter between AS and RS, with the client having no need to care = about the
> > specifics.
>
> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not <= br> > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure.=C2=A0 But (in my understanding), in common usage, the contents and interpretation of the access token is set by common agreement between AS and RS, with the client serving only as a "dumb" channel for tran= sporting
the token.=C2=A0 That is, we're providing a token format that an RS and= AS can
agree to use, most likely for all tokens issued by the AS for that RS.=C2= =A0 I
don't know of any existing mechanisms, or desire for such mechanisms by=
deployments, for using a different token format for different tokens issued=
by a given AS for a given RS.=C2=A0 Attempting to have the client provide i= nput
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.=C2=A0 Is = there some
pent-up demand among OAuth deployments that I'm not aware of?=C2=A0 I f= reely
admit to not being very on top of the broad spectrum of what's deployed= ...

> 1) A client may wish to obtain an Access Token that corresponds to thi= s
> Profile because, for example,
> this document mandates the "sub" claim to be present". = Hence, the
> content of the Access Token is not
> totally "/an internal matter between AS and RS/".
>
> However, I have not understood how a client could request an Access > Token that corresponds to *_this_***Profile,
> since there is no mandatory parameter in the request (both the "s= cope"
> parameter and the "resource" parameter are optional).
>
> In the future, we could define _*another*_**Profile. Hence, there is t= he
> same question:=C2=A0 How could a client request an Access Token
> that corresponds to *_that other_***Profile ?
>
> 2) When getting a JWT,=C2=A0 how can the client make sure that the acc= ess
> token it got is compliant with this Profile ?
>
> RFC 8725 states in section 3.11 :
>
>=C2=A0 =C2=A0 =C2=A03.11. Use Explicit Typing
>=C2=A0 =C2=A0 =C2=A0Sometimes, one kind of JWT can be confused for anot= her. If a
>=C2=A0 =C2=A0 =C2=A0particular kind of JWT is subject to such confusion= ,
>=C2=A0 =C2=A0 =C2=A0that JWT can include an explicit JWT type value, an= d the validation
>=C2=A0 =C2=A0 =C2=A0rules can specify checking the type (...).
>=C2=A0 =C2=A0 =C2=A0Explicit JWT typing is accomplished by using the &q= uot;typ" Header
>=C2=A0 =C2=A0 =C2=A0Parameter.
>
> Wouldn't be wise to include an explicit JWT type value for JWTs > conformant to this Profile ?

In the model where the client is a "dumb" communications channel,= this
question does not seem interesting.=C2=A0 But the related question of "= ;how can
the RS make sure that the access token it got was generated according to this profile?" does seem interesting, and seems like it would benefit = from
the same proposed solution.

> This relates to an email posted by Dominick Baier under the topic &quo= t;JAR:
> JWT typ" on May 19 :
>
>=C2=A0 =C2=A0 =C2=A0This has been brought up before - but no response.<= br> >
>=C2=A0 =C2=A0 =C2=A0Either I can=E2=80=99t find it - or it is missing. = But is the setting the
>=C2=A0 =C2=A0 =C2=A0JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ&qu= ot; usage
if I'm still on the IESG when this document gets there: I think I'v= e been
making a habit of doing so.

Thanks,

Ben

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000057d75c05a7086724-- From nobody Mon Jun 1 10:54:37 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEA63A13D0 for ; Mon, 1 Jun 2020 10:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK-9FUB-f56j for ; Mon, 1 Jun 2020 10:54:34 -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 3CEE83A13CD for ; Mon, 1 Jun 2020 10:54:34 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id e125so4462768lfd.1 for ; Mon, 01 Jun 2020 10:54: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=HgrSWxLUCvUXazNpomsA/XnfOWVeOf3jqDkPjl5JSXY=; b=CrYY0dttB7SYgya3Ih0LyVySNBhvk1drL1NIRP1AJNAvbk3RMEYOyw+L6r+2U5pbmT YMvfr5SrC3dhCpl+xuLCNfr7q7K1ft6Ct/jAu2lUOqvJcDQUXFRMhunnMuWvcDBZKd3y i1CUxEmpbkIRQUfFoav3Uaakz5kRvsR7zTvSC93VcGkLfNrLzVECxx5pkreml3kX9Kx/ NBsR2D98gzoSAmPpMlKg6zRUFXlgeUniCxROggtuyqOW896SFAV8//JetSMTrs8yl/k2 lgrbIT8V3eB3OSxdqaJZb+y+mT6BRxL7Hb9MYXPcIo1F/70+NeYL9UTAA29tUpCLWWtN dlOw== 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=HgrSWxLUCvUXazNpomsA/XnfOWVeOf3jqDkPjl5JSXY=; b=jwYV0Sez+FR57HgtDAk9VwB8DuzjAWA3/TxtV5pD5jgLP/ueMAxwSfsMZSRDuDl0kr FnP9rWJMAoab9TAJ81A4xgTu4ucOOedBebIfu3i1XMOIT+/TgXLLyDJfSyKyixfx0UCH yDUzp2rocapEv+obPOAx2zSJsOzQvds30ONK0Z44CNftp9zskifEfRNssU2MYBBrcgrE XpxwYfrNTp6j2+JyYLrux4SlxEsyp2ruvnOk3hTl4JmF8CjXArgLdbVy/VxK1HFo+tC5 8ph7b/JO83Rqs/AtScXB0LP82fbvS9FW53Fa6FxYLf+dd1BAVlZ18N3rmrruRl4J7DoJ IGKQ== X-Gm-Message-State: AOAM530IGCy+yxP+B+fXuNG0gW0QrCEeqbpt9MPF2xPdWLqp59Ib1Izo uC7AUcNYwVcXI+Edy4TJlaOR4VRcmq4naY1WcA8= X-Google-Smtp-Source: ABdhPJyfTP7v5ofvw3rySnZKHgW4HFzbxumUmY4HU24lSGuZUIay9nuruJxVp4Og29dh6ddVUyX+4DCCGDSilUNhzwk= X-Received: by 2002:a19:8453:: with SMTP id g80mr12026983lfd.167.1591034070414; Mon, 01 Jun 2020 10:54:30 -0700 (PDT) MIME-Version: 1.0 References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de> <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com> In-Reply-To: <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com> From: Dick Hardt Date: Mon, 1 Jun 2020 10:54:04 -0700 Message-ID: To: Neil Madden Cc: Daniel Fett , "oauth@ietf.org" , Mike Jones Content-Type: multipart/alternative; boundary="00000000000097b9f005a7097c82" Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 17:54:37 -0000 --00000000000097b9f005a7097c82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike: what are your thoughts on the options? =E1=90=A7 On Sat, May 30, 2020 at 4:39 AM Neil Madden wrote: > We (ForgeRock) already support solution 1 as a configuration option, but = I > prefer solution 2 and have raised a ticket for us to implement it. For us > at least it=E2=80=99s a trivial fix and seems more robust against configu= ration > errors. > > =E2=80=94 Neil > > On 30 May 2020, at 08:58, Daniel Fett wrote: > > Hi all, > > Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE > [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the > conclusion that we have two options: > > *1. "Static" Solution* > > For every client_id that is registered with an AS, the AS MUST either > always enforce the use of PKCE or always enforce the use of nonce. Whethe= r > PKCE or nonce is enforced can be part of the client registration or > configured in other ways. > > In other words: A single client is not allowed to switch between using > PKCE and using nonce. > > Note that the client is allowed to use the respective other mechanism on > top of the enforced one. > > Properties: > > - Easy to understand mitigation. > - Implementation is mainly a new data field and a check in the > authorization request. > - Not compatible to deployments where clients sometimes use nonce and > sometimes use PKCE with the same client_id. > > *2. "Dynamic" Solution* > > Each AS that supports PKCE MUST check whether a code challenge is > contained in the authorization request. This information MUST be bound to > the code that is issued. > > When a code arrives at the token endpoint, the AS MUST do the following > check: > > 1. If there was a code_challenge in the authorization request for > which this code was issued, there must be a code_verifier in the token > request and it must be verified according to RFC7636. (This is no chan= ge > from the current behavior in RFC7636.) > 2. If there was no code_challenge in the authorization request, any > request to the token endpoint containing a code_verifier MUST be rejec= ted. > > Properties: > > - No change in behavior needed for properly implemented clients. > Backwards compatible for all existing deployments. > - Implementation is mainly some logic for the authorization endpoint, > token endpoint, and a new data field in the authorization session > maintained by the AS. > - Slightly more complex to implement for the AS, maybe. > > We would like to hear the feedback from the working group on these two > solutions before proceeding to propose wording for the affected documents= . > > [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > > -Daniel > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000097b9f005a7097c82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike: what are your thoughts on the options?
3D""=E1=90=A7

On Sat, May 30, 2020 at 4:39 AM Neil Madden <neil.madden@forgerock.com> wrote:=
We (ForgeRock) already support solution 1 as a c= onfiguration option, but I prefer solution 2 and have raised a ticket for u= s to implement it. For us at least it=E2=80=99s a trivial fix and seems mor= e robust against configuration errors.

=E2=80=94 Neil

On 30 May 2020, at 08:58, Daniel Fe= tt <fett@danielf= ett.de> wrote:

=20 =20 =20
Hi all,

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that we have two options:

1. "Static" Solution

For every client_id that is registered with an AS, the AS MUST either always enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or nonce is enforced can be part of the client registration or configured in other ways.

In other words: A single client is not allowed to switch between using PKCE and using nonce.

Note that the client is allowed to use the respective other mechanism on top of the enforced one.

Properties:
  • Easy to understand mitigation.
  • Implementation is mainly a new data field and a check in the authorization request.
  • Not compatible to deployments where clients sometimes use nonce and sometimes use PKCE with the same client_id.

2. "Dynamic" Solution

Each AS that = supports PKCE MUST check whether a code challenge is contained in the authorization request. This information MUST be bound to the code that is issued.

When a code arrives at t= he token endpoint, the AS MUST do the following check:

  1. If there was a code_challenge in the authorization request for which this code was issued, there must be a code_verifier in the token request and it must be verified according to RFC7636. (This is no change from the current behavior in RFC7636.)
  2. If there was no code_challenge in the authorization request, any request to the token endpoint containing a code_verifier MUST be rejected.

Properties:

  • No change in behavior needed for properly implemented clients. Backwards compatible for all existing deployments.
  • Implementation is mainly some logic for the authorization endpoint, token endpoint, and a new data field in the authorization session maintained by the AS.
  • Slightly more complex to implement for the AS, maybe.
We would like to hear the feedback from the working group on these two solutions before proceeding to propose wording for the affected documents.


-Daniel

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000097b9f005a7097c82-- From nobody Mon Jun 1 12:11:41 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA793A150A for ; Mon, 1 Jun 2020 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Ug8gcHgoSW for ; Mon, 1 Jun 2020 12:11:29 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650113.outbound.protection.outlook.com [40.107.65.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96643A150B for ; Mon, 1 Jun 2020 12:11:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I42s1xumM866nD3b3kJYh/KmqABHRJ9y1389N2k9EccRepkJ2tRV/C5uIBGrAYOf/v9kU+4hBEDcbxFh9UoUP/CRBP05bH1aprtw4uGcRZTrPnQDQAlxO4rCtwkMWVVEG+Wh+PaK2jzHAElHXAb3YqOJ8hJQxWuh4pe39U6nuh6ys/2DhGWCzK9bx62QrIBIvIE/s38f2Wcx74AXWt790YKuX4cX0RIzFD2NBinA5NW1V+wnFhv3HmlAh0jh855DrqYExZX+2qzdzcWxMXlLz0eKAqCkIkczO+TUZgaOLQErMBcQlDmuvGhDcjorT0A6csUV3mQl6/ZxF0XHzhrzXg== 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=hrByEIvsAi1M+Xu4je3vsmu5PvOPtMG229U9cdmK0n0=; b=SzKbm3vWCpflL1qWXjy83kqQtaL8XO6hDmsmAI52bAUCIf6/ZH6x8IEReNa2m2yryszuOPPSHXfZtI4tMO9yMA3OG1OPm13xklzVoTgEeoUKVOXL5cynRBdaH/Vaxvr2EtGvQwlhCUYEcWeIcyfrCUOaQpdhmo0vzO46K0qwNChYhJEFv25ubz3EQeBXDVbSynu9EZSjmN2Zk32+7ScgSDQ06STe9he4oC6UyHPTNBN7FuQ9zZXcYM/5bFsD4l3upZ+dSI43LCe+Hn/zLWR7i204Affau8b2rMl1RFnZe+C1lYUymNd1gWe9kBLgR5N7HTDx2E3b584xhPU/mbuzDg== 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=hrByEIvsAi1M+Xu4je3vsmu5PvOPtMG229U9cdmK0n0=; b=cwBabnDM4b7ItnlVKfsgi0TfOPC96e0Ht9V+Ylf0ZqH+44Ssf/SvUSvVwsUYkuZbxR+kjM25a3qdHHzisXXAox4mP/jjG+raMnrM0iGoKtcJBpi9PfKx+VQ1+yqgodgkBrgWuryY0hTLJyktyQOj76/y5vDB1C6qyTGjyhDskJo= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0323.namprd00.prod.outlook.com (2603:10b6:207:1f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3094.0; Mon, 1 Jun 2020 19:11:26 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8cb:32d6:fcd9:4c17]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::d8cb:32d6:fcd9:4c17%9]) with mapi id 15.20.3101.000; Mon, 1 Jun 2020 19:11:26 +0000 From: Mike Jones To: Dick Hardt , Neil Madden CC: Daniel Fett , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Downgrade attacks on PKCE Thread-Index: AdY4SHGdz8Mrlse7SpiGnPEG3tbLTg== Date: Mon, 1 Jun 2020 19:11:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0c6b5ef4-1ac0-40a8-9154-0000300e6bb8; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-01T19:09:12Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 10c599ea-cf9f-4e9e-f4d6-08d8065f9547 x-ms-traffictypediagnostic: BL0PR00MB0323: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KWh/0zBtaEGphSeVPsbXVKTdTV5Xo1Aml29W8vkOre/hzk5IpLoA4c9MbdYRm6rgwpLmnPd/gtqGtdtux4uOHm/jMDXMf+HxQx6Ul4QyvWcaZbrshB4NjeX3jF5VIEx1NJSpofQUzSF0y39pSNfWpZhqSYtfsXImCn4gBT7BKiDjhNTN6jV9IO6LdzCBWj+yf51BW3Si3Kk2vesvzAnmW7VamFcJvKFIhvx1BQFFL76ojUz1joa9qa84iHSFj2aZYtuGBmPqCPYVQVRtlRozxC8XiWl1kgaPsglNnzsCqqrjjR9LJ4+2QQ4WDikVOd94j36EJ5UiWYOrZRcmEa1MOF33+lvarLXb8cbKb+afICbtv4/2f7AtK6kTXer4NMUBjx0YdvISMKto9OkxNQ8maIxu9NAgRej9XUxFKunbInMRiPi4E/MVY7K9HXxO/5kvbjpUGQOr8PhHc0X/AVYOUg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(39860400002)(366004)(136003)(55016002)(166002)(8676002)(86362001)(9686003)(2906002)(76236002)(66476007)(64756008)(66446008)(966005)(66556008)(7696005)(52536014)(8990500004)(5660300002)(10290500003)(54906003)(8936002)(110136005)(82950400001)(186003)(83080400001)(82960400001)(26005)(316002)(53546011)(71200400001)(4326008)(66946007)(76116006)(83380400001)(478600001)(6506007)(33656002)(99710200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: tK79tW/TP7bxWgM8ddn4SUG6o8wztDV5QyKR5NYf1IYbi/50Ehbt9dwF3qH/YJHYXc2ogZTpWN8Z6UMAYUQ11Off2ybVCN20t4kG8CFLELG2h6yoyyhG0WFzuiHRnZfxlKu7BYNbHMTLDYaPXmYaURVbAZmD7L48z41qm8jtd75ie2MLGWzLvsLrEH3Tmsefy1iMB/sZoTq8PNrs3KeD+N4YcfvZPFVRgcCXYkS5Hm+48JkXa30cHUkFT+KQjXi6/uLYoZUui4EswhaRv92fC052BBBL0GDzIhFBRkH0h9sSb3hr40xF32MMmgTcfXtTW2YfW3GnAdJt0ql3j88KPtaQZdTBv7ks2iI06c4D6lIsYPRICh2psrii/91VgNBDmkBDUYHkRhuLWUwEPNHjFqawdExiSH7dAwmDDYuX9fcPpx6xKL/ilvyUuSrKIm9Q1Ql0kIjRTvDkJsj9i2jofZZOLK3yMNWRSg70KBv/Ki0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688661C391F3234CBFB9812F58A0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10c599ea-cf9f-4e9e-f4d6-08d8065f9547 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 19:11:26.8209 (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: WRluydHyo7GEp5ged5ulKUB0CA8BZy6YxfvtFZDwjreHE5B4U9za7xDqw4JsTfGh7zKb8b5DmcB78xWloqoSHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0323 Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 19:11:39 -0000 --_000_MN2PR00MB0688661C391F3234CBFB9812F58A0MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGlrZSBGaWxpcCBhbmQgTmVpbCBhbmQgSSBiZWxpZXZlIFJ5YW4sIEkgcHJlZmVyIHRoZSBkeW5h bWljIG9wdGlvbiAyLiAgSXQga2VlcHMgZXhpc3RpbmcgY2xpZW50cyB3b3JraW5nIHdoZW4gcG9z c2libGUsIHdoaWNoIHNob3VsZCBiZSBhIGdvYWwgb2YgT0F1dGggMi4xLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTZW50OiBNb25k YXksIEp1bmUgMSwgMjAyMCAxMDo1NCBBTQ0KVG86IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBm b3JnZXJvY2suY29tPg0KQ2M6IERhbmllbCBGZXR0IDxmZXR0QGRhbmllbGZldHQuZGU+OyBvYXV0 aEBpZXRmLm9yZzsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gRG93bmdyYWRlIGF0dGFja3Mgb24gUEtDRQ0KDQpNaWtlOiB3 aGF0IGFyZSB5b3VyIHRob3VnaHRzIG9uIHRoZSBvcHRpb25zPw0K4ZCnDQoNCk9uIFNhdCwgTWF5 IDMwLCAyMDIwIGF0IDQ6MzkgQU0gTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5j b208bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNCldlIChGb3JnZVJv Y2spIGFscmVhZHkgc3VwcG9ydCBzb2x1dGlvbiAxIGFzIGEgY29uZmlndXJhdGlvbiBvcHRpb24s IGJ1dCBJIHByZWZlciBzb2x1dGlvbiAyIGFuZCBoYXZlIHJhaXNlZCBhIHRpY2tldCBmb3IgdXMg dG8gaW1wbGVtZW50IGl0LiBGb3IgdXMgYXQgbGVhc3QgaXTigJlzIGEgdHJpdmlhbCBmaXggYW5k IHNlZW1zIG1vcmUgcm9idXN0IGFnYWluc3QgY29uZmlndXJhdGlvbiBlcnJvcnMuDQoNCuKAlCBO ZWlsDQoNCg0KT24gMzAgTWF5IDIwMjAsIGF0IDA4OjU4LCBEYW5pZWwgRmV0dCA8ZmV0dEBkYW5p ZWxmZXR0LmRlPG1haWx0bzpmZXR0QGRhbmllbGZldHQuZGU+PiB3cm90ZToNCg0KSGkgYWxsLA0K DQpBYXJvbiwgRGljaywgVG9yc3RlbiBhbmQgSSB0b2RheSBkaXNjdXNzZWQgdGhlIGRvd25ncmFk ZSBhdHRhY2tzIG9uIFBLQ0UgWzFdIGFuZCBob3cgdG8gbWl0aWdhdGUgdGhlbSBpbiBPQXV0aCAy LjEgYW5kIDIuMC4gV2UgY2FtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHdlIGhhdmUgdHdvIG9w dGlvbnM6DQoNCjEuICJTdGF0aWMiIFNvbHV0aW9uDQoNCkZvciBldmVyeSBjbGllbnRfaWQgdGhh dCBpcyByZWdpc3RlcmVkIHdpdGggYW4gQVMsIHRoZSBBUyBNVVNUIGVpdGhlciBhbHdheXMgZW5m b3JjZSB0aGUgdXNlIG9mIFBLQ0Ugb3IgYWx3YXlzIGVuZm9yY2UgdGhlIHVzZSBvZiBub25jZS4g V2hldGhlciBQS0NFIG9yIG5vbmNlIGlzIGVuZm9yY2VkIGNhbiBiZSBwYXJ0IG9mIHRoZSBjbGll bnQgcmVnaXN0cmF0aW9uIG9yIGNvbmZpZ3VyZWQgaW4gb3RoZXIgd2F5cy4NCg0KSW4gb3RoZXIg d29yZHM6IEEgc2luZ2xlIGNsaWVudCBpcyBub3QgYWxsb3dlZCB0byBzd2l0Y2ggYmV0d2VlbiB1 c2luZyBQS0NFIGFuZCB1c2luZyBub25jZS4NCg0KTm90ZSB0aGF0IHRoZSBjbGllbnQgaXMgYWxs b3dlZCB0byB1c2UgdGhlIHJlc3BlY3RpdmUgb3RoZXIgbWVjaGFuaXNtIG9uIHRvcCBvZiB0aGUg ZW5mb3JjZWQgb25lLg0KDQpQcm9wZXJ0aWVzOg0KDQogICogICBFYXN5IHRvIHVuZGVyc3RhbmQg bWl0aWdhdGlvbi4NCiAgKiAgIEltcGxlbWVudGF0aW9uIGlzIG1haW5seSBhIG5ldyBkYXRhIGZp ZWxkIGFuZCBhIGNoZWNrIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQogICogICBOb3Qg Y29tcGF0aWJsZSB0byBkZXBsb3ltZW50cyB3aGVyZSBjbGllbnRzIHNvbWV0aW1lcyB1c2Ugbm9u Y2UgYW5kIHNvbWV0aW1lcyB1c2UgUEtDRSB3aXRoIHRoZSBzYW1lIGNsaWVudF9pZC4NCg0KMi4g IkR5bmFtaWMiIFNvbHV0aW9uDQoNCkVhY2ggQVMgdGhhdCBzdXBwb3J0cyBQS0NFIE1VU1QgY2hl Y2sgd2hldGhlciBhIGNvZGUgY2hhbGxlbmdlIGlzIGNvbnRhaW5lZCBpbiB0aGUgYXV0aG9yaXph dGlvbiByZXF1ZXN0LiBUaGlzIGluZm9ybWF0aW9uIE1VU1QgYmUgYm91bmQgdG8gdGhlIGNvZGUg dGhhdCBpcyBpc3N1ZWQuDQoNCldoZW4gYSBjb2RlIGFycml2ZXMgYXQgdGhlIHRva2VuIGVuZHBv aW50LCB0aGUgQVMgTVVTVCBkbyB0aGUgZm9sbG93aW5nIGNoZWNrOg0KDQogIDEuICBJZiB0aGVy ZSB3YXMgYSBjb2RlX2NoYWxsZW5nZSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZvciB3 aGljaCB0aGlzIGNvZGUgd2FzIGlzc3VlZCwgdGhlcmUgbXVzdCBiZSBhIGNvZGVfdmVyaWZpZXIg aW4gdGhlIHRva2VuIHJlcXVlc3QgYW5kIGl0IG11c3QgYmUgdmVyaWZpZWQgYWNjb3JkaW5nIHRv IFJGQzc2MzYuIChUaGlzIGlzIG5vIGNoYW5nZSBmcm9tIHRoZSBjdXJyZW50IGJlaGF2aW9yIGlu IFJGQzc2MzYuKQ0KICAyLiAgSWYgdGhlcmUgd2FzIG5vIGNvZGVfY2hhbGxlbmdlIGluIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QsIGFueSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBj b250YWluaW5nIGEgY29kZV92ZXJpZmllciBNVVNUIGJlIHJlamVjdGVkLg0KDQpQcm9wZXJ0aWVz Og0KDQogICogICBObyBjaGFuZ2UgaW4gYmVoYXZpb3IgbmVlZGVkIGZvciBwcm9wZXJseSBpbXBs ZW1lbnRlZCBjbGllbnRzLiBCYWNrd2FyZHMgY29tcGF0aWJsZSBmb3IgYWxsIGV4aXN0aW5nIGRl cGxveW1lbnRzLg0KICAqICAgSW1wbGVtZW50YXRpb24gaXMgbWFpbmx5IHNvbWUgbG9naWMgZm9y IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCB0b2tlbiBlbmRwb2ludCwgYW5kIGEgbmV3IGRh dGEgZmllbGQgaW4gdGhlIGF1dGhvcml6YXRpb24gc2Vzc2lvbiBtYWludGFpbmVkIGJ5IHRoZSBB Uy4NCiAgKiAgIFNsaWdodGx5IG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQgZm9yIHRoZSBBUywg bWF5YmUuDQpXZSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIGZlZWRiYWNrIGZyb20gdGhlIHdvcmtp bmcgZ3JvdXAgb24gdGhlc2UgdHdvIHNvbHV0aW9ucyBiZWZvcmUgcHJvY2VlZGluZyB0byBwcm9w b3NlIHdvcmRpbmcgZm9yIHRoZSBhZmZlY3RlZCBkb2N1bWVudHMuDQoNClsxXSBodHRwczovL2Rh bmllbGZldHQuZGUvMjAyMC8wNS8xNi9wa2NlLXZzLW5vbmNlLWVxdWl2YWxlbnQtb3Itbm90Lw0K DQotRGFuaWVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_MN2PR00MB0688661C391F3234CBFB9812F58A0MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODA4NzY0OTE7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjIzNDcwNjY4O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjcxOTg2 NTA4MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI4MDA2OTI2NDt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTkxNTc3OTk3MjsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTEyNjQwNTYwNjQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+TGlrZSBGaWxpcCBhbmQgTmVpbCBhbmQgSSBiZWxpZXZlIFJ5YW4sIEkgcHJlZmVyIHRo ZSBkeW5hbWljIG9wdGlvbiAyLiZuYnNwOyBJdCBrZWVwcyBleGlzdGluZyBjbGllbnRzIHdvcmtp bmcgd2hlbiBwb3NzaWJsZSwgd2hpY2ggc2hvdWxkIGJlIGEgZ29hbCBvZiBPQXV0aCAyLjEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5j b20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMSwgMjAyMCAxMDo1NCBBTTxi cj4NCjxiPlRvOjwvYj4gTmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVuQGZvcmdlcm9jay5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBEYW5pZWwgRmV0dCAmbHQ7ZmV0dEBkYW5pZWxmZXR0LmRlJmd0 Ozsgb2F1dGhAaWV0Zi5vcmc7IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRG93bmdyYWRlIGF0 dGFja3Mgb24gUEtDRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtl OiB3aGF0IGFyZSB5b3VyIHRob3VnaHRzIG9uIHRoZSBvcHRpb25zPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyB3aWR0aD0iMSIgaGVpZ2h0 PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAy NSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVv WVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD02OGJm OGM0NC1iMmZhLTQ0ZDYtOWFlYi05OTRjNDlkMTVkNDciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hp dGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFNhdCwgTWF5IDMwLCAyMDIwIGF0IDQ6MzkgQU0gTmVpbCBNYWRkZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIj5uZWlsLm1hZGRlbkBmb3JnZXJv Y2suY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgKEZvcmdlUm9jaykgYWxyZWFkeSBzdXBw b3J0IHNvbHV0aW9uIDEgYXMgYSBjb25maWd1cmF0aW9uIG9wdGlvbiwgYnV0IEkgcHJlZmVyIHNv bHV0aW9uIDIgYW5kIGhhdmUgcmFpc2VkIGEgdGlja2V0IGZvciB1cyB0byBpbXBsZW1lbnQgaXQu IEZvciB1cyBhdCBsZWFzdCBpdOKAmXMgYSB0cml2aWFsIGZpeCBhbmQgc2VlbXMgbW9yZSByb2J1 c3QgYWdhaW5zdCBjb25maWd1cmF0aW9uIGVycm9ycy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBOZWlsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMCBNYXkgMjAyMCwgYXQgMDg6NTgsIERhbmllbCBGZXR0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZmV0dEBkYW5pZWxmZXR0LmRlIiB0YXJnZXQ9Il9ibGFuayI+ ZmV0dEBkYW5pZWxmZXR0LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYXJvbiwgRGljaywgVG9yc3RlbiBh bmQgSSB0b2RheSBkaXNjdXNzZWQgdGhlIGRvd25ncmFkZSBhdHRhY2tzIG9uIFBLQ0UgWzFdIGFu ZCBob3cgdG8gbWl0aWdhdGUgdGhlbSBpbiBPQXV0aCAyLjEgYW5kIDIuMC4gV2UgY2FtZSB0byB0 aGUgY29uY2x1c2lvbiB0aGF0IHdlIGhhdmUgdHdvIG9wdGlvbnM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjEuICZxdW90O1N0YXRpYyZx dW90OyBTb2x1dGlvbjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Rm9yIGV2ZXJ5IGNsaWVudF9pZCB0aGF0IGlzIHJlZ2lzdGVyZWQgd2l0 aCBhbiBBUywgdGhlIEFTIE1VU1QgZWl0aGVyIGFsd2F5cyBlbmZvcmNlIHRoZSB1c2Ugb2YgUEtD RSBvciBhbHdheXMgZW5mb3JjZSB0aGUgdXNlIG9mIG5vbmNlLiBXaGV0aGVyIFBLQ0Ugb3Igbm9u Y2UgaXMgZW5mb3JjZWQgY2FuIGJlIHBhcnQgb2YgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gb3Ig Y29uZmlndXJlZCBpbiBvdGhlciB3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvdGhlciB3b3JkczogQSBzaW5nbGUgY2xpZW50IGlz IG5vdCBhbGxvd2VkIHRvIHN3aXRjaCBiZXR3ZWVuIHVzaW5nIFBLQ0UgYW5kIHVzaW5nIG5vbmNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O b3RlIHRoYXQgdGhlIGNsaWVudCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUgcmVzcGVjdGl2ZSBvdGhl ciBtZWNoYW5pc20gb24gdG9wIG9mIHRoZSBlbmZvcmNlZCBvbmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb3BlcnRpZXM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkVhc3kgdG8gdW5kZXJzdGFuZCBtaXRp Z2F0aW9uLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm8xIj4NCkltcGxlbWVudGF0aW9uIGlzIG1haW5seSBhIG5ldyBkYXRhIGZpZWxk IGFuZCBhIGNoZWNrIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KTm90IGNv bXBhdGlibGUgdG8gZGVwbG95bWVudHMgd2hlcmUgY2xpZW50cyBzb21ldGltZXMgdXNlIG5vbmNl IGFuZCBzb21ldGltZXMgdXNlIFBLQ0Ugd2l0aCB0aGUgc2FtZSBjbGllbnRfaWQuDQo8bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwPjxiPjIuICZxdW90O0R5bmFtaWMmcXVvdDsgU29sdXRpb248L2I+ PG86cD48L286cD48L3A+DQo8cD5FYWNoIEFTIHRoYXQgc3VwcG9ydHMgUEtDRSBNVVNUIGNoZWNr IHdoZXRoZXIgYSBjb2RlIGNoYWxsZW5nZSBpcyBjb250YWluZWQgaW4gdGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdC4gVGhpcyBpbmZvcm1hdGlvbiBNVVNUIGJlIGJvdW5kIHRvIHRoZSBjb2RlIHRo YXQgaXMgaXNzdWVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+V2hlbiBhIGNvZGUgYXJyaXZlcyBhdCB0 aGUgdG9rZW4gZW5kcG9pbnQsIHRoZSBBUyBNVVNUIGRvIHRoZSBmb2xsb3dpbmcgY2hlY2s6PG86 cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpJZiB0aGVyZSB3YXMgYSBjb2RlX2NoYWxs ZW5nZSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZvciB3aGljaCB0aGlzIGNvZGUgd2Fz IGlzc3VlZCwgdGhlcmUgbXVzdCBiZSBhIGNvZGVfdmVyaWZpZXIgaW4gdGhlIHRva2VuIHJlcXVl c3QgYW5kIGl0IG11c3QgYmUgdmVyaWZpZWQgYWNjb3JkaW5nIHRvIFJGQzc2MzYuIChUaGlzIGlz IG5vIGNoYW5nZSBmcm9tIHRoZSBjdXJyZW50IGJlaGF2aW9yIGluIFJGQzc2MzYuKTxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4N CklmIHRoZXJlIHdhcyBubyBjb2RlX2NoYWxsZW5nZSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1 ZXN0LCBhbnkgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgY29udGFpbmluZyBhIGNvZGVf dmVyaWZpZXIgTVVTVCBiZSByZWplY3RlZC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwPlByb3Bl cnRpZXM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCk5vIGNoYW5nZSBpbiBiZWhhdmlvciBu ZWVkZWQgZm9yIHByb3Blcmx5IGltcGxlbWVudGVkIGNsaWVudHMuIEJhY2t3YXJkcyBjb21wYXRp YmxlIGZvciBhbGwgZXhpc3RpbmcgZGVwbG95bWVudHMuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KSW1wbGVtZW50YXRpb24g aXMgbWFpbmx5IHNvbWUgbG9naWMgZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCB0b2tl biBlbmRwb2ludCwgYW5kIGEgbmV3IGRhdGEgZmllbGQgaW4gdGhlIGF1dGhvcml6YXRpb24gc2Vz c2lvbiBtYWludGFpbmVkIGJ5IHRoZSBBUy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+DQpTbGlnaHRseSBtb3JlIGNvbXBsZXgg dG8gaW1wbGVtZW50IGZvciB0aGUgQVMsIG1heWJlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd291bGQgbGlrZSB0byBoZWFyIHRo ZSBmZWVkYmFjayBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIG9uIHRoZXNlIHR3byBzb2x1dGlvbnMg YmVmb3JlIHByb2NlZWRpbmcgdG8gcHJvcG9zZSB3b3JkaW5nIGZvciB0aGUgYWZmZWN0ZWQgZG9j dW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYW5pZWxmZXR0LmRlLzIwMjAvMDUvMTYvcGtjZS12 cy1ub25jZS1lcXVpdmFsZW50LW9yLW5vdC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGFu aWVsZmV0dC5kZS8yMDIwLzA1LzE2L3BrY2UtdnMtbm9uY2UtZXF1aXZhbGVudC1vci1ub3QvPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t RGFuaWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR00MB0688661C391F3234CBFB9812F58A0MN2PR00MB0688namp_-- From nobody Mon Jun 1 13:19:23 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535213A1532 for ; Mon, 1 Jun 2020 13:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq5a4QH1rhrb for ; Mon, 1 Jun 2020 13:19:19 -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 C06A03A1530 for ; Mon, 1 Jun 2020 13:19:18 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id w1so10395284qkw.5 for ; Mon, 01 Jun 2020 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=mHyyYIPaulyLhbVegG3naTtoxIGGC3tqRSn/gOHqb5s=; b=p0v0HWwd+vDcggsu8vnY1keUTI1bgntRToba5kCofkohWbK4S1C+i73KGldIy+b/I/ GuSFfqEGWSSgnoAaSLVFwVZ8q1rV6sPGpjDLAiEbpySDmKoem3z66FkyJvdHIsDyz5v7 wgO3bzv7fSnEex/eDAaxzTO/eO9qRlvw3Z19m0Zzob38lwDlp+FgTloDB0h+XZYIzt3B 4O3kvaUDB81gG6WJQzcK83gnQAlDQ9US5A/J4nKn4MNUvGH9tPvsgz+mxp3sujg3sAnF ib7IzuW9GIBu+FUXCtEZjojMi4zROt8nYIo0aJwoM7nV77JaOfebw8kYvGsYe7GGcu3+ NtQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=mHyyYIPaulyLhbVegG3naTtoxIGGC3tqRSn/gOHqb5s=; b=IE/JE9h5oEGAg9P66v0nt2gfObUJX5+aFyikGrnI55ebpbknXcqBWrTZmF2/erb358 85Tvjcgl7ToedKPNx5dla0TqG6xNJilYygPv5SQBSQI6+rnKiR4yB6bXiuMrUfZcG2kZ WgYZNefMz4NvMl24fSQRysZ4wm20SylVupydX+wrRp+2Au3pgf7C2xUePAXv1rXkMSdd 0cft1c0C4s040LSMeJEAAucQHS0VGBxD/xVnRiJTEsu9Ao6sjfmSftfhfQZZ758ua8fv QwO1ZgDBHNauo9NGbzETPIHLJNVMFKBEzRnPWWwQdK+pOepE0Dt7oijyyqqV4DR6XfC2 jFAA== X-Gm-Message-State: AOAM532PTCNEIwJ0F8i+m/ebYwArKBSu+HNo6th1SvLNdEUGHZF3GQTf XRcEFiOKIejD6JKF6CSd0zzxmKxUIBeA3PSN X-Google-Smtp-Source: ABdhPJz5cDePG1ne4E3pnE1+4xHQCbkedDYsq+WuQWj4ZTjhGMpcjeWTFx+P6oyQY9aw+71v7VONCQ== X-Received: by 2002:a37:784:: with SMTP id 126mr21040036qkh.200.1591042757000; Mon, 01 Jun 2020 13:19:17 -0700 (PDT) Received: from [192.168.8.102] ([190.107.226.22]) by smtp.gmail.com with ESMTPSA id b189sm273087qkg.110.2020.06.01.13.19.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 13:19:16 -0700 (PDT) To: oauth@ietf.org References: From: John Bradley Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE= Message-ID: <45997787-9218-569c-1b1f-3cb159557089@ve7jtb.com> Date: Mon, 1 Jun 2020 16:19:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------382AB4311FCE7C7B761940C6" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:19:21 -0000 This is a multi-part message in MIME format. --------------382AB4311FCE7C7B761940C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Definatly 2. To my mind if you get a challange and dont get a verifyer that must fail.  I guess the querstion is if there is a veriyer with no challange what to do.  We diden't specify that.   I would reject that as a config error or indication of a MIM in the front channel. I think that is the correct thing to do. On 6/1/2020 3:11 PM, Mike Jones wrote: > > Like Filip and Neil and I believe Ryan, I prefer the dynamic option > 2.  It keeps existing clients working when possible, which should be a > goal of OAuth 2.1. > >   > >                                                        Thanks, > >                                                        -- Mike > >   > > *From:* Dick Hardt > *Sent:* Monday, June 1, 2020 10:54 AM > *To:* Neil Madden > *Cc:* Daniel Fett ; oauth@ietf.org; Mike Jones > > *Subject:* Re: [OAUTH-WG] Downgrade attacks on PKCE > >   > > Mike: what are your thoughts on the options? > > ᐧ > >   > > On Sat, May 30, 2020 at 4:39 AM Neil Madden > wrote: > > We (ForgeRock) already support solution 1 as a configuration > option, but I prefer solution 2 and have raised a ticket for us to > implement it. For us at least it’s a trivial fix and seems more > robust against configuration errors. > >   > > — Neil > > > > On 30 May 2020, at 08:58, Daniel Fett > wrote: > >   > > Hi all, > >   > > Aaron, Dick, Torsten and I today discussed the downgrade > attacks on PKCE [1] and how to mitigate them in OAuth 2.1 and > 2.0. We came to the conclusion that we have two options: > >   > > *1. "Static" Solution* > >   > > For every client_id that is registered with an AS, the AS MUST > either always enforce the use of PKCE or always enforce the > use of nonce. Whether PKCE or nonce is enforced can be part of > the client registration or configured in other ways. > >   > > In other words: A single client is not allowed to switch > between using PKCE and using nonce. > >   > > Note that the client is allowed to use the respective other > mechanism on top of the enforced one. > >   > > Properties: > > * Easy to understand mitigation. > * Implementation is mainly a new data field and a check in > the authorization request. > * Not compatible to deployments where clients sometimes use > nonce and sometimes use PKCE with the same client_id. > > *2. "Dynamic" Solution* > > Each AS that supports PKCE MUST check whether a code challenge > is contained in the authorization request. This information > MUST be bound to the code that is issued. > > When a code arrives at the token endpoint, the AS MUST do the > following check: > > 1. If there was a code_challenge in the authorization request > for which this code was issued, there must be a > code_verifier in the token request and it must be verified > according to RFC7636. (This is no change from the current > behavior in RFC7636.) > 2. If there was no code_challenge in the authorization > request, any request to the token endpoint containing a > code_verifier MUST be rejected. > > Properties: > > * No change in behavior needed for properly implemented > clients. Backwards compatible for all existing deployments. > * Implementation is mainly some logic for the authorization > endpoint, token endpoint, and a new data field in the > authorization session maintained by the AS. > * Slightly more complex to implement for the AS, maybe. > > We would like to hear the feedback from the working group on > these two solutions before proceeding to propose wording for > the affected documents. > >   > > [1] > https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > >   > > -Daniel > >   > > _______________________________________________ > OAuth mailing 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 --------------382AB4311FCE7C7B761940C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Definatly 2.

To my mind if you get a challange and dont get a verifyer that must fail. 

I guess the querstion is if there is a veriyer with no challange what to do. 

We diden't specify that.   I would reject that as a config error or indication of a MIM in the front channel.

I think that is the correct thing to do.

On 6/1/2020 3:11 PM, Mike Jones wrote:

Like Filip and Neil and I believe Ryan, I prefer the dynamic option 2.  It keeps existing clients working when possible, which should be a goal of OAuth 2.1.

 

                                                       Thanks,

                                                       -- Mike

 

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Monday, June 1, 2020 10:54 AM
To: Neil Madden <neil.madden@forgerock.com>
Cc: Daniel Fett <fett@danielfett.de>; oauth@ietf.org; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE

 

Mike: what are your thoughts on the options?

ᐧ

 

On Sat, May 30, 2020 at 4:39 AM Neil Madden <neil.madden@forgerock.com> wrote:

We (ForgeRock) already support solution 1 as a configuration option, but I prefer solution 2 and have raised a ticket for us to implement it. For us at least it’s a trivial fix and seems more robust against configuration errors.

 

— Neil



On 30 May 2020, at 08:58, Daniel Fett <fett@danielfett.de> wrote:

 

Hi all,

 

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that we have two options:

 

1. "Static" Solution

 

For every client_id that is registered with an AS, the AS MUST either always enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or nonce is enforced can be part of the client registration or configured in other ways.

 

In other words: A single client is not allowed to switch between using PKCE and using nonce.

 

Note that the client is allowed to use the respective other mechanism on top of the enforced one.

 

Properties:

  • Easy to understand mitigation.
  • Implementation is mainly a new data field and a check in the authorization request.
  • Not compatible to deployments where clients sometimes use nonce and sometimes use PKCE with the same client_id.

2. "Dynamic" Solution

Each AS that supports PKCE MUST check whether a code challenge is contained in the authorization request. This information MUST be bound to the code that is issued.

When a code arrives at the token endpoint, the AS MUST do the following check:

  1. If there was a code_challenge in the authorization request for which this code was issued, there must be a code_verifier in the token request and it must be verified according to RFC7636. (This is no change from the current behavior in RFC7636.)
  2. If there was no code_challenge in the authorization request, any request to the token endpoint containing a code_verifier MUST be rejected.

Properties:

  • No change in behavior needed for properly implemented clients. Backwards compatible for all existing deployments.
  • Implementation is mainly some logic for the authorization endpoint, token endpoint, and a new data field in the authorization session maintained by the AS.
  • Slightly more complex to implement for the AS, maybe.

We would like to hear the feedback from the working group on these two solutions before proceeding to propose wording for the affected documents.

 

 

-Daniel

 

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

 

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------382AB4311FCE7C7B761940C6-- From nobody Mon Jun 1 21:00:39 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703CF3A080C for ; Mon, 1 Jun 2020 21:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYNtUIv2OdJo for ; Mon, 1 Jun 2020 21:00:35 -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 7547C3A080B for ; Mon, 1 Jun 2020 21:00:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05240Pkj006462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jun 2020 00:00:29 -0400 Date: Mon, 1 Jun 2020 21:00:25 -0700 From: Benjamin Kaduk To: Dmitry Khlebnikov Cc: Naveen Agarwal , Rifaat Shekh-Yusef , "n-sakimura@nri.co.jp" , oauth , RFC Errata System Message-ID: <20200602040025.GJ58497@kduck.mit.edu> References: <20200518100426.ACC2DF40753@rfc-editor.org> <20200523202532.GE58497@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] [Technical Errata Reported] RFC7636 (6179) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 04:00:37 -0000 Hi Dmitry, Thanks for clarifying the motivation. I think it's shifted my stance a bit, to lean more towards classifying as "editorial" (in that the protocol in the RFC itself is not affected) with status of "Hold for document update". -Ben On Tue, Jun 02, 2020 at 12:32:48AM +0000, Dmitry Khlebnikov wrote: > Naveen, > > My concern with that section is that it provides misleading information about salting and that was the primary reason I was recommending to remove it. However, knowing that we cannot amend what was already released as RFC (Unfortunately, somehow I missed the discussion in 2014 when I could have influenced that part), even if we make an errata saying that this part of the RFC is not applicable and one should not even think about applying a salt to a single unique hash the number of people confused and not being aware of the errata is going to be significant. Still, I think it is the right thing to do for those who are seeking for the information. > > What prompted me to write it up (the request for errata) was that in a week I had several people approaching me in regard to this RFC and asking for advice (I am a Senior Security Adviser for one of Australia's largest realestate advertising platforms). This coupled with the overall misunderstanding of salting (a techique against rainbow tables) and peppering (a technique to protect hashes from bruteforcing once the dataset is exfiltrated) of hashes pushed me to reach out. > > -- > Dmitry Khlebnikov > Senioe Security Adviser // REA Group > +61 428 425291 > > ________________________________________ > From: Naveen Agarwal > Sent: Tuesday, 2 June 2020 03:47 > To: Rifaat Shekh-Yusef > Cc: Benjamin Kaduk; Dmitry Khlebnikov; n-sakimura@nri.co.jp; oauth; RFC Errata System > Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179) > > [External Email] > > > As one of the author, writing from my persona email. > > I think at the time someone must have suggested that we should add a salt for the code_verifier before hashing and this was added to explain that there is no need to do that. As Dmitry agreed that salting is not really applicable in this case and I agree that the section could have been written in a better way. But I do think when people try to implement they may ask the same question as they have been told again and again that you should salt your hashes. So leaving it in place doesn't hurt (as it is not making any bad recommendation but not doing a great job justifying why we didn't add salting). > > Thanks > > Naveen > > On Sun, May 31, 2020 at 12:41 PM Rifaat Shekh-Yusef > wrote: > Nat, John, > > Do you guys have any thoughts on this errata? > > Regards, > Rifaat > > > On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk > wrote: > Authors, WG, any comments? > > Right now the likely dispositions seem to me to be Editorial/HFDU or > Rejected; the text is noting that salting is not used and attempting to > give an explanation of why that's the right choice. It's not clear that > the WG was in error to include some such discussion at the time of > publication, which is essentially what this errata report is claiming. > > Thanks, > > Ben > > On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC7636, > > "Proof Key for Code Exchange by OAuth Public Clients". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6179 > > > > -------------------------------------- > > Type: Technical > > Reported by: Dmitry Khlebnikov > > > > > Section: 7.3 > > > > Original Text > > ------------- > > 7.3. Salting the code_challenge > > > > To reduce implementation complexity, salting is not used in the > > production of the code challenge, as the code verifier contains > > sufficient entropy to prevent brute-force attacks. Concatenating a > > publicly known value to a code verifier (containing 256 bits of > > entropy) and then hashing it with SHA256 to produce a code challenge > > would not increase the number of attempts necessary to brute force a > > valid value for code verifier. > > > > While the "S256" transformation is like hashing a password, there are > > important differences. Passwords tend to be relatively low-entropy > > words that can be hashed offline and the hash looked up in a > > dictionary. By concatenating a unique though public value to each > > password prior to hashing, the dictionary space that an attacker > > needs to search is greatly expanded. > > > > Modern graphics processors now allow attackers to calculate hashes in > > real time faster than they could be looked up from a disk.. This > > eliminates the value of the salt in increasing the complexity of a > > brute-force attack for even low-entropy passwords. > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The section misrepresents the information about "salting" and the whole idea > > of "salting" is not applicable to a standalone hash. I suggest to drop the entire > > section as irrelevant to the rest of the standard. > > > > For some reason the section implies that "salting" is protecting and increasing > > entropy of a single hash, which is not what "salting" is about and is not the > > reason for the technique. The section is also making a speculative assumptions > > about the low-entropy tendency in password hashes and makes an incorrect > > conclusion on the benefits of "salting" for a password hash. > > > > One could argue that the entropy and the complexity required to bruteforce a hash > > and a salted hash for the same password (where the same hashing algorithm is > > applied) are approximately the same in most cases (or just slightly more > > complex for the salted version if the producer of the hash used a non-standard > > routine in relation of mixing in the salt, e.g. instead of appending the salt > > it inserts in in the middle of the password to be hashed). In any case, that > > public data is already known to the attacker and it is just a matter of the > > configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate > > the knowledge. > > > > Just as an illustration: consider an example password ('abc'), an example salt > > ('123'), and that the hash is generated using a concatinated version of these > > two (e.g. HASH('abc123')). Since the salt is included with the hash in plain > > text, the bruteforcer would just need to set their tool up with the "^.*123$" > > pattern making the salt essentially a string terminator which is not affecting > > the bruteforce effort in any way). > > > > More and more people I meet are confused about the problem area the "salting" > > technique was invented to address: it is to increase the entropy of a set of > > passwords, so the same password would not result in the same hash value, with > > the primary goal is to prevent attackers to be able to re-use pre-calculated > > hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to > > make it impossible to quickly assess what hashes the attacker should focus on > > (e.g. when you have 1000 hashes and without salts you can easily spot that > > some hashes are the same, which means breaking these one would gain much more > > in comparison to unique hashes in the same set). > > > > This being said, I am suggesting to drop section 7.3 completely as irrelevant, > > since what we currently have is very confusing and seeds unnecessary and > > wrong ideas that "salting" can improve the security of a single hash by itself. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7636 (draft-ietf-oauth-spop-15) > > -------------------------------------- > > Title : Proof Key for Code Exchange by OAuth Public Clients > > Publication Date : September 2015 > > Author(s) : N. Sakimura, Ed., J. Bradley, N. Agarwal > > Category : PROPOSED STANDARD > > Source : Web Authorization Protocol > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jun 2 01:20:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD4B3A0A47 for ; Tue, 2 Jun 2020 01:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cooc83eekjup for ; Tue, 2 Jun 2020 01:20:43 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9673A09D9 for ; Tue, 2 Jun 2020 01:20:42 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d69 with ME id m8Lb2200a4FMSmm038LbhK; Tue, 02 Jun 2020 10:20:40 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 02 Jun 2020 10:20:40 +0200 X-ME-IP: 86.238.65.197 To: Benjamin Kaduk Cc: oauth@ietf.org, Vittorio Bertocci References: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <20200530205522.GV58497@kduck.mit.edu> From: Denis Message-ID: <0c2a52b0-f05b-38c6-6e37-7aacd6c98a24@free.fr> Date: Tue, 2 Jun 2020 10:20:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200530205522.GV58497@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------0AF47E7B1E810AF327DFB3E1" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 08:20:46 -0000 This is a multi-part message in MIME format. --------------0AF47E7B1E810AF327DFB3E1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin, Responses are between the lines. > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: >> Hi Benjamin, >>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: >>>> Since then, I questioned myself how a client would be able to >>>> request an access token that would be *strictly compliant with this >>>> Profile*. >>> I don't understand why this is an interesting question to ask. The >>> access token and interpretation thereof is (AIUI) generally seen as >>> an internal matter between AS and RS, with the client having no need >>> to care about the specifics. >> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not >> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. > Sure. But (in my understanding), in common usage, the contents and > interpretation of the access token is set by common agreement between > AS and RS, with the client serving only as a "dumb" channel for > transporting the token. That is, we're providing a token format that > an RS and AS can agree to use, most likely for all tokens issued by > the AS for that RS. I don't know of any existing mechanisms, or desire > for such mechanisms by deployments, for using a different token format > for different tokens issued by a given AS for a given RS. Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it means that potentially other Profiles could be defined in the future. In the request, there is no parameter for a client to indicate that it wants a JWT conformant to _this_ profile and no parameter either in the response to indicate to the client that it got a JWT that is conformant to _this_ profile. The processing mandated in the document of a request made by a client to an AS only applies for a request conformant to this profile which may or may not include a scope parameter and which may or may not include a "resource" parameter (and, if it does not, shall include an "aud" claim). Currently, it is not possible to make a difference between a JWT request or response conformant to this profile and other JWT requests or responses. > Attempting to have the client provide input that would affect such a > mechanism seems like complexity with no market demand; a "solution in > search of a problem" as it were. Is there some pent-up demand among > OAuth deployments that I'm not aware of? I freely admit to not being > very on top of the broad spectrum of what's deployed... >> 1) A client may wish to obtain an Access Token that corresponds to >> this Profile because, for example, this document mandates the "sub" >> claim to be present". Hence, the content of the Access Token is not >> totally "/an internal matter between AS and RS/". However, I have not >> understood how a client could request an Access Token that >> corresponds to *_this_***Profile, since there is no mandatory >> parameter in the request (both the "scope" parameter and the >> "resource" parameter are optional). In the future, we could define >> _*another*_**Profile. Hence, there is the same question:  How could a >> client request an Access Token that corresponds to *_that >> other_***Profile ? 2) When getting a JWT,  how can the client make >> sure that the access token it got is compliant with this Profile ? >> RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing >> Sometimes, one kind of JWT can be confused for another. If a >> particular kind of JWT is subject to such confusion, that JWT can >> include an explicit JWT type value, and the validation rules can >> specify checking the type (...). Explicit JWT typing is accomplished >> by using the "typ" Header Parameter. Wouldn't be wise to include an >> explicit JWT type value for JWTs conformant to this Profile ? > In the model where the client is a "dumb" communications channel, this > question does not seem interesting. But the related question of "how > can the RS make sure that the access token it got was generated > according to this profile?" does seem interesting, and seems like it > would benefit from the same proposed solution. An explicit JWT type value added both in the JWT request and in the JWT response would solve this problem. >> This relates to an email posted by Dominick Baier under the topic >> "JAR: JWT typ" on May 19 : This has been brought up before - but no >> response. Either I can’t find it - or it is missing. But is the >> setting the JWT typ explicitly mentioned somewhere? > It is fairly likely that I will remember to ask about explicit "typ" > usage if I'm still on the IESG when this document gets there: I think > I've been making a habit of doing so. Once again, an explicit "typ" sould be considered for both the JWT request and the JWT response. This implies that the client "MUST" be able to inspect the content of the access token. Denis > Thanks, Ben --------------0AF47E7B1E810AF327DFB3E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Benjamin,

Responses are between the lines.

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:

Hi Benjamin,

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:

Since then, I questioned myself how a client would be able to request an
access token that would be
*strictly compliant with this Profile*.

I don't understand why this is an interesting question to ask.  The access
token and interpretation thereof is (AIUI) generally seen as an internal
matter between AS and RS, with the client having no need to care about the
specifics.


This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
_*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.


Sure.  But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between AS
and RS, with the client serving only as a "dumb" channel for transporting
the token.  That is, we're providing a token format that an RS and AS can
agree to use, most likely for all tokens issued by the AS for that RS.  I
don't know of any existing mechanisms, or desire for such mechanisms by
deployments, for using a different token format for different tokens issued
by a given AS for a given RS.

Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it means that potentially other Profiles could be defined in the future.
In the request, there is no parameter for a client to indicate that it wants a JWT conformant to this profile and no parameter either
in the response to indicate to the client that it got a JWT that is conformant to this profile.

The processing mandated in the document of a request made by a client to an AS only applies for a request conformant to this profile
which may or may not include a scope parameter and which may or may not include a "resource" parameter (and, if it does not, shall
include an "aud" claim). Currently, it is not possible to make a difference between a JWT request or response conformant to this profile
and other JWT requests or responses. 

                             Attempting to have the client provide input
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.  Is there some
pent-up demand among OAuth deployments that I'm not aware of?  I freely
admit to not being very on top of the broad spectrum of what's deployed...


1) A client may wish to obtain an Access Token that corresponds to this 
Profile because, for example,
this document mandates the "sub" claim to be present". Hence, the 
content of the Access Token is not
totally "/an internal matter between AS and RS/".

However, I have not understood how a client could request an Access 
Token that corresponds to *_this_***Profile,
since there is no mandatory parameter in the request (both the "scope" 
parameter and the "resource" parameter are optional).

In the future, we could define _*another*_**Profile. Hence, there is the 
same question:  How could a client request an Access Token
that corresponds to *_that other_***Profile ?

2) When getting a JWT,  how can the client make sure that the access 
token it got is compliant with this Profile ?

RFC 8725 states in section 3.11 :

    3.11. Use Explicit Typing
    Sometimes, one kind of JWT can be confused for another. If a
    particular kind of JWT is subject to such confusion,
    that JWT can include an explicit JWT type value, and the validation
    rules can specify checking the type (...).
    Explicit JWT typing is accomplished by using the "typ" Header
    Parameter.

Wouldn't be wise to include an explicit JWT type value for JWTs 
conformant to this Profile ?


In the model where the client is a "dumb" communications channel, this
question does not seem interesting.  But the related question of "how can
the RS make sure that the access token it got was generated according to
this profile?" does seem interesting, and seems like it would benefit from
the same proposed solution.

An explicit JWT type value added both in the JWT request and in the JWT response would solve this problem.



This relates to an email posted by Dominick Baier under the topic "JAR: 
JWT typ" on May 19 :

    This has been brought up before - but no response.

    Either I can’t find it - or it is missing. But is the setting the
    JWT typ explicitly mentioned somewhere?


It is fairly likely that I will remember to ask about explicit "typ" usage
if I'm still on the IESG when this document gets there: I think I've been
making a habit of doing so.
Once again, an explicit "typ" sould be considered for both the JWT request and the JWT response.
This implies that the client "MUST" be able to inspect the content of the access token.

Denis



Thanks,

Ben


--------------0AF47E7B1E810AF327DFB3E1-- From nobody Tue Jun 2 01:27:20 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470E73A09FD for ; Tue, 2 Jun 2020 01:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNnF1_qXXRgT for ; Tue, 2 Jun 2020 01:27:16 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EE03A09F5 for ; Tue, 2 Jun 2020 01:27:15 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d69 with ME id m8TC220084FMSmm038TCh5; Tue, 02 Jun 2020 10:27:13 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 02 Jun 2020 10:27:13 +0200 X-ME-IP: 86.238.65.197 To: Benjamin Kaduk Cc: oauth , Aaron Parecki References: <20200531043747.GN58497@kduck.mit.edu> From: Denis Message-ID: <51d9eeac-8d54-0bbe-00f8-1e34b2f6271b@free.fr> Date: Tue, 2 Jun 2020 10:27:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200531043747.GN58497@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------DC39F16A64AF64830AE5C9A6" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request)) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 08:27:18 -0000 This is a multi-part message in MIME format. --------------DC39F16A64AF64830AE5C9A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin and Aaron, Note: This is also a reply to Aaron who wrote: Typically in OAuth it's the authorization server's job to inform users and protect access to their resources. Obviously in order to do that the AS must know about the details of the request. Can you please clarify the scenario in which you would want the AS to have no information about the request that it's authorizing? The start of the answer comes from the text that was inserted in my first email of this thread, which is copied again below: OAuth initially assumed a static relationship between clients, authorization servers and resource servers. The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship. *A key question is whether such strong relationship will be maintained for ever * or whether it will be allowed to perform some evolutions of this relationship. In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is that the AS and the RS do not need any longer to have such a strong relationship. In terms of trust relationships, a RS simply needs to trust the access tokens issued by an AS. The AS does have any more a "need to know" of all the RSs that are accepting its access tokens. This would be a major simplification of the current global architecture. oauth-security-topics states:   The privileges associated with an access token SHOULD be restricted to the minimum required for the particular   application or use case. This means that the client should be able to select *by itself * the claims it would like to be placed into an access token with respect to the operations it is willing to perform on a RS. As long as only the scope request parameter will be usable in an access token request to select the claims to be placed into an access token, it will not be possible to remove this strong relationship. *1° About d**raft-ietf-oauth-rar-01* In draft-ietf-oauth-rar-01, it is acknowledged that the parameter "scope" that allows OAuth clients to specify the requested scope is not sufficient to specify fine-grained authorization requirements. If the OAuth WG believes that the AS and the RS relationship are not necessarily any more *bilateral *but may also be***unilateral*, i.e. an AS may be trusted by several RS, but the ASs do not need to know /in advance/ the RSs, then some evolutions are possible as explained below. A RS must know which attributes from a client are necessary in order to accomplish a given operation.After being informed by the RS of which attributes are necessary in order to accomplish a given operation, a client may request these attributes to any AS that is trusted by the RS for these types of attributes. If the client also has a trust relationship with one or more of these AS, then it may proceed. For example, a  RS may request three attributes to an AS: a "sub" claim which is a value locally unique in the context of the AS or that is globally unique, a home address and an indicator stating whether the user is over 21 years old. If the client finds these three attributes as being acceptable for the kind of operation it is willing to perform on the RS, then it may request these three attributes to one or more appropriate ASs. In this way, the AS does not know which operation(s) will be performed on an AS. Hence, there is no need to define JSON objects with "type" fields such as "account_information" and "payment_initiation" as given as examples in draft-ietf-oauth-rar-01. However, JSON objects able to indicate e.g. a pseudonym, a home address, a family name, a first name, etc ... should be defined. To respond to Aaron, the AS does not need to know the details of the operations that will be performed by a client on a RS but only needs to provide the attributes that are being requested by the client. The job of the RSs is to inform its clients about which attributes are necessary in order to perform a given operation and to indicate which ASs are trusted to provide these attributes. This does not mean that all this information shall necessarily be made publicly available: it may only be available to authenticated clients at the time they are willing to perform a given operation. ASs do not needto know (and hence to control) which attributes are necessary to perform _every_ operation on_every_ RS. Unilateral relationships would make the whole architecture more scalable. *2° About draft-ietf-oauth-jwsreq-22 * draft-ietf-oauth-jwsreq-22 introduces the ability to send request parameters in a JSON Web Token (JWT) which allows the request to be signed with JSON Web Signature (JWS) (...) so that the integrity [and] source authentication (...) property of the Authorization Request is attained. It should be realized that a simpler mechanism could be used in some cases: integrity "protection" of a message is in fact the "detection" of the integrity of a message by a receiver. It is possible to *detect *that the /request /has been modified by observing the /response/, i.e. the content of the JWT. Let us assume that no cryptographic mechanism is used in the request, then when a client receives a JWT, *if it may verify its content*, it may then know whether or not the request parameters have been modified while in transit. For example, if a client requested a pseudonym claim, a home address claim, a family name claim and a first name claim to be present in the JWT, unless an error is reported, it can verify that these claims are indeed present in the JWT. This is another reason why a client should be able to inspect the content of the access token. Denis > On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote: >> As indicated in the abstract: >> >> "This document introduces the ability to send request parameters in >> a JSON Web Token (JWT) instead, >>   which allows the request to be signed with JSON Web Signature (JWS)". >> >> This approach has a major consequence which is not indicated in the >> "Privacy Considerations section: >> the AS will have the knowledge of these request parameters such as >> "please let me make a payment with the amount of 45 Euros" >> or "please give me read access to folder A and write access to file X". >> >> Such an approach has privacy issues which are currently not documented >> in the Privacy Considerations section. >> >> The AS would be in a position to know, not only which resources servers >> are going to be accessed, but also what kind of operations >> are going to be performed by its clients on the resource servers. With >> such an approach, ASs will have a deep knowledge of every >> operation that can be performed by a user on every RS. >> >> As a consequence, the AS would also be in a position to trace the >> actions performed by its users on the resources servers. >> >> Other approaches that are more "privacy friendly" should be considered >> to address the initial problem. > Do you have the start of a list of such other approaches to seed the > discussion? There seemms to be some inherent tension between the > authorization server knowing what it is authorizing and the privacy > properties you are advocating... > > Thanks, > > Ben --------------DC39F16A64AF64830AE5C9A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Benjamin and Aaron,

Note: This is also a reply to Aaron who wrote:
Typically in OAuth it's the authorization server's job to inform users and protect access to their resources.
Obviously in order to do that the AS must know about the details of the request.

Can you please clarify the scenario in which you would want the AS to have no information about the request that it's authorizing?
The start of the answer comes from the text that was inserted in my first email of this thread, which is copied again below:
OAuth initially assumed a static relationship between clients, authorization servers and resource servers.

The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship.

A key question is whether such strong relationship will be maintained for ever or
whether it will be allowed to perform some evolutions of this relationship.

In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is
that the AS and the RS do not need any longer to have such a strong relationship. In terms of trust relationships, a RS
simply needs to trust the access tokens issued by an AS. The AS does have any more a "need to know" of all the RSs
that are accepting its access tokens. This would be a major simplification of the current global architecture.

oauth-security-topics states:

  The privileges associated with an access token SHOULD be restricted to the minimum required for the particular
  application or use case.

This means that the client should be able to select by itself the claims it would like to be placed into an access token
with respect to the operations it is willing to perform on a RS.

As long as only the scope request parameter will be usable in an access token request to select the claims to be placed
into an access token, it will not be possible to remove this strong relationship.

1° About draft-ietf-oauth-rar-01

In draft-ietf-oauth-rar-01, it is acknowledged that the parameter "scope" that allows OAuth clients to specify the requested scope
is not sufficient to specify fine-grained authorization requirements.

If the OAuth WG believes that the AS and the RS relationship are not necessarily any more bilateral but may also be unilateral,
i.e. an AS may be trusted by several RS, but the ASs do not need to know in advance the RSs, then some evolutions are possible
as explained below.

A RS must know which attributes from a client are necessary in order to accomplish a given operation. After being informed by the RS
of which attributes are necessary in order to accomplish a given operation, a client may request these attributes to any AS that is trusted
by the RS for these types of attributes. If the client also has a trust relationship with one or more of these AS, then it may proceed.

For example, a  RS may request three attributes to an AS: a "sub" claim which is a value locally unique in the context of the AS
or that is globally unique, a home address and an indicator stating whether the user is over 21 years old. If the client finds these three attributes
as being acceptable for the kind of operation it is willing to perform on the RS, then it may request these three attributes to one or more
appropriate ASs.

In this way, the AS does not know which operation(s) will be performed on an AS. Hence, there is no need to define JSON objects
with "type" fields such as "account_information" and "payment_initiation" as given as examples in draft-ietf-oauth-rar-01.

However, JSON objects able to indicate e.g. a pseudonym, a home address, a family name, a first name, etc ... should be defined.

To respond to Aaron, the AS does not need to know the details of the operations that will be performed by a client on a RS but only needs to provide
the attributes that are being requested by the client. The job of the RSs is to inform its clients about which attributes are necessary in order to perform
a given operation and to indicate which ASs are trusted to provide these attributes.

This does not mean that all this information shall necessarily be made publicly available: it may only be available to authenticated clients
at the time they are willing to perform a given operation.

ASs do not need to know (and hence to control) which attributes are necessary to perform every operation on every RS.
Unilateral relationships would make the whole architecture more scalable.


2° About draft-ietf-oauth-jwsreq-22

draft-ietf-oauth-jwsreq-22 introduces the ability to send request parameters in a JSON Web Token (JWT) which allows the request to be signed
with JSON Web Signature (JWS) (...) so that the integrity [and] source authentication (...) property of the Authorization Request is attained.

It should be realized that a simpler mechanism could be used in some cases: integrity "protection" of a message is in fact the "detection" of the integrity
of a message by a receiver. It is possible to detect that the request has been modified by observing the response, i.e. the content of the JWT. Let us assume
that no cryptographic mechanism is used in the request, then when a client receives a JWT, if it may verify its content, it may then know whether or not
the request parameters have been modified while in transit. For example, if a client requested a pseudonym claim, a home address claim, a family name
claim and a first name claim to be present in the JWT, unless an error is reported, it can verify that these claims are indeed present in the JWT. 

This is another reason why a client should be able to inspect the content of the access token.
Denis

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:

As indicated in the abstract:

    "This document introduces the ability to send request parameters in
    a JSON Web Token (JWT) instead,
       which allows the request to be signed with JSON Web Signature (JWS)".

This approach has a major consequence which is not indicated in the 
"Privacy Considerations section:
the AS will have the knowledge of these request parameters such as 
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X".

Such an approach has privacy issues which are currently not documented 
in the Privacy Considerations section.

The AS would be in a position to know, not only which resources servers 
are going to be accessed, but also what kind of operations
are going to be performed by its clients on the resource servers. With 
such an approach, ASs will have a deep knowledge of every
operation that can be performed by a user on every RS.

As a consequence, the AS would also be in a position to trace the 
actions performed by its users on the resources servers.

Other approaches that are more "privacy friendly" should be considered 
to address the initial problem.

Do you have the start of a list of such other approaches to seed the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben


--------------DC39F16A64AF64830AE5C9A6-- From nobody Tue Jun 2 02:33:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7633A003D for ; Tue, 2 Jun 2020 02:33:09 -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_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 ranR5oE91MI8 for ; Tue, 2 Jun 2020 02:33:08 -0700 (PDT) Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.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 245013A003B for ; Tue, 2 Jun 2020 02:33:08 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id g3I8jubEDu8TBg3IAjn9Db; Tue, 02 Jun 2020 02:33:07 -0700 X-CMAE-Analysis: v=2.3 cv=Y6qGTSWN c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=zm8yXq-ZAAAA:8 a=npVdL-2ZxAp8NDnCRQwA:9 a=QEXdDO2ut3YA:10 a=axDs-AP9Xeh0hCMQ1f8A:9 a=2jFNRdZuiVSJzA0E:21 a=_W_S_7VecoQA:10 a=00HjG7_zKW9Ns9g_Kk0A:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=FiTvH8tk0901yUyQXKyt:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <5c4c8549-99f2-d10e-74db-66bd655d1c90@connect2id.com> Date: Tue, 2 Jun 2020 12:33:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040506070804000004080506" X-CMAE-Envelope: MS4wfJeWjtkMBIexodhqzxALokeo9d1LI3jhSqbG3yDgaiIJq/T5aIly4VVabUNQ0ORojeZKCWe53znCe6QtQSRBzANPGqdeebIWtR+p/rYH34c7x1KH8qv8 PAjzceBm24c6YCA313wriJzjHJl99L/BUEBzp4tWzYIKMXc9VAIxQhc8 Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 09:33:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040506070804000004080506 Content-Type: multipart/alternative; boundary="------------277AE71992EA67AA4B182DCA" Content-Language: en-US This is a multi-part message in MIME format. --------------277AE71992EA67AA4B182DCA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for laying out the solutions so neatly. We would prefer #2 the "dynamic" solution because it wouldn't require us to do any changes. I've had the impression that the unexpected code_verifier case was somehow covered as an error in RFC 7636 but checked the spec now and apparently it isn't. Vladimir On 30/05/2020 10:58, Daniel Fett wrote: > Hi all, > > Aaron, Dick, Torsten and I today discussed the downgrade attacks on > PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the > conclusion that we have two options: > > *1. "Static" Solution* > > For every client_id that is registered with an AS, the AS MUST either > always enforce the use of PKCE or always enforce the use of nonce. > Whether PKCE or nonce is enforced can be part of the client > registration or configured in other ways. > > In other words: A single client is not allowed to switch between using > PKCE and using nonce. > > Note that the client is allowed to use the respective other mechanism > on top of the enforced one. > > Properties: > > * Easy to understand mitigation. > * Implementation is mainly a new data field and a check in the > authorization request. > * Not compatible to deployments where clients sometimes use nonce > and sometimes use PKCE with the same client_id. * > *** > > ** > > *2. "Dynamic" Solution* > > Each AS that supports PKCE MUST check whether a code challenge is > contained in the authorization request. This information MUST be bound > to the code that is issued. > > When a code arrives at the token endpoint, the AS MUST do the > following check: > > 1. If there was a code_challenge in the authorization request for > which this code was issued, there must be a code_verifier in the > token request and it must be verified according to RFC7636. (This > is no change from the current behavior in RFC7636.) > 2. If there was no code_challenge in the authorization request, any > request to the token endpoint containing a code_verifier MUST be > rejected. > > Properties: > > * No change in behavior needed for properly implemented clients. > Backwards compatible for all existing deployments. > * Implementation is mainly some logic for the authorization > endpoint, token endpoint, and a new data field in the > authorization session maintained by the AS. > * Slightly more complex to implement for the AS, maybe. > > We would like to hear the feedback from the working group on these two > solutions before proceeding to propose wording for the affected documen= ts. > > [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > > -Daniel --------------277AE71992EA67AA4B182DCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks for laying out the solutions so neatly.

We would prefer #2 the "dynamic" solution because it wouldn't require us to do any changes. I've had the impression that the unexpected code_verifier case was somehow covered as an error in RFC 7636 but checked the spec now and apparently it isn't.

Vladimir

On 30/05/2020 10:58, Daniel Fett wrote= :
Hi all,

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that we have two options:

1. "Static" Solution

For every client_id that is registered with an AS, the AS MUST either always enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or nonce is enforced can be part of the client registration or configured in other ways.

In other words: A single client is not allowed to switch between using PKCE and using nonce.

Note that the client is allowed to use the respective other mechanism on top of the enforced one.

Properties:
  • Easy to understand mitigation.
  • Implementation is mainly a new data field and a check in the authorization request.
  • Not compatible to deployments where clients sometimes use nonce and sometimes use PKCE with the same client_id.
    =

2. "Dynamic" Solution

Each AS that supports PKCE MUST check whether a code challenge is contained in the authorization request. This information MUST be bound to the code that is issued.

When a code arrives at the token endpoint, the AS MUST do the following check:

  1. If there was a code_challenge in the authorization request for which this code was issued, there must be a code_verifier in the token request and it must be verified according to RFC7636. (This is no change from the current behavior in RFC7636.)
  2. If there was no code_challenge in the authorization request, any request to the token endpoint containing a code_verifier MUST be rejected.

Properties:

  • No change in behavior needed for properly implemented clients. Backwards compatible for all existing deployments.
  • Implementation is mainly some logic for the authorization endpoint, token endpoint, and a new data field in the authorization session maintained by the AS.
  • Slightly more complex to implement for the AS, maybe.
We would like to hear the feedback from the working group on these two solutions before proceeding to propose wording for the affected documents.

[1] https://danielfett.de/2020/05/16/pkce-= vs-nonce-equivalent-or-not/

-Daniel

--------------277AE71992EA67AA4B182DCA-- --------------ms040506070804000004080506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDIwOTMzMDNaMC8G CSqGSIb3DQEJBDEiBCA9a73jlGyWXwr0C7YpkSH8kZ1qqy4E8dxvO98eONcpDjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAFJGsdCyVhuD5K4V0Tw4zwGecbgInMg+0QQ1RdXGrTjQhhBC leozG8G/+Uw9YgbMrZytbU1oH4UoIZRd0NHE6J/4NmF0SlicyY/p/a1joA4HxJbetHWHLHcV VPfW4E873AWrSMxeZBaEwGP+bmzQ6ifDrJegffJqFYTEQE7oF8ZSgtWDtBwLc//8t/Kfnljk NV8mNy0obh8tW3G4v+7E/DdJAOG//08dRxMo/pw5g4/xEwRShbeN4RehvV6zwpSSqp2fUr+I NnSJ4m+HQqUyZPm7Suhy+THd4WrL6mpJUJkbDmd9hkWI1MvobZotI2JEttlL1K+77oGRAlSZ R1ALlZ8AAAAAAAA= --------------ms040506070804000004080506-- From nobody Tue Jun 2 02:42:17 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB9B3A03F2 for ; Tue, 2 Jun 2020 02:42: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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=surevoip.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UjaZzs49mjT for ; Tue, 2 Jun 2020 02:42:13 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499173A03ED for ; Tue, 2 Jun 2020 02:42:12 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id q15so1027164uaa.5 for ; Tue, 02 Jun 2020 02:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surevoip.co.uk; s=google-20190204; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fsXDX4qobBJfOopj/54EUPFGRxjbTw1gtEMDkuOshuI=; b=ZCjMw7y6N7lTppE/9esS19Ixv3PeBvDCIl7PJLBn1EbD1mv4iSRvHDS2Pz15n7YjEs 88Q2YEnTdASu8yeSpvWymVQfuUjscavwAUdl8/ncbrA+9rNWRySV/3mgZGsNv7m5yZzi UdM/mGKBCmf3K1LuECD00qFu/WXLMA8GucwOIHtqiYALWsAVjKMU4Je58j3OF1m8kwNB jmm5fd7SHtJbKaA4ck3WAcNsiXOJ7NpOtpknJkWkH967hDlC82pS61EktUInVQfTtXfW tM7dzeA7R2L8X16YTjAPpv4mjzVjhbZPAvdqo5DLjcHlAIJCejcuZm0ej1/ExfE+r3il 2CQw== 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=fsXDX4qobBJfOopj/54EUPFGRxjbTw1gtEMDkuOshuI=; b=HOfhN4GZNqgP3Ney6KuvY3YsyEKYY7LWnLmNKnuNljC4cFO+IvotroR60B590jp8gv HDpx4nwtFQ2PUkOagAaZBRneesvnWmAtiqZjro1VZgdE54lG5Ml4DXESVuSntDpKH/ll X0cSpNsOAMZ+ab6U1ZGVf+frYtfRh4JvfjSdYh4sBAfeuj3ZzdsmDcz8dy7tFkPGkiY+ BhM8OQxQASlsWR2637zeLg8S2Ek3t4dEq5F+jMMssHj2HJnJCKaURjBE6s2akrfl6R4d 2nMuAEn2tIyvw10LElocAQqh7KpX4J+htD3ZdLR1md7ntGiY5CslZnJQqsTNM6wv0T7n Lyeg== X-Gm-Message-State: AOAM532KStBzSSgzCKLhc61WXg1rsfvgraf8DzhpeYHuk0tEB8qx+lcs DMmu5uOMZefOM5BrHi+/obE8R/eT36ZbvcipdOZHCxB2b6ECOA== X-Google-Smtp-Source: ABdhPJy9WOgHg2fPhVztUx6MsZY71u1q/3JRFpuz0Y79CDydb0b2DSqOsRQkre2J6F36IllJCGPn5RzVXtqltCeurAg= X-Received: by 2002:ab0:60b2:: with SMTP id f18mr4363501uam.68.1591090930604; Tue, 02 Jun 2020 02:42:10 -0700 (PDT) MIME-Version: 1.0 References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de> <5c4c8549-99f2-d10e-74db-66bd655d1c90@connect2id.com> In-Reply-To: <5c4c8549-99f2-d10e-74db-66bd655d1c90@connect2id.com> From: Gavin Henry Date: Tue, 2 Jun 2020 10:41:59 +0100 Message-ID: To: Vladimir Dzhuvinov Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b977c905a716b93d" Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 09:42:15 -0000 --000000000000b977c905a716b93d Content-Type: text/plain; charset="UTF-8" I note Ory Hydra forces PKCE for all types of clients already. --000000000000b977c905a716b93d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I note Ory Hydra forces=C2=A0PKCE for all types of clients already.<= /div>
--000000000000b977c905a716b93d-- From nobody Tue Jun 2 03:28:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143173A07F5 for ; Tue, 2 Jun 2020 03:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=6K4RH+p3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=6K4RH+p3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsO9C41rbCzz for ; Tue, 2 Jun 2020 03:28:39 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70081.outbound.protection.outlook.com [40.107.7.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2863A07F4 for ; Tue, 2 Jun 2020 03:28:38 -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=FIIElE4uuRlDSD5PYJq+3WMJ5PPAZNSEMmaervLP5Qg=; b=6K4RH+p3Wvi7Ere1uizPwYvTgRW2LfUGH9HSCnz7BGtRIXodqMArS0NwjJwZsDJG1/1v3krtDcgUUmul7ntrxWWXP7ohSt4nk6rXf17YP0x26pwadXlpz2OX9ItH10eC9r9fmJk1lABLF2/bjOR4sSmBYixYvU7H6L2iF63sdRs= Received: from AM7PR04CA0016.eurprd04.prod.outlook.com (2603:10a6:20b:110::26) by AM0PR08MB5059.eurprd08.prod.outlook.com (2603:10a6:208:15c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Tue, 2 Jun 2020 10:28:34 +0000 Received: from AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:110:cafe::58) by AM7PR04CA0016.outlook.office365.com (2603:10a6:20b:110::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 2 Jun 2020 10:28:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT050.mail.protection.outlook.com (10.152.17.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Tue, 2 Jun 2020 10:28:34 +0000 Received: ("Tessian outbound 14e212f6ce41:v57"); Tue, 02 Jun 2020 10:28:34 +0000 X-CR-MTA-TID: 64aa7808 Received: from 420806e47648.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F40D1BF5-AD97-43CF-B035-5E41AFA15936.1; Tue, 02 Jun 2020 10:28:29 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 420806e47648.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 02 Jun 2020 10:28:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C/q8M2SuwbP/ei6zJmZAM/XEMmmX0DZa28jSFMyb+ePz7O18I/29ofaf41RPfW/NfSl8HyXei/bhBtgG68ViAi2WNHeA73G00jnKTPAZsuzvAivqbePxZf2omPUy3dThO7c+0WiimIqnfT+pGJ6e0bg5i1zx/AKAa5uU0UdhuKvsvaaam4ikaNYlSep/yva+7MQgM7LCasGbQlWkCFe4TPjqmumWjreX4tepCaqXHJp8+oA3HUDezIrivaDErTx1iy+Qgsg/wgkVgyZKrQMT241LRyMH3xy2oYJ6dAUJaayexKlBed8CWIRBz6aYaOTzP4vywL5Jt6RyutWcocTCLA== 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=FIIElE4uuRlDSD5PYJq+3WMJ5PPAZNSEMmaervLP5Qg=; b=d7DEapdYs1NLDTjLcAH1oBDo8Xbuu8cyGFXYUDFpyGgFC1m/OmTYhtIRqGRxS0DjId8yFbSvu53elgziZAUtWTP3drzs/0Stfl9HAh4mOZl87e6NNBVAXfUxrsOaQ3bgiFTDrf2VCyWhMi47M4S2rP8hWW2JgSfHaOQC/PTybnFr8ZZucpYsoHne3r0CstNK1FzFhUk0LBFgvwu7jZNaFuxkoWqCdDESoCMQrONu+Ve9vuLc5oxl7AZQ1+u/QqI6689JZ4YUPzOLVdUfD4oT8DRWMXHxSbUPkaV0QiDHgBte5/YoIT9vPw7zyQ4XclLx2F352FvwpESK3lE73stmWA== 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=FIIElE4uuRlDSD5PYJq+3WMJ5PPAZNSEMmaervLP5Qg=; b=6K4RH+p3Wvi7Ere1uizPwYvTgRW2LfUGH9HSCnz7BGtRIXodqMArS0NwjJwZsDJG1/1v3krtDcgUUmul7ntrxWWXP7ohSt4nk6rXf17YP0x26pwadXlpz2OX9ItH10eC9r9fmJk1lABLF2/bjOR4sSmBYixYvU7H6L2iF63sdRs= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3314.eurprd08.prod.outlook.com (2603:10a6:208:60::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.25; Tue, 2 Jun 2020 10:28:27 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3045.024; Tue, 2 Jun 2020 10:28:27 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , Denis CC: Vittorio Bertocci , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Thread-Index: AQHWE1f9z2EgpsdZ60eoi9hyjcl/fqiQWrGAgAAd5wCAF3pgAIAAGgMAgB1ZqWA= Date: Tue, 2 Jun 2020 10:28:27 +0000 Message-ID: References: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 711e8913-dc2d-4307-babe-97d3cdcb86f4.0 x-checkrecipientchecked: true Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.49] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e1730246-05b8-4e8d-d1f5-08d806dfb42e x-ms-traffictypediagnostic: AM0PR08MB3314:|AM0PR08MB5059: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0422860ED4 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: v5pB5TdlSmEjtO8YifbCCpK4HADPcGi208GaNWWBBIoO1MGmmTeB371V8JhHsPA78L8XYiw2yRpRtQAZiO3Mg/ebPBjr5lvEprAjfJ5+2doBb2u4C4xCfQRtghgJnDVqC8ZroX+W/0tzFMNCPFjoe3tNQ274R4IlrQXcv/Mf0ZFZ9llNvuUeMTaTxnfHt4VI6KqR0M/qIQiOulnqbfhJ8UbIg7naI6NajET+E9cDJw4cOfY960SQWfjIaQwnP2LBEwggCemZy4aby/wFzwCpFGi2spjvxbjmLynMCejBFXMFtaKPkowT6vdXJ7IK5gVQU44u9/2/Ej7413nFucw+H86ihJsFdhyuYiS9+5o6kVzClX73PCv8Rfi8ZjaMT2B80pbtPhjCO++cygaAuF7D+fVfruKshhEwBnl3Fk6+WKKdatVHMBAxQlTZ6Awbe2OSxMPoV93gj9aH1riuBMQ0jg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(396003)(346002)(136003)(54906003)(186003)(30864003)(8936002)(110136005)(2906002)(66946007)(76116006)(64756008)(66476007)(66446008)(66556008)(4326008)(316002)(8676002)(966005)(66574014)(5660300002)(166002)(71200400001)(55016002)(53546011)(83380400001)(478600001)(86362001)(52536014)(33656002)(7696005)(18074004)(9686003)(26005)(6506007)(15866825006)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IFqLwBohyXu/i0ixY9Bs82rBARrduHx+fHaJacu1WuRsx74m491VeJAv2pXonCjoA0X6i+7NGharSTZ8CuW56/0a60B2WcnftANYRd9ls8aMaElHamO9N4+wcgTjgyRsxOxY00Skxu7vkjGPERxfA/E2ilgi0b2rABDtlaEBbcZ3GhVDXgVRlPGOu8LWOY2UBYWSSD/Zo5/1Wi5cX9n3LgR+rK7IrG8RzQPzdxZcc3NYucenzi66l5AIplnOxZKo7/LruTxtHhxQ0ANddJxfFEQVt1VFyEnFkfLdf+8ZakRL0x2TAtOBaX/CvdMqjZWqOrpyZFajv4lkEDcD9a4PNb0hBy6RnUoPAvxLP/ivJuTn/gnH0jPImyvbaBV1HvCFJL8N/zUiYSW6AwQGGlYFZyV2/Zd5hJnOI1WBM6sr5xDYRXo+L++oFxrjxPpZg8miAlvyVTibRdLPuVNkccc5o207nFlvwg16tIlSIZ7QRNE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37162721EE1CA10919B22500FA8B0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3314 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(39860400002)(136003)(46966005)(6506007)(33656002)(8676002)(26005)(4326008)(966005)(70586007)(7696005)(66574014)(166002)(70206006)(8936002)(18074004)(36906005)(5660300002)(316002)(55016002)(336012)(86362001)(54906003)(82740400003)(110136005)(47076004)(356005)(9686003)(82310400002)(52536014)(478600001)(53546011)(81166007)(30864003)(83380400001)(186003)(33964004)(2906002)(15866825006)(559001)(579004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 67214632-0c41-4550-a225-08d806dfb00d X-Forefront-PRVS: 0422860ED4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /UR6UD/LXZPLu9SVXhteVmfJ4vXQWIEQECHf8LEThDF0MQEEDbmTnEo1ayCLs5K0y1/gRP683VGhjU77ov2piJfpQT7CrQJOFPp2P7PjRRjv9sBg9OsISwQypCj3XvEKQQN40CEUlOYE7EbAk1wZ6BeDS2Xrlazi/7T6cY4TxRI/82cKSfIk9NiaS+hE/iJt2ZgSeSaWpXXpxbMf83osexWfny2yXWVv3qaLfHXyFp4sJnx6C9kqc/bnz0PeSONywB4aR9VK8MK80ZDZo90YpkvKmKxTJvOdjsfeNHIsNPwSJ9z87pgEAucZj7UBgRy5qUMrtvN2hg+/AG2zQgZ+aN0PzGF3hwMu2P57+HdVPF8hhVF9ykkqSIL+pduksJXqmbU9MbTqA8PvD+GP2y+vfLBgFVQsgwKWFI+GoHpyBeGCRJElMU56u3J8jXjdHffC7PZ/YBzGuXH6MdFle70TMO/QGd6+Bqig99zPfzz3Punw4GCJDJiJAoFl3QzYRlx2 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2020 10:28:34.2576 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e1730246-05b8-4e8d-d1f5-08d806dfb42e 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: AM0PR08MB5059 Archived-At: Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 10:28:45 -0000 --_000_AM0PR08MB37162721EE1CA10919B22500FA8B0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIHRyeSB0byBqdW1wIGluIGhlcmUgaW4gb3JkZXIgdG8gbWFrZSBhIHByb3Bvc2FsIGZv ciB0aGUgdGV4dCBpbiB0aGUgcHJpdmFjeSBjb25zaWRlcmF0aW9uIHNlY3Rpb246DQoNCkZST006 DQo2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QtMDQjc2VjdGlvbi02Pi4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCg0KDQogICBB cyBKV1QgYWNjZXNzIHRva2VucyBjYXJyeSBpbmZvcm1hdGlvbiBieSB2YWx1ZSwgaXQgbm93IGJl Y29tZXMNCiAgIHBvc3NpYmxlIGZvciByZXF1ZXN0b3JzIGFuZCByZWNlaXZlcnMgdG8gZGlyZWN0 bHkgcGVlayBpbnNpZGUgdGhlDQogICB0b2tlbiBjbGFpbXMgY29sbGVjdGlvbi4gIFRoZSBjbGll bnQgTVVTVCBOT1QgaW5zcGVjdCB0aGUgY29udGVudCBvZg0KICAgdGhlIGFjY2VzcyB0b2tlbjog dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyDQogICBtaWdo dCBkZWNpZGUgdG8gY2hhbmdlIHRva2VuIGZvcm1hdCBhdCBhbnkgdGltZSAoZm9yIGV4YW1wbGUg YnkNCiAgIHN3aXRjaGluZyBmcm9tIHRoaXMgcHJvZmlsZSB0byBvcGFxdWUgdG9rZW5zKSBoZW5j ZSBhbnkgbG9naWMgaW4gdGhlDQogICBjbGllbnQgcmVseWluZyBvbiB0aGUgYWJpbGl0eSB0byBy ZWFkIHRoZSBhY2Nlc3MgdG9rZW4gY29udGVudCB3b3VsZA0KICAgYnJlYWsgd2l0aG91dCByZWNv dXJzZS4gIE5vbmV0aGVsZXNzLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkDQogICBub3Qg YXNzdW1lIHRoYXQgY2xpZW50cyB3aWxsIGNvbXBseSB3aXRoIHRoZSBhYm92ZS4gIFdoZW5ldmVy IGNsaWVudA0KICAgYWNjZXNzIHRvIHRoZSBhY2Nlc3MgdG9rZW4gY29udGVudCBwcmVzZW50cyBw cml2YWN5IGlzc3VlcyBmb3IgYQ0KICAgZ2l2ZW4gc2NlbmFyaW8sIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBzaG91bGQgdGFrZSBleHBsaWNpdCBzdGVwcw0KICAgdG8gcHJldmVudCBpdCBhcyBk ZXNjcmliZWQgYmVsb3cuDQoNCiAgIEluIHNjZW5hcmlvcyBpbiB3aGljaCBKV1QgYWNjZXNzIHRv a2VucyBhcmUgYWNjZXNzaWJsZSB0byB0aGUgZW5kDQogICB1c2VyLCBpdCBzaG91bGQgYmUgZXZh bHVhdGVkIHdoZXRoZXIgdGhlIGluZm9ybWF0aW9uIGNhbiBiZSBhY2Nlc3NlZA0KICAgd2l0aG91 dCBwcml2YWN5IHZpb2xhdGlvbnMgKGZvciBleGFtcGxlLCBpZiBhbiBlbmQgdXNlciB3b3VsZCBz aW1wbHkNCiAgIGFjY2VzcyBoaXMgb3IgaGVyIG93biBwZXJzb25hbCBpbmZvcm1hdGlvbikgb3Ig aWYgc3RlcHMgbXVzdCBiZSB0YWtlbg0KICAgdG8gZW5mb3JjZSBjb2ZpZGVudGlhbGl0eS4gIFBv c3NpYmxlIG1lYXN1cmVzIGluY2x1ZGU6IGVuY3J5cHRpbmcgdGhlDQogICBhY2Nlc3MgdG9rZW4s IGVuY3J5cHRpbmcgdGhlIHNlbnNpdGl2ZSBjbGFpbXMsIG9taXR0aW5nIHRoZSBzZW5zaXRpdmUN CiAgIGNsYWltcyBvciBub3QgdXNpbmcgdGhpcyBwcm9maWxlLCBmYWxsaW5nIGJhY2sgb24gb3Bh cXVlIGFjY2Vzcw0KICAgdG9rZW5zLg0KDQogICBJbiBldmVyeSBzY2VuYXJpbywgdGhlIGNvbnRl bnQgb2YgdGhlIEpXVCBhY2Nlc3MgdG9rZW4gd2lsbA0KICAgZXZlbnR1YWxseSBiZSBhY2Nlc3Np YmxlIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIuICBJdCdzIGltcG9ydGFudCB0bw0KICAgZXZhbHVh dGUgd2hldGhlciB0aGUgcmVzb3VyY2Ugc2VydmVyIGdhaW5lZCB0aGUgcHJvcGVyIGVudGl0bGVt ZW50IHRvDQogICBoYXZlIGFjY2VzcyB0byBhbnkgY29udGVudCByZWNlaXZlZCBpbiBmb3JtIG9m IGNsYWltcywgZm9yIGV4YW1wbGUNCiAgIHRocm91Z2ggdXNlciBjb25zZW50IGluIHNvbWUgZm9y bSwgcG9saWNpZXMgYW5kIGFncmVlbWVudHMgd2l0aCB0aGUNCiAgIG9yZ2FuaXphdGlvbiBydW5u aW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMsIGFuZCBzbyBvbi4NCg0KVE86DQoNCjY8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3 dC0wNCNzZWN0aW9uLTY+LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucw0KICAgVGhlIGRlc2lnbiBv ZiBPQXV0aCAyLjAgZW52aXNpb25zIHRoYXQgYWNjZXNzIHRva2VucyBhcmUgY3JlYXRlZCBieQ0K ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCBjb25zdW1lZCBieSByZXNvdXJjZSBzZXJ2ZXJz Lg0KICAgQXMgSldUIGFjY2VzcyB0b2tlbnMsIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 LCBjYXJyeSBpbmZvcm1hdGlvbiBieSB2YWx1ZSwgaXQgaXMNCiAgIHBvc3NpYmxlIGZvciBPQXV0 aCBjbGllbnRzIHRvIHBlZWsgaW5zaWRlIHRoZSBhY2Nlc3MgdG9rZW4uDQogICBXaGlsZSB0aGlz IGlzIHRlY2huaWNhbCBwb3NzaWJsZSwgaXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUN CiAgIE9BdXRoIDIuMCBwcm90b2NvbCBkb2VzIG5vdCBhaW0gdG8gZXhwb3NlIHRoZSBjb250ZW50 IG9mIHRoZQ0KICAgYWNjZXNzIHRva2VuIHRvIHRoZSBjbGllbnQuIFRoZSBhY2Nlc3MgdG9rZW4g aXMgdGhlcmVmb3JlLCBieSBkZXNpZ24sIGNvbnNpZGVyZWQgdG8gYmUNCiAgIG9wYXF1ZSB0byB0 aGUgY2xpZW50Lg0KDQogICBBIG51bWJlciBvZiBjYXNlcyBtYXkgbWFrZSBpdCBkaWZmaWN1bHQg b3IgaW1wb3NzaWJsZSBmb3IgY2xpZW50cyB0bw0KICAgaW5zcGVjdCB0aGUgdG9rZW4sIGZvciBl eGFtcGxlLCB0aGUgYWNjZXNzIHRva2VuIG1heSBiZSBlbmNyeXB0ZWQsDQogICB0aGUgYWNjZXNz IHRva2VuIG1heSBjb250YWluIHZlbmRvci1zcGVjaWZpYyBjbGFpbXMgdGhhdCBoYXZlIG5vdCBi ZWVuDQogICBzdGFuZGFyZGl6ZWQgb3IgaGF2ZSBiZWVuIHN0YW5kYXJkaXplZCBpbiBvdGhlciBj b25zb3J0aWEgbWFraW5nIHBhcnNpbmcNCiAgIG9mIHRoZSB0b2tlbiBkaWZmaWN1bHQuIEFkZGl0 aW9uYWxseSwgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgdGhlDQogICBhY2Nlc3MgdG9rZW4g aXMgY29udmV5ZWQgYnkgdmFsdWUgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbXBsZW1l bnRhdGlvbg0KICAgbWF5IGNoYW5nZSB0aGUgdG9rZW4gZm9ybWF0IGF0IGFueSB0aW1lLg0KDQog ICBJbiBzY2VuYXJpb3Mgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIGZvciB0aGUgY2xpZW50cyB0byBv YnRhaW4gaW5mb3JtYXRpb24NCiAgIHRyYW5zbWl0dGVkIGluIHRoZSBhY2Nlc3MgdG9rZW4sIE9B dXRoIDIuMCB0b2tlbiBpbnRyb3NwZWN0aW9uIG1heSBwcm92aWRlDQogICBhIHVzZWZ1bCB0b29s IHRvIGVuYWJsZSBzdWNoIGZ1bmN0aW9uYWxpdHkgKHByb3BlciBhdXRob3JpemF0aW9uIGFzc3Vt ZWQpLg0KDQogICBJbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0 b2tlbiBtdXN0IG5vdCBiZSByZWFkYWJsZQ0KICAgYnkgY2xpZW50cywgZW5jcnlwdGluZyB0aGUg Y29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuIGlzIFJFQ09NTUVOREVELg0KDQogICBTaW5jZSB0 aGUgY29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuIGlzIGFjY2Vzc2libGUgdG8gdGhlIHJlc291 cmNlIHNlcnZlcg0KICAgaXQgaXMgaW1wb3J0YW50IHRvDQogICBldmFsdWF0ZSB3aGV0aGVyIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgZ2FpbmVkIHRoZSBwcm9wZXIgZW50aXRsZW1lbnQgdG8NCiAgIGhh dmUgYWNjZXNzIHRvIGFueSBjb250ZW50IHJlY2VpdmVkIGluIGZvcm0gb2YgY2xhaW1zLCBmb3Ig ZXhhbXBsZQ0KICAgdGhyb3VnaCB1c2VyIGNvbnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2llcyBh bmQgYWdyZWVtZW50cyB3aXRoIHRoZQ0KICAgb3JnYW5pemF0aW9uIHJ1bm5pbmcgdGhlIGF1dGhv cml6YXRpb24gc2VydmVycywgYW5kIHNvIG9uLiBUaGUgcG9saWNpZXMNCiAgIGFuZCB0aGUgdXNl ciBpbnRlcmZhY2VzIHRvIGVuYWJsZSB0aGlzIHVzZXIgY29uc2VudCBhcmUsIGhvd2V2ZXIsIHBh cnQNCiAgIG9mIGEgc3BlY2lmaWMgZGVwbG95bWVudCBhbmQgdGhlcmVmb3JlIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KSG93IGRvZXMgdGhpcyBzb3VuZD8NCg0KQ2lh bw0KSGFubmVzDQoNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFJpZmFhdCBTaGVraC1ZdXNlZg0KU2VudDogVGh1cnNkYXksIE1heSAxNCwgMjAy MCA4OjAzIFBNDQpUbzogRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NCkNjOiBWaXR0b3JpbyBC ZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICJKU09OIFdlYiBUb2tlbiAoSldU KSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyINCg0KRGVuaXMsDQoNCllvdSBh cmUgcmVoYXNoaW5nIHRoZSBzYW1lIGlzc3VlcyB0aGF0IHlvdSBoYXZlIGFscmVhZHkgZGlzY3Vz c2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgbXVsdGlwbGUgdGltZXMsDQpZb3UgY291bGQgbm90IGdl dCB0aGUgV0cgdG8gYWdyZWUgd2l0aCB5b3VyIHBvaW50cywgYmVjYXVzZSB0aGUgV0cgYmVsaWV2 ZSB0aGF0IHRoaXMgaXNzdWUgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N Cg0KVGhlIGJlc3QgdGhlIGNoYWlycyBjYW4gZG8gYXQgdGhpcyBzdGFnZSBpcyB0byBjYXB0dXJl IHlvdXIgcG9pbnQgaW4gdGhlIHNoZXBoZXJkIHdyaXRlLXVwIHRvIHRoZSBJRVNHLg0KV2UgdGhp bmsgdGhpcyBkb2N1bWVudCBoYXMgdGhlIHN1cHBvcnQgb2YgdGhlIFdHIGFuZCBpcyByZWFkeSB0 byBtb3ZlIGZvcndhcmQuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gVGh1LCBNYXkgMTQs IDIwMjAgYXQgMTI6MjkgUE0gRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMu aWV0ZkBmcmVlLmZyPj4gd3JvdGU6DQpIaSBWaXR0b3JpbywNCg0KSSBhbSByZWZlcnJpbmcgdG8g dGhlIGVtYWlsIHlvdSBzZW50IG9uIEFwcmlsIHRoZSAyOSB0aCB3aGljaCBpcyBjb3BpZWQgYmVs b3cuDQoNCjEpIFlvdSB3cm90ZToNCj4gdGFyZ2V0aW5nIG9mIGFjY2VzcyB0b2tlbnMNCkxldCBt ZSB0aGluayBhYm91dCB0aGF0IGEgYml0IGxvbmdlci4NCkkgYWNrbm93bGVkZ2UgdGhhdCB0aGUg ZGVjaXNpb24gb2YgaW5jbHVkaW5nIGFuIGF1ZGllbmNlIGhhcyB0aGUgZWZmZWN0IG9mIGxldHRp bmcgdGhlIEFTIHRyYWNrIHdoZW4gdGhlIGNsaWVudCBhY2Nlc3NlcyBhIHBhcnRpY3VsYXIgcmVz b3VyY2UsDQpidXQgYXQgdGhlIHNhbWUgdGltZSB0aGF04oCZcyBjb21wbGV0ZWx5IG1haW5zdHJl YW0gYW5kIHZlcnkgbXVjaCBieSBkZXNpZ24gaW4gYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBjYXNl cy4gQXMgc3VjaCwgSSBmaW5kIHRoZSBsYW5ndWFnZQ0KeW91IGFyZSBzdWdnZXN0aW5nIHRvIGJl IHBvdGVudGlhbGx5IGNvbmZ1c2luZywgYXMgaXQgcG9zaXRpb25zIHRoaXMgYXMgYW4gZXhjZXB0 aW9uIHZzIGEgcHJpdmFjeSBwcm90ZWN0aW5nIG1haW5zdHJlYW0gdGhhdCBpcyBpbiBmYWN0IG5v dCBjb21tb24sDQphbmQgYXNjcmliZXMgdG8gdGhlIGNsaWVudCBtb3JlIGxhdGl0dWRlIHRoYW4g SSBiZWxpZXZlIGlzIGxlZ2l0aW1hdGUgdG8gZXhwZWN0IG9yIGdyYW50Lg0KSeKAmWxsIHRyeSB0 byBjb21lIHVwIHdpdGggY29uY2lzZSBsYW5ndWFnZSB0aGF0IGNsYXJpZmllcyB0byB0aGUgcmVh ZGVyIHRoYXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtIGRvZXMgYWxsb3cgQVMgdHJhY2tpbmcuDQpT aW5jZSB0aGUgbGFzdCBkcmFmdCBoYXMgYmVlbiBwdWJsaXNoZWQgb24gdGhlIDI3IHRoLCB5b3Ug aGF2ZSBub3QgcHJvcG9zZWQgYW55ICJjb25jaXNlIGxhbmd1YWdlIHRoYXQgY2xhcmlmaWVzIHRv IHRoZSByZWFkZXINCnRoYXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtIGRvZXMgYWxsb3cgQVMgdHJh Y2tpbmciLg0KDQoyKSBZb3UgYWxzbyB3cm90ZSBhYm91dCB0aGUgInN1YiIgdW5pcXVlbmVzczoN CkFzIGxvbmcgYXMgYW4gaWRlbnRpZmllciBpZGVudGlmaWVzIG9uZSByZXNvdXJjZSBvbmx5LCBp dCBzYXRpc2ZpZXMgdW5pcXVlbmVzcy4gSXQgZG9lc27igJl0IGhhdmUgdG8gYmUgYSBzaW5nbGV0 b24uDQpSRkMgNzUxOSBkZWZpbmVzIGluIHNlY3Rpb24gNC4xLjIgdGhlIHNlbWFudGljcyBvZiB0 aGUgInN1YiIgY2xhaW0gdXNpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZToNClRoZSBzdWJqZWN0 IHZhbHVlIE1VU1QgZWl0aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUg Y29udGV4dCBvZiB0aGUgaXNzdWVyIG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS4NClRoZSB0ZXh0IGRv ZXMgTk9UIHNheSB0aGF0IHRoZSBzdWJqZWN0IHZhbHVlICJNVVNUIGJlIHNjb3BlZCB0byBiZSBs b2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIi4NCkNo YW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgYW4gYWxyZWFkeSBkZWZpbmVkIGNsYWltIGlzIG5vdCBw ZXJtaXR0ZWQuIElmIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUgc3VjaCBhIHNlbWFudGljcyBhdmFp bGFibGUsDQphIG5ldyBjbGFpbSBzaG91bGQgYmUgZGVmaW5lZCAoYW5kIGl0IHdvdWxkIGJlIHZl cnkgbmljZSB0byBoYXZlIGl0ICEpLg0KDQozKSBUaGUgdGV4dCBpcyB0aGUgcHJpdmFjeSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uIHN0YXRlczoNCg0KICAgQWx0aG91Z2ggdGhlIGFiaWxpdHkgdG8g Y29ycmVsYXRlIHJlcXVlc3RzIG1pZ2h0IGJlIHJlcXVpcmVkIGJ5IGRlc2lnbiBpbiBtYW55IHNj ZW5hcmlvcywgdGhlcmUgYXJlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbg0KICAg c2VydmVyIG1pZ2h0IHdhbnQgdG8gcHJldmVudCBjb3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0aGUg ZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KDQpJbiB0aGUgcmVhbCB3b3JsZCwgaXQgaXMgYWxz byBjbGllbnRzIG9yIGVuZC11c2VycyB3aGljaCB3b3VsZCBsaWtlIHRvIHByZXZlbnQgY29ycmVs YXRpb24gdG8gcHJlc2VydmUgdGhlaXIgZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KDQpBIGJl dHRlciBzZW50ZW5jZSB3b3VsZCBiZToNCg0KICAgQWx0aG91Z2ggdGhlIGFiaWxpdHkgdG8gY29y cmVsYXRlIHJlcXVlc3RzIG1pZ2h0IGJlIHJlcXVpcmVkIGJ5IGRlc2lnbiBpbiBtYW55IHNjZW5h cmlvcywgdGhlcmUgYXJlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbg0KICAgc2Vy dmVyIG9yIHRoZSBjbGllbnQgbWlnaHQgd2FudCB0byBwcmV2ZW50IGNvcnJlbGF0aW9uIHRvIHBy ZXNlcnZlIHRoZSBkZXNpcmVkIGxldmVsIG9mIHByaXZhY3kuDQoNCjQpIFRoZSB0ZXh0IGNvbnRp bnVlcyB3aXRoOg0KDQogICBBdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIGNob29zZSBob3cg dG8gYXNzaWduICJzdWIiIHZhbHVlcyBhY2NvcmRpbmcgdG8gdGhlIGxldmVsIG9mIHByaXZhY3kg cmVxdWlyZWQgYnkgZWFjaA0KICAgc2l0dWF0aW9uLiAgRm9yIGluc3RhbmNlOiBpZiBhIHNvbHV0 aW9uIHJlcXVpcmVzIHByZXZlbnRpbmcgdHJhY2tpbmcgIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFj cm9zcyBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLA0KICAgdGhlICBhdXRob3JpemF0aW9uIHNl cnZlciBzaG91bGQgZW5zdXJlIHRoYXQgSldUIGFjY2VzcyB0b2tlbnMgbWVhbnQgZm9yIGRpZmZl cmVudCByZXNvdXJjZSBzZXJ2ZXJzIGhhdmUgZGlzdGluY3QgInN1YiINCiAgIHZhbHVlcyB0aGF0 IGNhbm5vdCBiZSBjb3JyZWxhdGVkIGluIHRoZSBldmVudCBvZiByZXNvdXJjZSBzZXJ2ZXJzIGNv bGx1c2lvbi4NCg0KQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFyZSBub3QgbmVjZXNzYXJpbHkgYWJs ZSB0byBjaG9vc2UgdGhlIGxldmVsIG9mIHByaXZhY3kgcmVxdWlyZWQgYnkgZWFjaCBzaXR1YXRp b24uIFdoZW4gdGhlcmUgYXJlIGRpZmZlcmVudA0Kc2l0dWF0aW9ucyBmb3IgdGhlIHNhbWUgcmVz b3VyY2Ugc2VydmVyLCB0aGUgc2NvcGUgaXMgKHVuZm9ydHVuYXRlbHkgYXQgdGhlIG1vbWVudCkg dGhlIG9ubHkgd2F5IHRvIHNlbGVjdCB0aGUgImxldmVsIG9mIHByaXZhY3kgdGhhdCBpcyByZXF1 aXJlZCIuDQoNClRoZSBleGFtcGxlICgiRm9yIGluc3RhbmNlOiIpIGlzIG9ubHkgYW4gZXhhbXBs ZSB0aGF0IHByb3ZpZGVzIGEgdmFndWUgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBBU3Mgd2hpY2gg aXMgTk9UIGNvbmZvcm1hbnQNCndpdGggdGhlIHNlbWFudGljcyBvZiB0aGUgInN1YiIgY2xhaW0g YXMgZGVmaW5lZCBpbiBSRkMgNzUxOS4NCg0KV2hhdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGhlcmUg YXJlIG5vdCAiZXhhbXBsZXMiIG9yIHdoYXQgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxk IGRvLCBidXQgZXhwbGFuYXRpb25zIGFib3V0IHRoZSBpbXBsaWNhdGlvbnMNCmZvciB0aGUgZW5k LXVzZXIgb3IgZm9yIHRoZSBjbGllbnQgZm9yIHRoZSB2YXJpb3VzIHZhbHVlcyB0aGF0IGNhbiBi ZSBwbGFjZWQgaW50byB0aGUgInN1YiIgY2xhaW0gYnkgYW4gQVMuIFRoZSBwcm9ibGVtIGlzIHdp ZGVyIHRoYXQgc2ltcGx5DQphIGNvbGx1c2lvbiBiZXR3ZWVuIHJlc291cmNlIHNlcnZlcnMsIGJ1 dCBhbHNvIHdpdGggb3RoZXIgc2VydmVycyB0aGF0IERPIE5PVCBwYXJ0aWNpcGF0ZSBpbiBhbnkg T0F1dGggZXhjaGFuZ2UuDQoNClJGQyA2OTczIChQcml2YWN5IENvbnNpZGVyYXRpb25zKSBzdGF0 ZXMgaW4gc2VjdGlvbiA3IDogR3VpZGVsaW5lcw0KVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGd1aWRh bmNlIGZvciBkb2N1bWVudCBhdXRob3JzIGluIHRoZSBmb3JtIG9mIGEgcXVlc3Rpb25uYWlyZSBh Ym91dCBhIHByb3RvY29sIGJlaW5nIGRlc2lnbmVkLg0KVGhlIHF1ZXN0aW9ubmFpcmUgbWF5IGJl IHVzZWZ1bCBhdCBhbnkgcG9pbnQgaW4gdGhlIGRlc2lnbiBwcm9jZXNzLCBwYXJ0aWN1bGFybHkg YWZ0ZXIgZG9jdW1lbnQgYXV0aG9ycyBoYXZlIGRldmVsb3BlZA0KYSBoaWdoLWxldmVsIHByb3Rv Y29sIG1vZGVsIGFzIGRlc2NyaWJlZCBpbiBbUkZDNDEwMV0uDQpPbmUgb2YgdGhlIHF1ZXN0aW9u cyBpczoNCmYuICBDb3JyZWxhdGlvbi4gIERvZXMgdGhlIHByb3RvY29sIGFsbG93IGZvciBjb3Jy ZWxhdGlvbiBvZiBpZGVudGlmaWVycyA/ICBBcmUgdGhlcmUgZXhwZWN0ZWQgd2F5cyB0aGF0IGlu Zm9ybWF0aW9uIGV4cG9zZWQNCmJ5IHRoZSBwcm90b2NvbCB3aWxsIGJlIGNvbWJpbmVkIG9yIGNv cnJlbGF0ZWQgd2l0aCBpbmZvcm1hdGlvbiBvYnRhaW5lZCBvdXRzaWRlIHRoZSBwcm90b2NvbCA/ DQpJdCBpcyBpbXBvcnRhbnQgdG8gcHJvdmlkZSBhbiBhbnN3ZXIgdG8gdGhlc2UgdHdvIHF1ZXN0 aW9ucy4NCg0KSGVyZWFmdGVyIGlzIHNvbWUgdGV4dCB0aGF0IGlzIGZ1bGx5IGNvbmZvcm1hbnQg d2l0aCBSRkMgNzUxOSB3aGljaCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIHByaXZh Y3kgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0Kd2hpY2ggZXhwbGFpbnMgdGhlIGltcGxpY2F0aW9u cyBvZiB0aGUgdHdvIChhbmQgb25seSB0d28pIGZsYXZvdXJzIG9mIHRoZSAic3ViIiBjbGFpbS4N CldoZW4gdGhlIHN1YiBjbGFpbSBjb250YWlucyBhIGxvY2FsbHkgdW5pcXVlIGlkZW50aWZpZXIg aW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciwgdGhpcyBhbGxvd3MgdGhlIHRyYWNraW5nIG9m IHByaW5jaXBhbCBhY3Rpdml0aWVzDQphY3Jvc3MgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycy4N Cg0KV2hlbiB0aGUgc3ViIGNsYWltIGNvbnRhaW5zIGEgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZp ZXIsIHRoaXMgYWxsb3dzIHRvIGNvcnJlbGF0ZSBwcmluY2lwYWwgYWN0aXZpdGllcyBhY3Jvc3Mg bXVsdGlwbGUgcmVzb3VyY2UNCnNlcnZlcnMsIHdoaWxlIGluIGFkZGl0aW9uLCB0aGlzIGdsb2Jh bGx5IHVuaXF1ZSBpZGVudGlmaWVyIG1heSBhbHNvIGFsbG93IHRvIGNvcnJlbGF0ZSB0aGUgcHJp bmNpcGFsIGFjdGl2aXRpZXMgb24gc2VydmVycyB3aGVyZQ0Kbm8gYWNjZXNzIGhhcyBiZWVuIHBl cmZvcm1lZCBieSB0aGUgcHJpbmNpcGFscyB0byB0aGVzZSBzZXJ2ZXJzIGJ1dCB3aGVyZSB0aGUg c2FtZSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYXJlIGJlaW5nIHVzZWQNCmJ5IHRoZXNl IHNlcnZlcnMuDQpEZW5pcw0KVGhhbmtzIERlbmlzIGZvciB0aGUgdGhvcm91Z2ggY29tbWVudGFy eS4NCg0KPiBUaGUgdGl0bGUgb2YgdGhpcyBzcGVjLg0KRml4ZWQsIHRoYW5rcyENCg0KPiBUaGUg Y2xpZW50IE1VU1QgTk9UIGluc3BlY3QgdGhlIGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0b2tlbg0K VGhpcyBpcyByZWFsbHkgYSBzdGlja3kgcG9pbnQuIEkgcmVhbGx5IHdhbnQgdG8gYWNrbm93bGVk Z2UgeW91ciBQb1Ygb24gdGhpcywgYnV0IGF0IHRoZSBzYW1lIHRpbWUgSSBmb3VuZCB0aGlzIHRv IGJlIG9uZSBvZiB0aGUgYmlnZ2VzdCBzb3VyY2VzIG9mIGlzc3VlcyBpbiB0aGUgdXNlIG9mIEpX VCBmb3IgYWNjZXNzIHRva2VucyBoZW5jZSBJIGZlZWwgd2UgcmVhbGx5IG5lZWQgdG8gZ2l2ZSBz b2xpZCBndWlkYW5jZSBoZXJlLiBMZXQgbWUgZXhwYW5kIGZ1cnRoZXIgb24gdGhlIHJlYXNvbmlu ZyBiZWhpbmQgaXQsIGFuZCBwZXJoYXBzIHdlIGNhbiBnZXQgdG8gbGFuZ3VhZ2UgdGhhdCBzYXRp c2ZpZXMgYm90aCBQb1ZzLg0KVG8gbWUgdGhlIGtleSBwb2ludCBpcyB0aGF0IGNsaWVudHMgc2hv dWxkIG5vdCB3cml0ZSBjb2RlIHRoYXQgaW5zcGVjdHMgYWNjZXNzIHRva2Vucy4gVGFraW5nIGEg ZGVwZW5kZW5jeSBvbiB0aGUgYWJpbGl0eSB0byBkbyBzbyBpcyBpZ25vcmluZyBmdW5kYW1lbnRh bCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXJjaGl0ZWN0dXJlIGFuZCByZWxhdGlvbnNoaXBzIGJl dHdlZW4gT0F1dGggcm9sZXMsIGFuZCBzdWdnZXN0cyBhbiBhYmlsaXR5IG9mIHRoZSBjbGllbnQg dG8gdW5kZXJzdGFuZCB0aGUgc2VtYW50aWMgb2YgdGhlIGNvbnRlbnQgdGhhdCBjYW5ub3QgYmUg YXNzdW1lZCBpbiB0aGUgZ2VuZXJhbCBjYXNlLiBJIGV4cGFuZGVkIG9uIHRoZSBkZXRhaWxzIGlu IG15IGZvcm1lciByZXBseSB0byB5b3Ugb24gdGhpcyB0b3BpYywgSSB3b3VsZCByZWNvbW1lbmQg cmVmZXJyaW5nIHRvIGl0LiBDbGllbnRzIHZpb2xhdGluZyB0aGlzIHNpbXBsZSBwcmluY2lwbGUg aGFzIGJlZW4gb25lIG9mIHRoZSBtb3N0IGNvbW1vbiBzb3VyY2VzIG9mIHByb2R1Y3Rpb24gaXNz dWVzIEkgaGFkIHRvIGRlYWwgd2l0aCBpbiB0aGUgcGFzdCBmZXcgeWVhcnMsIGFuZCBvbmUgb2Yg dGhlIGhhcmRlc3QgdG8gcmVtZWRpYXRlIGdpdmVuIHRoYXQgY2xpZW50cyBhcmUgaGFyZCB0byB1 cGRhdGUgYW5kIHNvbWV0aW1lcyB0aGUgdGhpbmdzIHRoZXkgcmVsaWVkIG9uIHdlcmUgaXJyZW1l ZGlhYmx5IGxvc3QuIFRoaXMgaXMgd2h5IEkgYW0gaW5jbGluZWQgdG8gcHV0IGluIGhlcmUgc3Ry b25nIGxhbmd1YWdlLg0KVGhhdCBzYWlkOiBJIGhhdmUgbm90aGluZyBhZ2FpbnN0IGNsaWVudCBk ZXZlbG9wZXJzIGV4YW1pbmluZyBhIG5ldHdvcmsgdHJhY2UgYW5kIGRyYXdpbmcgY29uY2x1c2lv bnMgYmFzZWQgb24gdGhlIGNvbnRlbnQgb2Ygd2hhdCB0aGV5IHNlZS4gVGhhdCBkb2VzbuKAmXQg Y3JlYXRlIGFueSBoYXJkIGRlcGVuZGVuY2llcyBhbmQgaGFzIG5vIGltcGxpY2F0aW9ucyBpbiBy ZXNwZWN0IHRvIGNoYW5nZXMgaW4gdGhlIHNvbHV0aW9uIGJlaGF2aW9yLiBIb3dldmVyIEkgYW0g bm90IHN1cmUgaG93IHRvIHBocmFzZSB0aGF0IGluIHRoZSBzcGVjaWZpY2F0aW9uLCBnaXZlbiB0 aGF0IHJlZmVycmluZyB0byB0aGUgY2xpZW50IGluZXZpdGFibHkgcmVmZXJzIHRvIGl0cyBjb2Rl LiBJIGFtIG9wZW4gdG8gc3VnZ2VzdGlvbnMuDQoNCj4gIDMp4oCmDQpJIGhhdmUgYSBwcmV0dHkg aGFyZCB0aW1lIGZvbGxvd2luZyB0aGUgY2hhaW4gb2YgcmVhc29uaW5nIGluIHRoaXMgc2VjdGlv bi4gTGV0IG1lIGF0dGVtcHQgdG8gdGFja2xlIGl0IHRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3Rh bmRpbmcuDQpJIHRoaW5rIHRoZSBrZXkgbWlnaHQgYmUNCj4gYSBjbGllbnQgc2hvdWxkIGJlIGFi bGUgdG8gY2hvb3NlIHdoZXRoZXIgaXQgd2lzaGVzIHRoZSBzdWIgY2xhaW0gdG8gY29udGFpbiBb Li5dDQpJIGRvbuKAmXQgdGhpbmsgdGhhdCBzaG91bGQgYmUgYSBjaG9pY2UgbGVmdCB0byB0aGUg Y2xpZW50LiBJbiBidXNpbmVzcyBzeXN0ZW1zLCBteSBleHBlcmllbmNlIGlzIHRoYXQgdGhlIHR5 cGUgb2YgaWRlbnRpZmllcnMgdG8gYmUgdXNlZCAod2hlbiB0aGUgSWRQIGdpdmVzIGFueSBjaG9p Y2UgYXQgYWxsKSAgaXMgZXN0YWJsaXNoZWQgYXQgcmVzb3VyY2UgcHJvdmlzaW9uaW5nIHRpbWUu IEkgYW0gbm90IGF3YXJlIG9mIG1lY2hhbmlzbXMgdGhydSB3aGljaCBhIGNsaWVudCBzaWduYWxz IHRoZSBuYXR1cmUgb2YgdGhlIGlkZW50aWZpZXIgdG8gYmUgdXNlZCwgbm9yIHRoYXQgd291bGQg YmUgZnVsbHkgZmVhc2libGUgKHRoZSByZXNvdXJjZSBrbm93cyB3aGF0IGl0IG5lZWRzIHRvIHBl cmZvcm0gaXRzIGZ1bmN0aW9uKS4NCkZ1cnRoZXJtb3JlOg0KPiB3aGljaCBoYXMgbm90aGluZyB0 byBkbyB3aXRoIHVuaXF1ZW5lc3Mgc2luY2UgdGhlIHZhbHVlIGNoYW5nZXMgZm9yIGV2ZXJ5IGdl bmVyYXRlZCB0b2tlbi4NCkFnYWluLCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHdhcyB0b3VjaGVk IG9uIGluIG15IGZvcm1lciByZXBseSB0byB5b3VyIG1lc3NhZ2UuIEFzIGxvbmcgYXMgYW4gaWRl bnRpZmllciBpZGVudGlmaWVzIG9uZSByZXNvdXJjZSBvbmx5LCBpdCBzYXRpc2ZpZXMgdW5pcXVl bmVzcy4gSXQgZG9lc27igJl0IGhhdmUgdG8gYmUgYSBzaW5nbGV0b24uDQpGaW5hbGx5LCB0aGUg c2NvcGUgaXMgb3B0aW9uYWwgKGZvciBnb29kIHJlYXNvbnM6IDFzdCBwYXJ0eSBhbmQgbm9uIGRl bGVnYXRpb24gc2NlbmFyaW9zIGRvbuKAmXQgcmVxdWlyZSBpdCkgaGVuY2UgaXQgY2Fubm90IGJl IHJlbGllZCB1cG9uIGZvciBwcm9wZXJ0aWVzIHRoYXQgc2hvdWxkIGhvbGQgaW4gZXZlcnkgc2Nl bmFyaW8uDQpJbiBzdW1tYXJ5OiBwZXIgdGhlIHByZWNlZGluZyB0aHJlYWQgb24gdGhpcyB0b3Bp YywgdGhlIGNvbnNlbnN1cyB3YXMgdGhhdCB2YXJ5aW5nIHRoZSBzdWIgY29udGVudCB3YXMgYSBz YXRpc2ZhY3Rvcnkgd2F5IG9mIHByb3RlY3RpbmcgYWdhaW5zdCBjb3JyZWxhdGlvbi4gSSBkb27i gJl0IGEgZ3JlZSB0aGF0IGNsaWVudHMgc2hvdWxkIGhhdmUgYSBtZWNoYW5pc20gdG8gcmVxdWVz dCBkaWZmZXJlbnQgc3ViIGZsYXZvcnMsIGFzIHRoYXQgZGVjaXNpb24gc2hvdWxkIGJlIGRvbmUg b3V0IG9mIGJhbmQgYnkgdGhlIEFTIGFuZCBSUzsgYW5kIHRoZSBzY29wZSBpc27igJl0IGFsd2F5 cyBhdmFpbGFibGUgYW55d2F5Lg0KPiB0YXJnZXRpbmcgb2YgYWNjZXNzIHRva2Vucw0KTGV0IG1l IHRoaW5rIGFib3V0IHRoYXQgYSBiaXQgbG9uZ2VyLg0KSSBhY2tub3dsZWRnZSB0aGF0IHRoZSBk ZWNpc2lvbiBvZiBpbmNsdWRpbmcgYW4gYXVkaWVuY2UgaGFzIHRoZSBlZmZlY3Qgb2YgbGV0dGlu ZyB0aGUgQVMgdHJhY2sgd2hlbiB0aGUgY2xpZW50IGFjY2Vzc2VzIGEgcGFydGljdWxhciByZXNv dXJjZSwgYnV0IGF0IHRoZSBzYW1lIHRpbWUgdGhhdOKAmXMgY29tcGxldGVseSBtYWluc3RyZWFt IGFuZCB2ZXJ5IG11Y2ggYnkgZGVzaWduIGluIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgY2FzZXMu IEFzIHN1Y2gsIEkgZmluZCB0aGUgbGFuZ3VhZ2UgeW91IGFyZSBzdWdnZXN0aW5nIHRvIGJlIHBv dGVudGlhbGx5IGNvbmZ1c2luZywgYXMgaXQgcG9zaXRpb25zIHRoaXMgYXMgYW4gZXhjZXB0aW9u IHZzIGEgcHJpdmFjeSBwcm90ZWN0aW5nIG1haW5zdHJlYW0gdGhhdCBpcyBpbiBmYWN0IG5vdCBj b21tb24sIGFuZCBhc2NyaWJlcyB0byB0aGUgY2xpZW50IG1vcmUgbGF0aXR1ZGUgdGhhbiBJIGJl bGlldmUgaXMgbGVnaXRpbWF0ZSB0byBleHBlY3Qgb3IgZ3JhbnQuDQpJ4oCZbGwgdHJ5IHRvIGNv bWUgdXAgd2l0aCBjb25jaXNlIGxhbmd1YWdlIHRoYXQgY2xhcmlmaWVzIHRvIHRoZSByZWFkZXIg dGhhdCB0aGUgY3VycmVudCBtZWNoYW5pc20gZG9lcyBhbGxvdyBBUyB0cmFja2luZy4NCg0KRnJv bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj48bWFpbHRvOmRl bmlzLmlldGZAZnJlZS5mcj4NCkRhdGU6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMjAgYXQgMDk6 MTINClRvOiAib2F1dGhAaWV0Zi5vcmciPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGll dGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBT ZWNvbmQgV0dMQyBvbiAiSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4w IEFjY2VzcyBUb2tlbnMiDQoNCllvdSB3aWxsIGZpbmQgZm91ciBjb21tZW50cyBudW1iZXJlZCAx KSB0byA0KS4NCjEpIFRoZSB0aXRsZSBvZiB0aGlzIHNwZWMuIGlzOg0KDQpKU09OIFdlYiBUb2tl biAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2Vucw0KDQpTbywgdGhpcyBz cGVjLiBpcyBzdXBwb3NlZCB0byBiZSB0YXJnZXRlZCB0byBPQXV0aCAyLjAuICBIb3dldmVyLCB0 aGUgaGVhZGVyIGF0IHRoZSB0b3Agb2YgdGhlIHBhZ2Ugb21pdHMgdG8gbWVudGlvbiBpdC4NCg0K Q3VycmVudGx5LCBpdCBpcyA6DQpJbnRlcm5ldC1EcmFmdCAgICAgICBPQXV0aCBBY2Nlc3MgVG9r ZW4gSldUIFByb2ZpbGUgICAgICAgICAgIEFwcmlsIDIwMjANCkl0IHNob3VsZCByYXRoZXIgYmU6 DQpJbnRlcm5ldC1EcmFmdCAgICAgICBPQXV0aCAyLjAgQWNjZXNzIFRva2VuIEpXVCBQcm9maWxl ICAgICAgICAgICBBcHJpbCAyMDIwDQoNCjIpIFRoZSBmb2xsb3dpbmcgdGV4dCBpcyB3aXRoaW4g c2VjdGlvbiA2Lg0KDQpUaGUgY2xpZW50IE1VU1QgTk9UIGluc3BlY3QgdGhlIGNvbnRlbnQgb2YN CnRoZSBhY2Nlc3MgdG9rZW46IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGhlIHJlc291 cmNlIHNlcnZlcg0KbWlnaHQgZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55IHRp bWUgKGZvciBleGFtcGxlIGJ5DQpzd2l0Y2hpbmcgZnJvbSB0aGlzIHByb2ZpbGUgdG8gb3BhcXVl IHRva2VucykgaGVuY2UgYW55IGxvZ2ljIGluIHRoZQ0KY2xpZW50IHJlbHlpbmcgb24gdGhlIGFi aWxpdHkgdG8gcmVhZCB0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgd291bGQNCmJyZWFrIHdpdGhv dXQgcmVjb3Vyc2UuDQpOb25ldGhlbGVzcywgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZA0K bm90IGFzc3VtZSB0aGF0IGNsaWVudHMgd2lsbCBjb21wbHkgd2l0aCB0aGUgYWJvdmUuDQpJdCBp cyBvZiBhIHByaW1hcnkgaW1wb3J0YW5jZSB0aGF0IGNsaWVudHMgTUFZIGJlIGFibGUgdG8gaW5z cGVjdCB0b2tlbnMgYmVmb3JlIHRyYW5zbWl0dGluZyB0aGVtLg0KVGhlICJNVVNUIE5PVCIgaXMg bm90IGFjY2VwdGFibGUuDQpUaGUgYWJvdmUgdGV4dCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aDoN Cg0KUmVhZGluZyB0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgbWF5IGJlIHVzZWZ1bCBmb3IgdGhl IHVzZXIgdG8gdmVyaWZ5IHRoYXQNCnRoZSBhY2Nlc3MgdG9rZW4gY29udGVudCBtYXRjaGVzIHdp dGggaXRzIGV4cGVjdGF0aW9ucy4gIEhvd2V2ZXIsDQp0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIgbWlnaHQgZGVjaWRlIHRvIGNoYW5nZSB0aGUNCnRva2Vu IGZvcm1hdCBhdCBhbnkgdGltZS4gIFRodXMsIHRoZSBjbGllbnQgc2hvdWxkIG5vdCBleHBlY3Qg dG8gYWx3YXlzIGJlDQppbiBhIHBvc2l0aW9uIHRvIHJlYWQgdGhlIGFjY2VzcyB0b2tlbiBjb250 ZW50Lg0KDQpUaGUgcmVtYWluaW5nIG9mIHRoZSB0ZXh0IGFib3V0IHRoaXMgdG9waWMgaXMgZmlu ZS4NCg0KDQozKSBUaGUgbmV4dCB0b3BpYyBpcyBhYm91dCB0aGUgc3ViIGNsYWltLg0KDQpUaGUg dGV4dCBzdGF0ZXM6DQoNCkFsdGhvdWdoIHRoZSBhYmlsaXR5IHRvIGNvcnJlbGF0ZSByZXF1ZXN0 cyBtaWdodCBiZSByZXF1aXJlZCBieQ0KZGVzaWduIGluIG1hbnkgc2NlbmFyaW9zLCB0aGVyZSBh cmUgc2NlbmFyaW9zIHdoZXJlIHRoZSBhdXRob3JpemF0aW9uDQpzZXJ2ZXIgbWlnaHQgd2FudCB0 byBwcmV2ZW50IGNvcnJlbGF0aW9uIHRvIHByZXNlcnZlIHRoZSBkZXNpcmVkDQpsZXZlbCBvZiBw cml2YWN5LiBBdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIGNob29zZSBob3cgdG8gYXNzaWdu DQpzdWIgdmFsdWVzIGFjY29yZGluZyB0byB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCBi eSBlYWNoDQpzaXR1YXRpb24uDQoNCkkgaGF2ZSBhIHNldCBvZiBxdWVzdGlvbnM6DQoNCiAgMS4g IEhvdyBjYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGNob29zZSBob3cgdG8gYXNzaWduIHN1YiB2 YWx1ZXMgYWNjb3JkaW5nIHRvIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkICJieSBlYWNo IHNpdHVhdGlvbiIgPw0KICAyLiAgSG93IGNhbiBhdXRob3JpemF0aW9uIHNlcnZlcnMga25vdyB0 aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAiYnkgZWFjaCBzaXR1YXRpb24iID8NCiAgMy4g IEhvdyBjYW4gdGhlIHVzZXJzIGJlIGluZm9ybWVkIG9mIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJl cXVpcmVkICJieSBlYWNoIHNpdHVhdGlvbiIgPw0KICA0LiAgSG93IGNhbiB0aGUgdXNlcnMgY29u c2VudCB3aXRoIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkICJieSBlYWNoIHNpdHVhdGlv biIgPw0KQ3VycmVudGx5LCB0aGUgcmVxdWVzdCBNVVNUIGluY2x1ZGUgZWl0aGVyIGEgcmVzb3Vy Y2UgcGFyYW1ldGVyIG9yIGFuIGF1ZCBjbGFpbSBwYXJhbWV0ZXIsIHdoaWxlIGl0IE1BWSBpbmNs dWRlIGEgc2NvcGUgcGFyYW1ldGVyLg0KVGhlIHN5bnRheCBvZiB0aGUgc2NvcGUgcGFyYW1ldGVy IGlzIGEgbGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNhc2Utc2Vuc2l0aXZlIHN0cmluZ3MgKFJG QyA2NzQ5KS4gSXQgaXMgdGh1cyBzdWJqZWN0IHRvIHByaXZhdGUgYWdyZWVtZW50cw0KYmV0d2Vl biBjbGllbnRzIGFuZCBBdXRob3JpemF0aW9uIFNlcnZlcnMuIFNpbmNlIHRoZSBzY29wZSBpcyBi ZWluZyByZXR1cm5lZCwgaXQgaXMgYSBwcmltYXJ5IGltcG9ydGFuY2UgdGhhdCB0aGUgcmV0dXJu ZWQgc2NvcGUgbWF0Y2hlcw0Kd2l0aCBpdHMgZXhwZWN0YXRpb25zIGJlZm9yZSB0cmFuc21pdHRp bmcgdGhlIHRva2VuIHRvIGEgUmVzb3VyY2UgU2VydmVyLg0KDQpJbiB0aGVvcnksIGEgY2xpZW50 IHNob3VsZCBiZSBhYmxlIHRvIGNob29zZSB3aGV0aGVyIGl0IHdpc2hlcyB0aGUgc3ViIGNsYWlt IHRvIGNvbnRhaW4gOg0KDQogICogICBhIGdsb2JhbCB1bmlxdWUgaWRlbnRpZmllciBmb3IgYWxs IEFTcyAoImdsb2JhbGx5IHVuaXF1ZSIpLA0KICAqICAgYSB1bmlxdWUgaWRlbnRpZmllciBmb3Ig ZWFjaCBBUyAoImxvY2FsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIiKSwN CiAgKiAgIGEgZGlmZmVyZW50IHBzZXVkb255bSBmb3IgZWFjaCBSUywgb3INCiAgKiAgIGEgZGlm ZmVyZW50IHBzZXVkb255bSBmb3IgZWFjaCBhdXRob3JpemF0aW9uIHRva2VuIHJlcXVlc3QuDQpU aGUgb25seSB2YXJpYWJsZSBwYXJhbWV0ZXIgdGhhdCBpdCBjYW4gdXNlIGZvciB0aGlzIHB1cnBv c2UgaW4gdGhlIHRva2VuIHJlcXVlc3QgaXMgdGhlIHNjb3BlIHBhcmFtZXRlci4NCg0KUkZDIDc1 MTkgc3RhdGVzIGlzIHNlY3Rpb24gNC4xLjI6DQoNClRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0 aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUg aXNzdWVyDQpvciBiZSBnbG9iYWxseSB1bmlxdWUuDQoNCkl0IGlzIHF1aXRlIGhhcmQgdG8gcmVj b2duaXplIHRoYXQgdGhlIHN1YiBjbGFpbSBpcyBhYmxlIHRvIGNhcnJ5IGEgZGlmZmVyZW50IHBz ZXVkb255bSBmb3IgZWFjaCBSUywgaS5lLiBmb3IgY2FzZSAoYyksIG9yDQphIGRpZmZlcmVudCBw c2V1ZG9ueW0gZm9yIGVhY2ggYXV0aG9yaXphdGlvbiB0b2tlbiByZXF1ZXN0LCBpLmUuIGZvciBj YXNlIChkKSwgd2hpY2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB1bmlxdWVuZXNzDQpzaW5jZSB0 aGUgdmFsdWUgY2hhbmdlcyBmb3IgZXZlcnkgZ2VuZXJhdGVkIHRva2VuLg0KDQpUaGlzIGhhcyBp bXBsaWNhdGlvbnMgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQpGb3IgaW5zdGFuY2U6IGlm IGEgc29sdXRpb24gcmVxdWlyZXMgcHJldmVudGluZyB0cmFja2luZw0KcHJpbmNpcGFsIGFjdGl2 aXRpZXMgYWNyb3NzIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMsIHRoZQ0KYXV0aG9yaXphdGlv biBzZXJ2ZXIgc2hvdWxkIGVuc3VyZSB0aGF0IEpXVCBhY2Nlc3MgdG9rZW5zIG1lYW50IGZvcg0K ZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnMgaGF2ZSBkaXN0aW5jdCBzdWIgdmFsdWVzIHRoYXQg Y2Fubm90IGJlDQpjb3JyZWxhdGVkIGluIHRoZSBldmVudCBvZiByZXNvdXJjZSBzZXJ2ZXJzIGNv bGx1c2lvbi4NCg0KU2luY2UgaXQgYWRkcmVzc2VzIGNhc2UgKGMpLg0KDQphbmQgYWxzbyBhYm91 dCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCjQuYikgU2ltaWxhcmx5OiBpZiBhIHNvbHV0aW9uIHJl cXVpcmVzIHByZXZlbnRpbmcgYSByZXNvdXJjZSBzZXJ2ZXIgZnJvbQ0KY29ycmVsYXRpbmcgdGhl IHByaW5jaXBhbOKAmXMgYWN0aXZpdHkgd2l0aGluIHRoZSByZXNvdXJjZSBpdHNlbGYsIHRoZQ0K YXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGFzc2lnbiBkaWZmZXJlbnQgc3ViIHZhbHVlcyBm b3IgZXZlcnkgSldUDQphY2Nlc3MgdG9rZW4gaXNzdWVkLg0KDQpTaW5jZSBpdCBhZGRyZXNzZXMg Y2FzZSAoZCkuDQoNClRoaXMgbWVhbnMgdGhhdCB0aGUgY3VycmVudCB0ZXh0IHBsYWNlZCBpbiB0 aGUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBhIGdvb2QgYXR0ZW1wdCB0byBh ZGRyZXNzIHRoZSBjYXNlLA0KYnV0IHRoYXQgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmV2aXNlZC4N Cg0KUHJvcG9zZWQgdGV4dCByZXBsYWNlbWVudCBmb3IgYWxsIHRoZSBwcmV2aW91c2x5IHF1b3Rl ZCBzZW50ZW5jZXM6DQoNCkFjY29yZGluZyB0byBSRkMgNzUxOSAoNC4xLjIpOiBUaGUgc3ViamVj dCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBzY29wZWQgdG8gYmUgbG9jYWxseSB1bmlxdWUgaW4gdGhl IGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuDQoNCldoZW4gdGhl IHN1YiBjbGFpbSBjb250YWlucyBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyLCB0aGlzIGFs bG93cyB0byBjb3JyZWxhdGUgcHJpbmNpcGFsIGFjdGl2aXRpZXMgYWNyb3NzIG11bHRpcGxlIHJl c291cmNlIHNlcnZlcnMsIHdoaWxlIGluIGFkZGl0aW9uLA0KdGhpcyBnbG9iYWxseSB1bmlxdWUg aWRlbnRpZmllciBtYXkgYWxzbyBhbGxvdyB0byBjb3JyZWxhdGUgdGhlIHByaW5jaXBhbCBhY3Rp dml0aWVzIG9uIHNlcnZlcnMgd2hlcmUgbm8gYWNjZXNzIGhhcyBiZWVuIHBlcmZvcm1lZCBieSB0 aGUgcHJpbmNpcGFscw0KdG8gdGhlc2Ugc2VydmVycyBidXQgd2hlcmUgdGhlIHNhbWUgZ2xvYmFs bHkgdW5pcXVlIGlkZW50aWZpZXJzIGFyZSBiZWluZyB1c2VkIGJ5IHRoZXNlIHNlcnZlcnMuDQoN CldoZW4gdGhlIHN1YiBjbGFpbSBjb250YWlucyBhIGxvY2FsbHkgdW5pcXVlIGlkZW50aWZpZXIg aW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciwgdGhpcyBhbHNvIGFsbG93cyB0aGUgdHJhY2tp bmcgb2YgcHJpbmNpcGFsIGFjdGl2aXRpZXMgYWNyb3NzIG11bHRpcGxlIHJlc291cmNlIHNlcnZl cnMuDQoNClRoZSBzY29wZSByZXF1ZXN0IHBhcmFtZXRlciBpcyB0aGUgb25seSB3YXkgdG8gaW5m bHVlbmNlIG9uIHRoZSBjb250ZW50IG9mIHRoZSBzdWIgY2xhaW0gcGFyYW1ldGVyLiBJdHMgbWVh bmluZyBpcyBzdWJqZWN0IHRvIGEgcHJpdmF0ZSBhZ3JlZW1lbnQNCmJldHdlZW4gdGhlIGNsaWVu dCBhbmQgdGhlIEFTLCB3aGljaCBtZWFucyB0aGF0IHRoZSB1c2Ugb2YgdGhlIHNjb3BlIHBhcmFt ZXRlciBpcyB0aGUgb25seSB3YXkgdG8gY2hvb3NlIGJldHdlZW4gYSBsb2NhbGx5IHVuaXF1ZSBp ZGVudGlmaWVyDQppbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyIG9yIGEgZ2xvYmFsbHkgdW5p cXVlIGlkZW50aWZpZXIuDQoNClNpbmNlIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgYmVpbmcgcmV0 dXJuZWQsIGl0IGlzIGEgcHJpbWFyeSBpbXBvcnRhbmNlIHRoYXQgdGhlIHJldHVybmVkIHNjb3Bl IG1hdGNoZXMgd2l0aCB0aGUgZXhwZWN0YXRpb25zIG9mIHRoZSBjbGllbnQgYmVmb3JlIHRyYW5z bWl0dGluZw0KdGhlIHRva2VuIHRvIGEgUmVzb3VyY2UgU2VydmVyLg0KDQpIb3dldmVyLCB0aGVy ZSBhcmUgb3RoZXIgY2FzZXMgd2hlcmUgdGhlIGNsaWVudCB3b3VsZCBsaWtlIHRvIGJlIGFibGUg dG8gY2hvb3NlIHdoZXRoZXIgaXQgd2lzaGVzIHRoZSBzdWIgY2xhaW0gdG8gY29udGFpbiA6DQog ICAgLSBhIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggUlMgc28gdGhhdCBkaWZmZXJlbnQg cmVzb3VyY2Ugc2VydmVycyB3aWxsIGJlIHVuYWJsZSB0byBjb3JyZWxhdGUgaXRzIGFjdGl2aXRp ZXMsIG9yDQogICAgLSBhIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggYXV0aG9yaXphdGlv biB0b2tlbiByZXF1ZXN0LCBzbyB0aGF0IHRoZSBzYW1lIHJlc291cmNlIHNlcnZlciBjYW5ub3Qg Y29ycmVsYXRlIGl0cyBhY3Rpdml0aWVzIHBlcmZvcm1lZCBhdCBkaWZmZXJlbnQgaW5zdGFudCBv ZiB0aW1lLg0KDQpDb25zaWRlcmluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBzdWIgY2xhaW0sIHRo ZXNlIHR3byBjYXNlcyBjYW5ub3QgYmUgY3VycmVudGx5IHN1cHBvcnRlZC4NCg0KDQo0KSBUaGUg bmV4dCB0b3BpYyBpcyBhYm91dCB0aGUgdGFyZ2V0aW5nIG9mIGFjY2VzcyB0b2tlbnMNClRleHQg aGFkIGJlZW4gcHJvcG9zZWQgYmVmb3JlIHRoZSBsYXN0IGNvbmZlcmVuY2UgY2FsbC4gVGhlbiwg dGhlIHRvcGljIGhhcyBiZWVuIHByZXNlbnRlZCBhdCB0aGUgdmVyeSBlbmQgb2YgdGhlIGxhc3Qg Y29uZmVyZW5jZSBjYWxsLCBidXQgbm8gdGV4dCBoYXMgYmVlbiBpbmNsdWRlZA0KaW4gdGhlIG5l eHQgZHJhZnQuDQpIZXJlIGlzIGEgcmV2aXNlZCB0ZXh0IGJlIGluY2x1ZGVkIGluIHRoZSBwcml2 YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb246DQpGb3Igc2VjdXJpdHkgcmVhc29ucywgc29tZSBj bGllbnRzIG1heSBiZSB3aWxsaW5nIHRvIHRhcmdldCB0aGVpciBhY2Nlc3MgdG9rZW5zIGJ1dCwg Zm9yIHByaXZhY3kgcmVhc29ucywgbWF5IGJlIHVud2lsbGluZyB0byBkaXNjbG9zZSB0byBBdXRo b3JpemF0aW9uIFNlcnZlcnMNCmFuIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBSZXNvdXJjZSBTZXJ2 ZXJzIHRoZXkgYXJlIGdvaW5nIHRvIGFjY2Vzcywgc28gdGhhdCBBdXRob3JpemF0aW9uIFNlcnZl cnMgd2lsbCBiZSB1bmFibGUgdG8ga25vdyB3aGljaCByZXNvdXJjZXMgc2VydmVycyBhcmUgYmVp bmcgYWNjZXNzZWQuDQpUaGUgZGlzY2xvc3VyZSBvZiB0aGUgUmVzb3VyY2UgU2VydmVycyBuYW1l cyBhbGxvd3MgdGhlIEF1dGhvcml6YXRpb24gU2VydmVycyB0byBsaXN0IGFsbCB0aGUgUmVzb3Vy Y2UgU2VydmVycyBiZWluZyBhY2Nlc3MgYnkgYWxsIGl0cyB1c2VycyBhbmQgaW4gYWRkaXRpb24g dG8gbGlzdCBwYWlycw0Kb2YgKFByaW5jaXBhbCwgUmVzb3VyY2UgU2VydmVycykgd2hpY2ggYWxs b3cgdG8gdHJhY2UgYWxsIHRoZSB1c2VycyBhY2Nlc3NlcyB0byBSZXNvdXJjZSBTZXJ2ZXJzIHBl cmZvcm1lZCB0aHJvdWdoIGEgZ2l2ZW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFdoZW4gYSB0b2tl biBpcyB0YXJnZXRlZCwNCnRoaXMgcHJvZmlsZSBkb2VzIG5vdCBjb250YWluIHByb3Zpc2lvbnMg dG8gYWRkcmVzcyB0aGVzZSB0d28gdGhyZWF0cy4NCg0KRGVuaXMNCkhpIGFsbCwNCg0KVGhpcyBp cyBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgIkpTT04gV2ViIFRva2VuIChK V1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIi4NCg0KSGVyZSBpcyB0aGUg ZG9jdW1lbnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1h Y2Nlc3MtdG9rZW4tand0LTA2DQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIE9B dXRoIG1haWxpbmcgbGlzdCBieSBBcHJpbCAyOSwgMjAyMC4NCg0KUmVnYXJkcywNCiBSaWZhYXQg JiBIYW5uZXMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM0PR08MB37162721EE1CA10919B22500FA8B0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjYxNzYzMjAzOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTYxOTEyNTAzNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjE5MzMyMDAyODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNTMxODU0ODY7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldCBtZSB0cnkg dG8ganVtcCBpbiBoZXJlIGluIG9yZGVyIHRvIG1ha2UgYSBwcm9wb3NhbCBmb3IgdGhlIHRleHQg aW4gdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbiBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5GUk9NOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1l PSJzZWN0aW9uLTYiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA0I3NlY3Rpb24tNiI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpzZWN0aW9uLTYiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj42PC9zcGFu PjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpzZWN0aW9uLTYiPjwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpzZWN0aW9uLTYiPjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+LiZuYnNwOw0KIFByaXZhY3kgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEFzIEpXVCBh Y2Nlc3MgdG9rZW5zIGNhcnJ5IGluZm9ybWF0aW9uIGJ5IHZhbHVlLCBpdCBub3cgYmVjb21lczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgcG9zc2libGUgZm9yIHJlcXVlc3RvcnMgYW5kIHJlY2VpdmVy cyB0byBkaXJlY3RseSBwZWVrIGluc2lkZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRva2Vu IGNsYWltcyBjb2xsZWN0aW9uLiZuYnNwOyBUaGUgY2xpZW50IE1VU1QgTk9UIGluc3BlY3QgdGhl IGNvbnRlbnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBhY2Nlc3MgdG9rZW46IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGhlIHJlc291cmNlIHNlcnZlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgbWlnaHQgZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUg KGZvciBleGFtcGxlIGJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzd2l0Y2hpbmcgZnJvbSB0aGlz IHByb2ZpbGUgdG8gb3BhcXVlIHRva2VucykgaGVuY2UgYW55IGxvZ2ljIGluIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgY2xpZW50IHJlbHlpbmcgb24gdGhlIGFiaWxpdHkgdG8gcmVhZCB0aGUg YWNjZXNzIHRva2VuIGNvbnRlbnQgd291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJyZWFrIHdp dGhvdXQgcmVjb3Vyc2UuJm5ic3A7IE5vbmV0aGVsZXNzLCBhdXRob3JpemF0aW9uIHNlcnZlcnMg c2hvdWxkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBub3QgYXNzdW1lIHRoYXQgY2xpZW50cyB3aWxs IGNvbXBseSB3aXRoIHRoZSBhYm92ZS4mbmJzcDsgV2hlbmV2ZXIgY2xpZW50PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBhY2Nlc3MgdG8gdGhlIGFjY2VzcyB0b2tlbiBjb250ZW50IHByZXNlbnRzIHBy aXZhY3kgaXNzdWVzIGZvciBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBnaXZlbiBzY2VuYXJpbywg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCB0YWtlIGV4cGxpY2l0IHN0ZXBzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyB0byBwcmV2ZW50IGl0IGFzIGRlc2NyaWJlZCBiZWxvdy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJbiBzY2VuYXJpb3MgaW4gd2hpY2ggSldU IGFjY2VzcyB0b2tlbnMgYXJlIGFjY2Vzc2libGUgdG8gdGhlIGVuZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgdXNlciwgaXQgc2hvdWxkIGJlIGV2YWx1YXRlZCB3aGV0aGVyIHRoZSBpbmZvcm1hdGlv biBjYW4gYmUgYWNjZXNzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHdpdGhvdXQgcHJpdmFjeSB2 aW9sYXRpb25zIChmb3IgZXhhbXBsZSwgaWYgYW4gZW5kIHVzZXIgd291bGQgc2ltcGx5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBhY2Nlc3MgaGlzIG9yIGhlciBvd24gcGVyc29uYWwgaW5mb3JtYXRp b24pIG9yIGlmIHN0ZXBzIG11c3QgYmUgdGFrZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRvIGVu Zm9yY2UgY29maWRlbnRpYWxpdHkuJm5ic3A7IFBvc3NpYmxlIG1lYXN1cmVzIGluY2x1ZGU6IGVu Y3J5cHRpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9rZW4sIGVuY3J5cHRp bmcgdGhlIHNlbnNpdGl2ZSBjbGFpbXMsIG9taXR0aW5nIHRoZSBzZW5zaXRpdmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGNsYWltcyBvciBub3QgdXNpbmcgdGhpcyBwcm9maWxlLCBmYWxsaW5nIGJh Y2sgb24gb3BhcXVlIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdG9rZW5zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEluIGV2ZXJ5IHNjZW5hcmlvLCB0aGUgY29u dGVudCBvZiB0aGUgSldUIGFjY2VzcyB0b2tlbiB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBl dmVudHVhbGx5IGJlIGFjY2Vzc2libGUgdG8gdGhlIHJlc291cmNlIHNlcnZlci4mbmJzcDsgSXQn cyBpbXBvcnRhbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV2YWx1YXRlIHdoZXRoZXIgdGhl IHJlc291cmNlIHNlcnZlciBnYWluZWQgdGhlIHByb3BlciBlbnRpdGxlbWVudCB0bzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgaGF2ZSBhY2Nlc3MgdG8gYW55IGNvbnRlbnQgcmVjZWl2ZWQgaW4gZm9y bSBvZiBjbGFpbXMsIGZvciBleGFtcGxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aHJvdWdoIHVz ZXIgY29uc2VudCBpbiBzb21lIGZvcm0sIHBvbGljaWVzIGFuZCBhZ3JlZW1lbnRzIHdpdGggdGhl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvcmdhbml6YXRpb24gcnVubmluZyB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXJzLCBhbmQgc28gb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U Tzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNz LXRva2VuLWp3dC0wNCNzZWN0aW9uLTYiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Njwvc3Bh bj48L2E+LiZuYnNwOw0KIFByaXZhY3kgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBUaGUgZGVzaWduIG9mIE9BdXRoIDIuMCBlbnZpc2lvbnMgdGhhdCBhY2Nlc3MgdG9r ZW5zIGFyZSBjcmVhdGVkIGJ5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YXV0aG9yaXph dGlvbiBzZXJ2ZXJzIGFuZCBjb25zdW1lZCBieSByZXNvdXJjZSBzZXJ2ZXJzLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwO0FzIEpXVCBhY2Nlc3MgdG9rZW5zLCBhcyBkZXNjcmliZWQgaW4g dGhpcyBkb2N1bWVudCwgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0IGlzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBwb3NzaWJsZSBmb3IgT0F1dGggY2xpZW50cyB0byBwZWVrIGluc2lkZSB0 aGUgYWNjZXNzIHRva2VuLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1doaWxlIHRoaXMg aXMgdGVjaG5pY2FsIHBvc3NpYmxlLCBpdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgT0F1dGggMi4wIHByb3RvY29sIGRvZXMgbm90IGFpbSB0byBl eHBvc2UgdGhlIGNvbnRlbnQgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9r ZW4gdG8gdGhlIGNsaWVudC4gVGhlIGFjY2VzcyB0b2tlbiBpcyB0aGVyZWZvcmUsIGJ5IGRlc2ln biwgY29uc2lkZXJlZCB0byBiZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO29wYXF1ZSB0 byB0aGUgY2xpZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBu dW1iZXIgb2YgY2FzZXMgbWF5IG1ha2UgaXQgZGlmZmljdWx0IG9yIGltcG9zc2libGUgZm9yIGNs aWVudHMgdG8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtpbnNwZWN0IHRoZSB0b2tlbiwg Zm9yIGV4YW1wbGUsIHRoZSBhY2Nlc3MgdG9rZW4gbWF5IGJlIGVuY3J5cHRlZCwNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgYWNjZXNzIHRva2VuIG1heSBjb250YWluIHZlbmRvci1z cGVjaWZpYyBjbGFpbXMgdGhhdCBoYXZlIG5vdCBiZWVuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7c3RhbmRhcmRpemVkIG9yIGhhdmUgYmVlbiBzdGFuZGFyZGl6ZWQgaW4gb3RoZXIgY29u c29ydGlhIG1ha2luZyBwYXJzaW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgdGhl IHRva2VuIGRpZmZpY3VsdC4gQWRkaXRpb25hbGx5LCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhh dCB0aGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDthY2Nlc3MgdG9rZW4gaXMgY29udmV5 ZWQgYnkgdmFsdWUgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgbWF5IGNoYW5nZSB0aGUgdG9rZW4gZm9ybWF0IGF0IGFueSB0 aW1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSW4gc2NlbmFyaW9z IHdoZXJlIGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlIGNsaWVudHMgdG8gb2J0YWluIGluZm9ybWF0 aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJhbnNtaXR0ZWQgaW4gdGhlIGFjY2Vz cyB0b2tlbiwgT0F1dGggMi4wIHRva2VuIGludHJvc3BlY3Rpb24gbWF5IHByb3ZpZGUNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDthIHVzZWZ1bCB0b29sIHRvIGVuYWJsZSBzdWNoIGZ1bmN0 aW9uYWxpdHkgKHByb3BlciBhdXRob3JpemF0aW9uIGFzc3VtZWQpLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtJbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIGNvbnRl bnQgb2YgdGhlIGFjY2VzcyB0b2tlbiBtdXN0IG5vdCBiZSByZWFkYWJsZQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwO2J5IGNsaWVudHMsIGVuY3J5cHRpbmcgdGhlIGNvbnRlbnQgb2YgdGhl IGFjY2VzcyB0b2tlbiBpcyBSRUNPTU1FTkRFRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7U2luY2UgdGhlIGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0 b2tlbiBpcyBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGl0IGlzIGltcG9ydGFudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXZhbHVhdGUg d2hldGhlciB0aGUgcmVzb3VyY2Ugc2VydmVyIGdhaW5lZCB0aGUgcHJvcGVyIGVudGl0bGVtZW50 IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBoYXZlIGFjY2VzcyB0byBhbnkgY29udGVudCByZWNl aXZlZCBpbiBmb3JtIG9mIGNsYWltcywgZm9yIGV4YW1wbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHRocm91Z2ggdXNlciBjb25zZW50IGluIHNvbWUgZm9ybSwgcG9saWNpZXMgYW5kIGFncmVlbWVu dHMgd2l0aCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9yZ2FuaXphdGlvbiBydW5uaW5nIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcnMsIGFuZCBzbyBvbi4gVGhlIHBvbGljaWVzDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIHRoZSB1c2VyIGludGVyZmFjZXMgdG8gZW5hYmxlIHRo aXMgdXNlciBjb25zZW50IGFyZSwgaG93ZXZlciwgcGFydA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwO29mIGEgc3BlY2lmaWMgZGVwbG95bWVudCBhbmQgdGhlcmVmb3JlIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRvZXMgdGhp cyBzb3VuZD8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYg T2YgPC9iPg0KUmlmYWF0IFNoZWtoLVl1c2VmPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBN YXkgMTQsIDIwMjAgODowMyBQTTxicj4NCjxiPlRvOjwvYj4gRGVuaXMgJmx0O2RlbmlzLmlldGZA ZnJlZS5mciZndDs8YnI+DQo8Yj5DYzo8L2I+IFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jp by5iZXJ0b2NjaUBhdXRoMC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAo SldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZW5pcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgcmVoYXNoaW5nIHRoZSBzYW1lIGlzc3Vl cyB0aGF0IHlvdSBoYXZlIGFscmVhZHkgZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgbXVs dGlwbGUgdGltZXMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Zb3UgY291bGQgbm90IGdldCB0aGUgV0cgdG8gYWdyZWUgd2l0aCB5b3VyIHBvaW50 cywgYmVjYXVzZSB0aGUgV0cgYmVsaWV2ZSZuYnNwO3RoYXQgdGhpcyBpc3N1ZSBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYmVzdCB0aGUgY2hhaXJzIGNhbiBkbyBhdCB0 aGlzIHN0YWdlIGlzIHRvIGNhcHR1cmUgeW91ciBwb2ludCBpbiB0aGUgc2hlcGhlcmQgd3JpdGUt dXAgdG8gdGhlIElFU0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSB0aGluayB0aGlzIGRvY3VtZW50IGhhcyB0aGUgc3VwcG9ydCBvZiB0aGUg V0cgYW5kIGlzIHJlYWR5IHRvIG1vdmUmbmJzcDtmb3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBNYXkgMTQsIDIwMjAgYXQgMTI6MjkgUE0gRGVuaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkZW5p cy5pZXRmQGZyZWUuZnIiPmRlbmlzLmlldGZAZnJlZS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBWaXR0b3Jpbyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgYW0gcmVmZXJyaW5nIHRvIHRoZSBlbWFpbCB5b3Ugc2VudCBvbiBB cHJpbCB0aGUgMjkgdGggd2hpY2ggaXMgY29waWVkIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIFlvdSB3cm90ZTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgdGFyZ2V0aW5nIG9mIGFjY2VzcyB0b2tlbnM8L3NwYW4+PC9pPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TGV0IG1lIHRoaW5rIGFib3V0IHRoYXQgYSBiaXQg bG9uZ2VyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSBhY2tub3ds ZWRnZSB0aGF0IHRoZSBkZWNpc2lvbiBvZiBpbmNsdWRpbmcgYW4gYXVkaWVuY2UgaGFzIHRoZSBl ZmZlY3Qgb2YgbGV0dGluZyB0aGUgQVMgdHJhY2sgd2hlbiB0aGUgY2xpZW50IGFjY2Vzc2VzIGEg cGFydGljdWxhciByZXNvdXJjZSwNCjxicj4NCmJ1dCBhdCB0aGUgc2FtZSB0aW1lIHRoYXTigJlz IGNvbXBsZXRlbHkgbWFpbnN0cmVhbSBhbmQgdmVyeSBtdWNoIGJ5IGRlc2lnbiBpbiBhIHZlcnkg bGFyZ2UgbnVtYmVyIG9mIGNhc2VzLiBBcyBzdWNoLCBJIGZpbmQgdGhlIGxhbmd1YWdlDQo8YnI+ DQp5b3UgYXJlIHN1Z2dlc3RpbmcgdG8gYmUgcG90ZW50aWFsbHkgY29uZnVzaW5nLCBhcyBpdCBw b3NpdGlvbnMgdGhpcyBhcyBhbiBleGNlcHRpb24gdnMgYSBwcml2YWN5IHByb3RlY3RpbmcgbWFp bnN0cmVhbSB0aGF0IGlzIGluIGZhY3Qgbm90IGNvbW1vbiwNCjxicj4NCmFuZCBhc2NyaWJlcyB0 byB0aGUgY2xpZW50IG1vcmUgbGF0aXR1ZGUgdGhhbiBJIGJlbGlldmUgaXMgbGVnaXRpbWF0ZSB0 byBleHBlY3Qgb3IgZ3JhbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPknigJlsbCB0cnkgdG8gY29tZSB1cCB3aXRoIGNvbmNpc2UgbGFuZ3VhZ2UgdGhhdCBj bGFyaWZpZXMgdG8gdGhlIHJlYWRlciB0aGF0IHRoZSBjdXJyZW50IG1lY2hhbmlzbSBkb2VzIGFs bG93IEFTIHRyYWNraW5nPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LiAmbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNl IHRoZSBsYXN0IGRyYWZ0IGhhcyBiZWVuIHB1Ymxpc2hlZCBvbiB0aGUgMjcgdGgsIHlvdSBoYXZl IG5vdCBwcm9wb3NlZCBhbnkgJnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmNvbmNpc2Ug bGFuZ3VhZ2UgdGhhdCBjbGFyaWZpZXMgdG8gdGhlIHJlYWRlcg0KPGJyPg0KdGhhdCB0aGUgY3Vy cmVudCBtZWNoYW5pc20gZG9lcyBhbGxvdyBBUyB0cmFja2luZzwvc3Bhbj4mcXVvdDsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIFlvdSBh bHNvIHdyb3RlIGFib3V0IHRoZSAmcXVvdDtzdWImcXVvdDsgdW5pcXVlbmVzczo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgbG9uZyBhcyBh biBpZGVudGlmaWVyIGlkZW50aWZpZXMgb25lIHJlc291cmNlIG9ubHksIGl0IHNhdGlzZmllcyB1 bmlxdWVuZXNzLiBJdCBkb2VzbuKAmXQgaGF2ZSB0byBiZSBhIHNpbmdsZXRvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJGQyA3NTE5IGRlZmluZXMgaW4gc2VjdGlvbiA0LjEuMiB0aGUgc2VtYW50aWNzIG9mIHRoZSAm cXVvdDtzdWImcXVvdDsgY2xhaW0gdXNpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHN1YmplY3QgdmFsdWUgTVVTVCBl aXRoZXIgYmUgc2NvcGVkIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRo ZSBpc3N1ZXIgb3IgYmUgZ2xvYmFsbHkgdW5pcXVlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRleHQgZG9lcyBO T1Qgc2F5IHRoYXQgdGhlIHN1YmplY3QgdmFsdWUgJnF1b3Q7TVVTVCBiZSBzY29wZWQgdG8gYmUg bG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlDQo8Yj5yZXNvdXJjZSBzZXJ2ZXI8 L2I+JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiBhbiBhbHJlYWR5IGRlZmluZWQgY2xhaW0g aXMgbm90IHBlcm1pdHRlZC4gSWYgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZSBzdWNoIGEgc2VtYW50 aWNzIGF2YWlsYWJsZSwNCjxicj4NCmEgbmV3IGNsYWltIHNob3VsZCBiZSBkZWZpbmVkIChhbmQg aXQgd291bGQgYmUgdmVyeSBuaWNlIHRvIGhhdmUgaXQgISkuIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBUaGUgdGV4dCBpcyB0aGUgcHJp dmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHN0YXRlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEFsdGhvdWdoIHRo ZSBhYmlsaXR5IHRvIGNvcnJlbGF0ZSByZXF1ZXN0cyBtaWdodCBiZSByZXF1aXJlZCBieSBkZXNp Z24gaW4gbWFueSBzY2VuYXJpb3MsIHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIGF1dGhv cml6YXRpb248YnI+DQombmJzcDsmbmJzcDsgc2VydmVyIG1pZ2h0IHdhbnQgdG8gcHJldmVudCBj b3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0aGUgZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRo ZSByZWFsIHdvcmxkLCBpdCBpcyBhbHNvIGNsaWVudHMgb3IgZW5kLXVzZXJzIHdoaWNoIHdvdWxk IGxpa2UgdG8gcHJldmVudCBjb3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0aGVpciBkZXNpcmVkIGxl dmVsIG9mIHByaXZhY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkEgYmV0dGVyIHNlbnRlbmNlIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IEFsdGhvdWdoIHRoZSBhYmlsaXR5IHRvIGNvcnJlbGF0ZSByZXF1ZXN0cyBtaWdodCBiZSByZXF1 aXJlZCBieSBkZXNpZ24gaW4gbWFueSBzY2VuYXJpb3MsIHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hl cmUgdGhlIGF1dGhvcml6YXRpb248YnI+DQombmJzcDsmbmJzcDsgc2VydmVyIDxiPm9yIHRoZSBj bGllbnQ8L2I+IG1pZ2h0IHdhbnQgdG8gcHJldmVudCBjb3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0 aGUgZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NCkgVGhlIHRleHQgY29udGludWVz IHdpdGg6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyBBdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIGNob29zZSBob3cg dG8gYXNzaWduICZxdW90O3N1YiZxdW90OyB2YWx1ZXMgYWNjb3JkaW5nIHRvIHRoZSBsZXZlbCBv ZiBwcml2YWN5IHJlcXVpcmVkIGJ5IGVhY2g8YnI+DQombmJzcDsmbmJzcDsgc2l0dWF0aW9uLiZu YnNwOyBGb3IgaW5zdGFuY2U6IGlmIGEgc29sdXRpb24gcmVxdWlyZXMgcHJldmVudGluZyB0cmFj a2luZyZuYnNwOyBwcmluY2lwYWwgYWN0aXZpdGllcyBhY3Jvc3MgbXVsdGlwbGUgcmVzb3VyY2Ug c2VydmVycywNCjxicj4NCiZuYnNwOyZuYnNwOyB0aGUmbmJzcDsgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgc2hvdWxkIGVuc3VyZSB0aGF0IEpXVCBhY2Nlc3MgdG9rZW5zIG1lYW50IGZvciBkaWZmZXJl bnQgcmVzb3VyY2Ugc2VydmVycyBoYXZlIGRpc3RpbmN0ICZxdW90O3N1YiZxdW90Ow0KPGJyPg0K Jm5ic3A7Jm5ic3A7IHZhbHVlcyB0aGF0IGNhbm5vdCBiZSBjb3JyZWxhdGVkIGluIHRoZSBldmVu dCBvZiByZXNvdXJjZSBzZXJ2ZXJzIGNvbGx1c2lvbi4mbmJzcDsgPG86cD4NCjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9yaXphdGlvbiBzZXJ2 ZXJzIGFyZSBub3QgbmVjZXNzYXJpbHkgYWJsZSB0byBjaG9vc2UgdGhlIGxldmVsIG9mIHByaXZh Y3kgcmVxdWlyZWQgYnkgZWFjaCBzaXR1YXRpb24uIFdoZW4gdGhlcmUgYXJlIGRpZmZlcmVudA0K PGJyPg0Kc2l0dWF0aW9ucyBmb3IgdGhlIHNhbWUgcmVzb3VyY2Ugc2VydmVyLCB0aGUgc2NvcGUg aXMgKHVuZm9ydHVuYXRlbHkgYXQgdGhlIG1vbWVudCkgdGhlIG9ubHkgd2F5IHRvIHNlbGVjdCB0 aGUgJnF1b3Q7bGV2ZWwgb2YgcHJpdmFjeSB0aGF0IGlzIHJlcXVpcmVkJnF1b3Q7LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZXhhbXBs ZSAoJnF1b3Q7Rm9yIGluc3RhbmNlOiZxdW90OykgaXMgb25seSBhbiBleGFtcGxlIHRoYXQgcHJv dmlkZXMgYSB2YWd1ZSByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIEFTcyB3aGljaCBpcyBOT1QgY29u Zm9ybWFudDxicj4NCndpdGggdGhlIHNlbWFudGljcyBvZiB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNs YWltIGFzIGRlZmluZWQgaW4gUkZDIDc1MTkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgc2hvdWxkIGJlIGRpc2N1c3NlZCBoZXJlIGFy ZSBub3QgJnF1b3Q7ZXhhbXBsZXMmcXVvdDsgb3Igd2hhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZl ciBzaG91bGQgZG8sIGJ1dCBleHBsYW5hdGlvbnMgYWJvdXQgdGhlIGltcGxpY2F0aW9ucw0KPGJy Pg0KZm9yIHRoZSBlbmQtdXNlciBvciBmb3IgdGhlIGNsaWVudCBmb3IgdGhlIHZhcmlvdXMgdmFs dWVzIHRoYXQgY2FuIGJlIHBsYWNlZCBpbnRvIHRoZSAmcXVvdDtzdWImcXVvdDsgY2xhaW0gYnkg YW4gQVMuIFRoZSBwcm9ibGVtIGlzIHdpZGVyIHRoYXQgc2ltcGx5DQo8YnI+DQphIGNvbGx1c2lv biBiZXR3ZWVuIHJlc291cmNlIHNlcnZlcnMsIGJ1dCBhbHNvIHdpdGggb3RoZXIgc2VydmVycyB0 aGF0IERPIE5PVCBwYXJ0aWNpcGF0ZSBpbiBhbnkgT0F1dGggZXhjaGFuZ2UuDQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDY5NzMgKFBy aXZhY3kgQ29uc2lkZXJhdGlvbnMpIHN0YXRlcyBpbiBzZWN0aW9uIDcgOiBHdWlkZWxpbmVzPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2VjdGlvbiBwcm92aWRl cyBndWlkYW5jZSBmb3IgZG9jdW1lbnQgYXV0aG9ycyBpbiB0aGUgZm9ybSBvZiBhIHF1ZXN0aW9u bmFpcmUgYWJvdXQgYSBwcm90b2NvbCBiZWluZyBkZXNpZ25lZC4mbmJzcDsNCjxicj4NClRoZSBx dWVzdGlvbm5haXJlIG1heSBiZSB1c2VmdWwgYXQgYW55IHBvaW50IGluIHRoZSBkZXNpZ24gcHJv Y2VzcywgcGFydGljdWxhcmx5IGFmdGVyIGRvY3VtZW50IGF1dGhvcnMgaGF2ZSBkZXZlbG9wZWQN Cjxicj4NCmEgaGlnaC1sZXZlbCBwcm90b2NvbCBtb2RlbCBhcyBkZXNjcmliZWQgaW4gW1JGQzQx MDFdLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T25lIG9mIHRoZSBxdWVzdGlvbnMgaXM6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmYuJm5ic3A7IDxiPkNvcnJlbGF0aW9uPC9iPi4mbmJzcDsgRG9lcyB0aGUgcHJvdG9j b2wgYWxsb3cgZm9yIGNvcnJlbGF0aW9uIG9mIGlkZW50aWZpZXJzID8mbmJzcDsgQXJlIHRoZXJl IGV4cGVjdGVkIHdheXMgdGhhdCBpbmZvcm1hdGlvbiBleHBvc2VkDQo8YnI+DQpieSB0aGUgcHJv dG9jb2wgd2lsbCBiZSBjb21iaW5lZCBvciA8Yj5jb3JyZWxhdGVkIHdpdGggaW5mb3JtYXRpb24g b2J0YWluZWQgb3V0c2lkZSB0aGUgcHJvdG9jb2w8L2I+ID88bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGltcG9y dGFudCB0byBwcm92aWRlIGFuIGFuc3dlciB0byB0aGVzZSB0d28gcXVlc3Rpb25zLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlYWZ0ZXIg aXMgc29tZSB0ZXh0IHRoYXQgaXMgZnVsbHkgY29uZm9ybWFudCB3aXRoIFJGQyA3NTE5IHdoaWNo IHNob3VsZCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uDQo8YnI+DQp3aGljaCBleHBsYWlucyB0aGUgaW1wbGljYXRpb25zIG9mIHRoZSB0d28g KGFuZCBvbmx5IHR3bykgZmxhdm91cnMgb2YgdGhlICZxdW90O3N1YiZxdW90OyBjbGFpbS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiB0 aGUgc3ViIGNsYWltIGNvbnRhaW5zIGEgbG9jYWxseSB1bmlxdWUgaWRlbnRpZmllciBpbiB0aGUg Y29udGV4dCBvZiB0aGUgaXNzdWVyLCB0aGlzIGFsbG93cyB0aGUgdHJhY2tpbmcgb2YgcHJpbmNp cGFsIGFjdGl2aXRpZXMNCjxicj4NCmFjcm9zcyBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVu IHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllciwgdGhp cyBhbGxvd3MgdG8gY29ycmVsYXRlIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBs ZSByZXNvdXJjZQ0KPGJyPg0Kc2VydmVycywgd2hpbGUgaW4gYWRkaXRpb24sIHRoaXMgZ2xvYmFs bHkgdW5pcXVlIGlkZW50aWZpZXIgbWF5IGFsc28gYWxsb3cgdG8gY29ycmVsYXRlIHRoZSBwcmlu Y2lwYWwgYWN0aXZpdGllcyBvbiBzZXJ2ZXJzIHdoZXJlDQo8YnI+DQpubyBhY2Nlc3MgaGFzIGJl ZW4gcGVyZm9ybWVkIGJ5IHRoZSBwcmluY2lwYWxzIHRvIHRoZXNlIHNlcnZlcnMgYnV0IHdoZXJl IHRoZSBzYW1lIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyBhcmUgYmVpbmcgdXNlZA0KPGJy Pg0KYnkgdGhlc2Ugc2VydmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+RGVuaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGFua3MgRGVuaXMgZm9yIHRoZSB0aG9yb3VnaCBjb21tZW50YXJ5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+Jmd0OyBUaGUgdGl0bGUgb2YgdGhpcyBzcGVjLjwvaT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rml4ZWQsIHRoYW5rcyE8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPiZndDsgVGhlIGNsaWVudCBNVVNUIE5PVCBpbnNw ZWN0IHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW48L2k+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgcmVhbGx5IGEgc3RpY2t5IHBvaW50LiBJIHJl YWxseSB3YW50IHRvIGFja25vd2xlZGdlIHlvdXIgUG9WIG9uIHRoaXMsIGJ1dCBhdCB0aGUgc2Ft ZSB0aW1lIEkgZm91bmQgdGhpcyB0byBiZSBvbmUgb2YgdGhlIGJpZ2dlc3Qgc291cmNlcyBvZiBp c3N1ZXMgaW4gdGhlIHVzZSBvZiBKV1QgZm9yDQogYWNjZXNzIHRva2VucyBoZW5jZSBJIGZlZWwg d2UgcmVhbGx5IG5lZWQgdG8gZ2l2ZSBzb2xpZCBndWlkYW5jZSBoZXJlLiBMZXQgbWUgZXhwYW5k IGZ1cnRoZXIgb24gdGhlIHJlYXNvbmluZyBiZWhpbmQgaXQsIGFuZCBwZXJoYXBzIHdlIGNhbiBn ZXQgdG8gbGFuZ3VhZ2UgdGhhdCBzYXRpc2ZpZXMgYm90aCBQb1ZzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyBtZSB0aGUga2V5IHBvaW50IGlzIHRoYXQgY2xpZW50 cyBzaG91bGQgbm90IHdyaXRlDQo8aT5jb2RlPC9pPiB0aGF0IGluc3BlY3RzIGFjY2VzcyB0b2tl bnMuIFRha2luZyBhIGRlcGVuZGVuY3kgb24gdGhlIGFiaWxpdHkgdG8gZG8gc28gaXMgaWdub3Jp bmcgZnVuZGFtZW50YWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFyY2hpdGVjdHVyZSBhbmQgcmVs YXRpb25zaGlwcyBiZXR3ZWVuIE9BdXRoIHJvbGVzLCBhbmQgc3VnZ2VzdHMgYW4gYWJpbGl0eSBv ZiB0aGUgY2xpZW50IHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGljIG9mIHRoZSBjb250ZW50DQog dGhhdCBjYW5ub3QgYmUgYXNzdW1lZCBpbiB0aGUgZ2VuZXJhbCBjYXNlLiBJIGV4cGFuZGVkIG9u IHRoZSBkZXRhaWxzIGluIG15IGZvcm1lciByZXBseSB0byB5b3Ugb24gdGhpcyB0b3BpYywgSSB3 b3VsZCByZWNvbW1lbmQgcmVmZXJyaW5nIHRvIGl0LiBDbGllbnRzIHZpb2xhdGluZyB0aGlzIHNp bXBsZSBwcmluY2lwbGUgaGFzIGJlZW4gb25lIG9mIHRoZSBtb3N0IGNvbW1vbiBzb3VyY2VzIG9m IHByb2R1Y3Rpb24gaXNzdWVzIEkgaGFkIHRvDQogZGVhbCB3aXRoIGluIHRoZSBwYXN0IGZldyB5 ZWFycywgYW5kIG9uZSBvZiB0aGUgaGFyZGVzdCB0byByZW1lZGlhdGUgZ2l2ZW4gdGhhdCBjbGll bnRzIGFyZSBoYXJkIHRvIHVwZGF0ZSBhbmQgc29tZXRpbWVzIHRoZSB0aGluZ3MgdGhleSByZWxp ZWQgb24gd2VyZSBpcnJlbWVkaWFibHkgbG9zdC4gVGhpcyBpcyB3aHkgSSBhbSBpbmNsaW5lZCB0 byBwdXQgaW4gaGVyZSBzdHJvbmcgbGFuZ3VhZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoYXQgc2FpZDogSSBoYXZlIG5vdGhpbmcgYWdhaW5zdCBjbGllbnQgZGV2 ZWxvcGVycyBleGFtaW5pbmcgYSBuZXR3b3JrIHRyYWNlIGFuZCBkcmF3aW5nIGNvbmNsdXNpb25z IGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIHdoYXQgdGhleSBzZWUuIFRoYXQgZG9lc27igJl0IGNy ZWF0ZSBhbnkgaGFyZCBkZXBlbmRlbmNpZXMNCiBhbmQgaGFzIG5vIGltcGxpY2F0aW9ucyBpbiBy ZXNwZWN0IHRvIGNoYW5nZXMgaW4gdGhlIHNvbHV0aW9uIGJlaGF2aW9yLiBIb3dldmVyIEkgYW0g bm90IHN1cmUgaG93IHRvIHBocmFzZSB0aGF0IGluIHRoZSBzcGVjaWZpY2F0aW9uLCBnaXZlbiB0 aGF0IHJlZmVycmluZyB0byB0aGUgY2xpZW50IGluZXZpdGFibHkgcmVmZXJzIHRvIGl0cyBjb2Rl LiBJIGFtIG9wZW4gdG8gc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m Z3Q7ICZuYnNwOzMp4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg aGF2ZSBhIHByZXR0eSBoYXJkIHRpbWUgZm9sbG93aW5nIHRoZSBjaGFpbiBvZiByZWFzb25pbmcg aW4gdGhpcyBzZWN0aW9uLiBMZXQgbWUgYXR0ZW1wdCB0byB0YWNrbGUgaXQgdG8gdGhlIGJlc3Qg b2YgbXkgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSB0aGluayB0aGUga2V5IG1pZ2h0IGJlICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT4mZ3Q7IGEgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRv IGNob29zZSB3aGV0aGVyIGl0IHdpc2hlcyB0aGUgc3ViIGNsYWltIHRvIGNvbnRhaW4gWy4uXTwv aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb27igJl0IHRoaW5r IHRoYXQgc2hvdWxkIGJlIGEgY2hvaWNlIGxlZnQgdG8gdGhlIGNsaWVudC4gSW4gYnVzaW5lc3Mg c3lzdGVtcywgbXkgZXhwZXJpZW5jZSBpcyB0aGF0IHRoZSB0eXBlIG9mIGlkZW50aWZpZXJzIHRv IGJlIHVzZWQgKHdoZW4gdGhlIElkUCBnaXZlcyBhbnkgY2hvaWNlIGF0IGFsbCkgJm5ic3A7aXMN CiBlc3RhYmxpc2hlZCBhdCByZXNvdXJjZSBwcm92aXNpb25pbmcgdGltZS4gSSBhbSBub3QgYXdh cmUgb2YgbWVjaGFuaXNtcyB0aHJ1IHdoaWNoIGEgY2xpZW50IHNpZ25hbHMgdGhlIG5hdHVyZSBv ZiB0aGUgaWRlbnRpZmllciB0byBiZSB1c2VkLCBub3IgdGhhdCB3b3VsZCBiZSBmdWxseSBmZWFz aWJsZSAodGhlIHJlc291cmNlIGtub3dzIHdoYXQgaXQgbmVlZHMgdG8gcGVyZm9ybSBpdHMgZnVu Y3Rpb24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GdXJ0aGVybW9y ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+Jmd0OyB3aGljaCBo YXMgbm90aGluZyB0byBkbyB3aXRoIHVuaXF1ZW5lc3Mgc2luY2UgdGhlIHZhbHVlIGNoYW5nZXMg Zm9yIGV2ZXJ5IGdlbmVyYXRlZCB0b2tlbi48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFnYWluLCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHdhcyB0b3VjaGVkIG9u IGluIG15IGZvcm1lciByZXBseSB0byB5b3VyIG1lc3NhZ2UuIEFzIGxvbmcgYXMgYW4gaWRlbnRp ZmllciBpZGVudGlmaWVzIG9uZSByZXNvdXJjZSBvbmx5LCBpdCBzYXRpc2ZpZXMgdW5pcXVlbmVz cy4gSXQgZG9lc27igJl0IGhhdmUNCiB0byBiZSBhIHNpbmdsZXRvbi4gPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZpbmFsbHksIHRoZSBzY29wZSBpcyBvcHRpb25hbCAo Zm9yIGdvb2QgcmVhc29uczogMTxzdXA+c3Q8L3N1cD4gcGFydHkgYW5kIG5vbiBkZWxlZ2F0aW9u IHNjZW5hcmlvcyBkb27igJl0IHJlcXVpcmUgaXQpIGhlbmNlIGl0IGNhbm5vdCBiZSByZWxpZWQg dXBvbiBmb3IgcHJvcGVydGllcyB0aGF0IHNob3VsZCBob2xkDQogaW4gZXZlcnkgc2NlbmFyaW8u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHN1bW1hcnk6IHBlciB0 aGUgcHJlY2VkaW5nIHRocmVhZCBvbiB0aGlzIHRvcGljLCB0aGUgY29uc2Vuc3VzIHdhcyB0aGF0 IHZhcnlpbmcgdGhlIHN1YiBjb250ZW50IHdhcyBhIHNhdGlzZmFjdG9yeSB3YXkgb2YgcHJvdGVj dGluZyBhZ2FpbnN0IGNvcnJlbGF0aW9uLiBJIGRvbuKAmXQgYSBncmVlIHRoYXQNCiBjbGllbnRz IHNob3VsZCBoYXZlIGEgbWVjaGFuaXNtIHRvIHJlcXVlc3QgZGlmZmVyZW50IHN1YiBmbGF2b3Jz LCBhcyB0aGF0IGRlY2lzaW9uIHNob3VsZCBiZSBkb25lIG91dCBvZiBiYW5kIGJ5IHRoZSBBUyBh bmQgUlM7IGFuZCB0aGUgc2NvcGUgaXNu4oCZdCBhbHdheXMgYXZhaWxhYmxlIGFueXdheS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+Jmd0OyB0YXJnZXRpbmcgb2Yg YWNjZXNzIHRva2VuczwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TGV0IG1lIHRoaW5rIGFib3V0IHRoYXQgYSBiaXQgbG9uZ2VyLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWNrbm93bGVkZ2UgdGhhdCB0aGUgZGVjaXNpb24gb2Yg aW5jbHVkaW5nIGFuIGF1ZGllbmNlIGhhcyB0aGUgZWZmZWN0IG9mIGxldHRpbmcgdGhlIEFTIHRy YWNrIHdoZW4gdGhlIGNsaWVudCBhY2Nlc3NlcyBhIHBhcnRpY3VsYXIgcmVzb3VyY2UsIGJ1dCBh dCB0aGUgc2FtZSB0aW1lIHRoYXTigJlzIGNvbXBsZXRlbHkNCiBtYWluc3RyZWFtIGFuZCB2ZXJ5 IG11Y2ggYnkgZGVzaWduIGluIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgY2FzZXMuIEFzIHN1Y2gs IEkgZmluZCB0aGUgbGFuZ3VhZ2UgeW91IGFyZSBzdWdnZXN0aW5nIHRvIGJlIHBvdGVudGlhbGx5 IGNvbmZ1c2luZywgYXMgaXQgcG9zaXRpb25zIHRoaXMgYXMgYW4gZXhjZXB0aW9uIHZzIGEgcHJp dmFjeSBwcm90ZWN0aW5nIG1haW5zdHJlYW0gdGhhdCBpcyBpbiBmYWN0IG5vdCBjb21tb24sIGFu ZCBhc2NyaWJlcw0KIHRvIHRoZSBjbGllbnQgbW9yZSBsYXRpdHVkZSB0aGFuIEkgYmVsaWV2ZSBp cyBsZWdpdGltYXRlIHRvIGV4cGVjdCBvciBncmFudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SeKAmWxsIHRyeSB0byBjb21lIHVwIHdpdGggY29uY2lzZSBsYW5ndWFn ZSB0aGF0IGNsYXJpZmllcyB0byB0aGUgcmVhZGVyIHRoYXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNt IGRvZXMgYWxsb3cgQVMgdHJhY2tpbmcuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCA8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O29hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7PC9hPiBvbiBiZWhhbGYgb2YgRGVuaXMgPGEgaHJlZj0ibWFpbHRvOmRlbmlzLmll dGZAZnJlZS5mciIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O2RlbmlzLmlldGZAZnJlZS5mciZndDs8 L2E+PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgQXByaWwgMjksIDIwMjAgYXQgMDk6MTI8 YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPiZxdW90O29hdXRoQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+ PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICZxdW90 O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5z JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+WW91IHdpbGwgZmluZCBmb3VyIGNvbW1lbnRzIG51bWJlcmVkIDEpIHRv IDQpLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjEpDQo8L2I+VGhlIHRpdGxlIG9mIHRoaXMgc3BlYy4gaXM6PGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+SlNPTiBXZWIg VG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGgNCjxiPjIuMDwvYj4gQWNjZXNzIFRva2Vuczwv c3Bhbj48YnI+DQo8YnI+DQpTbywgdGhpcyBzcGVjLiBpcyBzdXBwb3NlZCB0byBiZSB0YXJnZXRl ZCB0byBPQXV0aCA8Yj4yLjAuIDwvYj4mbmJzcDtIb3dldmVyLCB0aGUgaGVhZGVyIGF0IHRoZSB0 b3Agb2YgdGhlIHBhZ2Ugb21pdHMgdG8gbWVudGlvbiBpdC4NCjxicj4NCjxicj4NCkN1cnJlbnRs eSwgaXQgaXMgOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J bnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCBB Y2Nlc3MgVG9rZW4gSldUIFByb2ZpbGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXByaWwgMjAyMDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JdCBzaG91bGQgcmF0aGVyIGJlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBPQXV0aA0KPGI+Mi4wPC9iPiBBY2Nlc3MgVG9rZW4gSldUIFByb2Zp bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQXByaWwgMjAyMDxicj4NCjxicj4NCjxiPjIpPC9iPiBUaGUgZm9sbG93aW5nIHRleHQg aXMgd2l0aGluIHNlY3Rpb24gNi48YnI+DQo8YnI+DQpUaGUgY2xpZW50IE1VU1QgTk9UIGluc3Bl Y3QgdGhlIGNvbnRlbnQgb2Y8YnI+DQp0aGUgYWNjZXNzIHRva2VuOiB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXI8YnI+DQptaWdodCBkZWNpZGUgdG8gY2hh bmdlIHRva2VuIGZvcm1hdCBhdCBhbnkgdGltZSAoZm9yIGV4YW1wbGUgYnk8YnI+DQpzd2l0Y2hp bmcgZnJvbSB0aGlzIHByb2ZpbGUgdG8gb3BhcXVlIHRva2VucykgaGVuY2UgYW55IGxvZ2ljIGlu IHRoZTxicj4NCmNsaWVudCByZWx5aW5nIG9uIHRoZSBhYmlsaXR5IHRvIHJlYWQgdGhlIGFjY2Vz cyB0b2tlbiBjb250ZW50IHdvdWxkPGJyPg0KYnJlYWsgd2l0aG91dCByZWNvdXJzZS48YnI+DQpO b25ldGhlbGVzcywgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZDxicj4NCm5vdCBhc3N1bWUg dGhhdCBjbGllbnRzIHdpbGwgY29tcGx5IHdpdGggdGhlIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBvZiBhIHByaW1hcnkgaW1wb3J0YW5jZSB0aGF0 IGNsaWVudHMgTUFZIGJlIGFibGUgdG8gaW5zcGVjdCB0b2tlbnMgYmVmb3JlIHRyYW5zbWl0dGlu ZyB0aGVtLjxicj4NClRoZSAmcXVvdDtNVVNUIE5PVCZxdW90OyBpcyBub3QgYWNjZXB0YWJsZS4g PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBhYm92ZSB0ZXh0IHNo b3VsZCBiZSByZXBsYWNlZCB3aXRoOjxicj4NCjxicj4NClJlYWRpbmcgdGhlIGFjY2VzcyB0b2tl biBjb250ZW50IG1heSBiZSB1c2VmdWwgZm9yIHRoZSB1c2VyIHRvIHZlcmlmeSB0aGF0IDxicj4N CnRoZSBhY2Nlc3MgdG9rZW4gY29udGVudCBtYXRjaGVzIHdpdGggaXRzIGV4cGVjdGF0aW9ucy4m bmJzcDsgSG93ZXZlciwgPGJyPg0KdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUgcmVz b3VyY2Ugc2VydmVyIG1pZ2h0IGRlY2lkZSB0byBjaGFuZ2UgdGhlIDxicj4NCnRva2VuIGZvcm1h dCBhdCBhbnkgdGltZS4mbmJzcDsgVGh1cywgdGhlIGNsaWVudCBzaG91bGQgbm90IGV4cGVjdCB0 byBhbHdheXMgYmUgPGJyPg0KaW4gYSBwb3NpdGlvbiB0byByZWFkIHRoZSBhY2Nlc3MgdG9rZW4g Y29udGVudC48YnI+DQo8YnI+DQpUaGUgcmVtYWluaW5nIG9mIHRoZSB0ZXh0IGFib3V0IHRoaXMg dG9waWMgaXMgZmluZS48YnI+DQo8YnI+DQo8YnI+DQo8Yj4zKSA8L2I+VGhlIG5leHQgdG9waWMg aXMgYWJvdXQgdGhlIHN1YiBjbGFpbS48YnI+DQo8YnI+DQpUaGUgdGV4dCBzdGF0ZXM6PGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+ QWx0aG91Z2ggdGhlIGFiaWxpdHkgdG8gY29ycmVsYXRlIHJlcXVlc3RzIG1pZ2h0IGJlIHJlcXVp cmVkIGJ5PGJyPg0KZGVzaWduIGluIG1hbnkgc2NlbmFyaW9zLCB0aGVyZSBhcmUgc2NlbmFyaW9z IHdoZXJlIHRoZSBhdXRob3JpemF0aW9uPGJyPg0Kc2VydmVyIG1pZ2h0IHdhbnQgdG8gcHJldmVu dCBjb3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0aGUgZGVzaXJlZDxicj4NCmxldmVsIG9mIHByaXZh Y3kuIEF1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQgY2hvb3NlIGhvdyB0byBhc3NpZ248YnI+ DQpzdWIgdmFsdWVzIGFjY29yZGluZyB0byB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCBi eSBlYWNoPGJyPg0Kc2l0dWF0aW9uLjwvc3Bhbj48YnI+DQo8YnI+DQpJIGhhdmUgYSBzZXQgb2Yg cXVlc3Rpb25zOiA8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkhvdyBjYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXJzIGNob29zZSBob3cgdG8gYXNzaWduIHN1YiB2YWx1ZXMgYWNjb3Jk aW5nIHRvIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkICZxdW90O2J5IGVhY2ggc2l0dWF0 aW9uJnF1b3Q7ID88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMSBsZXZlbDEgbGZvMSI+DQpIb3cgY2FuIGF1dGhvcml6YXRpb24gc2VydmVycyBrbm93IHRo ZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkICZxdW90O2J5IGVhY2ggc2l0dWF0aW9uJnF1b3Q7 ID8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8xIj4NCkhvdyBjYW4gdGhlIHVzZXJzIGJlIGluZm9ybWVkIG9mIHRoZSBsZXZlbCBv ZiBwcml2YWN5IHJlcXVpcmVkICZxdW90O2J5IGVhY2ggc2l0dWF0aW9uJnF1b3Q7ID88bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+ DQpIb3cgY2FuIHRoZSB1c2VycyA8Yj5jb25zZW50PC9iPiB3aXRoIHRoZSBsZXZlbCBvZiBwcml2 YWN5IHJlcXVpcmVkICZxdW90O2J5IGVhY2ggc2l0dWF0aW9uJnF1b3Q7ID88bzpwPjwvbzpwPjwv bGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q3VycmVudGx5LCB0aGUgcmVxdWVzdCBN VVNUIGluY2x1ZGUgZWl0aGVyIGEgcmVzb3VyY2UgcGFyYW1ldGVyIG9yIGFuIGF1ZCBjbGFpbSBw YXJhbWV0ZXIsIHdoaWxlIGl0IE1BWSBpbmNsdWRlIGEgc2NvcGUgcGFyYW1ldGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgc3ludGF4IG9mIHRoZSBzY29wZSBw YXJhbWV0ZXIgaXMgYSBsaXN0IG9mIHNwYWNlLWRlbGltaXRlZCwgY2FzZS1zZW5zaXRpdmUgc3Ry aW5ncyAoUkZDIDY3NDkpLiBJdCBpcyB0aHVzIHN1YmplY3QgdG8gcHJpdmF0ZSBhZ3JlZW1lbnRz DQo8YnI+DQpiZXR3ZWVuIGNsaWVudHMgYW5kIEF1dGhvcml6YXRpb24gU2VydmVycy4gU2luY2Ug dGhlIHNjb3BlIGlzIGJlaW5nIHJldHVybmVkLCBpdCBpcyBhIHByaW1hcnkgaW1wb3J0YW5jZSB0 aGF0IHRoZSByZXR1cm5lZCBzY29wZSBtYXRjaGVzDQo8YnI+DQp3aXRoIGl0cyBleHBlY3RhdGlv bnMgYmVmb3JlIHRyYW5zbWl0dGluZyB0aGUgdG9rZW4gdG8gYSBSZXNvdXJjZSBTZXJ2ZXIuPGJy Pg0KPGJyPg0KSW4gdGhlb3J5LCBhIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBjaG9vc2Ugd2hl dGhlciBpdCB3aXNoZXMgdGhlIHN1YiBjbGFpbSB0byBjb250YWluIDo8bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPg0KYSBnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXIgZm9yIGFsbCBBU3MgKCZxdW90 O2dsb2JhbGx5IHVuaXF1ZSZxdW90OyksPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KYSB1bmlxdWUgaWRlbnRpZmllciBmb3Ig ZWFjaCBBUyAoJnF1b3Q7bG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3Vl ciZxdW90OyksPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPg0KYSBkaWZmZXJlbnQgcHNldWRvbnltIGZvciBlYWNoIFJTLCBvciA8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+DQphIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggYXV0aG9yaXphdGlvbiB0b2tl biByZXF1ZXN0LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgb25seSB2YXJpYWJsZSBwYXJhbWV0ZXIgdGhhdCBpdCBjYW4gdXNlIGZvciB0aGlzIHB1cnBv c2UgaW4gdGhlIHRva2VuIHJlcXVlc3QgaXMgdGhlIHNjb3BlIHBhcmFtZXRlci48YnI+DQo8YnI+ DQpSRkMgNzUxOSBzdGF0ZXMgaXMgc2VjdGlvbiA0LjEuMjo8YnI+DQo8YnI+DQpUPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5oZSBzdWJqZWN0IHZhbHVl IE1VU1QgZWl0aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4 dCBvZiB0aGUgaXNzdWVyDQo8YnI+DQpvciBiZSBnbG9iYWxseSB1bmlxdWUuPGJyPg0KPC9zcGFu Pjxicj4NCkl0IGlzIHF1aXRlIGhhcmQgdG8gcmVjb2duaXplIHRoYXQgdGhlIHN1YiBjbGFpbSBp cyBhYmxlIHRvIGNhcnJ5IGEgZGlmZmVyZW50IHBzZXVkb255bSBmb3IgZWFjaCBSUywgaS5lLiBm b3IgY2FzZSAoYyksIG9yDQo8YnI+DQphIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggYXV0 aG9yaXphdGlvbiB0b2tlbiByZXF1ZXN0LCBpLmUuIGZvciBjYXNlIChkKSwgd2hpY2ggaGFzIG5v dGhpbmcgdG8gZG8gd2l0aCB1bmlxdWVuZXNzDQo8YnI+DQpzaW5jZSB0aGUgdmFsdWUgY2hhbmdl cyBmb3IgZXZlcnkgZ2VuZXJhdGVkIHRva2VuLjxicj4NCjxicj4NClRoaXMgaGFzIGltcGxpY2F0 aW9ucyBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ6PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Rm9yIGluc3RhbmNlOiBpZiBhIHNv bHV0aW9uIHJlcXVpcmVzIHByZXZlbnRpbmcgdHJhY2tpbmc8YnI+DQpwcmluY2lwYWwgYWN0aXZp dGllcyBhY3Jvc3MgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycywgdGhlPGJyPg0KYXV0aG9yaXph dGlvbiBzZXJ2ZXIgc2hvdWxkIGVuc3VyZSB0aGF0IEpXVCBhY2Nlc3MgdG9rZW5zIG1lYW50IGZv cjxicj4NCmRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzIGhhdmUgZGlzdGluY3Qgc3ViIHZhbHVl cyB0aGF0IGNhbm5vdCBiZTxicj4NCmNvcnJlbGF0ZWQgaW4gdGhlIGV2ZW50IG9mIHJlc291cmNl IHNlcnZlcnMgY29sbHVzaW9uLjxicj4NCjxicj4NCjwvc3Bhbj5TaW5jZSBpdCBhZGRyZXNzZXMg Y2FzZSAoYykuPGJyPg0KPGJyPg0KYW5kIGFsc28gYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Ojxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPjQuYikgU2ltaWxhcmx5OiBpZiBhIHNvbHV0aW9uIHJlcXVpcmVzIHByZXZlbnRpbmcgYSBy ZXNvdXJjZSBzZXJ2ZXIgZnJvbQ0KPGJyPg0KY29ycmVsYXRpbmcgdGhlIHByaW5jaXBhbOKAmXMg YWN0aXZpdHkgd2l0aGluIHRoZSByZXNvdXJjZSBpdHNlbGYsIHRoZSA8YnI+DQphdXRob3JpemF0 aW9uIHNlcnZlciBzaG91bGQgYXNzaWduIGRpZmZlcmVudCBzdWIgdmFsdWVzIGZvciBldmVyeSBK V1QgPGJyPg0KYWNjZXNzIHRva2VuIGlzc3VlZC48L3NwYW4+PGJyPg0KPGJyPg0KU2luY2UgaXQg YWRkcmVzc2VzIGNhc2UgKGQpLjxicj4NCjxicj4NClRoaXMgbWVhbnMgdGhhdCB0aGUgY3VycmVu dCB0ZXh0IHBsYWNlZCBpbiB0aGUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBh IGdvb2QgYXR0ZW1wdCB0byBhZGRyZXNzIHRoZSBjYXNlLA0KPGJyPg0KYnV0IHRoYXQgdGhlIHRl eHQgbmVlZHMgdG8gYmUgcmV2aXNlZC48YnI+DQo8YnI+DQpQcm9wb3NlZCB0ZXh0IHJlcGxhY2Vt ZW50IGZvciBhbGwgdGhlIHByZXZpb3VzbHkgcXVvdGVkIHNlbnRlbmNlczo8YnI+DQo8YnI+DQpB Y2NvcmRpbmcgdG8gUkZDIDc1MTkgKDQuMS4yKTogVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRo ZXIgYmUgc2NvcGVkIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBp c3N1ZXIgb3IgYmUgZ2xvYmFsbHkgdW5pcXVlLjxicj4NCjxicj4NCldoZW4gdGhlIHN1YiBjbGFp bSBjb250YWlucyBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyLCB0aGlzIGFsbG93cyB0byBj b3JyZWxhdGUgcHJpbmNpcGFsIGFjdGl2aXRpZXMgYWNyb3NzIG11bHRpcGxlIHJlc291cmNlIHNl cnZlcnMsIHdoaWxlIGluIGFkZGl0aW9uLA0KPGJyPg0KdGhpcyBnbG9iYWxseSB1bmlxdWUgaWRl bnRpZmllciBtYXkgYWxzbyBhbGxvdyB0byBjb3JyZWxhdGUgdGhlIHByaW5jaXBhbCBhY3Rpdml0 aWVzIG9uIHNlcnZlcnMgd2hlcmUgbm8gYWNjZXNzIGhhcyBiZWVuIHBlcmZvcm1lZCBieSB0aGUg cHJpbmNpcGFscw0KPGJyPg0KdG8gdGhlc2Ugc2VydmVycyBidXQgd2hlcmUgdGhlIHNhbWUgZ2xv YmFsbHkgdW5pcXVlIGlkZW50aWZpZXJzIGFyZSBiZWluZyB1c2VkIGJ5IHRoZXNlIHNlcnZlcnMu DQo8YnI+DQo8YnI+DQpXaGVuIHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBsb2NhbGx5IHVuaXF1 ZSBpZGVudGlmaWVyIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIsIHRoaXMgYWxzbyBhbGxv d3MgdGhlIHRyYWNraW5nIG9mIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBsZSBy ZXNvdXJjZSBzZXJ2ZXJzLjxicj4NCjxicj4NClRoZSBzY29wZSByZXF1ZXN0IHBhcmFtZXRlciBp cyB0aGUgb25seSB3YXkgdG8gaW5mbHVlbmNlIG9uIHRoZSBjb250ZW50IG9mIHRoZSBzdWIgY2xh aW0gcGFyYW1ldGVyLiBJdHMgbWVhbmluZyBpcyBzdWJqZWN0IHRvIGEgcHJpdmF0ZSBhZ3JlZW1l bnQNCjxicj4NCmJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFTLCB3aGljaCBtZWFucyB0aGF0 IHRoZSB1c2Ugb2YgdGhlIHNjb3BlIHBhcmFtZXRlciBpcyB0aGUgb25seSB3YXkgdG8gY2hvb3Nl IGJldHdlZW4gYSBsb2NhbGx5IHVuaXF1ZSBpZGVudGlmaWVyDQo8YnI+DQppbiB0aGUgY29udGV4 dCBvZiB0aGUgaXNzdWVyIG9yIGEgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXIuPGJyPg0KPGJy Pg0KU2luY2UgdGhlIHNjb3BlIHBhcmFtZXRlciBpcyBiZWluZyByZXR1cm5lZCwgaXQgaXMgYSBw cmltYXJ5IGltcG9ydGFuY2UgdGhhdCB0aGUgcmV0dXJuZWQgc2NvcGUgbWF0Y2hlcyB3aXRoIHRo ZSBleHBlY3RhdGlvbnMgb2YgdGhlIGNsaWVudCBiZWZvcmUgdHJhbnNtaXR0aW5nDQo8YnI+DQp0 aGUgdG9rZW4gdG8gYSBSZXNvdXJjZSBTZXJ2ZXIuPGJyPg0KPGJyPg0KSG93ZXZlciwgdGhlcmUg YXJlIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgd291bGQgbGlrZSB0byBiZSBhYmxlIHRv IGNob29zZSB3aGV0aGVyIGl0IHdpc2hlcyB0aGUgc3ViIGNsYWltIHRvIGNvbnRhaW4gOg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gYSBkaWZmZXJlbnQgcHNldWRvbnltIGZvciBlYWNoIFJT IHNvIHRoYXQgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnMgd2lsbCBiZSB1bmFibGUgdG8gY29y cmVsYXRlIGl0cyBhY3Rpdml0aWVzLCBvcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtIGEgZGlm ZmVyZW50IHBzZXVkb255bSBmb3IgZWFjaCBhdXRob3JpemF0aW9uIHRva2VuIHJlcXVlc3QsIHNv IHRoYXQgdGhlIHNhbWUgcmVzb3VyY2Ugc2VydmVyIGNhbm5vdCBjb3JyZWxhdGUgaXRzIGFjdGl2 aXRpZXMgcGVyZm9ybWVkIGF0IGRpZmZlcmVudCBpbnN0YW50IG9mIHRpbWUuDQo8YnI+DQo8YnI+ DQpDb25zaWRlcmluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBzdWIgY2xhaW0sIHRoZXNlIHR3byBj YXNlcyBjYW5ub3QgYmUgY3VycmVudGx5IHN1cHBvcnRlZC48YnI+DQo8YnIgY2xlYXI9ImFsbCI+ DQo8YnI+DQo8Yj40KSA8L2I+VGhlIG5leHQgdG9waWMgaXMgYWJvdXQgdGhlIHRhcmdldGluZyBv ZiBhY2Nlc3MgdG9rZW5zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRl eHQgaGFkIGJlZW4gcHJvcG9zZWQgYmVmb3JlIHRoZSBsYXN0IGNvbmZlcmVuY2UgY2FsbC4gVGhl biwgdGhlIHRvcGljIGhhcyBiZWVuIHByZXNlbnRlZCBhdCB0aGUgdmVyeSBlbmQgb2YgdGhlIGxh c3QgY29uZmVyZW5jZSBjYWxsLCBidXQgbm8gdGV4dCBoYXMgYmVlbiBpbmNsdWRlZA0KPGJyPg0K aW4gdGhlIG5leHQgZHJhZnQuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IZXJlIGlzIGEgcmV2aXNlZCB0ZXh0IGJlIGluY2x1ZGVkIGluIHRoZSBwcml2YWN5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkZvciBzZWN1cml0eSByZWFzb25zLCBzb21lIGNsaWVudHMgbWF5IGJlIHdpbGxpbmcgdG8gdGFy Z2V0IHRoZWlyIGFjY2VzcyB0b2tlbnMgYnV0LCBmb3IgcHJpdmFjeSByZWFzb25zLCBtYXkgYmUg dW53aWxsaW5nIHRvIGRpc2Nsb3NlIHRvIEF1dGhvcml6YXRpb24gU2VydmVycw0KPGJyPg0KYW4g aWRlbnRpZmljYXRpb24gb2YgdGhlIFJlc291cmNlIFNlcnZlcnMgdGhleSBhcmUgZ29pbmcgdG8g YWNjZXNzLCBzbyB0aGF0IEF1dGhvcml6YXRpb24gU2VydmVycyB3aWxsIGJlIHVuYWJsZSB0byBr bm93IHdoaWNoIHJlc291cmNlcyBzZXJ2ZXJzIGFyZSBiZWluZyBhY2Nlc3NlZC4NCjxicj4NClRo ZSBkaXNjbG9zdXJlIG9mIHRoZSBSZXNvdXJjZSBTZXJ2ZXJzIG5hbWVzIGFsbG93cyB0aGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXJzIHRvIGxpc3QgYWxsIHRoZSBSZXNvdXJjZSBTZXJ2ZXJzIGJlaW5n IGFjY2VzcyBieSBhbGwgaXRzIHVzZXJzIGFuZCBpbiBhZGRpdGlvbiB0byBsaXN0IHBhaXJzDQo8 YnI+DQpvZiAoUHJpbmNpcGFsLCBSZXNvdXJjZSBTZXJ2ZXJzKSB3aGljaCBhbGxvdyB0byB0cmFj ZSBhbGwgdGhlIHVzZXJzIGFjY2Vzc2VzIHRvIFJlc291cmNlIFNlcnZlcnMgcGVyZm9ybWVkIHRo cm91Z2ggYSBnaXZlbiBBdXRob3JpemF0aW9uIFNlcnZlci4gV2hlbiBhIHRva2VuIGlzIHRhcmdl dGVkLA0KPGJyPg0KdGhpcyBwcm9maWxlIGRvZXMgbm90IGNvbnRhaW4gcHJvdmlzaW9ucyB0byBh ZGRyZXNzIHRoZXNlIHR3byB0aHJlYXRzLjxicj4NCjxicj4NCkRlbmlzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUl Ij4NCkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhl aWdodDoxMTUlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2xpbmUtaGVpZ2h0OjExNSUiPg0KVGhpcyBpcyBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBmb3IgJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4w IEFjY2VzcyBUb2tlbnMmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNz LXRva2VuLWp3dC0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDY8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NClBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIE9BdXRoIG1haWxpbmcgbGlzdCBieSBBcHJpbCAy OSwgMjAyMC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdo dDoxMTUlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xp bmUtaGVpZ2h0OjExNSUiPg0KUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5uZXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR08MB37162721EE1CA10919B22500FA8B0AM0PR08MB3716eurp_-- From nobody Tue Jun 2 21:12:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DF3A127D for ; Tue, 2 Jun 2020 21:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwEnGPnUikG7 for ; Tue, 2 Jun 2020 21:12:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80AA3A127B for ; Tue, 2 Jun 2020 21:12:46 -0700 (PDT) Received: from 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 0534CdgN013989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 00:12:41 -0400 Date: Tue, 2 Jun 2020 21:12:38 -0700 From: Benjamin Kaduk To: Janak Amarasena Cc: oauth , Vittorio Bertocci Message-ID: <20200603041238.GR58497@mit.edu> References: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <20200530205522.GV58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 04:12:49 -0000 On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote: > Hi all, > > My apologies, if this was already discussed. > > In section *4*. Validating JWT Access Tokens > it > is stated; > > The resource server MUST handle errors as described in section 3.1 of > [RFC6750] . In > particular, in case of any failure in the validation > checks listed above the *authorization server* response MUST include > the error code "invalid_token". > > > > > Should this be; > > ... above the *resource server* response MUST include the error code > "invalid_token". It does look like it should be the resource server there, yes. Good catch, and thanks for mentioning it! -Ben > > If that is not the case, which kind of scenarios would occur for an AS to > respond with the error code "invalid_token"? > > Best Regards, > Janak Amarasena > > On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk wrote: > > > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > > > Hi Benjamin, > > > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > > > >> Since then, I questioned myself how a client would be able to request > > an > > > >> access token that would be > > > >> *strictly compliant with this Profile*. > > > > I don't understand why this is an interesting question to ask. The > > access > > > > token and interpretation thereof is (AIUI) generally seen as an > > internal > > > > matter between AS and RS, with the client having no need to care about > > the > > > > specifics. > > > > > > This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not > > > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. > > > > Sure. But (in my understanding), in common usage, the contents and > > interpretation of the access token is set by common agreement between AS > > and RS, with the client serving only as a "dumb" channel for transporting > > the token. That is, we're providing a token format that an RS and AS can > > agree to use, most likely for all tokens issued by the AS for that RS. I > > don't know of any existing mechanisms, or desire for such mechanisms by > > deployments, for using a different token format for different tokens issued > > by a given AS for a given RS. Attempting to have the client provide input > > that would affect such a mechanism seems like complexity with no market > > demand; a "solution in search of a problem" as it were. Is there some > > pent-up demand among OAuth deployments that I'm not aware of? I freely > > admit to not being very on top of the broad spectrum of what's deployed... > > > > > 1) A client may wish to obtain an Access Token that corresponds to this > > > Profile because, for example, > > > this document mandates the "sub" claim to be present". Hence, the > > > content of the Access Token is not > > > totally "/an internal matter between AS and RS/". > > > > > > However, I have not understood how a client could request an Access > > > Token that corresponds to *_this_***Profile, > > > since there is no mandatory parameter in the request (both the "scope" > > > parameter and the "resource" parameter are optional). > > > > > > In the future, we could define _*another*_**Profile. Hence, there is the > > > same question: How could a client request an Access Token > > > that corresponds to *_that other_***Profile ? > > > > > > 2) When getting a JWT, how can the client make sure that the access > > > token it got is compliant with this Profile ? > > > > > > RFC 8725 states in section 3.11 : > > > > > > 3.11. Use Explicit Typing > > > Sometimes, one kind of JWT can be confused for another. If a > > > particular kind of JWT is subject to such confusion, > > > that JWT can include an explicit JWT type value, and the validation > > > rules can specify checking the type (...). > > > Explicit JWT typing is accomplished by using the "typ" Header > > > Parameter. > > > > > > Wouldn't be wise to include an explicit JWT type value for JWTs > > > conformant to this Profile ? > > > > In the model where the client is a "dumb" communications channel, this > > question does not seem interesting. But the related question of "how can > > the RS make sure that the access token it got was generated according to > > this profile?" does seem interesting, and seems like it would benefit from > > the same proposed solution. > > > > > This relates to an email posted by Dominick Baier under the topic "JAR: > > > JWT typ" on May 19 : > > > > > > This has been brought up before - but no response. > > > > > > Either I can’t find it - or it is missing. But is the setting the > > > JWT typ explicitly mentioned somewhere? > > > > It is fairly likely that I will remember to ask about explicit "typ" usage > > if I'm still on the IESG when this document gets there: I think I've been > > making a habit of doing so. > > > > Thanks, > > > > Ben > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From nobody Tue Jun 2 21:23:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A0B3A00C3 for ; Tue, 2 Jun 2020 21:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZQ_pdNK-JCA for ; Tue, 2 Jun 2020 21:23:31 -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 90D4B3A00C1 for ; Tue, 2 Jun 2020 21:23:31 -0700 (PDT) Received: from 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 0534NPSV016341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 00:23:27 -0400 Date: Tue, 2 Jun 2020 21:23:24 -0700 From: Benjamin Kaduk To: Denis Cc: oauth@ietf.org, Vittorio Bertocci Message-ID: <20200603042324.GS58497@mit.edu> References: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <20200530205522.GV58497@kduck.mit.edu> <0c2a52b0-f05b-38c6-6e37-7aacd6c98a24@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0c2a52b0-f05b-38c6-6e37-7aacd6c98a24@free.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 04:23:33 -0000 Hi Denis, On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: > Hi Benjamin, > > Responses are between the lines. > > > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > >> Hi Benjamin, > >>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > >>>> Since then, I questioned myself how a client would be able to > >>>> request an access token that would be *strictly compliant with this > >>>> Profile*. > >>> I don't understand why this is an interesting question to ask. The > >>> access token and interpretation thereof is (AIUI) generally seen as > >>> an internal matter between AS and RS, with the client having no need > >>> to care about the specifics. > >> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not > >> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. > > Sure. But (in my understanding), in common usage, the contents and > > interpretation of the access token is set by common agreement between > > AS and RS, with the client serving only as a "dumb" channel for > > transporting the token. That is, we're providing a token format that > > an RS and AS can agree to use, most likely for all tokens issued by > > the AS for that RS. I don't know of any existing mechanisms, or desire > > for such mechanisms by deployments, for using a different token format > > for different tokens issued by a given AS for a given RS. > > Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it > means that potentially other Profiles could be defined in the future. > In the request, there is no parameter for a client to indicate that it > wants a JWT conformant to _this_ profile and no parameter either > in the response to indicate to the client that it got a JWT that is > conformant to _this_ profile. I don't think my point came through clearly. Right now, the AS and RS have to negotiate by some out-of-band means what token format and details to use for tokens issued by AS with RS in audience, and there is not a "well-known" description of how to use JWT to do so. The goal of this document is to simplify the out-of-band negotiation between AS and RS, so they can just say "use RFC NNNN" instead of having to specify a lot of details individually. Nowhere does the client come into the current negotiation of what token format to use, and the act of specifying a profile of JWT for this usage does not create a requirement for the client to be included in the negotiation. Now, whether or not to include the client in this negotiation (and whether or not to make the choice of token format finer-grained) may be a topic worth discussion in its own right, but that discussion is untethered from specifying a profile of JWT to simplify AS/RS negotiations. > The processing mandated in the document of a request made by a client to > an AS only applies for a request conformant to this profile > which may or may not include a scope parameter and which may or may not > include a "resource" parameter (and, if it does not, shall > include an "aud" claim). Currently, it is not possible to make a > difference between a JWT request or response conformant to this profile > and other JWT requests or responses. I don't see where this document places constraints on a "conformant request" made by a client; could you point that out to me? (FWIW, the section heading for section 3 seems needlessly confusing, as the contents of the section do not seem to say anything about specifically requesting a JWT token. I can see how this heading might cause some confusion.) > > Attempting to have the client provide input that would affect such a > > mechanism seems like complexity with no market demand; a "solution in > > search of a problem" as it were. Is there some pent-up demand among > > OAuth deployments that I'm not aware of? I freely admit to not being > > very on top of the broad spectrum of what's deployed... > >> 1) A client may wish to obtain an Access Token that corresponds to > >> this Profile because, for example, this document mandates the "sub" > >> claim to be present". Hence, the content of the Access Token is not > >> totally "/an internal matter between AS and RS/". However, I have not > >> understood how a client could request an Access Token that > >> corresponds to *_this_***Profile, since there is no mandatory > >> parameter in the request (both the "scope" parameter and the > >> "resource" parameter are optional). In the future, we could define > >> _*another*_**Profile. Hence, there is the same question:  How could a > >> client request an Access Token that corresponds to *_that > >> other_***Profile ? 2) When getting a JWT,  how can the client make > >> sure that the access token it got is compliant with this Profile ? > >> RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing > >> Sometimes, one kind of JWT can be confused for another. If a > >> particular kind of JWT is subject to such confusion, that JWT can > >> include an explicit JWT type value, and the validation rules can > >> specify checking the type (...). Explicit JWT typing is accomplished > >> by using the "typ" Header Parameter. Wouldn't be wise to include an > >> explicit JWT type value for JWTs conformant to this Profile ? > > In the model where the client is a "dumb" communications channel, this > > question does not seem interesting. But the related question of "how > > can the RS make sure that the access token it got was generated > > according to this profile?" does seem interesting, and seems like it > > would benefit from the same proposed solution. > > An explicit JWT type value added both in the JWT request and in the JWT > response would solve this problem. An explicit JWT type is a solution to the problme I'm interested in, yes. Though I don't know if that's what you mean by "this problem". > >> This relates to an email posted by Dominick Baier under the topic > >> "JAR: JWT typ" on May 19 : This has been brought up before - but no > >> response. Either I can’t find it - or it is missing. But is the > >> setting the JWT typ explicitly mentioned somewhere? > > It is fairly likely that I will remember to ask about explicit "typ" > > usage if I'm still on the IESG when this document gets there: I think > > I've been making a habit of doing so. > > Once again, an explicit "typ" sould be considered for both the JWT > request and the JWT response. This implies that the client "MUST" be > able to inspect the content of the access token. As above, I do not see how the client currently has input into the token type/format agreed upon by the AS/RS out-of-band, so I dispute both the premise and the supposed conclusion. -Ben From nobody Wed Jun 3 00:31:06 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8C3A0CB7 for ; Wed, 3 Jun 2020 00:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yahoo-corp.jp header.b=AKdqzv3t; dkim=pass (1024-bit key) header.d=yjcorp.onmicrosoft.com header.b=S2xU/CrS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyu0WmINK2em for ; Wed, 3 Jun 2020 00:31:02 -0700 (PDT) Received: from obrelay01.is.bbt.yahoo.co.jp (obrelay01.is.bbt.yahoo.co.jp [182.22.8.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5883A0CB4 for ; Wed, 3 Jun 2020 00:31:01 -0700 (PDT) Received: from corp-ob06.is.ssk.ynwp.yahoo.co.jp (corp-ob06.is.ssk.ynwp.yahoo.co.jp [182.22.89.23]) by obrelay01.is.bbt.yahoo.co.jp (Mailer-Daemon) with ESMTP id 0537Uxa1018531 for ; Wed, 3 Jun 2020 16:30:59 +0900 Received: from yjwex2drcas02.yjoffice.local (yjwex2casdr02.is.kks.yahoo.co.jp [172.22.63.28]) by corp-ob06.is.ssk.ynwp.yahoo.co.jp (Postfix) with ESMTP id 14EF9120067 for ; Wed, 3 Jun 2020 16:30:59 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-corp.jp; s=default; t=1591169459; bh=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; h=From:To:Subject:Date:References:In-Reply-To; b=AKdqzv3tTvRDyl8Gx4P5MVORVvoLYuy+LGv/yCm9B0CbHglbRUVFY3PzBkcTSBIGa XATyqi8WAqLmyQ6b7ari2Gx+/G97hX1V19zHlHNsuU16SkEWMK5o7FjL2NMiAi5F2G EE6C/g9waMab4ZjgmspQur/vjiB0vBhqkpWguH+8= Received: from yjwex2drmbx01.yjoffice.local (172.22.63.31) by yjwex2drcas02.yjoffice.local (172.22.63.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:30:58 +0900 Received: from yjwex2drcas01.yjoffice.local (172.22.63.27) by yjwex2drmbx01.yjoffice.local (172.22.63.31) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:30:58 +0900 Received: from yjwex2edge02.yjoffice.local (103.2.245.142) by yjwex2drcas01.yjoffice.local (172.22.63.26) with Microsoft SMTP Server id 15.0.1473.3 via Frontend Transport; Wed, 3 Jun 2020 16:30:58 +0900 Received: from APC01-HK2-obe.outbound.protection.outlook.com (104.47.124.52) by yjwex2edge02.yahoo-corp.jp (103.2.245.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:29:22 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EmV3kK/oFLo90YJCxXys/gKi+UqDaU9hJFjk9f9v3ka53MQheeHin0cJDu6mZb87EicKp/u7OLJ2UxebQI7wkAS/aeGWbMy+w7Yr6PCgcH2yXcUNH7CC/q4DcfropFrlit9rVt53KlgY+h3LkEaobgonUPyiSXB3QiddRcUKwCXp0yBD1c1qf6/FyjJeoKk6fHN+snwln+dQgGBJBRrbUi1SrB/L/AtiOVd165Sjp1qqM52yL4MbQyESmG+tCt1mtdQBZweHIxlGQgVHHqxwadkEOGa0+2ULI2t+UK4qFzTBv5Fkk8TbpV9RPaxj6JVuK1GTMhagNdpacU8wTNmDWA== 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=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; b=oeqY/hoPuPgLkzUGIBrKnaug9GLTxsS67G19BSCH3ptTiyBQkynIxC3E6ZLCTymQ6eh2lWDHeTlhSP5nfpV5Oow/i1ErnlK1sXUmV03+mG2AaxFewXfh+rQInpbUsDTEeIgmNI8SdMl5LMXG2HTT4TFyNnue1iDpxQqfvnzceapgf6vy7Oter+VznkkBNQBhqfol8BXg9HWvXal5RuZ2nP66ZCHHWJZQNjnC0OhyNgmO5kl9GUXHl5B/1uTQrz54F2/pz8d6tmCqFanCbHrJMo0yh0ephKefDfwIU5pSZYKlfJyEZFbAyIio684L317ovF0k1bHdHb7ikXZ0gW80WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yahoo-corp.jp; dmarc=pass action=none header.from=yahoo-corp.jp; dkim=pass header.d=yahoo-corp.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yjcorp.onmicrosoft.com; s=selector1-yjcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; b=S2xU/CrS9KeDsILnoWqjP6WIemeJ52Y5h1h+/npHxhUR3sndT7Dyv1Mdi0+venESJB4/Uwxn+j2tJ/i+MUbPFHP111UDlK0crhl5mBlVv27kqtlPz3swWfusHq2qvPTZEzIwRpUHaST5hPbXVhSvilvHjV7etAj2YQkfUmjjdao= Received: from TY2PR01MB4700.jpnprd01.prod.outlook.com (2603:1096:404:10c::13) by TY2PR01MB2954.jpnprd01.prod.outlook.com (2603:1096:404:74::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.18; Wed, 3 Jun 2020 07:30:56 +0000 Received: from TY2PR01MB4700.jpnprd01.prod.outlook.com ([fe80::fd94:5815:78a0:b1f9]) by TY2PR01MB4700.jpnprd01.prod.outlook.com ([fe80::fd94:5815:78a0:b1f9%6]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 07:30:56 +0000 From: Kazuki Tsuzuku To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Downgrade attacks on PKCE Thread-Index: AQHWOWp55OcPG6IcEUS6ob+YhLP7N6jGfOLD Date: Wed, 3 Jun 2020 07:30:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=yahoo-corp.jp; x-originating-ip: [211.14.29.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6fddb812-4922-4920-4113-08d807900e10 x-ms-traffictypediagnostic: TY2PR01MB2954: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hiVX+yvLrashU0K2q+wTekF0tL7O+IViwVwlqwY0tEX2WAnE3n11THHPQeq93nhFd5Xry9seqCarm3SmtLD7It0GqYAaiZgMvFVA2oUGKKKLbXD6oZhrYMppk9VfMgWsloK+8qG8D8JzpS0VDrFBztxXDiUjQgTFnWx0d40IBhnR0ONlRQeqEENKX4QfjH/Eu7d9Q8v3eBcJs4qeWL6T97jIxnWWDDvHbDw4zWUd5mFdGNNkrWTu5QQoYPcXpfmbymgIRVRkt8cUZWl+G3wWoTEmDTrBG5kbEH9h9cmx1n+yrlSZ4wroCDYIdXarP9SsK6yWWMmlaERxLtU++3/9i7VqbT8S6f1zNGLa3Aj+D+bBzYBTATilCQv7IDnnO97jEio9oYiU/iNEFjsWXlvHWw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB4700.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(186003)(86362001)(2940100002)(8936002)(55016002)(26005)(966005)(6916009)(316002)(19627405001)(6506007)(7696005)(8676002)(9686003)(53546011)(85182001)(478600001)(66476007)(66556008)(166002)(66446008)(66946007)(71200400001)(33656002)(76116006)(52536014)(83380400001)(64756008)(5660300002)(83080400001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CXdC3D18fLjIOGkGXL/HmhhTQcYIE0jobEUIWKb3/C0zfR7o4f8RC6fO7Ns7waCir32CC0UsmhiWX0uMK7+phYjMIGaQgT7xG6d+8cqsbujRDyVrQ5C4HJtGByxmo+SpDfac/oP+z0Hd+k6FOMFd0svG5NJBOQ8TxUpkSV9SLoeLTcGp0fIU6AR4V6it8+UZOMB0WKO9jTQJRRfdhvIIaengWowSwfEcXawogUD1qT4AMK6y+aKv1Re3y3+Fa/fbSDASukRAQBQxBtEFDPQYVesaM/Nt3TH1iRiSAjWheB1pmm5vr2w33Ch7c/ufOEI7rh3Y5a4p60o1H14HUe+y7wGeYzA1nDFpY2AmjFY0FXCCoX7PfU0Y5mX/+i8pEwtWqXSDJS4iQ1JKxHt7ptfDhP4Rf9ySPDfSRPlPqEkTuyTUtEz7+QGaL4UZzT/hS6HIHSGN+lJ3WqhwbjY0BZ7E/T4zKEwizM9IcI3bDnFUmTg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6fddb812-4922-4920-4113-08d807900e10 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 07:30:56.5286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a208d369-cd4e-4f87-b119-98eaf31df2c3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OENxltm+THx/wqYraEHEXF3VmRXMMxbTkQL5jow2M92GB8/hxESEg59PFXwcGlvk7p0q/UI7jZJN0F7kAgF8xg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2954 Archived-At: Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 07:31:05 -0000 --_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable We(Yahoo! JAPAN) agree with option 2. Option 1 is not realistic for us as an IdP with thousands of clients becaus= e it will force them to change implementations. Also, we already implemented 2 and it was not complicated. Kazuki Tsuzuku > On 30 May 2020, at 08:58, Daniel Fett wrote: > > Hi all, > > Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE = [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusio= n that we have two options: > > 1. "Static" Solution > > For every client_id that is registered with an AS, the AS MUST either alw= ays enforce the use of PKCE or always enforce the use of nonce. Whether PKC= E or nonce is enforced can be part of the client registration or configured= in other ways. > > In other words: A single client is not allowed to switch between using PK= CE and using nonce. > > Note that the client is allowed to use the respective other mechanism on = top of the enforced one. > > Properties: > Easy to understand mitigation. > Implementation is mainly a new data field and a check in the authorizatio= n request. > Not compatible to deployments where clients sometimes use nonce and somet= imes use PKCE with the same client_id. > 2. "Dynamic" Solution > > Each AS that supports PKCE MUST check whether a code challenge is contain= ed in the authorization request. This information MUST be bound to the code= that is issued. > > When a code arrives at the token endpoint, the AS MUST do the following c= heck: > > If there was a code_challenge in the authorization request for which this= code was issued, there must be a code_verifier in the token request and it= must be verified according to RFC7636. (This is no change from the current= behavior in RFC7636.) > If there was no code_challenge in the authorization request, any request = to the token endpoint containing a code_verifier MUST be rejected. > Properties: > > No change in behavior needed for properly implemented clients. Backwards = compatible for all existing deployments. > Implementation is mainly some logic for the authorization endpoint, token= endpoint, and a new data field in the authorization session maintained by = the AS. > Slightly more complex to implement for the AS, maybe. > We would like to hear the feedback from the working group on these two so= lutions before proceeding to propose wording for the affected documents. > > [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > > -Daniel > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
We(Yahoo! JAPAN) agree with option 2.
Option 1 is not realistic for us as an IdP with thousands of clients b= ecause it will force them to change implementations.
Also, we already implemented 2 and it was not complicated.

Kazuki Tsuzuku

> On 30 May 2020, at 08:58, Daniel Fett <fett@danielfett.de>= wrote:
>
> Hi all,
>
> Aaron, Dick, Torsten and I today discussed the downgrade attacks = on PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the c= onclusion that we have two options:
>
> 1. "Static" Solution
>
> For every client_id that is registered with an AS, the AS MUST ei= ther always enforce the use of PKCE or always enforce the use of nonce. Whe= ther PKCE or nonce is enforced can be part of the client registration or co= nfigured in other ways.
>
> In other words: A single client is not allowed to switch between = using PKCE and using nonce.
>
> Note that the client is allowed to use the respective other mecha= nism on top of the enforced one.
>
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the auth= orization request.
> Not compatible to deployments where clients sometimes use nonce a= nd sometimes use PKCE with the same client_id.
> 2. "Dynamic" Solution
>
> Each AS that supports PKCE MUST check whether a code challenge is= contained in the authorization request. This information MUST be bound to = the code that is issued.
>
> When a code arrives at the token endpoint, the AS MUST do the fol= lowing check:
>
> If there was a code_challenge in the authorization request for wh= ich this code was issued, there must be a code_verifier in the token reques= t and it must be verified according to RFC7636. (This is no change from the= current behavior in RFC7636.)
> If there was no code_challenge in the authorization request, any = request to the token endpoint containing a code_verifier MUST be rejected.<= br>
> Properties:
>
> No change in behavior needed for properly implemented clients. Ba= ckwards compatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoin= t, token endpoint, and a new data field in the authorization session mainta= ined by the AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on thes= e two solutions before proceeding to propose wording for the affected docum= ents.
>
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-= not/ <https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/&= gt;
>
> -Daniel
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_-- From nobody Wed Jun 3 03:12:10 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7743A0FAF for ; Wed, 3 Jun 2020 03:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPOneoVIXYak for ; Wed, 3 Jun 2020 03:12:02 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AEE3A0788 for ; Wed, 3 Jun 2020 03:12:00 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id maBx220044FMSmm03aBxgN; Wed, 03 Jun 2020 12:11:59 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 03 Jun 2020 12:11:59 +0200 X-ME-IP: 86.238.65.197 To: Hannes Tschofenig Cc: Rifaat Shekh-Yusef , Vittorio Bertocci , "oauth@ietf.org" References: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> From: Denis Message-ID: <24ffa213-1a09-f7d1-28f8-e1b678cf85d9@free.fr> Date: Wed, 3 Jun 2020 12:11:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FFB7FFA4DE674E508484D31D" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 10:12:09 -0000 This is a multi-part message in MIME format. --------------FFB7FFA4DE674E508484D31D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Hannes, First of all, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section. Let us look at the following proposed sentence: While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token     to the client. The access token is therefore, by design, considered to be opaque to the client". / In the context of this document/, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile (and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT. So, /in the context of this document/, the access token cannot be considered to be opaque to the client. About the second paragraph, /in the context of this document (/besides the case where the JWT is encrypted), it is neither difficult, nor impossible to parse the token/. / About the second paragraph, let us look at the following proposed sentence/in the context of this document/ : " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change       the token format at any time ". The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid /in the context of this document/. This JWT profile will be stable over time. This means that this quoted sentence is inappropriate /in the context of this document/. The third proposed paragraph is stating : "In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection       may provide a useful tool to enable such functionality (proper authorization assumed) ". RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients. As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed to be stable over time. The last proposed paragraph is the following:    " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement       to have access to any content received in form of claims, /for example through user consent in some form, policies and agreements with the organization running / /      the authorization servers, and so on/. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore       outside the scope of this document ". The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on" should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers. The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence: Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore outside the scope of this document. Finally, there are still two questions that have been raised but which have not yet been answered at this time: * how can a client request a JWT compliant to /this/ profile, and * how can a client be confident that it got a JWT compliant to /this/ profile ? Denis > Let me try to jump in here in order to make a proposal for the text in > the privacy consideration section: > > FROM: > > *6**.  > Privacy Considerations* > >    As JWT access tokens carry information by value, it now becomes > >    possible for requestors and receivers to directly peek inside the > >    token claims collection.  The client MUST NOT inspect the content of > >    the access token: the authorization server and the resource server > >    might decide to change token format at any time (for example by > >    switching from this profile to opaque tokens) hence any logic in the > >    client relying on the ability to read the access token content would > >    break without recourse. Nonetheless, authorization servers should > >    not assume that clients will comply with the above.  Whenever client > >    access to the access token content presents privacy issues for a > >    given scenario, the authorization server should take explicit steps > >    to prevent it as described below. > >    In scenarios in which JWT access tokens are accessible to the end > >    user, it should be evaluated whether the information can be accessed > >    without privacy violations (for example, if an end user would simply > >    access his or her own personal information) or if steps must be taken > >    to enforce cofidentiality. Possible measures include: encrypting the > >    access token, encrypting the sensitive claims, omitting the sensitive > >    claims or not using this profile, falling back on opaque access > >    tokens. > >    In every scenario, the content of the JWT access token will > >    eventually be accessible to the resource server.  It's important to > >    evaluate whether the resource server gained the proper entitlement to > >    have access to any content received in form of claims, for example > >    through user consent in some form, policies and agreements with the > >    organization running the authorization servers, and so on. > > TO: > > *6 > . > Privacy Considerations* > >    The design of OAuth 2.0 envisions that access tokens are created by > >    authorization servers and consumed by resource servers. > >    As JWT access tokens, as described in this document, carry > information by value, it is > >    possible for OAuth clients to peek inside the access token. > >    While this is technical possible, it is important to note that the > >    OAuth 2.0 protocol does not aim to expose the content of the > >    access token to the client. The access token is therefore, by > design, considered to be > >    opaque to the client. > >    A number of cases may make it difficult or impossible for clients to > >    inspect the token, for example, the access token may be encrypted, > >    the access token may contain vendor-specific claims that have not been > >    standardized or have been standardized in other consortia making > parsing > >    of the token difficult. Additionally, there is no guarantee that the > >    access token is conveyed by value and the authorization server > implementation > >    may change the token format at any time. > >    In scenarios where it is desirable for the clients to obtain > information > >    transmitted in the access token, OAuth 2.0 token introspection may > provide > >    a useful tool to enable such functionality (proper authorization > assumed). > >    In scenarios where the content of the access token must not be > readable > >    by clients, encrypting the content of the access token is RECOMMENDED. > >    Since the content of the access token is accessible to the resource > server > >    it is important to > >    evaluate whether the resource server gained the proper entitlement to > >    have access to any content received in form of claims, for example > >    through user consent in some form, policies and agreements with the > >    organization running the authorization servers, and so on. The > policies > >    and the user interfaces to enable this user consent are, however, part > >    of a specific deployment and therefore outside the scope of this > document. > > How does this sound? > > Ciao > > Hannes > > *From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef > *Sent:* Thursday, May 14, 2020 8:03 PM > *To:* Denis > *Cc:* Vittorio Bertocci ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens" > > Denis, > > You are rehashing the same issues that you have already discussed on > the mailing list multiple times, > > You could not get the WG to agree with your points, because the WG > believe that this issue is outside the scope of this document. > > The best the chairs can do at this stage is to capture your point in > the shepherd write-up to the IESG. > > We think this document has the support of the WG and is ready to > move forward. > > Regards, > >  Rifaat > > On Thu, May 14, 2020 at 12:29 PM Denis > wrote: > > Hi Vittorio, > > I am referring to the email you sent on April the 29 th which is > copied below. > > 1) You wrote: > > /> targeting of access tokens/ > > Let me think about that a bit longer. > > I acknowledge that the decision of including an audience has > the effect of letting the AS track when the client accesses a > particular resource, > but at the same time that’s completely mainstream and very > much by design in a very large number of cases. As such, I > find the language > you are suggesting to be potentially confusing, as it > positions this as an exception vs a privacy protecting > mainstream that is in fact not common, > and ascribes to the client more latitude than I believe is > legitimate to expect or grant. > > *I’ll try to come up with concise language that clarifies to > the reader that the current mechanism does allow AS tracking*. > > Since the last draft has been published on the 27 th, you have not > proposed any "concise language that clarifies to the reader > that the current mechanism does allow AS tracking". > > 2) You also wrote about the "sub" uniqueness: > > As long as an identifier identifies one resource only, it > satisfies uniqueness. It doesn’t have to be a singleton. > > RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim > using the following sentence: > > The subject value MUST either be scoped to be locally unique > in the context of the issuer or be globally unique. > > The text does NOT say that the subject value "MUST be scoped to be > locally unique in the context of the *resource server*". > > Changing the semantics of an already defined claim is not > permitted. If you would like to have such a semantics available, > a new claim should be defined (and it would be very nice to have > it !). > > 3) The text is the privacy considerations section states: > >    Although the ability to correlate requests might be required by > design in many scenarios, there are scenarios where the authorization >    server might want to prevent correlation to preserve the > desired level of privacy. > > In the real world, it is also clients or end-users which would > like to prevent correlation to preserve their desired level of > privacy. > > A better sentence would be: > >    Although the ability to correlate requests might be required by > design in many scenarios, there are scenarios where the authorization >    server *or the client* might want to prevent correlation to > preserve the desired level of privacy. > > 4) The text continues with: > >    Authorization servers should choose how to assign "sub" values > according to the level of privacy required by each >    situation.  For instance: if a solution requires preventing > tracking  principal activities across multiple resource servers, >    the  authorization server should ensure that JWT access tokens > meant for different resource servers have distinct "sub" >    values that cannot be correlated in the event of resource > servers collusion. > > Authorization servers are not necessarily able to choose the level > of privacy required by each situation. When there are different > situations for the same resource server, the scope is > (unfortunately at the moment) the only way to select the "level of > privacy that is required". > > The example ("For instance:") is only an example that provides a > vague recommendation for the ASs which is NOT conformant > with the semantics of the "sub" claim as defined in RFC 7519. > > What should be discussed here are not "examples" or what an > authorization server should do, but explanations about the > implications > for the end-user or for the client for the various values that can > be placed into the "sub" claim by an AS. The problem is wider that > simply > a collusion between resource servers, but also with other servers > that DO NOT participate in any OAuth exchange. > > RFC 6973 (Privacy Considerations) states in section 7 : Guidelines > > This section provides guidance for document authors in the > form of a questionnaire about a protocol being designed. > The questionnaire may be useful at any point in the design > process, particularly after document authors have developed > a high-level protocol model as described in [RFC4101]. > > One of the questions is: > > f. *Correlation*.  Does the protocol allow for correlation of > identifiers ? Are there expected ways that information exposed > by the protocol will be combined or *correlated with > information obtained outside the protocol* ? > > It is important to provide an answer to these two questions. > > Hereafter is some text that is fully conformant with RFC 7519 > which should be incorporated into the privacy considerations section > which explains the implications of the two (and only two) flavours > of the "sub" claim. > > When the sub claim contains a locally unique identifier in the > context of the issuer, this allows the tracking of principal > activities > across multiple resource servers. > > When the sub claim contains a globally unique identifier, this > allows to correlate principal activities across multiple resource > servers, while in addition, this globally unique identifier > may also allow to correlate the principal activities on > servers where > no access has been performed by the principals to these > servers but where the same globally unique identifiers are > being used > by these servers. > > Denis > > Thanks Denis for the thorough commentary. > > /> The title of this spec./ > > Fixed, thanks! > > /> The client MUST NOT inspect the content of the access token/ > > This is really a sticky point. I really want to acknowledge > your PoV on this, but at the same time I found this to be one > of the biggest sources of issues in the use of JWT for access > tokens hence I feel we really need to give solid guidance > here. Let me expand further on the reasoning behind it, and > perhaps we can get to language that satisfies both PoVs. > > To me the key point is that clients should not write /code/ > that inspects access tokens. Taking a dependency on the > ability to do so is ignoring fundamental information about the > architecture and relationships between OAuth roles, and > suggests an ability of the client to understand the semantic > of the content that cannot be assumed in the general case. I > expanded on the details in my former reply to you on this > topic, I would recommend referring to it. Clients violating > this simple principle has been one of the most common sources > of production issues I had to deal with in the past few years, > and one of the hardest to remediate given that clients are > hard to update and sometimes the things they relied on were > irremediably lost. This is why I am inclined to put in here > strong language. > > That said: I have nothing against client developers examining > a network trace and drawing conclusions based on the content > of what they see. That doesn’t create any hard dependencies > and has no implications in respect to changes in the solution > behavior. However I am not sure how to phrase that in the > specification, given that referring to the client inevitably > refers to its code. I am open to suggestions. > > >  3)… > > I have a pretty hard time following the chain of reasoning in > this section. Let me attempt to tackle it to the best of my > understanding. > > I think the key might be > > /> a client should be able to choose whether it wishes the sub > claim to contain [..]/ > > I don’t think that should be a choice left to the client. In > business systems, my experience is that the type of > identifiers to be used (when the IdP gives any choice at all) >  is established at resource provisioning time. I am not aware > of mechanisms thru which a client signals the nature of the > identifier to be used, nor that would be fully feasible (the > resource knows what it needs to perform its function). > > Furthermore: > > /> which has nothing to do with uniqueness since the value > changes for every generated token./ > > Again, this is something that was touched on in my former > reply to your message. As long as an identifier identifies one > resource only, it satisfies uniqueness. It doesn’t have to be > a singleton. > > Finally, the scope is optional (for good reasons: 1^st party > and non delegation scenarios don’t require it) hence it cannot > be relied upon for properties that should hold in every scenario. > > In summary: per the preceding thread on this topic, the > consensus was that varying the sub content was a satisfactory > way of protecting against correlation. I don’t a gree that > clients should have a mechanism to request different sub > flavors, as that decision should be done out of band by the AS > and RS; and the scope isn’t always available anyway. > > /> targeting of access tokens/ > > Let me think about that a bit longer. > > I acknowledge that the decision of including an audience has > the effect of letting the AS track when the client accesses a > particular resource, but at the same time that’s completely > mainstream and very much by design in a very large number of > cases. As such, I find the language you are suggesting to be > potentially confusing, as it positions this as an exception vs > a privacy protecting mainstream that is in fact not common, > and ascribes to the client more latitude than I believe is > legitimate to expect or grant. > > I’ll try to come up with concise language that clarifies to > the reader that the current mechanism does allow AS tracking. > > *From: *OAuth > on behalf of Denis > > *Date: *Wednesday, April 29, 2020 at 09:12 > *To: *"oauth@ietf.org" > > *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) > Profile for OAuth 2.0 Access Tokens" > > You will find four comments numbered 1) to 4). > > *1) *The title of this spec. is: > > JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens > > So, this spec. is supposed to be targeted to OAuth *2.0. > * However, the header at the top of the page omits to mention it. > > Currently, it is : > > Internet-Draft OAuth Access Token JWT Profile           April 2020 > > It should rather be: > > Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020 > > *2)* The following text is within section 6. > > The client MUST NOT inspect the content of > the access token: the authorization server and the resource server > might decide to change token format at any time (for example by > switching from this profile to opaque tokens) hence any logic > in the > client relying on the ability to read the access token content > would > break without recourse. > Nonetheless, authorization servers should > not assume that clients will comply with the above. > > It is of a primary importance that clients MAY be able to > inspect tokens before transmitting them. > The "MUST NOT" is not acceptable. > > The above text should be replaced with: > > Reading the access token content may be useful for the user to > verify that > the access token content matches with its expectations.  However, > the authorization server and the resource server might decide > to change the > token format at any time.  Thus, the client should not expect > to always be > in a position to read the access token content. > > The remaining of the text about this topic is fine. > > > *3) *The next topic is about the sub claim. > > The text states: > > Although the ability to correlate requests might be required by > design in many scenarios, there are scenarios where the > authorization > server might want to prevent correlation to preserve the desired > level of privacy. Authorization servers should choose how to > assign > sub values according to the level of privacy required by each > situation. > > I have a set of questions: > > 1. How can authorization servers choose how to assign sub > values according to the level of privacy required "by each > situation" ? > 2. How can authorization servers know the level of privacy > required "by each situation" ? > 3. How can the users be informed of the level of privacy > required "by each situation" ? > 4. How can the users *consent* with the level of privacy > required "by each situation" ? > > Currently, the request MUST include either a resource > parameter or an aud claim parameter, while it MAY include a > scope parameter. > > The syntax of the scope parameter is a list of > space-delimited, case-sensitive strings (RFC 6749). It is thus > subject to private agreements > between clients and Authorization Servers. Since the scope is > being returned, it is a primary importance that the returned > scope matches > with its expectations before transmitting the token to a > Resource Server. > > In theory, a client should be able to choose whether it wishes > the sub claim to contain : > > * a global unique identifier for all ASs ("globally unique"), > * a unique identifier for each AS ("locally unique in the > context of the issuer"), > * a different pseudonym for each RS, or > * a different pseudonym for each authorization token request. > > The only variable parameter that it can use for this purpose > in the token request is the scope parameter. > > RFC 7519 states is section 4.1.2: > > The subject value MUST either be scoped to be locally unique > in the context of the issuer > or be globally unique. > > It is quite hard to recognize that the sub claim is able to > carry a different pseudonym for each RS, i.e. for case (c), or > a different pseudonym for each authorization token request, > i.e. for case (d), which has nothing to do with uniqueness > since the value changes for every generated token. > > This has implications about the following text: > > For instance: if a solution requires preventing tracking > principal activities across multiple resource servers, the > authorization server should ensure that JWT access tokens > meant for > different resource servers have distinct sub values that cannot be > correlated in the event of resource servers collusion. > > Since it addresses case (c). > > and also about the following text: > > 4.b) Similarly: if a solution requires preventing a resource > server from > correlating the principal’s activity within the resource > itself, the > authorization server should assign different sub values for > every JWT > access token issued. > > Since it addresses case (d). > > This means that the current text placed in the privacy > considerations section was a good attempt to address the case, > but that the text needs to be revised. > > Proposed text replacement for all the previously quoted sentences: > > According to RFC 7519 (4.1.2): The subject value MUST either > be scoped to be locally unique in the context of the issuer or > be globally unique. > > When the sub claim contains a globally unique identifier, this > allows to correlate principal activities across multiple > resource servers, while in addition, > this globally unique identifier may also allow to correlate > the principal activities on servers where no access has been > performed by the principals > to these servers but where the same globally unique > identifiers are being used by these servers. > > When the sub claim contains a locally unique identifier in the > context of the issuer, this also allows the tracking of > principal activities across multiple resource servers. > > The scope request parameter is the only way to influence on > the content of the sub claim parameter. Its meaning is subject > to a private agreement > between the client and the AS, which means that the use of the > scope parameter is the only way to choose between a locally > unique identifier > in the context of the issuer or a globally unique identifier. > > Since the scope parameter is being returned, it is a primary > importance that the returned scope matches with the > expectations of the client before transmitting > the token to a Resource Server. > > However, there are other cases where the client would like to > be able to choose whether it wishes the sub claim to contain : >     - a different pseudonym for each RS so that different > resource servers will be unable to correlate its activities, or >     - a different pseudonym for each authorization token > request, so that the same resource server cannot correlate its > activities performed at different instant of time. > > Considering the semantics of the sub claim, these two cases > cannot be currently supported. > > > *4) *The next topic is about the targeting of access tokens > > Text had been proposed before the last conference call. Then, > the topic has been presented at the very end of the last > conference call, but no text has been included > in the next draft. > > Here is a revised text be included in the privacy > considerations section: > > For security reasons, some clients may be willing to target > their access tokens but, for privacy reasons, may be unwilling > to disclose to Authorization Servers > an identification of the Resource Servers they are going to > access, so that Authorization Servers will be unable to know > which resources servers are being accessed. > The disclosure of the Resource Servers names allows the > Authorization Servers to list all the Resource Servers being > access by all its users and in addition to list pairs > of (Principal, Resource Servers) which allow to trace all the > users accesses to Resource Servers performed through a given > Authorization Server. When a token is targeted, > this profile does not contain provisions to address these two > threats. > > Denis > > Hi all, > > This is a second working group last call for "JSON Web > Token (JWT) Profile for OAuth 2.0 Access Tokens". > > Here is the document: > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06 > > Please send your comments to the OAuth mailing list by > April 29, 2020. > > Regards, > >  Rifaat & Hannes > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > 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. --------------FFB7FFA4DE674E508484D31D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Hannes,

First of all, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section.

Let us look at the following proposed sentence:
    While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token
    to the client. The access token is therefore, by design, considered to be opaque to the client".

In the context of this document, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile
(and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT.
So, in the context of this document, the access token cannot be considered to be opaque to the client.
About the second paragraph, in the context of this document (besides the case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token.

About the second paragraph, let us look at the following proposed sentence in the context of this document :

    " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change
      the token format at any time ".
The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid in the context of this document.
This JWT profile will be stable over time. This means that this quoted sentence is inappropriate in the context of this document.
The third proposed paragraph is stating :

    " In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection
      may provide a useful tool to enable such functionality (proper authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients.
As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients
and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed
to be stable over time.

The last proposed paragraph is the following:
   " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
      to have access to any content received in form of claims, for example through user consent in some form, policies and agreements with the organization running
      the authorization servers, and so on. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore
      outside the scope of this document ".
The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on"
should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers.
The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence:

Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment
and therefore outside the scope of this document.
Finally, there are still two questions that have been raised but which have not yet been answered at this time:

  • how can a client request a JWT compliant to this profile, and
  • how can a client be confident that it got a JWT compliant to this profile ?


Denis


Let me try to jump in here in order to make a proposal for the text in the privacy consideration section:

 

FROM:

6.  Privacy Considerations

 

 

   As JWT access tokens carry information by value, it now becomes

   possible for requestors and receivers to directly peek inside the

   token claims collection.  The client MUST NOT inspect the content of

   the access token: the authorization server and the resource server

   might decide to change token format at any time (for example by

   switching from this profile to opaque tokens) hence any logic in the

   client relying on the ability to read the access token content would

   break without recourse.  Nonetheless, authorization servers should

   not assume that clients will comply with the above.  Whenever client

   access to the access token content presents privacy issues for a

   given scenario, the authorization server should take explicit steps

   to prevent it as described below.

 

   In scenarios in which JWT access tokens are accessible to the end

   user, it should be evaluated whether the information can be accessed

   without privacy violations (for example, if an end user would simply

   access his or her own personal information) or if steps must be taken

   to enforce cofidentiality.  Possible measures include: encrypting the

   access token, encrypting the sensitive claims, omitting the sensitive

   claims or not using this profile, falling back on opaque access

   tokens.

 

   In every scenario, the content of the JWT access token will

   eventually be accessible to the resource server.  It's important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on.

 

TO:

 

6.  Privacy Considerations

   The design of OAuth 2.0 envisions that access tokens are created by

   authorization servers and consumed by resource servers.

   As JWT access tokens, as described in this document, carry information by value, it is

   possible for OAuth clients to peek inside the access token.

   While this is technical possible, it is important to note that the

   OAuth 2.0 protocol does not aim to expose the content of the

   access token to the client. The access token is therefore, by design, considered to be

   opaque to the client.

 

   A number of cases may make it difficult or impossible for clients to

   inspect the token, for example, the access token may be encrypted,

   the access token may contain vendor-specific claims that have not been

   standardized or have been standardized in other consortia making parsing

   of the token difficult. Additionally, there is no guarantee that the

   access token is conveyed by value and the authorization server implementation

   may change the token format at any time.

 

   In scenarios where it is desirable for the clients to obtain information

   transmitted in the access token, OAuth 2.0 token introspection may provide

   a useful tool to enable such functionality (proper authorization assumed).

 

   In scenarios where the content of the access token must not be readable

   by clients, encrypting the content of the access token is RECOMMENDED.

  

   Since the content of the access token is accessible to the resource server

   it is important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on. The policies

   and the user interfaces to enable this user consent are, however, part

   of a specific deployment and therefore outside the scope of this document.

 

 

How does this sound?

 

Ciao

Hannes

 

 

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, May 14, 2020 8:03 PM
To: Denis <denis.ietf@free.fr>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

 

Denis,

 

You are rehashing the same issues that you have already discussed on the mailing list multiple times,

You could not get the WG to agree with your points, because the WG believe that this issue is outside the scope of this document.

 

The best the chairs can do at this stage is to capture your point in the shepherd write-up to the IESG.

We think this document has the support of the WG and is ready to move forward.

 

Regards,

 Rifaat

 

 

On Thu, May 14, 2020 at 12:29 PM Denis <denis.ietf@free.fr> wrote:

Hi Vittorio,

 

I am referring to the email you sent on April the 29 th which is copied below.

 

1) You wrote:

> targeting of access tokens

Let me think about that a bit longer.

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

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

Since the last draft has been published on the 27 th, you have not proposed any "concise language that clarifies to the reader
that the current mechanism does allow AS tracking".

 

2) You also wrote about the "sub" uniqueness:

As long as an identifier identifies one resource only, it satisfies uniqueness. It doesn’t have to be a singleton.

RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using the following sentence:

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

The text does NOT say that the subject value "MUST be scoped to be locally unique in the context of the resource server".

Changing the semantics of an already defined claim is not permitted. If you would like to have such a semantics available,
a new claim should be defined (and it would be very nice to have it !).

 

3) The text is the privacy considerations section states:

 

   Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization
   server might want to prevent correlation to preserve the desired level of privacy.

 

In the real world, it is also clients or end-users which would like to prevent correlation to preserve their desired level of privacy.

 

A better sentence would be:

 

   Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization
   server or the client might want to prevent correlation to preserve the desired level of privacy.

 

4) The text continues with:

 

   Authorization servers should choose how to assign "sub" values according to the level of privacy required by each
   situation.  For instance: if a solution requires preventing tracking  principal activities across multiple resource servers,
   the  authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub"
   values that cannot be correlated in the event of resource servers collusion. 

 

Authorization servers are not necessarily able to choose the level of privacy required by each situation. When there are different
situations for the same resource server, the scope is (unfortunately at the moment) the only way to select the "level of privacy that is required".

 

The example ("For instance:") is only an example that provides a vague recommendation for the ASs which is NOT conformant
with the semantics of the "sub" claim as defined in RFC 7519.

 

What should be discussed here are not "examples" or what an authorization server should do, but explanations about the implications
for the end-user or for the client for the various values that can be placed into the "sub" claim by an AS. The problem is wider that simply
a collusion between resource servers, but also with other servers that DO NOT participate in any OAuth exchange.

 

RFC 6973 (Privacy Considerations) states in section 7 : Guidelines

This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. 
The questionnaire may be useful at any point in the design process, particularly after document authors have developed
a high-level protocol model as described in [RFC4101].

One of the questions is:

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

It is important to provide an answer to these two questions.

 

Hereafter is some text that is fully conformant with RFC 7519 which should be incorporated into the privacy considerations section
which explains the implications of the two (and only two) flavours of the "sub" claim.

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

 

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

Denis

Thanks Denis for the thorough commentary.

 

> The title of this spec.

Fixed, thanks!

 

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

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

To me the key point is that clients should not write code that inspects access tokens. Taking a dependency on the ability to do so is ignoring fundamental information about the architecture and relationships between OAuth roles, and suggests an ability of the client to understand the semantic of the content that cannot be assumed in the general case. I expanded on the details in my former reply to you on this topic, I would recommend referring to it. Clients violating this simple principle has been one of the most common sources of production issues I had to deal with in the past few years, and one of the hardest to remediate given that clients are hard to update and sometimes the things they relied on were irremediably lost. This is why I am inclined to put in here strong language.

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

 

>  3)…

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

I think the key might be   

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

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

Furthermore:

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

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

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

In summary: per the preceding thread on this topic, the consensus was that varying the sub content was a satisfactory way of protecting against correlation. I don’t a gree that clients should have a mechanism to request different sub flavors, as that decision should be done out of band by the AS and RS; and the scope isn’t always available anyway.

> targeting of access tokens

Let me think about that a bit longer.

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

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

 

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

 

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

1) The title of this spec. is:

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

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

Currently, it is : 

Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft       OAuth 2.0 Access Token JWT Profile           April 2020

2) The following text is within section 6.

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

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

The above text should be replaced with:

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

The remaining of the text about this topic is fine.


3) The next topic is about the sub claim.

The text states:

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

I have a set of questions:

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

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

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

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

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

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

RFC 7519 states is section 4.1.2:

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

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

This has implications about the following text:

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

Since it addresses case (c).

and also about the following text:

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

Since it addresses case (d).

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

Proposed text replacement for all the previously quoted sentences:

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

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

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

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

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

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

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


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

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

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

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

Denis

Hi all,

 

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

 

Here is the document:

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

 

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

 

Regards,

 Rifaat & Hannes

 

 

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

 

 

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

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


--------------FFB7FFA4DE674E508484D31D-- From nobody Wed Jun 3 06:32:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1D3A0F14 for ; Wed, 3 Jun 2020 06:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSEDgk9wqW71 for ; Wed, 3 Jun 2020 06:32:30 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A10C3A0EE4 for ; Wed, 3 Jun 2020 06:32:30 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id e5so1829510ote.11 for ; Wed, 03 Jun 2020 06:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UtASniKMcM/z7PC1EO6R3tebRK5gXpurKtrfWc3Qfo=; b=Bfw5Do7seI5As5CVbGXF/X7V9FTYbBSs19xrLZmDnUWyCjX4aICPipScIrSNtHC3mm DvfTGcD78rnhVKH71te2w4Cog4bE9DBvcO/40lsgyPvhzJNYZZhvwjkieoYOxn+H0/Oz 92vSl80ct6ZtKJWlspl7SLrZyMbkaRsBbX0AQ= 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=2UtASniKMcM/z7PC1EO6R3tebRK5gXpurKtrfWc3Qfo=; b=ByFxwUdM7HYg1k8WrhrkFfe4FVBasXQZEIsCY5rnJypofh94EGYDYlBSG507t1twMj nM7oX11kWhuf7Mpj/Cf4bO7RQUiWn9Oa5NRKBfS+2vv1ZfH7ci9DEd9CMFQvdqwlfBGx H5woWRWzLGcAK7fKlQow21ArBQ42tumB75HYyF67gFuJVjF3SvIAuikdQRQvMykQK2hQ WqVCAamPp+3OOkQaHYz7q0O31oAoXpvW8XshwU3bqhUp6HnnFhaSu8YOfJfusaPV/4xG Sx9ROrfoc1i7NLkDN++2J5yGSRN7ncNU64PLj0TmC4eNRIEJIHTbmIajqSvMkUCnWyVk 25Yw== X-Gm-Message-State: AOAM530TAu9n+P22/Zt3eEQoKWRRWmXvdblYewdmQot2WiulEfCyKxBw BjbCefbYwomsb/8HwP76DlpuYW4Q6LCIaW4d2XjDlKemCuKoFNpw X-Google-Smtp-Source: ABdhPJy00/bX8qULXSJ6lbg37V+m3Z81Che7gIIqxJ6yjJ7qwLmt67muzftBRAV89vXE4C+ASQqq1XypYGsS5kximCA= X-Received: by 2002:a9d:6349:: with SMTP id y9mr17484otk.260.1591191149076; Wed, 03 Jun 2020 06:32:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Wed, 3 Jun 2020 15:32:17 +0200 Message-ID: To: Francis Pouatcha Cc: OAuth WG , Openid-specs Fapi Content-Type: multipart/alternative; boundary="00000000000035f71e05a72e0f2b" Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 13:32:33 -0000 --00000000000035f71e05a72e0f2b Content-Type: text/plain; charset="UTF-8" Thank you for the replies to this message. I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery doc, however that is not always possible. I'd like to understand Francis what particular issue you see from allowing an AS to specify multiple authorization_endpoints? I can see that to avoid user confusion it would be necessary for the Client to record which endpoint they redirected the user to, in case they need the user to re-authorize - but I can't see any particular security issue? No matter which authorization_endpoint the user was sent to, after the user is redirected back to the Client's redirect_uri the process is the same as if there had been 1 authorization_endpoint. I am in favour of Vladimir's suggestion of: "alternative_authorization_endpoints": { "banking": { "authorization_endpoint": "https://loadsamoney/business/auth", "description": "loadsmoney business banking customers", "logo_url": "https://loadsamoney/business/logo.png" }, "personal": { "authorization_endpoint": "https://loadsamoney/consumer/auth", "description": "loadsmoney personal customers", "logo_url": "https://loadsamoney/consumer/logo.png" } } Dave On Wed, 27 May 2020 at 16:09, Francis Pouatcha wrote: > >> >> Message: 1 >> Date: Tue, 26 May 2020 09:03:16 +0300 >> From: Vladimir Dzhuvinov >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands >> Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com> >> Content-Type: text/plain; charset="utf-8" >> >> My understanding of the branding concept was to present different UIs to >> resource owners during login and authorization, while keeping the OP / >> AS the same, meaning identical issuer. In a spec it would be helpful to >> spell out what branding means (and what not). >> > Let us call this varian the AS-Brand. > As an RO, I sign in for AS-Brand-A and my token is usable under the > context of AS-Brand-B because both share the same issuer. This kills > transparency at the RO site. > > I support: One AS-Brand <-> One Issuer. > > Regards > /Francis > >> >> Regarding a token being issued for "personal" vs "business" and >> confusion - the usage of the token is normally defined by its scope and >> audience (RS) and if this rule is observed (and it's not relied solely >> on the issuer URI for that) then clients shouldn't get confused here. >> >> Vladimir >> >> On 23/05/2020 06:26, Francis Pouatcha wrote: >> > - I will go for Option 1 even if we have the same runtime instance >> > producing tokens under different?issuer uris. >> > - Option 2 might expose security risk as many clients rely on >> > the?issuer to associate the? token with authorization context. By no >> > way shall a token issued for "personal" be valid for "business". >> > Therefore considering?the?use of the?same issuer here might lead to >> > confusion at the?RP. >> > - In order to avoid confusion, AS must make?sure each "brand" >> > uses?separated key material to produce the token. >> > >> > BTW: >> > The term brand as used in the context of most Open Banking initiatives >> > refers to entities consuming the Interface provided by TPPs (Third >> > Party Providers).. TPPs play the roles of RPs in the oAuth2 context. >> > >> > Unless I misunderstood this thread we are using a brand here to refer >> > to an AS virtual host (issuer-uri). >> > >> > Going forward, we need?to?agree on choosing another term to refer to >> > issuers, and leave the term "Brand" for consumers of TPP-interfaces. >> > >> > The core brand problem we will be facing in open banking is for having >> > the AS display the "consumer-brand" logo to the RO in the consent >> screen. >> > >> > >> > >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov >> > > wrote: >> > >> >> > >> With that said it makes sense to devise a structure which can >> > accommodate UI driven as well as automatic choice. >> > >> >> > >>? ? ? ? The UI driven chooser will need a human readable >> > description and other UI hints. This can work for instance with >> > "classic" OIDC Discovery. >> > >> >> > >>? ? ? ? The "auto" chooser will need some sort of an ID. For a >> > bank chooser this means providing the issuer URI and an optional >> > brand ID and both must get registered together. Or, one could >> > define a standard brand ID (label) for banking operations and if >> > the "alternative_authorization_endpoints" is present look for it >> > in the structure, else fall back to the default >> > "authorization_endpoint". >> > >> Here is one possible layout which has IDs and UI hints: >> > >> >> > >> { >> > >>? ?... >> > >>? ?"alternative_authorization_endpoints": { >> > >>? ? ?"banking": { >> > >>? ? ? ?"authorization_endpoint": >> > >> "https://loadsamoney/business/auth" >> > >> , >> > >>? ? ? ?"description": "loadsmoney business banking customers", >> > >>? ? ? ?"logo_url": >> > >> "https://loadsamoney/business/logo.png" >> > >> >> > >>? ? ?}, >> > >>? ? ?"personal": { >> > >>? ? ? ?"authorization_endpoint": >> > >> "https://loadsamoney/consumer/auth" >> > >> , >> > >>? ? ? ?"description": "loadsmoney personal customers", >> > >>? ? ? ?"logo_url": >> > >> "https://loadsamoney/consumer/logo.png" >> > >> >> > >>? ? ?} >> > >>? ?} >> > >> } >> > >> >> > >> >> > >> >> > >> On 22/05/2020 09:59, Torsten Lodderstedt wrote: >> > >>> I think an id or label per endpoint set would be needed to >> > determine the set of endpoints to be used by a certain client. >> > >>> >> > >>> On the conceptual side, I?m asking myself how the complete >> > process is supposed to work. Who is deciding what issuer/endpoint >> > set combination to use. I assume in an open banking scenario, >> > there will always be some kind of bank chooser. Will this chooser >> > provide the client with issuer and brand id? >> > >>> >> > >>> >> > >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov >> > > >> > >>>>? wrote: >> > >>>> >> > >>>> A mapping like the one you propose can definitely work. Since >> > the user will be making the choice which endpoint to take with the >> > client app, having the logo_uri is a good idea. If the branded >> > endpoints differ somehow in policy one could also allow inclusion >> > of the op_policy_uri and op_tos_uri params from Discovery. >> > >>>> >> > >>>> >> > >>>> >> > >> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery >> > >>>> >> > >>>> >> > >>>> Vladimir >> > >>>> >> > >>>> On 20/05/2020 19:16, Joseph Heenan wrote: >> > >>>> >> > >>>>> Thanks for your thoughts Vladimir! >> > >>>>> >> > >>>>> The client_id based solution I wasn?t previously aware of - >> > unfortunately it doesn?t solve the problem for app2app, as the >> > mobile OS selects the app to use based purely on the URL (and in >> > at least the iOS case will not offer the user a choice if multiple >> > apps claim to handle the same url). >> > >>>>> >> > >>>>> I think some kind of mapping like you suggest will work and >> > fallback, I wonder about a structure in the authorization server >> > metadata something like this: >> > >>>>> >> > >>>>> { >> > >>>>>? ?... >> > >>>>>? ?"alternative_authorization_endpoints": [ >> > >>>>>? ? ?{ >> > >>>>>? ? ? ?"authorization_endpoint": >> > >>>>> "https://loadsamoney/business/auth" >> > >>>>> , >> > >>>>>? ? ? ?"description": "loadsmoney business banking customers", >> > >>>>>? ? ? ?"logo_url": >> > >>>>> "https://loadsamoney/business/logo.png" >> > >>>>> >> > >>>>>? ? ?}, >> > >>>>>? ? ?{ >> > >>>>>? ? ? ?"authorization_endpoint": >> > >>>>> "https://loadsamoney/consumer/auth" >> > >>>>> , >> > >>>>>? ? ? ?"description": "loadsmoney personal customers", >> > >>>>>? ? ? ?"logo_url": >> > >>>>> "https://loadsamoney/consumer/logo.png" >> > >>>>> >> > >>>>>? ? ?} >> > >>>>>? ?] >> > >>>>> } >> > >>>>> >> > >>>>> And as you say, the existing authorization_endpoint can be a >> > fallback for clients that are unaware of the new spec or prefer >> > the simpler option of just using a single authorization endpoint. >> > Supporting the new spec would allow a better UX though so there?s >> > advantages to client to do so. >> > >>>>> >> > >>>>>> Speaking of mTLS, I'm not sure how the >> > "mtls_endpoint_aliases" can be sensibly combined with the proposed >> > multi-brand spec. >> > >>>>>> >> > >>>>>> >> > >>>>> I think that particular part is not really an issue as mtls >> > isn?t used at the authorization endpoint. >> > >>>>> >> > >>>>> Thanks >> > >>>>> >> > >>>>> Joseph >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov >> > > >> > >>>>>>? wrote: >> > >>>>>> >> > >>>>>> Hi Dave, >> > >>>>>> >> > >>>>>> In the absence of such a "multi-brand" spec we have tackled >> > this issue in the past by letting the "brand" be encoded in the >> > client_id. An alternative scenario is to do a "brand" lookup by >> > client_id. Then let the AS render the "branded" authZ endpoint. >> > >>>>>> >> > >>>>>> You're probably aware the mTLS spec is allowing for >> > endpoint aliases, so this is not the first time such as need has >> > occurred: >> > >>>>>> >> > >>>>>> >> > >>>>>> https://tools.ietf.org/html/rfc8705#section-5 >> > >>>>>> >> > >>>>>> >> > >>>>>> One could devise a similar JSON object with mappings >> > "label" - "authorization_endpoint". >> > >>>>>> >> > >>>>>> Clients that are aware of the new spec will look it up, >> > those that are not will fall back to the std >> "authorization_endpoint". >> > >>>>>> >> > >>>>>> Speaking of mTLS, I'm not sure how the >> > "mtls_endpoint_aliases" can be sensibly combined with the proposed >> > multi-brand spec. >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> Vladimir >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> On 20/05/2020 15:07, Dave Tonge wrote: >> > >>>>>> >> > >>>>>>> Dear OAuth WG >> > >>>>>>> >> > >>>>>>> We have an issue in the OpenID FAPI Working Group that we >> > believe affects the wider OAuth community. >> > >>>>>>> >> > >>>>>>> In summary: what is the recommended approach to discovery >> > (RFC8414) for Authorization Servers who support multiple "brands" . >> > >>>>>>> >> > >>>>>>> If brands are completely separate, then it seems sensible >> > that each brand must have its own `issuer` and therefore its own >> > discovery document at the correct location (i.e. brand 1 would >> > have an issuer of >> > >>>>>>> "https://as/brand1" and a discovery document available at? >> > https://as/.well-known/oauth-authorization-server/brand1 >> > >>>>>>> ). >> > >>>>>>> >> > >>>>>>> However in the real world it is not always so simple. We >> > have many existing implementations in UK open banking that support >> > multiple authorization endpoints. Here is an example (thanks to >> > @Joseph Heenan ) >> > >>>>>>> >> > >>>>>>> >> > >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking, >> > one ?login page? for both business and personal customers. >> > >>>>>>>> >> > >>>>>>>> They have separate mobile apps for business/personal, and >> > are required to support app2app. This means they will definitely >> > be exposing multiple authorization endpoints (as there?s a 1:1 >> > mapping of authorization endpoints to mobile apps) - the choice is >> > how they do this. >> > >>>>>>>> >> > >>>>>>>> Their choices are: >> > >>>>>>>> >> > >>>>>>>> 1. Multiple discovery endpoints (one for business, one >> > for personal), each with a different authorization endpoint, >> > multiple issuers (if their vendor allows this) >> > >>>>>>>> 2. Single discovery endpoint, single issuer, multiple >> > authorization endpoints listed in one discovery doc (one for >> > business, one for personal) some of which are hardcoded by the 3rd >> > party >> > >>>>>>>> 3. Multiple discovery endpoints each with a different >> > authorization endpoint, same issuer in all cases (breaks RFC8414 >> > and OIDC Discovery) >> > >>>>>>>> >> > >>>>>>> Option 3 is invalid and that leaves us with options 1 and 2. >> > >>>>>>> Option 1 can be problematic as often it is in reality the >> > same `issuer` behind the scenes. >> > >>>>>>> >> > >>>>>>> We would like to get feedback on this issue and >> > potentially an extension to RFC8414 to allow the definition of >> > multiple authorization endpoints. >> > >>>>>>> >> > >>>>>>> Thanks in advance >> > >>>>>>> >> > >>>>>>> Dave Tonge >> > >>>>>>> Co-Chair FAPI WG >> > >>>>>>> Open ID Foundation >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>> -- >> > >>>> Vladimir Dzhuvinov >> > > > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --00000000000035f71e05a72e0f2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the replies to this message= .

I agree that the best deployment option is: 1 brand =3D 1 = issuer =3D 1 discovery doc, however that is not always possible.

<= /div>
I'd like to understand Francis what particular issue you see from = allowing an AS to specify multiple authorization_endpoints?
I can see = that to avoid user confusion it would be necessary=C2=A0for the Client to r= ecord which endpoint they redirected the user to, in case they need the use= r to re-authorize - but I can't see any particular security issue?

No matter which authorization_endpoint the user was sent to, aft= er the user is redirected back to the Client's redirect_uri the process= is the same as if there had been 1 authorization_endpoint.=C2=A0

=
I am in favour of Vladimir's suggestion of:

"= alternative_authorization_endpoints": {
=C2=A0 =C2=A0 "banking= ": {
=C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "= ;https://loadsamoney/business= /auth",
=C2=A0 =C2=A0 =C2=A0 "description": "loa= dsmoney business banking customers",
=C2=A0 =C2=A0 =C2=A0 "log= o_url": "https:= //loadsamoney/business/logo.png"
=C2=A0 =C2=A0 },
=C2=A0 =C2= =A0 "personal": {
=C2=A0 =C2=A0 =C2=A0 "authorization_end= point": "https://lo= adsamoney/consumer/auth",
=C2=A0 =C2=A0 =C2=A0 "descriptio= n": "loadsmoney personal customers",
=C2=A0 =C2=A0 =C2=A0= "logo_url": "https://loadsamoney/consumer/logo.png"
=C2=A0 =C2=A0 }
= =C2=A0 }

Dave


On Wed, 27 May 2020 at 16:0= 9, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:


Message: 1
Date: Tue, 26 May 2020 09:03:16 +0300
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2= id.com>
Content-Type: text/plain; charset=3D"utf-8"

My understanding of the branding concept was to present different UIs to resource owners during login and authorization, while keeping the OP /
AS the same, meaning identical issuer. In a spec it would be helpful to
spell out what branding means (and what not).
Let us c= all this varian the AS-Brand.=C2=A0
As an RO, I sign=C2=A0in for = AS-Brand-A and my token is usable under the context of AS-Brand-B because b= oth share the same issuer.=C2=A0 This kills transparency=C2=A0at the RO sit= e.

I support: One AS-Brand <-> One Issuer.

Regards
/Francis

Regarding a token being issued for "personal" vs "business&q= uot; and
confusion - the usage of the token is normally defined by its scope and
audience (RS) and if this rule is observed (and it's not relied solely<= br> on the issuer URI for that) then clients shouldn't get confused here.
Vladimir

On 23/05/2020 06:26, Francis Pouatcha wrote:
> - I will go for Option 1 even if we have the same runtime instance
> producing tokens under different?issuer uris.
> - Option 2 might expose security risk as many clients rely on
> the?issuer to associate the? token with authorization context. By no > way shall a token issued for "personal" be valid for "b= usiness".
> Therefore considering?the?use of the?same issuer here might lead to > confusion at the?RP.
> - In order to avoid confusion, AS must make?sure each "brand"= ;
> uses?separated key material to produce the token.
>
> BTW:
> The term brand as used in the context of most Open Banking initiatives=
> refers to entities consuming the Interface provided by TPPs (Third
> Party Providers).. TPPs play the roles of RPs in the oAuth2 context. >
> Unless I misunderstood this thread we are using a brand here to refer<= br> > to an AS virtual host (issuer-uri).
>
> Going forward, we need?to?agree on choosing another term to refer to > issuers, and leave the term "Brand" for consumers of TPP-int= erfaces.
>
> The core brand problem we will be facing in open banking is for having=
> the AS display the "consumer-brand" logo to the RO in the co= nsent screen.
>
>
>=C2=A0 =C2=A0 =C2=A0>> On 22 May 2020, at 08:52, Vladimir Dzhuvin= ov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>> = wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> With that said it makes sense to devise a = structure which can
>=C2=A0 =C2=A0 =C2=A0accommodate UI driven as well as automatic choice.<= br> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The UI driven chooser will need a h= uman readable
>=C2=A0 =C2=A0 =C2=A0description and other UI hints. This can work for i= nstance with
>=C2=A0 =C2=A0 =C2=A0"classic" OIDC Discovery.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The "auto" chooser will n= eed some sort of an ID. For a
>=C2=A0 =C2=A0 =C2=A0bank chooser this means providing the issuer URI an= d an optional
>=C2=A0 =C2=A0 =C2=A0brand ID and both must get registered together. Or,= one could
>=C2=A0 =C2=A0 =C2=A0define a standard brand ID (label) for banking oper= ations and if
>=C2=A0 =C2=A0 =C2=A0the "alternative_authorization_endpoints"= is present look for it
>=C2=A0 =C2=A0 =C2=A0in the structure, else fall back to the default
>=C2=A0 =C2=A0 =C2=A0"authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>> Here is one possible layout which has IDs = and UI hints:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> {
>=C2=A0 =C2=A0 =C2=A0>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>? ?"alternative_authorization_endpoint= s": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"banking": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/business= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/busi= ness/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"personal": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/consumer= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money personal customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/cons= umer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>? ?}
>=C2=A0 =C2=A0 =C2=A0>> }
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 22/05/2020 09:59, Torsten Lodderstedt w= rote:
>=C2=A0 =C2=A0 =C2=A0>>> I think an id or label per endpoint se= t would be needed to
>=C2=A0 =C2=A0 =C2=A0determine the set of endpoints to be used by a cert= ain client.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> On the conceptual side, I?m asking mys= elf how the complete
>=C2=A0 =C2=A0 =C2=A0process is supposed to work. Who is deciding what i= ssuer/endpoint
>=C2=A0 =C2=A0 =C2=A0set combination to use. I assume in an open banking= scenario,
>=C2=A0 =C2=A0 =C2=A0there will always be some kind of bank chooser. Wil= l this chooser
>=C2=A0 =C2=A0 =C2=A0provide the client with issuer and brand id?
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 22. May 2020, at 08:10, Vladimi= r Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> A mapping like the one you propose= can definitely work. Since
>=C2=A0 =C2=A0 =C2=A0the user will be making the choice which endpoint t= o take with the
>=C2=A0 =C2=A0 =C2=A0client app, having the logo_uri is a good idea. If = the branded
>=C2=A0 =C2=A0 =C2=A0endpoints differ somehow in policy one could also a= llow inclusion
>=C2=A0 =C2=A0 =C2=A0of the op_policy_uri and op_tos_uri params from Dis= covery.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0ht= tps://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 20/05/2020 19:16, Joseph Heenan= wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks for your thoughts Vladi= mir!
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> The client_id based solution I= wasn?t previously aware of -
>=C2=A0 =C2=A0 =C2=A0unfortunately it doesn?t solve the problem for app2= app, as the
>=C2=A0 =C2=A0 =C2=A0mobile OS selects the app to use based purely on th= e URL (and in
>=C2=A0 =C2=A0 =C2=A0at least the iOS case will not offer the user a cho= ice if multiple
>=C2=A0 =C2=A0 =C2=A0apps claim to handle the same url).
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think some kind of mapping l= ike you suggest will work and
>=C2=A0 =C2=A0 =C2=A0fallback, I wonder about a structure in the authori= zation server
>=C2=A0 =C2=A0 =C2=A0metadata something like this:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> {
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?"alternative_authorizat= ion_endpoints": [
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/business/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/business/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/consumer/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney personal customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/consumer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?]
>=C2=A0 =C2=A0 =C2=A0>>>>> }
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> And as you say, the existing a= uthorization_endpoint can be a
>=C2=A0 =C2=A0 =C2=A0fallback for clients that are unaware of the new sp= ec or prefer
>=C2=A0 =C2=A0 =C2=A0the simpler option of just using a single authoriza= tion endpoint.
>=C2=A0 =C2=A0 =C2=A0Supporting the new spec would allow a better UX tho= ugh so there?s
>=C2=A0 =C2=A0 =C2=A0advantages to client to do so.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think that particular part i= s not really an issue as mtls
>=C2=A0 =C2=A0 =C2=A0isn?t used at the authorization endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Joseph
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20 May 2020, at 16:07, = Vladimir Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi Dave,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> In the absence of such a &= quot;multi-brand" spec we have tackled
>=C2=A0 =C2=A0 =C2=A0this issue in the past by letting the "brand&q= uot; be encoded in the
>=C2=A0 =C2=A0 =C2=A0client_id. An alternative scenario is to do a "= ;brand" lookup by
>=C2=A0 =C2=A0 =C2=A0client_id. Then let the AS render the "branded= " authZ endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> You're probably aware = the mTLS spec is allowing for
>=C2=A0 =C2=A0 =C2=A0endpoint aliases, so this is not the first time suc= h as need has
>=C2=A0 =C2=A0 =C2=A0occurred:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> https:= //tools.ietf.org/html/rfc8705#section-5
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> One could devise a similar= JSON object with mappings
>=C2=A0 =C2=A0 =C2=A0"label" - "authorization_endpoint&qu= ot;.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Clients that are aware of = the new spec will look it up,
>=C2=A0 =C2=A0 =C2=A0those that are not will fall back to the std "= authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20/05/2020 15:07, Dave = Tonge wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dear OAuth WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We have an issue in th= e OpenID FAPI Working Group that we
>=C2=A0 =C2=A0 =C2=A0believe affects the wider OAuth community.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> In summary: what is th= e recommended approach to discovery
>=C2=A0 =C2=A0 =C2=A0(RFC8414) for Authorization Servers who support mul= tiple "brands" .
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> If brands are complete= ly separate, then it seems sensible
>=C2=A0 =C2=A0 =C2=A0that each brand must have its own `issuer` and ther= efore its own
>=C2=A0 =C2=A0 =C2=A0discovery document at the correct location (i.e. br= and 1 would
>=C2=A0 =C2=A0 =C2=A0have an issuer of
>=C2=A0 =C2=A0 =C2=A0>>>>>>> "https://as/brand1&qu= ot; and a discovery document available at?
>=C2=A0 =C2=A0 =C2=A0https://as/.well-kno= wn/oauth-authorization-server/brand1
>=C2=A0 =C2=A0 =C2=A0>>>>>>> ).
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> However in the real wo= rld it is not always so simple. We
>=C2=A0 =C2=A0 =C2=A0have many existing implementations in UK open banki= ng that support
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints. Here is an exampl= e (thanks to
>=C2=A0 =C2=A0 =C2=A0@Joseph Heenan )
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Bank ?loadsamoney?= has one idp and, for internet banking,
>=C2=A0 =C2=A0 =C2=A0one ?login page? for both business and personal cus= tomers.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> They have separate= mobile apps for business/personal, and
>=C2=A0 =C2=A0 =C2=A0are required to support app2app. This means they wi= ll definitely
>=C2=A0 =C2=A0 =C2=A0be exposing multiple authorization endpoints (as th= ere?s a 1:1
>=C2=A0 =C2=A0 =C2=A0mapping of authorization endpoints to mobile apps) = - the choice is
>=C2=A0 =C2=A0 =C2=A0how they do this.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Their choices are:=
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 1. Multiple discov= ery endpoints (one for business, one
>=C2=A0 =C2=A0 =C2=A0for personal), each with a different authorization = endpoint,
>=C2=A0 =C2=A0 =C2=A0multiple issuers (if their vendor allows this)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 2. Single discover= y endpoint, single issuer, multiple
>=C2=A0 =C2=A0 =C2=A0authorization endpoints listed in one discovery doc= (one for
>=C2=A0 =C2=A0 =C2=A0business, one for personal) some of which are hardc= oded by the 3rd
>=C2=A0 =C2=A0 =C2=A0party
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 3. Multiple discov= ery endpoints each with a different
>=C2=A0 =C2=A0 =C2=A0authorization endpoint, same issuer in all cases (b= reaks RFC8414
>=C2=A0 =C2=A0 =C2=A0and OIDC Discovery)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 3 is invalid an= d that leaves us with options 1 and 2.
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 1 can be proble= matic as often it is in reality the
>=C2=A0 =C2=A0 =C2=A0same `issuer` behind the scenes.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We would like to get f= eedback on this issue and
>=C2=A0 =C2=A0 =C2=A0potentially an extension to RFC8414 to allow the de= finition of
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Thanks in advance
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dave Tonge
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Co-Chair FAPI WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Open ID Foundation
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> --
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir Dzhuvinov
>

--
=
Francis Pouatcha
Co-Founder and Technical Lead at adorys
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

=
--00000000000035f71e05a72e0f2b-- From nobody Wed Jun 3 09:13:08 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428B53A0797 for ; Wed, 3 Jun 2020 09:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVLG6IN-OMo4 for ; Wed, 3 Jun 2020 09:13:05 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF193A0788 for ; Wed, 3 Jun 2020 09:13:04 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d86 with ME id mgD12200A4FMSmm03gD12t; Wed, 03 Jun 2020 18:13:02 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 03 Jun 2020 18:13:02 +0200 X-ME-IP: 86.238.65.197 To: Benjamin Kaduk Cc: oauth@ietf.org, Vittorio Bertocci References: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <20200530205522.GV58497@kduck.mit.edu> <0c2a52b0-f05b-38c6-6e37-7aacd6c98a24@free.fr> <20200603042324.GS58497@mit.edu> From: Denis Message-ID: <01860781-023a-9bba-64e5-774468586edd@free.fr> Date: Wed, 3 Jun 2020 18:13:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200603042324.GS58497@mit.edu> Content-Type: multipart/alternative; boundary="------------56F302F7D8D8ADB0237B18A7" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:13:07 -0000 This is a multi-part message in MIME format. --------------56F302F7D8D8ADB0237B18A7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin, My responses are between the lines. > Hi Denis, > > On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: >> Hi Benjamin, >> >> Responses are between the lines. >> >>> On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: >>>> Hi Benjamin, >>>>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: >>>>>> Since then, I questioned myself how a client would be able to >>>>>> request an access token that would be *strictly compliant with this >>>>>> Profile*. >>>>> I don't understand why this is an interesting question to ask. The >>>>> access token and interpretation thereof is (AIUI) generally seen as >>>>> an internal matter between AS and RS, with the client having no need >>>>> to care about the specifics. >>>> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not >>>> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. >>> Sure. But (in my understanding), in common usage, the contents and >>> interpretation of the access token is set by common agreement between >>> AS and RS, with the client serving only as a "dumb" channel for >>> transporting the token. That is, we're providing a token format that >>> an RS and AS can agree to use, most likely for all tokens issued by >>> the AS for that RS. I don't know of any existing mechanisms, or desire >>> for such mechanisms by deployments, for using a different token format >>> for different tokens issued by a given AS for a given RS. >> Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it >> means that potentially other Profiles could be defined in the future. >> In the request, there is no parameter for a client to indicate that it >> wants a JWT conformant to _this_ profile and no parameter either >> in the response to indicate to the client that it got a JWT that is >> conformant to _this_ profile. > I don't think my point came through clearly. Right now, the AS and RS have > to negotiate by some out-of-band means what token format and details to use > for tokens issued by AS with RS in audience, and there is not a > "well-known" description of how to use JWT to do so. The goal of this > document is to simplify the out-of-band negotiation between AS and RS, so > they can just say "use RFC NNNN" instead of having to specify a lot of > details individually. At this time, it is still unknown how a client can request a JWT conformant to /this/ profile, i.e. I have not identified in the protocol a request parameter saying "use RFC NNNN". > Nowhere does the client come into the current negotiation of what token format to use, > and the act of specifying a profile of JWT for this usage does not create a requirement > for the client to be included in the negotiation. It is not a "negotiation" where one party proposes a set of choices and the other party selects one of these choices, it is supposed to be a protocol where the client is saying "please provide me a token compliant with RFC NNNN". Unfortunately, the current protocol description does not allow to do so. > Now, whether or not to include the client in this negotiation (and whether > or not to make the choice of token format finer-grained) may be a topic > worth discussion in its own right, but that discussion is untethered from > specifying a profile of JWT to simplify AS/RS negotiations. Agreed. It is not a matter for this working draft which may be discussed using a separate thread. > >> The processing mandated in the document of a request made by a client to >> an AS only applies for a request conformant to this profile >> which may or may not include a scope parameter and which may or may not >> include a "resource" parameter (and, if it does not, shall >> include an "aud" claim). Currently, it is not possible to make a >> difference between a JWT request or response conformant to this profile >> and other JWT requests or responses. > I don't see where this document places constraints on a "conformant > request" made by a client; could you point that out to me? > > (FWIW, the section heading for section 3 seems needlessly confusing, as the > contents of the section do not seem to say anything about specifically > requesting a JWT token. I can see how this heading might cause some > confusion.) This is the core of the discussion: the current protocol description does not allow a client to say: "Please provide me a token compliant with RFC NNNN". > >>> Attempting to have the client provide input that would affect such a >>> mechanism seems like complexity with no market demand; a "solution in >>> search of a problem" as it were. Is there some pent-up demand among >>> OAuth deployments that I'm not aware of? I freely admit to not being >>> very on top of the broad spectrum of what's deployed... >>>> 1) A client may wish to obtain an Access Token that corresponds to >>>> this Profile because, for example, this document mandates the "sub" >>>> claim to be present". Hence, the content of the Access Token is not >>>> totally "/an internal matter between AS and RS/". However, I have not >>>> understood how a client could request an Access Token that >>>> corresponds to *_this_***Profile, since there is no mandatory >>>> parameter in the request (both the "scope" parameter and the >>>> "resource" parameter are optional). In the future, we could define >>>> _*another*_**Profile. Hence, there is the same question:  How could a >>>> client request an Access Token that corresponds to *_that >>>> other_***Profile ? 2) When getting a JWT,  how can the client make >>>> sure that the access token it got is compliant with this Profile ? >>>> RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing >>>> Sometimes, one kind of JWT can be confused for another. If a >>>> particular kind of JWT is subject to such confusion, that JWT can >>>> include an explicit JWT type value, and the validation rules can >>>> specify checking the type (...). Explicit JWT typing is accomplished >>>> by using the "typ" Header Parameter. Wouldn't be wise to include an >>>> explicit JWT type value for JWTs conformant to this Profile ? >>> In the model where the client is a "dumb" communications channel, this >>> question does not seem interesting. But the related question of "how >>> can the RS make sure that the access token it got was generated >>> according to this profile?" does seem interesting, and seems like it >>> would benefit from the same proposed solution. >> An explicit JWT type value added both in the JWT request and in the JWT >> response would solve this problem. > An explicit JWT type is a solution to the problme I'm interested in, yes. > Though I don't know if that's what you mean by "this problem".  The problem that still needs to be solved is a way for a client to be able to state: "Please provide me a token compliant with RFC NNNN". > >>>> This relates to an email posted by Dominick Baier under the topic >>>> "JAR: JWT typ" on May 19 : This has been brought up before - but no >>>> response. Either I can’t find it - or it is missing. But is the >>>> setting the JWT typ explicitly mentioned somewhere? >>> It is fairly likely that I will remember to ask about explicit "typ" >>> usage if I'm still on the IESG when this document gets there: I think >>> I've been making a habit of doing so. >> Once again, an explicit "typ" sould be considered for both the JWT >> request and the JWT response. This implies that the client "MUST" be >> able to inspect the content of the access token. > As above, I do not see how the client currently has input into the token > type/format agreed upon by the AS/RS out-of-band, so I dispute both the > premise and the supposed conclusion. Since the token format negotiation is out-of-band (i.e. it is not specified in the current RFCs or in drafts in preparation) all assumptions can be made of the way(s) a RS makes available the token formats it supports. Without knowing anything about which token formats are being supported, the client may attempt to ask: "Please provide me a token compliant with RFC NNNN". This will fail or succeed. So the client does not need to have any knowledge about the token type/format agreed upon by the AS/RS out-of-band. Denis > -Ben --------------56F302F7D8D8ADB0237B18A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Benjamin,

My responses are between the lines.

Hi Denis,

On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote:

Hi Benjamin,

Responses are between the lines.


On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:

Hi Benjamin,

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:

Since then, I questioned myself how a client would be able to 
request an access token that would be *strictly compliant with this 
Profile*.

I don't understand why this is an interesting question to ask. The 
access token and interpretation thereof is (AIUI) generally seen as 
an internal matter between AS and RS, with the client having no need 
to care about the specifics.

This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
_*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure. But (in my understanding), in common usage, the contents and 
interpretation of the access token is set by common agreement between 
AS and RS, with the client serving only as a "dumb" channel for 
transporting the token. That is, we're providing a token format that 
an RS and AS can agree to use, most likely for all tokens issued by 
the AS for that RS. I don't know of any existing mechanisms, or desire 
for such mechanisms by deployments, for using a different token format 
for different tokens issued by a given AS for a given RS.

Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it 
means that potentially other Profiles could be defined in the future.
In the request, there is no parameter for a client to indicate that it 
wants a JWT conformant to _this_ profile and no parameter either
in the response to indicate to the client that it got a JWT that is 
conformant to _this_ profile.

I don't think my point came through clearly.  Right now, the AS and RS have
to negotiate by some out-of-band means what token format and details to use
for tokens issued by AS with RS in audience, and there is not a
"well-known" description of how to use JWT to do so. The goal of this
document is to simplify the out-of-band negotiation between AS and RS, so
they can just say "use RFC NNNN" instead of having to specify a lot of
details individually.

At this time, it is still unknown how a client can request a JWT conformant to this profile,
i.e. I have not identified in the protocol a request parameter saying "use RFC NNNN".

Nowhere does the client come into the current negotiation of what token format to use, 
and the act of specifying a profile of JWT for this usage does not create a requirement 
for the client to be included in the negotiation.

It is not a "negotiation" where one party proposes a set of choices and the other party selects one of  these choices,
it is supposed to be a protocol where the client is saying "please provide me a token compliant with RFC NNNN".
Unfortunately, the current protocol description does not allow to do so. 

Now, whether or not to include the client in this negotiation (and whether
or not to make the choice of token format finer-grained) may be a topic
worth discussion in its own right, but that discussion is untethered from
specifying a profile of JWT to simplify AS/RS negotiations.

Agreed. It is not a matter for this working draft which may be discussed using a separate thread.


The processing mandated in the document of a request made by a client to 
an AS only applies for a request conformant to this profile
which may or may not include a scope parameter and which may or may not 
include a "resource" parameter (and, if it does not, shall
include an "aud" claim). Currently, it is not possible to make a 
difference between a JWT request or response conformant to this profile
and other JWT requests or responses.

I don't see where this document places constraints on a "conformant
request" made by a client; could you point that out to me?

(FWIW, the section heading for section 3 seems needlessly confusing, as the
contents of the section do not seem to say anything about specifically
requesting a JWT token.  I can see how this heading might cause some
confusion.)

This is the core of the discussion: the current protocol description does not
allow a client to say: "Please provide me a token compliant with RFC NNNN".


Attempting to have the client provide input that would affect such a 
mechanism seems like complexity with no market demand; a "solution in 
search of a problem" as it were. Is there some pent-up demand among 
OAuth deployments that I'm not aware of? I freely admit to not being 
very on top of the broad spectrum of what's deployed...

1) A client may wish to obtain an Access Token that corresponds to 
this Profile because, for example, this document mandates the "sub" 
claim to be present". Hence, the content of the Access Token is not 
totally "/an internal matter between AS and RS/". However, I have not 
understood how a client could request an Access Token that 
corresponds to *_this_***Profile, since there is no mandatory 
parameter in the request (both the "scope" parameter and the 
"resource" parameter are optional). In the future, we could define 
_*another*_**Profile. Hence, there is the same question:  How could a 
client request an Access Token that corresponds to *_that 
other_***Profile ? 2) When getting a JWT,  how can the client make 
sure that the access token it got is compliant with this Profile ? 
RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing 
Sometimes, one kind of JWT can be confused for another. If a 
particular kind of JWT is subject to such confusion, that JWT can 
include an explicit JWT type value, and the validation rules can 
specify checking the type (...). Explicit JWT typing is accomplished 
by using the "typ" Header Parameter. Wouldn't be wise to include an 
explicit JWT type value for JWTs conformant to this Profile ?

In the model where the client is a "dumb" communications channel, this 
question does not seem interesting. But the related question of "how 
can the RS make sure that the access token it got was generated 
according to this profile?" does seem interesting, and seems like it 
would benefit from the same proposed solution.

An explicit JWT type value added both in the JWT request and in the JWT 
response would solve this problem.

An explicit JWT type is a solution to the problme I'm interested in, yes.
Though I don't know if that's what you mean by "this problem".

 The problem that still needs to be solved is a way for a client to be able to state:
"Please provide me a token compliant with RFC NNNN".


This relates to an email posted by Dominick Baier under the topic 
"JAR: JWT typ" on May 19 : This has been brought up before - but no 
response. Either I can’t find it - or it is missing. But is the 
setting the JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ" 
usage if I'm still on the IESG when this document gets there: I think 
I've been making a habit of doing so.

Once again, an explicit "typ" sould be considered for both the JWT 
request and the JWT response. This implies that the client "MUST" be 
able to inspect the content of the access token.

As above, I do not see how the client currently has input into the token
type/format agreed upon by the AS/RS out-of-band, so I dispute both the
premise and the supposed conclusion.

Since the token format negotiation is out-of-band (i.e. it is not specified in the current RFCs
or in drafts in preparation) all assumptions can be made of the way(s) a RS makes available
the token formats it supports. Without knowing anything about which token formats are
being supported, the client may attempt to ask: "Please provide me a token compliant with
RFC NNNN". This will fail or succeed. So the client does not need to have any knowledge
about the token type/format agreed upon by the AS/RS out-of-band.

Denis

-Ben


--------------56F302F7D8D8ADB0237B18A7-- From nobody Wed Jun 3 10:07:49 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE903A0B21 for ; Wed, 3 Jun 2020 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pf_G2F-tV79 for ; Wed, 3 Jun 2020 10:07:45 -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 F030D3A0B1C for ; Wed, 3 Jun 2020 10:07:44 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t18so3188380wru.6 for ; Wed, 03 Jun 2020 10:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jwgw8773A6UFpTlOY7pHTOfaiYwDJhz9Gejtm1FzhGA=; b=CuyxZzK7HZoGxO+aWGPeRPide8fO5c0v1QaFbGFpv3KE8nQhJBQDhRie+0kV8vpax7 C3boK1hCf4k6C8VkHSeIAhTlEHZUPXUi5Wzzuc/f/fflNxpL4seJhCT1FU8s6vTlQuL2 XHTjVwBIJ97i0OuYbnO/nF7Te4I+KDhdvXXd8= 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=jwgw8773A6UFpTlOY7pHTOfaiYwDJhz9Gejtm1FzhGA=; b=BFkkGULWAE9k2U0QPdqSN+p/JUIA7v/Y3Yi8htsGw+qjlBstWPJd0/ViB6O8YayuR8 vsI9qrdyNWWMo1wvlc4fI0cRqyfsYkgCIOXR/cLuE2DHDJ2KwX2noQLu5Z42u7+qZ93+ WdM6JXRDQS1jEAkE3C/TSJHIinFGx41WRnNoOxk0W8kLbeZ41ryWZb+CzqUklTCwUWxO hdjpkMg2PRFml80dvgQK4tQGUhkO02eY7RzBNOErLbMs5xhQDtiaCf2IKhdv6AO3qQiO RM/QGRkg3rYAxB9O+Oq45fNxrcuRw+Eq+o8Ja3CglzAe6w5X90qJOuE8AkHBy20bv1ha ClJQ== X-Gm-Message-State: AOAM530UUApFbK5yrMMErDZALhUQgJyW8ymmqNMuLA1MHLclxBPqvc1k 8MCBmLKHAfCx9CvEaWZciNl7cUcVhHZwerzeI6RTTA== X-Google-Smtp-Source: ABdhPJzCavH8sdDoK/uImeSrBltMO8a85jcbWzvbUKd9GCB4mANMQ8kbqwrNmvl/M/qR3SMmE4zvyxOx78fpCDRoVNo= X-Received: by 2002:adf:e545:: with SMTP id z5mr398721wrm.89.1591204063067; Wed, 03 Jun 2020 10:07:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Wed, 3 Jun 2020 13:07:32 -0400 Message-ID: To: Dave Tonge Cc: OAuth WG , Openid-specs Fapi Content-Type: multipart/alternative; boundary="000000000000f1d4cf05a7311099" Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 17:07:48 -0000 --000000000000f1d4cf05a7311099 Content-Type: text/plain; charset="UTF-8" Hello Dave, > > I agree that the best deployment option is: 1 brand = 1 issuer = 1 > discovery doc, however that is not always possible. > > I'd like to understand Francis what particular issue you see from allowing > an AS to specify multiple authorization_endpoints? > Confusing End User! A user is using the same credentials on a yellow styled "https://loadsamoney/business/auth" and a green styled " https://loadsamoney/consumer/auth". A well designed environment will have a centralized page for login and account management like " https://loadsamoney/accounts/auth " even better "https://accounts.loadsamoney/auth ". I can see that to avoid user confusion it would be necessary for the Client > to record which endpoint they redirected the user to, in case they need the > user to re-authorize - but I can't see any particular security issue? > Let assume the "Client-Business" will record the business auth-endpoint and keep sending RO to "https://loadsamoney/business/auth" for reauthentication. If the user opens his personal banking application on another tab, "Client-Consumer" will send the user to " https://loadsamoney/consumer/auth". For SSO to work, the AS has to store the SSO-Cookies under "https://loadsamoney/ ". Now your AS SSO Cookies are also accessible to "https://loadsamoney/blog "! This problem is even worse if instead of path you use subdomains like " https://business.loadsamoney/auth " and " https://consumer.loadsamoney/auth " the the SSO Cookie of your AS has to be set to: ".loadsamoney", providing access to the SSO Cookies to all other subdomain hosted application like " https://blog.loadsamoney/ ". Most AS I have used in customer projects use cookies to manage SSO? > > No matter which authorization_endpoint the user was sent to, after the > user is redirected back to the Client's redirect_uri the process is the > same as if there had been 1 authorization_endpoint. > AS UI customization is being done today by many AS deployment because of: - Multitenancy of deployment - The need to have client identity disclosed to the RO in a consent page I am in favour of Vladimir's suggestion of: > > "alternative_authorization_endpoints": { > "banking": { > "authorization_endpoint": "https://loadsamoney/business/auth", > "description": "loadsmoney business banking customers", > "logo_url": "https://loadsamoney/business/logo.png" > }, > "personal": { > "authorization_endpoint": "https://loadsamoney/consumer/auth", > "description": "loadsmoney personal customers", > "logo_url": "https://loadsamoney/consumer/logo.png" > } > } > This use case is neither multi tenancy nor the disclosure of the client identity in a consent page. Starting with the logo here, we will end up adding css and js code snippets. This type of customizing shall be done in the AS-Deployment without playing around with the public AS metadata. I am in favor of pushing those changes into target AS-Deployment specific customizing. /Francis > > Dave > > > On Wed, 27 May 2020 at 16:09, Francis Pouatcha 40adorsys.de@dmarc.ietf.org> wrote: > >> >>> >>> Message: 1 >>> Date: Tue, 26 May 2020 09:03:16 +0300 >>> From: Vladimir Dzhuvinov >>> To: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands >>> Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2id.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> My understanding of the branding concept was to present different UIs to >>> resource owners during login and authorization, while keeping the OP / >>> AS the same, meaning identical issuer. In a spec it would be helpful to >>> spell out what branding means (and what not). >>> >> Let us call this varian the AS-Brand. >> As an RO, I sign in for AS-Brand-A and my token is usable under the >> context of AS-Brand-B because both share the same issuer. This kills >> transparency at the RO site. >> >> I support: One AS-Brand <-> One Issuer. >> >> Regards >> /Francis >> >>> >>> Regarding a token being issued for "personal" vs "business" and >>> confusion - the usage of the token is normally defined by its scope and >>> audience (RS) and if this rule is observed (and it's not relied solely >>> on the issuer URI for that) then clients shouldn't get confused here. >>> >>> Vladimir >>> >>> On 23/05/2020 06:26, Francis Pouatcha wrote: >>> > - I will go for Option 1 even if we have the same runtime instance >>> > producing tokens under different?issuer uris. >>> > - Option 2 might expose security risk as many clients rely on >>> > the?issuer to associate the? token with authorization context. By no >>> > way shall a token issued for "personal" be valid for "business". >>> > Therefore considering?the?use of the?same issuer here might lead to >>> > confusion at the?RP. >>> > - In order to avoid confusion, AS must make?sure each "brand" >>> > uses?separated key material to produce the token. >>> > >>> > BTW: >>> > The term brand as used in the context of most Open Banking initiatives >>> > refers to entities consuming the Interface provided by TPPs (Third >>> > Party Providers).. TPPs play the roles of RPs in the oAuth2 context. >>> > >>> > Unless I misunderstood this thread we are using a brand here to refer >>> > to an AS virtual host (issuer-uri). >>> > >>> > Going forward, we need?to?agree on choosing another term to refer to >>> > issuers, and leave the term "Brand" for consumers of TPP-interfaces. >>> > >>> > The core brand problem we will be facing in open banking is for having >>> > the AS display the "consumer-brand" logo to the RO in the consent >>> screen. >>> > >>> > >>> > >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov >>> > > wrote: >>> > >> >>> > >> With that said it makes sense to devise a structure which can >>> > accommodate UI driven as well as automatic choice. >>> > >> >>> > >>? ? ? ? The UI driven chooser will need a human readable >>> > description and other UI hints. This can work for instance with >>> > "classic" OIDC Discovery. >>> > >> >>> > >>? ? ? ? The "auto" chooser will need some sort of an ID. For a >>> > bank chooser this means providing the issuer URI and an optional >>> > brand ID and both must get registered together. Or, one could >>> > define a standard brand ID (label) for banking operations and if >>> > the "alternative_authorization_endpoints" is present look for it >>> > in the structure, else fall back to the default >>> > "authorization_endpoint". >>> > >> Here is one possible layout which has IDs and UI hints: >>> > >> >>> > >> { >>> > >>? ?... >>> > >>? ?"alternative_authorization_endpoints": { >>> > >>? ? ?"banking": { >>> > >>? ? ? ?"authorization_endpoint": >>> > >> "https://loadsamoney/business/auth" >>> > >> , >>> > >>? ? ? ?"description": "loadsmoney business banking customers", >>> > >>? ? ? ?"logo_url": >>> > >> "https://loadsamoney/business/logo.png" >>> > >> >>> > >>? ? ?}, >>> > >>? ? ?"personal": { >>> > >>? ? ? ?"authorization_endpoint": >>> > >> "https://loadsamoney/consumer/auth" >>> > >> , >>> > >>? ? ? ?"description": "loadsmoney personal customers", >>> > >>? ? ? ?"logo_url": >>> > >> "https://loadsamoney/consumer/logo.png" >>> > >> >>> > >>? ? ?} >>> > >>? ?} >>> > >> } >>> > >> >>> > >> >>> > >> >>> > >> On 22/05/2020 09:59, Torsten Lodderstedt wrote: >>> > >>> I think an id or label per endpoint set would be needed to >>> > determine the set of endpoints to be used by a certain client. >>> > >>> >>> > >>> On the conceptual side, I?m asking myself how the complete >>> > process is supposed to work. Who is deciding what issuer/endpoint >>> > set combination to use. I assume in an open banking scenario, >>> > there will always be some kind of bank chooser. Will this chooser >>> > provide the client with issuer and brand id? >>> > >>> >>> > >>> >>> > >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov >>> > > >>> > >>>>? wrote: >>> > >>>> >>> > >>>> A mapping like the one you propose can definitely work. Since >>> > the user will be making the choice which endpoint to take with the >>> > client app, having the logo_uri is a good idea. If the branded >>> > endpoints differ somehow in policy one could also allow inclusion >>> > of the op_policy_uri and op_tos_uri params from Discovery. >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery >>> > >>>> >>> > >>>> >>> > >>>> Vladimir >>> > >>>> >>> > >>>> On 20/05/2020 19:16, Joseph Heenan wrote: >>> > >>>> >>> > >>>>> Thanks for your thoughts Vladimir! >>> > >>>>> >>> > >>>>> The client_id based solution I wasn?t previously aware of - >>> > unfortunately it doesn?t solve the problem for app2app, as the >>> > mobile OS selects the app to use based purely on the URL (and in >>> > at least the iOS case will not offer the user a choice if multiple >>> > apps claim to handle the same url). >>> > >>>>> >>> > >>>>> I think some kind of mapping like you suggest will work and >>> > fallback, I wonder about a structure in the authorization server >>> > metadata something like this: >>> > >>>>> >>> > >>>>> { >>> > >>>>>? ?... >>> > >>>>>? ?"alternative_authorization_endpoints": [ >>> > >>>>>? ? ?{ >>> > >>>>>? ? ? ?"authorization_endpoint": >>> > >>>>> "https://loadsamoney/business/auth" >>> > >>>>> , >>> > >>>>>? ? ? ?"description": "loadsmoney business banking customers", >>> > >>>>>? ? ? ?"logo_url": >>> > >>>>> "https://loadsamoney/business/logo.png" >>> > >>>>> >>> > >>>>>? ? ?}, >>> > >>>>>? ? ?{ >>> > >>>>>? ? ? ?"authorization_endpoint": >>> > >>>>> "https://loadsamoney/consumer/auth" >>> > >>>>> , >>> > >>>>>? ? ? ?"description": "loadsmoney personal customers", >>> > >>>>>? ? ? ?"logo_url": >>> > >>>>> "https://loadsamoney/consumer/logo.png" >>> > >>>>> >>> > >>>>>? ? ?} >>> > >>>>>? ?] >>> > >>>>> } >>> > >>>>> >>> > >>>>> And as you say, the existing authorization_endpoint can be a >>> > fallback for clients that are unaware of the new spec or prefer >>> > the simpler option of just using a single authorization endpoint. >>> > Supporting the new spec would allow a better UX though so there?s >>> > advantages to client to do so. >>> > >>>>> >>> > >>>>>> Speaking of mTLS, I'm not sure how the >>> > "mtls_endpoint_aliases" can be sensibly combined with the proposed >>> > multi-brand spec. >>> > >>>>>> >>> > >>>>>> >>> > >>>>> I think that particular part is not really an issue as mtls >>> > isn?t used at the authorization endpoint. >>> > >>>>> >>> > >>>>> Thanks >>> > >>>>> >>> > >>>>> Joseph >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov >>> > > >>> > >>>>>>? wrote: >>> > >>>>>> >>> > >>>>>> Hi Dave, >>> > >>>>>> >>> > >>>>>> In the absence of such a "multi-brand" spec we have tackled >>> > this issue in the past by letting the "brand" be encoded in the >>> > client_id. An alternative scenario is to do a "brand" lookup by >>> > client_id. Then let the AS render the "branded" authZ endpoint. >>> > >>>>>> >>> > >>>>>> You're probably aware the mTLS spec is allowing for >>> > endpoint aliases, so this is not the first time such as need has >>> > occurred: >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> https://tools.ietf.org/html/rfc8705#section-5 >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> One could devise a similar JSON object with mappings >>> > "label" - "authorization_endpoint". >>> > >>>>>> >>> > >>>>>> Clients that are aware of the new spec will look it up, >>> > those that are not will fall back to the std >>> "authorization_endpoint". >>> > >>>>>> >>> > >>>>>> Speaking of mTLS, I'm not sure how the >>> > "mtls_endpoint_aliases" can be sensibly combined with the proposed >>> > multi-brand spec. >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> Vladimir >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> On 20/05/2020 15:07, Dave Tonge wrote: >>> > >>>>>> >>> > >>>>>>> Dear OAuth WG >>> > >>>>>>> >>> > >>>>>>> We have an issue in the OpenID FAPI Working Group that we >>> > believe affects the wider OAuth community. >>> > >>>>>>> >>> > >>>>>>> In summary: what is the recommended approach to discovery >>> > (RFC8414) for Authorization Servers who support multiple "brands" . >>> > >>>>>>> >>> > >>>>>>> If brands are completely separate, then it seems sensible >>> > that each brand must have its own `issuer` and therefore its own >>> > discovery document at the correct location (i.e. brand 1 would >>> > have an issuer of >>> > >>>>>>> "https://as/brand1" and a discovery document available at? >>> > https://as/.well-known/oauth-authorization-server/brand1 >>> > >>>>>>> ). >>> > >>>>>>> >>> > >>>>>>> However in the real world it is not always so simple. We >>> > have many existing implementations in UK open banking that support >>> > multiple authorization endpoints. Here is an example (thanks to >>> > @Joseph Heenan ) >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>>> Bank ?loadsamoney? has one idp and, for internet banking, >>> > one ?login page? for both business and personal customers. >>> > >>>>>>>> >>> > >>>>>>>> They have separate mobile apps for business/personal, and >>> > are required to support app2app. This means they will definitely >>> > be exposing multiple authorization endpoints (as there?s a 1:1 >>> > mapping of authorization endpoints to mobile apps) - the choice is >>> > how they do this. >>> > >>>>>>>> >>> > >>>>>>>> Their choices are: >>> > >>>>>>>> >>> > >>>>>>>> 1. Multiple discovery endpoints (one for business, one >>> > for personal), each with a different authorization endpoint, >>> > multiple issuers (if their vendor allows this) >>> > >>>>>>>> 2. Single discovery endpoint, single issuer, multiple >>> > authorization endpoints listed in one discovery doc (one for >>> > business, one for personal) some of which are hardcoded by the 3rd >>> > party >>> > >>>>>>>> 3. Multiple discovery endpoints each with a different >>> > authorization endpoint, same issuer in all cases (breaks RFC8414 >>> > and OIDC Discovery) >>> > >>>>>>>> >>> > >>>>>>> Option 3 is invalid and that leaves us with options 1 and >>> 2. >>> > >>>>>>> Option 1 can be problematic as often it is in reality the >>> > same `issuer` behind the scenes. >>> > >>>>>>> >>> > >>>>>>> We would like to get feedback on this issue and >>> > potentially an extension to RFC8414 to allow the definition of >>> > multiple authorization endpoints. >>> > >>>>>>> >>> > >>>>>>> Thanks in advance >>> > >>>>>>> >>> > >>>>>>> Dave Tonge >>> > >>>>>>> Co-Chair FAPI WG >>> > >>>>>>> Open ID Foundation >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>> -- >>> > >>>> Vladimir Dzhuvinov >>> > >> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > > -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000f1d4cf05a7311099 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dave,
=

I agree that t= he best deployment option is: 1 brand =3D 1 issuer =3D 1 discovery doc, how= ever that is not always possible.

I'd like to understand Francis what particular= issue you see from allowing an AS to specify multiple authorization_endpoi= nts?
Confusing End User! A user is using= the same credentials on a yellow styled "https://loadsamoney/business/auth&q= uot; and a green styled "https://loadsamoney/consumer/auth". A well desi= gned environment will have a centralized page for login and account managem= ent like "https://loadsamoney/accounts/auth" even better "https://accounts.l= oadsamoney/auth".

I can see that to avoid user co= nfusion it would be necessary=C2=A0for the Client to record which endpoint = they redirected the user to, in case they need the user to re-authorize - b= ut I can't see any particular security issue?
Let assume the "Client-Business" will record the busine= ss auth-endpoint and keep sending RO to "https://loadsamoney/business/auth&qu= ot; for reauthentication. If the user opens his personal banking applicatio= n on another tab,=C2=A0"Client-Consumer" will send the user to &q= uot;https:/= /loadsamoney/consumer/auth". For SSO to work, the AS has to store = the SSO-Cookies under "https://loadsamoney/". Now your AS SSO Cookies ar= e also accessible to "https://loadsamoney/blog"! This problem is even wo= rse if instead of path you use subdomains like "https://business.loadsamoney/auth= " and "https://consumer.loadsamoney/auth" the the SSO Cookie = of your AS has to be set to: ".loadsamoney", providing access to = the SSO Cookies to all other subdomain hosted application like "https://blog.load= samoney/".
Most AS I have used in customer projects use = cookies to manage SSO?
=C2=A0

No matter which authorizati= on_endpoint the user was sent to, after the user is redirected back to the = Client's redirect_uri the process is the same as if there had been 1 au= thorization_endpoint.=C2=A0
AS UI custom= ization is being done today by many AS deployment because of:
- M= ultitenancy of deployment
- The need to have client identity disc= losed to the RO in a consent page

I am in favour of Vladimir&#= 39;s suggestion of:

"alternative_authorization_endpoints": {
=C2=A0 =C2= =A0 "banking": {
=C2=A0 =C2=A0 =C2=A0 "authorization_endp= oint": "https://loadsamoney/business/auth",
=C2=A0 =C2=A0 =C2=A0= "description": "loadsmoney business banking customers"= ,
=C2=A0 =C2=A0 =C2=A0 "logo_url": "https://loadsamoney/business= /logo.png"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "personal&quo= t;: {
=C2=A0 =C2=A0 =C2=A0 "authorization_endpoint": "https://loadsa= money/consumer/auth",
=C2=A0 =C2=A0 =C2=A0 "description&qu= ot;: "loadsmoney personal customers",
=C2=A0 =C2=A0 =C2=A0 &qu= ot;logo_url": "https://loadsamoney/consumer/logo.png"
=C2=A0= =C2=A0 }
=C2=A0 }
This use case = is neither multi tenancy nor the disclosure=C2=A0of the client identity in = a consent page. Starting with the logo here, we will end up adding css and = js code snippets. This type of customizing shall be done in the AS-Deployme= nt without playing around with the public AS metadata.=C2=A0

=
I am in favor of pushing those changes into target AS-Deployment= specific customizing.
/Francis

Dave


On Wed, 27 May 2020 at 16:09, F= rancis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:


Message: 1
Date: Tue, 26 May 2020 09:03:16 +0300
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
Message-ID: <2fc4c4ee-8627-936a-baf4-872c0f18eca6@connect2= id.com>
Content-Type: text/plain; charset=3D"utf-8"

My understanding of the branding concept was to present different UIs to resource owners during login and authorization, while keeping the OP /
AS the same, meaning identical issuer. In a spec it would be helpful to
spell out what branding means (and what not).
Let us c= all this varian the AS-Brand.=C2=A0
As an RO, I sign=C2=A0in for = AS-Brand-A and my token is usable under the context of AS-Brand-B because b= oth share the same issuer.=C2=A0 This kills transparency=C2=A0at the RO sit= e.

I support: One AS-Brand <-> One Issuer.

Regards
/Francis

Regarding a token being issued for "personal" vs "business&q= uot; and
confusion - the usage of the token is normally defined by its scope and
audience (RS) and if this rule is observed (and it's not relied solely<= br> on the issuer URI for that) then clients shouldn't get confused here.
Vladimir

On 23/05/2020 06:26, Francis Pouatcha wrote:
> - I will go for Option 1 even if we have the same runtime instance
> producing tokens under different?issuer uris.
> - Option 2 might expose security risk as many clients rely on
> the?issuer to associate the? token with authorization context. By no > way shall a token issued for "personal" be valid for "b= usiness".
> Therefore considering?the?use of the?same issuer here might lead to > confusion at the?RP.
> - In order to avoid confusion, AS must make?sure each "brand"= ;
> uses?separated key material to produce the token.
>
> BTW:
> The term brand as used in the context of most Open Banking initiatives=
> refers to entities consuming the Interface provided by TPPs (Third
> Party Providers).. TPPs play the roles of RPs in the oAuth2 context. >
> Unless I misunderstood this thread we are using a brand here to refer<= br> > to an AS virtual host (issuer-uri).
>
> Going forward, we need?to?agree on choosing another term to refer to > issuers, and leave the term "Brand" for consumers of TPP-int= erfaces.
>
> The core brand problem we will be facing in open banking is for having=
> the AS display the "consumer-brand" logo to the RO in the co= nsent screen.
>
>
>=C2=A0 =C2=A0 =C2=A0>> On 22 May 2020, at 08:52, Vladimir Dzhuvin= ov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>> = wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> With that said it makes sense to devise a = structure which can
>=C2=A0 =C2=A0 =C2=A0accommodate UI driven as well as automatic choice.<= br> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The UI driven chooser will need a h= uman readable
>=C2=A0 =C2=A0 =C2=A0description and other UI hints. This can work for i= nstance with
>=C2=A0 =C2=A0 =C2=A0"classic" OIDC Discovery.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ? The "auto" chooser will n= eed some sort of an ID. For a
>=C2=A0 =C2=A0 =C2=A0bank chooser this means providing the issuer URI an= d an optional
>=C2=A0 =C2=A0 =C2=A0brand ID and both must get registered together. Or,= one could
>=C2=A0 =C2=A0 =C2=A0define a standard brand ID (label) for banking oper= ations and if
>=C2=A0 =C2=A0 =C2=A0the "alternative_authorization_endpoints"= is present look for it
>=C2=A0 =C2=A0 =C2=A0in the structure, else fall back to the default
>=C2=A0 =C2=A0 =C2=A0"authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>> Here is one possible layout which has IDs = and UI hints:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> {
>=C2=A0 =C2=A0 =C2=A0>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>? ?"alternative_authorization_endpoint= s": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"banking": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/business= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/busi= ness/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>? ? ?"personal": {
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"authorization_endpoint":<= br> >=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/consumer= /auth"
>=C2=A0 =C2=A0 =C2=A0>> ,
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"description": "loads= money personal customers",
>=C2=A0 =C2=A0 =C2=A0>>? ? ? ?"logo_url":
>=C2=A0 =C2=A0 =C2=A0>> "https://loadsamoney/cons= umer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>? ?}
>=C2=A0 =C2=A0 =C2=A0>> }
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 22/05/2020 09:59, Torsten Lodderstedt w= rote:
>=C2=A0 =C2=A0 =C2=A0>>> I think an id or label per endpoint se= t would be needed to
>=C2=A0 =C2=A0 =C2=A0determine the set of endpoints to be used by a cert= ain client.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> On the conceptual side, I?m asking mys= elf how the complete
>=C2=A0 =C2=A0 =C2=A0process is supposed to work. Who is deciding what i= ssuer/endpoint
>=C2=A0 =C2=A0 =C2=A0set combination to use. I assume in an open banking= scenario,
>=C2=A0 =C2=A0 =C2=A0there will always be some kind of bank chooser. Wil= l this chooser
>=C2=A0 =C2=A0 =C2=A0provide the client with issuer and brand id?
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 22. May 2020, at 08:10, Vladimi= r Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> A mapping like the one you propose= can definitely work. Since
>=C2=A0 =C2=A0 =C2=A0the user will be making the choice which endpoint t= o take with the
>=C2=A0 =C2=A0 =C2=A0client app, having the logo_uri is a good idea. If = the branded
>=C2=A0 =C2=A0 =C2=A0endpoints differ somehow in policy one could also a= llow inclusion
>=C2=A0 =C2=A0 =C2=A0of the op_policy_uri and op_tos_uri params from Dis= covery.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0ht= tps://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 20/05/2020 19:16, Joseph Heenan= wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks for your thoughts Vladi= mir!
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> The client_id based solution I= wasn?t previously aware of -
>=C2=A0 =C2=A0 =C2=A0unfortunately it doesn?t solve the problem for app2= app, as the
>=C2=A0 =C2=A0 =C2=A0mobile OS selects the app to use based purely on th= e URL (and in
>=C2=A0 =C2=A0 =C2=A0at least the iOS case will not offer the user a cho= ice if multiple
>=C2=A0 =C2=A0 =C2=A0apps claim to handle the same url).
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think some kind of mapping l= ike you suggest will work and
>=C2=A0 =C2=A0 =C2=A0fallback, I wonder about a structure in the authori= zation server
>=C2=A0 =C2=A0 =C2=A0metadata something like this:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> {
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?...
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?"alternative_authorizat= ion_endpoints": [
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/business/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney business banking customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/business/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?},
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?{
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"authorization_endp= oint":
>=C2=A0 =C2=A0 =C2=A0>>>>> "https://loadsamo= ney/consumer/auth"
>=C2=A0 =C2=A0 =C2=A0>>>>> ,
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"description":= "loadsmoney personal customers",
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ? ?"logo_url": >=C2=A0 =C2=A0 =C2=A0>>>>> "https://load= samoney/consumer/logo.png"
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>? ? ?}
>=C2=A0 =C2=A0 =C2=A0>>>>>? ?]
>=C2=A0 =C2=A0 =C2=A0>>>>> }
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> And as you say, the existing a= uthorization_endpoint can be a
>=C2=A0 =C2=A0 =C2=A0fallback for clients that are unaware of the new sp= ec or prefer
>=C2=A0 =C2=A0 =C2=A0the simpler option of just using a single authoriza= tion endpoint.
>=C2=A0 =C2=A0 =C2=A0Supporting the new spec would allow a better UX tho= ugh so there?s
>=C2=A0 =C2=A0 =C2=A0advantages to client to do so.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I think that particular part i= s not really an issue as mtls
>=C2=A0 =C2=A0 =C2=A0isn?t used at the authorization endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Thanks
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Joseph
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20 May 2020, at 16:07, = Vladimir Dzhuvinov
>=C2=A0 =C2=A0 =C2=A0<vladimir@connect2id.com <mailto:vladimir@connect2id.com>><= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>? wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi Dave,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> In the absence of such a &= quot;multi-brand" spec we have tackled
>=C2=A0 =C2=A0 =C2=A0this issue in the past by letting the "brand&q= uot; be encoded in the
>=C2=A0 =C2=A0 =C2=A0client_id. An alternative scenario is to do a "= ;brand" lookup by
>=C2=A0 =C2=A0 =C2=A0client_id. Then let the AS render the "branded= " authZ endpoint.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> You're probably aware = the mTLS spec is allowing for
>=C2=A0 =C2=A0 =C2=A0endpoint aliases, so this is not the first time suc= h as need has
>=C2=A0 =C2=A0 =C2=A0occurred:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> https:= //tools.ietf.org/html/rfc8705#section-5
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> One could devise a similar= JSON object with mappings
>=C2=A0 =C2=A0 =C2=A0"label" - "authorization_endpoint&qu= ot;.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Clients that are aware of = the new spec will look it up,
>=C2=A0 =C2=A0 =C2=A0those that are not will fall back to the std "= authorization_endpoint".
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Speaking of mTLS, I'm = not sure how the
>=C2=A0 =C2=A0 =C2=A0"mtls_endpoint_aliases" can be sensibly c= ombined with the proposed
>=C2=A0 =C2=A0 =C2=A0multi-brand spec.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Vladimir
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 20/05/2020 15:07, Dave = Tonge wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dear OAuth WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We have an issue in th= e OpenID FAPI Working Group that we
>=C2=A0 =C2=A0 =C2=A0believe affects the wider OAuth community.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> In summary: what is th= e recommended approach to discovery
>=C2=A0 =C2=A0 =C2=A0(RFC8414) for Authorization Servers who support mul= tiple "brands" .
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> If brands are complete= ly separate, then it seems sensible
>=C2=A0 =C2=A0 =C2=A0that each brand must have its own `issuer` and ther= efore its own
>=C2=A0 =C2=A0 =C2=A0discovery document at the correct location (i.e. br= and 1 would
>=C2=A0 =C2=A0 =C2=A0have an issuer of
>=C2=A0 =C2=A0 =C2=A0>>>>>>> "https://as/brand1&qu= ot; and a discovery document available at?
>=C2=A0 =C2=A0 =C2=A0https://as/.well-kno= wn/oauth-authorization-server/brand1
>=C2=A0 =C2=A0 =C2=A0>>>>>>> ).
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> However in the real wo= rld it is not always so simple. We
>=C2=A0 =C2=A0 =C2=A0have many existing implementations in UK open banki= ng that support
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints. Here is an exampl= e (thanks to
>=C2=A0 =C2=A0 =C2=A0@Joseph Heenan )
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Bank ?loadsamoney?= has one idp and, for internet banking,
>=C2=A0 =C2=A0 =C2=A0one ?login page? for both business and personal cus= tomers.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> They have separate= mobile apps for business/personal, and
>=C2=A0 =C2=A0 =C2=A0are required to support app2app. This means they wi= ll definitely
>=C2=A0 =C2=A0 =C2=A0be exposing multiple authorization endpoints (as th= ere?s a 1:1
>=C2=A0 =C2=A0 =C2=A0mapping of authorization endpoints to mobile apps) = - the choice is
>=C2=A0 =C2=A0 =C2=A0how they do this.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> Their choices are:=
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 1. Multiple discov= ery endpoints (one for business, one
>=C2=A0 =C2=A0 =C2=A0for personal), each with a different authorization = endpoint,
>=C2=A0 =C2=A0 =C2=A0multiple issuers (if their vendor allows this)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 2. Single discover= y endpoint, single issuer, multiple
>=C2=A0 =C2=A0 =C2=A0authorization endpoints listed in one discovery doc= (one for
>=C2=A0 =C2=A0 =C2=A0business, one for personal) some of which are hardc= oded by the 3rd
>=C2=A0 =C2=A0 =C2=A0party
>=C2=A0 =C2=A0 =C2=A0>>>>>>>> 3. Multiple discov= ery endpoints each with a different
>=C2=A0 =C2=A0 =C2=A0authorization endpoint, same issuer in all cases (b= reaks RFC8414
>=C2=A0 =C2=A0 =C2=A0and OIDC Discovery)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 3 is invalid an= d that leaves us with options 1 and 2.
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Option 1 can be proble= matic as often it is in reality the
>=C2=A0 =C2=A0 =C2=A0same `issuer` behind the scenes.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> We would like to get f= eedback on this issue and
>=C2=A0 =C2=A0 =C2=A0potentially an extension to RFC8414 to allow the de= finition of
>=C2=A0 =C2=A0 =C2=A0multiple authorization endpoints.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Thanks in advance
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Dave Tonge
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Co-Chair FAPI WG
>=C2=A0 =C2=A0 =C2=A0>>>>>>> Open ID Foundation
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> --
>=C2=A0 =C2=A0 =C2=A0>>>> Vladimir Dzhuvinov
>

--
=
Francis Pouatcha
Co-Founder and Technical Lead at adorys
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

=


--
Francis Pouatcha
Co-= Founder and Technical Lead at adorys
--000000000000f1d4cf05a7311099-- From nobody Thu Jun 4 06:52:23 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0123A0ABA for ; Thu, 4 Jun 2020 06:52: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_1GO_9rOqlv for ; Thu, 4 Jun 2020 06:52:21 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C513A0ABC for ; Thu, 4 Jun 2020 06:52:20 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id g10so5318830wmh.4 for ; Thu, 04 Jun 2020 06:52:20 -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=if/Lit+CdvU/OafEqNhjQD6uj29uzOE7110G5p3xPvQ=; b=atnIxmHLqdx6a6fRRm2oIsc45420BKf0aHFSCAKSOQg2jzfp/fPMOd6rcze0rbGvjo V+7OqSjAacT4PpAMdGX2tzKVJkaYLwHbFpZdAIEx2ek4eGJVFh96le4HpUF8UlJvIuus qhBbF0xgdRrU0+5Plx1zMpLhpdIt4JSYV8vx61+KorjXmZ2M1+nLNkjPhmvaT3k4+hEI av6uVjaDOkkz/hcrsYKDYooYScTZA3brK0/kfasPa6q1ggpK9sKDea8MlHwfn8X4H7wA IdEZHsJgDK1y3CJ0r8yYK8QSbVEZrurWUQpg2t2CM7dcCUxHnMERRqGAGBU6bZwYa1Sy 3B/A== 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=if/Lit+CdvU/OafEqNhjQD6uj29uzOE7110G5p3xPvQ=; b=razpYqTzc2rLlQLAtopZosGVDsCyVpUzteh2bt9ZNAkktbfEWe2C8MSw5fzxkjYCuk FpSlwhPjuFUxZx8pi3083R5w/AK/i5gwDXJYMQi+0TOGiDtUWgLiZekj5i3cQ6Ax0oRH 87/v1Bs8zjFBUOeqPT9AvW2hrCzBV1aeBsEOetXwvRYJfu92WnY+TwISUPuSKHCXzuWL tcitBGMQXpycCkUgELaxqAKO0W+aOzRocU9folULPRZLXzvFsN6GIqPy4Mkp+y7A6wK8 QCbelE8rflAYDiWdjQYpcH3x1IrtD9UI/9JQfQc4C/KWOhNdysVz1M2hoyLBvfBKmr3X fdhQ== X-Gm-Message-State: AOAM530pyzQROdKarbwqMVtN0dyf1hnLgOYOhW8VDXngUcgJDBKPBukl tXXrcnesj0BvRN/ZKrj3zL1EdQZD2xIeqOt3 X-Google-Smtp-Source: ABdhPJxw/lurCouKxTQZ7Qt6mXOM2qmTKYOqGKK7Pt+r519F91mFc8Cz7kVgC2HxzjisWkF7TRIsug== X-Received: by 2002:a1c:305:: with SMTP id 5mr4123326wmd.60.1591278735906; Thu, 04 Jun 2020 06:52:15 -0700 (PDT) Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id t188sm2523782wmt.27.2020.06.04.06.52.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 06:52:15 -0700 (PDT) From: Joseph Heenan Message-Id: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3B195026-3D5A-4424-A140-B705CC20F7FF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 4 Jun 2020 14:52:14 +0100 In-Reply-To: Cc: Dave Tonge , Openid-specs-fapi , OAuth WG To: Francis Pouatcha References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 13:52:23 -0000 --Apple-Mail=_3B195026-3D5A-4424-A140-B705CC20F7FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Francis, > On 3 Jun 2020, at 18:07, Francis Pouatcha = wrote: >=20 > Hello Dave, >=20 > I agree that the best deployment option is: 1 brand =3D 1 issuer =3D 1 = discovery doc, however that is not always possible. >=20 > I'd like to understand Francis what particular issue you see from = allowing an AS to specify multiple authorization_endpoints? > Confusing End User! A user is using the same credentials on a yellow = styled "https://loadsamoney/business/auth = " and a green styled = "https://loadsamoney/consumer/auth ". = A well designed environment will have a centralized page for login and = account management like "https://loadsamoney/accounts/auth = " even better = "https://accounts.loadsamoney/auth ". In the cases Dave and I are thinking of, there=E2=80=99s no SSO between = the different brands (sorry,I=E2=80=99m struggling to find a better word = than brands!), which also have segmented user credentials - there=E2=80=99= s no user confusion. >=20 > I can see that to avoid user confusion it would be necessary for the = Client to record which endpoint they redirected the user to, in case = they need the user to re-authorize - but I can't see any particular = security issue? > Let assume the "Client-Business" will record the business = auth-endpoint and keep sending RO to "https://loadsamoney/business/auth = " for reauthentication. If the user = opens his personal banking application on another tab, "Client-Consumer" = will send the user to "https://loadsamoney/consumer/auth = ". For SSO to work, the AS has to = store the SSO-Cookies under "https://loadsamoney/ = ". Now your AS SSO Cookies are also = accessible to "https://loadsamoney/blog = "! This problem is even worse if = instead of path you use subdomains like = "https://business.loadsamoney/auth " = and "https://consumer.loadsamoney/auth = " the the SSO Cookie of your AS has = to be set to: ".loadsamoney", providing access to the SSO Cookies to all = other subdomain hosted application like "https://blog.loadsamoney/ = ". > Most AS I have used in customer projects use cookies to manage SSO? I think this is either mainly an issue with the example urls, or solved = by pointing out that you should not do SSO between different = authorization endpoints for the reasons you say? > =20 >=20 > No matter which authorization_endpoint the user was sent to, after the = user is redirected back to the Client's redirect_uri the process is the = same as if there had been 1 authorization_endpoint.=20 > AS UI customization is being done today by many AS deployment because = of: > - Multitenancy of deployment > - The need to have client identity disclosed to the RO in a consent = page >=20 > I am in favour of Vladimir's suggestion of: >=20 > "alternative_authorization_endpoints": { > "banking": { > "authorization_endpoint": "https://loadsamoney/business/auth = ", > "description": "loadsmoney business banking customers", > "logo_url": "https://loadsamoney/business/logo.png = " > }, > "personal": { > "authorization_endpoint": "https://loadsamoney/consumer/auth = ", > "description": "loadsmoney personal customers", > "logo_url": "https://loadsamoney/consumer/logo.png = " > } > } > This use case is neither multi tenancy nor the disclosure of the = client identity in a consent page. Starting with the logo here, we will = end up adding css and js code snippets. This type of customizing shall = be done in the AS-Deployment without playing around with the public AS = metadata.=20 I don=E2=80=99t understand why =E2=80=9Cdisclosure of the client = identity in a consent page=E2=80=9D is relevant here; that already = happens, it will continue to happen in the same way and isn=E2=80=99t = affected in any way by this suggestion. Yes, there are other architectures that don=E2=80=99t require this. I = don=E2=80=99t think it is the job of the protocol to disallow or make = some architectures difficult just because other architectures are = better. I don=E2=80=99t think it=E2=80=99s even clear that having a client deal = with 16 different issuers for a single bank (a real world example of = what would happen if we forced =E2=80=98one authorization endpoint per = issuer=E2=80=99) is actually =E2=80=9Cbetter=E2=80=9D. It=E2=80=99s a = pain for the client to manage 16 different issuers rather than 1 with 16 = authorization endpoints - it means 16 client registrations and 16 = issuers to configure, and it obfuscates to the client that these are = actually all the same system. I have a hard time saying that one = architecture is clearly good and that the other should clearly be = disallowed unless you=E2=80=99re willing to go outside of the standards, = particularly when switching architectures is a large breaking change = that would be close to impossible to coordinate in any real world system = with a number of active OAuth clients. > I am in favor of pushing those changes into target AS-Deployment = specific customizing. Many authorization servers are already running multiple authorization = endpoints. They are required in certain architectures, and there are no = other security concerns raised so far that are unique to those = architectures. (The need to do SSO sensibly and securely applies to all = architectures.) The suggested new metadata allows authorization servers to publish these = multiple authorization endpoints in a standard machine readable format = that clients can then use with less need for manual configuration and = poking around emails or =E2=80=98dev portals=E2=80=99 to find the = details. I do not see a downside of allowing this. Thanks Joseph --Apple-Mail=_3B195026-3D5A-4424-A140-B705CC20F7FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Francis,

On 3 Jun 2020, at 18:07, Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

Hello Dave,

I = agree that the best deployment option is: 1 brand =3D 1 issuer =3D 1 = discovery doc, however that is not always possible.

I'd like to understand Francis what = particular issue you see from allowing an AS to specify multiple = authorization_endpoints?
Confusing End User! A user is using the same credentials on a = yellow styled "https://loadsamoney/business/auth" and = a green styled "https://loadsamoney/consumer/auth". A = well designed environment will have a centralized page for login and = account management like "https://loadsamoney/accounts/auth" even = better "https://accounts.loadsamoney/auth".
=

In the cases Dave and I are = thinking of, there=E2=80=99s no SSO between the different brands = (sorry,I=E2=80=99m struggling to find a better word than brands!), which = also have segmented user credentials - there=E2=80=99s no user = confusion.


I can see that to avoid user confusion = it would be necessary for the Client to record which endpoint they = redirected the user to, in case they need the user to re-authorize - but = I can't see any particular security = issue?
Let assume the = "Client-Business" will record the business auth-endpoint and keep = sending RO to "https://loadsamoney/business/auth" for = reauthentication. If the user opens his personal banking application on = another tab, "Client-Consumer" will send the user to "https://loadsamoney/consumer/auth". For SSO to work, the = AS has to store the SSO-Cookies under "https://loadsamoney/". Now your AS SSO Cookies are also = accessible to "https://loadsamoney/blog"! This problem = is even worse if instead of path you use subdomains like "https://business.loadsamoney/auth" and "https://consumer.loadsamoney/auth" the the SSO Cookie of = your AS has to be set to: ".loadsamoney", providing access to the SSO = Cookies to all other subdomain hosted application like "https://blog.loadsamoney/".
Most AS = I have used in customer projects use cookies to manage SSO?

I think this is either mainly an issue with the = example urls, or solved by pointing out that you should not do SSO = between different authorization endpoints for the reasons you = say?

 

No = matter which authorization_endpoint the user was sent to, after the user = is redirected back to the Client's redirect_uri the process is the same = as if there had been 1 = authorization_endpoint. 
AS UI customization is being done today by many AS deployment = because of:
- Multitenancy of deployment
- The need to have client identity disclosed to the RO in a = consent page


I = am in favour of Vladimir's suggestion of:

"alternative_authorization_endpoints": = {
    "banking": {
    =   "authorization_endpoint": "https://loadsamoney/business/auth",
  =     "description": "loadsmoney business banking customers",
      "logo_url": "https://loadsamoney/business/logo.png"
 =   },
    "personal": {
  =     "authorization_endpoint": "https://loadsamoney/consumer/auth",
  =     "description": "loadsmoney personal customers",
      "logo_url": "https://loadsamoney/consumer/logo.png"
 =   }
  }
This use case = is neither multi tenancy nor the disclosure of the client identity = in a consent page. Starting with the logo here, we will end up adding = css and js code snippets. This type of customizing shall be done in the = AS-Deployment without playing around with the public AS = metadata. 

I don=E2=80=99t understand why =E2=80=9Cdisclosure = of the client identity in a consent page=E2=80=9D is relevant here; that = already happens, it will continue to happen in the same way and isn=E2=80=99= t affected in any way by this suggestion.

Yes, there are other architectures that don=E2=80=99= t require this. I don=E2=80=99t think it is the job of the protocol to = disallow or make some architectures difficult just because other = architectures are better.

I don=E2=80=99= t think it=E2=80=99s even clear that having a client deal with 16 = different issuers for a single bank (a real world example of what would = happen if we forced =E2=80=98one authorization endpoint per issuer=E2=80=99= ) is actually =E2=80=9Cbetter=E2=80=9D. It=E2=80=99s a pain for the = client to manage 16 different issuers rather than 1 with 16 = authorization endpoints - it means 16 client registrations and 16 = issuers to configure, and it obfuscates to the client that these are = actually all the same system. I have a hard time saying that one = architecture is clearly good and that the other should clearly be = disallowed unless you=E2=80=99re willing to go outside of the standards, = particularly when switching architectures is a large breaking change = that would be close to impossible to coordinate in any real world system = with a number of active OAuth clients.

I am in favor of pushing those = changes into target AS-Deployment specific = customizing.

Many authorization servers are already running = multiple authorization endpoints. They are required in certain = architectures, and there are no other security concerns raised so far = that are unique to those architectures. (The need to do SSO sensibly and = securely applies to all architectures.)

The suggested new metadata allows authorization = servers to publish these multiple authorization endpoints in a standard = machine readable format that clients can then use with less need for = manual configuration and poking around emails or =E2=80=98dev portals=E2=80= =99 to find the details. I do not see a downside of allowing = this.

Thanks

Joseph

= --Apple-Mail=_3B195026-3D5A-4424-A140-B705CC20F7FF-- From nobody Thu Jun 4 07:26:31 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5CE3A0CFA for ; Thu, 4 Jun 2020 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VCIvTCsj; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VCIvTCsj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfw-oPU-YcB6 for ; Thu, 4 Jun 2020 07:26:24 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70053.outbound.protection.outlook.com [40.107.7.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A97C3A0CEB for ; Thu, 4 Jun 2020 07:26:23 -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=G9BfX5d93qTv2pr2I90Pm/kz7exlvDFpJ5KEKCQ540w=; b=VCIvTCsjCRYGPa+yX/RpS7FMAV13JP7qPH3gDR9//rj9sNgkVfiYjD/1VkPALJdB53j+myTJ8qfRp+SZCZ/5uPthHCZ1iepHTuJs4jy6duAdNu48s65d9beYFAWgJSeO7WApl/oKHTXjclSMlEzCm5D9UUa4l1RJlOZ2jHj8dMs= Received: from DB6PR0802CA0037.eurprd08.prod.outlook.com (2603:10a6:4:a3::23) by VI1PR0802MB2303.eurprd08.prod.outlook.com (2603:10a6:800:a7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Thu, 4 Jun 2020 14:26:17 +0000 Received: from DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::17) by DB6PR0802CA0037.outlook.office365.com (2603:10a6:4:a3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19 via Frontend Transport; Thu, 4 Jun 2020 14:26:17 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT019.mail.protection.outlook.com (10.152.20.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 14:26:17 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Thu, 04 Jun 2020 14:26:17 +0000 X-CR-MTA-TID: 64aa7808 Received: from 9463d92ccaa5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F01F5957-9503-4845-9119-C89277A3FFF1.1; Thu, 04 Jun 2020 14:26:12 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9463d92ccaa5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 04 Jun 2020 14:26:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gHL+ak7TF6mZ9r0DmlHQYkxqqDwN0PE3wZGh52rGT+WnkXaureMZjpWcyI2HXAszNnqYFzsoFxIlLDSIsSp1RCv1bSgny0ud4ZySFWy3DB0YDN+4/miZrAPhuOp4tEyYlnUHQPDJfKuvtEcDitYObm3xF9d5VeXVLU1rigJcOhFH8lqZXRE1Lp3ENdzEpE8Wemj6vbq+4rQ0i1PAPTcjU30gPT9ae0ocDDrj+wGz4/KRRitEdeLbN+s3akaAZdMFZWZcIkRIki8hzMXkm3X9A5SS2Zk/WZ5i+v5OSioCy6BYTmMlVida8olCeuhpwoDTFygO812F9gEHIdpct96Low== 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=G9BfX5d93qTv2pr2I90Pm/kz7exlvDFpJ5KEKCQ540w=; b=Lm03h76Ac+31ULCkZTJ/1fN1nG+df85IdRB6JE4bnWqv0CqOFNULzYdIN2/EtrY96bM85DJ7396VybRq16scn9ZyCCBiSodpUpnSXS1/UBebGYB/Dyj7Aw6KJXWAp+x7iTabxI7gtZtKM8Ar7/Xz3re9T1CVeeZAFmMDuIH50s9xUSemENOMF3xvgjAWn7QqSFkAnNb0pwzHWkG3MeA6BFdjrUak5fG2epeFekkMTGLgUmJ09Wmb/4P6gS/QlNUdptpvGxjFGWOjS8uH7H9+OuDVX6JovHlai/l20xZ5n8o+C0EhoGDVSX5806CdPWe1Aix7XWRJEowkbktU6zzTGg== 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=G9BfX5d93qTv2pr2I90Pm/kz7exlvDFpJ5KEKCQ540w=; b=VCIvTCsjCRYGPa+yX/RpS7FMAV13JP7qPH3gDR9//rj9sNgkVfiYjD/1VkPALJdB53j+myTJ8qfRp+SZCZ/5uPthHCZ1iepHTuJs4jy6duAdNu48s65d9beYFAWgJSeO7WApl/oKHTXjclSMlEzCm5D9UUa4l1RJlOZ2jHj8dMs= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3651.eurprd08.prod.outlook.com (2603:10a6:208:d4::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 14:26:10 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 14:26:10 +0000 From: Hannes Tschofenig To: Denis CC: Rifaat Shekh-Yusef , Vittorio Bertocci , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Thread-Index: AQHWE1f9z2EgpsdZ60eoi9hyjcl/fqiQWrGAgAAd5wCAF3pgAIAAGgMAgB1ZqWCAAZGAAIAB1l6g Date: Thu, 4 Jun 2020 14:26:10 +0000 Message-ID: References: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <24ffa213-1a09-f7d1-28f8-e1b678cf85d9@free.fr> In-Reply-To: <24ffa213-1a09-f7d1-28f8-e1b678cf85d9@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 67019288-f9b0-440b-bb79-42a0c9761cb4.1 x-checkrecipientchecked: true Authentication-Results-Original: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.196.137] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d16c250f-95e4-4455-98da-08d808933e9d x-ms-traffictypediagnostic: AM0PR08MB3651:|VI1PR0802MB2303: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04244E0DC5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: suzb/HHIeBal+bDPmsNE058cGZsSy2rOzqXMtcpQZ3Ko4smclS9hKv2pez0B1TSthk8Vv+voPyoFXoNY+0crY4t1Ud2LW5JxwKocOpSiVDw9iv2rqwkFzpmW43+8gyikRH03EPbyUlhV9/mTHA8PFniEpBYDiLw3ijk6u+8CueHQ2L0R7wIQEu7DukyEw3k3Wr1rBon/kVNSzW4EjP1pQfjEFvcYs6nvJ8oh9e0Uet04dLbSbIYf3x8yRthsHMQShf1BSdZjZqeuLT1+VccdzqKTdo2T/bDoxuXisiT45/iOlROED2l+Hd9QQ751mTdnoOCuBS/UCk+kSFYh7tD0kPOyW6EKTlExWWyPUn7o8VBh9p+q8SLdh8dq/1YpzUoifIHdYthZ5YZ/uQP9LqdEKuzQ9mqycZeB048tglIfTAQbaQgr/LAxw0QPv6r+mw21bIiCprTjBphoFLeWRpGIcg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(396003)(39860400002)(346002)(366004)(26005)(52536014)(966005)(66574014)(478600001)(166002)(4326008)(86362001)(18074004)(186003)(66476007)(2906002)(64756008)(53546011)(33656002)(8936002)(55016002)(83380400001)(8676002)(76116006)(5660300002)(9686003)(7696005)(316002)(66556008)(6916009)(30864003)(71200400001)(66446008)(6506007)(66946007)(9326002)(54906003)(15866825006)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: l6R9QtOdXimpWL3FEFZVr6GoYqdU6M3Xw4L0h8bIEDqkOYMbehoHZRk+dQLQSuPdqrQbJThlrnZpf5++KwdXmVUbdQmJfkG2jmBTHbRxmS7CRUXaX8Xy5qZftSjGb0UcDl/4E6+Fg4FhdxNSMfUBoVi1VJ+iWH+YAwsBzsubCJLh/NWHMnhLJJnSvs8I+1o2dBGD6Kv5a7oHqr/ksTsTVPmhykEkPBBOvC3gkqs2ejEHDZApmKnB4IjdKE7zyygByeEy4/kbr/EO2ScQbQEVa4fHzMYWnV5uCzOz4WjTkXr4nnFPcQ8ebiPN9Yxm51q5Iln2FfXR/NMY5k8RXhPscRFF+0Q7wDsGyuT2DkO7oI50aOS1ez4zg/WJF2OnKF8X7UuCj6gO0qLbD8NzlqAMZKUK0mKFr/vZZGorLAsDclSBJKcbK/SOg4MeHD8WECrKZSi68I58B8DI5OdrflDs98FdJjKlqrl1zz7C8kHfzG3WL6r+NMNPBLuSB1/Plgz8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37161916ED0662F4CB2C736EFA890AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3651 Original-Authentication-Results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(396003)(39860400002)(46966005)(33656002)(26005)(6506007)(53546011)(186003)(70206006)(86362001)(70586007)(6862004)(166002)(8676002)(4326008)(81166007)(356005)(7696005)(47076004)(83380400001)(9326002)(82310400002)(8936002)(66574014)(82740400003)(33964004)(54906003)(478600001)(336012)(55016002)(9686003)(316002)(966005)(18074004)(30864003)(5660300002)(2906002)(52536014)(15866825006)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f2791ae4-84ba-4515-32ab-08d808933a27 X-Forefront-PRVS: 04244E0DC5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZXYslhuLbKSVf+WSAiQ4Stak/7ijlPzXBimlNcm7hcoKpsCNSjq78Ssq6AnSnbIW1tTMCsEIKDeIvd0Z2K6sqZr8j3kMHkLC2SD27vUB2TJLcGosFoOXAy+4tYyoksI3qM76NYnFYuBycWgImRBpMHM798SDDvCPKYrwGqJlpozvD5SdAbHxBXJB+gGyVtqvWKgLadb8OdrYyEtQw9bvf8ARWZK0jdJqQMhQ1uTaRrjBXF2hDUs3S+TM7tR3+G0WzeQWpKDfCF7jWnuAGEnGhvTfEP0ju5mc5vL7M/bsEeoB271vL6xdj2mmaqLHMGIJcvCW6NIEXwibCaxgBx94lYbxwsvuusyvm8fC/+ovqXXWeqeyDdt83eRVNqe2TUTgTb//EXr24nMmY6s6cJXuZ5OQ5qNnhNlzL4wsU/4b8p2tHnumqyrILY/1hcLA+SjE6ZjrFV5SMXM0+Wr3XFSnTO8YZ5Cj2gEvW5fxGc1GwVscHQxcn6P55++Duwy7wBQP X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2020 14:26:17.6565 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d16c250f-95e4-4455-98da-08d808933e9d 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: VI1PR0802MB2303 Archived-At: Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 14:26:30 -0000 --_000_AM0PR08MB37161916ED0662F4CB2C736EFA890AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVuaXMsDQoNClBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgYmVsb3cuDQoNCg0KRnJvbTogRGVu aXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAzLCAyMDIwIDEy OjEyIFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+ DQpDYzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQucy5pZXRmQGdtYWlsLmNvbT47IFZpdHRv cmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+OyBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gIkpTT04gV2ViIFRva2Vu IChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQpIaSBIYW5uZXMs DQpGaXJzdCBvZiBhbGwsIEkgZG8gYXBwcmVjaWF0ZSB5b3VyIGVmZm9ydHMgdG8gYXR0ZW1wdCB0 byBnZXQgcmlkIG9mIHRoZSAiTVVTVCBOT1QiIGluIHRoZSAiUHJpdmFjeSBjb25zaWRlcmF0aW9u cyIgc2VjdGlvbi4NCg0KTGV0IHVzIGxvb2sgYXQgdGhlIGZvbGxvd2luZyBwcm9wb3NlZCBzZW50 ZW5jZToNCg0KICAgIFdoaWxlIHRoaXMgaXMgdGVjaG5pY2FsIHBvc3NpYmxlLCBpdCBpcyBpbXBv cnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgZG9lcyBub3QgYWltIHRv IGV4cG9zZSB0aGUgY29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuDQogICAgdG8gdGhlIGNsaWVu dC4gVGhlIGFjY2VzcyB0b2tlbiBpcyB0aGVyZWZvcmUsIGJ5IGRlc2lnbiwgY29uc2lkZXJlZCB0 byBiZSBvcGFxdWUgdG8gdGhlIGNsaWVudCIuDQoNCkluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9j dW1lbnQsIGEgZGV0YWlsZWQgY29udGVudCBvZiB0aGUgSldUIGlzIGV4cGVjdGVkIGFuZCB0aHVz LCBpZiBhIGNsaWVudCByZWNlaXZlcyBhIEpXVCBjb21wbGlhbnQgdG8gdGhpcyBwcm9maWxlDQoo YW5kIGlmIHRoZSB0b2tlbiBpcyBub3QgZW5jcnlwdGVkIHdoaWNoIGlzIG1vc3Qgb2Z0ZW4gdGhl IGNhc2UpIGl0IHdpbGwgYWJzb2x1dGVseSBiZSBzdXJlIHRvIHBpY2sgdXAgYW55IGd1YXJhbnRl ZWQgZmllbGQgd2l0aGluIHRoZSBKV1QuDQpTbywgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1 bWVudCwgdGhlIGFjY2VzcyB0b2tlbiBjYW5ub3QgYmUgY29uc2lkZXJlZCB0byBiZSBvcGFxdWUg dG8gdGhlIGNsaWVudC4NCg0KW0hhbm5lc10gSGVyZSB3ZSBoYXZlIGEgZGlzY29ubmVjdC4gVGhl IE9BdXRoIDIuMCBkZXNpZ24gZG9lcyBub3QgYXNzdW1lIHRoYXQgdGhlIGNsaWVudCBpbnNwZWN0 cyB0aGUgYWNjZXNzIHRva2VucyBpZiBpdCBmbGllcyBieS4gVGhpcyBkb2N1bWVudCBjb3VsZCBu b3QgY2hhbmdlIHRoYXQuDQpUaGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50IGlzIGFjdHVhbGx5 IHF1aXRlIHNpbXBsZTogVGhvc2Ugd2hvIHdhbnQgdG8gdXNlIEpXVCBhcyBhIGZvcm1hdCBmb3Ig YWNjZXNzIHRva2VucyB0aGV5IGNhbiB1c2UgdGhlIGNsYWltcyBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudC4gWW91IGFyZSBhbHNvIGZyZWUgdG8gdXNlIHdoYXRldmVyIGZvcm1hdCB5b3Ugd2Fu dC4NCg0KDQoNCg0KQWJvdXQgdGhlIHNlY29uZCBwYXJhZ3JhcGgsIGluIHRoZSBjb250ZXh0IG9m IHRoaXMgZG9jdW1lbnQgKGJlc2lkZXMgdGhlIGNhc2Ugd2hlcmUgdGhlIEpXVCBpcyBlbmNyeXB0 ZWQpLCBpdCBpcyBuZWl0aGVyIGRpZmZpY3VsdCwNCm5vciBpbXBvc3NpYmxlIHRvIHBhcnNlIHRo ZSB0b2tlbi4NCg0KQWJvdXQgdGhlIHNlY29uZCBwYXJhZ3JhcGgsIGxldCB1cyBsb29rIGF0IHRo ZSBmb2xsb3dpbmcgcHJvcG9zZWQgc2VudGVuY2UgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1 bWVudCA6DQoNCiAgICAiIEFkZGl0aW9uYWxseSwgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQg dGhlIGFjY2VzcyB0b2tlbiBpcyBjb252ZXllZCBieSB2YWx1ZSBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGltcGxlbWVudGF0aW9uIG1heSBjaGFuZ2UNCiAgICAgIHRoZSB0b2tlbiBmb3Jt YXQgYXQgYW55IHRpbWUgIi4NCg0KVGhlIGFyZ3VtZW50YXRpb24gdGhhdCB0aGUgdG9rZW4gZm9y bWF0IG1heSBjaGFuZ2UgYXQgYW55IHBvaW50IG9mIHRpbWUsIHdoaWxlIGJlaW5nIHZhbGlkIGlu IHRoZSBnZW5lcmFsIGNhc2UsIGlzIGludmFsaWQgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1 bWVudC4NClRoaXMgSldUIHByb2ZpbGUgd2lsbCBiZSBzdGFibGUgb3ZlciB0aW1lLiBUaGlzIG1l YW5zIHRoYXQgdGhpcyBxdW90ZWQgc2VudGVuY2UgaXMgaW5hcHByb3ByaWF0ZSBpbiB0aGUgY29u dGV4dCBvZiB0aGlzIGRvY3VtZW50Lg0KDQpbSGFubmVzXSBIZXJlIGlzIHRoZSBpc3N1ZS4gSW4g YSBnaXZlbiBkZXBsb3ltZW50IHlvdSBkbyBub3Qga25vdyBob3cgdGhlIGFjY2VzcyB0b2tlbiBp cyBlbmNvZGVkIG5vciB3aGV0aGVyIHRoZSBjbGFpbXMgYXJlIGluIHRoaXMgZm9ybWF0LiBZb3Ug ZG9u4oCZdCBrbm93IHdoZXRoZXIgdGhlIHRva2VuIGlzIGNvbnZleWVkIGJ5IHJlZmVyZW5jZSBv ciBieSB2YWx1ZS4gSGVuY2UsIHdoeSBzaG91bGQgd2Ugc3VkZGVubHkgZXZlbiBnaXZlIGRldmVs b3BlcnMgdGhlIGltcHJlc3Npb24gdGhhdCBPQXV0aCBDbGllbnRzIHNob3VsZCBsb29rIGF0IHRo ZSB0b2tlbi4NCg0KDQoNClRoZSB0aGlyZCBwcm9wb3NlZCBwYXJhZ3JhcGggaXMgc3RhdGluZyA6 DQoNCiAgICAiIEluIHNjZW5hcmlvcyB3aGVyZSBpdCBpcyB3aGVyZSBpdCBpcyBkZXNpcmFibGUg Zm9yIHRoZSBjbGllbnRzIHRvIG9idGFpbiBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpbiB0aGUg YWNjZXNzIHRva2VuLCBPQXV0aCAyLjAgdG9rZW4gaW50cm9zcGVjdGlvbg0KICAgICAgbWF5IHBy b3ZpZGUgYSB1c2VmdWwgdG9vbCB0byBlbmFibGUgc3VjaCBmdW5jdGlvbmFsaXR5IChwcm9wZXIg YXV0aG9yaXphdGlvbiBhc3N1bWVkKSAiLg0KDQpSRkMgNzY2MiAoT0F1dGggMi4wIFRva2VuIElu dHJvc3BlY3Rpb24pIGlzIGEgcHJvdG9jb2wgdG8gYmUgdXNlZCBieSBwcm90ZWN0ZWQgcmVzb3Vy Y2VzLCBidXQgaXMgbm90IGEgcHJvdG9jb2wgdG8gYmUgdXNlZCBieSBjbGllbnRzLg0KQXMgaW5k aWNhdGVkLCBpbiBvcmRlciB0byBiZSB1c2FibGUsIGEgInByb3BlciBhdXRob3JpemF0aW9uIiBh bHNvIG5lZWRzIHRvIGJlIG1hbmFnZWQuIEJlc2lkZXMgdGhlIGRpZmZpY3VsdHkgdG8gc3VwcG9y dCBzdWNoIGEgcHJvdG9jb2wgZm9yIGNsaWVudHMNCmFuZCB0byB0d2lzdCBpdHMgb3JpZ2luYWwg dXNhZ2UgYXMgZGVmaW5lZCBpbiBSRkMgNzY2MiwgaXQgaXMgc2ltcGxlciB0byBkZXZlbG9wIHRo ZSBjb2RlIHRvIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgdGhlIEpXVCwgc2luY2UgaXRzIGNvbnRl bnQgaXMgZ3VhcmFudGVlZA0KdG8gYmUgc3RhYmxlIG92ZXIgdGltZS4NCltIYW5uZXNdIFdoaWxl IGl0IG1heSBiZSBzaW1wbGVyIHRvIGluc3BlY3QgdGhlIGFjY2VzcyB0b2tlbiwgdGhlIHVzZSBv ZiB0b2tlbiBpbnRyb3NwZWN0aW9uIGlzIGEgYmV0dGVyIG1hdGNoIGZvciB0aGUgT0F1dGggYXJj aGl0ZWN0dXJlLiBXZSBjYW4gdGFsayBhYm91dCB1cGRhdGluZyB0aGUgdG9rZW4gaW50cm9zcGVj dGlvbiBSRkMgdG8gYWxzbyBkZXNjcmliZSB0aGlzIHVzZSBjYXNlLCBhc3N1bWluZyB0aGVyZSBp cyBpbnRlcmVzdC4NClRoZSBxdWVzdGlvbiBpbiBnZW5lcmFsIHdpbGwgc3VyZmFjZSB3aHkgdGhl IGNsaWVudCBzaG91bGQgZ2V0IGFjY2VzcyB0byB0aGUgY29udGVudCBvZiB0aGUgYWNjZXNzIHRv a2VuIGluIHRoZSBmaXJzdCBwbGFjZS4gRm9yIHRob3NlIGNhc2VzIHdoZXJlIGluZm9ybWF0aW9u IGlzIHBhc3NlZCB0byB0aGUgY2xpZW50IG90aGVyIG1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhlIGlk ZW50aXR5IHRva2VuIGluIE9JREMsIGhhdmUgYmVlbiBkZXZlbG9wZWQuDQoNClRoZSBsYXN0IHBy b3Bvc2VkIHBhcmFncmFwaCBpcyB0aGUgZm9sbG93aW5nOg0KDQogICAiIFNpbmNlIHRoZSBjb250 ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYWNjZXNzaWJsZSB0byB0aGUgcmVzb3VyY2Ugc2Vy dmVyIGl0IGlzIGltcG9ydGFudCB0byBldmFsdWF0ZSB3aGV0aGVyIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgZ2FpbmVkIHRoZSBwcm9wZXIgZW50aXRsZW1lbnQNCiAgICAgIHRvIGhhdmUgYWNjZXNzIHRv IGFueSBjb250ZW50IHJlY2VpdmVkIGluIGZvcm0gb2YgY2xhaW1zLCBmb3IgZXhhbXBsZSB0aHJv dWdoIHVzZXIgY29uc2VudCBpbiBzb21lIGZvcm0sIHBvbGljaWVzIGFuZCBhZ3JlZW1lbnRzIHdp dGggdGhlIG9yZ2FuaXphdGlvbiBydW5uaW5nDQogICAgICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzLCBhbmQgc28gb24uIFRoZSBwb2xpY2llcyBhbmQgdGhlIHVzZXIgaW50ZXJmYWNlcyB0byBl bmFibGUgdGhpcyB1c2VyIGNvbnNlbnQgYXJlLCBob3dldmVyLCBwYXJ0IG9mIGEgc3BlY2lmaWMg ZGVwbG95bWVudCBhbmQgdGhlcmVmb3JlDQogICAgICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50ICIuDQoNClRoZSBzZW50ZW5jZSAiZm9yIGV4YW1wbGUgdGhyb3VnaCB1c2VyIGNv bnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2llcyBhbmQgYWdyZWVtZW50cyB3aXRoIHRoZSBvcmdh bml6YXRpb24gcnVubmluZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLCBhbmQgc28gb24iDQpz aG91bGQgYmUgcmVtb3ZlZCwgc2luY2UgdGhpcyBleGFtcGxlIGxldHMgYmVsaWV2ZSB0aGF0IHRo ZSBjb25zZW50IGlzIGhhbmRsZWQgYnkgdGhlIGF1dGhvcml6YXRpb25zIHNlcnZlcnMgd2hpbGUg aXQgbWlnaHQgYmUgaGFuZGxlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVycy4NCltIYW5uZXNdIFRo ZSBpbmZvcm1hdGlvbiBpcyBkaXNjbG9zZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCBoZW5jZSB0aGUgY29uc2VudCBoYXMgdG8gYmUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuDQoNCg0KVGhlIGxhc3QgcHJvcG9zZWQgcGFyYWdyYXBoIHdvdWxkIGJlIHNvbHV0aW9uIG5l dXRyYWwgaWYgdGhlIGV4YW1wbGUgd2VyZSByZW1vdmVkLiBUaGlzIHdvdWxkIGxlYWQgdG8gdGhl IGZvbGxvd2luZyBzZW50ZW5jZToNCg0KU2luY2UgdGhlIGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0 b2tlbiBpcyBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIgaXQgaXMgaW1wb3J0YW50 IHRvIGV2YWx1YXRlIHdoZXRoZXIgdGhlIHJlc291cmNlIHNlcnZlciBnYWluZWQgdGhlIHByb3Bl ciBlbnRpdGxlbWVudA0KdG8gaGF2ZSBhY2Nlc3MgdG8gYW55IGNvbnRlbnQgcmVjZWl2ZWQgaW4g Zm9ybSBvZiBjbGFpbXMuIFRoZSBwb2xpY2llcyBhbmQgdGhlIHVzZXIgaW50ZXJmYWNlcyB0byBl bmFibGUgdGhpcyB1c2VyIGNvbnNlbnQgYXJlLCBob3dldmVyLCBwYXJ0IG9mIGEgc3BlY2lmaWMg ZGVwbG95bWVudA0KYW5kIHRoZXJlZm9yZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50Lg0KDQpGaW5hbGx5LCB0aGVyZSBhcmUgc3RpbGwgdHdvIHF1ZXN0aW9ucyB0aGF0IGhhdmUg YmVlbiByYWlzZWQgYnV0IHdoaWNoIGhhdmUgbm90IHlldCBiZWVuIGFuc3dlcmVkIGF0IHRoaXMg dGltZToNCg0KICAqICAgaG93IGNhbiBhIGNsaWVudCByZXF1ZXN0IGEgSldUIGNvbXBsaWFudCB0 byB0aGlzIHByb2ZpbGUsIGFuZA0KICAqICAgaG93IGNhbiBhIGNsaWVudCBiZSBjb25maWRlbnQg dGhhdCBpdCBnb3QgYSBKV1QgY29tcGxpYW50IHRvIHRoaXMgcHJvZmlsZSA/DQoNCltIYW5uZXNd IFJlZ2FyZGluZyB0aGUgdHdvIHF1ZXN0aW9uczogSXQgY2Fubm90IGFuZCBpdCB3YXMgbmV2ZXIg dGhlIGludGVudGlvbiBvZiB0aGlzIHdvcmsuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCkRlbmlzDQoN CkxldCBtZSB0cnkgdG8ganVtcCBpbiBoZXJlIGluIG9yZGVyIHRvIG1ha2UgYSBwcm9wb3NhbCBm b3IgdGhlIHRleHQgaW4gdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbiBzZWN0aW9uOg0KDQpGUk9N Og0KNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3Mt dG9rZW4tand0LTA0I3NlY3Rpb24tNj4uICBQcml2YWN5IENvbnNpZGVyYXRpb25zDQoNCg0KICAg QXMgSldUIGFjY2VzcyB0b2tlbnMgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0IG5vdyBi ZWNvbWVzDQogICBwb3NzaWJsZSBmb3IgcmVxdWVzdG9ycyBhbmQgcmVjZWl2ZXJzIHRvIGRpcmVj dGx5IHBlZWsgaW5zaWRlIHRoZQ0KICAgdG9rZW4gY2xhaW1zIGNvbGxlY3Rpb24uICBUaGUgY2xp ZW50IE1VU1QgTk9UIGluc3BlY3QgdGhlIGNvbnRlbnQgb2YNCiAgIHRoZSBhY2Nlc3MgdG9rZW46 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGhlIHJlc291cmNlIHNlcnZlcg0KICAgbWln aHQgZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUgKGZvciBleGFtcGxl IGJ5DQogICBzd2l0Y2hpbmcgZnJvbSB0aGlzIHByb2ZpbGUgdG8gb3BhcXVlIHRva2VucykgaGVu Y2UgYW55IGxvZ2ljIGluIHRoZQ0KICAgY2xpZW50IHJlbHlpbmcgb24gdGhlIGFiaWxpdHkgdG8g cmVhZCB0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgd291bGQNCiAgIGJyZWFrIHdpdGhvdXQgcmVj b3Vyc2UuICBOb25ldGhlbGVzcywgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZA0KICAgbm90 IGFzc3VtZSB0aGF0IGNsaWVudHMgd2lsbCBjb21wbHkgd2l0aCB0aGUgYWJvdmUuICBXaGVuZXZl ciBjbGllbnQNCiAgIGFjY2VzcyB0byB0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgcHJlc2VudHMg cHJpdmFjeSBpc3N1ZXMgZm9yIGENCiAgIGdpdmVuIHNjZW5hcmlvLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgc2hvdWxkIHRha2UgZXhwbGljaXQgc3RlcHMNCiAgIHRvIHByZXZlbnQgaXQgYXMg ZGVzY3JpYmVkIGJlbG93Lg0KDQogICBJbiBzY2VuYXJpb3MgaW4gd2hpY2ggSldUIGFjY2VzcyB0 b2tlbnMgYXJlIGFjY2Vzc2libGUgdG8gdGhlIGVuZA0KICAgdXNlciwgaXQgc2hvdWxkIGJlIGV2 YWx1YXRlZCB3aGV0aGVyIHRoZSBpbmZvcm1hdGlvbiBjYW4gYmUgYWNjZXNzZWQNCiAgIHdpdGhv dXQgcHJpdmFjeSB2aW9sYXRpb25zIChmb3IgZXhhbXBsZSwgaWYgYW4gZW5kIHVzZXIgd291bGQg c2ltcGx5DQogICBhY2Nlc3MgaGlzIG9yIGhlciBvd24gcGVyc29uYWwgaW5mb3JtYXRpb24pIG9y IGlmIHN0ZXBzIG11c3QgYmUgdGFrZW4NCiAgIHRvIGVuZm9yY2UgY29maWRlbnRpYWxpdHkuICBQ b3NzaWJsZSBtZWFzdXJlcyBpbmNsdWRlOiBlbmNyeXB0aW5nIHRoZQ0KICAgYWNjZXNzIHRva2Vu LCBlbmNyeXB0aW5nIHRoZSBzZW5zaXRpdmUgY2xhaW1zLCBvbWl0dGluZyB0aGUgc2Vuc2l0aXZl DQogICBjbGFpbXMgb3Igbm90IHVzaW5nIHRoaXMgcHJvZmlsZSwgZmFsbGluZyBiYWNrIG9uIG9w YXF1ZSBhY2Nlc3MNCiAgIHRva2Vucy4NCg0KICAgSW4gZXZlcnkgc2NlbmFyaW8sIHRoZSBjb250 ZW50IG9mIHRoZSBKV1QgYWNjZXNzIHRva2VuIHdpbGwNCiAgIGV2ZW50dWFsbHkgYmUgYWNjZXNz aWJsZSB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiAgSXQncyBpbXBvcnRhbnQgdG8NCiAgIGV2YWx1 YXRlIHdoZXRoZXIgdGhlIHJlc291cmNlIHNlcnZlciBnYWluZWQgdGhlIHByb3BlciBlbnRpdGxl bWVudCB0bw0KICAgaGF2ZSBhY2Nlc3MgdG8gYW55IGNvbnRlbnQgcmVjZWl2ZWQgaW4gZm9ybSBv ZiBjbGFpbXMsIGZvciBleGFtcGxlDQogICB0aHJvdWdoIHVzZXIgY29uc2VudCBpbiBzb21lIGZv cm0sIHBvbGljaWVzIGFuZCBhZ3JlZW1lbnRzIHdpdGggdGhlDQogICBvcmdhbml6YXRpb24gcnVu bmluZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLCBhbmQgc28gb24uDQoNClRPOg0KDQo2PGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QtMDQjc2VjdGlvbi02Pi4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCiAgIFRoZSBkZXNpZ24g b2YgT0F1dGggMi4wIGVudmlzaW9ucyB0aGF0IGFjY2VzcyB0b2tlbnMgYXJlIGNyZWF0ZWQgYnkN CiAgIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgY29uc3VtZWQgYnkgcmVzb3VyY2Ugc2VydmVy cy4NCiAgIEFzIEpXVCBhY2Nlc3MgdG9rZW5zLCBhcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVu dCwgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0IGlzDQogICBwb3NzaWJsZSBmb3IgT0F1 dGggY2xpZW50cyB0byBwZWVrIGluc2lkZSB0aGUgYWNjZXNzIHRva2VuLg0KICAgV2hpbGUgdGhp cyBpcyB0ZWNobmljYWwgcG9zc2libGUsIGl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhl DQogICBPQXV0aCAyLjAgcHJvdG9jb2wgZG9lcyBub3QgYWltIHRvIGV4cG9zZSB0aGUgY29udGVu dCBvZiB0aGUNCiAgIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50LiBUaGUgYWNjZXNzIHRva2Vu IGlzIHRoZXJlZm9yZSwgYnkgZGVzaWduLCBjb25zaWRlcmVkIHRvIGJlDQogICBvcGFxdWUgdG8g dGhlIGNsaWVudC4NCg0KICAgQSBudW1iZXIgb2YgY2FzZXMgbWF5IG1ha2UgaXQgZGlmZmljdWx0 IG9yIGltcG9zc2libGUgZm9yIGNsaWVudHMgdG8NCiAgIGluc3BlY3QgdGhlIHRva2VuLCBmb3Ig ZXhhbXBsZSwgdGhlIGFjY2VzcyB0b2tlbiBtYXkgYmUgZW5jcnlwdGVkLA0KICAgdGhlIGFjY2Vz cyB0b2tlbiBtYXkgY29udGFpbiB2ZW5kb3Itc3BlY2lmaWMgY2xhaW1zIHRoYXQgaGF2ZSBub3Qg YmVlbg0KICAgc3RhbmRhcmRpemVkIG9yIGhhdmUgYmVlbiBzdGFuZGFyZGl6ZWQgaW4gb3RoZXIg Y29uc29ydGlhIG1ha2luZyBwYXJzaW5nDQogICBvZiB0aGUgdG9rZW4gZGlmZmljdWx0LiBBZGRp dGlvbmFsbHksIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZQ0KICAgYWNjZXNzIHRva2Vu IGlzIGNvbnZleWVkIGJ5IHZhbHVlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW1wbGVt ZW50YXRpb24NCiAgIG1heSBjaGFuZ2UgdGhlIHRva2VuIGZvcm1hdCBhdCBhbnkgdGltZS4NCg0K ICAgSW4gc2NlbmFyaW9zIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlIGNsaWVudHMgdG8g b2J0YWluIGluZm9ybWF0aW9uDQogICB0cmFuc21pdHRlZCBpbiB0aGUgYWNjZXNzIHRva2VuLCBP QXV0aCAyLjAgdG9rZW4gaW50cm9zcGVjdGlvbiBtYXkgcHJvdmlkZQ0KICAgYSB1c2VmdWwgdG9v bCB0byBlbmFibGUgc3VjaCBmdW5jdGlvbmFsaXR5IChwcm9wZXIgYXV0aG9yaXphdGlvbiBhc3N1 bWVkKS4NCg0KICAgSW4gc2NlbmFyaW9zIHdoZXJlIHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3Mg dG9rZW4gbXVzdCBub3QgYmUgcmVhZGFibGUNCiAgIGJ5IGNsaWVudHMsIGVuY3J5cHRpbmcgdGhl IGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0b2tlbiBpcyBSRUNPTU1FTkRFRC4NCg0KICAgU2luY2Ug dGhlIGNvbnRlbnQgb2YgdGhlIGFjY2VzcyB0b2tlbiBpcyBhY2Nlc3NpYmxlIHRvIHRoZSByZXNv dXJjZSBzZXJ2ZXINCiAgIGl0IGlzIGltcG9ydGFudCB0bw0KICAgZXZhbHVhdGUgd2hldGhlciB0 aGUgcmVzb3VyY2Ugc2VydmVyIGdhaW5lZCB0aGUgcHJvcGVyIGVudGl0bGVtZW50IHRvDQogICBo YXZlIGFjY2VzcyB0byBhbnkgY29udGVudCByZWNlaXZlZCBpbiBmb3JtIG9mIGNsYWltcywgZm9y IGV4YW1wbGUNCiAgIHRocm91Z2ggdXNlciBjb25zZW50IGluIHNvbWUgZm9ybSwgcG9saWNpZXMg YW5kIGFncmVlbWVudHMgd2l0aCB0aGUNCiAgIG9yZ2FuaXphdGlvbiBydW5uaW5nIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlcnMsIGFuZCBzbyBvbi4gVGhlIHBvbGljaWVzDQogICBhbmQgdGhlIHVz ZXIgaW50ZXJmYWNlcyB0byBlbmFibGUgdGhpcyB1c2VyIGNvbnNlbnQgYXJlLCBob3dldmVyLCBw YXJ0DQogICBvZiBhIHNwZWNpZmljIGRlcGxveW1lbnQgYW5kIHRoZXJlZm9yZSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQoNCkhvdyBkb2VzIHRoaXMgc291bmQ/DQoNCkNp YW8NCkhhbm5lcw0KDQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNoZWtoLVl1 c2VmDQpTZW50OiBUaHVyc2RheSwgTWF5IDE0LCAyMDIwIDg6MDMgUE0NClRvOiBEZW5pcyA8ZGVu aXMuaWV0ZkBmcmVlLmZyPjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyPg0KQ2M6IFZpdHRvcmlv IEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+PG1haWx0bzp2aXR0b3Jpby5i ZXJ0b2NjaUBhdXRoMC5jb20+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAiSlNPTiBXZWIgVG9rZW4g KEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiDQoNCkRlbmlzLA0KDQpZ b3UgYXJlIHJlaGFzaGluZyB0aGUgc2FtZSBpc3N1ZXMgdGhhdCB5b3UgaGF2ZSBhbHJlYWR5IGRp c2N1c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0IG11bHRpcGxlIHRpbWVzLA0KWW91IGNvdWxkIG5v dCBnZXQgdGhlIFdHIHRvIGFncmVlIHdpdGggeW91ciBwb2ludHMsIGJlY2F1c2UgdGhlIFdHIGJl bGlldmUgdGhhdCB0aGlzIGlzc3VlIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuDQoNClRoZSBiZXN0IHRoZSBjaGFpcnMgY2FuIGRvIGF0IHRoaXMgc3RhZ2UgaXMgdG8gY2Fw dHVyZSB5b3VyIHBvaW50IGluIHRoZSBzaGVwaGVyZCB3cml0ZS11cCB0byB0aGUgSUVTRy4NCldl IHRoaW5rIHRoaXMgZG9jdW1lbnQgaGFzIHRoZSBzdXBwb3J0IG9mIHRoZSBXRyBhbmQgaXMgcmVh ZHkgdG8gbW92ZSBmb3J3YXJkLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIFRodSwgTWF5 IDE0LCAyMDIwIGF0IDEyOjI5IFBNIERlbmlzIDxkZW5pcy5pZXRmQGZyZWUuZnI8bWFpbHRvOmRl bmlzLmlldGZAZnJlZS5mcj4+IHdyb3RlOg0KSGkgVml0dG9yaW8sDQoNCkkgYW0gcmVmZXJyaW5n IHRvIHRoZSBlbWFpbCB5b3Ugc2VudCBvbiBBcHJpbCB0aGUgMjkgdGggd2hpY2ggaXMgY29waWVk IGJlbG93Lg0KDQoxKSBZb3Ugd3JvdGU6DQo+IHRhcmdldGluZyBvZiBhY2Nlc3MgdG9rZW5zDQpM ZXQgbWUgdGhpbmsgYWJvdXQgdGhhdCBhIGJpdCBsb25nZXIuDQpJIGFja25vd2xlZGdlIHRoYXQg dGhlIGRlY2lzaW9uIG9mIGluY2x1ZGluZyBhbiBhdWRpZW5jZSBoYXMgdGhlIGVmZmVjdCBvZiBs ZXR0aW5nIHRoZSBBUyB0cmFjayB3aGVuIHRoZSBjbGllbnQgYWNjZXNzZXMgYSBwYXJ0aWN1bGFy IHJlc291cmNlLA0KYnV0IGF0IHRoZSBzYW1lIHRpbWUgdGhhdOKAmXMgY29tcGxldGVseSBtYWlu c3RyZWFtIGFuZCB2ZXJ5IG11Y2ggYnkgZGVzaWduIGluIGEgdmVyeSBsYXJnZSBudW1iZXIgb2Yg Y2FzZXMuIEFzIHN1Y2gsIEkgZmluZCB0aGUgbGFuZ3VhZ2UNCnlvdSBhcmUgc3VnZ2VzdGluZyB0 byBiZSBwb3RlbnRpYWxseSBjb25mdXNpbmcsIGFzIGl0IHBvc2l0aW9ucyB0aGlzIGFzIGFuIGV4 Y2VwdGlvbiB2cyBhIHByaXZhY3kgcHJvdGVjdGluZyBtYWluc3RyZWFtIHRoYXQgaXMgaW4gZmFj dCBub3QgY29tbW9uLA0KYW5kIGFzY3JpYmVzIHRvIHRoZSBjbGllbnQgbW9yZSBsYXRpdHVkZSB0 aGFuIEkgYmVsaWV2ZSBpcyBsZWdpdGltYXRlIHRvIGV4cGVjdCBvciBncmFudC4NCknigJlsbCB0 cnkgdG8gY29tZSB1cCB3aXRoIGNvbmNpc2UgbGFuZ3VhZ2UgdGhhdCBjbGFyaWZpZXMgdG8gdGhl IHJlYWRlciB0aGF0IHRoZSBjdXJyZW50IG1lY2hhbmlzbSBkb2VzIGFsbG93IEFTIHRyYWNraW5n Lg0KU2luY2UgdGhlIGxhc3QgZHJhZnQgaGFzIGJlZW4gcHVibGlzaGVkIG9uIHRoZSAyNyB0aCwg eW91IGhhdmUgbm90IHByb3Bvc2VkIGFueSAiY29uY2lzZSBsYW5ndWFnZSB0aGF0IGNsYXJpZmll cyB0byB0aGUgcmVhZGVyDQp0aGF0IHRoZSBjdXJyZW50IG1lY2hhbmlzbSBkb2VzIGFsbG93IEFT IHRyYWNraW5nIi4NCg0KMikgWW91IGFsc28gd3JvdGUgYWJvdXQgdGhlICJzdWIiIHVuaXF1ZW5l c3M6DQpBcyBsb25nIGFzIGFuIGlkZW50aWZpZXIgaWRlbnRpZmllcyBvbmUgcmVzb3VyY2Ugb25s eSwgaXQgc2F0aXNmaWVzIHVuaXF1ZW5lc3MuIEl0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIGEgc2lu Z2xldG9uLg0KUkZDIDc1MTkgZGVmaW5lcyBpbiBzZWN0aW9uIDQuMS4yIHRoZSBzZW1hbnRpY3Mg b2YgdGhlICJzdWIiIGNsYWltIHVzaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQpUaGUgc3Vi amVjdCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBzY29wZWQgdG8gYmUgbG9jYWxseSB1bmlxdWUgaW4g dGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuDQpUaGUgdGV4 dCBkb2VzIE5PVCBzYXkgdGhhdCB0aGUgc3ViamVjdCB2YWx1ZSAiTVVTVCBiZSBzY29wZWQgdG8g YmUgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHJlc291cmNlIHNlcnZlciIu DQpDaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIGFuIGFscmVhZHkgZGVmaW5lZCBjbGFpbSBpcyBu b3QgcGVybWl0dGVkLiBJZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIHN1Y2ggYSBzZW1hbnRpY3Mg YXZhaWxhYmxlLA0KYSBuZXcgY2xhaW0gc2hvdWxkIGJlIGRlZmluZWQgKGFuZCBpdCB3b3VsZCBi ZSB2ZXJ5IG5pY2UgdG8gaGF2ZSBpdCAhKS4NCg0KMykgVGhlIHRleHQgaXMgdGhlIHByaXZhY3kg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXM6DQoNCiAgIEFsdGhvdWdoIHRoZSBhYmlsaXR5 IHRvIGNvcnJlbGF0ZSByZXF1ZXN0cyBtaWdodCBiZSByZXF1aXJlZCBieSBkZXNpZ24gaW4gbWFu eSBzY2VuYXJpb3MsIHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIGF1dGhvcml6YXRpb24N CiAgIHNlcnZlciBtaWdodCB3YW50IHRvIHByZXZlbnQgY29ycmVsYXRpb24gdG8gcHJlc2VydmUg dGhlIGRlc2lyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCg0KSW4gdGhlIHJlYWwgd29ybGQsIGl0IGlz IGFsc28gY2xpZW50cyBvciBlbmQtdXNlcnMgd2hpY2ggd291bGQgbGlrZSB0byBwcmV2ZW50IGNv cnJlbGF0aW9uIHRvIHByZXNlcnZlIHRoZWlyIGRlc2lyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCg0K QSBiZXR0ZXIgc2VudGVuY2Ugd291bGQgYmU6DQoNCiAgIEFsdGhvdWdoIHRoZSBhYmlsaXR5IHRv IGNvcnJlbGF0ZSByZXF1ZXN0cyBtaWdodCBiZSByZXF1aXJlZCBieSBkZXNpZ24gaW4gbWFueSBz Y2VuYXJpb3MsIHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIGF1dGhvcml6YXRpb24NCiAg IHNlcnZlciBvciB0aGUgY2xpZW50IG1pZ2h0IHdhbnQgdG8gcHJldmVudCBjb3JyZWxhdGlvbiB0 byBwcmVzZXJ2ZSB0aGUgZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5Lg0KDQo0KSBUaGUgdGV4dCBj b250aW51ZXMgd2l0aDoNCg0KICAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZCBjaG9vc2Ug aG93IHRvIGFzc2lnbiAic3ViIiB2YWx1ZXMgYWNjb3JkaW5nIHRvIHRoZSBsZXZlbCBvZiBwcml2 YWN5IHJlcXVpcmVkIGJ5IGVhY2gNCiAgIHNpdHVhdGlvbi4gIEZvciBpbnN0YW5jZTogaWYgYSBz b2x1dGlvbiByZXF1aXJlcyBwcmV2ZW50aW5nIHRyYWNraW5nICBwcmluY2lwYWwgYWN0aXZpdGll cyBhY3Jvc3MgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycywNCiAgIHRoZSAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgc2hvdWxkIGVuc3VyZSB0aGF0IEpXVCBhY2Nlc3MgdG9rZW5zIG1lYW50IGZvciBk aWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVycyBoYXZlIGRpc3RpbmN0ICJzdWIiDQogICB2YWx1ZXMg dGhhdCBjYW5ub3QgYmUgY29ycmVsYXRlZCBpbiB0aGUgZXZlbnQgb2YgcmVzb3VyY2Ugc2VydmVy cyBjb2xsdXNpb24uDQoNCkF1dGhvcml6YXRpb24gc2VydmVycyBhcmUgbm90IG5lY2Vzc2FyaWx5 IGFibGUgdG8gY2hvb3NlIHRoZSBsZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkIGJ5IGVhY2ggc2l0 dWF0aW9uLiBXaGVuIHRoZXJlIGFyZSBkaWZmZXJlbnQNCnNpdHVhdGlvbnMgZm9yIHRoZSBzYW1l IHJlc291cmNlIHNlcnZlciwgdGhlIHNjb3BlIGlzICh1bmZvcnR1bmF0ZWx5IGF0IHRoZSBtb21l bnQpIHRoZSBvbmx5IHdheSB0byBzZWxlY3QgdGhlICJsZXZlbCBvZiBwcml2YWN5IHRoYXQgaXMg cmVxdWlyZWQiLg0KDQpUaGUgZXhhbXBsZSAoIkZvciBpbnN0YW5jZToiKSBpcyBvbmx5IGFuIGV4 YW1wbGUgdGhhdCBwcm92aWRlcyBhIHZhZ3VlIHJlY29tbWVuZGF0aW9uIGZvciB0aGUgQVNzIHdo aWNoIGlzIE5PVCBjb25mb3JtYW50DQp3aXRoIHRoZSBzZW1hbnRpY3Mgb2YgdGhlICJzdWIiIGNs YWltIGFzIGRlZmluZWQgaW4gUkZDIDc1MTkuDQoNCldoYXQgc2hvdWxkIGJlIGRpc2N1c3NlZCBo ZXJlIGFyZSBub3QgImV4YW1wbGVzIiBvciB3aGF0IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHNo b3VsZCBkbywgYnV0IGV4cGxhbmF0aW9ucyBhYm91dCB0aGUgaW1wbGljYXRpb25zDQpmb3IgdGhl IGVuZC11c2VyIG9yIGZvciB0aGUgY2xpZW50IGZvciB0aGUgdmFyaW91cyB2YWx1ZXMgdGhhdCBj YW4gYmUgcGxhY2VkIGludG8gdGhlICJzdWIiIGNsYWltIGJ5IGFuIEFTLiBUaGUgcHJvYmxlbSBp cyB3aWRlciB0aGF0IHNpbXBseQ0KYSBjb2xsdXNpb24gYmV0d2VlbiByZXNvdXJjZSBzZXJ2ZXJz LCBidXQgYWxzbyB3aXRoIG90aGVyIHNlcnZlcnMgdGhhdCBETyBOT1QgcGFydGljaXBhdGUgaW4g YW55IE9BdXRoIGV4Y2hhbmdlLg0KDQpSRkMgNjk3MyAoUHJpdmFjeSBDb25zaWRlcmF0aW9ucykg c3RhdGVzIGluIHNlY3Rpb24gNyA6IEd1aWRlbGluZXMNClRoaXMgc2VjdGlvbiBwcm92aWRlcyBn dWlkYW5jZSBmb3IgZG9jdW1lbnQgYXV0aG9ycyBpbiB0aGUgZm9ybSBvZiBhIHF1ZXN0aW9ubmFp cmUgYWJvdXQgYSBwcm90b2NvbCBiZWluZyBkZXNpZ25lZC4NClRoZSBxdWVzdGlvbm5haXJlIG1h eSBiZSB1c2VmdWwgYXQgYW55IHBvaW50IGluIHRoZSBkZXNpZ24gcHJvY2VzcywgcGFydGljdWxh cmx5IGFmdGVyIGRvY3VtZW50IGF1dGhvcnMgaGF2ZSBkZXZlbG9wZWQNCmEgaGlnaC1sZXZlbCBw cm90b2NvbCBtb2RlbCBhcyBkZXNjcmliZWQgaW4gW1JGQzQxMDFdLg0KT25lIG9mIHRoZSBxdWVz dGlvbnMgaXM6DQpmLiAgQ29ycmVsYXRpb24uICBEb2VzIHRoZSBwcm90b2NvbCBhbGxvdyBmb3Ig Y29ycmVsYXRpb24gb2YgaWRlbnRpZmllcnMgPyAgQXJlIHRoZXJlIGV4cGVjdGVkIHdheXMgdGhh dCBpbmZvcm1hdGlvbiBleHBvc2VkDQpieSB0aGUgcHJvdG9jb2wgd2lsbCBiZSBjb21iaW5lZCBv ciBjb3JyZWxhdGVkIHdpdGggaW5mb3JtYXRpb24gb2J0YWluZWQgb3V0c2lkZSB0aGUgcHJvdG9j b2wgPw0KSXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUgYW4gYW5zd2VyIHRvIHRoZXNlIHR3byBx dWVzdGlvbnMuDQoNCkhlcmVhZnRlciBpcyBzb21lIHRleHQgdGhhdCBpcyBmdWxseSBjb25mb3Jt YW50IHdpdGggUkZDIDc1MTkgd2hpY2ggc2hvdWxkIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBw cml2YWN5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24NCndoaWNoIGV4cGxhaW5zIHRoZSBpbXBsaWNh dGlvbnMgb2YgdGhlIHR3byAoYW5kIG9ubHkgdHdvKSBmbGF2b3VycyBvZiB0aGUgInN1YiIgY2xh aW0uDQpXaGVuIHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBsb2NhbGx5IHVuaXF1ZSBpZGVudGlm aWVyIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIsIHRoaXMgYWxsb3dzIHRoZSB0cmFja2lu ZyBvZiBwcmluY2lwYWwgYWN0aXZpdGllcw0KYWNyb3NzIG11bHRpcGxlIHJlc291cmNlIHNlcnZl cnMuDQoNCldoZW4gdGhlIHN1YiBjbGFpbSBjb250YWlucyBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVu dGlmaWVyLCB0aGlzIGFsbG93cyB0byBjb3JyZWxhdGUgcHJpbmNpcGFsIGFjdGl2aXRpZXMgYWNy b3NzIG11bHRpcGxlIHJlc291cmNlDQpzZXJ2ZXJzLCB3aGlsZSBpbiBhZGRpdGlvbiwgdGhpcyBn bG9iYWxseSB1bmlxdWUgaWRlbnRpZmllciBtYXkgYWxzbyBhbGxvdyB0byBjb3JyZWxhdGUgdGhl IHByaW5jaXBhbCBhY3Rpdml0aWVzIG9uIHNlcnZlcnMgd2hlcmUNCm5vIGFjY2VzcyBoYXMgYmVl biBwZXJmb3JtZWQgYnkgdGhlIHByaW5jaXBhbHMgdG8gdGhlc2Ugc2VydmVycyBidXQgd2hlcmUg dGhlIHNhbWUgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXJzIGFyZSBiZWluZyB1c2VkDQpieSB0 aGVzZSBzZXJ2ZXJzLg0KRGVuaXMNClRoYW5rcyBEZW5pcyBmb3IgdGhlIHRob3JvdWdoIGNvbW1l bnRhcnkuDQoNCj4gVGhlIHRpdGxlIG9mIHRoaXMgc3BlYy4NCkZpeGVkLCB0aGFua3MhDQoNCj4g VGhlIGNsaWVudCBNVVNUIE5PVCBpbnNwZWN0IHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9r ZW4NClRoaXMgaXMgcmVhbGx5IGEgc3RpY2t5IHBvaW50LiBJIHJlYWxseSB3YW50IHRvIGFja25v d2xlZGdlIHlvdXIgUG9WIG9uIHRoaXMsIGJ1dCBhdCB0aGUgc2FtZSB0aW1lIEkgZm91bmQgdGhp cyB0byBiZSBvbmUgb2YgdGhlIGJpZ2dlc3Qgc291cmNlcyBvZiBpc3N1ZXMgaW4gdGhlIHVzZSBv ZiBKV1QgZm9yIGFjY2VzcyB0b2tlbnMgaGVuY2UgSSBmZWVsIHdlIHJlYWxseSBuZWVkIHRvIGdp dmUgc29saWQgZ3VpZGFuY2UgaGVyZS4gTGV0IG1lIGV4cGFuZCBmdXJ0aGVyIG9uIHRoZSByZWFz b25pbmcgYmVoaW5kIGl0LCBhbmQgcGVyaGFwcyB3ZSBjYW4gZ2V0IHRvIGxhbmd1YWdlIHRoYXQg c2F0aXNmaWVzIGJvdGggUG9Wcy4NClRvIG1lIHRoZSBrZXkgcG9pbnQgaXMgdGhhdCBjbGllbnRz IHNob3VsZCBub3Qgd3JpdGUgY29kZSB0aGF0IGluc3BlY3RzIGFjY2VzcyB0b2tlbnMuIFRha2lu ZyBhIGRlcGVuZGVuY3kgb24gdGhlIGFiaWxpdHkgdG8gZG8gc28gaXMgaWdub3JpbmcgZnVuZGFt ZW50YWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFyY2hpdGVjdHVyZSBhbmQgcmVsYXRpb25zaGlw cyBiZXR3ZWVuIE9BdXRoIHJvbGVzLCBhbmQgc3VnZ2VzdHMgYW4gYWJpbGl0eSBvZiB0aGUgY2xp ZW50IHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGljIG9mIHRoZSBjb250ZW50IHRoYXQgY2Fubm90 IGJlIGFzc3VtZWQgaW4gdGhlIGdlbmVyYWwgY2FzZS4gSSBleHBhbmRlZCBvbiB0aGUgZGV0YWls cyBpbiBteSBmb3JtZXIgcmVwbHkgdG8geW91IG9uIHRoaXMgdG9waWMsIEkgd291bGQgcmVjb21t ZW5kIHJlZmVycmluZyB0byBpdC4gQ2xpZW50cyB2aW9sYXRpbmcgdGhpcyBzaW1wbGUgcHJpbmNp cGxlIGhhcyBiZWVuIG9uZSBvZiB0aGUgbW9zdCBjb21tb24gc291cmNlcyBvZiBwcm9kdWN0aW9u IGlzc3VlcyBJIGhhZCB0byBkZWFsIHdpdGggaW4gdGhlIHBhc3QgZmV3IHllYXJzLCBhbmQgb25l IG9mIHRoZSBoYXJkZXN0IHRvIHJlbWVkaWF0ZSBnaXZlbiB0aGF0IGNsaWVudHMgYXJlIGhhcmQg dG8gdXBkYXRlIGFuZCBzb21ldGltZXMgdGhlIHRoaW5ncyB0aGV5IHJlbGllZCBvbiB3ZXJlIGly cmVtZWRpYWJseSBsb3N0LiBUaGlzIGlzIHdoeSBJIGFtIGluY2xpbmVkIHRvIHB1dCBpbiBoZXJl IHN0cm9uZyBsYW5ndWFnZS4NClRoYXQgc2FpZDogSSBoYXZlIG5vdGhpbmcgYWdhaW5zdCBjbGll bnQgZGV2ZWxvcGVycyBleGFtaW5pbmcgYSBuZXR3b3JrIHRyYWNlIGFuZCBkcmF3aW5nIGNvbmNs dXNpb25zIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIHdoYXQgdGhleSBzZWUuIFRoYXQgZG9lc27i gJl0IGNyZWF0ZSBhbnkgaGFyZCBkZXBlbmRlbmNpZXMgYW5kIGhhcyBubyBpbXBsaWNhdGlvbnMg aW4gcmVzcGVjdCB0byBjaGFuZ2VzIGluIHRoZSBzb2x1dGlvbiBiZWhhdmlvci4gSG93ZXZlciBJ IGFtIG5vdCBzdXJlIGhvdyB0byBwaHJhc2UgdGhhdCBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgZ2l2 ZW4gdGhhdCByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBpbmV2aXRhYmx5IHJlZmVycyB0byBpdHMg Y29kZS4gSSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25zLg0KDQo+ICAzKeKApg0KSSBoYXZlIGEgcHJl dHR5IGhhcmQgdGltZSBmb2xsb3dpbmcgdGhlIGNoYWluIG9mIHJlYXNvbmluZyBpbiB0aGlzIHNl Y3Rpb24uIExldCBtZSBhdHRlbXB0IHRvIHRhY2tsZSBpdCB0byB0aGUgYmVzdCBvZiBteSB1bmRl cnN0YW5kaW5nLg0KSSB0aGluayB0aGUga2V5IG1pZ2h0IGJlDQo+IGEgY2xpZW50IHNob3VsZCBi ZSBhYmxlIHRvIGNob29zZSB3aGV0aGVyIGl0IHdpc2hlcyB0aGUgc3ViIGNsYWltIHRvIGNvbnRh aW4gWy4uXQ0KSSBkb27igJl0IHRoaW5rIHRoYXQgc2hvdWxkIGJlIGEgY2hvaWNlIGxlZnQgdG8g dGhlIGNsaWVudC4gSW4gYnVzaW5lc3Mgc3lzdGVtcywgbXkgZXhwZXJpZW5jZSBpcyB0aGF0IHRo ZSB0eXBlIG9mIGlkZW50aWZpZXJzIHRvIGJlIHVzZWQgKHdoZW4gdGhlIElkUCBnaXZlcyBhbnkg Y2hvaWNlIGF0IGFsbCkgIGlzIGVzdGFibGlzaGVkIGF0IHJlc291cmNlIHByb3Zpc2lvbmluZyB0 aW1lLiBJIGFtIG5vdCBhd2FyZSBvZiBtZWNoYW5pc21zIHRocnUgd2hpY2ggYSBjbGllbnQgc2ln bmFscyB0aGUgbmF0dXJlIG9mIHRoZSBpZGVudGlmaWVyIHRvIGJlIHVzZWQsIG5vciB0aGF0IHdv dWxkIGJlIGZ1bGx5IGZlYXNpYmxlICh0aGUgcmVzb3VyY2Uga25vd3Mgd2hhdCBpdCBuZWVkcyB0 byBwZXJmb3JtIGl0cyBmdW5jdGlvbikuDQpGdXJ0aGVybW9yZToNCj4gd2hpY2ggaGFzIG5vdGhp bmcgdG8gZG8gd2l0aCB1bmlxdWVuZXNzIHNpbmNlIHRoZSB2YWx1ZSBjaGFuZ2VzIGZvciBldmVy eSBnZW5lcmF0ZWQgdG9rZW4uDQpBZ2FpbiwgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCB3YXMgdG91 Y2hlZCBvbiBpbiBteSBmb3JtZXIgcmVwbHkgdG8geW91ciBtZXNzYWdlLiBBcyBsb25nIGFzIGFu IGlkZW50aWZpZXIgaWRlbnRpZmllcyBvbmUgcmVzb3VyY2Ugb25seSwgaXQgc2F0aXNmaWVzIHVu aXF1ZW5lc3MuIEl0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIGEgc2luZ2xldG9uLg0KRmluYWxseSwg dGhlIHNjb3BlIGlzIG9wdGlvbmFsIChmb3IgZ29vZCByZWFzb25zOiAxc3QgcGFydHkgYW5kIG5v biBkZWxlZ2F0aW9uIHNjZW5hcmlvcyBkb27igJl0IHJlcXVpcmUgaXQpIGhlbmNlIGl0IGNhbm5v dCBiZSByZWxpZWQgdXBvbiBmb3IgcHJvcGVydGllcyB0aGF0IHNob3VsZCBob2xkIGluIGV2ZXJ5 IHNjZW5hcmlvLg0KSW4gc3VtbWFyeTogcGVyIHRoZSBwcmVjZWRpbmcgdGhyZWFkIG9uIHRoaXMg dG9waWMsIHRoZSBjb25zZW5zdXMgd2FzIHRoYXQgdmFyeWluZyB0aGUgc3ViIGNvbnRlbnQgd2Fz IGEgc2F0aXNmYWN0b3J5IHdheSBvZiBwcm90ZWN0aW5nIGFnYWluc3QgY29ycmVsYXRpb24uIEkg ZG9u4oCZdCBhIGdyZWUgdGhhdCBjbGllbnRzIHNob3VsZCBoYXZlIGEgbWVjaGFuaXNtIHRvIHJl cXVlc3QgZGlmZmVyZW50IHN1YiBmbGF2b3JzLCBhcyB0aGF0IGRlY2lzaW9uIHNob3VsZCBiZSBk b25lIG91dCBvZiBiYW5kIGJ5IHRoZSBBUyBhbmQgUlM7IGFuZCB0aGUgc2NvcGUgaXNu4oCZdCBh bHdheXMgYXZhaWxhYmxlIGFueXdheS4NCj4gdGFyZ2V0aW5nIG9mIGFjY2VzcyB0b2tlbnMNCkxl dCBtZSB0aGluayBhYm91dCB0aGF0IGEgYml0IGxvbmdlci4NCkkgYWNrbm93bGVkZ2UgdGhhdCB0 aGUgZGVjaXNpb24gb2YgaW5jbHVkaW5nIGFuIGF1ZGllbmNlIGhhcyB0aGUgZWZmZWN0IG9mIGxl dHRpbmcgdGhlIEFTIHRyYWNrIHdoZW4gdGhlIGNsaWVudCBhY2Nlc3NlcyBhIHBhcnRpY3VsYXIg cmVzb3VyY2UsIGJ1dCBhdCB0aGUgc2FtZSB0aW1lIHRoYXTigJlzIGNvbXBsZXRlbHkgbWFpbnN0 cmVhbSBhbmQgdmVyeSBtdWNoIGJ5IGRlc2lnbiBpbiBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIGNh c2VzLiBBcyBzdWNoLCBJIGZpbmQgdGhlIGxhbmd1YWdlIHlvdSBhcmUgc3VnZ2VzdGluZyB0byBi ZSBwb3RlbnRpYWxseSBjb25mdXNpbmcsIGFzIGl0IHBvc2l0aW9ucyB0aGlzIGFzIGFuIGV4Y2Vw dGlvbiB2cyBhIHByaXZhY3kgcHJvdGVjdGluZyBtYWluc3RyZWFtIHRoYXQgaXMgaW4gZmFjdCBu b3QgY29tbW9uLCBhbmQgYXNjcmliZXMgdG8gdGhlIGNsaWVudCBtb3JlIGxhdGl0dWRlIHRoYW4g SSBiZWxpZXZlIGlzIGxlZ2l0aW1hdGUgdG8gZXhwZWN0IG9yIGdyYW50Lg0KSeKAmWxsIHRyeSB0 byBjb21lIHVwIHdpdGggY29uY2lzZSBsYW5ndWFnZSB0aGF0IGNsYXJpZmllcyB0byB0aGUgcmVh ZGVyIHRoYXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtIGRvZXMgYWxsb3cgQVMgdHJhY2tpbmcuDQoN CkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERlbmlzIDxkZW5pcy5pZXRmQGZyZWUuZnI+PG1haWx0 bzpkZW5pcy5pZXRmQGZyZWUuZnI+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDIwIGF0 IDA5OjEyDQpUbzogIm9hdXRoQGlldGYub3JnIjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxvYXV0 aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gU2Vjb25kIFdHTEMgb24gIkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRo IDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQpZb3Ugd2lsbCBmaW5kIGZvdXIgY29tbWVudHMgbnVtYmVy ZWQgMSkgdG8gNCkuDQoxKSBUaGUgdGl0bGUgb2YgdGhpcyBzcGVjLiBpczoNCg0KSlNPTiBXZWIg VG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMNCg0KU28sIHRo aXMgc3BlYy4gaXMgc3VwcG9zZWQgdG8gYmUgdGFyZ2V0ZWQgdG8gT0F1dGggMi4wLiAgSG93ZXZl ciwgdGhlIGhlYWRlciBhdCB0aGUgdG9wIG9mIHRoZSBwYWdlIG9taXRzIHRvIG1lbnRpb24gaXQu DQoNCkN1cnJlbnRseSwgaXQgaXMgOg0KSW50ZXJuZXQtRHJhZnQgICAgICAgT0F1dGggQWNjZXNz IFRva2VuIEpXVCBQcm9maWxlICAgICAgICAgICBBcHJpbCAyMDIwDQpJdCBzaG91bGQgcmF0aGVy IGJlOg0KSW50ZXJuZXQtRHJhZnQgICAgICAgT0F1dGggMi4wIEFjY2VzcyBUb2tlbiBKV1QgUHJv ZmlsZSAgICAgICAgICAgQXByaWwgMjAyMA0KDQoyKSBUaGUgZm9sbG93aW5nIHRleHQgaXMgd2l0 aGluIHNlY3Rpb24gNi4NCg0KVGhlIGNsaWVudCBNVVNUIE5PVCBpbnNwZWN0IHRoZSBjb250ZW50 IG9mDQp0aGUgYWNjZXNzIHRva2VuOiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSBy ZXNvdXJjZSBzZXJ2ZXINCm1pZ2h0IGRlY2lkZSB0byBjaGFuZ2UgdG9rZW4gZm9ybWF0IGF0IGFu eSB0aW1lIChmb3IgZXhhbXBsZSBieQ0Kc3dpdGNoaW5nIGZyb20gdGhpcyBwcm9maWxlIHRvIG9w YXF1ZSB0b2tlbnMpIGhlbmNlIGFueSBsb2dpYyBpbiB0aGUNCmNsaWVudCByZWx5aW5nIG9uIHRo ZSBhYmlsaXR5IHRvIHJlYWQgdGhlIGFjY2VzcyB0b2tlbiBjb250ZW50IHdvdWxkDQpicmVhayB3 aXRob3V0IHJlY291cnNlLg0KTm9uZXRoZWxlc3MsIGF1dGhvcml6YXRpb24gc2VydmVycyBzaG91 bGQNCm5vdCBhc3N1bWUgdGhhdCBjbGllbnRzIHdpbGwgY29tcGx5IHdpdGggdGhlIGFib3ZlLg0K SXQgaXMgb2YgYSBwcmltYXJ5IGltcG9ydGFuY2UgdGhhdCBjbGllbnRzIE1BWSBiZSBhYmxlIHRv IGluc3BlY3QgdG9rZW5zIGJlZm9yZSB0cmFuc21pdHRpbmcgdGhlbS4NClRoZSAiTVVTVCBOT1Qi IGlzIG5vdCBhY2NlcHRhYmxlLg0KVGhlIGFib3ZlIHRleHQgc2hvdWxkIGJlIHJlcGxhY2VkIHdp dGg6DQoNClJlYWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBjb250ZW50IG1heSBiZSB1c2VmdWwgZm9y IHRoZSB1c2VyIHRvIHZlcmlmeSB0aGF0DQp0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgbWF0Y2hl cyB3aXRoIGl0cyBleHBlY3RhdGlvbnMuICBIb3dldmVyLA0KdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyIG1pZ2h0IGRlY2lkZSB0byBjaGFuZ2UgdGhlDQp0 b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUuICBUaHVzLCB0aGUgY2xpZW50IHNob3VsZCBub3QgZXhw ZWN0IHRvIGFsd2F5cyBiZQ0KaW4gYSBwb3NpdGlvbiB0byByZWFkIHRoZSBhY2Nlc3MgdG9rZW4g Y29udGVudC4NCg0KVGhlIHJlbWFpbmluZyBvZiB0aGUgdGV4dCBhYm91dCB0aGlzIHRvcGljIGlz IGZpbmUuDQoNCg0KMykgVGhlIG5leHQgdG9waWMgaXMgYWJvdXQgdGhlIHN1YiBjbGFpbS4NCg0K VGhlIHRleHQgc3RhdGVzOg0KDQpBbHRob3VnaCB0aGUgYWJpbGl0eSB0byBjb3JyZWxhdGUgcmVx dWVzdHMgbWlnaHQgYmUgcmVxdWlyZWQgYnkNCmRlc2lnbiBpbiBtYW55IHNjZW5hcmlvcywgdGhl cmUgYXJlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbg0Kc2VydmVyIG1pZ2h0IHdh bnQgdG8gcHJldmVudCBjb3JyZWxhdGlvbiB0byBwcmVzZXJ2ZSB0aGUgZGVzaXJlZA0KbGV2ZWwg b2YgcHJpdmFjeS4gQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZCBjaG9vc2UgaG93IHRvIGFz c2lnbg0Kc3ViIHZhbHVlcyBhY2NvcmRpbmcgdG8gdGhlIGxldmVsIG9mIHByaXZhY3kgcmVxdWly ZWQgYnkgZWFjaA0Kc2l0dWF0aW9uLg0KDQpJIGhhdmUgYSBzZXQgb2YgcXVlc3Rpb25zOg0KDQog IDEuICBIb3cgY2FuIGF1dGhvcml6YXRpb24gc2VydmVycyBjaG9vc2UgaG93IHRvIGFzc2lnbiBz dWIgdmFsdWVzIGFjY29yZGluZyB0byB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAiYnkg ZWFjaCBzaXR1YXRpb24iID8NCiAgMi4gIEhvdyBjYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGtu b3cgdGhlIGxldmVsIG9mIHByaXZhY3kgcmVxdWlyZWQgImJ5IGVhY2ggc2l0dWF0aW9uIiA/DQog IDMuICBIb3cgY2FuIHRoZSB1c2VycyBiZSBpbmZvcm1lZCBvZiB0aGUgbGV2ZWwgb2YgcHJpdmFj eSByZXF1aXJlZCAiYnkgZWFjaCBzaXR1YXRpb24iID8NCiAgNC4gIEhvdyBjYW4gdGhlIHVzZXJz IGNvbnNlbnQgd2l0aCB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAiYnkgZWFjaCBzaXR1 YXRpb24iID8NCkN1cnJlbnRseSwgdGhlIHJlcXVlc3QgTVVTVCBpbmNsdWRlIGVpdGhlciBhIHJl c291cmNlIHBhcmFtZXRlciBvciBhbiBhdWQgY2xhaW0gcGFyYW1ldGVyLCB3aGlsZSBpdCBNQVkg aW5jbHVkZSBhIHNjb3BlIHBhcmFtZXRlci4NClRoZSBzeW50YXggb2YgdGhlIHNjb3BlIHBhcmFt ZXRlciBpcyBhIGxpc3Qgb2Ygc3BhY2UtZGVsaW1pdGVkLCBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdz IChSRkMgNjc0OSkuIEl0IGlzIHRodXMgc3ViamVjdCB0byBwcml2YXRlIGFncmVlbWVudHMNCmJl dHdlZW4gY2xpZW50cyBhbmQgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBTaW5jZSB0aGUgc2NvcGUg aXMgYmVpbmcgcmV0dXJuZWQsIGl0IGlzIGEgcHJpbWFyeSBpbXBvcnRhbmNlIHRoYXQgdGhlIHJl dHVybmVkIHNjb3BlIG1hdGNoZXMNCndpdGggaXRzIGV4cGVjdGF0aW9ucyBiZWZvcmUgdHJhbnNt aXR0aW5nIHRoZSB0b2tlbiB0byBhIFJlc291cmNlIFNlcnZlci4NCg0KSW4gdGhlb3J5LCBhIGNs aWVudCBzaG91bGQgYmUgYWJsZSB0byBjaG9vc2Ugd2hldGhlciBpdCB3aXNoZXMgdGhlIHN1YiBj bGFpbSB0byBjb250YWluIDoNCg0KICAqICAgYSBnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXIgZm9y IGFsbCBBU3MgKCJnbG9iYWxseSB1bmlxdWUiKSwNCiAgKiAgIGEgdW5pcXVlIGlkZW50aWZpZXIg Zm9yIGVhY2ggQVMgKCJsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVy IiksDQogICogICBhIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggUlMsIG9yDQogICogICBh IGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggYXV0aG9yaXphdGlvbiB0b2tlbiByZXF1ZXN0 Lg0KVGhlIG9ubHkgdmFyaWFibGUgcGFyYW1ldGVyIHRoYXQgaXQgY2FuIHVzZSBmb3IgdGhpcyBw dXJwb3NlIGluIHRoZSB0b2tlbiByZXF1ZXN0IGlzIHRoZSBzY29wZSBwYXJhbWV0ZXIuDQoNClJG QyA3NTE5IHN0YXRlcyBpcyBzZWN0aW9uIDQuMS4yOg0KDQpUaGUgc3ViamVjdCB2YWx1ZSBNVVNU IGVpdGhlciBiZSBzY29wZWQgdG8gYmUgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2Yg dGhlIGlzc3Vlcg0Kb3IgYmUgZ2xvYmFsbHkgdW5pcXVlLg0KDQpJdCBpcyBxdWl0ZSBoYXJkIHRv IHJlY29nbml6ZSB0aGF0IHRoZSBzdWIgY2xhaW0gaXMgYWJsZSB0byBjYXJyeSBhIGRpZmZlcmVu dCBwc2V1ZG9ueW0gZm9yIGVhY2ggUlMsIGkuZS4gZm9yIGNhc2UgKGMpLCBvcg0KYSBkaWZmZXJl bnQgcHNldWRvbnltIGZvciBlYWNoIGF1dGhvcml6YXRpb24gdG9rZW4gcmVxdWVzdCwgaS5lLiBm b3IgY2FzZSAoZCksIHdoaWNoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdW5pcXVlbmVzcw0Kc2lu Y2UgdGhlIHZhbHVlIGNoYW5nZXMgZm9yIGV2ZXJ5IGdlbmVyYXRlZCB0b2tlbi4NCg0KVGhpcyBo YXMgaW1wbGljYXRpb25zIGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KRm9yIGluc3RhbmNl OiBpZiBhIHNvbHV0aW9uIHJlcXVpcmVzIHByZXZlbnRpbmcgdHJhY2tpbmcNCnByaW5jaXBhbCBh Y3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLCB0aGUNCmF1dGhvcml6 YXRpb24gc2VydmVyIHNob3VsZCBlbnN1cmUgdGhhdCBKV1QgYWNjZXNzIHRva2VucyBtZWFudCBm b3INCmRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzIGhhdmUgZGlzdGluY3Qgc3ViIHZhbHVlcyB0 aGF0IGNhbm5vdCBiZQ0KY29ycmVsYXRlZCBpbiB0aGUgZXZlbnQgb2YgcmVzb3VyY2Ugc2VydmVy cyBjb2xsdXNpb24uDQoNClNpbmNlIGl0IGFkZHJlc3NlcyBjYXNlIChjKS4NCg0KYW5kIGFsc28g YWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQo0LmIpIFNpbWlsYXJseTogaWYgYSBzb2x1dGlv biByZXF1aXJlcyBwcmV2ZW50aW5nIGEgcmVzb3VyY2Ugc2VydmVyIGZyb20NCmNvcnJlbGF0aW5n IHRoZSBwcmluY2lwYWzigJlzIGFjdGl2aXR5IHdpdGhpbiB0aGUgcmVzb3VyY2UgaXRzZWxmLCB0 aGUNCmF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBhc3NpZ24gZGlmZmVyZW50IHN1YiB2YWx1 ZXMgZm9yIGV2ZXJ5IEpXVA0KYWNjZXNzIHRva2VuIGlzc3VlZC4NCg0KU2luY2UgaXQgYWRkcmVz c2VzIGNhc2UgKGQpLg0KDQpUaGlzIG1lYW5zIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBwbGFjZWQg aW4gdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB3YXMgYSBnb29kIGF0dGVtcHQg dG8gYWRkcmVzcyB0aGUgY2FzZSwNCmJ1dCB0aGF0IHRoZSB0ZXh0IG5lZWRzIHRvIGJlIHJldmlz ZWQuDQoNClByb3Bvc2VkIHRleHQgcmVwbGFjZW1lbnQgZm9yIGFsbCB0aGUgcHJldmlvdXNseSBx dW90ZWQgc2VudGVuY2VzOg0KDQpBY2NvcmRpbmcgdG8gUkZDIDc1MTkgKDQuMS4yKTogVGhlIHN1 YmplY3QgdmFsdWUgTVVTVCBlaXRoZXIgYmUgc2NvcGVkIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGlu IHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIgb3IgYmUgZ2xvYmFsbHkgdW5pcXVlLg0KDQpXaGVu IHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllciwgdGhp cyBhbGxvd3MgdG8gY29ycmVsYXRlIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBs ZSByZXNvdXJjZSBzZXJ2ZXJzLCB3aGlsZSBpbiBhZGRpdGlvbiwNCnRoaXMgZ2xvYmFsbHkgdW5p cXVlIGlkZW50aWZpZXIgbWF5IGFsc28gYWxsb3cgdG8gY29ycmVsYXRlIHRoZSBwcmluY2lwYWwg YWN0aXZpdGllcyBvbiBzZXJ2ZXJzIHdoZXJlIG5vIGFjY2VzcyBoYXMgYmVlbiBwZXJmb3JtZWQg YnkgdGhlIHByaW5jaXBhbHMNCnRvIHRoZXNlIHNlcnZlcnMgYnV0IHdoZXJlIHRoZSBzYW1lIGds b2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyBhcmUgYmVpbmcgdXNlZCBieSB0aGVzZSBzZXJ2ZXJz Lg0KDQpXaGVuIHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBsb2NhbGx5IHVuaXF1ZSBpZGVudGlm aWVyIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIsIHRoaXMgYWxzbyBhbGxvd3MgdGhlIHRy YWNraW5nIG9mIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBsZSByZXNvdXJjZSBz ZXJ2ZXJzLg0KDQpUaGUgc2NvcGUgcmVxdWVzdCBwYXJhbWV0ZXIgaXMgdGhlIG9ubHkgd2F5IHRv IGluZmx1ZW5jZSBvbiB0aGUgY29udGVudCBvZiB0aGUgc3ViIGNsYWltIHBhcmFtZXRlci4gSXRz IG1lYW5pbmcgaXMgc3ViamVjdCB0byBhIHByaXZhdGUgYWdyZWVtZW50DQpiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBBUywgd2hpY2ggbWVhbnMgdGhhdCB0aGUgdXNlIG9mIHRoZSBzY29wZSBw YXJhbWV0ZXIgaXMgdGhlIG9ubHkgd2F5IHRvIGNob29zZSBiZXR3ZWVuIGEgbG9jYWxseSB1bmlx dWUgaWRlbnRpZmllcg0KaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBhIGdsb2JhbGx5 IHVuaXF1ZSBpZGVudGlmaWVyLg0KDQpTaW5jZSB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGJlaW5n IHJldHVybmVkLCBpdCBpcyBhIHByaW1hcnkgaW1wb3J0YW5jZSB0aGF0IHRoZSByZXR1cm5lZCBz Y29wZSBtYXRjaGVzIHdpdGggdGhlIGV4cGVjdGF0aW9ucyBvZiB0aGUgY2xpZW50IGJlZm9yZSB0 cmFuc21pdHRpbmcNCnRoZSB0b2tlbiB0byBhIFJlc291cmNlIFNlcnZlci4NCg0KSG93ZXZlciwg dGhlcmUgYXJlIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgd291bGQgbGlrZSB0byBiZSBh YmxlIHRvIGNob29zZSB3aGV0aGVyIGl0IHdpc2hlcyB0aGUgc3ViIGNsYWltIHRvIGNvbnRhaW4g Og0KICAgIC0gYSBkaWZmZXJlbnQgcHNldWRvbnltIGZvciBlYWNoIFJTIHNvIHRoYXQgZGlmZmVy ZW50IHJlc291cmNlIHNlcnZlcnMgd2lsbCBiZSB1bmFibGUgdG8gY29ycmVsYXRlIGl0cyBhY3Rp dml0aWVzLCBvcg0KICAgIC0gYSBkaWZmZXJlbnQgcHNldWRvbnltIGZvciBlYWNoIGF1dGhvcml6 YXRpb24gdG9rZW4gcmVxdWVzdCwgc28gdGhhdCB0aGUgc2FtZSByZXNvdXJjZSBzZXJ2ZXIgY2Fu bm90IGNvcnJlbGF0ZSBpdHMgYWN0aXZpdGllcyBwZXJmb3JtZWQgYXQgZGlmZmVyZW50IGluc3Rh bnQgb2YgdGltZS4NCg0KQ29uc2lkZXJpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgc3ViIGNsYWlt LCB0aGVzZSB0d28gY2FzZXMgY2Fubm90IGJlIGN1cnJlbnRseSBzdXBwb3J0ZWQuDQoNCg0KNCkg VGhlIG5leHQgdG9waWMgaXMgYWJvdXQgdGhlIHRhcmdldGluZyBvZiBhY2Nlc3MgdG9rZW5zDQpU ZXh0IGhhZCBiZWVuIHByb3Bvc2VkIGJlZm9yZSB0aGUgbGFzdCBjb25mZXJlbmNlIGNhbGwuIFRo ZW4sIHRoZSB0b3BpYyBoYXMgYmVlbiBwcmVzZW50ZWQgYXQgdGhlIHZlcnkgZW5kIG9mIHRoZSBs YXN0IGNvbmZlcmVuY2UgY2FsbCwgYnV0IG5vIHRleHQgaGFzIGJlZW4gaW5jbHVkZWQNCmluIHRo ZSBuZXh0IGRyYWZ0Lg0KSGVyZSBpcyBhIHJldmlzZWQgdGV4dCBiZSBpbmNsdWRlZCBpbiB0aGUg cHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOg0KRm9yIHNlY3VyaXR5IHJlYXNvbnMsIHNv bWUgY2xpZW50cyBtYXkgYmUgd2lsbGluZyB0byB0YXJnZXQgdGhlaXIgYWNjZXNzIHRva2VucyBi dXQsIGZvciBwcml2YWN5IHJlYXNvbnMsIG1heSBiZSB1bndpbGxpbmcgdG8gZGlzY2xvc2UgdG8g QXV0aG9yaXphdGlvbiBTZXJ2ZXJzDQphbiBpZGVudGlmaWNhdGlvbiBvZiB0aGUgUmVzb3VyY2Ug U2VydmVycyB0aGV5IGFyZSBnb2luZyB0byBhY2Nlc3MsIHNvIHRoYXQgQXV0aG9yaXphdGlvbiBT ZXJ2ZXJzIHdpbGwgYmUgdW5hYmxlIHRvIGtub3cgd2hpY2ggcmVzb3VyY2VzIHNlcnZlcnMgYXJl IGJlaW5nIGFjY2Vzc2VkLg0KVGhlIGRpc2Nsb3N1cmUgb2YgdGhlIFJlc291cmNlIFNlcnZlcnMg bmFtZXMgYWxsb3dzIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlcnMgdG8gbGlzdCBhbGwgdGhlIFJl c291cmNlIFNlcnZlcnMgYmVpbmcgYWNjZXNzIGJ5IGFsbCBpdHMgdXNlcnMgYW5kIGluIGFkZGl0 aW9uIHRvIGxpc3QgcGFpcnMNCm9mIChQcmluY2lwYWwsIFJlc291cmNlIFNlcnZlcnMpIHdoaWNo IGFsbG93IHRvIHRyYWNlIGFsbCB0aGUgdXNlcnMgYWNjZXNzZXMgdG8gUmVzb3VyY2UgU2VydmVy cyBwZXJmb3JtZWQgdGhyb3VnaCBhIGdpdmVuIEF1dGhvcml6YXRpb24gU2VydmVyLiBXaGVuIGEg dG9rZW4gaXMgdGFyZ2V0ZWQsDQp0aGlzIHByb2ZpbGUgZG9lcyBub3QgY29udGFpbiBwcm92aXNp b25zIHRvIGFkZHJlc3MgdGhlc2UgdHdvIHRocmVhdHMuDQoNCkRlbmlzDQpIaSBhbGwsDQoNClRo aXMgaXMgYSBzZWNvbmQgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yICJKU09OIFdlYiBUb2tl biAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyIuDQoNCkhlcmUgaXMg dGhlIGRvY3VtZW50Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtYWNjZXNzLXRva2VuLWp3dC0wNg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo ZSBPQXV0aCBtYWlsaW5nIGxpc3QgYnkgQXByaWwgMjksIDIwMjAuDQoNClJlZ2FyZHMsDQogUmlm YWF0ICYgSGFubmVzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KDQoNCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM0PR08MB37161916ED0662F4CB2C736EFA890AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IFw7Y29sb3JcOmJsYWNrIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MjYxNzYzMjAzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYxOTEyNTAz NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjI3MzAyNjkxODsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTk1ODQ3NjM3MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0 LWlkOjI4MTc2NzU4MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODMzNTAzNTY2O30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxODU4MzQ3NTY5Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTA1NTk5MDM3NDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDox OTMzMjAwMjgxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzUzMTg1NDg2O30NCkBsaXN0IGw0 OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsMg0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs NDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IERlbmlzLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNlZSBteSByZXNwb25zZSBi ZWxvdy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBEZW5pcyAmbHQ7ZGVuaXMuaWV0ZkBmcmVlLmZyJmd0OyA8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdW5lIDMsIDIwMjAgMTI6MTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5l cyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQucy5pZXRmQGdtYWlsLmNvbSZndDs7 IFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20mZ3Q7OyBv YXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTZWNvbmQg V0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAg QWNjZXNzIFRva2VucyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEhhbm5lcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5GaXJzdCBvZiBhbGws IEkgZG8gYXBwcmVjaWF0ZSB5b3VyIGVmZm9ydHMgdG8gYXR0ZW1wdCB0byBnZXQgcmlkIG9mIHRo ZSAmcXVvdDtNVVNUIE5PVCZxdW90OyBpbiB0aGUgJnF1b3Q7UHJpdmFjeSBjb25zaWRlcmF0aW9u cyZxdW90OyBzZWN0aW9uLjxicj4NCjxicj4NCkxldCB1cyBsb29rIGF0IHRoZSBmb2xsb3dpbmcg cHJvcG9zZWQgc2VudGVuY2U6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+V2hpbGUgdGhpcyBpcyB0ZWNobmljYWwgcG9zc2libGUsIGl0IGlz IGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhlIE9BdXRoIDIuMCBwcm90b2NvbCBkb2VzIG5vdCBh aW0gdG8gZXhwb3NlIHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4NCjwvc3Bhbj48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGUgY2xp ZW50LiBUaGUgYWNjZXNzIHRva2VuIGlzIHRoZXJlZm9yZSwgYnkgZGVzaWduLCBjb25zaWRlcmVk IHRvIGJlIG9wYXF1ZSB0byB0aGUgY2xpZW50JnF1b3Q7Ljwvc3Bhbj48YnI+DQo8aT48YnI+DQpJ biB0aGUgY29udGV4dCBvZiB0aGlzIGRvY3VtZW50PC9pPiwgYSBkZXRhaWxlZCBjb250ZW50IG9m IHRoZSBKV1QgaXMgZXhwZWN0ZWQgYW5kIHRodXMsIGlmIGEgY2xpZW50IHJlY2VpdmVzIGEgSldU IGNvbXBsaWFudCB0byB0aGlzIHByb2ZpbGUNCjxicj4NCihhbmQgaWYgdGhlIHRva2VuIGlzIG5v dCBlbmNyeXB0ZWQgd2hpY2ggaXMgbW9zdCBvZnRlbiB0aGUgY2FzZSkgaXQgd2lsbCBhYnNvbHV0 ZWx5IGJlIHN1cmUgdG8gcGljayB1cCBhbnkgZ3VhcmFudGVlZCBmaWVsZCB3aXRoaW4gdGhlIEpX VC4NCjxicj4NClNvLCA8aT5pbiB0aGUgY29udGV4dCBvZiB0aGlzIGRvY3VtZW50PC9pPiwgdGhl IDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YWNjZXNzIHRva2VuIGNhbm5vdCBiZSBjb25zaWRl cmVkIHRvIGJlIG9wYXF1ZSB0byB0aGUgY2xpZW50Ljwvc3Bhbj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPltIYW5uZXNdIEhlcmUgd2UgaGF2ZSBh IGRpc2Nvbm5lY3QuIFRoZSBPQXV0aCAyLjAgZGVzaWduIGRvZXMgbm90IGFzc3VtZSB0aGF0IHRo ZSBjbGllbnQgaW5zcGVjdHMgdGhlIGFjY2VzcyB0b2tlbnMgaWYgaXQgZmxpZXMgYnkuIFRoaXMg ZG9jdW1lbnQgY291bGQgbm90IGNoYW5nZSB0aGF0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPlRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgYWN0dWFsbHkgcXVpdGUg c2ltcGxlOiBUaG9zZSB3aG8gd2FudCB0byB1c2UgSldUIGFzIGEgZm9ybWF0IGZvciBhY2Nlc3Mg dG9rZW5zIHRoZXkgY2FuIHVzZSB0aGUgY2xhaW1zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 LiBZb3UgYXJlIGFsc28gZnJlZSB0bw0KIHVzZSB3aGF0ZXZlciBmb3JtYXQgeW91IHdhbnQuIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KQWJvdXQgdGhlIHNlY29u ZCBwYXJhZ3JhcGgsIDxpPmluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQgKDwvaT5iZXNp ZGVzIHRoZSBjYXNlIHdoZXJlIHRoZSBKV1QgaXMgZW5jcnlwdGVkKSwgaXQgaXMgbmVpdGhlciBk aWZmaWN1bHQsDQo8YnI+DQpub3IgaW1wb3NzaWJsZSB0byBwYXJzZSB0aGUgdG9rZW48aT4uPGJy Pg0KPC9pPjxicj4NCkFib3V0IHRoZSBzZWNvbmQgcGFyYWdyYXBoLCBsZXQgdXMgbG9vayBhdCB0 aGUgZm9sbG93aW5nIHByb3Bvc2VkIHNlbnRlbmNlPGk+IGluIHRoZSBjb250ZXh0IG9mIHRoaXMg ZG9jdW1lbnQ8L2k+IDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7IEFkZGl0 aW9uYWxseSwgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiBpcyBj b252ZXllZCBieSB2YWx1ZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGltcGxlbWVudGF0 aW9uIG1heSBjaGFuZ2UNCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg dG9rZW4gZm9ybWF0IGF0IGFueSB0aW1lICZxdW90Oy48YnI+DQo8YnI+DQpUaGUgYXJndW1lbnRh dGlvbiB0aGF0IHRoZSB0b2tlbiBmb3JtYXQgbWF5IGNoYW5nZSBhdCBhbnkgcG9pbnQgb2YgdGlt ZSwgd2hpbGUgYmVpbmcgdmFsaWQgaW4gdGhlIGdlbmVyYWwgY2FzZSwgaXMgaW52YWxpZA0KPGk+ aW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudDwvaT4uIDxicj4NClRoaXMgSldUIHByb2Zp bGUgd2lsbCBiZSBzdGFibGUgb3ZlciB0aW1lLiBUaGlzIG1lYW5zIHRoYXQgdGhpcyBxdW90ZWQg c2VudGVuY2UgaXMgaW5hcHByb3ByaWF0ZQ0KPGk+aW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1 bWVudDwvaT4uPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5bSGFubmVzXSBIZXJlIGlzIHRoZSBpc3N1ZS4gSW4gYSBnaXZlbiBkZXBsb3ltZW50IHlv dSBkbyBub3Qga25vdyBob3cgdGhlIGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIG5vciB3aGV0aGVy IHRoZSBjbGFpbXMgYXJlIGluIHRoaXMgZm9ybWF0LiBZb3UgZG9u4oCZdCBrbm93IHdoZXRoZXIg dGhlIHRva2VuIGlzIGNvbnZleWVkDQogYnkgcmVmZXJlbmNlIG9yIGJ5IHZhbHVlLiBIZW5jZSwg d2h5IHNob3VsZCB3ZSBzdWRkZW5seSBldmVuIGdpdmUgZGV2ZWxvcGVycyB0aGUgaW1wcmVzc2lv biB0aGF0IE9BdXRoIENsaWVudHMgc2hvdWxkIGxvb2sgYXQgdGhlIHRva2VuLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NClRoZSB0 aGlyZCBwcm9wb3NlZCBwYXJhZ3JhcGggaXMgc3RhdGluZyA6PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IEluIHNjZW5hcmlvcyB3 aGVyZSBpdCBpcyB3aGVyZSBpdCBpcyBkZXNpcmFibGUgZm9yIHRoZSBjbGllbnRzIHRvIG9idGFp biBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpbiB0aGUgYWNjZXNzIHRva2VuLCBPQXV0aCAyLjAg dG9rZW4gaW50cm9zcGVjdGlvbg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1heSBwcm92aWRlIGEgdXNlZnVsIHRvb2wgdG8gZW5hYmxlIHN1Y2ggZnVuY3Rpb25hbGl0eSAo cHJvcGVyIGF1dGhvcml6YXRpb24gYXNzdW1lZCkgJnF1b3Q7Ljxicj4NCjxicj4NCjwvc3Bhbj5S RkMgNzY2MiAoT0F1dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb24pIGlzIGEgcHJvdG9jb2wgdG8g YmUgdXNlZCBieSBwcm90ZWN0ZWQgcmVzb3VyY2VzLCBidXQgaXMgbm90IGEgcHJvdG9jb2wgdG8g YmUgdXNlZCBieSBjbGllbnRzLg0KPGJyPg0KQXMgaW5kaWNhdGVkLCBpbiBvcmRlciB0byBiZSB1 c2FibGUsIGEgJnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5wcm9wZXIgYXV0aG9yaXph dGlvbiZxdW90OyBhbHNvIG5lZWRzIHRvIGJlIG1hbmFnZWQuIEJlc2lkZXMgdGhlIGRpZmZpY3Vs dHkgdG8gc3VwcG9ydCBzdWNoIGEgcHJvdG9jb2wgZm9yIGNsaWVudHMNCjxicj4NCmFuZCB0byB0 d2lzdCBpdHMgb3JpZ2luYWwgdXNhZ2UgYXMgZGVmaW5lZCBpbiBSRkMgNzY2MiwgaXQgaXMgc2lt cGxlciB0byBkZXZlbG9wIHRoZSBjb2RlIHRvIGV4YW1pbmUgdGhlIGNvbnRlbnQgb2YgdGhlIEpX VCwgc2luY2UgaXRzIGNvbnRlbnQgaXMgZ3VhcmFudGVlZA0KPGJyPg0KdG8gYmUgc3RhYmxlIDwv c3Bhbj5vdmVyIHRpbWU8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi48L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5bSGFubmVzXSBXaGlsZSBpdCBtYXkgYmUg c2ltcGxlciB0byBpbnNwZWN0IHRoZSBhY2Nlc3MgdG9rZW4sIHRoZSB1c2Ugb2YgdG9rZW4gaW50 cm9zcGVjdGlvbiBpcyBhIGJldHRlciBtYXRjaCBmb3IgdGhlIE9BdXRoIGFyY2hpdGVjdHVyZS4g V2UgY2FuIHRhbGsgYWJvdXQgdXBkYXRpbmcgdGhlIHRva2VuIGludHJvc3BlY3Rpb24NCiBSRkMg dG8gYWxzbyBkZXNjcmliZSB0aGlzIHVzZSBjYXNlLCBhc3N1bWluZyB0aGVyZSBpcyBpbnRlcmVz dC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBxdWVzdGlvbiBpbiBnZW5l cmFsIHdpbGwgc3VyZmFjZSB3aHkgdGhlIGNsaWVudCBzaG91bGQgZ2V0IGFjY2VzcyB0byB0aGUg Y29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBmaXJzdCBwbGFjZS4gRm9yIHRob3Nl IGNhc2VzIHdoZXJlIGluZm9ybWF0aW9uIGlzIHBhc3NlZCB0byB0aGUgY2xpZW50DQogb3RoZXIg bWVjaGFuaXNtcywgc3VjaCBhcyB0aGUgaWRlbnRpdHkgdG9rZW4gaW4gT0lEQywgaGF2ZSBiZWVu IGRldmVsb3BlZC4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbGFzdCBwcm9wb3NlZCBwYXJh Z3JhcGggaXMgdGhlIGZvbGxvd2luZzo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7IFNp bmNlIHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYWNjZXNzaWJsZSB0byB0aGUg cmVzb3VyY2Ugc2VydmVyIGl0IGlzIGltcG9ydGFudCB0byBldmFsdWF0ZSB3aGV0aGVyIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgZ2FpbmVkIHRoZSBwcm9wZXIgZW50aXRsZW1lbnQNCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBoYXZlIGFjY2VzcyB0byBhbnkgY29udGVudCBy ZWNlaXZlZCBpbiBmb3JtIG9mIGNsYWltcywgPGk+Zm9yIGV4YW1wbGUgdGhyb3VnaCB1c2VyIGNv bnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2llcyBhbmQgYWdyZWVtZW50cyB3aXRoIHRoZSBvcmdh bml6YXRpb24gcnVubmluZw0KPC9pPjxicj4NCjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLCBhbmQgc28gb248L2k+LiBUaGUgcG9saWNp ZXMgYW5kIHRoZSB1c2VyIGludGVyZmFjZXMgdG8gZW5hYmxlIHRoaXMgdXNlciBjb25zZW50IGFy ZSwgaG93ZXZlciwgcGFydCBvZiBhIHNwZWNpZmljIGRlcGxveW1lbnQgYW5kIHRoZXJlZm9yZQ0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50ICZxdW90Oy48YnI+DQo8YnI+DQpUaGUgc2VudGVuY2UgJnF1b3Q7Zm9yIGV4YW1w bGUgdGhyb3VnaCB1c2VyIGNvbnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2llcyBhbmQgYWdyZWVt ZW50cyB3aXRoIHRoZSBvcmdhbml6YXRpb24gcnVubmluZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzLCBhbmQgc28gb24mcXVvdDsNCjxicj4NCnNob3VsZCBiZSByZW1vdmVkLCBzaW5jZSB0aGlz IGV4YW1wbGUgbGV0cyBiZWxpZXZlIHRoYXQgdGhlIGNvbnNlbnQgaXMgaGFuZGxlZCBieSB0aGUg YXV0aG9yaXphdGlvbnMgc2VydmVycyB3aGlsZSBpdCBtaWdodCBiZSBoYW5kbGVkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+W0hhbm5lc10gVGhlIGluZm9ybWF0aW9uIGlzIGRpc2Nsb3NlZCBieSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYW5kIGhlbmNlIHRoZSBjb25zZW50IGhhcyB0byBiZSB3aXRoIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KVGhlIGxhc3QgcHJvcG9zZWQgcGFyYWdyYXBoIHdvdWxkIGJlIHNvbHV0 aW9uIG5ldXRyYWwgaWYgdGhlIGV4YW1wbGUgd2VyZSByZW1vdmVkLiBUaGlzIHdvdWxkIGxlYWQg dG8gdGhlIGZvbGxvd2luZyBzZW50ZW5jZTo8YnI+DQo8YnI+DQpTaW5jZSB0aGUgY29udGVudCBv ZiB0aGUgYWNjZXNzIHRva2VuIGlzIGFjY2Vzc2libGUgdG8gdGhlIHJlc291cmNlIHNlcnZlciBp dCBpcyBpbXBvcnRhbnQgdG8gZXZhbHVhdGUgd2hldGhlciB0aGUgcmVzb3VyY2Ugc2VydmVyIGdh aW5lZCB0aGUgcHJvcGVyIGVudGl0bGVtZW50DQo8YnI+DQp0byBoYXZlIGFjY2VzcyB0byBhbnkg Y29udGVudCByZWNlaXZlZCBpbiBmb3JtIG9mIGNsYWltcy4gVGhlIHBvbGljaWVzIGFuZCB0aGUg dXNlciBpbnRlcmZhY2VzIHRvIGVuYWJsZSB0aGlzIHVzZXIgY29uc2VudCBhcmUsIGhvd2V2ZXIs IHBhcnQgb2YgYSBzcGVjaWZpYyBkZXBsb3ltZW50DQo8YnI+DQphbmQgdGhlcmVmb3JlIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KRmluYWxseSwgdGhlcmUg YXJlIHN0aWxsIHR3byBxdWVzdGlvbnMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkIGJ1dCB3aGljaCBo YXZlIG5vdCB5ZXQgYmVlbiBhbnN3ZXJlZCBhdCB0aGlzIHRpbWU6DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5ob3cgY2FuIGEgY2xpZW50IHJlcXVlc3QgYSBKV1QgY29tcGxpYW50 IHRvDQo8aT50aGlzPC9pPiBwcm9maWxlLCBhbmQgPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5ob3cgY2FuIGEgY2xp ZW50IGJlIGNvbmZpZGVudCB0aGF0IGl0IGdvdCBhIEpXVCBjb21wbGlhbnQgdG8NCjxpPnRoaXM8 L2k+IHByb2ZpbGUgPzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+W0hhbm5lc10gUmVnYXJkaW5nIHRoZSB0d28gcXVlc3Rpb25zOiBJdCBjYW5ub3QgYW5kIGl0 IHdhcyBuZXZlciB0aGUgaW50ZW50aW9uIG9mIHRoaXMgd29yay4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I YW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpEZW5pczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldCBtZSB0cnkgdG8g anVtcCBpbiBoZXJlIGluIG9yZGVyIHRvIG1ha2UgYSBwcm9wb3NhbCBmb3IgdGhlIHRleHQgaW4g dGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbiBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5GUk9NOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4t and0LTA0I3NlY3Rpb24tNiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj42PC9zcGFu PjwvYj48L2E+PGEgbmFtZT0ic2VjdGlvbi02Ij48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7 LHNlcmlmIj4uJm5ic3A7DQogUHJpdmFjeSBDb25zaWRlcmF0aW9uczwvc3Bhbj48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsm bmJzcDsgQXMgSldUIGFjY2VzcyB0b2tlbnMgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0 IG5vdyBiZWNvbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgcG9zc2libGUgZm9yIHJl cXVlc3RvcnMgYW5kIHJlY2VpdmVycyB0byBkaXJlY3RseSBwZWVrIGluc2lkZSB0aGU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyB0b2tlbiBjbGFpbXMgY29sbGVjdGlvbi4mbmJzcDsgVGhl IGNsaWVudCBNVVNUIE5PVCBpbnNwZWN0IHRoZSBjb250ZW50IG9mPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsgdGhlIGFjY2VzcyB0b2tlbjogdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCB0aGUgcmVzb3VyY2Ugc2VydmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgbWlnaHQg ZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUgKGZvciBleGFtcGxlIGJ5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJs YWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgc3dpdGNoaW5nIGZyb20gdGhpcyBwcm9maWxl IHRvIG9wYXF1ZSB0b2tlbnMpIGhlbmNlIGFueSBsb2dpYyBpbiB0aGU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyBjbGllbnQgcmVseWluZyBvbiB0aGUgYWJpbGl0eSB0byByZWFkIHRoZSBh Y2Nlc3MgdG9rZW4gY29udGVudCB3b3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IGJy ZWFrIHdpdGhvdXQgcmVjb3Vyc2UuJm5ic3A7IE5vbmV0aGVsZXNzLCBhdXRob3JpemF0aW9uIHNl cnZlcnMgc2hvdWxkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgbm90IGFzc3VtZSB0aGF0 IGNsaWVudHMgd2lsbCBjb21wbHkgd2l0aCB0aGUgYWJvdmUuJm5ic3A7IFdoZW5ldmVyIGNsaWVu dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpi bGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IGFjY2VzcyB0byB0aGUgYWNjZXNzIHRva2Vu IGNvbnRlbnQgcHJlc2VudHMgcHJpdmFjeSBpc3N1ZXMgZm9yIGE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyBnaXZlbiBzY2VuYXJpbywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3Vs ZCB0YWtlIGV4cGxpY2l0IHN0ZXBzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgdG8gcHJl dmVudCBpdCBhcyBkZXNjcmliZWQgYmVsb3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyBJbiBzY2VuYXJpb3MgaW4gd2hpY2ggSldUIGFjY2VzcyB0 b2tlbnMgYXJlIGFjY2Vzc2libGUgdG8gdGhlIGVuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7IHVzZXIsIGl0IHNob3VsZCBiZSBldmFsdWF0ZWQgd2hldGhlciB0aGUgaW5mb3JtYXRpb24g Y2FuIGJlIGFjY2Vzc2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgd2l0aG91dCBwcml2 YWN5IHZpb2xhdGlvbnMgKGZvciBleGFtcGxlLCBpZiBhbiBlbmQgdXNlciB3b3VsZCBzaW1wbHk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6Ymxh Y2smcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyBhY2Nlc3MgaGlzIG9yIGhlciBvd24gcGVyc29u YWwgaW5mb3JtYXRpb24pIG9yIGlmIHN0ZXBzIG11c3QgYmUgdGFrZW48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyB0byBlbmZvcmNlIGNvZmlkZW50aWFsaXR5LiZuYnNwOyBQb3NzaWJsZSBt ZWFzdXJlcyBpbmNsdWRlOiBlbmNyeXB0aW5nIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7IGFjY2VzcyB0b2tlbiwgZW5jcnlwdGluZyB0aGUgc2Vuc2l0aXZlIGNsYWltcywgb21pdHRp bmcgdGhlIHNlbnNpdGl2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IGNsYWltcyBvciBu b3QgdXNpbmcgdGhpcyBwcm9maWxlLCBmYWxsaW5nIGJhY2sgb24gb3BhcXVlIGFjY2Vzczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IHRva2Vucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFj ayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IEluIGV2ZXJ5IHNjZW5hcmlvLCB0aGUgY29udGVu dCBvZiB0aGUgSldUIGFjY2VzcyB0b2tlbiB3aWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJz cDsgZXZlbnR1YWxseSBiZSBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7 IEl0J3MgaW1wb3J0YW50IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgZXZhbHVhdGUg d2hldGhlciB0aGUgcmVzb3VyY2Ugc2VydmVyIGdhaW5lZCB0aGUgcHJvcGVyIGVudGl0bGVtZW50 IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9y OmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgaGF2ZSBhY2Nlc3MgdG8gYW55IGNvbnRl bnQgcmVjZWl2ZWQgaW4gZm9ybSBvZiBjbGFpbXMsIGZvciBleGFtcGxlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsgdGhyb3VnaCB1c2VyIGNvbnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2ll cyBhbmQgYWdyZWVtZW50cyB3aXRoIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IG9y Z2FuaXphdGlvbiBydW5uaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMsIGFuZCBzbyBvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRPOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNCNzZWN0 aW9uLTYiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Njwvc3Bhbj48L2E+LiZuYnNwOw0KIFBy aXZhY3kgQ29uc2lkZXJhdGlvbnM8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgVGhl IGRlc2lnbiBvZiBPQXV0aCAyLjAgZW52aXNpb25zIHRoYXQgYWNjZXNzIHRva2VucyBhcmUgY3Jl YXRlZCBieQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg O2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDthdXRob3JpemF0aW9u IHNlcnZlcnMgYW5kIGNvbnN1bWVkIGJ5IHJlc291cmNlIHNlcnZlcnMuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwO0FzIEpXVCBhY2Nlc3MgdG9rZW5zLCBhcyBkZXNjcmliZWQg aW4gdGhpcyBkb2N1bWVudCwgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0IGlzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgcG9zc2libGUgZm9yIE9BdXRoIGNsaWVudHMgdG8gcGVl ayBpbnNpZGUgdGhlIGFjY2VzcyB0b2tlbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7V2hpbGUgdGhpcyBpcyB0ZWNobmljYWwgcG9zc2libGUsIGl0IGlzIGltcG9ydGFudCB0 byBub3RlIHRoYXQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgT0F1dGggMi4wIHBy b3RvY29sIGRvZXMgbm90IGFpbSB0byBleHBvc2UgdGhlIGNvbnRlbnQgb2YgdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7 LHNlcmlmIj4mbmJzcDsmbmJzcDsgYWNjZXNzIHRva2VuIHRvIHRoZSBjbGllbnQuIFRoZSBhY2Nl c3MgdG9rZW4gaXMgdGhlcmVmb3JlLCBieSBkZXNpZ24sIGNvbnNpZGVyZWQgdG8gYmUNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b3BhcXVlIHRvIHRoZSBjbGllbnQuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2sm cXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IEEgbnVtYmVy IG9mIGNhc2VzIG1heSBtYWtlIGl0IGRpZmZpY3VsdCBvciBpbXBvc3NpYmxlIGZvciBjbGllbnRz IHRvDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29s b3I6YmxhY2smcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwO2luc3BlY3QgdGhlIHRva2Vu LCBmb3IgZXhhbXBsZSwgdGhlIGFjY2VzcyB0b2tlbiBtYXkgYmUgZW5jcnlwdGVkLA0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgYWNjZXNzIHRva2VuIG1heSBjb250YWlu IHZlbmRvci1zcGVjaWZpYyBjbGFpbXMgdGhhdCBoYXZlIG5vdCBiZWVuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwO3N0YW5kYXJkaXplZCBvciBoYXZlIGJlZW4gc3RhbmRhcmRp emVkIGluIG90aGVyIGNvbnNvcnRpYSBtYWtpbmcgcGFyc2luZw0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDtvZiB0aGUgdG9rZW4gZGlmZmljdWx0LiBBZGRpdGlvbmFsbHksIHRo ZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDthY2Nlc3MgdG9rZW4gaXMgY29udmV5ZWQgYnkgdmFsdWUgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7 IG1heSBjaGFuZ2UgdGhlIHRva2VuIGZvcm1hdCBhdCBhbnkgdGltZS4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg O2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgSW4gc2NlbmFyaW9zIHdoZXJl IGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlIGNsaWVudHMgdG8gb2J0YWluIGluZm9ybWF0aW9uDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6Ymxh Y2smcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwO3RyYW5zbWl0dGVkIGluIHRoZSBhY2Nl c3MgdG9rZW4sIE9BdXRoIDIuMCB0b2tlbiBpbnRyb3NwZWN0aW9uIG1heSBwcm92aWRlDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2sm cXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwO2EgdXNlZnVsIHRvb2wgdG8gZW5hYmxlIHN1 Y2ggZnVuY3Rpb25hbGl0eSAocHJvcGVyIGF1dGhvcml6YXRpb24gYXNzdW1lZCkuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVv dDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4gc2Nl bmFyaW9zIHdoZXJlIHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4gbXVzdCBub3QgYmUg cmVhZGFibGUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YnkgY2xpZW50cywg ZW5jcnlwdGluZyB0aGUgY29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuIGlzIFJFQ09NTUVOREVE Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpi bGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwO1NpbmNlIHRoZSBjb250ZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYWNjZXNz aWJsZSB0byB0aGUgcmVzb3VyY2Ugc2VydmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsg aXQgaXMgaW1wb3J0YW50IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgZXZhbHVhdGUg d2hldGhlciB0aGUgcmVzb3VyY2Ugc2VydmVyIGdhaW5lZCB0aGUgcHJvcGVyIGVudGl0bGVtZW50 IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9y OmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgaGF2ZSBhY2Nlc3MgdG8gYW55IGNvbnRl bnQgcmVjZWl2ZWQgaW4gZm9ybSBvZiBjbGFpbXMsIGZvciBleGFtcGxlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsgdGhyb3VnaCB1c2VyIGNvbnNlbnQgaW4gc29tZSBmb3JtLCBwb2xpY2ll cyBhbmQgYWdyZWVtZW50cyB3aXRoIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IG9y Z2FuaXphdGlvbiBydW5uaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMsIGFuZCBzbyBvbi4g VGhlIHBvbGljaWVzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyA7Y29sb3I6YmxhY2smcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwO2FuZCB0aGUg dXNlciBpbnRlcmZhY2VzIHRvIGVuYWJsZSB0aGlzIHVzZXIgY29uc2VudCBhcmUsIGhvd2V2ZXIs IHBhcnQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtj b2xvcjpibGFjayZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgYSBzcGVjaWZpYyBk ZXBsb3ltZW50IGFuZCB0aGVyZWZvcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgZG9lcyB0aGlzIHNvdW5kPyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFu bmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggPGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPiZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3Jn Jmd0OzwvYT4NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMTQsIDIwMjAgODowMyBQTTxicj4NCjxiPlRvOjwvYj4g RGVuaXMgPGEgaHJlZj0ibWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mciI+Jmx0O2RlbmlzLmlldGZA ZnJlZS5mciZndDs8L2E+PGJyPg0KPGI+Q2M6PC9iPiBWaXR0b3JpbyBCZXJ0b2NjaSA8YSBocmVm PSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIj4mbHQ7dml0dG9yaW8uYmVydG9j Y2lAYXV0aDAuY29tJmd0OzwvYT47DQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTZWNv bmQgV0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAy LjAgQWNjZXNzIFRva2VucyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EZW5pcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PllvdSBhcmUgcmVoYXNoaW5nIHRoZSBzYW1lIGlzc3VlcyB0aGF0IHlvdSBoYXZlIGFscmVhZHkg ZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgbXVsdGlwbGUgdGltZXMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgY291bGQgbm90IGdl dCB0aGUgV0cgdG8gYWdyZWUgd2l0aCB5b3VyIHBvaW50cywgYmVjYXVzZSB0aGUgV0cgYmVsaWV2 ZSZuYnNwO3RoYXQgdGhpcyBpc3N1ZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgYmVzdCB0aGUgY2hhaXJzIGNhbiBkbyBhdCB0aGlzIHN0YWdlIGlzIHRvIGNhcHR1cmUg eW91ciBwb2ludCBpbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXAgdG8gdGhlIElFU0cuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB0aGluayB0aGlz IGRvY3VtZW50IGhhcyB0aGUgc3VwcG9ydCBvZiB0aGUgV0cgYW5kIGlzIHJlYWR5IHRvIG1vdmUm bmJzcDtmb3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXkgMTQsIDIwMjAgYXQgMTI6Mjkg UE0gRGVuaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkZW5pcy5pZXRmQGZyZWUuZnIiPmRlbmlzLmll dGZAZnJlZS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVml0dG9yaW8sPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIHJlZmVycmluZyB0byB0aGUgZW1haWwg eW91IHNlbnQgb24gQXByaWwgdGhlIDI5IHRoIHdoaWNoIGlzIGNvcGllZCBiZWxvdy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4xKSBZ b3Ugd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHRhcmdldGluZyBvZiBhY2Nlc3MgdG9rZW5zPC9zcGFuPjwv aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkxldCBtZSB0aGluayBhYm91 dCB0aGF0IGEgYml0IGxvbmdlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkkgYWNrbm93bGVkZ2UgdGhhdCB0aGUgZGVjaXNpb24gb2YgaW5jbHVkaW5nIGFuIGF1ZGll bmNlIGhhcyB0aGUgZWZmZWN0IG9mIGxldHRpbmcgdGhlIEFTIHRyYWNrIHdoZW4gdGhlIGNsaWVu dCBhY2Nlc3NlcyBhIHBhcnRpY3VsYXIgcmVzb3VyY2UsDQo8YnI+DQpidXQgYXQgdGhlIHNhbWUg dGltZSB0aGF04oCZcyBjb21wbGV0ZWx5IG1haW5zdHJlYW0gYW5kIHZlcnkgbXVjaCBieSBkZXNp Z24gaW4gYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBjYXNlcy4gQXMgc3VjaCwgSSBmaW5kIHRoZSBs YW5ndWFnZQ0KPGJyPg0KeW91IGFyZSBzdWdnZXN0aW5nIHRvIGJlIHBvdGVudGlhbGx5IGNvbmZ1 c2luZywgYXMgaXQgcG9zaXRpb25zIHRoaXMgYXMgYW4gZXhjZXB0aW9uIHZzIGEgcHJpdmFjeSBw cm90ZWN0aW5nIG1haW5zdHJlYW0gdGhhdCBpcyBpbiBmYWN0IG5vdCBjb21tb24sDQo8YnI+DQph bmQgYXNjcmliZXMgdG8gdGhlIGNsaWVudCBtb3JlIGxhdGl0dWRlIHRoYW4gSSBiZWxpZXZlIGlz IGxlZ2l0aW1hdGUgdG8gZXhwZWN0IG9yIGdyYW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5J4oCZbGwgdHJ5IHRvIGNvbWUgdXAgd2l0aCBjb25jaXNlIGxh bmd1YWdlIHRoYXQgY2xhcmlmaWVzIHRvIHRoZSByZWFkZXIgdGhhdCB0aGUgY3VycmVudCBtZWNo YW5pc20gZG9lcyBhbGxvdyBBUyB0cmFja2luZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi4gJm5ic3A7DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TaW5jZSB0aGUgbGFzdCBkcmFmdCBoYXMgYmVlbiBwdWJsaXNoZWQgb24gdGhlIDI3 IHRoLCB5b3UgaGF2ZSBub3QgcHJvcG9zZWQgYW55ICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpi bHVlIj5jb25jaXNlIGxhbmd1YWdlIHRoYXQgY2xhcmlmaWVzIHRvIHRoZSByZWFkZXINCjxicj4N CnRoYXQgdGhlIGN1cnJlbnQgbWVjaGFuaXNtIGRvZXMgYWxsb3cgQVMgdHJhY2tpbmc8L3NwYW4+ JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yKSBZb3UgYWxzbyB3cm90ZSBhYm91dCB0aGUgJnF1b3Q7c3ViJnF1b3Q7IHVuaXF1ZW5l c3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIGxvbmcgYXMgYW4gaWRlbnRpZmllciBpZGVudGlmaWVzIG9uZSByZXNvdXJjZSBvbmx5LCBp dCBzYXRpc2ZpZXMgdW5pcXVlbmVzcy4gSXQgZG9lc27igJl0IGhhdmUgdG8gYmUgYSBzaW5nbGV0 b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SRkMgNzUxOSBkZWZpbmVzIGluIHNlY3Rpb24gNC4xLjIgdGhlIHNlbWFu dGljcyBvZiB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNsYWltIHVzaW5nIHRoZSBmb2xsb3dpbmcgc2Vu dGVuY2U6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzdWJqZWN0 IHZhbHVlIE1VU1QgZWl0aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUg Y29udGV4dCBvZiB0aGUgaXNzdWVyIG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSB0ZXh0IGRvZXMgTk9UIHNheSB0aGF0IHRoZSBzdWJqZWN0IHZhbHVlICZxdW90O01VU1QgYmUg c2NvcGVkIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZQ0KPGI+cmVz b3VyY2Ugc2VydmVyPC9iPiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgYW4gYWxyZWFkeSBk ZWZpbmVkIGNsYWltIGlzIG5vdCBwZXJtaXR0ZWQuIElmIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUg c3VjaCBhIHNlbWFudGljcyBhdmFpbGFibGUsDQo8YnI+DQphIG5ldyBjbGFpbSBzaG91bGQgYmUg ZGVmaW5lZCAoYW5kIGl0IHdvdWxkIGJlIHZlcnkgbmljZSB0byBoYXZlIGl0ICEpLiA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgVGhlIHRl eHQgaXMgdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyBBbHRob3VnaCB0aGUgYWJpbGl0eSB0byBjb3JyZWxhdGUgcmVxdWVzdHMgbWlnaHQgYmUgcmVx dWlyZWQgYnkgZGVzaWduIGluIG1hbnkgc2NlbmFyaW9zLCB0aGVyZSBhcmUgc2NlbmFyaW9zIHdo ZXJlIHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7IHNlcnZlciBtaWdodCB3YW50 IHRvIHByZXZlbnQgY29ycmVsYXRpb24gdG8gcHJlc2VydmUgdGhlIGRlc2lyZWQgbGV2ZWwgb2Yg cHJpdmFjeS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiB0aGUgcmVhbCB3b3JsZCwgaXQgaXMgYWxzbyBjbGllbnRzIG9yIGVuZC11c2Vy cyB3aGljaCB3b3VsZCBsaWtlIHRvIHByZXZlbnQgY29ycmVsYXRpb24gdG8gcHJlc2VydmUgdGhl aXIgZGVzaXJlZCBsZXZlbCBvZiBwcml2YWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGJldHRlciBzZW50ZW5jZSB3b3VsZCBiZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBBbHRob3VnaCB0aGUgYWJpbGl0eSB0byBjb3JyZWxhdGUgcmVxdWVzdHMg bWlnaHQgYmUgcmVxdWlyZWQgYnkgZGVzaWduIGluIG1hbnkgc2NlbmFyaW9zLCB0aGVyZSBhcmUg c2NlbmFyaW9zIHdoZXJlIHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7IHNlcnZl ciA8Yj5vciB0aGUgY2xpZW50PC9iPiBtaWdodCB3YW50IHRvIHByZXZlbnQgY29ycmVsYXRpb24g dG8gcHJlc2VydmUgdGhlIGRlc2lyZWQgbGV2ZWwgb2YgcHJpdmFjeS4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQpIFRoZSB0 ZXh0IGNvbnRpbnVlcyB3aXRoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3Vs ZCBjaG9vc2UgaG93IHRvIGFzc2lnbiAmcXVvdDtzdWImcXVvdDsgdmFsdWVzIGFjY29yZGluZyB0 byB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCBieSBlYWNoPGJyPg0KJm5ic3A7Jm5ic3A7 IHNpdHVhdGlvbi4mbmJzcDsgRm9yIGluc3RhbmNlOiBpZiBhIHNvbHV0aW9uIHJlcXVpcmVzIHBy ZXZlbnRpbmcgdHJhY2tpbmcmbmJzcDsgcHJpbmNpcGFsIGFjdGl2aXRpZXMgYWNyb3NzIG11bHRp cGxlIHJlc291cmNlIHNlcnZlcnMsDQo8YnI+DQombmJzcDsmbmJzcDsgdGhlJm5ic3A7IGF1dGhv cml6YXRpb24gc2VydmVyIHNob3VsZCBlbnN1cmUgdGhhdCBKV1QgYWNjZXNzIHRva2VucyBtZWFu dCBmb3IgZGlmZmVyZW50IHJlc291cmNlIHNlcnZlcnMgaGF2ZSBkaXN0aW5jdCAmcXVvdDtzdWIm cXVvdDsNCjxicj4NCiZuYnNwOyZuYnNwOyB2YWx1ZXMgdGhhdCBjYW5ub3QgYmUgY29ycmVsYXRl ZCBpbiB0aGUgZXZlbnQgb2YgcmVzb3VyY2Ugc2VydmVycyBjb2xsdXNpb24uJm5ic3A7IDxvOnA+ DQo8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhv cml6YXRpb24gc2VydmVycyBhcmUgbm90IG5lY2Vzc2FyaWx5IGFibGUgdG8gY2hvb3NlIHRoZSBs ZXZlbCBvZiBwcml2YWN5IHJlcXVpcmVkIGJ5IGVhY2ggc2l0dWF0aW9uLiBXaGVuIHRoZXJlIGFy ZSBkaWZmZXJlbnQNCjxicj4NCnNpdHVhdGlvbnMgZm9yIHRoZSBzYW1lIHJlc291cmNlIHNlcnZl ciwgdGhlIHNjb3BlIGlzICh1bmZvcnR1bmF0ZWx5IGF0IHRoZSBtb21lbnQpIHRoZSBvbmx5IHdh eSB0byBzZWxlY3QgdGhlICZxdW90O2xldmVsIG9mIHByaXZhY3kgdGhhdCBpcyByZXF1aXJlZCZx dW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIGV4YW1wbGUgKCZxdW90O0ZvciBpbnN0YW5jZTomcXVvdDspIGlzIG9ubHkgYW4gZXhh bXBsZSB0aGF0IHByb3ZpZGVzIGEgdmFndWUgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBBU3Mgd2hp Y2ggaXMgTk9UIGNvbmZvcm1hbnQ8YnI+DQp3aXRoIHRoZSBzZW1hbnRpY3Mgb2YgdGhlICZxdW90 O3N1YiZxdW90OyBjbGFpbSBhcyBkZWZpbmVkIGluIFJGQyA3NTE5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHNob3VsZCBiZSBkaXNj dXNzZWQgaGVyZSBhcmUgbm90ICZxdW90O2V4YW1wbGVzJnF1b3Q7IG9yIHdoYXQgYW4gYXV0aG9y aXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGRvLCBidXQgZXhwbGFuYXRpb25zIGFib3V0IHRoZSBpbXBs aWNhdGlvbnMNCjxicj4NCmZvciB0aGUgZW5kLXVzZXIgb3IgZm9yIHRoZSBjbGllbnQgZm9yIHRo ZSB2YXJpb3VzIHZhbHVlcyB0aGF0IGNhbiBiZSBwbGFjZWQgaW50byB0aGUgJnF1b3Q7c3ViJnF1 b3Q7IGNsYWltIGJ5IGFuIEFTLiBUaGUgcHJvYmxlbSBpcyB3aWRlciB0aGF0IHNpbXBseQ0KPGJy Pg0KYSBjb2xsdXNpb24gYmV0d2VlbiByZXNvdXJjZSBzZXJ2ZXJzLCBidXQgYWxzbyB3aXRoIG90 aGVyIHNlcnZlcnMgdGhhdCBETyBOT1QgcGFydGljaXBhdGUgaW4gYW55IE9BdXRoIGV4Y2hhbmdl Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJGQyA2OTczIChQcml2YWN5IENvbnNpZGVyYXRpb25zKSBzdGF0ZXMgaW4gc2VjdGlvbiA3IDog R3VpZGVsaW5lczxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNl Y3Rpb24gcHJvdmlkZXMgZ3VpZGFuY2UgZm9yIGRvY3VtZW50IGF1dGhvcnMgaW4gdGhlIGZvcm0g b2YgYSBxdWVzdGlvbm5haXJlIGFib3V0IGEgcHJvdG9jb2wgYmVpbmcgZGVzaWduZWQuJm5ic3A7 DQo8YnI+DQpUaGUgcXVlc3Rpb25uYWlyZSBtYXkgYmUgdXNlZnVsIGF0IGFueSBwb2ludCBpbiB0 aGUgZGVzaWduIHByb2Nlc3MsIHBhcnRpY3VsYXJseSBhZnRlciBkb2N1bWVudCBhdXRob3JzIGhh dmUgZGV2ZWxvcGVkDQo8YnI+DQphIGhpZ2gtbGV2ZWwgcHJvdG9jb2wgbW9kZWwgYXMgZGVzY3Jp YmVkIGluIFtSRkM0MTAxXS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uZSBvZiB0aGUgcXVlc3Rpb25zIGlzOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5mLiZuYnNwOyA8Yj5Db3JyZWxhdGlvbjwvYj4uJm5ic3A7IERv ZXMgdGhlIHByb3RvY29sIGFsbG93IGZvciBjb3JyZWxhdGlvbiBvZiBpZGVudGlmaWVycyA/Jm5i c3A7IEFyZSB0aGVyZSBleHBlY3RlZCB3YXlzIHRoYXQgaW5mb3JtYXRpb24gZXhwb3NlZA0KPGJy Pg0KYnkgdGhlIHByb3RvY29sIHdpbGwgYmUgY29tYmluZWQgb3IgPGI+Y29ycmVsYXRlZCB3aXRo IGluZm9ybWF0aW9uIG9idGFpbmVkIG91dHNpZGUgdGhlIHByb3RvY29sPC9iPiA/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBpbXBvcnRhbnQgdG8gcHJvdmlkZSBhbiBhbnN3ZXIgdG8gdGhlc2UgdHdvIHF1ZXN0 aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVyZWFmdGVyIGlzIHNvbWUgdGV4dCB0aGF0IGlzIGZ1bGx5IGNvbmZvcm1hbnQgd2l0aCBS RkMgNzUxOSB3aGljaCBzaG91bGQgYmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIHByaXZhY3kgY29u c2lkZXJhdGlvbnMgc2VjdGlvbg0KPGJyPg0Kd2hpY2ggZXhwbGFpbnMgdGhlIGltcGxpY2F0aW9u cyBvZiB0aGUgdHdvIChhbmQgb25seSB0d28pIGZsYXZvdXJzIG9mIHRoZSAmcXVvdDtzdWImcXVv dDsgY2xhaW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoZW4gdGhlIHN1YiBjbGFpbSBjb250YWlucyBhIGxvY2FsbHkgdW5pcXVlIGlkZW50 aWZpZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciwgdGhpcyBhbGxvd3MgdGhlIHRyYWNr aW5nIG9mIHByaW5jaXBhbCBhY3Rpdml0aWVzDQo8YnI+DQphY3Jvc3MgbXVsdGlwbGUgcmVzb3Vy Y2Ugc2VydmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hlbiB0aGUgc3ViIGNsYWltIGNvbnRhaW5zIGEgZ2xvYmFsbHkgdW5pcXVlIGlk ZW50aWZpZXIsIHRoaXMgYWxsb3dzIHRvIGNvcnJlbGF0ZSBwcmluY2lwYWwgYWN0aXZpdGllcyBh Y3Jvc3MgbXVsdGlwbGUgcmVzb3VyY2UNCjxicj4NCnNlcnZlcnMsIHdoaWxlIGluIGFkZGl0aW9u LCB0aGlzIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyIG1heSBhbHNvIGFsbG93IHRvIGNvcnJl bGF0ZSB0aGUgcHJpbmNpcGFsIGFjdGl2aXRpZXMgb24gc2VydmVycyB3aGVyZQ0KPGJyPg0Kbm8g YWNjZXNzIGhhcyBiZWVuIHBlcmZvcm1lZCBieSB0aGUgcHJpbmNpcGFscyB0byB0aGVzZSBzZXJ2 ZXJzIGJ1dCB3aGVyZSB0aGUgc2FtZSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYXJlIGJl aW5nIHVzZWQNCjxicj4NCmJ5IHRoZXNlIHNlcnZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkRlbmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIERlbmlzIGZvciB0aGUgdGhvcm91Z2ggY29tbWVu dGFyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPiZndDsgVGhlIHRpdGxlIG9mIHRo aXMgc3BlYy48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZpeGVk LCB0aGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT4mZ3Q7IFRoZSBjbGllbnQg TVVTVCBOT1QgaW5zcGVjdCB0aGUgY29udGVudCBvZiB0aGUgYWNjZXNzIHRva2VuPC9pPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIHJlYWxseSBhIHN0aWNr eSBwb2ludC4gSSByZWFsbHkgd2FudCB0byBhY2tub3dsZWRnZSB5b3VyIFBvViBvbiB0aGlzLCBi dXQgYXQgdGhlIHNhbWUgdGltZSBJIGZvdW5kIHRoaXMgdG8gYmUgb25lIG9mIHRoZSBiaWdnZXN0 IHNvdXJjZXMgb2YgaXNzdWVzIGluIHRoZSB1c2Ugb2YgSldUIGZvcg0KIGFjY2VzcyB0b2tlbnMg aGVuY2UgSSBmZWVsIHdlIHJlYWxseSBuZWVkIHRvIGdpdmUgc29saWQgZ3VpZGFuY2UgaGVyZS4g TGV0IG1lIGV4cGFuZCBmdXJ0aGVyIG9uIHRoZSByZWFzb25pbmcgYmVoaW5kIGl0LCBhbmQgcGVy aGFwcyB3ZSBjYW4gZ2V0IHRvIGxhbmd1YWdlIHRoYXQgc2F0aXNmaWVzIGJvdGggUG9Wcy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gbWUgdGhlIGtleSBwb2ludCBp cyB0aGF0IGNsaWVudHMgc2hvdWxkIG5vdCB3cml0ZQ0KPGk+Y29kZTwvaT4gdGhhdCBpbnNwZWN0 cyBhY2Nlc3MgdG9rZW5zLiBUYWtpbmcgYSBkZXBlbmRlbmN5IG9uIHRoZSBhYmlsaXR5IHRvIGRv IHNvIGlzIGlnbm9yaW5nIGZ1bmRhbWVudGFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhcmNoaXRl Y3R1cmUgYW5kIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBPQXV0aCByb2xlcywgYW5kIHN1Z2dlc3Rz IGFuIGFiaWxpdHkgb2YgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpYyBvZiB0 aGUgY29udGVudA0KIHRoYXQgY2Fubm90IGJlIGFzc3VtZWQgaW4gdGhlIGdlbmVyYWwgY2FzZS4g SSBleHBhbmRlZCBvbiB0aGUgZGV0YWlscyBpbiBteSBmb3JtZXIgcmVwbHkgdG8geW91IG9uIHRo aXMgdG9waWMsIEkgd291bGQgcmVjb21tZW5kIHJlZmVycmluZyB0byBpdC4gQ2xpZW50cyB2aW9s YXRpbmcgdGhpcyBzaW1wbGUgcHJpbmNpcGxlIGhhcyBiZWVuIG9uZSBvZiB0aGUgbW9zdCBjb21t b24gc291cmNlcyBvZiBwcm9kdWN0aW9uIGlzc3VlcyBJIGhhZCB0bw0KIGRlYWwgd2l0aCBpbiB0 aGUgcGFzdCBmZXcgeWVhcnMsIGFuZCBvbmUgb2YgdGhlIGhhcmRlc3QgdG8gcmVtZWRpYXRlIGdp dmVuIHRoYXQgY2xpZW50cyBhcmUgaGFyZCB0byB1cGRhdGUgYW5kIHNvbWV0aW1lcyB0aGUgdGhp bmdzIHRoZXkgcmVsaWVkIG9uIHdlcmUgaXJyZW1lZGlhYmx5IGxvc3QuIFRoaXMgaXMgd2h5IEkg YW0gaW5jbGluZWQgdG8gcHV0IGluIGhlcmUgc3Ryb25nIGxhbmd1YWdlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IHNhaWQ6IEkgaGF2ZSBub3RoaW5nIGFnYWlu c3QgY2xpZW50IGRldmVsb3BlcnMgZXhhbWluaW5nIGEgbmV0d29yayB0cmFjZSBhbmQgZHJhd2lu ZyBjb25jbHVzaW9ucyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiB3aGF0IHRoZXkgc2VlLiBUaGF0 IGRvZXNu4oCZdCBjcmVhdGUgYW55IGhhcmQgZGVwZW5kZW5jaWVzDQogYW5kIGhhcyBubyBpbXBs aWNhdGlvbnMgaW4gcmVzcGVjdCB0byBjaGFuZ2VzIGluIHRoZSBzb2x1dGlvbiBiZWhhdmlvci4g SG93ZXZlciBJIGFtIG5vdCBzdXJlIGhvdyB0byBwaHJhc2UgdGhhdCBpbiB0aGUgc3BlY2lmaWNh dGlvbiwgZ2l2ZW4gdGhhdCByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBpbmV2aXRhYmx5IHJlZmVy cyB0byBpdHMgY29kZS4gSSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jmd0OyAmbmJzcDszKeKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGhhdmUgYSBwcmV0dHkgaGFyZCB0aW1lIGZvbGxvd2luZyB0aGUgY2hhaW4g b2YgcmVhc29uaW5nIGluIHRoaXMgc2VjdGlvbi4gTGV0IG1lIGF0dGVtcHQgdG8gdGFja2xlIGl0 IHRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlIGtleSBtaWdodCBiZSAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+Jmd0OyBhIGNsaWVudCBzaG91 bGQgYmUgYWJsZSB0byBjaG9vc2Ugd2hldGhlciBpdCB3aXNoZXMgdGhlIHN1YiBjbGFpbSB0byBj b250YWluIFsuLl08L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg ZG9u4oCZdCB0aGluayB0aGF0IHNob3VsZCBiZSBhIGNob2ljZSBsZWZ0IHRvIHRoZSBjbGllbnQu IEluIGJ1c2luZXNzIHN5c3RlbXMsIG15IGV4cGVyaWVuY2UgaXMgdGhhdCB0aGUgdHlwZSBvZiBp ZGVudGlmaWVycyB0byBiZSB1c2VkICh3aGVuIHRoZSBJZFAgZ2l2ZXMgYW55IGNob2ljZSBhdCBh bGwpICZuYnNwO2lzDQogZXN0YWJsaXNoZWQgYXQgcmVzb3VyY2UgcHJvdmlzaW9uaW5nIHRpbWUu IEkgYW0gbm90IGF3YXJlIG9mIG1lY2hhbmlzbXMgdGhydSB3aGljaCBhIGNsaWVudCBzaWduYWxz IHRoZSBuYXR1cmUgb2YgdGhlIGlkZW50aWZpZXIgdG8gYmUgdXNlZCwgbm9yIHRoYXQgd291bGQg YmUgZnVsbHkgZmVhc2libGUgKHRoZSByZXNvdXJjZSBrbm93cyB3aGF0IGl0IG5lZWRzIHRvIHBl cmZvcm0gaXRzIGZ1bmN0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+RnVydGhlcm1vcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxp PiZndDsgd2hpY2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB1bmlxdWVuZXNzIHNpbmNlIHRoZSB2 YWx1ZSBjaGFuZ2VzIGZvciBldmVyeSBnZW5lcmF0ZWQgdG9rZW4uPC9pPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZ2FpbiwgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCB3 YXMgdG91Y2hlZCBvbiBpbiBteSBmb3JtZXIgcmVwbHkgdG8geW91ciBtZXNzYWdlLiBBcyBsb25n IGFzIGFuIGlkZW50aWZpZXIgaWRlbnRpZmllcyBvbmUgcmVzb3VyY2Ugb25seSwgaXQgc2F0aXNm aWVzIHVuaXF1ZW5lc3MuIEl0IGRvZXNu4oCZdCBoYXZlDQogdG8gYmUgYSBzaW5nbGV0b24uIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GaW5hbGx5LCB0aGUgc2NvcGUg aXMgb3B0aW9uYWwgKGZvciBnb29kIHJlYXNvbnM6IDE8c3VwPnN0PC9zdXA+IHBhcnR5IGFuZCBu b24gZGVsZWdhdGlvbiBzY2VuYXJpb3MgZG9u4oCZdCByZXF1aXJlIGl0KSBoZW5jZSBpdCBjYW5u b3QgYmUgcmVsaWVkIHVwb24gZm9yIHByb3BlcnRpZXMgdGhhdCBzaG91bGQgaG9sZA0KIGluIGV2 ZXJ5IHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBz dW1tYXJ5OiBwZXIgdGhlIHByZWNlZGluZyB0aHJlYWQgb24gdGhpcyB0b3BpYywgdGhlIGNvbnNl bnN1cyB3YXMgdGhhdCB2YXJ5aW5nIHRoZSBzdWIgY29udGVudCB3YXMgYSBzYXRpc2ZhY3Rvcnkg d2F5IG9mIHByb3RlY3RpbmcgYWdhaW5zdCBjb3JyZWxhdGlvbi4gSSBkb27igJl0IGEgZ3JlZSB0 aGF0DQogY2xpZW50cyBzaG91bGQgaGF2ZSBhIG1lY2hhbmlzbSB0byByZXF1ZXN0IGRpZmZlcmVu dCBzdWIgZmxhdm9ycywgYXMgdGhhdCBkZWNpc2lvbiBzaG91bGQgYmUgZG9uZSBvdXQgb2YgYmFu ZCBieSB0aGUgQVMgYW5kIFJTOyBhbmQgdGhlIHNjb3BlIGlzbuKAmXQgYWx3YXlzIGF2YWlsYWJs ZSBhbnl3YXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPiZndDsg dGFyZ2V0aW5nIG9mIGFjY2VzcyB0b2tlbnM8L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkxldCBtZSB0aGluayBhYm91dCB0aGF0IGEgYml0IGxvbmdlci4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFja25vd2xlZGdlIHRoYXQgdGhl IGRlY2lzaW9uIG9mIGluY2x1ZGluZyBhbiBhdWRpZW5jZSBoYXMgdGhlIGVmZmVjdCBvZiBsZXR0 aW5nIHRoZSBBUyB0cmFjayB3aGVuIHRoZSBjbGllbnQgYWNjZXNzZXMgYSBwYXJ0aWN1bGFyIHJl c291cmNlLCBidXQgYXQgdGhlIHNhbWUgdGltZSB0aGF04oCZcyBjb21wbGV0ZWx5DQogbWFpbnN0 cmVhbSBhbmQgdmVyeSBtdWNoIGJ5IGRlc2lnbiBpbiBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIGNh c2VzLiBBcyBzdWNoLCBJIGZpbmQgdGhlIGxhbmd1YWdlIHlvdSBhcmUgc3VnZ2VzdGluZyB0byBi ZSBwb3RlbnRpYWxseSBjb25mdXNpbmcsIGFzIGl0IHBvc2l0aW9ucyB0aGlzIGFzIGFuIGV4Y2Vw dGlvbiB2cyBhIHByaXZhY3kgcHJvdGVjdGluZyBtYWluc3RyZWFtIHRoYXQgaXMgaW4gZmFjdCBu b3QgY29tbW9uLCBhbmQgYXNjcmliZXMNCiB0byB0aGUgY2xpZW50IG1vcmUgbGF0aXR1ZGUgdGhh biBJIGJlbGlldmUgaXMgbGVnaXRpbWF0ZSB0byBleHBlY3Qgb3IgZ3JhbnQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlsbCB0cnkgdG8gY29tZSB1cCB3aXRoIGNv bmNpc2UgbGFuZ3VhZ2UgdGhhdCBjbGFyaWZpZXMgdG8gdGhlIHJlYWRlciB0aGF0IHRoZSBjdXJy ZW50IG1lY2hhbmlzbSBkb2VzIGFsbG93IEFTIHRyYWNraW5nLiAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggPGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtvYXV0 aC1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT4gb24gYmVoYWxmIG9mIERlbmlzIDxhIGhyZWY9Im1h aWx0bzpkZW5pcy5pZXRmQGZyZWUuZnIiIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtkZW5pcy5pZXRm QGZyZWUuZnImZ3Q7PC9hPjxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDI5LCAy MDIwIGF0IDA5OjEyPGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj4mcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OzwvYT4gPGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQombHQ7b2F1dGhAaWV0 Zi5vcmcmZ3Q7PC9hPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBTZWNvbmQg V0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAg QWNjZXNzIFRva2VucyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSB3aWxsIGZpbmQgZm91ciBjb21tZW50cyBu dW1iZXJlZCAxKSB0byA0KS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj4xKQ0KPC9iPlRoZSB0aXRsZSBvZiB0aGlzIHNwZWMuIGlzOjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXIiPkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoDQo8Yj4yLjA8L2I+IEFj Y2VzcyBUb2tlbnM8L3NwYW4+PGJyPg0KPGJyPg0KU28sIHRoaXMgc3BlYy4gaXMgc3VwcG9zZWQg dG8gYmUgdGFyZ2V0ZWQgdG8gT0F1dGggPGI+Mi4wLiA8L2I+Jm5ic3A7SG93ZXZlciwgdGhlIGhl YWRlciBhdCB0aGUgdG9wIG9mIHRoZSBwYWdlIG9taXRzIHRvIG1lbnRpb24gaXQuDQo8YnI+DQo8 YnI+DQpDdXJyZW50bHksIGl0IGlzIDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgT0F1dGggQWNjZXNzIFRva2VuIEpXVCBQcm9maWxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFwcmlsIDIwMjA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgc2hvdWxkIHJhdGhlciBiZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW50ZXJuZXQtRHJhZnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGgNCjxiPjIuMDwvYj4gQWNjZXNzIFRv a2VuIEpXVCBQcm9maWxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFwcmlsIDIwMjA8YnI+DQo8YnI+DQo8Yj4yKTwvYj4gVGhlIGZv bGxvd2luZyB0ZXh0IGlzIHdpdGhpbiBzZWN0aW9uIDYuPGJyPg0KPGJyPg0KVGhlIGNsaWVudCBN VVNUIE5PVCBpbnNwZWN0IHRoZSBjb250ZW50IG9mPGJyPg0KdGhlIGFjY2VzcyB0b2tlbjogdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyPGJyPg0KbWlnaHQg ZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUgKGZvciBleGFtcGxlIGJ5 PGJyPg0Kc3dpdGNoaW5nIGZyb20gdGhpcyBwcm9maWxlIHRvIG9wYXF1ZSB0b2tlbnMpIGhlbmNl IGFueSBsb2dpYyBpbiB0aGU8YnI+DQpjbGllbnQgcmVseWluZyBvbiB0aGUgYWJpbGl0eSB0byBy ZWFkIHRoZSBhY2Nlc3MgdG9rZW4gY29udGVudCB3b3VsZDxicj4NCmJyZWFrIHdpdGhvdXQgcmVj b3Vyc2UuPGJyPg0KTm9uZXRoZWxlc3MsIGF1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQ8YnI+ DQpub3QgYXNzdW1lIHRoYXQgY2xpZW50cyB3aWxsIGNvbXBseSB3aXRoIHRoZSBhYm92ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgaXMgb2YgYSBwcmltYXJ5IGlt cG9ydGFuY2UgdGhhdCBjbGllbnRzIE1BWSBiZSBhYmxlIHRvIGluc3BlY3QgdG9rZW5zIGJlZm9y ZSB0cmFuc21pdHRpbmcgdGhlbS48YnI+DQpUaGUgJnF1b3Q7TVVTVCBOT1QmcXVvdDsgaXMgbm90 IGFjY2VwdGFibGUuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg YWJvdmUgdGV4dCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aDo8YnI+DQo8YnI+DQpSZWFkaW5nIHRo ZSBhY2Nlc3MgdG9rZW4gY29udGVudCBtYXkgYmUgdXNlZnVsIGZvciB0aGUgdXNlciB0byB2ZXJp ZnkgdGhhdCA8YnI+DQp0aGUgYWNjZXNzIHRva2VuIGNvbnRlbnQgbWF0Y2hlcyB3aXRoIGl0cyBl eHBlY3RhdGlvbnMuJm5ic3A7IEhvd2V2ZXIsIDxicj4NCnRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBhbmQgdGhlIHJlc291cmNlIHNlcnZlciBtaWdodCBkZWNpZGUgdG8gY2hhbmdlIHRoZSA8YnI+ DQp0b2tlbiBmb3JtYXQgYXQgYW55IHRpbWUuJm5ic3A7IFRodXMsIHRoZSBjbGllbnQgc2hvdWxk IG5vdCBleHBlY3QgdG8gYWx3YXlzIGJlIDxicj4NCmluIGEgcG9zaXRpb24gdG8gcmVhZCB0aGUg YWNjZXNzIHRva2VuIGNvbnRlbnQuPGJyPg0KPGJyPg0KVGhlIHJlbWFpbmluZyBvZiB0aGUgdGV4 dCBhYm91dCB0aGlzIHRvcGljIGlzIGZpbmUuPGJyPg0KPGJyPg0KPGJyPg0KPGI+MykgPC9iPlRo ZSBuZXh0IHRvcGljIGlzIGFib3V0IHRoZSBzdWIgY2xhaW0uPGJyPg0KPGJyPg0KVGhlIHRleHQg c3RhdGVzOjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvdXJpZXIiPkFsdGhvdWdoIHRoZSBhYmlsaXR5IHRvIGNvcnJlbGF0ZSByZXF1ZXN0cyBt aWdodCBiZSByZXF1aXJlZCBieTxicj4NCmRlc2lnbiBpbiBtYW55IHNjZW5hcmlvcywgdGhlcmUg YXJlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbjxicj4NCnNlcnZlciBtaWdodCB3 YW50IHRvIHByZXZlbnQgY29ycmVsYXRpb24gdG8gcHJlc2VydmUgdGhlIGRlc2lyZWQ8YnI+DQps ZXZlbCBvZiBwcml2YWN5LiBBdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIGNob29zZSBob3cg dG8gYXNzaWduPGJyPg0Kc3ViIHZhbHVlcyBhY2NvcmRpbmcgdG8gdGhlIGxldmVsIG9mIHByaXZh Y3kgcmVxdWlyZWQgYnkgZWFjaDxicj4NCnNpdHVhdGlvbi48L3NwYW4+PGJyPg0KPGJyPg0KSSBo YXZlIGEgc2V0IG9mIHF1ZXN0aW9uczogPG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5 cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvNCI+ DQpIb3cgY2FuIGF1dGhvcml6YXRpb24gc2VydmVycyBjaG9vc2UgaG93IHRvIGFzc2lnbiBzdWIg dmFsdWVzIGFjY29yZGluZyB0byB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAmcXVvdDti eSBlYWNoIHNpdHVhdGlvbiZxdW90OyA/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzQiPg0KSG93IGNhbiBhdXRob3JpemF0aW9uIHNl cnZlcnMga25vdyB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAmcXVvdDtieSBlYWNoIHNp dHVhdGlvbiZxdW90OyA/DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsNCBsZXZlbDEgbGZvNCI+DQpIb3cgY2FuIHRoZSB1c2VycyBiZSBpbmZvcm1lZCBv ZiB0aGUgbGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAmcXVvdDtieSBlYWNoIHNpdHVhdGlvbiZx dW90OyA/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQg bGV2ZWwxIGxmbzQiPg0KSG93IGNhbiB0aGUgdXNlcnMgPGI+Y29uc2VudDwvYj4gd2l0aCB0aGUg bGV2ZWwgb2YgcHJpdmFjeSByZXF1aXJlZCAmcXVvdDtieSBlYWNoIHNpdHVhdGlvbiZxdW90OyA/ PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkN1cnJlbnRseSwg dGhlIHJlcXVlc3QgTVVTVCBpbmNsdWRlIGVpdGhlciBhIHJlc291cmNlIHBhcmFtZXRlciBvciBh biBhdWQgY2xhaW0gcGFyYW1ldGVyLCB3aGlsZSBpdCBNQVkgaW5jbHVkZSBhIHNjb3BlIHBhcmFt ZXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHN5bnRheCBv ZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGEgbGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNhc2Ut c2Vuc2l0aXZlIHN0cmluZ3MgKFJGQyA2NzQ5KS4gSXQgaXMgdGh1cyBzdWJqZWN0IHRvIHByaXZh dGUgYWdyZWVtZW50cw0KPGJyPg0KYmV0d2VlbiBjbGllbnRzIGFuZCBBdXRob3JpemF0aW9uIFNl cnZlcnMuIFNpbmNlIHRoZSBzY29wZSBpcyBiZWluZyByZXR1cm5lZCwgaXQgaXMgYSBwcmltYXJ5 IGltcG9ydGFuY2UgdGhhdCB0aGUgcmV0dXJuZWQgc2NvcGUgbWF0Y2hlcw0KPGJyPg0Kd2l0aCBp dHMgZXhwZWN0YXRpb25zIGJlZm9yZSB0cmFuc21pdHRpbmcgdGhlIHRva2VuIHRvIGEgUmVzb3Vy Y2UgU2VydmVyLjxicj4NCjxicj4NCkluIHRoZW9yeSwgYSBjbGllbnQgc2hvdWxkIGJlIGFibGUg dG8gY2hvb3NlIHdoZXRoZXIgaXQgd2lzaGVzIHRoZSBzdWIgY2xhaW0gdG8gY29udGFpbiA6PG86 cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm83Ij4NCmEgZ2xvYmFsIHVuaXF1ZSBpZGVudGlmaWVyIGZvciBh bGwgQVNzICgmcXVvdDtnbG9iYWxseSB1bmlxdWUmcXVvdDspLDxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm83Ij4NCmEgdW5pcXVlIGlk ZW50aWZpZXIgZm9yIGVhY2ggQVMgKCZxdW90O2xvY2FsbHkgdW5pcXVlIGluIHRoZSBjb250ZXh0 IG9mIHRoZSBpc3N1ZXImcXVvdDspLDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm83Ij4NCmEgZGlmZmVyZW50IHBzZXVkb255bSBmb3Ig ZWFjaCBSUywgb3IgPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzciPg0KYSBkaWZmZXJlbnQgcHNldWRvbnltIGZvciBlYWNoIGF1dGhv cml6YXRpb24gdG9rZW4gcmVxdWVzdC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIG9ubHkgdmFyaWFibGUgcGFyYW1ldGVyIHRoYXQgaXQgY2FuIHVzZSBm b3IgdGhpcyBwdXJwb3NlIGluIHRoZSB0b2tlbiByZXF1ZXN0IGlzIHRoZSBzY29wZSBwYXJhbWV0 ZXIuPGJyPg0KPGJyPg0KUkZDIDc1MTkgc3RhdGVzIGlzIHNlY3Rpb24gNC4xLjI6PGJyPg0KPGJy Pg0KVDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aGUg c3ViamVjdCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBzY29wZWQgdG8gYmUgbG9jYWxseSB1bmlxdWUg aW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3Vlcg0KPGJyPg0Kb3IgYmUgZ2xvYmFsbHkgdW5pcXVl Ljxicj4NCjwvc3Bhbj48YnI+DQpJdCBpcyBxdWl0ZSBoYXJkIHRvIHJlY29nbml6ZSB0aGF0IHRo ZSBzdWIgY2xhaW0gaXMgYWJsZSB0byBjYXJyeSBhIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVh Y2ggUlMsIGkuZS4gZm9yIGNhc2UgKGMpLCBvcg0KPGJyPg0KYSBkaWZmZXJlbnQgcHNldWRvbnlt IGZvciBlYWNoIGF1dGhvcml6YXRpb24gdG9rZW4gcmVxdWVzdCwgaS5lLiBmb3IgY2FzZSAoZCks IHdoaWNoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdW5pcXVlbmVzcw0KPGJyPg0Kc2luY2UgdGhl IHZhbHVlIGNoYW5nZXMgZm9yIGV2ZXJ5IGdlbmVyYXRlZCB0b2tlbi48YnI+DQo8YnI+DQpUaGlz IGhhcyBpbXBsaWNhdGlvbnMgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Ojxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkZvciBpbnN0 YW5jZTogaWYgYSBzb2x1dGlvbiByZXF1aXJlcyBwcmV2ZW50aW5nIHRyYWNraW5nPGJyPg0KcHJp bmNpcGFsIGFjdGl2aXRpZXMgYWNyb3NzIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMsIHRoZTxi cj4NCmF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBlbnN1cmUgdGhhdCBKV1QgYWNjZXNzIHRv a2VucyBtZWFudCBmb3I8YnI+DQpkaWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVycyBoYXZlIGRpc3Rp bmN0IHN1YiB2YWx1ZXMgdGhhdCBjYW5ub3QgYmU8YnI+DQpjb3JyZWxhdGVkIGluIHRoZSBldmVu dCBvZiByZXNvdXJjZSBzZXJ2ZXJzIGNvbGx1c2lvbi48YnI+DQo8YnI+DQo8L3NwYW4+U2luY2Ug aXQgYWRkcmVzc2VzIGNhc2UgKGMpLjxicj4NCjxicj4NCmFuZCBhbHNvIGFib3V0IHRoZSBmb2xs b3dpbmcgdGV4dDo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyIj40LmIpIFNpbWlsYXJseTogaWYgYSBzb2x1dGlvbiByZXF1aXJlcyBw cmV2ZW50aW5nIGEgcmVzb3VyY2Ugc2VydmVyIGZyb20NCjxicj4NCmNvcnJlbGF0aW5nIHRoZSBw cmluY2lwYWzigJlzIGFjdGl2aXR5IHdpdGhpbiB0aGUgcmVzb3VyY2UgaXRzZWxmLCB0aGUgPGJy Pg0KYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGFzc2lnbiBkaWZmZXJlbnQgc3ViIHZhbHVl cyBmb3IgZXZlcnkgSldUIDxicj4NCmFjY2VzcyB0b2tlbiBpc3N1ZWQuPC9zcGFuPjxicj4NCjxi cj4NClNpbmNlIGl0IGFkZHJlc3NlcyBjYXNlIChkKS48YnI+DQo8YnI+DQpUaGlzIG1lYW5zIHRo YXQgdGhlIGN1cnJlbnQgdGV4dCBwbGFjZWQgaW4gdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiB3YXMgYSBnb29kIGF0dGVtcHQgdG8gYWRkcmVzcyB0aGUgY2FzZSwNCjxicj4NCmJ1 dCB0aGF0IHRoZSB0ZXh0IG5lZWRzIHRvIGJlIHJldmlzZWQuPGJyPg0KPGJyPg0KUHJvcG9zZWQg dGV4dCByZXBsYWNlbWVudCBmb3IgYWxsIHRoZSBwcmV2aW91c2x5IHF1b3RlZCBzZW50ZW5jZXM6 PGJyPg0KPGJyPg0KQWNjb3JkaW5nIHRvIFJGQyA3NTE5ICg0LjEuMik6IFRoZSBzdWJqZWN0IHZh bHVlIE1VU1QgZWl0aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29u dGV4dCBvZiB0aGUgaXNzdWVyIG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS48YnI+DQo8YnI+DQpXaGVu IHRoZSBzdWIgY2xhaW0gY29udGFpbnMgYSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllciwgdGhp cyBhbGxvd3MgdG8gY29ycmVsYXRlIHByaW5jaXBhbCBhY3Rpdml0aWVzIGFjcm9zcyBtdWx0aXBs ZSByZXNvdXJjZSBzZXJ2ZXJzLCB3aGlsZSBpbiBhZGRpdGlvbiwNCjxicj4NCnRoaXMgZ2xvYmFs bHkgdW5pcXVlIGlkZW50aWZpZXIgbWF5IGFsc28gYWxsb3cgdG8gY29ycmVsYXRlIHRoZSBwcmlu Y2lwYWwgYWN0aXZpdGllcyBvbiBzZXJ2ZXJzIHdoZXJlIG5vIGFjY2VzcyBoYXMgYmVlbiBwZXJm b3JtZWQgYnkgdGhlIHByaW5jaXBhbHMNCjxicj4NCnRvIHRoZXNlIHNlcnZlcnMgYnV0IHdoZXJl IHRoZSBzYW1lIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyBhcmUgYmVpbmcgdXNlZCBieSB0 aGVzZSBzZXJ2ZXJzLg0KPGJyPg0KPGJyPg0KV2hlbiB0aGUgc3ViIGNsYWltIGNvbnRhaW5zIGEg bG9jYWxseSB1bmlxdWUgaWRlbnRpZmllciBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyLCB0 aGlzIGFsc28gYWxsb3dzIHRoZSB0cmFja2luZyBvZiBwcmluY2lwYWwgYWN0aXZpdGllcyBhY3Jv c3MgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycy48YnI+DQo8YnI+DQpUaGUgc2NvcGUgcmVxdWVz dCBwYXJhbWV0ZXIgaXMgdGhlIG9ubHkgd2F5IHRvIGluZmx1ZW5jZSBvbiB0aGUgY29udGVudCBv ZiB0aGUgc3ViIGNsYWltIHBhcmFtZXRlci4gSXRzIG1lYW5pbmcgaXMgc3ViamVjdCB0byBhIHBy aXZhdGUgYWdyZWVtZW50DQo8YnI+DQpiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBBUywgd2hp Y2ggbWVhbnMgdGhhdCB0aGUgdXNlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgdGhlIG9ubHkg d2F5IHRvIGNob29zZSBiZXR3ZWVuIGEgbG9jYWxseSB1bmlxdWUgaWRlbnRpZmllcg0KPGJyPg0K aW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlm aWVyLjxicj4NCjxicj4NClNpbmNlIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgYmVpbmcgcmV0dXJu ZWQsIGl0IGlzIGEgcHJpbWFyeSBpbXBvcnRhbmNlIHRoYXQgdGhlIHJldHVybmVkIHNjb3BlIG1h dGNoZXMgd2l0aCB0aGUgZXhwZWN0YXRpb25zIG9mIHRoZSBjbGllbnQgYmVmb3JlIHRyYW5zbWl0 dGluZw0KPGJyPg0KdGhlIHRva2VuIHRvIGEgUmVzb3VyY2UgU2VydmVyLjxicj4NCjxicj4NCkhv d2V2ZXIsIHRoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IHdvdWxkIGxpa2Ug dG8gYmUgYWJsZSB0byBjaG9vc2Ugd2hldGhlciBpdCB3aXNoZXMgdGhlIHN1YiBjbGFpbSB0byBj b250YWluIDoNCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtIGEgZGlmZmVyZW50IHBzZXVkb255 bSBmb3IgZWFjaCBSUyBzbyB0aGF0IGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgYmUg dW5hYmxlIHRvIGNvcnJlbGF0ZSBpdHMgYWN0aXZpdGllcywgb3I8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgLSBhIGRpZmZlcmVudCBwc2V1ZG9ueW0gZm9yIGVhY2ggYXV0aG9yaXphdGlvbiB0b2tl biByZXF1ZXN0LCBzbyB0aGF0IHRoZSBzYW1lIHJlc291cmNlIHNlcnZlciBjYW5ub3QgY29ycmVs YXRlIGl0cyBhY3Rpdml0aWVzIHBlcmZvcm1lZCBhdCBkaWZmZXJlbnQgaW5zdGFudCBvZiB0aW1l Lg0KPGJyPg0KPGJyPg0KQ29uc2lkZXJpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgc3ViIGNsYWlt LCB0aGVzZSB0d28gY2FzZXMgY2Fubm90IGJlIGN1cnJlbnRseSBzdXBwb3J0ZWQuPGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPGJyPg0KPGI+NCkgPC9iPlRoZSBuZXh0IHRvcGljIGlzIGFib3V0IHRo ZSB0YXJnZXRpbmcgb2YgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UZXh0IGhhZCBiZWVuIHByb3Bvc2VkIGJlZm9yZSB0aGUgbGFzdCBjb25mZXJl bmNlIGNhbGwuIFRoZW4sIHRoZSB0b3BpYyBoYXMgYmVlbiBwcmVzZW50ZWQgYXQgdGhlIHZlcnkg ZW5kIG9mIHRoZSBsYXN0IGNvbmZlcmVuY2UgY2FsbCwgYnV0IG5vIHRleHQgaGFzIGJlZW4gaW5j bHVkZWQNCjxicj4NCmluIHRoZSBuZXh0IGRyYWZ0LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGVyZSBpcyBhIHJldmlzZWQgdGV4dCBiZSBpbmNsdWRlZCBpbiB0aGUg cHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Gb3Igc2VjdXJpdHkgcmVhc29ucywgc29tZSBjbGllbnRzIG1heSBiZSB3 aWxsaW5nIHRvIHRhcmdldCB0aGVpciBhY2Nlc3MgdG9rZW5zIGJ1dCwgZm9yIHByaXZhY3kgcmVh c29ucywgbWF5IGJlIHVud2lsbGluZyB0byBkaXNjbG9zZSB0byBBdXRob3JpemF0aW9uIFNlcnZl cnMNCjxicj4NCmFuIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBSZXNvdXJjZSBTZXJ2ZXJzIHRoZXkg YXJlIGdvaW5nIHRvIGFjY2Vzcywgc28gdGhhdCBBdXRob3JpemF0aW9uIFNlcnZlcnMgd2lsbCBi ZSB1bmFibGUgdG8ga25vdyB3aGljaCByZXNvdXJjZXMgc2VydmVycyBhcmUgYmVpbmcgYWNjZXNz ZWQuDQo8YnI+DQpUaGUgZGlzY2xvc3VyZSBvZiB0aGUgUmVzb3VyY2UgU2VydmVycyBuYW1lcyBh bGxvd3MgdGhlIEF1dGhvcml6YXRpb24gU2VydmVycyB0byBsaXN0IGFsbCB0aGUgUmVzb3VyY2Ug U2VydmVycyBiZWluZyBhY2Nlc3MgYnkgYWxsIGl0cyB1c2VycyBhbmQgaW4gYWRkaXRpb24gdG8g bGlzdCBwYWlycw0KPGJyPg0Kb2YgKFByaW5jaXBhbCwgUmVzb3VyY2UgU2VydmVycykgd2hpY2gg YWxsb3cgdG8gdHJhY2UgYWxsIHRoZSB1c2VycyBhY2Nlc3NlcyB0byBSZXNvdXJjZSBTZXJ2ZXJz IHBlcmZvcm1lZCB0aHJvdWdoIGEgZ2l2ZW4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFdoZW4gYSB0 b2tlbiBpcyB0YXJnZXRlZCwNCjxicj4NCnRoaXMgcHJvZmlsZSBkb2VzIG5vdCBjb250YWluIHBy b3Zpc2lvbnMgdG8gYWRkcmVzcyB0aGVzZSB0d28gdGhyZWF0cy48YnI+DQo8YnI+DQpEZW5pczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGlu ZS1oZWlnaHQ6MTE1JSI+DQpIaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NClRoaXMgaXMgYSBzZWNvbmQgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgZm9yICZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUg Zm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQpIZXJlIGlzIHRoZSBk b2N1bWVudDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdo dDoxMTUlIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6 MTE1JSI+DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBPQXV0aCBtYWlsaW5nIGxp c3QgYnkgQXByaWwgMjksIDIwMjAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NClJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDtSaWZhYXQgJmFt cDsgSGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWln aHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLA0KIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N CjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_AM0PR08MB37161916ED0662F4CB2C736EFA890AM0PR08MB3716eurp_-- From nobody Thu Jun 4 11:35:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC883A0D8D for ; Thu, 4 Jun 2020 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LONGWORDS=2.035, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7ds_u8MQfFx for ; Thu, 4 Jun 2020 11:35:05 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2573A0D5E for ; Thu, 4 Jun 2020 11:35:04 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id e9so3859327pgo.9 for ; Thu, 04 Jun 2020 11:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=CFZsfA7vs03G6Wi95T9meUH7qIhLas31zJVHRkt08D4=; b=b+nqnzPNdi71sW5L/l2XYrufYpxDlcDblusrEFOb2W49t/TiY68TXARXYWUCwrKcmr M3XE7Ujpn3+UNq6EQDHbr1vG2T8H1Z+bREH5OT2xRommfJRzXy80IMAyfms6Ve/W4QjU CMEgcQIVldXbSxpqgsb4xMIRo/SNqpGjBQ6AJ6aKSaMQIs4paakdSugfpGLQHyeIYb+G axpyi/FzerMkR+Y4+s34W7N47o4XVdRg3nZ/C4xFaJwrOP3Ceu/9y57o86OXrCPhT72Q 6130vdeD7kZtrUWO/agNQ55iU56aV0GIWHtSAzUVEJDt1fYogaSIa2mwVg6RvPQmRawG Uk/Q== 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=CFZsfA7vs03G6Wi95T9meUH7qIhLas31zJVHRkt08D4=; b=XtYx3OTf6wqN9icILK0ViUKJW7L55Qt4ppxYdQ7735pexRrPaXqfKwZHC/qmcnOehC udDcDLk3K7IIfljkli5TNnFhpEj9Ebu3cFbgcfqXdpLxS3J+J7MjCVePAxyH2yjb6WRp ssW2LF1ej0oujozC6DLXLB/XxFr65J5O+Un2Mqdj53z6fq12VsDFTKbrNZ6SbJ4REFaV YyD94RURdv/QFK+dblBc7JNyzHS7kiHJ7r95HDZvRBeNbcHZlfk6x4E8y+riEhDD/Tsf IX5OK2pYw8UJ9K2BG8WrLKYTDg8B9Dhd09JHWa9ZzQUJypZKC/A3gA7xq137n40QotMM naeg== X-Gm-Message-State: AOAM531oWLwfxAv8uIK9gUo0y/CWF/bHFOtaDIrh+9nt7NKNFl+/CI+i lDG7+rOuziknAD2cXCF8aU/0Ag== X-Google-Smtp-Source: ABdhPJyPRLKomBkc+m4qyA/knpP36Aeio4zyWa1L1nH9TDwfX8CsBLFsW2InprlQELMmg//QcXj4WQ== X-Received: by 2002:a63:6dc9:: with SMTP id i192mr5215113pgc.402.1591295704138; Thu, 04 Jun 2020 11:35:04 -0700 (PDT) Received: from ?IPv6:2001:569:79bc:100:9d1:c8fa:c5f1:e69? (node-1w7jr9qqo6k55g3ofnxsal3e1.ipv6.telus.net. [2001:569:79bc:100:9d1:c8fa:c5f1:e69]) by smtp.gmail.com with ESMTPSA id t2sm4651502pgh.89.2020.06.04.11.35.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 11:35:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-BE2974D5-E213-4318-ADC1-4460C0C8C59C Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Thu, 4 Jun 2020 11:35:02 -0700 Message-Id: References: Cc: Denis , Vittorio Bertocci , "oauth@ietf.org" In-Reply-To: To: Hannes Tschofenig X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 18:35:10 -0000 --Apple-Mail-BE2974D5-E213-4318-ADC1-4460C0C8C59C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Denis, I agree with Hannes. Speaking as one of the security consideration and threa= t model authors for OAuth2, a foundational design assumption was always that= access tokens are opaque to clients.=20 Even in the case of OIDC they created the id token to be a token defined for= the client in the special purpose case of authentication.=20 In my experience a client insisting on using and interpreting tokens is ofte= n doing something wrong and violating security processing rules like audienc= e. Issues such as sharing a token unintended parties (ie not the resources s= pecified by the aud claim) leading to confused deputy or impersonation attac= ks.=20 Opaqueness of ATs to clients is a foundational architectural principle of th= e OAuth 2 framework.=20 This is not to dismiss new use cases OAuth 2 does not address. But I feel th= ese cases that require access token inspection by clients should be evaluate= d in the context of a new protocol evolution proposal (eg like xyz).=20 Phil Hunt > On Jun 4, 2020, at 7:26 AM, Hannes Tschofenig w= rote: >=20 > =EF=BB=BF > Hi Denis, > =20 > Please see my response below. > =20 > =20 > From: Denis =20 > Sent: Wednesday, June 3, 2020 12:12 PM > To: Hannes Tschofenig > Cc: Rifaat Shekh-Yusef ; Vittorio Bertocci ; oauth@ietf.org > Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for O= Auth 2.0 Access Tokens" > =20 > Hi Hannes, >=20 > First of all, I do appreciate your efforts to attempt to get rid of the "M= UST NOT" in the "Privacy considerations" section. >=20 > Let us look at the following proposed sentence: >=20 > While this is technical possible, it is important to note that the OAu= th 2.0 protocol does not aim to expose the content of the access token=20 > to the client. The access token is therefore, by design, considered to= be opaque to the client". >=20 > In the context of this document, a detailed content of the JWT is expected= and thus, if a client receives a JWT compliant to this profile=20 > (and if the token is not encrypted which is most often the case) it will a= bsolutely be sure to pick up any guaranteed field within the JWT.=20 > So, in the context of this document, the access token cannot be considered= to be opaque to the client. >=20 >=20 > [Hannes] Here we have a disconnect. The OAuth 2.0 design does not assume t= hat the client inspects the access tokens if it flies by. This document coul= d not change that. >=20 > The purpose of this document is actually quite simple: Those who want to u= se JWT as a format for access tokens they can use the claims described in th= is document. You are also free to use whatever format you want. >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > About the second paragraph, in the context of this document (besides the c= ase where the JWT is encrypted), it is neither difficult,=20 > nor impossible to parse the token. >=20 > About the second paragraph, let us look at the following proposed sentence= in the context of this document : >=20 > " Additionally, there is no guarantee that the access token is conveye= d by value and the authorization server implementation may change=20 > the token format at any time ". >=20 > The argumentation that the token format may change at any point of time, w= hile being valid in the general case, is invalid in the context of this docu= ment.=20 > This JWT profile will be stable over time. This means that this quoted sen= tence is inappropriate in the context of this document. >=20 >=20 > [Hannes] Here is the issue. In a given deployment you do not know how the a= ccess token is encoded nor whether the claims are in this format. You don=E2= =80=99t know whether the token is conveyed by reference or by value. Hence, w= hy should we suddenly even give developers the impression that OAuth Clients= should look at the token. >=20 > =20 >=20 > =20 >=20 >=20 > The third proposed paragraph is stating : >=20 > " In scenarios where it is where it is desirable for the clients to ob= tain information transmitted in the access token, OAuth 2.0 token introspect= ion=20 > may provide a useful tool to enable such functionality (proper autho= rization assumed) ". >=20 > RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by prote= cted resources, but is not a protocol to be used by clients.=20 > As indicated, in order to be usable, a "proper authorization" also needs t= o be managed. Besides the difficulty to support such a protocol for clients=20= > and to twist its original usage as defined in RFC 7662, it is simpler to d= evelop the code to examine the content of the JWT, since its content is guar= anteed=20 > to be stable over time. >=20 > [Hannes] While it may be simpler to inspect the access token, the use of t= oken introspection is a better match for the OAuth architecture. We can talk= about updating the token introspection RFC to also describe this use case, a= ssuming there is interest. >=20 > The question in general will surface why the client should get access to t= he content of the access token in the first place. For those cases where inf= ormation is passed to the client other mechanisms, such as the identity toke= n in OIDC, have been developed. >=20 > =20 >=20 > The last proposed paragraph is the following: >=20 > " Since the content of the access token is accessible to the resource s= erver it is important to evaluate whether the resource server gained the pro= per entitlement=20 > to have access to any content received in form of claims, for exampl= e through user consent in some form, policies and agreements with the organi= zation running=20 > the authorization servers, and so on. The policies and the user inte= rfaces to enable this user consent are, however, part of a specific deployme= nt and therefore=20 > outside the scope of this document ". >=20 > The sentence "for example through user consent in some form, policies and a= greements with the organization running the authorization servers, and so on= "=20 > should be removed, since this example lets believe that the consent is han= dled by the authorizations servers while it might be handled by the resource= servers. > [Hannes] The information is disclosed by the authorization server and henc= e the consent has to be with the authorization server. >=20 >=20 > The last proposed paragraph would be solution neutral if the example were r= emoved. This would lead to the following sentence: >=20 > Since the content of the access token is accessible to the resource server= it is important to evaluate whether the resource server gained the proper e= ntitlement=20 > to have access to any content received in form of claims. The policies and= the user interfaces to enable this user consent are, however, part of a spe= cific deployment=20 > and therefore outside the scope of this document. >=20 > Finally, there are still two questions that have been raised but which hav= e not yet been answered at this time: > how can a client request a JWT compliant to this profile, and > how can a client be confident that it got a JWT compliant to this profile ?= > =20 > [Hannes] Regarding the two questions: It cannot and it was never the inten= tion of this work. > =20 > Ciao > Hannes > =20 >=20 > Denis > =20 > Let me try to jump in here in order to make a proposal for the text in the= privacy consideration section: > =20 > FROM: > 6. Privacy Considerations > =20 > =20 > As JWT access tokens carry information by value, it now becomes > possible for requestors and receivers to directly peek inside the > token claims collection. The client MUST NOT inspect the content of > the access token: the authorization server and the resource server > might decide to change token format at any time (for example by > switching from this profile to opaque tokens) hence any logic in the > client relying on the ability to read the access token content would > break without recourse. Nonetheless, authorization servers should > not assume that clients will comply with the above. Whenever client > access to the access token content presents privacy issues for a > given scenario, the authorization server should take explicit steps > to prevent it as described below. > =20 > In scenarios in which JWT access tokens are accessible to the end > user, it should be evaluated whether the information can be accessed > without privacy violations (for example, if an end user would simply > access his or her own personal information) or if steps must be taken > to enforce cofidentiality. Possible measures include: encrypting the > access token, encrypting the sensitive claims, omitting the sensitive > claims or not using this profile, falling back on opaque access > tokens. > =20 > In every scenario, the content of the JWT access token will > eventually be accessible to the resource server. It's important to > evaluate whether the resource server gained the proper entitlement to > have access to any content received in form of claims, for example > through user consent in some form, policies and agreements with the > organization running the authorization servers, and so on. > =20 > TO: > =20 > 6. Privacy Considerations > The design of OAuth 2.0 envisions that access tokens are created by > authorization servers and consumed by resource servers. > As JWT access tokens, as described in this document, carry information b= y value, it is > possible for OAuth clients to peek inside the access token. > While this is technical possible, it is important to note that the > OAuth 2.0 protocol does not aim to expose the content of the > access token to the client. The access token is therefore, by design, c= onsidered to be > opaque to the client. > =20 > A number of cases may make it difficult or impossible for clients to > inspect the token, for example, the access token may be encrypted, > the access token may contain vendor-specific claims that have not been > standardized or have been standardized in other consortia making parsin= g > of the token difficult. Additionally, there is no guarantee that the > access token is conveyed by value and the authorization server implemen= tation > may change the token format at any time. > =20 > In scenarios where it is desirable for the clients to obtain informatio= n > transmitted in the access token, OAuth 2.0 token introspection may prov= ide > a useful tool to enable such functionality (proper authorization assume= d). > =20 > In scenarios where the content of the access token must not be readable= > by clients, encrypting the content of the access token is RECOMMENDED. > =20 > Since the content of the access token is accessible to the resource ser= ver > it is important to > evaluate whether the resource server gained the proper entitlement to > have access to any content received in form of claims, for example > through user consent in some form, policies and agreements with the > organization running the authorization servers, and so on. The policies= > and the user interfaces to enable this user consent are, however, part > of a specific deployment and therefore outside the scope of this docume= nt. > =20 > =20 > How does this sound? > =20 > Ciao > Hannes > =20 > =20 > =20 > From: OAuth On Behalf Of Rifaat Shekh-Yusef > Sent: Thursday, May 14, 2020 8:03 PM > To: Denis > Cc: Vittorio Bertocci ; oauth@ietf.org > Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for O= Auth 2.0 Access Tokens" > =20 > Denis, > =20 > You are rehashing the same issues that you have already discussed on the m= ailing list multiple times, > You could not get the WG to agree with your points, because the WG believe= that this issue is outside the scope of this document. > =20 > The best the chairs can do at this stage is to capture your point in the s= hepherd write-up to the IESG. > We think this document has the support of the WG and is ready to move forw= ard. > =20 > Regards, > Rifaat > =20 > =20 > On Thu, May 14, 2020 at 12:29 PM Denis wrote: > Hi Vittorio, > =20 > I am referring to the email you sent on April the 29 th which is copied be= low. > =20 > 1) You wrote: > > targeting of access tokens > Let me think about that a bit longer. > I acknowledge that the decision of including an audience has the effect of= letting the AS track when the client accesses a particular resource,=20 > but at the same time that=E2=80=99s completely mainstream and very much by= design in a very large number of cases. As such, I find the language=20 > you are suggesting to be potentially confusing, as it positions this as an= exception vs a privacy protecting mainstream that is in fact not common,=20= > and ascribes to the client more latitude than I believe is legitimate to e= xpect or grant. >=20 > I=E2=80=99ll try to come up with concise language that clarifies to the re= ader that the current mechanism does allow AS tracking. =20 > Since the last draft has been published on the 27 th, you have not propose= d any "concise language that clarifies to the reader=20 > that the current mechanism does allow AS tracking". > =20 > 2) You also wrote about the "sub" uniqueness: > As long as an identifier identifies one resource only, it satisfies unique= ness. It doesn=E2=80=99t have to be a singleton. > RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using t= he following sentence: > The subject value MUST either be scoped to be locally unique in the contex= t of the issuer or be globally unique. > The text does NOT say that the subject value "MUST be scoped to be locally= unique in the context of the resource server". > Changing the semantics of an already defined claim is not permitted. If yo= u would like to have such a semantics available,=20 > a new claim should be defined (and it would be very nice to have it !). > =20 > 3) The text is the privacy considerations section states: > =20 > Although the ability to correlate requests might be required by design i= n many scenarios, there are scenarios where the authorization > server might want to prevent correlation to preserve the desired level o= f privacy. > =20 > In the real world, it is also clients or end-users which would like to pre= vent correlation to preserve their desired level of privacy. > =20 > A better sentence would be: > =20 > Although the ability to correlate requests might be required by design i= n many scenarios, there are scenarios where the authorization > server or the client might want to prevent correlation to preserve the d= esired level of privacy. > =20 > 4) The text continues with: > =20 > Authorization servers should choose how to assign "sub" values accordin= g to the level of privacy required by each > situation. For instance: if a solution requires preventing tracking p= rincipal activities across multiple resource servers,=20 > the authorization server should ensure that JWT access tokens meant fo= r different resource servers have distinct "sub"=20 > values that cannot be correlated in the event of resource servers collu= sion.=20 > =20 > Authorization servers are not necessarily able to choose the level of priv= acy required by each situation. When there are different=20 > situations for the same resource server, the scope is (unfortunately at th= e moment) the only way to select the "level of privacy that is required". > =20 > The example ("For instance:") is only an example that provides a vague rec= ommendation for the ASs which is NOT conformant > with the semantics of the "sub" claim as defined in RFC 7519. > =20 > What should be discussed here are not "examples" or what an authorization s= erver should do, but explanations about the implications=20 > for the end-user or for the client for the various values that can be plac= ed into the "sub" claim by an AS. The problem is wider that simply=20 > a collusion between resource servers, but also with other servers that DO N= OT participate in any OAuth exchange. > =20 > RFC 6973 (Privacy Considerations) states in section 7 : Guidelines > This section provides guidance for document authors in the form of a quest= ionnaire about a protocol being designed. =20 > The questionnaire may be useful at any point in the design process, partic= ularly after document authors have developed=20 > a high-level protocol model as described in [RFC4101]. > One of the questions is: > f. Correlation. Does the protocol allow for correlation of identifiers ?= Are there expected ways that information exposed=20 > by the protocol will be combined or correlated with information obtained o= utside the protocol ? > It is important to provide an answer to these two questions. > =20 > Hereafter is some text that is fully conformant with RFC 7519 which should= be incorporated into the privacy considerations section=20 > which explains the implications of the two (and only two) flavours of the "= sub" claim. > When the sub claim contains a locally unique identifier in the context of t= he issuer, this allows the tracking of principal activities=20 > across multiple resource servers. > =20 > When the sub claim contains a globally unique identifier, this allows to c= orrelate principal activities across multiple resource=20 > servers, while in addition, this globally unique identifier may also allow= to correlate the principal activities on servers where=20 > no access has been performed by the principals to these servers but where t= he same globally unique identifiers are being used=20 > by these servers. > Denis >=20 > Thanks Denis for the thorough commentary. > =20 > > The title of this spec. > Fixed, thanks! > =20 > > The client MUST NOT inspect the content of the access token > This is really a sticky point. I really want to acknowledge your PoV on th= is, but at the same time I found this to be one of the biggest sources of is= sues in the use of JWT for access tokens hence I feel we really need to give= solid guidance here. Let me expand further on the reasoning behind it, and p= erhaps we can get to language that satisfies both PoVs. > To me the key point is that clients should not write code that inspects ac= cess tokens. Taking a dependency on the ability to do so is ignoring fundame= ntal information about the architecture and relationships between OAuth role= s, and suggests an ability of the client to understand the semantic of the c= ontent that cannot be assumed in the general case. I expanded on the details= in my former reply to you on this topic, I would recommend referring to it.= Clients violating this simple principle has been one of the most common sou= rces of production issues I had to deal with in the past few years, and one o= f the hardest to remediate given that clients are hard to update and sometim= es the things they relied on were irremediably lost. This is why I am inclin= ed to put in here strong language. > That said: I have nothing against client developers examining a network tr= ace and drawing conclusions based on the content of what they see. That does= n=E2=80=99t create any hard dependencies and has no implications in respect t= o changes in the solution behavior. However I am not sure how to phrase that= in the specification, given that referring to the client inevitably refers t= o its code. I am open to suggestions. > =20 > > 3)=E2=80=A6 > I have a pretty hard time following the chain of reasoning in this section= . Let me attempt to tackle it to the best of my understanding. > I think the key might be =20 > > a client should be able to choose whether it wishes the sub claim to con= tain [..] > I don=E2=80=99t think that should be a choice left to the client. In busin= ess systems, my experience is that the type of identifiers to be used (when t= he IdP gives any choice at all) is established at resource provisioning tim= e. I am not aware of mechanisms thru which a client signals the nature of th= e identifier to be used, nor that would be fully feasible (the resource know= s what it needs to perform its function). > Furthermore: > > which has nothing to do with uniqueness since the value changes for ever= y generated token. > Again, this is something that was touched on in my former reply to your me= ssage. As long as an identifier identifies one resource only, it satisfies u= niqueness. It doesn=E2=80=99t have to be a singleton. > Finally, the scope is optional (for good reasons: 1st party and non delega= tion scenarios don=E2=80=99t require it) hence it cannot be relied upon for p= roperties that should hold in every scenario. > In summary: per the preceding thread on this topic, the consensus was that= varying the sub content was a satisfactory way of protecting against correl= ation. I don=E2=80=99t a gree that clients should have a mechanism to reques= t different sub flavors, as that decision should be done out of band by the A= S and RS; and the scope isn=E2=80=99t always available anyway. > > targeting of access tokens > Let me think about that a bit longer. > I acknowledge that the decision of including an audience has the effect of= letting the AS track when the client accesses a particular resource, but at= the same time that=E2=80=99s completely mainstream and very much by design i= n a very large number of cases. As such, I find the language you are suggest= ing to be potentially confusing, as it positions this as an exception vs a p= rivacy protecting mainstream that is in fact not common, and ascribes to the= client more latitude than I believe is legitimate to expect or grant. > I=E2=80=99ll try to come up with concise language that clarifies to the re= ader that the current mechanism does allow AS tracking. =20 > =20 > From: OAuth on behalf of Denis > Date: Wednesday, April 29, 2020 at 09:12 > To: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for O= Auth 2.0 Access Tokens" > =20 > You will find four comments numbered 1) to 4). > 1) The title of this spec. is: >=20 > JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens >=20 > So, this spec. is supposed to be targeted to OAuth 2.0. However, the head= er at the top of the page omits to mention it.=20 >=20 > Currently, it is :=20 > Internet-Draft OAuth Access Token JWT Profile April 2020 > It should rather be: > Internet-Draft OAuth 2.0 Access Token JWT Profile April 20= 20 >=20 > 2) The following text is within section 6. >=20 > The client MUST NOT inspect the content of > the access token: the authorization server and the resource server > might decide to change token format at any time (for example by > switching from this profile to opaque tokens) hence any logic in the > client relying on the ability to read the access token content would > break without recourse. > Nonetheless, authorization servers should > not assume that clients will comply with the above. > It is of a primary importance that clients MAY be able to inspect tokens b= efore transmitting them. > The "MUST NOT" is not acceptable. > The above text should be replaced with: >=20 > Reading the access token content may be useful for the user to verify that= =20 > the access token content matches with its expectations. However,=20 > the authorization server and the resource server might decide to change th= e=20 > token format at any time. Thus, the client should not expect to always be= =20 > in a position to read the access token content. >=20 > The remaining of the text about this topic is fine. >=20 >=20 > 3) The next topic is about the sub claim. >=20 > The text states: >=20 > Although the ability to correlate requests might be required by > design in many scenarios, there are scenarios where the authorization > server might want to prevent correlation to preserve the desired > level of privacy. Authorization servers should choose how to assign > sub values according to the level of privacy required by each > situation. >=20 > I have a set of questions: > How can authorization servers choose how to assign sub values according to= the level of privacy required "by each situation" ? > How can authorization servers know the level of privacy required "by each s= ituation" ? > How can the users be informed of the level of privacy required "by each si= tuation" ? > How can the users consent with the level of privacy required "by each situ= ation" ? > Currently, the request MUST include either a resource parameter or an aud c= laim parameter, while it MAY include a scope parameter. > The syntax of the scope parameter is a list of space-delimited, case-sensi= tive strings (RFC 6749). It is thus subject to private agreements=20 > between clients and Authorization Servers. Since the scope is being return= ed, it is a primary importance that the returned scope matches=20 > with its expectations before transmitting the token to a Resource Server. >=20 > In theory, a client should be able to choose whether it wishes the sub cla= im to contain : > a global unique identifier for all ASs ("globally unique"), > a unique identifier for each AS ("locally unique in the context of the iss= uer"), > a different pseudonym for each RS, or > a different pseudonym for each authorization token request. > The only variable parameter that it can use for this purpose in the token r= equest is the scope parameter. >=20 > RFC 7519 states is section 4.1.2: >=20 > The subject value MUST either be scoped to be locally unique in the contex= t of the issuer=20 > or be globally unique. >=20 > It is quite hard to recognize that the sub claim is able to carry a differ= ent pseudonym for each RS, i.e. for case (c), or=20 > a different pseudonym for each authorization token request, i.e. for case (= d), which has nothing to do with uniqueness=20 > since the value changes for every generated token. >=20 > This has implications about the following text: >=20 > For instance: if a solution requires preventing tracking > principal activities across multiple resource servers, the > authorization server should ensure that JWT access tokens meant for > different resource servers have distinct sub values that cannot be > correlated in the event of resource servers collusion. >=20 > Since it addresses case (c). >=20 > and also about the following text: >=20 > 4.b) Similarly: if a solution requires preventing a resource server from=20= > correlating the principal=E2=80=99s activity within the resource itself, t= he=20 > authorization server should assign different sub values for every JWT=20 > access token issued. >=20 > Since it addresses case (d). >=20 > This means that the current text placed in the privacy considerations sect= ion was a good attempt to address the case,=20 > but that the text needs to be revised. >=20 > Proposed text replacement for all the previously quoted sentences: >=20 > According to RFC 7519 (4.1.2): The subject value MUST either be scoped to b= e locally unique in the context of the issuer or be globally unique. >=20 > When the sub claim contains a globally unique identifier, this allows to c= orrelate principal activities across multiple resource servers, while in add= ition,=20 > this globally unique identifier may also allow to correlate the principal a= ctivities on servers where no access has been performed by the principals=20= > to these servers but where the same globally unique identifiers are being u= sed by these servers.=20 >=20 > When the sub claim contains a locally unique identifier in the context of t= he issuer, this also allows the tracking of principal activities across mult= iple resource servers. >=20 > The scope request parameter is the only way to influence on the content of= the sub claim parameter. Its meaning is subject to a private agreement=20 > between the client and the AS, which means that the use of the scope param= eter is the only way to choose between a locally unique identifier=20 > in the context of the issuer or a globally unique identifier. >=20 > Since the scope parameter is being returned, it is a primary importance th= at the returned scope matches with the expectations of the client before tra= nsmitting=20 > the token to a Resource Server. >=20 > However, there are other cases where the client would like to be able to c= hoose whether it wishes the sub claim to contain :=20 > - a different pseudonym for each RS so that different resource servers= will be unable to correlate its activities, or > - a different pseudonym for each authorization token request, so that t= he same resource server cannot correlate its activities performed at differe= nt instant of time.=20 >=20 > Considering the semantics of the sub claim, these two cases cannot be curr= ently supported. >=20 >=20 > 4) The next topic is about the targeting of access tokens > Text had been proposed before the last conference call. Then, the topic ha= s been presented at the very end of the last conference call, but no text ha= s been included=20 > in the next draft. > Here is a revised text be included in the privacy considerations section: > For security reasons, some clients may be willing to target their access t= okens but, for privacy reasons, may be unwilling to disclose to Authorizatio= n Servers=20 > an identification of the Resource Servers they are going to access, so tha= t Authorization Servers will be unable to know which resources servers are b= eing accessed.=20 > The disclosure of the Resource Servers names allows the Authorization Serv= ers to list all the Resource Servers being access by all its users and in ad= dition to list pairs=20 > of (Principal, Resource Servers) which allow to trace all the users access= es to Resource Servers performed through a given Authorization Server. When a= token is targeted,=20 > this profile does not contain provisions to address these two threats. >=20 > Denis > Hi all, > =20 > This is a second working group last call for "JSON Web Token (JWT) Profile= for OAuth 2.0 Access Tokens". > =20 > Here is the document: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06 > =20 > Please send your comments to the OAuth mailing list by April 29, 2020. > =20 > Regards, > Rifaat & Hannes > =20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. > =20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential 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 o= ther 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 --Apple-Mail-BE2974D5-E213-4318-ADC1-4460C0C8C59C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Denis,

I agree wit= h Hannes. Speaking as one of the security consideration and threat model aut= hors for OAuth2, a foundational design assumption was always that access tok= ens are opaque to clients. 

Even in the case of OIDC= they created the id token to be a token defined for the client in the speci= al purpose case of authentication. 

In my expe= rience a client insisting on using and interpreting tokens is often doing so= mething wrong and violating security processing rules like audience. Issues s= uch as sharing a token unintended parties (ie not the resources specified by= the aud claim) leading to confused deputy or impersonation attacks. 

Opaqueness of ATs to clients is a foundational archi= tectural principle of the OAuth 2 framework. 

= This is not to dismiss new use cases OAuth 2 does not address. But I feel th= ese cases that require access token inspection by clients should be evaluate= d in the context of a new protocol evolution proposal (eg like xyz). 
Phil Hunt

On Jun 4, 2020, at 7:26 AM, Hannes Tschofenig <Hannes.Tschofenig@a= rm.com> wrote:

=EF=BB=BF

Hi Denis,

 

Please see my response below.

 

 

From: Denis <denis.ietf@free.fr>
Sent: Wednesday, June 3, 2020 12:12 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>; Vittorio Bert= occi <vittorio.bertocci@auth0.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile f= or OAuth 2.0 Access Tokens"

 

Hi Hannes,

First of all, I d= o appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Pr= ivacy considerations" section.

Let us look at the following proposed sentence:

    While this is technical possi= ble, it is important to note that the OAuth 2.0 protocol does not aim to exp= ose the content of the access token
    to the client. The access tok= en is therefore, by design, considered to be opaque to the client".
In the context of this document, a detailed content of the JWT is expect= ed and thus, if a client receives a JWT compliant to this profile
(and if the token is not encrypted which is most often the case) it will abs= olutely be sure to pick up any guaranteed field within the JWT.
So, in the context of this document, the = access token cannot be considered to be opaque to the client.

[Hannes] Here we have a disconnect. The OAuth 2.0 design does not assume t= hat the client inspects the access tokens if it flies by. This document coul= d not change that.

The purpose of this document is actually quite simple: Those who want to u= se JWT as a format for access tokens they can use the claims described in th= is document. You are also free to use whatever format you want.

 

 

 


About the second paragraph, in the context of this document (besides t= he case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token.

About the second paragraph, let us look at the following proposed sentence in the context of this document :

    " Additionally, there is no guarantee that the access tok= en is conveyed by value and the authorization server implementation may chan= ge
      the token format at any time ".

The argumentation that the token format may change at any point of time, whi= le being valid in the general case, is invalid in the context of this document.
This JWT profile will be stable over time. This means that this quoted sente= nce is inappropriate in the context of this document.

[Hannes] Here is the issue. In a given deployment you do not know how the a= ccess token is encoded nor whether the claims are in this format. You don=E2= =80=99t know whether the token is conveyed by reference or by value. Hence, why should we suddenly even give developer= s the impression that OAuth Clients should look at the token.

 

 


The third proposed paragraph is stating :

    " In scenarios where it is wh= ere it is desirable for the clients to obtain information transmitted in the= access token, OAuth 2.0 token introspection
      may provide a useful tool to enable such func= tionality (proper authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by p= rotected resources, but is not a protocol to be used by clients.
As indicated, in order to be usable, a "proper a= uthorization" also needs to be managed. Besides the difficulty to support su= ch a protocol for clients
and to twist its original usage as defined in RFC 7662, it is simpler to dev= elop the code to examine the content of the JWT, since its content is guaran= teed
to be stable over time.=

[Hannes] While it may be simpler to inspect the access token, the use of t= oken introspection is a better match for the OAuth architecture. We can talk= about updating the token introspection RFC to also describe this use case, assuming there is interest. =

The question in general will surface why the client should get access to t= he content of the access token in the first place. For those cases where inf= ormation is passed to the client other mechanisms, such as the identity token in OIDC, have been developed. <= o:p>

 

The last pr= oposed paragraph is the following:

   " Since the content of the access token is accessible to the re= source server it is important to evaluate whether the resource server gained= the proper entitlement
      to have access to any content received in for= m of claims, for example through user consent in some form, policies and a= greements with the organization running
      the authorization servers, and so on. T= he policies and the user interfaces to enable this user consent are, however= , part of a specific deployment and therefore
      outside the scope of this document ".

The sentence "for example through user consent in some form, policies and ag= reements with the organization running the authorization servers, and so on"=
should be removed, since this example lets believe that the consent is handl= ed by the authorizations servers while it might be handled by the resource s= ervers.

[Hannes] The information is disclosed by the authorization server an= d hence the consent has to be with the authorization server.



The last proposed paragraph would be solution neutral if the example were re= moved. This would lead to the following sentence:

Since the content of the access token is accessible to the resource server i= t is important to evaluate whether the resource server gained the proper ent= itlement
to have access to any content received in form of claims. The policies and t= he user interfaces to enable this user consent are, however, part of a speci= fic deployment
and therefore outside the scope of this document.

Finally, there are still two questions that have been raised but which have n= ot yet been answered at this time:

  • how can a client re= quest a JWT compliant to this profile, and
  • how can a client be= confident that it got a JWT compliant to this profile ?

 =

[Hannes] Regarding the two questions: It cannot and it was never the= intention of this work.

 

Ciao

Hannes

 


Denis

 

Let me try to jump in here in order to make a proposa= l for the text in the privacy consideration section:

 

FROM:

6= .  Privacy Considerations

 

 

   As JWT access tokens carry i= nformation by value, it now becomes

   possible for requestors and r= eceivers to directly peek inside the

   token claims collection.&nbs= p; The client MUST NOT inspect the content of

   the access token: the author= ization server and the resource server

   might decide to change token= format at any time (for example by

   switching from this profile t= o opaque tokens) hence any logic in the

   client relying on the abilit= y to read the access token content would

   break without recourse. = ; Nonetheless, authorization servers should

   not assume that clients will= comply with the above.  Whenever client

   access to the access token c= ontent presents privacy issues for a

   given scenario, the authoriz= ation server should take explicit steps

   to prevent it as described b= elow.

 

   In scenarios in which JWT ac= cess tokens are accessible to the end

   user, it should be evaluated= whether the information can be accessed

   without privacy violations (= for example, if an end user would simply

   access his or her own person= al information) or if steps must be taken

   to enforce cofidentiality.&n= bsp; Possible measures include: encrypting the

   access token, encrypting the= sensitive claims, omitting the sensitive

   claims or not using this pro= file, falling back on opaque access

   tokens.

 

   In every scenario, the conte= nt of the JWT access token will

   eventually be accessible to t= he resource server.  It's important to

   evaluate whether the resourc= e server gained the proper entitlement to

   have access to any content r= eceived in form of claims, for example

   through user consent in some= form, policies and agreements with the

   organization running the aut= horization servers, and so on.

 

TO:

 

6.&= nbsp; Privacy Considerations

   The design of OAuth 2.0 envi= sions that access tokens are created by

   authorization servers a= nd consumed by resource servers.

   As JWT access tokens, a= s described in this document, carry information by value, it is<= /o:p>

   possible for OAuth clients t= o peek inside the access token.

   While this is technical= possible, it is important to note that the

   OAuth 2.0 protocol does not a= im to expose the content of the

   access token to the client. T= he access token is therefore, by design, considered to be

   opaque to the client.

 

   A number of cases may make i= t difficult or impossible for clients to

   inspect the token, for e= xample, the access token may be encrypted,

   the access token may co= ntain vendor-specific claims that have not been

   standardized or have be= en standardized in other consortia making parsing

   of the token difficult.= Additionally, there is no guarantee that the

   access token is conveye= d by value and the authorization server implementation

=

   may change the token format a= t any time.

 

   In scenarios where it is des= irable for the clients to obtain information

   transmitted in the acce= ss token, OAuth 2.0 token introspection may provide

   a useful tool to enable= such functionality (proper authorization assumed).

 

   In scenarios where the c= ontent of the access token must not be readable

   by clients, encrypting t= he content of the access token is RECOMMENDED.

  

   Since the content of th= e access token is accessible to the resource server

   it is important to

   evaluate whether the resourc= e server gained the proper entitlement to

   have access to any content r= eceived in form of claims, for example

   through user consent in some= form, policies and agreements with the

   organization running the aut= horization servers, and so on. The policies

   and the user interfaces= to enable this user consent are, however, part

   of a specific deploymen= t and therefore outside the scope of this document.

 

 

How does this sound?

 

Ciao

Hannes

 

 

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, May 14, 2020 8:03 PM
To: Denis <denis.ietf@free.f= r>
Cc: Vittorio Bertocci = <vittorio.bertocci@auth0.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile f= or OAuth 2.0 Access Tokens"

 

Denis,

 

You are rehashing the same issues that you have alrea= dy discussed on the mailing list multiple times,

You could not get the WG to agree with your points, b= ecause the WG believe that this issue is outside the scope of this docu= ment.

 

The best the chairs can do at this stage is to captur= e your point in the shepherd write-up to the IESG.

We think this document has the support of the WG and i= s ready to move forward.

 

Regards,

 Rifaat

 

 

On Thu, May 14, 2020 at 12:29 PM Denis <denis.ietf@free.fr> wrote:

=

Hi Vittorio,

 

I am referring to the email you sent on April the 29 th which is copied b= elow.

 

1) You wrote:

> tar= geting of access tokens

Let me thin= k about that a bit longer.

I acknowledge tha= t the decision of including an audience has the effect of letting the AS tra= ck when the client accesses a particular resource,
but at the same time that=E2=80=99s completely mainstream and very much by d= esign in a very large number of cases. As such, I find the language
you are suggesting to be potentially confusing, as it positions this as an e= xception vs a privacy protecting mainstream that is in fact not common,
and ascribes to the client more latitude than I believe is legitimate to exp= ect or grant.

I=E2=80=99ll try to come up with concise language that clarifies to t= he reader that the current mechanism does allow AS tracking.  

Since the last draft has been published on the 27 th,= you have not proposed any "concise language that= clarifies to the reader
that the current mechanism does allow AS tracking".

 

2) You also wrote about the "sub" uniqueness:

As long as an identifier identifies one resource only= , it satisfies uniqueness. It doesn=E2=80=99t have to be a singleton.

RFC 7519 defines in section 4.1.2 the semantics of th= e "sub" claim using the following sentence:

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

The text does NOT say that the subject value "MUST be= scoped to be locally unique in the context of the resource server".

Changing the semantics of an already defined claim is= not permitted. If you would like to have such a semantics available,
a new claim should be defined (and it would be very nice to have it !).

 

3) The text is the privacy considerations section sta= tes:

 

   Although the ability to correlate reques= ts might be required by design in many scenarios, there are scenarios where t= he authorization
   server might want to prevent correlation to preserve the desire= d level of privacy.

 

In the real world, it is also clients or end-users wh= ich would like to prevent correlation to preserve their desired level of pri= vacy.

 

A better sentence would be:

 

   Although the ability to correlate reques= ts might be required by design in many scenarios, there are scenarios where t= he authorization
   server or the client might want to prevent correlation t= o preserve the desired level of privacy.

 

4) The text continues with:

 

   Authorization servers should choose how t= o assign "sub" values according to the level of privacy required by each
=    situation.  For instance: if a solution requires preventin= g tracking  principal activities across multiple resource servers,
   the  authorization server should ensure that JWT access to= kens meant for different resource servers have distinct "sub"
   values that cannot be correlated in the event of resource serve= rs collusion. 

 

Authorization servers are not necessarily able to cho= ose the level of privacy required by each situation. When there are differen= t
situations for the same resource server, the scope is (unfortunately at the m= oment) the only way to select the "level of privacy that is required".<= /o:p>

 

The example ("For instance:") is only an example that= provides a vague recommendation for the ASs which is NOT conformant
with the semantics of the "sub" claim as defined in RFC 7519.

=

 

What should be discussed here are not "examples" or w= hat an authorization server should do, but explanations about the implicatio= ns
for the end-user or for the client for the various values that can be placed= into the "sub" claim by an AS. The problem is wider that simply
a collusion between resource servers, but also with other servers that DO NO= T participate in any OAuth exchange.

 

RFC 6973 (Privacy Considerations) states in section 7= : Guidelines

This section provides guidance for document authors i= n the form of a questionnaire about a protocol being designed. 
The questionnaire may be useful at any point in the design process, particul= arly after document authors have developed
a high-level protocol model as described in [RFC4101].

One of the questions is:

f.  Correlation.  Does the protocol a= llow for correlation of identifiers ?  Are there expected ways that inf= ormation exposed
by the protocol will be combined or correlated with information obtained o= utside the protocol ?

It is important to provide an answer to these two que= stions.

 

Hereafter is some text that is fully conformant with R= FC 7519 which should be incorporated into the privacy considerations section=
which explains the implications of the two (and only two) flavours of the "s= ub" claim.

When the sub claim contains a locally unique identifi= er in the context of the issuer, this allows the tracking of principal activ= ities
across multiple resource servers.

 

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

Denis

Thanks Denis for the thorough commentary.

 

> The title of this spec.

Fixed, thanks!

 

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

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

To me the key point is that clients should not write code that inspects access tokens. Taking a dependency on the ability t= o do so is ignoring fundamental information about the architecture and relat= ionships between OAuth roles, and suggests an ability of the client to under= stand the semantic of the content that cannot be assumed in the general case. I expanded on the details in my= former reply to you on this topic, I would recommend referring to it. Clien= ts violating this simple principle has been one of the most common sources o= f production issues I had to deal with in the past few years, and one of the hardest to remediate given t= hat clients are hard to update and sometimes the things they relied on were i= rremediably lost. This is why I am inclined to put in here strong language.<= o:p>

That said: I have nothing against client developers examining a netw= ork trace and drawing conclusions based on the content of what they see. Tha= t doesn=E2=80=99t create any hard dependencies and has no implications in respect to changes in the solution behavior. How= ever I am not sure how to phrase that in the specification, given that refer= ring to the client inevitably refers to its code. I am open to suggestions.<= o:p>

 

>  3)=E2=80=A6

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

I think the key might be   

> a client should be able to choose whether it wishes the sub c= laim to contain [..]

I don=E2=80=99t think that should be a choice left to the client. In= business systems, my experience is that the type of identifiers to be used (= when the IdP gives any choice at all)  is established at resource provisioning time. I am not aware of mechanisms thr= u which a client signals the nature of the identifier to be used, nor that w= ould be fully feasible (the resource knows what it needs to perform its func= tion).

Furthermore:

> which has nothing to do with uniqueness since the value chan= ges for every generated token.

Again, this is something that was touched on in my former reply to y= our message. As long as an identifier identifies one resource only, it satis= fies uniqueness. It doesn=E2=80=99t have to be a singleton.

Finally, the scope is optional (for good reasons: 1st par= ty and non delegation scenarios don=E2=80=99t require it) hence it cannot be= relied upon for properties that should hold in every scenario.

In summary: per the preceding thread on this topic, the consensus wa= s that varying the sub content was a satisfactory way of protecting against c= orrelation. I don=E2=80=99t a gree that clients should have a mechanism to request different sub flavors, as that d= ecision should be done out of band by the AS and RS; and the scope isn=E2=80= =99t always available anyway.

> targeting of access tokens

Let me think about that a bit longer.

I acknowledge that the decision of including an audience has the eff= ect of letting the AS track when the client accesses a particular resource, b= ut at the same time that=E2=80=99s completely mainstream and very much by design in a very large number of cases. As such= , I find the language you are suggesting to be potentially confusing, as it p= ositions this as an exception vs a privacy protecting mainstream that is in f= act not common, and ascribes to the client more latitude than I believe is legitimate to expect or grant= .

I=E2=80=99ll try to come up with concise language that clarifies to t= he reader that the current mechanism does allow AS tracking.   

 

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

 

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

1) The title of this spec. is:

JSON Web Token (JWT) Pr= ofile for OAuth 2.0 Access Tokens

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

Currently, it is : 

Internet-Draft       OAuth Access Toke= n JWT Profile           Ap= ril 2020

It should rather be:

Internet-Draft       OAuth 2.0 Access Token JWT Profile       = ;    April 2020

2) The following text is within section 6.

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

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

The above text should be replaced with:

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

The remaining of the text about this topic is fine.


3) The next topic is about the sub claim.

The text states:

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

I have a set of questions:

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

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

The syntax of the scope parameter is a list of space-delimited, case= -sensitive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being returned= , it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.
In theory, a client should be able to choose whether it wishes the sub claim= to contain :

  • a global unique identifier for all ASs ("globally unique"),
    • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto;mso-list:l0 level1 lfo7"> a unique identifier for each AS ("locally unique in the context of the issue= r"),
  • a different pseudonym for each RS, or
  • a different pseudonym for each authorization token request.
    • <= /ul>

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

    RFC 7519 states is section 4.1.2:

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

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

    This has implications about the following text:

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

    Since it addresses case (c).

    and also about the following text:

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

    Since it addresses case (d).

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

    Proposed text replacement for all the previously quoted sentences:

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

    When the sub claim contains a globally unique identifier, this allows to cor= relate principal activities across multiple resource servers, while in addit= ion,
    this globally unique identifier may also allow to correlate the principal ac= tivities on servers where no access has been performed by the principals
    to these servers but where the same globally unique identifiers are being us= ed by these servers.

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

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

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

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

    Considering the semantics of the sub claim, these two cases cannot be curren= tly supported.


    4) The next topic is about the targeting of access tokens<= /p>

    Text had been proposed before the last conference call. Then, the to= pic has been presented at the very end of the last conference call, but no t= ext has been included
    in the next draft.

    Here is a revised text be included in the privacy considerations sec= tion:

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

    Denis

Hi all,

 

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

 

Here is the document:

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

 

Please send your comments to the OAuth mailing list by April 29, 2020.<= /o:p>

 

Regards,

 Rifaat & Hannes

 

 

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

 

 

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

IMPORTANT NOTICE: The contents of this email and any a= ttachments are confidential and may also be privileged. If you are not the i= ntended recipient, please notify the sender immediately and do not disclose t= he contents to any other person, use it for any purpose, or store or copy the information in any medium. Tha= nk you.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, ple= ase notify the sender immediately and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-BE2974D5-E213-4318-ADC1-4460C0C8C59C-- From nobody Thu Jun 4 19:23:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832013A1144 for ; Thu, 4 Jun 2020 19:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0y2AnzYYDwX for ; Thu, 4 Jun 2020 19:23:24 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC133A1146 for ; Thu, 4 Jun 2020 19:23:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.73,474,1583154000"; d="scan'208,217";a="377009174" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Jun 2020 12:23:19 +1000 Received: from wsapp6785.srv.dir.telstra.com ([10.75.3.134]) by ipcavi.tcif.telstra.com.au with ESMTP; 05 Jun 2020 12:23:18 +1000 Received: from wsapp5872.srv.dir.telstra.com (10.75.11.108) by wsapp6785.srv.dir.telstra.com (10.75.3.134) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 12:23:17 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5872.srv.dir.telstra.com (10.75.11.108) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 12:23:17 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Jun 2020 12:23:17 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUjZFFg1e8T7/tvGLYaLDQQ47laNrd8YTLE06WZqF5Az5GwVAFPv+1OffcRsSxJDWbD+Oz8AWoosaCXyI7HCiEjY87ysWs13fnmUJ3wpa4jpQWbf6mfileEfmb/hh6o00JEq9zbBuwp3u/YuxhtcqJOs/DAptWBHgMrfUaQcfyJ0tHV2Yp5kz/4yAnjM/aNrgqAyCTtNwnbnY36BC/ymlSmfJrrU58HRVv4UQuQT4ve1kq93UQOeFHQOQjTDH3ireAzBsbHA/XCvmKyZWHELx2FN0ucKLJeLXZ6+X/fiRZ2SCOyZaI6IKxxBVroKhElqA1E8RytGtq6ubcfppAgZgA== 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=o0lM8mXlHkppZ4QJQpwfpsr8IJgS17gtNMui94LbBTc=; b=SvcwFufgfWavLHoTrlaGFGZUUVAvZIer4HzNLzxqadeiXyTmHf38NN5WjhhNodh5O7aDpYjlT2E6jsFg/8md3hjDcyf9Oi4O+mmcwGiMVD2W4DrT7nwlHPlK4/rrn2u+gjembkNeMkd0pLRk9Sdrl15O8cPFe8jx77FoYSdHXa5MtanVSqqCz/hCR3N1VcJQnSXWbKI4frV6nQ7L0m3G+v1OFBeDHP2zLT84zl7cK6kBxwKAarCNVPR3jupFkceCFRVdq1i7E8Es7BPOGqP2ERCTITZv3pMwpUr1V3jC7bBLASLU+gJGoNDQfAtwijs61sxoXOoEu9S6wxgujPcqvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0lM8mXlHkppZ4QJQpwfpsr8IJgS17gtNMui94LbBTc=; b=UitxfbXnLHqoFXP2wTkPKcYwbpsg+n0EgrrItj7dNFin9qRmH+t+5CcUrQSHJTcUsXP/3s1u6jztRDvRgy0JGW7wTJd0si4yTBFMUZs3IGV3LWKEkdEsxX9ObbdbOHzIxKa4aK+ZvZNfaPsFEPbMJDbleOM0qSvV4X2euRpzbpo= Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by ME2PR01MB2610.ausprd01.prod.outlook.com (2603:10c6:201:16::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Fri, 5 Jun 2020 02:23:15 +0000 Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::7959:e5a7:16dc:e620]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::7959:e5a7:16dc:e620%7]) with mapi id 15.20.3066.018; Fri, 5 Jun 2020 02:23:15 +0000 From: "Manger, James" To: Joseph Heenan , Francis Pouatcha CC: Openid-specs-fapi , OAuth WG Thread-Topic: [OAUTH-WG] Issuers, Discovery Docs & Brands Thread-Index: AQHWNDCDDhHpSvSeYEGNG+LAGM0HA6jG7muAgAA8JACAAVvEAIAAr/0Q Date: Fri, 5 Jun 2020 02:23:15 +0000 Message-ID: References: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> In-Reply-To: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: authlete.com; dkim=none (message not signed) header.d=none;authlete.com; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [144.132.40.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 95625b6d-8025-4fa6-5de3-08d808f76770 x-ms-traffictypediagnostic: ME2PR01MB2610: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gCUSj/mev8nuFevdjzD+uYTyM+Zi5GuxBqEPGEPNXZo3r9GoCn/+CidCU9M12kgZBrTzBj9jK+OB6XNqICx+0PpDgupfX0OogtKZm+mPA8SRZTueT43DZ8RRcub0OUH4DSnngqUJeF2bNtZ2+i149sFZfdqWin0sRmWZu8paIH7a+oxlcKVfVlovuLu2q5yq5bHfin//SC/uDrUwZqgL9xDubhamYFPyx3OiB5tJjUFoc2de1TEKo7gkuoI8wAdC56n0Y1y9NmtwpGmhDPx6Dgi2vpzZHOAbaEiWa1fw1nzrQZNpj0gyhqzwbVXZiR3Un5wx7GnwUA7BHmUQ1+DZntUfn5JLrLKbfJTdIIu9fhiGNnlo6yyBvWpCzXUaqPdL1y6au89BEboQjcc7ml8ULQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(346002)(396003)(136003)(52536014)(76116006)(66556008)(71200400001)(66476007)(64756008)(66446008)(66946007)(478600001)(8936002)(4326008)(8676002)(33656002)(9686003)(186003)(55016002)(2906002)(26005)(6506007)(5660300002)(110136005)(316002)(166002)(54906003)(83380400001)(7696005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: eqcqINJxiNQumXZbJteG1ctdogl2ROfM3t762+5yfwO+RAMhkL1l5E7TAaSyr007TzcvKY9pU1rzgtQaYGVLgPgc26BGAHbGjJcvdpAhdOCHuH7Jw/nSgRwpG+0g/ywzhZ9mdXSm4PeINsuvIQFM1v7lI/WB8HiW6rCJMzJPioKWyNa0Q1bn35pj0akCLTg3UmhAkqgpCNneltxCTG8WrmR7Uuj0Xmj4V1tg/3pBBNlmvMtLJ6l7MsbBUfSGcRwhyXpMVO9TEYJ7bLHOIQYCT3cb69v/9dBD3+X6htLQqGea4onhaGHFX3wlha+kKVdFpl+I3Y0DyMs2Z+2TUbb2/fRbhxHcH/TDINqGiXspocVahFfxAGXHL5o+E5aHVWUGQxCQGwMCOkHyKNxOYtg9rlat1W6KebIlCoBCYHEYqKj8ZdLOpNBQldOKr+OD6rNLfSIOD3ttUXFN1VXnFv7oiGNdxsYoU8nFf0pvKHFTHp0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011FF24E2C95FF0BDB0287CE5860ME2PR01MB3011ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 95625b6d-8025-4fa6-5de3-08d808f76770 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 02:23:15.6857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I8AU0JuZhdlGkDaUZNPBcLfHCTbYOVBfFgmS42Q2VoLqVbJDCRazPsGX/Z7s7aV41QS9v622jw3fRzpFnGtonofJLLNNcmcSOoqZQLWKy/A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2610 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 02:23:27 -0000 --_000_ME2PR01MB3011FF24E2C95FF0BDB0287CE5860ME2PR01MB3011ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VkZ2luZyBzdXBwb3J0IGZvciBtdWx0aXBsZSBBdXRob3JpemF0aW9uIFNlcnZlciBicmFuZHMg dmlhIHRoaXMgImFsdGVybmF0aXZlX2F1dGhvcml6YXRpb25fZW5kcG9pbnRzIiBtZXRhZGF0YSBm aWVsZCBpcyBhIHZlcnkga2x1ZGd5IGhhY2suDQoNCj4gImFsdGVybmF0aXZlX2F1dGhvcml6YXRp b25fZW5kcG9pbnRzIjogew0KPiAgICAiYmFua2luZyI6IHsNCj4gICAgICAiYXV0aG9yaXphdGlv bl9lbmRwb2ludCI6ICJodHRwczovL2xvYWRzYW1vbmV5L2J1c2luZXNzL2F1dGgiLA0KPiAgICAg ICJkZXNjcmlwdGlvbiI6ICJsb2Fkc21vbmV5IGJ1c2luZXNzIGJhbmtpbmcgY3VzdG9tZXJzIiwN Cj4gICAgICAibG9nb191cmwiOiAiaHR0cHM6Ly9sb2Fkc2Ftb25leS9idXNpbmVzcy9sb2dvLnBu ZyINCj4gICAgfSwNCj4gICAgInBlcnNvbmFsIjogew0KPiAgICAgICJhdXRob3JpemF0aW9uX2Vu ZHBvaW50IjogImh0dHBzOi8vbG9hZHNhbW9uZXkvY29uc3VtZXIvYXV0aCIsDQo+ICAgICAgImRl c2NyaXB0aW9uIjogImxvYWRzbW9uZXkgcGVyc29uYWwgY3VzdG9tZXJzIiwNCj4gICAgICAibG9n b191cmwiOiAiaHR0cHM6Ly9sb2Fkc2Ftb25leS9jb25zdW1lci9sb2dvLnBuZyINCj4gICAgfQ0K PiAgfQ0KDQpJdCBhc3N1bWVzIG9ubHkgMSBwaWVjZSBvZiBtZXRhZGF0YSAoYXV0aG9yaXphdGlv bl9lbmRwb2ludCkgaXMgYnJhbmQtc3BlY2lmaWMsIGJ1dCBub25lIG9mIHRoZSBvdGhlciA1MCAo ZWcgdWlfbG9jYWxlc19zdXBwb3J0ZWQsIG9wX3Rvc191cmksIHNjb3Blc19zdXBwb3J0ZWQsIOKA pikgZnJvbSA0IGRpZmZlcmVudCBzcGVjcyBjdXJyZW50bHkgbGlzdGVkIGluIHRoZSBtZXRhZGF0 YSByZWdpc3RyeTxodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0 ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGE+ IChub3QgdG8gbWVudGlvbiB0aGUgb25lcyBpbiBkcmFmdCBzcGVjcyBub3QgcmVnaXN0ZXJlZCB5 ZXQpLg0KSXQgb2ZmZXJzIDEgbG9nbyAoaW4gb25lIHNpemUvcmVzb2x1dGlvbi9mb3JtYXQvY29s b3VyLXBhbGV0dGUv4oCmKSBhbmQgMSBkZXNjcmlwdGlvbiAoaW4gb25lIGxhbmd1YWdlKSwgd2hp Y2ggaXMgbGlrZWx5IHRvIGJlIHRvdGFsbHkgaW5hZGVxdWF0ZSBzbyB0aGUgc3VnZ2VzdGlvbiBp cyBwcm9iYWJseSBvbmx5IGEgZnJhY3Rpb24gb2YgdGhlIGFjdHVhbCBjb21wbGV4aXR5IHJlcXVp cmVkLg0KDQoNCklmIHlvdSB3YW50IHRvIGJ1aWxkIGEg4oCcY2hvb3NlcuKAnSB1c2VyLWludGVy ZmFjZSBhbGxvd2luZyBhIHVzZXIgdG8sIHNheSwgcGljayBiZXR3ZWVuIG11bHRpcGxlIGJhbmtz ICYgYnJhbmRzIHRoZW4gdGhhdCBuZWVkcyBhIHNvbHV0aW9uIHF1aXRlIGRpc3RpbmN0IGZyb20g QVMgbWV0YWRhdGEuDQoNCklmIHlvdSB3YW50IHRvIGFsbG93IGEgY2xpZW50IHRvIHJldXNlIDEg ZHluYW1pYyByZWdpc3RyYXRpb24gYWNyb3NzIG11bHRpcGxlIGJyYW5kcywgY291bGQgeW91IGNv bXBhcmUgdGhlIOKAnHJlZ2lzdHJhdGlvbl9lbmRwb2ludOKAnSBpbiBlYWNoIGJyYW5k4oCZcyBv d24gQVMgbWV0YWRhdGEgKGJlaW5nIGNhcmVmdWwgYSBtYWxpY2lvdXMgQVMgY2Fubm90IHRyaWNr IHRoZSBjbGllbnQgaW50byBzaGFyaW5nIHRoZSBjbGllbnTigJlzIGNyZWRzIGZyb20gYSB2aWN0 aW0gQVMpLiBPciBob3cgYWJvdXQgYW4g4oCcYXNzb2NpYXRlZF9pc3N1ZXLigJ0gbWVtYmVyIGhv bGRpbmcgYW4gYXJyYXkgb2YgaXNzdWVyIGlkZW50aWZpZXJzLiBJZiBpc3NBICYgaXNzQiBlYWNo IGxpc3QgZWFjaCBvdGhlciBpbiB0aGVpciDigJxhc3NvY2lhdGVkX2lzc3VlcuKAnSBtZXRhZGF0 YSwgdGhlbiBhIGNsaWVudCByZWdpc3RyYXRpb24gYXQgZWl0aGVyIGNhbiBiZSB1c2VkIGF0IHRo ZSBvdGhlci4NCg0KSWYgeW91IG1lcmVseSB3YW50IHRvIHRyaWdnZXIgYSBkaWZmZXJlbnQgbG9v ay1uLWZlZWwsIGRlZmluZSBhIOKAnGJyYW5k4oCdIHBhcmFtZXRlciB0byBhZGQgdGhlIHRvIHRo ZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_ME2PR01MB3011FF24E2C95FF0BDB0287CE5860ME2PR01MB3011ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldlZGdpbmcgc3VwcG9ydCBmb3IgbXVsdGlw bGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYnJhbmRzIHZpYSB0aGlzICZxdW90O2FsdGVybmF0aXZl X2F1dGhvcml6YXRpb25fZW5kcG9pbnRzJnF1b3Q7IG1ldGFkYXRhIGZpZWxkIGlzIGEgdmVyeSBr bHVkZ3kgaGFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jmd0OyAmcXVvdDthbHRlcm5hdGl2ZV9hdXRob3JpemF0aW9uX2Vu ZHBvaW50cyZxdW90OzogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtiYW5raW5nJnF1b3Q7OiB7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2F1dGhvcml6YXRp b25fZW5kcG9pbnQmcXVvdDs6ICZxdW90O2h0dHBzOi8vbG9hZHNhbW9uZXkvYnVzaW5lc3MvYXV0 aCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDs6ICZxdW90O2xvYWRzbW9uZXkg YnVzaW5lc3MgYmFua2luZyBjdXN0b21lcnMmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2xvZ29fdXJsJnF1 b3Q7OiAmcXVvdDtodHRwczovL2xvYWRzYW1vbmV5L2J1c2luZXNzL2xvZ28ucG5nJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3BlcnNv bmFsJnF1b3Q7OiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2F1dGhvcml6YXRpb25fZW5kcG9pbnQmcXVvdDs6ICZx dW90O2h0dHBzOi8vbG9hZHNhbW9uZXkvY29uc3VtZXIvYXV0aCZxdW90Oyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 ZGVzY3JpcHRpb24mcXVvdDs6ICZxdW90O2xvYWRzbW9uZXkgcGVyc29uYWwgY3VzdG9tZXJzJnF1 b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtsb2dvX3VybCZxdW90OzogJnF1b3Q7aHR0cHM6Ly9sb2Fkc2Ftb25l eS9jb25zdW1lci9sb2dvLnBuZyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7Jm5i c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SXQgYXNzdW1lcyBvbmx5IDEgcGllY2Ugb2YgbWV0YWRhdGEgKGF1dGhvcml6 YXRpb25fZW5kcG9pbnQpIGlzIGJyYW5kLXNwZWNpZmljLCBidXQgbm9uZSBvZiB0aGUgb3RoZXIg NTAgKGVnIHVpX2xvY2FsZXNfc3VwcG9ydGVkLCBvcF90b3NfdXJpLCBzY29wZXNfc3VwcG9ydGVk LCDigKYpIGZyb20gNCBkaWZmZXJlbnQgc3BlY3MgY3VycmVudGx5DQogbGlzdGVkIGluIHRoZSA8 YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJz L29hdXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGEiPg0K bWV0YWRhdGEgcmVnaXN0cnk8L2E+IChub3QgdG8gbWVudGlvbiB0aGUgb25lcyBpbiBkcmFmdCBz cGVjcyBub3QgcmVnaXN0ZXJlZCB5ZXQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXQg b2ZmZXJzIDEgbG9nbyAoaW4gb25lIHNpemUvcmVzb2x1dGlvbi9mb3JtYXQvY29sb3VyLXBhbGV0 dGUv4oCmKSBhbmQgMSBkZXNjcmlwdGlvbiAoaW4gb25lIGxhbmd1YWdlKSwgd2hpY2ggaXMgbGlr ZWx5IHRvIGJlIHRvdGFsbHkgaW5hZGVxdWF0ZSBzbyB0aGUgc3VnZ2VzdGlvbiBpcyBwcm9iYWJs eSBvbmx5IGEgZnJhY3Rpb24gb2YgdGhlDQogYWN0dWFsIGNvbXBsZXhpdHkgcmVxdWlyZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgeW91IHdhbnQgdG8gYnVp bGQgYSDigJxjaG9vc2Vy4oCdIHVzZXItaW50ZXJmYWNlIGFsbG93aW5nIGEgdXNlciB0bywgc2F5 LCBwaWNrIGJldHdlZW4gbXVsdGlwbGUgYmFua3MgJmFtcDsgYnJhbmRzIHRoZW4gdGhhdCBuZWVk cyBhIHNvbHV0aW9uIHF1aXRlIGRpc3RpbmN0IGZyb20gQVMgbWV0YWRhdGEuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHlv dSB3YW50IHRvIGFsbG93IGEgY2xpZW50IHRvIHJldXNlIDEgZHluYW1pYyByZWdpc3RyYXRpb24g YWNyb3NzIG11bHRpcGxlIGJyYW5kcywgY291bGQgeW91IGNvbXBhcmUgdGhlIOKAnHJlZ2lzdHJh dGlvbl9lbmRwb2ludOKAnSBpbiBlYWNoIGJyYW5k4oCZcyBvd24gQVMgbWV0YWRhdGEgKGJlaW5n IGNhcmVmdWwgYSBtYWxpY2lvdXMgQVMgY2Fubm90DQogdHJpY2sgdGhlIGNsaWVudCBpbnRvIHNo YXJpbmcgdGhlIGNsaWVudOKAmXMgY3JlZHMgZnJvbSBhIHZpY3RpbSBBUykuIE9yIGhvdyBhYm91 dCBhbiDigJxhc3NvY2lhdGVkX2lzc3VlcuKAnSBtZW1iZXIgaG9sZGluZyBhbiBhcnJheSBvZiBp c3N1ZXIgaWRlbnRpZmllcnMuIElmIGlzc0EgJmFtcDsgaXNzQiBlYWNoIGxpc3QgZWFjaCBvdGhl ciBpbiB0aGVpciDigJxhc3NvY2lhdGVkX2lzc3VlcuKAnSBtZXRhZGF0YSwgdGhlbiBhIGNsaWVu dCByZWdpc3RyYXRpb24gYXQNCiBlaXRoZXIgY2FuIGJlIHVzZWQgYXQgdGhlIG90aGVyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JZiB5b3UgbWVyZWx5IHdhbnQgdG8gdHJpZ2dlciBhIGRpZmZlcmVudCBsb29rLW4tZmVlbCwg ZGVmaW5lIGEg4oCcYnJhbmTigJ0gcGFyYW1ldGVyIHRvIGFkZCB0aGUgdG8gdGhlIGF1dGhvcml6 YXRpb24gcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ME2PR01MB3011FF24E2C95FF0BDB0287CE5860ME2PR01MB3011ausp_-- From nobody Fri Jun 5 00:52:23 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA253A1393 for ; Fri, 5 Jun 2020 00:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.425 X-Spam-Level: X-Spam-Status: No, score=0.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 OyZ-wfVmHY8r for ; Fri, 5 Jun 2020 00:52:17 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97643A1390 for ; Fri, 5 Jun 2020 00:52:15 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d90 with ME id nKsC2200E4FMSmm03KsCPh; Fri, 05 Jun 2020 09:52:13 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 05 Jun 2020 09:52:13 +0200 X-ME-IP: 86.238.65.197 To: Hannes Tschofenig Cc: Rifaat Shekh-Yusef , Vittorio Bertocci , "oauth@ietf.org" References: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <24ffa213-1a09-f7d1-28f8-e1b678cf85d9@free.fr> From: Denis Message-ID: Date: Fri, 5 Jun 2020 09:52:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7C329777D29714EBC316695" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 07:52:22 -0000 This is a multi-part message in MIME format. --------------E7C329777D29714EBC316695 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi  Hannes, Let us start by the last argument of this email which is copied below: Finally, there are still two questions that have been raised but which have not yet been answered at this time: * how can a client request a JWT compliant to /this/ profile, and * how can a client be confident that it got a JWT compliant to /this/ profile ? [Hannes] Regarding the two questions: It cannot and it was never the intention of this work. If this document was limited to section 2, it would simply be a description of a specific profile, but it is more than that since it includes two additional sections: 3. Requesting a JWT Access Token 4. Validating JWT Access Tokens In section 3, the text states:    If the request does not include a "resource" parameter, the authorization server *MUST* use in the "aud" claim   as default resource indicator. If the authorization server has no way to know that the client is sending a request which implies compliance with draft-ietf-oauth-access-token-jwt why should it behave in such a way ? In section 4 the text states:    resource servers receiving a JWT access token *MUST* validate it in the following manner If the resource server has no way to know that it is checking a JWT which is supposed to be compliant with draft-ietf-oauth-access-token-jwt why should it behave in such a way ? The responses to these two questions are important before handling the other comments. IMHO, a token type would be able to easily address the problem; otherwise sections 3 and 4 should be deleted. The remaining of my replies are within the text below prefixed with [Denis]. > Hi Denis, > > Please see my response below. > > *From:* Denis > *Sent:* Wednesday, June 3, 2020 12:12 PM > *To:* Hannes Tschofenig > *Cc:* Rifaat Shekh-Yusef ; Vittorio Bertocci > ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens" > > Hi Hannes, > > I do appreciate your efforts to attempt to get rid of the "MUST NOT" > in the "Privacy considerations" section. > > Let us look at the following proposed sentence: > > While this is technical possible, it is important to note that the > OAuth 2.0 protocol does not aim to expose the content of the access token >     to the client. The access token is therefore, by design, > considered to be opaque to the client". > / > In the context of this document/, a detailed content of the JWT is > expected and thus, if a client receives a JWT compliant to this profile > (and if the token is not encrypted which is most often the case) it > will absolutely be sure to pick up any guaranteed field within the JWT. > So, /in the context of this document/, the access token cannot be > considered to be opaque to the client. > > [Hannes] Here we have a disconnect. The OAuth 2.0 design does not > assume that the client inspects the access tokens if it flies by. This > document could not change that. > The purpose of this document is actually quite simple: Those who want > to use JWT as a format for access tokens they can use the claims > described in this document. > You are also free to use whatever format you want. > [Denis] You wrote: "The OAuth 2.0 design does not *assume *that the client inspects the access tokens if it flies by". However, there are cases where the client may be interested to know which attributes have been placed into the JWT, there should be some way(s) to be able to do it. Using Token Introspection (extended to be used by clients) would be like bringing in an elephant to kill a mouse. Using a local API would be a simple solution, however the IETF defines (most often) protocols rather than local APIs. The user's privacy cannot be fulfilled if the client is unable to know which attributes have been placed into the JWT. A solution to address this issue would be to clearly advertise the following in the Privacy Considerations section: As the OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by, clients have no way to know which identity attributes have effectively been placed into the JWT. Since these identity attributes may disclose more private information than what is strictly necessary to perform one or more operations, this may be a serious concern for users that care about their privacy. > About the second paragraph, /in the context of this document (/besides > the case where the JWT is encrypted), it is neither difficult, > nor impossible to parse the token/. > / > About the second paragraph, let us look at the following proposed > sentence/in the context of this document/ : > >     " Additionally, there is no guarantee that the access token is > conveyed by value and the authorization server implementation may change >       the token format at any time ". > > The argumentation that the token format may change at any point of > time, while being valid in the general case, is invalid /in the > context of this document/. > This JWT profile will be stable over time. This means that this quoted > sentence is inappropriate /in the context of this document/. > > [Hannes] Here is the issue. In a given deployment you do not know how > the access token is encoded nor whether the claims are in this format. > You don’t know whether the token is conveyed by reference or by value. > Hence, why should we suddenly even give developers the impression > that OAuth Clients should look at the token. > [Denis] OAuth clients SHOULD only look at the attributes placed into the JWT, when/if they have privacy concerns about the identity attributes that have been placed into the JWT. Otherwise, they would have no idea on how they could be traced by the resources servers /and other servers // //that don't use OAuth/. In the current situation, it appears necessary to clearly advertise in the Privacy Considerations section that the token opacity may be a serious concern for users that care about their privacy. It is also important to note that the /foundational design assumption /of keeping access tokens opaque to clients (and their users) is closing the door to any confidence for clients that their privacy is indeed preserved by the authorization servers. > The third proposed paragraph is stating : > >     "In scenarios where it is where it is desirable for the clients to > obtain information transmitted in the access token, OAuth 2.0 token > introspection >       may provide a useful tool to enable such functionality (proper > authorization assumed) ". > > RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by > protected resources, but is not a protocol to be used by clients. > As indicated, in order to be usable, a "proper authorization" also > needs to be managed. Besides the difficulty to support such a protocol > for clients > and to twist its original usage as defined in RFC 7662, it is simpler > to develop the code to examine the content of the JWT, since its > content is guaranteed > to be stable over time. > > [Hannes] While it may be simpler to inspect the access token, the use > of token introspection is a better match for the OAuth architecture. > We can talk about updating the token introspection RFC to also > describe this use case, assuming there is interest. > [Denis] Updating the token introspection RFC would be like bringing a bull in a china shop. > The question in general will surface why the client should get access > to the content of the access token in the first place. > For those cases where information is passed to the client other > mechanisms, such as the identity token in OIDC, have been developed. > [Denis] The reason has been explained above: it has to do with correlation of the users by different resources servers, but also by other servers when "globally unique identifiers" are being used in the "sub" claim. > The last proposed paragraph is the following: > >    " Since the content of the access token is accessible to the > resource server it is important to evaluate whether the resource > server gained the proper entitlement >       to have access to any content received in form of claims, /for > example through user consent in some form, policies and agreements > with the organization running / > /      the authorization servers, and so on/. The policies and the > user interfaces to enable this user consent are, however, part of a > specific deployment and therefore >       outside the scope of this document ". > > The sentence "for example through user consent in some form, policies > and agreements with the organization running the authorization > servers, and so on" > should be removed, since this example lets believe that the consent is > handled by the authorizations servers while it might be handled by the > resource servers. > > [Hannes] The information is disclosed by the authorization server and > hence the consent has to be with the authorization server. > > The last proposed paragraph would be solution neutral if the example > were removed. This would lead to the following sentence: > > Since the content of the access token is accessible to the resource > server it is important to evaluate whether the resource server gained > the proper entitlement > to have access to any content received in form of claims. The policies > and the user interfaces to enable this user consent are, however, part > of a specific deployment > and therefore outside the scope of this document. > [Denis] A resource server may say: "In order to perform this operation , I need your date of birth". If the user agrees, then the client will ask to the authorization server to insert the date of birth of the user into the JWT. In this way, the consent is given by the client when talking to the resource server. The authorization server is not involved with a consent given by the user. Obviously, this is one scenario and other scenarios exist, but such a scenario should not be prevented. The AS does not need to know which operation will be performed by the user, it only needs to know that the user is willing his birth date to be included into the JWT. However, at the moment, since there is no RFC supporting such a possibility, asking for specific standardized attributes is not (yet) possible. > > Finally, there are still two questions that have been raised but which > have not yet been answered at this time: > > * how can a client request a JWT compliant to /this/ profile, and > * how can a client be confident that it got a JWT compliant to > /this/ profile ? > > [Hannes] Regarding the two questions: It cannot and it was never the > intention of this work. > [Denis] This point has been addressed at the top of this email. However, I would like to add one point. Let us suppose that a token type would be added both in the token request and within the token itself, and if, at the minimum, the client would  be allowed to access to this token type, saying "This token is conformant to RFC XXX", then the client would be able to call a local API able to disclose the content of the token. This would be like using a piece of cheese to catch the mouse. Denis > Ciao > > Hannes > > > Denis > > Let me try to jump in here in order to make a proposal for the > text in the privacy consideration section: > > FROM: > > *6* > *.  > Privacy Considerations* > >    As JWT access tokens carry information by value, it now becomes > >    possible for requestors and receivers to directly peek inside the > >    token claims collection.  The client MUST NOT inspect the > content of > >    the access token: the authorization server and the resource server > >    might decide to change token format at any time (for example by > >    switching from this profile to opaque tokens) hence any logic > in the > >    client relying on the ability to read the access token content > would > >    break without recourse. Nonetheless, authorization servers should > >    not assume that clients will comply with the above.  Whenever > client > >    access to the access token content presents privacy issues for a > >    given scenario, the authorization server should take explicit steps > >    to prevent it as described below. > >    In scenarios in which JWT access tokens are accessible to the end > >    user, it should be evaluated whether the information can be > accessed > >    without privacy violations (for example, if an end user would > simply > >    access his or her own personal information) or if steps must be > taken > >    to enforce cofidentiality. Possible measures include: > encrypting the > >    access token, encrypting the sensitive claims, omitting the > sensitive > >    claims or not using this profile, falling back on opaque access > >    tokens. > >    In every scenario, the content of the JWT access token will > >    eventually be accessible to the resource server.  It's important to > >    evaluate whether the resource server gained the proper > entitlement to > >    have access to any content received in form of claims, for example > >    through user consent in some form, policies and agreements with the > >    organization running the authorization servers, and so on. > > TO: > > *6 > . > Privacy Considerations* > >    The design of OAuth 2.0 envisions that access tokens are > created by > >    authorization servers and consumed by resource servers. > >    As JWT access tokens, as described in this document, carry > information by value, it is > >    possible for OAuth clients to peek inside the access token. > >    While this is technical possible, it is important to note that the > >    OAuth 2.0 protocol does not aim to expose the content of the > >    access token to the client. The access token is therefore, by > design, considered to be > >    opaque to the client. > >    A number of cases may make it difficult or impossible for > clients to > >    inspect the token, for example, the access token may be encrypted, > >    the access token may contain vendor-specific claims that have > not been > >    standardized or have been standardized in other consortia > making parsing > >    of the token difficult. Additionally, there is no guarantee > that the > >    access token is conveyed by value and the authorization server > implementation > >    may change the token format at any time. > >    In scenarios where it is desirable for the clients to obtain > information > >    transmitted in the access token, OAuth 2.0 token introspection > may provide > >    a useful tool to enable such functionality (proper > authorization assumed). > >    In scenarios where the content of the access token must not be > readable > >    by clients, encrypting the content of the access token is > RECOMMENDED. > >    Since the content of the access token is accessible to the > resource server > >    it is important to > >    evaluate whether the resource server gained the proper > entitlement to > >    have access to any content received in form of claims, for example > >    through user consent in some form, policies and agreements with the > >    organization running the authorization servers, and so on. The > policies > >    and the user interfaces to enable this user consent are, > however, part > >    of a specific deployment and therefore outside the scope of > this document. > > How does this sound? > > Ciao > > Hannes > > *From:* OAuth > *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Thursday, May 14, 2020 8:03 PM > *To:* Denis > *Cc:* Vittorio Bertocci > ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) > Profile for OAuth 2.0 Access Tokens" > > Denis, > > You are rehashing the same issues that you have already discussed > on the mailing list multiple times, > > You could not get the WG to agree with your points, because the WG > believe that this issue is outside the scope of this document. > > The best the chairs can do at this stage is to capture your point > in the shepherd write-up to the IESG. > > We think this document has the support of the WG and is ready to > move forward. > > Regards, > >  Rifaat > > On Thu, May 14, 2020 at 12:29 PM Denis > wrote: > > Hi Vittorio, > > I am referring to the email you sent on April the 29 th which > is copied below. > > 1) You wrote: > > /> targeting of access tokens/ > > Let me think about that a bit longer. > > I acknowledge that the decision of including an audience > has the effect of letting the AS track when the client > accesses a particular resource, > but at the same time that’s completely mainstream and very > much by design in a very large number of cases. As such, I > find the language > you are suggesting to be potentially confusing, as it > positions this as an exception vs a privacy protecting > mainstream that is in fact not common, > and ascribes to the client more latitude than I believe is > legitimate to expect or grant. > > *I’ll try to come up with concise language that clarifies > to the reader that the current mechanism does allow AS > tracking*. > > Since the last draft has been published on the 27 th, you have > not proposed any "concise language that clarifies to the reader > that the current mechanism does allow AS tracking". > > 2) You also wrote about the "sub" uniqueness: > > As long as an identifier identifies one resource only, it > satisfies uniqueness. It doesn’t have to be a singleton. > > RFC 7519 defines in section 4.1.2 the semantics of the "sub" > claim using the following sentence: > > The subject value MUST either be scoped to be locally > unique in the context of the issuer or be globally unique. > > The text does NOT say that the subject value "MUST be scoped > to be locally unique in the context of the *resource server*". > > Changing the semantics of an already defined claim is not > permitted. If you would like to have such a semantics available, > a new claim should be defined (and it would be very nice to > have it !). > > 3) The text is the privacy considerations section states: > >    Although the ability to correlate requests might be > required by design in many scenarios, there are scenarios > where the authorization >    server might want to prevent correlation to preserve the > desired level of privacy. > > In the real world, it is also clients or end-users which would > like to prevent correlation to preserve their desired level of > privacy. > > A better sentence would be: > >    Although the ability to correlate requests might be > required by design in many scenarios, there are scenarios > where the authorization >    server *or the client* might want to prevent correlation to > preserve the desired level of privacy. > > 4) The text continues with: > >    Authorization servers should choose how to assign "sub" > values according to the level of privacy required by each >    situation.  For instance: if a solution requires preventing > tracking  principal activities across multiple resource servers, >    the  authorization server should ensure that JWT access > tokens meant for different resource servers have distinct "sub" >    values that cannot be correlated in the event of resource > servers collusion. > > Authorization servers are not necessarily able to choose the > level of privacy required by each situation. When there are > different > situations for the same resource server, the scope is > (unfortunately at the moment) the only way to select the > "level of privacy that is required". > > The example ("For instance:") is only an example that provides > a vague recommendation for the ASs which is NOT conformant > with the semantics of the "sub" claim as defined in RFC 7519. > > What should be discussed here are not "examples" or what an > authorization server should do, but explanations about the > implications > for the end-user or for the client for the various values that > can be placed into the "sub" claim by an AS. The problem is > wider that simply > a collusion between resource servers, but also with other > servers that DO NOT participate in any OAuth exchange. > > RFC 6973 (Privacy Considerations) states in section 7 : Guidelines > > This section provides guidance for document authors in the > form of a questionnaire about a protocol being designed. > The questionnaire may be useful at any point in the design > process, particularly after document authors have developed > a high-level protocol model as described in [RFC4101]. > > One of the questions is: > > f. *Correlation*.  Does the protocol allow for correlation > of identifiers ?  Are there expected ways that information > exposed > by the protocol will be combined or *correlated with > information obtained outside the protocol* ? > > It is important to provide an answer to these two questions. > > Hereafter is some text that is fully conformant with RFC 7519 > which should be incorporated into the privacy considerations > section > which explains the implications of the two (and only two) > flavours of the "sub" claim. > > When the sub claim contains a locally unique identifier in > the context of the issuer, this allows the tracking of > principal activities > across multiple resource servers. > > When the sub claim contains a globally unique identifier, > this allows to correlate principal activities across > multiple resource > servers, while in addition, this globally unique > identifier may also allow to correlate the principal > activities on servers where > no access has been performed by the principals to these > servers but where the same globally unique identifiers are > being used > by these servers. > > Denis > > Thanks Denis for the thorough commentary. > > /> The title of this spec./ > > Fixed, thanks! > > /> The client MUST NOT inspect the content of the access > token/ > > This is really a sticky point. I really want to > acknowledge your PoV on this, but at the same time I found > this to be one of the biggest sources of issues in the use > of JWT for access tokens hence I feel we really need to > give solid guidance here. Let me expand further on the > reasoning behind it, and perhaps we can get to language > that satisfies both PoVs. > > To me the key point is that clients should not write > /code/ that inspects access tokens. Taking a dependency on > the ability to do so is ignoring fundamental information > about the architecture and relationships between OAuth > roles, and suggests an ability of the client to understand > the semantic of the content that cannot be assumed in the > general case. I expanded on the details in my former reply > to you on this topic, I would recommend referring to it. > Clients violating this simple principle has been one of > the most common sources of production issues I had to deal > with in the past few years, and one of the hardest to > remediate given that clients are hard to update and > sometimes the things they relied on were irremediably > lost. This is why I am inclined to put in here strong > language. > > That said: I have nothing against client developers > examining a network trace and drawing conclusions based on > the content of what they see. That doesn’t create any hard > dependencies and has no implications in respect to changes > in the solution behavior. However I am not sure how to > phrase that in the specification, given that referring to > the client inevitably refers to its code. I am open to > suggestions. > > >  3)… > > I have a pretty hard time following the chain of reasoning > in this section. Let me attempt to tackle it to the best > of my understanding. > > I think the key might be > > /> a client should be able to choose whether it wishes the > sub claim to contain [..]/ > > I don’t think that should be a choice left to the client. > In business systems, my experience is that the type of > identifiers to be used (when the IdP gives any choice at > all)  is established at resource provisioning time. I am > not aware of mechanisms thru which a client signals the > nature of the identifier to be used, nor that would be > fully feasible (the resource knows what it needs to > perform its function). > > Furthermore: > > /> which has nothing to do with uniqueness since the value > changes for every generated token./ > > Again, this is something that was touched on in my former > reply to your message. As long as an identifier identifies > one resource only, it satisfies uniqueness. It doesn’t > have to be a singleton. > > Finally, the scope is optional (for good reasons: 1^st > party and non delegation scenarios don’t require it) hence > it cannot be relied upon for properties that should hold > in every scenario. > > In summary: per the preceding thread on this topic, the > consensus was that varying the sub content was a > satisfactory way of protecting against correlation. I > don’t a gree that clients should have a mechanism to > request different sub flavors, as that decision should be > done out of band by the AS and RS; and the scope isn’t > always available anyway. > > /> targeting of access tokens/ > > Let me think about that a bit longer. > > I acknowledge that the decision of including an audience > has the effect of letting the AS track when the client > accesses a particular resource, but at the same time > that’s completely mainstream and very much by design in a > very large number of cases. As such, I find the language > you are suggesting to be potentially confusing, as it > positions this as an exception vs a privacy protecting > mainstream that is in fact not common, and ascribes to the > client more latitude than I believe is legitimate to > expect or grant. > > I’ll try to come up with concise language that clarifies > to the reader that the current mechanism does allow AS > tracking. > > *From: *OAuth > on behalf of Denis > > *Date: *Wednesday, April 29, 2020 at 09:12 > *To: *"oauth@ietf.org" > > *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token > (JWT) Profile for OAuth 2.0 Access Tokens" > > You will find four comments numbered 1) to 4). > > *1) *The title of this spec. is: > > JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens > > So, this spec. is supposed to be targeted to OAuth *2.0. > * However, the header at the top of the page omits to > mention it. > > Currently, it is : > > Internet-Draft OAuth Access Token JWT Profile           > April 2020 > > It should rather be: > > Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020 > > *2)* The following text is within section 6. > > The client MUST NOT inspect the content of > the access token: the authorization server and the > resource server > might decide to change token format at any time (for > example by > switching from this profile to opaque tokens) hence any > logic in the > client relying on the ability to read the access token > content would > break without recourse. > Nonetheless, authorization servers should > not assume that clients will comply with the above. > > It is of a primary importance that clients MAY be able to > inspect tokens before transmitting them. > The "MUST NOT" is not acceptable. > > The above text should be replaced with: > > Reading the access token content may be useful for the > user to verify that > the access token content matches with its expectations.  > However, > the authorization server and the resource server might > decide to change the > token format at any time.  Thus, the client should not > expect to always be > in a position to read the access token content. > > The remaining of the text about this topic is fine. > > > *3) *The next topic is about the sub claim. > > The text states: > > Although the ability to correlate requests might be > required by > design in many scenarios, there are scenarios where the > authorization > server might want to prevent correlation to preserve the > desired > level of privacy. Authorization servers should choose how > to assign > sub values according to the level of privacy required by each > situation. > > I have a set of questions: > > 1. How can authorization servers choose how to assign sub > values according to the level of privacy required "by > each situation" ? > 2. How can authorization servers know the level of > privacy required "by each situation" ? > 3. How can the users be informed of the level of privacy > required "by each situation" ? > 4. How can the users *consent* with the level of privacy > required "by each situation" ? > > Currently, the request MUST include either a resource > parameter or an aud claim parameter, while it MAY include > a scope parameter. > > The syntax of the scope parameter is a list of > space-delimited, case-sensitive strings (RFC 6749). It is > thus subject to private agreements > between clients and Authorization Servers. Since the scope > is being returned, it is a primary importance that the > returned scope matches > with its expectations before transmitting the token to a > Resource Server. > > In theory, a client should be able to choose whether it > wishes the sub claim to contain : > > * a global unique identifier for all ASs ("globally > unique"), > * a unique identifier for each AS ("locally unique in > the context of the issuer"), > * a different pseudonym for each RS, or > * a different pseudonym for each authorization token > request. > > The only variable parameter that it can use for this > purpose in the token request is the scope parameter. > > RFC 7519 states is section 4.1.2: > > The subject value MUST either be scoped to be locally > unique in the context of the issuer > or be globally unique. > > It is quite hard to recognize that the sub claim is able > to carry a different pseudonym for each RS, i.e. for case > (c), or > a different pseudonym for each authorization token > request, i.e. for case (d), which has nothing to do with > uniqueness > since the value changes for every generated token. > > This has implications about the following text: > > For instance: if a solution requires preventing tracking > principal activities across multiple resource servers, the > authorization server should ensure that JWT access tokens > meant for > different resource servers have distinct sub values that > cannot be > correlated in the event of resource servers collusion. > > Since it addresses case (c). > > and also about the following text: > > 4.b) Similarly: if a solution requires preventing a > resource server from > correlating the principal’s activity within the resource > itself, the > authorization server should assign different sub values > for every JWT > access token issued. > > Since it addresses case (d). > > This means that the current text placed in the privacy > considerations section was a good attempt to address the > case, > but that the text needs to be revised. > > Proposed text replacement for all the previously quoted > sentences: > > According to RFC 7519 (4.1.2): The subject value MUST > either be scoped to be locally unique in the context of > the issuer or be globally unique. > > When the sub claim contains a globally unique identifier, > this allows to correlate principal activities across > multiple resource servers, while in addition, > this globally unique identifier may also allow to > correlate the principal activities on servers where no > access has been performed by the principals > to these servers but where the same globally unique > identifiers are being used by these servers. > > When the sub claim contains a locally unique identifier in > the context of the issuer, this also allows the tracking > of principal activities across multiple resource servers. > > The scope request parameter is the only way to influence > on the content of the sub claim parameter. Its meaning is > subject to a private agreement > between the client and the AS, which means that the use of > the scope parameter is the only way to choose between a > locally unique identifier > in the context of the issuer or a globally unique identifier. > > Since the scope parameter is being returned, it is a > primary importance that the returned scope matches with > the expectations of the client before transmitting > the token to a Resource Server. > > However, there are other cases where the client would like > to be able to choose whether it wishes the sub claim to > contain : >     - a different pseudonym for each RS so that different > resource servers will be unable to correlate its > activities, or >     - a different pseudonym for each authorization token > request, so that the same resource server cannot correlate > its activities performed at different instant of time. > > Considering the semantics of the sub claim, these two > cases cannot be currently supported. > > > *4) *The next topic is about the targeting of access tokens > > Text had been proposed before the last conference call. > Then, the topic has been presented at the very end of the > last conference call, but no text has been included > in the next draft. > > Here is a revised text be included in the privacy > considerations section: > > For security reasons, some clients may be willing to > target their access tokens but, for privacy reasons, may > be unwilling to disclose to Authorization Servers > an identification of the Resource Servers they are going > to access, so that Authorization Servers will be unable to > know which resources servers are being accessed. > The disclosure of the Resource Servers names allows the > Authorization Servers to list all the Resource Servers > being access by all its users and in addition to list pairs > of (Principal, Resource Servers) which allow to trace all > the users accesses to Resource Servers performed through a > given Authorization Server. When a token is targeted, > this profile does not contain provisions to address these > two threats. > > Denis > > Hi all, > > This is a second working group last call for "JSON Web > Token (JWT) Profile for OAuth 2.0 Access Tokens". > > Here is the document: > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06 > > Please send your comments to the OAuth mailing list by > April 29, 2020. > > Regards, > >  Rifaat & Hannes > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please notify the sender immediately and do > not disclose the contents to any other person, use it for any > purpose, or store or copy the information in any medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. --------------E7C329777D29714EBC316695 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi  Hannes,

Let us start by the last argument of this email which is copied below:
Finally, there are still two questions that have been raised but which have not yet been answered at this time:
  • how can a client request a JWT compliant to this profile, and
  • how can a client be confident that it got a JWT compliant to this profile ?

 

[Hannes] Regarding the two questions: It cannot and it was never the intention of this work.

If this document was limited to section 2, it would simply be a description of a specific profile, but it is more than that
since it includes two additional sections:

3. Requesting a JWT Access Token
4. Validating JWT Access Tokens

In section 3, the text states:


   If the request does not include a "resource" parameter, the authorization server MUST use in the "aud" claim
  as default resource indicator.

If the authorization server has no way to know that the client is sending a request which implies compliance
with draft-ietf-oauth-access-token-jwt why should it behave in such a way ?


In section 4 the text states:


   resource servers receiving a JWT access token MUST validate it in the following manner


If the resource server has no way to know that it is checking a JWT which is supposed to be compliant
with draft-ietf-oauth-access-token-jwt why should it behave in such a way ?


The responses to these two questions are important before handling the other comments.

IMHO, a token type would be able to easily address the problem; otherwise sections 3 and 4 should be deleted.


The remaining of my replies are within the text below prefixed with [Denis].

Hi Denis,

 

Please see my response below.

 

 

From: Denis <denis.ietf@free.fr>
Sent: Wednesday, June 3, 2020 12:12 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>; Vittorio Bertocci <vittorio.bertocci@auth0.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

 

Hi Hannes,

I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section.

Let us look at the following proposed sentence:

    While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token
    to the client. The access token is therefore, by design, considered to be opaque to the client".

In the context of this document, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile
(and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT.
So, in the context of this document, the access token cannot be considered to be opaque to the client.

[Hannes] Here we have a disconnect. The OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by. This document could not change that.
The purpose of this document is actually quite simple: Those who want to use JWT as a format for access tokens they can use the claims described in this document.
You are also free to use whatever format you want.

[Denis] You wrote: "The OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by". However, there are cases where
the client may be interested to know which attributes have been placed into the JWT, there should be some way(s) to be able to do it.
Using Token Introspection (extended to be used by clients) would be like bringing in an elephant to kill a mouse. Using a local API would be a simple
solution, however the IETF defines (most often) protocols rather than local APIs.

The user's privacy cannot be fulfilled if the client is unable to know which attributes have been placed into the JWT. A solution to address this issue
would be to clearly advertise the following in the Privacy Considerations section:

As the OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by, clients have no way to know which identity
attributes have effectively been placed into the JWT. Since these identity attributes may disclose more private information than what is strictly
necessary to perform one or more operations, this may be a serious concern for users that care about their privacy.

About the second paragraph, in the context of this document (besides the case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token.

About the second paragraph, let us look at the following proposed sentence in the context of this document :

    " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change
      the token format at any time ".

The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid in the context of this document.
This JWT profile will be stable over time. This means that this quoted sentence is inappropriate in the context of this document.

[Hannes] Here is the issue. In a given deployment you do not know how the access token is encoded nor whether the claims are in this format.
You don’t know whether the token is conveyed by reference or by value. Hence, why should we suddenly even give developers the impression
that OAuth Clients should look at the token.

[Denis] OAuth clients SHOULD only look at the attributes placed into the JWT, when/if they have privacy concerns about the identity attributes
that have been placed into the JWT. Otherwise, they would have no idea on how they could be traced by the resources servers and other servers
that don't use OAuth. In the current situation, it appears necessary to clearly advertise in the Privacy Considerations section that the token opacity
may be a serious concern for users that care about their privacy.

It is also important to note that the foundational design assumption of keeping access tokens opaque to clients (and their users) is closing the door
to any confidence for clients that their privacy is indeed preserved by the authorization servers.

 The third proposed paragraph is stating :

    " In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection
      may provide a useful tool to enable such functionality (proper authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients.
As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients
and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed
to be stable over time.

[Hannes] While it may be simpler to inspect the access token, the use of token introspection is a better match for the OAuth architecture.
We can talk about updating the token introspection RFC to also describe this use case, assuming there is interest.

[Denis] Updating the token introspection RFC would be like bringing a bull in a china shop.

The question in general will surface why the client should get access to the content of the access token in the first place.
For those cases where information is passed to the client other mechanisms, such as the identity token in OIDC, have been developed.

[Denis] The reason has been explained above: it has to do with correlation of the users by different resources servers,
but also by other servers when "globally unique identifiers" are being used in the "sub" claim.

The last proposed paragraph is the following:

   " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
      to have access to any content received in form of claims, for example through user consent in some form, policies and agreements with the organization running
      the authorization servers, and so on. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore
      outside the scope of this document ".

The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on"
should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers.

[Hannes] The information is disclosed by the authorization server and hence the consent has to be with the authorization server.

The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence:

Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment
and therefore outside the scope of this document.

[Denis] A resource server may say: "In order to perform this operation , I need your date of birth". If the user agrees, then the client will ask to the authorization
server to insert the date of birth of the user into the JWT. In this way, the consent is given by the client when talking to the resource server. The authorization
server is not involved with a consent given by the user. Obviously, this is one scenario and other scenarios exist, but such a scenario should not be prevented.

The AS does not need to know which operation will be performed by the user, it only needs to know that the user is willing his birth date to be included into the JWT.
However, at the moment, since there is no RFC supporting such a possibility, asking for specific standardized attributes is not (yet) possible.


Finally, there are still two questions that have been raised but which have not yet been answered at this time:

  • how can a client request a JWT compliant to this profile, and
  • how can a client be confident that it got a JWT compliant to this profile ?

 

[Hannes] Regarding the two questions: It cannot and it was never the intention of this work.

[Denis] This point has been addressed at the top of this email. However, I would like to add one point.

Let us suppose that a token type would be added both in the token request and within the token itself,
and if, at the minimum, the client would  be allowed to access to this token type, saying "This token is conformant to RFC XXX",
then the client would be able to call a local API able to disclose the content of the token.

This would be like using a piece of cheese to catch the mouse.

Denis

 

Ciao

Hannes

 


Denis

 

Let me try to jump in here in order to make a proposal for the text in the privacy consideration section:

 

FROM:

6.  Privacy Considerations

 

 

   As JWT access tokens carry information by value, it now becomes

   possible for requestors and receivers to directly peek inside the

   token claims collection.  The client MUST NOT inspect the content of

   the access token: the authorization server and the resource server

   might decide to change token format at any time (for example by

   switching from this profile to opaque tokens) hence any logic in the

   client relying on the ability to read the access token content would

   break without recourse.  Nonetheless, authorization servers should

   not assume that clients will comply with the above.  Whenever client

   access to the access token content presents privacy issues for a

   given scenario, the authorization server should take explicit steps

   to prevent it as described below.

 

   In scenarios in which JWT access tokens are accessible to the end

   user, it should be evaluated whether the information can be accessed

   without privacy violations (for example, if an end user would simply

   access his or her own personal information) or if steps must be taken

   to enforce cofidentiality.  Possible measures include: encrypting the

   access token, encrypting the sensitive claims, omitting the sensitive

   claims or not using this profile, falling back on opaque access

   tokens.

 

   In every scenario, the content of the JWT access token will

   eventually be accessible to the resource server.  It's important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on.

 

TO:

 

6.  Privacy Considerations

   The design of OAuth 2.0 envisions that access tokens are created by

   authorization servers and consumed by resource servers.

   As JWT access tokens, as described in this document, carry information by value, it is

   possible for OAuth clients to peek inside the access token.

   While this is technical possible, it is important to note that the

   OAuth 2.0 protocol does not aim to expose the content of the

   access token to the client. The access token is therefore, by design, considered to be

   opaque to the client.

 

   A number of cases may make it difficult or impossible for clients to

   inspect the token, for example, the access token may be encrypted,

   the access token may contain vendor-specific claims that have not been

   standardized or have been standardized in other consortia making parsing

   of the token difficult. Additionally, there is no guarantee that the

   access token is conveyed by value and the authorization server implementation

   may change the token format at any time.

 

   In scenarios where it is desirable for the clients to obtain information

   transmitted in the access token, OAuth 2.0 token introspection may provide

   a useful tool to enable such functionality (proper authorization assumed).

 

   In scenarios where the content of the access token must not be readable

   by clients, encrypting the content of the access token is RECOMMENDED.

  

   Since the content of the access token is accessible to the resource server

   it is important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on. The policies

   and the user interfaces to enable this user consent are, however, part

   of a specific deployment and therefore outside the scope of this document.

 

 

How does this sound?

 

Ciao

Hannes

 

 

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, May 14, 2020 8:03 PM
To: Denis <denis.ietf@free.fr>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

 

Denis,

 

You are rehashing the same issues that you have already discussed on the mailing list multiple times,

You could not get the WG to agree with your points, because the WG believe that this issue is outside the scope of this document.

 

The best the chairs can do at this stage is to capture your point in the shepherd write-up to the IESG.

We think this document has the support of the WG and is ready to move forward.

 

Regards,

 Rifaat

 

 

On Thu, May 14, 2020 at 12:29 PM Denis <denis.ietf@free.fr> wrote:

Hi Vittorio,

 

I am referring to the email you sent on April the 29 th which is copied below.

 

1) You wrote:

> targeting of access tokens

Let me think about that a bit longer.

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

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

Since the last draft has been published on the 27 th, you have not proposed any "concise language that clarifies to the reader
that the current mechanism does allow AS tracking".

 

2) You also wrote about the "sub" uniqueness:

As long as an identifier identifies one resource only, it satisfies uniqueness. It doesn’t have to be a singleton.

RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using the following sentence:

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

The text does NOT say that the subject value "MUST be scoped to be locally unique in the context of the resource server".

Changing the semantics of an already defined claim is not permitted. If you would like to have such a semantics available,
a new claim should be defined (and it would be very nice to have it !).

 

3) The text is the privacy considerations section states:

 

   Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization
   server might want to prevent correlation to preserve the desired level of privacy.

 

In the real world, it is also clients or end-users which would like to prevent correlation to preserve their desired level of privacy.

 

A better sentence would be:

 

   Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization
   server or the client might want to prevent correlation to preserve the desired level of privacy.

 

4) The text continues with:

 

   Authorization servers should choose how to assign "sub" values according to the level of privacy required by each
   situation.  For instance: if a solution requires preventing tracking  principal activities across multiple resource servers,
   the  authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub"
   values that cannot be correlated in the event of resource servers collusion. 

 

Authorization servers are not necessarily able to choose the level of privacy required by each situation. When there are different
situations for the same resource server, the scope is (unfortunately at the moment) the only way to select the "level of privacy that is required".

 

The example ("For instance:") is only an example that provides a vague recommendation for the ASs which is NOT conformant
with the semantics of the "sub" claim as defined in RFC 7519.

 

What should be discussed here are not "examples" or what an authorization server should do, but explanations about the implications
for the end-user or for the client for the various values that can be placed into the "sub" claim by an AS. The problem is wider that simply
a collusion between resource servers, but also with other servers that DO NOT participate in any OAuth exchange.

 

RFC 6973 (Privacy Considerations) states in section 7 : Guidelines

This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. 
The questionnaire may be useful at any point in the design process, particularly after document authors have developed
a high-level protocol model as described in [RFC4101].

One of the questions is:

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

It is important to provide an answer to these two questions.

 

Hereafter is some text that is fully conformant with RFC 7519 which should be incorporated into the privacy considerations section
which explains the implications of the two (and only two) flavours of the "sub" claim.

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

 

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

Denis

Thanks Denis for the thorough commentary.

 

> The title of this spec.

Fixed, thanks!

 

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

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

To me the key point is that clients should not write code that inspects access tokens. Taking a dependency on the ability to do so is ignoring fundamental information about the architecture and relationships between OAuth roles, and suggests an ability of the client to understand the semantic of the content that cannot be assumed in the general case. I expanded on the details in my former reply to you on this topic, I would recommend referring to it. Clients violating this simple principle has been one of the most common sources of production issues I had to deal with in the past few years, and one of the hardest to remediate given that clients are hard to update and sometimes the things they relied on were irremediably lost. This is why I am inclined to put in here strong language.

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

 

>  3)…

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

I think the key might be   

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

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

Furthermore:

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

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

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

In summary: per the preceding thread on this topic, the consensus was that varying the sub content was a satisfactory way of protecting against correlation. I don’t a gree that clients should have a mechanism to request different sub flavors, as that decision should be done out of band by the AS and RS; and the scope isn’t always available anyway.

> targeting of access tokens

Let me think about that a bit longer.

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

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

 

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

 

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

1) The title of this spec. is:

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

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

Currently, it is : 

Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft       OAuth 2.0 Access Token JWT Profile           April 2020

2) The following text is within section 6.

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

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

The above text should be replaced with:

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

The remaining of the text about this topic is fine.


3) The next topic is about the sub claim.

The text states:

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

I have a set of questions:

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

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

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

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

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

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

RFC 7519 states is section 4.1.2:

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

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

This has implications about the following text:

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

Since it addresses case (c).

and also about the following text:

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

Since it addresses case (d).

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

Proposed text replacement for all the previously quoted sentences:

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

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

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

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

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

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

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


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

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

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

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

Denis

Hi all,

 

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

 

Here is the document:

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

 

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

 

Regards,

 Rifaat & Hannes

 

 

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

 

 

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

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

 

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


--------------E7C329777D29714EBC316695-- From nobody Fri Jun 5 11:19:37 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D073A0D93 for ; Fri, 5 Jun 2020 11:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKPvsMrNIe7l for ; Fri, 5 Jun 2020 11:19:34 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38183A0D92 for ; Fri, 5 Jun 2020 11:19:33 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 577586D47 for ; Fri, 5 Jun 2020 18:19:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591381171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UbUjFHychnqRMLNFI9dOmh1ep2Xb7qEvDHx3UuYscxE=; b=Heg7A3FKGDckN/OQMNmj/icv6hVSmnVpZeoogb89z+BWcodAajPRgiyjShC23MIryUI74J 10NU5en6oCuYs1LGwLzEok+blUo8DzP6tgguWEDRV0YmWmT9e4WfGup69Xz2kehG2prMd6 MnivkR4dYG1S/Gl8VSsnsVeU6bgf4i4= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <9d96fb91-c6a2-63bf-0944-110102b63e2a@danielfett.de> Date: Fri, 5 Jun 2020 20:19:30 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2444845B30A025CF8C08FF23" Content-Language: en-US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591381171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UbUjFHychnqRMLNFI9dOmh1ep2Xb7qEvDHx3UuYscxE=; b=cXDpenA/0Myy3dhwEpt4A8/ToDqbBJP56e9YdPgB+UPXd1FrzAqy3tlbqJR4T72qJIllzh 6HSDzNCrh4dQIpMEWdgcj6maPBQ9iQ0rTJS0t2wjUDLa948IjhjdvGq9qdzedFKSujntCI fD5g4Lwzjb0KxYbwrjP+hE/hmP6Mrn0= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591381171; a=rsa-sha256; cv=none; b=V/E48+xODth3xxGy/GttEPSG8SfLGgrJdyXoAvgiFEseg7khlI6ScC3cudQXLGs1z9F+JF CwcEmUVFrjYwe/lHsLaOI1DcCWqhQpwWDJHsGRaPeA6VkE3j6wlSCGGbSliPxqGgJd9uhf tGNhy5d2hoLPqtTrLcwyy5r0ad8Avic= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: ++ Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Archived-At: Subject: Re: [OAUTH-WG] Virtual OAuth Security Workshop 2020, July 21-24 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 18:19:36 -0000 This is a multi-part message in MIME format. --------------2444845B30A025CF8C08FF23 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit We still have some of the three-hour workshop/tutorial slots open. If you're interested to give a workshop/tutorial, please submit a proposal here: https://docs.google.com/forms/d/e/1FAIpQLSfqHnsKRodCWom4j4f7j791gnoaz2XLTOTiGCv4F_Wl9cNQSQ/viewform -Daniel Am 31.05.20 um 17:52 schrieb Daniel Fett: > Website: https://osw2020.com/ > Registration: https://barcamptools.eu/oauth-security-workshop-2020/ > Twitter: https://twitter.com/secworkshop > > The OAuth Security Workshop 2020 will be held as a virtual event on July > 21 to 24. As Zoom Fatigue is a real thing, the workshop will be spread > over four days (compared to the originally planned three days). > > As in 2019, the OSW will be a mix of pre-scheduled tutorials and talks, > and an unconference part where every participant can propose and conduct > a session. Sessions in the unconference are often driven by recent > discussions in the community, but can also be used to deep-dive into > topics from the talks and tutorials, or to discuss or work on any > OAuth-related topic. > > The event will be free of charge. A prior registration is required: > https://barcamptools.eu/oauth-security-workshop-2020/ > > Schedule outline: > > July 21 (Tutorials/Workshops day): On the first day, we will have two > tutorial slots with up to 3 hours each. If needed, multiple tutorials > can run in parallel. > > July 22 (Talks day): The second day starts with the official opening of > the workshop, followed by two parallel tracks of talks with eight talk > slots each. Each talk is 25 minutes. > > July 23 and July 24 (Unconference days): At the beginning of each of the > two days, sessions are proposed and scheduled in the plenum. Sessions > can be anything from talks to open discussions or tutorials. We will > have up to three parallel session tracks with five slots each (four plus > closing on the last day), 45 minutes each. > > The precise times in various time zones can be found on the website: > https://osw2020.com/ > > The full schedule for talks and workshops will be published in June. > > Session proposals for the unconference part can be submitted ahead of > time on the registration website. > > > If you have any questions, feel free to contact me (mail@danielfett.de). > > -Daniel > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2444845B30A025CF8C08FF23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
We still have some of the three-hour workshop/tutorial slots open.

If you're interested to give a workshop/tutorial, please submit a proposal here: https://docs.google.com/forms/d/e/1FAIpQLSfqHnsKRodCWom4j4f7j791gnoaz2XLTOTiGCv4F_Wl9cNQSQ/viewform

-Daniel

Am 31.05.20 um 17:52 schrieb Daniel Fett:
Website: https://osw2020.com/
Registration: https://barcamptools.eu/oauth-security-workshop-2020/
Twitter: https://twitter.com/secworkshop

The OAuth Security Workshop 2020 will be held as a virtual event on July
21 to 24. As Zoom Fatigue is a real thing, the workshop will be spread
over four days (compared to the originally planned three days).

As in 2019, the OSW will be a mix of pre-scheduled tutorials and talks,
and an unconference part where every participant can propose and conduct
a session. Sessions in the unconference are often driven by recent
discussions in the community, but can also be used to deep-dive into
topics from the talks and tutorials, or to discuss or work on any
OAuth-related topic.

The event will be free of charge. A prior registration is required:
https://barcamptools.eu/oauth-security-workshop-2020/

Schedule outline:

July 21 (Tutorials/Workshops day): On the first day, we will have two
tutorial slots with up to 3 hours each. If needed, multiple tutorials
can run in parallel.

July 22 (Talks day): The second day starts with the official opening of
the workshop, followed by two parallel tracks of talks with eight talk
slots each. Each talk is 25 minutes.

July 23 and July 24 (Unconference days): At the beginning of each of the
two days, sessions are proposed and scheduled in the plenum. Sessions
can be anything from talks to open discussions or tutorials. We will
have up to three parallel session tracks with five slots each (four plus
closing on the last day), 45 minutes each.

The precise times in various time zones can be found on the website:
https://osw2020.com/

The full schedule for talks and workshops will be published in June.

Session proposals for the unconference part can be submitted ahead of
time on the registration website.


If you have any questions, feel free to contact me (mail@danielfett.de).

-Daniel

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


--------------2444845B30A025CF8C08FF23-- From nobody Fri Jun 5 13:17:27 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE03A09B1 for ; Fri, 5 Jun 2020 13:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7tGxbRWvA4qg for ; Fri, 5 Jun 2020 13:17:23 -0700 (PDT) Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65C63A09B7 for ; Fri, 5 Jun 2020 13:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1591388242; bh=mturvl+w8RbFC7C00E38+4KQQPdzuOtmCKe4VOG4QTk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=AS6QDgzERQahJYcZdZCI785Gm7Hy0hWP9EpVfSRvLKzGs7DcC092oylP4kj9gwRHXE5TFhAUQDM9QQNyseLA+nRs/uWx0pteLglWRn8SfXC4NfnpmBpZTZ33FfVD8hCbbqU//qDWEE7ipD0fee2cYgro5UQaUP3u60Uubv91ZBi1Jq6qsPjMZ7yToW1Sr2oZlckLUPeNXfQjrrASahKzFLDAZ55Wav+oziymPAuvuoKl0DjEP1Nv0qbAbudHcSBfBqukTbRtUybVaTjGUYS/3q5WoVIYuPPiJmzNLC+znt3e58ZcOquxfmUDxBryzpZ1ejbpT4LgIkwO14mIUKBBIw== X-YMail-OSG: eCnH9voVM1lgBl.JNxEl_cMfRnONDU6hpVV1n9xcxIkFsq6CWyoERgVkg85_LR2 YfZun5HTxjHdjb4DD6oXAmABSLTtnRez44.gONhrucHacnLu1vXivOYhMcJmtvvh8FbhltMWtArC ZlkmXkGn6lCQ3YImZwwUZbq96O2mT2a.5NiEXDPm9qwZZwCOoLtr.FDps0IwqTuiikTyqpzWg5yk ywmh0ynFUlKn8xFsmxkUa_YoujN0usHTrj67bbDyir1O7PZ2kNlLV1kMjBotpX74yi5kUnfF87Gk 8JHH9L5gvhFRSVUsVO.DFR.UpmFpSIIsVrbfTE6CBJYrEfWZJupQALDjyQZndb7Y40cJHfjXXQeO EAL3uk6ECLBt61eRmjw8wcWhquWgfGijJ6X14lyPm0LAcHFJ48oh00OoMEH8bpwTKmgg87USr0_q p.xuW7a62CS8gONmmK92ISJs_TEN5XVBW12vqXgzkdsqZewdz5cluYq7mIluC.zvZS9MoumMGkG1 ZO2NfE.6.ZxwIPXMHpDCNw8VJnE8_XuwMjStInvnpJ9aebIXGYayVidtOjZ2qzZUGFGjwa5S7TZ2 dmiYoISKqUo57RiivKS5qiNYw1SQ_qCC_va_r0J3YOcAA_ynKUf1WNxxY4o2O7jmJs97kxznEQrD RPixuFR487BgyFn4PZ8FvN5VrAATkkM5F3Z4YSjJXMoB6h_JJEWGXWFTYCjG4dKnMXFf7RxSusRe ZERMeR5UF2t.Nmuv5VkDMq6q5uSr0qXumetJ_K1sHbnISiCpzxio6leHtMg9.qYf3JRYNaR_VwnE qo_YpFn7.xIfBkCkC2goNhEvj1Z75yKSL8L5lFyTpfMfYKtd.796cpWh_KWmSXCjjr0O9JGlh5LX BtWYy9t5B.Nv6fUqa4ZVU.r4KbPQgKNS9ygkWSrq2qoNnWtohwGtzg5LhpGGl3XyZPwF_Tfm1sFS nbmDqJLTAhIHxLzH7rSKSIpcp9oA1CakBj936EmPr.PWuwWUXeScb2UHnCmBSuFWN_0HwkRq7rLw 9zf9Ku.JqvhnckL7lO4MvgkbqkFmZVqSyIeFpjBt.FIQAJPnv.uzajTM24x9572QoYMzYNWurlcg uwwelKq5OH1LnzbhKWtwcJ1T2jIhN.iqZTkb2KVBKeAUOMdQicZZ4M_ySd2ViSd6bkUhiwVSLjND qvOynm.V16qaXq19QzLQ9ch0D4WSqCqgDE1vUfwRqXzI6xQVkTvNbH1KucGaVaS.5ikA2bT3PlXm .aZ18LvSFpibqC1YgHAPe0ySKGkA641rZXDCZciTj4r2tykkXcG6F3Ko5s3yw1yuhkHJbCeMfSNu MKkyh8dPEYifTmoTWhMJpm.blYx.NlQFFsUS8oBJ7OJNU6KoKekSFNdGLshOv.T.eyuqO_13KXj1 JQc33Evwykr1ReE8ipA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Fri, 5 Jun 2020 20:17:22 +0000 Received: by smtp408.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a37857451b6bfd90dc49dc39c6d76d45; Fri, 05 Jun 2020 20:17:19 +0000 (UTC) To: Brian Campbell , Filip Skokan Cc: oauth References: From: George Fletcher Organization: AOL LLC Message-ID: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> Date: Fri, 5 Jun 2020 16:17:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------07AAB0DD09AEDC63523E00FD" Content-Language: en-US X-Mailer: WebService/1.1.16037 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 20:17:26 -0000 This is a multi-part message in MIME format. --------------07AAB0DD09AEDC63523E00FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The issue I see with sticking with the DPoP token_type is that from a roll_out perspective, ALL resource servers must be updated to support the new scheme and only then can the DPoP deployment start. For any wide ecosystem deployment that can be problematic. I don't have any great suggestions:( Secondly, I do think we need a way to allow for the refresh_token to be bound while leaving the access_tokens as bearer tokens. This adds useful security without impacting existing RS deployments. It was unclear from our interim meeting discussion how the client knows whether the refresh token has been bound to the public key or not. The AS can signal that the access_token is NOT bound by returning a token_type of "bearer" but we should think about adding addition response fields for the refresh token binding (e.g. "rt_token_type). Thanks, George On 5/29/20 5:50 PM, Brian Campbell wrote: > Apologies for the slow reply on this. No excuses other than life > sometimes happens. > > `token_type` is maybe not the clearest extension point (and one I've > arguably misused in OAuth MTLS > and the now defunct > Token Binding > and > admitted to being on the fence about in the issue you linked to > ). But it is the > extension point that was basically left in RFC 6749 to facilitate > this exact kind of thing (for MAC really but it's conceptually > similar in that it was an application level proof mechanism of sorts) > . The text from RFC 6749 sec 7.1 > is also copied > below. Note that a "client MUST NOT use an access token if it does > not understand the token type" so FWIW the client behaviours you > describe aren't in line with that. > > It still seems to be that using DPoP token_type is the appropriate > thing to do and that it can be defined to account and allow for mixed > token type situations. It would define that the DPoP authz scheme be > used as the authentication method to include the access token when > making a protected resource request. That definition can also include > falling back to using the Bearer authz scheme when/if so challenged > by a protected resource. > > > > 7.1 . Access Token > Types > > The access token type provides the client with the information > required to successfully utilize the access token to make a > protected resource request (along with type-specific attributes). > The client MUST NOT use an access token if it does not understand the > token type. > > For example, the "bearer" token type defined in [RFC6750 > ] is utilized by simply > including the access token string in the request: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the "mac" token type defined in [OAuth-HTTP-MAC > ] is > utilized by issuing a Message Authentication Code (MAC) key together > with the access token that is used to sign certain components of the > HTTP requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC > id="h480djs93hd8", nonce="274312:dj83hs9s", > mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" > > The above examples are provided for illustration purposes only. > Developers are advised to consult the [RFC6750 > ] and [OAuth-HTTP-MAC > ] > specifications before use. > > Each access token type definition specifies the additional > attributes (if any) sent to the client together with the > "access_token" response parameter. It also defines the HTTP > authentication method used to include the access token when making a > protected resource request. > > > > On Tue, May 19, 2020 at 7:20 AM Filip Skokan > wrote: > >> This is a RE: to yesterday's interim meeting discussion, largely >> related to the first rollout step where we want to constrain >> refresh tokens but leave protected resource access intact. >> >> I'll start off with a case that I hope we can agree is absolutely >> necessary for DPoP to solve - that is constraining refresh tokens >> for browser based applications. Now, *do we see this as a >> secondary objective? I think it should be on par with access token >> constraining.* SPAs using code flow and having access to refresh >> tokens as means against the continuous browser efforts to cut down >> on storage access is a real case servers will be eventually forced >> to adopt. >> >> Since rollout for DPoP needs to begin with the AS and Client >> supporting it (regardless what order i guess) there are going to be >> instances where the RS will be supporting both Bearer and DPoP at >> the same time. >> >> As discussed yesterday, the client shouldn't know/care and change >> its behaviour when it comes to using access tokens. >> >> *But what is the client behaviour we take for standard?* Because I >> can see two conflicting implementations in the wild >> >> 1. The client echoes the token_type it received from the token >> endpoint as the authorization scheme - (optionally) throws on >> unrecognized token type values 2. The client uses Bearer as a fixed >> authorization scheme and ignores the token_type it received >> >> #2 is an implementation which I suspect has no idea about DPoP, but >> if extended to send DPoP headers (through various mechanism - >> library extensions or even manipulating the `XMLHttpRequest` >> prototype) will >> >> - 🎉 get the benefit of having its Refresh Tokens bound - 🎉 most >> likely continue to work with RSs that only support Bearer - ❌ will >> cease to work with RSs that will adopt support for DPoP because >> it'll be using the wrong scheme, that is unless (🎉) RSs >> supporting DPoP choose to suspend the requirement to use the new >> scheme and instead depend on the presence of `cnf.jkt` as means to >> trigger DPoP validation. *Q: is that an acceptable thing to do?* >> >> Arguably, client behaviour #1 is what a client should be using if >> it supports other schemes besides Bearer. But it may as well be the >> behaviour of a client that has no clue about DPoP, right? Again, >> such client can be made to support DPoP in a SPA through >> manipulation of the XMLHttpRequest prototype, in which case the >> developer needs to do the same for the protected resource calls. >> But at this point the developer has to know which RS to apply DPoP >> to and which not - ergo - which to send Bearer vs. DPoP scheme to? >> The developer will have to write a whitelist of resource servers >> anyway - and there we get to the point where client has >> information and functionality that it shouldn't /need to/ have. >> >> Its great that we have token_type, authorization header schemes, >> etc..., but we don't seem have a well defined (or at least >> followed) behaviour for our clients around handling the token_type >> response values and their usage. >> >> A developer has to resolve to navigate this monkey course unless >> the RS definition on the AS is aware of the fact that the RS does >> support DPoP, so that the issued token_type is always correct for >> the RS. So, *should we make that a recommended way of 'indicating' >> when to issue Bearer vs DPoP access tokens?* >> >> What else could we do that doesn't give more decision making to >> the clients so that the very first step - *Refresh Tokens get >> constrained* - is achieved* but Protected Resource access is >> unaffected?* >> >> Note that this was not "a thing" for mTLS because it continues to >> use the Bearer scheme (for better or worse) and it completely omits >> possible continuous rollout or discussing what are the signals the >> RS must use to require mTLS to be used), same for the abandoned >> OAuth 2.0 Token Binding draft (also continued to use the Bearer >> scheme). >> >> I suspect we have just this opportunity to fix token types and >> their use and if we can't, we'll have to resolve to abandon that >> extension point as one that doesn't support continued rollout of >> real sender constraining mechanism (e.g. http signatures in the >> future) and just continue using Bearer because in the end, given >> that RSs could be relying on the presence of the cnf claim to >> figure out the token's constraining mechanism, would that be such a >> bad thing? >> >> Put it the other way around. By introducing Bearer scheme, do we >> actually gain anything of value that can't be gained through other >> means? >> >> Note that this message didn't start with the goal of questioning >> the new scheme use, it just sort of landed there... My pedantic >> nature would love to see the new scheme and token_type extension >> point used as it was meant to be but I also recognize the many >> issues it brings that could be sidestepped by not introducing it in >> the first place, all without losing capabilities. >> >> Previous material on the topic >> >> - https://github.com/danielfett/draft-dpop/issues/41, decision to >> break backwards compatibility amongst the authors - ML >> >> thread, in my opinion inconclusive, no consensus >> >> >> S pozdravem, *Filip Skokan* >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --------------07AAB0DD09AEDC63523E00FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The issue I see with sticking with the DPoP token_type is that from a roll_out perspective, ALL resource servers must be updated to support the new scheme and only then can the DPoP deployment start. For any wide ecosystem deployment that can be problematic. I don't have any great suggestions:(

Secondly, I do think we need a way to allow for the refresh_token to be bound while leaving the access_tokens as bearer tokens. This adds useful security without impacting existing RS deployments. It was unclear from our interim meeting discussion how the client knows whether the refresh token has been bound to the public key or not. The AS can signal that the access_token is NOT bound by returning a token_type of "bearer" but we should think about adding addition response fields for the refresh token binding (e.g. "rt_token_type).

Thanks,
George

On 5/29/20 5:50 PM, Brian Campbell wrote:
> Apologies for the slow reply on this. No excuses other than life > sometimes happens. > > `token_type` is maybe not the clearest extension point (and one I've > arguably misused in OAuth MTLS > <https://www.rfc-editor.org/rfc/rfc8705.html> and the now defunct > Token Binding > <https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08>and > admitted to being on the fence about in the issue you linked to > <https://github.com/danielfett/draft-dpop/issues/41>). But it is the > extension point that was basically left in RFC 6749 to facilitate > this exact kind of thing (for MAC really but it's conceptually > similar in that it was an application level proof mechanism of sorts) > . The text from RFC 6749 sec 7.1 > <https://tools.ietf.org/html/rfc6749?#section-7.1> is also copied > below. Note that a "client MUST NOT use an access token if it does > not understand the token type" so FWIW the client behaviours you > describe aren't in line with that. > > It still seems to be that using DPoP token_type is the appropriate > thing to do and that it can be defined to account and allow for mixed > token type situations. It would define that the DPoP authz scheme be > used as the authentication method to include the access token when > making a protected resource request. That definition can also include > falling back to using the Bearer authz scheme when/if so challenged > by a protected resource. > > <https://tools.ietf.org/html/rfc6749?#section-7.1> > > 7.1 <https://tools.ietf.org/html/rfc6749?#section-7.1>. Access Token > Types > > The access token type provides the client with the information > required to successfully utilize the access token to make a > protected resource request (along with type-specific attributes). > The client MUST NOT use an access token if it does not understand the > token type. > > For example, the "bearer" token type defined in [RFC6750 > <https://tools.ietf.org/html/rfc6750>] is utilized by simply > including the access token string in the request: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the "mac" token type defined in [OAuth-HTTP-MAC > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] is > utilized by issuing a Message Authentication Code (MAC) key together > with the access token that is used to sign certain components of the > HTTP requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC > id="h480djs93hd8", nonce="274312:dj83hs9s", > mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" > > The above examples are provided for illustration purposes only. > Developers are advised to consult the [RFC6750 > <https://tools.ietf.org/html/rfc6750>] and [OAuth-HTTP-MAC > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] > specifications before use. > > Each access token type definition specifies the additional > attributes (if any) sent to the client together with the > "access_token" response parameter. It also defines the HTTP > authentication method used to include the access token when making a > protected resource request. > > > > On Tue, May 19, 2020 at 7:20 AM Filip Skokan <panva.ip@gmail.com> > wrote: > >> This is a RE: to yesterday's interim meeting discussion, largely >> related to the first rollout step where we want to constrain >> refresh tokens but leave protected resource access intact. >> >> I'll start off with a case that I hope we can agree is absolutely >> necessary for DPoP to solve - that is constraining refresh tokens >> for browser based applications. Now, *do we see this as a >> secondary objective? I think it should be on par with access token >> constraining.* SPAs using code flow and having access to refresh >> tokens as means against the continuous browser efforts to cut down >> on storage access is a real case servers will be eventually forced >> to adopt. >> >> Since rollout for DPoP needs to begin with the AS and Client >> supporting it (regardless what order i guess) there are going to be >> instances where the RS will be supporting both Bearer and DPoP at >> the same time. >> >> As discussed yesterday, the client shouldn't know/care and change >> its behaviour when it comes to using access tokens. >> >> *But what is the client behaviour we take for standard?* Because I >> can see two conflicting implementations in the wild >> >> 1. The client echoes the token_type it received from the token >> endpoint as the authorization scheme - (optionally) throws on >> unrecognized token type values 2. The client uses Bearer as a fixed >> authorization scheme and ignores the token_type it received >> >> #2 is an implementation which I suspect has no idea about DPoP, but >> if extended to send DPoP headers (through various mechanism - >> library extensions or even manipulating the `XMLHttpRequest` >> prototype) will >> >> - 🎉 get the benefit of having its Refresh Tokens bound - 🎉 most >> likely continue to work with RSs that only support Bearer - ❌ will >> cease to work with RSs that will adopt support for DPoP because >> it'll be using the wrong scheme, that is unless (🎉) RSs >> supporting DPoP choose to suspend the requirement to use the new >> scheme and instead depend on the presence of `cnf.jkt` as means to >> trigger DPoP validation. *Q: is that an acceptable thing to do?* >> >> Arguably, client behaviour #1 is what a client should be using if >> it supports other schemes besides Bearer. But it may as well be the >> behaviour of a client that has no clue about DPoP, right? Again, >> such client can be made to support DPoP in a SPA through >> manipulation of the XMLHttpRequest prototype, in which case the >> developer needs to do the same for the protected resource calls. >> But at this point the developer has to know which RS to apply DPoP >> to and which not - ergo - which to send Bearer vs. DPoP scheme to? >> The developer will have to write a whitelist of resource servers >> anyway - and there we get to the point where client has >> information and functionality that it shouldn't /need to/ have. >> >> Its great that we have token_type, authorization header schemes, >> etc..., but we don't seem have a well defined (or at least >> followed) behaviour for our clients around handling the token_type >> response values and their usage. >> >> A developer has to resolve to navigate this monkey course unless >> the RS definition on the AS is aware of the fact that the RS does >> support DPoP, so that the issued token_type is always correct for >> the RS. So, *should we make that a recommended way of 'indicating' >> when to issue Bearer vs DPoP access tokens?* >> >> What else could we do that doesn't give more decision making to >> the clients so that the very first step - *Refresh Tokens get >> constrained* - is achieved* but Protected Resource access is >> unaffected?* >> >> Note that this was not "a thing" for mTLS because it continues to >> use the Bearer scheme (for better or worse) and it completely omits >> possible continuous rollout or discussing what are the signals the >> RS must use to require mTLS to be used), same for the abandoned >> OAuth 2.0 Token Binding draft (also continued to use the Bearer >> scheme). >> >> I suspect we have just this opportunity to fix token types and >> their use and if we can't, we'll have to resolve to abandon that >> extension point as one that doesn't support continued rollout of >> real sender constraining mechanism (e.g. http signatures in the >> future) and just continue using Bearer because in the end, given >> that RSs could be relying on the presence of the cnf claim to >> figure out the token's constraining mechanism, would that be such a >> bad thing? >> >> Put it the other way around. By introducing Bearer scheme, do we >> actually gain anything of value that can't be gained through other >> means? >> >> Note that this message didn't start with the goal of questioning >> the new scheme use, it just sort of landed there... My pedantic >> nature would love to see the new scheme and token_type extension >> point used as it was meant to be but I also recognize the many >> issues it brings that could be sidestepped by not introducing it in >> the first place, all without losing capabilities. >> >> Previous material on the topic >> >> - https://github.com/danielfett/draft-dpop/issues/41, decision to >> break backwards compatibility amongst the authors - ML >> <https://mailarchive.ietf.org/arch/browse/oauth/?q=%22DPoP%20-%20new%20authorization%20scheme%20%2F%20immediate%20usability%20concerns%22&gbt=1&index=> >> thread, in my opinion inconclusive, no consensus >> >> >> S pozdravem, *Filip Skokan* >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
--------------07AAB0DD09AEDC63523E00FD-- From nobody Sat Jun 6 01:06:16 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D53A0F34 for ; Sat, 6 Jun 2020 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAtHv90A32Ik for ; Sat, 6 Jun 2020 01:06:11 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76EC3A0F32 for ; Sat, 6 Jun 2020 01:06:10 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id k8so9248281edq.4 for ; Sat, 06 Jun 2020 01:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=D07SKWgrlsvEnd/YCdwVirIKTq87BhEMsmHCTZQFuzs=; b=KM5GW89wB2iNs4Jf5JsmwNf0MF+Rvqs84UZgjFUhc4MTNCxcK+25+oMJxhaHTULGkN vMj3kI5nCr4ct4j1tANO7l7i01nd2r4MQUEDgz1t+MRmEP32lKoI8nJsnYVl5xiZi3pp jEpuXgzIB6XplbR9eMDt2cfyIWvJHbSwTWJLMY8BEbBdJkyYUUrUpTDDDYM/T3jZTa3W roJ9J8U+h5+SATTUc+AJCkUAFipsJkUogFHiiDqghXmjCbY9+m1NptyY/ZL46aZ/A0kn O4cJWaQuGSNaM/Z9NYn6agPqPhmkt9JhPryJ+PiwuYcYseq9k8Nxjp/L5CY1yK6vPWtF 10Vw== 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=D07SKWgrlsvEnd/YCdwVirIKTq87BhEMsmHCTZQFuzs=; b=Aswe5lm+U41v0fSORIzEli9LiPTEtlqtIiUitNF+ObeFF4stQFQcdYNGNCe0Mwvl5D mo20lcLKNtrAHC+8cmksn5oupbqXM7CJ8QOKkXWA1KM1CVeqKxT+eHZcU2qh7IeEfDLb 4yE35wF7X8RzrHwO/8jY/J/h/yA3KiiMMKk29TSMZQlH2PrTF4PTuZHB2tzxlqa2V5Ra CS08m3ZTS2JB90SJXwHxwyFiJAaM/P/q6LGomIm2wAM7asfjVXOa3TDHXxRlIJpfWr22 U66M6UyR3a8rjVi6rD1l8r2SFmB0AtqjHgrWiY9A6JBUA6XQdnpnRCoAHe1NOmWdaJPj GN+g== X-Gm-Message-State: AOAM533CWQLAiFkBp3iloyZ8TnkFrAmw6W3/tdNUjac9e25LXkUIvDQQ botSy3/VVhSOaC8cpIqMHkZxgg== X-Google-Smtp-Source: ABdhPJyeUrHPlfsaNZEEQr76e/duNhX6K/5p/kOCFZMlpiAH1Xxv/UFIVJnV+BeEQv7yp87pbJpjJg== X-Received: by 2002:a05:6402:228d:: with SMTP id cw13mr13648579edb.150.1591430765817; Sat, 06 Jun 2020 01:06:05 -0700 (PDT) Received: from ?IPv6:2a01:598:90a7:28b3:f8be:3610:ba20:d03a? ([2a01:598:90a7:28b3:f8be:3610:ba20:d03a]) by smtp.gmail.com with ESMTPSA id x11sm435416ejv.81.2020.06.06.01.06.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 01:06:03 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-80A2A4E3-1B01-4375-8C59-B406E7DC3D74; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 6 Jun 2020 10:06:02 +0200 Message-Id: References: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> Cc: Brian Campbell , Filip Skokan , oauth In-Reply-To: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> To: George Fletcher X-Mailer: iPad Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 08:06:14 -0000 --Apple-Mail-80A2A4E3-1B01-4375-8C59-B406E7DC3D74 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 05.06.2020 um 22:17 schrieb George Fletcher : >=20 > Secondly, I do think we need a way to allow for the refresh_token to be bo= und while leaving the access_tokens as bearer tokens. This adds useful secur= ity without impacting existing RS deployments. +1 that=E2=80=99s a very useful feature= --Apple-Mail-80A2A4E3-1B01-4375-8C59-B406E7DC3D74 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjA2MDgwNjAyWjAvBgkqhkiG9w0BCQQxIgQg TlFPK3zGbUdYin2krC/jxaBEO7Z/K9FO7yzVKb/lVmgwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAafBsvtSanZW3YudXHI4UOBgxFXlNoqOGUpiY8Fu2NRFJ/h60eJAr sJJT/7D33Vi2NwNDJ7j5Hevj8AjgIqFE/q68TWYgtxDJQDtvzkHPFWNGFVHxzMCo/Lbdvfo7rDV5 hhkCMZ9RRTvFxDSD59fShfugI1K11COHmA8tnrlld2J+QLMy6ORFdvnlOtSq3tMZudXLf0luIWVb 6APSlDsMqulcv2s92hhSfyjia89qUhcnzq85cGjFdUGPmJrkBVZqktb53a+dokT/iemaqA+gm/m2 6Ml/RJNBYzbnbQhhuQIj06JDSbsRIP5xHgyU70zV0s76HiXjnQM7bx8mMXFj3gAAAAAAAA== --Apple-Mail-80A2A4E3-1B01-4375-8C59-B406E7DC3D74-- From nobody Sat Jun 6 01:45:24 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3503A0F9E for ; Sat, 6 Jun 2020 01:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULr51-DuFFnH for ; Sat, 6 Jun 2020 01:45:22 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1CC3A0F9D for ; Sat, 6 Jun 2020 01:45:21 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id o15so12672086ejm.12 for ; Sat, 06 Jun 2020 01:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=wX4tXhubpwtV5EZF5UdcO/PLvu1/SAJbfLEqXOjld/A=; b=M2mFyFTaiZIeB04O8ufKuvOm9A6jbGL2THZ0tpx9GnpnPfc6eNZWEz/WmsvtNSD6K5 dISp0JAQr5CqnHATZlgFrYNFYN5Q/5qlMOmH9tzHLcyZGwPARRpej9w+ZI0ojZy2tMLh Sq/PCXuNE6OKc9xpVOYqNh084fJm57Iv1z3fAWq4Ubzs9jtgqfAPzVIIYP0+4wwKnwUT LkbZniWkqiCR/RCR7k546NARHBWQXlOQo183kh8SQvWGYt+a5i/rlrSEonu/gCytg4Dp olboLOYN8umwh9Q6/HgiLGosETTEgenO6DuX4jgTqTDBLUy8BwU7TBAtzsTjydzr0BXR LTsw== 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=wX4tXhubpwtV5EZF5UdcO/PLvu1/SAJbfLEqXOjld/A=; b=LI5Z76K4NDXKwYzzQipq/3yAwSobSKDek1mgYyb2ImdA8BrqfVDrnqMJRRVinh5T+U GPUxaqf2huL4d/aqosT12a0rBSTa3bij5s6x+5Ms9Snw0/P+GI52NyGKDjiClxoMeIAa t5ePSj2BjF4pPFfEGwvmAcfRBPo+E4RhOvsbbZxHINH7xJkCxaw5eyA49V30hdWO8bk+ V1QO3/8CTHXNo7HyG6f7oK7QHJLxkS9/qYwBr3P1uP3ZdKc0AKPwdBS/uvm6gS+byPe8 yz6V6EnF41ctXha7JUqZmnNOZFIcD36cbUwRNY5JzQTTX0KvHf0LqqbHGWsFyn0SX/pJ 8GIg== X-Gm-Message-State: AOAM533Bdbu8zf6hJRTCI35hHSAgltbHwsIlcG12t9vNYY18ZlB2aTAj kn6pK2e4KT7CZ4JMsjcC/cDTJA== X-Google-Smtp-Source: ABdhPJy3j8tpruWsaBZJtmIDb6CSVWl1ZhzOwM6WTqWPPXWlJ63QWRyJJLwizfNoh5GaizvbqFSPaw== X-Received: by 2002:a17:907:ab9:: with SMTP id bz25mr12252297ejc.39.1591433120220; Sat, 06 Jun 2020 01:45:20 -0700 (PDT) Received: from ?IPv6:2a01:598:90a7:28b3:f8be:3610:ba20:d03a? ([2a01:598:90a7:28b3:f8be:3610:ba20:d03a]) by smtp.gmail.com with ESMTPSA id y62sm271233edy.61.2020.06.06.01.45.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 01:45:19 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-43C32448-7B02-4E76-ADD5-25C4D3D13401; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 6 Jun 2020 10:45:17 +0200 Message-Id: <53944EF3-4BF8-4555-BEE8-B9522A7D1501@lodderstedt.net> References: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> Cc: Francis Pouatcha , Joseph Heenan , OAuth WG In-Reply-To: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> To: Financial API Working Group List X-Mailer: iPad Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] [Openid-specs-fapi] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 08:45:24 -0000 --Apple-Mail-43C32448-7B02-4E76-ADD5-25C4D3D13401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 04.06.2020 um 15:52 schrieb Joseph Heenan via Openid-specs-fapi : >=20 > In the cases Dave and I are thinking of, there=E2=80=99s no SSO between th= e different brands (sorry,I=E2=80=99m struggling to find a better word than b= rands!), which also have segmented user credentials - there=E2=80=99s no use= r confusion. Segmented user credentials to me indicate that different issuers should be u= sed. I don=E2=80=99t see the advantage of using the same issuer if the user r= ealms are different.= --Apple-Mail-43C32448-7B02-4E76-ADD5-25C4D3D13401 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjA2MDg0NTE3WjAvBgkqhkiG9w0BCQQxIgQg JOcV/5ezF4M88PwBwyItOSX7Lmc38yLb/mIv3dGgGJ8wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAOt6Gg47nuSnLBylOmkgXg6CHqSdbFHLiy7FGO8fL1oCVUcZd/xGx DUSoAPERojhtjvt7UEXJOMkxZ7NJRqyO+sJHaiIHMTFWvS7hW3djYH11b01v6bXwCudUBQ+XTmhr K7j+B5yKH3gcWlnEqExj5MsulMhPgqMN1qN5cK6j0TkeP56y1unV4MImFvOmVPL7fSOyzfE3DSU9 mKPDD2dEahqLhoDxCPg48v9cE5VuQ6GZcOjCyZUmRVWi6ahzVBQjCCmIJVPNw84U28KJSLoRgPjM 4vlC/O5aCaCy/LUkee7eUAgAL3/73TKa3L8KFBWY0Ap2E1Yu1TIp2MSxv2Bl6gAAAAAAAA== --Apple-Mail-43C32448-7B02-4E76-ADD5-25C4D3D13401-- From nobody Sat Jun 6 15:57:41 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93153A0F41 for ; Sat, 6 Jun 2020 15:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nIhg5n2Keqw for ; Sat, 6 Jun 2020 15:57:37 -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 794BA3A0F43 for ; Sat, 6 Jun 2020 15:57:37 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id p5so13512636wrw.9 for ; Sat, 06 Jun 2020 15:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1/mF2PPYwcG+zYgwaSK+eaR9W3SzJEukj29wuMcbzJQ=; b=cmFtXwyhlT8cc4hB9oGjhkhM4CotwkwRJyvi0DksHxhBC/t+o/ALVIP08QVTrJEJeK 0MRw0LpOuDb7XltI5KMCsWWLHsbs4i7tBA3SaZRVxzXB3VLcCtl0hqQBH9J+1I7cQCGu IjMoQft3Ak4KbRl7F4LdZtETtrGE6xNUYOidw= 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=1/mF2PPYwcG+zYgwaSK+eaR9W3SzJEukj29wuMcbzJQ=; b=O17O7C+qUBOSpIyhqRQacuEuiW5D5CNmHf5b9pRyhJB1oI8ZZz8Mh2LbF26ORoZhVt /OLhuHAXKpxtAZE87OEakxdqt9z0Ph2K+BAInIF+MRTcDFSqJvIGp7nrjlvAzCyw44C8 OyngSRUj1HHZ8O3fWPTYghoAr+47ig/Cpk9su9cni8O2LUmbJyoGJHs8SifpQx6qMo1V q68NDOqPpTf9OrPEuxbbOaQHu5gHKbn6cSa535WY+JqKyvs1c+bQXjfXXsZynlPP0YEx +sx5eTmvKUGLYAxuMUxvoXPnAO2Myk4hdV57QK0876sFsux3CPh0witGx/ce+OhQet5f rzig== X-Gm-Message-State: AOAM530oZNm+IgTc+k/042TjU3f6wePFxW0Sz5VP4z6ULPV6zeo/XInM F1smWxtRcNZy20uDtIKkWhB5tSl+lpkaAi5MczaRe+rd/cE= X-Google-Smtp-Source: ABdhPJyqs0VeSoztkVdcWBw38jiWT5a0Y2LztWQ7wr9TJfzdXXtpu0G0/dQlFLtPPxsLHejDcax6J142MgRNuuNcQM4= X-Received: by 2002:a5d:4bc5:: with SMTP id l5mr16433084wrt.104.1591484255599; Sat, 06 Jun 2020 15:57:35 -0700 (PDT) MIME-Version: 1.0 References: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> In-Reply-To: From: Francis Pouatcha Date: Sat, 6 Jun 2020 18:57:24 -0400 Message-ID: To: oauth Cc: George Fletcher , Brian Campbell , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="000000000000b894e205a7724d5c" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 22:57:40 -0000 --000000000000b894e205a7724d5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > > Am 05.06.2020 um 22:17 schrieb George Fletcher .ietf.org>: > > > > Secondly, I do think we need a way to allow for the refresh_token to be > bound while leaving the access_tokens as bearer tokens. This adds useful > security without impacting existing RS deployments. > > +1 that=E2=80=99s a very useful > feature_______________________________________________ > AFAIK a refresh_token is always bound. What am I missing here? --=20 Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000b894e205a7724d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Am 05.06.2020 um 22:17 schrieb George Fletcher = <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to b= e bound while leaving the access_tokens as bearer tokens. This adds useful = security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature____________________________________= ___________
AFAIK a refresh_token is always bound. Wha= t am I missing here?
--
Francis Pouatcha
Co-Founder and Technica= l Lead at adorys
=
--000000000000b894e205a7724d5c-- From nobody Sat Jun 6 20:42:00 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67483A094A for ; Sat, 6 Jun 2020 20:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 X-FjOn_RoajN for ; Sat, 6 Jun 2020 20:41:55 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F123A0948 for ; Sat, 6 Jun 2020 20:41:55 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id t7so7141894pgt.3 for ; Sat, 06 Jun 2020 20:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Oq6NNXkh2Nepekthagj8DSiKE5mUv3iOPYmDDQDeWjc=; b=XmjqRZt8vVZQL3WdQ6G4itqGhItc/x1NLPOr9I7rTwnzsfCQhUliXRFo/OpyY75XpQ vbxm7y+FijlIYpf+RZizcRPGEs+bnEXG3lHRLnKU9+xzaGrCB279//X4E8NU5TQ5vpwq BMP9g7hzEYbsJ1Omxu0g3/L6zpobRLrEepuOl54sXiKPIobEAgKML/ohnrOHoM/mgiEP /+AAktaX0pxtIA4FEzkcwUvIXtBadG8EaOS1utAxFXMmm9gf09nmQI5P/QM05851l+de 2EiHLOGhsPz35mal/zygf57wbJpQQEUoVnYboBF0w5lclAk9dC4j6RT7+9DdgbVIXmT2 sQbA== 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=Oq6NNXkh2Nepekthagj8DSiKE5mUv3iOPYmDDQDeWjc=; b=sTxJC8YjVlkH3kyzzrvL1Kyh5Qb/k1ql1a3GdXf5JPZBpYceoAK68ghQSILcZ+vRwh u5y9dz2yUsBuqoKxDSnZErbqOZzIfO+gLl7UXw5aAFU7/R9FWt6hfDUJPRjIpflLJQ3P sF30J5yz668twTMssS7eIEy+eKZJCu4oamwELmC5xYTJLI7sHNWo3xBaVyjodFGoHpr+ JO+rKNCN45PtM648n2NmWp+BSHYw6FdwIb0WWmbnHBYwxW/jM3gfqlYnh1IqZaX++pwL SzckbOAqzrsjO2JEOrdKSpQ0QW55AOOyfRSWcSI3OYOiXnymxx9Prj8/9mq3qep+qNFs sv8w== X-Gm-Message-State: AOAM531UFxUDgo4DhkOSZ8E+sw7K/FYBhtInkuGGAVijF1snd4v5VP4D YU9GZLtefNX1m0uw9W998JwqnmAJS20= X-Google-Smtp-Source: ABdhPJyyLTMCLtD6L3e6m5JThv0j+JH0kIFhJkZmYmFhxJrRRhzhvzbeA2CdTINi7RcXKBbJDC+KMQ== X-Received: by 2002:aa7:9686:: with SMTP id f6mr2284081pfk.132.1591501313008; Sat, 06 Jun 2020 20:41:53 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id f6sm3463159pfe.174.2020.06.06.20.41.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2020 20:41:52 -0700 (PDT) From: Nov Matake Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_950E9EA2-34D9-482A-99F9-F16986BC30A8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 12:41:48 +0900 In-Reply-To: Cc: oauth , George Fletcher , Brian Campbell , Torsten Lodderstedt To: Francis Pouatcha References: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 03:41:57 -0000 --Apple-Mail=_950E9EA2-34D9-482A-99F9-F16986BC30A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 DPoP-bound refresh token seems feature duplication with dynamic client = registration. > 2020/06/07 7:57=E3=80=81Francis Pouatcha = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 >=20 > > Am 05.06.2020 um 22:17 schrieb George Fletcher = >: > >=20 > > Secondly, I do think we need a way to allow for the refresh_token to = be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments. >=20 > +1 that=E2=80=99s a very useful = feature_______________________________________________ > AFAIK a refresh_token is always bound. What am I missing here? > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ = __________________________________= _____________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_950E9EA2-34D9-482A-99F9-F16986BC30A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 DPoP-bound refresh token seems feature duplication with = dynamic client registration.

2020/06/07 7:57=E3=80=81Francis = Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:


> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_950E9EA2-34D9-482A-99F9-F16986BC30A8-- From nobody Sun Jun 7 00:22:08 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE73A0B32 for ; Sun, 7 Jun 2020 00:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvmqdtbJBT0o for ; Sun, 7 Jun 2020 00:22:05 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840993A0B33 for ; Sun, 7 Jun 2020 00:22:05 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id q13so10793499edi.3 for ; Sun, 07 Jun 2020 00:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=2klc+xsH93yDu2YEpHbtyOdvTb8WtR60eQohZNkvQow=; b=0ZI4TUsdLoFZHHy/mTUjcspNCxprljgNoioR7q4KjKheX100vMMaXwyR0zARllNAgA 6p1Dd7TxBxjH5zQzWxDtyHtwDHEab7q93pky5UJE+CPD+0x2J7reEfqXzc9FVPHdhXaD 8GbomTprqQu/4AmUPZ5ic4xgM0h89hM1DPlklVoDj0lwPZ+8IZxR1/6lG1ke1HpzPSVq 8EivjUgAoYAieqEvcWMmS9YaOw3wkXmKDuc92bUa/k8fDZCQnTryZWiiL9JvLbmTUST2 wxr+lOZKOfJwSkzX9itwOUWuHiscyCfe7eVlF/rruTtzy+8q84qY0L7UoqlIvZJJpvs6 a4zA== 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=2klc+xsH93yDu2YEpHbtyOdvTb8WtR60eQohZNkvQow=; b=Zdw+AytkwarT+HDwWLs21sIUj9kFyEJSXHEpM6kd8XEiUBXn9SpvpVkLFhRxQ/czFn JGdE2s/IDjPcr/q6kgI9ck5OY+c400lKB6UVLLNExdJn06e1IfuxC+8cjgilUm6rZzzY geQ3XkuEUAPIweErz5L6qEVsp4Fc5IPYtClHUuTpOdE/0frl9VL7ybp2oVjuyiaxHaKH 50MXGMZnkfBtD9R/AQcluzJphFxIwJIsHNtl2qs1BgSH/9WHldE0nS8cpQcmRWGPJ9E/ tIR4exXgL7o0zLuoFh6WuAqHR3P6ZbKC7sa3FZGF3GMVTwJRqMsB/ScoH8sQ3wvGfBfB jvpw== X-Gm-Message-State: AOAM530GEeMCybaAXU+lTbarSEOoIpC9uNmeokxDgIkQpYG+ACe1IHJG mgGDdpkfA4hbmH3ntjlVfDIH7WYh9qM= X-Google-Smtp-Source: ABdhPJywuOek1hXZqLeg6itvwL7LE6WumuI7rmmeUa2ua/mvPXgOZ7xIpaj5kxWnuDelcM+ZTZB/Qg== X-Received: by 2002:aa7:c9c9:: with SMTP id i9mr16420151edt.166.1591514522070; Sun, 07 Jun 2020 00:22:02 -0700 (PDT) Received: from ?IPv6:2003:eb:8f18:4cac:595f:7e6:53fe:b837? (p200300eb8f184cac595f07e653feb837.dip0.t-ipconnect.de. [2003:eb:8f18:4cac:595f:7e6:53fe:b837]) by smtp.gmail.com with ESMTPSA id n16sm4681552ejl.70.2020.06.07.00.22.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 00:22:01 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-21CAEC53-F93A-4980-B4F9-A46F19D1F00D; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 09:22:00 +0200 Message-Id: References: Cc: oauth , George Fletcher In-Reply-To: To: Francis Pouatcha X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 07:22:07 -0000 --Apple-Mail-21CAEC53-F93A-4980-B4F9-A46F19D1F00D Content-Type: multipart/alternative; boundary=Apple-Mail-E41E56F9-A6D0-40A8-8EB9-61843553E168 Content-Transfer-Encoding: 7bit --Apple-Mail-E41E56F9-A6D0-40A8-8EB9-61843553E168 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That=E2=80=99s correct for confidential clients. For a public client, the refresh token is just bound to the client id. DPoP a= llows binding to an ephemeral key pair for this kind of clients. > Am 07.06.2020 um 00:57 schrieb Francis Pouatcha : >=20 > =EF=BB=BF >>=20 >> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >> >=20 >> > Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments. >>=20 >> +1 that=E2=80=99s a very useful feature__________________________________= _____________ > AFAIK a refresh_token is always bound. What am I missing here? > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ --Apple-Mail-E41E56F9-A6D0-40A8-8EB9-61843553E168 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That=E2=80=99s correct for= confidential clients.

For a= public client, the refresh token is just bound to the client id. DPoP allow= s binding to an ephemeral key pair for this kind of clients.

Am 07.06.2020 um 00:57 schrieb Francis P= ouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>:

=EF=BB=BF

&g= t; Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=3D40aol.com@d= marc..ietf.= org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token is always bound. What a= m I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead= at adorys
= --Apple-Mail-E41E56F9-A6D0-40A8-8EB9-61843553E168-- --Apple-Mail-21CAEC53-F93A-4980-B4F9-A46F19D1F00D Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG 9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z 8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG 9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW 0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj 2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF 6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDcw NzIyMDBaMC8GCSqGSIb3DQEJBDEiBCDvH3K2S2Z9H7Bqi0f0iuwjc9NLrcZYqlnjmnLkZZjcmTCB vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBAQUA BIIBAJSX+ODMhGIqvJZCIDuuW/6Fn/WU5kSSXEEN8VP7RdbVALPU8XDC96C6nA8avPAK+cYT13wL D4v4Y2faqciLZxNPKUhf7YoUcIBVpM/PeCySTLnNWWcu5+YGtKvclK6rJMg+LOFxdCPdketbI0at 6oysWmsPYC2flUIze04pZ4MWxjF8dGNOt0ahvCjQoT2jmMCLrKcYLAysXqrMQO1FF1nrm0phbDu1 JyatnhW9WP6RFQg6ca//c83670nizUxeOT123QvOd4Ywi61lfvUt84rbQl9uKy6Y8OzcohbB0N1t xzWasebosmdgUWLKnFlbTPSFK0DWhr+km55LqrP60DcAAAAAAAA= --Apple-Mail-21CAEC53-F93A-4980-B4F9-A46F19D1F00D-- From nobody Sun Jun 7 00:24:44 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B03A09F2 for ; Sun, 7 Jun 2020 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umSGoZpff3fX for ; Sun, 7 Jun 2020 00:24:41 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1E83A09F1 for ; Sun, 7 Jun 2020 00:24:41 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id o15so14690559ejm.12 for ; Sun, 07 Jun 2020 00:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=248zMwXHbxlMeNhIN0hVyiGEn20i4dgy96M6Zy1rE84=; b=GqxqoOw5wnLJrPdS6xQSubnQBH+WkKoIMKcrlMesfbnTdTsrti5Sy7WbrQw9YcBZKN iWbKPBAzF2uh81i75V8r6LOA+WCfC1NhnH5stDck91eJVIB3CMO2+Xnf4oiH+sqdUrde HAIkYbolh+fIb6rVEoeUIwylbfEhyYvwPdOpWs3p0guVjjpq0NGiaXBKrXNIIs5V2KD6 w6TB044aUx0nZVHplkkOPLM9lLcu191Uu+5D0nMuN7gG5jpqV02jLgoxJ7NuPa42V4OU N8/0O2WKQe/qEqdq2Sz6IaATJ+sCNWt6XTLXouDrDoNdKLurxEz3iA1h/anqjs9rXfnd 9xMw== 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=248zMwXHbxlMeNhIN0hVyiGEn20i4dgy96M6Zy1rE84=; b=Do3GZftti9hkgDL6NhfB23OPWIG49tl+4hy5+12IVbv8OaNO5JTsv+p8Nx30aXq214 DdVy+JcbNoi1b5krhCXkoj7jIDQ2oWFXeDvbWEBzWvSL2lzevTVRVnztwUqjlBeT140F qUGazeRty5CWf11ikgfgyDUqesSB3PxAkfHbtUhhGdCa2l6GwJpfI9E/7XCfUNHf1IGi vN4rTieq9EYxoddb4iPppzvMIqSIFeu7v7q6oB8bIWW3z4XTO649+Ve3P47LNPGOJV/F DTeCE8FeTjMIfijJp1WrTeyQ8k3ZM/dCU9uGPKdeCIfN0WAgpVBXMjY1MZHqxTmVaWBJ qfqg== X-Gm-Message-State: AOAM532rbgslPszBoSpJhdPFchgVhmSaMIfvaUG0n2ifGe0ZMDTFJ4Lw 6dQFY6QC3i39cOF3jZUv4keYYQ== X-Google-Smtp-Source: ABdhPJw7gcWCefC5mKHFG1n4sEuWQCtq6R+uHHQ6eJjcDSciHcaoulaK33VVidCPYAfhw2tHygoeAA== X-Received: by 2002:a17:906:6686:: with SMTP id z6mr15566809ejo.258.1591514678178; Sun, 07 Jun 2020 00:24:38 -0700 (PDT) Received: from ?IPv6:2003:eb:8f18:4cac:595f:7e6:53fe:b837? (p200300eb8f184cac595f07e653feb837.dip0.t-ipconnect.de. [2003:eb:8f18:4cac:595f:7e6:53fe:b837]) by smtp.gmail.com with ESMTPSA id n5sm9374981edq.13.2020.06.07.00.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 00:24:37 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-8BC59785-8CFD-43A5-9A21-8EE751B3C9AB; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 09:24:36 +0200 Message-Id: <19341B4C-BCA9-49A6-ACB1-E9466BE9A1E2@lodderstedt.net> References: Cc: Francis Pouatcha , oauth In-Reply-To: To: Nov Matake X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 07:24:43 -0000 --Apple-Mail-8BC59785-8CFD-43A5-9A21-8EE751B3C9AB Content-Type: multipart/alternative; boundary=Apple-Mail-689F199A-0C8F-4E76-B179-07032BDD6C49 Content-Transfer-Encoding: 7bit --Apple-Mail-689F199A-0C8F-4E76-B179-07032BDD6C49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are similarities in this particular use case but I would argue DPoP is= more light weight than dynamic client registration, less state management i= n particular. > Am 07.06.2020 um 05:41 schrieb Nov Matake : >=20 > =EF=BB=BFDPoP-bound refresh token seems feature duplication with dynamic c= lient registration. >=20 >> 2020/06/07 7:57=E3=80=81Francis Pouatcha =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >>>=20 >>> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >>> >=20 >>> > Secondly, I do think we need a way to allow for the refresh_token to b= e bound while leaving the access_tokens as bearer tokens. This adds useful s= ecurity without impacting existing RS deployments. >>>=20 >>> +1 that=E2=80=99s a very useful feature_________________________________= ______________ >> AFAIK a refresh_token is always bound. What am I missing here? >> --=20 >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-689F199A-0C8F-4E76-B179-07032BDD6C49 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are similarities in t= his particular use case but I would argue DPoP is more light weight than dyn= amic client registration, less state management in particular.

Am 07.06.2020 um 05:41 schrieb Nov Ma= take <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh token seems feature duplicat= ion with dynamic client registration.

2020/06/07 7:57=E3=80=81Fra= ncis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:


> Am 05.06.2020 um 22:17 schrieb Geor= ge Fletcher <gffletch=3D40aol.com= @dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token i= s always bound. What am I missing here?
--
<= div class=3D"">
Fra= ncis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-689F199A-0C8F-4E76-B179-07032BDD6C49-- --Apple-Mail-8BC59785-8CFD-43A5-9A21-8EE751B3C9AB Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG 9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z 8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG 9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW 0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj 2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF 6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDcw NzI0MzZaMC8GCSqGSIb3DQEJBDEiBCBD3jD3TY7ObV4kLHLEgeWCeNuRjwkSMTcyfGPtvxzJeDCB vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBAQUA BIIBAAmerj8xAHNIigSAxZ0sT1j/X7HvSCUTQbzyn1EC81vN2ZpsaCWKTdTMPuMasfYubA/A5dD+ eWcFPtcLsGRTHRWBSommyuIOpirO8v45x2qnwmEd4oY0cIV2ZgbFEqBUtE0WV3OExIxDuRgAF0pR hnoXNVi538U1c0MopggdWfhzyrn68yp7kSKlCp40FVhccls+YTHMl7PijGGUoHX45NdCkQ0/WUD4 4rUxIWCXataORLruuif4MAN2rPyjoA+lJhpb3noytpFCe73j6PZzBsKuLR3JbQLYjhZsjmcDi9za T/DagpWcK3dBpk4FcYeC3S1iaWh3wVyyryP/n+f8iEIAAAAAAAA= --Apple-Mail-8BC59785-8CFD-43A5-9A21-8EE751B3C9AB-- From nobody Sun Jun 7 04:04:53 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE823A0D3D for ; Sun, 7 Jun 2020 04:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed3LCT_OOsCY for ; Sun, 7 Jun 2020 04:04:50 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF723A0D3C for ; Sun, 7 Jun 2020 04:04:50 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id ne5so2080486pjb.5 for ; Sun, 07 Jun 2020 04:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=keJ9llU1fCdYpPI3cenkymWSVu/jeZA08DGfAKB4Meg=; b=OtyzqjE/G3nyCYUjxoN2kBDBnH7UtKZHO+4wHAIo+6v7/dWknWeUecPVP6AYOBJw+S BGUeuiQ9PuZnFkCyBk0rFlkXrs5XdbzSa2CESuNpQAxmFk/+RoLiMie8R5+QCDs3L0MN /QTQnc3LgwGQgi9UOt751SwgNXQQmbtnMhbbJXob3ia5fxg9Nit7qtCbWq+PfiKbEBUC dfjEtKlSD1gQAU4pwbrKbaIVVgK5SpNRzQW4WwCTkkX76mjfddTfSA/bsKkWWaCgxtjm XmkL+/fmTrX+7ATBYy9AOKe1cVnLz+TedmWhnLIVnfA//s/S1mWZzUPYwPqkJg0rKQUM YjaA== 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=keJ9llU1fCdYpPI3cenkymWSVu/jeZA08DGfAKB4Meg=; b=kmnwQiHfeZGpkfUsoCJdWJL8Pi61attxUHMppTqwzXi2gl/kVUtR7YeiSdWRJMra28 CvictkmenFkOd1JAPoxOxQWEfVmbrGFDdI5NQlbDUpEU7EpDnWF+3P5kfCf1+/diKVSv kqkaqpHBjJf3OzdCGdRE7YTyiW2yJgLSv0fJRM5t+a9tpOwuJpbQfYUKKuNuPbpvQJMF Iazt38RBMxtG2dewsZWQAWYkFHgiyOAJGjsQNzTiFanoapZmkjMjhN7wbJaadW1bZFGo OQE3KCjrcOTDbiewZYxqiHH3fTpBfFPPOBPtWHMym6o87XIVGYHZ2gd5Ea3omkIwhPJN +d/g== X-Gm-Message-State: AOAM531QTKcDRILancxJ27uck6xdhypEunslL2IympP101XrVtSy4T7H vFdxFQHehPwHGJ0JVmP9VTE= X-Google-Smtp-Source: ABdhPJxXz9AYimswfIWh78k3BTMO88+XXLmAHpO7C387Yk4quP5Oq8VBDuFHiJAi2L/fXG2ompc17w== X-Received: by 2002:a17:90a:e288:: with SMTP id d8mr12606925pjz.173.1591527887736; Sun, 07 Jun 2020 04:04:47 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id z144sm4379810pfc.195.2020.06.07.04.04.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 04:04:46 -0700 (PDT) From: Nov Matake Message-Id: <8590F26F-309F-4F84-B99F-2D29353859B5@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_848B1ECC-0AF7-4957-8342-74F1AAD74E34" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 20:04:43 +0900 In-Reply-To: <19341B4C-BCA9-49A6-ACB1-E9466BE9A1E2@lodderstedt.net> Cc: Francis Pouatcha , oauth To: Torsten Lodderstedt References: <19341B4C-BCA9-49A6-ACB1-E9466BE9A1E2@lodderstedt.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 11:04:53 -0000 --Apple-Mail=_848B1ECC-0AF7-4957-8342-74F1AAD74E34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since each client instance has at least one key, those are same level of = state management. > 2020/06/07 16:24=E3=80=81Torsten Lodderstedt = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > There are similarities in this particular use case but I would argue = DPoP is more light weight than dynamic client registration, less state = management in particular. >=20 >> Am 07.06.2020 um 05:41 schrieb Nov Matake : >>=20 >> =EF=BB=BFDPoP-bound refresh token seems feature duplication with = dynamic client registration. >>=20 >>> 2020/06/07 7:57=E3=80=81Francis Pouatcha = >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB: >>>=20 >>>=20 >>> > Am 05.06.2020 um 22:17 schrieb George Fletcher @dmarc..ietf.org >: >>> >=20 >>> > Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments. >>>=20 >>> +1 that=E2=80=99s a very useful = feature_______________________________________________ >>> AFAIK a refresh_token is always bound. What am I missing here? >>> --=20 >>> Francis Pouatcha >>> Co-Founder and Technical Lead at adorys >>> https://adorsys-platform.de/solutions/ = __________________________________= _____________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_848B1ECC-0AF7-4957-8342-74F1AAD74E34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since= each client instance has at least one key, those are same level of = state management.

2020/06/07 16:24=E3=80=81Torsten = Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

There = are similarities in this particular use case but I would argue DPoP is = more light weight than dynamic client registration, less state = management in particular.

Am 07.06.2020 um 05:41 = schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh = token seems feature duplication with dynamic client registration.

2020/06/07 7:57=E3=80=81Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:


> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_848B1ECC-0AF7-4957-8342-74F1AAD74E34-- From nobody Sun Jun 7 04:26:03 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B123A0D69 for ; Sun, 7 Jun 2020 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld7ygk2AXvz2 for ; Sun, 7 Jun 2020 04:26:00 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68653A0D67 for ; Sun, 7 Jun 2020 04:25:59 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id x1so15028618ejd.8 for ; Sun, 07 Jun 2020 04:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bebG4GJWylV+cJ5auPuTTp6MnBB8oPv0xckZrV63yTQ=; b=sgZxTtNWzmBLQwrH+DwqZsthpdt4v6BtvF7yPeo1WvqJ0hQ0Z+2c1nh0pgmqtnbfKg sT+Wyt1qvvZ5RPjDaMNduOQWQlnYakp+AO8j3nqLtRHWZhNGcPwF/ZNeCr+5xBQ5mUkg 8V45wZ1L7n96JPMGACVpKajmTI678VicPX7hu0MRdRsEKX34Dmmh4JOoPzmPf6EpTuiV IE1pvoYxUMXp1TcTF9Tsx0djw1ScZaxLvyWZ+oqDo+6kwj+oD46uuqsTqrNjpPmOhdqt KhyISNwAsGkHphspeyH6fohmZEDNQHIKL54DrjYUgeXtaqVJ3HFV1Mb4URkL4r3Ef4TY 6UqQ== 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=bebG4GJWylV+cJ5auPuTTp6MnBB8oPv0xckZrV63yTQ=; b=rGk5H0Fk3RffSiP6JxhH547Gyj+gstQP8NkGLw6MP0f0SNPiU4HXq0iWxDFQfQ38jW 4s9j5be75lBfWzHsmfgJefsDg8Fd3xizEgxy5Szp1xAxWFxjo5599iW/65P5W+8jevGs UCoivygx6GZg7JKevzevW7F3hcGsp/RH95vVeLkcusOMIkIeJikxJu2NLIxpLcNdhcG7 5X0y85tQBESsq+nyvViXk0yR7k4p761yNy0VjVSE1BbGQ0Vxzhys4eRXZX0Ud2eiruaj 5ssrCFpjF4sllPSPRMsPAYHFf/Vr66wezyA6HqQYtdX2F/mUZGIu+eDQRorhHkIdTU5o HK6A== X-Gm-Message-State: AOAM531Lmq6gwxkKnzbjnAOEq+sgSl4YOukdtenSBXyU1XcSpb89FBDs NKXyKjS5BZNEj83RD2KXPDmTxA== X-Google-Smtp-Source: ABdhPJw2WelTT7nZmDIRi6/JLwygEIAtP/AaqBiUaUEQBqeKO4Zm7eub06hBd5gKrn62tQtdkDAuIw== X-Received: by 2002:a17:906:6897:: with SMTP id n23mr16946926ejr.437.1591529158149; Sun, 07 Jun 2020 04:25:58 -0700 (PDT) Received: from ?IPv6:2a01:598:8184:992b:6522:fbe:7df4:6df6? ([2a01:598:8184:992b:6522:fbe:7df4:6df6]) by smtp.gmail.com with ESMTPSA id t12sm8272037eje.21.2020.06.07.04.25.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 04:25:57 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-FB7CC23C-1123-4AE7-8AF0-AB40DE91872C; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 13:25:54 +0200 Message-Id: <1ABEEE6B-761E-458B-937D-F3581BC6DE55@lodderstedt.net> References: <8590F26F-309F-4F84-B99F-2D29353859B5@gmail.com> Cc: Francis Pouatcha , oauth In-Reply-To: <8590F26F-309F-4F84-B99F-2D29353859B5@gmail.com> To: Nov Matake X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 11:26:02 -0000 --Apple-Mail-FB7CC23C-1123-4AE7-8AF0-AB40DE91872C Content-Type: multipart/alternative; boundary=Apple-Mail-AC417245-5D4C-4D4E-AF0A-CFEBAD6C3A3E Content-Transfer-Encoding: 7bit --Apple-Mail-AC417245-5D4C-4D4E-AF0A-CFEBAD6C3A3E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If the client would register for every transaction. And don=E2=80=99t forget, DPoP also supports sender constrained access to re= source servers, which dyn registration does not. > Am 07.06.2020 um 13:04 schrieb Nov Matake : >=20 > =EF=BB=BFSince each client instance has at least one key, those are same l= evel of state management. >=20 >> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt =E3= =81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> There are similarities in this particular use case but I would argue DPoP= is more light weight than dynamic client registration, less state managemen= t in particular. >>=20 >>>> Am 07.06.2020 um 05:41 schrieb Nov Matake : >>>>=20 >>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with dynamic= client registration. >>>=20 >>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>=20 >>>>>=20 >>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >>>>> >=20 >>>>> > Secondly, I do think we need a way to allow for the refresh_token to= be bound while leaving the access_tokens as bearer tokens. This adds useful= security without impacting existing RS deployments. >>>>>=20 >>>>> +1 that=E2=80=99s a very useful feature_______________________________= ________________ >>>> AFAIK a refresh_token is always bound. What am I missing here? >>>> --=20 >>>> Francis Pouatcha >>>> Co-Founder and Technical Lead at adorys >>>> https://adorsys-platform.de/solutions/ >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 --Apple-Mail-AC417245-5D4C-4D4E-AF0A-CFEBAD6C3A3E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If the client would regist= er for every transaction.

A= nd don=E2=80=99t forget, DPoP also supports sender constrained access to res= ource servers, which dyn registration does not.

Am 07.06.2020 um 13:04 schrieb Nov Matake <matake= @gmail.com>:

=EF=BB=BFSince each client instance has at least one key, those are sa= me level of state management.

2020/06/07 16:24=E3=80=81Torsten Lod= derstedt <torsten@l= odderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

There are similarities in this particular use= case but I would argue DPoP is more light weight than dynamic client regist= ration, less state management in particular.

Am 07.06.2020 um 05:41= schrieb Nov Matake <matak= e@gmail.com>:

=EF=BB=BFD= PoP-bound refresh token seems feature duplication with dynamic client regist= ration.

2020/06/07 7:57=E3=80=81Francis Pouatcha <<= a href=3D"mailto:fpo=3D40adorsys.de@dmarc.ietf.org" class=3D"">fpo=3D40adors= ys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:


> Am 05.06.2020 um 22:17 schrieb George Fletcher <gf= fletch=3D40aol.com@dmarc..ietf= .org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token i= s always bound. What am I missing here?
--
<= div class=3D"">
Fra= ncis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail-AC417245-5D4C-4D4E-AF0A-CFEBAD6C3A3E-- --Apple-Mail-FB7CC23C-1123-4AE7-8AF0-AB40DE91872C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG 9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z 8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG 9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW 0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj 2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF 6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDcx MTI1NTVaMC8GCSqGSIb3DQEJBDEiBCDw0o6u1UaIoB2HNY5nWtBn3DMzYZ5YwKP/y/SeuJSWejCB vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBAQUA BIIBAFLLFBZ1cIgCReuElavqDA5FxnGRp1BsuAB8honlIutq2DtLBW3+Nn7ws9I7eyTxczTIo2u9 aetg/WpLDbrwapWMWIDlCjHAKAsGOnLCcGCqQLEhvgvWokib37jQu4maUxfdPKIzQnrx9AHglQhO TOVA8rwwusXShF9vX0vtFbPIclEGoDfY7LMjHxC9GrecLSA+mNLOGK6iFJWftbLSO/OM/xzMbRa8 ZBcE7LzhQdCHqGVS6P2Bt9Q+hBMXQS58C/289zgyc3VmOnOQVJl4H1i3V42yqGRRQ3D6ggZHVViK zwKCKuTdwUQYon9eJjqDbB2jtsqYrQKKvskP1RYJtyAAAAAAAAA= --Apple-Mail-FB7CC23C-1123-4AE7-8AF0-AB40DE91872C-- From nobody Sun Jun 7 04:33:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEB53A0D6F for ; Sun, 7 Jun 2020 04:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiAMolgGp4pJ for ; Sun, 7 Jun 2020 04:33:52 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BAD3A0D6E for ; Sun, 7 Jun 2020 04:33:52 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id p21so7379902pgm.13 for ; Sun, 07 Jun 2020 04:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VpnrxNoJdUpg9ayERMzhF4PR5eh9cEW3kirr3Sf6LkI=; b=hXz2nyzsffDedjFL2TYCY/9yCSDAPUe4bY5vcmA6EVeBWV9KmO/VgtJkJI78qOMWAm AgODPyODF11/inArg5shBUqyKikb8PbTMAk8dEGd1BDTNalm9+uoLOQ5jmqlCm8pgeGF Oz0r8D4z4kGHeeKD+Kq4FT2sHPCcDjFJDf1zC+Rrw6OLuglOvMr4Gvb/56Z4715WebK3 SGFTfzH3+mQdhPRFrpZlC7FMBydwWloOwOS8zRRz959ut4pFzGnq4W7C/ZoHnfamVDs9 fm0UN0JBupOGH1TEirfIXvcpqYc2cLkBCk2y7i9luO1MWA7c4OLr77YZ6kkOOpe5SNpn 0fnQ== 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=VpnrxNoJdUpg9ayERMzhF4PR5eh9cEW3kirr3Sf6LkI=; b=tbs6CSas/5HNjhrrf+1qyb/S+mzRJBOUIvDoCeFGwt3xkrHh3UGNw9f5rzemVN/3Ba chXICdrsQAKEX/E3ugvn/YnJQtHoobGXVx2yWl7wWiKpexe5Enpr0yfeP+NwYQrULS65 lZDjyVmuRlkx3tLtLiVHuYTnzPc9l8ibo6YXBV1+S96gkrzfQzFUsHGcmYo9y85mJ6UM FY/SQPknH53WIMaSTcOUYzjrGa4ZBWk9BCnZV9JtlOIDVii2uNjaOX4Ock8L5HZuNkD1 hQcbexdOXw7KnOewHdvU5X8xRSY8zQCSZOxlttfWYF/e7b25KzP0xvSylMu7z7TGpogg lb+w== X-Gm-Message-State: AOAM532SIHHdDGGnps8FHnKuuAJ5uXDLt4ZdMC3VpG4iHI0+jxa8oJx4 +TAYCyFEUPTNB+iy6fyUoBEPtCYXyro= X-Google-Smtp-Source: ABdhPJygdHqiBmpf9cCfojhqS1lQ6SqRknz2uHoMUViPUILhRS/FLBZsuYFk0zGeJ9s4D417WmnY3g== X-Received: by 2002:aa7:8a4c:: with SMTP id n12mr17162350pfa.326.1591529629630; Sun, 07 Jun 2020 04:33:49 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id ds11sm12648819pjb.0.2020.06.07.04.33.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 04:33:49 -0700 (PDT) From: Nov Matake Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_85B83CA8-2F07-42A2-A43D-FA58B4F02DA1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 20:33:46 +0900 In-Reply-To: <1ABEEE6B-761E-458B-937D-F3581BC6DE55@lodderstedt.net> Cc: Francis Pouatcha , oauth To: Torsten Lodderstedt References: <8590F26F-309F-4F84-B99F-2D29353859B5@gmail.com> <1ABEEE6B-761E-458B-937D-F3581BC6DE55@lodderstedt.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 11:33:54 -0000 --Apple-Mail=_85B83CA8-2F07-42A2-A43D-FA58B4F02DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =10Confidential clients can also use DPoP. > 2020/06/07 20:25=E3=80=81Torsten Lodderstedt = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > If the client would register for every transaction. >=20 > And don=E2=80=99t forget, DPoP also supports sender constrained access = to resource servers, which dyn registration does not. >=20 >> Am 07.06.2020 um 13:04 schrieb Nov Matake : >>=20 >> =EF=BB=BFSince each client instance has at least one key, those are = same level of state management. >>=20 >>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt = >=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>=20 >>> There are similarities in this particular use case but I would argue = DPoP is more light weight than dynamic client registration, less state = management in particular. >>>=20 >>>> Am 07.06.2020 um 05:41 schrieb Nov Matake >: >>>>=20 >>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with = dynamic client registration. >>>>=20 >>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha = >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB: >>>>>=20 >>>>>=20 >>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher = @dmarc..ietf.org = >: >>>>> >=20 >>>>> > Secondly, I do think we need a way to allow for the = refresh_token to be bound while leaving the access_tokens as bearer = tokens. This adds useful security without impacting existing RS = deployments. >>>>>=20 >>>>> +1 that=E2=80=99s a very useful = feature_______________________________________________ >>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>> --=20 >>>>> Francis Pouatcha >>>>> Co-Founder and Technical Lead at adorys >>>>> https://adorsys-platform.de/solutions/ = __________________________________= _____________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>=20 --Apple-Mail=_85B83CA8-2F07-42A2-A43D-FA58B4F02DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =10Confidential clients can also use DPoP.

2020/06/07 20:25=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

If = the client would register for every transaction.

And don=E2=80=99= t forget, DPoP also supports sender constrained access to resource = servers, which dyn registration does not.

Am = 07.06.2020 um 13:04 schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFSince each client instance has at least one key, those are = same level of state management.

2020/06/07= 16:24=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

There = are similarities in this particular use case but I would argue DPoP is = more light weight than dynamic client registration, less state = management in particular.

Am 07.06.2020 um 05:41 = schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh = token seems feature duplication with dynamic client registration.

2020/06/07 7:57=E3=80=81Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:


> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_85B83CA8-2F07-42A2-A43D-FA58B4F02DA1-- From nobody Sun Jun 7 04:49:37 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C393A00B0 for ; Sun, 7 Jun 2020 04:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 f0KIk4HKhOxk for ; Sun, 7 Jun 2020 04:49:33 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC003A00AE for ; Sun, 7 Jun 2020 04:49:32 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id x13so14413659wrv.4 for ; Sun, 07 Jun 2020 04:49:32 -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=6sm6cGBp+E/9ECzP5fY8fe7I1lmL5KNgQFSeXl195yI=; b=jTpuqnJxdkUUOLC7D3Jbo/R4OTzvy9LomLOTty+2KBJIuQKdc4qMGTFlfuqTnx1XFZ mks34VQ9HsTsJW3RrmoXABBPRyG8/3buGDXk3j4uNf9TDxVtsOZG5dy4J4yc2ScvglQb YREGf8EMqwX3xOD6eXFISdhZrHhcXq4N0GXus= 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=6sm6cGBp+E/9ECzP5fY8fe7I1lmL5KNgQFSeXl195yI=; b=ekVzBv16v9wAYj2gIRNiOz1VxQWXeWQz4n8ZWU27aIl+K2fc4zX23+44UT9U6aefk2 WcRXOwiYIZLTvtGEx8UksK8VB2UuDZoOFvBPF9JuPju5XSXZFAxIpSPNmjy9umg1gpYo t4NOapHZ5Ar4jCPynJseQ38edZ8q+/BvNmT1MDlACwHPe8HIab0A+MNg6RiizKlaQZPJ CV60PGCFBvtG4mHhG3ZRndgB3knRxwxd/lNilDUSCp+/rTBzKXB+jRlH5VSmM93unID8 mOasnlNxgZ5x32D3pvsGx60v3h9HLjfJwVR6CJqQ+rHrD+5d/727/XPTVhY/KaCHpSWS GnPg== X-Gm-Message-State: AOAM532uAQ/M6txijOwwDFFxQZ2ZCb/vm34a/98wKol+uf8Wp/fnuSYS BqTBlvptnFuPwWwh+oQqv2l33A== X-Google-Smtp-Source: ABdhPJygK3d0KEZKbuR6KkH6R61DznHb7DxyoSjth6N1pEI0+W+vo+0DWq9C2ueEavZr1dZt4jH8gQ== X-Received: by 2002:adf:f450:: with SMTP id f16mr18657711wrp.307.1591530571235; Sun, 07 Jun 2020 04:49:31 -0700 (PDT) Received: from [10.0.0.3] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id d191sm18771146wmd.44.2020.06.07.04.49.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 04:49:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4CE14C89-114C-4AF7-A471-FA31F1927791 Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 12:49:30 +0100 Message-Id: <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com> References: Cc: Torsten Lodderstedt , oauth In-Reply-To: To: Nov Matake X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 11:49:36 -0000 --Apple-Mail-4CE14C89-114C-4AF7-A471-FA31F1927791 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are multiple issues with using dynamic client registration for this. I= f a user uninstalls and later reinstalls an app then they can end up with mu= ltiple registrations for the same client, which makes it harder for them to m= anage access. Additionally, client registrations typically don=E2=80=99t exp= ire so the AS doesn=E2=80=99t know when it can remove unused clients. Besides, this ship already sailed with mTLS cert-bound refresh tokens.=20 Neil > On 7 Jun 2020, at 12:34, Nov Matake wrote: >=20 > =EF=BB=BF=10Confidential clients can also use DPoP. >=20 >> 2020/06/07 20:25=E3=80=81Torsten Lodderstedt =E3= =81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> If the client would register for every transaction. >>=20 >> And don=E2=80=99t forget, DPoP also supports sender constrained access to= resource servers, which dyn registration does not. >>=20 >>>> Am 07.06.2020 um 13:04 schrieb Nov Matake : >>>>=20 >>> =EF=BB=BFSince each client instance has at least one key, those are same= level of state management. >>>=20 >>>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt =E3= =81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>=20 >>>> There are similarities in this particular use case but I would argue DP= oP is more light weight than dynamic client registration, less state managem= ent in particular. >>>>=20 >>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake : >>>>>>=20 >>>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with dynam= ic client registration. >>>>>=20 >>>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>=20 >>>>>>>=20 >>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >>>>>>> >=20 >>>>>>> > Secondly, I do think we need a way to allow for the refresh_token t= o be bound while leaving the access_tokens as bearer tokens. This adds usefu= l security without impacting existing RS deployments. >>>>>>>=20 >>>>>>> +1 that=E2=80=99s a very useful feature_____________________________= __________________ >>>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>>> --=20 >>>>>> Francis Pouatcha >>>>>> Co-Founder and Technical Lead at adorys >>>>>> https://adorsys-platform.de/solutions/ >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4CE14C89-114C-4AF7-A471-FA31F1927791 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are multiple issues w= ith using dynamic client registration for this. If a user uninstalls and lat= er reinstalls an app then they can end up with multiple registrations for th= e same client, which makes it harder for them to manage access. Additionally= , client registrations typically don=E2=80=99t expire so the AS doesn=E2=80=99= t know when it can remove unused clients.

Besides, this ship already sailed with mTLS cert-bound refres= h tokens. 

Neil
<= div dir=3D"ltr">
On 7 Jun 2020, at 12:34, Nov M= atake <matake@gmail.com> wrote:

=EF=BB=BF=10Confidential clients can also use DPo= P.

2020/06/07 20:25=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81= =AE=E3=83=A1=E3=83=BC=E3=83=AB:

If the client would register for every transaction.

And don=E2=80= =99t forget, DPoP also supports sender constrained access to resource server= s, which dyn registration does not.

Am 07.06.2020 um 13:04 schrieb N= ov Matake <matake@gmail.co= m>:

=EF=BB=BFSince each cl= ient instance has at least one key, those are same level of state management= .

2020/06/07 16:24=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

There are similarities in this particular use case but I wo= uld argue DPoP is more light weight than dynamic client registration, less s= tate management in particular.

Am 07.06.2020 um 05:41 schrieb Nov M= atake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refr= esh token seems feature duplication with dynamic client registration.

=
2020/06/07 7:57=E3=80=81Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ie= tf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:


> Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token i= s always bound. What am I missing here?
--
<= div class=3D"">
Fra= ncis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth


<= br class=3D"">_______________________________________________OAuth mailing list
OAuth@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-4CE14C89-114C-4AF7-A471-FA31F1927791-- From nobody Sun Jun 7 05:07:52 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3323A0602 for ; Sun, 7 Jun 2020 05:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nys2v1g9HZ9 for ; Sun, 7 Jun 2020 05:07:48 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366D23A060D for ; Sun, 7 Jun 2020 05:07:48 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id s88so4809463pjb.5 for ; Sun, 07 Jun 2020 05:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q1rn9lsxTBjQfwd69BtUrezAd7VRfEQkOkDJqRv5m54=; b=f5aFAonq21vuu6YV/MRsp4T1Ie4pqNz98UHOWGrNrGjQHjaCkM2L5TBT6xJZ2zLYVy d4a7nKGX+0c8Dbcxk5X+MHutmb8PW03XMgYowvFiv4SZQoRus3fQYUiTgiJrsNG/n72V Ttubb5I5PehbDNTU4gW1NH7rrENLweTTF3hwWmQyIzCzTVLAhrNMKKLfMyzbpslNIL7i wVH+CKfG6xuqXGDkJIiXCK0WBDKyK33d0d//xJM6GBvfOdagjOKptd+VXHiJZEiWCT/9 IMfbQVGqqZPLvSmNlfN+u2cPcEmUdaUwx35bHc1aPCImz+uGvdD+zT7bnLl1NCg1H95s lUpw== 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=q1rn9lsxTBjQfwd69BtUrezAd7VRfEQkOkDJqRv5m54=; b=kFrcRvOeyzIWeLQsMHm4Ca9iVR4fAd5Ck0tcPj0X3oeOE+vuC1nknLjFcC035ZJXQJ NjOVX8s9dXfIBCspCr1kR1YMm5kN7If662DmYaw0G/N8jP65Hjk7VtlgPzLOY89zcIoa yrHMqjjdOfSkIjQEOh7JQBefMSxPrtUXVCSMYJTcwX0+2SZekF8Wau7w6/wIFDXmRTEd DbMMBKd9fK1CZWjl6pIfyJmjqCDGr5T/KbIY1Jc5t08p8s1mCEdbV6I91ovuJJkOT3ID cFQ9IZ9U4tgddVBXbyFpfy96iffAELeIzYMAcvkQQ4QHvkhmGWSGj3l9BhoZ2VeDJjCo oC5A== X-Gm-Message-State: AOAM5306cRWlA48jBht+QPLSjp+YsYWmjx2pnghwCadCtMnDHyDu7MFw 0W6V1C1GHXbnwZsRmuEC5Xc= X-Google-Smtp-Source: ABdhPJwSqFsTXbA3ZDY08n5imhNyCa0GXmxh0x47JEQDCeZ/Mj2PQLGQX+1wKeYgatI5sXFlO6i54w== X-Received: by 2002:a17:90a:e2c4:: with SMTP id fr4mr12280634pjb.32.1591531667515; Sun, 07 Jun 2020 05:07:47 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id v3sm12588200pja.8.2020.06.07.05.07.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 05:07:46 -0700 (PDT) From: Nov Matake Message-Id: <4CAC2CCD-E776-455D-914C-7BBBA1912B32@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9ACE2C3D-2286-4991-81FF-B635432EA6DD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 21:07:44 +0900 In-Reply-To: <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com> Cc: Torsten Lodderstedt , oauth To: Neil Madden References: <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 12:07:51 -0000 --Apple-Mail=_9ACE2C3D-2286-4991-81FF-B635432EA6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So, you mean=E2=80=A6 If a frontend client want to use * sender-constrained code, bearer access token and sender-constrained = refresh token, use DynReg. * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use DynReg + DPoP. * bearer code, sender-constrained access token and sender-constrained = refresh token, use DPoP only. * bearer code, bearer access token and bearer refresh token, use = neither. is my understanding correct?? > 2020/06/07 20:49=E3=80=81Neil Madden = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > There are multiple issues with using dynamic client registration for = this. If a user uninstalls and later reinstalls an app then they can end = up with multiple registrations for the same client, which makes it = harder for them to manage access. Additionally, client registrations = typically don=E2=80=99t expire so the AS doesn=E2=80=99t know when it = can remove unused clients. >=20 > Besides, this ship already sailed with mTLS cert-bound refresh tokens.=20= >=20 > Neil >=20 >> On 7 Jun 2020, at 12:34, Nov Matake wrote: >>=20 >> =EF=BB=BF=10Confidential clients can also use DPoP. >>=20 >>> 2020/06/07 20:25=E3=80=81Torsten Lodderstedt = >=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>=20 >>> If the client would register for every transaction. >>>=20 >>> And don=E2=80=99t forget, DPoP also supports sender constrained = access to resource servers, which dyn registration does not. >>>=20 >>>> Am 07.06.2020 um 13:04 schrieb Nov Matake >: >>>>=20 >>>> =EF=BB=BFSince each client instance has at least one key, those are = same level of state management. >>>>=20 >>>>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt = >=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>>>=20 >>>>> There are similarities in this particular use case but I would = argue DPoP is more light weight than dynamic client registration, less = state management in particular. >>>>>=20 >>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake >: >>>>>>=20 >>>>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with = dynamic client registration. >>>>>>=20 >>>>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha = >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB: >>>>>>>=20 >>>>>>>=20 >>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher = @dmarc..ietf.org = >: >>>>>>> >=20 >>>>>>> > Secondly, I do think we need a way to allow for the = refresh_token to be bound while leaving the access_tokens as bearer = tokens. This adds useful security without impacting existing RS = deployments. >>>>>>>=20 >>>>>>> +1 that=E2=80=99s a very useful = feature_______________________________________________ >>>>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>>>> --=20 >>>>>>> Francis Pouatcha >>>>>>> Co-Founder and Technical Lead at adorys >>>>>>> https://adorsys-platform.de/solutions/ = __________________________________= _____________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9ACE2C3D-2286-4991-81FF-B635432EA6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So, = you mean=E2=80=A6

If = a frontend client want to use
* sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg.
* sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + = DPoP.
* bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP = only.
* bearer code, bearer access token = and bearer refresh token, use neither.

is my understanding = correct??

2020/06/07 20:49=E3=80=81Neil = Madden <neil.madden@forgerock.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:

There = are multiple issues with using dynamic client registration for this. If = a user uninstalls and later reinstalls an app then they can end up with = multiple registrations for the same client, which makes it harder for = them to manage access. Additionally, client registrations typically = don=E2=80=99t expire so the AS doesn=E2=80=99t know when it can remove = unused clients.

Besides, this ship already sailed with mTLS = cert-bound refresh tokens. 

Neil

On 7 Jun = 2020, at 12:34, Nov Matake <matake@gmail.com> wrote:

=EF=BB=BF=10Confidential = clients can also use DPoP.

2020/06/07= 20:25=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

If = the client would register for every transaction.

And don=E2=80=99= t forget, DPoP also supports sender constrained access to resource = servers, which dyn registration does not.

Am = 07.06.2020 um 13:04 schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFSince each client instance has at least one key, those are = same level of state management.

2020/06/07= 16:24=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

There = are similarities in this particular use case but I would argue DPoP is = more light weight than dynamic client registration, less state = management in particular.

Am 07.06.2020 um 05:41 = schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh = token seems feature duplication with dynamic client registration.

2020/06/07 7:57=E3=80=81Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:


> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

= --Apple-Mail=_9ACE2C3D-2286-4991-81FF-B635432EA6DD-- From nobody Sun Jun 7 05:26:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90DC3A0794 for ; Sun, 7 Jun 2020 05:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Xbac19FLHric for ; Sun, 7 Jun 2020 05:26:44 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE473A078F for ; Sun, 7 Jun 2020 05:26:44 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id u13so12668426wml.1 for ; Sun, 07 Jun 2020 05:26:44 -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=heTS95f0epuub2KXWcRoshcllVSNoBA2Ne103T5ck2Y=; b=T2TjNEwm3TL0BaPcvAr/KyAw9+qAPxI5C+WRQX9OpOmq0peOvd+hM1xIYDehnxdqOi iwmw7yMSsLq1uOqr4odw4tgHmZ6ZySChZwRwGGM7RMoeu85tNq+6w+uaM0LPflKrFzsG s095V4cQln307pcriBJnvg/rWVCZ2hxj96CHs= 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=heTS95f0epuub2KXWcRoshcllVSNoBA2Ne103T5ck2Y=; b=qha4V7XUg//L4M0HNgjZlGaUeJ/1uU2tQIbnvP4RqG8KvBNx56jLA3SlpeYhfeMORI Ys4ixPXd05T/xOSZtxBIiuYSf2KxvDIrdV1q696hDILfv1U3MMCJy8qWPq4mUD91n2rm bnOQ5c7Lps8yy9I1M5y3JmyeZZg0Es//qPpFF8AukNqeuWvwo+NBU+42iabI1iKEqnoq NE/1/u1fRhMaCqcm+nwSZbWupotjtI4O3XougJ+SQNn6PkjJPywJYcCk3dzjtEzG0Nur xKCSuD9HvovLE6X3WHoqR+kt1vM3InVIj/8Gj3+IJoz//StGs9G1hiketS3iT/6Uuljs Kz/Q== X-Gm-Message-State: AOAM530fxAP7aTlBfFghZEf0TJRhKrfc1L3gCkZoIlkP6pOibp0OL99Q AO7EGAazGpUjODiPyqJ+sbiepQ== X-Google-Smtp-Source: ABdhPJx8V7lYky4BEUdGzNwg4ce3ADHdTgDI+0axc0ja5SWpJ/1WPCAr1UMBznvj4oBYxRt+RwDOUw== X-Received: by 2002:a1c:2045:: with SMTP id g66mr10241272wmg.53.1591532802509; Sun, 07 Jun 2020 05:26:42 -0700 (PDT) Received: from [10.0.0.3] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id o10sm18388033wrq.40.2020.06.07.05.26.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 05:26:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B928F2DC-EF16-4E8E-8632-418F36BB66F6 Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 13:26:41 +0100 Message-Id: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> References: <4CAC2CCD-E776-455D-914C-7BBBA1912B32@gmail.com> Cc: Torsten Lodderstedt , oauth In-Reply-To: <4CAC2CCD-E776-455D-914C-7BBBA1912B32@gmail.com> To: Nov Matake X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 12:26:48 -0000 --Apple-Mail-B928F2DC-EF16-4E8E-8632-418F36BB66F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Answers inline:=20 > On 7 Jun 2020, at 13:07, Nov Matake wrote: >=20 > =EF=BB=BFSo, you mean=E2=80=A6 >=20 > If a frontend client want to use > * sender-constrained code, bearer access token and sender-constrained refr= esh token, use DynReg. I=E2=80=99m not really sure what a sender-constrained code would be, but I s= uspect the right answer here is PKCE + DPoP. PKCE basically is PoP for auth c= odes.=20 > * sender-constrained code, sender-constrained access token and sender-cons= trained refresh token, use DynReg + DPoP. PKCE + DPoP > * bearer code, sender-constrained access token and sender-constrained refr= esh token, use DPoP only. Sure, but you should always use PKCE, so PKCE + DPoP.=20 > * bearer code, bearer access token and bearer refresh token, use neither. >=20 > is my understanding correct?? Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound toke= ns, or etc).=20 >=20 >> 2020/06/07 20:49=E3=80=81Neil Madden =E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> There are multiple issues with using dynamic client registration for this= . If a user uninstalls and later reinstalls an app then they can end up with= multiple registrations for the same client, which makes it harder for them t= o manage access. Additionally, client registrations typically don=E2=80=99t e= xpire so the AS doesn=E2=80=99t know when it can remove unused clients. >>=20 >> Besides, this ship already sailed with mTLS cert-bound refresh tokens.=20= >>=20 >> Neil >>=20 >>>> On 7 Jun 2020, at 12:34, Nov Matake wrote: >>>>=20 >>> =EF=BB=BF=10Confidential clients can also use DPoP. >>>=20 >>>> 2020/06/07 20:25=E3=80=81Torsten Lodderstedt =E3= =81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>=20 >>>> If the client would register for every transaction. >>>>=20 >>>> And don=E2=80=99t forget, DPoP also supports sender constrained access t= o resource servers, which dyn registration does not. >>>>=20 >>>>>> Am 07.06.2020 um 13:04 schrieb Nov Matake : >>>>>>=20 >>>>> =EF=BB=BFSince each client instance has at least one key, those are sa= me level of state management. >>>>>=20 >>>>>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>=20 >>>>>> There are similarities in this particular use case but I would argue D= PoP is more light weight than dynamic client registration, less state manage= ment in particular. >>>>>>=20 >>>>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake : >>>>>>>>=20 >>>>>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with dyn= amic client registration. >>>>>>>=20 >>>>>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >>>>>>>>> >=20 >>>>>>>>> > Secondly, I do think we need a way to allow for the refresh_toke= n to be bound while leaving the access_tokens as bearer tokens. This adds us= eful security without impacting existing RS deployments. >>>>>>>>>=20 >>>>>>>>> +1 that=E2=80=99s a very useful feature___________________________= ____________________ >>>>>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>>>>> --=20 >>>>>>>> Francis Pouatcha >>>>>>>> Co-Founder and Technical Lead at adorys >>>>>>>> https://adorsys-platform.de/solutions/ >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-B928F2DC-EF16-4E8E-8632-418F36BB66F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Answers inline: 

On 7 J= un 2020, at 13:07, Nov Matake <matake@gmail.com> wrote:

=EF=BB=BFSo, you mean=E2= =80=A6

If a frontend cli= ent want to use
* sender-constrained co= de, bearer access token and sender-constrained refresh token, use DynReg.
I=E2=80=99m not really sure what a sender-constrained code woul= d be, but I suspect the right answer here is PKCE + DPoP. PKCE basically is P= oP for auth codes. 

* sender-constrained code,&= nbsp;sender-constrained access token and sender-constrained&nb= sp;refresh token, use DynReg + DPoP.

PKCE + DPoP

* bearer code, sender-constrained&= nbsp;access token and sender-constrained refresh token= , use DPoP only.

Sure, but= you should always use PKCE, so PKCE + DPoP. 

* bearer code, bearer&nb= sp;access token and bearer refresh token, use neither= .

is my understanding correct??
<= /div>

Just use PKCE + DPoP. (Or a diff= erent PoP mechanism, eg mTLS cert-bound tokens, or etc). 

=
2020/06/= 07 20:49=E3=80=81Neil Madden <neil.madden@forgerock.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:

There are multiple= issues with using dynamic client registration for this. If a user uninstall= s and later reinstalls an app then they can end up with multiple registratio= ns for the same client, which makes it harder for them to manage access. Add= itionally, client registrations typically don=E2=80=99t expire so the AS doe= sn=E2=80=99t know when it can remove unused clients.

Besides, this shi= p already sailed with mTLS cert-bound refresh tokens. 

Neil
=

On 7 Jun 2020, at 12:34, Nov Matake <matake@gmail.com> wrote:

<= /blockquote>
=EF=BB=BF=10Confidential clients can also use DPoP.

2020/06/07 20:25=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB:

If the client would register for every transaction.

And don=E2=80=99= t forget, DPoP also supports sender constrained access to resource servers, w= hich dyn registration does not.

Am 07.06.2020 um 13:04 schrieb Nov M= atake <matake@gmail.com>:

=EF=BB=BFSince each clie= nt instance has at least one key, those are same level of state management.<= br class=3D"">

2020/06/07 16:24=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net= >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

There are similarities in this particular use case but I wou= ld argue DPoP is more light weight than dynamic client registration, less st= ate management in particular.

Am 07.06.2020 um 05:41 schrieb Nov Ma= take <matake@gmail.com= >:

=EF=BB=BFDPoP-bound refre= sh token seems feature duplication with dynamic client registration.

<= div class=3D"">2020/06/07 7:57=E3=80=81Francis Pouatcha <fpo=3D40adorsys.de@dmarc.iet= f.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:


> Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token i= s always bound. What am I missing here?
--
<= div class=3D"">
Fra= ncis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth


<= br class=3D"">_____________________________________________= __
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/o= auth

= --Apple-Mail-B928F2DC-EF16-4E8E-8632-418F36BB66F6-- From nobody Sun Jun 7 05:36:49 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3401C3A07A6 for ; Sun, 7 Jun 2020 05:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQpnU45OWHbr for ; Sun, 7 Jun 2020 05:36:46 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8FD3A07A0 for ; Sun, 7 Jun 2020 05:36:46 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id q16so5567504plr.2 for ; Sun, 07 Jun 2020 05:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WA2Du4DAP1Zrz2VBaFhyE4kwaSKPDswBebXwgYVJoSs=; b=X/uZDbRT/d/fktWaMkuzm4075J+pvOqrB5FTrYZ4go+1LtaoDRry2YlYnxxt5dV3AH y/ABqnkEMGIeuJK12slL/D5qm/BaNc5lJrC1m9A1n0i8RUjBrchiB1Z+qVz/q9suYwtN EFd7RlLsg0rIu8AwpjXw6QwIfkvCnAJ9mr0zwLN6P6iCpNoLMtBp6X6q6VoJdSI/Fver RWfHNwlIlCO6/VRo9tUkE+hfzV88+mD7381Ri8wI2U0huSXU2hGHBBdrgAnkPx5QQ9WC T99sgX3EHKa3kCpjWRkfuLAjCDJYfQNFh9npEVJ01SjxFPgRq+SrCts1KopvkXfv788K birg== 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=WA2Du4DAP1Zrz2VBaFhyE4kwaSKPDswBebXwgYVJoSs=; b=siaCEzpU57MMVr1QUMUvn7t7GumuYR/Z6OYyJTyFsAzOmz5imUIC0k1OQRyWbsvB/5 gXkV8GPgULRgVYLrM3n5ROPknpfxnFBCPVkyLoAwHKWQWe7bON19YnbKpY0cxi80qlUO DujzZdHanCtR6yiHDAo+3lJVQnSgG5q2XvvNkIF9GtbNsuI/GtEBsMw4bVUBmSytSUkH eyudaR4WmE7bdxrTXJ1m/rRO+X7swrixrGoHSiwHH1w3PXOL++V0P/V4YpYRWEPCE3/8 LKm9dc+B6/91QFXA1VTQj2MbSjtyHXOTaRMUob5jkBPrFnX68LuHDUSAvBYr4EHHA48N vU4g== X-Gm-Message-State: AOAM530mAjZp7gZP1ZM0l577eCAVCSER6n7VTmAsInJ7/m2ZdyDXxsel 1muInW3zYqa9XwMVQT7A5Qk= X-Google-Smtp-Source: ABdhPJzu3B6nKkT0xZxvUndBto3BKvCLh2tBqr02GmlE3FFjKigzziVrZNJTJ7fd7KjMxqz5MOIfSg== X-Received: by 2002:a17:902:a588:: with SMTP id az8mr16054786plb.318.1591533404156; Sun, 07 Jun 2020 05:36:44 -0700 (PDT) Received: from [172.16.80.125] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id 71sm4460884pfb.20.2020.06.07.05.36.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 05:36:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9A0B9C10-8229-4C32-9362-BF72B51C0220 Content-Transfer-Encoding: 7bit From: Nov Matake Mime-Version: 1.0 (1.0) Date: Sun, 7 Jun 2020 21:36:41 +0900 Message-Id: References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> Cc: Torsten Lodderstedt , oauth In-Reply-To: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> To: Neil Madden X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 12:36:48 -0000 --Apple-Mail-9A0B9C10-8229-4C32-9362-BF72B51C0220 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, both PKCE and Client Credential provide sender-constrained code... lots of choices Sent from my iPhone > On Jun 7, 2020, at 21:26, Neil Madden wrote: >=20 > =EF=BB=BF > Answers inline:=20 >=20 >>> On 7 Jun 2020, at 13:07, Nov Matake wrote: >>>=20 >> =EF=BB=BFSo, you mean=E2=80=A6 >>=20 >> If a frontend client want to use >> * sender-constrained code, bearer access token and sender-constrained ref= resh token, use DynReg. >=20 > I=E2=80=99m not really sure what a sender-constrained code would be, but I= suspect the right answer here is PKCE + DPoP. PKCE basically is PoP for aut= h codes.=20 >=20 >> * sender-constrained code, sender-constrained access token and sender-con= strained refresh token, use DynReg + DPoP. >=20 > PKCE + DPoP >=20 >> * bearer code, sender-constrained access token and sender-constrained ref= resh token, use DPoP only. >=20 > Sure, but you should always use PKCE, so PKCE + DPoP.=20 >=20 >> * bearer code, bearer access token and bearer refresh token, use neither.= >>=20 >> is my understanding correct?? >=20 > Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound to= kens, or etc).=20 >=20 >>=20 >>> 2020/06/07 20:49=E3=80=81Neil Madden =E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB: >>>=20 >>> There are multiple issues with using dynamic client registration for thi= s. If a user uninstalls and later reinstalls an app then they can end up wit= h multiple registrations for the same client, which makes it harder for them= to manage access. Additionally, client registrations typically don=E2=80=99= t expire so the AS doesn=E2=80=99t know when it can remove unused clients. >>>=20 >>> Besides, this ship already sailed with mTLS cert-bound refresh tokens.=20= >>>=20 >>> Neil >>>=20 >>>>> On 7 Jun 2020, at 12:34, Nov Matake wrote: >>>>>=20 >>>> =EF=BB=BF=10Confidential clients can also use DPoP. >>>>=20 >>>>> 2020/06/07 20:25=E3=80=81Torsten Lodderstedt = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>=20 >>>>> If the client would register for every transaction. >>>>>=20 >>>>> And don=E2=80=99t forget, DPoP also supports sender constrained access= to resource servers, which dyn registration does not. >>>>>=20 >>>>>>> Am 07.06.2020 um 13:04 schrieb Nov Matake : >>>>>>>=20 >>>>>> =EF=BB=BFSince each client instance has at least one key, those are s= ame level of state management. >>>>>>=20 >>>>>>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>>=20 >>>>>>> There are similarities in this particular use case but I would argue= DPoP is more light weight than dynamic client registration, less state mana= gement in particular. >>>>>>>=20 >>>>>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake : >>>>>>>>>=20 >>>>>>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication with dy= namic client registration. >>>>>>>>=20 >>>>>>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher : >>>>>>>>>> >=20 >>>>>>>>>> > Secondly, I do think we need a way to allow for the refresh_tok= en to be bound while leaving the access_tokens as bearer tokens. This adds u= seful security without impacting existing RS deployments. >>>>>>>>>>=20 >>>>>>>>>> +1 that=E2=80=99s a very useful feature__________________________= _____________________ >>>>>>>>> AFAIK a refresh_token is always bound. What am I missing here? >>>>>>>>> --=20 >>>>>>>>> Francis Pouatcha >>>>>>>>> Co-Founder and Technical Lead at adorys >>>>>>>>> https://adorsys-platform.de/solutions/ >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail-9A0B9C10-8229-4C32-9362-BF72B51C0220 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, both PKCE and Client Credential provi= de sender-constrained code...
lots of choices

Sent from my iPhone

On Jun 7, 2020, at 21:26, Neil Madden <neil.madden@forgerock.com> wro= te:

=EF= =BB=BF
Answers inline: 

On 7 Jun 2020, at 13:07, Nov Matake= <matake@gmail.com> wrote:

=EF=BB=BFSo, you mean=E2=80=A6

If a frontend client want to use
* sender-constrained code, bearer access t= oken and sender-constrained refresh token, use DynReg.

I=E2=80=99m not really= sure what a sender-constrained code would be, but I suspect the right answe= r here is PKCE + DPoP. PKCE basically is PoP for auth codes. 

=
*=  sender-constrained code, sender-constrained a= ccess token and sender-constrained refresh token, use DynReg= + DPoP.

PKCE + DPoP
=
* bearer code, sender-constrained access token and <= span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">se= nder-constrained refresh token, use DPoP only.
=

Sure, but you should always use PKCE, so PK= CE + DPoP. 

* bearer code, bearer access token and bea= rer refresh token, use neither.

is my understanding correct??

<= /div>
Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-= bound tokens, or etc). 


2020/06/07 20:49=E3=80=81Neil Madden <<= a href=3D"mailto:neil.madden@forgerock.com" class=3D"">neil.madden@forgerock= .com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

There are multiple issues with using dynamic client r= egistration for this. If a user uninstalls and later reinstalls an app then t= hey can end up with multiple registrations for the same client, which makes i= t harder for them to manage access. Additionally, client registrations typic= ally don=E2=80=99t expire so the AS doesn=E2=80=99t know when it can remove u= nused clients.

Besides, this ship already sailed with mTLS cert-bound r= efresh tokens. 

<= div dir=3D"ltr" class=3D"">Neil

On 7 Jun 2020, at 12:34, Nov Matake &= lt;matake@gmail.com> w= rote:

=EF=BB=BF=10Confidential c= lients can also use DPoP.

2020/06/07 20:25=E3=80=81Tor= sten Lodderstedt <t= orsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
If the client would register for e= very transaction.

And don=E2=80=99t forget, DPoP also supports sender c= onstrained access to resource servers, which dyn registration does not.

Am 07.06.2020 um 13:04 schrieb Nov Matake <matake@gmail.com>:

<= /blockquote>
=EF=BB=BFSince each client instance has at least one key, tho= se are same level of state management.

2020/06/07 16:2= 4=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

There are similaritie= s in this particular use case but I would argue DPoP is more light weight th= an dynamic client registration, less state management in particular.

Am 07.06.2020 um 05:41 schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh token seems feature duplication wi= th dynamic client registration.

2020/06/07 7:57=E3=80=81= Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB:


> Am 05.06.2020 um 22:17 schrieb G= eorge Fletcher <gffletch=3D40aol= .com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token to be= bound while leaving the access_tokens as bearer tokens. This adds useful se= curity without impacting existing RS deployments.

+1 that=E2=80=99s a very useful feature_____________________________________= __________
AFAIK a refresh_token i= s always bound. What am I missing here?
--
<= div class=3D"">
Fra= ncis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth


<= br class=3D"">_____________________________________________= __
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/o= auth

<= /body>= --Apple-Mail-9A0B9C10-8229-4C32-9362-BF72B51C0220-- From nobody Sun Jun 7 05:42:14 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202BF3A07B6 for ; Sun, 7 Jun 2020 05:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcRFnq0iJBOU for ; Sun, 7 Jun 2020 05:42:10 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE933A07B3 for ; Sun, 7 Jun 2020 05:42:10 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id p21so7425050pgm.13 for ; Sun, 07 Jun 2020 05:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=syRb+//no42A0FwLT/HIjt3Ao6AJXF51/yrCwit79ms=; b=Lo/v9Yj1FJSlOdFpaxhQUXadJihbY7GpzSQZUNK87HjZ+V2EbUmHGp2881PPqpA/wh zQ3MQUiPQisNhRmeGZteJrjvNKckKivowFzMfjNgeKNctFpTtAVBKJJs8L55b52VSl8d rPa/vxNiTzqzswIaIPm5414NosEXCfp7QVudLTjGxSkjOTmWYCzfkA2QMIhzRoYzRN2F RQFK6txj0p5IhE8HI4qNNSER33C6ZWr4dAt+nnXqUY3iKAFv2bSAgTr8VJRfgmp69V3/ O0Q6CJDmCUey+a2Z50QCLjymdCch7Y1STzHP3bcd0M5LqRfpkwj9jqYCXxtp1zDNfQnV owLg== 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=syRb+//no42A0FwLT/HIjt3Ao6AJXF51/yrCwit79ms=; b=r5w+19MgG3w1qK+jdZocoJlx5fN8zhd99a762QwoFhKvxNq+dj8FogReQONWd3Rtw8 f11eqqswBdaIHbqD/Qof+BMNRjkDFpHDuOeBmACz14PS0rIV4Ni2RJhh3hKh8In7tyoY 3CAUpAdsnJ3Y5LOB6OobOi9NdfRLRFfSRLX3uUJdS1X2JMnjIcVCGeWvsBBNJGKSxaAC EQEt4s2qe2dQEID/tLZlFpH8eLlSz1GrGyBlEJZk8ThuFE9gxjvDwu3ERg6o92+/deG6 5+3GrHT3QgWSXS3l7JcnDXD4HEwCjDNx6aXiZK52GMNx0pEh3aOW963LxeJEOAxFO0jD KYOQ== X-Gm-Message-State: AOAM530N6lzg+8UIPraVR0a/eLANAMMfcXUtMI72ZDSH4535Sdq60wiK tYdgivrV8sOY0AMxZ5yWg04= X-Google-Smtp-Source: ABdhPJyjow+oacfz4kes9UhSvK1NWbyHkhELXyXgWEpeTjBFsTa1uhvhIYh/1Bb1921j8ttEbGLVLA== X-Received: by 2002:a63:5761:: with SMTP id h33mr16102452pgm.175.1591533728958; Sun, 07 Jun 2020 05:42:08 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id p30sm3575356pgn.58.2020.06.07.05.42.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 05:42:08 -0700 (PDT) From: Nov Matake Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_100D096B-2E76-48A6-9BE5-345DB5B1F654" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 21:42:05 +0900 In-Reply-To: Cc: Torsten Lodderstedt , oauth To: Neil Madden References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 12:42:13 -0000 --Apple-Mail=_100D096B-2E76-48A6-9BE5-345DB5B1F654 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 * sender-constrained code, bearer access token and sender-constrained = refresh token, use DynReg or "PKCE + DPoP allowing access token = remaining bearer". * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP". * bearer code, sender-constrained access token and sender-constrained = refresh token, use DPoP only. * sender-constrained code, bearer access token and bearer refresh token, = use PKCE only. * bearer code, bearer access token and bearer refresh token, use none of = them. > 2020/06/07 21:36=E3=80=81Nov Matake =E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >=20 > Yeah, both PKCE and Client Credential provide sender-constrained = code... > lots of choices >=20 > Sent from my iPhone >=20 >> On Jun 7, 2020, at 21:26, Neil Madden = wrote: >>=20 >> =EF=BB=BF >> Answers inline:=20 >>=20 >>> On 7 Jun 2020, at 13:07, Nov Matake wrote: >>>=20 >>> =EF=BB=BFSo, you mean=E2=80=A6 >>>=20 >>> If a frontend client want to use >>> * sender-constrained code, bearer access token and = sender-constrained refresh token, use DynReg. >>=20 >> I=E2=80=99m not really sure what a sender-constrained code would be, = but I suspect the right answer here is PKCE + DPoP. PKCE basically is = PoP for auth codes.=20 >>=20 >>> * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use DynReg + DPoP. >>=20 >> PKCE + DPoP >>=20 >>> * bearer code, sender-constrained access token and = sender-constrained refresh token, use DPoP only. >>=20 >> Sure, but you should always use PKCE, so PKCE + DPoP.=20 >>=20 >>> * bearer code, bearer access token and bearer refresh token, use = neither. >>>=20 >>> is my understanding correct?? >>=20 >> Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS = cert-bound tokens, or etc).=20 >>=20 >>>=20 >>>> 2020/06/07 20:49=E3=80=81Neil Madden >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>=20 >>>> There are multiple issues with using dynamic client registration = for this. If a user uninstalls and later reinstalls an app then they can = end up with multiple registrations for the same client, which makes it = harder for them to manage access. Additionally, client registrations = typically don=E2=80=99t expire so the AS doesn=E2=80=99t know when it = can remove unused clients. >>>>=20 >>>> Besides, this ship already sailed with mTLS cert-bound refresh = tokens.=20 >>>>=20 >>>> Neil >>>>=20 >>>>> On 7 Jun 2020, at 12:34, Nov Matake > wrote: >>>>>=20 >>>>> =EF=BB=BF=10Confidential clients can also use DPoP. >>>>>=20 >>>>>> 2020/06/07 20:25=E3=80=81Torsten Lodderstedt = >=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>>>>=20 >>>>>> If the client would register for every transaction. >>>>>>=20 >>>>>> And don=E2=80=99t forget, DPoP also supports sender constrained = access to resource servers, which dyn registration does not. >>>>>>=20 >>>>>>> Am 07.06.2020 um 13:04 schrieb Nov Matake >: >>>>>>>=20 >>>>>>> =EF=BB=BFSince each client instance has at least one key, those = are same level of state management. >>>>>>>=20 >>>>>>>> 2020/06/07 16:24=E3=80=81Torsten Lodderstedt = >=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>>>>>>=20 >>>>>>>> There are similarities in this particular use case but I would = argue DPoP is more light weight than dynamic client registration, less = state management in particular. >>>>>>>>=20 >>>>>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake >: >>>>>>>>>=20 >>>>>>>>> =EF=BB=BFDPoP-bound refresh token seems feature duplication = with dynamic client registration. >>>>>>>>>=20 >>>>>>>>>> 2020/06/07 7:57=E3=80=81Francis Pouatcha = >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher = @dmarc..ietf.org = >: >>>>>>>>>> >=20 >>>>>>>>>> > Secondly, I do think we need a way to allow for the = refresh_token to be bound while leaving the access_tokens as bearer = tokens. This adds useful security without impacting existing RS = deployments. >>>>>>>>>>=20 >>>>>>>>>> +1 that=E2=80=99s a very useful = feature_______________________________________________ >>>>>>>>>> AFAIK a refresh_token is always bound. What am I missing = here? >>>>>>>>>> --=20 >>>>>>>>>> Francis Pouatcha >>>>>>>>>> Co-Founder and Technical Lead at adorys >>>>>>>>>> https://adorsys-platform.de/solutions/ = __________________________________= _____________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 --Apple-Mail=_100D096B-2E76-48A6-9BE5-345DB5B1F654 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
* sender-constrained code, bearer access token and = sender-constrained refresh token, use DynReg or "PKCE + DPoP allowing = access token remaining bearer".
* = sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + = DPoP".
* bearer code, sender-constrained access = token and sender-constrained refresh token, use DPoP only.
* sender-constrained code, bearer access token and bearer = refresh token, use PKCE only.
* bearer code, bearer = access token and bearer refresh token, use none of them.

2020/06/07= 21:36=E3=80=81Nov Matake <matake@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
Yeah, both PKCE and Client = Credential provide sender-constrained code...
lots of = choices

Sent from my iPhone

On Jun 7, 2020, at = 21:26, Neil Madden <neil.madden@forgerock.com> wrote:

=EF=BB=BF
Answers inline: 

On 7 Jun 2020, at 13:07, Nov Matake <matake@gmail.com> = wrote:

=EF=BB=BFSo, you mean=E2=80=A6

If a frontend client want to use
* sender-constrained code, bearer access = token and sender-constrained refresh token, use DynReg.

I=E2=80=99m not really sure what a = sender-constrained code would be, but I suspect the right answer here is = PKCE + DPoP. PKCE basically is PoP for auth codes. 

* sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + = DPoP.

PKCE + DPoP

* bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP = only.

Sure, but you should always use PKCE, = so PKCE + DPoP. 

* bearer = code, bearer access token and bearer refresh token, use = neither.

is = my understanding correct??

Just use PKCE + DPoP. = (Or a different PoP mechanism, eg mTLS cert-bound tokens, or = etc). 

2020/06/07 20:49=E3=80=81Neil Madden <neil.madden@forgerock.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:

There = are multiple issues with using dynamic client registration for this. If = a user uninstalls and later reinstalls an app then they can end up with = multiple registrations for the same client, which makes it harder for = them to manage access. Additionally, client registrations typically = don=E2=80=99t expire so the AS doesn=E2=80=99t know when it can remove = unused clients.

Besides, this ship already sailed with mTLS = cert-bound refresh tokens. 

Neil

On 7 Jun = 2020, at 12:34, Nov Matake <matake@gmail.com> wrote:

=EF=BB=BF=10Confidential = clients can also use DPoP.

2020/06/07= 20:25=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

If = the client would register for every transaction.

And don=E2=80=99= t forget, DPoP also supports sender constrained access to resource = servers, which dyn registration does not.

Am = 07.06.2020 um 13:04 schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFSince each client instance has at least one key, those are = same level of state management.

2020/06/07= 16:24=E3=80=81Torsten Lodderstedt <torsten@lodderstedt.net>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

There = are similarities in this particular use case but I would argue DPoP is = more light weight than dynamic client registration, less state = management in particular.

Am 07.06.2020 um 05:41 = schrieb Nov Matake <matake@gmail.com>:

=EF=BB=BFDPoP-bound refresh = token seems feature duplication with dynamic client registration.

2020/06/07 7:57=E3=80=81Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83= =BC=E3=83=AB:


> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

<= /div>
= --Apple-Mail=_100D096B-2E76-48A6-9BE5-345DB5B1F654-- From nobody Sun Jun 7 06:53:21 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAC3A0869 for ; Sun, 7 Jun 2020 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixFslMh7iXRj for ; Sun, 7 Jun 2020 06:53:17 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25C03A0868 for ; Sun, 7 Jun 2020 06:53:16 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 357BA7040 for ; Sun, 7 Jun 2020 13:53:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591537991; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FFnXGJGqHr9yFW3mhVU2GWM6DatoSdsQzcnhFNR8U9E=; b=S5m/INlVVAmCxIrW25/e8+NifTKv6i6vLPplDJ+4kPNDWRoIupnZOtSpPBEwwb0D+TqNhl F4bC0fS+TP0+56ZQZfs4Ah4IUpvqyASs+vcCSUWUMut4gSO+pIub8RPzTVbHx22aOmQsOJ fCH7k2wbkF+n0P396kCiLubk3+kKWQE= To: oauth@ietf.org References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> From: Daniel Fett Message-ID: <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> Date: Sun, 7 Jun 2020 15:53:10 +0200 MIME-Version: 1.0 In-Reply-To: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> Content-Type: multipart/alternative; boundary="------------CEF7BCF0D2197AF9A44417A0" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591537992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FFnXGJGqHr9yFW3mhVU2GWM6DatoSdsQzcnhFNR8U9E=; b=k6XsWOvXadDJ/Oajg0s8B4ZgiBJuSArg1Xj1sHXN2nqdUF8iSSF+8RmYa3GP+M0jv1SOGD pMICNBFlPKp3XHmmkOH36Um4/fvLIqeWcHBMeB767raXCokOEFJW3KfruAxy5g53mZLi8P 6gSlSqtUBXBVK1sgFhBQ8zFQ10Addrg= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591537992; a=rsa-sha256; cv=none; b=mg8T+yE+QkrNws0xxt47nq/NlCnCHbxv/1rxvgvphxgSnU405Bq1oo//iIwBDkXjO0rAYC A24mEOP1kWYZYmNwqZJSoQZ1z4CFIo9DK9xZ7u+N3tBsWt22cutVfHPUZiKq8JdJv6IOt0 qZI/xTPhHuJKw1Ncvt57RbLXxL555xU= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Mix-Up Revisited X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 13:53:19 -0000 This is a multi-part message in MIME format. --------------CEF7BCF0D2197AF9A44417A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, I was wondering if we should move towards introducing and (more explicitly) recommending the iss parameter in the security BCP, for the reasons laid out below and in the article (which is now at https://danielfett.de/2020/05/04/mix-up-revisited/). Any thoughts on this? -Daniel Am 04.05.20 um 19:34 schrieb Daniel Fett: > > Hi all, > > to make substantiated recommendations for FAPI 2.0, the security > considerations for PAR, and the security BCP, I did another analysis > on the threats that arise from mix-up attacks. I was interested in > particular in two questions: > > * Does PAR help preventing mix-up attacks? > * Do we need JARM to prevent mix-up attacks? > > I wrote down several attack variants and configurations in the > following document: > https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html > > The key takeaways are: > > 1. The security BCP needs to make clear that per-*AS* redirect URIs > are only sufficient if OAuth Metadata is not used to resolve > multiple issuers. Otherwise, per-*Issuer* redirect URIs or the iss > parameter MUST be used. > 2. PAR-enabled authorization servers can protect the integrity better > and protect against Mix-Up Attacks better if they ONLY accept PAR > requests. > 3. We should emphasize the importance of the iss parameter (or > issuer) in the authorization response. Maybe introduce this > parameter in the security BCP or another document? > 4. Sender-constrained access tokens help against mix-up attacks when > the access token is targeted. > 5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might > be worth looking into. > > I would like to hear your thoughts! > > -Daniel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------CEF7BCF0D2197AF9A44417A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all,
I was wondering if we should move towards introducing and (more explicitly) recommending the iss parameter in the security BCP, for the reasons laid out below and in the article (which is now at https://danielfett.de/2020/05/04/mix-up-revisited/).

Any thoughts on this?

-Daniel

Am 04.05.20 um 19:34 schrieb Daniel Fett:

Hi all,

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

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

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

The key takeaways are:

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

I would like to hear your thoughts!

-Daniel


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


--------------CEF7BCF0D2197AF9A44417A0-- From nobody Sun Jun 7 07:00:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F133A0878 for ; Sun, 7 Jun 2020 07:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyxifJ9Ps7Ma for ; Sun, 7 Jun 2020 07:00:20 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104583A0873 for ; Sun, 7 Jun 2020 07:00:20 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id f185so13819177wmf.3 for ; Sun, 07 Jun 2020 07:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NnHpR913E4ho1yLRfW1pmUmOKC/+pEGUXzV2ldKuxVo=; b=ICIGOC3Rf/RfR5er2Bp7aBCiKQjIKLOk0ww5GgVhURXzX0EfRzOJ+CGWJGCtJ6HV+u mj9ak0t0m5ic4tEiXsAahhScodEcxLQv5NSrSE6higM9NyUrOSbwRuMdgI7sHw9U96ip wG7sphKgrQVPpqbmLa1YyEriI5Oy/qaimsh9o= 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=NnHpR913E4ho1yLRfW1pmUmOKC/+pEGUXzV2ldKuxVo=; b=tVj/s6ny2w4g5TGkL2D7nkbN4zxdACrhY8BnE8CJSfKpZwptdfu2PQgeyx2ARMKfxz R/qOsBfP7ffGSvLURtnd1AIEJiACxr+/1eFPmHgazWQwk0RU7iHGdGvhDhkPss8XcObv 7OjZ2NHLjbUfqiZLbkBxvqtGSp/9JpGBiJXOkvP9yDqyvWe+d64VV4OHqMyZ+xlpxfSz TIm0SfsGsud37Ke9EUrE49f4N+acEOe830i5RX8PLrs/cmBuJyy4C2sx6zPnY4hc1JRL T/nNz0oOXkWqJAo3IVrUeoNTUyTKPppB4n00bM3QtO2diEWB3Go3gJR7QZop03ha4Eu5 saXA== X-Gm-Message-State: AOAM531t3VBKIHfu6/BLqnrJrAiEQVugfEqVMonYY52TH8MzDkYUzaAf RAu7efjvFsXP/+c1gPeS4kj0FMZgShyqGp8cFddOdg== X-Google-Smtp-Source: ABdhPJxXNLiIj6C0qXygCi+qHF+cgmHRyF930ylQihF8Kdh6OgstzTIGBhXO44LESdhLWn0F2m2oG7jGu73PnCPTGQU= X-Received: by 2002:a1c:ed0e:: with SMTP id l14mr11748364wmh.8.1591538416913; Sun, 07 Jun 2020 07:00:16 -0700 (PDT) MIME-Version: 1.0 References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> In-Reply-To: From: Francis Pouatcha Date: Sun, 7 Jun 2020 10:00:06 -0400 Message-ID: To: Nov Matake Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000fc9e5105a77ee972" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 14:00:23 -0000 --000000000000fc9e5105a77ee972 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am a little bit confused. Let me break it down: code : -> sender : Client -> consumer : AS -> sender PoP : --> confidential client: code_verifier (PKCE) --> public client: code_verifier (PKCE)? refresh_token : -> sender : Client -> consumer : AS -> sender PoP : --> confidential client: private_key_jwt, mTLS --> public client: DPoP? access_token : -> presenter : Client -> consumer : RS -> sender PoP : --> confidential client: private_key_jwt, mTLS --> public client: DPoP? Is this correct? On Sun, Jun 7, 2020 at 8:42 AM Nov Matake wrote: > * sender-constrained code, bearer access token and sender-constrained > refresh token, use DynReg or "PKCE + DPoP allowing access token remaining > bearer". > * sender-constrained code, sender-constrained access token and > sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP". > * bearer code, sender-constrained access token and sender-constrained > refresh token, use DPoP only. > * sender-constrained code, bearer access token and bearer refresh token, > use PKCE only. > * bearer code, bearer access token and bearer refresh token, use none of > them. > > 2020/06/07 21:36=E3=80=81Nov Matake =E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: > > Yeah, both PKCE and Client Credential provide sender-constrained code... > lots of choices > > Sent from my iPhone > > On Jun 7, 2020, at 21:26, Neil Madden wrote: > > =EF=BB=BF > Answers inline: > > On 7 Jun 2020, at 13:07, Nov Matake wrote: > > =EF=BB=BFSo, you mean=E2=80=A6 > > If a frontend client want to use > * sender-constrained code, bearer access token and sender-constrained ref= resh > token, use DynReg. > > > I=E2=80=99m not really sure what a sender-constrained code would be, but = I suspect > the right answer here is PKCE + DPoP. PKCE basically is PoP for auth code= s. > > * sender-constrained code, sender-constrained access token and > sender-constrained refresh token, use DynReg + DPoP. > > > PKCE + DPoP > > * bearer code, sender-constrained access token and sender-constrained ref= resh > token, use DPoP only. > > > Sure, but you should always use PKCE, so PKCE + DPoP. > > * bearer code, bearer access token and bearer refresh token, use neither. > > > is my understanding correct?? > > > Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound > tokens, or etc). > > > 2020/06/07 20:49=E3=80=81Neil Madden =E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB: > > There are multiple issues with using dynamic client registration for this= . > If a user uninstalls and later reinstalls an app then they can end up wit= h > multiple registrations for the same client, which makes it harder for the= m > to manage access. Additionally, client registrations typically don=E2=80= =99t expire > so the AS doesn=E2=80=99t know when it can remove unused clients. > > Besides, this ship already sailed with mTLS cert-bound refresh tokens. > > Neil > > --=20 Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000fc9e5105a77ee972 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am a little bit confused. Let me=C2=A0 = break it down:

code :
<= /div>
=C2=A0 -> sender : Client
=C2=A0 -> consumer : AS=
=C2=A0 -> sender PoP :=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0--> confidential client: code_verifier (PKCE)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 code_verifier (PKCE)?

refresh_token :
=C2=A0 -= > sender : Client
=C2=A0 -> consumer : AS
=C2=A0 = -> sender PoP :=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0--= > confidential client: private_key_jwt, mTLS
=C2= =A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 DPoP?
<= /div>

access_token :
=C2=A0 -> p= resenter : Client
=C2=A0 -> consumer : RS
=C2=A0 -&g= t; sender PoP :=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0= --> confidential client: private_key_jwt, mTLS
= =C2=A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 DPoP?
=C2=A0=C2=A0
Is this correct?

On Sun, Jun 7, 2020 at 8= :42 AM Nov Matake <matake@gmail.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">
* sender-constrained code, be= arer access token and sender-constrained refresh token, use DynReg or "= ;PKCE + DPoP allowing access token remaining bearer".
* send= er-constrained code, sender-constrained access token and sender-constrained= refresh token, use "DynReg + DPoP" or "PKCE + DPoP".
* bearer code, sender-constrained access token and sender-constrai= ned refresh token, use DPoP only.
* sender-constrained code, bear= er access token and bearer refresh token, use PKCE only.
* bearer= code, bearer access token and bearer refresh token, use none of them.

2020/06/07 21:36=E3=80=81Nov Matak= e <matake@gmail.co= m>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

Yeah, both PKCE and Client Credential provide sender-constrained code..= .
lots of choices

Sent from my iPhone

On Jun 7, 2020, at 21:26,= Neil Madden <neil.madden@forgerock.com> wrote:

=EF=BB=BF
Answers i= nline:=C2=A0

On 7 Jun 2020, at 13:07, Nov Matake <matake@gmail.com> wrote:

=EF=BB=BFSo, you = mean=E2=80=A6

If a frontend client want to use
*=C2=A0sender-constrained=C2=A0code,=C2=A0bearer=C2=A0<= /span>access token and=C2=A0sender-constrained=C2=A0refresh to= ken, use DynReg.

I=E2=80=99= m not really sure what a sender-constrained code would be, but I suspect th= e right answer here is PKCE + DPoP. PKCE basically is PoP for auth codes.= =C2=A0

*=C2= =A0sender-constrained=C2=A0code,=C2=A0sender-constrained= =C2=A0access token and=C2=A0sender-constrained=C2=A0ref= resh token, use DynReg + DPoP.

PKCE + DPoP

=
* bearer code,=C2=A0sender-constrained=C2=A0access token = and=C2=A0sender-constrained=C2=A0refresh token, use DPoP only.=

Sure, but you should alw= ays use PKCE, so PKCE + DPoP.=C2=A0

* bearer code,=C2=A0bearer=C2=A0access token and=C2=A0bearer=C2=A0refresh token, use neither.=
is my understanding correct??
Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS ce= rt-bound tokens, or etc).=C2=A0


2020/06/07 20:49= =E3=80=81Neil Madden <neil.madden@forgerock.com>=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB:

There are multi= ple issues with using dynamic client registration for this. If a user unins= talls and later reinstalls an app then they can end up with multiple regist= rations for the same client, which makes it harder for them to manage acces= s. Additionally, client registrations typically don=E2=80=99t expire so the= AS doesn=E2=80=99t know when it can remove unused clients.

Besides, this ship already sailed with = mTLS cert-bound refresh tokens.=C2=A0

Neil

<= /div>


= --
Francis= Pouatcha
Co-Founder and Technical Lead at adorys
--000000000000fc9e5105a77ee972-- From nobody Sun Jun 7 07:18:41 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9DB3A087F for ; Sun, 7 Jun 2020 07:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbtwJKea5yqV for ; Sun, 7 Jun 2020 07:18:37 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9019E3A087C for ; Sun, 7 Jun 2020 07:18:37 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d8so2438575plo.12 for ; Sun, 07 Jun 2020 07:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p2WW3npujaUPXCEbQXCmiDaEk+GKeaqqC2rPvK08aaw=; b=YZLjT6wSYnauHJm0h7tAKeWdcBrRyCkB+XYCDEfbC1z/v8/qdnEcv4rQjJXHdgY2Dh g/Vq+yiDclyTgmeC82+D1Cy/EN8Z9EgywUK8YDV+/IHD9aPeaK3z/RnLl3/VDbjjZffi E/LkgSpDKhOAeM485May4Ssi2Xy6tW0CYoP0gLbkQWd/4HRPoE+n18tZbITBygrnb/xT 7h5nlVqCxx+2ObJRPbOlcFfwiKVox+VBc+8ityTaN0wsgcvNvO2xLB3GenrvZF2KLc0E phD0tueoWzC5yOgP/cL6uHuUqm01K85YAU9DwBNGVjrrQ7BPQKnvLZLk6HRGcM0/TblR dGtg== 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=p2WW3npujaUPXCEbQXCmiDaEk+GKeaqqC2rPvK08aaw=; b=jfJxoLBp94CMfVX6tONP+dfI5G4e391vpBTa+TDxswPvAGG16RRz4OvZCx9NBA/GLS 7KQqsCU1Nt/ZjCUWKH7Nm1wWxLVxIH/SA0TtPjLfSqVm9btiGo3blb3/XXOhjcipQVg6 MJRK0T1tSWxZJeWTs9zoXnBlQu0k1qFd4BUkY20P1242ej3RaQBrqpOS9UhxoyZIG5Uu 4M+vPrEmRXslLqz67AjXCN8zqJWNuGu9Rk++Sh3fWEjYcteYcIK6ZChyuirclsjqk+5V /50Ck5J0ux9bCdN666cZRoXJtJKEh8++DIyHDJZE6uNc0EEhNFHUbPWonBrPHCrW2e7B 2+Dw== X-Gm-Message-State: AOAM530LF6fc8Kz0yH7okg01UdPtnoRaRbLKSkufU39cOCyiLuWkS0fZ O4EEmy5MNRJzU83TBv/hqks= X-Google-Smtp-Source: ABdhPJx0YB/fwOsp0eejW0L+izR48JMgIVyz8tdAw14WLamyFbJsJ9Xv1TWvTzR2VahtYbQh2ibvpg== X-Received: by 2002:a17:90a:cf17:: with SMTP id h23mr12877265pju.139.1591539516803; Sun, 07 Jun 2020 07:18:36 -0700 (PDT) Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id a14sm4444151pfc.133.2020.06.07.07.18.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 07:18:36 -0700 (PDT) From: Nov Matake Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9CEA000A-3B2E-4CC4-9828-3D019FC64F5C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 23:18:33 +0900 In-Reply-To: Cc: Neil Madden , oauth To: Francis Pouatcha References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 14:18:40 -0000 --Apple-Mail=_9CEA000A-3B2E-4CC4-9828-3D019FC64F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =10private_key_jwt and mTLS can be sender PoP method for code too. > 2020/06/07 23:00=E3=80=81Francis Pouatcha = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > I am a little bit confused. Let me break it down: >=20 > code : > -> sender : Client > -> consumer : AS > -> sender PoP :=20 > --> confidential client: code_verifier (PKCE) > --> public client: code_verifier (PKCE)? >=20 > refresh_token : > -> sender : Client > -> consumer : AS > -> sender PoP :=20 > --> confidential client: private_key_jwt, mTLS > --> public client: DPoP? >=20 > access_token : > -> presenter : Client > -> consumer : RS > -> sender PoP :=20 > --> confidential client: private_key_jwt, mTLS > --> public client: DPoP? > =20 > Is this correct? >=20 > On Sun, Jun 7, 2020 at 8:42 AM Nov Matake > wrote: > * sender-constrained code, bearer access token and sender-constrained = refresh token, use DynReg or "PKCE + DPoP allowing access token = remaining bearer". > * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP". > * bearer code, sender-constrained access token and sender-constrained = refresh token, use DPoP only. > * sender-constrained code, bearer access token and bearer refresh = token, use PKCE only. > * bearer code, bearer access token and bearer refresh token, use none = of them. >=20 >> 2020/06/07 21:36=E3=80=81Nov Matake >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> Yeah, both PKCE and Client Credential provide sender-constrained = code... >> lots of choices >>=20 >> Sent from my iPhone >>=20 >>> On Jun 7, 2020, at 21:26, Neil Madden > wrote: >>>=20 >>> =EF=BB=BF >>> Answers inline:=20 >>>=20 >>>> On 7 Jun 2020, at 13:07, Nov Matake > wrote: >>>>=20 >>>> =EF=BB=BFSo, you mean=E2=80=A6 >>>>=20 >>>> If a frontend client want to use >>>> * sender-constrained code, bearer access token and = sender-constrained refresh token, use DynReg. >>>=20 >>> I=E2=80=99m not really sure what a sender-constrained code would be, = but I suspect the right answer here is PKCE + DPoP. PKCE basically is = PoP for auth codes.=20 >>>=20 >>>> * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use DynReg + DPoP. >>>=20 >>> PKCE + DPoP >>>=20 >>>> * bearer code, sender-constrained access token and = sender-constrained refresh token, use DPoP only. >>>=20 >>> Sure, but you should always use PKCE, so PKCE + DPoP.=20 >>>=20 >>>> * bearer code, bearer access token and bearer refresh token, use = neither. >>>>=20 >>>> is my understanding correct?? >>>=20 >>> Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS = cert-bound tokens, or etc).=20 >>>=20 >>>>=20 >>>>> 2020/06/07 20:49=E3=80=81Neil Madden >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>=20 >>>>> There are multiple issues with using dynamic client registration = for this. If a user uninstalls and later reinstalls an app then they can = end up with multiple registrations for the same client, which makes it = harder for them to manage access. Additionally, client registrations = typically don=E2=80=99t expire so the AS doesn=E2=80=99t know when it = can remove unused clients. >>>>>=20 >>>>> Besides, this ship already sailed with mTLS cert-bound refresh = tokens.=20 >>>>>=20 >>>>> Neil >>>>>=20 >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ = --Apple-Mail=_9CEA000A-3B2E-4CC4-9828-3D019FC64F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =10private_key_jwt and mTLS can be sender PoP method for code = too.

2020/06/07 23:00=E3=80=81Francis Pouatcha = <fpo@adorsys.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
I am a little bit confused. Let me  break it = down:

code :
  = -> sender : Client
  -> consumer : = AS
  -> sender PoP : 
       --> confidential client: = code_verifier (PKCE)
    =    --> public client:  code_verifier (PKCE)?

refresh_token :
  -> sender : = Client
  -> consumer : AS
  -> sender PoP : 
       --> confidential client: = private_key_jwt, mTLS
       --> public = client:  DPoP?

access_token :
  -> presenter : Client
  -> consumer : RS
  -> = sender PoP : 
       --> confidential client: = private_key_jwt, mTLS
       --> public = client:  DPoP?
  
Is this correct?

On Sun, Jun = 7, 2020 at 8:42 AM Nov Matake <matake@gmail.com> wrote:
* sender-constrained code, = bearer access token and sender-constrained refresh token, use DynReg or = "PKCE + DPoP allowing access token remaining bearer".
* sender-constrained code, sender-constrained access token = and sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + = DPoP".
* bearer code, sender-constrained access = token and sender-constrained refresh token, use DPoP only.
* sender-constrained code, bearer access token and bearer = refresh token, use PKCE only.
* bearer code, bearer = access token and bearer refresh token, use none of them.

2020/06/07 21:36=E3=80=81Nov Matake <matake@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
Yeah, = both PKCE and Client Credential provide sender-constrained code...
lots of choices

Sent from my iPhone

On Jun 7, = 2020, at 21:26, Neil Madden <neil.madden@forgerock.com> wrote:

=EF=BB=BF
Answers = inline: 

On 7 Jun = 2020, at 13:07, Nov Matake <matake@gmail.com> wrote:

=EF=BB=BFSo, you mean=E2=80=A6

If a frontend client = want to use
* sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg.

I=E2=80=99m not really sure what a = sender-constrained code would be, but I suspect the right answer here is = PKCE + DPoP. PKCE basically is PoP for auth codes. 

* sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + = DPoP.

PKCE + DPoP

* bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP = only.

Sure, but you should always use PKCE, = so PKCE + DPoP. 

* bearer = code, bearer access token and bearer refresh token, use = neither.

is = my understanding correct??

Just use PKCE + DPoP. = (Or a different PoP mechanism, eg mTLS cert-bound tokens, or = etc). 

2020/06/07 20:49=E3=80=81Neil Madden <neil.madden@forgerock.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:

There are multiple issues with = using dynamic client registration for this. If a user uninstalls and = later reinstalls an app then they can end up with multiple registrations = for the same client, which makes it harder for them to manage access. = Additionally, client registrations typically don=E2=80=99t expire so the = AS doesn=E2=80=99t know when it can remove unused clients.

Besides, this ship already sailed with mTLS cert-bound = refresh tokens. 

Neil



-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

= --Apple-Mail=_9CEA000A-3B2E-4CC4-9828-3D019FC64F5C-- From nobody Sun Jun 7 08:02:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705C23A0901 for ; Sun, 7 Jun 2020 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MsN7F1G42dc for ; Sun, 7 Jun 2020 08:02:51 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CE73A0900 for ; Sun, 7 Jun 2020 08:02:50 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id q25so13933360wmj.0 for ; Sun, 07 Jun 2020 08:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BehMBOiQSkhnQZzBOW7RdkATCrzc3Oj1N/WdItd1tPU=; b=SclQjIG7iRY2CC+7BVxVdXryBIkexLjhynmD796H4CKQKIleX1icd2rmejBZn1CIBA DNd0+hjmCviBroKxZSM+oMcFIL4Mzhed6UrKEeku5yACyk/cVDTf+6HBx/LpyIqKDotl W8yLmLUTnvNrIy9cK9JtIVAjfKia13ISdtWR8= 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=BehMBOiQSkhnQZzBOW7RdkATCrzc3Oj1N/WdItd1tPU=; b=FPALnd/Rz3RRt48lVE/WiVs7FYV9HLZeXSCmgwCxTUZohlv1VKy1cHNdPHQ74WV/13 8+adx+KnY+S2s2toF3n0rpl3P16BYcqjrxUqloGSkICMocdE99VDMyfb0DItD8BqseS2 4532pGaeqzCycjj0B42PK0MPCPqWfKMMB0B0c7XePBexWFKVH4u+N0RihtfMi0cduRhT Kcs4TniMdgA6GtpNeNHC0KhFChAfvITGJlYCVB5R/9IsvpUwO8LcAMC2DFHtF6HCGAGc BcgcECVxRlTohXrHQlvuscUVsfPYBXU19M+nOEZTIqEtqo0GNrfDK3RUpV5cb8k/SNYr DMyg== X-Gm-Message-State: AOAM530vsT23d0fBJPJgc3z6QMS39PQHI7F0XMjBtS/KLkSwyvvM2VkX k38WmfCE9nnxqUs/dEOYWCsxo6ia0R/je64Ji66fiw== X-Google-Smtp-Source: ABdhPJzdHu4f215e/6WkwjAhPLRjgy6fp71Rz8HbX/Q1CLQlksQYk8cvDrdsPlGDqxby4Kwt2umyZ4xlfMX5ILprNv4= X-Received: by 2002:a1c:9802:: with SMTP id a2mr11516198wme.64.1591542169357; Sun, 07 Jun 2020 08:02:49 -0700 (PDT) MIME-Version: 1.0 References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> In-Reply-To: From: Francis Pouatcha Date: Sun, 7 Jun 2020 11:02:38 -0400 Message-ID: To: Nov Matake , Daniel Fett Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000a662ba05a77fc97b" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 15:02:54 -0000 --000000000000a662ba05a77fc97b Content-Type: text/plain; charset="UTF-8" On Sun, Jun 7, 2020 at 10:18 AM Nov Matake wrote: > private_key_jwt and mTLS can be sender PoP method for code too. > > Yes,correct thanks for pointing this out: So we have code : -> sender : Client -> consumer : AS -> sender PoP : --> confidential client: [code_verifier (PKCE) AND [ private_key_jwt XOR mTLS ] ] --> public client: code_verifier (PKCE) AND ? refresh_token : -> sender : Client -> consumer : AS -> sender PoP : --> confidential client: private_key_jwt, mTLS --> public client: DPoP AND ? access_token : -> presenter : Client -> consumer : RS -> sender PoP : --> confidential client: private_key_jwt, mTLS --> public client: DPoP AND ? @Daniel Fett I still have some question marks in here. Am I missing anything? -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000a662ba05a77fc97b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 7, 2020 at 10:18 AM Nov M= atake <matake@gmail.com> wrot= e:
private_key_jwt and mTLS can be sender PoP me= thod for code too.


Yes,correct thanks for pointing this out: So we have=C2= =A0
code :
=C2=A0 -> sender : C= lient
=C2=A0 -> consumer : AS
=C2=A0 -> sender Po= P :=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> confidential client: = [code_verifier (PKCE)=C2=A0 AND [ private_key_jwt XOR mTLS ] ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 code_verifier (PK= CE) AND ?

refresh_token :
=C2=A0 -> sender : Client
=C2=A0 -> consumer : AS
<= div>=C2=A0 -> sender PoP :=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0--> confidential client: private_key_jwt, mTLS
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 DPoP AND ?<= /div>

access_token :
=C2=A0 -> presenter : Client
=C2=A0 -> consumer : RS
=C2=A0 -> sender PoP :=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0--> confidential client: private_key_jwt, mTLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0--> public client:=C2=A0 DPoP= AND ?

@Daniel Fett=C2=A0 I still have some question marks in h= ere. Am I missing anything?=C2=A0
--
Francis Pouatcha
Co-Founder a= nd Technical Lead at adorys
--000000000000a662ba05a77fc97b-- From nobody Sun Jun 7 10:11:28 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B03A0A0C for ; Sun, 7 Jun 2020 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b2Lmyt2HVl8 for ; Sun, 7 Jun 2020 10:11:23 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4CD3A097D for ; Sun, 7 Jun 2020 10:11:23 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id o15so15605820ejm.12 for ; Sun, 07 Jun 2020 10:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0oCR8Sfw57slKLZ8mF0CS7eI5mkceIlO0OAyxWhAkLQ=; b=TeFSW6OO9cu3jlMwv3o8X2+g9+uEZyPFK0S0cttbQI5JvC3PXX3PLYmHtGRXyayHUp kwPwogp7E+nqZInqy9ybNJDKM15hzeUa4/4VFk5T2IP7OoegHZS7UUbCPARzOKi74gl7 pAsX/O41FVzP9CQDtMoaH/rX+fZgghrAYsvAzizm9yjWD0sUkbRENx3VnG9IBZ9faCxT 2OBL+6p6xeCo0QDukgutawikotKF3rkzavxAujPgbkLL5mY0y0XRzAQnE9jMGf0iscWQ HGSHBXe0g+RkhVEFJ4HemJTWyYmDiLrwhJhmlXKEw2aFcXngu4CuXcH6ZbfLspgyIYb8 VizA== 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=0oCR8Sfw57slKLZ8mF0CS7eI5mkceIlO0OAyxWhAkLQ=; b=tguusGgk0Vi77Pqnf+wTFuB2qD3/NAHDvhH+mqCB73UlplobiM4JnQLYOgokDNZbtM xOXDayRaOoIhmJeLjWdEa4KD6sR5G72aErFOZDuuidrqKyw1BnbZhlunbud4YdpDBTYQ KBkPoAUtd0zPTUwJrLd3aeXYcZGXUKeceA53wn5X13MoiqRjSlPXmyfVZ8nXiiYgHtOQ LOTBqfyxONkRqmqYXdsybELwPOSCBR+DXnNgT40ZuqEAFTiWaRqWpkAXOZu8hg2cjnIW VWQZrSzjE4pDfglg0vEBAhAfmvpwq8JoH1FJjNZWvj0unyRCuIdTL20WJuz+uoBP08W4 KACA== X-Gm-Message-State: AOAM531vbjP6IPu5EibSMKRNvOf0MgCgQAIEDvO/iZy0HITz/xg+MrPh zbDqte2EALWcuuW9pJ+uvI7dvw== X-Google-Smtp-Source: ABdhPJxoJcB9E5MxDP9o0m239skP4YTS83IYtC6O1uSLNdeknp4o0gIh2op4P6QCfmj8fWC08AtKWg== X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr17144160eja.377.1591549881597; Sun, 07 Jun 2020 10:11:21 -0700 (PDT) Received: from p200300eb8f184cac11bf175ea3b0e1bc.dip0.t-ipconnect.de (p200300eb8f184cac11bf175ea3b0e1bc.dip0.t-ipconnect.de. [2003:eb:8f18:4cac:11bf:175e:a3b0:e1bc]) by smtp.gmail.com with ESMTPSA id t9sm8888697ejy.43.2020.06.07.10.11.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 10:11:20 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <1164F63D-F22E-4B70-96A0-BC83779587F1@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D3B632E5-1A72-4D7F-B634-1C11B7C7D803"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 19:11:18 +0200 In-Reply-To: Cc: Francis Pouatcha , oauth To: Nov Matake References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 17:11:26 -0000 --Apple-Mail=_D3B632E5-1A72-4D7F-B634-1C11B7C7D803 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7. Jun 2020, at 16:18, Nov Matake wrote: >=20 > =10private_key_jwt and mTLS can be sender PoP method for code too. Seems we need to distinguish certain =E2=80=9Ckinds=E2=80=9D of PoP for = code.=20 1) private_key_jwt, mTLS and other client secrets can be used to = authenticate the client and thus check the binding of the code to a = particular client_id. 2) PKCE is different in that it allows to tie the code to a certain = transaction running on a certain device.=20 (2) detects code replay at the same client_id on a different device, (1) = does not.=20 Regarding PoP for access tokens: private_key_jwt does not provide this = capability. mTLS and DPoP provide it for both confidential and public = clients.=20 >=20 >> 2020/06/07 23:00=E3=80=81Francis Pouatcha = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>=20 >> I am a little bit confused. Let me break it down: >>=20 >> code : >> -> sender : Client >> -> consumer : AS >> -> sender PoP :=20 >> --> confidential client: code_verifier (PKCE) >> --> public client: code_verifier (PKCE)? >>=20 >> refresh_token : >> -> sender : Client >> -> consumer : AS >> -> sender PoP :=20 >> --> confidential client: private_key_jwt, mTLS >> --> public client: DPoP? >>=20 >> access_token : >> -> presenter : Client >> -> consumer : RS >> -> sender PoP :=20 >> --> confidential client: private_key_jwt, mTLS >> --> public client: DPoP? >> =20 >> Is this correct? >>=20 >> On Sun, Jun 7, 2020 at 8:42 AM Nov Matake wrote: >> * sender-constrained code, bearer access token and sender-constrained = refresh token, use DynReg or "PKCE + DPoP allowing access token = remaining bearer". >> * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP". >> * bearer code, sender-constrained access token and sender-constrained = refresh token, use DPoP only. >> * sender-constrained code, bearer access token and bearer refresh = token, use PKCE only. >> * bearer code, bearer access token and bearer refresh token, use none = of them. >>=20 >>> 2020/06/07 21:36=E3=80=81Nov Matake =E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>=20 >>> Yeah, both PKCE and Client Credential provide sender-constrained = code... >>> lots of choices >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jun 7, 2020, at 21:26, Neil Madden = wrote: >>>>=20 >>>> =EF=BB=BF >>>> Answers inline:=20 >>>>=20 >>>>> On 7 Jun 2020, at 13:07, Nov Matake wrote: >>>>>=20 >>>>> =EF=BB=BFSo, you mean=E2=80=A6 >>>>>=20 >>>>> If a frontend client want to use >>>>> * sender-constrained code, bearer access token and = sender-constrained refresh token, use DynReg. >>>>=20 >>>> I=E2=80=99m not really sure what a sender-constrained code would = be, but I suspect the right answer here is PKCE + DPoP. PKCE basically = is PoP for auth codes.=20 >>>>=20 >>>>> * sender-constrained code, sender-constrained access token and = sender-constrained refresh token, use DynReg + DPoP. >>>>=20 >>>> PKCE + DPoP >>>>=20 >>>>> * bearer code, sender-constrained access token and = sender-constrained refresh token, use DPoP only. >>>>=20 >>>> Sure, but you should always use PKCE, so PKCE + DPoP.=20 >>>>=20 >>>>> * bearer code, bearer access token and bearer refresh token, use = neither. >>>>>=20 >>>>> is my understanding correct?? >>>>=20 >>>> Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS = cert-bound tokens, or etc).=20 >>>>=20 >>>>>=20 >>>>>> 2020/06/07 20:49=E3=80=81Neil Madden = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>=20 >>>>>> There are multiple issues with using dynamic client registration = for this. If a user uninstalls and later reinstalls an app then they can = end up with multiple registrations for the same client, which makes it = harder for them to manage access. Additionally, client registrations = typically don=E2=80=99t expire so the AS doesn=E2=80=99t know when it = can remove unused clients. >>>>>>=20 >>>>>> Besides, this ship already sailed with mTLS cert-bound refresh = tokens.=20 >>>>>>=20 >>>>>> Neil >>>>>>=20 >>=20 >>=20 >> --=20 >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D3B632E5-1A72-4D7F-B634-1C11B7C7D803 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3 DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4 uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3 sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6 yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4 VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI 5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ 8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjA3MTcxMTE4 WjAvBgkqhkiG9w0BCQQxIgQgsetxqcrvOixO3W/LOpOmMIA3VFJ6LuJCoUMgaKYvtj8wgbMGCSsG AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7 IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAYniWyaCXx0JDOjFUYRFigMAV/5Y+ XUnfzNG3V7oRc2PErgdAXeRWmw1TjYdPmkj69oWzewT2zF/M5ENMl+1cHmqEGZnUiKgKOCGawIkj zqJ0ejLeumlyEyvIqpdRvkG2ZEiEUcpmgu+tCxvjqikrtOTVIHDlcUcMiBZ2mql+CRVLQyVj3yCz Qii5Dqvqf4akMXtZ5Ku+9DeIOwpajDFwrp2y9r/yfMmQ6MMRWKwKqGpnv7TXCzf4lgLh4U5/V+wE G45QkO6hOnPLfMiEhORu2YSb7mPzCr29RudomAMJn9QA3jv6U75/oYtg4R7AdVN+3tMkya8zkRXy nDKMKVknEQAAAAAAAA== --Apple-Mail=_D3B632E5-1A72-4D7F-B634-1C11B7C7D803-- From nobody Mon Jun 8 00:46:07 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A53A094D for ; Mon, 8 Jun 2020 00:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qYY-UJF92ww for ; Mon, 8 Jun 2020 00:46:04 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A7D3A094C for ; Mon, 8 Jun 2020 00:46:04 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 0D1FB7381 for ; Mon, 8 Jun 2020 07:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591602359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EqJLJ2x84E8ehxzkFSASqIdMfsQR2kwQvLXiuSBdXJM=; b=fySrVNU4r60+ZMnaxhVod4thSxaKyIUkdEqKY1H7MuE+hzXeElr96CiWWqKXYOWnnQxmed zbmdxGutZc8y3WvswbTBhJHt7TXgaMJJRWsPxmKXh2MOtY+2mGGjTBZ/CF8+R4WYBHEvUd V82GFqrkY2PPXnH3qRe3IrRVaLsaaxY= From: Daniel Fett To: oauth@ietf.org Message-ID: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> Date: Mon, 8 Jun 2020 09:45:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------084F7C924782983087B2DAF6" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591602359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EqJLJ2x84E8ehxzkFSASqIdMfsQR2kwQvLXiuSBdXJM=; b=XEU2XZNULbEZP68tYi0gMdNt7YXjVRrJmBcdQVEUP9qGiqDWrtrqQOSDC6IFs049ktGwKS a2nqOsv66rH/wxg0X15RHkaFdn3+vYSVgyGl1DV0RikSNezKVmWsxIMcsnGsUs6tFMSsWn JXUAbBjOBKbpHN/pr3diFyPW47dvOsA= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591602359; a=rsa-sha256; cv=none; b=Y1ZwG4pZYVT7C8BEjS6KFgDqVacDnIltdboMgB4E0GmkgTBzn3AkZHonTjaQEWFodPh/uj ZWDPu66oTDnyGZsnLeJKx8Q32LdKoPvJiOgDqoAqKx1n7THC+zZ67ESTrrONTBB83zqJkc QDqL6FbDh96gRaAWzUIm4cnawb2L65U= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jun 2020 07:46:07 -0000 This is a multi-part message in MIME format. --------------084F7C924782983087B2DAF6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, RFC8414 says that the URI where the OAuth metadata document is published = is formed by inserting a well-known URI string into the authorization server's issuer identifier between the host component and the path component, if any. By default, the well-known URI string used is "/.well-known/oauth-authorization-server". I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.= Is this a common deviation from the spec? Do you know how specific products handle this? Does it make sense to serve the metadata document from both locations? -Daniel --------------084F7C924782983087B2DAF6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

RFC8414 says that the URI where the OAuth metadata document is published is

formed by inserting a well-known URI string into the authorization
   server's issuer identifier between the host component and the path
   component, if any.  By default, the well-known URI string used is
   "/.well-known/oauth-authorization-server".

I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.

Is this a common deviation from the spec?

Do you know how specific products handle this?

Does it make sense to serve the metadata document from both locations?

-Daniel

--------------084F7C924782983087B2DAF6-- From nobody Mon Jun 8 00:55:03 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECB73A0962 for ; Mon, 8 Jun 2020 00:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 ZgHbgdwTbbGh for ; Mon, 8 Jun 2020 00:54:59 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414833A095F for ; Mon, 8 Jun 2020 00:54:54 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id c35so12620763edf.5 for ; Mon, 08 Jun 2020 00:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=PJ4G+yYgbGiMGfIRcqUD019pac/6ZnKPcGAyRbqVfW0=; b=HD9hK0bsS+fYjH3JX4vfVo9RfnT0kJgbXVDpIwqY/yim9frRszA2FOKoATMx8jDSVw 4QtDIEetmZqdmKjo9bKNaTPtjIJqKCWuq/U8BRU6zY1KewstXYA20h54kLVtqQLSDDFj JJZ0Kkn5AbOvhovlLl6NUZXXxKtqmc2vWqWcbZ0oHkSl/6lMdek4Eou009abzA9gRm+0 D6dAXnZaBDsgJwXqplhnZz88M4JGJouQos7zwlkFUbcZYfSxA9OANt+iys6yMaQIa4tD wqR6dI4nrFHoFMEMywoKjEnUwhdaN/irBqoH2U0Fm2qOIxF01TZ/Y+iU8eSUQ8aS29M0 RdJg== 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=PJ4G+yYgbGiMGfIRcqUD019pac/6ZnKPcGAyRbqVfW0=; b=TI4RPN3JV1142znuWZb6kUFaYXyD30lbvmoYixeVrgJHLURgI+AnlRfg9IxfR5bZ7c e66bmNitEUKPD0EzVZo/z4e4j3HQwB/njr+F82u/w7oh211K0ZLofBVtyraO6NhkmNSE wqFDqj71tc5umKpOCXrYxh6h4YEsOyDtzvA5Uhm2oPFgaY1E8Mc6l3zMHuamE+9O3s26 eiO4O55TmTuL38tTXPg0vZ0kjAao5jRQSiQd8htnlbaZsa13eXfms43om8XaZgcarCDW Or4CYkGUFs+UCgNXz/gBodEXoCNpG0EuoYsQjtQ5m4haolRId6kIds0Bxyr5Q7jZdXrh ujVA== X-Gm-Message-State: AOAM5301wjyCz/447F705fExOWIsb7HzWvGfKhSvGRkDBbEgQ733zdxQ cxf40X+FLob5CCKps/F6LDPMdktTmw== X-Google-Smtp-Source: ABdhPJwgOCSi3reR+A8XlHIYcXjGpK+AJZ1i3MXSmEkhCV5+CIl0sYDbRWNsZKvgas6hbd+j3A4lgA== X-Received: by 2002:a05:6402:2d5:: with SMTP id b21mr21797110edx.293.1591602891435; Mon, 08 Jun 2020 00:54:51 -0700 (PDT) Received: from [100.66.206.216] (ip-37-188-244-216.eurotel.cz. [37.188.244.216]) by smtp.gmail.com with ESMTPSA id j11sm10229978ejf.53.2020.06.08.00.54.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 00:54:50 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E2A82EF0-0E42-480A-97CB-8F88988427EB Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Mon, 8 Jun 2020 09:54:50 +0200 Message-Id: References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> Cc: oauth@ietf.org In-Reply-To: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> To: Daniel Fett X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jun 2020 07:55:01 -0000 --Apple-Mail-E2A82EF0-0E42-480A-97CB-8F88988427EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Some products publish both, but they don=E2=80=99t always return the same co= ntent, eventho as far as i can tell they should be aliases.=20 The uri normalization of 8414 is also implemented wrong in some cases, since= it differs from OIDC as far as issuer path component is concerned. I find it best for AS to have just one or both with the same content, client= software doing discovery can check both locations.=20 Odesl=C3=A1no z iPhonu > 8. 6. 2020 v 9:46, Daniel Fett : >=20 > =EF=BB=BF > Hi all, >=20 > RFC8414 says that the URI where the OAuth metadata document is published i= s >=20 > formed by inserting a well-known URI string into the authorization > server's issuer identifier between the host component and the path > component, if any. By default, the well-known URI string used is > "/.well-known/oauth-authorization-server". >=20 > I found that some OAuth servers and clients instead follow the convention u= sed by OpenID Connect, where the suffix "/.well-known/openid-configuration" (= or "/.well-known/oauth-authorization-server") is appended to the issuer URL.= >=20 > Is this a common deviation from the spec?=20 >=20 > Do you know how specific products handle this?=20 >=20 > Does it make sense to serve the metadata document from both locations? >=20 > -Daniel >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E2A82EF0-0E42-480A-97CB-8F88988427EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Some products publish both, but they don=E2= =80=99t always return the same content, eventho as far as i can tell they sh= ould be aliases. 

The uri normalization of 8414 is a= lso implemented wrong in some cases, since it differs from OIDC as far as is= suer path component is concerned.

I find it best fo= r AS to have just one or both with the same content, client software doing d= iscovery can check both locations. 

Odesl=C3=A1= no z iPhonu

8. 6. 2= 020 v 9:46, Daniel Fett <fett@danielfett.de>:

=EF=BB=BF =20 =20 =20

Hi all,

RFC8414 says that the URI where the OAuth metadata document is published is

fo=
rmed by inserting a well-known URI string into the authorization
   server's issuer identifier between the host component and the path
   component, if any.  By default, the well-known URI string used is
   "/.well-known/oauth-authorization-server".

I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.

Is this a common deviation from the spec?

Do you know how specific products handle this?

Does it make sense to serve the metadata document from both locations?

-Daniel

=20 _______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-E2A82EF0-0E42-480A-97CB-8F88988427EB-- From nobody Mon Jun 8 02:15:16 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5F3A0477 for ; Mon, 8 Jun 2020 02:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaEcbh26PSzK for ; Mon, 8 Jun 2020 02:15:13 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13783A045B for ; Mon, 8 Jun 2020 02:15:12 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id B64D67388; Mon, 8 Jun 2020 09:15:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591607708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LYAp/UxygRGgxAYZPKBXvhEpSNZehD1mGM/mB6g2B50=; b=XRqAxIgz9QZo8xu2tJptphNLuI6ngYFKGkZqearkCqIkq/ULiE0/HxxCyL5gkTHVZYMpsO emWa+Q0HrROctGoWdSzqhU8l1Q0kyHrq6OfbwI8Euoy+VnFSucGm6bEwWyFTPoE0dbnJvG 2n/0c+a6NEub949tv1KXTXxkRnQeZUo= To: Filip Skokan Cc: oauth@ietf.org References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> From: Daniel Fett Message-ID: Date: Mon, 8 Jun 2020 11:15:07 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9CD0E2190421D46AE07082EB" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591607709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LYAp/UxygRGgxAYZPKBXvhEpSNZehD1mGM/mB6g2B50=; b=quTOY1CZMKcKaz+Nzoezw++wluRmjoX117k7/xshRtH4QbBe+ibrY1I+5rxkPbFIgD+V2z SN69BzWPU8Hkpe8L65nXjPwB+8UrRhUAyNNCXLt/4ujpp/4+jIqI0vEVFhiRUmbFvf25gm lzlQJbscvqu2jO3WOTUDtGUuvEOrlRU= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591607709; a=rsa-sha256; cv=none; b=E037TR60M5jfiV5asHE5n+P4NtRYsv+MiIU9Fey9zimSndUsNlS/pr9XD9b2h8Ivmcx9Be vhTHV+iXWkWYuM/vKRx4rHzUFUDuASvf1TJRhIbgzcvspJBHEJEG782zbRCn842ldl2LEp yBRBfpCRvJA7nVG1n/qQ606TOQxsiiU= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: + Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jun 2020 09:15:15 -0000 This is a multi-part message in MIME format. --------------9CD0E2190421D46AE07082EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Filip, Thanks for your answers! I'm not quite sure if the wording in my question was clear: My main concern is the difference between https://example.com/some/path*/.well-known/oauth-authorization-server* and https://example.com*/.well-known/oauth-authorization-server*/some/path, i.e., the usage of the well-known URI as a postfix or as an infix. Am 08.06.20 um 09:54 schrieb Filip Skokan: > Some products publish both, but they don’t always return the same > content, eventho as far as i can tell they should be aliases. > The uri normalization of 8414 is also implemented wrong in some cases, > since it differs from OIDC as far as issuer path component is concerned. This is where I'm not sure whether all products follow RFC8414 and properly use the well-known part as an infix. > > I find it best for AS to have just one or both with the same content, > client software doing discovery can check both locations. That would be the safe implementation, but I was wondering if prescribing this is a good choice for an ecosystem. That would mean that all authorization servers in the ecosystem would need to implement both https://example.com/some/path/.well-known/oauth-authorization-server and https://example.com/.well-known/oauth-authorization-server/some/path. Even if it is only an alias this could mean a considerable overhead for some implementations. -Daniel > > Odesláno z iPhonu > >> 8. 6. 2020 v 9:46, Daniel Fett : >> >>  >> >> Hi all, >> >> RFC8414 says that the URI where the OAuth metadata document is >> published is >> >> formed by inserting a well-known URI string into the authorization >> server's issuer identifier between the host component and the path >> component, if any. By default, the well-known URI string used is >> "/.well-known/oauth-authorization-server". >> >> I found that some OAuth servers and clients instead follow the >> convention used by OpenID Connect, where the suffix >> "/.well-known/openid-configuration" (or >> "/.well-known/oauth-authorization-server") is appended to the issuer URL. >> >> Is this a common deviation from the spec? >> >> Do you know how specific products handle this? >> >> Does it make sense to serve the metadata document from both locations? >> >> -Daniel >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de --------------9CD0E2190421D46AE07082EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Filip,

Thanks for your answers!

I'm not quite sure if the wording in my question was clear: My main concern is the difference between https://example.com/some/path/.well-known/oauth-authorization-server and https://example.com/.well-known/oauth-authorization-server/some/path, i.e., the usage of the well-known URI as a postfix or as an infix.

Am 08.06.20 um 09:54 schrieb Filip Skokan:
Some products publish both, but they don’t always return the same content, eventho as far as i can tell they should be aliases.
The uri normalization of 8414 is also implemented wrong in some cases, since it differs from OIDC as far as issuer path component is concerned.
This is where I'm not sure whether all products follow RFC8414 and properly use the well-known part as an infix.

I find it best for AS to have just one or both with the same content, client software doing discovery can check both locations.

That would be the safe implementation, but I was wondering if prescribing this is a good choice for an ecosystem. That would mean that all authorization servers in the ecosystem would need to implement both https://example.com/some/path/.well-known/oauth-authorization-server and https://example.com/.well-known/oauth-authorization-server/some/path. Even if it is only an alias this could mean a considerable overhead for some implementations.

-Daniel


Odesláno z iPhonu

8. 6. 2020 v 9:46, Daniel Fett <fett@danielfett.de>:



Hi all,

RFC8414 says that the URI where the OAuth metadata document is published is

formed by inserting a well-known URI string into the authorization
   server's issuer identifier between the host component and the path
   component, if any.  By default, the well-known URI string used is
   "/.well-known/oauth-authorization-server".

I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.

Is this a common deviation from the spec?

Do you know how specific products handle this?

Does it make sense to serve the metadata document from both locations?

-Daniel

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


-- 
https://danielfett.de
--------------9CD0E2190421D46AE07082EB-- From nobody Mon Jun 8 02:52:57 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065353A0837 for ; Mon, 8 Jun 2020 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPVXrswmrrBI for ; Mon, 8 Jun 2020 02:52:53 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326A93A082D for ; Mon, 8 Jun 2020 02:52:53 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id p18so12876691eds.7 for ; Mon, 08 Jun 2020 02:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gD0mxdjfjiWJJQQPr4ruxX0VOYOhrWYD+TAzdFMJWr8=; b=kzH2AvsG0MH5mhXlxK5Gdw12vtEwB1SwpU0q5/egq9Z7LAu0Sq3sjiHI6VNI7V/i57 8ZxXIZNwqeWepRBc9KFbJpMiyLmH4M221jFLACcCymr1liAwCf8lzQK3Rt4VAw7F/I1g nG7VMDRgTK3ixcbGeuAx3zeHTNBe13GDBqIEGtkHk7mNfSOTBT60k0/L51lDCA7urxgo k2FvrqHc+Padg0r2uvCTsk3PhGgMud5LfFEB7zvk8XLiQDKvVolhYWTCYhj+yN+jsuxB x4ps8edvvSj/kByTZL6XLqTrBaN33rah1NPXwuPdsm8c3Cie5ckvehzbBO9YHk3sErSO MgpQ== 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=gD0mxdjfjiWJJQQPr4ruxX0VOYOhrWYD+TAzdFMJWr8=; b=SjeGaCGoKQi2swOJAmPZCarOFV/vDPSTci4WWSi9A9n4wA2767EonJFVwVFxpp7Iea 70ELcUceapsM0bDkUzNrLQ0FkGNgbgSjwhFX2SMXMtRdbxMq4HCC7EyDvIo8F9bgTQ/6 tP2mh7R+bB/DS+9st7Ac9so8sc2bApT5H121Toi9ViQ5IXi42ACejCti5y31HsLwXc9J 8FOFVdtFT6XBLHQiLWcL+BvHJ7UflJIbqpKxB9bJv51s6m96k2PMPFYkPlkYr1xuqtSC OWzC+1j4tXf4+GqmrG6cH32pweOHFdEZ9Ir5e8jU2bIq6TajzrT0a3tmeVEFo1G1KuND LnyQ== X-Gm-Message-State: AOAM532xp4WvF1w+p/YbGCrQJ2+7IJ6+oy//s+jgfgVlWI4GVqC1zMVc 58T4fpLjbz9PcIby7oZv1g== X-Google-Smtp-Source: ABdhPJxB2qh4hXqU1LmDxjxgYYEI2zYy0pPIn5WWQKagVnnPnd5FresSYhgl45i2z11BTioPXKLS9Q== X-Received: by 2002:aa7:de08:: with SMTP id h8mr20609043edv.164.1591609970231; Mon, 08 Jun 2020 02:52:50 -0700 (PDT) Received: from [100.66.206.216] (ip-37-188-244-216.eurotel.cz. [37.188.244.216]) by smtp.gmail.com with ESMTPSA id t12sm10409693eje.21.2020.06.08.02.52.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 02:52:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5926357B-A10E-4754-83CE-CAB98EF5534B Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Mon, 8 Jun 2020 11:52:48 +0200 Message-Id: References: <67566E39-B76A-4CC4-8C41-9514126E72DD@gmail.com> Cc: oauth@ietf.org In-Reply-To: <67566E39-B76A-4CC4-8C41-9514126E72DD@gmail.com> To: Daniel Fett X-Mailer: iPhone Mail (17F75) Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jun 2020 09:52:55 -0000 --Apple-Mail-5926357B-A10E-4754-83CE-CAB98EF5534B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Preemptive send, sorry. That question was not clear from your text to me.=20= When it comes to client=E2=80=99s discovery, at least my software does the f= ollowing - when issuer is passed in it does oidc=E2=80=99s well known (openi= d-configuration) as a suffix and 8414=E2=80=99s well known (oauth-authorizat= ion-server) as an infix. According to both specs. Whichever returns first ge= ts used as they as far as i can tell should be aliases.=20 When discovery is performed with a URL that contains the keyword well-known,= it just fetches that resource directly.=20 This way the software is working as intended for conform ASs=E2=80=99 and de= velopers can still use the non conform ones by passing the well known locati= on directly. Odesl=C3=A1no z iPhonu > 8. 6. 2020 v 11:47, Filip Skokan : >=20 > =EF=BB=BFThat question was not clear from your text, you=20 >=20 > Odesl=C3=A1no z iPhonu >=20 >> 8. 6. 2020 v 11:15, Daniel Fett : >>=20 >> =EF=BB=BF >> Hi Filip, >>=20 >> Thanks for your answers! >>=20 >> I'm not quite sure if the wording in my question was clear: My main conce= rn is the difference between https://example.com/some/path/.well-known/oauth= -authorization-server and https://example.com/.well-known/oauth-authorizatio= n-server/some/path, i.e., the usage of the well-known URI as a postfix or as= an infix.=20 >>=20 >> Am 08.06.20 um 09:54 schrieb Filip Skokan: >>> Some products publish both, but they don=E2=80=99t always return the sam= e content, eventho as far as i can tell they should be aliases.=20 >>> The uri normalization of 8414 is also implemented wrong in some cases, s= ince it differs from OIDC as far as issuer path component is concerned. >> This is where I'm not sure whether all products follow RFC8414 and proper= ly use the well-known part as an infix. >>>=20 >>> I find it best for AS to have just one or both with the same content, cl= ient software doing discovery can check both locations.=20 >> That would be the safe implementation, but I was wondering if prescribing= this is a good choice for an ecosystem. That would mean that all authorizat= ion servers in the ecosystem would need to implement both https://example.co= m/some/path/.well-known/oauth-authorization-server and https://example.com/.= well-known/oauth-authorization-server/some/path. Even if it is only an alias= this could mean a considerable overhead for some implementations. >>=20 >> -Daniel >>=20 >>>=20 >>> Odesl=C3=A1no z iPhonu >>>=20 >>>> 8. 6. 2020 v 9:46, Daniel Fett : >>>>=20 >>>> =EF=BB=BF >>>> Hi all, >>>>=20 >>>> RFC8414 says that the URI where the OAuth metadata document is publishe= d is >>>>=20 >>>> formed by inserting a well-known URI string into the authorization >>>> server's issuer identifier between the host component and the path >>>> component, if any. By default, the well-known URI string used is >>>> "/.well-known/oauth-authorization-server". >>>>=20 >>>> I found that some OAuth servers and clients instead follow the conventi= on used by OpenID Connect, where the suffix "/.well-known/openid-configurati= on" (or "/.well-known/oauth-authorization-server") is appended to the issuer= URL. >>>>=20 >>>> Is this a common deviation from the spec?=20 >>>>=20 >>>> Do you know how specific products handle this?=20 >>>>=20 >>>> Does it make sense to serve the metadata document from both locations? >>>>=20 >>>> -Daniel >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> --=20 >> https://danielfett.de --Apple-Mail-5926357B-A10E-4754-83CE-CAB98EF5534B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Preemptive send, sorry. That question was n= ot clear from your text to me. 

When it comes to cli= ent=E2=80=99s discovery, at least my software does the following - when issu= er is passed in it does oidc=E2=80=99s well known (openid-configuration) as a= suffix and 8414=E2=80=99s well known (oauth-authorization-server) as an inf= ix. According to both specs. Whichever returns first gets used as they as fa= r as i can tell should be aliases. 

When disco= very is performed with a URL that contains the keyword well-known, it just f= etches that resource directly. 

This way the s= oftware is working as intended for conform ASs=E2=80=99 and developers can s= till use the non conform ones by passing the well known location directly.

Odesl=C3=A1no z iPhonu

8. 6. 2020 v 11:47, Filip Skokan <= panva.ip@gmail.com>:

=
=EF=BB=BFThat question was not clear from your text, you =

Odesl=C3=A1no z iPho= nu

8. 6. 2020 v 11:= 15, Daniel Fett <fett@danielfett.de>:

=EF=BB=BF =20 =20 =20
Hi Filip,

Thanks for your answers!

I'm not quite sure if the wording in my question was clear: My main concern is the difference between https://example.com/some/path/.well-known/oauth-authorization-ser= ver and ht= tps://example.com/.well-known/oauth-authorization-server/some/pat= h, i.e., the usage of the well-known URI as a postfix or as an infix.

Am 08.06.20 um 09:54 schrieb Filip Skokan:
Some products publish both, but they don=E2=80=99t always return the s= ame content, eventho as far as i can tell they should be aliases.
The uri normalization of 8414 is also implemented wrong in some cases, since it differs from OIDC as far as issuer path component is concerned.
This is where I'm not sure whether all products follow RFC8414 and properly use the well-known part as an infix.

I find it best for AS to have just one or both with the same content, client software doing discovery can check both locations.

That would be the safe implementation, but I was wondering if prescribing this is a good choice for an ecosystem. That would mean that all authorization servers in the ecosystem would need to implement both https://example.co= m/some/path/.well-known/oauth-authorization-server and https://example.com/.well-kno= wn/oauth-authorization-server/some/path. Even if it is only an alias this could mean a considerable overhead for some implementations.

-Daniel


Odesl=C3=A1no z iPhonu

8. 6. 2020 v 9:46, Daniel Fett <fett@danielfett.de>:

=EF=BB=BF

Hi all,

RFC8414 says that the URI where the OAuth metadata document is published is

formed by inserting a well-known URI string into the authorization
   server's issuer identifier between the host component and the path
   component, if any.  By default, the well-known URI string used is
   "/.well-known/oauth-authorization-server".

I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.

Is this a common deviation from the spec?

Do you know how specific products handle this?

Does it make sense to serve the metadata document from both locations?

-Daniel

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


--=20
https://da=
nielfett.de
=20
= --Apple-Mail-5926357B-A10E-4754-83CE-CAB98EF5534B-- From nobody Mon Jun 8 04:52:19 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5A3A09D3 for ; Mon, 8 Jun 2020 04:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XovM5yL90Ls1 for ; Mon, 8 Jun 2020 04:52:15 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E385D3A09CD for ; Mon, 8 Jun 2020 04:52:14 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id h5so17062650wrc.7 for ; Mon, 08 Jun 2020 04:52:14 -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=V4PyfVXkPy7abFJtvFhdsRRnkg8bvu2tL7QBlVQrfa8=; b=pBYGgoe6wvzy2V+jCRkrUUvj5Y9IoniNTxoP+LiPsk3FwNuYhDmzuC83dynYm++bN7 ZOegZ6slMLy6dXaxnzCBXNKerM0t1iE+yPipOxSJe5Lm0EZs7hzQxCKxb79BBtg8zwp1 Asod0YBCXCU+hD/g4eM3wO/LCcaxeOtQaqtIT/x69e4YOOL1N9YfKo8l59MxDX7Cn7Kq JY5leilWWaEM444dqAyRTmLNkwt384eLo5myi8EMtMUyjD/o/aMIw+B72f2lewDA9LYB sUBe1dp4uDXcYKCk9gGd3jsG9EwU34LtOvI7hcLOoyuX2q8AucrPuykEUd2BSI8UO6co Up+w== 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=V4PyfVXkPy7abFJtvFhdsRRnkg8bvu2tL7QBlVQrfa8=; b=XUUcsYh6dsqDwyg1Wmj5HHDi6i9RYg48HBOkMnLWZxNE+gDPyJ0i+TcXkr2Eom063d O6YIdseSiNPk/U39WMr0dN+zybpO2kykUoc+sqyApy/1axNGMudyYM3rQGW0QxWfM84w 5ND/juDqhyB2A6p8x9n+CshEhdCXfCLm88bTe189Mz/VWnvJkNKRkmGoJbaggbccM3Zi uMp9sRrG8wT3qHGIOvR5fpWlbg1tpPyW2B0vHAQpPzyPcW9fm+ZUWETzbjQT+tXZnlm3 5AtMQ+ifx3Ow/9slyOUyfRoZfsl/eIf5m4MOGd21RFL7nKycjeMn59WxGOB59uyi//Mw 98Hg== X-Gm-Message-State: AOAM532iT84MDidccZDf9+aS5BGC06dYN/6RBAuC49Llns4FH1MsKf0u nSk0Fom2794BY0sqUhxYtaAu4w== X-Google-Smtp-Source: ABdhPJzG5WZuINY7Gg6OX5LKng+lQ/syYw26LxlOMSK5OI143W84lvvVBqAKDfiTWXFfxDq2UNDA0g== X-Received: by 2002:a5d:4b47:: with SMTP id w7mr22150614wrs.234.1591617132089; Mon, 08 Jun 2020 04:52:12 -0700 (PDT) Received: from [192.168.1.112] (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id z9sm21647218wmi.41.2020.06.08.04.52.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 04:52:11 -0700 (PDT) From: Joseph Heenan Message-Id: <563AD7F9-D4A0-4F99-BAE2-B84F7439A733@authlete.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8A3017A5-CF88-4333-99FB-6B288AE5F338" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 8 Jun 2020 12:52:10 +0100 In-Reply-To: Cc: Francis Pouatcha , Openid-specs-fapi , OAuth WG To: "Manger, James" References: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 11:52:18 -0000 --Apple-Mail=_8A3017A5-CF88-4333-99FB-6B288AE5F338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, > On 5 Jun 2020, at 03:23, Manger, James = wrote: > If you merely want to trigger a different look-n-feel, define a = =E2=80=9Cbrand=E2=80=9D parameter to add the to the authorization = request. Unfortunately this doesn=E2=80=99t work when the authorization endpoint = is a claimed https url for a mobile app: the mobile app to be used is = selected purely based on the host/path segment. =10Joseph --Apple-Mail=_8A3017A5-CF88-4333-99FB-6B288AE5F338 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = James,


On 5 Jun 2020, at 03:23, = Manger, James <James.H.Manger@team.telstra.com> wrote:
If you merely want to = trigger a different look-n-feel, define a =E2=80=9Cbrand=E2=80=9D = parameter to add the to the authorization request.

Unfortunately this doesn=E2=80=99t work = when the authorization endpoint is a claimed https url for a mobile app: = the mobile app to be used is selected purely based on the host/path = segment.

=10Joseph

= --Apple-Mail=_8A3017A5-CF88-4333-99FB-6B288AE5F338-- From nobody Mon Jun 8 15:50:56 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880393A089B for ; Mon, 8 Jun 2020 15:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GCRiDBBDC2r for ; Mon, 8 Jun 2020 15:50: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 4EDD03A0889 for ; Mon, 8 Jun 2020 15:50:39 -0700 (PDT) Received: from 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 058MoVJ8030306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jun 2020 18:50:34 -0400 Date: Mon, 8 Jun 2020 15:50:31 -0700 From: Benjamin Kaduk To: Daniel Fett Cc: Filip Skokan , oauth@ietf.org Message-ID: <20200608225031.GB58497@mit.edu> References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> 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] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jun 2020 22:50:55 -0000 On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: > Hi Filip, > > Thanks for your answers! > > I'm not quite sure if the wording in my question was clear: My main > concern is the difference between > https://example.com/some/path*/.well-known/oauth-authorization-server* > and > https://example.com*/.well-known/oauth-authorization-server*/some/path, > i.e., the usage of the well-known URI as a postfix or as an infix. .well-known is only defined at the root of the path component of a URI. Usage such as https://example.com/some/path*/.well-known/oauth-authorization-server* is noncompliant with RFC 5785. -Ben From nobody Mon Jun 8 22:20:06 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF24F3A093C for ; Mon, 8 Jun 2020 22:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoIY_iihB_kL for ; Mon, 8 Jun 2020 22:20:02 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C4D3A0938 for ; Mon, 8 Jun 2020 22:20:02 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id r9so1531232wmh.2 for ; Mon, 08 Jun 2020 22:20:02 -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=nVKv2PKRA5D5jk/4m5P3dz73DwFlq8y8Na8cLmyM97A=; b=Grj9umYG/t8pqOlwFPdtRIZzmp5xyek+MIaSLKff2hfwBMou5wL8jmih6d1NM8c2kU JdBEv2OVeXh/rI0+X4rRHvtnwsBmhw0R0vQU68wUsf/65FD4AsmVYPiA5bLofxxmD7b8 /zcLxEA5xBGurM2mTAcjAlVRs0QlQbmq1fK5KWwRhKnJr//kjTuCt8g3EVFLnlCId/9a rSGkme5Leh15E00D934eYCGm2iTfFbwvlACxRSAVdi2qkcrV0nW1T4W1j/NAI+xJm38V ghFyXhtDCzi3oyUigW/foFnBvnQd6YCxErcJE5WrZmBS9hY1BzOST3pp9PFtuXAVMfq2 gi0g== 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=nVKv2PKRA5D5jk/4m5P3dz73DwFlq8y8Na8cLmyM97A=; b=C88cv2hrcWN3Md/Ax2GCMaNFaQcozSZzzBpQSsKFRgdm7qsI/8XDWOzfdZ6I3qjd0l Wx37RilVGgYL2d5dRQI6lEHim4jXgawXVOuoH0j0TOW6rU80SPqlX+GKdhg7hfkwzdF3 9u/NWTI7GyTrt6ldOvNjboeBQEF4ZL8UjhkxK5no5eMMqa318iY9b3LFNC06WBCrLWhc 1P4ps99lrsdbQG/YaHYW9mi4cBiZceu0K0d2bP5/l6aXXBhFpf07UxXiHLXJYa44CX+I zjvhykde7bAqIA4S1Lzkb8e45UXqSSCUPbeowdMNKsI58DKPAtnZrQfY2AqG1oCb9No+ oz2w== X-Gm-Message-State: AOAM532GoSFAoPChHxWl6yVtBAjjfZqBHvmCt+YYqaMhOlITSWJ7eFhj NUr9qE1ZkOhGPpiZ4vkqmHHZ2lw3vDvttCztukk= X-Google-Smtp-Source: ABdhPJxwIsESDTKohRhtY9mw/P78vGumn8FJeRDj+Wr8f4r6pSW6qeAhA2A/DmX7R5UdZvb268ih8O2d1Dh7P9gv2lM= X-Received: by 2002:a05:600c:4152:: with SMTP id h18mr2207696wmm.189.1591680000287; Mon, 08 Jun 2020 22:20:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Tue, 9 Jun 2020 14:19:49 +0900 Message-ID: To: Brock Allen Cc: oauth Content-Type: multipart/alternative; boundary="0000000000000367e305a79fe17f" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwsreq-21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 05:20:04 -0000 --0000000000000367e305a79fe17f Content-Type: text/plain; charset="UTF-8" Hi Brock, Starting from the easy one: 3) has been addressed. It does not break the existing OIDC implementation either as there is no requirements as to the mime-type checking there. Now, 2) will break all OIDC implementations. It is quite late to bring this in and I and my colleagues did not find security benefit that balances such breaking change. I could add 1) as an optional claim though. Best, Nat Sakimura On Thu, May 7, 2020 at 10:32 PM Brock Allen wrote: > Perhaps quite late, but a few comments/questions related to this: > > 1) When decoded, all the JWT samples are missing the "typ" claim from the > header, which I think should be "oauth.authz.req+jwt". > > 2) When validating the JAR if we are to validate the "typ" then this would > be incompatible with OIDC's request object, I think? > > 3) When the JAR is passed by reference, then the HTTP response > Content-Type of "application/oauth.authz.req+jwt" would also seem to break > or be incompatible with OIDC's request object passed by reference? > > There might need to be clarification when mixing this w/ an OIDC OP > implementation. > > TIA > > -Brock > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000000367e305a79fe17f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brock,=C2=A0

Starting from the easy = one: 3) has been addressed. It does not break the existing OIDC implementat= ion either as there is no requirements as to the mime-type checking there.= =C2=A0

Now, 2) will break all OIDC implementations= . It is quite late to bring this in and I and my colleagues=C2=A0did not fi= nd security benefit that balances such breaking change.=C2=A0
I could add 1) as an optional claim though.=C2=A0
Best,=C2=A0

Nat Sakimura
On Thu, = May 7, 2020 at 10:32 PM Brock Allen <brockallen@gmail.com> wrote:
Perhaps quite late, but a few comments/questions related= to this:

1) When decoded, all the JWT samples are missi= ng the "typ" claim from the header, which I think should be "= ;oauth.authz.req+jwt".

2) When validating the= JAR if we are to validate the "typ" then this would be incompati= ble with OIDC's request object, I think?

3) Wh= en the JAR is passed by reference, then the HTTP response Content-Type of= =C2=A0"application/oauth.authz.req+jwt" would also seem to break = or be incompatible with OIDC's request object passed by reference?

There might need to be clarification when mixing this = w/ an OIDC OP implementation.=C2=A0

TIA

-Brock

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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000000367e305a79fe17f-- From nobody Tue Jun 9 00:42:34 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7E3A0864 for ; Tue, 9 Jun 2020 00:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2X4g19mwi0x for ; Tue, 9 Jun 2020 00:42:31 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3503A0833 for ; Tue, 9 Jun 2020 00:42:31 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 1D09E7504; Tue, 9 Jun 2020 07:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591688548; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q5yMW3G/Mya83gQohhExcApSWM9RKwunjUJ038+T6yU=; b=Q8lDFq4DH/E+dc5ZjJxJ0VT7VYl2wgVK8AdfomP14pCYdASNVZp8J48Q342SOQh9+Ururm phxSJXviVAHfuapQFsAlcaViFxOarCluWsRnggIz11a7BEm9Xx1X5yQ0rQru21OM9+N/2F g3TU3ukWN+Rf1EJI7fztgfcShfGv/BQ= To: Benjamin Kaduk Cc: Filip Skokan , oauth@ietf.org References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> <20200608225031.GB58497@mit.edu> From: Daniel Fett Message-ID: <61e18e42-e878-9f2c-3a6c-5c0d993a1ac5@danielfett.de> Date: Tue, 9 Jun 2020 09:42:27 +0200 MIME-Version: 1.0 In-Reply-To: <20200608225031.GB58497@mit.edu> Content-Type: multipart/alternative; boundary="------------F8F9CCD2538C4BF6A2B8F80A" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591688548; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q5yMW3G/Mya83gQohhExcApSWM9RKwunjUJ038+T6yU=; b=f+CUZufQd/L4QksNvayf8bS2Ue0GEwJsXcGMS5lZlpccOzR/ZIDH2uaP37X2MR8bmMaQn+ Fz1o2gtk0bqtfQP3OMLVpfbiDPijYgvNA1J3VLzErwxFD+nn1XDr8wmhD7VkIq5b1mUpG8 adjYmWfav2CXKPNSGkQRAFWFLOcPiXg= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591688548; a=rsa-sha256; cv=none; b=KVh43Nwf9pO4wHTMmIV/Gt5hUvYMJH+1zzBRL2qDxVvlEBobuzOBVG1AZqEMrlBhvDhbQJ YG/WdBuKO/ohQHsR0ujhaMuSdHshkOmUCy6cEHc0Kd9CQOAJIMmTMMlzA406bOxdvLEqsS ok3RwpKyUctHokg7nvnSdDS4F3HuBHY= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2020 07:42:32 -0000 This is a multi-part message in MIME format. --------------F8F9CCD2538C4BF6A2B8F80A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 09.06.20 um 00:50 schrieb Benjamin Kaduk: > On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: >> Hi Filip, >> >> Thanks for your answers! >> >> I'm not quite sure if the wording in my question was clear: My main >> concern is the difference between >> https://example.com/some/path*/.well-known/oauth-authorization-server* >> and >> https://example.com*/.well-known/oauth-authorization-server*/some/path, >> i.e., the usage of the well-known URI as a postfix or as an infix. > .well-known is only defined at the root of the path component of a URI. > Usage such as > https://example.com/some/path*/.well-known/oauth-authorization-server* is > noncompliant with RFC 5785. I know, but my impression is that since OIDC did it this way, some clients are expecting the same behavior for RFC8414. Thus the question if AS should be allowed or even required to offer the postfix variant in an ecosystem. -Daniel -- https://danielfett.de --------------F8F9CCD2538C4BF6A2B8F80A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 09.06.20 um 00:50 schrieb Benjamin Kaduk:
On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote:

Hi Filip,

Thanks for your answers!

I'm not quite sure if the wording in my question was clear: My main
concern is the difference between
https://example.com/some/path*/.well-known/oauth-authorization-server*
and
https://example.com*/.well-known/oauth-authorization-server*/some/path,
i.e., the usage of the well-known URI as a postfix or as an infix.

.well-known is only defined at the root of the path component of a URI.
Usage such as
https://example.com/some/path*/.well-known/oauth-authorization-server* is
noncompliant with RFC 5785.

I know, but my impression is that since OIDC did it this way, some clients are expecting the same behavior for RFC8414. Thus the question if AS should be allowed or even required to offer the postfix variant in an ecosystem.

-Daniel


-- 
https://danielfett.de
--------------F8F9CCD2538C4BF6A2B8F80A-- From nobody Tue Jun 9 03:08:06 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8780D3A0D0A for ; Tue, 9 Jun 2020 03:08:04 -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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeGvpZXGq2eS for ; Tue, 9 Jun 2020 03:08:02 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2B03A0CFE for ; Tue, 9 Jun 2020 03:08:02 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id ibAmjDe7ALvc2ibAnjwmyn; Tue, 09 Jun 2020 03:08:02 -0700 X-CMAE-Analysis: v=2.3 cv=RO/N4Lq+ c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=A1X0JdhQAAAA:8 a=N8jRir--Xbr3ef71DcMA:9 a=QEXdDO2ut3YA:10 a=EE5gYq7_bG6CvcGDQigA:9 a=K5wMINwhczAcj2Mf:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=Df3jFdWbhGDLdZNm0fyq:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <5453af6c-a55a-8a56-f5f6-c1778e31aece@connect2id.com> Date: Tue, 9 Jun 2020 13:08:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070106010003090301090809" X-CMAE-Envelope: MS4wfKWoR6q9C8JQZ63gZQSbMZRJzcTvAstNSmwsPLLqiYQSHhzHhp5vvWJXbJXPmZZ9G3kJJh4Hmw3XPJ19Krd20H9xqeffWSx5uW3K5LqlUutWljH84iKm pfF/Ss4xbV/WYECnD8SV7gCqVp/38BgT7PTY2ekSISwefvhUREdCQVBz Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2020 10:08:05 -0000 This is a cryptographically signed message in MIME format. --------------ms070106010003090301090809 Content-Type: multipart/alternative; boundary="------------9E74FDC81C131097D7B6DB92" Content-Language: en-US This is a multi-part message in MIME format. --------------9E74FDC81C131097D7B6DB92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/06/2020 12:15, Daniel Fett wrote: > That would be the safe implementation, but I was wondering if > prescribing this is a good choice for an ecosystem. Postfix vs infix: If we reason about the common ways ASes (as web apps) get deployed, then (perhaps) it will become obvious which method is the most natural and likely to be taken. * For an AS which gets deployed in a dedicated host, e.g. as as.example.com , the app root is likely to be https://as.example.com/ and hence the config URL becoming a simple postfix. * Multi-tenant ASes where each AS has a dedicated domain for each issuer also. * For an AS which gets deployed as part of some larger app (e.g. as module or package) on the same host, the AS is likely to end up at some path like https://example.com/as/ and hence the config being easier for a postfix URL. * Multi-tenant ASes which share a domain - this is not clear, but I suppose both postfix and infix can be made to work without the one method demanding more effort. The infix is not natural, IMO, given the way apps get deployed. Postfix seems more natural. I may be wrong about these assumptions. But that's one good way to approach the problem and specify something which implementers actually find easier / natural. This, to me, is what an "ideal" technical standard is. Vladimir --------------9E74FDC81C131097D7B6DB92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 08/06/2020 12:15, Daniel Fett wrote= :
Tha= t would be the safe implementation, but I was wondering if prescribing this is a good choice for an ecosystem.

Postfix vs infix:

If we reason about the common ways ASes (as web apps) get deployed, then (perhaps) it will become obvious which method is the most natural and likely to be taken.

  • For an AS which gets deployed in a dedicated host, e.g. as as.example.com , the app root is likely to be https://as.example.com/ and hence the config URL becoming a simple postfix.

  • Multi-tenant ASes where each AS has a dedicated domain for each issuer also.

  • For an AS which gets deployed as part of some larger app (e.g. as module or package) on the same host, the AS is likely to end up at some path like https://example.com/as/ and hence the config being easier for a postfix URL.

  • Multi-tenant ASes which share a domain - this is not clear, but I suppose both postfix and infix can be made to work without the one method demanding more effort.


The infix is not natural, IMO, given the way apps get deployed. Postfix seems more natural.

I may be wrong about these assumptions. But that's one good way to approach the problem and specify something which implementers actually find easier / natural. This, to me, is what an "ideal" technical standard is.

Vladimir


--------------9E74FDC81C131097D7B6DB92-- --------------ms070106010003090301090809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDkxMDA4MDBaMC8G CSqGSIb3DQEJBDEiBCDXgR3wLy+UkxCz9TN6Y/2AbT07LCCcy3yq+aabvHqVLjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBADvERVNGYGcy1s9XrF1XIga80iK5Ojo+EkNr/iL16CYvauwW eHUk6hNjrPHwOjiEnPWAL05ggjWT0r0y9UIbMTxCIFgjQTbAV/QJ7rA4spKr5UtTWnVmPEDA Tr++TYJGxOe6o232UhwOILUtws6BORC9ATt2HmC/mWk5cFY/06ZawoN8CbPYIAnTgesaQCC5 fzpxEdIKve1MV0yzZMH3z93tOZriKwwK7w2Lfa8pQGoei75xSkEZrSEYhgipQ1Z8lOCnAw+5 cw5M3YX4mDg35AfrbBAr3TByY4LIfa56TuDR640WJ8G9KLz8NNvHpIxbRUiGPDoIn2TU2ffU QCPugeoAAAAAAAA= --------------ms070106010003090301090809-- From nobody Tue Jun 9 14:34:33 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045333A0916 for ; Tue, 9 Jun 2020 14:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94UcNxFcY4lx for ; Tue, 9 Jun 2020 14:34:28 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1987C3A097A for ; Tue, 9 Jun 2020 14:34:20 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id c17so26946647lji.11 for ; Tue, 09 Jun 2020 14:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zrtyFuKvAQMrkRfjWOC98x7CTaGpiadG9+Onpt3BmTk=; b=SlHaf50Kv9Jms0QCAbFbQgdTWwZNYbPgKwFuG3ytYZrSVNcAPqRkzZRW3pcDMDRrLW o4qmWbqqGlBDgkamBMPgFhLZvxnnJKtM4EcIEf4E8ckI6Z6ZWh9bdHhtgUdhLMj3Hgwy IHFeqHUvN1LfcYGjkUkbl81V6QGm77WAtZS4IZU8NT4kq6cu9k6dhiZBVwyAqU2xVQc9 ocDiqhAqDHcGWFiImgZuLejs1dfHAffBXXCumtHWgz0Z5pxFqva12nwUVmGWmovLbgqD 1ThtwdVVzWnoEUUbDvl7Ci6JBkFquqMYDn/c17nQSqk3Rixa/DNfwyZNrbgOyDF6ZLAV 9/3w== 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=zrtyFuKvAQMrkRfjWOC98x7CTaGpiadG9+Onpt3BmTk=; b=OkKJiuHn7ecQwOPwza3ut9LDRQcJrLMUHCW/Rh+0kGxR00htJY7L1J2VnT8vQWGJw1 3VRs2FCiX6pjy8UyzUVFILlWyBbgwr10qvPzN4GKw+WWyn0I8e3d3uc+e6pXzusztPIu aHzJZqW9B1N2BWS5nV0eoDbk9jcWPthvzGzegT4obo5ToSAxxD4DGiNvonKtdnbJrzMh Ibxy/CKwQ5YVApGgtd/BrfneQFeEFL5BoqyozPBodobQt2HW0+IGYBNZpLoSWLmCgolc AJDscVPPL/1dWn8OJZApxpZl5xRpgBBNBggh2ArfUrr5+L345139U3K9GvzmLBrC5Sek oN7Q== X-Gm-Message-State: AOAM53132y8R9JpzWYuVw04d+nTMZ1tYR2+WL/Ge5MXXn+/keg3xboav 4jr2YmvnAt2fZPoOpzAUsvBRSxwjaxZ8MEtdxLRdUZstunSmg9wA6WxA+FFkHgihD44CY2fYyPa iIBG01c5Tbdy5xQ== X-Google-Smtp-Source: ABdhPJxq25L2W52sccUNe0QbjuVVDjwxTkv0snjC17k/Xo/K/lm079oq2ZefouXU4LfSHsjm/HjOi9cfVsuuao3rXrg= X-Received: by 2002:a2e:b4b9:: with SMTP id q25mr121867ljm.313.1591738456469; Tue, 09 Jun 2020 14:34:16 -0700 (PDT) MIME-Version: 1.0 References: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> In-Reply-To: <3e87e004-81a9-4581-9d21-93370e771977@aol.com> From: Brian Campbell Date: Tue, 9 Jun 2020 15:33:49 -0600 Message-ID: To: George Fletcher Cc: Brian Campbell , Filip Skokan , oauth Content-Type: multipart/alternative; boundary="00000000000046774f05a7ad7d1d" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 21:34:31 -0000 --00000000000046774f05a7ad7d1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't follow the reasoning about all resource servers needing to be updated to support the new scheme before deployment could start. Given how 6750, JWT and Introspection define things (basically as extensible with unrecognized stuff to be ignored) , I would expect that a existing regular RFC 6750 protected resource with no knowledge of DPoP would almost certainly accept a dpop/jkt bound access token as though it was a bearer token. The definition of the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP header but also say that, if that was met with a 401 WWW-Authenticate: Bearer challenge (or the client had prior such knowledge about the RS), that the access token could be sent using the Bearer authorization scheme. And would work as such. There may well be some existing protected resources that wouldn't accept a dpop/jkt bound access token but I'd say they'd be operating erroneously and I would think it'd be a pretty small minority - DPoP not defining a new token_type wouldn't change that situation at all anyway. In fact, from the perspective of interoperability on roll out, I don't see how DPoP defining a new token_type or not changes anything. Things look a little more intentional with a new token type and auth scheme and there might be an additional 401 challenge at first with a Bearer only RS but I don't see how the actual inerop is any different. The suggestion/proposal during the interim to signal to the client that the RT had been bound was indeed to introduce a new token endpoint response parameter[1]. Although I had an intentionally ridiculous name there to serve as a placeholder and hopefully avoid bikeshedding the name. I will say that doing something general (like an rt_token_type) in a specific extension like DPoP can be pretty problematic so I think it should need to be something DPoP specific even if that's a little ugly. [1] slide #23 https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides= -interim-2020-oauth-09-sessa-dpop.pdf On Fri, Jun 5, 2020 at 2:17 PM George Fletcher wrote: > The issue I see with sticking with the DPoP token_type is that from a > roll_out perspective, ALL resource > servers must be updated to support the new scheme and only then can the > DPoP deployment start. > For any wide ecosystem deployment that can be problematic. I don't have any > great suggestions:( > > Secondly, I do think we need a way to allow for the refresh_token to be > bound while leaving the > access_tokens as bearer tokens. This adds useful security without impacting > existing RS deployments. > It was unclear from our interim meeting discussion how the client knows > whether the refresh token has > been bound to the public key or not. The AS can signal that the > access_token is NOT bound by > returning a token_type of "bearer" but we should think about adding > addition response fields for > the refresh token binding (e.g. "rt_token_type). > > Thanks, > George > > On 5/29/20 5:50 PM, Brian Campbell wrote: > > Apologies for the slow reply on this. No excuses other than life > > sometimes happens. > > `token_type` is maybe not the clearest extension > point (and one I've > arguably misused in OAuth MTLS > > > and the now defunct > Token > Binding > > and > > admitted to being on the fence about in the issue you linked to > > > ). But it is the > > extension point that was basically left in RFC 6749 to facilitate > this > exact kind of thing (for MAC really but it's conceptually > similar in th= at > it was an application level proof mechanism of sorts) > . The text from R= FC > 6749 sec 7.1 > > is also copied > > below. Note that a "client MUST NOT use an access token if it does > not > understand the token type" so FWIW the client behaviours you > describe > aren't in line with that. > > It still seems to be that using DPoP > token_type is the appropriate > thing to do and that it can be defined to > account and allow for mixed > token type situations. It would define that > the DPoP authz scheme be > used as the authentication method to include t= he > access token when > making a protected resource request. That definition > can also include > falling back to using the Bearer authz scheme when/if = so > challenged > by a protected resource. > > > > > > 7.1 > > . Access Token > Types > > > The access token type provides the client with the information > > required to successfully utilize the access token to make a > protected > resource request (along with type-specific attributes). > The client MUST > NOT use an access token if it does not understand the > token type. > > F= or > example, the "bearer" token type defined in [RFC6750 > > > ] is utilized by simply > including > the access token string in the request: > > GET /resource/1 HTTP/1.1 Host= : > example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the "mac" > token type defined in [OAuth-HTTP-MAC > > > ] is > utilized > by issuing a Message Authentication Code (MAC) key together > with the > access token that is used to sign certain components of the > HTTP > requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: > MAC > id=3D"h480djs93hd8", nonce=3D"274312:dj83hs9s", > > mac=3D"kDZvddkndxvhGRXZhvuDjEWhGeE=3D" > > The above examples are provide= d for > illustration purposes only. > Developers are advised to consult the > [RFC6750 > > ] and [OAuth-HTTP-MAC > > > ] > > specifications before use. > > Each access token type definition specifie= s > the additional > attributes (if any) sent to the client together with the= > > "access_token" response parameter. It also defines the HTTP > > authentication method used to include the access token when making a > > protected resource request. > > > > On Tue, May 19, 2020 at 7:20 AM Filip > Skokan > wrote: > >> This is a > RE: to yesterday's interim meeting discussion, largely >> related to the > first rollout step where we want to constrain >> refresh tokens but leave > protected resource access intact. >> >> I'll start off with a case that I > hope we can agree is absolutely >> necessary for DPoP to solve - that is > constraining refresh tokens >> for browser based applications. Now, *do w= e > see this as a >> secondary objective? I think it should be on par with > access token >> constraining.* SPAs using code flow and having access to > refresh >> tokens as means against the continuous browser efforts to cut > down >> on storage access is a real case servers will be eventually force= d > >> to adopt. >> >> Since rollout for DPoP needs to begin with the AS and > Client >> supporting it (regardless what order i guess) there are going t= o > be >> instances where the RS will be supporting both Bearer and DPoP at >= > > the same time. >> >> As discussed yesterday, the client shouldn't know/ca= re > and change >> its behaviour when it comes to using access tokens. >> >> > *But what is the client behaviour we take for standard?* Because I >> can > see two conflicting implementations in the wild >> >> 1. The client echoe= s > the token_type it received from the token >> endpoint as the authorizatio= n > scheme - (optionally) throws on >> unrecognized token type values 2. The > client uses Bearer as a fixed >> authorization scheme and ignores the > token_type it received >> >> #2 is an implementation which I suspect has = no > idea about DPoP, but >> if extended to send DPoP headers (through various > mechanism - >> library extensions or even manipulating the `XMLHttpReques= t` > >> prototype) will >> >> - =F0=9F=8E=89 get the benefit of having its Ref= resh Tokens > bound - =F0=9F=8E=89 most >> likely continue to work with RSs that only s= upport > Bearer - =E2=9D=8C will >> cease to work with RSs that will adopt support= for DPoP > because >> it'll be using the wrong scheme, that is unless (=F0=9F=8E=89)= RSs >> > supporting DPoP choose to suspend the requirement to use the new >> schem= e > and instead depend on the presence of `cnf.jkt` as means to >> trigger DP= oP > validation. *Q: is that an acceptable thing to do?* >> >> Arguably, clien= t > behaviour #1 is what a client should be using if >> it supports other > schemes besides Bearer. But it may as well be the >> behaviour of a clien= t > that has no clue about DPoP, right? Again, >> such client can be made to > support DPoP in a SPA through >> manipulation of the XMLHttpRequest > prototype, in which case the >> developer needs to do the same for the > protected resource calls. >> But at this point the developer has to know > which RS to apply DPoP >> to and which not - ergo - which to send Bearer > vs. DPoP scheme to? >> The developer will have to write a whitelist of > resource servers >> anyway - and there we get to the point where client h= as > >> information and functionality that it shouldn't /need to/ have. >> >> > Its great that we have token_type, authorization header schemes, >> etc..= ., > but we don't seem have a well defined (or at least >> followed) behaviour > for our clients around handling the token_type >> response values and the= ir > usage. >> >> A developer has to resolve to navigate this monkey course > unless >> the RS definition on the AS is aware of the fact that the RS do= es > >> support DPoP, so that the issued token_type is always correct for >> t= he > RS. So, *should we make that a recommended way of 'indicating' >> when to > issue Bearer vs DPoP access tokens?* >> >> What else could we do that > doesn't give more decision making to >> the clients so that the very firs= t > step - *Refresh Tokens get >> constrained* - is achieved* but Protected > Resource access is >> unaffected?* >> >> Note that this was not "a thing" > for mTLS because it continues to >> use the Bearer scheme (for better or > worse) and it completely omits >> possible continuous rollout or discussi= ng > what are the signals the >> RS must use to require mTLS to be used), same > for the abandoned >> OAuth 2.0 Token Binding draft (also continued to use > the Bearer >> scheme). >> >> I suspect we have just this opportunity to f= ix > token types and >> their use and if we can't, we'll have to resolve to > abandon that >> extension point as one that doesn't support continued > rollout of >> real sender constraining mechanism (e.g. http signatures in > the >> future) and just continue using Bearer because in the end, given >= > > that RSs could be relying on the presence of the cnf claim to >> figure o= ut > the token's constraining mechanism, would that be such a >> bad thing? >> > >> Put it the other way around. By introducing Bearer scheme, do we >> > actually gain anything of value that can't be gained through other >> > means? >> >> Note that this message didn't start with the goal of > questioning >> the new scheme use, it just sort of landed there... My > pedantic >> nature would love to see the new scheme and token_type > extension >> point used as it was meant to be but I also recognize the ma= ny > >> issues it brings that could be sidestepped by not introducing it in >> > the first place, all without losing capabilities. >> >> Previous material > on the topic >> >> - https://github.com/danielfett/draft-dpop/issues/41, > decision to >> break backwards compatibility amongst the authors - ML >> > > > >> thread, in my opinion inconclusive, no consensus >> >> >> S pozdravem, > *Filip Skokan* >> _______________________________________________ OAuth > mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oaut= h > >> > > > _______________________________________________ OAuth mailing li= st > > 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._ --00000000000046774f05a7ad7d1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't follow the reasoning about all resource s= ervers needing to be updated to support the new scheme before deployment co= uld start.=C2=A0 Given how 6750, JWT and Introspection define things (basic= ally as extensible with unrecognized stuff to be ignored) , I would expect = that a existing regular RFC 6750 protected resource with no knowledge of DP= oP would almost certainly accept a dpop/jkt bound access token as though it= was a bearer token. The definition of the DPoP token_type would prescribe = sending the access token with the DPoP authorization scheme in conjunction = with the DPoP header but also say that, if that was met with a 401 WWW-Auth= enticate: Bearer challenge (or the client had prior such knowledge about th= e RS), that the access token could be sent using the Bearer authorization s= cheme. And would work as such. There may well be some existing protected re= sources that wouldn't accept a dpop/jkt bound access token but I'd = say they'd be operating erroneously and I would think it'd be a pre= tty small minority - DPoP not defining a new token_type wouldn't change= that situation at all anyway. In fact, from the perspective of interoperab= ility on roll out, I don't see how DPoP defining a new token_type or no= t changes anything. Things look a little more intentional with a new token = type and auth scheme and there might be an additional 401 challenge at firs= t with a Bearer only RS but I don't see how the actual inerop is any di= fferent.=C2=A0

The suggestion/proposal during= the interim to signal to the client that the RT had been bound was indeed = to introduce a new token endpoint response parameter[1]. Although I had an = intentionally ridiculous name there to serve as a placeholder and hopefully= avoid bikeshedding the name. I will say that doing something general (like= an rt_token_type) in a specific extension like DPoP can be pretty problema= tic so I think it should=C2=A0 need to be something DPoP specific even if t= hat's a little ugly.



On Fri, Jun 5, 2020 at 2:17 PM G= eorge Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
The issue I see with sticking with the DPoP token_type is that from a roll_out perspective, ALL resource
servers must be updated to support the new scheme and only then can the DPoP deployment start.
For any wide ecosystem deployment that can be problematic. I don't have any great suggestions:(

Secondly, I do think we need a way to allow for the refresh_token to be bound while leaving the
access_tokens as bearer tokens. This adds useful security without impacting existing RS deployments.
It was unclear from our interim meeting discussion how the client knows whether the refresh token has
been bound to the public key or not. The AS can signal that the access_token is NOT bound by
returning a token_type of "bearer" but we should think about adding addit= ion response fields for
the refresh token binding (e.g. "rt_token_= type).

Thanks,
George

On 5/29/20 5:50 PM, Brian Campbell wrote:
> Apol= ogies for the slow reply on this. No excuses other than life > sometimes happens. >=20 > `token_type` is maybe not the clearest extension point (and one I'= ve=20 > arguably misused in OAuth MTLS > <https://www.rfc-editor.org/rfc/rfc8705.html> and the now def= unct > Token Binding=20 > <https://tools.ietf.org/html/draft-ietf-oauth-toke= n-binding-08>and > admitted to being on the fence about in the issue you linked to=20 > <https://github.com/danielfett/draft-dpop/issues/41>)= . But it is the=20 > extension point that was basically left in RFC 6749 to facilitate > this exact kind of thing (for MAC really but it's conceptually > similar in that it was an application level proof mechanism of sorts) > . The text from RFC 6749 sec 7.1 > <https://tools.ietf.org/html/rfc6749?#section-7.1> is al= so copied > below. Note that a "client MUST NOT use an access token if it doe= s=20 > not understand the token type" so FWIW the client behaviours you > describe aren't in line with that. >=20 > It still seems to be that using DPoP token_type is the appropriate > thing to do and that it can be defined to account and allow for mixed > token type situations. It would define that the DPoP authz scheme be > used as the authentication method to include the access token when > making a protected resource request. That definition can also include > falling back to using the Bearer authz scheme when/if so challenged > by a protected resource. >=20 > <https://tools.ietf.org/html/rfc6749?#section-7.1> >=20 > 7.1 <https://tools.ietf.org/html/rfc6749?#section-7.1>. = Access Token > Types >=20 > The access token type provides the client with the information=20 > required to successfully utilize the access token to make a > protected resource request (along with type-specific attributes). > The client MUST NOT use an access token if it does not understand the > token type. >=20 > For example, the "bearer" token type defined in [RFC6750=20 > <= https://tools.ietf.org/html/rfc6750>] is utilized by simply > including the access token string in the request: >=20 > GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer > mF_9.B5f-4.1JqM >=20 > while the "mac" token type defined in [OAuth-HTTP-MAC=20 > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC= >] is > utilized by issuing a Message Authentication Code (MAC) key together > with the access token that is used to sign certain components of the > HTTP requests: >=20 > GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC > id=3D"h480djs93hd8", nonce=3D"274312:dj83hs9s",=20 > mac=3D"kDZvddkndxvhGRXZhvuDjEWhGeE=3D" >=20 > The above examples are provided for illustration purposes only.=20 > Developers are advised to consult the [RFC6750=20 > <= https://tools.ietf.org/html/rfc6750>] and [OAuth-HTTP-MAC=20 > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC= >]=20 > specifications before use. >=20 > Each access token type definition specifies the additional > attributes (if any) sent to the client together with the > "access_token" response parameter. It also defines the HTTP > authentication method used to include the access token when making a > protected resource request. >=20 >=20 >=20 > On Tue, May 19, 2020 at 7:20 AM Filip Skokan <panva.ip@gmail.com> > wrote: >=20 >> This is a RE: to yesterday's interim meeting discussion, large= ly >> related to the first rollout step where we want to constrain >> refresh tokens but leave protected resource access intact. >>=20 >> I'll start off with a case that I hope we can agree is absolut= ely=20 >> necessary for DPoP to solve - that is constraining refresh tokens >> for browser based applications. Now, *do we see this as a >> secondary objective? I think it should be on par with access token >> constraining.* SPAs using code flow and having access to refresh >> tokens as means against the continuous browser efforts to cut down >> on storage access is a real case servers will be eventually forced >> to adopt. >>=20 >> Since rollout for DPoP needs to begin with the AS and Client >> supporting it (regardless what order i guess) there are going to b= e >> instances where the RS will be supporting both Bearer and DPoP at >> the same time. >>=20 >> As discussed yesterday, the client shouldn't know/care and cha= nge >> its behaviour when it comes to using access tokens. >>=20 >> *But what is the client behaviour we take for standard?* Because I >> can see two conflicting implementations in the wild >>=20 >> 1. The client echoes the token_type it received from the token=20 >> endpoint as the authorization scheme - (optionally) throws on >> unrecognized token type values 2. The client uses Bearer as a fixe= d >> authorization scheme and ignores the token_type it received >>=20 >> #2 is an implementation which I suspect has no idea about DPoP, bu= t >> if extended to send DPoP headers (through various mechanism - >> library extensions or even manipulating the `XMLHttpRequest` >> prototype) will >>=20 >> - =F0=9F=8E=89 get the benefit of having its Refresh Tokens bound = - =F0=9F=8E=89 most >> likely continue to work with RSs that only support Bearer - =E2=9D= =8C will >> cease to work with RSs that will adopt support for DPoP because >> it'll be using the wrong scheme, that is unless (=F0=9F=8E=89)= RSs >> supporting DPoP choose to suspend the requirement to use the new >> scheme and instead depend on the presence of `cnf.jkt` as means to >> trigger DPoP validation. *Q: is that an acceptable thing to do?* >>=20 >> Arguably, client behaviour #1 is what a client should be using if >> it supports other schemes besides Bearer. But it may as well be th= e >> behaviour of a client that has no clue about DPoP, right? Again, >> such client can be made to support DPoP in a SPA through >> manipulation of the XMLHttpRequest prototype, in which case the >> developer needs to do the same for the protected resource calls. >> But at this point the developer has to know which RS to apply DPoP >> to and which not - ergo - which to send Bearer vs. DPoP scheme to? >> The developer will have to write a whitelist of resource servers >> anyway - and there we get to the point where client has >> information and functionality that it shouldn't /need to/ have= . >>=20 >> Its great that we have token_type, authorization header schemes, >> etc..., but we don't seem have a well defined (or at least >> followed) behaviour for our clients around handling the token_type >> response values and their usage. >>=20 >> A developer has to resolve to navigate this monkey course unless >> the RS definition on the AS is aware of the fact that the RS does >> support DPoP, so that the issued token_type is always correct for >> the RS. So, *should we make that a recommended way of 'indicat= ing' >> when to issue Bearer vs DPoP access tokens?* >>=20 >> What else could we do that doesn't give more decision making t= o >> the clients so that the very first step - *Refresh Tokens get >> constrained* - is achieved* but Protected Resource access is >> unaffected?* >>=20 >> Note that this was not "a thing" for mTLS because it con= tinues to >> use the Bearer scheme (for better or worse) and it completely omit= s >> possible continuous rollout or discussing what are the signals the >> RS must use to require mTLS to be used), same for the abandoned >> OAuth 2.0 Token Binding draft (also continued to use the Bearer >> scheme). >>=20 >> I suspect we have just this opportunity to fix token types and >> their use and if we can't, we'll have to resolve to abando= n that >> extension point as one that doesn't support continued rollout = of >> real sender constraining mechanism (e.g. http signatures in the >> future) and just continue using Bearer because in the end, given >> that RSs could be relying on the presence of the cnf claim to >> figure out the token's constraining mechanism, would that be s= uch a >> bad thing? >>=20 >> Put it the other way around. By introducing Bearer scheme, do we >> actually gain anything of value that can't be gained through o= ther >> means? >>=20 >> Note that this message didn't start with the goal of questioni= ng >> the new scheme use, it just sort of landed there... My pedantic >> nature would love to see the new scheme and token_type extension >> point used as it was meant to be but I also recognize the many >> issues it brings that could be sidestepped by not introducing it i= n >> the first place, all without losing capabilities. >>=20 >> Previous material on the topic >>=20 >> - https://github.com/danielfett/draft-dpop/issues/41, de= cision to=20 >> break backwards compatibility amongst the authors - ML=20 >> <https://mailarchiv= e.ietf.org/arch/browse/oauth/?q=3D%22DPoP%20-%20new%20authorization%20schem= e%20%2F%20immediate%20usability%20concerns%22&gbt=3D1&index=3D><= /a> >> thread, in my opinion inconclusive, no consensus >>=20 >>=20 >> S pozdravem, *Filip Skokan*=20 >> _______________________________________________ OAuth mailing list= =20 >> OAuth@ietf.org= https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 > _______________________________________________ OAuth mailing list=20 > 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. --00000000000046774f05a7ad7d1d-- From nobody Wed Jun 10 13:32:55 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660003A11F7; Wed, 10 Jun 2020 13:32:53 -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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spHIoo9Ciyim; Wed, 10 Jun 2020 13:32:51 -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 721033A11F6; Wed, 10 Jun 2020 13:32:51 -0700 (PDT) Received: from [192.168.1.14] (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 05AKWnFX006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 16:32:49 -0400 From: Justin Richer Message-Id: <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA832DF-6D90-4489-A32A-2ED9EA01CA80" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 10 Jun 2020 16:32:48 -0400 In-Reply-To: Cc: Francis Pouatcha , oauth To: Torsten Lodderstedt References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 20:32:53 -0000 --Apple-Mail=_2BA832DF-6D90-4489-A32A-2ED9EA01CA80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What if we simply declare that refresh tokens are always bound to the = DPoP key used to request them? Is there value in NOT binding the refresh = token? As for access tokens, the way I read it, all of this is true: - The AS could still decide to issue a Bearer token, using the = token_type field, for whatever policy reason. - A client getting back a Bearer token from a DPoP request would do = Bearer headers.=20 - A client getting a DPoP token from a DPoP request would do DPoP = headers. - An client should never send a DPoP token as a Bearer header. - An RS should ALWAYS look for a DPoP binding signature from a DPoP = scheme token. Missing that is an error. So if we just declare that a refresh token must always be DPoP bound = when DPoP is used to request it and a refresh token is issued, then = we=E2=80=99re in the clear here, as best as I can tell, and it allows = the AS some flexibility. Some problems with this: 1) Pretty much every single OAuth client in the world ignores the = =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support = DPoP wouldn=E2=80=99t ignore it, so that=E2=80=99s probably ok. 2) If we wanted to make refresh token binding switchable we=E2=80=99d = need a =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the = client would need to know how to understand it and deal with its absence = (since most servers won=E2=80=99t send it). 3) This presumes the client will not rotate its key before using the = refresh token. If it does it=E2=80=99ll have to do a whole new grant. 4) None of this prevents an RS from ignoring the DPoP signature, but I = think that=E2=80=99s a separate problem. 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be able to = bind a NEW DPoP key during a refresh, using the old key as proof for the = refresh token and the new key going forward. Is this a case we want to = enable? =E2=80=94 Justin > On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt = wrote: >=20 > That=E2=80=99s correct for confidential clients. >=20 > For a public client, the refresh token is just bound to the client id. = DPoP allows binding to an ephemeral key pair for this kind of clients. >=20 >> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha = : >>=20 >> =EF=BB=BF >>=20 >> > Am 05.06.2020 um 22:17 schrieb George Fletcher = >: >> >=20 >> > Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments. >>=20 >> +1 that=E2=80=99s a very useful = feature_______________________________________________ >> AFAIK a refresh_token is always bound. What am I missing here? >> --=20 >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ = __________________________________= _____________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2BA832DF-6D90-4489-A32A-2ED9EA01CA80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What = if we simply declare that refresh tokens are always bound = to the DPoP key used to request them? Is there value in NOT binding = the refresh token?

As = for access tokens, the way I read it, all of this is true:

- The AS could still = decide to issue a Bearer token, using the token_type field, for whatever = policy reason.
- A client getting back a Bearer = token from a DPoP request would do Bearer headers. 
- A client getting a DPoP token from a DPoP request would do = DPoP headers.
- An client should never send a DPoP = token as a Bearer header.
- An RS should ALWAYS = look for a DPoP binding signature from a DPoP scheme token. Missing that = is an error.

So = if we just declare that a refresh token must always be DPoP bound when = DPoP is used to request it and a refresh token is issued, then we=E2=80=99= re in the clear here, as best as I can tell, and it allows the AS some = flexibility.

Some problems with this:

1) Pretty much every single OAuth = client in the world ignores the =E2=80=9Ctoken_type=E2=80=9D field. But = clients being updated to support DPoP wouldn=E2=80=99t ignore it, so = that=E2=80=99s probably ok.
2) If we wanted to make = refresh token binding switchable we=E2=80=99d need a = =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the client = would need to know how to understand it and deal with its absence (since = most servers won=E2=80=99t send it).
3) This = presumes the client will not rotate its key before using the refresh = token. If it does it=E2=80=99ll have to do a whole new grant.
4) None of this prevents an RS from ignoring the DPoP = signature, but I think that=E2=80=99s a separate problem.
5) It=E2=80=99s arguable that we=E2=80=99d want a client to = be able to bind a NEW DPoP key during a refresh, using the old key as = proof for the refresh token and the new key going forward. Is this a = case we want to enable?

 =E2=80=94 Justin

On Jun = 7, 2020, at 3:22 AM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:

That=E2=80=99s correct for confidential clients.

For a public client, the refresh token is just bound to the = client id. DPoP allows binding to an ephemeral key pair for this kind of = clients.

Am 07.06.2020 um 00:57 schrieb Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org>:

=EF=BB=BF

> Am 05.06.2020 um = 22:17 schrieb George Fletcher <gffletch=3D40aol.com@dmarc..ietf.org>:
>
> Secondly, I do think we need a way to allow for the refresh_token = to be bound while leaving the access_tokens as bearer tokens. This adds = useful security without impacting existing RS deployments.

+1 that=E2=80=99s a very useful = feature_______________________________________________
AFAIK a refresh_token is always = bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_2BA832DF-6D90-4489-A32A-2ED9EA01CA80-- From nobody Wed Jun 10 16:35:55 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF7F3A15B6 for ; Wed, 10 Jun 2020 16:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgFwZl3MhWlR for ; Wed, 10 Jun 2020 16:35:51 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F203A15B2 for ; Wed, 10 Jun 2020 16:35:50 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id j198so5720552wmj.0 for ; Wed, 10 Jun 2020 16:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RsK4i/PAK34KHWqRSztWDXFioW1YgegPKQhMi1cChKE=; b=gFaz7l07iFL0hQJG1T9r2GZDju8NtmiJpqZXILKhHqdRIRDJK6pwwfsvLQGlhHRlhU PmJZ1sQgxHSs83DTgQMPnHxf10nUXGJ0A/HtHH5uMjaM9WgOTc+ybV34BDiBUZ902B8u wRP6qYNS1ZSVN7Zf5K3tE+DRVV28ZdJYOA6pU= 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=RsK4i/PAK34KHWqRSztWDXFioW1YgegPKQhMi1cChKE=; b=LXiljn5ge4WJtltkpdLbZlVzPAVSC1RSbyQs1NnplYbkV/y1ZjRZC6iqF0KeJkrwk8 6MSH9a5oYxiZ6pPkWgpwqStH4SJi3EXSmLClO12tBLyjHA0CiQG1/fBg2pgTbvSQR84X 9nbVK1+KMxo7PRMpfq/Pz0V7vHkkHebPQSdMpxqj/Q3ULRGdrGI/d6lTiAy5izpOhCm+ fFkb/4LccUuWBN6bCq934y0quWOb7+x4RV5e1zvz/6sPdDMjEdongrX6qLcEgQUMZGYl oLNLDQjqnUpoxB7TRouwtKJUyQN5ACSC73QM7P7Lm/UQ7XjX3QtGodVfEPnmujkVb0U4 VIzg== X-Gm-Message-State: AOAM532FPeRLrsKiGCY74Ww053cXQQK/JN1AfB1uqR5PjHiif5xFenxN wmPEUVEJr7Q3CJXpnbcuzlt4KDhPPXvOYuddRi2y7Q== X-Google-Smtp-Source: ABdhPJzBNSiC1kjOcNszYwDKCuserG8Fz24rkXQbpHUNBKXMwOeE+d5qGL8p4xnkSySrE27IJNRDx5RYl3YQd4Vcy5c= X-Received: by 2002:a1c:4e17:: with SMTP id g23mr5149746wmh.38.1591832149189; Wed, 10 Jun 2020 16:35:49 -0700 (PDT) MIME-Version: 1.0 References: <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu> In-Reply-To: <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu> From: Francis Pouatcha Date: Wed, 10 Jun 2020 19:35:38 -0400 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000cb7b4405a7c34d02" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 23:35:53 -0000 --000000000000cb7b4405a7c34d02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: > What if we simply declare that *refresh tokens are always bound to the > DPoP key* used to request them? Is there value in NOT binding the refresh > token? > > Fully agree. I will add a *refresh_token shall always be PoP bound*. Independent of the type of PoP. > As for access tokens, the way I read it, all of this is true: > > - The AS could still decide to issue a Bearer token, using the token_type > field, for whatever policy reason. > - A client getting back a Bearer token from a DPoP request would do Beare= r > headers. > - A client getting a DPoP token from a DPoP request would do DPoP headers= . > - An client should never send a DPoP token as a Bearer header. > - An RS should ALWAYS look for a DPoP binding signature from a DPoP schem= e > token. Missing that is an error. > > So if we just declare that a refresh token must always be DPoP bound when > DPoP is used to request it and a refresh token is issued, then we=E2=80= =99re in the > clear here, as best as I can tell, and it allows the AS some flexibility. > > Some problems with this: > > 1) Pretty much every single OAuth client in the world ignores the > =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support = DPoP wouldn=E2=80=99t > ignore it, so that=E2=80=99s probably ok. > 2) If we wanted to make refresh token binding switchable we=E2=80=99d nee= d a > =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the client wou= ld need to know > how to understand it and deal with its absence (since most servers won=E2= =80=99t > send it). > 3) This presumes the client will not rotate its key before using the > refresh token. If it does it=E2=80=99ll have to do a whole new grant. > 4) None of this prevents an RS from ignoring the DPoP signature, but I > think that=E2=80=99s a separate problem. > 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be able to bi= nd a NEW DPoP key > during a refresh, using the old key as proof for the refresh token and th= e > new key going forward. Is this a case we want to enable? > Key rotation shall be handled separately from the refresh_token process. If a refresh_token is bound to a key, the client shall keep that key till the refresh_token is consumed. A key rotation process shall be designed such as to allow the key holder to keep obsolete keys for the completion of pending processes. > > =E2=80=94 Justin > > On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt < > torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote: > > That=E2=80=99s correct for confidential clients. > > For a public client, the refresh token is just bound to the client id. > DPoP allows binding to an ephemeral key pair for this kind of clients. > > --=20 Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000cb7b4405a7c34d02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jun 10, 2020 at 4:32 PM Justin Ri= cher <jricher@mit.edu> wrote:<= br>
What if we simply declare that refresh tokens = are always bound to the DPoP key used to request them? Is there value i= n NOT binding the refresh token?

Full= y agree. I will add a refresh_token shall always be PoP bound. Indep= endent of the type of PoP.
=C2=A0
As for access tokens, the way I read it, all of this is true:
<= div>
- The AS could still decide to issue a Bearer token, usi= ng the token_type field, for whatever policy reason.
- A client g= etting back a Bearer token from a DPoP request would do Bearer headers.=C2= =A0
- A client getting a DPoP token from a DPoP request would do = DPoP headers.
- An client should never send a DPoP token as a Bea= rer header.
- An RS should ALWAYS look for a DPoP binding signatu= re from a DPoP scheme token. Missing that is an error.

=
So if we just declare that a refresh token must always be DPoP bound w= hen DPoP is used to request it and a refresh token is issued, then we=E2=80= =99re in the clear here, as best as I can tell, and it allows the AS some f= lexibility.

Some problems with this:
1) Pretty much every single OAuth client in the world ignores t= he =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support= DPoP wouldn=E2=80=99t ignore it, so that=E2=80=99s probably ok.
= 2) If we wanted to make refresh token binding switchable we=E2=80=99d need = a =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the client wou= ld need to know how to understand it and deal with its absence (since most = servers won=E2=80=99t send it).
3) This presumes the client will = not rotate its key before using the refresh token. If it does it=E2=80=99ll= have to do a whole new grant.
4) None of this prevents an RS fro= m ignoring the DPoP signature, but I think that=E2=80=99s a separate proble= m.
5) It=E2=80=99s arguable that we=E2=80=99d want a client to be= able to bind a NEW DPoP key during a refresh, using the old key as proof f= or the refresh token and the new key going forward. Is this a case we want = to enable?
Key rotation shall be handled separ= ately from the refresh_token process. If a refresh_token is bound to a key,= the client shall keep that key till the refresh_token is consumed. A key r= otation process shall be designed such as to allow the key holder to keep o= bsolete keys for the completion of pending processes.

=C2=A0=E2=80=94 Justin

On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <torste= n=3D40lodderstedt.net@dmarc.ietf.org> wrote:

That=E2=80=99s correct for confidential clients.=

For a public client, the = refresh token is just bound to the client id. DPoP allows binding to an eph= emeral key pair for this kind of clients.


--
<= div dir=3D"ltr" class=3D"gmail_signature">
Francis Pouatch= a
Co-Founder and Technical Lead at adorys
--000000000000cb7b4405a7c34d02-- From nobody Wed Jun 10 23:36:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD73A1731 for ; Wed, 10 Jun 2020 23:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py27uvXecU74 for ; Wed, 10 Jun 2020 23:36:21 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CA03A1730 for ; Wed, 10 Jun 2020 23:36:20 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id l10so4850117wrr.10 for ; Wed, 10 Jun 2020 23:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xRlcHIx0jH5CdGUnnYgKydql95K00ht/qID0k3fJnpQ=; b=lQYB37ewdNpXkXdhi+3/ipeMkaPEsZhql6t48r7jHxU74rLe5PoFPSCeZ8mq6kUFKD PgBtpERvY6ZNErVEcYov6Egkl+s/ilwNJH1J1iArmd+tkDNAQGFIrM3PcqsMrU1CZ2f6 3Hp0gySRMr6B4ruxiaD/vwXNwTcBYB65CGP409/1BWfPN1hhE6pjjpbxYoopZiQxzyZW he/XW1g3JKalPI+KGkKZzFRL6SoH0ha8RANqgGJzik33ZeoU2ry6SK4eDlxV3khjS2cm U5zlQaB+q3rMI56NS0PBDMTMMD2FBLjHezFzG6/IHVwjRl6WGwEVeLsMpytBqSgPO0Eh 8+dw== 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=xRlcHIx0jH5CdGUnnYgKydql95K00ht/qID0k3fJnpQ=; b=KzxeRrXylxSiWGYAnvqCcwEzdZHLr2fJC6m5YKBWywIzjSp5wPh/8WlH9dMLyVAIpt lWCP0K4wJp3GgyVmEe4mflwgga/BN4diwjkRItdcB2c6RR/54nhINDA9/u8QAAIVLiaf FfWf9/Cuu+HlH0pes9Yxvsa5MgHSLNAvDS5mfRaCkp4ulaPswhb/wluBxvNqQM7tsatf /N0Qh3DsNioVhIVLZNkvs68fLH7zaJRSDNZryYUWO4MGmbA0Oaz1A7Dx5pU3m1NBZHtu wartgDqRBpdsfD1GXnpFhuir0o9fbuwf8/hed17saDWlbqY3p23hoH3xPyXIp3OLbSUw GMKA== X-Gm-Message-State: AOAM530jKR2ZXssY0Yo6bd7S6+YL9LgviFRH7Z92uF2aEE+g1JONJYDK Kg2LFqoACZ+r2sHR1GZd0FZTCw== X-Google-Smtp-Source: ABdhPJxoKuI/HmTLbcnGxgmlxQTd1YfWk8Yyors5bToDDiUzbQs47UAz7x6N5bVwwLKmufie8ZD6cA== X-Received: by 2002:adf:bac8:: with SMTP id w8mr7445900wrg.47.1591857378924; Wed, 10 Jun 2020 23:36:18 -0700 (PDT) Received: from p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de (p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de. [2003:eb:8f18:4cda:d587:c99b:cde:18fd]) by smtp.gmail.com with ESMTPSA id v7sm3325152wro.76.2020.06.10.23.36.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 23:36:17 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_642BB858-DA71-4FA6-BCEC-A220955CDBE1"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 08:36:16 +0200 In-Reply-To: Cc: oauth , Justin Richer To: Francis Pouatcha References: <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 06:36:23 -0000 --Apple-Mail=_642BB858-DA71-4FA6-BCEC-A220955CDBE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I generally agree with the proposal, but I would suggest to limit it to = public clients.=20 In case of confidential clients, the refresh token is (via the = client_id) already bound to the client=E2=80=99s secret(s) and those can = be rotated. Additionally binding the refresh token to a DPoP key would = limit it=E2=80=99s applicability w/o a benefit.=20 > On 11. Jun 2020, at 01:35, Francis Pouatcha wrote: >=20 >=20 > On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: > What if we simply declare that refresh tokens are always bound to the = DPoP key used to request them? Is there value in NOT binding the refresh = token? >=20 > Fully agree. I will add a refresh_token shall always be PoP bound. = Independent of the type of PoP. > =20 > As for access tokens, the way I read it, all of this is true: >=20 > - The AS could still decide to issue a Bearer token, using the = token_type field, for whatever policy reason. > - A client getting back a Bearer token from a DPoP request would do = Bearer headers.=20 > - A client getting a DPoP token from a DPoP request would do DPoP = headers. > - An client should never send a DPoP token as a Bearer header. > - An RS should ALWAYS look for a DPoP binding signature from a DPoP = scheme token. Missing that is an error. >=20 > So if we just declare that a refresh token must always be DPoP bound = when DPoP is used to request it and a refresh token is issued, then = we=E2=80=99re in the clear here, as best as I can tell, and it allows = the AS some flexibility. >=20 > Some problems with this: >=20 > 1) Pretty much every single OAuth client in the world ignores the = =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support = DPoP wouldn=E2=80=99t ignore it, so that=E2=80=99s probably ok. > 2) If we wanted to make refresh token binding switchable we=E2=80=99d = need a =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the = client would need to know how to understand it and deal with its absence = (since most servers won=E2=80=99t send it). > 3) This presumes the client will not rotate its key before using the = refresh token. If it does it=E2=80=99ll have to do a whole new grant. > 4) None of this prevents an RS from ignoring the DPoP signature, but I = think that=E2=80=99s a separate problem. > 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be able to = bind a NEW DPoP key during a refresh, using the old key as proof for the = refresh token and the new key going forward. Is this a case we want to = enable? > Key rotation shall be handled separately from the refresh_token = process. If a refresh_token is bound to a key, the client shall keep = that key till the refresh_token is consumed. A key rotation process = shall be designed such as to allow the key holder to keep obsolete keys = for the completion of pending processes. >=20 > =E2=80=94 Justin >=20 >> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt = wrote: >>=20 >> That=E2=80=99s correct for confidential clients. >>=20 >> For a public client, the refresh token is just bound to the client = id. DPoP allows binding to an ephemeral key pair for this kind of = clients. >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ --Apple-Mail=_642BB858-DA71-4FA6-BCEC-A220955CDBE1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3 DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4 uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3 sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6 yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4 VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI 5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ 8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjExMDYzNjE2 WjAvBgkqhkiG9w0BCQQxIgQgsTYO6c2wEiuV1sPMjrO4jYdfnp94EhuY6JGmjubjvyowgbMGCSsG AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7 IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAGGKXXU03ppXRDixPg26aos3yqiXr 4fXEdHgeuYucY5m609JTOxziUNtdyP+41pWqYb34mA9edf6rFaWRt9LSMHC9wlk6u5avxrZmL6IN ejeW7N4oYGb5rbQbXo7lTjVompcAAwI89fpb4yJDqDP6321oK55dypwSt25n40MT485bvfZp9aC0 8RzqA1NBXSBIYUKKjLETtCpGJsmfmh/BU2wKDs/30z63NkDNA0HZu/EXpn5yL9NOVMA36A63HX1C joEO+gh4tJ+K6c40T2pls88HjsBPcJLRmkZ5vS5BASmkax35OpZoDZ4GOQEFOZBpgUj3//yOGXRg Uy4L7wlLiwAAAAAAAA== --Apple-Mail=_642BB858-DA71-4FA6-BCEC-A220955CDBE1-- From nobody Thu Jun 11 00:26:29 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE133A0F37 for ; Thu, 11 Jun 2020 00:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLpI3Y962Lso for ; Thu, 11 Jun 2020 00:26:26 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3303A0F59 for ; Thu, 11 Jun 2020 00:26:26 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id l10so4984492wrr.10 for ; Thu, 11 Jun 2020 00:26:26 -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=pQL75m29NwUd3ZqT4WApmbSnNgrkACyGJKa5nRFid6k=; b=dmnn7JgqZEyGH124Co34Izx8RZx1vmQyrRWl1hIeUw6ne/yPkZ0nsOqmi6Iq70lGZs GbpbFHhYUM6RHPwpFT5A83AwvDkySydRQNGe7MZXw7PAj0h2iXiUJg523peBM3WZLqME 2OgU2OMbCRCzAeJPhZ+0fA9ghtaeNADp4VvyM= 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=pQL75m29NwUd3ZqT4WApmbSnNgrkACyGJKa5nRFid6k=; b=X43hqqOdXDVPTTvvpJwi0ckibMRT1ztLYXMou5iReBSqb834KzteNraJzz1aAX85bB at7IEhmYaa3e1tbQhGiH9gYIcItV+md3S2wFeusF/+1XcUnQ8PVR0Y8iE1aQfADdk3dT QSXuK/3TtLphzdxlJJ74rKy7iNpxNDw5Z8oKHJIIOZXXdO1V7/GyBD/Q5c84bzkrbDII khfeF8tdkzVoMXogcxIjPGlQ5kXyfnB2NFoXg7H/wepnCgMZnqL9yEo89ibnZhR1vGJd xrnAd9kCfAqZngunhIEeuJDrfDwFqC8TtiIcAEXYxYW1eLItmyk1KeKHL/t5VX9Ys3Zu sk3A== X-Gm-Message-State: AOAM533/Kh836EZ2ejNTiwRIAzv1EKV7JfDGWy4sy7y9Wq5oZYt3/Hpm dz99x4kF80aPI47BB9IkdDvPzA== X-Google-Smtp-Source: ABdhPJwHFnigTt1DFrhcAdXc9F1AvyrZhAsjInkE44o5xYZt7qQpXVJJG8r8Z/F5pAHPBprtZ/tc/g== X-Received: by 2002:a5d:684a:: with SMTP id o10mr7545907wrw.4.1591860382312; Thu, 11 Jun 2020 00:26:22 -0700 (PDT) Received: from [10.0.0.3] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id w1sm2751350wmi.13.2020.06.11.00.26.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 00:26:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Neil Madden Mime-Version: 1.0 (1.0) Date: Thu, 11 Jun 2020 08:26:20 +0100 Message-Id: <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> Cc: Francis Pouatcha , oauth In-Reply-To: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 07:26:28 -0000 +1 > On 11 Jun 2020, at 07:36, Torsten Lodderstedt wrote: >=20 > =EF=BB=BFI generally agree with the proposal, but I would suggest to limit= it to public clients.=20 >=20 > In case of confidential clients, the refresh token is (via the client_id) a= lready bound to the client=E2=80=99s secret(s) and those can be rotated. Add= itionally binding the refresh token to a DPoP key would limit it=E2=80=99s a= pplicability w/o a benefit.=20 >=20 >> On 11. Jun 2020, at 01:35, Francis Pouatcha wrote: >>=20 >>=20 >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: >> What if we simply declare that refresh tokens are always bound to the DPo= P key used to request them? Is there value in NOT binding the refresh token?= >>=20 >> Fully agree. I will add a refresh_token shall always be PoP bound. Indepe= ndent of the type of PoP. >>=20 >> As for access tokens, the way I read it, all of this is true: >>=20 >> - The AS could still decide to issue a Bearer token, using the token_type= field, for whatever policy reason. >> - A client getting back a Bearer token from a DPoP request would do Beare= r headers.=20 >> - A client getting a DPoP token from a DPoP request would do DPoP headers= . >> - An client should never send a DPoP token as a Bearer header. >> - An RS should ALWAYS look for a DPoP binding signature from a DPoP schem= e token. Missing that is an error. >>=20 >> So if we just declare that a refresh token must always be DPoP bound when= DPoP is used to request it and a refresh token is issued, then we=E2=80=99r= e in the clear here, as best as I can tell, and it allows the AS some flexib= ility. >>=20 >> Some problems with this: >>=20 >> 1) Pretty much every single OAuth client in the world ignores the =E2=80=9C= token_type=E2=80=9D field. But clients being updated to support DPoP wouldn=E2= =80=99t ignore it, so that=E2=80=99s probably ok. >> 2) If we wanted to make refresh token binding switchable we=E2=80=99d nee= d a =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the client wo= uld need to know how to understand it and deal with its absence (since most s= ervers won=E2=80=99t send it). >> 3) This presumes the client will not rotate its key before using the refr= esh token. If it does it=E2=80=99ll have to do a whole new grant. >> 4) None of this prevents an RS from ignoring the DPoP signature, but I th= ink that=E2=80=99s a separate problem. >> 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be able to bi= nd a NEW DPoP key during a refresh, using the old key as proof for the refre= sh token and the new key going forward. Is this a case we want to enable? >> Key rotation shall be handled separately from the refresh_token process. I= f a refresh_token is bound to a key, the client shall keep that key till the= refresh_token is consumed. A key rotation process shall be designed such as= to allow the key holder to keep obsolete keys for the completion of pending= processes. >>=20 >> =E2=80=94 Justin >>=20 >>>> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt wrote: >>>=20 >>> That=E2=80=99s correct for confidential clients. >>>=20 >>> For a public client, the refresh token is just bound to the client id. D= PoP allows binding to an ephemeral key pair for this kind of clients. >>=20 >>=20 >> --=20 >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 11 10:24:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67F3A0B1C for ; Thu, 11 Jun 2020 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZN5FwX4bg3s for ; Thu, 11 Jun 2020 10:24:47 -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 EA4DD3A0B0B for ; Thu, 11 Jun 2020 10:24:46 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id x13so7010640wrv.4 for ; Thu, 11 Jun 2020 10:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YVHmmNW3JVhkqIPloW0C9DCKvClsu9suGLWNqSvhBsM=; b=JawBA6mrPWRJ5ShJ9vSCkilZepN3xgQhB30cQZ0oJ2tkQ+LTuJ51PSfgk8AxD3u3x+ lRmOrMx2LZTy7WHoyMUFy2Exw+M0LCGUnlN5tmko7H1DlrMYFP36ksoFk03WCFZkqUqr ZX2gR+bSzFKGF36o4XRee0ojuaM6SSjt/BV6c= 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=YVHmmNW3JVhkqIPloW0C9DCKvClsu9suGLWNqSvhBsM=; b=mWc5HIqU1sIjsswrrAGsWRmWXiNgRhnScvBxq18dGmdHEnboF9aQy44dLK+BATfywv ScHe2XdjYQzbutcMpza0KHMhKFJN5zyWSx75aodZ8ZQNgrKAEtdFKPXrT0pc6fiLMQcB c8vHGXeP0WGHT26T+CdxtvtqLcJuTlRVlg5Ir+8aJdAjwPSrODRSPrY64GMuip9nW3XG Xa2S2OkpzP/jv91nAjpk8qW6HPv/6jqCfaCb42atgKJENtBvyq+tokMOUv10HYF4sS1+ tCdIXBo5SLSH/k1p4jce+Bv6Zpk6FKXoXZewgQ6ClHGFykYcb/qtL58uUnnnZktlRjxI joVw== X-Gm-Message-State: AOAM530YnOeT38umwrg/8wTeS0x0e0q+QD5mShZBdyrN8JNbGK808uV3 k4dOCYwHGI7GbdDtjLofjljb5s67saAZnrtmEgE0ag== X-Google-Smtp-Source: ABdhPJxITnY/a3q56sLGrpIMcnqKyIQbXq3ogLBoZ15pn1Cvtd8Vncgc8d/jUjDG40yaqvgULv3lwrEE1kQ8BaXyMT0= X-Received: by 2002:adf:e545:: with SMTP id z5mr10199064wrm.89.1591896285306; Thu, 11 Jun 2020 10:24:45 -0700 (PDT) MIME-Version: 1.0 References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> In-Reply-To: <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> From: Francis Pouatcha Date: Thu, 11 Jun 2020 13:24:34 -0400 Message-ID: To: Neil Madden Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="0000000000009af76b05a7d23ccf" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 17:24:49 -0000 --0000000000009af76b05a7d23ccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 11, 2020 at 3:26 AM Neil Madden wrote: > +1 > > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > > > > =EF=BB=BFI generally agree with the proposal, but I would suggest to li= mit it to > public clients. > > > > > In case of confidential clients, the refresh token is (via the > client_id) already bound to the client=E2=80=99s secret(s) and those can = be > rotated. Additionally binding the refresh token to a DPoP key would limit > it=E2=80=99s applicability w/o a benefit. > I meant *PoP* and not *DPoP*. The client secret is also a variant of PoP. This does not change the value of this sentence: "*refresh_token shall always be bound to a PoP*". --=20 Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --0000000000009af76b05a7d23ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 11, 2020 at 3:26 AM Neil = Madden <neil.madden@forgero= ck.com> wrote:
+1

> On 11 Jun 2020, at 07:36, Torsten Lodderstedt <torsten=3D40lodderstedt.n= et@dmarc.ietf.org> wrote:
>
> =EF=BB=BFI generally agree with the proposal, but I would suggest to l= imit it to public clients.
=C2=A0
>
> In case of confidential clients, the refresh token is (via the client_= id) already bound to the client=E2=80=99s secret(s) and those can be rotate= d. Additionally binding the refresh token to a DPoP key would limit it=E2= =80=99s applicability w/o a benefit.
I meant PoP and not DPoP. The client secret is also a variant of PoP. This do= es not change the value of this sentence: "refresh_token shall alwa= ys be bound to a PoP".

--
<= div>
Francis Pouatcha
=
Co-Founder and Technical Lead at adorys
--0000000000009af76b05a7d23ccf-- From nobody Thu Jun 11 10:51:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E4D3A0CB1 for ; Thu, 11 Jun 2020 10:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUUE3_RzQmjm for ; Thu, 11 Jun 2020 10:51:23 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30DB3A0CB2 for ; Thu, 11 Jun 2020 10:51:22 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id g10so5738859wmh.4 for ; Thu, 11 Jun 2020 10:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AB8zFqddbkQJF7gE04FNUPK7mKCsiq121w8X2eXHZ3I=; b=gMo+wpaoMpvbazD0efo+pOivzJyFODunrM2Dw514nStoBpasGsMiGAN9NyBeX3slFA 7mRmg0cOQ9Lwg3xno3RNPTkYvS9X23tT1igFlkhYWKk4R9hxE3vTRpDhsc6ZQRnHAmd4 NgXQVO+r1n2TsF8OTTda2o8zsTdltqNDn/AuAwdxi9lHWSuszEf/c1TE1+XorChnLD31 BHPjQIdJWVZ7F5SrJVNZZEcd8yMp+qLipWsUhjLDE/TB3/JiHgX6GZW18kkkallSvyH6 4CSQrv0QatdTu2bqIG+Ow/itBQlAWcrlaGvMDrDXRfqWU1yF+6XFj1ZbEYguWBV3rcOd hYGA== 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=AB8zFqddbkQJF7gE04FNUPK7mKCsiq121w8X2eXHZ3I=; b=gY9XxWV4XvUUetb8a/XO0WXYvjAYT38KvbJr3N8BpzDsjmDJm/Rvad3K1PfAgHAs/0 dJ0rsC0VOXQ5qQ+XZKThdJtm6i+FdYT3ZKIujWh2QarrZk4C+Y99NuGZRQJJdZX0FulY Hb2Cj1TsnfUU36KPjJPzNAOpd5CNhDyYOITm01D2gKM9Z8p9+ZSmH2UCpbxnVMuxPY9+ /c1P0o6ZEVmtF2ok1ytAiE0Byxxd/+QYef2RVikkxlVhqofi7wSm2OZmwiHngSAJEA1b 2yhqM0xkR6BfURQLOllUQ2akTgG+oFnWhrSaDnc/CEIh19tuO/zzOX9Bavki0C3TMnYe /sMg== X-Gm-Message-State: AOAM531gqem9rzUYDfQoo/FUcbn5VwkGMN2U/MuDLMmOr9hoLxXbbl2d dGffr3+pq/f6JaPQCAetiEzmXkvM5Y8= X-Google-Smtp-Source: ABdhPJy2L8xaHKkWX29twfA8bZAZSd8E0Ahk7wJREqg//rI5drJta4q9TopPkGvC1j7Of72wm0OWGQ== X-Received: by 2002:a1c:5a82:: with SMTP id o124mr9113241wmb.188.1591897879829; Thu, 11 Jun 2020 10:51:19 -0700 (PDT) Received: from p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de (p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de. [2003:eb:8f18:4cda:d587:c99b:cde:18fd]) by smtp.gmail.com with ESMTPSA id k17sm6163198wrl.54.2020.06.11.10.51.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 10:51:18 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <25B48BEE-D460-4CD8-8432-19D383E5B8EE@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D93FE8F3-78F0-412A-8F1D-0D6482AE2735"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 19:51:16 +0200 In-Reply-To: Cc: Neil Madden , oauth To: Francis Pouatcha References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 17:51:24 -0000 --Apple-Mail=_D93FE8F3-78F0-412A-8F1D-0D6482AE2735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11. Jun 2020, at 19:24, Francis Pouatcha = wrote: >=20 >=20 >=20 > On Thu, Jun 11, 2020 at 3:26 AM Neil Madden = wrote: > +1 >=20 > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt = wrote: > >=20 > > =EF=BB=BFI generally agree with the proposal, but I would suggest to = limit it to public clients.=20 > =20 > >=20 > > In case of confidential clients, the refresh token is (via the = client_id) already bound to the client=E2=80=99s secret(s) and those can = be rotated. Additionally binding the refresh token to a DPoP key would = limit it=E2=80=99s applicability w/o a benefit.=20 > I meant PoP and not DPoP. The client secret is also a variant of PoP. = This does not change the value of this sentence: "refresh_token shall = always be bound to a PoP". This means you agree DPoP shall be used for refresh tokens issued to = public clients only? As you said, client authentication is a kind of PoP = as well, so confidential clients don=E2=80=99t need DPoP protection for = refresh tokens.=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ --Apple-Mail=_D93FE8F3-78F0-412A-8F1D-0D6482AE2735 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3 DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4 uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3 sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6 yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4 VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI 5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ 8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjExMTc1MTE3 WjAvBgkqhkiG9w0BCQQxIgQg0fScj/ms5sPk0ICU3lzTKHBx73Xgg4nt5yOLr9TGmCUwgbMGCSsG AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7 IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAJoOYLV5hlSCYAOpR8ip/0hreh84h h08AeWLlZpw6ZWZsnVvJNTPQUSjoNY07cRfBheAQYlr0/uS18mqZBQUxX/7mudg4GDHly6F4eSrZ H9vB1THY+Fo6z2Vz50MFl3Nz3XWVQ66svYRNxx+sLy8+0zZmUAs5JQ87gH862M4tcmviWTCuGzNW 37yEnZZBLTFMFuRM4t4+oXkPZKzQFGdYCEwsDr7dOsJNq7EdFi3dmYofk+N6OESlW6oYwNfJzW1g E9CH4Ta0grU52WkH6qbunnx331IF/EFSm6D8TXbB4YUwAPM4rDUub7vWas47G3liuD90p2aWF0Rg Ydgd2HERgwAAAAAAAA== --Apple-Mail=_D93FE8F3-78F0-412A-8F1D-0D6482AE2735-- From nobody Thu Jun 11 14:16:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDFD3A098C for ; Thu, 11 Jun 2020 14:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeATWH1YIGaj for ; Thu, 11 Jun 2020 14:16:21 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706C13A0982 for ; Thu, 11 Jun 2020 14:16:21 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id r15so6416705wmh.5 for ; Thu, 11 Jun 2020 14:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XwdP/TFrGPjrQ6HyH8lt0SpYZOM5A7HCtzt4SS4HUFA=; b=Xnucj5TkuRq4dylv93/anXb8eCJ88Khorym/u+Qd0buzOdl4tC9cDmENUunRUeVYQP TVUoJ9o4bYtUKlIgX5F1BinZN6bja99OaxazratgZPZpopEriOmqtePGUeD/uET29kKk cQKWQMx0wuQxZRyp2l+O2/TOenlsjJbf/aNfE1vlX3HHFyF5dQHshUbtfxo/cSC3OsWr nTpuTd6cb7NpuVyeh1rA/VpB2w6tIInKH+SuyqYAJKIUdmxri86HSxwQE/IMCyhgxLhw tLMJp4JfKWU/gntcF8EE6sEa0iFUGJ3ZXM9qVGQnjP+MfB08/4jZu8WO9AgqImyhnupE YYDw== 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=XwdP/TFrGPjrQ6HyH8lt0SpYZOM5A7HCtzt4SS4HUFA=; b=PwPAd1GlKJURSPFaYG1kz7D3E7aC829JklrmxkuvB9iocQyWRTNqJA9fCo7Eb8niHU bwx4gDSkdgeSDr1jPZnPt4OcniZdNMC7AcNwRXk7CyqHJKLzUl7fnCWtRcwhLZgDG/CD ZiO3/7MOFys6WKKfylx+sCGR61cXBXgMhtI1WOopqb6kZNmtbqkx+PbBKeXk1iJNj1YX DhcpETvwV1kK3Q+Y9QxNmW7UWb78C7GiRSQynzQwCsOsK1Dh2jslzoSEj+D40/gXvVxg gylC1sYBSXFPRjZ80T47lbQrVPtRfE2AupGjhsE6yqO+RNYmsRE9n01V64gYkJCzKjk/ Lm7Q== X-Gm-Message-State: AOAM532nZT3jeITHiP81HqKYT2Xd31yjUBX0mMpQMk3Jarn9W8QnQX9g lAB3slBFH43+BRTHG0uFDO0xI9Jv16tv8eZozLlod36w X-Google-Smtp-Source: ABdhPJye/jVT3YpNBDCO52OB5Gn81Tp8Vm75DoP9tJ1WBBhGdsxxMFCmJrfi3/VndDuREndW+oZc1h3ZUAyMck6ZM9A= X-Received: by 2002:a7b:c40e:: with SMTP id k14mr10476785wmi.59.1591910179549; Thu, 11 Jun 2020 14:16:19 -0700 (PDT) MIME-Version: 1.0 References: <159181529656.16063.6964178024900109434@ietfa.amsl.com> In-Reply-To: <159181529656.16063.6964178024900109434@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Thu, 11 Jun 2020 17:16:08 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c4361f05a7d57868" Archived-At: Subject: [OAUTH-WG] Fwd: Nomcom 2020-2021 Second Call For Volunteers X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Jun 2020 21:16:24 -0000 --000000000000c4361f05a7d57868 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please, consider volunteering for this role. Regards, Rifaat ---------- Forwarded message --------- From: NomCom Chair 2020 Date: Wed, Jun 10, 2020 at 2:55 PM Subject: Nomcom 2020-2021 Second Call For Volunteers To: IETF Announcement List Cc: This is the second sending of the call for volunteers for the 2020-2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago): - I've fixed the URL at the bottom of the email to point to https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a test to see if anyone was paying attention. Apparently, some people were. ;= ) - The IETF 108 registration form includes a checkbox that will let you volunteer. You can use this instead of emailing me, when you register for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers! ---------------------------------------------------------------------------= ------ The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py. If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD =C3=89ric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 20-24 July (exact time and date to be determined after NomCom membership is finalized on July 12), the week prior to IETF 108. Being at IETF 110 (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as follows: To: nomcom-chair-2020@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email body: Your Full Name: // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://datatracker.ietf.org/nomcom/2020/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Barbara Stark bs7652 at att dot com nomcom-chair-2020 at ietf dot org --000000000000c4361f05a7d57868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please, consider volunteering=C2=A0for this role.

=
Regards,
=C2=A0Rifaat


---------- Forwarded mes= sage ---------
From: Nom= Com Chair 2020 <nomcom-chair-2020@ietf.org>
Date: Wed, J= un 10, 2020 at 2:55 PM
Subject: Nomcom 2020-2021 Second Call For Volunte= ers
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: <ietf@ietf.org>


This is the second sending of = the call for volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks ago= ):
=C2=A0- I've fixed the URL at the bottom of the email to point to https://datatracker.ietf.org/nomcom/2020/ instead of /2019/= . This was a test to see if anyone was paying attention. Apparently, some p= eople were. ;)
=C2=A0- The IETF 108 registration form includes a checkbox that will let yo= u volunteer. You can use this instead of emailing me, when you register for= IETF 108.
=C2=A0- I currently have 39 volunteers. Last year had 149. I need more volu= nteers!
---------------------------------------------------------------------------= ------
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Tru= st, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way f= rom a pool of volunteers. The more volunteers, the better chance we have of= choosing a random yet representative cross section of the IETF population.=

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713= ). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

=C2=A0 =C2=A0 =C2=A0 Members of the IETF community must have attended at le= ast three of
=C2=A0 =C2=A0 =C2=A0 the last five in-person IETF meetings in order to volu= nteer.

=C2=A0 =C2=A0 =C2=A0 The five meetings are the five most recent in-person m= eetings that
=C2=A0 =C2=A0 =C2=A0 ended prior to the date on which the solicitation for = NomCom
=C2=A0 =C2=A0 =C2=A0 volunteers was submitted for distribution to the IETF = community.
=C2=A0 =C2=A0 =C2=A0 Because no IETF 107 in-person meeting was held, for th= e 2020-2021
=C2=A0 =C2=A0 =C2=A0 Nominating Committee those five meetings are IETFs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 102 [Montreal, Canada; July 2018],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 103 [Bangkok, Thailand; November 2018],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 104 [Prague, Czech Republic; March 2019],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 105 [Montreal, Canada; July 2019], and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five = listed meetings. You can check your eligibility at: https= ://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you decide to volunteer, please re= member that anyone appointed to this NomCom will not be considered as a can= didate for any of the positions that the 2020 - 2021 NomCom is responsible = for filling.

People commonly volunteer by ticking the box on IETF registration forms. Th= e IETF 106 form did not ask whether people were willing to volunteer. IETF = 107 did ask, but all those registrations were canceled. I have asked the Se= cretariat if it is possible to get the list if volunteers from canceled IET= F 107 registrations. If that list is available, I will contact all who are = verified as eligible. But given the uncertainty of this process, I would en= courage people to volunteer directly (see the bottom of this email for inst= ructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeti= ng, and thus the positions for which this NomCom is responsible, are

IETF Trust:
=C2=A0 =C2=A0 Joel Halpern

LLC:
=C2=A0 =C2=A0 Maja Andjelkovic

IAB:
=C2=A0 =C2=A0 Jari Arkko
=C2=A0 =C2=A0 Jeff Tantsura
=C2=A0 =C2=A0 Mark Nottingham
=C2=A0 =C2=A0 Stephen Farrell
=C2=A0 =C2=A0 Wes Hardaker
=C2=A0 =C2=A0 Zhenbin Li

IESG:
=C2=A0 =C2=A0 Alissa Cooper, IETF Chair/GEN AD
=C2=A0 =C2=A0 Alvaro Retana, RTG AD
=C2=A0 =C2=A0 Barry Leiba, ART AD
=C2=A0 =C2=A0 Deborah Brungard, RTG AD
=C2=A0 =C2=A0 =C3=89ric Vyncke, INT AD
=C2=A0 =C2=A0 Magnus Westerlund, TSV AD
=C2=A0 =C2=A0 Roman Danyliw, SEC AD
=C2=A0 =C2=A0 Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the Genera= l area has 1; all other areas have 2 ADs. Thus, all areas (that have more t= han one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be = completed in January 2021.=C2=A0 The NomCom will have regularly scheduled c= onference calls to ensure progress. There will be activities to collect req= uirements from the community, review candidate questionnaires, review feedb= ack from community members about candidates, and talk to candidates.

While being a NomCom member does require some time commitment it is also a = very rewarding experience.

As a member of the NomCom it is very important that you be willing and able= to attend either videoconference or in-person meetings (which may not happ= en) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Video= conference attendance will be supported whether or not there are in-person = meetings. Orientation and setting of the NomCom schedule will be done by vi= deoconference during the week 20-24 July (exact time and date to be determi= ned after NomCom membership is finalized on July 12), the week prior to IET= F 108.=C2=A0 Being at IETF 110 (Prague) is not essential.

Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as = follows:

To: nomcom-= chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Please include the following information in the email body:

Your Full Name:
=C2=A0 =C2=A0 // as you write it on the IETF registration form

Current Primary Affiliation:
=C2=A0 =C2=A0 // Typically what goes in the Company field
=C2=A0 =C2=A0 // in the IETF Registration Form

Emails:
=C2=A0 =C2=A0// All email addresses used to register for the past 5 IETF me= etings
=C2=A0 =C2=A0// Preferred email address first

Telephone:
=C2=A0 =C2=A0 // For confirmation if selected

You should expect an email response from me within 5 business days stating = whether or not you are qualified.=C2=A0 If you don't receive this respo= nse, please re-send your email with the tag "RESEND"" added = to the subject line.

If you are not yet sure if you would like to volunteer, please consider tha= t NomCom members play a very important role in shaping the leadership of th= e IETF.=C2=A0 Questions by email or voice are welcome. Volunteering for the= NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2020/=

I will be publishing a more detailed target timetable, as well as details o= f the randomness seeds to be used for the RFC 3797 selection process, withi= n the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf dot org

--000000000000c4361f05a7d57868-- From nobody Thu Jun 11 14:17:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73E3A0A9B for ; Thu, 11 Jun 2020 14:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25-BjTrX3iSI for ; Thu, 11 Jun 2020 14:17:45 -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 D279B3A0A96 for ; Thu, 11 Jun 2020 14:17:40 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id e125so4331502lfd.1 for ; Thu, 11 Jun 2020 14:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+4nqHRxe0EdpbLwe1L/6WhNdZneHQI2i3QHU5DHFJr0=; b=G9i9tqZtForxIAW9W0PN2lv4MxbNcG6mNLXxdZev4jXuPlvdcZYwNFhUOR5PRPQATZ pyJO3RDoTytpv9aFEHRaaLlqvunospC26CoqoKi/CM7FwjJ7O97NlbF3FDcMynP3hlDF p2rB/LwRsMwUsiFbmCLiocE9EMgzbzILps3nhcFPYjSTSS8pIUQ+/B1TASRJrfx2fYUU cc1qm3+r8xFWL21lJecgsW0gUEMoDCvf5pP98p52hNW2l4LFJPDTGdPUrWFbtF20Wd5q L3PPhdpXRFWRbMysAIyXONqKTR4t53V1MNwPLlcTX4gRc7IYSdfhzzfyGpm0kdV2VJ6z V3Uw== 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=+4nqHRxe0EdpbLwe1L/6WhNdZneHQI2i3QHU5DHFJr0=; b=lL2eSaMtkf6wa4t93nuRwZwjjaJeWyxGyvLmqk6IIFHSJDBOje8REIVroTzLNhpK3o +91ND6WVIikmpicv0F+ZH09QBGGielcvflcm0ySkAQR7OgGzXFhDTtM3S9tJaeexA/u5 BuCRIvXuw/a7uyXHoTxUYwLbgtRYFYC38+ylox2eymT/KI0AYknBpTfuVWci3PbZBadl sbBJ0tgOsOnlKv3sGuqN9GEei/ZpsmfTU149V5rcVz3dOMrv6x8pAI/AwJ/cOUoGNO9d zu+Fj6/Yz6fOtisa6CMLAbzIb5qqNouXHjPY6h+uL7oBu6BqIg91HrfIpJDTmjnplAGU mQLw== X-Gm-Message-State: AOAM533a7syJ9O89E/79ApogK7POPFgnz6/KooTHQ2PF3FzjPLob3kFW qhhzhL2IlDe6KcN6PrM9kdI4y7bqWbsmFpN1RSE+v6Wwl0GQS2SllcAnZ6Z4cyity/TladoMUe2 4o2lOq69xIGu2nQ== X-Google-Smtp-Source: ABdhPJyWIfWYuN7vuoDVcccMMBFcuaBSpYoFXuamKkbFHNZIOM9K373EocE1HJaqxNuS1pWHPmOGPlH9wlTY+XR2ioY= X-Received: by 2002:a19:103:: with SMTP id 3mr5019211lfb.196.1591910257270; Thu, 11 Jun 2020 14:17:37 -0700 (PDT) MIME-Version: 1.0 References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> In-Reply-To: <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> From: Brian Campbell Date: Thu, 11 Jun 2020 15:17:10 -0600 Message-ID: To: Neil Madden Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000663c5505a7d57d79" Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:17:49 -0000 --000000000000663c5505a7d57d79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The current draft (draft-ietf-oauth-dpop-01) does say that when a valid DPoP proof is presented and refresh token is issued to a public client, the refresh token must be bound to the DPoP key. So that part is already covered in the document. And, for whatever it's worth, that pretty closely mirrors how it works with MTLS, public clients, and RTs. If there are specific suggestions as to how to make it more clear, they'd of course be welcome. The text in draft does need to be updated to better account/allow for, as Justin said, the "AS could still decide to issue a Bearer token, using the token_type field, for whatever policy reason." I'd sort of thought it already did and it was the intent but, on reading again, there's definitely some text that needs to be fixed. That should help better facilitate mixed or rollout deployments by letting the AS decide to bind ATs or not based on resource or scope requested or other policy. Also to help facilitate mixed or rollout deployments, I'm not sure about "An client should never send a DPoP [bound access] token as a Bearer header." Such a constraint could be put on the client but it seems unhelpful. A bad acting client could easily ignore it and I'm not sure what it accomplishes if/when followed. Following from https://github.com/danielfett/draft-dpop/issues/58 the draft needs to be updated to say explicitly that an RS supporting both Bearer and DPoP schemes simultaneously needs to update its Bearer token evaluation functionality so as to reject tokens that are dpop bound. But the draft can't really impose anything on existing RSs supporting only Bearer (and unaware of DPoP). And such RSs will most likely accept a DPoP bound AT when send via the Bearer scheme (JWT says to ignore unrecognized claims, introspection says other parameters might be present, and 6750 is basically silent on the content of the AT, which is where the binding is carried). This admittedly doesn't seem quite right. But there's nothing this draft can realistically do about it. And I think it can help with mixed or rollout deployments. Especially those where sufficient information about what RS(s) the requested token is for are not available in the token request for whatever reason. Currently the draft is silent about it and maybe that's as it should be. But I'm suggesting in a few messages on this thread that the definition of the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP header but also say that, if that was met with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or the client had prior such knowledge about the RS), that the access token could be sent using the Bearer authorization scheme. It is correct that, as currently written in the draft, a public client with a DPoP bound refresh token will have to use the same key for the lifetime of the grant. That seemed like a good tradeoff vs. defining a mechanism for key rotation for the public client refresh token case where two proofs (one to verify the binding for the RT being sent and one to newly bind the RT to) would be presented on refresh grant type request. I tend to think where it is now hits the right balance in functionality and complexity. But if there are strong beliefs otherwise, let's discuss the need and cost/benefit and all that. On Thu, Jun 11, 2020 at 1:26 AM Neil Madden wrote: > +1 > > > On 11 Jun 2020, at 07:36, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > > > > =EF=BB=BFI generally agree with the proposal, but I would suggest to li= mit it to > public clients. > > > > In case of confidential clients, the refresh token is (via the > client_id) already bound to the client=E2=80=99s secret(s) and those can = be > rotated. Additionally binding the refresh token to a DPoP key would limit > it=E2=80=99s applicability w/o a benefit. > > > >> On 11. Jun 2020, at 01:35, Francis Pouatcha wrote: > >> > >> > >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer wrote: > >> What if we simply declare that refresh tokens are always bound to the > DPoP key used to request them? Is there value in NOT binding the refresh > token? > >> > >> Fully agree. I will add a refresh_token shall always be PoP bound. > Independent of the type of PoP. > >> > >> As for access tokens, the way I read it, all of this is true: > >> > >> - The AS could still decide to issue a Bearer token, using the > token_type field, for whatever policy reason. > >> - A client getting back a Bearer token from a DPoP request would do > Bearer headers. > >> - A client getting a DPoP token from a DPoP request would do DPoP > headers. > >> - An client should never send a DPoP token as a Bearer header. > >> - An RS should ALWAYS look for a DPoP binding signature from a DPoP > scheme token. Missing that is an error. > >> > >> So if we just declare that a refresh token must always be DPoP bound > when DPoP is used to request it and a refresh token is issued, then we=E2= =80=99re > in the clear here, as best as I can tell, and it allows the AS some > flexibility. > >> > >> Some problems with this: > >> > >> 1) Pretty much every single OAuth client in the world ignores the > =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support = DPoP wouldn=E2=80=99t > ignore it, so that=E2=80=99s probably ok. > >> 2) If we wanted to make refresh token binding switchable we=E2=80=99d = need a > =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the client wou= ld need to know > how to understand it and deal with its absence (since most servers won=E2= =80=99t > send it). > >> 3) This presumes the client will not rotate its key before using the > refresh token. If it does it=E2=80=99ll have to do a whole new grant. > >> 4) None of this prevents an RS from ignoring the DPoP signature, but I > think that=E2=80=99s a separate problem. > >> 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be able to= bind a NEW DPoP > key during a refresh, using the old key as proof for the refresh token an= d > the new key going forward. Is this a case we want to enable? > >> Key rotation shall be handled separately from the refresh_token > process. If a refresh_token is bound to a key, the client shall keep that > key till the refresh_token is consumed. A key rotation process shall be > designed such as to allow the key holder to keep obsolete keys for the > completion of pending processes. > >> > >> =E2=80=94 Justin > >> > >>>> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >>> > >>> That=E2=80=99s correct for confidential clients. > >>> > >>> For a public client, the refresh token is just bound to the client id= . > DPoP allows binding to an ephemeral key pair for this kind of clients. > >> > >> > >> -- > >> Francis Pouatcha > >> Co-Founder and Technical Lead at adorys > >> https://adorsys-platform.de/solutions/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > 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._ --000000000000663c5505a7d57d79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current draft (draft-ietf-oauth-= dpop-01) does say that when a valid DPoP proof is presented and refresh tok= en is issued to a public client, the refresh token must be bound to the DPo= P key. So that part is already covered in the document. And, for whatever i= t's worth, that pretty closely mirrors how it works with MTLS, public c= lients, and RTs. If there are specific suggestions as to how to make it mor= e clear, they'd of course be welcome.

The= text in draft does need to be updated to better account/allow for, as Just= in said, the "AS could still decide to issue a Bearer token, using the= token_type field, for whatever policy reason." I'd sort of though= t it already did and it was the intent but, on reading again, there's d= efinitely some text that needs to be fixed. That should help better facili= tate mixed or rollout deployments by letting the AS decide to bind ATs or n= ot based on resource or scope requested or other policy.
Also to help facilitate mixed or rollout deployments, I'm n= ot sure about "An client should never send a DPoP [bound access] token= as a Bearer header."=C2=A0 Such a constraint could be put on the clie= nt but it seems unhelpful. A bad acting client could easily ignore it and I= 'm not sure what it accomplishes if/when followed. Following from https://github.com/danielfett/draft-dpop/issues/58 the draft needs to = be updated to say explicitly that an RS supporting both Bearer and DPoP schemes simultan= eously needs to update its Bearer token evaluation functionality so as to r= eject tokens that are dpop bound. But the draft can't really impo= se anything on existing RSs supporting only Bearer (and unaware of DPoP). A= nd such RSs will most likely accept a DPoP bound AT when send via the Beare= r scheme (JWT says to ignore unrecognized claims, introspection says other = parameters might be present, and 6750 is basically silent on the content of= the AT, which is where the binding is carried). This admittedly doesn'= t seem quite right. But there's nothing this draft can realistically do= about it. And I think it can help with mixed or rollout deployments. Espec= ially those where sufficient information about what RS(s) the requested tok= en is for are not available in the token request for whatever reason. Curre= ntly the draft is silent about it and maybe that's as it should be. But= I'm suggesting in a few messages on this thread that the definition of= the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP=20 header but also say that, if that was met with a 401 WWW-Authenticate:=20 Bearer challenge by a particular RS (or the client had prior such knowledge= about the RS),=20 that the access token could be sent using the Bearer authorization=20 scheme.

It is correct that, as curre= ntly written in the draft, a public client with a DPoP bound refresh token = will have to use the same key for the lifetime of the grant. That seemed li= ke a good tradeoff vs. defining a mechanism for key rotation for the public= client refresh token case where two proofs (one to verify the binding for = the RT being sent and one to newly bind the RT to) would be presented on re= fresh grant type request. I tend to think where it is now hits the right ba= lance in functionality and complexity. But if there are strong beliefs othe= rwise, let's discuss the need and cost/benefit and all that.
=



On Thu, Jun 11, 2020 at 1:26 AM Neil Madden &= lt;neil.madd= en@forgerock.com> wrote:
+1

> On 11 Jun 2020, at 07:36, Torsten Lodderstedt <torsten=3D40lodderstedt.n= et@dmarc.ietf.org> wrote:
>
> =EF=BB=BFI generally agree with the proposal, but I would suggest to l= imit it to public clients.
>
> In case of confidential clients, the refresh token is (via the client_= id) already bound to the client=E2=80=99s secret(s) and those can be rotate= d. Additionally binding the refresh token to a DPoP key would limit it=E2= =80=99s applicability w/o a benefit.
>
>> On 11. Jun 2020, at 01:35, Francis Pouatcha <fpo@adorsys.de> wrote:
>>
>>
>> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <jricher@mit.edu> wrote:
>> What if we simply declare that refresh tokens are always bound to = the DPoP key used to request them? Is there value in NOT binding the refres= h token?
>>
>> Fully agree. I will add a refresh_token shall always be PoP bound.= Independent of the type of PoP.
>>
>> As for access tokens, the way I read it, all of this is true:
>>
>> - The AS could still decide to issue a Bearer token, using the tok= en_type field, for whatever policy reason.
>> - A client getting back a Bearer token from a DPoP request would d= o Bearer headers.
>> - A client getting a DPoP token from a DPoP request would do DPoP = headers.
>> - An client should never send a DPoP token as a Bearer header.
>> - An RS should ALWAYS look for a DPoP binding signature from a DPo= P scheme token. Missing that is an error.
>>
>> So if we just declare that a refresh token must always be DPoP bou= nd when DPoP is used to request it and a refresh token is issued, then we= =E2=80=99re in the clear here, as best as I can tell, and it allows the AS = some flexibility.
>>
>> Some problems with this:
>>
>> 1) Pretty much every single OAuth client in the world ignores the = =E2=80=9Ctoken_type=E2=80=9D field. But clients being updated to support DP= oP wouldn=E2=80=99t ignore it, so that=E2=80=99s probably ok.
>> 2) If we wanted to make refresh token binding switchable we=E2=80= =99d need a =E2=80=9Crefresh_token_type=E2=80=9D field or similar, and the = client would need to know how to understand it and deal with its absence (s= ince most servers won=E2=80=99t send it).
>> 3) This presumes the client will not rotate its key before using t= he refresh token. If it does it=E2=80=99ll have to do a whole new grant. >> 4) None of this prevents an RS from ignoring the DPoP signature, b= ut I think that=E2=80=99s a separate problem.
>> 5) It=E2=80=99s arguable that we=E2=80=99d want a client to be abl= e to bind a NEW DPoP key during a refresh, using the old key as proof for t= he refresh token and the new key going forward. Is this a case we want to e= nable?
>> Key rotation shall be handled separately from the refresh_token pr= ocess. If a refresh_token is bound to a key, the client shall keep that key= till the refresh_token is consumed. A key rotation process shall be design= ed such as to allow the key holder to keep obsolete keys for the completion= of pending processes.
>>
>> =E2=80=94 Justin
>>
>>>> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <torste= n=3D4= 0lodderstedt.net@dmarc.ietf.org> wrote:
>>>
>>> That=E2=80=99s correct for confidential clients.
>>>
>>> For a public client, the refresh token is just bound to the cl= ient id. DPoP allows binding to an ephemeral key pair for this kind of clie= nts.
>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
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. --000000000000663c5505a7d57d79-- From nobody Fri Jun 12 08:10:47 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9443A0C01 for ; Fri, 12 Jun 2020 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtHahZp8GZYH for ; Fri, 12 Jun 2020 08:10:43 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825283A0B50 for ; Fri, 12 Jun 2020 08:10:43 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id A23897822 for ; Fri, 12 Jun 2020 15:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591974640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4AvXBE3o+MPg5I8jGErmlrHXfHwqsKQAEhe4r1GWUz8=; b=DMSk7//muQoIQVdp8zPERVV6gKARltDuNWUpg1tZ0ylCAWLSBfUbSKbv3x75Mf1MOh2BzU D/6JwQhhD2kmAS6+dVclgEXDb/aDo/iEVpoAQZk68jnJVH+Ip9WjtVxpyABT54cGNyKceD GlrTc5kCBdoPGH+2cO7ZMEnP9+xg+PY= To: oauth@ietf.org References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> From: Daniel Fett Message-ID: <8154b9ce-6238-9516-6fe7-a933ec7acc13@danielfett.de> Date: Fri, 12 Jun 2020 17:10:39 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0A7DA632255ED3EB09EB92B0" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591974640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4AvXBE3o+MPg5I8jGErmlrHXfHwqsKQAEhe4r1GWUz8=; b=MF1tYlwyp0s6UIboBkr4LY8rI9QKqNWZVdHgWotSwJTiw1HIbYbXytZ47SVUGaznxDzSwk DRxgjzBa8zXSaV9J2MB9cdVBoEVODaWpM9OBlBEWf94JQ5m2YlmqmAM/zFOWDJ5BXpKmLT 3I7ix8W8ellWxgpCu9SotJHO70xjTMg= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591974640; a=rsa-sha256; cv=none; b=h2QcrsIjgxJZuZbBljThPpOvupRJ4/rSgu3FowmQ5FrKp7ybUTqOT7x9FqswvBH7BlxDmc 2B2sgIdV7p2xpw+vLn48TzUjKS2CIPTFEOSWBQBLNZhO19OZu2qewvFXYChaOtD4IEUf3Y MGT/RiGnjGdqxm7wY0eAVrBQwcLgsh0= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 15:10:45 -0000 This is a multi-part message in MIME format. --------------0A7DA632255ED3EB09EB92B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 11.06.20 um 23:17 schrieb Brian Campbell: > > Also to help facilitate mixed or rollout deployments, I'm not sure > about "An client should never send a DPoP [bound access] token as a > Bearer header."  Such a constraint could be put on the client but it > seems unhelpful. A bad acting client could easily ignore it and I'm > not sure what it accomplishes if/when followed. Following from > https://github.com/danielfett/draft-dpop/issues/58 the draft needs to > be updated to say explicitly that an RS supporting both Bearer and > DPoP schemes simultaneously needs to update its Bearer token > evaluation functionality so as to reject tokens that are dpop bound. > But the draft can't really impose anything on existing RSs supporting > only Bearer (and unaware of DPoP). And such RSs will most likely > accept a DPoP bound AT when send via the Bearer scheme (JWT says to > ignore unrecognized claims, introspection says other parameters might > be present, and 6750 is basically silent on the content of the AT, > which is where the binding is carried). This admittedly doesn't seem > quite right. But there's nothing this draft can realistically do about > it. And I think it can help with mixed or rollout deployments. > Especially those where sufficient information about what RS(s) the > requested token is for are not available in the token request for > whatever reason. Currently the draft is silent about it and maybe > that's as it should be. But I'm suggesting in a few messages on this > thread that the definition of the DPoP token_type would prescribe > sending the access token with the DPoP authorization scheme in > conjunction with the DPoP header but also say that, if that was met > with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or > the client had prior such knowledge about the RS), that the access > token could be sent using the Bearer authorization scheme. I would support that. > > It is correct that, as currently written in the draft, a public client > with a DPoP bound refresh token will have to use the same key for the > lifetime of the grant. That seemed like a good tradeoff vs. defining a > mechanism for key rotation for the public client refresh token case > where two proofs (one to verify the binding for the RT being sent and > one to newly bind the RT to) would be presented on refresh grant type > request. I tend to think where it is now hits the right balance in > functionality and complexity. But if there are strong beliefs > otherwise, let's discuss the need and cost/benefit and all that. Absolutely agree. We would create a lot of complexity for very little gain. -Daniel -- https://danielfett.de --------------0A7DA632255ED3EB09EB92B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 11.06.20 um 23:17 schrieb Brian Campbell:

Also to help facilitate mixed or rollout deployments, I'm not sure about "An client should never send a DPoP [bound access] token as a Bearer header."  Such a constraint could be put on the client but it seems unhelpful. A bad acting client could easily ignore it and I'm not sure what it accomplishes if/when followed. Following from https://github.com/danielfett/draft-dpop/issues/58 the draft needs to be updated to say explicitly that an RS supporting both Bearer and DPoP schemes simultaneously needs to update its Bearer token evaluation functionality so as to reject tokens that are dpop bound. But the draft can't really impose anything on existing RSs supporting only Bearer (and unaware of DPoP). And such RSs will most likely accept a DPoP bound AT when send via the Bearer scheme (JWT says to ignore unrecognized claims, introspection says other parameters might be present, and 6750 is basically silent on the content of the AT, which is where the binding is carried). This admittedly doesn't seem quite right. But there's nothing this draft can realistically do about it. And I think it can help with mixed or rollout deployments. Especially those where sufficient information about what RS(s) the requested token is for are not available in the token request for whatever reason. Currently the draft is silent about it and maybe that's as it should be. But I'm suggesting in a few messages on this thread that the definition of the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP header but also say that, if that was met with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or the client had prior such knowledge about the RS), that the access token could be sent using the Bearer authorization scheme.
I would support that.

It is correct that, as currently written in the draft, a public client with a DPoP bound refresh token will have to use the same key for the lifetime of the grant. That seemed like a good tradeoff vs. defining a mechanism for key rotation for the public client refresh token case where two proofs (one to verify the binding for the RT being sent and one to newly bind the RT to) would be presented on refresh grant type request. I tend to think where it is now hits the right balance in functionality and complexity. But if there are strong beliefs otherwise, let's discuss the need and cost/benefit and all that.

Absolutely agree. We would create a lot of complexity for very little gain.

-Daniel


-- 
https://danielfett.de
--------------0A7DA632255ED3EB09EB92B0-- From nobody Fri Jun 12 09:55:24 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E93A0847 for ; Fri, 12 Jun 2020 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zjAnHvLIpQE for ; Fri, 12 Jun 2020 09:55:17 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC9B3A07CE for ; Fri, 12 Jun 2020 09:55:17 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id r7so10455359wro.1 for ; Fri, 12 Jun 2020 09:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XCeVNWUdrlFYlPk3irGk0k22WTGzFUWwlXpogyD3JII=; b=KIRCw1lte4aheCcLzGG5MZvlvECNYTnl9+7YHFGCX/raWrClzVTHsQfC/9YO+ToRkK +0DZepnYD0om0ws/ViimJeR6R0L7nuApBElMnNr8I9oJAGXyvHVGtFMlf3Ic9rzWTLR+ xgz9aXSOb0X7cnvJlvit2H5ZdKGbRNcZRp4f2sBupA5j/uefakWo4+dkYon8SyknWFUO e8d8tm7VCl48JwtFhVbTdxeF46Qxe/Zo5RxfrTsx+qrIzC6lLysiI0yQK04tRVZdeirP mHvxll8bF70OyxlTa13YCl7JGIVlMtoYu+rueciQmFAhaWu71wGRMOALsFDvkkIUdLzb E4BQ== 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=XCeVNWUdrlFYlPk3irGk0k22WTGzFUWwlXpogyD3JII=; b=c6lFf+1HLqbdKRHJU2kF1cr2upQeL0M7IwcpQocyaEOe9DNg5PT/nFhgUMxFLIUpze eBuwWVf+MZeGDEKNVJ3WN5I64ljcRU600ai52qZ8Jta84ZGH1KEkC+L7nWcqrItEMsDt cAw1gasWqVpGE+X4eZlx65ewKhbjw3h7CrmKKvle6OTFtTaK+WsrzI0KOLuhkXbO0iog E+NXiqB6h7boAn1vwINqmAZDKqoIb5CHjJMeSt1YimDcWJlb9SXY5Mcs4nNVG0eVSSo8 G7PdETINkLhDK/A+kfXUXnDmoFZ5AJvRTlsdx1Ca/I8KgA9R75vtywMJZmO4Xi+FVVDY OzBA== X-Gm-Message-State: AOAM531Ofl0GlgfvBJz1ndJ/kZoBP9DhzQnMZiC9cDgz7wFvFfgwByQ+ 0NqWeOfQ8pbneOb2HtfzfdGMzq9tVu08JJ5L2i8= X-Google-Smtp-Source: ABdhPJwsVYjIUFDqStSxmLeJGLh5Lx+N1AHKskewijdfWJXst82JALshwRFq8IwlWIaHCntzrsD6J5SElzxmLvCE1LU= X-Received: by 2002:a5d:4c4b:: with SMTP id n11mr15062656wrt.381.1591980915561; Fri, 12 Jun 2020 09:55:15 -0700 (PDT) MIME-Version: 1.0 References: <20200531043747.GN58497@kduck.mit.edu> <51d9eeac-8d54-0bbe-00f8-1e34b2f6271b@free.fr> In-Reply-To: <51d9eeac-8d54-0bbe-00f8-1e34b2f6271b@free.fr> From: Nat Sakimura Date: Sat, 13 Jun 2020 01:55:04 +0900 Message-ID: To: Denis Cc: Benjamin Kaduk , oauth Content-Type: multipart/alternative; boundary="000000000000f617e405a7e5f087" Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request)) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:55:22 -0000 --000000000000f617e405a7e5f087 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My take is that the basic assumption of OAuth 2.0 Framework is that there is a strong relationship between AS and RS. I feel that it is quite unrealistic that an RS would trust the access token issued by an AS that it has no strong relationship with. Your scenario is more like in the case where a user was authenticated at an IdP, gets an assertion and go to the AS of the RS domain to get the token for the RS to access it. Also, you assume that the response to a tampered request comes back to the honest client. That may not be the case. The response to the tampered authorization request may go to the attacker's client. So, the comparison approach does not work. Best, Nat Sakimura On Tue, Jun 2, 2020 at 5:27 PM Denis wrote: > Hi Benjamin and Aaron, > > Note: This is also a reply to Aaron who wrote: > > Typically in OAuth it's the authorization server's job to inform users an= d > protect access to their resources. > Obviously in order to do that the AS must know about the details of the > request. > > Can you please clarify the scenario in which you would want the AS to hav= e > no information about the request that it's authorizing? > > The start of the answer comes from the text that was inserted in my first > email of this thread, which is copied again below: > > OAuth initially assumed a static relationship between clients, > authorization servers and resource servers. > > The original model for OAuth was making the assumption that the AS and th= e > RS had a strong bilateral relationship. > > *A key question is whether such strong relationship will be maintained fo= r > ever * or > whether it will be allowed to perform some evolutions of this relationshi= p > . > > In order to respect the privacy of the users, there is the need to > encompass other scenarios. One of these scenarios is > that the AS and the RS do not need any longer to have such a strong > relationship. In terms of trust relationships, a RS > simply needs to trust the access tokens issued by an AS. The AS does have > any more a "need to know" of all the RSs > that are accepting its access tokens. This would be a major simplificatio= n > of the current global architecture. > > oauth-security-topics states: > > The privileges associated with an access token SHOULD be restricted to > the minimum required for the particular > application or use case. > > This means that the client should be able to select *by itself * the > claims it would like to be placed into an access token > with respect to the operations it is willing to perform on a RS. > > As long as only the scope request parameter will be usable in an access > token request to select the claims to be placed > into an access token, it will not be possible to remove this strong > relationship. > > *1=C2=B0 About d**raft-ietf-oauth-rar-01* > > In draft-ietf-oauth-rar-01, it is acknowledged that the parameter "scope" > that allows OAuth clients to specify the requested scope > is not sufficient to specify fine-grained authorization requirements. > > If the OAuth WG believes that the AS and the RS relationship are not > necessarily any more *bilateral *but may also be *unilateral*, > i.e. an AS may be trusted by several RS, but the ASs do not need to know = *in > advance* the RSs, then some evolutions are possible > as explained below. > > A RS must know which attributes from a client are necessary in order to > accomplish a given operation. After being informed by the RS > of which attributes are necessary in order to accomplish a given > operation, a client may request these attributes to any AS that is > trusted > by the RS for these types of attributes. If the client also has a trust > relationship with one or more of these AS, then it may proceed. > > For example, a RS may request three attributes to an AS: a "sub" claim > which is a value locally unique in the context of the AS > or that is globally unique, a home address and an indicator stating > whether the user is over 21 years old. If the client finds these three > attributes > as being acceptable for the kind of operation it is willing to perform on > the RS, then it may request these three attributes to one or more > appropriate ASs. > > In this way, the AS does not know which operation(s) will be performed on > an AS. Hence, there is no need to define JSON objects > with "type" fields such as "account_information" and "payment_initiation" > as given as examples in draft-ietf-oauth-rar-01. > > However, JSON objects able to indicate e.g. a pseudonym, a home address, = a > family name, a first name, etc ... should be defined. > > To respond to Aaron, the AS does not need to know the details of the > operations that will be performed by a client on a RS but only needs to > provide > the attributes that are being requested by the client. The job of the RSs > is to inform its clients about which attributes are necessary in order to > perform > a given operation and to indicate which ASs are trusted to provide these > attributes. > > This does not mean that all this information shall necessarily be made > publicly available: it may only be available to authenticated clients > at the time they are willing to perform a given operation. > > ASs do not need to know (and hence to control) which attributes are > necessary to perform *every* operation on *every* RS. > Unilateral relationships would make the whole architecture more scalable. > > > *2=C2=B0 About draft-ietf-oauth-jwsreq-22 * > > draft-ietf-oauth-jwsreq-22 introduces the ability to send request > parameters in a JSON Web Token (JWT) which allows the request to be signe= d > with JSON Web Signature (JWS) (...) so that the integrity [and] source > authentication (...) property of the Authorization Request is attained. > > It should be realized that a simpler mechanism could be used in some > cases: integrity "protection" of a message is in fact the "detection" of > the integrity > of a message by a receiver. It is possible to *detect *that the *request = *has > been modified by observing the *response*, i.e. the content of the JWT. > Let us assume > that no cryptographic mechanism is used in the request, then when a clien= t > receives a JWT, *if it may verify its content*, it may then know whether > or not > the request parameters have been modified while in transit. For example, > if a client requested a pseudonym claim, a home address claim, a family > name > claim and a first name claim to be present in the JWT, unless an error is > reported, it can verify that these claims are indeed present in the JWT. > > This is another reason why a client should be able to inspect the content= of the access token. > > Denis > > On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote: > > As indicated in the abstract: > > "This document introduces the ability to send request parameters in > a JSON Web Token (JWT) instead, > which allows the request to be signed with JSON Web Signature (JWS= )". > > This approach has a major consequence which is not indicated in the > "Privacy Considerations section: > the AS will have the knowledge of these request parameters such as > "please let me make a payment with the amount of 45 Euros" > or "please give me read access to folder A and write access to file X". > > Such an approach has privacy issues which are currently not documented > in the Privacy Considerations section. > > The AS would be in a position to know, not only which resources servers > are going to be accessed, but also what kind of operations > are going to be performed by its clients on the resource servers. With > such an approach, ASs will have a deep knowledge of every > operation that can be performed by a user on every RS. > > As a consequence, the AS would also be in a position to trace the > actions performed by its users on the resources servers. > > Other approaches that are more "privacy friendly" should be considered > to address the initial problem. > > Do you have the start of a list of such other approaches to seed the > discussion? There seemms to be some inherent tension between the > authorization server knowing what it is authorizing and the privacy > properties you are advocating... > > Thanks, > > Ben > > > _______________________________________________ > 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 --000000000000f617e405a7e5f087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My take is that the basic assumption of OAuth 2.0 Framewor= k is that there is a strong relationship between AS and RS.=C2=A0
I fee= l that it is quite unrealistic=C2=A0that an RS would trust the access token= issued by an AS that it has no strong relationship with.=C2=A0
Y= our scenario=C2=A0is more like in the case where a user was authenticated a= t an IdP, gets an assertion and go to the AS of the RS domain to get the to= ken for the RS to access it.=C2=A0

Also, you assum= e that the response to a tampered request comes back to the honest client. = That may not be the case.=C2=A0
The response to the tampered auth= orization request may go to the attacker's client. So, the comparison a= pproach does not work.=C2=A0

Best,=C2=A0

Nat Sakimura

On Tue, Jun 2, 2020 at 5:27 PM Denis <= denis.ietf@free.fr> wrote:
=
=20 =20 =20
Hi Benjamin and Aaron,

Note: This is also a reply to Aaron who wrote:
Typically in OAu= th it's the authorization server's job to inform users and protect access to their resources.
Obviously in order to do that the AS must know about the details of the request.

Can you please c= larify the scenario in which you would want the AS to have no information about the request that it's authorizing?
The start of the a= nswer comes from the text that was inserted in my first email of this thread, which is copied again below:
OAuth = initially assumed a static relationship between clients, authorization servers and resource servers.

The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship.

A key question is whether such strong relationship will be maintained for ever or
whether it will be allowed to perform some evolutions of this = relationship.

In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is
that the AS and the RS do not need any longer to have such a strong relationship. In terms of trust relationships, a RS
simply needs to trust the access tokens issued by an AS. The AS does have any more a "need to know" of all t= he RSs
that are accepting its access tokens. This would be a major simplification of the current global architecture.

oauth-security-topics states:

=C2=A0 The privileg= es associated with an access token SHOULD be restricted to the minimum required for the particular
=C2=A0 application or use case.

This means that the client should be able to select by itself the claims it would like to be placed into an access token
with respect to the operations it is willing to perform on a RS.

As long as only the scope request parameter will be usable in an access token request to select the claims to be placed
into an access token, it will not be possible to remove this strong relationship.

1=C2=B0 About draft-ietf-oauth-rar-01=

I= n draft-ietf-oauth-rar-01, it is acknowledged that the parameter "scope&q= uot; that allows OAuth clients to specify the requested scope
is not sufficient to specify fine-grained authorization requirements.

If the OAuth WG believes that the AS and the RS relationship are not necessarily any more bilateral but may also be unilateral,
i.e. an AS may be trusted by several RS, but the ASs do not need to know in advance the RSs, then some evolutions are possible
as explained below.

A RS must know which attributes from a client are necessary in order to accomplish a given operation.<= span style=3D"font-family:Arial" lang=3D"EN-US"> After being informed by th= e RS
of which attributes are necessary= in order to accomplish a given operation, a client may request these attributes to any AS that is trusted
by the RS for these types of attributes. If the client also has a trust relationship with one or more of these AS, then it may proceed.

For example, a=C2=A0 RS may request three attributes to an AS: a "sub" claim which is a value locally unique in the context of the AS
or that is globally unique, a home address and an indicator stating whether the user is over 21 years old. If the client finds these three attributes
as being acceptable for the kind of operation it is willing to perform on the RS, then it may request these three attributes to one or more
appropriate ASs.

In this way, the AS d= oes not know which operation(s) will be performed on an AS. Hence, there is no need to define JSON objects
with "type" fields such as "account_informatio= n" and "payment_initiation" as given as examples in draft-ietf-oauth-rar-01.

However, JSON objects= able to indicate e.g. a pseudonym, a home address, a family name, a first name, etc ... should be defined.

To respond to Aaron, = the AS does not need to know the details of the operations that will be performed by a client on a RS but only needs to provide
the attributes that are being requested by the client. The job of the RSs is to inform its clients about which attributes are necessary in order to perform
a given operation and to indicate which ASs are trusted to provide these attributes.

= This does not mean that all this information shall necessarily be made publicly available: it may only be available to authenticated clients
at the time they are willing to perform a given operation.

= ASs do not nee= d to know (and henc= e to control) which attributes are necessary to perform every operation on every RS.
Unilateral relationships would make the whole architecture more scalable.


= 2=C2=B0 About draft-ietf-oauth-jwsreq-22

= draft-ietf-oau= th-jwsreq-22 introduces the ability to send request parameters in a JSON Web Token (JWT) which allows the request to be signed
with JSON Web Signature (JWS) (...) so that the integrity [and] source authentication (...) property of the Authorization Request is attained.=

= It should be r= ealized that a simpler mechanism could be used in some cases: integrity "protection" of a message is in fact the &quo= t;detection" of the integrity
of a message by a receiver. It is possible to detect that the request has been modified by observing the response, i.e. the content of the JWT. Let us assume
that no cryptographic mechanism is used in the request, then when a client receives a JWT, if it may verify its content, it may then know whether or not
the request parameters have been modified while in transit. For example, if a client requested a pseudonym claim, a home address claim, a family name
claim and a first name claim to be present in the JWT, unless an error is reported, it can = verify that these claims are indeed present in the JWT. 

This is another reason why a client shoul=
d be able to inspect the content of the access token.
Denis

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:

As indicated in the abstract:

    "This document introduces the ability to send request parameters i=
n
    a JSON Web Token (JWT) instead,
     =C2=A0 which allows the request to be signed with JSON Web Signature (=
JWS)".

This approach has a major consequence which is not indicated in the=20
"Privacy Considerations section:
the AS will have the knowledge of these request parameters such as=20
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X&=
quot;.

Such an approach has privacy issues which are currently not documented=20
in the Privacy Considerations section.

The AS would be in a position to know, not only which resources servers=20
are going to be accessed, but also what kind of operations
are going to be performed by its clients on the resource servers. With=20
such an approach, ASs will have a deep knowledge of every
operation that can be performed by a user on every RS.

As a consequence, the AS would also be in a position to trace the=20
actions performed by its users on the resources servers.

Other approaches that are more "privacy friendly" should be consi=
dered=20
to address the initial problem.

Do you have the start of a list of such other approaches to seed=
 the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben


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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--000000000000f617e405a7e5f087-- From nobody Fri Jun 12 09:57:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78BB3A114B for ; Fri, 12 Jun 2020 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szfjy4oHhRUD for ; Fri, 12 Jun 2020 09:57:46 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E903A1147 for ; Fri, 12 Jun 2020 09:57:45 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id f185so8921592wmf.3 for ; Fri, 12 Jun 2020 09:57: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 :cc; bh=xwJbBUkmEP3B8K85PG8+nbgVNP0rp1FvqDs3JyCqs0M=; b=d9HPgcoFwEquQ2wWlouZV4ZDopmLghUqa+L11gEMuZoqu3XVMe6ulGH5cwQe2Q7m/B jAlok/E63ksEBkEzv/iYK21vDUfrn+eOjs8vx8bTrrT2AEJSrXCejCYugL4hOS6szXKV fpBkVJJGnLg466B/LNZhA/jH1VQgDfEeplxWxx915hp2/GPr1lFnj9Zxg+7WIE8Wgakb LCyx4jlMBUg2dwrJlmX5nG//nAT1tEIw44R2XiEcJiBb7XjXGyQXLCjV+I1hRcLUqQg/ pWQVESc2Zzb/IeCGTasfMZFO2/4K9JahYVHINooOzwOzp+dU7q+GdD/MMTrCp/M1y+rl +Zxw== 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=xwJbBUkmEP3B8K85PG8+nbgVNP0rp1FvqDs3JyCqs0M=; b=q2SMoCMpayyrCLTSHHqh2r2jK1XNamIUAVdZ5SP/W5LRAZTn2LCsAne1OAcYZcIaT0 GSfpah86DmVT5iBYsEw13WSa9Lp3DjyIgE4DLCBb5ZeYXnuVUxP6mGdDmAprLd3eEOfk X4SA82vMvHETOpV6zMG/JkFRjvBDev0t7knK8jtl2b+wQkTGyCpHr0X4zDVbuk3w7Tjw tZj3zvxIpWvoG2NlSTFnP4Q8IzL+QVEWKy7Sf47q/OZ/3IK7SRoNXSx1HWM5vG6/Zakg pypIls+YiVRUuIAio1TZ7xjp1AbS8bm3ZjMlLk0wfw/dOjgvtOSnDumwKaiCehrHCY2A 8Cvg== X-Gm-Message-State: AOAM5308tNS+MvVDv2Umsv8DCxEPfhNWCxB81bobiiION/gzaQKtGWVi omtCwepT3+sq7lR33pYl0E6nRxEDkbaMrE+cTb2IJReW X-Google-Smtp-Source: ABdhPJwGfTaaSp+mYqfIV/EWmY180ZosJTxnk58A72OO25lKC2K01gFejGQMxmQb1RzNMW/DlxJwB8vXEUKXw5o4P90= X-Received: by 2002:a05:600c:4152:: with SMTP id h18mr15097553wmm.189.1591981063839; Fri, 12 Jun 2020 09:57:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Sat, 13 Jun 2020 01:57:32 +0900 Message-ID: To: Dominick Baier Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cca6de05a7e5f9cd" Archived-At: Subject: Re: [OAUTH-WG] To the authors of jwsreq/JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:57:48 -0000 --000000000000cca6de05a7e5f9cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late reply. I and John were really busy lately partly due to COVID-19 thing and could not respond in a timely fashion. I just replied to one of the thread that you posed a question about. Is that the question you mentioned in this email? Best, Nat Sakimura On Sun, May 31, 2020 at 5:22 PM Dominick Baier wrote: > Hi, > > We had asked a couple of questions over the last weeks regarding details > of the JAR spec. Not a single response from the spec authors. > > We are in the process of implementing JAR and about to release the > software. > > We need some clarifications and I am confused that we did not get any > response. Is it a technical issue? > > thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > _______________________________________________ > 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 --000000000000cca6de05a7e5f9cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Thibault Normand
"Il existe moins bien mais c'e= st plus cher !"
http://www.zenithar.org
--00000000000093225605a8e53240-- From nobody Thu Jun 25 03:28:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247CE3A0909 for ; Thu, 25 Jun 2020 03:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kql7fbjjKlkx for ; Thu, 25 Jun 2020 03:28:07 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495983A0893 for ; Thu, 25 Jun 2020 03:28:07 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id k1so3671747ils.2 for ; Thu, 25 Jun 2020 03:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=NZ5Uz2faVblxGn+SsxS8YEq6TsKIB4E9uD97fpQLOus=; b=uHqbtG103oPq75pjbA+SGTd66mYEqH0IIHPG7LXUxXE6FGR79szeSOFcRlKJEhxew6 An4p8I0NPrZQZvsFvnWaJB/k9ys8XcT4flsEdyU2swAnDtkt/2aZQwckOfOrE1ugq5Gn vQZtoQfC/PUaGdaWgmIuqkArb2xDPOEGBTpTXUMPiKyr58xdGvtTM/ww5zMfQdiOBtau 874DoBVmoCdNqufRugKqcga4IQ8vuEi1ziW1Ok5SJb3oDbne/im2ZpSjxbG4591+eiid ZgV55W7O+MfWT67QmhhyemCurh4F/tKCeEDLmydhbI59w4Yga3dZlTcfYHiz4fbrUe0L SMPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=NZ5Uz2faVblxGn+SsxS8YEq6TsKIB4E9uD97fpQLOus=; b=XJfO6NlAxwcfur9xKlBKeS/1ZM2tWtJuFUlWltVrANB9XGdYUVXsYvw4JotzaxZrCn OSILGQs9TRENn8STUTxIllLVgyo+Eba/rpDe9voi/4WQpU84G0dimb9/4mGy0OdwrO9s hpiE/kjgfd5DmmZFpZ+Dj8WWER3bW8dgCsMahtACKzCdLHzdRzE1sbBnC9cBLy585xS+ HM2A4Q6S8U/F4tTaBan3hmNueNTbb16/7Spt8eQfUzKa3qh26WY0ENuOPDjcrgJ48B6P 6Ubn0GLSWcxcbTipirTRRqnbD58iATOdWRvLFvMSK1TLYUJTXm2qoA22lItaO9eGJK6W 3tvQ== X-Gm-Message-State: AOAM532DeUAu81mLRqL80L34ivW6V6X3DJTpbl/X4Lg+rwk1+rbrfNHx 26IWNpYepq469D+9AemNAH/iHsFcL+qjUdOP6ZIYieA= X-Google-Smtp-Source: ABdhPJx2CBSkHJ3PEH4zB07HTsXXzPqAX7RWSZL5MUi45goZFLGPrTBjwjfd8JTTe7YcLTHgfaI9SUumF4vZ/HiSWRw= X-Received: by 2002:a92:da46:: with SMTP id p6mr15752849ilq.48.1593080885891; Thu, 25 Jun 2020 03:28:05 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jun 2020 03:28:05 -0700 From: Dominick Baier In-Reply-To: References: <1592833863766.52147@kuleuven.be> <33E98F20-6AF6-4A4D-A626-B9C4DA7C64C9@gmail.com> MIME-Version: 1.0 Date: Thu, 25 Jun 2020 03:28:05 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d69d005a8e60c1d" Archived-At: Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Jun 2020 10:28:09 -0000 --0000000000004d69d005a8e60c1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Have a look at https://github.com/IdentityServer/IdentityServer4 I t=E2=80=99s an OIDC ce= rtified .NET implementation Thanks! =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 25. June 2020 at 11:27:34, Thibault Normand (thibault.normand@gmail.com) wrote: Hello Pieter, I'm also interested (https://github.com/zntrio/solid), my OIDC framework is not focused on building a compliant OIDC server but produce a restricted and harmonized feature set according to your authentication use cases (human, act as human, software, machine, iot). It mostly like libsodium is (a high-level api) for low-level encryption operations (CHACHA20/Poly130). The project is quite new and focused on authorization server building blocks without the wire protocol constraints. I tried to design flow without the wire protocol constraints in order to make the building blocks useable in different context (standard / HTTP, or IoT / CoAP). Regards, Le lun. 22 juin 2020 =C3=A0 17:25, Filip Skokan a =C3= =A9crit : > Hello Pieter, > > I=E2=80=99m interested for my open source project. > > Filip > > Odesl=C3=A1no z iPhonu > > 22. 6. 2020 v 15:51, Pieter Philippaerts >: > > =EF=BB=BF > Hello everyone, > > As part of a research project, I've created a test suite to test OAuth 2.= 0 > implementations and measure how well they implement the various > MAY/SHOULD/MUST security recommendations in the OAuth standards. (It also > includes test cases for the OIDC and FAPI RO/RW recommendations.) The too= l > is practically finished and will be made available to the public in a few > months. > > I'm currently working on a security analysis of the OAuth2 ecosystem > (i..e. I'm using the tool to test various OAuth/OIDC implementations) and > I'm still looking for more candidates to test. If you are the author of a= n > OAuth library or if you are running an OAuth service, feel free to contac= t > me to get involved. Apart from my gratitude, I can offer you a free > security audit of your product :-) > > Regards, > Pieter > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thibault Normand "Il existe moins bien mais c'est plus cher !" http://www.zenithar.org _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000004d69d005a8e60c1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hey,= =C2=A0

<= /div>

It=E2=80=99s an OIDC certified .NET implementation

Thanks!
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 25. June 2020 at 11:27:34, Thibault Norman= d (thibault.normand@gmail.com= ) wrote:

Hello Pieter,

= I'm also interested (https:= //github.com/zntrio/solid), my OIDC framework is not focused on buildin= g a compliant OIDC server but produce a restricted and harmonized feature s= et according to your authentication use cases (human, act as human, softwar= e, machine, iot). It mostly like libsodium is (a high-level api) for low-le= vel encryption operations (CHACHA20/Poly130).

The = project is quite new and focused on authorization server building blocks wi= thout the wire protocol constraints.
I tried to design flow witho= ut the wire protocol constraints in order to make the building blocks useab= le in different context (standard / HTTP, or IoT / CoAP).

Regards,

Le=C2=A0lun. 22 juin 2020 =C3=A0=C2=A017:25, Fili= p Skokan <panva.ip@gmail.com&g= t; a =C3=A9crit=C2=A0:
Hello Pieter,=C2=A0

I=E2=80=99m= interested for my open source project.=C2=A0

Fili= p

Odesl=C3=A1no z=C2=A0iPhonu

22. 6. 2020 v=C2=A015:51, Pieter Philippaert= s <= pieter.philippaerts@kuleuven.be>:

=EF=BB=BF
Hello everyone,

As part of a research project, I've created a test=C2=A0suite to t= est OAuth 2.0 implementations and measure how well they implement the vario= us MAY/SHOULD/MUST security recommendations in the OAuth standards. (It als= o includes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made = available to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosyst= em (i..e. I'm using the tool to test various OAuth/OIDC implementations= ) and I'm still looking for more candidates to test. If you are the aut= hor of an OAuth library or if you are running an OAuth service, feel free to contact me to get involved. Apart from my g= ratitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


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


--
Thibault Normand
"Il existe moins bien mais c'e= st plus cher !"
http://www.zenithar.org
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--0000000000004d69d005a8e60c1d-- From nobody Tue Jun 30 00:25:29 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437703A0D91 for ; Tue, 30 Jun 2020 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_FINANCIALSOLUTION=1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.148, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc7We2Bnm0PV for ; Tue, 30 Jun 2020 00:25:27 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5AF3A0B45 for ; Tue, 30 Jun 2020 00:25:26 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id d13so9609202ybk.8 for ; Tue, 30 Jun 2020 00:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=ldz/q4rpIuyolwS/HimEYNdluIZSVwU43cNVDL8+spM=; b=aLUBo7AqsbjbjUx/fGHS4YV+QBHGL5ePAxLZQ2b8R/a0snJ9unqbFlxpxN7+rHPeMy /jZjKmIT0/d3y2NBVlsQjtZicZv/f5kotjZJkoHC2x8BeUEqtNLP+MeQAm2vXAeoMrjZ QRXpHH+cZzN/XWKb5JkOJMxiyopK/b1p32ooI= 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=ldz/q4rpIuyolwS/HimEYNdluIZSVwU43cNVDL8+spM=; b=swD4jAqwI+urBRfWuJ6a1Qeocr1jbAISdiGmn4DeOu3XDvswXN5iOUd7IsjHhzgriI CiecK3uQLavz4A24vwVPQ9ogtyIN6vgJaRErdkFclQ97ORRjQ3g5nSnsH1WZ+o1MyVJe TKAOybXG+WgvVvm41ZHSo8oGr/BZUE7Cm6vxfFRbindwLPkJWoKv+iNtsTnN+PIYnm4C DuAXOUPZEoK9g0vEEukkKaUStq65DNMtb57d4wpt2k5txD/cMf34CRZ1XY5hMl5smcNI 8a2yDyJ4UgDJvOvLFClVIclpVcL22phGCx3o/xyj8JZnso0jNZPr6EFlqZWyTDznYtsZ yslA== X-Gm-Message-State: AOAM530j87qrE8CDqaWkYhOAY/Byrjj6NutZxi4/i3Zb8oOa7/CFR8Vx pXSKdSYyJfG3Hhu2LJABGZx7w4s2ho+iZa8S8Hgr29sWj5A= X-Google-Smtp-Source: ABdhPJwlrQVRVchLEmzIQDOu2jARS9dHI5hD4uq91rTOulVLpY5XFxTURASeLNum31B2x8aULGHN7ieG5RBpQLx5uIA= X-Received: by 2002:a25:1941:: with SMTP id 62mr35408698ybz.16.1593501925379; Tue, 30 Jun 2020 00:25:25 -0700 (PDT) MIME-Version: 1.0 From: Thiloshon Nagarajah Date: Tue, 30 Jun 2020 12:55:14 +0530 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000362c2205a94814b5" Archived-At: Subject: [OAUTH-WG] client_id in PAR and JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:25:28 -0000 --000000000000362c2205a94814b5 Content-Type: text/plain; charset="UTF-8" Hi All, In OAuth JAR specification, client_id is a required query parameter of authorisation call, in both *request* and *request_uri* flows [ https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section-5]. But in OAuth PAR specification, which is a complimentary spec to JAR, it is specified "Clients are encouraged to use the request URI as the only parameter (in the authorisation call) in order to use the integrity and authenticity provided by the pushed authorization request." [ https://tools.ietf.org/html/draft-ietf-oauth-par-01#section-4] Taking into account these both are building upon OAuth spec, which also mandates client_id query param in authorisation call, it seems like PAR is not compatible with OAuth and JAR specs. Is this intentional? If it is may I know the rationale behind this decision? Regards, -- Thiloshon Nagarajah Software Engineer, Financial Solutions WSO2 +94774209947 --000000000000362c2205a94814b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

In OAuth JAR specific= ation, client_id is a required query parame= ter of authorisation call, in both request and request_uri fl= ows [https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section-5= ].

But in OAuth PAR specification, which is a comp= limentary spec to JAR, it is specified "Clien= ts are encouraged to use the request URI a= s the only parameter=C2=A0(in the= =C2=A0authorisation call)=C2=A0in order to = use the integrity and authenticity provided by the pushed authorization req= uest." [https://tools.ietf.org/html/draft-ietf-oauth-par-01#sect= ion-4]

Taking into account these both are= building upon OAuth spec, which also mandates cli= ent_id query param in authorisation=C2=A0call, it seems like PAR is = not compatible with OAuth and JAR specs.=C2=A0

Is = this intentional? If it is may I know the rationale behind this decision?= =C2=A0

Regards,
--
Thiloshon Nagarajah
Software Engi= neer,
Financial Solutions
WSO2
+94774209947
--000000000000362c2205a94814b5-- From nobody Tue Jun 30 00:39:35 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17D3A08CF for ; Tue, 30 Jun 2020 00:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_FINANCIALSOLUTION=1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbjGNDUZJbNJ for ; Tue, 30 Jun 2020 00:39:33 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041453A0889 for ; Tue, 30 Jun 2020 00:39:33 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id dm19so8960120edb.13 for ; Tue, 30 Jun 2020 00:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bc1orOES0ldas8Fz8EJUptNhS7UPhhJog+sA4Ua4sC0=; b=LADZhrfBia5J/oJT7dUsinY4sibTT6kadepY7bwZenBYXeEaALwPmFVq1Fmu5TnEFQ MjiqhK2bYB1IUFMo/umycc8p2R1BP4eXKArR9BAGvs7tYno6E2jG3NAyjpx9f+GoIyPi 5Dv8vMZIQbgt6baIQl7j8FNizsIK06XGIrPKIk4oHuJYW5ZBy5d+pHFvrVqb8sgVxkif OrRf2p+u0V1RHrptVAYUU+JgLWMgzKVP0yABwe4YI99AAMRI1ljY3iG5Vsh6Ch4Q47no nJ/+KaH/Lkzjn41oDEsqURwSYsW0sgNcYNjb5uLxN/d/zU5SYG8QNToTHjxCuxWDGEsq EPzA== 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=bc1orOES0ldas8Fz8EJUptNhS7UPhhJog+sA4Ua4sC0=; b=lwr1y2J/DgngJUiRVX1EfswR0elnv3+8fDH1HgHmLQ0MB3zBvGMbsDXJv/hKZ9u9nD +CNdVNzyoghtJ8XH4VL9k1jiloEAI+lvhclHdiMxiq7MObO9rf2QTKK4CS5+3H7kQ5ho BJWLoYxrGnz/nU/YLAPg9T4i8cFZo+WicvVLGI+uEds/Q710eujHljm7PZv3jhAARpXW uyicAbtS97eodyGmjIGDR+vFxSZ7oYvsVGd+ls08htE9yxrWoawArVJxLT/I6FPHAGWu frISC2WqsH1FvXXe7kTfKOZfNzTRngCtiUnua/Dm2gzYTentet7Gc9+sgBAhwiblDh2V UFaA== X-Gm-Message-State: AOAM533r2kwXJmv5npHN69MzpJZF07GpIzk8l5I02TcNDh5uzWI+Jl+U fdUdZhhpgyibjJDa5BhgmZlkWM+pJw== X-Google-Smtp-Source: ABdhPJxOV4M1Fkie+rMNlTjO7ywDiL5P8luT6lbXkn4ql2JOPjVZRlW6J913B4o3L6z8hgJxDixgYQ== X-Received: by 2002:a05:6402:1b94:: with SMTP id cc20mr21182015edb.177.1593502771239; Tue, 30 Jun 2020 00:39:31 -0700 (PDT) Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id d23sm1359160eja.27.2020.06.30.00.39.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 00:39:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B3AB47AA-B506-41FB-AF13-93B088382792 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Tue, 30 Jun 2020 09:39:29 +0200 Message-Id: References: Cc: oauth@ietf.org In-Reply-To: To: Thiloshon Nagarajah X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] client_id in PAR and JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:39:35 -0000 --Apple-Mail-B3AB47AA-B506-41FB-AF13-93B088382792 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thiloshon, Not quite the way it went down but we have this adressed in a future PAR dra= ft.=20 Thank you ;) Filip Odesl=C3=A1no z iPhonu > 30. 6. 2020 v 9:25, Thiloshon Nagarajah : >=20 > =EF=BB=BF > Hi All, >=20 > In OAuth JAR specification, client_id is a required query parameter of aut= horisation call, in both request and request_uri flows [https://tools.ietf.o= rg/html/draft-ietf-oauth-jwsreq-23#section-5]. >=20 > But in OAuth PAR specification, which is a complimentary spec to JAR, it i= s specified "Clients are encouraged to use the request URI as the only param= eter (in the authorisation call) in order to use the integrity and authentic= ity provided by the pushed authorization request." [https://tools.ietf.org/h= tml/draft-ietf-oauth-par-01#section-4] >=20 > Taking into account these both are building upon OAuth spec, which also ma= ndates client_id query param in authorisation call, it seems like PAR is not= compatible with OAuth and JAR specs.=20 >=20 > Is this intentional? If it is may I know the rationale behind this decisio= n?=20 >=20 > Regards, > --=20 > Thiloshon Nagarajah > Software Engineer, > Financial Solutions > WSO2 > +94774209947 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B3AB47AA-B506-41FB-AF13-93B088382792 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thiloshon,

Not quite t= he way it went down but we have this adressed in a future PAR draft. 

Thank you ;)

Filip

<= div dir=3D"ltr">Odesl=C3=A1no z iPhonu

30. 6. 2020 v 9:25, Thiloshon Nagarajah <thilosh= on=3D40wso2.com@dmarc.ietf.org>:

=EF=BB=BF
Hi All,
=
In OAuth JAR specification, client_i= d is a required query parameter of authorisation call, in both req= uest and request_uri flows [https://tools.ietf.org/html/draft-ie= tf-oauth-jwsreq-23#section-5].

But in OAuth PAR= specification, which is a complimentary spec to JAR, it is specified "Clients are encouraged to use the request URI as the only parameter (in the authorisation call) in order to use the integrity and authenticity provided by the pushe= d authorization request." [https://tools.ietf.org/html/draft-ietf-oauth= -par-01#section-4]

Taking into account the= se both are building upon OAuth spec, which also mandates client_id query param in authorisation call, it seems lik= e PAR is not compatible with OAuth and JAR specs. 

=
Is this intentional? If it is may I know the rationale behind this deci= sion? 

Regards,
--
Thiloshon Nagarajah
Software E= ngineer,
Financial Solutions
WSO2
+94774209947=

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-B3AB47AA-B506-41FB-AF13-93B088382792-- From nobody Tue Jun 30 01:15:36 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4C3A10E0 for ; Tue, 30 Jun 2020 01:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_FINANCIALSOLUTION=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txBlWM3pCD2I for ; Tue, 30 Jun 2020 01:15:33 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454123A0F08 for ; Tue, 30 Jun 2020 01:15:32 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id e197so5653158yba.5 for ; Tue, 30 Jun 2020 01:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QQj6DMACEDwYfWSWRybk4Mp4s9193pUGOH6W/8NnuDo=; b=YhX1sfBvDyNWsa6WP1hRLIK/SzUf6J88B0ofsbcFz5sZdceW98j/hQxjRx1xYusFWG eQP/GlZ5PbrXh6zGZ2yyKnXccwTdIeeibFLvQkklDYKaI8QyOC/9A7qNzjdPE7edDFG9 Eh5loc9nXc4PdeoiMdls8EtyIOnfH7H3lbh6Q= 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=QQj6DMACEDwYfWSWRybk4Mp4s9193pUGOH6W/8NnuDo=; b=SSPjqpX5RiwLpKVZF976tPjKTs+cy0o7UcyBtkukT6jA06wyOkzW4xldxIZHsugqVg PBERUqlAWoBurcwel243zdBAQ8CpK7BEX7o9aKXqICSHeMyyA1ZFxXCTgeIeUcW2tGTs W2uH6yR1hOaujR+te+o8QcYkjGCQdrNXY4QUz7gQA+047V8jx13apXdWRUs6+5vjDGjh Ywz43otJqPf6HsTOjPPsKYxDPzIPWuPT70RqOj4Mz8NWdxc84p6bdQ24kRnV1EJUQSRd LAHR4mRvzxos1qNy33kdug3u9uIpBJ/pgTlt+qJtWFBAHK1EVv9JJrhOjkULV0LTCHCc J16Q== X-Gm-Message-State: AOAM532cCQbuLfnuf0FEi5DRdAnnzsDHMbSQ4/Kr+rhj2+iC92DGBtrh TwMGwEVEC/nRogT9wDhP61agDjrWYIg4gqcr6mFqsw== X-Google-Smtp-Source: ABdhPJxot/TV8HGHn++qgYqq2VOy0U2/5CNkHld3sMftf79sAkjm76RUFdcq0OKAx1ga4g5GxcigXmFhwrC3pxBAGOc= X-Received: by 2002:a25:37ca:: with SMTP id e193mr31638538yba.505.1593504931844; Tue, 30 Jun 2020 01:15:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thiloshon Nagarajah Date: Tue, 30 Jun 2020 13:45:21 +0530 Message-ID: To: Filip Skokan Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000692f7605a948c7ae" Archived-At: Subject: Re: [OAUTH-WG] client_id in PAR and JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:15:35 -0000 --000000000000692f7605a948c7ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Filip, So I'm assuming client_id will be mandated as a query param in PAR as well? Regards On Tue, Jun 30, 2020 at 1:09 PM Filip Skokan wrote: > Hi Thiloshon, > > Not quite the way it went down but we have this adressed in a future PAR > draft. > > Thank you ;) > > Filip > > Odesl=C3=A1no z iPhonu > > 30. 6. 2020 v 9:25, Thiloshon Nagarajah 40wso2.com@dmarc.ietf.org>: > > =EF=BB=BF > Hi All, > > In OAuth JAR specification, client_id is a required query parameter of > authorisation call, in both *request* and *request_uri* flows [ > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section-5]. > > But in OAuth PAR specification, which is a complimentary spec to JAR, it > is specified "Clients are encouraged to use the request URI as the only > parameter (in the authorisation call) in order to use the integrity and > authenticity provided by the pushed authorization request." [ > https://tools.ietf.org/html/draft-ietf-oauth-par-01#section-4] > > Taking into account these both are building upon OAuth spec, which also > mandates client_id query param in authorisation call, it seems like PAR > is not compatible with OAuth and JAR specs. > > Is this intentional? If it is may I know the rationale behind this > decision? > > Regards, > -- > Thiloshon Nagarajah > Software Engineer, > Financial Solutions > WSO2 > +94774209947 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thiloshon Nagarajah Software Engineer, Financial Solutions WSO2 +94774209947 --000000000000692f7605a948c7ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Filip,

So I'm assuming=C2= =A0client_id will be mandated as a query param in PAR as well?
Regards=C2=A0

On Tue, Jun 30, 2020 at 1:09 PM Filip Skoka= n <panva.ip@gmail.com> wrot= e:
Hi Thiloshon,

Not quite the way it went down but we= have this adressed in a future PAR draft.=C2=A0

T= hank you ;)

Filip

Odesl=C3= =A1no z=C2=A0iPhonu

30.= 6. 2020 v=C2=A09:25, Thiloshon Nagarajah <thiloshon=3D40wso2.com@dmarc.ietf.org= >:

= =EF=BB=BF
Hi All,

In OAuth JAR= specification, client_id is a required que= ry parameter of authorisation call, in both request and request_u= ri flows [https://tools.ietf.org/html/draft-ietf-oa= uth-jwsreq-23#section-5].

But in OAuth PAR spe= cification, which is a complimentary spec to JAR, it is specified "Clients are encouraged to use the request URI = as the only parameter=C2=A0(in the=C2=A0authorisation call)=C2=A0in order to use the integrity and authenticity provided by the= pushed authorization request." [https://tools= .ietf.org/html/draft-ietf-oauth-par-01#section-4]

Taking into account these both are building upon OAuth spec, which= also mandates client_id query param in aut= horisation=C2=A0call, it seems like PAR is not compatible with OAuth and JA= R specs.=C2=A0

Is this intentional? If it is may I= know the rationale behind this decision?=C2=A0

Re= gards,
--
Thiloshon NagarajahSoftware Engineer,
Financial Solutions
WSO2
+94774209947

_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
<= br clear=3D"all">

--
Thiloshon Nagarajah
Software Engineer,
Financial Solutions
WSO2
+94774209947

--000000000000692f7605a948c7ae-- From nobody Tue Jun 30 03:02:00 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072AA3A115E for ; Tue, 30 Jun 2020 03:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_FINANCIALSOLUTION=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmxw47Np5RPq for ; Tue, 30 Jun 2020 03:01:57 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073143A115B for ; Tue, 30 Jun 2020 03:01:57 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id dm19so9335282edb.13 for ; Tue, 30 Jun 2020 03:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=fUgVd07ywz5HWNDWIBn5oYenhDOHgiZLbqgKfY/0Bxs=; b=dQnZjJq4q6Xm0JfbeCgbYgfdTayvTKGGPR/m5vijq/71UAxC8R2XKqXsG37GTIItok pJzPGYcCX72njAV45wcn15mAxGkWbmNSuLFaa2C90ye9S6FYoSfJh6Q8S121prfHObSw 59q+nsBpSVfxJwS+NhuUwLyrZImnsKClV0CGgmXNwRMoVhlqheAIYy5xIzCLIp200iVZ rGaKZb9iy14Vf9B+NieXFKum18eRxslensoI+bbO/gWpSOcdwnhxri0Z11aL15v49qKx OLx+BzmJCTmexeVnQ9ieXYaLFIYxZX+NHsjnYpfDp69tk4clVSBTYQfpJKQDtbvr5c5F ze6g== 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=fUgVd07ywz5HWNDWIBn5oYenhDOHgiZLbqgKfY/0Bxs=; b=kj14LksgrbL1pZdUbAXLfqklytmzj7XhJgzGMLY8WYIoireAvobDTK9+TyOdL4+CXl veDN1nLjICCOgbSRUYpdl5IEs2CMMRzP6El+OocE/ouMJK+6aAVa9Eb0XVuVXzG/P6j9 ZZl2ZPmuLk14h5Tl5Nve+ShHyGabVQzBIuKBFEfXaFx1Qhomy7LPIOQwh6JefJWGIq86 JjRA6H6Xde490N5+K0T8LAVY0t839el1rqaMsSFSndImH7QbdhmML2pZPAiXnvA8WVT/ kDElr1mxeNUGPKE4AvWMGPxQNgOO8FqIOHTtnOGoTzf+kpglEMHrnGs3fFRiqYPckcFU 0jNQ== X-Gm-Message-State: AOAM532e+1MLz5IXG5pCbFD0PUri9dsZ2GWHpG3vFqR+KREBvvTTICOh FcLEskgfdw6oQotQGVuVhw== X-Google-Smtp-Source: ABdhPJz9cWsiv/IHoZ6cfeyNVtZIiTQqbUHdibqu4OYOxbD6z1PmpQvtRjKiFTyZ6nKPCYNojRsmWQ== X-Received: by 2002:aa7:dad6:: with SMTP id x22mr10969634eds.310.1593511315498; Tue, 30 Jun 2020 03:01:55 -0700 (PDT) Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id k23sm1609825ejo.120.2020.06.30.03.01.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 03:01:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C0F98BB7-4DB2-4A40-A51C-8BA76EB0C1D8 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Tue, 30 Jun 2020 12:01:53 +0200 Message-Id: <3ACD016D-981D-42BE-957C-9472E68EFBA1@gmail.com> References: Cc: oauth@ietf.org In-Reply-To: To: Thiloshon Nagarajah X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] client_id in PAR and JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:01:59 -0000 --Apple-Mail-C0F98BB7-4DB2-4A40-A51C-8BA76EB0C1D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It already is in the new revision of JAR, PAR will follow it too.=20 Technically tho, since authorization requests can also use POST its not stri= ctly a query string parameter, it may be contained in the request body too. L= et=E2=80=99s call it authorization endpoint parameters and leave the =E2=80=9C= how its transferred=E2=80=9D mechanism out.=20 Odesl=C3=A1no z iPhonu > 30. 6. 2020 v 10:15, Thiloshon Nagarajah : >=20 > =EF=BB=BF > Hi Filip, >=20 > So I'm assuming client_id will be mandated as a query param in PAR as well= ? >=20 > Regards=20 >=20 >> On Tue, Jun 30, 2020 at 1:09 PM Filip Skokan wrote: >> Hi Thiloshon, >>=20 >> Not quite the way it went down but we have this adressed in a future PAR d= raft.=20 >>=20 >> Thank you ;) >>=20 >> Filip >>=20 >> Odesl=C3=A1no z iPhonu >>=20 >>> 30. 6. 2020 v 9:25, Thiloshon Nagarajah : >>>=20 >>> =EF=BB=BF >>> Hi All, >>>=20 >>> In OAuth JAR specification, client_id is a required query parameter of a= uthorisation call, in both request and request_uri flows [https://tools.ietf= .org/html/draft-ietf-oauth-jwsreq-23#section-5]. >>>=20 >>> But in OAuth PAR specification, which is a complimentary spec to JAR, it= is specified "Clients are encouraged to use the request URI as the only par= ameter (in the authorisation call) in order to use the integrity and authent= icity provided by the pushed authorization request." [https://tools.ietf.org= /html/draft-ietf-oauth-par-01#section-4] >>>=20 >>> Taking into account these both are building upon OAuth spec, which also m= andates client_id query param in authorisation call, it seems like PAR is no= t compatible with OAuth and JAR specs.=20 >>>=20 >>> Is this intentional? If it is may I know the rationale behind this decis= ion?=20 >>>=20 >>> Regards, >>> --=20 >>> Thiloshon Nagarajah >>> Software Engineer, >>> Financial Solutions >>> WSO2 >>> +94774209947 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Thiloshon Nagarajah > Software Engineer, > Financial Solutions > WSO2 > +94774209947 >=20 --Apple-Mail-C0F98BB7-4DB2-4A40-A51C-8BA76EB0C1D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable It already is in the new revision of JAR, P= AR will follow it too. 

Technically tho, since autho= rization requests can also use POST its not strictly a query string paramete= r, it may be contained in the request body too. Let=E2=80=99s call it author= ization endpoint parameters and leave the =E2=80=9Chow its transferred=E2=80= =9D mechanism out. 

Odesl=C3=A1no z iPhonu=

30. 6. 2020 v 10:1= 5, Thiloshon Nagarajah <thiloshon@wso2.com>:

=EF=BB=BF
Hi&nbs= p;Filip,

So I'm assuming client_id will be mandated a= s a query param in PAR as well?

Regards 
=

O= n Tue, Jun 30, 2020 at 1:09 PM Filip Skokan <panva.ip@gmail.com> wrote:
Hi Thiloshon,

Not quite the way it went down but we have this adressed in a future PAR dr= aft. 

Thank you ;)

Fi= lip

Odesl=C3=A1no z iPhonu

30. 6. 2020 v 9:25, Thiloshon Nagarajah= <thiloshon=3D40wso2.com@dmarc.ietf.org>:

=EF=BB=BF
<= div dir=3D"ltr">
Hi All,
In OAuth JAR specification, clien= t_id is a required query parameter of authorisation call, in both = request and request_uri flows [https://tools.i= etf.org/html/draft-ietf-oauth-jwsreq-23#section-5].

=
But in OAuth PAR specification, which is a complimentary spec to JAR, i= t is specified "Clients are encouraged to use the r= equest URI as the only parameter (in the authorisation call) in order to use the integrity and authenticity p= rovided by the pushed authorization request." [https:= //tools.ietf.org/html/draft-ietf-oauth-par-01#section-4]
=
Taking into account these both are building upon OAuth spec, w= hich also mandates client_id query param in a= uthorisation call, it seems like PAR is not compatible with OAuth and J= AR specs. 

Is this intentional? If it is may I= know the rationale behind this decision? 

Reg= ards,
--
Thiloshon Nagarajah
= Software Engineer,
Financial Solutions
WSO2
+9= 4774209947

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth


--
=
Thiloshon Nagarajah
Software Engineer,
Financ= ial Solutions
WSO2
+94774209947
<= br>
= --Apple-Mail-C0F98BB7-4DB2-4A40-A51C-8BA76EB0C1D8-- From nobody Tue Jun 30 03:53:07 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E83A1189 for ; Tue, 30 Jun 2020 03:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_FINANCIALSOLUTION=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wso2.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcjM575k1KOU for ; Tue, 30 Jun 2020 03:53:05 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065073A1187 for ; Tue, 30 Jun 2020 03:53:04 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id s1so9861480ybo.7 for ; Tue, 30 Jun 2020 03:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R5/uz5iBL2nEuuAwtMlkmX3knLFnqbqJCEta85aCP6E=; b=GsVotzQJpFUE475DLiX/8p8+1SBM7HQmjzfCMwVnqgq1yug76ny7CG2Hb1t1qDnzqP AAO6+2NKZPhGHN+/lnP3uy25rk2OUU+J3FDf0fjTuyKz182l4jP11MQFQgR3+YqP0yKi hWpsTl2Me5wEwUqd1rIrHD32WpnH9RuZz2pFo= 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=R5/uz5iBL2nEuuAwtMlkmX3knLFnqbqJCEta85aCP6E=; b=n1hovb1Rdbe0yGuYVcq9ssdqWy1eu4/BYcxDRK7nmQ5A6F4kaRZ71qmHUSoiT9jR5C KbzZmgv+1aF97ZQBkLA4ObdgpOZMmB5y7f9z3IaWxNH262mNkpHF53ksxH6Y/ESvgmOI E51CVv1EXKptUcVQSHxyxrIlsMaDZhXJ21Znrm2oMihv4uFPe8lXdj5WxdTsyclPTo1S Fl0kDx/qf7NygkxrL16u3t/Ej8tmTjKi28gX3Kp4VwYiqqZ13w3haSf7O82/btki9e7v LDipkiD67co45j7678VbIQ479VpxkqMiZWa0c+kByEMakwBG2fxp/b/oyNifiY5sHp6d 9vMg== X-Gm-Message-State: AOAM533jsMsnZsZSs3J7F3KYWsDQ+KFfew5loMMjXB/u8hme9ftHZqKR pISBKXS8VzRahOIBIi/pvicSi7ZRHYx/NSsFdl4OUw== X-Google-Smtp-Source: ABdhPJxcIynGS99w+yPMwSmLFxYiscbQnMt37rNdr0fTWVI0H/pINm7nLrN4CkJALMwTIXoABxtLzuVkX7PkKYiTC4o= X-Received: by 2002:a25:abf1:: with SMTP id v104mr31654702ybi.214.1593514383728; Tue, 30 Jun 2020 03:53:03 -0700 (PDT) MIME-Version: 1.0 References: <3ACD016D-981D-42BE-957C-9472E68EFBA1@gmail.com> In-Reply-To: <3ACD016D-981D-42BE-957C-9472E68EFBA1@gmail.com> From: Thiloshon Nagarajah Date: Tue, 30 Jun 2020 16:22:52 +0530 Message-ID: To: Filip Skokan Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c97dfd05a94afafe" Archived-At: Subject: Re: [OAUTH-WG] client_id in PAR and JAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:53:07 -0000 --000000000000c97dfd05a94afafe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Filip, Ok, thanks for the clarification. Regards On Tue, Jun 30, 2020 at 3:31 PM Filip Skokan wrote: > It already is in the new revision of JAR, PAR will follow it too. > > Technically tho, since authorization requests can also use POST its not > strictly a query string parameter, it may be contained in the request bod= y > too. Let=E2=80=99s call it authorization endpoint parameters and leave th= e =E2=80=9Chow its > transferred=E2=80=9D mechanism out. > > Odesl=C3=A1no z iPhonu > > 30. 6. 2020 v 10:15, Thiloshon Nagarajah : > > =EF=BB=BF > Hi Filip, > > So I'm assuming client_id will be mandated as a query param in PAR as wel= l? > > Regards > > On Tue, Jun 30, 2020 at 1:09 PM Filip Skokan wrote: > >> Hi Thiloshon, >> >> Not quite the way it went down but we have this adressed in a future PAR >> draft. >> >> Thank you ;) >> >> Filip >> >> Odesl=C3=A1no z iPhonu >> >> 30. 6. 2020 v 9:25, Thiloshon Nagarajah > 40wso2.com@dmarc.ietf.org>: >> >> =EF=BB=BF >> Hi All, >> >> In OAuth JAR specification, client_id is a required query parameter of >> authorisation call, in both *request* and *request_uri* flows [ >> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section-5]. >> >> But in OAuth PAR specification, which is a complimentary spec to JAR, it >> is specified "Clients are encouraged to use the request URI as the only >> parameter (in the authorisation call) in order to use the integrity and >> authenticity provided by the pushed authorization request." [ >> https://tools.ietf.org/html/draft-ietf-oauth-par-01#section-4] >> >> Taking into account these both are building upon OAuth spec, which also >> mandates client_id query param in authorisation call, it seems like PAR >> is not compatible with OAuth and JAR specs. >> >> Is this intentional? If it is may I know the rationale behind this >> decision? >> >> Regards, >> -- >> Thiloshon Nagarajah >> Software Engineer, >> Financial Solutions >> WSO2 >> +94774209947 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Thiloshon Nagarajah > Software Engineer, > Financial Solutions > WSO2 > +94774209947 > > > --=20 Thiloshon Nagarajah Software Engineer, Financial Solutions WSO2 +94774209947 --000000000000c97dfd05a94afafe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Filip,

Ok, thanks for the clarification= .=C2=A0

Regards

On Tue, Jun 30, 2020 at 3= :31 PM Filip Skokan <panva.ip@gmai= l.com> wrote:
It already is in the new revision of JAR, PAR will f= ollow it too.=C2=A0

Technically tho, since authorization= requests can also use POST its not strictly a query string parameter, it m= ay be contained in the request body too. Let=E2=80=99s call it authorizatio= n endpoint parameters and leave the =E2=80=9Chow its transferred=E2=80=9D m= echanism out.=C2=A0

Odesl=C3=A1no z=C2=A0iPhonu

30. 6. 2020 v=C2=A010:15, = Thiloshon Nagarajah <thiloshon@wso2.com>:

=EF=BB=BF
Hi=C2=A0Filip,
So I'm assuming=C2=A0client_id will be mandated as a query = param in PAR as well?

Regards=C2=A0
On Tue, J= un 30, 2020 at 1:09 PM Filip Skokan <panva.ip@gmail.com> wrote:
Hi Thiloshon,
=
Not quite the way it went down but we have this adressed in = a future PAR draft.=C2=A0

Thank you ;)
<= br>
Filip

Odesl=C3=A1no z=C2=A0iPhonu

30. 6. 2020 v=C2=A09:25, T= hiloshon Nagarajah <thiloshon=3D40wso2.com@dmarc.ietf.org>:

=EF=BB=BF
Hi All,

In OAuth JAR specification, client_id is a required query parameter of authori= sation call, in both request and request_uri flows [https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-23#section= -5].

But in OAuth PAR specification, which is = a complimentary spec to JAR, it is specified "Clients are encouraged to use the request URI as the only parameter=C2=A0(in= the=C2=A0authorisation call)=C2=A0in order= to use the integrity and authenticity provided by the pushed authorization= request." [https://tools.ietf.org/html/draft-= ietf-oauth-par-01#section-4]

Taking into = account these both are building upon OAuth spec, which also mandates client_id query param in authorisation=C2=A0call,= it seems like PAR is not compatible with OAuth and JAR specs.=C2=A0
<= div>
Is this intentional? If it is may I know the rationale b= ehind this decision?=C2=A0

Regards,
--
Thiloshon Nagarajah
Software Engineer,<= /div>
Financial Solutions
WSO2
+94774209947

=
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
<= br clear=3D"all">

--
Th= iloshon Nagarajah
Software Engineer,
Financial Solutions
WSO2
+94774209947


--
= Thiloshon Nagarajah
Software Engineer,
Financial Solutions
WSO2
+94774209947

--000000000000c97dfd05a94afafe--
Hi,=C2=A0

Sorry for the late reply. I a= nd John were really busy lately partly due to COVID-19 thing and could not = respond in a timely fashion.=C2=A0
I just replied to one of the t= hread that you posed a question about. Is that the question you mentioned i= n this=C2=A0email?

Best,=C2=A0

Nat Sakimura
On Sun, May 31, 2020 at 5:22 PM Dominick Baier <dbaier@leastprivilege.co= m> wrote:
Hi,=C2=A0

We had asked a coupl= e of questions over the last weeks regarding details of the JAR spec. Not a= single response from the spec authors.

We are in the process of implementing JAR and about to= release the software.

We need some clarifications and I am confused that we did not get any r= esponse. Is it a technical issue?

thanks
=E2=80= =94=E2=80=94=E2=80=94
Dominick Baier
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat= _en
--000000000000cca6de05a7e5f9cd-- From nobody Fri Jun 12 12:39:54 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6EE3A0CCB; Fri, 12 Jun 2020 12:39:51 -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: oauth-chairs@ietf.org, rdd@cert.org, oauth@ietf.org, rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159199079112.28651.9515509544130921075@ietfa.amsl.com> Date: Fri, 12 Jun 2020 12:39:51 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Not having a session at IETF 108 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, 12 Jun 2020 19:39:52 -0000 Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the oauth working group does not plan to hold a session at IETF 108. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Jun 12 14:48:38 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5533A11AF for ; Fri, 12 Jun 2020 14:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YI-K8YR9AABd for ; Fri, 12 Jun 2020 14:48:35 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809553A11AB for ; Fri, 12 Jun 2020 14:48:34 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id c17so12704670lji.11 for ; Fri, 12 Jun 2020 14:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=ULqOZLKu0F8tt+R+2DdlKE+iO1I6mT7bXDLKjnm2yho=; b=d30i9YCkAP9ER1cdZ2T2WBg2jPqOnatnJJSYtQT6Zkkn4wReWU+0z0bTlFl21W2yH5 tcYTdlP44oyGvjuLVbiMm/klcyzKfg9/7A9acF7Wlf2WUJmplDv6EqmCv8gsZzNcBgLm mHj0MqAXRh2BzbXzz6bFGVwFLceeYsMsyNOPu/0I5uNxLPmJfOk2IXy/C/pHaA14Ex1P LNTma+LgtGoJR0N22SXDxqXYpAnWkaytdK8AKWXhGc5ES9vva0dkSsZSk182qWi1oiMe oDvTdsVPsxpn4u/ZHzU5l4FDAYMNtYKi7gnDmFTd6Xe+C8CE/g7MgZMnYw+nNe6Uz19R TiIA== 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=ULqOZLKu0F8tt+R+2DdlKE+iO1I6mT7bXDLKjnm2yho=; b=uIYX7HRZxxdxk/e+JB9X+PikSFVrwazWXXexVo8eh0NRgI4dpG65qvfZ78eVDkTlBP 2xE9Ghq5wFX3Q6HFBe1zimbJZFu50s1hLZH1Lo4EG8fHMKS5OsCzVYFYV5DmSUIJvxRz CVAOqijrKDzar/adZz/07v1kFYIB5mPeVeFppK0vQbyiUIskNRCppuKvWNNZm9LMLrYA KDQ6KsPOjhJTBLgAPVbwCQCCvomct5/e2PAO+npO+xKMrnFN8PaJ5Xu1mDpuhFDM1sYf kp5ZkGmdqOgKGvNs98Te3bOKIpk2oA84yPpYzKTf3nmCmcmVD1yry6+R1MncxBtyMQ9o OlEQ== X-Gm-Message-State: AOAM533TadNaPh7PGgnskYv3KXBzp3qbHkKbwD28Tb2iiq8oB4u5gUhh 5QnT6BWLeHcC50PCbdzKlrlvpkuZuL1FLvMS9Ivpmmf7FxAoJF+mUDSTqNcwJmXHnrWpgG78fZ8 l3gnXZgC3hVR+Pw== X-Received: by 2002:a2e:85da:: with SMTP id h26mt5952689ljj.170.1591998510533; Fri, 12 Jun 2020 14:48:30 -0700 (PDT) MIME-Version: 1.0 References: <159199079112.28651.9515509544130921075@ietfa.amsl.com> In-Reply-To: <159199079112.28651.9515509544130921075@ietfa.amsl.com> From: Brian Campbell Date: Fri, 12 Jun 2020 15:48:04 -0600 Message-ID: Cc: oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000b8bdeb05a7ea0955" Archived-At: Subject: Re: [OAUTH-WG] oauth - Not having a session at IETF 108 X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jun 2020 21:48:37 -0000 --000000000000b8bdeb05a7ea0955 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No OAuth WG sessions planned for the 108 meeting? On Fri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that th= e > oauth working group does not plan to hold a session at IETF 108. > > This message was generated and sent by the IETF Meeting Session Request > Tool. > > > > _______________________________________________ > 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._ --000000000000b8bdeb05a7ea0955 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No OAuth WG sessions planned for the 108 meeting?

On F= ri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool <session-request@ietf.org> wrote= :


Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the = oauth working group does not plan to hold a session at IETF 108.

This message was generated and sent by the IETF Meeting Session Request Too= l.



_______________________________________________
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. --000000000000b8bdeb05a7ea0955-- From nobody Fri Jun 12 15:04:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86143A0D6F; Fri, 12 Jun 2020 15:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a7pfbRmOSG2; Fri, 12 Jun 2020 15:04:08 -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 051893A0D6E; Fri, 12 Jun 2020 15:04:08 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id x13so11454331wrv.4; Fri, 12 Jun 2020 15:04: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=NrRRCp+wNweOzdqFCiA7Dg0qBQkeKJ6ReLgOPR7rCzQ=; b=NZ89Cfe6zQun8uCtOluLDDMJTXg44UO2IrbdeKBDuqGZ8FrnU/Q+TatipvTCEt2Tcx rVmZ/lgZ6Cxk+brUQm9rnSla0RMeawdf6RPDslI/EbOj7qASuzeyXA+4A8HXkUC5IfX9 JwBJEemPMJlK79WL8vwlaMtaBOY4QR0zMdgDGONFQijH33M9dODN2r2w5YuIa7bGktjg pwlFlg+MpevPi9bkVeUwrVZqATQe0LUoMseSGqp7pMinxLzFojpkCaIbIrzvl1gmZndp TlrEEsgBMQMnkDhZbxuzd51fPOUyZUbz4YkMms5QC0I56ajYlyyKeFpfaj9/ewcOA+EP eeDw== 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=NrRRCp+wNweOzdqFCiA7Dg0qBQkeKJ6ReLgOPR7rCzQ=; b=BWAxxNC09jCBOVHhLy4OSlwdjutarM5HhIzXSt+WDDpMh6UOkNzLE0Q206+T047OE3 h8dOcTcGfOoPQQ9belse3jWS8kMgN4ZVV1JQ5Erpeai+4KTZhWImXdq+8I6EeMusGoqY fz4kZwtKH3TMGA94Gb5o1bnBB5sexWyzWIiqKycwxG6NoEfvkOeG1uEnuOsKVr8SMjqC Q5/W2g6GKr+2IsPLblDl5jE7AJSTZrSXumU6+Y16pUlNNBXIKwrXu7VFt6BdraRa8+cI G9JljLlFEiEiZKADnlqnkDTCdFWxH45UrRuFGDlJlJ+3rp5ZiR8D28ZNCFzWvyITf8y4 n75Q== X-Gm-Message-State: AOAM531ChbKL+TS/MVj514G7TflJUlQ1u83z42qgK3ESn6oMOEHNRRGn 3cdQ5WYgF03ZHpzgZDd8OsX4MxMC9Mgny+IQW/+T++9I X-Google-Smtp-Source: ABdhPJxsLglJBw3M/1SrkyT1tOyMdmDzaNW7u97LwOleypLnTWVIVAt8YzDZcqHqz5X8BfsAYHWLfKb6JRAymxa7XZ4= X-Received: by 2002:adf:f207:: with SMTP id p7mr16999812wro.206.1591999446554; Fri, 12 Jun 2020 15:04:06 -0700 (PDT) MIME-Version: 1.0 References: <159199079112.28651.9515509544130921075@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Fri, 12 Jun 2020 18:03:55 -0400 Message-ID: To: Brian Campbell Cc: oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000007e9b7305a7ea4146" Archived-At: Subject: Re: [OAUTH-WG] oauth - Not having a session at IETF 108 X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Jun 2020 22:04:10 -0000 --0000000000007e9b7305a7ea4146 Content-Type: text/plain; charset="UTF-8" Based on the discussion during the last interim meeting series, the plan is to schedule another series of these meetings with times/dates that work for the WG. Regards, Rifaat On Fri, Jun 12, 2020 at 5:48 PM Brian Campbell wrote: > No OAuth WG sessions planned for the 108 meeting? > > On Fri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool < > session-request@ietf.org> wrote: > >> >> >> Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that >> the oauth working group does not plan to hold a session at IETF 108. >> >> This message was generated and sent by the IETF Meeting Session Request >> Tool. >> >> >> >> _______________________________________________ >> 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.* --0000000000007e9b7305a7ea4146 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on the discussion during the last interim meeting se= ries, the plan is to schedule=C2=A0another series of these meetings with ti= mes/dates that work for the WG.

Regards,
= =C2=A0Rifaat


On Fri, Jun 12, 2020 at 5:48 PM Bria= n Campbell <bcampbell@ping= identity.com> wrote:
No OAuth WG sessions planned for the 108 meeti= ng?

On Fri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool &= lt;session-re= quest@ietf.org> wrote:


Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the = oauth working group does not plan to hold a session at IETF 108.

This message was generated and sent by the IETF Meeting Session Request Too= l.



_______________________________________________
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.
--0000000000007e9b7305a7ea4146-- From nobody Thu Jun 18 05:07:07 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91BE3A0CC2 for ; Thu, 18 Jun 2020 05:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHRC30g4u4n4 for ; Thu, 18 Jun 2020 05:07:05 -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 5851B3A0CC1 for ; Thu, 18 Jun 2020 05:07:05 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id w18so6720173iom.5 for ; Thu, 18 Jun 2020 05:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nmNKtl9mx9fiXl7zy7xN6RjkPwyotugJFlAs3LIAGHc=; b=vSXRv4tWC2Gzmk9Ukvx8+z8CGPNBAkzSMOBNL9Kpk202hAn/07/FNsAH3exAhY8TAU I40Z57LH1hztEEbUTQs8X0cz7bkuvBvM+qJnSZ56DsZS0+jW0jEPQyR95+4Linm1zIom EPek0Kqlpi7N78/2YPnknWuNQttZbOLvCQ05bjjhtbk7Ip5zyDy5x8iwPwhPDrgbk4L2 SP7wHjQc5zz+Px8VZLI0qDvkHTOw/sSauwkDVcw4Sp4GhkwXnyR9kFRAI3etac/wfljy DRGOzeQHF5jHZTiTm00wjT0GR1EGkGQxd8aUI6H71KHEz/kNLx0yP6IcR094mZXp7lb/ 8NKg== 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=nmNKtl9mx9fiXl7zy7xN6RjkPwyotugJFlAs3LIAGHc=; b=ebBOjfbSXDDfYN9QNYPeA/8fBtq4TV9UdmfkKI/Z1lgUcviPpAJka+SBtgsEVazxxx fVUlXOfyk8oJI4nNWz1ucuVaJ4cHgE2DcpECSAuzY3aurJFtGE/AVcivLgiVZfPguJIm SQRKYpz/BXAjiHoarTDOKXveD2gWSIZXnbGEBqbYxAxNJ15yfU5S5QgeC6+2RZEqyzkv xHlWBWDppOFjjeGaaIFshB7cCdl574JfBqKZGIEfFHIMQJ8J9T+OEOEDgHVgU4Gcf8Po vAb72krBrAHGje6YMrAL4gKCAB3g4XN1mSJOoGb0g/faP1wwOQWbO6TldBM2yY3SZ4Wp YX4Q== X-Gm-Message-State: AOAM532II2hkW4pgdXRFJcv46OFMjQoHKNCmR12cwSZXEtYR7K8MTCt2 KKFHlRAoOqpMbCayFtvIVkOo4+ix2iV0Z6Cr4NKwxQn/ X-Google-Smtp-Source: ABdhPJxC+yM9roV7Z9lL9N2VLQLxsuLg4lMmz8F2uRwgcpQpX+QZw9ro9Qyx/pMEqhwNWoT7iZbk3rIPP7hfZzIWCqk= X-Received: by 2002:a05:6638:12d2:: with SMTP id v18mr4111187jas.4.1592482024129; Thu, 18 Jun 2020 05:07:04 -0700 (PDT) MIME-Version: 1.0 From: Logan Widick Date: Thu, 18 Jun 2020 08:06:53 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005c071a05a85a9d6a" Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt: roles, groups, entitlements claim format clarification X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jun 2020 12:07:07 -0000 --0000000000005c071a05a85a9d6a Content-Type: text/plain; charset="UTF-8" What are the formats of the "roles", "groups", and "entitlements" JWT claims going to be? Arrays of strings? Arrays of the objects from SCIM Core? Something else? Sincerely, Logan Widick --0000000000005c071a05a85a9d6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What are the formats of the "roles", "grou= ps", and "entitlements" JWT claims going to be? Arrays of st= rings? Arrays of the objects from SCIM Core? Something else?

Sincerely,

=
Logan Widick
--0000000000005c071a05a85a9d6a-- From nobody Thu Jun 18 13:32:39 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4188B3A0F6E for ; Thu, 18 Jun 2020 13:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ocHMHL7V2U6 for ; Thu, 18 Jun 2020 13:32:31 -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 4E0643A0F62 for ; Thu, 18 Jun 2020 13:32:31 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id i3so8911884ljg.3 for ; Thu, 18 Jun 2020 13:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8t6YmB8BW73j4kMFo7hlmPYw6CdNUZ5y9pTwSmUAYOs=; b=esKn6mcyKLQ0jZYpXoltJlY0WKUA1XrxmeFN7DHjxz0S7RvwKXC11E8p30oomuRwge i9ZH41OMM/NKq4JwTOGU/fWbE7zftvdqYFSFrfnan4dp11XZ4mxJXOq36w008N+b6pcD PRhe0kfH7L3s48XomWZJY3Ad2YT55IQ+f9dZazzsAnCjbNwA6NjdRSZ95rIcBvjRnzLt QKDkePWm1gjSLNR68zKawmZEJzBC5sX54/pDaJ7shun2j4w6IOoFKBcR/9EQV1rB4Rx4 d9muz+g+tVgj0Abuv3ZckLqdensmH7/i6AkEzqN49Tux/1hMGbtVoNRpLozLjSOWL68S phKA== 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=8t6YmB8BW73j4kMFo7hlmPYw6CdNUZ5y9pTwSmUAYOs=; b=GqAw8n1SCLQjz4dW+8VjQh5tHXqDa3z36xNRXyRSkb6GVjiVnVjK1Wc4Mk2H8Go0Z+ MSDoCpCgr+W30AiBNXiPyQmfL1WUdZe4jK6dKnzPMUpHknI1JctmdMTkPLClktK5gZnR 1U0BI0AX1uegUIW3T0If+v4xrdhpePXRIT2Ul9XdzcLKCV1uedX8nv6PQfDnDLE4FHsU xUYaGQCnKJZ8PBDyEd4FIRPw8IVBmNtIkl284x82fLW7NkSjLOkM0U7aMrA3LT7bMnHc b7y8Nqs7cPhUzFqCBVqQe3EXOVwDA0eVgTvek9fJCfiH91+aDhvIdJKWkHUKryfw2sA3 RNQA== X-Gm-Message-State: AOAM533+RWojQP35QgeYERXA/yiJ4oXQ5/pry/T0GB3tCzS0UwatFlhR GqBsdUnSXJ4aPCV4FQCzsOfiEbKUpfWQ60G3u7b24px0WKKYrLZ45U+0iM+Rx2FH/GFNyo0LvPU P+oSPq9cXFdd5Yq+H X-Google-Smtp-Source: ABdhPJyEwuu3r/E3eIWTYAfJzYjOfuMPIvUmSdzzT6FPls8WmEWD+YrH1eqi4Lv6R21wxKQXpDNtc6bICd9NCAVvTYE= X-Received: by 2002:a2e:6804:: with SMTP id c4mr83761lja.422.1592512349421; Thu, 18 Jun 2020 13:32:29 -0700 (PDT) MIME-Version: 1.0 References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> In-Reply-To: <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> From: Brian Campbell Date: Thu, 18 Jun 2020 14:32:03 -0600 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="000000000000e366dc05a861acac" Archived-At: Subject: Re: [OAUTH-WG] Mix-Up Revisited X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 20:32:36 -0000 --000000000000e366dc05a861acac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my (probably simplistic) understanding of things, the root underlying issue that allows for mix-up in its variations is the lack of anything identifying the AS in the authorization response. Following from that, introducing and using an `iss` authorization response parameter has always seemed like the most straightforward approach for mitigating the issue (which was part of the draft-ietf-oauth-mix-up-mitigation but other parameters were also included and, for reasons I'm not sure about, interest in that work faded in favor of telling clients to use per AS redirect URIs) . Though for the `iss` authorization response parameter to be effective, all parties involved need to know about it and act on it. So I think it'd need to be something more than a passing recommendation in the BCP. It should be defined, registered, explained, etc.. Actually introducing a new parameter is maybe going beyond the expected scope of the BCP (or 2.1). But maybe that's ok, if we're at least more intentional about it. On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett wrote: > Hi all, > I was wondering if we should move towards introducing and (more > explicitly) recommending the iss parameter in the security BCP, for the > reasons laid out below and in the article (which is now at > https://danielfett.de/2020/05/04/mix-up-revisited/). > > Any thoughts on this? > > -Daniel > > Am 04.05.20 um 19:34 schrieb Daniel Fett: > > Hi all, > > to make substantiated recommendations for FAPI 2.0, the security > considerations for PAR, and the security BCP, I did another analysis on t= he > threats that arise from mix-up attacks. I was interested in particular in > two questions: > > - Does PAR help preventing mix-up attacks? > - Do we need JARM to prevent mix-up attacks? > > I wrote down several attack variants and configurations in the following > document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.htm= l > > The key takeaways are: > > 1. The security BCP needs to make clear that per-*AS* redirect URIs > are only sufficient if OAuth Metadata is not used to resolve multiple > issuers. Otherwise, per-*Issuer* redirect URIs or the iss parameter > MUST be used. > 2. PAR-enabled authorization servers can protect the integrity better > and protect against Mix-Up Attacks better if they ONLY accept PAR requ= ests. > 3. We should emphasize the importance of the iss parameter (or issuer) > in the authorization response. Maybe introduce this parameter in the > security BCP or another document? > 4. Sender-constrained access tokens help against mix-up attacks when > the access token is targeted. > 5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might > be worth looking into. > > I would like to hear your thoughts! > > -Daniel > > _______________________________________________ > 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._ --000000000000e366dc05a861acac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my (probably simplistic) understanding of things, the r= oot underlying issue that allows for mix-up in its variations is the lack o= f anything identifying the AS in the authorization response. Following from= that, introducing and using an `iss` authorization response parameter has = always seemed like the most straightforward approach for mitigating the iss= ue (which was part of the draft-ietf-oauth-mix-up-mitigation but other para= meters were also included and, for reasons I'm not sure about, interest= in that work faded in favor of telling clients to use per AS redirect URIs= ) . Though for the `iss` authorization response parameter to be effective, = all parties involved need to know about it and act on it. So I think it'= ;d need to be something more than a passing recommendation in the BCP. It s= hould be defined, registered, explained, etc.. Actually introducing a new p= arameter is maybe going beyond the expected scope of the BCP (or 2.1). But = maybe that's ok, if we're at least more intentional about it.=C2=A0=

On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett <fett@danielfett.de> wrote:
=20 =20 =20
Hi all,
I was wondering if we should move towards introducing and (more explicitly) recommending the iss parameter in the security BCP, for the reasons laid out below and in the article (which is now at https://danielfett.de/2020/05/0= 4/mix-up-revisited/).

Any thoughts on this?

-Daniel

Am 04.05.20 um 19:34 schrieb Daniel Fett:
=20

Hi all,

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

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

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

The key takeaways are:

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

I would like to hear your thoughts!

-Daniel


_______________________________________________
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. --000000000000e366dc05a861acac-- From nobody Thu Jun 18 13:49:56 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B403A0F65 for ; Thu, 18 Jun 2020 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBrT_hKI1Afv for ; Thu, 18 Jun 2020 13:49:52 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640124.outbound.protection.outlook.com [40.107.64.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2853A080F for ; Thu, 18 Jun 2020 13:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L7N3UqYhMqWMQCiwifvhorW8fxwLY0+0BRUlFTVCN/6QubdBB64/sEFkBrRnb8ZHHwlkfMGD76NnMn010s/P5VuBGG5e+8O6mFtTZqwQv/+gR29qMo0Wo4CAfbvggBXYkbaAX1LjFIQfcEer7hayN5Nyghq6Gm0YdjITBF9G4XnRsB83B4Qo18spOSOCcLmxri1X678f+cHHiyGYzpxT6nv7lMJwh4UUbVlHhjq2spoKcDxKVo+YiZ6Iq6AvF21E2XgONDmfq5GciaIEgIkBGETdCgVi1yr9mLs3/WSbJyTwfiDkul3PB1wGsQgifyvGwLVlxWOJtaGNfMPMx+W4Zg== 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=LZg2reeAUmOgQpQNg48TZ16dLmYh9UNUUTE3+jCq0h4=; b=ErZ+QRnVCiqxpQKAULLVzTz6LJUcgGeQMUxk9qLyKNgUInu+UFmrwF2/7Q8I14IAAESQ3gjNwh2hm77Lsdl0Eg8cIeazx9bm7xqJBFp6ZpyqrSt8CIurjeLU3sE4OpyRR//ND2NGbSST7c0MvYeuZ4w0kid5AMPdokq3qp3iwlZ6gkaAtL3z6mJcI4CXISGIy+rpT3gTxTaovTYNXhljvkXjYR9MuNAG7O18CR7z91DPNl+4OGePEV4Q6xMKPHAfBVrSRILKgHqWjdh9jS0fdxPGyQDJM0RxkWW3aeqQxV25EJ8bryAG/VOstLM/yzsXpdImjw5M6LnPP2aLVTtW6Q== 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=LZg2reeAUmOgQpQNg48TZ16dLmYh9UNUUTE3+jCq0h4=; b=OPV3JcN4+FqxvRYzdYNdIspPXErj6G6POxlHr6Zu6tu75KOipUkYWDK0Oirn7yboGyhqFc3+dYvZuST5J2Cq1+eByfSuFJfgZEtJkh92TJu/qqDB8Q8MuejSZsvJgu5V5XuYk3idfUpSocYOwcg0wZ2rdKRBXoSZuS1rwy9kmc4= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by BL0PR00MB0803.namprd00.prod.outlook.com (2603:10b6:208:1ce::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3151.0; Thu, 18 Jun 2020 20:49:50 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f%8]) with mapi id 15.20.3154.000; Thu, 18 Jun 2020 20:49:50 +0000 From: Mike Jones To: Brian Campbell , Daniel Fett CC: oauth Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited Thread-Index: AQHWPNMMfyvqnY9dGEW9M+tsywie66je5WaAgAAD2pA= Date: Thu, 18 Jun 2020 20:49:50 +0000 Message-ID: References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> 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=23c95061-b448-4f18-a9ab-453efb6d0879; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-18T20:45:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c699dda8-61b8-4906-7b8a-08d813c9253b x-ms-traffictypediagnostic: BL0PR00MB0803: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: USb0IlrhFzZ2E+/eEoOUazCeNykRFEosBwPvEGCSU80peqIVkKDl0CWOk1su4zfjkUjuBc/NAJiXvYY5ZeZR6x2PTYbx/wiexrfgEU6Jz8KQQevL9wrUdUteJySI/gQzfjbPn+S8VqB+jAvAbAsxDXFNzZMtz4gp414ByuiEK3A++etRdPLmGj8o0AJb3gflcN3RkeVx5WYfYZBeEsPjyhkNbQ1g5tlXIQi4QCUieuTxSdIJBEi36FvxvnmqZVo4+CNQXXxq8ioDcz0UzXvkQGJDc8OFmVWS3/tz5QgygoKQja7JirVsSezd3F58AnU+GFoJJIneV9uNqYlYrh5nTsvUiTyedG8fpMw21dwzmKEq2vdZ4BuHJVVq1PnbTjaC+Gequ9DXFP19t68Mcrlyfg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(166002)(478600001)(8676002)(64756008)(71200400001)(66446008)(86362001)(10290500003)(66476007)(66946007)(66556008)(76116006)(8936002)(8990500004)(9686003)(966005)(110136005)(83080400001)(4326008)(33656002)(83380400001)(55016002)(82960400001)(82950400001)(186003)(26005)(7696005)(2906002)(53546011)(6506007)(5660300002)(316002)(21615005)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: i9cE+zcm1JGNGSYwc4rjJbXUYwT3+LYQROXlRuZ6t9knwsik8pflSnwBA+BD84LfivS4vQqj1/jQLN9jOmkIW1Zur1Ut5popIAHadhBMCfWJXn31O4LIP9kcXJU+Lc/stMgHLJ1T352JB04DrHw0MMyVl3eU5Xa2LhR5pqSKiU2aotM6RPks4LzsPw/NmzM5spc5MBb+AlGkxIYLWVyYcZIGIfsb5V2wRRKBLrqW9SSbvqDwQpuNdM8idspD7Cf7+RjLFldXprAsTJbDpV6/Evhhu2s6jK12OwuR9nXeD7QlGlWri5qGjYuyKPjlaR/jGQAqB0OElUnJuVGKhT12QYHkXaIRq3IvqwDRXsIJHhLuVozXgpDQ5swp1oqGeE1XZn6DXpcBzAG3o5DMOH/N7yAQkIAlZaphpdlFQtdX0MUCL5lOrO1zlFqP9k8REc+1V4MCBp2WqJZQFIz3A0AjZYoyMWjKbP37L4kjeZeXfps= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06866084FF95C4956A76B472F59B0MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c699dda8-61b8-4906-7b8a-08d813c9253b X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 20:49:50.5670 (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: 7iDnTL4mGtJnl+KvLLf1HzASKVbYjJcL/k+MVh/EYTUEFi/nqZcLKlZIQYHXA6uy82cjbhEFZo9ZuXQl/fTinw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0803 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 20:49:55 -0000 --_000_MN2PR00MB06866084FF95C4956A76B472F59B0MN2PR00MB0686namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGRvY3VtZW50aW5nIHRoZSB1c2Ugb2YgdGhlIGlzc3VlciB0byBtaXRpZ2F0ZSBt aXgtdXAgYXR0YWNrcy4gIE5vdGUgdGhhdCB3aGlsZSBpc3N1ZXIgd2FzIGZpcnN0IGRlZmluZWQg YnkgT3BlbklEIENvbm5lY3QsIGl0IGJlY2FtZSBhcnQgb2YgT0F1dGggMi4wIGluIFJGQyA4NDE0 IC0gT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIENh bXBiZWxsDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxOCwgMjAyMCAxOjMyIFBNDQpUbzogRGFuaWVs IEZldHQgPGZldHRAZGFuaWVsZmV0dC5kZT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbT0FVVEgtV0ddIE1peC1VcCBSZXZpc2l0ZWQNCg0KSW4g bXkgKHByb2JhYmx5IHNpbXBsaXN0aWMpIHVuZGVyc3RhbmRpbmcgb2YgdGhpbmdzLCB0aGUgcm9v dCB1bmRlcmx5aW5nIGlzc3VlIHRoYXQgYWxsb3dzIGZvciBtaXgtdXAgaW4gaXRzIHZhcmlhdGlv bnMgaXMgdGhlIGxhY2sgb2YgYW55dGhpbmcgaWRlbnRpZnlpbmcgdGhlIEFTIGluIHRoZSBhdXRo b3JpemF0aW9uIHJlc3BvbnNlLiBGb2xsb3dpbmcgZnJvbSB0aGF0LCBpbnRyb2R1Y2luZyBhbmQg dXNpbmcgYW4gYGlzc2AgYXV0aG9yaXphdGlvbiByZXNwb25zZSBwYXJhbWV0ZXIgaGFzIGFsd2F5 cyBzZWVtZWQgbGlrZSB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2ggZm9yIG1pdGln YXRpbmcgdGhlIGlzc3VlICh3aGljaCB3YXMgcGFydCBvZiB0aGUgZHJhZnQtaWV0Zi1vYXV0aC1t aXgtdXAtbWl0aWdhdGlvbiBidXQgb3RoZXIgcGFyYW1ldGVycyB3ZXJlIGFsc28gaW5jbHVkZWQg YW5kLCBmb3IgcmVhc29ucyBJJ20gbm90IHN1cmUgYWJvdXQsIGludGVyZXN0IGluIHRoYXQgd29y ayBmYWRlZCBpbiBmYXZvciBvZiB0ZWxsaW5nIGNsaWVudHMgdG8gdXNlIHBlciBBUyByZWRpcmVj dCBVUklzKSAuIFRob3VnaCBmb3IgdGhlIGBpc3NgIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgcGFy YW1ldGVyIHRvIGJlIGVmZmVjdGl2ZSwgYWxsIHBhcnRpZXMgaW52b2x2ZWQgbmVlZCB0byBrbm93 IGFib3V0IGl0IGFuZCBhY3Qgb24gaXQuIFNvIEkgdGhpbmsgaXQnZCBuZWVkIHRvIGJlIHNvbWV0 aGluZyBtb3JlIHRoYW4gYSBwYXNzaW5nIHJlY29tbWVuZGF0aW9uIGluIHRoZSBCQ1AuIEl0IHNo b3VsZCBiZSBkZWZpbmVkLCByZWdpc3RlcmVkLCBleHBsYWluZWQsIGV0Yy4uIEFjdHVhbGx5IGlu dHJvZHVjaW5nIGEgbmV3IHBhcmFtZXRlciBpcyBtYXliZSBnb2luZyBiZXlvbmQgdGhlIGV4cGVj dGVkIHNjb3BlIG9mIHRoZSBCQ1AgKG9yIDIuMSkuIEJ1dCBtYXliZSB0aGF0J3Mgb2ssIGlmIHdl J3JlIGF0IGxlYXN0IG1vcmUgaW50ZW50aW9uYWwgYWJvdXQgaXQuDQoNCk9uIFN1biwgSnVuIDcs IDIwMjAgYXQgNzo1MyBBTSBEYW5pZWwgRmV0dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPG1haWx0bzpm ZXR0QGRhbmllbGZldHQuZGU+PiB3cm90ZToNCkhpIGFsbCwNCkkgd2FzIHdvbmRlcmluZyBpZiB3 ZSBzaG91bGQgbW92ZSB0b3dhcmRzIGludHJvZHVjaW5nIGFuZCAobW9yZSBleHBsaWNpdGx5KSBy ZWNvbW1lbmRpbmcgdGhlIGlzcyBwYXJhbWV0ZXIgaW4gdGhlIHNlY3VyaXR5IEJDUCwgZm9yIHRo ZSByZWFzb25zIGxhaWQgb3V0IGJlbG93IGFuZCBpbiB0aGUgYXJ0aWNsZSAod2hpY2ggaXMgbm93 IGF0IGh0dHBzOi8vZGFuaWVsZmV0dC5kZS8yMDIwLzA1LzA0L21peC11cC1yZXZpc2l0ZWQvKS4N Cg0KQW55IHRob3VnaHRzIG9uIHRoaXM/DQoNCi1EYW5pZWwNCg0KQW0gMDQuMDUuMjAgdW0gMTk6 MzQgc2NocmllYiBEYW5pZWwgRmV0dDoNCg0KSGkgYWxsLA0KDQp0byBtYWtlIHN1YnN0YW50aWF0 ZWQgcmVjb21tZW5kYXRpb25zIGZvciBGQVBJIDIuMCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGZvciBQQVIsIGFuZCB0aGUgc2VjdXJpdHkgQkNQLCBJIGRpZCBhbm90aGVyIGFuYWx5c2lz IG9uIHRoZSB0aHJlYXRzIHRoYXQgYXJpc2UgZnJvbSBtaXgtdXAgYXR0YWNrcy4gSSB3YXMgaW50 ZXJlc3RlZCBpbiBwYXJ0aWN1bGFyIGluIHR3byBxdWVzdGlvbnM6DQoNCiAgKiAgIERvZXMgUEFS IGhlbHAgcHJldmVudGluZyBtaXgtdXAgYXR0YWNrcz8NCiAgKiAgIERvIHdlIG5lZWQgSkFSTSB0 byBwcmV2ZW50IG1peC11cCBhdHRhY2tzPw0KDQpJIHdyb3RlIGRvd24gc2V2ZXJhbCBhdHRhY2sg dmFyaWFudHMgYW5kIGNvbmZpZ3VyYXRpb25zIGluIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6IGh0 dHBzOi8vZGFuaWVsZmV0dC5naXRodWIuaW8vbm90ZXMvb2F1dGgvTWl4LVVwJTIwUmV2aXNpdGVk Lmh0bWwNCg0KVGhlIGtleSB0YWtlYXdheXMgYXJlOg0KDQogIDEuICBUaGUgc2VjdXJpdHkgQkNQ IG5lZWRzIHRvIG1ha2UgY2xlYXIgdGhhdCBwZXItQVMgcmVkaXJlY3QgVVJJcyBhcmUgb25seSBz dWZmaWNpZW50IGlmIE9BdXRoIE1ldGFkYXRhIGlzIG5vdCB1c2VkIHRvIHJlc29sdmUgbXVsdGlw bGUgaXNzdWVycy4gT3RoZXJ3aXNlLCBwZXItSXNzdWVyIHJlZGlyZWN0IFVSSXMgb3IgdGhlIGlz cyBwYXJhbWV0ZXIgTVVTVCBiZSB1c2VkLg0KICAyLiAgUEFSLWVuYWJsZWQgYXV0aG9yaXphdGlv biBzZXJ2ZXJzIGNhbiBwcm90ZWN0IHRoZSBpbnRlZ3JpdHkgYmV0dGVyIGFuZCBwcm90ZWN0IGFn YWluc3QgTWl4LVVwIEF0dGFja3MgYmV0dGVyIGlmIHRoZXkgT05MWSBhY2NlcHQgUEFSIHJlcXVl c3RzLg0KICAzLiAgV2Ugc2hvdWxkIGVtcGhhc2l6ZSB0aGUgaW1wb3J0YW5jZSBvZiB0aGUgaXNz IHBhcmFtZXRlciAob3IgaXNzdWVyKSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZS4gTWF5 YmUgaW50cm9kdWNlIHRoaXMgcGFyYW1ldGVyIGluIHRoZSBzZWN1cml0eSBCQ1Agb3IgYW5vdGhl ciBkb2N1bWVudD8NCiAgNC4gIFNlbmRlci1jb25zdHJhaW5lZCBhY2Nlc3MgdG9rZW5zIGhlbHAg YWdhaW5zdCBtaXgtdXAgYXR0YWNrcyB3aGVuIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdGFyZ2V0ZWQu DQogIDUuICBTZW5kZXItY29uc3RyYWluaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgKFBBUiAr IFBBUi1EUG9QPykgbWlnaHQgYmUgd29ydGggbG9va2luZyBpbnRvLg0KDQpJIHdvdWxkIGxpa2Ug dG8gaGVhciB5b3VyIHRob3VnaHRzIQ0KDQotRGFuaWVsDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVz ZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1 dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS4NCg== --_000_MN2PR00MB06866084FF95C4956A76B472F59B0MN2PR00MB0686namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6LWFwcGxlLXN5c3RlbTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NDQ1MTQ3Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTUyMTA3NDkyNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MTQ1MTgyMTg2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTIxNDI4NjA5MjI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgc3VwcG9y dCBkb2N1bWVudGluZyB0aGUgdXNlIG9mIHRoZSBpc3N1ZXIgdG8gbWl0aWdhdGUgbWl4LXVwIGF0 dGFja3MuJm5ic3A7IE5vdGUgdGhhdCB3aGlsZSBpc3N1ZXIgd2FzIGZpcnN0IGRlZmluZWQgYnkg T3BlbklEIENvbm5lY3QsIGl0IGJlY2FtZSBhcnQgb2YgT0F1dGggMi4wIGluIFJGQyA4NDE0IC0g T0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg PC9iPg0KQnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMTgs IDIwMjAgMTozMiBQTTxicj4NCjxiPlRvOjwvYj4gRGFuaWVsIEZldHQgJmx0O2ZldHRAZGFuaWVs ZmV0dC5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBNaXgtVXAgUmV2 aXNpdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IChwcm9i YWJseSBzaW1wbGlzdGljKSB1bmRlcnN0YW5kaW5nIG9mIHRoaW5ncywgdGhlIHJvb3QgdW5kZXJs eWluZyBpc3N1ZSB0aGF0IGFsbG93cyBmb3IgbWl4LXVwIGluIGl0cyB2YXJpYXRpb25zIGlzIHRo ZSBsYWNrIG9mIGFueXRoaW5nIGlkZW50aWZ5aW5nIHRoZSBBUyBpbiB0aGUgYXV0aG9yaXphdGlv biByZXNwb25zZS4gRm9sbG93aW5nIGZyb20gdGhhdCwgaW50cm9kdWNpbmcgYW5kIHVzaW5nDQog YW4gYGlzc2AgYXV0aG9yaXphdGlvbiByZXNwb25zZSBwYXJhbWV0ZXIgaGFzIGFsd2F5cyBzZWVt ZWQgbGlrZSB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2ggZm9yIG1pdGlnYXRpbmcg dGhlIGlzc3VlICh3aGljaCB3YXMgcGFydCBvZiB0aGUgZHJhZnQtaWV0Zi1vYXV0aC1taXgtdXAt bWl0aWdhdGlvbiBidXQgb3RoZXIgcGFyYW1ldGVycyB3ZXJlIGFsc28gaW5jbHVkZWQgYW5kLCBm b3IgcmVhc29ucyBJJ20gbm90IHN1cmUgYWJvdXQsDQogaW50ZXJlc3QgaW4gdGhhdCB3b3JrIGZh ZGVkIGluIGZhdm9yIG9mIHRlbGxpbmcgY2xpZW50cyB0byB1c2UgcGVyIEFTIHJlZGlyZWN0IFVS SXMpIC4gVGhvdWdoIGZvciB0aGUgYGlzc2AgYXV0aG9yaXphdGlvbiByZXNwb25zZSBwYXJhbWV0 ZXIgdG8gYmUgZWZmZWN0aXZlLCBhbGwgcGFydGllcyBpbnZvbHZlZCBuZWVkIHRvIGtub3cgYWJv dXQgaXQgYW5kIGFjdCBvbiBpdC4gU28gSSB0aGluayBpdCdkIG5lZWQgdG8gYmUgc29tZXRoaW5n IG1vcmUNCiB0aGFuIGEgcGFzc2luZyByZWNvbW1lbmRhdGlvbiBpbiB0aGUgQkNQLiBJdCBzaG91 bGQgYmUgZGVmaW5lZCwgcmVnaXN0ZXJlZCwgZXhwbGFpbmVkLCBldGMuLiBBY3R1YWxseSBpbnRy b2R1Y2luZyBhIG5ldyBwYXJhbWV0ZXIgaXMgbWF5YmUgZ29pbmcgYmV5b25kIHRoZSBleHBlY3Rl ZCBzY29wZSBvZiB0aGUgQkNQIChvciAyLjEpLiBCdXQgbWF5YmUgdGhhdCdzIG9rLCBpZiB3ZSdy ZSBhdCBsZWFzdCBtb3JlIGludGVudGlvbmFsIGFib3V0IGl0LiZuYnNwOw0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1biA3LCAyMDIwIGF0 IDc6NTMgQU0gRGFuaWVsIEZldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpmZXR0QGRhbmllbGZldHQu ZGUiIHRhcmdldD0iX2JsYW5rIj5mZXR0QGRhbmllbGZldHQuZGU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3YXMgd29uZGVyaW5nIGlmIHdlIHNob3VsZCBtb3ZlIHRvd2FyZHMg aW50cm9kdWNpbmcgYW5kIChtb3JlIGV4cGxpY2l0bHkpIHJlY29tbWVuZGluZyB0aGUgaXNzIHBh cmFtZXRlciBpbiB0aGUgc2VjdXJpdHkgQkNQLCBmb3IgdGhlIHJlYXNvbnMgbGFpZCBvdXQgYmVs b3cgYW5kIGluIHRoZSBhcnRpY2xlICh3aGljaCBpcyBub3cgYXQNCjxhIGhyZWY9Imh0dHBzOi8v ZGFuaWVsZmV0dC5kZS8yMDIwLzA1LzA0L21peC11cC1yZXZpc2l0ZWQvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9kYW5pZWxmZXR0LmRlLzIwMjAvMDUvMDQvbWl4LXVwLXJldmlzaXRlZC88L2E+ KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW55IHRob3VnaHRzIG9uIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMDQuMDUuMjAgdW0gMTk6MzQgc2NocmllYiBEYW5p ZWwgRmV0dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cD5IaSBhbGwsPG86cD48L286cD48 L3A+DQo8cD50byBtYWtlIHN1YnN0YW50aWF0ZWQgcmVjb21tZW5kYXRpb25zIGZvciBGQVBJIDIu MCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBQQVIsIGFuZCB0aGUgc2VjdXJpdHkg QkNQLCBJIGRpZCBhbm90aGVyIGFuYWx5c2lzIG9uIHRoZSB0aHJlYXRzIHRoYXQgYXJpc2UgZnJv bSBtaXgtdXAgYXR0YWNrcy4gSSB3YXMgaW50ZXJlc3RlZCBpbiBwYXJ0aWN1bGFyIGluIHR3byBx dWVzdGlvbnM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkRvZXMgUEFSIGhlbHAgcHJldmVu dGluZyBtaXgtdXAgYXR0YWNrcz88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpEbyB3ZSBuZWVkIEpBUk0gdG8gcHJldmVudCBt aXgtdXAgYXR0YWNrcz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkkgd3JvdGUgZG93biBzZXZl cmFsIGF0dGFjayB2YXJpYW50cyBhbmQgY29uZmlndXJhdGlvbnMgaW4gdGhlIGZvbGxvd2luZyBk b2N1bWVudDoNCjxhIGhyZWY9Imh0dHBzOi8vZGFuaWVsZmV0dC5naXRodWIuaW8vbm90ZXMvb2F1 dGgvTWl4LVVwJTIwUmV2aXNpdGVkLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGFu aWVsZmV0dC5naXRodWIuaW8vbm90ZXMvb2F1dGgvTWl4LVVwJTIwUmV2aXNpdGVkLmh0bWw8L2E+ PG86cD48L286cD48L3A+DQo8cD5UaGUga2V5IHRha2Vhd2F5cyBhcmU6PG86cD48L286cD48L3A+ DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMSBsZXZlbDEgbGZvMiI+DQpUaGUgc2VjdXJpdHkgQkNQIG5lZWRzIHRvIG1ha2UgY2xlYXIg dGhhdCBwZXItPGI+QVM8L2I+IHJlZGlyZWN0IFVSSXMgYXJlIG9ubHkgc3VmZmljaWVudCBpZiBP QXV0aCBNZXRhZGF0YSBpcyBub3QgdXNlZCB0byByZXNvbHZlIG11bHRpcGxlIGlzc3VlcnMuIE90 aGVyd2lzZSwgcGVyLTxiPklzc3VlcjwvYj4gcmVkaXJlY3QgVVJJcyBvciB0aGUgaXNzIHBhcmFt ZXRlciBNVVNUIGJlIHVzZWQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KUEFSLWVuYWJsZWQgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzIGNhbiBwcm90ZWN0IHRoZSBpbnRlZ3JpdHkgYmV0dGVyIGFuZCBwcm90ZWN0IGFnYWluc3Qg TWl4LVVwIEF0dGFja3MgYmV0dGVyIGlmIHRoZXkgT05MWSBhY2NlcHQgUEFSIHJlcXVlc3RzLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBs Zm8yIj4NCldlIHNob3VsZCBlbXBoYXNpemUgdGhlIGltcG9ydGFuY2Ugb2YgdGhlIGlzcyBwYXJh bWV0ZXIgKG9yIGlzc3VlcikgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UuIE1heWJlIGlu dHJvZHVjZSB0aGlzIHBhcmFtZXRlciBpbiB0aGUgc2VjdXJpdHkgQkNQIG9yIGFub3RoZXIgZG9j dW1lbnQ/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzIiPg0KU2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgaGVscCBhZ2Fp bnN0IG1peC11cCBhdHRhY2tzIHdoZW4gdGhlIGFjY2VzcyB0b2tlbiBpcyB0YXJnZXRlZC48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZv MiI+DQpTZW5kZXItY29uc3RyYWluaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgKFBBUiAmIzQz OyBQQVItRFBvUD8pIG1pZ2h0IGJlIHdvcnRoIGxvb2tpbmcgaW50by48bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjxwPkkgd291bGQgbGlrZSB0byBoZWFyIHlvdXIgdGhvdWdodHMhPG86cD48L286cD48 L3A+DQo8cD4tRGFuaWVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90Oy1hcHBsZS1zeXN0ZW0mcXVvdDssc2VyaWY7Y29sb3I6IzU1 NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuDQogQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBv dGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR00MB06866084FF95C4956A76B472F59B0MN2PR00MB0686namp_-- From nobody Sat Jun 20 12:34:29 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2E13A092D for ; Sat, 20 Jun 2020 12:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxoC1RwgmrF8 for ; Sat, 20 Jun 2020 12:34:25 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215293A092B for ; Sat, 20 Jun 2020 12:34:25 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id l10so12852714wrr.10 for ; Sat, 20 Jun 2020 12:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rKK+Y1zIRZSJINXPWA6mEouoTdV6IMF6wrL4utXv+9E=; b=sw8//wHc3rDIgcjM8U6xQltdaAY2UBxZAjExVanOL7kVCH7+hvUk47TB4p7uJ7R1vM 0hAR9jkKX3td2CqmAAIFSDDixSztr/nHZ036JwnigMelWLu6C8rFUjVA3rSAmGBLimVE TeKvkj4+Jl7JVCX0am6u6rdkpKHLU8mBe7bpEn8lJ+BfpuaFKF/T73xAYLKgOS1CD9gy M6oznxvb63zF5etlsBU360R3y0l7HRstvSf0Dt6mYe6dpfI8SgPna0pGpsq1awPhmhCW 8PK6/NJHjrFDcXFTGmVqZxi+iEt9jGR1Qw7a9e+bcHIFubh8mUWGB98jO/2sWTtu1fA8 GIWA== 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=rKK+Y1zIRZSJINXPWA6mEouoTdV6IMF6wrL4utXv+9E=; b=VRgO7srlAGKzG4TVJh/50t/8gdAvk8v6Ic/suJRH2JIQY+396QQLo70dTYxmqOtwxt nEmRYsGl5xaFKcfgQU7tCe8kqQoVQgsfp9npaVlXq+rix1JBld0m2wCqDPiyMVB2+reg TEGaWg5uKmmKfCMDOnGDCSEaYLLqt3cFwUCEVhn7s0F/PumPpsI1sk5t9zCt2cZDy8a/ XrUnusZcXKgC8SaVbMzlu6EoxfLgskUs9u9qqQ4lYjmwXIDo5q8P0wEkynSJ/YGAfPMI a6pEdrmP9JXGUHRorazP1LqTRBzcVIg1OE0VYb9IJTKTvIzFhc7xL8nR40NNfiX/f1I/ h7ow== X-Gm-Message-State: AOAM530AWp7XrIz3K25F7DlvVba0t6Gb+F5lgNHEl9swIGoRrxiaPvwc Ffrz+m27g53Iv+Tr5A6tignynlXxqitLbQJPdsLdpJyJ X-Google-Smtp-Source: ABdhPJyJ+9rOvLJB+2LkmuG3oZPyle6kiiUvCPAyavRHQlY4WBQD0Ta8QIZeGatvCSJOeniU/+/oi5Xmhge2BmsFVmE= X-Received: by 2002:adf:82d0:: with SMTP id 74mr9849358wrc.138.1592681663387; Sat, 20 Jun 2020 12:34:23 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 20 Jun 2020 15:34:11 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c95b6205a889183f" Archived-At: Subject: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jun 2020 19:34:27 -0000 --000000000000c95b6205a889183f Content-Type: text/plain; charset="UTF-8" All, As you know, IETF108 will be online, and based on the discussion during the last interim meeting series, our plan is to schedule another series of these meetings for the OAuth WG. Based on the WG feedback, the plan is to have a series of *one hour* meetings, and to discuss *one document* per meeting. Based on the above, we would like to get the WG opinion on the following proposal: 1. Meeting day/time would be *Monday @ 12:00pm Eastern Time *(same as the last interim series) 2. Have around 9 meetings spread over 3 months: - *July *meetings, before IETF108: *July 6, 13, and 20* - *August* meetings: *August 3, 10, 17* - *September *meetings: *September 7, 14, 21* Thoughts? Regards, Rifaat & Hannes --000000000000c95b6205a889183f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As you know, IETF108 will be onlin= e, and based on the discussion during the last interim meeting series, our = plan is to schedule=C2=A0another series of these meetings for the OAuth WG.=
Based on the WG feedback, the plan is to have a series of one= hour meetings, and to discuss one document per meeting.=C2=A0

Based on the above, we would like to get the WG opi= nion on the following proposal:

1. Meeting day/tim= e would be Monday @ 12:00pm Eastern Time (same as the last interim s= eries)

2. Have around 9 meetings spread over 3 mon= ths:
  • July meetings, before IETF108: July 6, 13,= and 20
  • August meetings: August 3, 10, 17
    • September meetings: September 7, 14, 21
=
Thoughts?=C2=A0

Regards,
=
=C2=A0Rifaat & Hannes

--000000000000c95b6205a889183f-- From nobody Sun Jun 21 11:42:40 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB043A07E0 for ; Sun, 21 Jun 2020 11:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrNiugy6xxPb for ; Sun, 21 Jun 2020 11:42:37 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D213D3A07F7 for ; Sun, 21 Jun 2020 11:42:36 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id g139so7547884lfd.10 for ; Sun, 21 Jun 2020 11:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d8xQDBJFdyFwo8H9dWDnbBgTi5H7ReKNLkPzfORNBlQ=; b=nQ3cNvpUrZRAaIiB6fadTxti7oj37A4WWVXbtLtPnVtysrP60YW/K7UVrQjxsiBt7m MsG11GCF7NOo0iGXwR/eAlHP2kCq3yD8BE/rDOJl0ziLBCuQSFl/v69bA7G4QrTRvaip Fw7PaPpCR3hrADR1pjNXB46GNRivb+OWeXV+RBJSxGXctUS5H6wPOSVUqiGkjzyEvkX6 K+qBTnkoTgGs47jWC2MCbM1VUVIE7aq9TT/oTKd2EWzkSP49SO5CAuUk9pT5ZvGKvIBB 09rlIWovYEPEHQ7LCNxWNdSTzhkJlZ/gck7NF5E+jkugNvGHESCql1q2ix3N4SVYeLAn bVYw== 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=d8xQDBJFdyFwo8H9dWDnbBgTi5H7ReKNLkPzfORNBlQ=; b=bGQB64c1+zE4seZY2XlhuPh1wXVfmzs1rDArTdgeKoZgLhI4epFGpwwEeuiDJNoznW jp6MUYG1ky+iIcz5EO2bXt/veATW5pCQSsw8BfFIwf8d8oSWGk+lrofq62Lw5EuRRlFa V/HEyEQ5wvZ2w06vmyxXbtFv/00O0qMCIY61Hkxr+bSSYrq55+RBmg5oiXfJw/4MphXc iNV9FO/SY+QY933R/PSw34TTUZhrn9PRzmL1wHyffKZYLxhKZ4E+0gfsGvhUWQ+KgaGH SI54yxTScsbLPcuCvR2h1T1x//AHECHUd9jc94MyqyVj9FJvSl0JYddIpCIndK60tSjE y/iQ== X-Gm-Message-State: AOAM531lzw4au1f+qVHnq4m7lKqDVdduAGo0ja6qmI5gL8/bIvC8sAWY i8KknIUAetC7q1eUB02AbLR/gt1fOnLTB00Y7CQ= X-Google-Smtp-Source: ABdhPJyH+Ufz2syAi+w8qGjKVIpOdYUQ5CsGylNKL0fRiOwxdsTY+4WSEwB2iiWjHGFhUNdBU2CvCqECYaJSAOgXgp0= X-Received: by 2002:a19:14e:: with SMTP id 75mr7839916lfb.7.1592764954678; Sun, 21 Jun 2020 11:42:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 21 Jun 2020 11:42:23 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000559b4d05a89c7d25" Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jun 2020 18:42:38 -0000 --000000000000559b4d05a89c7d25 Content-Type: text/plain; charset="UTF-8" +1 On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef wrote: > All, > > As you know, IETF108 will be online, and based on the discussion during > the last interim meeting series, our plan is to schedule another series of > these meetings for the OAuth WG. > Based on the WG feedback, the plan is to have a series of *one hour* > meetings, and to discuss *one document* per meeting. > > Based on the above, we would like to get the WG opinion on the following > proposal: > > 1. Meeting day/time would be *Monday @ 12:00pm Eastern Time *(same as the > last interim series) > > 2. Have around 9 meetings spread over 3 months: > > - *July *meetings, before IETF108: *July 6, 13, and 20* > - *August* meetings: *August 3, 10, 17* > - *September *meetings: *September 7, 14, 21* > > > Thoughts? > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000559b4d05a89c7d25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Sat, Jun 20, 2020 at 12:34 PM Rifaat= Shekh-Yusef <rifaat.s.ietf@g= mail.com> wrote:
All,
As you know, IETF108 will be online, and based on the discu= ssion during the last interim meeting series, our plan is to schedule=C2=A0= another series of these meetings for the OAuth WG.
Based on the W= G feedback, the plan is to have a series of one hour meetings, and t= o discuss one document per meeting.=C2=A0

B= ased on the above, we would like to get the WG opinion on the following pro= posal:

1. Meeting day/time would be Monday @ 12= :00pm Eastern Time (same as the last interim series)

2. Have around 9 meetings spread over 3 months:
  • July meetings, before IETF108: July 6, 13, and 20
  • Au= gust meetings: August 3, 10, 17
  • September meeting= s: September 7, 14, 21

Thoughts?= =C2=A0

Regards,
=C2=A0Rifaat & = Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000559b4d05a89c7d25-- From nobody Sun Jun 21 13:39:44 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A253A087C for ; Sun, 21 Jun 2020 13:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msnovatec.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 8_MR0DtPVHIv for ; Sun, 21 Jun 2020 13:39:41 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C193A087B for ; Sun, 21 Jun 2020 13:39:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UPZtf59Rzm/DuLTNDvWkcuo2mA5RyiYKSvcF7pk9Fng6+fF0PzKT7zvwCMZmyQ7VAxTrgjjKXcuyY+idf0QgZecndxuZH/0OEJFQxY4TAuitqEZrarjIVZzg2XDRHcjhGGf1x7yHeyoV3Sv6GCOtgzT9wPWDl5PmpyOWNC0vphfKLuYsJvjTT8Yv1x3SM3VsqGb3zoh88ykoLO2PQyGvQlTeSuTsa7xZxnH7TyAJd8fKyUZEZvAyyFqaPcKrSn0FefyxZc0EOzqIYtd5t2vN03m2gmY1MFCXnGj73C/Z6p7lfp3Jva7J8/sNoTtNvc8W4V+2z0BNewQX5jf/0idq0Q== 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=nqL2FktJ0MfLBFkg9W6TKcJ7xkgEni1ypLbDQ/QKeCs=; b=Q5/uMNvA8vaogJ+/ugELwJLbU3jSfvdQiV5QlvioKKNBaNpwID0c8pH9ZlfAFm5l7+em1WVTKZMAzdFk7Kb0lvNro2fDR7YfhTPBYLM9Z8Bq8Cw8KGiFRF0rzAOyt7eVm9LFJbU5Ld1weRHRWYVnZet4hOP6BZls3V0wGedgSq6wHYh4SOI+gceFSuU5pYhe7tn7MqDjDn7rN7nr3clcZS0JcdPMLgW4zIDSRfgLAflIW72PNBwjtUXGamMnjt8MPI+3tsjIgH+l+C5CCOBTG6335p1qRErSh3p/taYC4PTEGbPB9PQ8MFVbLIWdhJxhckOblRV5keGoAcFEygZdPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=novatec-gmbh.de; dmarc=pass action=none header.from=novatec-gmbh.de; dkim=pass header.d=novatec-gmbh.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msnovatec.onmicrosoft.com; s=selector2-msnovatec-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nqL2FktJ0MfLBFkg9W6TKcJ7xkgEni1ypLbDQ/QKeCs=; b=efBBf52AZc0hPhON5Ip4023eWXkOTOpFUaEtNrUR59hnW5uclWy5Gd4lRS7uKKwn0cx2b2dmR67xeQawNPLyazebir7c91dqtmBRchPrQNO+HgTqQiXpBxMaUnx+Gv732Rz9T1VW8s/u7mdVkQXYFLQ5kne7iyOPy462bGIAZQA= Received: from DBBPR04MB6203.eurprd04.prod.outlook.com (2603:10a6:10:c8::22) by DBBPR04MB6218.eurprd04.prod.outlook.com (2603:10a6:10:d0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Sun, 21 Jun 2020 20:39:37 +0000 Received: from DBBPR04MB6203.eurprd04.prod.outlook.com ([fe80::a465:a51d:3980:725e]) by DBBPR04MB6203.eurprd04.prod.outlook.com ([fe80::a465:a51d:3980:725e%4]) with mapi id 15.20.3109.026; Sun, 21 Jun 2020 20:39:37 +0000 From: Falk Andreas To: Dick Hardt , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 Thread-Index: AQHWRznk6xUv8jbpLEqCwDseJIO7O6jjaPOAgAAgc8s= Date: Sun, 21 Jun 2020 20:39:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=novatec-gmbh.de; x-originating-ip: [94.186.169.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ab554ec-b78a-42c1-58b0-08d8162336f1 x-ms-traffictypediagnostic: DBBPR04MB6218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:421; x-forefront-prvs: 04410E544A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gDXzb+wmWyL0xDo+srV0IQ+/ecpSDI/QR8LjaSQXVwlMwSvSfXgylVH7vaPP2NNAHmR8UZkgQi6NrCdLnqziyb14nf2Mj3e1pWfD4/MFi8QBbcWbUc2sBPV6GJ3X8aMfBdIvSBMuQeAOf0jI9CiyjRn6sqLVTTq0FZqzj0XYW6RKZO3N92x0/KHNAGfW5prbLYk+t4oVWOQQ8uOuvEGc+7CyVhZgWZx0ERgNoY5qvi3ZA5pLiaIOcgZKKL2gP7JTn063ZTbpQcNpogNpxeK3Qp1xgsX4f6FyQt2Xlf0rfQn308UwVPeKiPhnhCGI0jklAh7E+BFce+Za5kSXAUr862SyiOO6FoMq69ILt++H0aIXEm/bogweXKoQ68khRpklfc0Y+ZU5EqhJlW30BWFv+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR04MB6203.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(376002)(136003)(39830400003)(346002)(366004)(66946007)(316002)(110136005)(9686003)(186003)(8676002)(19627405001)(55016002)(4326008)(6506007)(53546011)(83380400001)(52536014)(7696005)(33656002)(8936002)(166002)(66556008)(66476007)(64756008)(66446008)(76116006)(26005)(86362001)(2906002)(966005)(5660300002)(508600001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Eov3IfbBtyrbWsTdc0wJ1kTTFpEExZxHZgQxVpxMbHWq1Tg0ru5plgXJttn/NfGTQooveqtkDwAo8atLuAkqeOUESHjyENL+jTK0scp1Wlu9AxvjpBWR77T8djbQ4xJHF+HTvJ81/S2yEPHzWqQzthrrXbTY+hh8p4AexxV3O+LCe3CurvuvJzw4O+ssb0c0930QXvpd1s5gqdRHQOgtds4Uw2bg4YGERYKKrA+75B1rRmmaGRxkP4eofKMRlc6lKeG/zwKY0dnKxbETQjwwYKVFkeHe9GUX/QLpNNH427AqEZUsxRFYrtTJG0LxXrqqlxpA6AxjG8Gv8YBnnCb2bq347hDaZe1W3cpn25PlXxAPQpsQczL2eze9V0Jk0ofjNdrEsbJu65DtZhqBs0uE6ffYeWq1Cx5wrtHgVeTkpQfq+17x5wBoCiRvEjWIvxUtXo9MpFlyuzqGQZLk9KaRv/FXyHICEWFcc8ak24xe4CI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR04MB62030791FDEE994D12636416DC960DBBPR04MB6203eurp_" MIME-Version: 1.0 X-OriginatorOrg: novatec-gmbh.de X-MS-Exchange-CrossTenant-Network-Message-Id: 6ab554ec-b78a-42c1-58b0-08d8162336f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2020 20:39:37.3808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ea17416-affd-4b68-a5a5-9f2de2d9c1f9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bcvKUZ0X0OS+nAWMcfojOzbSoMcdbqCaAvOU7dpJFTFFRjbiykS3id5Ef2NcRP5A/kzXpUv9HjamQM0okzA+Ow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR04MB6218 Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jun 2020 20:39:44 -0000 --_000_DBBPR04MB62030791FDEE994D12636416DC960DBBPR04MB6203eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ________________________________ Von: OAuth im Auftrag von Dick Hardt Gesendet: Sonntag, 21. Juni 2020 20:42 An: Rifaat Shekh-Yusef Cc: oauth Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place o= f IETF108 +1 On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef > wrote: All, As you know, IETF108 will be online, and based on the discussion during the= last interim meeting series, our plan is to schedule another series of the= se meetings for the OAuth WG. Based on the WG feedback, the plan is to have a series of one hour meetings= , and to discuss one document per meeting. Based on the above, we would like to get the WG opinion on the following pr= oposal: 1. Meeting day/time would be Monday @ 12:00pm Eastern Time (same as the las= t interim series) 2. Have around 9 meetings spread over 3 months: * July meetings, before IETF108: July 6, 13, and 20 * August meetings: August 3, 10, 17 * September meetings: September 7, 14, 21 Thoughts? Regards, Rifaat & Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_DBBPR04MB62030791FDEE994D12636416DC960DBBPR04MB6203eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1
Von: OAuth <oauth-bounce= s@ietf.org> im Auftrag von Dick Hardt <dick.hardt@gmail.com>
Gesendet: Sonntag, 21. Juni 2020 20:42
An: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in = place of IETF108
 
+1

On Sat, Jun 20, 2020 at 12:34 PM Ri= faat Shekh-Yusef <rifaat.s.ie= tf@gmail.com> wrote:
All,

As you know, IETF108 will be online, and based on the discussion durin= g the last interim meeting series, our plan is to schedule another ser= ies of these meetings for the OAuth WG.
Based on the WG feedback, the plan is to have a series of one hour<= /b> meetings, and to discuss one document per meeting. 

Based on the above, we would like to get the WG opinion on the followi= ng proposal:

1. Meeting day/time would be Monday @ 12:00pm Eastern Time (sam= e as the last interim series)

2. Have around 9 meetings spread over 3 months:
  • July meetings, before IETF108: July 6, 13, and 20
    • August meetings: August 3, 10, 17
  • September m= eetings: September 7, 14, 21

Thoughts? 

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_DBBPR04MB62030791FDEE994D12636416DC960DBBPR04MB6203eurp_-- From nobody Sun Jun 21 14:41:40 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D19F3A00D4 for ; Sun, 21 Jun 2020 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo50PlsAsRAV for ; Sun, 21 Jun 2020 14:41:36 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21673A00D2 for ; Sun, 21 Jun 2020 14:41:36 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id mb16so16013680ejb.4 for ; Sun, 21 Jun 2020 14:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=M3cyze8/2Z+HVZUSjxCWCXer1vFROgNS8FCGHp64dHw=; b=vPK5tN2asQ8F74//KBoFmBlEwNlhrnx/NM1BQlRxwhmdrM+pN9GkVZ1J/3O2r8BCeA 1h6kU9pbzYGG1XLxkt9fj0JkSY5r5MH2vQ687uOE79tj0Q0nW4z64LxYlQtsm2AJQJSY 8yEOK1K/i2pSw/JBSlrmIR28RfInOXDn/O4nUiNyolPzMCRsVS4g4Rslw1OS93CaRHMK ZZx5GIJhQNr9/yqitv9P5IDZy8Xqn5pZKSumg9BfpS0s8HSNdRbQJ1+NZ0sDddY6Gwze kXptLLl1KORsfI+wgahCEV6xbPPaKwbsyPEEB1C8Yu211a3J626TMRhK2jYOKbDg/emc Xj+w== 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=M3cyze8/2Z+HVZUSjxCWCXer1vFROgNS8FCGHp64dHw=; b=gECPpjSxN1yc5xLm9UL8y9hKTsrdv9OvhvuB/WjBF5+kcnhk7JXlg6qXMB7rwT/ZKX G6oUoQqlGuSrQFWMDiRqysGVwjY3vwPIg2MERE0gar4LOEPTUjCFoPs6/cOQAiDTmEd5 V7KdhasBi8TA7KFpgWIKOkfwSuxJ8VU5ZpXTdFMewp9CRcDA1aQ8O1goU2NFRC7ayY8G 8+rQpPQyuxRpH0VyI+KU6/MlTEEwTP+7zi+GWmoda1A1sVXaxRIyNiftXHzKlJkP/Wd5 urzXOta3WrALCzfE/aBQHrpOas5HheahXZEfqkOPoV+SZ5y+ULmdkFgwvkcmpUijvWm5 4w5w== X-Gm-Message-State: AOAM530FNTh6qJacZbmeWdV7CUBGsdYo3nDvImBBmqlZXCVdWu93nYMQ HFBXvuQxBOiVBLXDBsYqtxukjg== X-Google-Smtp-Source: ABdhPJzHaV4j7d6DBvSy5vfSYbpCJWTaWX08oNXKFJCZFufUly6Iun7hvQ5kMPNvbPQs89QHNw5I/w== X-Received: by 2002:a17:907:94cf:: with SMTP id dn15mr10068887ejc.457.1592775695018; Sun, 21 Jun 2020 14:41:35 -0700 (PDT) Received: from ?IPv6:2003:eb:8f26:af0d:b9b3:2309:e90e:80d9? (p200300eb8f26af0db9b32309e90e80d9.dip0.t-ipconnect.de. [2003:eb:8f26:af0d:b9b3:2309:e90e:80d9]) by smtp.gmail.com with ESMTPSA id m13sm441098ejc.1.2020.06.21.14.41.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jun 2020 14:41:34 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-3A327007-61F8-445D-93C3-549D2BB96F52; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 21 Jun 2020 23:41:32 +0200 Message-Id: References: Cc: Dick Hardt , Rifaat Shekh-Yusef , oauth In-Reply-To: To: Falk Andreas X-Mailer: iPad Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jun 2020 21:41:39 -0000 --Apple-Mail-3A327007-61F8-445D-93C3-549D2BB96F52 Content-Type: multipart/alternative; boundary=Apple-Mail-4E8BCB20-72E9-4E16-BEA3-BF500DE385FF Content-Transfer-Encoding: 7bit --Apple-Mail-4E8BCB20-72E9-4E16-BEA3-BF500DE385FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 > Am 21.06.2020 um 22:39 schrieb Falk Andreas = : >=20 > =EF=BB=BF > +1 > Von: OAuth im Auftrag von Dick Hardt > Gesendet: Sonntag, 21. Juni 2020 20:42 > An: Rifaat Shekh-Yusef > Cc: oauth > Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place o= f IETF108 > =20 > +1 >=20 > On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef wrote: > All, >=20 > As you know, IETF108 will be online, and based on the discussion during th= e last interim meeting series, our plan is to schedule another series of the= se meetings for the OAuth WG. > Based on the WG feedback, the plan is to have a series of one hour meeting= s, and to discuss one document per meeting.=20 >=20 > Based on the above, we would like to get the WG opinion on the following p= roposal: >=20 > 1. Meeting day/time would be Monday @ 12:00pm Eastern Time (same as the la= st interim series) >=20 > 2. Have around 9 meetings spread over 3 months: > July meetings, before IETF108: July 6, 13, and 20 > August meetings: August 3, 10, 17 > September meetings: September 7, 14, 21 >=20 > Thoughts?=20 >=20 > Regards, > Rifaat & Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4E8BCB20-72E9-4E16-BEA3-BF500DE385FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1
<= br>
Am 21.06.2020 um 22:39 schrieb Falk Andreas <= ;Andreas.Falk@novatec-gmbh.de>:

=EF=BB=BF =
+1
Von: OAuth <oauth-bounces@= ietf.org> im Auftrag von Dick Hardt <dick.hardt@gmail.com>
Gesendet: Sonntag, 21. Juni 2020 20:42
An: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in p= lace of IETF108
 
+1

On Sat, Jun 20, 2020 at 12:34 PM Rif= aat Shekh-Yusef <rifaat.s.ietf= @gmail.com> wrote:
All,

As you know, IETF108 will be online, and based on the discussion during= the last interim meeting series, our plan is to schedule another serie= s of these meetings for the OAuth WG.
Based on the WG feedback, the plan is to have a series of one hour meetings, and to discuss one document per meeting. 

Based on the above, we would like to get the WG opinion on the followin= g proposal:

1. Meeting day/time would be Monday @ 12:00pm Eastern Time (same= as the last interim series)

2. Have around 9 meetings spread over 3 months:
  • July meetings, before IETF108: July 6, 13, and 20
  • = August meetings: August 3, 10, 17
  • September mee= tings: September 7, 14, 21

Thoughts? 

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-4E8BCB20-72E9-4E16-BEA3-BF500DE385FF-- --Apple-Mail-3A327007-61F8-445D-93C3-549D2BB96F52 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjIxMjE0MTMzWjAvBgkqhkiG9w0BCQQxIgQg SA85iQOxDBNkTdteAa4unedY5yP6XhAm6cTKrKeR2vIwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAYc2I2Merw2rjLdNz1PkWPE9Q+4OcvFclXsT2Q8hcbDPJkxrwbrIb TCJQJ9av8qHoajJ1OqFrZ2B1lnnMmOAbuycgxhmFPpN+PW09Uo5CFlQAbtAQDdV8dStJ3bYIpRP4 gAlprdxeQ+glbMld3ylSENdcmM0qFVyKrtjhV262icw9DktXHh8xb0efZajxAgpHPCViqqPk4u4J GV2eItzb6hAMzcgFIYxzVmbSdlKNk1cOFzy5duAJ7IKRh4enALTy4I3ZA1p3i/y6vwg4pQJ5vUy0 56fCyQdiUEK5uEth22nc08YhMKmI9tUg5XmUKNdf54addjOCAs6iI2488rVHvgAAAAAAAA== --Apple-Mail-3A327007-61F8-445D-93C3-549D2BB96F52-- From nobody Sun Jun 21 17:58:41 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207EE3A082B for ; Sun, 21 Jun 2020 17:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgU8FgxDJLDG for ; Sun, 21 Jun 2020 17:58: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 BD9383A081C for ; Sun, 21 Jun 2020 17:58:38 -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 05M0wU8F009046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jun 2020 20:58:32 -0400 Date: Sun, 21 Jun 2020 17:58:29 -0700 From: Benjamin Kaduk To: Daniel Fett Cc: Filip Skokan , oauth@ietf.org Message-ID: <20200622005829.GH11992@kduck.mit.edu> References: <79d39d11-f812-07bb-7a60-5c3bf7162c0a@danielfett.de> <20200608225031.GB58497@mit.edu> <61e18e42-e878-9f2c-3a6c-5c0d993a1ac5@danielfett.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61e18e42-e878-9f2c-3a6c-5c0d993a1ac5@danielfett.de> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 00:58:40 -0000 On Tue, Jun 09, 2020 at 09:42:27AM +0200, Daniel Fett wrote: > Am 09.06.20 um 00:50 schrieb Benjamin Kaduk: > > On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: > >> Hi Filip, > >> > >> Thanks for your answers! > >> > >> I'm not quite sure if the wording in my question was clear: My main > >> concern is the difference between > >> https://example.com/some/path*/.well-known/oauth-authorization-server* > >> and > >> https://example.com*/.well-known/oauth-authorization-server*/some/path, > >> i.e., the usage of the well-known URI as a postfix or as an infix. > > .well-known is only defined at the root of the path component of a URI. > > Usage such as > > https://example.com/some/path*/.well-known/oauth-authorization-server* is > > noncompliant with RFC 5785. > > I know, but my impression is that since OIDC did it this way, some > clients are expecting the same behavior for RFC8414. Thus the question > if AS should be allowed or even required to offer the postfix variant in > an ecosystem. Hmm, we don't seem to have gotten many replies on this question. My own individual opinion is "no", roughly on the grounds that doing it in the wild starts a slippery slope and we don't want to get in the business of encouraging BCP 190 violations. -Ben From nobody Mon Jun 22 06:51:13 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3923A0D36 for ; Mon, 22 Jun 2020 06:51:12 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0i9YSyKRpYO for ; Mon, 22 Jun 2020 06:51:10 -0700 (PDT) Received: from rhcavuit03.kulnet.kuleuven.be (rhcavuit03.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DAC3A0D35 for ; Mon, 22 Jun 2020 06:51:08 -0700 (PDT) X-KULeuven-Envelope-From: pieter.philippaerts@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 49487120337.A24D9 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by rhcavuit03.kulnet.kuleuven.be (Postfix) with ESMTP id 49487120337 for ; Mon, 22 Jun 2020 15:51:05 +0200 (CEST) Received: from ICTS-S-EXMBX25.luna.kuleuven.be (icts-s-exmbx25.luna.kuleuven.be [10.112.11.60]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPS id 364F6200A3 for ; Mon, 22 Jun 2020 15:51:05 +0200 (CEST) Received: from ICTS-S-EXMBX19.luna.kuleuven.be (10.112.11.50) by ICTS-S-EXMBX25.luna.kuleuven.be (10.112.11.60) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 15:51:04 +0200 Received: from ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396]) by ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396%21]) with mapi id 15.00.1497.006; Mon, 22 Jun 2020 15:51:04 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Philippaerts To: "oauth@ietf.org" Thread-Topic: OAuth services/libraries wanted for security evaluation... Thread-Index: AQHWSJv/CEiq3qLLQkSm2HSHXzeoXw== Date: Mon, 22 Jun 2020 13:51:04 +0000 Message-ID: <1592833863766.52147@kuleuven.be> Accept-Language: en-US, nl-BE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.112.50.1] Content-Type: multipart/alternative; boundary="_000_159283386376652147kuleuvenbe_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 13:51:12 -0000 --_000_159283386376652147kuleuvenbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, As part of a research project, I've created a test suite to test OAuth 2.0 = implementations and measure how well they implement the various MAY/SHOULD/= MUST security recommendations in the OAuth standards. (It also includes tes= t cases for the OIDC and FAPI RO/RW recommendations.) The tool is practical= ly finished and will be made available to the public in a few months. I'm currently working on a security analysis of the OAuth2 ecosystem (i.e. = I'm using the tool to test various OAuth/OIDC implementations) and I'm stil= l looking for more candidates to test. If you are the author of an OAuth li= brary or if you are running an OAuth service, feel free to contact me to ge= t involved. Apart from my gratitude, I can offer you a free security audit = of your product :-) Regards, Pieter --_000_159283386376652147kuleuvenbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone,

As part of a research project, I've created a test suite to test = OAuth 2.0 implementations and measure how well they implement the various M= AY/SHOULD/MUST security recommendations in the OAuth standards. (It also in= cludes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made = available to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosystem (= i.e. I'm using the tool to test various OAuth/OIDC implementations) and I'm= still looking for more candidates to test. If you are the author of an OAu= th library or if you are running an OAuth service, feel free to contact me to get involved. Apart from my g= ratitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


--_000_159283386376652147kuleuvenbe_-- From nobody Mon Jun 22 07:52:11 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348483A0D90 for ; Mon, 22 Jun 2020 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=ficksworkshop.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRqEoNNL2w7k for ; Mon, 22 Jun 2020 07:52:08 -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 698823A0D8C for ; Mon, 22 Jun 2020 07:52:08 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id l17so15681466qki.9 for ; Mon, 22 Jun 2020 07:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ficksworkshop.com; s=google-ficksworkshop; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=EPDP5dH9gzuv9DyH6Wim7QscQUA9iX1AuZ2HomlzwBk=; b=FAjdFCz8cFrgZjRi+Ymr+y6SVzBjOQQC0yQbx6t+l8EqgSYr2QFyw8Ri6E1oKnk1sY YJCQY14uEjnIlpcOuWU+6JkelZcrJOs3VQe8pLuLr1Dkm2g9dS7XM5OCeQiZw7cDblVi vF3O44WJAj43TOmTEQXzv4GfZIxmR2Ohm+Ne+ss8gYWXAuXKErxSPMQh8wolIYfy6j/X D9wp0wNXUoOmQEHZS2gIEIb8PjTYVRCdrY+w/opaK8swL2j3I6S/Nx2xk8rULduj6SeW 3nA+vttqTDSXQAoxO+jVZwLGpp2e7gDoBMJLDsRaVN5SHzZOZRq+4uDQseKSP6LLuD9v LpCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=EPDP5dH9gzuv9DyH6Wim7QscQUA9iX1AuZ2HomlzwBk=; b=mFzJ61gylEQkNGWlNcRXZKb6FPaJV690QL3aXuYYHvKe2rFRbCPR7nSKtTU/3WjaA6 B4yzsQ0HhYe2AsE9jB47lElRELwGipww3X+k6VUp5PqPcoyhbh1gUEFdGPNM7mEcw+jK SihzW/SnsGXiM8OTyIS4j89JEXbGh+ILY1S/Y6QZH/PznTD3yjFnAyfusDgCJdUJT48W OFGHy3hBEcG+5DcHEUTrw18shhOQxnwfdi6pfKhw96IsiYYJkt9Bhg30HwL1AFW4fVOs OW9JblbPEEi9IZoJ3AsKSKPvZOdLzcDrXxuoi+JGGGlhsMip6HTOv7hWTEoEHx/2D3i5 k1+w== X-Gm-Message-State: AOAM532+F/qTiIdSgLsSj+bH525pFQW+C6ATbkcEqbe6W7d9z+n7xaOO tyhTLAdHuN+HUnqsj6NjlNBJy4zHXeY= X-Google-Smtp-Source: ABdhPJwQTH/7B0XMFchxEJzL233oPLAcK/ZybzgIQBHUgSH9YXCAAmIwiYiCHD3he9nzhDQxcAWmCA== X-Received: by 2002:ae9:c00d:: with SMTP id u13mr16477969qkk.434.1592837526964; Mon, 22 Jun 2020 07:52:06 -0700 (PDT) Received: from MN2PR18MB3445.namprd18.prod.outlook.com ([2603:1036:302:417f::5]) by smtp.gmail.com with ESMTPSA id x144sm3705986qkb.93.2020.06.22.07.52.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 07:52:06 -0700 (PDT) From: Garret Fick To: "oauth@ietf.org" , Pieter Philippaerts Thread-Topic: OAuth services/libraries wanted for security evaluation... Thread-Index: ATcyNjMzZP7CgsRuN/OBtg4Devk2MTBFNzQz X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 22 Jun 2020 14:52:05 +0000 Message-ID: References: <1592833863766.52147@kuleuven.be> In-Reply-To: <1592833863766.52147@kuleuven.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_MN2PR18MB344554A4ECFD677AC0CD7EF1AB970MN2PR18MB3445namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 14:52:10 -0000 --_000_MN2PR18MB344554A4ECFD677AC0CD7EF1AB970MN2PR18MB3445namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pieter, I am responsible for a very large private OAuth2 and OIDC implementation. I= would be highly interested in learning more about your tool if it is avail= able as code. Garret ________________________________ From: OAuth on behalf of Pieter Philippaerts Sent: Monday, June 22, 2020 9:51:04 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth services/libraries wanted for security evaluation= ... Hello everyone, As part of a research project, I've created a test suite to test OAuth 2.0 = implementations and measure how well they implement the various MAY/SHOULD/= MUST security recommendations in the OAuth standards. (It also includes tes= t cases for the OIDC and FAPI RO/RW recommendations.) The tool is practical= ly finished and will be made available to the public in a few months. I'm currently working on a security analysis of the OAuth2 ecosystem (i.e. = I'm using the tool to test various OAuth/OIDC implementations) and I'm stil= l looking for more candidates to test. If you are the author of an OAuth li= brary or if you are running an OAuth service, feel free to contact me to ge= t involved. Apart from my gratitude, I can offer you a free security audit = of your product :-) Regards, Pieter --_000_MN2PR18MB344554A4ECFD677AC0CD7EF1AB970MN2PR18MB3445namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Pieter,

I am responsible for a very large private OAuth2 and OIDC implementation. I= would be highly interested in learning more about your tool if it is avail= able as code.

Garret
From: OAuth <oauth-bounc= es@ietf.org> on behalf of Pieter Philippaerts <pieter.philippaerts@ku= leuven.be>
Sent: Monday, June 22, 2020 9:51:04 AM
To: oauth@ietf.org <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth services/libraries wanted for security eva= luation...
 
Hello everyone,

As part of a research project, I've created a test suite to test = OAuth 2.0 implementations and measure how well they implement the various M= AY/SHOULD/MUST security recommendations in the OAuth standards. (It also in= cludes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made = available to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosystem (= i.e. I'm using the tool to test various OAuth/OIDC implementations) and I'm= still looking for more candidates to test. If you are the author of an OAu= th library or if you are running an OAuth service, feel free to contact me to get involved. Apart from my g= ratitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


--_000_MN2PR18MB344554A4ECFD677AC0CD7EF1AB970MN2PR18MB3445namp_-- From nobody Mon Jun 22 08:01:37 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BAF3A0DE1 for ; Mon, 22 Jun 2020 08:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_rc2aUsqIX3 for ; Mon, 22 Jun 2020 08:01:30 -0700 (PDT) Received: from rhcavuit03.kulnet.kuleuven.be (rhcavuit03.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C523A0DA2 for ; Mon, 22 Jun 2020 08:01:29 -0700 (PDT) X-KULeuven-Envelope-From: pieter.philippaerts@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 61B6812032F.A4287 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by rhcavuit03.kulnet.kuleuven.be (Postfix) with ESMTP id 61B6812032F for ; Mon, 22 Jun 2020 17:01:25 +0200 (CEST) Received: from ICTS-S-EXMBX18.luna.kuleuven.be (icts-s-exmbx18.luna.kuleuven.be [10.112.11.49]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTPS id 3E3A340B5; Mon, 22 Jun 2020 17:01:25 +0200 (CEST) Received: from ICTS-S-EXMBX19.luna.kuleuven.be (10.112.11.50) by ICTS-S-EXMBX18.luna.kuleuven.be (10.112.11.49) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 22 Jun 2020 17:01:24 +0200 Received: from ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396]) by ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396%21]) with mapi id 15.00.1497.006; Mon, 22 Jun 2020 17:01:24 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Philippaerts To: Aaron Parecki , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... Thread-Index: AQHWSJv/CEiq3qLLQkSm2HSHXzeoX6jkiRsAgAAsdDM= Date: Mon, 22 Jun 2020 15:01:24 +0000 Message-ID: <1592838083725.90090@kuleuven.be> References: <1592833863766.52147@kuleuven.be>, In-Reply-To: Accept-Language: en-US, nl-BE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.112.50.1] Content-Type: multipart/alternative; boundary="_000_159283808372590090kuleuvenbe_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 15:01:37 -0000 --_000_159283808372590090kuleuvenbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Aaron, > * Whether an AS token endpoint rejects a request that contains a PKCE cod= e_verifier > if the authorization code was issued with no code_challenge present This is indeed one of the test cases. Out of the small set of 15 sites I ha= ve currently tested (major providers - think Google, Microsoft, Facebook, .= ..), the results are the following: - 7 sites do not implement PKCE (they ignore the parameters altogether) - 3 sites have PKCE support but do not detect the downgrade - 3 sites have PKCE support and detect the downgrade - 2 sites do not use the authorization code grant > * Whether an OIDC client uses PKCE > * Whether an OIDC client that does not use PKCE properly checks the nonce= value (for all response types) I should have been more specific in my first email: the test suite tests se= rver implementations, not client implementations. The framework is basicall= y a (malicious) client. I've thought about testing clients, but it seems mu= ch harder. A number of the client security guidelines are difficult to test= (e.g. "the client secret should be stored securely"), and the testing proc= edure will likely not support a high degree of automation. But it is someth= ing I'm interested in investigating further in a follow-up project. ? Regards, Pieter ________________________________ From: Aaron Parecki Sent: Monday, June 22, 2020 16:03 To: Pieter Philippaerts Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evalua= tion... Hi Pieter, This sounds like a great project! Can you make sure to test these things, I would be very curious to see the = result and it will help inform some of the future work in the Security BCP = and OAuth 2.1. * Whether an AS token endpoint rejects a request that contains a PKCE code_= verifier if the authorization code was issued with no code_challenge presen= t * Whether an OIDC client uses PKCE * Whether an OIDC client that does not use PKCE properly checks the nonce v= alue (for all response types) Thank you! --- Aaron Parecki https://aaronparecki.com On Mon, Jun 22, 2020 at 6:51 AM Pieter Philippaerts > wrote: Hello everyone, As part of a research project, I've created a test suite to test OAuth 2.0 = implementations and measure how well they implement the various MAY/SHOULD/= MUST security recommendations in the OAuth standards. (It also includes tes= t cases for the OIDC and FAPI RO/RW recommendations.) The tool is practical= ly finished and will be made available to the public in a few months. I'm currently working on a security analysis of the OAuth2 ecosystem (i.e. = I'm using the tool to test various OAuth/OIDC implementations) and I'm stil= l looking for more candidates to test. If you are the author of an OAuth li= brary or if you are running an OAuth service, feel free to contact me to ge= t involved. Apart from my gratitude, I can offer you a free security audit = of your product :-) Regards, Pieter _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_159283808372590090kuleuvenbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Aaron,


> * Whether an AS token = endpoint rejects a request that contains a PKCE code_verifier

> if the authorization c= ode was issued with no code_challenge present


This is indeed one of the test cases. Out of the small set of 15 sites= I have currently tested (major providers - think Google, Microsoft, F= acebook, ...), the results are the following:
 - 7 sites do not implement PKCE (they ignore the parameters alto= gether)

 - 3 sites have PKCE support but do not detect the downgrade

 - 3 sites have PKCE support and detect the downgrade

 - 2 sites do not use the authorization code grant


> * Whether an OIDC clie= nt uses PKCE 

> * Whether an OIDC client that does not use PKCE properly checks t= he nonce value (for all response types)

I should have been more specific in my first email: the test suite tests se= rver implementations, not client implementations. The framework is basicall= y a (malicious) client. I've thought about testing clients, but it seems mu= ch harder. A number of the client security guidelines are difficult to test (e.g. "the client secret should= be stored securely"), and the testing procedure will likely not suppo= rt a high degree of automation. But it is something I'm interested in = investigating further in a follow-up project.

​

Regards,

Pieter



From: Aaron Parecki <aar= on@parecki.com>
Sent: Monday, June 22, 2020 16:03
To: Pieter Philippaerts
Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security= evaluation...
 
Hi Pieter,

This sounds like a great project! 

Can you make sure to test these things, I would be very curious to see= the result and it will help inform some of the future work in the Security= BCP and OAuth 2.1.

* Whether an AS token endpoint rejects a request that contains a PKCE = code_verifier if the authorization code was issued with no code_challenge p= resent
* Whether an OIDC client uses PKCE 
* Whether an OIDC client that does not use PKCE properly checks the no= nce value (for all response types)

Thank you!

---
Aaron Parecki


On Mon, Jun 22, 2020 at 6:51 AM Piete= r Philippaerts <piete= r.philippaerts@kuleuven.be> wrote:
Hello everyone,

As part of a research project, I've created a test suite to test = OAuth 2.0 implementations and measure how well they implement the various M= AY/SHOULD/MUST security recommendations in the OAuth standards. (It also in= cludes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made = available to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosystem (= i.e. I'm using the tool to test various OAuth/OIDC implementations) and I'm= still looking for more candidates to test. If you are the author of an OAu= th library or if you are running an OAuth service, feel free to contact me to get involved. Apart from my g= ratitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_159283808372590090kuleuvenbe_-- From nobody Mon Jun 22 08:24:56 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B483A0D9F for ; Mon, 22 Jun 2020 08:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PQGKBYRo6Ns for ; Mon, 22 Jun 2020 08:24:53 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1C43A0D93 for ; Mon, 22 Jun 2020 08:24:53 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id y10so4037774eje.1 for ; Mon, 22 Jun 2020 08:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=wn6+12zbTMCm0+8QyVDmG6gPorLIF6lRLY0PEycMFNI=; b=Hwz5p/yjyeywV7ySqam2MEbq+Hf9mVgYlIRZPeoeLVn3nYgEHd9VOMw7MqfEiv4/o/ /IzVAXe+xu8NgjifQEBJtePiCb4wGDlOQennLdNIS5So/apgklcW8UsxytQNERj5/62g DgtxWtskq6mqyLPKOIk6jjCebnJOGnfSIfURivaZBwoATos5VLrbB8WQoNLPQJZ/CyKd R7EVv2jcZPoHxDrrsOOJX1+SYRghEADcTlSnFRnoGctGgboDIxgwGUREU1FspA7imR95 VhiTRdbXgrj0vlhrw1vmbP725Ge06FX2uLxJ6bpx8go0zNWKisXx3SYbaNvLpclxeL9D kIMQ== 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=wn6+12zbTMCm0+8QyVDmG6gPorLIF6lRLY0PEycMFNI=; b=jVGp7BEkshyNoMCPpK3TuILV+MbJmSBvqqXxPgeY3hGHCmjyzsA9OxGwfWIG4KabRv 2HmxSmFeL/KSHrcLz4Vf/mHjI6D530TOd07VMVzeoF5GCbWnwv73bNgVg/+92013TFyY XUECKM/ust7ujUYXh1bbV0m9XOk1C+G4QKsmxsXJ8Quwn0j5gYQpa8QOp+SivRqAJGcH RbsAzoGx4tUv5zpwIpLnCvp1vk27n9Fkb5VgPrzh2n1rz+Rl7hoWjVARE4Zg7+8f2DXX GZBXV8SzQzFv2IXFdQG9gfNsThk+DFRo1XnRaYXVNvmyfKET41wjwALTihWoSPmpJKID tn7w== X-Gm-Message-State: AOAM532CtZC/vdpxq6GS6xYpc2fHRNHWA2PSUdUsQGWiBw1UOAICHcwL dD6AOIQ8lF4cu05BLCRBuaOv2lnXAA== X-Google-Smtp-Source: ABdhPJz8R8zyBbnYgvfexwN7WpilZ98cDQ5F/iUysJxu0n115RxHqSfMEd1iVT1sdfybqapfVDHUHg== X-Received: by 2002:a17:906:3407:: with SMTP id c7mr2997183ejb.284.1592839491732; Mon, 22 Jun 2020 08:24:51 -0700 (PDT) Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id v23sm12457172edr.94.2020.06.22.08.24.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 08:24:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9962E026-0586-499A-AEA2-9A9B4DFAD205 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Mon, 22 Jun 2020 17:24:46 +0200 Message-Id: <33E98F20-6AF6-4A4D-A626-B9C4DA7C64C9@gmail.com> References: <1592833863766.52147@kuleuven.be> Cc: "oauth@ietf.org" In-Reply-To: <1592833863766.52147@kuleuven.be> To: Pieter Philippaerts X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 15:24:55 -0000 --Apple-Mail-9962E026-0586-499A-AEA2-9A9B4DFAD205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Pieter,=20 I=E2=80=99m interested for my open source project.=20 Filip Odesl=C3=A1no z iPhonu > 22. 6. 2020 v 15:51, Pieter Philippaerts = : >=20 > =EF=BB=BF > Hello everyone, >=20 > As part of a research project, I've created a test suite to test OAuth 2.0= implementations and measure how well they implement the various MAY/SHOULD/= MUST security recommendations in the OAuth standards. (It also includes test= cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically= finished and will be made available to the public in a few months. >=20 > I'm currently working on a security analysis of the OAuth2 ecosystem (i.e.= I'm using the tool to test various OAuth/OIDC implementations) and I'm stil= l looking for more candidates to test. If you are the author of an OAuth lib= rary or if you are running an OAuth service, feel free to contact me to get i= nvolved. Apart from my gratitude, I can offer you a free security audit of y= our product :-) >=20 > Regards, > Pieter >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9962E026-0586-499A-AEA2-9A9B4DFAD205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Pieter, 

I=E2= =80=99m interested for my open source project. 

Filip

Odesl=C3=A1no z iPhonu

22. 6. 2020 v 15:51, Pieter Philipp= aerts <pieter.philippaerts@kuleuven.be>:

=EF=BB=BF
Hello everyone,

As part of a research project, I've created a test suite to test O= Auth 2.0 implementations and measure how well they implement the various MAY= /SHOULD/MUST security recommendations in the OAuth standards. (It also inclu= des test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made a= vailable to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosystem (i= .e. I'm using the tool to test various OAuth/OIDC implementations) and I'm s= till looking for more candidates to test. If you are the author of an OAuth l= ibrary or if you are running an OAuth service, feel free to contact me to get involved. Apart from my gr= atitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-9962E026-0586-499A-AEA2-9A9B4DFAD205-- From nobody Mon Jun 22 15:16:21 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7843A11F6 for ; Mon, 22 Jun 2020 15:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIK7cjxiU8jJ for ; Mon, 22 Jun 2020 15:16:16 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640098.outbound.protection.outlook.com [40.107.64.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 BB0BD3A11F3 for ; Mon, 22 Jun 2020 15:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jc4fH6zXLguSHIkLKXn7GkRIIHRoJO2HitkaHhlNJYMCndwYguY09KNIcPhKzmsnYb0W07ZWMjACdoHJHh1CpPBmfUSuY7T2NRQ5hY4Gqj2V88v+3WA+MK7lz1Nj8SbPs/+4jp4oyUGSzv6BY2VvN4xIeBtpH+rNsdM47arNkoF8F1I3ka4WMLElnDVs+A98JHvi0w9cPcEQUGVTxZvYhuZ1541llmuyQ5Yk04uxnw4pLfxPjAWtdQkcn6dUPSzPRawBq/fLkqz7I6KzjKvtZoLeVQIspXJ83q9qTbhs9p2xZZaSlvLqUDgMGDtNCUjAbUCjf6yPtvzCxc0wzXMlJA== 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=jHZYXfV9MicWCxnXs0FxdRKu2qBozvgfqjg6/uoU374=; b=ggyLmEOPVMQlUkyfMf1fyWGjmFj72+4LtSaX2dMLJcSEB5FME8ULO08UleUWarEBZV0GYBJZqcaGopQ3vHoSWMPL80F9pSvvPNO6GC6/1UkDg7blYNeO2fJw7YX7rwhddImuQ3LtU5BhSQd4W9OrqIZ5laGtg1mix+LlZNNZuSHWAjvr51+Bb4+edoE0eTlnq3pp+VLurMXHOiPxkZ04SlZmwmbJKQVzvq5jySoOGdmI0X6SaTilvLeR+YB+H4Q8fEUJRZm2znWvBXymCOxmUSDEJht1rBr9pAO91cpcS59/sp8kU0G5f4TpKZydVZWoQ0D5y05/HSLmA5mK7SOtkQ== 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=jHZYXfV9MicWCxnXs0FxdRKu2qBozvgfqjg6/uoU374=; b=XyIS3fRL3PRv0Hh6ljXaVj5Mxig6lbFQY+K0JBXLhx0mpfR/Dz1IESLWyr8EIWu44DIU3Goe/xCaWpCx6QV3OHXtOHuE90h6TkSAvhLo4nHeBxMK9NZV3RgA9ckPxMfEDb9MerbdD8oXIGbArdAPRvK6EBl/b5LCcPbUN9VB5Y0= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0777.namprd00.prod.outlook.com (2603:10b6:610:6f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3161.0; Mon, 22 Jun 2020 22:16:15 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::3c44:1c81:e278:edb0]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::3c44:1c81:e278:edb0%2]) with mapi id 15.20.3166.000; Mon, 22 Jun 2020 22:16:15 +0000 From: Mike Jones To: Torsten Lodderstedt , Falk Andreas CC: oauth Thread-Topic: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 Thread-Index: AdZI4r0f1agS52EtSAKcP4znHYd/dQ== Date: Mon, 22 Jun 2020 22:16:15 +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=c4fa664d-4df5-4188-918f-7068215815eb; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-22T22:15:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7378f0d6-9bda-4392-f300-08d816f9e131 x-ms-traffictypediagnostic: CH2PR00MB0777: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:486; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PfkXRyABdMvCHNlcrZEcoraiO44zO83Ku+MlZPumU6Z5Id/gXysfGJtpLu+BDU4BhBqojAr8R0njrBDb8Rb/c18IAgGHPvMZqfLAgVv6mnIqqAy7QHc4Uunv9BO2RZQo34SHtPLgwD4Hi8ZGApXWsCSvPAOV2orupS+QqksYuYCmCyDk814oyKqbYac1fZfKGqghTxJmNKMk3PIPdVB9QiWwwcxL5xjrjGhDBsHB3d7Adwz9651Edupv6pOXeB8IScZiHnn37iwjkgtS7VGegWy8lpEOBL6bSgSWeSI2u7oa8lG3OZMggeJrrwrpkDqWsD6I1nblQPpZDIt46s+BrDQ6hTbN0xcmjRfdPKYSGlaQyycBZWuUEoJV4VRB4GBzdbUxNnhp+q36/Dld6OP/QQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(71200400001)(76116006)(66476007)(6506007)(53546011)(66946007)(110136005)(64756008)(66556008)(186003)(26005)(66446008)(86362001)(33656002)(9686003)(55016002)(7696005)(316002)(478600001)(83380400001)(8990500004)(8936002)(966005)(10290500003)(166002)(5660300002)(2906002)(8676002)(4326008)(82960400001)(52536014)(82950400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 9cexyLAJYm0I1D1/x6wANSxVDXw6zjzobxQ++uMdkMyIQEGsP1Jzvjm+v3rdXkvkSVDDWFJpVH86+4ro0NRQ6E4LvOAc2/urJP3llfJei524Ax9oz/PeuQoS8XuPhZUOtUSQep/PfgzR2QXXs3fI3CMhOKcttAyFNqjkgAiIfGXwONjJofbkrHodVwhrRtPnah6hbXp3ciAQiy1kzwhtFnFaxbGYU0ZAK4TjNftHTcrA+bjW4nuQAf5jhQo62kP0qAKmeh1c1wYNLYVdA+JL0ObcewTY8POH3bXAtGY9DAwjlPgteLkwXwXRmHZgBQ14IF4teHznR96bf1TtwLmT3X5ereoWlitrCFGwnWq+wrhqZZVFcD3Bylm6q7b8zXRE7HZh7J1L4vlhGrXI1sJLu7GMTXcnMJolw0tCWinI9g9glPT4LTKExOn3i2kw0AZQ4MGeRN56iVirhwS/HycFVKqXl3REleW4EbKi5RVQBCA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067846819E81B2CFC93AB35DF5970CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7378f0d6-9bda-4392-f300-08d816f9e131 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 22:16:15.2714 (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: npwEBmNvGiWHvYwb6net4ztdzbt5xTQFeTzn8FyMPy+xzEEyzkCqBkOH/SiWcJy4QNcBgEsMmfzHlUdogzeV4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0777 Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jun 2020 22:16:20 -0000 --_000_CH2PR00MB067846819E81B2CFC93AB35DF5970CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZnJvbSBtZSB0b28NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQpTZW50OiBTdW5kYXksIEp1bmUgMjEsIDIw MjAgMjo0MiBQTQ0KVG86IEZhbGsgQW5kcmVhcyA8QW5kcmVhcy5GYWxrQG5vdmF0ZWMtZ21iaC5k ZT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBB IHByb3Bvc2FsIGZvciBPQXV0aCBXRyBJbnRlcmltIE1lZXRpbmdzIGluIHBsYWNlIG9mIElFVEYx MDgNCg0KKzENCg0KDQpBbSAyMS4wNi4yMDIwIHVtIDIyOjM5IHNjaHJpZWIgRmFsayBBbmRyZWFz IDxBbmRyZWFzLkZhbGtAbm92YXRlYy1nbWJoLmRlPG1haWx0bzpBbmRyZWFzLkZhbGtAbm92YXRl Yy1nbWJoLmRlPj46DQrvu78NCisxDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Vm9uOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4+IGltIEF1ZnRyYWcgdm9uIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpHZXNlbmRldDogU29ubnRhZywgMjEuIEp1 bmkgMjAyMCAyMDo0Mg0KQW46IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LnMuaWV0ZkBnbWFp bC5jb208bWFpbHRvOnJpZmFhdC5zLmlldGZAZ21haWwuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCkJldHJlZmY6IFJlOiBbT0FVVEgtV0dd IEEgcHJvcG9zYWwgZm9yIE9BdXRoIFdHIEludGVyaW0gTWVldGluZ3MgaW4gcGxhY2Ugb2YgSUVU RjEwOA0KDQorMQ0KDQpPbiBTYXQsIEp1biAyMCwgMjAyMCBhdCAxMjozNCBQTSBSaWZhYXQgU2hl a2gtWXVzZWYgPHJpZmFhdC5zLmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQucy5pZXRmQGdt YWlsLmNvbT4+IHdyb3RlOg0KQWxsLA0KDQpBcyB5b3Uga25vdywgSUVURjEwOCB3aWxsIGJlIG9u bGluZSwgYW5kIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgbGFzdCBpbnRlcmlt IG1lZXRpbmcgc2VyaWVzLCBvdXIgcGxhbiBpcyB0byBzY2hlZHVsZSBhbm90aGVyIHNlcmllcyBv ZiB0aGVzZSBtZWV0aW5ncyBmb3IgdGhlIE9BdXRoIFdHLg0KQmFzZWQgb24gdGhlIFdHIGZlZWRi YWNrLCB0aGUgcGxhbiBpcyB0byBoYXZlIGEgc2VyaWVzIG9mIG9uZSBob3VyIG1lZXRpbmdzLCBh bmQgdG8gZGlzY3VzcyBvbmUgZG9jdW1lbnQgcGVyIG1lZXRpbmcuDQoNCkJhc2VkIG9uIHRoZSBh Ym92ZSwgd2Ugd291bGQgbGlrZSB0byBnZXQgdGhlIFdHIG9waW5pb24gb24gdGhlIGZvbGxvd2lu ZyBwcm9wb3NhbDoNCg0KMS4gTWVldGluZyBkYXkvdGltZSB3b3VsZCBiZSBNb25kYXkgQCAxMjow MHBtIEVhc3Rlcm4gVGltZSAoc2FtZSBhcyB0aGUgbGFzdCBpbnRlcmltIHNlcmllcykNCg0KMi4g SGF2ZSBhcm91bmQgOSBtZWV0aW5ncyBzcHJlYWQgb3ZlciAzIG1vbnRoczoNCg0KICAqICAgSnVs eSBtZWV0aW5ncywgYmVmb3JlIElFVEYxMDg6IEp1bHkgNiwgMTMsIGFuZCAyMA0KICAqICAgQXVn dXN0IG1lZXRpbmdzOiBBdWd1c3QgMywgMTAsIDE3DQogICogICBTZXB0ZW1iZXIgbWVldGluZ3M6 IFNlcHRlbWJlciA3LCAxNCwgMjENCg0KVGhvdWdodHM/DQoNClJlZ2FyZHMsDQogUmlmYWF0ICYg SGFubmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_CH2PR00MB067846819E81B2CFC93AB35DF5970CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzMyMDI3NjQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czozMTEzMDgzMTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+JiM0 MzsxIGZyb20gbWUgdG9vPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9u IEJlaGFsZiBPZiA8L2I+DQpUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+IFN1 bmRheSwgSnVuZSAyMSwgMjAyMCAyOjQyIFBNPGJyPg0KPGI+VG86PC9iPiBGYWxrIEFuZHJlYXMg Jmx0O0FuZHJlYXMuRmFsa0Bub3ZhdGVjLWdtYmguZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt V0ddIEEgcHJvcG9zYWwgZm9yIE9BdXRoIFdHIEludGVyaW0gTWVldGluZ3MgaW4gcGxhY2Ugb2Yg SUVURjEwODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYj NDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW0gMjEuMDYuMjAyMCB1bSAyMjozOSBzY2hyaWViIEZh bGsgQW5kcmVhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlYXMuRmFsa0Bub3ZhdGVjLWdtYmgu ZGUiPkFuZHJlYXMuRmFsa0Bub3ZhdGVjLWdtYmguZGU8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+77u/ IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBpbSBBdWZ0cmFnIHZvbiBEaWNrIEhhcmR0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IFNvbm50YWcsIDIxLiBKdW5pIDIwMjAg MjA6NDI8YnI+DQo8Yj5Bbjo8L2I+IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJpZmFhdC5zLmlldGZAZ21haWwuY29tIj5yaWZhYXQucy5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+QmV0cmVmZjo8L2I+IFJlOiBbT0FV VEgtV0ddIEEgcHJvcG9zYWwgZm9yIE9BdXRoIFdHIEludGVyaW0gTWVldGluZ3MgaW4gcGxhY2Ug b2YgSUVURjEwODwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBKdW4gMjAs IDIwMjAgYXQgMTI6MzQgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86 cmlmYWF0LnMuaWV0ZkBnbWFpbC5jb20iPnJpZmFhdC5zLmlldGZAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxsLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIHlvdSBrbm93LCBJRVRGMTA4IHdpbGwgYmUgb25saW5lLCBhbmQgYmFzZWQg b24gdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBsYXN0IGludGVyaW0gbWVldGluZyBzZXJpZXMs IG91ciBwbGFuIGlzIHRvIHNjaGVkdWxlJm5ic3A7YW5vdGhlciBzZXJpZXMgb2YgdGhlc2UgbWVl dGluZ3MgZm9yIHRoZSBPQXV0aCBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIHRoZSBXRyBmZWVkYmFjaywgdGhlIHBsYW4gaXMg dG8gaGF2ZSBhIHNlcmllcyBvZiA8Yj4NCm9uZSBob3VyPC9iPiBtZWV0aW5ncywgYW5kIHRvIGRp c2N1c3MgPGI+b25lIGRvY3VtZW50PC9iPiBwZXIgbWVldGluZy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhlIGFi b3ZlLCB3ZSB3b3VsZCBsaWtlIHRvIGdldCB0aGUgV0cgb3BpbmlvbiBvbiB0aGUgZm9sbG93aW5n IHByb3Bvc2FsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLiBNZWV0aW5nIGRheS90aW1lIHdvdWxkIGJlIDxiPk1vbmRheSBAIDEyOjAwcG0g RWFzdGVybiBUaW1lDQo8L2I+KHNhbWUgYXMgdGhlIGxhc3QgaW50ZXJpbSBzZXJpZXMpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIEhhdmUg YXJvdW5kIDkgbWVldGluZ3Mgc3ByZWFkIG92ZXIgMyBtb250aHM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxiPkp1bHkgPC9iPm1lZXRpbmdzLCBiZWZvcmUgSUVU RjEwODogPGI+SnVseSA2LCAxMywgYW5kIDIwPC9iPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxiPkF1Z3VzdDwvYj4gbWVl dGluZ3M6IDxiPkF1Z3VzdCAzLCAxMCwgMTc8L2I+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPGI+U2VwdGVtYmVyIDwvYj5t ZWV0aW5nczogPGI+U2VwdGVtYmVyIDcsIDE0LCAyMTwvYj48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvdWdodHM/Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7UmlmYWF0ICZhbXA7IEhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CH2PR00MB067846819E81B2CFC93AB35DF5970CH2PR00MB0678namp_-- From nobody Mon Jun 22 17:44:31 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC83A0810 for ; Mon, 22 Jun 2020 17:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eczsm9pHJhw6 for ; Mon, 22 Jun 2020 17:44:28 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC053A082A for ; Mon, 22 Jun 2020 17:44:25 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id y17so8364083plb.8 for ; Mon, 22 Jun 2020 17:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=IC9HD+XVd/C5MKZ09Tra34aKzYFQRyviv73mQbDY1D8=; b=TmeN2dRUtWDFLe5bW92mmUEYm5B+a7EfMRdihFQKdhcbVUZtQkPMq2eYmSkKorSQCJ gAc/h3fss3TPCAiWJSEKw+0Nu9Ilo3YKZeE7uqcmYsD5zDW0AMzZaeBuZiOIIDQxVUy+ ykSTahwL1/JSFQ/C8f1LR6urzj8JyT9SrPtSnnyxhwANPe4bTPz0Lb9nYbpvg2zfs2HO yDhB0KLEUqwFB1aI+BASMqePHrwQteGDoezym5wsLEghWVzmV9ifS6JanWHqdPgqFyJp 53LAcTKJrEHKcx/AXk2NAksTFyhUKF6yqcpeMWTxCIhb5kAH5osPh2mvcjMwi+4AprZ0 f3zw== 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=IC9HD+XVd/C5MKZ09Tra34aKzYFQRyviv73mQbDY1D8=; b=azFEmKY6LPmUK+S0Kl1aIUuERKlcNQnMBuzteqqNHct3BsTf25qD3Evcl18pMm9cFF N9PrIFHSvaaPggjxNHExwMQfNUl+2SD9FwYRDGZ8m+cDdbSFRNh3TlZw/SltmY2UG3nd ppmPaz92qDbDuO9IzGAzmC84JLDzy6XGOJDJ2mltx66Awmx4pPnG7n17xvmXxVkESrqI XfrZ3hV8Vee4mGqjK5JoLUFiBcfXnLzzY0OsFchoJLNlHXhdrSGrCulmizHEa0WFkEaw 82sstiL/uVPoLrBguEdCm3PBcythIrvcveECzWjWgCy9nB227JZsbQZ9se8eHpkhT0sa eUVQ== X-Gm-Message-State: AOAM530n+cq47C+y8k4apoQR21sXhCtrNNyB0o8ZyH2kco/CQsIvkxMw K+an4J/trT7F043GJ45oE3eXXNr09g0= X-Google-Smtp-Source: ABdhPJzBMVGKl6naq3IYfLhKqBs+OqxgytdF5N+T3TewSH8gf2S450d3iUcdPVUwZZlV343Jwl4HQg== X-Received: by 2002:a17:902:9e0c:: with SMTP id d12mr21775084plq.197.1592873064401; Mon, 22 Jun 2020 17:44:24 -0700 (PDT) Received: from ?IPv6:2001:569:7a71:1d00:a8e2:da:ce85:dede? (node-1w7jr9qrfoxxa3cf5mqgeq95q.ipv6.telus.net. [2001:569:7a71:1d00:a8e2:da:ce85:dede]) by smtp.gmail.com with ESMTPSA id a19sm15150673pfd.165.2020.06.22.17.44.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 17:44:23 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A88005D7-884D-440B-A42A-B6AF48CED3A0 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Mon, 22 Jun 2020 17:44:22 -0700 Message-Id: <10E1C140-2968-4F1D-A21E-BC97A5EA75E7@independentid.com> References: Cc: Torsten Lodderstedt , Falk Andreas , oauth In-Reply-To: To: Mike Jones X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Jun 2020 00:44:30 -0000 --Apple-Mail-A88005D7-884D-440B-A42A-B6AF48CED3A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Jun 22, 2020, at 3:16 PM, Mike Jones wrote: >=20 > =EF=BB=BF > +1 from me too > =20 > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: Sunday, June 21, 2020 2:42 PM > To: Falk Andreas > Cc: oauth > Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place o= f IETF108 > =20 > +1 >=20 >=20 > Am 21.06.2020 um 22:39 schrieb Falk Andreas = : >=20 > =EF=BB=BF > +1 > Von: OAuth im Auftrag von Dick Hardt > Gesendet: Sonntag, 21. Juni 2020 20:42 > An: Rifaat Shekh-Yusef > Cc: oauth > Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place o= f IETF108 > =20 > +1 > =20 > On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef wrote: > All, > =20 > As you know, IETF108 will be online, and based on the discussion during th= e last interim meeting series, our plan is to schedule another series of the= se meetings for the OAuth WG. > Based on the WG feedback, the plan is to have a series of one hour meeting= s, and to discuss one document per meeting.=20 > =20 > Based on the above, we would like to get the WG opinion on the following p= roposal: > =20 > 1. Meeting day/time would be Monday @ 12:00pm Eastern Time (same as the la= st interim series) > =20 > 2. Have around 9 meetings spread over 3 months: > July meetings, before IETF108: July 6, 13, and 20 > August meetings: August 3, 10, 17 > September meetings: September 7, 14, 21 > =20 > Thoughts?=20 > =20 > Regards, > Rifaat & Hannes > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A88005D7-884D-440B-A42A-B6AF48CED3A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

Phil

On Jun 22, 2020, at 3:16 PM, Mike J= ones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

=EF=BB=BF

+1 from me too

 

From: OAuth <oauth-bounces@ietf.org> = On Behalf Of Torsten Lodderstedt
Sent: Sunday, June 21, 2020 2:42 PM
To: Falk Andreas <Andreas.Falk@novatec-gmbh.de>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in p= lace of IETF108

 

+1



Am 21.06.2020 um 22:39= schrieb Falk Andreas <An= dreas.Falk@novatec-gmbh.de>:

=EF=BB=BF

+1

Von: OAuth <oa= uth-bounces@ietf.org> im Auftrag von Dick Hardt <dick.hardt@gmail.com>
Gesendet: Sonntag, 21. Juni 2020 20:42
An: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>= ;
Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in p= lace of IETF108

 

+1

 

On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef &= lt;rifaat.s.ietf@gmail.com>= ; wrote:

All,

 

As you know, IETF108 will be online, and based on the= discussion during the last interim meeting series, our plan is to schedule&= nbsp;another series of these meetings for the OAuth WG.

Based on the WG feedback, the plan is to have a serie= s of one hour meetings, and to discuss one document per meeting. =

 

Based on the above, we would like to get the WG opini= on on the following proposal:

 

1. Meeting day/time would be Monday @ 12:00pm East= ern Time (same as the last interim series)

 

2. Have around 9 meetings spread over 3 months:<= /o:p>

  • July meetings, before IETF108: July 6, 13, and 20
  • August meetings: August 3, 10, 17
  • September meetings: September 7, 14, 21

 

Thoughts? 

 

Regards,

 Rifaat & Hannes

 

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

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

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-A88005D7-884D-440B-A42A-B6AF48CED3A0-- From nobody Tue Jun 23 12:21:25 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6F3A094E for ; Tue, 23 Jun 2020 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOIdTF7e0f8i for ; Tue, 23 Jun 2020 12:21:22 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047463A094C for ; Tue, 23 Jun 2020 12:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1592940082; x=1624476082; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=l2i0uwzHE6vk4ENE97+9vPT4kayZ8pwwVmkSAQ2LxWo=; b=NIf3igNJ5eYeUh6VEUbpmidF0V93Tggn2Y2lZUMBLu6ddyUFnfta4tov ZWg/ZFB2jUupoFlRlXqoyLhGVBAyRhrsoJgmtWrCgIeUBPrdEd6lKJles E3qF5ZUrvoiXVSCjAVA15G/E+apb5iKz7IDnWQR3p+lDJ3NO3z4b8fqWR 0=; IronPort-SDR: Ay9oh3dw1qbv+5B0847pTEvgATyEBig0twdJUHAUpKg6L5BlF6wyYrqy/tmKOssBwEfu53jT9N XBNA/dL0kJTA== X-IronPort-AV: E=Sophos; i="5.75,272,1589241600"; d="scan'208,217"; a="53300117" Thread-Topic: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-d0be17ee.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 23 Jun 2020 19:21:14 +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-d0be17ee.us-west-2.amazon.com (Postfix) with ESMTPS id 17F18A07BF; Tue, 23 Jun 2020 19:21:13 +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.1497.2; Tue, 23 Jun 2020 19:21:12 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 19:21:12 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Tue, 23 Jun 2020 19:21:12 +0000 From: "Richard Backman, Annabelle" To: Phillip Hunt , Mike Jones CC: Torsten Lodderstedt , oauth Thread-Index: AdZI4r0fjly64GQpP0WWxi2D14rCFQAFLJwAABhV4QA= Date: Tue, 23 Jun 2020 19:21:12 +0000 Message-ID: References: <10E1C140-2968-4F1D-A21E-BC97A5EA75E7@independentid.com> In-Reply-To: <10E1C140-2968-4F1D-A21E-BC97A5EA75E7@independentid.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.48] Content-Type: multipart/alternative; boundary="_000_F136C86880D54AFBA44FF3D7DE89A4ADamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Jun 2020 19:21:24 -0000 --_000_F136C86880D54AFBA44FF3D7DE89A4ADamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0K4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0 cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFBoaWxsaXAgSHVudCA8cGhpbC5odW50QGluZGVw ZW5kZW50aWQuY29tPg0KRGF0ZTogTW9uZGF5LCBKdW5lIDIyLCAyMDIwIGF0IDU6NDUgUE0NClRv OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y Zz4NCkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuPTQwbG9kZGVyc3RlZHQubmV0QGRt YXJjLmlldGYub3JnPiwgb2F1dGggPE9BdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtFWFRF Uk5BTF0gW09BVVRILVdHXSBBIHByb3Bvc2FsIGZvciBPQXV0aCBXRyBJbnRlcmltIE1lZXRpbmdz IGluIHBsYWNlIG9mIElFVEYxMDgNCg0KDQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQg ZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBv cGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlciBhbmQga25v dyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoNCisxDQpQaGlsDQoNCg0KT24gSnVuIDIyLCAyMDIw LCBhdCAzOjE2IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBk bWFyYy5pZXRmLm9yZz4gd3JvdGU6DQorMSBmcm9tIG1lIHRvbw0KDQpGcm9tOiBPQXV0aCA8b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNl bnQ6IFN1bmRheSwgSnVuZSAyMSwgMjAyMCAyOjQyIFBNDQpUbzogRmFsayBBbmRyZWFzIDxBbmRy ZWFzLkZhbGtAbm92YXRlYy1nbWJoLmRlPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEEgcHJvcG9zYWwgZm9yIE9BdXRoIFdHIEludGVyaW0gTWVl dGluZ3MgaW4gcGxhY2Ugb2YgSUVURjEwOA0KDQorMQ0KDQoNCg0KQW0gMjEuMDYuMjAyMCB1bSAy MjozOSBzY2hyaWViIEZhbGsgQW5kcmVhcyA8QW5kcmVhcy5GYWxrQG5vdmF0ZWMtZ21iaC5kZTxt YWlsdG86QW5kcmVhcy5GYWxrQG5vdmF0ZWMtZ21iaC5kZT4+Og0KKzENCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpWb246IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gaW0gQXVmdHJhZyB2b24gRGljayBIYXJkdCA8 ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkdlc2Vu ZGV0OiBTb25udGFnLCAyMS4gSnVuaSAyMDIwIDIwOjQyDQpBbjogUmlmYWF0IFNoZWtoLVl1c2Vm IDxyaWZhYXQucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LnMuaWV0ZkBnbWFpbC5jb20+ Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KQmV0 cmVmZjogUmU6IFtPQVVUSC1XR10gQSBwcm9wb3NhbCBmb3IgT0F1dGggV0cgSW50ZXJpbSBNZWV0 aW5ncyBpbiBwbGFjZSBvZiBJRVRGMTA4DQoNCisxDQoNCk9uIFNhdCwgSnVuIDIwLCAyMDIwIGF0 IDEyOjM0IFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LnMuaWV0ZkBnbWFpbC5jb208bWFp bHRvOnJpZmFhdC5zLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpBbGwsDQoNCkFzIHlvdSBrbm93 LCBJRVRGMTA4IHdpbGwgYmUgb25saW5lLCBhbmQgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gZHVy aW5nIHRoZSBsYXN0IGludGVyaW0gbWVldGluZyBzZXJpZXMsIG91ciBwbGFuIGlzIHRvIHNjaGVk dWxlIGFub3RoZXIgc2VyaWVzIG9mIHRoZXNlIG1lZXRpbmdzIGZvciB0aGUgT0F1dGggV0cuDQpC YXNlZCBvbiB0aGUgV0cgZmVlZGJhY2ssIHRoZSBwbGFuIGlzIHRvIGhhdmUgYSBzZXJpZXMgb2Yg b25lIGhvdXIgbWVldGluZ3MsIGFuZCB0byBkaXNjdXNzIG9uZSBkb2N1bWVudCBwZXIgbWVldGlu Zy4NCg0KQmFzZWQgb24gdGhlIGFib3ZlLCB3ZSB3b3VsZCBsaWtlIHRvIGdldCB0aGUgV0cgb3Bp bmlvbiBvbiB0aGUgZm9sbG93aW5nIHByb3Bvc2FsOg0KDQoxLiBNZWV0aW5nIGRheS90aW1lIHdv dWxkIGJlIE1vbmRheSBAIDEyOjAwcG0gRWFzdGVybiBUaW1lIChzYW1lIGFzIHRoZSBsYXN0IGlu dGVyaW0gc2VyaWVzKQ0KDQoyLiBIYXZlIGFyb3VuZCA5IG1lZXRpbmdzIHNwcmVhZCBvdmVyIDMg bW9udGhzOg0KwrcgICAgICAgICBKdWx5IG1lZXRpbmdzLCBiZWZvcmUgSUVURjEwODogSnVseSA2 LCAxMywgYW5kIDIwDQrCtyAgICAgICAgIEF1Z3VzdCBtZWV0aW5nczogQXVndXN0IDMsIDEwLCAx Nw0KwrcgICAgICAgICBTZXB0ZW1iZXIgbWVldGluZ3M6IFNlcHRlbWJlciA3LCAxNCwgMjENCg0K VGhvdWdodHM/DQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgSGFubmVzDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_F136C86880D54AFBA44FF3D7DE89A4ADamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3Nl LTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjMzMjAyNzY0OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzExMzA4MzE4O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzU5MjMzNTI0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjg0MjYzNTg2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdT IElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFtYXpvbi5j b20vaWRlbnRpdHkvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9hd3MuYW1h em9uLmNvbS9pZGVudGl0eS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0 aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUGhpbGxpcCBIdW50ICZsdDtwaGls Lmh1bnRAaW5kZXBlbmRlbnRpZC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSnVu ZSAyMiwgMjAyMCBhdCA1OjQ1IFBNPGJyPg0KPGI+VG86IDwvYj5NaWtlIEpvbmVzICZsdDtNaWNo YWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzog PC9iPlRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1h cmMuaWV0Zi5vcmcmZ3Q7LCBvYXV0aCAmbHQ7T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJFOiBbRVhURVJOQUxdIFtPQVVUSC1XR10gQSBwcm9wb3NhbCBmb3IgT0F1dGgg V0cgSW50ZXJpbSBNZWV0aW5ncyBpbiBwbGFjZSBvZiBJRVRGMTA4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSI2MjIiIHN0eWxlPSJ3aWR0aDo0NjYuNXB0O21hcmdpbi1sZWZ0Oi41aW47 Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1 LjI1cHQiPg0KPHRkIHdpZHRoPSI2MjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NDY2LjVw dDtib3JkZXI6c29saWQgI0VEN0QzMSAxLjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7 aGVpZ2h0OjE1LjI1cHQiPg0KPHA+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6I0ZGRkY5 OSI+Q0FVVElPTjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFja2dy b3VuZDojRkZGRjk5Ij46IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhl IG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5s ZXNzDQogeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg c2FmZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5QaGlsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpPbiBKdW4gMjIsIDIwMjAs IGF0IDM6MTYgUE0sIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mIzQzOzEgZnJvbSBtZSB0b288L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtv YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Ub3JzdGVuIExv ZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVuZSAyMSwgMjAyMCAyOjQyIFBN PGJyPg0KPGI+VG86PC9iPiBGYWxrIEFuZHJlYXMgJmx0O0FuZHJlYXMuRmFsa0Bub3ZhdGVjLWdt YmguZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEEgcHJvcG9zYWwgZm9yIE9BdXRoIFdH IEludGVyaW0gTWVldGluZ3MgaW4gcGxhY2Ugb2YgSUVURjEwODxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4w cHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpBbSAyMS4wNi4yMDIwIHVtIDIyOjM5IHNjaHJpZWIgRmFs ayBBbmRyZWFzICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVhcy5GYWxrQG5vdmF0ZWMtZ21iaC5k ZSI+QW5kcmVhcy5GYWxrQG5vdmF0ZWMtZ21iaC5kZTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtYWxpZ246Y2Vu dGVyIj4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Vm9uOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgaW0g QXVmdHJhZyB2b24gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+R2VzZW5kZXQ6PC9i PiBTb25udGFnLCAyMS4gSnVuaSAyMDIwIDIwOjQyPGJyPg0KPGI+QW46PC9iPiBSaWZhYXQgU2hl a2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQucy5pZXRmQGdtYWlsLmNvbSI+cmlm YWF0LnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPkJldHJlZmY6PC9iPiBSZTogW09BVVRILVdHXSBBIHByb3Bvc2FsIGZvciBPQXV0aCBXRyBJ bnRlcmltIE1lZXRpbmdzIGluIHBsYWNlIG9mIElFVEYxMDg8L3NwYW4+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiYjNDM7MTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBT YXQsIEp1biAyMCwgMjAyMCBhdCAxMjozNCBQTSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWZhYXQucy5pZXRmQGdtYWlsLmNvbSI+cmlmYWF0LnMuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkFzIHlvdSBrbm93LCBJRVRGMTA4IHdpbGwgYmUgb25saW5lLCBh bmQgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBsYXN0IGludGVyaW0gbWVldGlu ZyBzZXJpZXMsIG91ciBwbGFuIGlzIHRvIHNjaGVkdWxlJm5ic3A7YW5vdGhlciBzZXJpZXMgb2Yg dGhlc2UgbWVldGluZ3MgZm9yIHRoZSBPQXV0aCBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5CYXNl ZCBvbiB0aGUgV0cgZmVlZGJhY2ssIHRoZSBwbGFuIGlzIHRvIGhhdmUgYSBzZXJpZXMgb2YNCjxi Pm9uZSBob3VyPC9iPiBtZWV0aW5ncywgYW5kIHRvIGRpc2N1c3MgPGI+b25lIGRvY3VtZW50PC9i PiBwZXIgbWVldGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5CYXNlZCBvbiB0aGUgYWJvdmUsIHdlIHdvdWxkIGxpa2UgdG8gZ2V0IHRoZSBX RyBvcGluaW9uIG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWw6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MS4gTWVldGluZyBkYXkvdGltZSB3b3VsZCBiZSA8 Yj5Nb25kYXkgQCAxMjowMHBtIEVhc3Rlcm4gVGltZQ0KPC9iPihzYW1lIGFzIHRoZSBsYXN0IGlu dGVyaW0gc2VyaWVzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjIuIEhhdmUgYXJvdW5kIDkgbWVldGluZ3Mgc3ByZWFkIG92ZXIgMyBtb250aHM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxiPkp1bHkgPC9iPm1lZXRpbmdzLCBiZWZvcmUgSUVURjEwODogPGI+SnVseSA2LCAx MywgYW5kIDIwPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48Yj5BdWd1c3Q8L2I+IG1lZXRpbmdzOiA8Yj5BdWd1c3QgMywgMTAsIDE3PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 Yj5TZXB0ZW1iZXIgPC9iPm1lZXRpbmdzOiA8Yj5TZXB0ZW1iZXIgNywgMTQsIDIxPC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRob3VnaHRzPyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5uZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQpPQXV0aEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F136C86880D54AFBA44FF3D7DE89A4ADamazoncom_-- From nobody Thu Jun 25 02:27:17 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F253A0896 for ; Thu, 25 Jun 2020 02:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaH-jHl4g0tL for ; Thu, 25 Jun 2020 02:27:15 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4E13A0827 for ; Thu, 25 Jun 2020 02:27:14 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id l2so3700692wmf.0 for ; Thu, 25 Jun 2020 02:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X7Q0WUgs/AGWE6jpAq1raxbzcnvzCVCmy1tSX5T/Td4=; b=j5maEaUYb/izsHoVqFZOe9eOUz2+2/TLFER5WYYfds/xaInw6j8z0HXBOLLYH4yWoU rVXRA/a1H3CfQpZZJsgXXCouzS0KRO8+/YnE5M2AGvtkkI9WPiYTMl+FKkBA8XWtx1g6 EMs58DcLz1V6S2tR8Q2cTWD6G3sPOkayMcX/Eyh5d7Qg29k9TxHu5ymavrX86QT3LLS0 zTENaYom2pY0IEW4iR+fgRStxRldMPPipxQsxdiUImGyTnxodU5QgBV4+7P4J3rptXBw QGL8UoSLFu1fmN8tCDQlcpOJv2J3UYAPIIbkeG1FuNubhrybFSxaplNL6eYLSPhwiJ/I caxg== 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=X7Q0WUgs/AGWE6jpAq1raxbzcnvzCVCmy1tSX5T/Td4=; b=NFt2S21DiQ8uOBqF3BUinh6iLUxJILZUwVyYQ7jeGUZsMNG2H+4dGB0yymOphuKs+r XYKrckk9q0WRryZ/SV9O6ulyeCQYaVj/sSsX/iiZooaRp7uJGIrakjI61L3CJfQfhz+6 NTf5sHz8xx6Wxj/PyERXLKjvohAzM4nnFCYb478hCa3xiSiiPK9LEz4pzYnRaCMJBVR7 BM5RMqqPHrLGPZPRRsE1dUQzwosO6PPJsCtJhuSmFrBSybJG3lW+1cKgY8HGysR5xtmI Xl+f82a0slc0WCRRFznBjIeCXKjSh9aXzQqKM65xCdZ8vIWvD2mh0H4hb7XfavLcH4Wg 0sRg== X-Gm-Message-State: AOAM533brthWOe/wgjw8riwiZr8gctt2LkRvL6VwI5Rrb9+4SzaxGDr2 OJ8Hl4JYrtMfwLZvyj8/t2CPJcO1hTcHpIdeAyQ= X-Google-Smtp-Source: ABdhPJxR8xQ5iCGvTeysS4Lo4vq4VBsHlvy+XxKQv/fA2aLpNSqyM1rGbIwWEnNUg0fT0plZr17WrRwr8b0AYyM4e0Q= X-Received: by 2002:a7b:ce14:: with SMTP id m20mr2493484wmc.129.1593077233032; Thu, 25 Jun 2020 02:27:13 -0700 (PDT) MIME-Version: 1.0 References: <1592833863766.52147@kuleuven.be> <33E98F20-6AF6-4A4D-A626-B9C4DA7C64C9@gmail.com> In-Reply-To: <33E98F20-6AF6-4A4D-A626-B9C4DA7C64C9@gmail.com> From: Thibault Normand Date: Thu, 25 Jun 2020 11:27:01 +0200 Message-ID: To: Filip Skokan Cc: Pieter Philippaerts , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000093225605a8e53240" Archived-At: Subject: Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation... X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Jun 2020 09:27:17 -0000 --00000000000093225605a8e53240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Pieter, I'm also interested (https://github.com/zntrio/solid), my OIDC framework is not focused on building a compliant OIDC server but produce a restricted and harmonized feature set according to your authentication use cases (human, act as human, software, machine, iot). It mostly like libsodium is (a high-level api) for low-level encryption operations (CHACHA20/Poly130). The project is quite new and focused on authorization server building blocks without the wire protocol constraints. I tried to design flow without the wire protocol constraints in order to make the building blocks useable in different context (standard / HTTP, or IoT / CoAP). Regards, Le lun. 22 juin 2020 =C3=A0 17:25, Filip Skokan a =C3= =A9crit : > Hello Pieter, > > I=E2=80=99m interested for my open source project. > > Filip > > Odesl=C3=A1no z iPhonu > > 22. 6. 2020 v 15:51, Pieter Philippaerts >: > > =EF=BB=BF > Hello everyone, > > As part of a research project, I've created a test suite to test OAuth 2.= 0 > implementations and measure how well they implement the various > MAY/SHOULD/MUST security recommendations in the OAuth standards. (It also > includes test cases for the OIDC and FAPI RO/RW recommendations.) The too= l > is practically finished and will be made available to the public in a few > months. > > I'm currently working on a security analysis of the OAuth2 ecosystem > (i..e. I'm using the tool to test various OAuth/OIDC implementations) and > I'm still looking for more candidates to test. If you are the author of a= n > OAuth library or if you are running an OAuth service, feel free to contac= t > me to get involved. Apart from my gratitude, I can offer you a free > security audit of your product :-) > > Regards, > Pieter > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thibault Normand "Il existe moins bien mais c'est plus cher !" http://www.zenithar.org --00000000000093225605a8e53240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Pieter,

I'm also i= nterested (https://github.com/z= ntrio/solid), my OIDC framework is not focused on building a compliant = OIDC server but produce a restricted and harmonized feature set according t= o your authentication use cases (human, act as human, software, machine, io= t). It mostly like libsodium is (a high-level api) for low-level encryption= operations (CHACHA20/Poly130).

The project is qui= te new and focused on authorization server building blocks without the wire= protocol constraints.
I tried to design flow without the wire pr= otocol constraints in order to make the building blocks useable in differen= t context (standard / HTTP, or IoT / CoAP).

Regard= s,

Le=C2=A0lun. 22 juin 2020 =C3=A0=C2=A017:25, Filip Skokan <<= a href=3D"mailto:panva.ip@gmail.com">panva.ip@gmail.com> a =C3=A9cri= t=C2=A0:
Hello Pieter,=C2=A0

I=E2=80=99m interested fo= r my open source project.=C2=A0

Filip

Odesl=C3=A1no z=C2=A0iPhonu

22. 6. 2020 v=C2=A015:51, Pieter Philippaerts <pieter.philip= paerts@kuleuven.be>:

=EF=BB=BF
Hello everyone,

As part of a research project, I've created a test=C2=A0suite to t= est OAuth 2.0 implementations and measure how well they implement the vario= us MAY/SHOULD/MUST security recommendations in the OAuth standards. (It als= o includes test cases for the OIDC and FAPI RO/RW recommendations.) The tool is practically finished and will be made = available to the public in a few months.

I'm currently working on a security analysis of the OAuth2 ecosyst= em (i..e. I'm using the tool to test various OAuth/OIDC implementations= ) and I'm still looking for more candidates to test. If you are the aut= hor of an OAuth library or if you are running an OAuth service, feel free to contact me to get involved. Apart from my g= ratitude, I can offer you a free security audit of your product :-)

Regards,
Pieter


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