From nobody Fri Jan 4 07:38:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04C130DC9 for ; Fri, 4 Jan 2019 07:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Uh2mBtt4hPer for ; Fri, 4 Jan 2019 07:38:48 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8A112F1A6 for ; Fri, 4 Jan 2019 07:38:47 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id b23so8897681ios.10 for ; Fri, 04 Jan 2019 07:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lkPVVEN+usvRsCCeMzHgAyXo/qtCnstWIrevwPoeksM=; b=CNFfclAfgSeDP0PJwHCU5/N6aGIErm2EIn5omCgvIkp4WJvvvaBZgmpIL+2V6xiXGh ptFoxh5DBTRnzXTL0G197IgtNPZPoaF1CtM5vqq7bcir7wKYBt5e+/7P5G4Vtpm9XfYZ mqsV8uOEG6/z2TW5Im/O1UkX8F57bVGNTdUkEn++8aETV+PkdOVkj4dhc6ffUKSJjuIH WYNrqftmsCk5t0R5O3iT238KV1bea90DKJBa8N6VxA1aYjcsK086PTzzdvInOBKGvGCA JL/VDfFHSSTCqxl8UuX5mdC6eD8+Iy9qaJpd1ues3lkknlRgTLcFHSBO6kVD6hS1FoqA YzPw== 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=lkPVVEN+usvRsCCeMzHgAyXo/qtCnstWIrevwPoeksM=; b=r7FZl4yahS44oftJ1gU+m54fDaAsYdPkMRmR8GSeX08fJF4Kv6aHw756eOgi0Nz5g8 m+N3MqfYc1lkKQTDCJ00mTbZS0N0YR0fSHZZpZubbOC+6YT/3J5TWfE1gJG3rIdyKrQ/ 2D+8hJo0oF3nNwN3tE6wkLMu5MsNCCq2MJKIj654LShYT0ltLaAWyC5yicbOrarKUKpm 0Me7mGSQ00g0iQhxpbQUE9LYVoM8kxCyFqIh/HwaNEa+Ad0VTpIowTOVS9Zlol4R429K LOvE51cN1ePezOUXkqbc8Dy2LsAZgtvTM3P5o2U7qFuncqcHfDDkf4rKU3dLpWC4sfn6 X7kg== X-Gm-Message-State: AJcUukftAPpTKJYKpos/uEuWYswiz6/cbQJYppucznUOkazjcyeu1Xop b4cLfYbRiHI5D70xb37h7VsrhHDlHm4rW+lpXYxSRqlhz84= X-Google-Smtp-Source: ALg8bN5Bhi6L8Fxc90UvpmhMxVzcurZzpM+W1YTUlTUMpJ9DKxjBhUawP5C5q8blkjo0oo5b4ccgQu9VIdqkWMTkZmI= X-Received: by 2002:a5d:904b:: with SMTP id v11mr14237275ioq.0.1546616326539; Fri, 04 Jan 2019 07:38:46 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 4 Jan 2019 10:38:35 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000bf4c6f057ea3acff" Archived-At: Subject: [OAUTH-WG] Resource Indicators Implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 15:38:50 -0000 --000000000000bf4c6f057ea3acff Content-Type: text/plain; charset="UTF-8" All, As part of the write-up for the Resource Indicators document, we are looking for information about implementations for this document. https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ Please, let us know if you are aware of any implementation for this draft. Regards, Rifaat & Hannes --000000000000bf4c6f057ea3acff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As par= t of the write-up for the Resource Indicators document, we are looking for = information about implementations for this document.
http= s://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/

Please, let us know if you are aware of any implementa= tion for this draft.

Regards,
=C2=A0Rifa= at & Hannes
--000000000000bf4c6f057ea3acff-- From nobody Fri Jan 4 07:43:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D17130DC7; Fri, 4 Jan 2019 07:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iNOcfqibck4B; Fri, 4 Jan 2019 07:43:04 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F5F12D4EA; Fri, 4 Jan 2019 07:43:01 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id b5so2000489iti.2; Fri, 04 Jan 2019 07:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WlrI8bzMuaynCvLq+BCt4pL1srAEXFGlNlwxlaEO7hI=; b=PCP/B/aynUWBG8Ab5TB6k63fWDZZv9E8mJx/RUlnsQvqg7qxyC3YK7dCAKt2Q9bEIw JFD8S1gAMKmqZNW8XH+urGp+fxfd5GxxLmC1Hltby/DDuBEdHTCRp42g4H021rkfgw0n ZKOWSIOrM21BHZHPRV2XCWk/smZJTN216mzrV49j1PaumkPgHILH7Z0s76xQJc2KWhoB NUV1ovf2ReHXbpximQf3A7wZpX79zsYdwwhxALtMpyZpdK/iU1RkqbfaYx+dwTEWwRBO 93Xch7onW0YzXb1vFSodi+flv723oaxzklHhLit7QWdQj8aq85F0dTauBr69HDQFiltE 6Kiw== 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=WlrI8bzMuaynCvLq+BCt4pL1srAEXFGlNlwxlaEO7hI=; b=jWPg9GWfrOpNg52vYoeccf2WI4fmEHNmfYq3kGZc23c1aEfKVw9jW2BZ8uYI08fOKm Sy5cFNMwF9mQHmjr+GOD6FGT9DcLlMclgk687MXUL3dS3Dii5W2shb/c7TmHuXgCLue4 OW0+zhBemkAB0wtilmKgRlCpI/b8K7BTP7y4YfVwid6Yvfi9eMLLcnDi8g0TDucyFGkz TQXFzjqu2tDCndkYZHWcqcpm9BQ1Ra13kiBbJa8mxuaWLYoEn1ye3Z2jMpdvZIqH+WXS WiHQBa6ogVGQlgn4Ji5/1LyJbc7n7EfiXg7kAioMdZBeyckZkqdLknhvvJp9z/BB1fdd 339w== X-Gm-Message-State: AJcUukeiYEqEXNqXWHxpl8k5fmbkwoqsxGEyY7W6z1HLif5bzPvc/Oal npyhHSfS50/WCYK9og5keTuk4FAcz1aH5cMsBIMoysrnf34= X-Google-Smtp-Source: ALg8bN4WccCR8e/kCTDhZ/bEtLBNew4IYLPoKxM3kl8QLUNlbHUiSUdAXqpaNa6wf1ZHCoxUNGxLnM0Lx1WUkB0Enjk= X-Received: by 2002:a24:cfc1:: with SMTP id y184mr1181031itf.72.1546616580360; Fri, 04 Jan 2019 07:43:00 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 4 Jan 2019 10:42:49 -0500 Message-ID: To: draft-ietf-oauth-resource-indicators@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000e0525c057ea3bb83" Archived-At: Subject: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 15:43:07 -0000 --000000000000e0525c057ea3bb83 Content-Type: text/plain; charset="UTF-8" Authors, As part of the write-up for the Resource Indicators document, we need an IPR disclosure from all of you. Are you aware of any IPR related to the following Resource Indicators document? https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ Regards, Rifaat --000000000000e0525c057ea3bb83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

As par= t of the write-up for the Resource Indicators document, we need an IPR disc= losure from all of you.

Are you aware of any IPR related to the following Resource Indicators docu= ment?

Regards,
<= div>=C2=A0Rifaat
--000000000000e0525c057ea3bb83-- From nobody Fri Jan 4 13:55:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE85A130E8F for ; Fri, 4 Jan 2019 13:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SlE8QWosBd0 for ; Fri, 4 Jan 2019 13:55:48 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700134.outbound.protection.outlook.com [40.107.70.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2A71271FF for ; Fri, 4 Jan 2019 13:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9v/p5LEKCK1BzhIakCwlnwB2k3ZBwL0fH42P+zPAwkQ=; b=naseOL28GRTiPyK9KMf6zPt4Dg3hMGXOyJZRTd7Wm+fe3hV1oEqP6DZAxtHVMOqzxf0wxnIpjcxXJzYvmIE1eUcsRn+LAOf362VbC7r4LlqbWlARX763yxG6ftN7HliIhNA2NO6cQZiUXIllJDchUoc7DZxNeaL9aPq6o4aL0r4= Received: from BL0PR0102CA0010.prod.exchangelabs.com (2603:10b6:207:18::23) by CO2PR01MB2021.prod.exchangelabs.com (2603:10b6:102:6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.9; Fri, 4 Jan 2019 21:55:46 +0000 Received: from DM3NAM03FT062.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by BL0PR0102CA0010.outlook.office365.com (2603:10b6:207:18::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Fri, 4 Jan 2019 21:55:45 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT062.mail.protection.outlook.com (10.152.83.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 4 Jan 2019 21:55:44 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x04LteeG029567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jan 2019 16:55:42 -0500 Date: Fri, 4 Jan 2019 15:55:40 -0600 From: Benjamin Kaduk To: Brian Campbell CC: Neil Madden , oauth Message-ID: <20190104215540.GL86936@kduck.kaduk.org> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(396003)(136003)(2980300002)(189003)(199004)(97756001)(36906005)(476003)(126002)(50466002)(956004)(4326008)(75432002)(106466001)(9686003)(47776003)(53416004)(16586007)(106002)(54906003)(786003)(86362001)(11346002)(446003)(55016002)(316002)(426003)(58126008)(229853002)(486006)(14444005)(5660300001)(305945005)(26005)(1076003)(76176011)(104016004)(186003)(8676002)(7696005)(23726003)(8936002)(246002)(6246003)(356004)(26826003)(508600001)(336012)(88552002)(2906002)(33656002)(46406003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB2021; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT062; 1:0oudJNgaDdO7PhrgPTfGaYQbW61HDX5xYBVMFH3e6lANhfMjYafEln1Rk0XmWjIX/h0z/kuabH/QMlUqpoystQ77hWbKvh0+bVaivrp4GjT9Q/PT9vjWQni0d8tgGS1N X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bbeeb7f0-cb6b-405b-d34c-08d6728f6074 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:CO2PR01MB2021; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2021; 3:pGj8RKFz5i2ubOLZgBkscYZmfZ8YEOdVcIbbjmfnXL1gYBErWkWRdKIDwDfFQerYOuvCUDuiYSgNplHIpiMTp22Ul5tJm6QrgoyaxYsRTSwfBDYlAzQdyVI5yQ464FAq5r4qacKui5NU9NNRAQNQkFTjy5bNhbGzIFFcO83eTXGBu+NrgGFAURlVi2qz9+BmSTOB30i6AXVQeKcmtX4DYHCCBAKwrQHRSUNIrroyq/tsYxUcys8DTbJkooPLIyW/JuRXOrMRX6lgEJla5Vyita3f6s1GfsuJp3kah+rhQOkQv+56CCVrTFXs040xXNeHI1fuMSb51kCmiAbkTPOpimBP0Moe+r2zm4tnmSrQ3RvLS+y7udy+CT3IQMlxX3CK; 25:4Txcp6kmZ/ocI+XBw1Lc9Eya/7tJBXucfwFu3NX4ew4F5K/cuB4hQ7xEj/4x0lb926ESIyy4xthmDaRluepU7VMf3Tha2T0tYP0gC/Lryseq+oxHbxr32WJsogv1ApIOXc6cgUhshV4tfNU+61AO3qxGiRhlsGcUBqoB3KTe+3ffbhlJR7ULh10eX+8UHDGGItgYeM5TltNf9NUCyuWmYtc8U1d+AkSpEaaayOJ1NNFTX+CeQs83tXVuYrWsWfytS48PJEk1tsnS+ixvmm6gMhl/Y/ugjysqwuH9D3KaP4fbd7SZf8YUm6cSe95NyJlXA95mjsqL92NPv2ZIV7ffpQ== X-MS-TrafficTypeDiagnostic: CO2PR01MB2021: X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2021; 31:Ysd87nKnwgp0TaaGof8Oin3Clb9IU2umBvTfSbkY+0SASyVF1xQwL6TSzYK2/r8nJ2oscfBtMrJfpt0C6eN4HZmSq9xNU+7lg6G9vQkgngeMUVTHz14+4rHGFZkt6hvxsV3beAP7MuPAJpmU8tv/NxHB0RbRyZIFAgL4H/8x7FXPvDJu2LXHaHh4d4qE3thcIiSDVPE6sce+uKL3IN7REO5E6A2JjW9hP0ellYyK2bQ=; 20:0nwGAN4TKjj7k4Q+jNqFPNqSX3rCfxQ+G/XYKmRRs49/LgWtcX4njpG8BFIAacQaHaZ1cN1xolLUm8DOgtCyltrlDkECSC0yooQF94h86/55RTy0645JTc5I11lvkIZRtGihREVMuI+2QHOuGVuhb0gtbTPiBy8HvuhWMHdQNX4T04TnAFszqmTatNppuJboRe1Qzd76zuGrEoD5Lxgry2Q38aOE4RVhGNpWyU7yKnthNP3FIuJxJjrH+7SbmViv5UrdzYw6r4mO6msg6JV54RWOusffG6iH5PFXbe9hnqZC/zQQr1/Sz9DaRFfgDJzX1Cq9GMuNpfwQGoD5971vUxtLYKtnw58THR/ZjJOSu8bh3sByratam/1ahSlU9/sMOsfUhU9dJF1ug956Uw2EHaN4SA8ZHh9wql3xVQmrl2lLdy6u4AcriLrXvuXMqLwcfc7r6OEjqC9DGX0gsI0gKjBfn7w/s+SlNGlUjpbGNyu9oS8s/Rm0o7+RdYP5xdjq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(3002001)(3231475)(944501520)(52105112)(93006095)(93004095)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201708071742011)(7699051)(76991095); SRVR:CO2PR01MB2021; BCL:0; PCL:0; RULEID:; SRVR:CO2PR01MB2021; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2021; 4:+jy6eiSCGpHYRla4bMnMkIvb3sReB/CS4BRwICFJJGmxuBV6ymCxrGya+1SC8boT6I/I/5jujQtkwWNoGbO+a0akZubbYsOGMXu5tX4r/G0C0Su48NF3eGyvtFcE0pA+Yt1HEIybvCgbVIedA3uks1O3gDFDehBZjqqiijUzP8wlxoIrV2XyJ8kCx8jheZOerouWQFQa9DAgEhbRZFGxEW1/5Z4w0+fxgdIJezR8NrUvY3uS7pp8mFXjE0mwvHQ6Df9nQ8HN15uU7qzH05TVUavmQFOYAxWaQbpPUxlLpKQ= X-Forefront-PRVS: 0907F58A24 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR01MB2021; 23:eq76GLzcJUDREAS5SsQVvTHxUvV/qDLmlN2oCvypo?= =?us-ascii?Q?icj3CN+9FkhwggFCfZrw4CVFBCUw0FGwN184hEWVPF44dvtbv6EJXMt0O4ac?= =?us-ascii?Q?fo1YCYZEY2xXy2deNZ+k+nOZQjJ2CZByOYoLH3yIdSY9liVuOj8jlIXKiP4i?= =?us-ascii?Q?2dbYYG2SIx41aButtY8YTu6mPep4x7zP3znc+qrPxWbvSJRftxtYr7EuUybH?= =?us-ascii?Q?NynzTMVbPoNOCCweed58xcfUKyUGY60UTuZNGXcOquaxMUFLOWzazj6jqYwV?= =?us-ascii?Q?XFilCuvzleS6ysTnusI4raMGjYzuA9eu/M0SXkRAWmd5lbe+xpnlRxzgzQUr?= =?us-ascii?Q?2SeTaq0iZSFssxAlCmaLPgW39RTw4gt+tqMypqKDfCzAhRSyAjGXADPFwiOs?= =?us-ascii?Q?p34sazpBPYr1trzvIJe2SVRCty3luK40esbFE+rJEc85xFNz5+0SF7u+RJ39?= =?us-ascii?Q?sL0KWau6pJB4O0blVlxQ5Nq1d43GWuSXmOCxqhVhrDq1SwEbCZ5L5cezmPeH?= =?us-ascii?Q?/9Zwy/ZnOIc9Y6Yrpm03jBxTKEywXfGbCNZd9j02kjRZIwCfOfQlqKauL7T8?= =?us-ascii?Q?ySsPJZE4J7UPkwWThtszoyVAnVo+gLODoNAD9ttkERggFlM3tgwjRRZc9zDG?= =?us-ascii?Q?VqndCUXnuvW15G/fgsexi2r5u8bz35Yd910TCSyXC44wqQnI0K0UXwFKOgWa?= =?us-ascii?Q?pOyG856VQWTxg9mE4dcyU4xNR4SSIu3m5/XepOVQxKGJU+ljAqjCT60m7DTm?= =?us-ascii?Q?L19EPYiJUkAcbJHFdLdg6cLZFlZRYkAEP069HVxQz8oDNBs1MO68Gvphpc+M?= =?us-ascii?Q?rBw657JDUHu28ZTYkGLaPkcQ4Nv15TVjmezOEknziwCEFP/+TzaGYnvTAo6z?= =?us-ascii?Q?ngCxSITb8ibE6dIZzq1mBza95K7Q9jJqBpmSr8tUskVulfnoRRzQTN0kvIIA?= =?us-ascii?Q?byAxk3o3BV6Vs/PL4pWeYpWfAcYG8qmdwz0SdMgAN0ZMWUAEpQoSv1nC2jvF?= =?us-ascii?Q?0ZTkIcSUdpcb0loOG9EvWXVnfGKno0nrMhQbEjf71mdMgXPS24TsEozw1Im7?= =?us-ascii?Q?I7CvYaCIiILP1EBM9m/Ytv/+XQ1I67/WryH16TJt2vfQhiRv5IwNVb+o1Gxo?= =?us-ascii?Q?rFsvM6iJNmcX8c1obZFNpIuJvrsIK6U9EzEEwfZXSOqTW67DQeDRUqU+2DgL?= =?us-ascii?Q?t7LEZz0jzMS8uzDFNs/4wpRMWBwxEB5iPbPoDdxqUpbFyihURGLfTDxRA=3D?= =?us-ascii?Q?=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 0cFtzXVi7N+r5La+KBGN2oYaZ3xU97MVxcjHVDO02lyb8RH2y78SNB3VEFQb0BEWL6fRa2AJ/flaYLD1v/aXxuNyYACYCQ//WDYaOupJG0KOM2dOmtPIomH3wzGhgMUdq5e9A6pc4FRsmedfbBZUaGLFEh+uA38/m05P8c7UsaWnZ5IIDj3tktqJlt8CqzgVO+Oa/L0ledBRN4/V5FxUsOMHovVGCU+pqRpdhxr7IKQ95+k8SgTRhhJeNHj4urXjOU1skTDLsAgGkALO2IRNWumnEjDOreHRexyy0GJqxRfY2PGtbB5TqK9/Vw6qk0fU X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2021; 6:hp82kjUIdJKttlhfrvjOvSIuruWJVsL8vV+2u7TgEkDLILQd88yt4ALAnBqZKALpuIwuqzw1IpiIe3jAbV0uBJlpcSOEhtrY0Dv1BeHsOcOiyb0OtabcgwjlnRG98s/gcChEwjNgrqQTn2PFXWE2gGGEZSvf4CtxCf7r/Ss7U7soTgnSQkPdql2RxtIRc1j8IKTiznqAbA7W7mc5WGAdAkXgPfIhHTcydSnbHr8/VkVea4FAEPMCg6VGbVrBHGX1sYfiA1PqZ2fL2EtmDb1K3Hhlkrqj/+bKjDtbxB58IAcD3JUSthQs4XkDfb9UmngOxT8CNmA5yNl5elm3R780Foqhl2TDplIsYGQZPhm57eweg3W/JOT5mUkTksUgsIWVRJoK/Sv95JHISctlVew7P2K5qO+LB+8uqjTOE/8ru1gvy4wr3xWV2N0M13r9T5GeljWnexuShuRy0gx4Zs7tBw==; 5:eTbODYwVHnpBJra776ggDJ9DLh9pGCvkvUyzJr6ZqLtC7HMWuYqg4sDgCzRzaBXOYCZ3YpPKrM2T3E78d9imEhTwV2XD6wQthHImnREsQlKAEKk92rh8KPuPHsGiVOgqM41Q5k4tuo4tBQMZVOXJ+s9iGDnKNBiLOorpyr8T9zFu+d3pTDEFZ4MAkvhh/ZM0pHBE5/s4hMbC97I8BjPUBw==; 7:LAe1VF7kNI852odnhMQ8dAPKXTBAA+F9lK4Z4ZApvITg+GjJ89crspU5+MihD/ud2yI0XsE9eIE/hvB7fzIIbOZySO5NIumlkO4ggU8k9GKZ1zlcG56nRLOLcDOZl9yu5lwWuUCEqi03ShiRa107lg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2019 21:55:44.0224 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bbeeb7f0-cb6b-405b-d34c-08d6728f6074 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB2021 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 21:55:51 -0000 On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: > > The observed behavior of the browsers surveyed seems logical and rather > reasonable (and better than the last time I futzed with it). Importantly it > means that for the situation described in the email that started this > thread (a javascript client making a fetch/XHR request to an MTLS token > endpoint), users using browsers that are not configured with, or have > access to, any client keys/certs will not see any UI prompt at all. I > suspect that not having client certs set up is the situation for the vast > majority of users and their browsers. And for those that do have client Is this still true when we limit to the set of users/browsers that are employees of big corporations? -Ben > certs set up, I think they are more likely to be the kind of user that is > able to deal with the UI prompt okay. From nobody Fri Jan 4 19:22:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10487128CF3 for ; Fri, 4 Jan 2019 19:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x2Im2dJIPPj for ; Fri, 4 Jan 2019 19:22:19 -0800 (PST) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F974130DD1 for ; Fri, 4 Jan 2019 19:22:17 -0800 (PST) Received: by mail-qt1-x843.google.com with SMTP id d19so42447787qtq.9 for ; Fri, 04 Jan 2019 19:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=VWxYiPur6jCNoEi7IvvCmSVTuavqUID2NdwMTYcgMdc=; b=yek1lob4OBazZRBJIea5gaNgnoGPodD5DaQ6kNkhbwzfpCGYyVe91DVdfPSTkMUIHK D4HMGp9uY2qU/CpnERrOxL9cWTDtNx7TzUjG4g81vv5GOTKb6VExJ/BSHRJkLOgwK3Qz AwuUoMvSa+VBdYOydbDw04nFdpd3oE3N7w50TI/tSguR/LTFs2kKe5hwHezkAq6tGLfs uFwtG/yGCOhQSF/zCIdfcSjajMDZGeug7Sh8hn9wJpvvA5gSXcCJcaGTPeh78mQWroZ9 TIXvO6EGabM/9HHf0unW8nqeqKgoj1rE86SdjONhdfMAQYXZTgfFZCgFbok78WSzyfcf U9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VWxYiPur6jCNoEi7IvvCmSVTuavqUID2NdwMTYcgMdc=; b=ZqQx5a0Lzg2FJRfaNgVs6fuD/cMtjgRBRfFgj73moXdKpDPtro2HyjciaK7PL5I5PH +HLwPmyxoPDaDuBEEYkkd2b1vByxyQeTHGH8mRQOFPI5KiJ1fCF2H08jxM7Q0eHdFJ/F VUh78cs+66CiOhkomRZIc6pdEqXNgZsDHzPA7Wj96dGRqNfJEjI7nkI8Eprf55sYFs44 vGiOJJhq6ldOF3eutxKvfSjcT5KAJAD+AMdp/PS51A35iUdcizW/p/b3wOlTo/D4zQmx NHAh+WRAI/AOXB65Wm3z9RrytIA1Bz/Ldo9hrpM24Y2ann1r4itdzU2VKpzYHopuBMnY rnsg== X-Gm-Message-State: AA+aEWbjVYNLBOtyc/dPhoWypSSIDy4ZOIkVr2K3ZRQywjh78RSWKkwe 8xEHUfh69IPBmB4nSaeq/QwipKJXKWVppA== X-Google-Smtp-Source: AFSGD/VoVSl6CigjIx4gZkLxkmSBcxQv4blQhugGaLPjdZNBU+1x4MDhX2UswklZyuLH5KTqGyQg8Q== X-Received: by 2002:ac8:7451:: with SMTP id h17mr51256184qtr.319.1546658535269; Fri, 04 Jan 2019 19:22:15 -0800 (PST) Received: from [192.168.8.100] ([191.126.178.10]) by smtp.gmail.com with ESMTPSA id m68sm26980231qte.49.2019.01.04.19.22.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jan 2019 19:22:14 -0800 (PST) From: John Bradley X-Google-Original-From: John Bradley To: Rifaat Shekh-Yusef , draft-ietf-oauth-resource-indicators@ietf.org, oauth References: Message-ID: <3bcb898b-0efa-047b-f144-101c928aceb4@ve7jtb.com> Date: Sat, 5 Jan 2019 00:22:12 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36736443366C9B72BF85C907" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 03:22:20 -0000 This is a multi-part message in MIME format. --------------36736443366C9B72BF85C907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am not aware of any IPR related to this specification On 1/4/2019 12:42 PM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Resource Indicators document, we need > an IPR disclosure from all of you. > > Are you aware of any IPR related to the following Resource Indicators > document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > Regards, >  Rifaat --------------36736443366C9B72BF85C907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am not aware of any IPR related to this specification 

On 1/4/2019 12:42 PM, Rifaat Shekh-Yusef wrote:
Authors,

As part of the write-up for the Resource Indicators document, we need an IPR disclosure from all of you.

Are you aware of any IPR related to the following Resource Indicators document?

Regards,
 Rifaat
--------------36736443366C9B72BF85C907-- From nobody Sat Jan 5 04:43:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E7E127B4C; Sat, 5 Jan 2019 04:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 LEaxdGjOAeEu; Sat, 5 Jan 2019 04:43:44 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60060.outbound.protection.outlook.com [40.107.6.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B3A124B0C; Sat, 5 Jan 2019 04:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MfET+jOIgxf4ByqElxwK72PUpeB6fvnkFnbIUb01gJk=; b=AvaLjNnd+9rDIV8DBOZV/JsspxcgYB5xiJFM6Pt8OoztZ/4wLhZu2fF+WV6pYmil/CbeD9JP2g3d2c5tjPobwpaQoxG2otPBimX/V4tc0QFxPvsudp+21YzNSlreUMrjWDvLdjyBcwsE/IU4tyDaUSyeB1yqgFJsu3AlSd/tn6U= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1408.eurprd08.prod.outlook.com (10.167.198.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.7; Sat, 5 Jan 2019 12:43:40 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60%2]) with mapi id 15.20.1495.005; Sat, 5 Jan 2019 12:43:40 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , "draft-ietf-oauth-resource-indicators@ietf.org" , oauth Thread-Topic: [OAUTH-WG] Resource Indicators - IPR Disclosure Thread-Index: AQHUpEQ1MHe1Hk90RUuBboc1XHW7AaWgn+xg Date: Sat, 5 Jan 2019 12:43:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1408; 6:5uC2JhNxOVcfy69+zMKHQxN1dBggVf5bUSnzU/r4I258YDzvzA4MghvehXr0STDfXAYtOcDeWorg9g6InmsxS4O6V8onf9LsCRvhXHwWxCxMkX9qKaw9lL+HMIG7kyd2O5HM8VNmV4X4LR+VN3viwgurQu5XW6E+xHR866+A6YJB4T/vCFCBf6bQ9IGXjCYDMUK7Ih9218hZ3ubnkcgFiIoXwof6MIPU1ZrMBHEoGa9eWNpRjk3Ktj8FiJQN1jnrM/yoZCiaohzOzLFf5Wy1iQS2a2xC2cEXKIH3ckzEfR7jhaFA4zqq3FU7f9+/2tLYZtt3WfTslkcYkMusDkmIiRdD4/SSvrIvXXA95SHF0Q7ZN+DrJM9hTuAvywkTVt+xlLATUH/hbkmI8LtCRuTVd79L/iKuZu/Il5iCaJmzbMn7UjXY0c5j673T6+JR2O2Web+XnnwU6y4ab8aKOFmmFg==; 5:R3ydP+sNt5q1o7kRCsZg8jXr7moyEc6xSmSFPHxc6S88Ht6tu1iXRA3ZgmhSNylCckbFgVePQrSzbWE5Hi5G0CHP7qk2bIqFOsW/DyPOf5Bxwj7uHBDOVmbcLjp/UCcz4/Z4pKMt88JnVAeUAMUx4zcZ3zBjESAwWldG8jz4JdlevX+MuZ+2vvh81lAoyXT8EvZNwm99c9EIsT1Bdq1Isg==; 7:ruYHob2Ii9cEAw9alnkn97nUUMJEc3CaT88hrUJmhpbleKpBZnOoRnuO8seIdXz3SmSKK5Q/1aLCUc5x9tQ2wU7QwfQKx8Q0NBSfVAZttPy0MKuIVp3ydnS7bLs8TC49Wmna38KI94TY91PzZhFmlA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fc400b3c-1f29-4292-6892-08d6730b6b3a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1408; x-ms-traffictypediagnostic: VI1PR0801MB1408: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB1408; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1408; x-forefront-prvs: 09086FB5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(376002)(396003)(39860400002)(40434004)(199004)(189003)(6506007)(53546011)(236005)(102836004)(9686003)(5660300001)(476003)(97736004)(11346002)(446003)(186003)(110136005)(54896002)(6306002)(26005)(486006)(39060400002)(33656002)(7736002)(81156014)(229853002)(81166006)(606006)(14454004)(478600001)(8676002)(966005)(790700001)(55016002)(6116002)(3846002)(74316002)(72206003)(25786009)(6246003)(68736007)(76176011)(6436002)(8936002)(53936002)(316002)(7696005)(105586002)(106356001)(66066001)(2906002)(2501003)(86362001)(99286004)(71200400001)(71190400001)(5024004)(14444005)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1408; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3Csnt4eZ0H5rfU5Gis0fFApnCpn4SDQaufE2Z+vsVBlzzlncHt3iixCwzO2jKx48EeVOdiE22pTHElFjrHj9Wn3OmoqMuaEGIiLp+VzUwncCJuhSnrV2CmSrCNdxI4d/LTrdalQ+l71MMzpN8Vnlx0qA5ppQkl/9c6x59pQM4rrNewC5qA8t5TvGWHvL0osiNg83EJtTmD9JCYkcUhpTQMuzsz320bUnzDOnybdwAxi8d33KVz6ZyNzGFUEa9gjUJxIBCcuyRY6LKfrKS6CbVthCGlONrQY9ZylcfDU59dAiz7DwZe+AAgDjGjQjTy36 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21123AE7F65854D62845F4E8FA8F0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc400b3c-1f29-4292-6892-08d6730b6b3a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2019 12:43:39.9234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1408 Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 12:43:48 -0000 --_000_VI1PR0801MB21123AE7F65854D62845F4E8FA8F0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUnMgcmVnYXJkaW5nIHRoaXMgZG9jdW1lbnQuDQoNCkZy b206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNo ZWtoLVl1c2VmDQpTZW50OiBGcmVpdGFnLCA0LiBKYW51YXIgMjAxOSAxNjo0Mw0KVG86IGRyYWZ0 LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9yc0BpZXRmLm9yZzsgb2F1dGggPG9hdXRoQGll dGYub3JnPg0KU3ViamVjdDogW09BVVRILVdHXSBSZXNvdXJjZSBJbmRpY2F0b3JzIC0gSVBSIERp c2Nsb3N1cmUNCg0KQXV0aG9ycywNCg0KQXMgcGFydCBvZiB0aGUgd3JpdGUtdXAgZm9yIHRoZSBS ZXNvdXJjZSBJbmRpY2F0b3JzIGRvY3VtZW50LCB3ZSBuZWVkIGFuIElQUiBkaXNjbG9zdXJlIGZy b20gYWxsIG9mIHlvdS4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhl IGZvbGxvd2luZyBSZXNvdXJjZSBJbmRpY2F0b3JzIGRvY3VtZW50Pw0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLw0K DQpSZWdhcmRzLA0KIFJpZmFhdA0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0K --_000_VI1PR0801MB21123AE7F65854D62845F4E8FA8F0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFJzIHJlZ2FyZGluZyB0aGlz IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gT0F1dGggJmx0O29hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpZmFhdCBTaGVraC1ZdXNlZjxi cj4NCjxiPlNlbnQ6PC9iPiBGcmVpdGFnLCA0LiBKYW51YXIgMjAxOSAxNjo0Mzxicj4NCjxiPlRv OjwvYj4gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzQGlldGYub3JnOyBvYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10g UmVzb3VyY2UgSW5kaWNhdG9ycyAtIElQUiBEaXNjbG9zdXJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QXV0aG9ycyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BcyBwYXJ0IG9mIHRoZSB3 cml0ZS11cCBmb3IgdGhlIFJlc291cmNlIEluZGljYXRvcnMgZG9jdW1lbnQsIHdlIG5lZWQgYW4g SVBSIGRpc2Nsb3N1cmUgZnJvbSBhbGwgb2YgeW91Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5b3UgYXdhcmUgb2YgYW55IElQ UiByZWxhdGVkIHRvIHRoZSBmb2xsb3dpbmcgUmVzb3VyY2UgSW5kaWNhdG9ycyBkb2N1bWVudD88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0 aC1yZXNvdXJjZS1pbmRpY2F0b3JzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLzwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDtSaWZhYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_VI1PR0801MB21123AE7F65854D62845F4E8FA8F0VI1PR0801MB2112_-- From nobody Mon Jan 7 05:01:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC81200D7 for ; Mon, 7 Jan 2019 05:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WudKmwNC0tdT for ; Mon, 7 Jan 2019 05:01:38 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6C3124BAA for ; Mon, 7 Jan 2019 05:01:38 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id k2so197243iog.7 for ; Mon, 07 Jan 2019 05:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sMCxMbzBgXHk28OD5FaEVSq+dFYH/hQgCAls/4TBsUQ=; b=UEo0akahx0fACQT3WOOq3pqbjoY3Da5nipPaSlMd6vYeuddeyId6/uHF8COTPRoiVQ 8++6bjW6dbsEJf2JAqxbWiwnl7Wcgvq/2MEFeKZ8LRLh1cB/SZ6Gg2KREx9jguPYcqnc zyqRTfHTVWFSwDAuhWOepNDJBwbX/MmtX6a9M= 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=sMCxMbzBgXHk28OD5FaEVSq+dFYH/hQgCAls/4TBsUQ=; b=BGQxPRUZC0Rts1hP8a8QtGAvn1bmVBcvlkAe3jO+9txHgbfgGJ/PCR7rfcr5oFHBmO f5mmJCB45iyANKbh6L+WVLyOAP2axnmnQc0mAzqMNKdxPBH7ksU6uTA0zlPxsXobD4im uO3HQSDDVf29WMfKcX/XenPqT1OEZMoYfMy7YbqYMq1X2Z6tTRsO7Om0vJT9wASIJ4Vt yk+27rmd5Wldo6aN4b0BaZn7QAc1QN6dBO/722kjzAYMkBtMUs1Xn1+wcqhCacTRuJoe kp3y+pflnw07fU2dkWlBF/yU+9ENeDqAZ7pnXkxwiv9wr8Lo15Pek9xdiKf/hUAVF2T9 IhPw== X-Gm-Message-State: AJcUukdXY1JO4YiM6ycfz92jX5/oYgbP8fysZivLweRf/1tI1dejYJ4m /ORyISJR7MQ2u0/7URKaERFUs3Kk5CpSWzcc056ncShGl5GrTuDEMxko4l3IWN563KoV+QbCT3U GD1QMJ++6ZlhLbQ== X-Google-Smtp-Source: ALg8bN6sxOSqUuxHSVRCAf5+kEaGEFtpjEmt5XqdHUiycrA8uGsIRtmemhdgKRje0j6wApbpJkSolC2KMsQ1tV9D+AA= X-Received: by 2002:a6b:700a:: with SMTP id l10mr14805189ioc.138.1546866097285; Mon, 07 Jan 2019 05:01:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 7 Jan 2019 06:01:10 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: draft-ietf-oauth-resource-indicators@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000003ea01e057eddd437" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 13:01:46 -0000 --0000000000003ea01e057eddd437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR related to this document. On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Resource Indicators document, we need an > IPR disclosure from all of you. > > Are you aware of any IPR related to the following Resource Indicators > document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > Regards, > Rifaat > _______________________________________________ > 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._ --0000000000003ea01e057eddd437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this document.

On Fri, Jan 4, 2019 at = 8:43 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
= Authors,

As part of the write-up for the Resource Indi= cators document, we need an IPR disclosure from all of you.

Are you aware of any IPR related to th= e following Resource Indicators document?

Regards,
=C2=A0Rifaat
_______________________________________________
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. --0000000000003ea01e057eddd437-- From nobody Mon Jan 7 09:22:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECFE130F8A for ; Mon, 7 Jan 2019 09:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 m2l_OsRZbkWm for ; Mon, 7 Jan 2019 09:22:18 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7934D128CE4 for ; Mon, 7 Jan 2019 09:22:18 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id x6so912573ioa.9 for ; Mon, 07 Jan 2019 09:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VFae7h2b++JVs1ZUQSPji+JUqvE5lyk1eK14khVj3dU=; b=k7i/hUUSuUdDfURVpqLsxAnNG0zBpU2aBeyZCGAh8ImOXQlOXIIF+T/5+eZ84Gx1x+ UItZPwIx3V/TEWMNB+wUnP44GtYr2djHK5doxSY0J4vFjdmMhX2/2G2P4Nqifd/z87Zq TT1YyCMRZRDogHbF7HGMYF9Q/69/gPmQyPxwc= 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=VFae7h2b++JVs1ZUQSPji+JUqvE5lyk1eK14khVj3dU=; b=noIj8herCdlzKJs67fR6vAQZTKRq/TpxXtdRtCRWBkTFV7FZWvlj/z8K/mWA/iI7Fb 1Vz/IXfTo7r/h1yUaBfedu91GnoRZx6HjhkKdL0TGph0jF0eUbYYUtuSPuvJ5ijaNmkB EuGcGCAHctYjH54p017kk3ZpYHsXvsJjCjn9uOmQ0gXN6oFbHw0UKdQKuKliyfJc96cM 6JS8oRCbFOw+tiG2YmNQA9Tt60hlYmX9N70wMvxOvQHEQGb5aJCuc8KNIYTvPvAZpnoH YME1FlfwRpPT0zEcktQkTMeH6VWTt9SI4QMCksnxD4+V0n6hG2tjykgUqCBX6yyqzoeF sugg== X-Gm-Message-State: AJcUukd5LZSAp43WMxOsGYbxTeFCnL5Ae7Ngzk8qBhQfxba0qfYEu5gA us2f6RGAegYg8UDy0d1C8exD/b/FGZkQUWT/was2z9+bxpvTvwOr9Xdx9s0U1mEdLmvwkMxaDcg lQ73mfxzPXKNQtg== X-Google-Smtp-Source: ALg8bN6WVZQ/aTsq7NdlR6QW2l3CoRYocSGjHbayzOEvwX+5obCLFExtU6GALckM/QalK4LKVx+wpLoywYwv2w1ia2Y= X-Received: by 2002:a6b:700a:: with SMTP id l10mr15399486ioc.138.1546881737598; Mon, 07 Jan 2019 09:22:17 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> In-Reply-To: <20190104215540.GL86936@kduck.kaduk.org> From: Brian Campbell Date: Mon, 7 Jan 2019 10:21:51 -0700 Message-ID: To: Benjamin Kaduk Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="0000000000007ac59b057ee17859" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 17:22:20 -0000 --0000000000007ac59b057ee17859 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't honestly know for sure but I suspect that employees of big corporations will likely have keys/certs on their devices/machines that are issued by some internal CA and provisioned to them automatically (and in many cases without the user knowing and/or understanding that they are there and why). Those users would likely be prompted when TLS handshaking with a server that presents an empty list of CAs in the certificate_authorities of the CertificateRequest. I dunno. Maybe I was too quick to retract the proposal for the MTLS supporting secondary token endpoint? What do folks (including Ben & Neil) think? On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: > On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: > > I > > suspect that not having client certs set up is the situation for the va= st > > majority of users and their browsers. And for those that do have client > > Is this still true when we limit to the set of users/browsers that are > employees of big corporations? > > -Ben > > > certs set up, I think they are more likely to be the kind of user that = is > > able to deal with the UI prompt okay. > --=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._ --0000000000007ac59b057ee17859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't honestly know for sure b= ut I suspect that employees of big corporations will likely have keys/certs= on their devices/machines that are issued by some internal CA and provisio= ned to them automatically (and in many cases without the user knowing and/o= r understanding that they are there and why). Those users would likely be p= rompted when TLS handshaking with a server that presents an empty list of C= As in the certificate_authorities of the CertificateRequest.

I dunno. Maybe I was too quick to retract the proposal for = the MTLS supporting secondary token endpoint?

What= do folks (including Ben & Neil) think?

On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk &l= t;kaduk@mit.edu> = wrote:
On Fri, D= ec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the v= ast
> majority of users and their browsers. And for those that do have clien= t

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that= is
> able to deal with the UI prompt okay.

<= 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. --0000000000007ac59b057ee17859-- From nobody Mon Jan 7 09:48:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F85130FCF for ; Mon, 7 Jan 2019 09:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 v9moNnMmzchA for ; Mon, 7 Jan 2019 09:48:22 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56647130FC7 for ; Mon, 7 Jan 2019 09:48:22 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id b5so2240893iti.2 for ; Mon, 07 Jan 2019 09:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/LS26OupOmGYIA8DPVjIQVNnG/BTOKKun2W+oc1uc+g=; b=JX+TxRRbb8Ix1UD5tR97aHHkGDSAnwOE5qlbpWA82YqNvg+jiCFkoJ13PJhSiP+e4m MHpWOu4e5anN2P2bImqSZEAv7k4Ui06YFulmPQFvUNKNoYb7JEITdtaKZSNBKj0a0dDb tTYVx9+/HxdubTD73zhKmtglTmhRXVDbiBEnE= 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=/LS26OupOmGYIA8DPVjIQVNnG/BTOKKun2W+oc1uc+g=; b=OZxrCniXkRzGww09CoSuR2loOiqxZ+fyqHc1CpfAPkjQHLnkS9chaEKZHqlrPNq2AR aNytI31N1PAkLBeGaCKQqlHZqpsNI5+a9xle94tTvfO7wUWVtkHa8+dw8LE9g4L5NOBW BvaD0RwtakccVf4RqEYZhi+DdZI5a6NwaS03j4lRa8s51o0IR7llAOhed0W+mLDt4pXI g7G/iU7TxLDogQfvujZkKLeCjiQN832l69ZJtZQiif9FcluwFxDYUTXG/hT/HxemN5EJ Jhtu2tBaX96ODweYcrndczIMTWQpiiaZpjuvzHN3EIBInzlPrRjXGRoht6eN9jl98Z1G +YOA== X-Gm-Message-State: AJcUukdRsdKhP26GxL2FliuEEYDafxtcJBjW8/tJqPt86TShx7S2WMZI teeujWr6AkEMrroANsIqkhTOCaQwsuBvhczQgRps0RUoYlvCKPl7kUSsrn2zql8unxb31d1DhOp zkHSbgkhsXXe+Hg== X-Google-Smtp-Source: ALg8bN7iFLPhSqlIqchcfgsZe3FA6WUragT6vtm+Oo4SdPBFn4LoTJfBW8A5i9C5f6dxSfD6ZX9f+2FTCTw0Z1Ci2Mg= X-Received: by 2002:a24:8ac7:: with SMTP id v190mr7830966itd.174.1546883301236; Mon, 07 Jan 2019 09:48:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 7 Jan 2019 10:47:55 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000adfed3057ee1d5d2" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators Implementations X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 17:48:25 -0000 --000000000000adfed3057ee1d5d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ping has an implementation that was done years ago but using a different parameter name (see 'aud' at https://documentation.pingidentity.com/pingfederate/pf92/index.shtml#adminG= uide/tokenEndpoint.html for one example). So it's not this exact draft per se but is conceptually the same. And problems encountered using 'aud' as the name helped inform the direction of the draft. So it's very much related and running code and all that. My understanding is that Microsoft has an implementation. I'm no authority on their stuff but, for example, you can see usage of the parameter in this documentation of the code flow: https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocol= s-oauth-code On Fri, Jan 4, 2019 at 8:39 AM Rifaat Shekh-Yusef wrote: > All, > > As part of the write-up for the Resource Indicators document, we are > looking for information about implementations for this document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > Please, let us know if you are aware of any implementation for this draft= . > > Regards, > Rifaat & Hannes > _______________________________________________ > 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._ --000000000000adfed3057ee1d5d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ping has an implementati= on that was done years ago but using a different parameter name (see 'a= ud' at https://documentation.pingid= entity.com/pingfederate/pf92/index.shtml#adminGuide/tokenEndpoint.html = for one example). So it's not this exact draft per se but is conceptual= ly the same. And problems encountered using 'aud' as the name help= ed inform the direction of the draft. So it's very much related and run= ning code and all that.

My unders= tanding is that Microsoft has an implementation. I'm no authority on th= eir stuff but, for example, you can see usage of the parameter in this docu= mentation of the code flow: https://docs.microsoft= .com/en-us/azure/active-directory/develop/v1-protocols-oauth-code

On Fri, Jan= 4, 2019 at 8:39 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

As part of the write-up for the Resource Indicators= document, we are looking for information about implementations for this do= cument.

Please= , let us know if you are aware of any implementation for this draft.
<= div>
Regards,
=C2=A0Rifaat & Hannes
=
_______________________________________________
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. --000000000000adfed3057ee1d5d2-- From nobody Mon Jan 7 09:59:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C3130FD0 for ; Mon, 7 Jan 2019 09:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9c7anPMXE1h6 for ; Mon, 7 Jan 2019 09:59:32 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE1F12870E for ; Mon, 7 Jan 2019 09:59:32 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 32so1080060ota.12 for ; Mon, 07 Jan 2019 09:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbzcr6EwIYe7ty2pScF2p7e4TrJk4AzOOPDXruTtNik=; b=mj+XEwvgSblCvoOMqgTdfVQZY7I4u7X3L015z6GAdQkbwjfT4PSf7vL8L/i0yh02go Qzf6Th/niRpcKa/QMzs86dofaKv99tYKpY7V01blZNGjzkaZucE0b+lvxdInNXnYpeGo QcgqNSVwv2L+5hvJr5SdfgBUxwI8FtymY/8DeLTJxCZ+i71Niwnmgpc4of1j31HSKsmM 1qI5K5PSLpIxEfO3I49SsftA8G9klSrrWU4LX05Y9mwDOFw+GmUsQb0abaL8Nh9IxLxr FOH1vMb1v1CC60qhuBCAzX/Tfi151Wx6AngZusyV2Jl9ExrWO9ht/7QHAwHX49TSXZAN jjTg== 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=rbzcr6EwIYe7ty2pScF2p7e4TrJk4AzOOPDXruTtNik=; b=VFANXjKI2A2GZlyX7OapzkK0fY9BrekMDMjajsLCLdceNbv9zHseqz8UyoAAlXFWuc tes8MQtNQfkwmznXS5Pg+yDq4wqieX8EZ/zX2SftlrMEh85kQvpyrdx28vZIjp2UFXgz tvK28vv0ZkWhi+O5jOiZxsDVQi5ZkG2WQhjcarwm32y60okp0pJ6OT/qsi0mZs4RQXz5 GZI8QGlsDAE+4NwSY/mEWUKGSXnF4oTuXaHOjMlKTlH9trmuTTYotA/ew3oleIZzwyIv tTJu/OIxM2Fu32oIkbto3YwjTGwbdldXyhUvP/1ykHC7lnYHhQE55j3R23iz6eXBWxvF RN+A== X-Gm-Message-State: AJcUukeQYFx8172G0BudEFWTJtg+33VidTYEboVGrhQJmJon12HbFWmd oORLVO/pv4vJqTvXI0BuJjAcDZGhSC2mkBGXyQ== X-Google-Smtp-Source: ALg8bN5fvl+VkU8DT//WhVbsuirFHYlok36b6Fp2AwfTGCdmUpvdcEvh7xZrdkme6U8SRl4z04ekgfZNlPMo8anH/8c= X-Received: by 2002:a9d:7097:: with SMTP id l23mr41335920otj.49.1546883971748; Mon, 07 Jan 2019 09:59:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Mon, 7 Jan 2019 18:59:20 +0100 Message-ID: To: Brian Campbell Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000a546cb057ee1fd32" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators Implementations X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 17:59:35 -0000 --000000000000a546cb057ee1fd32 Content-Type: text/plain; charset="UTF-8" OSS https://github.com/panva/node-oidc-provider has the latest draft implemented. and similar to Ping, Auth0 also has a different named parameter ('audience') that works within the Resource Indicators draft boundaries. Best, *Filip* On Mon, Jan 7, 2019 at 6:48 PM Brian Campbell wrote: > Ping has an implementation that was done years ago but using a different > parameter name (see 'aud' at > https://documentation.pingidentity.com/pingfederate/pf92/index.shtml#adminGuide/tokenEndpoint.html > for one example). So it's not this exact draft per se but is conceptually > the same. And problems encountered using 'aud' as the name helped inform > the direction of the draft. So it's very much related and running code and > all that. > > My understanding is that Microsoft has an implementation. I'm no authority > on their stuff but, for example, you can see usage of the parameter in this > documentation of the code flow: > https://docs.microsoft..com/en-us/azure/active-directory/develop/v1-protocols-oauth-code > > > On Fri, Jan 4, 2019 at 8:39 AM Rifaat Shekh-Yusef > wrote: > >> All, >> >> As part of the write-up for the Resource Indicators document, we are >> looking for information about implementations for this document. >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ >> >> Please, let us know if you are aware of any implementation for this draft. >> >> Regards, >> Rifaat & Hannes >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a546cb057ee1fd32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ping has an implementation = that was done years ago but using a different parameter name (see 'aud&= #39; at https://docum= entation.pingidentity.com/pingfederate/pf92/index.shtml#adminGuide/tokenEnd= point.html for one example). So it's not this exact draft per se bu= t is conceptually the same. And problems encountered using 'aud' a= s the name helped inform the direction of the draft. So it's very much = related and running code and all that.

My understanding is that Microsoft has an implementation. I'm no = authority on their stuff but, for example, you can see usage of the paramet= er in this documentation of the code flow: https://docs.microsoft..com/en-us/azure/active-directory/develo= p/v1-protocols-oauth-code

On Fri, Jan 4, 2019 at 8:39 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:
All,

As part of the write-up for the Resource Indicators document, we are look= ing for information about implementations for this document.

Please, let us know if you a= re aware of any implementation for this draft.

Reg= ards,
=C2=A0Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a546cb057ee1fd32-- From nobody Mon Jan 7 10:15:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1F2130FE8 for ; Mon, 7 Jan 2019 10:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ow6KMA2lN0dM for ; Mon, 7 Jan 2019 10:15:49 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBA61200B3 for ; Mon, 7 Jan 2019 10:15:49 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id j21so1099351oii.8 for ; Mon, 07 Jan 2019 10:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DZCq06Fk/dCDIg+MEL41Md4owAPd6pnPipA1N9jmEMY=; b=ZdaMjPoEygW3ZlNNZXr+nsNuShJuvZDetKDEI/2u1jCTvgX/x2IFL4w9oUSBOYFmeL LWpawDLM80PfjWL/P39HpyAc3dUuP2ZXBnmNuW+JCoompf2k5yvfsiiFUMqQlgRo/Byd euBLudZpRkcYZxLEe8IM+sPEc0zPrq9Bx09JA8WlH/kNII1jwKRJtbtNZtROjY2l6UJs lRUNYzw+WdcXILyJmb/hCTbXsaOcLr8aPMFc3ZVUYB4Rg7I+rR0cOlPE9IobZMBskdBJ gH2SIpd+Uitl3O/NclmYZVixljcrNgjBM7qFR8Vw/qGOjQn3ApRY946Y//gSBJblBqFA 6Q+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DZCq06Fk/dCDIg+MEL41Md4owAPd6pnPipA1N9jmEMY=; b=kG9fHG0MijIMQWHMICzra+51DT2EzR44bzBSqzkGPJMmcuI1h3O3JV1mALzs3xZNpi Nz1QVIk+FLekqXi9rBgzTWDZ2iWuuMSDGk9rXfw4ogPIQ5kcvetWcRZ5XG4bG1peegCS B5TU7fnKc0pKhdav73Wc6o3WxIUa5/Qht5n5eV9PzJUWI1rStcsQ2TzoKrQSUunRJwv+ 9sF1laEbu/EEvaFIarY9cS5EyDZ0s2zuOKBymOds+/yBpVzZr/mOEDcGBAVj3TX1aI0x ofQH39XNAvBPeObd7NLOQtHCkGXqpbmwNtjZslFggG7gUxe1txsbHWmHWoNhk88mtC7b GArg== X-Gm-Message-State: AJcUukd4xAb2OJ5pU1FalkosvwpDq4BtMdqSJFfX/ex7KDH+8jRgyfm5 c31+/w1gEd5drLXANkTV4iWaypNaZMmYA/m1uWCp X-Google-Smtp-Source: ALg8bN6w6pynSQqDhTW1w7EZTggVYl7MBY35AzGzdQIh3IaGm2gRhaP1Nsvv6O6MuWxS4sCpksTG7RXmfiAGZ88h8K4= X-Received: by 2002:aca:401:: with SMTP id 1mr8452017oie.335.1546884948843; Mon, 07 Jan 2019 10:15:48 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> In-Reply-To: From: Filip Skokan Date: Mon, 7 Jan 2019 19:15:37 +0100 Message-ID: To: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000e26323057ee237fa" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 18:15:52 -0000 --000000000000e26323057ee237fa Content-Type: text/plain; charset="UTF-8" I think we shouldn't make a sweeping assumption that may potentially harm UX for end-users. Even if for a small percentage. Tho i can say for sure this percentage may also be rather significant depending on the types of services end-users have encountered in the past and made them install certs. For example, in Czech Republic there's an online system for communicating with government agencies, essentially an email-like inbox that you only get when verifying your identity in person on a post office, every company is required to have one for communication e.g. with the tax office and individuals and freelancers are encouraged to have one as well. To finish signing up for this inbox online after you've verified your identity in person, you must install custom certificates on your system otherwise the browser won't let you through the online signup part due to HSTS. I can say with 100% confidence that most folk do not remove these certs from their system, this means they'd fall in the category that gets prompted and are in majority nowhere near the kind of users that are able to deal with the UI prompt when encountered in the wild. I'd like to see a solution that - works for every endpoint that needs mtls client cert for either client auth or certificate bound token validation. This isn't only a case for token endpoint, introspection, revocation, userinfo (RS-like endpoint that might be checking a cert bound access token) to list a few - can ensure clients without access to client certificates won't hit an endpoint configured to request one to avoid the change of having the UX flow broken, potentially selecting the wrong certificate which the browser then remembers to use thus failing auth until website data is cleared. Working under the assumption a client software always knows whether it is configured with client certificates or not it would be nice if there was either a defined prefix, suffix or a specific object in the discovery response (with the same endpoint names in it) that a client can rely on to detect if there is an mtls specific url for any discovered endpoint it needs to use when providing client certificates. Best, *Filip* On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell wrote: > I don't honestly know for sure but I suspect that employees of big > corporations will likely have keys/certs on their devices/machines that are > issued by some internal CA and provisioned to them automatically (and in > many cases without the user knowing and/or understanding that they are > there and why). Those users would likely be prompted when TLS handshaking > with a server that presents an empty list of CAs in the > certificate_authorities of the CertificateRequest. > > I dunno. Maybe I was too quick to retract the proposal for the MTLS > supporting secondary token endpoint? > > What do folks (including Ben & Neil) think? > > On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: > >> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: >> > I >> > suspect that not having client certs set up is the situation for the >> vast >> > majority of users and their browsers. And for those that do have client >> >> Is this still true when we limit to the set of users/browsers that are >> employees of big corporations? >> >> -Ben >> >> > certs set up, I think they are more likely to be the kind of user that >> is >> > able to deal with the UI prompt okay. >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e26323057ee237fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we shouldn't make a swee= ping assumption that may potentially harm UX for end-users. Even if for a s= mall percentage. Tho i can say for sure this percentage may also be rather = significant depending on the types of services end-users have encountered i= n the past and made them install certs.

For exampl= e, in Czech Republic there's an online system for communicating with go= vernment agencies, essentially an email-like inbox that you only get when v= erifying your identity in person on a post office, every company is require= d to have one for communication e.g. with the tax office and individuals an= d freelancers are encouraged to have one as well. To finish signing up for = this inbox online after you've verified your identity in person, you mu= st install custom certificates on your system otherwise the browser won'= ;t let you through the online signup part due to HSTS. I can say with 100% = confidence that most folk do not remove these certs from their system, this= means they'd fall in the category that gets prompted and are in majori= ty nowhere near the kind of users that are able to deal with the UI prompt = when encountered in the wild.

I'd like to see = a solution that
  • works for every endpoint that needs mtls = client cert for either client auth or certificate bound token validation. T= his isn't only a case for token endpoint, introspection, revocation, us= erinfo (RS-like endpoint that might be checking a cert bound access token) = to list a few
  • can ensure clients without access to client certi= ficates won't hit an endpoint configured to request one to avoid the ch= ange of having the UX flow broken, potentially selecting the wrong certific= ate which the browser then remembers to use thus failing auth until website= data is cleared.
Working under the assumption a cl= ient software always knows whether it is configured with client certificate= s or not it would be nice if there was either a defined prefix, suffix or a= specific object in the discovery response (with the same endpoint names in= it) that a client can rely on to detect if there is an mtls specific url f= or any discovered endpoint it needs to use when providing client certificat= es.

Best,
Filip

<= br>
On Mon, Jan 7, 2019 at 6:22 = PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wro= te:
I don't honestly know for sure but I suspect= that employees of big corporations will likely have keys/certs on their de= vices/machines that are issued by some internal CA and provisioned to them = automatically (and in many cases without the user knowing and/or understand= ing that they are there and why). Those users would likely be prompted when= TLS handshaking with a server that presents an empty list of CAs in the ce= rtificate_authorities of the CertificateRequest.

<= div>I dunno. Maybe I was too quick to retract the proposal for the MTLS sup= porting secondary token endpoint?

What do folks (i= ncluding Ben & Neil) think?

On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Dec 28, 2018 = at 03:55:15PM -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the v= ast
> majority of users and their browsers. And for those that do have clien= t

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that= is
> able to deal with the UI prompt okay.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e26323057ee237fa-- From nobody Mon Jan 7 10:36:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8076512426E for ; Mon, 7 Jan 2019 10:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZtjVghaJyBzg for ; Mon, 7 Jan 2019 10:36:33 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A98E1277D2 for ; Mon, 7 Jan 2019 10:36:33 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id j2so1526919wrw.1 for ; Mon, 07 Jan 2019 10:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7DtH6owl90w/JJ9BcA+S/q/yEx+B7LMQV75v8lPxWo=; b=bpE9b2XZLzX+dc5LaTzLWy/lfQQzVA6U9OoaYF8XK0hgAqGyrnlioDJWR77OHRya0k WBw36MNyHbx5ezHJseFFFdWAfoL9MBe9pJR7mwM6mHBqi8TKzgsAogLwBf1YTeCnp7yM D9PwnsHxz8lUGUB4KXDBtZPoC3vcNUf9s7baY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7DtH6owl90w/JJ9BcA+S/q/yEx+B7LMQV75v8lPxWo=; b=HfbTFk7EMgF14CjfBYhqlla+PDtHWKV1dAJq8NJP5S8SOVOU/2u29MfJn2khQiQnLy ZLRNY3wqS05EcB9wimlxoo/G+WWOA9XThBQfhd+zdN1NOfRcc8sSgHoK079pNZus1VWh 5DgNOELZswDf1Tmr1Z4LMiWnVRvcsFm5k0iZPFH+0GAVCbyfiEPqHbalbLCcSKTFw9Ii 9rl4aMJYVWBPZ2r8a2fnicOPnf46mnUYSqizpLNqc27M5pIBhQ6codP2k2E3ms2zNUmw mHB8g4e0oo4kpnNfBBXYRLYpwvtsJ4QW3O/n4bjHfPpUkYXmbN3c93UdL7SAu/NnqYxo D/xQ== X-Gm-Message-State: AJcUukfxMZUbjIM3MnX4vwHgWFEWUXBqVzkKlc2UmY5KSCC3Rel7q0KE vNTHhYj26T9nfTb2KOAQCSMvEKOJ9f4= X-Google-Smtp-Source: ALg8bN5emk7VGkkVNr4t1OSLYnvSHnVSUSP6jkq7W2UorIdw14AIF/XDk6qVvwGoIW4llbWmpaGA9A== X-Received: by 2002:a5d:524b:: with SMTP id p11mr50325446wrv.147.1546886191851; Mon, 07 Jan 2019 10:36:31 -0800 (PST) Received: from [192.168.1.65] (92.150.32.217.dyn.plus.net. [217.32.150.92]) by smtp.gmail.com with ESMTPSA id b129sm7557463wmd.24.2019.01.07.10.36.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 10:36:30 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C071B676-656E-471B-9554-85FD45C50C2F Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Mon, 7 Jan 2019 18:36:29 +0000 Cc: Benjamin Kaduk , oauth Content-Transfer-Encoding: 7bit Message-Id: <34DD1788-FC0E-4BB3-BB4D-198005285A71@forgerock.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jan 2019 18:36:37 -0000 --Apple-Mail-C071B676-656E-471B-9554-85FD45C50C2F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thinking about this, given that this is the *token* endpoint that clients ta= lk to directly, not the *authorize* endpoint, it seems already possible for t= he AS to put it on a different port/host so that users aren=E2=80=99t ever p= rompted for a cert. Right? =E2=80=94 Neil > On 7 Jan 2019, at 17:21, Brian Campbell wrote= : >=20 > I don't honestly know for sure but I suspect that employees of big corpora= tions will likely have keys/certs on their devices/machines that are issued b= y some internal CA and provisioned to them automatically (and in many cases w= ithout the user knowing and/or understanding that they are there and why). T= hose users would likely be prompted when TLS handshaking with a server that p= resents an empty list of CAs in the certificate_authorities of the Certifica= teRequest.=20 >=20 > I dunno. Maybe I was too quick to retract the proposal for the MTLS suppor= ting secondary token endpoint? >=20 > What do folks (including Ben & Neil) think?=20 >=20 >> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: >> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: >> > I >> > suspect that not having client certs set up is the situation for the va= st >> > majority of users and their browsers. And for those that do have client= >>=20 >> Is this still true when we limit to the set of users/browsers that are >> employees of big corporations? >>=20 >> -Ben >>=20 >> > certs set up, I think they are more likely to be the kind of user that i= s >> > able to deal with the UI prompt okay. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. --Apple-Mail-C071B676-656E-471B-9554-85FD45C50C2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thi= nking about this, given that this is the *token* endpoint that clients talk t= o directly, not the *authorize* endpoint, it seems already possible for the A= S to put it on a different port/host so that users aren=E2=80=99t ever promp= ted for a cert. Right?

=E2=80= =94 Neil

On 7 Jan 2019, at 17:21, Brian Campbell &= lt;bcampbell@pingidentity.com<= /a>> wrote:




On Fri, Dec 28, 2018 at 03:55:15PM= -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the va= st
> majority of users and their browsers. And for those that do have client=

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that i= s
> able to deal with the UI prompt okay.

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.= --Apple-Mail-C071B676-656E-471B-9554-85FD45C50C2F-- From nobody Tue Jan 8 05:00:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC22131118 for ; Tue, 8 Jan 2019 05:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4jOxks5wdWI for ; Tue, 8 Jan 2019 05:00:22 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63907131114 for ; Tue, 8 Jan 2019 05:00:22 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id g8so3042058iok.4 for ; Tue, 08 Jan 2019 05:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mssah9YD4GbRiBTXHvXLX1LfTAvlUvSXrK+RndczLHU=; b=a9wdcRwA/Fci/ZtNVOSZgkkFXWPJp3Llwdo7f5IlBgGwMvo0GCMKC0DpQF5fuT+6Io SzwvFrIP3GxYXS1yAr+JjnamCOGi1lNGvy76xGt7H3ataijR9NeLqboNwQvbsGhaNgu6 /4SPrwfrjqGMtClpfHG62CLzkZd/L1ASvGFDM= 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=Mssah9YD4GbRiBTXHvXLX1LfTAvlUvSXrK+RndczLHU=; b=JMRAFmeGha6iwMBhGfdvPlA+7uq1VEGLpjofAFVBHylY0F1OlmXJL/AB1+bGR4T2fB mm21oybUQltfrHpJldkZ+Q+1LmCpgh9ltl3Vl+i8TqTSU2jPFoj+bbBlJiIb/z0F1X3U YpF9pVtsnLPcXtjIstLAwBD7EXwoMac/slfwEpZnUQuaAupQvnAmtnG8e3rsRKkGqwlV hRkuxv/EXsjtKPVG8JxssyhCdnL0Tg1lJ3A8aQ77+3yzkSg72yi9T3SusURETix2ZXkK Usbjby9mFoW1QC6+kCxwUd/37PrWjApY4fDd4hVHSNtVILdJtkE0JHIoe0neR/YTQvtc RcUA== X-Gm-Message-State: AJcUukcmJxjx4qbjjxCHA9lorzYaj72y0F4d+55LimzG/+bFwCXoIBtE yC9vyF3RhJ2szGBpCNpIh8k/JpYfASHvunfhl1X790i9xnefMnxWAx4HIeS9VfxZ4L4WvVR3ZMn PA7CteD0BfkfCTQ== X-Google-Smtp-Source: ALg8bN6EJppXC2trloV2oDf5Tmi5ZM0EiwEd8UnFn3z37yhrW4AwG+33RtNV6I9MZz1093K5WIndZ4KOVgucbrq40/w= X-Received: by 2002:a6b:b345:: with SMTP id c66mr943034iof.59.1546952421537; Tue, 08 Jan 2019 05:00:21 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> In-Reply-To: From: Brian Campbell Date: Tue, 8 Jan 2019 05:59:55 -0700 Message-ID: To: Filip Skokan Cc: oauth Content-Type: multipart/alternative; boundary="000000000000921e8e057ef1ed5b" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 13:00:25 -0000 --000000000000921e8e057ef1ed5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable inline below... On Mon, Jan 7, 2019 at 11:15 AM Filip Skokan wrote: > I think we shouldn't make a sweeping assumption that may potentially harm > UX for end-users. Even if for a small percentage. Tho i can say for sure > this percentage may also be rather significant depending on the types of > services end-users have encountered in the past and made them install cer= ts. > > For example, in Czech Republic there's an online system for communicating > with government agencies, essentially an email-like inbox that you only g= et > when verifying your identity in person on a post office, every company is > required to have one for communication e.g. with the tax office and > individuals and freelancers are encouraged to have one as well. To finish > signing up for this inbox online after you've verified your identity in > person, you must install custom certificates on your system otherwise the > browser won't let you through the online signup part due to HSTS. I can s= ay > with 100% confidence that most folk do not remove these certs from their > system, this means they'd fall in the category that gets prompted and are > in majority nowhere near the kind of users that are able to deal with the > UI prompt when encountered in the wild. > In this example, the custom certificates one has to install on their system are additional root CAs, right? From my observations that has no bearing on the prompting behavior of the browsers (and shouldn't). What dictates the behavior is whether the browser is configured with, or has access to, one or more certificate with the associated private key that could be used as client TLS certificates. > > I'd like to see a solution that > > - works for every endpoint that needs mtls client cert for either > client auth or certificate bound token validation. This isn't only a c= ase > for token endpoint, introspection, revocation, userinfo (RS-like endpo= int > that might be checking a cert bound access token) to list a few > - can ensure clients without access to client certificates won't hit > an endpoint configured to request one to avoid the change of having th= e UX > flow broken, potentially selecting the wrong certificate which the bro= wser > then remembers to use thus failing auth until website data is cleared. > > Working under the assumption a client software always knows whether it is > configured with client certificates or not it would be nice if there was > either a defined prefix, suffix or a specific object in the discovery > response (with the same endpoint names in it) that a client can rely on t= o > detect if there is an mtls specific url for any discovered endpoint it > needs to use when providing client certificates. > Yeah, you are right about other endpoints (I'd been kind of willfully ignoring them to be honest) and I think the specific object in the discovery response that itself could have any of the same endpoint names in it would be the most straight forward way to approach that. Best, > *Filip* > > > On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> I don't honestly know for sure but I suspect that employees of big >> corporations will likely have keys/certs on their devices/machines that = are >> issued by some internal CA and provisioned to them automatically (and in >> many cases without the user knowing and/or understanding that they are >> there and why). Those users would likely be prompted when TLS handshakin= g >> with a server that presents an empty list of CAs in the >> certificate_authorities of the CertificateRequest. >> >> I dunno. Maybe I was too quick to retract the proposal for the MTLS >> supporting secondary token endpoint? >> >> What do folks (including Ben & Neil) think? >> >> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: >> >>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: >>> > I >>> > suspect that not having client certs set up is the situation for the >>> vast >>> > majority of users and their browsers. And for those that do have clie= nt >>> >>> Is this still true when we limit to the set of users/browsers that are >>> employees of big corporations? >>> >>> -Ben >>> >>> > certs set up, I think they are more likely to be the kind of user tha= t >>> is >>> > able to deal with the UI prompt okay. >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000921e8e057ef1ed5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline below...

On Mon, Jan 7, 2019 at 11:15 AM Filip Skokan <panva.ip@gmail.com> wrote:
I think we shouldn't make a sweeping assumption that may= potentially harm UX for end-users. Even if for a small percentage. Tho i c= an say for sure this percentage may also be rather significant depending on= the types of services end-users have encountered in the past and made them= install certs.

For example, in Czech Republic the= re's an online system for communicating with government agencies, essen= tially an email-like inbox that you only get when verifying your identity i= n person on a post office, every company is required to have one for commun= ication e.g. with the tax office and individuals and freelancers are encour= aged to have one as well. To finish signing up for this inbox online after = you've verified your identity in person, you must install custom certif= icates on your system otherwise the browser won't let you through the o= nline signup part due to HSTS. I can say with 100% confidence that most fol= k do not remove these certs from their system, this means they'd fall i= n the category that gets prompted and are in majority nowhere near the kind= of users that are able to deal with the UI prompt when encountered in the = wild.

In this example, th= e custom certificates one has to install on their system are additional roo= t CAs, right?=C2=A0 From my observations that has no bearing on the prompti= ng behavior of the browsers (and shouldn't). What dictates the behavior= is whether the browser is configured with, or has access to, one or more certificate with the=20 associated private key that could be used as client TLS certificates.
=C2=A0

I'd like to see a soluti= on that
  • works for every endpoint that needs mtls client c= ert for either client auth or certificate bound token validation. This isn&= #39;t only a case for token endpoint, introspection, revocation, userinfo (= RS-like endpoint that might be checking a cert bound access token) to list = a few
  • can ensure clients without access to client certificates = won't hit an endpoint configured to request one to avoid the change of = having the UX flow broken, potentially selecting the wrong certificate whic= h the browser then remembers to use thus failing auth until website data is= cleared.
Working under the assumption a client sof= tware always knows whether it is configured with client certificates or not= it would be nice if there was either a defined prefix, suffix or a specifi= c object in the discovery response (with the same endpoint names in it) tha= t a client can rely on to detect if there is an mtls specific url for any d= iscovered endpoint it needs to use when providing client certificates.
<= /div>

Yeah, you are right about= other endpoints (I'd been kind of willfully ignoring them to be honest= ) and I think the specific object in the discovery response that itself cou= ld have any of the same endpoint names in it would be the most straight for= ward way to approach that.=C2=A0
=C2=A0

Best,
Filip

=
On Mon, Jan 7, 2019 at 6:22= PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wr= ote:
I don't honestly know for sure but I suspec= t that employees of big corporations will likely have keys/certs on their d= evices/machines that are issued by some internal CA and provisioned to them= automatically (and in many cases without the user knowing and/or understan= ding that they are there and why). Those users would likely be prompted whe= n TLS handshaking with a server that presents an empty list of CAs in the c= ertificate_authorities of the CertificateRequest.

=
I dunno. Maybe I was too quick to retract the proposal for the MTLS su= pporting secondary token endpoint?

What do folks (= including Ben & Neil) think?

<= div dir=3D"ltr">On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Dec 28, 20= 18 at 03:55:15PM -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the v= ast
> majority of users and their browsers. And for those that do have clien= t

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that= is
> able to deal with the UI prompt okay.

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000921e8e057ef1ed5b-- From nobody Tue Jan 8 05:04:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1E5131118 for ; Tue, 8 Jan 2019 05:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV6NrfpX5ZQs for ; Tue, 8 Jan 2019 05:04:44 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-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 BBFAE131119 for ; Tue, 8 Jan 2019 05:04:44 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id b5so5834665iti.2 for ; Tue, 08 Jan 2019 05:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ItI3aVkOUPoG63S8tn/Gmu/D6OcqNyNS/Mvu0OhKRo=; b=d23icc1pn+stxWDeHma1dtnyo8o5X6hcuuO+iIf+A6O9XcY2ZA0WSmFTwoLt0uA1eV a8rkVVAK0nIqMxHnIGM08gHbS9nQjLE3Om2lM4M/Ms40ZaVZo7pkDX9aF2L32MniJrEA ZzjZgAMpWmAMat35cZZFoIDUJWjvCCCwvnwSo= 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=3ItI3aVkOUPoG63S8tn/Gmu/D6OcqNyNS/Mvu0OhKRo=; b=g53pFDH9KrFsmPSFBx/9giE6OM8q2Mm2C3zchpba9Z6BK3MP86gRaU0eLgJaFQb3sa 1R/upD4XdXcQ5PJ6gCJT1FWVz4ts0iKjIl5O23Dtwk8NxXJMNWOsC/dQirmkD4mso5i1 wTvryBhhzhjNqEbZ+TGZmVbbQPIutMQWdJwDrFYkcqxY823j7YfJoW86QJgIizLgmYYE 2pq9hvAXQwleM+nnH83rn5ae2HFvgPboPtdARld+SuLd02xMiwVrqSO/qdhEk0pqvrbf zD2F01IeXrYzl6790hqk9jO+rwZp8CAfaZT2BRZNxSQJeNhF/5Y3lhM7/9pPUHpX4qau BJfA== X-Gm-Message-State: AJcUukfRAkneg8RxfJEM/4ev1wWjoMM8mUx5tHzfSw82x9Bx/bmfNREy pPiNc3m7F2JI08ctkQdM313y4oZgUUbC37JCn4TVTNHQXFuULhGU8v1mDZIF0AUBx+Jqh42O223 qJEiWjCrcp6aSTQ== X-Google-Smtp-Source: ALg8bN6FAQFH2tsB4bMhlr6LqrS6GmOBKx88HmIlvDH/xusWAJKe4ICSJEL5vyuoMXmjEwWqpCAtwWWPq3KvOUIR6lU= X-Received: by 2002:a24:8ac7:: with SMTP id v190mr1180015itd.174.1546952683888; Tue, 08 Jan 2019 05:04:43 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> <34DD1788-FC0E-4BB3-BB4D-198005285A71@forgerock.com> In-Reply-To: <34DD1788-FC0E-4BB3-BB4D-198005285A71@forgerock.com> From: Brian Campbell Date: Tue, 8 Jan 2019 06:04:17 -0700 Message-ID: To: Neil Madden Cc: Benjamin Kaduk , oauth Content-Type: multipart/alternative; boundary="000000000000354354057ef1fd1a" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 13:04:48 -0000 --000000000000354354057ef1fd1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes *but* not when the client is a javascript application running in the user's browser. And the direction this WG is taking is to start/continue to suggest that such clients use the code flow (which hits the token endpoint) rather than the implicit (which only hits the authorization endpoint). On Mon, Jan 7, 2019 at 11:36 AM Neil Madden wrote: > Thinking about this, given that this is the *token* endpoint that clients > talk to directly, not the *authorize* endpoint, it seems already possible > for the AS to put it on a different port/host so that users aren=E2=80=99= t ever > prompted for a cert. Right? > > =E2=80=94 Neil > > On 7 Jan 2019, at 17:21, Brian Campbell > wrote: > > I don't honestly know for sure but I suspect that employees of big > corporations will likely have keys/certs on their devices/machines that a= re > issued by some internal CA and provisioned to them automatically (and in > many cases without the user knowing and/or understanding that they are > there and why). Those users would likely be prompted when TLS handshaking > with a server that presents an empty list of CAs in the > certificate_authorities of the CertificateRequest. > > I dunno. Maybe I was too quick to retract the proposal for the MTLS > supporting secondary token endpoint? > > What do folks (including Ben & Neil) think? > > On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: > >> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: >> > I >> > suspect that not having client certs set up is the situation for the >> vast >> > majority of users and their browsers. And for those that do have clien= t >> >> Is this still true when we limit to the set of users/browsers that are >> employees of big corporations? >> >> -Ben >> >> > certs set up, I think they are more likely to be the kind of user that >> is >> > able to deal with the UI prompt okay. >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000354354057ef1fd1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes *but* not when the client is a javascript applica= tion running in the user's browser. And the direction this WG is taking= is to start/continue to suggest that such clients use the code flow (which= hits the token endpoint) rather than the implicit (which only hits the aut= horization endpoint).=C2=A0

=
On Mon, Jan 7, 2019 at 11:36 AM Neil Madden <neil.madden@forgerock.com> wrote:=
Thinking about this, given that = this is the *token* endpoint that clients talk to directly, not the *author= ize* endpoint, it seems already possible for the AS to put it on a differen= t port/host so that users aren=E2=80=99t ever prompted for a cert. Right?

=E2=80=94 Neil

On 7 Jan 2019, at 17:21, Brian Campbell <bcampbell@pingidentity.com> wrote:



On Fri, Dec 28= , 2018 at 03:55:15PM -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the v= ast
> majority of users and their browsers. And for those that do have clien= t

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that= is
> able to deal with the UI prompt okay.

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000354354057ef1fd1a-- From nobody Tue Jan 8 07:39:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518ED130E6C for ; Tue, 8 Jan 2019 07:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zi6dWZmDNg4x for ; Tue, 8 Jan 2019 07:39:07 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B804D130DE3 for ; Tue, 8 Jan 2019 07:39:06 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id j21so3629391oii.8 for ; Tue, 08 Jan 2019 07:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=es7chmLBKhf2QLbOWNtNcxsMc/KxX4rEsGh1Ub0/J+k=; b=PIypnh4z0r4zCojcMkXcZAkvLHnYxLfAd8zbnIKUWVj9Er5ix3cjL91+QrzGyLeaKB TFH+G3N4uF5i7qUAqu/gj9MaNCQPAlZqU4tFR59w6frHU6W9wrqcHs3C0qhdPp1q/SzN BRu2rXK4ywSSX3/eREFmsqpP1FFOXer8nv2z9l11rKYd3e4i4nFCjeLx4DmMvSlDcpBj EDzzTkGuuAly60QKGY4Sg6dOTel2rbk9m+B4lgsnMdPmPnuyFPBdBbvYBO9BXa7S8AO9 uO9m8mwkVvSFRjHnmcQLzikasAQ4cZlJsS/9AUIUCLz7k/EhT3NPofzel5qo2wpEYJmg LRew== 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=es7chmLBKhf2QLbOWNtNcxsMc/KxX4rEsGh1Ub0/J+k=; b=OqWzDc6OJ8xmJaP0Tfe7q+dTkhRTydu3tXBe2wbYsNirBu0PcR2/ChEZp6BcPuvxy/ /6wICMRMWCXGV8lwgWEXf3nDAiL4smwiJL5dxlwRfuVOOkCIubguk6EmN3A5Zi/Qe+Xv FmSu4Q7DVO/HfI03FZ/oDmxSStE7GzlCeuXcKReDFsT28F6J5m0YBrQb+/11Qsv+ysvJ euVu61gN1pGNL9aDyyUx5NW5gNKrSfGNhVN9F8Dt0qtieivbKTPTCd+y82yhxIEWPTYN ysX9+CBEhhWqdpTdJDmyNshF8tkPtTJOMmvyc82G/6P6Bfh2f9lzUV+Vb+ImVTKIIgqN RR0w== X-Gm-Message-State: AJcUukdhVBT/qTVl08jmO/RyYtaM4BpntW2teSRNSMEKrmn0UtvqKA3U 9htP6t2UHb8ODpStbCxfPxGW4Dltaavlxz9ruw== X-Google-Smtp-Source: ALg8bN5WyXJwL0EnlOMbSqNgGbEP3O/txkxUaXDQrNCfTJdAEW8gQOHPHV+ikwjoTecQcyglsSYIUMppBfWEE3O4H0o= X-Received: by 2002:aca:5987:: with SMTP id n129mr1503796oib.174.1546961945570; Tue, 08 Jan 2019 07:39:05 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> In-Reply-To: From: Filip Skokan Date: Tue, 8 Jan 2019 16:38:54 +0100 Message-ID: To: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000003f5cad057ef42506" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 15:39:10 -0000 --0000000000003f5cad057ef42506 Content-Type: text/plain; charset="UTF-8" > > In this example, the custom certificates one has to install on their > system are additional root CAs, right? Correct,* in this example.* > From my observations that has no bearing on the prompting behavior of the > browsers (and shouldn't). What dictates the behavior is whether the browser > is configured with, or has access to, one or more certificate with the > associated private key that could be used as client TLS certificates. *with the associated private key* - hmm, does that explain my observation then (tested on OS X Chrome and FF) the result was that supporting both self-signed and PKI client auth method on the token (+introspection, revocation) endpoints and support for cert bound access tokens on the userinfo_endpoint for non-browser based clients while not prompting on token, userinfo or revocation calls made from the browser. This was my nginx server block https://gist.github.com/panva/bb153c974cfd65fb0bc9ebb89ca0a3eb Is that a valid setup? I honestly don't know, it seemed to fit the bill for this particular AS configuration. But without the option to discover mtls specific endpoints it's seems to be the only one usable for an AS that also has browser-based clients, one couldn't use `on` or `optional` configuration - are we in the position to restrict the possible configuration to just one? nah. If we consider having an `mtls_endpoints` or similar object in discovery then this whole problem and potential broken UX goes away, or rather, will only come up for browser based clients on e.g. provisioned hardware that access sites like company's intranet etc. and is developed with using those certs and therefore directly accessing the mtls_endpoints discovery namespace. The logic is also rather simple for a regular backend client implementation, if there's a client cert, look for that object's endpoint (and fallback to the usual if missing). If the client doesn't support sending mtls client certs, it will continue using the regular endpoints. The use of `mtls_endpoints` is optional but when used guarantees that browser based clients will never have randomly broken UX for some users. I can only imagine the support cases horror from customer's end-users who don't know what to do. It was, afterall, the original intention behind this section of the draft. The authorization server may also consider hosting the token endpoint, and other endpoints requiring client authentication, on a separate host name or port in order to prevent unintended impact on the TLS behavior of its other endpoints, e.g. the authorization endpoint. S pozdravem, *Filip Skokan* On Tue, Jan 8, 2019 at 2:00 PM Brian Campbell wrote: > inline below... > > On Mon, Jan 7, 2019 at 11:15 AM Filip Skokan wrote: > >> I think we shouldn't make a sweeping assumption that may potentially harm >> UX for end-users. Even if for a small percentage. Tho i can say for sure >> this percentage may also be rather significant depending on the types of >> services end-users have encountered in the past and made them install certs. >> >> For example, in Czech Republic there's an online system for communicating >> with government agencies, essentially an email-like inbox that you only get >> when verifying your identity in person on a post office, every company is >> required to have one for communication e.g. with the tax office and >> individuals and freelancers are encouraged to have one as well. To finish >> signing up for this inbox online after you've verified your identity in >> person, you must install custom certificates on your system otherwise the >> browser won't let you through the online signup part due to HSTS. I can say >> with 100% confidence that most folk do not remove these certs from their >> system, this means they'd fall in the category that gets prompted and are >> in majority nowhere near the kind of users that are able to deal with the >> UI prompt when encountered in the wild. >> > > In this example, the custom certificates one has to install on their > system are additional root CAs, right? From my observations that has no > bearing on the prompting behavior of the browsers (and shouldn't). What > dictates the behavior is whether the browser is configured with, or has > access to, one or more certificate with the associated private key that > could be used as client TLS certificates. > > >> >> I'd like to see a solution that >> >> - works for every endpoint that needs mtls client cert for either >> client auth or certificate bound token validation. This isn't only a case >> for token endpoint, introspection, revocation, userinfo (RS-like endpoint >> that might be checking a cert bound access token) to list a few >> - can ensure clients without access to client certificates won't hit >> an endpoint configured to request one to avoid the change of having the UX >> flow broken, potentially selecting the wrong certificate which the browser >> then remembers to use thus failing auth until website data is cleared. >> >> Working under the assumption a client software always knows whether it is >> configured with client certificates or not it would be nice if there was >> either a defined prefix, suffix or a specific object in the discovery >> response (with the same endpoint names in it) that a client can rely on to >> detect if there is an mtls specific url for any discovered endpoint it >> needs to use when providing client certificates. >> > > Yeah, you are right about other endpoints (I'd been kind of willfully > ignoring them to be honest) and I think the specific object in the > discovery response that itself could have any of the same endpoint names in > it would be the most straight forward way to approach that. > > > Best, >> *Filip* >> >> >> On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> I don't honestly know for sure but I suspect that employees of big >>> corporations will likely have keys/certs on their devices/machines that are >>> issued by some internal CA and provisioned to them automatically (and in >>> many cases without the user knowing and/or understanding that they are >>> there and why). Those users would likely be prompted when TLS handshaking >>> with a server that presents an empty list of CAs in the >>> certificate_authorities of the CertificateRequest. >>> >>> I dunno. Maybe I was too quick to retract the proposal for the MTLS >>> supporting secondary token endpoint? >>> >>> What do folks (including Ben & Neil) think? >>> >>> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk wrote: >>> >>>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: >>>> > I >>>> > suspect that not having client certs set up is the situation for the >>>> vast >>>> > majority of users and their browsers. And for those that do have >>>> client >>>> >>>> Is this still true when we limit to the set of users/browsers that are >>>> employees of big corporations? >>>> >>>> -Ben >>>> >>>> > certs set up, I think they are more likely to be the kind of user >>>> that is >>>> > able to deal with the UI prompt okay. >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited... If you have received this communication in error, please >>> notify the sender immediately by e-mail and delete the message and any file >>> attachments from your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --0000000000003f5cad057ef42506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this example, the custom certificates one has = to install on their system are additional root CAs, right?

Correct, in this example.
=C2=A0
From my observations that has= no bearing on the prompting behavior of the browsers (and shouldn't). = What dictates the behavior is whether the browser is configured with, or ha= s access to, one or more certificate with the associated private key that c= ould be used as client TLS certificates.

with the associated private key=C2=A0- hmm, does that explain my obser= vation then (tested on OS X Chrome and FF) the result was that supporting b= oth self-signed and PKI client auth method on the token (+introspection, re= vocation) endpoints and support for cert bound access tokens on the userinf= o_endpoint for non-browser based clients while not prompting on token, user= info or revocation calls made from the browser.


Is that a valid setup? I= honestly don't know, it seemed to fit the bill for this particular AS = configuration. But without the option to discover mtls specific endpoints i= t's seems to be the only one usable for an AS that also has browser-bas= ed clients, one couldn't use `on` or `optional` configuration - are we = in the position to restrict the possible configuration to just one? nah.

If we consider having an `mtls_endpoints` or similar= object in discovery then this whole problem and potential broken UX goes a= way, or rather, will only come up for browser based clients on e.g. provisi= oned hardware that access sites like company's intranet etc. and is dev= eloped with using those certs and therefore directly accessing the mtls_end= points discovery namespace.
The logic is also rather simple for a= regular backend client implementation, if there's a client cert, look = for that object's endpoint (and fallback to the usual if missing). If t= he client doesn't support sending mtls client certs, it will continue u= sing the regular endpoints. The use of `mtls_endpoints` is optional but whe= n used guarantees that browser based clients will never have randomly broke= n UX for some users. I can only imagine the support cases horror from custo= mer's end-users who don't know what to do.

It was, afterall, the original intention behind this section of the draft.=

The authorizat= ion server may also consider hosting the token endpoint, and other endpoint= s requiring client authentication, on a separate host name or port in order= to prevent unintended impact on the TLS behavior of its other endpoints, e= .g. the authorization endpoint.

S pozdravem,Filip Skokan


On Tue, Jan 8, 2019 at 2:00 PM Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
inline below...

On Mon, Jan 7, 2019 at 11:15 AM Fili= p Skokan <panva.= ip@gmail.com> wrote:
I think we shouldn't= make a sweeping assumption that may potentially harm UX for end-users. Eve= n if for a small percentage. Tho i can say for sure this percentage may als= o be rather significant depending on the types of services end-users have e= ncountered in the past and made them install certs.

For example, in Czech Republic there's an online system for communica= ting with government agencies, essentially an email-like inbox that you onl= y get when verifying your identity in person on a post office, every compan= y is required to have one for communication e.g. with the tax office and in= dividuals and freelancers are encouraged to have one as well. To finish sig= ning up for this inbox online after you've verified your identity in pe= rson, you must install custom certificates on your system otherwise the bro= wser won't let you through the online signup part due to HSTS. I can sa= y with 100% confidence that most folk do not remove these certs from their = system, this means they'd fall in the category that gets prompted and a= re in majority nowhere near the kind of users that are able to deal with th= e UI prompt when encountered in the wild.

In this example, the custom certificates one has to instal= l on their system are additional root CAs, right?=C2=A0 From my observation= s that has no bearing on the prompting behavior of the browsers (and should= n't). What dictates the behavior is whether the browser is configured with, or has access to, one or more certificate with the=20 associated private key that could be used as client TLS certificates.
=C2=A0

I'd like to see a soluti= on that
  • works for every endpoint that needs mtls client c= ert for either client auth or certificate bound token validation. This isn&= #39;t only a case for token endpoint, introspection, revocation, userinfo (= RS-like endpoint that might be checking a cert bound access token) to list = a few
  • can ensure clients without access to client certificates = won't hit an endpoint configured to request one to avoid the change of = having the UX flow broken, potentially selecting the wrong certificate whic= h the browser then remembers to use thus failing auth until website data is= cleared.
Working under the assumption a client sof= tware always knows whether it is configured with client certificates or not= it would be nice if there was either a defined prefix, suffix or a specifi= c object in the discovery response (with the same endpoint names in it) tha= t a client can rely on to detect if there is an mtls specific url for any d= iscovered endpoint it needs to use when providing client certificates.
<= /div>

Yeah, you are right about= other endpoints (I'd been kind of willfully ignoring them to be honest= ) and I think the specific object in the discovery response that itself cou= ld have any of the same endpoint names in it would be the most straight for= ward way to approach that.=C2=A0
=C2=A0

Best,
Filip

=

On Mon, Jan 7, 2019 a= t 6:22 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&= gt; wrote:
I don't honestly know for sure but I = suspect that employees of big corporations will likely have keys/certs on t= heir devices/machines that are issued by some internal CA and provisioned t= o them automatically (and in many cases without the user knowing and/or und= erstanding that they are there and why). Those users would likely be prompt= ed when TLS handshaking with a server that presents an empty list of CAs in= the certificate_authorities of the CertificateRequest.

=
I dunno. Maybe I was too quick to retract the proposal for the M= TLS supporting secondary token endpoint?

What do f= olks (including Ben & Neil) think?

On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <kaduk@mit.edu> wrote= :
On Fri, Dec 28= , 2018 at 03:55:15PM -0700, Brian Campbell wrote:
> I
> suspect that not having client certs set up is the situation for the v= ast
> majority of users and their browsers. And for those that do have clien= t

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that= is
> able to deal with the UI prompt okay.

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003f5cad057ef42506-- From nobody Tue Jan 8 15:56:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED54512E036 for ; Tue, 8 Jan 2019 15:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1981jH5J6rU for ; Tue, 8 Jan 2019 15:56:29 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471FD12D4ED for ; Tue, 8 Jan 2019 15:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bGbJz3a9J2ZVd1fRZ85bSWFbeEwDBtc9R9Wp/GiL9ew=; b=R5gIZRuVNT3WHDeLC63yIRsvSLUCnq5wIuyz7LsNmP6aMW9+9qbR/m6L8Ku3ulSDnjDdpKGm8xhO+zFsuJuU/rAfbUe1vb7w/37s29auj7qN75GKDMCaWCGaNdBDyXETrG4UIMSeE6gZW8qOvziwvL2mkCucd9XvegnWf5VQcmE= Received: from DM5PR0101CA0020.prod.exchangelabs.com (2603:10b6:4:28::33) by BN8PR01MB5522.prod.exchangelabs.com (2603:10b6:408:ba::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Tue, 8 Jan 2019 23:56:27 +0000 Received: from DM3NAM03FT039.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by DM5PR0101CA0020.outlook.office365.com (2603:10b6:4:28::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.13 via Frontend Transport; Tue, 8 Jan 2019 23:56:27 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT039.mail.protection.outlook.com (10.152.83.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Tue, 8 Jan 2019 23:56:27 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x08NuOPN021185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Jan 2019 18:56:26 -0500 Date: Tue, 8 Jan 2019 17:56:23 -0600 From: Benjamin Kaduk To: Brian Campbell CC: Neil Madden , oauth Message-ID: <20190108235623.GC28515@kduck.kaduk.org> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <20190104215540.GL86936@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(2980300002)(199004)(189003)(106002)(88552002)(426003)(54906003)(6246003)(8936002)(55016002)(2906002)(246002)(446003)(9686003)(36906005)(478600001)(229853002)(58126008)(786003)(1076003)(93886005)(46406003)(16586007)(316002)(956004)(53416004)(26826003)(11346002)(106466001)(476003)(75432002)(33656002)(336012)(6916009)(561944003)(8676002)(23726003)(104016004)(76176011)(7696005)(126002)(50466002)(26005)(356004)(6666004)(86362001)(5660300001)(97756001)(186003)(305945005)(486006)(47776003)(4326008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5522; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT039; 1:u58OMJ1F1J8EmRfKtTiTH4uxFJN29HXH4PIawv+oCms+v/wQ/s+L1VkY70Wcr1dMilSAxO9D3nrPi+YrcUJijWxcyQOhYNUPs09i/Q1s0yO0x900PqEXxDZRed9C0poU X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 41c3f7ce-39c1-4fb0-f12b-08d675c4e76c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:BN8PR01MB5522; X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5522; 3:/eq510MdnZddcr1n979PM9R/gl+rNU/7DjIaehO7kb6vfqdRTJ03R69iO22T4vJmvsUP7cTLLhFteX5Q4KgQHuatPwZCEX/p5K4zsJRuZ4sISfOG4GsNTfAhR3nIjvjq3Y2cKUGEgeE5u0MoAhltZavZPLEnLN+jSMXuzX53NAcsNR27reLjwyj/BxckvsQA9mPfH0cEDYY7NaQ6+UkxnU2Tvq7Vn10IIMUGxBc7/tK8/lAG7W9u+GAW5lONM/8/I2/oqwKEQipkfEjaLfp11TzaY5orMVpbodsY3TLQy8yXTQypF4fjRo0Acq7FuXkBADKgvXr1nl1vLg5UzEKY057X7pfZO+GlSg8Nm1Xp4JHGNlyK6fmBo9y/BXLPzHJP; 25:NpGzLDj0UREuevfHtshSaMMNeNx5/Zbm8FQsXpFiHPKJO3HvzUnh1HRSKUnE+U2f9U0RLTKwVumcTwuUn+ymVhWqpYdnJ03PbNgNt4tFI89+1m3Iw/mhbAmLAkWTcx3iyDffjo3WyJgwZC/YxpKkV4PumdEt4WL45odIFOCFrcyugAz0iZtfOi1coZEReGAyPXbbGpxf9Tfu7kJzwJwxMCJoVcR/YmuUe1otc9qbZ7hVq5RCRKQl+l3dET3Ffy0b0ocfRBjktvgxSm/YXWTv5CZM2Jh6GmHIxutVoA4stN3zlY6A9KUcBQT5WEu7ikx0vhPjxlHfXyUjF1NF8yAIsQ== X-MS-TrafficTypeDiagnostic: BN8PR01MB5522: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5522; 31:IY6C8lEAPJ+Wx95jbb0IEmGG7qkrubD/lhdMQOWCL0pWvW+weZJ43lr9ydebO/9cicAn9GWGnqO0vHdojOaH3MEaZzbCJRApYnY4ZIzQV2Vzv6W9ATwp6iFcMSJcTJpX91DDWJbZuxaWHRZb1sxQ0pD0khjWjfGr4MXavBOk9OnTwuMeGlzSH0Va2G6qPvu1dvwQ8nhACQjmF2+QCwxA2WwTUduuT/CZCu9rwKNM2no=; 20:p2nKVJIpmmmzgULvGxSXmq+xYamjc47xU5e3aSySWxpsvjRDL2KNZkAfPARbsFyyRdjgnFZ7MbaXnl9WndFVyKRx2KRfCs+ovW2zfLoCLiGnxNJdnCUNDIVcaBbFmGeRfSicnqWzN7VX5S70gX/VF3p88MRCK2vdZsWcFHKy+hcw27yfRB1bO6J+QAd2iAhyi9tI3z7BBOeDO14/aLHXXL/gT93yOKEdK9qrtHTJRAJ9Qps4Wwqnj9jR9xmGhKXXOp/PZnasa/++wi5NAgYcfLTf7rWlFSYyA0AmBAf1Z2rOP5h2spo01s4bh3n/vywPx9O9K21wDwtl/ybmjX5c3ON/dq8ksbnGd7o72/kfc9KNXSBI0dReeddSFNOnuz5Bnwg8CeB0yxcdEtZ12rtqbcDmdEqNYIdkWHyfdRBAcI/Parwo2itk5MR/JqLrcaeW7OP31U9N3kN+8VYnu68jeTBPaPi5EBf7ubnN5YKCwCEk9BL64+TfN93ZND+W35k1 X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5522; 4:K+SLcALOJzN9JBt/Lbfh07Cwa6VIYdyC0zbfmxTmy8oydx1fZEHkGJ2XbupchytoyTg9NXzUD5JZ1A6Xx9YUhzKwL/XprLjM1ZwUKysG+jghBTQEn529P7dPiS6ui0UglEw3Clv9m6w8C4bTvSs81le+dlOq9MgIc3AhxXUfvGJqzUzizklLsE/ImTRkBoF+Z59xdigvW+7m/RL+D+u7uQF/g7V6chfIZC2CDbK0tGZejoX7jYT1lXbvELxgFoO4pzyl+WVvNrblRYy9VVW9UynRch20WplGibYW6/7/S058uvY6rWQMB4E2IdbRWab1 X-Forefront-PRVS: 0911D5CE78 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN8PR01MB5522; 23:3d5pSFb+nyvM5cHOuGehzmD6v78eg+ktkyIG2kS0D?= =?us-ascii?Q?wTS6eMcU5rzWW2tjWpfKgatcn4XJRhb3paqA3EueciQXTQpOzZtsayddvTak?= =?us-ascii?Q?FfLGivzi2IUANt2f1xp8zUunAZa9TN4yhtT7qCXATtCdm8WBLQPRjm131FHE?= =?us-ascii?Q?4070I/H9DjWy8A7f6NKJJFDKSaWFd7bvU/65DGWLhjtxLZcV0FwtF485Yujc?= =?us-ascii?Q?tPMQffQAGPnFXvh17DuhKvZ6ojLbdWOiX77Jczn6wpBIlEpZyyrh/2szoNQx?= =?us-ascii?Q?MavwVYm221C1mItKLq5eiDyd6y/QlqroZIm9tjzOsBHAVUfDS3brlPZc6axj?= =?us-ascii?Q?5Vv7amK9b+QRUsF+tZ0jvD4lBtRuHoAPl6vNrvNCB/6B3V3xDOoJ0DkE5Uxe?= =?us-ascii?Q?0/EmQLqSs+Zi+Pv5dqSfCiMb7flyQQLR5n3s1f2ppXGcgCVz5RZkRvFQPb+N?= =?us-ascii?Q?e2aRU7s7uLHC5FdJnBd1ITcyZFan9RdIoJe3HeJqeTr7NFbDyDXWn2fJ+ys8?= =?us-ascii?Q?r0nQMarlo7Q4i+WVJzz7C3CeEYSekxUcZNjSVwAYh8JDf1qkAk0bTKK9diGR?= =?us-ascii?Q?u+w10JUdKwT5KDaK54H44XxV0TcVXSH5XZREfx6N0W+Eb5Ml9OfiJscdsUHe?= =?us-ascii?Q?A99WasZkUmLOdtE01hpEc0nvIaSfsHlkDFR90iPxBmPEGM7Lgy5+7HmZMKxv?= =?us-ascii?Q?uuF/ryEWEBelxeWSiv8p9ANKKFXLvOYZlat+WS95tcnt9kN0unxq7r23rtsp?= =?us-ascii?Q?Xt+e9XxklJLh2uT6JBagLA7Y/hBRi7/j4cbyunlHpbAxOKeWeUhSa/K+MFgB?= =?us-ascii?Q?GSERex5a7NlXCpn6Udfbx52QDb4Y83Hg0sLVPIeKFmdOD2rk0FEzTP8j+LSz?= =?us-ascii?Q?15YCa+ALequtPTjFIWzX5lDGhPnyspTOI0HfZOE7wWv0JWnFKRYhEdpAAo0b?= =?us-ascii?Q?ET0q1Uxv3yONlqbi1P9eRAS4RgpojtqT1lQezyGPWr0rvnd81EdswVUG1lhf?= =?us-ascii?Q?m1zcKyitzMLW9LrKB4zr5IQhRtVFZaBT/yAWvLxc0Dgq2Wvc8Udzcq23EHAN?= =?us-ascii?Q?7NuWcQuYj12QzXBRwN6NSXuiJ+3YTFV7HogT0nVOYSh9Syf68h4LNcKo6Yx0?= =?us-ascii?Q?GsnFD0u4cG7uVR1rH4QT9CB4QR+8dDetDy/vDITxwWhFbSluuFpkmq0tmbvo?= =?us-ascii?Q?4M3W0Y3fpsvT6DIa4/XK9SkEL7vnkyxRvLcuHr3D35mmNassgz9cPaGRZi/0?= =?us-ascii?Q?eKr4GAmF4VDIzPY4Qw3oZxP4IF5Yu9+7zXY8gkDWcSix/Mc77e9oUNJR50gZ?= =?us-ascii?B?UT09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: yj8Au+5laS0S9Qq00krEdarr457kQ4aYMupncj2MGdsjxt+nOIqJseizE2/vvUYzP89aC5iouYv3TcB44j8PluZQUvORO5HPVqWEwQWc3jt7MyhmoEPfrFSnSzqPWH7O3u8sgO4vr+oKajPt4fU/O8JmSoxGbGye54XrWktU+Nzz+gTYjWBxQVvmAXyushOhJxp6bbjrLgaqQhK0uyV2DZ7OQp17une0XcPqpkG2jpN8Gq/HOxcjBr07gsC3r6ySUT9HcMWB220mixpk6VnktfB5VUeZFyc4zpks6uu74t40mkh2rUX3v5IPGH09nzwd X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5522; 6:f/NdopUYd4T13Fa38VW2ryOtNQhY3vcx17PeyCv9XOkzY7dsB9AByjjYl+u7crlvRv6qRPbU9R57HAj08Pi9S3lfgEy8ATYHKNQ7lErRNoubpcPam4JOas34lowtA+sMx6UUs/fS36MQyUrgnhD5pNXxNoJBZDh0E2Kr5Li0pzn6DoMBEvesmz8YuJVEoXn5Nm4ah51QyDJy6lW5iz6etgEkRf1s1wZUzPAtziRn524nhU7SlNZTKbGpYBRrF/40eB/WOMnta3uwE8FB5d9yczecxQL/QH6lIGTyd1+Z8YOQR1MT2eUnc5px8tkY+tEvfncTdKF5upNs1RznHAdJ0W9rrhpgw1UFw5vyffIUhWl9VYJ/KkTrLG4Ku1Cb4okH/qssHlJDwJFW5hcLDFjdKf6sFNqSspV+IpmEg2UEjhgWEMEl+mYI8qhvmBeRaCWH554mPP2EoDLjoNoXny01pQ==; 5:syc9+KHQYXx9Q9G0Y2phCz9u8rSrs3UVrt1jam0JS/fs4qf25EGd6dY8cokln/ZbUoWiA3t46eNNXq+fVSNZDlFSkzY05Puj1NTR3w4rZW63VjNIyuXivgqb7hjThumfSJd7pCOuu7MDo62Yz///jELTDoilj7Isf2qgPzd6tRXorBWgNZGP+rh0XZZHX/4DJ25JogQdp4jKBTefZzLJ3Q==; 7:V5x/wuUr4GqM5A6PWJLPwPdQaabubV0Kn018V1sF2YmjD25uDStYnNdbZ8me3lyVWRRYcH/BuCJihWbAzeKNH0xFrd1/Igtabwu67unZfZdjFHdZbCnQ+5rdH4kx1p7GAM6X1mW4nZ8QMQeaqKWniQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2019 23:56:27.2938 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 41c3f7ce-39c1-4fb0-f12b-08d675c4e76c X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR01MB5522 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 23:56:32 -0000 On Mon, Jan 07, 2019 at 10:21:51AM -0700, Brian Campbell wrote: > I don't honestly know for sure but I suspect that employees of big > corporations will likely have keys/certs on their devices/machines that are > issued by some internal CA and provisioned to them automatically (and in > many cases without the user knowing and/or understanding that they are > there and why). Those users would likely be prompted when TLS handshaking > with a server that presents an empty list of CAs in the > certificate_authorities of the CertificateRequest. > > I dunno. Maybe I was too quick to retract the proposal for the MTLS > supporting secondary token endpoint? > > What do folks (including Ben & Neil) think? Sorry for the slow reply. I agree with Filip that we can't be confident that the affected population is a vanishingly small population, so it probably does make sense to continue thinking about how we can present a better UX. -Ben From nobody Tue Jan 8 21:30:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE78F12D4E7 for ; Tue, 8 Jan 2019 21:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f592BAkF60jI for ; Tue, 8 Jan 2019 21:30:01 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id A028F129AB8 for ; Tue, 8 Jan 2019 21:30:01 -0800 (PST) Received: from [IPv6:2601:282:202:b210:7d0b:3f09:d5ce:3d17] (unknown [IPv6:2601:282:202:b210:7d0b:3f09:d5ce:3d17]) by alkaline-solutions.com (Postfix) with ESMTPSA id EB8B031571; Wed, 9 Jan 2019 05:29:59 +0000 (UTC) From: David Waite Message-Id: <73B00324-DE55-48FD-A21D-B22438A707A7@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_72402306-15C5-468B-A7D7-6C49A2130EA5" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 8 Jan 2019 22:29:58 -0700 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jan 2019 05:30:05 -0000 --Apple-Mail=_72402306-15C5-468B-A7D7-6C49A2130EA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 28, 2018, at 3:55 PM, Brian Campbell = wrote: >=20 > I spent some time this holiday season futzing around with a few = different browsers to see what kind of UI, if any, they present to the = user when seeing different variations of the server requesting a client = certificate during the handshake.=20 >=20 > In a non-exhaustive and unscientific look at the browsers I had easily = at my disposal (FF, Chrome, and Safari on Mac OS), it seems they all = behave basically the same. If the browser is configured with, or has = access to, one or more client certificates that match the criteria of = the CertificateRequest message from the server (basically if issued by = one of the CAs in the certificate_authorities of the = CertificateRequest), a certificate selection UI prompt will be presented = to the user. Otherwise, a certificate selection UI prompt is not = presented all. When the CertificateRequest message has an empty = certificate_authorities list (likely the case with a optional_no_ca type = config), the browsers look for client certificates with any issuer = rather than narrowing it down.=20 Was your testing via XHR/fetch? FWIW, Firefox behavior is determined by a global pick automatically / prompt = every time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt = Safari on macOS relies on the keychain, where a record is created called = an Identity Preference. This is a URL (https or email) to preferred = certificate mapping. Previously, it would create this record the first = time a user selected a certificate, then never prompt again. Chrome seems to delegate to the underlying OS for certificate = management, so on the Mac it has this behavior as well. This means = however that other platforms may have different behaviors. Safari on iOS used to automatically select a single certificate match, = if the query was for a single client CA. I didn=E2=80=99t try with other = small numbers (2, 3, etc) but when exposing the list of all available = CAs as valid client CAs, it would prompt. This may not be the heuristic = anymore, as knowing the name of a client CA (such one issued as part of = a cloud EMM deployment) would allow certificates to be used for = tracking. IE (pre-edge) would allow the behavior to use an automatic cert or = prompt to be configured per-zone, which would allow policy to send a = device/user identification certificate to a particular set of sites by = default. I have no experience with configuring Edge, unfortunately. -DW= --Apple-Mail=_72402306-15C5-468B-A7D7-6C49A2130EA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I = spent some time this holiday season futzing around with a few different = browsers to see what kind of UI, if any, they present to the user when = seeing different variations of the server requesting a client = certificate during the handshake. 

In a = non-exhaustive and unscientific look at the browsers I had easily at my = disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave = basically the same. If the browser is configured with, or has access to, = one or more client certificates that match the criteria of the = CertificateRequest message from the server (basically if issued by one = of the CAs in the certificate_authorities of the CertificateRequest), a = certificate selection UI prompt will be presented to the user. = Otherwise, a certificate selection UI prompt is not presented all. When = the CertificateRequest message has an empty certificate_authorities list = (likely the case with a optional_no_ca type config), the browsers look = for client certificates with any issuer rather than narrowing it = down. 

Was your testing via XHR/fetch?

FWIW,

Firefox = behavior is determined by a global pick automatically / prompt every = time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt

Safari on macOS relies on the keychain, where a = record is created called an Identity Preference. This is a URL (https or = email) to preferred certificate mapping. Previously, it would create = this record the first time a user selected a certificate, then never = prompt again.

Chrome seems to = delegate to the underlying OS for certificate management, so on the Mac = it has this behavior as well. This means however that other platforms = may have different behaviors.

Safari = on iOS used to automatically select a single certificate match, if the = query was for a single client CA. I didn=E2=80=99t try with other small = numbers (2, 3, etc) but when exposing the list of all available CAs as = valid client CAs, it would prompt. This may not be the heuristic = anymore, as knowing the name of a client CA (such one issued as part of = a cloud EMM deployment) would allow certificates to be used for = tracking.

IE (pre-edge) would allow the = behavior to use an automatic cert or prompt to be configured per-zone, = which would allow policy to send a device/user identification = certificate to a particular set of sites by default. I have no = experience with configuring Edge, unfortunately.

-DW
= --Apple-Mail=_72402306-15C5-468B-A7D7-6C49A2130EA5-- From nobody Tue Jan 8 21:54:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A912D7EA for ; Tue, 8 Jan 2019 21:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 FGt3pGHm5jft for ; Tue, 8 Jan 2019 21:54:45 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8F12872C for ; Tue, 8 Jan 2019 21:54:45 -0800 (PST) Received: from [IPv6:2601:282:202:b210:7d0b:3f09:d5ce:3d17] (unknown [IPv6:2601:282:202:b210:7d0b:3f09:d5ce:3d17]) by alkaline-solutions.com (Postfix) with ESMTPSA id 8D8DC31571; Wed, 9 Jan 2019 05:54:44 +0000 (UTC) From: David Waite Message-Id: <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_722DA6B1-35B8-47ED-8966-BFAA2DE6EF7A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 8 Jan 2019 22:54:43 -0700 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jan 2019 05:54:47 -0000 --Apple-Mail=_722DA6B1-35B8-47ED-8966-BFAA2DE6EF7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 28, 2018, at 3:55 PM, Brian Campbell = wrote: >=20 > All of that is meant as an explanation of sorts to say that I think = that things are actually okay enough as is and that I'd like to retract = the proposal I'd previously made about the MTLS draft introducing a new = AS metadata parameter. It is admittedly interesting (ironic?) that Neil = sent a message in support of the proposal as I was writing this. It did = give me pause but ultimately didn't change my opinion that it's not = worth it to add this new AS metadata parameter. Note that the AS could make a decision based on the token endpoint = request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was desired by this public client installation. The AS = could then to TLS 1.2 renegotiation, 1.3 post-handshake client = authentication, or even use 307 temporary redirects to another token = endpoint to perform mutual authentication. Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2=80=9D= -like indicator imply that the client has multiple forms of = authentication and is choosing to use MTLS. The URL in particular I=E2=80=99= m reluctant to add support for, because I see it more likely a client = would use MTLS without knowing it (via a device-level policy being = applied to a public web or native app) than the reverse, where a single = client (represented by a single client_id) is dynamically picking = between forms of authentication. -DW= --Apple-Mail=_722DA6B1-35B8-47ED-8966-BFAA2DE6EF7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

<snip>

All = of that is meant as an explanation of sorts to say that I think that = things are actually okay enough as is and that I'd like to retract the = proposal I'd previously made about the MTLS draft introducing a new AS = metadata parameter. It is admittedly interesting (ironic?) that Neil = sent a message in support of the proposal as I was writing this. It did = give me pause but ultimately didn't change my opinion that it's not = worth it to add this new AS metadata = parameter.

Note that the AS could = make a decision based on the token endpoint request - such as a policy = associated with the =E2=80=9Cclient_id=E2=80=9D, or via a parameter in = the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indicating MTLS was = desired by this public client installation. The AS could then to TLS 1.2 = renegotiation, 1.3 post-handshake client authentication, or even use 307 = temporary redirects to another token endpoint to perform mutual = authentication.

Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication.

-DW
= --Apple-Mail=_722DA6B1-35B8-47ED-8966-BFAA2DE6EF7A-- From nobody Fri Jan 11 02:32:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02912D7EA for ; Fri, 11 Jan 2019 02:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 U5Bvy6J4PLFz for ; Fri, 11 Jan 2019 02:32:21 -0800 (PST) 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 0DC1712872C for ; Fri, 11 Jan 2019 02:32:20 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id q18so14581240wrx.9 for ; Fri, 11 Jan 2019 02:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dWGViHmS6wUil2O0SDDB75wsk0ic4zhhIwdBT5INvBk=; b=R6zRWlWvlIrHD3PhUi+RiYkBaQ6OoM0T/Xq2FMpfc6WtiovbXCimDkCDGQTyc9cDB3 ZnQQf0Lxtz+NXlP46NgFQbg5gBNORhrg0x3tC9EtRD6ZXFhwsv+ZjVSWMED3lwPJZM1f s2cT9FBjHxu136odGDXXKOA8XmG5PcUX38AEY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dWGViHmS6wUil2O0SDDB75wsk0ic4zhhIwdBT5INvBk=; b=LrMy156BqBWNGqd+pkuR5uNVsSJuqIJrUR2OZ9XmHCRpblZpNeOQrOxlShIDsxe+Gz ZdgRIfsWuEjmSwi/PbJieQABgyJazI1nRw26TGTJ25zFQzqUkGlxsbIbMuX1RMUDUn/K D5s4G6u9tIglpLEENTVW08T8m7VHQM1Mx+BmtLHR9BgaJyrOU/eV+uOp99VGNu40uhMe 3mrq1Wa5/Mb5r29l8nUqoLFpxRbhbfdWApQS9IpmR4zRRH3YjwedtsSw58uJ1fUxyp5I PxuIoILjcv2azhVMG77E3/VhOkA2zll5hLhEZs2VhibS991AopGbZB+IzwB0h1spBIW1 DC+Q== X-Gm-Message-State: AJcUukf3TE+kK6pghjsDrhmgxVoTE4+DZ4IxpLgPyMVPuJT+wnwOztjP btS24sHuH/AvT4tqUkHJHOm47w== X-Google-Smtp-Source: ALg8bN7dKHeOvLVQ+ji9kOx2USV1TRFNzDb6kXJiuGF8v/pJpOsnqupkFztOCX1Q8L6j6BylI5f8NA== X-Received: by 2002:adf:81b6:: with SMTP id 51mr13578420wra.240.1547202739115; Fri, 11 Jan 2019 02:32:19 -0800 (PST) Received: from guest2s-mbp.lan (92.150.32.217.dyn.plus.net. [217.32.150.92]) by smtp.gmail.com with ESMTPSA id b7sm55372931wrs.47.2019.01.11.02.32.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jan 2019 02:32:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> Date: Fri, 11 Jan 2019 10:32:16 +0000 Cc: Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> To: David Waite X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 10:32:24 -0000 On 9 Jan 2019, at 05:54, David Waite = wrote: >=20 >> On Dec 28, 2018, at 3:55 PM, Brian Campbell = wrote: >>=20 > >=20 >> All of that is meant as an explanation of sorts to say that I think = that things are actually okay enough as is and that I'd like to retract = the proposal I'd previously made about the MTLS draft introducing a new = AS metadata parameter. It is admittedly interesting (ironic?) that Neil = sent a message in support of the proposal as I was writing this. It did = give me pause but ultimately didn't change my opinion that it's not = worth it to add this new AS metadata parameter. >=20 > Note that the AS could make a decision based on the token endpoint = request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was desired by this public client installation. The AS = could then to TLS 1.2 renegotiation, 1.3 post-handshake client = authentication, or even use 307 temporary redirects to another token = endpoint to perform mutual authentication. Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? A 307 redirect could work though as the server will know if the client = either uses mTLS for client authentication or has indicated that it = wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. > Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2=80= =9D-like indicator imply that the client has multiple forms of = authentication and is choosing to use MTLS. The URL in particular I=E2=80=99= m reluctant to add support for, because I see it more likely a client = would use MTLS without knowing it (via a device-level policy being = applied to a public web or native app) than the reverse, where a single = client (represented by a single client_id) is dynamically picking = between forms of authentication. That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of device policy you are talking about? I am aware of e.g. mobile = device management being used to push client certificates to iOS devices, = but I think these are only available in Safari. =E2=80=94 Neil= From nobody Fri Jan 11 03:51:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541212E043 for ; Fri, 11 Jan 2019 03:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhn4iKnnhFzX for ; Fri, 11 Jan 2019 03:51:04 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A3B129B88 for ; Fri, 11 Jan 2019 03:51:03 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id v6so11974960oif.2 for ; Fri, 11 Jan 2019 03:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yc25wqx9FA1hVOpul5rzJ1Ksny03uGp0nfRYCDJRM88=; b=T9w/GIGKZJQi/beEdfFnGAHYbbBAjphsp80L+Bz0pX4oMoCH5UuE8aZ3EhMF+PgofQ LNdTsGKKL1yZ1qn/Fc2XVI3WRGQaOf+b9PPFD7DnjH6TiDFDhd/w3tt7oazf7E9Efgfm rOhHvyz7W8TN3Ki7bZmV7EZyyYwUruTBoang96yI16SCBWfy7+F0dW+MfEKiYK/+7gga yr5ojN8DPkr2vTrp9Wcqgz98HSgMay2agn0T04fFnzMyY8D/WydlqmmW6iTv6VHdS9Bt vKw9E6/ttBFLvm9cWcFZHn/YPoHx0raBUYoi8EVYLlPhfGily6+z8//RX2sFSHiNPWmB SfUg== 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=yc25wqx9FA1hVOpul5rzJ1Ksny03uGp0nfRYCDJRM88=; b=ANohWX73ohdNQBwTRAyFhhTtnb14GDE4O18VLfK+BCJkePu8xW7/qVcmqAZtt0o8Pi I3Q0P046GPi5bIKp39tpdhZwpW+I2eYgwHvQOOOBeRmSqIIlxcvagYRNfyVGOrNebUHG brXLsUeNttYNdtJBLXofnXfXiFhgKz9n9RpFDj5xFfVSiKA+KmvhT62kY2YkjHZ2dqxc iN71bcstiSSSnnKVS56U3zdnZQSpZYl6MexHQKSJ9OrLKbpKsMhnQbqTJoKk8yzxHcD5 J8U1GEotlhaTnVjbUH1yEY9pxGG1WcIpl+8d7HMhtSlxZPNsCAK/qRVdTTsFsIQPh6y0 eR8w== X-Gm-Message-State: AJcUukezMAST7ma7lF0IY1CbKBFjeyeX2gp0x0VFXAhgIfEVjyN8NaAV ct89jK0fjXvNUNmnXzeofqhH/U3XNA5SR9yVUw== X-Google-Smtp-Source: ALg8bN7Glm8mbmYbebaFMRluaxBWZZbMWcJBxtVWUFvgTUcyu4c0uK79BN5oge331sgBx0ZS6rSrhomF3/EMuros7WU= X-Received: by 2002:aca:fdd0:: with SMTP id b199mr8490112oii.178.1547207463064; Fri, 11 Jan 2019 03:51:03 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> In-Reply-To: <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> From: Filip Skokan Date: Fri, 11 Jan 2019 12:50:51 +0100 Message-ID: To: Neil Madden Cc: David Waite , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000003ada66057f2d4fef" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 11:51:07 -0000 --0000000000003ada66057f2d4fef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 307 indeed seems doable, similar to a discovery namespace it requires the client software to be prepared for this and follow the redirect in that case, but in David=E2=80=99s case it doesn=E2=80=99t require the client to = =E2=80=9Cknow=E2=80=9D it is bound to a device wide policy. The client just assumes it has no form of authentication and only sends the client_id. I=E2=80=99ll try to do a quick PoC for 307 and share any findings i may hav= e. Renegotiation not only isn=E2=80=99t easy to do in some common setups (self= managed tls terminating LB or proxy), but in some is outright impossible - e.g. managed services like AWS ALB or API Gateway that may be in use for regular requests and with self-hosted endpoints running nxinx/apache for just mtls requests on the side. Best, *Filip* On Fri, Jan 11, 2019 at 11:32 AM Neil Madden wrote: > On 9 Jan 2019, at 05:54, David Waite wrote= : > > > >> On Dec 28, 2018, at 3:55 PM, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> > > > > > >> All of that is meant as an explanation of sorts to say that I think > that things are actually okay enough as is and that I'd like to retract t= he > proposal I'd previously made about the MTLS draft introducing a new AS > metadata parameter. It is admittedly interesting (ironic?) that Neil sent= a > message in support of the proposal as I was writing this. It did give me > pause but ultimately didn't change my opinion that it's not worth it to a= dd > this new AS metadata parameter. > > > > Note that the AS could make a decision based on the token endpoint > request - such as a policy associated with the =E2=80=9Cclient_id=E2=80= =9D, or via a > parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indicatin= g MTLS was desired > by this public client installation. The AS could then to TLS 1.2 > renegotiation, 1.3 post-handshake client authentication, or even use 307 > temporary redirects to another token endpoint to perform mutual > authentication. > > Renegotiation is an intriguing option, but it has some practical > difficulties. Our AS product runs in a Java servlet container, where it i= s > pretty much impossible to dynamically trigger renegotiation without > accessing private internal APIs of the container. I also don=E2=80=99t kn= ow how you > could coordinate this in the common scenario where TLS is terminated at a > load balancer/reverse proxy? > > A 307 redirect could work though as the server will know if the client > either uses mTLS for client authentication or has indicated that it wants > certificate-bound access tokens, so it can redirect to a mTLS-specific > endpoint in those cases. > > > Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2= =80=9D-like > indicator imply that the client has multiple forms of authentication and = is > choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to add = support > for, because I see it more likely a client would use MTLS without knowing > it (via a device-level policy being applied to a public web or native app= ) > than the reverse, where a single client (represented by a single client_i= d) > is dynamically picking between forms of authentication. > > That=E2=80=99s an interesting observation. Can you elaborate on the sorts= of > device policy you are talking about? I am aware of e.g. mobile device > management being used to push client certificates to iOS devices, but I > think these are only available in Safari. > > =E2=80=94 Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003ada66057f2d4fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
307 indeed seems doable, similar to a discovery namespace = it requires the client software to be prepared for this and follow the redi= rect in that case, but in David=E2=80=99s case it doesn=E2=80=99t require t= he client to =E2=80=9Cknow=E2=80=9D it is bound to a device wide policy. Th= e client just assumes it has no form of authentication and only sends the c= lient_id.

I=E2=80=99ll try to do a quick PoC for 307 and share any f= indings i may have.

Renegotiation not only isn=E2=80=99t easy to do = in some common setups (self managed tls terminating LB or proxy), but in so= me is outright impossible - e.g. managed services like AWS ALB or API Gatew= ay that may be in use for regular requests and with self-hosted endpoints r= unning nxinx/apache for just mtls requests on the side.

Best= ,
Filip


On Fri, Jan 11, 2019 at 11:32 AM Neil Madden <neil.madden@forgerock.com> wrote:
=
On 9 Jan 2019, at 0= 5:54, David Waite <david@alkaline-solutions.com> wrote:
>
>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40pingiden= tity.com@dmarc.ietf.org> wrote:
>>
> <snip>
>
>> All of that is meant as an explanation of sorts to say that I thin= k that things are actually okay enough as is and that I'd like to retra= ct the proposal I'd previously made about the MTLS draft introducing a = new AS metadata parameter. It is admittedly interesting (ironic?) that Neil= sent a message in support of the proposal as I was writing this. It did gi= ve me pause but ultimately didn't change my opinion that it's not w= orth it to add this new AS metadata parameter.
>
> Note that the AS could make a decision based on the token endpoint req= uest - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D, or= via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indi= cating MTLS was desired by this public client installation. The AS could th= en to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, or e= ven use 307 temporary redirects to another token endpoint to perform mutual= authentication.

Renegotiation is an intriguing option, but it has some practical difficulti= es. Our AS product runs in a Java servlet container, where it is pretty muc= h impossible to dynamically trigger renegotiation without accessing private= internal APIs of the container. I also don=E2=80=99t know how you could co= ordinate this in the common scenario where TLS is terminated at a load bala= ncer/reverse proxy?

A 307 redirect could work though as the server will know if the client eith= er uses mTLS for client authentication or has indicated that it wants certi= ficate-bound access tokens, so it can redirect to a mTLS-specific endpoint = in those cases.

> Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2= =80=9D-like indicator imply that the client has multiple forms of authentic= ation and is choosing to use MTLS. The URL in particular I=E2=80=99m reluct= ant to add support for, because I see it more likely a client would use MTL= S without knowing it (via a device-level policy being applied to a public w= eb or native app) than the reverse, where a single client (represented by a= single client_id) is dynamically picking between forms of authentication.<= br>
That=E2=80=99s an interesting observation. Can you elaborate on the sorts o= f device policy you are talking about? I am aware of e.g. mobile device man= agement being used to push client certificates to iOS devices, but I think = these are only available in Safari.

=E2=80=94 Neil
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003ada66057f2d4fef-- From nobody Fri Jan 11 08:13:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A53126F72; Fri, 11 Jan 2019 08:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX6PoUopVM7a; Fri, 11 Jan 2019 08:13:33 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740133.outbound.protection.outlook.com [40.107.74.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703FA124C04; Fri, 11 Jan 2019 08:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B4iJT/GVtBzSI95aCqYGg2qhDeYHiW8B1D/7lhHD14I=; b=Mx9zN1SkPG7Ux4zNccbP7xUaQWFiDQ4Uv/UYMJb4QV/7uDm7m8FGWZyJEKGEuxESRZAvhC4813t+hF5GYnEwJbs1NyHQJSWTVaRrQakWyQSQYH1LUV4z5d2OkDyBi3Sq9IITnZ8RPrkmYuKPmqTRjE/vdtzlit74lVFF8AAm0Ms= Received: from BYAPR01CA0052.prod.exchangelabs.com (2603:10b6:a03:94::29) by DM6PR01MB4028.prod.exchangelabs.com (2603:10b6:5:2e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.14; Fri, 11 Jan 2019 16:13:27 +0000 Received: from DM3NAM03FT014.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by BYAPR01CA0052.outlook.office365.com (2603:10b6:a03:94::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.14 via Frontend Transport; Fri, 11 Jan 2019 16:13:27 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT014.mail.protection.outlook.com (10.152.82.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 11 Jan 2019 16:13:26 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0BGDLYh019734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jan 2019 11:13:23 -0500 Date: Fri, 11 Jan 2019 10:13:21 -0600 From: Benjamin Kaduk To: Brian Campbell CC: The IESG , oauth , , Message-ID: <20190111161321.GJ28515@kduck.mit.edu> References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(376002)(136003)(2980300002)(54094003)(52084003)(189003)(199004)(51914003)(51444003)(5660300001)(55016002)(229853002)(88552002)(6306002)(2906002)(6246003)(786003)(14444005)(46406003)(54906003)(53546011)(4326008)(126002)(316002)(11346002)(476003)(186003)(30864003)(426003)(336012)(446003)(956004)(16586007)(58126008)(50466002)(26005)(246002)(33656002)(106002)(5024004)(305945005)(76176011)(486006)(53416004)(8676002)(106466001)(8936002)(966005)(356004)(47776003)(7696005)(6916009)(86362001)(104016004)(478600001)(26826003)(345774005)(36906005)(23726003)(97756001)(1076003)(75432002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4028; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT014; 1:Roz7sjfJ6mF7J8Fz/z8kWzyV095Fzsbxt4OmOJx1T7DVKQBpuZjyDTmNvINqpeGh10rirSCQkEjDV4VTYAMxy8nfB594IxtayYx83eCsutH17kyBOd6yVTdiD0uw7Tco X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bd973d3c-8172-475e-d3fe-08d677dfb843 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB4028; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4028; 3:2UOFMPinbcPOOuki6mPbYRERvyoIe0oYXexZD2agf2idjfQIrDOJJFi9XNWNJawK+fg9cYkvvRjnSXtAfuu7lX1ORyR4bjdU8n360FvdXlCkknMN7XmcOckwnl15+/FCrDl4Ukk4SI4l4tiyyfmjXV66kZGjUzznvGXPjMfUIY6OfH3HaislMbI1Kh+jP84RSQLgy7SyOrcc3wypCOmKmZAKvaYhNOchnsYGsQxAHyFfKc0zNkqqUWoLTdT7KUAk3xb/jmfUIv9db4FUyvd1S5ArCzdratdfSXdZraAoQGokMiuesktuglG8dk2mH4KlbgFD11ogzd3c71QOILDeO/I9Lb3q0SA3Ek3cmliEtNTlDv/7UJLuXnBgy+O6MD3F; 25:POh2fF8hsPgLyIAEMsXbGlToCVymG8g18R0udU9o6NdTO+bOufX8VQSd4/n5ZVMYnbNce7YEIvIdAW/jnbb8YEZb+s8qoki3dKV+h8+SY+DIRACWl8EbPXOHntn+F+dbkxnqy2ktYJKQ7wPbrQW+CDThJ33tSXomIhGuLCdME1E3zhaH3IGrQAyKMsssk41xsoJDADypPGL7BytjPRXbAIcmBvrOltRGvHVO3Gol1WqMJhcxnrsMT8NiI/MKx9Rs2LuastgpNnDEg83OcSu+LM4VYlctKhvq1BwY6Knr3XRhiVzDE4G/SfkgqeK3VarSkRvC+SDqiX+7sxdw/WYbPQ== X-MS-TrafficTypeDiagnostic: DM6PR01MB4028: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4028; 31:i5SXM3wpcTaqYwzmu9UMqDJO8xa/3WEYL4T59vjC4rINu3qfIBmW5a1joQUDCdvCjPzzgzL0PiNQ/8eJbbRhz6Sy9TtGARhI2GHyfyDEq8ar/SR0Nsj/qqony1irzFhQqZTXcGLGhQ300o32O0bFzUCGJzUbA6RdPNn9yyfK52+QSOre2enMGlVvVMoSo2dBRDnhDQmAdd35dWncTQUBZ1XUySzMGELMF2p3dirl4cU=; 20:o3l56qS0Hma+CkvyO+eEvfdLGvVCNrjM2iKTKYbrHboGA1pirIQVzmabc2XCTqmSGCrbCO+XFqrMP5F2QBDXeTEwBfJk18HVUTHItqZy4XrGEeUapTwg0oyB0FySykKl7Uc/pEZG40bdOjwNsjiahW696hq1RtmBfb3z4M7FVKPrsgVV+/lbt1gE5wPtz4GRoHFv7ijt1mU2oDhXVj6Jc3NQPym+KowocI/506/Ryqi3qLXTtcdUKxk79vUZ0Eg3MLewpZaJvGq1Nwc89FNdovK0ftii6J91psQtvIQxhg3kcVoQkQWWqsGho2ETgxF7c/QcaPgdxMUTAga7jm8JM6rQ+yNG/PQQIiTZg+esVmFcHgJD3FK3SPJoDboZ13d9WtGyiPaGaQQnsL4yBp56PUXyA0mjtlz/aOCpVfhxytZdXFfv7W2weus9WVqy4nRv7z4DP9KtJgkRpou4fs1deq+Nz4wfcu8wlCDokSIJsvSAViMOYqjFABORaWasUU85dW8I9RN79K7vemLkSLVFVjx2sbb6EOreFcbZcSH7Y6hu1fW3PtQs8O64p2xmy3tO+KZAWZVzLgJhw8MKrSMfltTMHbTgp1Sf91UDll22U7U= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4028; 4:lu1B1b39RrpmDn/TXobuaMO6/4y8yYlXlI/NewOGWYxp4ROOxqEBH1uB8nKdrCDhs/81snVNgZdx1pWQzC36WKrnDubae5EoPs7x+QOCQqXihqZfwdWoC0EiZOVI3dp5dttWJ1WybozozA2xdquodkFD8YJoGYvlUU/JfjnXlyqN9tGtOUEJT73JMkfqF+8UrXfZbg6f11SlV7oRT2XviHp4lg7XaCClNoYDfDxaRz5KZG0bHTC4jpLLzhl9vDvG2kMfQMqiYFI68hZGPcC8+hw9DA3JEVN1oSOr9BiVuTg= X-Forefront-PRVS: 09144DB0F7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR01MB4028; 23:fzRHYKT/A0NOeXmzS57/hFZPbXpMYrbixVZnmlA7l?= =?us-ascii?Q?QSsRVfewysMgnvsMJP6xBsQYB0o5tw0/05oUMZZN//kj6zJCpfT026le2I2i?= =?us-ascii?Q?z/9fiQNCkG1AHW0RgWf6ieFebrGpl7himBOANrF/ecP19tQ4GwxX8xppOOvY?= =?us-ascii?Q?4s+VPK1FhOjiRVOAsfGMDIEjeI/xJVbeERfkwmtYckWSluj3QgR63/NuOR8y?= =?us-ascii?Q?EMK01/zOQ+iOPRjCJAeVE8Ct8AA8LuT+zXD13N9aq6gVyygV6ovgUKeR2aBA?= =?us-ascii?Q?V4A//qrLQfvbSQeTKlVMufWn1tRvBDQgksRzZbtEzinMw8AR3P6omuiX5ryD?= =?us-ascii?Q?FlwJ9ukfxbGYKz+0QJ2WPAsai/SyO+qe/uNPmkpjKZHEYF6Au4I8x+sHKmK1?= =?us-ascii?Q?ZYDKtDd64mPFOeK6OJdTrcLHphxBYgAXlMqGPKKrqspxvlMQ0SfIl0kjjwLS?= =?us-ascii?Q?Dc/U7Em7HVyyNhcgj9c1AKOPezgF0KZNUwp6gyJYXI4zYFBj+kqPM/C91+md?= =?us-ascii?Q?n944bxkbuBkt81aBVzNXfJbPPAloC8YL3R2liQl0f+jEeMkfZW0STdhU/fCy?= =?us-ascii?Q?A1rJxRBlmb2SIX7IUbx0m9ZFeuRqk/UD8bbUn1dXSuHoM4GS4Mni9dYaC3Nx?= =?us-ascii?Q?XQ9PHtdtaAkBEGb0j703cG8HHlSa1UB3hzm23xhE7k1+JU09Uq2PIGTp0bCf?= =?us-ascii?Q?4SxEeqwguPmJBrx4OhYKp/iDNcHjEk3trNNLUyTRL+JSm7va67hmoMvCJHYj?= =?us-ascii?Q?36Tp/CdTaIjDUFLBbKvEldkqvM84WmaMUvacwjT9g6iwoxn/Ck7RVokxr/gc?= =?us-ascii?Q?DqIbDE26HuAraGAwHC1G3juHKrKGIMkqRM2AG1g4obNj9d+WS+wCs7szBQCb?= =?us-ascii?Q?ye5PLyOq6ZYnAHCv32KAq18o+HcIRE0N9oZJXOyGLuSzkX+EdFFsqHz6xFjf?= =?us-ascii?Q?dEjL49tg3JsZjPAYMY9x5E9NZ7r6jhjaZee/RWKHCKMcXYPU6fkU1Uf7qTeJ?= =?us-ascii?Q?WUgB3g5Y/WsWRoXiqfeiMaJu4n+JjVTC/rtygfGXu9d7txyYwA4v/JGkIAEu?= =?us-ascii?Q?ff3Hfu/TvwQA2unCa0Vh7HQTFVRtXblG9Jjui/0Nj9Qs9Wk1v7hTuUy+iMcq?= =?us-ascii?Q?2gQa2RoLBArguPett0R11z8qiYD7auX+eg//b0tzwSyNntQ79u5xb4yqsejo?= =?us-ascii?Q?Qz6TifHl6Oo3HXhcgcdtXaRD4WzBP6XNAETQbQ/DqUNextgu5ZPzz4y4d1r4?= =?us-ascii?Q?Gu3XjGfl78N8e/uO2wiZB5my8vQqsqssavbvvKUswLpEwJg8Hrv1qJsVn704?= =?us-ascii?Q?Mb0KyJW3uFufGaBh8RFcYzKEs442zfWumgTu3FUijiD3Z4J1ALY/E+icHLCx?= =?us-ascii?Q?difpSQ1Z9ekuSYwbPX3kwhoHJbkgs5uzRIVgVm3nKkqjt9KkfvPHCRi1eFqg?= =?us-ascii?Q?qlcErnK0/LHc18VumBcrZxF/rX9yNo=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 6UDitx9z/V9U7up6phbWXokZz0ILYe0L4gMaQNIBwpKo3HHuWRPFuuFf5J0rFes23M44tQHu3CqT/8/Mr3YQ2SbRHCUzUDN3Mq9DAnaBgFl41WUrygUrAIjDpKiUdU7vue6Sg3RtUj2F8j7HgllbORgnxFZHPfZHfq+s33jswoEpFPO81kMd9lxUXQ6NsFKYjw4rWnz2hpB3t152INVbgh/1xfiKkUwteOgiaoSvT8k9Rtpin9yxf65DL0nky2IAZQ0CLbooALk4rdctwtJuvZLilFaHvlVcC7ZMxKP1G5EZrKJwe1U3bJaq05lA0es1uWd1Cme50mjGMVzRIlcXURy+8TqizEL23696zwo4Qe9AXga065Ww71cvze2W/ciONE4R+61ctgaPTCxeppUO27E496wsPBFA/Mqs/luYJJI= X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4028; 6:cHX8AZrrVKSOxEQZPM9rBzrYkiQ98qNyRNIWuS4sw0Oi2arrdpDOvVuWpJLoqLuGj/mbzyuFlieEffVenmLUa8DPRDrywwrgJHwLNrfb3/HhG28tlqrfe4jZawCda5oVhJEiBppM6VdGm++/PVnHXqWJBpSXtT47B2x30tK0fS+wM4iWl8HRmXYHlng7J2nfcbviYFY2J+h+cxfb90l4dNNnX40Qc5IdulTMKhw5DXcErijbsMxG+29QriU2yHNAOkVk4nsR4b6eU1i15sAWBxtVzE02GslmuxzrDxuZ+pVMx/C2eO96/gpUYcPjh9rRdLtpSp+UCBO5QdI4Um2U+a3G/kJE1EZLRxwk7p7O8mfEhX6L9UQM8crGv5LF7UrHe15j8p1+owEKMvm8KsUIEtoDX/StQIt8ZW9l2xMyztp6iyTTD2FEDwuEZBD4NbU6r60ZjLaxlivWwudpDWcDbA==; 5:nCjbvPBho5sLA2l4hC4Rs5V3TFIIanaI0vg3KQB21lILS/DhzYh+Bg+LVwd38aNoGDTFyjOxVeXYvqh4d2rQ1IFRnUAYL6ijt5eEQRiUcJCeMKZui0BdfdNvUVsWen/W7Cm+BO+cYpBzeHXjUOqwWJ9WyoiyN9/UkVrP4z55G9UZB1WHy707uVqurLKJKN6KeeCfNbFV2zZyeNNPm5VVsw==; 7:9uJiluLIeqrXaTQ2wk1XPrCtNltT2pMO4TcjccP80ffX/a9Mu+2UDBB+I3mQgBrH2NflHIMqBEcA9REukS9CC+PrTgUiPWgjRciNCYMjiVYPyOqDkO08f4p8OEyZSsDF8/IdN3rYR/YUWpyuzHTXBQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2019 16:13:26.6900 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd973d3c-8172-475e-d3fe-08d677dfb843 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4028 Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 16:13:38 -0000 I also apologize for the slow response (I gave Brian a unicast heads-up earlier) -- between vacation, the holidays, and a death in a the family I was away from email for quite some time. On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > I apologize for the slow response, Ben. I was on vacation with my family > around the Thanksgiving holiday when the ballot position came in. And even > on returning and starting to work on it, there's an awful lot here to get > through and this kind of thing is very time consuming for me. But thank you > for the review - I've attempted to reply, as best I can, to your > comments/questions inline below. > > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-token-exchange-16: Discuss > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > It looks like allocations in the OAuth URIs registry are merely > > "Specification Required", so we should not have the expectation of WG > > exclusivity and thus are squatting on unallocated values here. > > Process-wise, that's not great and the IESG shouldn't approve a document > > that is squatting on codepoints. > > > > In retrospect, RFC 6755 should have > used "RFC Required" for the OAuth URIs registry. But that was 2012 and 6755 > was my first RFC and I was even more clueless back then than I am now. And > what's done is done. > > In practice the only entries that have been made to the registry have been > from RFCs and the only prospective entries (that I'm aware of anyway) are > in documents that are on track to be RFCs. This document has followed the > same procedures with respect to the OAuth URIs registrations as those other > documents. > > Having said all that, I'm unsure what action you are expecting to see as a > result of this DISCUSS comment? There's two obvious routes -- first, to change the text to use placeholders like "TBD1" or "the token-exchange URI" (e.g., as opposed to urn:ietf:params:oauth:grant-type:token-exchange specifically) and request that IANA allocate the specific suggested values; or to get IANA to explicitly confirm that these values can be registered and will be marked as pending until this document is finalized (to prevent allocation "under our nose" by other means). Ekr and I can help mediate any IANA interaction needed for whatever route we end up taking, if needed. (Basically, this is a process concern -- the IESG should not give its stamp of approval to a document in a state that does something we don't want other people to do, even if the final published RFC will be able to make these claims correctly.) > > > > why do we allow both client authentication (i.e., using an > > actor token) and a distinct actor_token request parameter? Is it > > supposed to be the case that the actor_token parameter is only supplied > > for delegation flows? If so, that needs to be made explicit in the > > document. > > > > Client authentication is inherited from RFC 6749. It's optional but can be > useful for deployments that want to "lock down" who can invoke token > exchange. > > The actor_token and subject_token are inputs into the exchange. They have > to be validated but that is not exactly authentication per se. Honestly, I > struggle with the wording and how to describe it all (here and in not > dissimilar contexts of the authorization grants of RFC 7522 > and 7523 > ). I've done the best I can in the > document. If you can propose some text that you think would make things > more clear or explicit, that'd help progress this. But I honestly don't > know what to add or change here. Before I start trying to tweak text, can you confirm that the actor_token request parameter is okay to use in both delegation and impersonation scenarios? > > > > > > Are the privacy considerations (e.g., risk of a tailed per-request > > error_uri) relating to the use of error_uri discussed in some other > > document that we can refer to from this document's security > > considerations? (I say a bit more about this in my COMMENT.) > > > > I am not aware of any document with such considerations and I've searched > the likely suspects of RFC 6749 and RFC 6819 but don't find anything. > > The error_uri token endpoint response parameter was defined in the original > OAuth 2.0 framework document (RFC 6749) and any considerations around it > are applicable to considerably more than this document. It's also very > rarely used in practice as far as I know. I don't think that this document, > which is a narrow extension of a whole framework with a series of other > documents that use error_uri, is the appropriate place to add privacy or > security considerations about error_uri. Perhaps > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ would be > more appropriate in scope and content? Oh, definitely -- I only asked if there was something existing we could cheaply reference; this is definitely not the place to be writing this down from scratch. Thanks for doing the search! > I could remove the one mention of error_uri in this document? It's usage > would still be possible/valid by virtue of this document being an extension > of RFC 6749 but, out of sight and out of mind, and this doc wouldn't then > encourage new usage of it anyway. While usage isn't really happening anyway. I don't mind having the reference there; it's not really causing problems and could potentially be helpful. We should be able to get away with a generic reference to this class of thing elsewhere and one-sentence description ("when a proxy or similar mechanism is in place to protect client privacy, the error_uri mechanism can induce the client to lose some anonymity by dereferencing a URI pointing to a third party server that can leak information to the attacker, in a similar fashion as [ref]"). I don't have a [ref] handy right now, though; I'll need to ask around. In a pinch we could fallback to analogy to open-redirector issues, though we differ in which actors are receiving/conveying/acting on untrusted input, and we can have issues just by making the request as opposed to the user mis-interpreting the returned resource. But to reiterate, I'm only looking for a brief mention that some clients might care and don't need an exhaustive description. > > > > > > Section 2.1 has: > > audience > > OPTIONAL. The logical name of the target service where the client > > intends to use the requested security token. This serves a > > purpose similar to the "resource" parameter, but with the client > > providing a logical name rather than a location. Interpretation > > of the name requires that the value be something that both the > > client and the authorization server understand. An OAuth client > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > > examples of things that might be used as "audience" parameter > > values. [...] > > > > How does the STS know what type of identifier it is supposed > > to interpret the provided audience value as? > > > > The STS will have policy and configuration for the target entities for > which it supports the issuance of tokens to in this flow, even if/when > those entities are different types of things. The STS will have to search > that set of things to find the right one for the given name. In theory I > suppose there's potential ambiguity or even name collision. But in practice > (as it is the STS that ultimately decides the names it supports and can > service) I don't believe there is an actual issue. Okay, so at some point we're essentially just doing a lookup based on audience string, and the type information is attached to the lookup results (along with everything else needed). Do you think it makes sense to add a sentence after the non-elided quoted portion, something like ``However, "audience" values used on a given authorization server must be unique within that server, to ensure that they are properly interpreted as the intended type of value.''? (I'm of course open to other suggestions, including "just leave it as it is"; I think what triggered me to comment here is that "both the client and the authorization server understand" leaves open the possibility that the AS might share one understanding of a string with one client and a different understanding of that same string with a second client, since it's only a pairwise condition but we probably are safer with a global condition.) > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > The document could perhaps benefit from greater clarity as to whether > > "security token"s refer to inputs, outputs, or both, of the token > > endpoint (for the interactions defined in this specification). > > > > I have been aware of the potential need here and endeavored to be clear > about it throughout the document without being overly repetitive or wordy. > I will take another pass through the text and look for opportunities to > further clarity. But if there are specific points in the doc that you > believe need attention, please point them out so I can be sure they get > addressed. I made another quick pass, and it is better than I remembered. So thanks for the efforts, and sorry for maligning the document! Maybe 2.2.1's "token_type" description could reiterate "issued security token" both times that "security token" appears instead of just the second time, though the context really ought to be enough to make this one clear. Other than that, the only potential trouble I see is in the introduction when we get a barrage of the string all at once. And even that's in reasonable shape, with the only potential changes I see being in the first sentence of the second paragraph, something like "capable of validing security tokens provided to it and issuing new security tokens in response". > > > > > Section 1 > > > > The OAuth > > 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens > > [RFC6750] have emerged as popular standards for authorizing third- > > party applications access to HTTP and RESTful resources. [...] > > > > nit: possessive "applications'" > > > > Will fix. > > > > > > Section 1.1 > > > > This section really jumps in quickly with no lead-in to why we would > > care or transition from the introduction. I suggest: > > > > One common use case for an STS (as alluded to in the previous section) > > is to allow a resource server A to make calls to a backend service C on > > behalf of the requesting user B. Depending on the local site policy and > > authorization infrastructure, it may be desireable for A to use its own > > credentials to access C along with an annotation of some form that A is > > acting on behalf of B ("delegation"), or for A to be granted a limited > > access > > credential to C but that continues to identify B as the authorized > > entity ("imperesonation"). Delegation and impersonation can be useful > > concepts in other scenarios involving multiple participants as well. > > > > Documents written over time with more than one author sometimes bear the > scars of that process in disjoint transitions, which is the case here I > think. > > You're suggestion nicely takes the edge off the transition and provides > context for it. Thanks, I'll add that text to the top of sec 1.1. > > > > > Section 2.1 > > > > For example, [RFC7523] > > defines client authentication using JSON Web Tokens (JWTs) [JWT]. > > > > Please clarify that these are still bearer tokens. > > > > Okay. > > > > > > The supported methods of client authentication and whether or not to > > allow unauthenticated or unidentified clients are deployment > > decisions that are at the discretion of the authorization server. > > > > It seems appropriate to note that omitting client authentication allows > > for a compromised token to be leveraged via an STS into other tokens by > > anyone possessing the compromised token, and thus that client > > authentication allows for additional authorization checks as to which > > entities are permitted to impersonate or receive delegations from other > > entities. > > > > I'll add a note that says as much (borrowing heavily from your words, > thanks). > > > > > > The client makes a token exchange request to the token endpoint with > > an extension grant type by including the following parameters using > > the "application/x-www-form-urlencoded" format with a character > > encoding of UTF-8 in the HTTP request entity-body: > > > > Is there more to say than "just use UTF-8"; any normalization or > > canonicalization issues to consider? > > > > Nope, no normalization or canonicalization at this layer. Okay, thanks for confirming. > Note that Adam Roach did raise a DISCUSS around citation for the media type > https://mailarchive.ietf.org/arch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DYw , > which might result in a change to the wording here but it's still > x-www-form-urlencoded with UTF-8 as is better described in > https://tools.ietf.org/html/rfc6749#appendix-B Sure; I don't expect those changes to introduce any concerns of the nature I was asking about here. > > > > > subject_token > > REQUIRED. A security token that represents the identity of the > > party on behalf of whom the request is being made. Typically, the > > subject of this token will be the subject of the security token > > issued in response to this request. > > > > nit: I think there's a subtle grammar mismatch here, where we start off > > by talking about a/the request and end up with "this request". > > > > So changing that last "this request" to say "the request" would fix the > mismatch? I think so. > > > > In processing the request, the authorization sever MUST validate the > > subject token as appropriate for the indicated token type and, if the > > actor token is present, also validate it according to its token type. > > > > I misread this the first time around; I'd suggest something like > > "perform the appropriate validation procedures for the indicated token > > type" (as opposed to just verifying that the presented token is a > > syntactically valid instance of the claimed type). > > > > Makes sense, I'll update accordingly. Thanks. > > > > > In the absence of one-time-use or other semantics specific to the > > token type, the act of performing a token exchange has no impact on > > the validity of the subject token or actor token. Furthermore, the > > validity of the subject token or actor token have no impact on the > > validity of the issued token after the exchange has occurred. > > > > Do we really want this strong of a statement? I suspect that in many > > environments propagating, e.g., expiration time to the exchanged > > credential may be desired. > > > > The statement was not in any way intended to prohibit propagating > expiration time (or other criteria) to the exchanged credential. The > statement was added, best I can recall, in response to a question that came > up in a WG chair review asking if the input token(s) would somehow become > invalid once used as input to the exchange. Or if some later expiration or > other invalidation of the input token(s) would somehow invalidate the new > token. The point of the statement in the doc was to try and say that there > is no inherit linkage effectual relationship between the tokens outside the > exchange event. There could be but that's not a general property of the STS > protocol a would be specific to a particular token type or deployment. > > Does that make any more sense? Do you think the wording could/should be > adjusted? That makes perfect sense for what we want to happen, yes. I wonder if we really want the second sentence to be saying something like "The exchange is a one-time event and does not create a tight linkage betwee the input and output tokens, so that (for example) while the expiration time of the output token may be influenced by that of the input token, renewal or extension of the input token is not expected to be reflected in the ouput token's properties. It may still be appropriate to propagate token revocation events, though." (This bit about revocation is perhaps even more interesting than expiration time, and would seem to be prevented by the current text.) > > > > > Section 2.2.1 > > > > token_type > > [...] > > contents of the token itself. Note that the meaning of this > > parameter is different from the meaning of the "issued_token_type" > > parameter, which declares the representation of the issued > > security token; the term "token type" is typically used with this > > meaning, as it is in all "*_token_type" parameters in this > > specification. [...] > > > > Please disambiguate what "typically used with this meaning" means. > > Perhaps it would be even more clear to change this field's name to > > "token_access_token_type" to match the name of the registry? > > > > The "token_type" parameter is defined in RFC 6749 for a successful response > from the token endpoint so this document effectively inherits it. The name > is already defined in RFC 6749 and not in scope for this document to > change. > I will update the wording to disambiguate "this meaning" per your request. Okay, thanks. > > > > Section 2.3 > > > > The following example demonstrates a hypothetical token exchange in > > which an OAuth resource server assumes the role of the client during > > token exchange in order to trade an access token that it received in > > a protected resource request for a token that it will use to call to > > a backend service (extra line breaks and indentation in the examples > > are for display purposes only). > > > > We could maybe add some commas or parentheses to help the reader group > > the various clauses properly. E.g., it is "(trade an access token (that > > it received in a protected resource request)) for a token...", not > > "trace an access token that it received (in a protected resource request > > for a token)", where parentheses indicate logical grouping. > > > > Will try and do some grouping. > > > > > > > grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange > > &resource=https%3A%2F%2Fbackend.example.com%2Fapi%20 > > &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC > > &subject_token_type= > > urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token > > > > Figure 2: Token Exchange Request > > Is there really supposed to be a %20 in the resource query parameter's > > value? > > > > Nope. Nice catch. Thank you. I'll remove it. > > > > > > > The token octets in Figures 3 and 4 do not match up, despite the prose > > indicating that they are the same token. > > > > Indeed they don't. Look like I missed one token example when updating claim > names. I'll fix that. Thanks for catching that one. > > > > > > > Section 3 > > > > Would it be appropriate to note (here or elsewhere) that for non-JWT > > token formats that are a binary format, the URI used for conveying them > > needs to be associated with the semantics of base64 (or otherwise) > > encoding them for usage with OAuth? > > > > My thinking had been that it'd be more or less self-evident to the very > small group and type of people who would ever undertake such a thing. But a > brief note to that effect couldn't hurt. I'll add something as such. > To be clear, I wouldn't mind if you decided to leave it as is. But thanks :) > > > > > Token Exchange can work > > with both tokens issued by other parties and tokens from the given > > authorization server. [...] > > > > Does "work with" mean "accept as input" or "produce as output" or both? > > For input, as both subject_token and actor_token? > > > > Both and yes. Okay. (I don't have any text suggestions, and as-is is probably fine.) > > The following token type identifiers are defined by this > > specification. Other URIs MAY be used to indicate other token types. > > I'd also link to the registry here. > > > > The aforementioned other URIs may well be in different namespace so won't > ever be in the registry. And that registry also has entries for things > other than token types. So I don't think a link to it here would be > particularly helpful or even appropriate necessarily. Ah, good points. > > > > > Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted > > differently than the other URIs listed? > > > > The list of the ones defined in this doc is a list > with each URI in the list appearing in a while the > :jwt URI is defined elsewhere in RFC 7519 but relevant enough to warrant > mention in this doc and it is enclosed in a tag. I > feel like I've seen this style of treatment of literal values with list > items and in paragraph text in other documents so considered it "normal". > Is there a better or more recommended way of doing this kind of thing? Nope, what you did is fine. I think I managed to forget that I was reading a list of identifiers *defined by this specification* before I reached the end of the list :( > > > > > > Section 4.1 > > > > Do we want to consider a more self-describing subject identifier scheme, > > akin to > > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ? > > > > There's nothing precluding the use of such a scheme (well, except that doc > doesn't actually define a claim so some claim is needed) but the scope of > this document isn't to be that prescriptive in subject identification. Okay. > > > > > The example in Figure 5 appears to be using the "implicit issuer" > > behavior wherein the "iss" of the actor's "sub" is assumed to be the > > same value as in the containing structure. I'm not a fan of this type > > of behavior in general, but if it's going to be used, you need to > > document the possibility in some fashion. > > > > I'm not a hug fan myself but that's what OpenID Connect did and so it often > rears its head. > > I've tried to make examples that will be meaningful to readers and also > somewhat likely to be realistic. > > In this section it does say: > "For example, the combination > of the two claims "iss" and "sub" might be necessary to uniquely > identify an actor" > > And sub in RFC 7519 says: > "The subject value MUST either be scoped to be > locally unique in the context of the issuer or be globally unique." > I guess this could fall into the "globally unique" bucket, that's fair. (And this was a non-blocking comment anyway...) > > > > > > I might also consider some language about how "the nested "act" claims > > serve as a history trail that connects the initial request and subject > > through the various delegation steps undertaken before reaching the > > current actor. In this sense, the current actor is considered to > > include the entire authorization/delegation history, leading naturally > > to the nested structure described here". (But see also the other ballot > > comment about this potentially leaking information to unauthorized > > parties; it seems a more careful adjustment of the text is in order > > here.) > > > > Okay, I can add something to that effect. > > > > > Section 4.2 > > > > Is this really the first time we're defining "scope" as a JWT claim? I > > would have thought that would be defined long ago... > > > > Some things haven't historically happened in OAuth the way one might very > reasonably have expected. And this is one such thing. > > > > > > > Section 4.4 > > > > Just to double-check: this is "things that can act as me" (where "me" is > > the subject of the token containing this field), right? > > > Yes. Honestly, I have a hard time seeing this claim actually being used in > practice. But maybe I'm wrong. And I'm just the editor on this one. But > yes, that's the intended meaning. Okay. I think the this text has a pretty clear reading, but just wanted to double-check that I was getting the expected meaning from it (so no change suggested). > > The > > parenthetical "May Act For" doesn't really help me decide whether this > > claim represents the source or target of a permitted delegation, so > > maybe "Allowed Impersonators" or similar would be more clear. Even "act > > as" or "act on behalf of" instead of "act for" would help me, I think. > > [This would have trickle-down effects to later parts of the document as > > well, e.g., the IANA Considerations.] > > (Not that I claim to be a representative population, of course!) > > > > On looking at it again, I agree "May Act For" isn't a particularly good > name nor is it helpful in understanding it. I admit to having a hard time > with the language here. But, yeah, "May Act For" isn't very good. > > What about "Authorized Actor" in the parenthetical and "Authorized Actor - > the party that is authorized to become the actor" for the Claim Description > in registration? > I think that's an improvement, thanks. > > > It would probably also help greatly to note that when a subject_token is > > presented to the token endpoint in a token exchange request, the > > "may_act" claim in the subject token can be used by the authorization > > service to determine whether the client (or party identified in the > > actor_token) is authorized to engage in the requested delegation [or > > impersonation]. > > > > Okay, I can add something to that effect. > > > > > > Section 6 > > > > Let me say a bit more here about my perception of the potential privacy > > considerations involved in the use of an error_uri (so we can figure out > > if they are already discussed in a relevant document that we can cite; > > JWT itself doesn't seem to cover this topic). By sending an error_uri > > instead of an error string, the server is in effect causing the client > > to make an outbound request to a URL of the server's choosing. If there > > is a proxy between the client and server, this could result in the > > server (and/or a party controlled by the server) learning additional > > information about the client's identity/location. A malicious server > > could also attempt to construct a URI that, when retrieved by the > > client, performs some unwanted side effect. Defenses against this > > latter scenario are pretty well known in the web comunity, but we may > > want to be sure that the need for them is mentioned in a discoverable > > place. > > > > Thank you for the further explanation. As I wrote earlier, however, the > error_uri response parameter was originally defined in RFC 6749 and any > privacy or security considerations for it are applicable to considerably > more than this document. > > > > > Appendix A.1.1 > > > > In the following token exchange request, a client is requesting a > > token with impersonation semantics. [...] > > > > What part of the request indicates that impersonation semantics are > > requested? > > > > I guess it's not explicitly requesting impersonation semantics per se but > only a subject_token is being supplied in the request so impersonation is > kinda implied as there is no party identified that could be delegated to. > > Do you think the wording should be qualified as such or otherwise adjusted? I could go either way, but if I was adding something, I'd go for a parenthetical "(with only a subject_token and no actor_token, delegation is impossible)". > > > > > > Is the use of the "jwt" subject_token_type appropriate, given the > > previous discussion about id_token/access_token being generally > > preferred (as conveying more meaning)? > > > > The issuer of that token isn't the given AS so it isn't an access_token. > And it doesn't have all the claims required to be an id_token. That leaves > JWT. And JWT is used a lot in the examples so their claims can also be > seen and an "identity" can be traced through the exchange. Okay, thanks for the clarification. (And for all the changes!) -Benjamin From nobody Fri Jan 11 09:33:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29916127133; Fri, 11 Jan 2019 09:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPyefn858Ngf; Fri, 11 Jan 2019 09:33:30 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650119.outbound.protection.outlook.com [40.107.65.119]) (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 C83F6126CB6; Fri, 11 Jan 2019 09:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tfy69V3txYICBOoOfyY8TR+tRYSboPnMM+IzJDXpt1s=; b=aBvTbrWUqKq3ZvRswXDbk88tMm6bB9Oj+KMyjsMnzS0xEMrFxwNiaH1uJyjp5WrFYr3ooSQhsiNdMP25RQsU5Gvb340actBHDMg4VOCrwg6jxaSdoCAIy82lkeoo5T9LFcJFYfkPyK0wt2bQKDZxFGlZfleNt+RaRcrEbu7oOBE= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0324.namprd00.prod.outlook.com (52.132.20.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1557.0; Fri, 11 Jan 2019 17:33:27 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::e876:48dc:3e2d:b8d6]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::e876:48dc:3e2d:b8d6%9]) with mapi id 15.20.1561.000; Fri, 11 Jan 2019 17:33:26 +0000 From: Mike Jones To: Benjamin Kaduk , Brian Campbell CC: The IESG , oauth , "draft-ietf-oauth-token-exchange@ietf.org" , "oauth-chairs@ietf.org" Thread-Topic: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) Thread-Index: AQHUgaA83o63Ctfi6EGnHXCCSjitvKVvNKQAgDtZP4CAABYYEA== Date: Fri, 11 Jan 2019 17:33:26 +0000 Message-ID: References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> <20190111161321.GJ28515@kduck.mit.edu> In-Reply-To: <20190111161321.GJ28515@kduck.mit.edu> 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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-01-11T17:33:22.2566649Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b:6d76:be55:e2cc:2f0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0324; 6:Ddl1/VUIbx/thiX+bRJNh0XKH9t9ReGvlEh1iwsgK43My7AKdKzy7HNFx4OIJzb6ZrduNPk8LrtjINufdny0gAB4ZPwsMjR8eaGFdlbaUwAegl7FBSL2ialLcDXQ9LIil/hbkSVRi+2EixR+Kt0pZrSNBzZdYdGeiP5Pf6fGZhD45Ts4KsZbJlMOlEwuAYsZFKXtiV8p6l2D4gyJS//r0h1J/MDcDGWVPHnpocAvvP7FN1DCM/zJRO7prt0fiuGw9SFeKI9Km0+VhoUym0/2AKgfw0bszSBMxqLnCjKuA5PfJOczqxK86YlMsxe+XsE1tJDQ4jshpFOaksvpcz6GjtaDexAVOtWkJOPxbTA1WnJPTYO7nCtrKUETus2dR2Yv53bkkttwT/q9Yh1x0VYJv93WW7OujX7aMw9FQhuNQkSh9ZLeGfeQ2HbW20RzEVZdolcF2emSAHRv4VKE4fT2Aw==; 5:V85KFsSBXlFOkf1MIBUUdVWK4NTCPsjwf+Fe9KC8OTNnUjJ5ANWIt5auS52IQ7tCbVN7mf+NEOHQUrXjDxQK0CGa32xqwOYtHewANlMFXQRwfaEJQiiEcJmgqYfUd0RRO1Y4/YSRBUGxmJfxW2AYrDHnnByQ6hunNvJH/QDdj1IjJkEgC/yRBGqObxFlG/Q8ARjD31dAzQ5Ssa0XNGO9gg==; 7:TZnOQi52/hJSSQcIGssfy9wuWXD5wsQcbQL29xfJqWh/YRK8e3nE7FtvwxAdYEhpW7pQcTyoolDe0ZIh8nihN5kaKkDjHP5QnHu+gPpRCiHqJdqZjVltb58zOqz9VyBDbRS7abK2n2VqkTzGOyunRA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ba673850-5dc4-485c-d5a9-08d677eae502 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:BL0PR00MB0324; x-ms-traffictypediagnostic: BL0PR00MB0324: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(346002)(366004)(39860400002)(376002)(13464003)(52084003)(189003)(51914003)(51444003)(199004)(54094003)(33656002)(81156014)(966005)(72206003)(2171002)(53946003)(6306002)(9686003)(8936002)(55016002)(53936002)(81166006)(478600001)(14454004)(97736004)(5024004)(76176011)(11346002)(71190400001)(71200400001)(10290500003)(110136005)(256004)(6436002)(22452003)(68736007)(14444005)(7736002)(316002)(345774005)(30864003)(6246003)(305945005)(4326008)(25786009)(229853002)(54906003)(99286004)(86612001)(6346003)(86362001)(446003)(53546011)(6506007)(5660300001)(2906002)(8990500004)(6116002)(102836004)(10090500001)(8676002)(186003)(74316002)(46003)(7696005)(105586002)(476003)(486006)(106356001)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0324; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cKTfChftHi2sxIrq1NimXw7Zr05nI8minVOgUxP/pi9Nk7tPC27bZg5SZbb+RFUb++TWQR99/arhO5K3EA7LHnTX68h9fMWytlJMGqPNC8DJq5l3xt2zd9mh4qXbrvS4RDgfc+h0gcgnR0F0fwk5VU4R8W0SVVEPu/YZmQMaJZn+MTT1RVhaXOjHybGZEE84qOH+PIAoIRInCYq2OMupNDPsbyklKm07x8gSgQTjxymG4hrio7SVr4ke0hlx/rmihyy/b/nOpWkufjRRn0HgEsxhqmP2hIz7gqrwsv6J7+y0U/hwyy0OSphBv/6UoCmG82nfVmAH/c+/uVa0gyRdFDTiWMwfcVQ2Y6Q6sViAvtZbaG8PTjlrkcYCq/78lw6ah8hUPl+aO3CPBTOXH6kUCowkN5Am2KTuWZfRxmm/kqI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba673850-5dc4-485c-d5a9-08d677eae502 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 17:33:26.4546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0324 Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 17:33:34 -0000 I would advocate requesting early registration for urn:ietf:params:oauth:gr= ant-type:token-exchange. -- Mike -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, January 11, 2019 8:13 AM To: Brian Campbell Cc: The IESG ; oauth ; draft-ietf-oauth-toke= n-exchange@ietf.org; oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-= exchange-16: (with DISCUSS and COMMENT) I also apologize for the slow response (I gave Brian a unicast heads-up earlier) -- between vacation, the holidays, and a death in a the family I w= as away from email for quite some time. On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > I apologize for the slow response, Ben. I was on vacation with my=20 > family around the Thanksgiving holiday when the ballot position came=20 > in. And even on returning and starting to work on it, there's an awful=20 > lot here to get through and this kind of thing is very time consuming=20 > for me. But thank you for the review - I've attempted to reply, as=20 > best I can, to your comments/questions inline below. >=20 > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: >=20 > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-token-exchange-16: Discuss > > > > Please refer to=20 > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > It looks like allocations in the OAuth URIs registry are merely=20 > > "Specification Required", so we should not have the expectation of=20 > > WG exclusivity and thus are squatting on unallocated values here. > > Process-wise, that's not great and the IESG shouldn't approve a=20 > > document that is squatting on codepoints. > > >=20 > In retrospect, RFC 6755 should=20 > have used "RFC Required" for the OAuth URIs registry. But that was=20 > 2012 and 6755 was my first RFC and I was even more clueless back then=20 > than I am now. And what's done is done. >=20 > In practice the only entries that have been made to the registry have=20 > been from RFCs and the only prospective entries (that I'm aware of=20 > anyway) are in documents that are on track to be RFCs. This document=20 > has followed the same procedures with respect to the OAuth URIs=20 > registrations as those other documents. >=20 > Having said all that, I'm unsure what action you are expecting to see=20 > as a result of this DISCUSS comment? There's two obvious routes -- first, to change the text to use placeholders= like "TBD1" or "the token-exchange URI" (e.g., as opposed to urn:ietf:para= ms:oauth:grant-type:token-exchange specifically) and request that IANA allo= cate the specific suggested values; or to get IANA to explicitly confirm th= at these values can be registered and will be marked as pending until this = document is finalized (to prevent allocation "under our nose" by other mean= s). Ekr and I can help mediate any IANA interaction needed for whatever ro= ute we end up taking, if needed. (Basically, this is a process concern -- the IESG should not give its stamp= of approval to a document in a state that does something we don't want oth= er people to do, even if the final published RFC will be able to make these= claims correctly.) >=20 >=20 > > why do we allow both client authentication (i.e., using an actor=20 > > token) and a distinct actor_token request parameter? Is it supposed=20 > > to be the case that the actor_token parameter is only supplied for=20 > > delegation flows? If so, that needs to be made explicit in the=20 > > document. > > >=20 > Client authentication is inherited from RFC 6749. It's optional but=20 > can be useful for deployments that want to "lock down" who can invoke=20 > token exchange. >=20 > The actor_token and subject_token are inputs into the exchange. They=20 > have to be validated but that is not exactly authentication per se.=20 > Honestly, I struggle with the wording and how to describe it all (here=20 > and in not dissimilar contexts of the authorization grants of RFC 7522=20 > and 7523=20 > ). I've done the best I can in=20 > the document. If you can propose some text that you think would make=20 > things more clear or explicit, that'd help progress this. But I=20 > honestly don't know what to add or change here. Before I start trying to tweak text, can you confirm that the actor_token r= equest parameter is okay to use in both delegation and impersonation scenar= ios? >=20 >=20 > > > > Are the privacy considerations (e.g., risk of a tailed per-request > > error_uri) relating to the use of error_uri discussed in some other=20 > > document that we can refer to from this document's security=20 > > considerations? (I say a bit more about this in my COMMENT.) > > >=20 > I am not aware of any document with such considerations and I've=20 > searched the likely suspects of RFC 6749 and RFC 6819 but don't find anyt= hing. >=20 > The error_uri token endpoint response parameter was defined in the=20 > original OAuth 2.0 framework document (RFC 6749) and any=20 > considerations around it are applicable to considerably more than this=20 > document. It's also very rarely used in practice as far as I know. I=20 > don't think that this document, which is a narrow extension of a whole=20 > framework with a series of other documents that use error_uri, is the=20 > appropriate place to add privacy or security considerations about=20 > error_uri. Perhaps=20 > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ would = be more appropriate in scope and content? Oh, definitely -- I only asked if there was something existing we could che= aply reference; this is definitely not the place to be writing this down fr= om scratch. Thanks for doing the search! > I could remove the one mention of error_uri in this document? It's=20 > usage would still be possible/valid by virtue of this document being=20 > an extension of RFC 6749 but, out of sight and out of mind, and this=20 > doc wouldn't then encourage new usage of it anyway. While usage isn't rea= lly happening anyway. I don't mind having the reference there; it's not really causing problems a= nd could potentially be helpful. We should be able to get away with a gene= ric reference to this class of thing elsewhere and one-sentence description= ("when a proxy or similar mechanism is in place to protect client privacy,= the error_uri mechanism can induce the client to lose some anonymity by de= referencing a URI pointing to a third party server that can leak informatio= n to the attacker, in a similar fashion as [ref]"). I don't have a [ref] h= andy right now, though; I'll need to ask around. In a pinch we could fallback to analogy to open-redirector issues, though w= e differ in which actors are receiving/conveying/acting on untrusted input,= and we can have issues just by making the request as opposed to the user m= is-interpreting the returned resource. But to reiterate, I'm only looking = for a brief mention that some clients might care and don't need an exhausti= ve description. >=20 >=20 > > > > Section 2.1 has: > > audience > > OPTIONAL. The logical name of the target service where the clien= t > > intends to use the requested security token. This serves a > > purpose similar to the "resource" parameter, but with the client > > providing a logical name rather than a location. Interpretation > > of the name requires that the value be something that both the > > client and the authorization server understand. An OAuth client > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > > examples of things that might be used as "audience" parameter > > values. [...] > > > > How does the STS know what type of identifier it is supposed to=20 > > interpret the provided audience value as? > > >=20 > The STS will have policy and configuration for the target entities for=20 > which it supports the issuance of tokens to in this flow, even if/when=20 > those entities are different types of things. The STS will have to=20 > search that set of things to find the right one for the given name. In=20 > theory I suppose there's potential ambiguity or even name collision.=20 > But in practice (as it is the STS that ultimately decides the names it=20 > supports and can > service) I don't believe there is an actual issue. Okay, so at some point we're essentially just doing a lookup based on audie= nce string, and the type information is attached to the lookup results (alo= ng with everything else needed). Do you think it makes sense to add a sentence after the non-elided quoted p= ortion, something like ``However, "audience" values used on a given authori= zation server must be unique within that server, to ensure that they are pr= operly interpreted as the intended type of value.''? (I'm of course open t= o other suggestions, including "just leave it as it is"; I think what trigg= ered me to comment here is that "both the client and the authorization serv= er understand" leaves open the possibility that the AS might share one unde= rstanding of a string with one client and a different understanding of that= same string with a second client, since it's only a pairwise condition but= we probably are safer with a global condition.) >=20 >=20 > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > The document could perhaps benefit from greater clarity as to=20 > > whether "security token"s refer to inputs, outputs, or both, of the=20 > > token endpoint (for the interactions defined in this specification). > > >=20 > I have been aware of the potential need here and endeavored to be=20 > clear about it throughout the document without being overly repetitive or= wordy. > I will take another pass through the text and look for opportunities=20 > to further clarity. But if there are specific points in the doc that=20 > you believe need attention, please point them out so I can be sure=20 > they get addressed. I made another quick pass, and it is better than I remembered. So thanks f= or the efforts, and sorry for maligning the document! Maybe 2.2.1's "token_type" description could reiterate "issued security tok= en" both times that "security token" appears instead of just the second tim= e, though the context really ought to be enough to make this one clear. Other than that, the only potential trouble I see is in the introduction wh= en we get a barrage of the string all at once. And even that's in reasonab= le shape, with the only potential changes I see being in the first sentence= of the second paragraph, something like "capable of validing security toke= ns provided to it and issuing new security tokens in response". >=20 > > > > Section 1 > > > > The OAuth > > 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens > > [RFC6750] have emerged as popular standards for authorizing third- > > party applications access to HTTP and RESTful resources. [...] > > > > nit: possessive "applications'" > > >=20 > Will fix. >=20 >=20 > > > > Section 1.1 > > > > This section really jumps in quickly with no lead-in to why we would=20 > > care or transition from the introduction. I suggest: > > > > One common use case for an STS (as alluded to in the previous section= ) > > is to allow a resource server A to make calls to a backend service C = on > > behalf of the requesting user B. Depending on the local site policy = and > > authorization infrastructure, it may be desireable for A to use its o= wn > > credentials to access C along with an annotation of some form that A = is > > acting on behalf of B ("delegation"), or for A to be granted a=20 > > limited access > > credential to C but that continues to identify B as the authorized > > entity ("imperesonation"). Delegation and impersonation can be usefu= l > > concepts in other scenarios involving multiple participants as well. > > >=20 > Documents written over time with more than one author sometimes bear=20 > the scars of that process in disjoint transitions, which is the case=20 > here I think. >=20 > You're suggestion nicely takes the edge off the transition and=20 > provides context for it. Thanks, I'll add that text to the top of sec 1.1= . >=20 >=20 >=20 > > Section 2.1 > > > > For example, [RFC7523= ] > > defines client authentication using JSON Web Tokens (JWTs) [JWT]. > > > > Please clarify that these are still bearer tokens. > > >=20 > Okay. >=20 >=20 > > > > The supported methods of client authentication and whether or not to > > allow unauthenticated or unidentified clients are deployment > > decisions that are at the discretion of the authorization server. > > > > It seems appropriate to note that omitting client authentication=20 > > allows for a compromised token to be leveraged via an STS into other=20 > > tokens by anyone possessing the compromised token, and thus that=20 > > client authentication allows for additional authorization checks as=20 > > to which entities are permitted to impersonate or receive=20 > > delegations from other entities. > > >=20 > I'll add a note that says as much (borrowing heavily from your words,=20 > thanks). >=20 >=20 > > > > The client makes a token exchange request to the token endpoint with > > an extension grant type by including the following parameters using > > the "application/x-www-form-urlencoded" format with a character > > encoding of UTF-8 in the HTTP request entity-body: > > > > Is there more to say than "just use UTF-8"; any normalization or=20 > > canonicalization issues to consider? > > >=20 > Nope, no normalization or canonicalization at this layer. Okay, thanks for confirming. > Note that Adam Roach did raise a DISCUSS around citation for the media=20 > type=20 > https://mailarchive.ietf.org/arch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DY > w , which might result in a change to the wording here but it's still=20 > x-www-form-urlencoded with UTF-8 as is better described in=20 > https://tools.ietf.org/html/rfc6749#appendix-B Sure; I don't expect those changes to introduce any concerns of the nature = I was asking about here. >=20 > > > > subject_token > > REQUIRED. A security token that represents the identity of the > > party on behalf of whom the request is being made. Typically, th= e > > subject of this token will be the subject of the security token > > issued in response to this request. > > > > nit: I think there's a subtle grammar mismatch here, where we start=20 > > off by talking about a/the request and end up with "this request". > > >=20 > So changing that last "this request" to say "the request" would fix=20 > the mismatch? I think so. >=20 >=20 > > In processing the request, the authorization sever MUST validate the > > subject token as appropriate for the indicated token type and, if th= e > > actor token is present, also validate it according to its token type= . > > > > I misread this the first time around; I'd suggest something like=20 > > "perform the appropriate validation procedures for the indicated=20 > > token type" (as opposed to just verifying that the presented token=20 > > is a syntactically valid instance of the claimed type). > > >=20 > Makes sense, I'll update accordingly. Thanks. >=20 > > > > In the absence of one-time-use or other semantics specific to the > > token type, the act of performing a token exchange has no impact on > > the validity of the subject token or actor token. Furthermore, the > > validity of the subject token or actor token have no impact on the > > validity of the issued token after the exchange has occurred. > > > > Do we really want this strong of a statement? I suspect that in=20 > > many environments propagating, e.g., expiration time to the=20 > > exchanged credential may be desired. > > >=20 > The statement was not in any way intended to prohibit propagating=20 > expiration time (or other criteria) to the exchanged credential. The=20 > statement was added, best I can recall, in response to a question that=20 > came up in a WG chair review asking if the input token(s) would=20 > somehow become invalid once used as input to the exchange. Or if some=20 > later expiration or other invalidation of the input token(s) would=20 > somehow invalidate the new token. The point of the statement in the=20 > doc was to try and say that there is no inherit linkage effectual=20 > relationship between the tokens outside the exchange event. There=20 > could be but that's not a general property of the STS protocol a would be= specific to a particular token type or deployment. >=20 > Does that make any more sense? Do you think the wording could/should=20 > be adjusted? That makes perfect sense for what we want to happen, yes. I wonder if we really want the second sentence to be saying something like = "The exchange is a one-time event and does not create a tight linkage betwe= e the input and output tokens, so that (for example) while the expiration t= ime of the output token may be influenced by that of the input token, renew= al or extension of the input token is not expected to be reflected in the o= uput token's properties. It may still be appropriate to propagate token re= vocation events, though." (This bit about revocation is perhaps even more = interesting than expiration time, and would seem to be prevented by the cur= rent text.) >=20 > > > > Section 2.2.1 > > > > token_type > > [...] > > contents of the token itself. Note that the meaning of this > > parameter is different from the meaning of the "issued_token_type= " > > parameter, which declares the representation of the issued > > security token; the term "token type" is typically used with this > > meaning, as it is in all "*_token_type" parameters in this > > specification. [...] > > > > Please disambiguate what "typically used with this meaning" means. > > Perhaps it would be even more clear to change this field's name to=20 > > "token_access_token_type" to match the name of the registry? > > >=20 > The "token_type" parameter is defined in RFC 6749 for a successful=20 > response from the token endpoint so this document effectively inherits=20 > it. The name is already defined in RFC 6749 and not in scope for this=20 > document to change. > I will update the wording to disambiguate "this meaning" per your request= . Okay, thanks. >=20 >=20 > > Section 2.3 > > > > The following example demonstrates a hypothetical token exchange in > > which an OAuth resource server assumes the role of the client during > > token exchange in order to trade an access token that it received in > > a protected resource request for a token that it will use to call to > > a backend service (extra line breaks and indentation in the examples > > are for display purposes only). > > > > We could maybe add some commas or parentheses to help the reader=20 > > group the various clauses properly. E.g., it is "(trade an access=20 > > token (that it received in a protected resource request)) for a=20 > > token...", not "trace an access token that it received (in a=20 > > protected resource request for a token)", where parentheses indicate lo= gical grouping. > > >=20 > Will try and do some grouping. >=20 >=20 >=20 > > > > grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-excha= nge > > &resource=3Dhttps%3A%2F%2Fbackend.example.com%2Fapi%20 > > &subject_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC > > &subject_token_type=3D > > urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token > > > > Figure 2: Token Exchange Request Is there=20 > > really supposed to be a %20 in the resource query parameter's value? > > >=20 > Nope. Nice catch. Thank you. I'll remove it. >=20 >=20 >=20 > > > > The token octets in Figures 3 and 4 do not match up, despite the prose > > indicating that they are the same token. > > >=20 > Indeed they don't. Look like I missed one token example when updating cla= im > names. I'll fix that. Thanks for catching that one. >=20 >=20 >=20 > > > > Section 3 > > > > Would it be appropriate to note (here or elsewhere) that for non-JWT > > token formats that are a binary format, the URI used for conveying them > > needs to be associated with the semantics of base64 (or otherwise) > > encoding them for usage with OAuth? > > >=20 > My thinking had been that it'd be more or less self-evident to the very > small group and type of people who would ever undertake such a thing. But= a > brief note to that effect couldn't hurt. I'll add something as such. >=20 To be clear, I wouldn't mind if you decided to leave it as is. But thanks :) >=20 > > > > Token Exchange can work > > with both tokens issued by other parties and tokens from the given > > authorization server. [...] > > > > Does "work with" mean "accept as input" or "produce as output" or both? > > For input, as both subject_token and actor_token? > > >=20 > Both and yes. Okay. (I don't have any text suggestions, and as-is is probably fine.) >=20 > The following token type identifiers are defined by this > > specification. Other URIs MAY be used to indicate other token types= . > > I'd also link to the registry here. > > >=20 > The aforementioned other URIs may well be in different namespace so won't > ever be in the registry. And that registry also has entries for things > other than token types. So I don't think a link to it here would be > particularly helpful or even appropriate necessarily. Ah, good points. >=20 > > > > Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatted > > differently than the other URIs listed? > > >=20 > The list of the ones defined in this doc is a li= st > with each URI in the list appearing in a while = the > :jwt URI is defined elsewhere in RFC 7519 but relevant enough to warrant > mention in this doc and it is enclosed in a tag. I > feel like I've seen this style of treatment of literal values with list > items and in paragraph text in other documents so considered it "normal". > Is there a better or more recommended way of doing this kind of thing? Nope, what you did is fine. I think I managed to forget that I was reading a list of identifiers *defined by this specification* before I reached the end of the list :( >=20 >=20 >=20 >=20 > > Section 4.1 > > > > Do we want to consider a more self-describing subject identifier scheme= , > > akin to > > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ? > > >=20 > There's nothing precluding the use of such a scheme (well, except that do= c > doesn't actually define a claim so some claim is needed) but the scope of > this document isn't to be that prescriptive in subject identification. Okay. >=20 > > > > The example in Figure 5 appears to be using the "implicit issuer" > > behavior wherein the "iss" of the actor's "sub" is assumed to be the > > same value as in the containing structure. I'm not a fan of this type > > of behavior in general, but if it's going to be used, you need to > > document the possibility in some fashion. > > >=20 > I'm not a hug fan myself but that's what OpenID Connect did and so it oft= en > rears its head. >=20 > I've tried to make examples that will be meaningful to readers and also > somewhat likely to be realistic. >=20 > In this section it does say: > "For example, the combination > of the two claims "iss" and "sub" might be necessary to uniquely > identify an actor" >=20 > And sub in RFC 7519 says: > "The subject value MUST either be scoped to be > locally unique in the context of the issuer or be globally unique." >=20 I guess this could fall into the "globally unique" bucket, that's fair. (And this was a non-blocking comment anyway...) >=20 >=20 > > > > I might also consider some language about how "the nested "act" claims > > serve as a history trail that connects the initial request and subject > > through the various delegation steps undertaken before reaching the > > current actor. In this sense, the current actor is considered to > > include the entire authorization/delegation history, leading naturally > > to the nested structure described here". (But see also the other ballo= t > > comment about this potentially leaking information to unauthorized > > parties; it seems a more careful adjustment of the text is in order > > here.) > > >=20 > Okay, I can add something to that effect. >=20 >=20 >=20 > > Section 4.2 > > > > Is this really the first time we're defining "scope" as a JWT claim? I > > would have thought that would be defined long ago... > > >=20 > Some things haven't historically happened in OAuth the way one might very > reasonably have expected. And this is one such thing. >=20 >=20 >=20 > > > > Section 4.4 > > > > Just to double-check: this is "things that can act as me" (where "me" i= s > > the subject of the token containing this field), right? >=20 >=20 > Yes. Honestly, I have a hard time seeing this claim actually being used i= n > practice. But maybe I'm wrong. And I'm just the editor on this one. But > yes, that's the intended meaning. Okay. I think the this text has a pretty clear reading, but just wanted to double-check that I was getting the expected meaning from it (so no change suggested). >=20 > The > > parenthetical "May Act For" doesn't really help me decide whether this > > claim represents the source or target of a permitted delegation, so > > maybe "Allowed Impersonators" or similar would be more clear. Even "ac= t > > as" or "act on behalf of" instead of "act for" would help me, I think. > > [This would have trickle-down effects to later parts of the document as > > well, e.g., the IANA Considerations.] > > (Not that I claim to be a representative population, of course!) > > >=20 > On looking at it again, I agree "May Act For" isn't a particularly good > name nor is it helpful in understanding it. I admit to having a hard time > with the language here. But, yeah, "May Act For" isn't very good. >=20 > What about "Authorized Actor" in the parenthetical and "Authorized Actor = - > the party that is authorized to become the actor" for the Claim Descripti= on > in registration? >=20 I think that's an improvement, thanks. >=20 > > It would probably also help greatly to note that when a subject_token i= s > > presented to the token endpoint in a token exchange request, the > > "may_act" claim in the subject token can be used by the authorization > > service to determine whether the client (or party identified in the > > actor_token) is authorized to engage in the requested delegation [or > > impersonation]. > > >=20 > Okay, I can add something to that effect. >=20 >=20 > > > > Section 6 > > > > Let me say a bit more here about my perception of the potential privacy > > considerations involved in the use of an error_uri (so we can figure ou= t > > if they are already discussed in a relevant document that we can cite; > > JWT itself doesn't seem to cover this topic). By sending an error_uri > > instead of an error string, the server is in effect causing the client > > to make an outbound request to a URL of the server's choosing. If ther= e > > is a proxy between the client and server, this could result in the > > server (and/or a party controlled by the server) learning additional > > information about the client's identity/location. A malicious server > > could also attempt to construct a URI that, when retrieved by the > > client, performs some unwanted side effect. Defenses against this > > latter scenario are pretty well known in the web comunity, but we may > > want to be sure that the need for them is mentioned in a discoverable > > place. > > >=20 > Thank you for the further explanation. As I wrote earlier, however, the > error_uri response parameter was originally defined in RFC 6749 and any > privacy or security considerations for it are applicable to considerably > more than this document. >=20 >=20 >=20 > > Appendix A.1.1 > > > > In the following token exchange request, a client is requesting a > > token with impersonation semantics. [...] > > > > What part of the request indicates that impersonation semantics are > > requested? > > >=20 > I guess it's not explicitly requesting impersonation semantics per se but > only a subject_token is being supplied in the request so impersonation is > kinda implied as there is no party identified that could be delegated to. >=20 > Do you think the wording should be qualified as such or otherwise adjuste= d? I could go either way, but if I was adding something, I'd go for a parenthetical "(with only a subject_token and no actor_token, delegation is impossible)". >=20 >=20 > > > > Is the use of the "jwt" subject_token_type appropriate, given the > > previous discussion about id_token/access_token being generally > > preferred (as conveying more meaning)? > > >=20 > The issuer of that token isn't the given AS so it isn't an access_token. > And it doesn't have all the claims required to be an id_token. That leave= s > JWT. And JWT is used a lot in the examples so their claims can also be > seen and an "identity" can be traced through the exchange. Okay, thanks for the clarification. (And for all the changes!) -Benjamin From nobody Fri Jan 11 11:32:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252EF130E0E for ; Fri, 11 Jan 2019 11:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rtzS9JoHWMsH for ; Fri, 11 Jan 2019 11:32:35 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4E424130E5B for ; Fri, 11 Jan 2019 11:32:34 -0800 (PST) Received: from [IPv6:2601:282:202:b210:9583:833c:293:674d] (unknown [IPv6:2601:282:202:b210:9583:833c:293:674d]) by alkaline-solutions.com (Postfix) with ESMTPSA id 7671F315AB; Fri, 11 Jan 2019 19:32:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: David Waite In-Reply-To: <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> Date: Fri, 11 Jan 2019 12:32:32 -0700 Cc: Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> To: Neil Madden X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 19:32:43 -0000 > On Jan 11, 2019, at 3:32 AM, Neil Madden = wrote: >=20 > On 9 Jan 2019, at 05:54, David Waite = wrote: >>=20 >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = wrote: >>>=20 >> >>=20 >>> All of that is meant as an explanation of sorts to say that I think = that things are actually okay enough as is and that I'd like to retract = the proposal I'd previously made about the MTLS draft introducing a new = AS metadata parameter. It is admittedly interesting (ironic?) that Neil = sent a message in support of the proposal as I was writing this. It did = give me pause but ultimately didn't change my opinion that it's not = worth it to add this new AS metadata parameter. >>=20 >> Note that the AS could make a decision based on the token endpoint = request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was desired by this public client installation. The AS = could then to TLS 1.2 renegotiation, 1.3 post-handshake client = authentication, or even use 307 temporary redirects to another token = endpoint to perform mutual authentication. >=20 > Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? >=20 > A 307 redirect could work though as the server will know if the client = either uses mTLS for client authentication or has indicated that it = wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know = a way to have say a custom error code or WWW-Authenticate challenge to = trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive. >=20 >> Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2=80= =9D-like indicator imply that the client has multiple forms of = authentication and is choosing to use MTLS. The URL in particular I=E2=80=99= m reluctant to add support for, because I see it more likely a client = would use MTLS without knowing it (via a device-level policy being = applied to a public web or native app) than the reverse, where a single = client (represented by a single client_id) is dynamically picking = between forms of authentication. >=20 > That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of device policy you are talking about? I am aware of e.g. mobile = device management being used to push client certificates to iOS devices, = but I think these are only available in Safari. The primary use is to set policy to rely on device level management in = controlled environments like enterprises when available. So an AS may = try to detect a client certificate as an indicator of a managed device, = use that to assume a device with certain device-level authentication, = single user usage, remote wipe, etc. characteristics, and decide that it = can reduce user authentication requirements and/or expose additional = scopes. On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store. In terms of user agents, I believe you can perform similar behavior = (managed systems using client certificates on user agents transparently) = on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically inherits device level policy. Firefox on desktop I assume you = can do that in limited fashion as well. -DW= From nobody Fri Jan 11 12:32:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BD7128B14 for ; Fri, 11 Jan 2019 12:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYd4LXIXqcwU for ; Fri, 11 Jan 2019 12:32:02 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648AD127AC2 for ; Fri, 11 Jan 2019 12:32:02 -0800 (PST) Received: from [91.73.131.158] (helo=[10.234.78.124]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gi3Rj-0000PN-D0 for oauth@ietf.org; Fri, 11 Jan 2019 21:30:27 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary=Apple-Mail-1AC9808E-D8B7-4E43-87C7-9C1F02A9E9E1; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 12 Jan 2019 00:31:55 +0400 Message-Id: To: oauth@ietf.org X-Mailer: iPhone Mail (16C101) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] OAuth Security Workshop Call for Proposals X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 20:32:05 -0000 --Apple-Mail-1AC9808E-D8B7-4E43-87C7-9C1F02A9E9E1 Content-Type: multipart/alternative; boundary=Apple-Mail-71EA95EB-CF97-434D-A5DC-07BF48B949CE Content-Transfer-Encoding: 7bit --Apple-Mail-71EA95EB-CF97-434D-A5DC-07BF48B949CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, the Call for Proposal for the 4th OAuth Security Workshop is out! https://sec.uni-stuttgart.de/events/osw2019 Please propose a session! kind regards, Torsten. --Apple-Mail-71EA95EB-CF97-434D-A5DC-07BF48B949CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all,

the Call for Proposal for the 4th OAuth Security Workshop is out! 


Please propose a session!

kind regards,
Torsten.
--Apple-Mail-71EA95EB-CF97-434D-A5DC-07BF48B949CE-- --Apple-Mail-1AC9808E-D8B7-4E43-87C7-9C1F02A9E9E1 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCocw ggU6MIIEIqADAgECAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwMTA0MDAwMDAwWhcNMTkwMTA0MjM1 OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL+wxfKmVFFwQCaEpr/cqKq4YRnag/CxfnSJ0H5CTWIEQbU6 ITIPqVMukzn8DzCS+58RWUCnkTrSxnBQsaGQBLaV7KOpuz9xnGJXjdcGiUR/fNVPNV8x9nJQoPfm EZyFKb6H9RD0RcgYGlbi2Ik5YFXHAUP5+95lAFZD+WvVDlW5VgHkLxgr7Fdk5TzQjlzraYbxtd+/ 9LNOPC7B6loLTVvxL/9jqAHWhY+XwpO9DgfIyPUWbqV4ebFHs55RyJ1rZ5O7fIS/h43jVTdJrR7m 2fG7aVn0rVez093qw4RYMC4PfOPtNJMxnQsVx7CFj2tr29k1iq6RCawSvGQ2PKKl/g8CAwEAAaOC Ae0wggHpMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBThsbAlrM5A mxeFSuq98Yj+vvE9JTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoG A1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMCIGA1UdEQQbMBmBF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IB AQCwOuzDD7cCcpx871e56hzYXe/CF/XX+GWTwT7+NpmW8gsl4DIWxEkjuGxg0E3EqXSc4CLniBpe pOPkkJKCiRxqClCrTIOZ2MJO1+cq69iTccBmgjsC0dVv7lNPdonFk+epU/97HFNR5r/Zf4V50h2o qqnFOsYvrWhqB1rW+tSM02JO3s7+FFEgcyXbraG1gbiNJzSOHkpOnPSF2aMoTnFexIMOARXIkIT/ ysb3jOce9clr0tW+8qdQgmj8qQblHamoP1lXPr0dSHZkG5OBLNCrtuaIVIeNKQ3Q1+togaVEp7pM 04EyXkNKAZnk4nQqGvlfBRBfTgHCO06lBHdWABz2MIIFRTCCBC2gAwIBAgIQM9uaxqrCN5lrc/ED e5nwtDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE3MDEwOTAwMDAwMFoXDTE4MDEwOTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYX dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCu wZLNnLP0ur1JFb1K97kryfmVaGmU4ITocfeAzJ7XYOM6mQUVm3Rvve3bsbXteynpZTEeE169/tyT QBSm9hQ8IcGpUYlIhYX2FYChIUKBAAI6iH9wMVvPPU+wxjwSXs6Yi6zgle1jj9V2hIiEU/eHMBNs 0CDfYqn43y+1O4pPBuCeLMlLLNlNiuy22fcubBjXsdT5T29eWgy6zlT+WfgANnHTPLINKwDqC0/F dgmluBJOcdyRVnnN9HzSC4hnnfxjaqqyq3lVpJFJHahDMT8cROQpz+h09WGoGtcvK+dIWQI+sBdX Tuty/CQ+8dl5hW7hB1VbI7YchDiLbH2vmbtLAgMBAAGjggH1MIIB8TAfBgNVHSMEGDAWgBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU+eAeBXE5nsZKOL8hbhgkwGPTY8cwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3Vy ZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQbMBmB F3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQACa57IeOLIvWpiB976 FVKwa4qWBy+MIB8bwlqrjy0LQiM/ykf+0aLi4v0IdV8udXeksOeODoza6+kQGntytllydI8t5Wyz 62SHC/4XshJhDJPh+U2SpVRvyd97BsI9wg3Xc5t+lTuuVeghqsQSmVCjhK7KZhWW5DFMs4UqblA4 wXgkEzD+uPLi33knsx2n00VTNCso8kNonYmv9NxNcVyMu81WYwGMrT3n1r2/X/WaJEd3UMGxOHUq 8GKAQ5Q0zG9Pm5S0Hr+2KgNmoEMOTwa92ej/GbJ7diJqxLsmAxESrlZxeqlYa7mQwVkwY8S/I8d4 Fl6rHHdqZ/giZWdnpa+DMYID0DCCA8wCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMTExMjAzMTU1WjAvBgkqhkiG 9w0BCQQxIgQg+vTAMUAMw8ip9I5qNF3eHo7tZz8tB2x101qDYLPKSOcwgcEGCSsGAQQBgjcQBDGB szCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3 mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAL5K ZdEzMwXAq/avaRJvFM+BhtXOo+Z00A4vhLN23tlEEpk1MAD6QtqkzfMBexIna43RVlXCocb90bpw Rjvd4jyCgHrKIId1y/pmQi/E0YPuIDEC1HcgtHKzFUe5oKG9IeT+zWEkLJ/wULoft1rAxMRgvEmL yn9QxyBPYzv4pBcgAGkK6DLOkF5PWsvfCYdqB/j/y5iDY9g8mzADak5CumOz2lhQg715laHyt4fH C4ogUSxidQ1Gq2qeBhYGaKwWmDDAHr5OCHKSRQr0YaBkSRAHBjX9YrTzK2Jru81FHTNKsyzzRyQg JhF5HC2c1bFxWlQTWtMp2nG/Gf0yNcnOfL4AAAAAAAA= --Apple-Mail-1AC9808E-D8B7-4E43-87C7-9C1F02A9E9E1-- From nobody Sat Jan 12 06:31:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DA130F7C for ; Sat, 12 Jan 2019 06:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 Sr24WcBC3s51 for ; Sat, 12 Jan 2019 06:31:34 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C6F130F73 for ; Sat, 12 Jan 2019 06:31:32 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id h193so6663545ita.5 for ; Sat, 12 Jan 2019 06:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XR0esM0sWOFJSDrDo+QVSayK2sLt4UVZBbrdp7XVCgk=; b=LiielbY4P/5+tc7YJZBhLl+CtiiAbTqJwBpARxXnNbX1yZkXZBcj8hmxi7Llf4Hznb FIsLxq+2QTjkifXgP6m+eKR9WbjrjKQbrVgnUPIgA5rkzu5WKL0y3gUk7IHQl4E2bfh+ 3ym7/8OQtu/mpIpsEHftZ9QU4Ch66tvpKlIKk= 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=XR0esM0sWOFJSDrDo+QVSayK2sLt4UVZBbrdp7XVCgk=; b=KAZvaabKpk/cFVh/nGvkRAUAtVUA8YiZvZSCOsZJ0Ukc22YRk9ZxAv9gjZnn6vr0UU 7swYBFX1dFZa8Yy2+bUxDPIF1KAZU58fLLMW8Df9mOQ/exaBayJF2P5pPQOUBwtfmUfg cdFaxLzousgwbqB3kQV40+DmzikaglCZ6O7xTDSIZHrwQ121+b6xt4v/oCzAsgNvudy4 NAkb5PpXe+/Y2wTNUzUnMT7/zX4c4gmYZ9vEiI8yFPIan5dMu8Kq1aB1q9XIRw/Kr3Tb KhAmhPmzcxTbh2jqcds8UQBw1fdFQa+g8Hwte7CnF2VR3svNgsEmwkGCxQfnZTVwdOXF HcRA== X-Gm-Message-State: AJcUuke8rwc8EZ6sKhNavhVJHR5pFnGoje25FWpZfSaIhDInula1ED20 fR+AJqbljNLv03X2PVZJ+CQZlaHGE+V5ffoUWFBpKe+RPsMtc/yuIW423Z+HHN/0wCdQjBydTHD pklG79Xa90Kqj/g== X-Google-Smtp-Source: ALg8bN5k+ra4Zt1B+FZQYxAtObxOR4rBZQmf18vS73odlqcUvPC6baLOAlorumxeU2j/ZX2UH0O/K6DwNd+x3RWpXcs= X-Received: by 2002:a24:3987:: with SMTP id l129mr3760160ita.45.1547303491335; Sat, 12 Jan 2019 06:31:31 -0800 (PST) MIME-Version: 1.0 References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> <20190111161321.GJ28515@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Sat, 12 Jan 2019 07:31:19 -0700 Message-ID: To: Mike Jones Cc: Benjamin Kaduk , The IESG , oauth , "draft-ietf-oauth-token-exchange@ietf.org" , "oauth-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f61878057f43aa1c" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 14:31:40 -0000 --000000000000f61878057f43aa1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would also advocate for requesting early registration of the URIs. (I'll follow up on the rest of the thread at some point later as time allows and the usual caveats) On Fri, Jan 11, 2019, 10:33 AM Mike Jones I would advocate requesting early registration for > urn:ietf:params:oauth:grant-type:token-exchange. > > -- Mike > > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, January 11, 2019 8:13 AM > To: Brian Campbell > Cc: The IESG ; oauth ; > draft-ietf-oauth-token-exchange@ietf.org; oauth-chairs@ietf.org > Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on > draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) > > I also apologize for the slow response (I gave Brian a unicast heads-up > earlier) -- between vacation, the holidays, and a death in a the family I > was away from email for quite some time. > > On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > > I apologize for the slow response, Ben. I was on vacation with my > > family around the Thanksgiving holiday when the ballot position came > > in. And even on returning and starting to work on it, there's an awful > > lot here to get through and this kind of thing is very time consuming > > for me. But thank you for the review - I've attempted to reply, as > > best I can, to your comments/questions inline below. > > > > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-oauth-token-exchange-16: Discuss > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > It looks like allocations in the OAuth URIs registry are merely > > > "Specification Required", so we should not have the expectation of > > > WG exclusivity and thus are squatting on unallocated values here. > > > Process-wise, that's not great and the IESG shouldn't approve a > > > document that is squatting on codepoints. > > > > > > > In retrospect, RFC 6755 should > > have used "RFC Required" for the OAuth URIs registry. But that was > > 2012 and 6755 was my first RFC and I was even more clueless back then > > than I am now. And what's done is done. > > > > In practice the only entries that have been made to the registry have > > been from RFCs and the only prospective entries (that I'm aware of > > anyway) are in documents that are on track to be RFCs. This document > > has followed the same procedures with respect to the OAuth URIs > > registrations as those other documents. > > > > Having said all that, I'm unsure what action you are expecting to see > > as a result of this DISCUSS comment? > > There's two obvious routes -- first, to change the text to use > placeholders like "TBD1" or "the token-exchange URI" (e.g., as opposed to > urn:ietf:params:oauth:grant-type:token-exchange specifically) and request > that IANA allocate the specific suggested values; or to get IANA to > explicitly confirm that these values can be registered and will be marked > as pending until this document is finalized (to prevent allocation "under > our nose" by other means). Ekr and I can help mediate any IANA interacti= on > needed for whatever route we end up taking, if needed. > > (Basically, this is a process concern -- the IESG should not give its > stamp of approval to a document in a state that does something we don't > want other people to do, even if the final published RFC will be able to > make these claims correctly.) > > > > > > > > why do we allow both client authentication (i.e., using an actor > > > token) and a distinct actor_token request parameter? Is it supposed > > > to be the case that the actor_token parameter is only supplied for > > > delegation flows? If so, that needs to be made explicit in the > > > document. > > > > > > > Client authentication is inherited from RFC 6749. It's optional but > > can be useful for deployments that want to "lock down" who can invoke > > token exchange. > > > > The actor_token and subject_token are inputs into the exchange. They > > have to be validated but that is not exactly authentication per se. > > Honestly, I struggle with the wording and how to describe it all (here > > and in not dissimilar contexts of the authorization grants of RFC 7522 > > and 7523 > > ). I've done the best I can in > > the document. If you can propose some text that you think would make > > things more clear or explicit, that'd help progress this. But I > > honestly don't know what to add or change here. > > Before I start trying to tweak text, can you confirm that the actor_token > request parameter is okay to use in both delegation and impersonation > scenarios? > > > > > > > > > > > Are the privacy considerations (e.g., risk of a tailed per-request > > > error_uri) relating to the use of error_uri discussed in some other > > > document that we can refer to from this document's security > > > considerations? (I say a bit more about this in my COMMENT.) > > > > > > > I am not aware of any document with such considerations and I've > > searched the likely suspects of RFC 6749 and RFC 6819 but don't find > anything. > > > > The error_uri token endpoint response parameter was defined in the > > original OAuth 2.0 framework document (RFC 6749) and any > > considerations around it are applicable to considerably more than this > > document. It's also very rarely used in practice as far as I know. I > > don't think that this document, which is a narrow extension of a whole > > framework with a series of other documents that use error_uri, is the > > appropriate place to add privacy or security considerations about > > error_uri. Perhaps > > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > would be more appropriate in scope and content? > > Oh, definitely -- I only asked if there was something existing we could > cheaply reference; this is definitely not the place to be writing this do= wn > from scratch. Thanks for doing the search! > > > I could remove the one mention of error_uri in this document? It's > > usage would still be possible/valid by virtue of this document being > > an extension of RFC 6749 but, out of sight and out of mind, and this > > doc wouldn't then encourage new usage of it anyway. While usage isn't > really happening anyway. > > I don't mind having the reference there; it's not really causing problems > and could potentially be helpful. We should be able to get away with a > generic reference to this class of thing elsewhere and one-sentence > description ("when a proxy or similar mechanism is in place to protect > client privacy, the error_uri mechanism can induce the client to lose som= e > anonymity by dereferencing a URI pointing to a third party server that ca= n > leak information to the attacker, in a similar fashion as [ref]"). I don= 't > have a [ref] handy right now, though; I'll need to ask around. > > In a pinch we could fallback to analogy to open-redirector issues, though > we differ in which actors are receiving/conveying/acting on untrusted > input, and we can have issues just by making the request as opposed to th= e > user mis-interpreting the returned resource. But to reiterate, I'm only > looking for a brief mention that some clients might care and don't need a= n > exhaustive description. > > > > > > > > > > > Section 2.1 has: > > > audience > > > OPTIONAL. The logical name of the target service where the > client > > > intends to use the requested security token. This serves a > > > purpose similar to the "resource" parameter, but with the clien= t > > > providing a logical name rather than a location. Interpretatio= n > > > of the name requires that the value be something that both the > > > client and the authorization server understand. An OAuth clien= t > > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], = an > > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > > > examples of things that might be used as "audience" parameter > > > values. [...] > > > > > > How does the STS know what type of identifier it is supposed to > > > interpret the provided audience value as? > > > > > > > The STS will have policy and configuration for the target entities for > > which it supports the issuance of tokens to in this flow, even if/when > > those entities are different types of things. The STS will have to > > search that set of things to find the right one for the given name. In > > theory I suppose there's potential ambiguity or even name collision. > > But in practice (as it is the STS that ultimately decides the names it > > supports and can > > service) I don't believe there is an actual issue. > > Okay, so at some point we're essentially just doing a lookup based on > audience string, and the type information is attached to the lookup resul= ts > (along with everything else needed). > > Do you think it makes sense to add a sentence after the non-elided quoted > portion, something like ``However, "audience" values used on a given > authorization server must be unique within that server, to ensure that th= ey > are properly interpreted as the intended type of value.''? (I'm of cours= e > open to other suggestions, including "just leave it as it is"; I think wh= at > triggered me to comment here is that "both the client and the authorizati= on > server understand" leaves open the possibility that the AS might share on= e > understanding of a string with one client and a different understanding o= f > that same string with a second client, since it's only a pairwise conditi= on > but we probably are safer with a global condition.) > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > The document could perhaps benefit from greater clarity as to > > > whether "security token"s refer to inputs, outputs, or both, of the > > > token endpoint (for the interactions defined in this specification). > > > > > > > I have been aware of the potential need here and endeavored to be > > clear about it throughout the document without being overly repetitive > or wordy. > > I will take another pass through the text and look for opportunities > > to further clarity. But if there are specific points in the doc that > > you believe need attention, please point them out so I can be sure > > they get addressed. > > I made another quick pass, and it is better than I remembered. So thanks > for the efforts, and sorry for maligning the document! > > Maybe 2.2.1's "token_type" description could reiterate "issued security > token" both times that "security token" appears instead of just the secon= d > time, though the context really ought to be enough to make this one clear= . > Other than that, the only potential trouble I see is in the introduction > when we get a barrage of the string all at once. And even that's in > reasonable shape, with the only potential changes I see being in the firs= t > sentence of the second paragraph, something like "capable of validing > security tokens provided to it and issuing new security tokens in respons= e". > > > > > > > > > Section 1 > > > > > > The OAuth > > > 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens > > > [RFC6750] have emerged as popular standards for authorizing third- > > > party applications access to HTTP and RESTful resources. [...] > > > > > > nit: possessive "applications'" > > > > > > > Will fix. > > > > > > > > > > Section 1.1 > > > > > > This section really jumps in quickly with no lead-in to why we would > > > care or transition from the introduction. I suggest: > > > > > > One common use case for an STS (as alluded to in the previous > section) > > > is to allow a resource server A to make calls to a backend service = C > on > > > behalf of the requesting user B. Depending on the local site polic= y > and > > > authorization infrastructure, it may be desireable for A to use its > own > > > credentials to access C along with an annotation of some form that = A > is > > > acting on behalf of B ("delegation"), or for A to be granted a > > > limited access > > > credential to C but that continues to identify B as the authorized > > > entity ("imperesonation"). Delegation and impersonation can be > useful > > > concepts in other scenarios involving multiple participants as well= . > > > > > > > Documents written over time with more than one author sometimes bear > > the scars of that process in disjoint transitions, which is the case > > here I think. > > > > You're suggestion nicely takes the edge off the transition and > > provides context for it. Thanks, I'll add that text to the top of sec > 1.1. > > > > > > > > > Section 2.1 > > > > > > For example, > [RFC7523] > > > defines client authentication using JSON Web Tokens (JWTs) [JWT]. > > > > > > Please clarify that these are still bearer tokens. > > > > > > > Okay. > > > > > > > > > > The supported methods of client authentication and whether or not = to > > > allow unauthenticated or unidentified clients are deployment > > > decisions that are at the discretion of the authorization server. > > > > > > It seems appropriate to note that omitting client authentication > > > allows for a compromised token to be leveraged via an STS into other > > > tokens by anyone possessing the compromised token, and thus that > > > client authentication allows for additional authorization checks as > > > to which entities are permitted to impersonate or receive > > > delegations from other entities. > > > > > > > I'll add a note that says as much (borrowing heavily from your words, > > thanks). > > > > > > > > > > The client makes a token exchange request to the token endpoint wi= th > > > an extension grant type by including the following parameters usin= g > > > the "application/x-www-form-urlencoded" format with a character > > > encoding of UTF-8 in the HTTP request entity-body: > > > > > > Is there more to say than "just use UTF-8"; any normalization or > > > canonicalization issues to consider? > > > > > > > Nope, no normalization or canonicalization at this layer. > > Okay, thanks for confirming. > > > Note that Adam Roach did raise a DISCUSS around citation for the media > > type > > https://mailarchive.ietf.org/arch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DY > > w , which might result in a change to the wording here but it's still > > x-www-form-urlencoded with UTF-8 as is better described in > > https://tools.ietf.org/html/rfc6749#appendix-B > > Sure; I don't expect those changes to introduce any concerns of the natur= e > I was asking about here. > > > > > > > > > subject_token > > > REQUIRED. A security token that represents the identity of the > > > party on behalf of whom the request is being made. Typically, > the > > > subject of this token will be the subject of the security token > > > issued in response to this request. > > > > > > nit: I think there's a subtle grammar mismatch here, where we start > > > off by talking about a/the request and end up with "this request". > > > > > > > So changing that last "this request" to say "the request" would fix > > the mismatch? > > I think so. > > > > > > > > In processing the request, the authorization sever MUST validate t= he > > > subject token as appropriate for the indicated token type and, if > the > > > actor token is present, also validate it according to its token > type. > > > > > > I misread this the first time around; I'd suggest something like > > > "perform the appropriate validation procedures for the indicated > > > token type" (as opposed to just verifying that the presented token > > > is a syntactically valid instance of the claimed type). > > > > > > > Makes sense, I'll update accordingly. > > Thanks. > > > > > > > > > In the absence of one-time-use or other semantics specific to the > > > token type, the act of performing a token exchange has no impact o= n > > > the validity of the subject token or actor token. Furthermore, th= e > > > validity of the subject token or actor token have no impact on the > > > validity of the issued token after the exchange has occurred. > > > > > > Do we really want this strong of a statement? I suspect that in > > > many environments propagating, e.g., expiration time to the > > > exchanged credential may be desired. > > > > > > > The statement was not in any way intended to prohibit propagating > > expiration time (or other criteria) to the exchanged credential. The > > statement was added, best I can recall, in response to a question that > > came up in a WG chair review asking if the input token(s) would > > somehow become invalid once used as input to the exchange. Or if some > > later expiration or other invalidation of the input token(s) would > > somehow invalidate the new token. The point of the statement in the > > doc was to try and say that there is no inherit linkage effectual > > relationship between the tokens outside the exchange event. There > > could be but that's not a general property of the STS protocol a would > be specific to a particular token type or deployment. > > > > Does that make any more sense? Do you think the wording could/should > > be adjusted? > > That makes perfect sense for what we want to happen, yes. > > I wonder if we really want the second sentence to be saying something lik= e > "The exchange is a one-time event and does not create a tight linkage > betwee the input and output tokens, so that (for example) while the > expiration time of the output token may be influenced by that of the inpu= t > token, renewal or extension of the input token is not expected to be > reflected in the ouput token's properties. It may still be appropriate t= o > propagate token revocation events, though." (This bit about revocation i= s > perhaps even more interesting than expiration time, and would seem to be > prevented by the current text.) > > > > > > > > > Section 2.2.1 > > > > > > token_type > > > [...] > > > contents of the token itself. Note that the meaning of this > > > parameter is different from the meaning of the > "issued_token_type" > > > parameter, which declares the representation of the issued > > > security token; the term "token type" is typically used with th= is > > > meaning, as it is in all "*_token_type" parameters in this > > > specification. [...] > > > > > > Please disambiguate what "typically used with this meaning" means. > > > Perhaps it would be even more clear to change this field's name to > > > "token_access_token_type" to match the name of the registry? > > > > > > > The "token_type" parameter is defined in RFC 6749 for a successful > > response from the token endpoint so this document effectively inherits > > it. The name is already defined in RFC 6749 and not in scope for this > > document to change. > > I will update the wording to disambiguate "this meaning" per your > request. > > Okay, thanks. > > > > > > > > Section 2.3 > > > > > > The following example demonstrates a hypothetical token exchange i= n > > > which an OAuth resource server assumes the role of the client duri= ng > > > token exchange in order to trade an access token that it received = in > > > a protected resource request for a token that it will use to call = to > > > a backend service (extra line breaks and indentation in the exampl= es > > > are for display purposes only). > > > > > > We could maybe add some commas or parentheses to help the reader > > > group the various clauses properly. E.g., it is "(trade an access > > > token (that it received in a protected resource request)) for a > > > token...", not "trace an access token that it received (in a > > > protected resource request for a token)", where parentheses indicate > logical grouping. > > > > > > > Will try and do some grouping. > > > > > > > > > > > > > grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange > > > &resource=3Dhttps%3A%2F%2Fbackend.example.com%2Fapi%20 > > > &subject_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC > > > &subject_token_type=3D > > > urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token > > > > > > Figure 2: Token Exchange Request Is there > > > really supposed to be a %20 in the resource query parameter's value? > > > > > > > Nope. Nice catch. Thank you. I'll remove it. > > > > > > > > > > > > The token octets in Figures 3 and 4 do not match up, despite the pros= e > > > indicating that they are the same token. > > > > > > > Indeed they don't. Look like I missed one token example when updating > claim > > names. I'll fix that. Thanks for catching that one. > > > > > > > > > > > > Section 3 > > > > > > Would it be appropriate to note (here or elsewhere) that for non-JWT > > > token formats that are a binary format, the URI used for conveying th= em > > > needs to be associated with the semantics of base64 (or otherwise) > > > encoding them for usage with OAuth? > > > > > > > My thinking had been that it'd be more or less self-evident to the very > > small group and type of people who would ever undertake such a thing. > But a > > brief note to that effect couldn't hurt. I'll add something as such. > > > > To be clear, I wouldn't mind if you decided to leave it as is. But thank= s > :) > > > > > > > > > Token Exchange can wo= rk > > > with both tokens issued by other parties and tokens from the given > > > authorization server. [...] > > > > > > Does "work with" mean "accept as input" or "produce as output" or bot= h? > > > For input, as both subject_token and actor_token? > > > > > > > Both and yes. > > Okay. (I don't have any text suggestions, and as-is is probably fine.) > > > > > The following token type identifiers are defined by this > > > specification. Other URIs MAY be used to indicate other token > types. > > > I'd also link to the registry here. > > > > > > > The aforementioned other URIs may well be in different namespace so won= 't > > ever be in the registry. And that registry also has entries for things > > other than token types. So I don't think a link to it here would be > > particularly helpful or even appropriate necessarily. > > Ah, good points. > > > > > > > > > Why is the text about "urn:ietf:params:oauth:token-type:jwt" formatte= d > > > differently than the other URIs listed? > > > > > > > The list of the ones defined in this doc is a = list > > with each URI in the list appearing in a whil= e > the > > :jwt URI is defined elsewhere in RFC 7519 but relevant enough to warran= t > > mention in this doc and it is enclosed in a tag.= I > > feel like I've seen this style of treatment of literal values with list > > items and in paragraph text in other documents so considered it "normal= ". > > Is there a better or more recommended way of doing this kind of thing? > > Nope, what you did is fine. I think I managed to forget that I was readi= ng > a list of identifiers *defined by this specification* before I reached th= e > end of the list :( > > > > > > > > > > > > Section 4.1 > > > > > > Do we want to consider a more self-describing subject identifier > scheme, > > > akin to > > > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers ? > > > > > > > There's nothing precluding the use of such a scheme (well, except that > doc > > doesn't actually define a claim so some claim is needed) but the scope = of > > this document isn't to be that prescriptive in subject identification. > > Okay. > > > > > > > > > The example in Figure 5 appears to be using the "implicit issuer" > > > behavior wherein the "iss" of the actor's "sub" is assumed to be the > > > same value as in the containing structure. I'm not a fan of this typ= e > > > of behavior in general, but if it's going to be used, you need to > > > document the possibility in some fashion. > > > > > > > I'm not a hug fan myself but that's what OpenID Connect did and so it > often > > rears its head. > > > > I've tried to make examples that will be meaningful to readers and also > > somewhat likely to be realistic. > > > > In this section it does say: > > "For example, the combination > > of the two claims "iss" and "sub" might be necessary to uniquely > > identify an actor" > > > > And sub in RFC 7519 says: > > "The subject value MUST either be scoped to be > > locally unique in the context of the issuer or be globally unique." > > > > I guess this could fall into the "globally unique" bucket, that's fair. > (And this was a non-blocking comment anyway...) > > > > > > > > > > > I might also consider some language about how "the nested "act" claim= s > > > serve as a history trail that connects the initial request and subjec= t > > > through the various delegation steps undertaken before reaching the > > > current actor. In this sense, the current actor is considered to > > > include the entire authorization/delegation history, leading naturall= y > > > to the nested structure described here". (But see also the other > ballot > > > comment about this potentially leaking information to unauthorized > > > parties; it seems a more careful adjustment of the text is in order > > > here.) > > > > > > > Okay, I can add something to that effect. > > > > > > > > > Section 4.2 > > > > > > Is this really the first time we're defining "scope" as a JWT claim? = I > > > would have thought that would be defined long ago... > > > > > > > Some things haven't historically happened in OAuth the way one might ve= ry > > reasonably have expected. And this is one such thing. > > > > > > > > > > > > Section 4.4 > > > > > > Just to double-check: this is "things that can act as me" (where "me" > is > > > the subject of the token containing this field), right? > > > > > > Yes. Honestly, I have a hard time seeing this claim actually being used > in > > practice. But maybe I'm wrong. And I'm just the editor on this one. But > > yes, that's the intended meaning. > > Okay. I think the this text has a pretty clear reading, but just wanted = to > double-check that I was getting the expected meaning from it (so no chang= e > suggested). > > > > > The > > > parenthetical "May Act For" doesn't really help me decide whether thi= s > > > claim represents the source or target of a permitted delegation, so > > > maybe "Allowed Impersonators" or similar would be more clear. Even > "act > > > as" or "act on behalf of" instead of "act for" would help me, I think= . > > > [This would have trickle-down effects to later parts of the document = as > > > well, e.g., the IANA Considerations.] > > > (Not that I claim to be a representative population, of course!) > > > > > > > On looking at it again, I agree "May Act For" isn't a particularly good > > name nor is it helpful in understanding it. I admit to having a hard ti= me > > with the language here. But, yeah, "May Act For" isn't very good. > > > > What about "Authorized Actor" in the parenthetical and "Authorized Acto= r > - > > the party that is authorized to become the actor" for the Claim > Description > > in registration? > > > > I think that's an improvement, thanks. > > > > > > It would probably also help greatly to note that when a subject_token > is > > > presented to the token endpoint in a token exchange request, the > > > "may_act" claim in the subject token can be used by the authorization > > > service to determine whether the client (or party identified in the > > > actor_token) is authorized to engage in the requested delegation [or > > > impersonation]. > > > > > > > Okay, I can add something to that effect. > > > > > > > > > > Section 6 > > > > > > Let me say a bit more here about my perception of the potential priva= cy > > > considerations involved in the use of an error_uri (so we can figure > out > > > if they are already discussed in a relevant document that we can cite= ; > > > JWT itself doesn't seem to cover this topic). By sending an error_ur= i > > > instead of an error string, the server is in effect causing the clien= t > > > to make an outbound request to a URL of the server's choosing. If > there > > > is a proxy between the client and server, this could result in the > > > server (and/or a party controlled by the server) learning additional > > > information about the client's identity/location. A malicious server > > > could also attempt to construct a URI that, when retrieved by the > > > client, performs some unwanted side effect. Defenses against this > > > latter scenario are pretty well known in the web comunity, but we may > > > want to be sure that the need for them is mentioned in a discoverable > > > place. > > > > > > > Thank you for the further explanation. As I wrote earlier, however, the > > error_uri response parameter was originally defined in RFC 6749 and any > > privacy or security considerations for it are applicable to considerabl= y > > more than this document. > > > > > > > > > Appendix A.1.1 > > > > > > In the following token exchange request, a client is requesting a > > > token with impersonation semantics. [...] > > > > > > What part of the request indicates that impersonation semantics are > > > requested? > > > > > > > I guess it's not explicitly requesting impersonation semantics per se b= ut > > only a subject_token is being supplied in the request so impersonation = is > > kinda implied as there is no party identified that could be delegated t= o. > > > > Do you think the wording should be qualified as such or otherwise > adjusted? > > I could go either way, but if I was adding something, I'd go for a > parenthetical "(with only a subject_token and no actor_token, delegation = is > impossible)". > > > > > > > > > > > Is the use of the "jwt" subject_token_type appropriate, given the > > > previous discussion about id_token/access_token being generally > > > preferred (as conveying more meaning)? > > > > > > > The issuer of that token isn't the given AS so it isn't an access_token= . > > And it doesn't have all the claims required to be an id_token. That > leaves > > JWT. And JWT is used a lot in the examples so their claims can also be > > seen and an "identity" can be traced through the exchange. > > Okay, thanks for the clarification. > > (And for all the changes!) > > -Benjamin > > --=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._ --000000000000f61878057f43aa1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would also advocate for requesting early registrat= ion of the URIs.

(I'= ll follow up on the rest of the thread at some point later as time allows a= nd the usual caveats)


On Fri, Jan = 11, 2019, 10:33 AM Mike Jones <Michael.Jones@microsoft.com wrote:
I would advocate requesting early registration for urn:ietf:param= s:oauth:grant-type:token-exchange.

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

-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu>
Sent: Friday, January 11, 2019 8:13 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: The IESG <iesg@ietf.org>; oauth <oauth@ietf.org>; draft-ietf-oauth-token-exchange@ietf.org; oauth-chairs@i= etf.org
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-to= ken-exchange-16: (with DISCUSS and COMMENT)

I also apologize for the slow response (I gave Brian a unicast heads-up
earlier) -- between vacation, the holidays, and a death in a the family I w= as away from email for quite some time.

On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote:
> I apologize for the slow response, Ben. I was on vacation with my
> family around the Thanksgiving holiday when the ballot position came <= br> > in. And even on returning and starting to work on it, there's an a= wful
> lot here to get through and this kind of thing is very time consuming =
> for me. But thank you for the review - I've attempted to reply, as=
> best I can, to your comments/questions inline below.
>
> On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk <kaduk@mit.edu> wr= ote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-token-exchange-16: Discuss
> >
> > Please refer to
> > https://www.ietf.org/i= esg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatr= acker.ietf.org/doc/draft-ietf-oauth-token-exchange/
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > It looks like allocations in the OAuth URIs registry are merely <= br> > > "Specification Required", so we should not have the exp= ectation of
> > WG exclusivity and thus are squatting on unallocated values here.=
> > Process-wise, that's not great and the IESG shouldn't app= rove a
> > document that is squatting on codepoints.
> >
>
> In retrospect, RFC 6755 <https://tools.ietf.or= g/html/rfc6755> should
> have used "RFC Required" for the OAuth URIs registry. But th= at was
> 2012 and 6755 was my first RFC and I was even more clueless back then =
> than I am now. And what's done is done.
>
> In practice the only entries that have been made to the registry have =
> been from RFCs and the only prospective entries (that I'm aware of=
> anyway) are in documents that are on track to be RFCs. This document <= br> > has followed the same procedures with respect to the OAuth URIs
> registrations as those other documents.
>
> Having said all that, I'm unsure what action you are expecting to = see
> as a result of this DISCUSS comment?

There's two obvious routes -- first, to change the text to use placehol= ders like "TBD1" or "the token-exchange URI" (e.g., as = opposed to urn:ietf:params:oauth:grant-type:token-exchange specifically) an= d request that IANA allocate the specific suggested values; or to get IANA = to explicitly confirm that these values can be registered and will be marke= d as pending until this document is finalized (to prevent allocation "= under our nose" by other means).=C2=A0 Ekr and I can help mediate any = IANA interaction needed for whatever route we end up taking, if needed.

(Basically, this is a process concern -- the IESG should not give its stamp= of approval to a document in a state that does something we don't want= other people to do, even if the final published RFC will be able to make t= hese claims correctly.)

>
>
> > why do we allow both client authentication (i.e., using an actor =
> > token) and a distinct actor_token request parameter?=C2=A0 Is it = supposed
> > to be the case that the actor_token parameter is only supplied fo= r
> > delegation flows?=C2=A0 If so, that needs to be made explicit in = the
> > document.
> >
>
> Client authentication is inherited from RFC 6749. It's optional bu= t
> can be useful for deployments that want to "lock down" who c= an invoke
> token exchange.
>
> The actor_token and subject_token are inputs into the exchange. They <= br> > have to be validated but that is not exactly authentication per se. > Honestly, I struggle with the wording and how to describe it all (here=
> and in not dissimilar contexts of the authorization grants of RFC 7522=
> <https://tools.ietf.org/html/rfc7522> a= nd 7523
> <https://tools.ietf.org/html/rfc7523>).= I've done the best I can in
> the document. If you can propose some text that you think would make <= br> > things more clear or explicit, that'd help progress this. But I > honestly don't know what to add or change here.

Before I start trying to tweak text, can you confirm that the actor_token r= equest parameter is okay to use in both delegation and impersonation scenar= ios?

>
>
> >
> > Are the privacy considerations (e.g., risk of a tailed per-reques= t
> > error_uri) relating to the use of error_uri discussed in some oth= er
> > document that we can refer to from this document's security <= br> > > considerations?=C2=A0 (I say a bit more about this in my COMMENT.= )
> >
>
> I am not aware of any document with such considerations and I've <= br> > searched the likely suspects of RFC 6749 and RFC 6819 but don't fi= nd anything.
>
> The error_uri token endpoint response parameter was defined in the > original OAuth 2.0 framework document (RFC 6749) and any
> considerations around it are applicable to considerably more than this=
> document. It's also very rarely used in practice as far as I know.= I
> don't think that this document, which is a narrow extension of a w= hole
> framework with a series of other documents that use error_uri, is the =
> appropriate place to add privacy or security considerations about
> error_uri.=C2=A0 Perhaps
> https://datatracke= r.ietf.org/doc/draft-ietf-oauth-security-topics/ would be more appropri= ate in scope and content?

Oh, definitely -- I only asked if there was something existing we could che= aply reference; this is definitely not the place to be writing this down fr= om scratch.=C2=A0 Thanks for doing the search!

> I could remove the one mention of error_uri in this document? It's=
> usage would still be possible/valid by virtue of this document being <= br> > an extension of RFC 6749 but, out of sight and out of mind, and this <= br> > doc wouldn't then encourage new usage of it anyway. While usage is= n't really happening anyway.

I don't mind having the reference there; it's not really causing pr= oblems and could potentially be helpful.=C2=A0 We should be able to get awa= y with a generic reference to this class of thing elsewhere and one-sentenc= e description ("when a proxy or similar mechanism is in place to prote= ct client privacy, the error_uri mechanism can induce the client to lose so= me anonymity by dereferencing a URI pointing to a third party server that c= an leak information to the attacker, in a similar fashion as [ref]").= =C2=A0 I don't have a [ref] handy right now, though; I'll need to a= sk around.

In a pinch we could fallback to analogy to open-redirector issues, though w= e differ in which actors are receiving/conveying/acting on untrusted input,= and we can have issues just by making the request as opposed to the user m= is-interpreting the returned resource.=C2=A0 But to reiterate, I'm only= looking for a brief mention that some clients might care and don't nee= d an exhaustive description.

>
>
> >
> > Section 2.1 has:
> >=C2=A0 =C2=A0 audience
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OPTIONAL.=C2=A0 The logical name of the= target service where the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0intends to use the requested security t= oken.=C2=A0 This serves a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0purpose similar to the "resource&q= uot; parameter, but with the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0providing a logical name rather than a = location.=C2=A0 Interpretation
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of the name requires that the value be = something that both the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client and the authorization server und= erstand.=C2=A0 An OAuth client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier, a SAML entity identifier [O= ASIS.saml-core-2.0-os], an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OpenID Connect Issuer Identifier [OpenI= D.Core], or a URI are
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0examples of things that might be used a= s "audience" parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0values.=C2=A0 [...]
> >
> > How does the STS know what type of identifier it is supposed to <= br> > > interpret the provided audience value as?
> >
>
> The STS will have policy and configuration for the target entities for=
> which it supports the issuance of tokens to in this flow, even if/when=
> those entities are different types of things. The STS will have to > search that set of things to find the right one for the given name. In=
> theory I suppose there's potential ambiguity or even name collisio= n.
> But in practice (as it is the STS that ultimately decides the names it=
> supports and can
> service) I don't believe there is an actual issue.

Okay, so at some point we're essentially just doing a lookup based on a= udience string, and the type information is attached to the lookup results = (along with everything else needed).

Do you think it makes sense to add a sentence after the non-elided quoted p= ortion, something like ``However, "audience" values used on a giv= en authorization server must be unique within that server, to ensure that t= hey are properly interpreted as the intended type of value.''?=C2= =A0 (I'm of course open to other suggestions, including "just leav= e it as it is"; I think what triggered me to comment here is that &quo= t;both the client and the authorization server understand" leaves open= the possibility that the AS might share one understanding of a string with= one client and a different understanding of that same string with a second= client, since it's only a pairwise condition but we probably are safer= with a global condition.)

>
>
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > The document could perhaps benefit from greater clarity as to > > whether "security token"s refer to inputs, outputs, or = both, of the
> > token endpoint (for the interactions defined in this specificatio= n).
> >
>
> I have been aware of the potential need here and endeavored to be
> clear about it throughout the document without being overly repetitive= or wordy.
> I will take another pass through the text and look for opportunities <= br> > to further clarity. But if there are specific points in the doc that <= br> > you believe need attention, please point them out so I can be sure > they get addressed.

I made another quick pass, and it is better than I remembered.=C2=A0 So tha= nks for the efforts, and sorry for maligning the document!

Maybe 2.2.1's "token_type" description could reiterate "= issued security token" both times that "security token" appe= ars instead of just the second time, though the context really ought to be = enough to make this one clear.
Other than that, the only potential trouble I see is in the introduction wh= en we get a barrage of the string all at once.=C2=A0 And even that's in= reasonable shape, with the only potential changes I see being in the first= sentence of the second paragraph, something like "capable of validing= security tokens provided to it and issuing new security tokens in response= ".

>
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0The OAuth
> >=C2=A0 =C2=A0 2.0 Authorization Framework [RFC6749] and OAuth 2.0 = Bearer Tokens
> >=C2=A0 =C2=A0 [RFC6750] have emerged as popular standards for auth= orizing third-
> >=C2=A0 =C2=A0 party applications access to HTTP and RESTful resour= ces.=C2=A0 [...]
> >
> > nit: possessive "applications'"
> >
>
> Will fix.
>
>
> >
> > Section 1.1
> >
> > This section really jumps in quickly with no lead-in to why we wo= uld
> > care or transition from the introduction.=C2=A0 I suggest:
> >
> >=C2=A0 =C2=A0One common use case for an STS (as alluded to in the = previous section)
> >=C2=A0 =C2=A0is to allow a resource server A to make calls to a ba= ckend service C on
> >=C2=A0 =C2=A0behalf of the requesting user B.=C2=A0 Depending on t= he local site policy and
> >=C2=A0 =C2=A0authorization infrastructure, it may be desireable fo= r A to use its own
> >=C2=A0 =C2=A0credentials to access C along with an annotation of s= ome form that A is
> >=C2=A0 =C2=A0acting on behalf of B ("delegation"), or fo= r A to be granted a
> > limited access
> >=C2=A0 =C2=A0credential to C but that continues to identify B as t= he authorized
> >=C2=A0 =C2=A0entity ("imperesonation").=C2=A0 Delegation= and impersonation can be useful
> >=C2=A0 =C2=A0concepts in other scenarios involving multiple partic= ipants as well.
> >
>
> Documents written over time with more than one author sometimes bear <= br> > the scars of that process in disjoint transitions, which is the case <= br> > here I think.
>
> You're suggestion nicely takes the edge off the transition and > provides context for it. Thanks, I'll add that text to the top of = sec 1.1.
>
>
>
> > Section 2.1
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, [RFC7523]
> >=C2=A0 =C2=A0 defines client authentication using JSON Web Tokens = (JWTs) [JWT].
> >
> > Please clarify that these are still bearer tokens.
> >
>
> Okay.
>
>
> >
> >=C2=A0 =C2=A0 The supported methods of client authentication and w= hether or not to
> >=C2=A0 =C2=A0 allow unauthenticated or unidentified clients are de= ployment
> >=C2=A0 =C2=A0 decisions that are at the discretion of the authoriz= ation server.
> >
> > It seems appropriate to note that omitting client authentication =
> > allows for a compromised token to be leveraged via an STS into ot= her
> > tokens by anyone possessing the compromised token, and thus that =
> > client authentication allows for additional authorization checks = as
> > to which entities are permitted to impersonate or receive
> > delegations from other entities.
> >
>
> I'll add a note that says as much (borrowing heavily from your wor= ds,
> thanks).
>
>
> >
> >=C2=A0 =C2=A0 The client makes a token exchange request to the tok= en endpoint with
> >=C2=A0 =C2=A0 an extension grant type by including the following p= arameters using
> >=C2=A0 =C2=A0 the "application/x-www-form-urlencoded" fo= rmat with a character
> >=C2=A0 =C2=A0 encoding of UTF-8 in the HTTP request entity-body: > >
> > Is there more to say than "just use UTF-8"; any normali= zation or
> > canonicalization issues to consider?
> >
>
> Nope, no normalization or canonicalization at this layer.

Okay, thanks for confirming.

> Note that Adam Roach did raise a DISCUSS around citation for the media=
> type
> https://mailar= chive.ietf.org/arch/msg/oauth/Q1K-T2VS3wrHW7lx2EiP58b_DY
> w , which might result in a change to the wording here but it's st= ill
> x-www-form-urlencoded with UTF-8 as is better described in
> https://tools.ietf.org/html/rfc6749#ap= pendix-B

Sure; I don't expect those changes to introduce any concerns of the nat= ure I was asking about here.

>
> >
> >=C2=A0 =C2=A0 subject_token
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0REQUIRED.=C2=A0 A security token that r= epresents the identity of the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0party on behalf of whom the request is = being made.=C2=A0 Typically, the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0subject of this token will be the subje= ct of the security token
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0issued in response to this request.
> >
> > nit: I think there's a subtle grammar mismatch here, where we= start
> > off by talking about a/the request and end up with "this req= uest".
> >
>
> So changing that last "this request" to say "the reques= t" would fix
> the mismatch?

I think so.

>
>
> >=C2=A0 =C2=A0 In processing the request, the authorization sever M= UST validate the
> >=C2=A0 =C2=A0 subject token as appropriate for the indicated token= type and, if the
> >=C2=A0 =C2=A0 actor token is present, also validate it according t= o its token type.
> >
> > I misread this the first time around; I'd suggest something l= ike
> > "perform the appropriate validation procedures for the indic= ated
> > token type" (as opposed to just verifying that the presented= token
> > is a syntactically valid instance of the claimed type).
> >
>
> Makes sense, I'll update accordingly.

Thanks.

>
> >
> >=C2=A0 =C2=A0 In the absence of one-time-use or other semantics sp= ecific to the
> >=C2=A0 =C2=A0 token type, the act of performing a token exchange h= as no impact on
> >=C2=A0 =C2=A0 the validity of the subject token or actor token.=C2= =A0 Furthermore, the
> >=C2=A0 =C2=A0 validity of the subject token or actor token have no= impact on the
> >=C2=A0 =C2=A0 validity of the issued token after the exchange has = occurred.
> >
> > Do we really want this strong of a statement?=C2=A0 I suspect tha= t in
> > many environments propagating, e.g., expiration time to the
> > exchanged credential may be desired.
> >
>
> The statement was not in any way intended to prohibit propagating
> expiration time (or other criteria) to the exchanged credential. The <= br> > statement was added, best I can recall, in response to a question that=
> came up in a WG chair review asking if the input token(s) would
> somehow become invalid once used as input to the exchange. Or if some =
> later expiration or other invalidation of the input token(s) would > somehow invalidate the new token.=C2=A0 The point of the statement in = the
> doc was to try and say that there is no inherit linkage effectual
> relationship between the tokens outside the exchange event. There
> could be but that's not a general property of the STS protocol a w= ould be specific to a particular token type or deployment.
>
> Does that make any more sense? Do you think the wording could/should <= br> > be adjusted?

That makes perfect sense for what we want to happen, yes.

I wonder if we really want the second sentence to be saying something like = "The exchange is a one-time event and does not create a tight linkage = betwee the input and output tokens, so that (for example) while the expirat= ion time of the output token may be influenced by that of the input token, = renewal or extension of the input token is not expected to be reflected in = the ouput token's properties.=C2=A0 It may still be appropriate to prop= agate token revocation events, though."=C2=A0 (This bit about revocati= on is perhaps even more interesting than expiration time, and would seem to= be prevented by the current text.)

>
> >
> > Section 2.2.1
> >
> >=C2=A0 =C2=A0 token_type
> > [...]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0contents of the token itself.=C2=A0 Not= e that the meaning of this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0parameter is different from the meaning= of the "issued_token_type"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0parameter, which declares the represent= ation of the issued
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0security token; the term "token ty= pe" is typically used with this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0meaning, as it is in all "*_token_= type" parameters in this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0specification. [...]
> >
> > Please disambiguate what "typically used with this meaning&q= uot; means.
> > Perhaps it would be even more clear to change this field's na= me to
> > "token_access_token_type" to match the name of the regi= stry?
> >
>
> The "token_type" parameter is defined in RFC 6749 for a succ= essful
> response from the token endpoint so this document effectively inherits=
> it. The name is already defined in RFC 6749 and not in scope for this =
> document to change.
> I will update the wording to disambiguate "this meaning" per= your request.

Okay, thanks.

>
>
> > Section 2.3
> >
> >=C2=A0 =C2=A0 The following example demonstrates a hypothetical to= ken exchange in
> >=C2=A0 =C2=A0 which an OAuth resource server assumes the role of t= he client during
> >=C2=A0 =C2=A0 token exchange in order to trade an access token tha= t it received in
> >=C2=A0 =C2=A0 a protected resource request for a token that it wil= l use to call to
> >=C2=A0 =C2=A0 a backend service (extra line breaks and indentation= in the examples
> >=C2=A0 =C2=A0 are for display purposes only).
> >
> > We could maybe add some commas or parentheses to help the reader =
> > group the various clauses properly.=C2=A0 E.g., it is "(trad= e an access
> > token (that it received in a protected resource request)) for a <= br> > > token...", not "trace an access token that it received = (in a
> > protected resource request for a token)", where parentheses = indicate logical grouping.
> >
>
> Will try and do some grouping.
>
>
>
> >
> >=C2=A0 =C2=A0 =C2=A0grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agra= nt-type%3Atoken-exchange
> >=C2=A0 =C2=A0 =C2=A0&resource=3Dhttps%3A%2F%2Fba= ckend.example.com%2Fapi%20
> >=C2=A0 =C2=A0 =C2=A0&subject_token=3DaccVkjcJyb4BWCxGsndESCJQb= dFMogUC5PbRDqceLTC
> >=C2=A0 =C2=A0 =C2=A0&subject_token_type=3D
> >=C2=A0 =C2=A0 =C2=A0 urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aac= cess_token
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Figure 2: Token Exchange Request Is there
> > really supposed to be a %20 in the resource query parameter's= value?
> >
>
> Nope. Nice catch. Thank you. I'll remove it.
>
>
>
> >
> > The token octets in Figures 3 and 4 do not match up, despite the = prose
> > indicating that they are the same token.
> >
>
> Indeed they don't. Look like I missed one token example when updat= ing claim
> names. I'll fix that. Thanks for catching that one.
>
>
>
> >
> > Section 3
> >
> > Would it be appropriate to note (here or elsewhere) that for non-= JWT
> > token formats that are a binary format, the URI used for conveyin= g them
> > needs to be associated with the semantics of base64 (or otherwise= )
> > encoding them for usage with OAuth?
> >
>
> My thinking had been that it'd be more or less self-evident to the= very
> small group and type of people who would ever undertake such a thing. = But a
> brief note to that effect couldn't hurt. I'll add something as= such.
>

To be clear, I wouldn't mind if you decided to leave it as is.=C2=A0 Bu= t thanks
:)

>
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Exchange can work
> >=C2=A0 =C2=A0 with both tokens issued by other parties and tokens = from the given
> >=C2=A0 =C2=A0 authorization server.=C2=A0 [...]
> >
> > Does "work with" mean "accept as input" or &q= uot;produce as output" or both?
> > For input, as both subject_token and actor_token?
> >
>
> Both and yes.

Okay.=C2=A0 (I don't have any text suggestions, and as-is is probably f= ine.)

>
>=C2=A0 =C2=A0 The following token type identifiers are defined by this<= br> > >=C2=A0 =C2=A0 specification.=C2=A0 Other URIs MAY be used to indic= ate other token types.
> > I'd also link to the registry here.
> >
>
> The aforementioned other URIs may well be in different namespace so wo= n't
> ever be in the registry. And that registry also has entries for things=
> other than token types. So I don't think a link to it here would b= e
> particularly helpful or even appropriate necessarily.

Ah, good points.

>
> >
> > Why is the text about "urn:ietf:params:oauth:token-type:jwt&= quot; formatted
> > differently than the other URIs listed?
> >
>
> The list of the ones defined in this doc is a <list style=3D"h= anging"> list
> with each URI in the list appearing in a <t hangText=3D"URI:he= re"> while the
> :jwt URI is defined elsewhere in RFC 7519 but relevant enough to warra= nt
> mention in this doc and it is enclosed in a <spanx style=3D"ve= rb"> tag. I
> feel like I've seen this style of treatment of literal values with= list
> items and in paragraph text in other documents so considered it "= normal".
> Is there a better or more recommended way of doing this kind of thing?=

Nope, what you did is fine.=C2=A0 I think I managed to forget that I was re= ading
a list of identifiers *defined by this specification* before I reached the<= br> end of the list :(

>
>
>
>
> > Section 4.1
> >
> > Do we want to consider a more self-describing subject identifier = scheme,
> > akin to
> > https://tool= s.ietf.org/html/draft-ietf-secevent-subject-identifiers ?
> >
>
> There's nothing precluding the use of such a scheme (well, except = that doc
> doesn't actually define a claim so some claim is needed) but the s= cope of
> this document isn't to be that prescriptive in subject identificat= ion.

Okay.

>
> >
> > The example in Figure 5 appears to be using the "implicit is= suer"
> > behavior wherein the "iss" of the actor's "sub= " is assumed to be the
> > same value as in the containing structure.=C2=A0 I'm not a fa= n of this type
> > of behavior in general, but if it's going to be used, you nee= d to
> > document the possibility in some fashion.
> >
>
> I'm not a hug fan myself but that's what OpenID Connect did an= d so it often
> rears its head.
>
> I've tried to make examples that will be meaningful to readers and= also
> somewhat likely to be realistic.
>
> In this section it does say:
> "For example, the combination
>=C2=A0 =C2=A0 of the two claims "iss" and "sub" mig= ht be necessary to uniquely
>=C2=A0 =C2=A0 identify an actor"
>
> And sub in RFC 7519 says:
> "The subject value MUST either be scoped to be
>=C2=A0 =C2=A0 locally unique in the context of the issuer or be globall= y unique."
>

I guess this could fall into the "globally unique" bucket, that&#= 39;s fair.
(And this was a non-blocking comment anyway...)

>
>
> >
> > I might also consider some language about how "the nested &q= uot;act" claims
> > serve as a history trail that connects the initial request and su= bject
> > through the various delegation steps undertaken before reaching t= he
> > current actor.=C2=A0 In this sense, the current actor is consider= ed to
> > include the entire authorization/delegation history, leading natu= rally
> > to the nested structure described here".=C2=A0 (But see also= the other ballot
> > comment about this potentially leaking information to unauthorize= d
> > parties; it seems a more careful adjustment of the text is in ord= er
> > here.)
> >
>
>=C2=A0 Okay, I can add something to that effect.
>
>
>
> > Section 4.2
> >
> > Is this really the first time we're defining "scope"= ; as a JWT claim?=C2=A0 I
> > would have thought that would be defined long ago...
> >
>
> Some things haven't historically happened in OAuth the way one mig= ht very
> reasonably have expected. And this is one such thing.
>
>
>
> >
> > Section 4.4
> >
> > Just to double-check: this is "things that can act as me&quo= t; (where "me" is
> > the subject of the token containing this field), right?
>
>
> Yes. Honestly, I have a hard time seeing this claim actually being use= d in
> practice. But maybe I'm wrong. And I'm just the editor on this= one. But
> yes, that's the intended meaning.

Okay.=C2=A0 I think the this text has a pretty clear reading, but just want= ed to
double-check that I was getting the expected meaning from it (so no change<= br> suggested).

>
> The
> > parenthetical "May Act For" doesn't really help me = decide whether this
> > claim represents the source or target of a permitted delegation, = so
> > maybe "Allowed Impersonators" or similar would be more = clear.=C2=A0 Even "act
> > as" or "act on behalf of" instead of "act for= " would help me, I think.
> > [This would have trickle-down effects to later parts of the docum= ent as
> > well, e.g., the IANA Considerations.]
> > (Not that I claim to be a representative population, of course!)<= br> > >
>
> On looking at it again, I agree "May Act For" isn't a pa= rticularly good
> name nor is it helpful in understanding it. I admit to having a hard t= ime
> with the language here. But, yeah, "May Act For" isn't v= ery good.
>
> What about "Authorized Actor" in the parenthetical and "= ;Authorized Actor -
> the party that is authorized to become the actor" for the Claim D= escription
> in registration?
>

I think that's an improvement, thanks.

>
> > It would probably also help greatly to note that when a subject_t= oken is
> > presented to the token endpoint in a token exchange request, the<= br> > > "may_act" claim in the subject token can be used by the= authorization
> > service to determine whether the client (or party identified in t= he
> > actor_token) is authorized to engage in the requested delegation = [or
> > impersonation].
> >
>
> Okay, I can add something to that effect.
>
>
> >
> > Section 6
> >
> > Let me say a bit more here about my perception of the potential p= rivacy
> > considerations involved in the use of an error_uri (so we can fig= ure out
> > if they are already discussed in a relevant document that we can = cite;
> > JWT itself doesn't seem to cover this topic).=C2=A0 By sendin= g an error_uri
> > instead of an error string, the server is in effect causing the c= lient
> > to make an outbound request to a URL of the server's choosing= .=C2=A0 If there
> > is a proxy between the client and server, this could result in th= e
> > server (and/or a party controlled by the server) learning additio= nal
> > information about the client's identity/location.=C2=A0 A mal= icious server
> > could also attempt to construct a URI that, when retrieved by the=
> > client, performs some unwanted side effect.=C2=A0 Defenses agains= t this
> > latter scenario are pretty well known in the web comunity, but we= may
> > want to be sure that the need for them is mentioned in a discover= able
> > place.
> >
>
> Thank you for the further explanation. As I wrote earlier, however, th= e
> error_uri response parameter was originally defined in RFC 6749 and an= y
> privacy or security considerations for it are applicable to considerab= ly
> more than this document.
>
>
>
> > Appendix A.1.1
> >
> >=C2=A0 =C2=A0 In the following token exchange request, a client is= requesting a
> >=C2=A0 =C2=A0 token with impersonation semantics. [...]
> >
> > What part of the request indicates that impersonation semantics a= re
> > requested?
> >
>
> I guess it's not explicitly requesting impersonation semantics per= se but
> only a subject_token is being supplied in the request so impersonation= is
> kinda implied as there is no party identified that could be delegated = to.
>
> Do you think the wording should be qualified as such or otherwise adju= sted?

I could go either way, but if I was adding something, I'd go for a
parenthetical "(with only a subject_token and no actor_token, delegati= on is
impossible)".

>
>
> >
> > Is the use of the "jwt" subject_token_type appropriate,= given the
> > previous discussion about id_token/access_token being generally > > preferred (as conveying more meaning)?
> >
>
> The issuer of that token isn't the given AS so it isn't an acc= ess_token.
> And it doesn't have all the claims required to be an id_token. Tha= t leaves
> JWT.=C2=A0 And JWT is used a lot in the examples so their claims can a= lso be
> seen and an "identity" can be traced through the exchange.
Okay, thanks for the clarification.

(And for all the changes!)

-Benjamin


<= 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. --000000000000f61878057f43aa1c-- From nobody Mon Jan 14 08:57:40 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9B1311ED for ; Mon, 14 Jan 2019 08:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 jaVmmIXQpuk0 for ; Mon, 14 Jan 2019 08:57:36 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (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 3F2251311CC for ; Mon, 14 Jan 2019 08:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vr5cI8LA9Z18hMTdmGe3l07I/f2kKCSWTL4f5x/eWc4=; b=kn33qOM0j/GFEJRGTjUNkM6Z7tP1Rjzcmk4S8sUuvgdUw/L0CiJSS1a4n8G/TPzjA3wq49I+iCBy2BefzKLtuKPUSPsy9Cv1WWDhTZSuHIQb7BSEcEX6Hdy5ZfCN5ZS99pFVaEG/+YCt4t6BxJJy1lr8P61hcrsV3R/OejSN2IU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1887.eurprd08.prod.outlook.com (10.173.73.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.15; Mon, 14 Jan 2019 16:57:31 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60%2]) with mapi id 15.20.1516.019; Mon, 14 Jan 2019 16:57:31 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Resource Indicators Implementations Thread-Index: AQHUpEOdkkmT7HzXBUSQuvoP7m/A16WvC1gw Date: Mon, 14 Jan 2019 16:57:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1887; 6:eOa8afHTIidWkQLou2gUPeDC6MrVf2AERGtAWQwbPqG1W2GBExQjWI0bQnImfZoWJ2yZKCAv8DU/3jbuAMDrEkPF+dmS+QbmUHue3qomXk7WS7AshUtO2HLh+gDi40653DlVDUBQSYXqaS8UFMZQA1r0InhPXUi/uh8kH12KRhT6ltvnh1GMRO2r/OPlgBGeueapMWK0IzwT2A47X19rg7WW5a6cU6Eadsc4B57251IXnEmHGHorr9H7m6px6K0bpP30u+yK/zzC/STZ99174doPOhGIYvF5Ec+0KZgRkhxVZBJdp6n1MIeHFnrX7rIek+7yxaxbhHvOrfDM9teI33hs5CkhzszLXPa6WqNTDlKHTXrjbCuwNds8hy0Gy+cXDOeX+ehzYAfyaHHTPQm3Tamm4F5s2Ts7WIDsElJ3ARhcq+Yn2id3i5QXqpfSbeCHGchOL9o7IsX9ulNxPRmQOg==; 5:yGZN3LACCC2nzCoy9K9mbfcXdt4eM2Ia2SrwhPbNL2OcUTmncHMijckkIPg/Ob0mLdD0QMwV+99BW4+r0uadeUdOu35pfxvCMnBzu/xT21Ri7GvSE/j8WY2k6FzqTyzw9JW2mMLnDaUnUbDNFHnxr2j4rFIzMaU6R1c9iBVUw5VxIEUBRlGDarcU3nNA9ffcLF3OJYCFIsnArMZZwZl/2A==; 7:At/mgvXfMUduAK6h4CziC0CXKXjuOuAnawU2Hk3gpzbz8oYIAZjXdyBXKNZILyDwFYeOMQsHRiVLGLBtajrl3/PitZCrjb3FIA6H4obJ9DwCTdfs4w2U2YGhK5ZQ3lid82ShneRLgwvyr86iWAr3Gw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bd5844d4-de68-405e-ff51-08d67a415fbd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1887; x-ms-traffictypediagnostic: VI1PR0801MB1887: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(136003)(396003)(366004)(376002)(39860400002)(346002)(189003)(199004)(40434004)(5660300001)(55016002)(5024004)(14444005)(6436002)(486006)(316002)(25786009)(97736004)(39060400002)(53936002)(71190400001)(256004)(71200400001)(6246003)(53546011)(26005)(110136005)(74316002)(606006)(6116002)(790700001)(3846002)(99286004)(186003)(7696005)(11346002)(446003)(476003)(6506007)(102836004)(68736007)(76176011)(229853002)(86362001)(8676002)(72206003)(81156014)(81166006)(8936002)(106356001)(14454004)(966005)(478600001)(2906002)(54896002)(6306002)(236005)(9686003)(33656002)(66066001)(7736002)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1887; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CQD4gHXxWcgNNd23DWh9FfWmylJEw+T6a8YDF28SOegl4jNNmtvfFMtTROSamouiZoRU8ldGBtPe7e48QF18i74v/Dp/UCbYqqW39dZbP/bhK3NJJDHKEr8lJnRYMT7QUVpVfAIqI/8MJI9ZWCDXMO7dDLC5G3TPMqyru3g8eTIDIt5RjRP+AzxSu7ChAZ9YIAbAPdxXEoFz5ohT3sr7r/ao+s8V/BlaOrCeucuTdFcFGTQWOglvDQ9V72TNldYOKHFbmggUuN/lA1g7QdfwD/XcFLhed1v5I3pQ1i6NwSXvRTuEzNXa4lFkqsYWBgPaLWFRiZk4gNn7ZNIPeqIKYZo0IkOcFWhkvsANmBceCD2m/Xv6MQxFpLpu8kdd96OshUu9CU5CzcMKLEUpXThSDRUhbBh3B81D8k+65Tp5WeM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21126C8A68F8F307EF7048B3FA800VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd5844d4-de68-405e-ff51-08d67a415fbd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 16:57:31.6053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1887 Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators Implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 16:57:39 -0000 --_000_VI1PR0801MB21126C8A68F8F307EF7048B3FA800VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaW1wbGVtZW50IHRoZSByZXNvdXJjZSBpbmRpY2F0b3IgYXMgcGFydCBvZiBvdXIgUGVsaW9u IFNlY3VyZSBEZXZpY2UgQWNjZXNzIChTREEpIHByb2R1Y3QuDQoNCkhlcmUgaXMgdGhlIGxpbms6 DQpodHRwczovL2Nsb3VkLm1iZWQuY29tL2RvY3MvdjEuMi9kZXZpY2UtbWFuYWdlbWVudC9zZWN1 cmUtZGV2aWNlLWFjY2Vzcy5odG1sDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNoZWtoLVl1c2VmDQpTZW50OiBGcmVpdGFnLCA0LiBK YW51YXIgMjAxOSAxNjozOQ0KVG86IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtP QVVUSC1XR10gUmVzb3VyY2UgSW5kaWNhdG9ycyBJbXBsZW1lbnRhdGlvbnMNCg0KQWxsLA0KDQpB cyBwYXJ0IG9mIHRoZSB3cml0ZS11cCBmb3IgdGhlIFJlc291cmNlIEluZGljYXRvcnMgZG9jdW1l bnQsIHdlIGFyZSBsb29raW5nIGZvciBpbmZvcm1hdGlvbiBhYm91dCBpbXBsZW1lbnRhdGlvbnMg Zm9yIHRoaXMgZG9jdW1lbnQuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvDQoNClBsZWFzZSwgbGV0IHVzIGtub3cg aWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgaW1wbGVtZW50YXRpb24gZm9yIHRoaXMgZHJhZnQuDQoN ClJlZ2FyZHMsDQogUmlmYWF0ICYgSGFubmVzDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= --_000_VI1PR0801MB21126C8A68F8F307EF7048B3FA800VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldlIGltcGxlbWVudCB0aGUgcmVzb3VyY2UgaW5kaWNhdG9yIGFzIHBh cnQgb2Ygb3VyIFBlbGlvbiBTZWN1cmUgRGV2aWNlIEFjY2VzcyAoU0RBKSBwcm9kdWN0Lg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgdGhlIGxpbms6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5odHRwczovL2Nsb3VkLm1iZWQuY29tL2RvY3MvdjEuMi9kZXZp Y2UtbWFuYWdlbWVudC9zZWN1cmUtZGV2aWNlLWFjY2Vzcy5odG1sPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmPGJyPg0KPGI+U2VudDo8L2I+IEZyZWl0YWcsIDQu IEphbnVhciAyMDE5IDE2OjM5PGJyPg0KPGI+VG86PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gUmVzb3VyY2UgSW5kaWNhdG9y cyBJbXBsZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgcGFydCBvZiB0aGUgd3JpdGUtdXAgZm9yIHRoZSBSZXNvdXJjZSBJ bmRpY2F0b3JzIGRvY3VtZW50LCB3ZSBhcmUgbG9va2luZyBmb3IgaW5mb3JtYXRpb24gYWJvdXQg aW1wbGVtZW50YXRpb25zIGZvciB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGxlYXNlLCBsZXQgdXMga25vdyBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBp bXBsZW1lbnRhdGlvbiBmb3IgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5uZXM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB21126C8A68F8F307EF7048B3FA800VI1PR0801MB2112_-- From nobody Mon Jan 14 08:59:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF4D1311E5 for ; Mon, 14 Jan 2019 08:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 aLnXPSP968_P for ; Mon, 14 Jan 2019 08:59:04 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::604]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9111311FF for ; Mon, 14 Jan 2019 08:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uwQ5pPkqjQGTyo2eXWoHUJjKWXSiqL+46Enjde1cC30=; b=K0vnou5h3dmo+ebTMTRjp8/OFS6jOCx8lUQG/9+Mtm1BC/izqXC+z+FuXZKnY/W7QGEeYkWBJrHaSGoUZY+HGZPvJVeLXR01m/Rt8xsRNe905v+uG6L+2pSqdo9bziAP9SFAu4zJ6fvqnuy6q8a7OqRYpvSFJZKt4x5hrDUDOPw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1887.eurprd08.prod.outlook.com (10.173.73.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.15; Mon, 14 Jan 2019 16:59:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60%2]) with mapi id 15.20.1516.019; Mon, 14 Jan 2019 16:59:02 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Presentation slots at IETF 104 Thread-Index: AdSsKlCmTTq+VBhuRpim9lovb1fkTA== Date: Mon, 14 Jan 2019 16:59:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1887; 6:deglYyi6NNQvZpcYOgMzdQjoeo90oYCznHH6KKqfdbSsqiTfFWXgkrfJUlw+fsy6mlSv/jznqlcRv9Uo8jMMVhp7Yxj1FTJagBBPC+p5vhbuEiIQVo8G6FFpFVTfKH1Hg8D2kF/EZCDUPs7jtCDfsA+BSmqCLSGJSKtG+QXypZ0zjOfCWRo7n16s9Ecvv/dpxJ83pjzFeVc6ZJzi4ru0I3RwOc7Jv4pFMpX3YHo3/T3YWTTWj1OeHtFDo2YZ0QTs2S0Cdw0JcNBEF1+fH8FuUXH+mf9IbFUR9dIHupdwsl/eHgxzJ620nk9ZOfcaSv1NlLnXLV7gEISXhuS06URMNeRIU5Xr2avQq9aCIQfIDAz+Y7Tzw64eLX1n9lvu/Ix7DvCGex4eQXmyQ/6axaSe5yF/e9jUWzNF7FozQYZpxLr/bkDoQS4rT+srW7U0qQy3mjLyLZRBfb7rzlCgXXNVJw==; 5:1P19Z2AnhmRJxRKUMlw6F8leYRVIzlKhCQ3PwVfhlm+PgGb0v77y8mwe6VgQu951eeZH7Yv0cn0quYUmaPJCaQhPII4sdD4f0Lju6ZAACQmfKlL8h/GcJAgpQSYuA8OMBbdhJC1rTd5cOGdfVzcRvhRmLrDlAVeCVrmXC6OkG85lDwHlJPdDt1ZO2LCVph/ION7u5FqdE6+QONFeDBI4+w==; 7:GpaVvGTCyZyB+WuLn2/F4ry6FxSf40d7fKbEa2I7WRc3DWoe79bhLfdlbTI3Jfw/X+INhn+2AuEFtpAmQwhR8uJOkk/xOzASHhn+FhI+d7SIwmMnDBHqb4gURcg6YHG9LkeBlY2HVq9Vw0pwHZwtjQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 409c5f62-8684-4603-dccc-08d67a4195b4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1887; x-ms-traffictypediagnostic: VI1PR0801MB1887: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(376002)(39860400002)(346002)(53754006)(189003)(199004)(40434004)(5660300001)(55016002)(6916009)(5024004)(14444005)(6436002)(486006)(316002)(25786009)(97736004)(53936002)(71190400001)(256004)(71200400001)(26005)(74316002)(6116002)(790700001)(3846002)(4743002)(99286004)(186003)(7696005)(476003)(6506007)(102836004)(68736007)(86362001)(8676002)(72206003)(81156014)(81166006)(8936002)(106356001)(14454004)(478600001)(2906002)(54896002)(6306002)(9686003)(33656002)(66066001)(7736002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1887; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pRGLINo+CaPEjeMvg1pf2cenz1+R/bM1VkJLhFWsdCX7/gKl6nBUc03fZ4ZYj65wffR0x92kP6rYfcygB+m0hE214HGlbzfYaMN2IVVByvVO8Dt1KdKqNvesOtGmGhFUyCLZMD7yNXqpUZHawkBK759qnqt/L06Epu2O3rRufwNBat4N9NE8m3ETv1xdnTZJczFrLqx0tostwlO3IiKGvtT2r9nyWVbaecnlK6cPTw8u8lCjlPLavyArnJUF8qEiJfeeK66mHuUS8AEPaezgw0UL6F8TbElXVrkEe/LVzS8Z7C3+lk/BwNZQ4Hl5+Or0ijOYBQBKkdrr/JcDD1QTSfIR5VXO0CeB0mtDCXmqpB2UD441rpUYJ2SM6J8ZMsovuWKW3PdAPmwRDA55wVfl/fMgJUL1ZS9BkwDpD18IMfk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21123BFFDC312F6B9D2C8593FA800VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 409c5f62-8684-4603-dccc-08d67a4195b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 16:59:02.1654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1887 Archived-At: Subject: [OAUTH-WG] Presentation slots at IETF 104 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 16:59:09 -0000 --_000_VI1PR0801MB21123BFFDC312F6B9D2C8593FA800VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, If you are planning to give a presentation at IETF#104 please drop us an em= ail. We started planning for the meeting already. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21123BFFDC312F6B9D2C8593FA800VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

If you are planning to give a presentation at IETF#1= 04 please drop us an email.

We started planning for the meeting already.

 

Ciao

Hannes & Rifaat

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21123BFFDC312F6B9D2C8593FA800VI1PR0801MB2112_-- From nobody Mon Jan 14 09:24:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE011311BB for ; Mon, 14 Jan 2019 09:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 VjwZF_sjEC3G for ; Mon, 14 Jan 2019 09:24:21 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFF31311CA for ; Mon, 14 Jan 2019 09:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DkLP059k+AXVYDWJJoleMvEboyNMYUm8yJFRe31eO5w=; b=eod22zESANjTEfqlVNS25ExyX7NByU/IiaHmxaGNzeyR5wneZXIKYwYsPBKljgcdk+v5Ggv5tIAlSnpVxWkNi58N1uQi1nFeRt37GvK5GHwcIqYvd6aDnyS1sGXzKGuCkGneP4pqmK2G7+vmWWOQwdh9UDnUts2L+e6rCUGsfKk= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1742.eurprd08.prod.outlook.com (10.168.67.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Mon, 14 Jan 2019 17:24:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60%2]) with mapi id 15.20.1516.019; Mon, 14 Jan 2019 17:24:17 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Updated "OAuth WG Virtual Office Hours" Conference Bridge Thread-Index: AdSsLfUJ4QKY1KieRFWqCE8Qk3bxfw== Date: Mon, 14 Jan 2019 17:24:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1742; 6:sC9QMRM2FO2+ZX4Gw6DB5PfW4doroKTQOu+MnzA0sSMIGeKyU8cZAQXh3p4RRdpQxcyvgpRszhJ6E3w8hppM++0m79/nScdfMXtDlaT/R5HRrmhdmz74P4w1emLX064qhl5uMTo3q20QWtO95CfOfkQSo2BsMybhKsQUBjamHBmm9d4UtftnVxAGSRa6Xg/0sM/WB4oYaD0SaEXE2FEimg4P2QBpoSmEps9Jmt/V3O/He0FiDe5J9Za9Fm4WnP42rDQ78J4Ly/PqGCvrUy8S4KPHvTHI2uctXXGTlAuW8b5uM+UasmOi5jExO1Tb6HMhT0FLbUVIOrEVMRG43bRva02rkcDUuJSkzTzmizRc+1YgelUXz/o4H7+ZHrq6Ca7JHlfMOWk7ccmn1DGOvZn1VQEMQz4cmZfiwABvoEM/xmuJlmgm33oNm52z1HtjKyBEmGL3GBBV3nsrESnhX3+UqA==; 5:T866uJfYr34i/G1mO7s7V+0nXtddyByrt153GPwwvF/2GgnnfMLpCtMFJaqqZ1+2mwJUyn9RhAR27kVAFcvQNM9Mqz+pQtkS8vUQX98FfBCX8FE9wZGlLnC1VZ7cGoV5BdDFALGH9PlpBMegK8S5oTG39wC+o7zEZb0H27BWeE6N9PiuvOTRr8F3ysoLb7Q/dt49w/6/hbRbRmsVygoi3g==; 7:z4WuAALnBLCRD7vBENXyv0MFRXTH/a0ZOYD/6SRuAT0+j2TO8T3LOcPSDoT22CF7nJHqQZgjFWVXo/Y454BPIIEruZXTOYiKQ5aCEofKaz4CpyJVcnRi9CbpXhvL6AakU5bxxIdR+sieeLlVKP6AYQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fbdc07b7-cd2e-4020-89a0-08d67a451cc7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0801MB1742; x-ms-traffictypediagnostic: VI1PR0801MB1742: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(376002)(396003)(346002)(40434004)(53754006)(199004)(189003)(38314003)(316002)(5660300001)(68736007)(2906002)(15650500001)(55016002)(25786009)(74316002)(478600001)(33656002)(305945005)(14454004)(99936001)(6436002)(72206003)(97736004)(99286004)(476003)(66066001)(71200400001)(71190400001)(53936002)(256004)(14444005)(5024004)(7696005)(6506007)(9686003)(105586002)(6916009)(186003)(6116002)(3846002)(7736002)(486006)(8936002)(86362001)(106356001)(81156014)(81166006)(102836004)(26005)(8676002)(4744005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1742; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: x6UTY39qGnDJHSdHy3xboekyRJY49aeyZPtSDTtpkZZQFu+2mU4/3Q+KCyeWtfyqt+ErbOAkVIhfplzbK1kQFb7Fv7IbAHrANjknAGUqo68Q+1iIIaLoXWvxBBDJlxuNBzTCluSaRIBW5f+GyTVlS0FvMlhpVunlJ5ojteu3qG3H+GeomH23m3FUtQOI9Kb7C5H4WgW77/EJgOviVqy5bAgbUgeH9Xrad5EWqD5i9oLLQjErIRGRaIuSMx9zbEO6u4NTqssnFKkMBzmyJoxslB1GDVk3Sqm1u6hTt+mJHaP+wOvlXsUsi7JZn+EBK9AnOlrkPO9FWwGhf/X0PqnAcXitd9WlO113R66X6xP47PUjYHuJf21j2nY+nWsoQ77oXkxHW1UiFl8cXlyq9nnx9Mh5CqG7KlgiPgpBBjQsT/M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_VI1PR0801MB2112C580FC8245136EA38F89FA800VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbdc07b7-cd2e-4020-89a0-08d67a451cc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 17:24:17.2323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1742 Archived-At: Subject: [OAUTH-WG] Updated "OAuth WG Virtual Office Hours" Conference Bridge X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:24:24 -0000 --_002_VI1PR0801MB2112C580FC8245136EA38F89FA800VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please update your meeting invite for the "OAuth WG Virtual Office Hours" c= onference call. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_002_VI1PR0801MB2112C580FC8245136EA38F89FA800VI1PR0801MB2112_ Content-Type: text/calendar; name="Webex_Meeting.ics" Content-Description: Webex_Meeting.ics Content-Disposition: attachment; filename="Webex_Meeting.ics"; size=3560; creation-date="Mon, 14 Jan 2019 17:23:36 GMT"; modification-date="Mon, 14 Jan 2019 16:09:50 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTcxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE3MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApDTEFTUzpQVUJMSUMKREVTQ1JJUFRJT046 XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1hYWE3NjdiYjQ0NTM0ZDk4ZjI3NDRlZmE1ZDhiMDRmOFxuTWVldGluZyBudW1i ZXIgKGFjY2VzcyBjb2RlKTogNjQ5IDU5OCA2OTdcbk1lZXRpbmcgcGFzc3dvcmQ6IGNvbnN0cmFp bmVkXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpIFxuVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBo b3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ5NTk4Njk3 JTIzJTIzKjAxKlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFi b3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5U IE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlv IGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9p bmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNv cmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3Mg eW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxu ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFM Ij4mbmJzcDs8QlI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+CQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYWFh NzY3YmI0NDUzNGQ5OGYyNzQ0ZWZhNWQ4YjA0ZjgiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBB RkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJleCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+ CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0OSA1OTggNjk3PC9GT05U PgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCQkJCTx0YWJsZT48dHI+PHRkPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8 L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+Y29uc3RyYWluZWQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PGJyPjxGT05U IHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZPTlQ+PGJyPjxGT05UIFNJWkU9IjEiIEZBQ0U9 IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJB UklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5 IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj48c3Ryb25nPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0 OTU5ODY5NyUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9u Om5vbmU7Jz4xLTY1MC00NzktMzIwODwvYT48L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZuYnNwOzxC Uj4JPGEgaHJlZj0iaHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9X QlgwMDAwMjkwNTUiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwi PkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48 Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJ Q0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQg b3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQs IHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcg dGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5n cy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIg Y29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+ PC9GT05UPgpBVFRFTkRFRTtDTj0iQ09SRSBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJ UEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNvcmUtY2hhaXJzQGlldGYub3JnCkRUU1RBTVA6MjAxOTAx MDlUMTYwMDAwWgpVSUQ6ODdlYWRhOGMtZDdmMC00NjkyLTk4YzEtN2Q0ODFjYzk2MzdlClBSSU9S SVRZOjUKRFRTVEFSVDtUWklEPSJFdXJvcGUgVGltZSI6MjAxOTAxMDlUMTcwMDAwCkRURU5EO1Ra SUQ9IkV1cm9wZSBUaW1lIjoyMDE5MDEwOVQxODAwMDAKUlJVTEU6RlJFUT1XRUVLTFk7SU5URVJW QUw9MjtCWURBWT1XRTtVTlRJTD0yMDE5MDMyMFQxODAwMDBaClNFUVVFTkNFOjE1NDc0ODIxOTYK U1VNTUFSWTpDb1JFIEhhbGx3YXkgYW5kIEludGVyaW0gTWVldGluZ3MKVFJBTlNQOk9QQVFVRQpP UkdBTklaRVI7Q049IkNPUkUgV29ya2luZyBHcm91cCI6TUFJTFRPOmNvcmUtY2hhaXJzQGlldGYu b3JnCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpCRUdJTjpWQUxBUk0KVFJJ R0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJN CkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_002_VI1PR0801MB2112C580FC8245136EA38F89FA800VI1PR0801MB2112_-- From nobody Mon Jan 14 10:42:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DB412867A for ; Mon, 14 Jan 2019 10:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOkDoY01IVxI for ; Mon, 14 Jan 2019 10:42:09 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320231274D0 for ; Mon, 14 Jan 2019 10:42:09 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id v10so18414013ios.13 for ; Mon, 14 Jan 2019 10:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QZODcBmf6OWUKEZ2S4n/X4FZGlm1D2/8TjN6XTh8pyE=; b=S+0KFCJNQKSSPl85FKkExthKLg8+0s2kGdlIuMPR1tMiSjuHSbgJPVUPagg0llnaYc 51qKvvztavsfvDw+TFrzi1AYhQ94LXz+Qj+v/XJ1oyhHFdhzTN2/+CFgaTGQobOQZJE4 l6uDfmW8Dh+5YrnvzSwZlCtlaunpas/6tYIBM= 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=QZODcBmf6OWUKEZ2S4n/X4FZGlm1D2/8TjN6XTh8pyE=; b=sgMe7NisFTpY5oNjcagSaUM1zUy9OoHR+ETY+r8BvGBPKtAt0QBEypjvjgYRBbL/Bg ysarEXSzIB29gYDpiw9gtzBS1VdyaPbhgkD/rk/9VXYvFj7CyI/S41qdXvPhYFL+Qb5i PHEpQfR6SB4/jRh7meGZTul2EeS8OcdalCc+vK6jr4l8BZzfKaBA87MqyztaAYELPlJU AgahQgmnsV6ydLH5EOueba5mj4+RbOae/BkjFdnsSe6Zi/WoaVxR31zuJgu+K9POmQCR CK+uyeuXQZXPh6+dtGP4KlklGPra0XKLxkPCxqEf1Ss5oN06c5aJZhC7YewqdhlhwCKZ tedw== X-Gm-Message-State: AJcUukeAnUTMwrxbX0PBYToMVRekpWw3SsbZ4aDuim4cq48YsZhQpvtB Su8Ycj6GAHpsVZRlUjk42vJ5uYrrVStQA17mWEHHr0gXHdMqMfny18kx3f6HJUQ4SOaySSNCeut 7aEx10YXeKDwLBQ== X-Google-Smtp-Source: ALg8bN4yQsal3fkm/VTt0HdpkpLROQLTpKVjOXeXeu51GC5n1wW0m6x7sSBcKhSwwiMuxNySHf3fv5jkP8gsb/a8PhI= X-Received: by 2002:a6b:b345:: with SMTP id c66mr17101158iof.59.1547491328425; Mon, 14 Jan 2019 10:42:08 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <73B00324-DE55-48FD-A21D-B22438A707A7@alkaline-solutions.com> In-Reply-To: <73B00324-DE55-48FD-A21D-B22438A707A7@alkaline-solutions.com> From: Brian Campbell Date: Mon, 14 Jan 2019 11:41:42 -0700 Message-ID: To: David Waite Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000eca0d6057f6f6620" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 18:42:12 -0000 --000000000000eca0d6057f6f6620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, my testing was not via XHR/fetch. Just direct request from the browser. I was making the assumption (maybe foolishly) that it wouldn't impact behavior because it's all at the network layer. I saw that Firefox setting but left the default (at least for my install), which was not to autopick. On Tue, Jan 8, 2019 at 10:30 PM David Waite wrote: > > Was your testing via XHR/fetch? > > FWIW, > > Firefox behavior is determined by a global pick automatically / prompt > every time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt > > Safari on macOS relies on the keychain, where a record is created called > an Identity Preference. This is a URL (https or email) to preferred > certificate mapping. Previously, it would create this record the first ti= me > a user selected a certificate, then never prompt again. > > Chrome seems to delegate to the underlying OS for certificate management, > so on the Mac it has this behavior as well. This means however that other > platforms may have different behaviors. > > Safari on iOS used to automatically select a single certificate match, if > the query was for a single client CA. I didn=E2=80=99t try with other sma= ll numbers > (2, 3, etc) but when exposing the list of all available CAs as valid clie= nt > CAs, it would prompt. This may not be the heuristic anymore, as knowing t= he > name of a client CA (such one issued as part of a cloud EMM deployment) > would allow certificates to be used for tracking. > > IE (pre-edge) would allow the behavior to use an automatic cert or prompt > to be configured per-zone, which would allow policy to send a device/user > identification certificate to a particular set of sites by default. I hav= e > no experience with configuring Edge, unfortunately. > > -DW > --=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._ --000000000000eca0d6057f6f6620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, my testing was not via XHR/fetch. Just direct req= uest from the browser. I was making the assumption (maybe foolishly) that i= t wouldn't impact behavior because it's all at the network layer. <= br>

I saw that Firefox setting but left the defaul= t (at least for my install), which was not to autopick.

<= /div>


On Tue,= Jan 8, 2019 at 10:30 PM David Waite <david@alkaline-solutions.com> wrote:=

<= div>Was your testing via XHR/fetch?

FWIW,

Firefox behavior is determined by a global pick automatica= lly / prompt every time flag. Details at=C2=A0https://wiki.mozilla.org/PSM:CertP= rompt

Safari on macOS relies on the keychain, = where a record is created called an Identity Preference. This is a URL (htt= ps or email) to preferred certificate mapping. Previously, it would create = this record the first time a user selected a certificate, then never prompt= again.

Chrome seems to delegate to the underlying= OS for certificate management, so on the Mac it has this behavior as well.= This means however that other platforms may have different behaviors.

Safari on iOS used to automatically select a single ce= rtificate match, if the query was for a single client CA. I didn=E2=80=99t = try with other small numbers (2, 3, etc) but when exposing the list of all = available CAs as valid client CAs, it would prompt. This may not be the heu= ristic anymore, as knowing the name of a client CA (such one issued as part= of a cloud EMM deployment) would allow certificates to be used for trackin= g.

IE (pre-edge) would allow the behavior to use an aut= omatic cert or prompt to be configured per-zone, which would allow policy t= o send a device/user identification certificate to a particular set of site= s by default. I have no experience with configuring Edge, unfortunately.

-DW

<= 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. --000000000000eca0d6057f6f6620-- From nobody Mon Jan 14 13:29:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D5713134D for ; Mon, 14 Jan 2019 13:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4eAormEiE6pP for ; Mon, 14 Jan 2019 13:29:27 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1251312FF for ; Mon, 14 Jan 2019 13:29:26 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id z7so1906851iti.0 for ; Mon, 14 Jan 2019 13:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h8Fz05lJtFlFG6byFjopubDfXYHtXgFULuqISn5jNMU=; b=UyRG9kM5VHK0JOlW9dcVp7chHFqcOGoRfRaVtTr3lZz2t4YXni4hNBcxDAUzrD2XFI 9AP0gQNwZeXfEozUsv6hCo7Z7rpYFm2ysq1cEbQ+LoX4awyulv+/HYHuONZS3f3+tnaz w6XPylbK/ivN/rxtEVmwky2U5V9PcLJdWf8oA= 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=h8Fz05lJtFlFG6byFjopubDfXYHtXgFULuqISn5jNMU=; b=o1H54YagGg0oPMO/6eAPeOdtZm8ygMg5SsL75zbQAuEMT6nvtCviafLXpegtJWY/pD gjxPWMqzryT0dlaYRxn2k/qMjL/SkJoe7XmmNf5Y5UwKGYDG4/h02rgOP8oQGnhr6dUz Hgd8MhkUo46PLES6P0CC1REK5Nls20uDfuHVO+4lvtA9MpBX+QAemAYLX07C1ghfYc7/ QhbfMyTN/dC0oBgbkC00pEN+azZmTMsfCoJu1vTX1cXPQMYKB94eDSMtnkbjtHLIswMT VDgaf11t+Q+PtSw8OFZgLCqBdtnXsPgMGmlH9P2qJnorMsUZpiNsuJqx/DWCDVaf4mMm C9Cw== X-Gm-Message-State: AJcUukdXmtADuwDLo0LAhZrRvyDLW44eLOGf1cPOTEmJtH5A1QKFolfD kUyFZiqK4JCBxT4Xp1x7YTH+BKXArrrcSgylBS/UgmsZJDDukokIjuFS9FZ6dYqwD3QsEbKEcLv tN04Zdp+jS6jI4g== X-Google-Smtp-Source: ALg8bN5/XUdpe1KPSq0mBMtWcQNtUYf70cFKHATCWSpv73GQqsEBWMwqWkCS9GdkkEOSYBGhX6YoZEMftzFjqaKZ2bk= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr744477itl.124.1547501365836; Mon, 14 Jan 2019 13:29:25 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> From: Brian Campbell Date: Mon, 14 Jan 2019 14:28:59 -0700 Message-ID: To: David Waite Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000336047057f71bd8c" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 21:29:31 -0000 --000000000000336047057f71bd8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Trying to summarize things somewhat here and focus in hopefully towards some decision. There's basically an idea on the table to add an AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON object which contains endpoints that a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this (with mtls_endpoints being that new parameter). { "issuer":"https://server.example.com", "authorization_endpoint":"https://server.example.com/authz", "token_endpoint":"https://server.example.com/token", "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], "userinfo_endpoint":"https://server.example.com/userinfo", "revocation_endpoint":"https://server.example.com/revo", "jwks_uri":"https://server.example.com/jwks.json", * "mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token ", "userinfo_endpoint":"https://mtls .example.com/userinfo ", "revocation_endpoint":"https://mtls .example.com/revo " }* } The idea behind this is that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. The arguments in favor of that seem to be basically that it allows for AS deployments to support MTLS while still allowing for a "not broken" UX for end-users of clients (in-browser javascript clients) that aren't doing MTLS. And that it's not much in terms of adding to the spec and complexity of implementations. The arguments against it seem to be 1) the bad UX isn't really that bad and/or will only happen to a subset of users 2) there are other things that can be done, such as 307ing or renegotiation/post-handshake client auth, to avoid the bad UX. Speaking for myself, I'm kinda torn on it. I will say that, in addition to the folks that have pointed out that renegotiation just isn't possible in some cases, my experience trying to do something like that in the past was not particularly successful or encouraging. That could have been my fault, of course, but still seems a relevant data point. I also have my doubts about the actual difficulty of getting an AS to issue a 307 like response for requests based on the calling client and the likelihood that some/all OAuth client software would handle it appropriately. On Fri, Jan 11, 2019 at 12:32 PM David Waite wrote: > > > > On Jan 11, 2019, at 3:32 AM, Neil Madden > wrote: > > > > On 9 Jan 2019, at 05:54, David Waite > wrote: > >> > >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >>> > >> > >> > >>> All of that is meant as an explanation of sorts to say that I think > that things are actually okay enough as is and that I'd like to retract t= he > proposal I'd previously made about the MTLS draft introducing a new AS > metadata parameter. It is admittedly interesting (ironic?) that Neil sent= a > message in support of the proposal as I was writing this. It did give me > pause but ultimately didn't change my opinion that it's not worth it to a= dd > this new AS metadata parameter. > >> > >> Note that the AS could make a decision based on the token endpoint > request - such as a policy associated with the =E2=80=9Cclient_id=E2=80= =9D, or via a > parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indicatin= g MTLS was desired > by this public client installation. The AS could then to TLS 1.2 > renegotiation, 1.3 post-handshake client authentication, or even use 307 > temporary redirects to another token endpoint to perform mutual > authentication. > > > > Renegotiation is an intriguing option, but it has some practical > difficulties. Our AS product runs in a Java servlet container, where it i= s > pretty much impossible to dynamically trigger renegotiation without > accessing private internal APIs of the container. I also don=E2=80=99t kn= ow how you > could coordinate this in the common scenario where TLS is terminated at a > load balancer/reverse proxy? > > > > A 307 redirect could work though as the server will know if the client > either uses mTLS for client authentication or has indicated that it wants > certificate-bound access tokens, so it can redirect to a mTLS-specific > endpoint in those cases. > > Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a= way to > have say a custom error code or WWW-Authenticate challenge to trigger > renegotiation on the reverse proxy - usually this is just a static, > location-based directive. > > > > >> Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2= =80=9D-like > indicator imply that the client has multiple forms of authentication and = is > choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to add = support > for, because I see it more likely a client would use MTLS without knowing > it (via a device-level policy being applied to a public web or native app= ) > than the reverse, where a single client (represented by a single client_i= d) > is dynamically picking between forms of authentication. > > > > That=E2=80=99s an interesting observation. Can you elaborate on the sor= ts of > device policy you are talking about? I am aware of e.g. mobile device > management being used to push client certificates to iOS devices, but I > think these are only available in Safari. > > The primary use is to set policy to rely on device level management in > controlled environments like enterprises when available. So an AS may try > to detect a client certificate as an indicator of a managed device, use > that to assume a device with certain device-level authentication, single > user usage, remote wipe, etc. characteristics, and decide that it can > reduce user authentication requirements and/or expose additional scopes. > > On more thought, this is typically done as part of the user agent hitting > the authorization endpoint, as a separate native application may be > interacting with the token endpoint, and in some operating systems the > application=E2=80=99s network connections do not utilize (and may not hav= e access > to) the system certificate store. > > In terms of user agents, I believe you can perform similar behavior > (managed systems using client certificates on user agents transparently) = on > macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typical= ly > inherits device level policy. Firefox on desktop I assume you can do that > in limited fashion as well. > > -DW --=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._ --000000000000336047057f71bd8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Trying to= summarize things somewhat here and focus in hopefully towards some decisio= n. There's basically an idea on the table to add an AS metadata paramet= er to the draft-ietf-oauth-mtls doc that would be a JSON object which conta= ins endpoints that a client doing MTLS would use rather than the regular en= dpoints. A straw-man example might look like this (with mtls_endpoints bein= g that new parameter).

{=C2=A0
=C2=A0 "issuer":= "https://serv= er.example.com",
=C2=A0 "authorization_endpoint":&quo= t;https://se= rver.example.com/authz",
=C2=A0 "token_endpoint":&quo= t;https://se= rver.example.com/token",
=C2=A0 "token_endpoint_auth_metho= ds_supported":[=C2=A0 "client_secret_basic","tls_client= _auth", "none"],
=C2=A0 "userinfo_endpoint":&qu= ot;https:= //server.example.com/userinfo",
=C2=A0 "revocation_endpoin= t":"https://server.example.com/revo",
=C2=A0 "jwks_uri":= "ht= tps://server.example.com/jwks.json",
=C2=A0 "mtls_endpo= ints":{=C2=A0
=C2=A0=C2=A0=C2=A0 "token_endpoint":"= https://mtls.e= xample.com/token",
=C2=A0=C2=A0=C2=A0 "userinfo_endpoint&q= uot;:"https://mtls.example.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocat= ion_endpoint":"https://mtls.example.com/revo"
=C2=A0 }
}

The idea behind this is that "regular" clients = (those not doing MTLS) will use the regular endpoints. And only the host/po= rt of the endpoints listed in mtls_endpoints will be set up to request TLS = client certificates during handshake. Thus any potential impact of the Cert= ificateRequest message being sent in the TLS handshake can be avoided for a= ll the other regular clients that are not going to do MTLS - including and = most importantly in-browser javascript clients where there can be less than= desirable UI presented to the end-user.

The = arguments in favor of that seem to be basically that it allows for AS deplo= yments to support MTLS while still allowing for a "not broken" UX= for end-users of clients (in-browser javascript clients) that aren't d= oing MTLS. And that it's not much in terms of adding to the spec and co= mplexity of implementations.

The arguments ag= ainst it seem to be 1) the bad UX isn't really that bad and/or will onl= y happen to a subset of users 2) there are other things that can be done, s= uch as 307ing or renegotiation/post-handshake client auth, to avoid the bad= UX.

Speaking for myself, I'm kinda torn = on it.

I will say that, in addition to the fo= lks that have pointed out that renegotiation just isn't possible in som= e cases, my experience trying to do something like that in the past was not= particularly successful or encouraging. That could have been my fault, of = course, but still seems a relevant data point. I also have my doubts about = the actual difficulty of getting an AS to issue a 307 like response for req= uests based on the calling client and the likelihood that some/all OAuth cl= ient software would handle it appropriately.
=C2=A0

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkalin= e-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

<= 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. --000000000000336047057f71bd8c-- From nobody Mon Jan 14 20:09:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66126130D7A for ; Mon, 14 Jan 2019 20:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0omNSRNephT for ; Mon, 14 Jan 2019 20:09:52 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740103.outbound.protection.outlook.com [40.107.74.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64E812F295 for ; Mon, 14 Jan 2019 20:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T7EIRBFRjCJFIbahL4S7Q8bTo40GM2I5OiS33WrZFV4=; b=Lpxs8WEYHfdpmzR3Zupof6LMsyl16KzRu1mL7Arx2Tr+AyhUP57m2dhrMt13U3wxN3IKtrfnxvTP6Q4CQnqa+YXgHQ8kFWgUL6RE4jQK4VurCeQfyZjzyGLrBGu+uJvfF9884FX9ugrVaHtRWEYqJge+vifwi+tBtPIxE55Zeq0= Received: from DM5PR0101CA0036.prod.exchangelabs.com (2603:10b6:4:28::49) by BYAPR01MB5527.prod.exchangelabs.com (2603:10b6:a03:123::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.20; Tue, 15 Jan 2019 04:09:49 +0000 Received: from BY2NAM03FT054.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::205) by DM5PR0101CA0036.outlook.office365.com (2603:10b6:4:28::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.13 via Frontend Transport; Tue, 15 Jan 2019 04:09:49 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT054.mail.protection.outlook.com (10.152.85.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Tue, 15 Jan 2019 04:09:48 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0F49ioa032288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 23:09:47 -0500 Date: Mon, 14 Jan 2019 22:09:44 -0600 From: Benjamin Kaduk To: Brian Campbell CC: David Waite , oauth Message-ID: <20190115040943.GB18381@kduck.mit.edu> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(396003)(346002)(2980300002)(199004)(189003)(356004)(50466002)(6666004)(446003)(186003)(26005)(1076003)(4744005)(23726003)(229853002)(7696005)(75432002)(106466001)(47776003)(76176011)(336012)(104016004)(426003)(55016002)(97756001)(5660300001)(53416004)(86362001)(316002)(4326008)(786003)(11346002)(36906005)(46406003)(58126008)(54906003)(33656002)(476003)(16586007)(126002)(8676002)(246002)(305945005)(6246003)(2906002)(486006)(956004)(8936002)(478600001)(106002)(88552002)(26826003)(93886005)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB5527; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT054; 1:3EkgRBfPWhtYkX1Pus6GoXUX5f6F75+crl0qrW5DqRx8b/sl25wyrGoPdMQtXXvFEndNiqdPbPOGDL9N0S/D1BYEvQfR1pPkT8a9NEzVcImciqkR/xi+x6pcKbJcMr2u X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 77ce6aa7-0754-44c3-2770-08d67a9f4acc X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BYAPR01MB5527; X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5527; 3:8mCXagdkB41IBKYDge1YSfl7BC7FsYOgMNNOm0DSOllhedBDAtsB17CzffQZPfyOyD7nj/19D+HJCUUtyHXC2GmUvYREBsdfIVmfNkW5K4U6/NfViIhIoTHUyf5vY6cgFLOecErcGK5y4H5mEPy5RszIjx9oCv8dqaU2LHRC7XjV1P5UfZKgYN8xgfJkbn4I6//thVmt1lQnWPeCRZaFrBBWNPMZ1Fzl7pRV3Nzo7DfTXp0qha1G8sDdc5EhEaQab8A3KKMXiZdYfeFQm+oZoCjUL2DUY6UyzRtjJ2Z69j9Mv8YZBrxTIie0q3G9UofOp3G+GblzzLeQXURhNX4GCtIQZUXYPUKmTY2u7hMiiHeHKBrYpn82jc5ReKoKgrXp; 25:TEZiPb3mn24sgtY6kNTDql3g9qoVdKwYwaZ73ZaGzIoB5uFliNjbr4I9Iaa4wcmCl6ivOur0gWSFNf13FYC4Pi/33Q/eoDGO+k52bIuKEhM50xlctlifmV+qaZOdD0tmUZWnTKnolVsga6lyp0DleVISq7go7C33qYQcz4lae16KLwaCfGRQ/EwSJqKQ/6H1jo8gBjElPjwGGywABCaiKlPVgJcR+cY0V+/rqe8u5I0ifWqGWULKn4RwasWQ4VKK7S6gFWHo71RUrEV+Vi21DIc8RB4SPTb5hFMhSXLr9ugwh6JXAImYyjWuLE2qIdigDD4SusCBdWQZvnNR7ITMzw== X-MS-TrafficTypeDiagnostic: BYAPR01MB5527: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5527; 31:iuy228ktv/hpBv8NHvosSp+dBxa4lHFtuwKfVyQmxaOtpNXC+ATcaSCCjqSZwA0xHNKAWicvNPVrjePUb4JNHsHhEhSzV9THwF21aakw1oMyz6E8Q78/yr89G8tUrTTUWzEgvF/1DtNBUh4DRbpU7eSbI8n0JkFNVORes7hofp0tKQ+iGVv/gJZX3YQSs3KEkn2HkF09bFVs01Ig6Lv6+QrhZTgfUGGgk+ltGrz8ykM=; 20:/YBmWOlj8TZMasT+YjFLAitbvokwZcWe5gJsecif75QK2GUHRKKqGi7SJJoFQXPMIz+SsbemHnPdAC7B5T7ZshIU17u7QO92ekJUFXM9nSurCLlE04V3q3i/wDG0TEeSB4JYj5icOuCJP1h70LVX8J8OTzFc2rJm+42/05fwhUSQgeP864MCJYfJPK2HRKc3x8PRKNyGutU0cdg1na/7cNMIRxuZH0iNtFEULlQPTNskcM48fqpa/lwGZThrYm0VbiUD8IG+f1sUB1SUBcY3XQ4X3NqtdMhA4k12YTo8XJt/fK2i5XPHZkMWSKFeRjiwdYgQnIWiD8olwX15KRBd42CzimpPFwwwmsnzqCJ62AlR6Hqdz93MCbU6zVq2yJUqEm8cyPePhbURxFZrnGIk/s5kPjOlefbLpWMN5OumvVZBwMTQKbcvR64/I4X0ohoQbm2SJT8QN1oSUxI1rqW2aaFRII7WCJkoZd0aqCOga1S2rM9uTeYM8+30B+vqimWX2PEKtOluWS23OeTUVz5yU4dHJmkGYUrBjx/yzENih3AHWAwT0O4qnFS4SHNyS/dtdZYHk6HYeLbjSexwxM3OklbuNkOii1DYAulxJPa33fU= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5527; 4:nmViYr8Twp7mNM+1PXYR9vNw4gF3Zez6tdyC8lUI+N6azTsNNuXi5W/tJXZNGGe98F7blbcm1Z/IJtOGsNt6L3r7pQOXfMrrvlvIOSAS/16ZyVxGov7nNGesK108oW8z8bVKX66ofC9s839JnFhJuilfqwW9jQqa1vFO5aputCWtaenpUImDryxx4KVBKSpYZNCuGHaa2YNZ8vgNriCT8A2FnWzIjVmhXFWsnUp6EunSJ+eRA/ucI/TXR0XncEjC/oRGQLchJS3UIaeIdp6en7+UN103tJwFoqIKKKI5Sgl5TkfFg6Ckew0tESqe5+ds X-Forefront-PRVS: 0918748D70 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYAPR01MB5527; 23:X5QzeR5GKuoBLX106/HPj5ovpnLfSy1FudwwE8pLd?= =?us-ascii?Q?rVjvsLEAhL6P2FuKiMipOjEPJba5bSfjp1o7doXpGhN9bzrc+O4VvH5fcJs7?= =?us-ascii?Q?NTxFEzVi+pVoeTBp3f8lTEWQrfZ8LPWgQOVkap0xi1YESgPnRAbxo75/Ufzr?= =?us-ascii?Q?PZfUq7sSvfBtFOJZTSZvUXBQCDonJlhBa1wcBO1uv7mglCVlITndesnDNGbC?= =?us-ascii?Q?+qmjirnopCOJP0vNa6My89P61LWf/E1wWg8l9ZI4D8jjhjou/3FTj/Y4Zc6I?= =?us-ascii?Q?8Uq9+DTLiHLlx9AqZflX2fQ50PIvEwUgoB/sthxwfQxSRP+B+V2W5YwtHIIg?= =?us-ascii?Q?8BQIyQdGX0DVOoQaqe1GB2Lq1fHWCV2C8FFfEtiC+jwGmlYAat366ufRwcia?= =?us-ascii?Q?gtT+sT0nlvNKPcingx6QjHVcwAiCbaVWAlageXldcBOr7mFIU1JHfRk5CQrm?= =?us-ascii?Q?ncsBP326iS36ImMSy0O6xsCeeposzoh3cUlD8wpsNpexQgg0cEappSdyRCfD?= =?us-ascii?Q?KmvyWtTACD9ygpIUKWnSxbL8TQGeFdt83XKehg4QwUWDIGElibPW0WdevB0n?= =?us-ascii?Q?q+48G0oTFA0hvs9uumWo2VFkwv4MmN+OwNro5Qwma4zMwLt07a2Pu+2U640M?= =?us-ascii?Q?08eutXh1mWX1C9vVihDp/kDRiiKluZ/l/j1kE/sEFwPsmkbRBfbXWfMTrqSU?= =?us-ascii?Q?FEyPqIl5dIM4XTkSglEyytNkkujvmr/fKKSI4k8BrOGimCO9lkIWz0heEl+N?= =?us-ascii?Q?OY0u/NnOiVdVEOqSVcuvLgsx1aa8I1XQlTqV02LY67G17idFsJ/3/bRIYteE?= =?us-ascii?Q?bLwfxl8epFA9QAdoqKmSP3P56EQLHD+XO+pKzZAee1wDSc3snK7y2bQKokFB?= =?us-ascii?Q?cvRNIWqUocV9k+n/bbEDSLhnon0EAuUZ83xTHytJjgS617EWfH9vyeOELZCW?= =?us-ascii?Q?H/+essiCFJNBKNYO1AiJBYtjDFyYKGP1GJ1E2hUHjzP0yY024JIm8ZhkL8E6?= =?us-ascii?Q?S/rZSAA9OzJar/a76ekmCX1vGC2UC2Jaxq15l7aZYTgBY4MsU8lh5QPYBQS2?= =?us-ascii?Q?vHbFXoTFT1dpRZ2+b5fME1y/7zAerpXCh3ZfrHiL8e+45BUrMK2YcMp6B5ix?= =?us-ascii?Q?zmyOVZs7TLaaCUqUUs6PiFNsKQWk5OhjK1SwjOgtHHP/NVF0anwNpr3yf//j?= =?us-ascii?Q?OfPbVpcHwz7rRdkbxo/ESZuoGgpPLGQUj+xN4tSEOkp2qPLAZvxG+iPyvq43?= =?us-ascii?Q?w95Vm99hgQzV4s8WzQ=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: CpDZ7zpQgjRSOEx86rWtDXBuswSpE9jp74dcZ4npIHjHWoANaHQaFvC0hD9NdffSMJ9cm3wpFE84Z9uAgmGmlmoSAa9lo26w7FNpzfdaOmWLUFuxqDLvfQBKP1qESOFMgk1rwX1OiFsGw/euenAPaiEdDp0nSUKOBkDAYvbrIcY1j0OX5A3UvaFjZ1mhDrcaw/t06KLvg2K7Q/4otfp+CJRgWeHk3VaNADakOzBiacmsltDyRwPOX0H+zGiUYNUabqqGLnqZPN80C7AadC9sSOMoNxry0TaPi6XY+r0fvfEYHAnEv/RGhKfNwcpvjn2fs9PT9tb7UAShCwtH2DUayYTD+OCdlsl4KR20SOAZKDGV3E8HyFaTClcDWYa5edvaObtAg+tN8jOWE0PAyKeyTzaUJ0f9ANrR1A6LG6TAw+s= X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5527; 6:9V4Gh3md81J9NZe2vkk4l8twWUG3jyGgBM3AJ394Dwg4XHS0YccB9+jYEwph3cwqbIvULd8mup0rGhnP+HyfMQnfSru9C7WnbYZ0maGnEtZq0Ol97kvduvisIorp7KwSaLXYkCC5gOFlNMWykZyPkl/IHH3Dud05u0dyObdHnFoyEsZVa27Zg03K/bteecS63imGqa9PSmjgzCfUj9t2rRJiwuR5RXfJh168fCw9uLYjB9KqJy7kdO9PqIxiS+lSoIvtlb7WC7H7mhK+vLihIzpobECtHx3wswOD6EO2/sVI71b9tYCgC6NOzT+msfa+kOfJFgnbXG1cl0+elRsIfm9w8B1q05AMMMH94XjH5tk0AsFluc6GipfSkIoAig9eqy4D3k50udI8ZuX25iCkB0khUwfvxAKf51ix9p/qP10Xz/7ebxob4wE7gyrSx+WVO+DuuGNvdRJ4F5GasnM7wA==; 5:WatHpvKNr92chGKssfW1klctboW53JpH+AvioTr03eebOrKhY8aFLnV7kcnGaJxGDOtjODpZx1NgsJ1CCqPACxAcCNdCzFmfYGGGDn0BBba8zEsK+nZgJbFELVFh7XWuqhgDFsWyzaIGl/VZVsbqrjQBfjfMoH5kjmZ23n9bJiwl1FHIICYj/1Dz+GO8fLSqmzDHDlD8aNXEbjTpLspapg==; 7:qMhpCCFdeALhiDl++vU0Csgj174S4dzldbkH2TloZY7BbOqy8tQq1uDFTBp7OFjgocyMcF4AyBe3iEIikKLQCDGbcc+XbxS41NYFLDmlv4k31eWIVrFK+bqdvOfC0NrVS7DQUQTm9GvFyBCRu3uv+g== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2019 04:09:48.8878 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77ce6aa7-0754-44c3-2770-08d67a9f4acc X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB5527 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 04:09:54 -0000 On just one narrow point... On Mon, Jan 14, 2019 at 02:28:59PM -0700, Brian Campbell wrote: > > I will say that, in addition to the folks that have pointed out that > renegotiation just isn't possible in some cases, my experience trying to do > something like that in the past was not particularly successful or > encouraging. That could have been my fault, of course, but still seems a > relevant data point. I also have my doubts about the actual difficulty of Also, the TLS folks get sad when we come up with new applications of renegotiation -- its removal from TLS 1.3 made many people happy. -Ben > getting an AS to issue a 307 like response for requests based on the > calling client and the likelihood that some/all OAuth client software would > handle it appropriately. From nobody Tue Jan 15 01:04:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74026130DEA for ; Tue, 15 Jan 2019 01:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham 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 n86xjLcwSui4 for ; Tue, 15 Jan 2019 01:04:48 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0899130E13 for ; Tue, 15 Jan 2019 01:04:47 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id u89-v6so1664533lje.1 for ; Tue, 15 Jan 2019 01:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fXdLkvtdly2eNsYqWNCFjtljydu21xMCGJCHuXgIoKU=; b=WK8iYwg5zv7c8nuG/yLLUFznxuINdYh5lDlad6z71j+GJKze0V42IpQnTtMK0lYVcs yEymv2hk4/OUjZmRmnKV+5NyNM0/23R4hfKjkkIPsWe+nSpyFwxoB77QmnXXw5yEuvIv ukehkLZuBtehhEqoedmvem7+1Q/a3mkOGF2Jg= 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=fXdLkvtdly2eNsYqWNCFjtljydu21xMCGJCHuXgIoKU=; b=nT2bEx7nerT99Eu4fQCY6/fJ2PlR+n5kg/bWH+3Rw9PAcluL4ZFotG/lqMLhF48WCB uaSVuDB3vWvead4NbKHrBh/8Jx+WepmFCS33nIE0mJgFEOZScYSiTz7kf+9555nFOZM7 8mree3qtDJSuk69fzMqfjyM4I6ik980f7k+v2nK60WhPFRehsDm3eIY60VP3iib7eTLv cPWAY9N4NiTqRk6oyySRHhMlTdAGv9NB/SWKcHc8aakaYM+/gC/QGbkZztf0o/9aOEbm +c30TJV0DBHkJVsHEwveNvAGMZeOD0TcrD3hYQ+Pvkfhop+fKUvqsSaIvkw9lFCEDe91 asSw== X-Gm-Message-State: AJcUukcFu4kTG5//Yy6yx9SNiEAjyRCQCABwQz1jBlsg20X61+GKXs2O 6rW+NqN+9e0ymqXu3Ca9Rqlegmq2IQGimEpVlwSb6mhXzszEbp1u X-Google-Smtp-Source: ALg8bN4pcUSyitnbaJ56c3+9Ewf2Su07SBjTRUyanQ3+KJTjtDivg1oOLo5L29vK96PVGcBCHtZv9dV//HrS/811e9w= X-Received: by 2002:a2e:a0d3:: with SMTP id f19-v6mr1997409ljm.48.1547543086021; Tue, 15 Jan 2019 01:04:46 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Dave Tonge Date: Tue, 15 Jan 2019 10:04:34 +0100 Message-ID: To: Brian Campbell Cc: David Waite , oauth Content-Type: multipart/alternative; boundary="000000000000eadde4057f7b73c6" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 09:04:53 -0000 --000000000000eadde4057f7b73c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional. While a 307 redirect seems kind of elegant I worry, like you, that not all clients would handle it appropriately. There would probably need to be an error defined for clients who attempt to use `tls_client_auth` at the regular endpoint. Dave On Mon, 14 Jan 2019 at 22:29, Brian Campbell wrote: > Trying to summarize things somewhat here and focus in hopefully towards > some decision. There's basically an idea on the table to add an AS metada= ta > parameter to the draft-ietf-oauth-mtls doc that would be a JSON object > which contains endpoints that a client doing MTLS would use rather than t= he > regular endpoints. A straw-man example might look like this (with > mtls_endpoints being that new parameter). > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > * "mtls_endpoints":{ > "token_endpoint":"https://mtls.example.com/token > ", "userinfo_endpoint":"https://mtls > .example.com/userinfo > ", "revocation_endpoint":"https://mtls > .example.com/revo > " }* > } > > The idea behind this is that "regular" clients (those not doing MTLS) wil= l > use the regular endpoints. And only the host/port of the endpoints listed > in mtls_endpoints will be set up to request TLS client certificates durin= g > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > The arguments in favor of that seem to be basically that it allows for AS > deployments to support MTLS while still allowing for a "not broken" UX fo= r > end-users of clients (in-browser javascript clients) that aren't doing > MTLS. And that it's not much in terms of adding to the spec and complexit= y > of implementations. > > The arguments against it seem to be 1) the bad UX isn't really that bad > and/or will only happen to a subset of users 2) there are other things th= at > can be done, such as 307ing or renegotiation/post-handshake client auth, = to > avoid the bad UX. > > Speaking for myself, I'm kinda torn on it. > > I will say that, in addition to the folks that have pointed out that > renegotiation just isn't possible in some cases, my experience trying to = do > something like that in the past was not particularly successful or > encouraging. That could have been my fault, of course, but still seems a > relevant data point. I also have my doubts about the actual difficulty of > getting an AS to issue a 307 like response for requests based on the > calling client and the likelihood that some/all OAuth client software wou= ld > handle it appropriately. > > > On Fri, Jan 11, 2019 at 12:32 PM David Waite > wrote: > >> >> >> > On Jan 11, 2019, at 3:32 AM, Neil Madden >> wrote: >> > >> > On 9 Jan 2019, at 05:54, David Waite >> wrote: >> >> >> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> >> >> >> >> >> >>> All of that is meant as an explanation of sorts to say that I think >> that things are actually okay enough as is and that I'd like to retract = the >> proposal I'd previously made about the MTLS draft introducing a new AS >> metadata parameter. It is admittedly interesting (ironic?) that Neil sen= t a >> message in support of the proposal as I was writing this. It did give me >> pause but ultimately didn't change my opinion that it's not worth it to = add >> this new AS metadata parameter. >> >> >> >> Note that the AS could make a decision based on the token endpoint >> request - such as a policy associated with the =E2=80=9Cclient_id=E2=80= =9D, or via a >> parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indicati= ng MTLS was desired >> by this public client installation. The AS could then to TLS 1.2 >> renegotiation, 1.3 post-handshake client authentication, or even use 307 >> temporary redirects to another token endpoint to perform mutual >> authentication. >> > >> > Renegotiation is an intriguing option, but it has some practical >> difficulties. Our AS product runs in a Java servlet container, where it = is >> pretty much impossible to dynamically trigger renegotiation without >> accessing private internal APIs of the container. I also don=E2=80=99t k= now how you >> could coordinate this in the common scenario where TLS is terminated at = a >> load balancer/reverse proxy? >> > >> > A 307 redirect could work though as the server will know if the client >> either uses mTLS for client authentication or has indicated that it want= s >> certificate-bound access tokens, so it can redirect to a mTLS-specific >> endpoint in those cases. >> >> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know = a way to >> have say a custom error code or WWW-Authenticate challenge to trigger >> renegotiation on the reverse proxy - usually this is just a static, >> location-based directive. >> >> > >> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_type= =E2=80=9D-like >> indicator imply that the client has multiple forms of authentication and= is >> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to add= support >> for, because I see it more likely a client would use MTLS without knowin= g >> it (via a device-level policy being applied to a public web or native ap= p) >> than the reverse, where a single client (represented by a single client_= id) >> is dynamically picking between forms of authentication. >> > >> > That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of >> device policy you are talking about? I am aware of e.g. mobile device >> management being used to push client certificates to iOS devices, but I >> think these are only available in Safari. >> >> The primary use is to set policy to rely on device level management in >> controlled environments like enterprises when available. So an AS may tr= y >> to detect a client certificate as an indicator of a managed device, use >> that to assume a device with certain device-level authentication, single >> user usage, remote wipe, etc. characteristics, and decide that it can >> reduce user authentication requirements and/or expose additional scopes. >> >> On more thought, this is typically done as part of the user agent hittin= g >> the authorization endpoint, as a separate native application may be >> interacting with the token endpoint, and in some operating systems the >> application=E2=80=99s network connections do not utilize (and may not ha= ve access >> to) the system certificate store. >> >> In terms of user agents, I believe you can perform similar behavior >> (managed systems using client certificates on user agents transparently)= on >> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typica= lly >> inherits device level policy. Firefox on desktop I assume you can do tha= t >> in limited fashion as well. >> >> -DW > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000eadde4057f7b73c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in favour of the `mtls= _endpoints` metadata parameter - although it should be optional.
Whil= e a 307 redirect seems kind of elegant I worry, like you,=C2=A0 that not al= l clients would handle it appropriately.
There would probably need to= be an error defined for clients who attempt to use `tls_client_auth` at th= e regular endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian = Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here and foc= us in hopefully towards some decision. There's basically an idea on the= table to add an AS metadata parameter to the draft-ietf-oauth-mtls doc tha= t would be a JSON object which contains endpoints that a client doing MTLS = would use rather than the regular endpoints. A straw-man example might look= like this (with mtls_endpoints being that new parameter).

{= =C2=A0
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 &q= uot;authorization_endpoint":"https://server.example.com/authz",
= =C2=A0 "token_endpoint":"https://server.example.com/token",
= =C2=A0 "token_endpoint_auth_methods_supported":[=C2=A0 "clie= nt_secret_basic","tls_client_auth", "none"],
= =C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",
=C2=A0 "jwks_uri":"https://server.example.com/jwks.json<= /a>",
=C2=A0 "mtls_endpoints":{=C2=A0
=C2=A0=C2=A0= =C2=A0 "token_endpoint":"https://mtls.example.com/token",
=C2= =A0=C2=A0=C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo&quo= t;,
=C2=A0=C2=A0=C2=A0 "revocation_endpoint":"https://= mtls= .example.com/revo= "
=C2=A0 }
}

The idea behind th= is is that "regular" clients (those not doing MTLS) will use the = regular endpoints. And only the host/port of the endpoints listed in mtls_e= ndpoints will be set up to request TLS client certificates during handshake= . Thus any potential impact of the CertificateRequest message being sent in= the TLS handshake can be avoided for all the other regular clients that ar= e not going to do MTLS - including and most importantly in-browser javascri= pt clients where there can be less than desirable UI presented to the end-u= ser.

The arguments in favor of that seem to b= e basically that it allows for AS deployments to support MTLS while still a= llowing for a "not broken" UX for end-users of clients (in-browse= r javascript clients) that aren't doing MTLS. And that it's not muc= h in terms of adding to the spec and complexity of implementations.

The arguments against it seem to be 1) the bad UX is= n't really that bad and/or will only happen to a subset of users 2) the= re are other things that can be done, such as 307ing or renegotiation/post-= handshake client auth, to avoid the bad UX.

S= peaking for myself, I'm kinda torn on it.

I will say that, in addition to the folks that have pointed out that reneg= otiation just isn't possible in some cases, my experience trying to do = something like that in the past was not particularly successful or encourag= ing. That could have been my fault, of course, but still seems a relevant d= ata point. I also have my doubts about the actual difficulty of getting an = AS to issue a 307 like response for requests based on the calling client an= d the likelihood that some/all OAuth client software would handle it approp= riately.
=C2=A0

On Fri, Jan 11= , 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

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



--000000000000eadde4057f7b73c6-- From nobody Tue Jan 15 01:30:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25F0130E2B for ; Tue, 15 Jan 2019 01:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSS9gDr7BNK8 for ; Tue, 15 Jan 2019 01:30:47 -0800 (PST) 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 CE028130DEA for ; Tue, 15 Jan 2019 01:30:46 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id i20so1920284otl.0 for ; Tue, 15 Jan 2019 01:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ge4iKDCSq5twaJcX4qiO8uhPpAug9w1KZrKd8vXndog=; b=rDV+6xRgRUa3gkgp1Eu8oaVhG+beTaDRulIkMxClx4rVFxGh5D0+F+JnNsq2XBKssd zDVTuhXamQDOswx3DRmWteNCY+Tu5vkPrDn9eUFeHSFB/pXoSkgR7WXKNspKZ/mk0SUZ Sng0F4IsbXQLxaJ2KnB+P1q9FBMuXgwNpn2qvSj6OZFLZFbpeEW1ni2GqsLNAIz8txGZ 6Tjv91uQh8qslXRoODU+DK+Tfy4M/Xb0tHLBv5y6D4Yhrf1hpXJGSQCH083+XJ3uqeb5 a8SNzxzgxOMrF/xOqJj5GC+mzho84hxHfl01cH2jpYUv4gWTEancrOUC4w7Jf4mNZH5i 71UA== 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=ge4iKDCSq5twaJcX4qiO8uhPpAug9w1KZrKd8vXndog=; b=ZZUuhCILRuWuolGA7fINdxQBVFiI4aHUresQ+AXjPOSKuQRJdEltw18Ah28EZDPa7n D/zjSujWc0vgXHowTd4Sogu83t/pvs5shgbK0hiQnEv8IuK4j4ecOMGU/x7AtEHwl+GH xO1lPV4CYVbjuNYctUFRLKiOhvrqI+e0c/te9yvy/dR4DXn8j1DwYgTYZxtSbVZtGSgx VP6uK1OPrsqGFtzkjTT3DHAQAvx/aa0LWpVdywtyM47xztLMQIwz+N4zfDk8GDesaRrE MMV2FSmWTWT5k1ruSkJEwp8i1P5z0cTjPUNvNQCJRQGrxJgDmdcHueJj6UKbt32tywnP 1coA== X-Gm-Message-State: AJcUukcfZ+oM9hr0auH4AD6mJuwwj7ffSHWUNitLB/ycMmyCCPRczy2F g8WZwupMyc0uYUNmWTdLFnll1UudQsu9ABR5ZnEojuw= X-Google-Smtp-Source: ALg8bN5W+z+UVTV880USNP23M4p5RKyugSU4kBHeNq8wE6RSZyLeVdcboebjrSJSMT9qg0wjixyWK8MWjxEoFOVwu6M= X-Received: by 2002:a9d:1c97:: with SMTP id l23mr1841343ota.276.1547544645944; Tue, 15 Jan 2019 01:30:45 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Filip Skokan Date: Tue, 15 Jan 2019 10:30:34 +0100 Message-ID: To: Dave Tonge Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="000000000000e54ba8057f7bd0f1" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 09:30:53 -0000 --000000000000e54ba8057f7bd0f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in favour of both 307 and metadata. - case 307 - I don't recall ever encountering an http client software that wouldn't have an option for following redirects, same for a server side frameworks not having the option to do a 307 response with a locati= on header. - case 307 - Relying purely on a new metadata doesn't help in the scenario David put forth earlier about clients not being aware of using mtls, a device policy of sorts. - case metadata - no second request if the client knows there's an mtls endpoint it should use. Maybe we should specify both as optional for an AS to deploy and a client to be ready for? S pozdravem, *Filip Skokan* On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge wrote: > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > While a 307 redirect seems kind of elegant I worry, like you, that not > all clients would handle it appropriately. > There would probably need to be an error defined for clients who attempt > to use `tls_client_auth` at the regular endpoint. > > Dave > > On Mon, 14 Jan 2019 at 22:29, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Trying to summarize things somewhat here and focus in hopefully towards >> some decision. There's basically an idea on the table to add an AS metad= ata >> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object >> which contains endpoints that a client doing MTLS would use rather than = the >> regular endpoints. A straw-man example might look like this (with >> mtls_endpoints being that new parameter). >> >> { >> "issuer":"https://server.example.com", >> "authorization_endpoint":"https://server.example.com/authz", >> "token_endpoint":"https://server.example.com/token", >> "token_endpoint_auth_methods_supported":[ >> "client_secret_basic","tls_client_auth", "none"], >> "userinfo_endpoint":"https://server.example.com/userinfo", >> "revocation_endpoint":"https://server.example.com/revo", >> "jwks_uri":"https://server.example.com/jwks.json", >> >> >> >> >> * "mtls_endpoints":{ >> "token_endpoint":"https://mtls.example.com/token >> ", "userinfo_endpoint":"https://mtls >> .example.com/userinfo >> ", "revocation_endpoint":"https://mtls >> ..example.com/revo >> " }* >> } >> >> The idea behind this is that "regular" clients (those not doing MTLS) >> will use the regular endpoints. And only the host/port of the endpoints >> listed in mtls_endpoints will be set up to request TLS client certificat= es >> during handshake.. Thus any potential impact of the CertificateRequest >> message being sent in the TLS handshake can be avoided for all the other >> regular clients that are not going to do MTLS - including and most >> importantly in-browser javascript clients where there can be less than >> desirable UI presented to the end-user. >> >> The arguments in favor of that seem to be basically that it allows for A= S >> deployments to support MTLS while still allowing for a "not broken" UX f= or >> end-users of clients (in-browser javascript clients) that aren't doing >> MTLS. And that it's not much in terms of adding to the spec and complexi= ty >> of implementations. >> >> The arguments against it seem to be 1) the bad UX isn't really that bad >> and/or will only happen to a subset of users 2) there are other things t= hat >> can be done, such as 307ing or renegotiation/post-handshake client auth,= to >> avoid the bad UX. >> >> Speaking for myself, I'm kinda torn on it. >> >> I will say that, in addition to the folks that have pointed out that >> renegotiation just isn't possible in some cases, my experience trying to= do >> something like that in the past was not particularly successful or >> encouraging. That could have been my fault, of course, but still seems a >> relevant data point. I also have my doubts about the actual difficulty o= f >> getting an AS to issue a 307 like response for requests based on the >> calling client and the likelihood that some/all OAuth client software wo= uld >> handle it appropriately. >> >> >> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >> david@alkaline-solutions.com> wrote: >> >>> >>> >>> > On Jan 11, 2019, at 3:32 AM, Neil Madden >>> wrote: >>> > >>> > On 9 Jan 2019, at 05:54, David Waite >>> wrote: >>> >> >>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>> >>> >> >>> >> >>> >>> All of that is meant as an explanation of sorts to say that I think >>> that things are actually okay enough as is and that I'd like to retract= the >>> proposal I'd previously made about the MTLS draft introducing a new AS >>> metadata parameter. It is admittedly interesting (ironic?) that Neil se= nt a >>> message in support of the proposal as I was writing this. It did give m= e >>> pause but ultimately didn't change my opinion that it's not worth it to= add >>> this new AS metadata parameter. >>> >> >>> >> Note that the AS could make a decision based on the token endpoint >>> request - such as a policy associated with the =E2=80=9Cclient_id=E2=80= =9D, or via a >>> parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indicat= ing MTLS was desired >>> by this public client installation. The AS could then to TLS 1.2 >>> renegotiation, 1.3 post-handshake client authentication, or even use 30= 7 >>> temporary redirects to another token endpoint to perform mutual >>> authentication. >>> > >>> > Renegotiation is an intriguing option, but it has some practical >>> difficulties. Our AS product runs in a Java servlet container, where it= is >>> pretty much impossible to dynamically trigger renegotiation without >>> accessing private internal APIs of the container. I also don=E2=80=99t = know how you >>> could coordinate this in the common scenario where TLS is terminated at= a >>> load balancer/reverse proxy? >>> > >>> > A 307 redirect could work though as the server will know if the clien= t >>> either uses mTLS for client authentication or has indicated that it wan= ts >>> certificate-bound access tokens, so it can redirect to a mTLS-specific >>> endpoint in those cases. >>> >>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know= a way to >>> have say a custom error code or WWW-Authenticate challenge to trigger >>> renegotiation on the reverse proxy - usually this is just a static, >>> location-based directive. >>> >>> > >>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_type= =E2=80=9D-like >>> indicator imply that the client has multiple forms of authentication an= d is >>> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to ad= d support >>> for, because I see it more likely a client would use MTLS without knowi= ng >>> it (via a device-level policy being applied to a public web or native a= pp) >>> than the reverse, where a single client (represented by a single client= _id) >>> is dynamically picking between forms of authentication. >>> > >>> > That=E2=80=99s an interesting observation. Can you elaborate on the s= orts of >>> device policy you are talking about? I am aware of e.g. mobile device >>> management being used to push client certificates to iOS devices, but I >>> think these are only available in Safari. >>> >>> The primary use is to set policy to rely on device level management in >>> controlled environments like enterprises when available. So an AS may t= ry >>> to detect a client certificate as an indicator of a managed device, use >>> that to assume a device with certain device-level authentication, singl= e >>> user usage, remote wipe, etc. characteristics, and decide that it can >>> reduce user authentication requirements and/or expose additional scopes= . >>> >>> On more thought, this is typically done as part of the user agent >>> hitting the authorization endpoint, as a separate native application ma= y be >>> interacting with the token endpoint, and in some operating systems the >>> application=E2=80=99s network connections do not utilize (and may not h= ave access >>> to) the system certificate store. >>> >>> In terms of user agents, I believe you can perform similar behavior >>> (managed systems using client certificates on user agents transparently= ) on >>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typic= ally >>> inherits device level policy. Firefox on desktop I assume you can do th= at >>> in limited fashion as well. >>> >>> -DW >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e54ba8057f7bd0f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in favour of both 307 and metadata.=C2=A0
  • case 307 - I don't recall ever encountering an http clie= nt software that wouldn't have an option for following redirects, same = for a server side frameworks not having the option to do a 307 response wit= h a location header.
  • case 307 - Relying purely on a new metadat= a doesn't help in the scenario David put forth earlier about clients no= t being aware of using mtls, a device policy of sorts.
  • case met= adata - no second request if the client knows there's an mtls endpoint = it should use.
Maybe we should specify both as optional= for an AS to deploy and a client to be ready for?

<= div>
S pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave = Tonge <dave.tonge@momentu= mft.co.uk> wrote:
I'm in favour o= f the `mtls_endpoints` metadata parameter - although it should be optional.=
While a 307 redirect seems kind of elegant I worry, like you,=C2=A0 = that not all clients would handle it appropriately.
There would prob= ably need to be an error defined for clients who attempt to use `tls_client= _auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 2= 2:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
Trying to summari= ze things somewhat here and focus in hopefully towards some decision. There= 's basically an idea on the table to add an AS metadata parameter to th= e draft-ietf-oauth-mtls doc that would be a JSON object which contains endp= oints that a client doing MTLS would use rather than the regular endpoints.= A straw-man example might look like this (with mtls_endpoints being that n= ew parameter).

{=C2=A0
=C2=A0 "issuer":"https://server.examp= le.com",
=C2=A0 "authorization_endpoint":"https://server.exa= mple.com/authz",
=C2=A0 "token_endpoint":"https://server.exa= mple.com/token",
=C2=A0 "token_endpoint_auth_methods_suppo= rted":[=C2=A0 "client_secret_basic","tls_client_auth&qu= ot;, "none"],
=C2=A0 "userinfo_endpoint":"https://server= .example.com/userinfo",
=C2=A0 "revocation_endpoint":= "https:/= /server.example.com/revo",
=C2=A0 "jwks_uri":"https://se= rver.example.com/jwks.json",
=C2=A0 "mtls_endpoints&quo= t;:{=C2=A0
=C2=A0=C2=A0=C2=A0 "token_endpoint":"https://mtls.example.= com/token",
=C2=A0=C2=A0=C2=A0 "userinfo_endpoint":&q= uot;https://mtls.e= xample.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocation_endpo= int":"https://mtls..example.com/revo"
=C2=A0 }
}

<= /div>
The idea behind this is that "regular" clients (those n= ot doing MTLS) will use the regular endpoints. And only the host/port of th= e endpoints listed in mtls_endpoints will be set up to request TLS client c= ertificates during handshake.. Thus any potential impact of the Certificate= Request message being sent in the TLS handshake can be avoided for all the = other regular clients that are not going to do MTLS - including and most im= portantly in-browser javascript clients where there can be less than desira= ble UI presented to the end-user.

The argumen= ts in favor of that seem to be basically that it allows for AS deployments = to support MTLS while still allowing for a "not broken" UX for en= d-users of clients (in-browser javascript clients) that aren't doing MT= LS. And that it's not much in terms of adding to the spec and complexit= y of implementations.

The arguments against i= t seem to be 1) the bad UX isn't really that bad and/or will only happe= n to a subset of users 2) there are other things that can be done, such as = 307ing or renegotiation/post-handshake client auth, to avoid the bad UX.

Speaking for myself, I'm kinda torn on it. =

I will say that, in addition to the folks tha= t have pointed out that renegotiation just isn't possible in some cases= , my experience trying to do something like that in the past was not partic= ularly successful or encouraging. That could have been my fault, of course,= but still seems a relevant data point. I also have my doubts about the act= ual difficulty of getting an AS to issue a 307 like response for requests b= ased on the calling client and the likelihood that some/all OAuth client so= ftware would handle it appropriately.
=C2=A0
=

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solut= ions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e54ba8057f7bd0f1-- From nobody Tue Jan 15 05:49:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EE9130E58 for ; Tue, 15 Jan 2019 05:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 f_pDsySCFnDD for ; Tue, 15 Jan 2019 05:49:10 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C4912D4E8 for ; Tue, 15 Jan 2019 05:49:09 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id g76so5074853itg.2 for ; Tue, 15 Jan 2019 05:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HiJhAJIeffCMddpNsboPdkTq64pUINbCGRBtD9/2DEw=; b=EiDRqeQluE+n5fqYn/FL4ZZ1yNyqoREbbmz3tI8n9eok0/TZa2DTbjdLu8K8EQ7LyM QSwk2sabFymfggn9lUhwvGDDdjNrZmA6zhEazfY+YCsaj1TBWezMUykLiUPOm9l0Uwdq fR1lQ4k95Qf5ize3ISwRiXJxf0LRd3q00Esrg= 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=HiJhAJIeffCMddpNsboPdkTq64pUINbCGRBtD9/2DEw=; b=UQ8lYjAQ5XWadFrkiqtauJ1xBcVt29Br/+19BWIw5x9qb0Ftirj+CyhhJheV8J/h0y yXp+jX3hmG3J8Ve/OYxstUvmhmQ2QdIYsHMsMjZnkjqicGc4Wh1YiqN4ZppfVlwhtaR7 EALuPMhYGvvxpzRwjkpTq4s7QoFg8JcaMvOJOLhFqnnjwZ58SICcNKLRqKe3VoTJMphF 4/SgZG/BKO4jqgSM34HMdtxdiLoBaHnE9OnwCIv0cHfP+c6yABQ1kuZ/oeA/qSZA+Iyl ZF7kRjUQYBAgKGPe8ZdeXl6wRGb1LAdkG0cS/067MG6PEj1asrARzp1jW4ZdAKwzPoTy o3ZA== X-Gm-Message-State: AJcUukdTPDnwP70SVHdpQ6lFhZ44NxKTKMIKu1nnKW0R0rRP0l9us8X0 zJf0ezErRq4A7psXy/7vp1wFQThT/dXP2cac3shIMOh3s1W1/AD8HIVJxmaxyHfELPoG4S7hZ8x 7NYKeHqm4PRUDX1yaghM= X-Google-Smtp-Source: ALg8bN7QdBQ3GsqJCQkasGB1zNVTQ2D8cMnHXv6uzc+gZ9amGHwxUlrtX2h46JCiF8ZWlkZnoExCU6S4FOte9tUJ4IU= X-Received: by 2002:a24:3987:: with SMTP id l129mr2365458ita.45.1547560149002; Tue, 15 Jan 2019 05:49:09 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Brian Campbell Date: Tue, 15 Jan 2019 06:48:42 -0700 Message-ID: To: Dave Tonge Cc: David Waite , oauth Content-Type: multipart/alternative; boundary="000000000000f35569057f7f6c87" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 13:49:12 -0000 --000000000000f35569057f7f6c87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata. On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > --=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._ --000000000000f35569057f7f6c87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would definitely be optional, apo= logies if that wasn't made clear. It'd be something to the effect o= f optional for the AS to include and clients doing MTLS would use it when p= resent in AS metadata.

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I&#= 39;m in favour of the `mtls_endpoints` metadata parameter - although it sho= uld be optional.

<= 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. --000000000000f35569057f7f6c87-- From nobody Tue Jan 15 05:55:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE9130E59 for ; Tue, 15 Jan 2019 05:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 iw81EUhpfjxd for ; Tue, 15 Jan 2019 05:54:59 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F022A130DE3 for ; Tue, 15 Jan 2019 05:54:58 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id w18so5121992ite.1 for ; Tue, 15 Jan 2019 05:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=slf9rkZ/6V8oaWp4fEyDKk/atqTimOKnmf7IlVhTnGo=; b=o/peByyHH/9y0JhpKzyQvs8W26D/anf0K4RiWMz9PPOaClCUj3alXkkS3XF2ECIM+8 p8a65Ob4Y6RwWvjTUQjs4U7A17VzLVj22lF9EwoXpBpL/c7vmnDA0DgDWmM3ehlZqumJ uGYejOOV0PwDVBqlcLWVWThhXgWFYM9TJnOjg= 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=slf9rkZ/6V8oaWp4fEyDKk/atqTimOKnmf7IlVhTnGo=; b=lpVRjLhZTZZZsgW6hzvjJtd2hmKwT437+bwNpDRkjZttYE1jljaGlDe8wOPHiY99tS JRf0Kl8zMPbafWA6PYBIsf8YgfkwNluK6t9H6+tZn44F9bAYlBmrIqTb8hs12ptCK62a cODcwgI/2Bh5EWP3RGe5jpBbw8sFBe7FPp0YqSZg6m1PQUBk2FnVNp+1hvAZMA6E+KJC znRBTSg+I6J4bJBjkF2kB8t8Jkq040kvnkGZqU8wx3N6Al3pwraohGfvcWQm+J0sWzQY xmNJTHxyUqJokBn/XdqXS3YkfRMh0cdhU9LeOjuRoF043ms58azqWeLkUR2l0wMqM2Bd jtig== X-Gm-Message-State: AJcUukd8u5evq39Ows8H1PCYv2tklFhHaOk6cWtzEIB3Ak//9cwlD98l fr+QQ6YICTYZzHmkdEazVOwt/4h2e7wEsV3tZloxpHwjkbL5L21wPPvik5IB1d/0TWoLFoRp6s9 sqInfDTLH1YEwbg== X-Google-Smtp-Source: ALg8bN5fVWbkGJ90Bi9ax2owZ8DKf7dh++dZpZS9L1fJaOU2JLodYkjxMiyCkBNKBohaiNbUystTkMN14QHW3RCt5UY= X-Received: by 2002:a24:3987:: with SMTP id l129mr2377115ita.45.1547560498121; Tue, 15 Jan 2019 05:54:58 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Brian Campbell Date: Tue, 15 Jan 2019 06:54:31 -0700 Message-ID: To: Filip Skokan Cc: Dave Tonge , oauth Content-Type: multipart/alternative; boundary="000000000000c25e8c057f7f81c3" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 13:55:02 -0000 --000000000000c25e8c057f7f81c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't know that the use of 307 would need to be discussed in the document itself. On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan wrote: > I'm in favour of both 307 and metadata. > > - case 307 - I don't recall ever encountering an http client software > that wouldn't have an option for following redirects, same for a serve= r > side frameworks not having the option to do a 307 response with a loca= tion > header. > - case 307 - Relying purely on a new metadata doesn't help in the > scenario David put forth earlier about clients not being aware of usin= g > mtls, a device policy of sorts. > - case metadata - no second request if the client knows there's an > mtls endpoint it should use. > > Maybe we should specify both as optional for an AS to deploy and a client > to be ready for? > > S pozdravem, > *Filip Skokan* > > > On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge > wrote: > >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> While a 307 redirect seems kind of elegant I worry, like you, that not >> all clients would handle it appropriately. >> There would probably need to be an error defined for clients who attempt >> to use `tls_client_auth` at the regular endpoint. >> >> Dave >> >> On Mon, 14 Jan 2019 at 22:29, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> Trying to summarize things somewhat here and focus in hopefully towards >>> some decision. There's basically an idea on the table to add an AS meta= data >>> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object >>> which contains endpoints that a client doing MTLS would use rather than= the >>> regular endpoints. A straw-man example might look like this (with >>> mtls_endpoints being that new parameter). >>> >>> { >>> "issuer":"https://server.example.com", >>> "authorization_endpoint":"https://server.example.com/authz", >>> "token_endpoint":"https://server.example.com/token", >>> "token_endpoint_auth_methods_supported":[ >>> "client_secret_basic","tls_client_auth", "none"], >>> "userinfo_endpoint":"https://server..example.com/userinfo >>> ", >>> "revocation_endpoint":"https://server.example.com/revo", >>> "jwks_uri":"https://server.example.com/jwks.json", >>> >>> >>> >>> >>> * "mtls_endpoints":{ >>> "token_endpoint":"https://mtls.example.com/token >>> ", "userinfo_endpoint":"https://mtls >>> .example.com/userinfo >>> ", "revocation_endpoint":"https://mtls >>> ..example.com/revo >>> " }* >>> } >>> >>> The idea behind this is that "regular" clients (those not doing MTLS) >>> will use the regular endpoints. And only the host/port of the endpoints >>> listed in mtls_endpoints will be set up to request TLS client certifica= tes >>> during handshake.. Thus any potential impact of the CertificateRequest >>> message being sent in the TLS handshake can be avoided for all the othe= r >>> regular clients that are not going to do MTLS - including and most >>> importantly in-browser javascript clients where there can be less than >>> desirable UI presented to the end-user. >>> >>> The arguments in favor of that seem to be basically that it allows for >>> AS deployments to support MTLS while still allowing for a "not broken" = UX >>> for end-users of clients (in-browser javascript clients) that aren't do= ing >>> MTLS. And that it's not much in terms of adding to the spec and complex= ity >>> of implementations. >>> >>> The arguments against it seem to be 1) the bad UX isn't really that bad >>> and/or will only happen to a subset of users 2) there are other things = that >>> can be done, such as 307ing or renegotiation/post-handshake client auth= , to >>> avoid the bad UX. >>> >>> Speaking for myself, I'm kinda torn on it. >>> >>> I will say that, in addition to the folks that have pointed out that >>> renegotiation just isn't possible in some cases, my experience trying t= o do >>> something like that in the past was not particularly successful or >>> encouraging. That could have been my fault, of course, but still seems = a >>> relevant data point. I also have my doubts about the actual difficulty = of >>> getting an AS to issue a 307 like response for requests based on the >>> calling client and the likelihood that some/all OAuth client software w= ould >>> handle it appropriately. >>> >>> >>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>> david@alkaline-solutions.com> wrote: >>> >>>> >>>> >>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden >>>> wrote: >>>> > >>>> > On 9 Jan 2019, at 05:54, David Waite >>>> wrote: >>>> >> >>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>> >>>> >> >>>> >> >>>> >>> All of that is meant as an explanation of sorts to say that I thin= k >>>> that things are actually okay enough as is and that I'd like to retrac= t the >>>> proposal I'd previously made about the MTLS draft introducing a new AS >>>> metadata parameter. It is admittedly interesting (ironic?) that Neil s= ent a >>>> message in support of the proposal as I was writing this. It did give = me >>>> pause but ultimately didn't change my opinion that it's not worth it t= o add >>>> this new AS metadata parameter. >>>> >> >>>> >> Note that the AS could make a decision based on the token endpoint >>>> request - such as a policy associated with the =E2=80=9Cclient_id=E2= =80=9D, or via a >>>> parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indica= ting MTLS was desired >>>> by this public client installation. The AS could then to TLS 1.2 >>>> renegotiation, 1.3 post-handshake client authentication, or even use 3= 07 >>>> temporary redirects to another token endpoint to perform mutual >>>> authentication. >>>> > >>>> > Renegotiation is an intriguing option, but it has some practical >>>> difficulties. Our AS product runs in a Java servlet container, where i= t is >>>> pretty much impossible to dynamically trigger renegotiation without >>>> accessing private internal APIs of the container. I also don=E2=80=99t= know how you >>>> could coordinate this in the common scenario where TLS is terminated a= t a >>>> load balancer/reverse proxy? >>>> > >>>> > A 307 redirect could work though as the server will know if the >>>> client either uses mTLS for client authentication or has indicated tha= t it >>>> wants certificate-bound access tokens, so it can redirect to a >>>> mTLS-specific endpoint in those cases. >>>> >>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t kno= w a way >>>> to have say a custom error code or WWW-Authenticate challenge to trigg= er >>>> renegotiation on the reverse proxy - usually this is just a static, >>>> location-based directive. >>>> >>>> > >>>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_type= =E2=80=9D-like >>>> indicator imply that the client has multiple forms of authentication a= nd is >>>> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to a= dd support >>>> for, because I see it more likely a client would use MTLS without know= ing >>>> it (via a device-level policy being applied to a public web or native = app) >>>> than the reverse, where a single client (represented by a single clien= t_id) >>>> is dynamically picking between forms of authentication. >>>> > >>>> > That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of >>>> device policy you are talking about? I am aware of e.g. mobile device >>>> management being used to push client certificates to iOS devices, but = I >>>> think these are only available in Safari. >>>> >>>> The primary use is to set policy to rely on device level management in >>>> controlled environments like enterprises when available. So an AS may = try >>>> to detect a client certificate as an indicator of a managed device, us= e >>>> that to assume a device with certain device-level authentication, sing= le >>>> user usage, remote wipe, etc. characteristics, and decide that it can >>>> reduce user authentication requirements and/or expose additional scope= s. >>>> >>>> On more thought, this is typically done as part of the user agent >>>> hitting the authorization endpoint, as a separate native application m= ay be >>>> interacting with the token endpoint, and in some operating systems the >>>> application=E2=80=99s network connections do not utilize (and may not = have access >>>> to) the system certificate store. >>>> >>>> In terms of user agents, I believe you can perform similar behavior >>>> (managed systems using client certificates on user agents transparentl= y) on >>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typi= cally >>>> inherits device level policy. Firefox on desktop I assume you can do t= hat >>>> in limited fashion as well. >>>> >>>> -DW >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited.... If you have received this communication in error, pleas= e >>> notify the sender immediately by e-mail and delete the message and any = file >>> attachments from your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=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._ --000000000000c25e8c057f7f81c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know that the use of 307 would need to be disc= ussed in the document itself.

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in= favour of both 307 and metadata.=C2=A0
  • case 307 - I don&= #39;t recall ever encountering an http client software that wouldn't ha= ve an option for following redirects, same for a server side frameworks not= having the option to do a 307 response with a location header.
    • case 307 - Relying purely on a new metadata doesn't help in the scenar= io David put forth earlier about clients not being aware of using mtls, a d= evice policy of sorts.
  • case metadata - no second request if the= client knows there's an mtls endpoint it should use.
Maybe we should specify both as optional for an AS to deploy and a clien= t to be ready for?

S pozdravem,
Filip Skokan


On = Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrot= e:
I'm in favour of the `mtls_endpoints` m= etadata parameter - although it should be optional.
While a 307 redi= rect seems kind of elegant I worry, like you,=C2=A0 that not all clients wo= uld handle it appropriately.
There would probably need to be an error= defined for clients who attempt to use `tls_client_auth` at the regular en= dpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <= ;bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here a= nd focus in hopefully towards some decision. There's basically an idea = on the table to add an AS metadata parameter to the draft-ietf-oauth-mtls d= oc that would be a JSON object which contains endpoints that a client doing= MTLS would use rather than the regular endpoints. A straw-man example migh= t look like this (with mtls_endpoints being that new parameter).
=
{=C2=A0
=C2=A0 "issuer":"https://server.example.com",
=C2= =A0 "authorization_endpoint":"https://server.example.com/authz"= ,
=C2=A0 "token_endpoint":"https://server.example.com/token"= ,
=C2=A0 "token_endpoint_auth_methods_supported":[=C2=A0 "= ;client_secret_basic","tls_client_auth", "none"],<= br>=C2=A0 "userinfo_endpoint":"https://server..example.com/userinfo",
=C2=A0 "revocation_endpoint":"https://server.example.com/rev= o",
=C2=A0 "jwks_uri":"https://server.example.com/jwks.j= son",
=C2=A0 "mtls_endpoints":{=C2=A0
=C2=A0= =C2=A0=C2=A0 "token_endpoint":"https://mtls.example.com/token",=C2=A0=C2=A0=C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocation_endpoint":"https:= //mtls..example.com/re= vo"
=C2=A0 }
}

The idea beh= ind this is that "regular" clients (those not doing MTLS) will us= e the regular endpoints. And only the host/port of the endpoints listed in = mtls_endpoints will be set up to request TLS client certificates during han= dshake.. Thus any potential impact of the CertificateRequest message being = sent in the TLS handshake can be avoided for all the other regular clients = that are not going to do MTLS - including and most importantly in-browser j= avascript clients where there can be less than desirable UI presented to th= e end-user.

The arguments in favor of that se= em to be basically that it allows for AS deployments to support MTLS while = still allowing for a "not broken" UX for end-users of clients (in= -browser javascript clients) that aren't doing MTLS. And that it's = not much in terms of adding to the spec and complexity of implementations. =

The arguments against it seem to be 1) the ba= d UX isn't really that bad and/or will only happen to a subset of users= 2) there are other things that can be done, such as 307ing or renegotiatio= n/post-handshake client auth, to avoid the bad UX.

Speaking for myself, I'm kinda torn on it.

I will say that, in addition to the folks that have pointed out tha= t renegotiation just isn't possible in some cases, my experience trying= to do something like that in the past was not particularly successful or e= ncouraging. That could have been my fault, of course, but still seems a rel= evant data point. I also have my doubts about the actual difficulty of gett= ing an AS to issue a 307 like response for requests based on the calling cl= ient and the likelihood that some/all OAuth client software would handle it= appropriately.
=C2=A0

On Fri,= Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote= :


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

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



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

<= 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. --000000000000c25e8c057f7f81c3-- From nobody Tue Jan 15 05:59:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C722130E5A for ; Tue, 15 Jan 2019 05:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 D7exui3rPp0q for ; Tue, 15 Jan 2019 05:59:03 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2929B130E59 for ; Tue, 15 Jan 2019 05:59:03 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id f18so2493283otl.11 for ; Tue, 15 Jan 2019 05:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x+Eyn8SdpPqYSj67WOf1D3e06+pGhAeRblyWjbVzcpQ=; b=c06KUUvWozEWcIKZcyZaMlad6ZivRNR/jqDc2yH1dYkwTosWQ0oRMFpbRHZcHrDHXh 1RjIFTDkyJF73Y4HAytUS29QV3iHRjuDkCx591CS2O+G5GNNy+FSUZy9mi8LXvQW/Itz MnThGSspeW4SxGrGnPRaWCzQGRei2zjDlbYqIS9iuSpk6VLmuBl3RhWqWqU1vpleu3Rz YuF4++/mc5RMmwmm+2Zk/scB6DRlJleP0m6RfhWOHaTBSXGFUj9zLaEgm0IoO/CdzIcM 7bLxm5/R1bWQNXKhtKDShvDJ0CFbkTkQRJrWVPYYqP9hv7XhEMQrECXO4J4UXvd6Sscq oHpA== 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=x+Eyn8SdpPqYSj67WOf1D3e06+pGhAeRblyWjbVzcpQ=; b=GuR49gVe6k9nSaBpY42el/O3OzzfkdV7J37NkTTwlJowShKfVJ0bmQ7fIbdzsrU604 9Jd3YHIPmQEdctUJ65GlcIUi6qGDdZJfQRg9bpgDoSuqCNgAAgrijrnkgp4+O7ehmLyR mL6NX/5MVjJuWYDIXngI+aLby+iV28t1vXbU67kYkCyRmluojhsJwxL06ffytzLMdUvI BmrCSawnKP88ek8HReHauOgYp0sHDMdG41FwJFXnM7DBM5jH2aeCuUcg9iLFqjROPL8Q QxYq2Vm8mIeLlAjBK89cHad3ozfKbfh6j1rvwj/GS9uGWDXOsJPLZKYp2my8V3rrqAAD Bwjw== X-Gm-Message-State: AJcUukfzEISRyLQLNXCTQ1yO4MjwMtbengyOjhfoXo6gv8xv5kuTF9fC i8IPpHPj7vN6N08K6RhDmqIu/+iRqWgo4kSJuA== X-Google-Smtp-Source: ALg8bN691Yn+HQlRwXW++/xigKJ77HL7aHzESc6hc9Y4O4bn2NzPa307CScgUKqhDaL8s7dxgvT81kQoVxCDoFeNCx0= X-Received: by 2002:a05:6830:d:: with SMTP id c13mr2556198otp.82.1547560742264; Tue, 15 Jan 2019 05:59:02 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Filip Skokan Date: Tue, 15 Jan 2019 14:58:51 +0100 Message-ID: To: Brian Campbell Cc: Dave Tonge , oauth Content-Type: multipart/alternative; boundary="0000000000004fa705057f7f90bc" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 13:59:07 -0000 --0000000000004fa705057f7f90bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I don't know that the use of 307 would need to be discussed in the > document itself. If the clients are supposed to be ready for this, yeah. For instance, my client software by default doesn't follow redirects, in order for it to be ready for mtls client authentication i'd have to know 307 is a possibility and whitelist 307 as a valid code to be followed. S pozdravem, *Filip Skokan* On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell wrote: > I don't know that the use of 307 would need to be discussed in the > document itself. > > On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan wrote: > >> I'm in favour of both 307 and metadata. >> >> - case 307 - I don't recall ever encountering an http client software >> that wouldn't have an option for following redirects, same for a serv= er >> side frameworks not having the option to do a 307 response with a loc= ation >> header. >> - case 307 - Relying purely on a new metadata doesn't help in the >> scenario David put forth earlier about clients not being aware of usi= ng >> mtls, a device policy of sorts. >> - case metadata - no second request if the client knows there's an >> mtls endpoint it should use. >> >> Maybe we should specify both as optional for an AS to deploy and a clien= t >> to be ready for? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge >> wrote: >> >>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>> should be optional. >>> While a 307 redirect seems kind of elegant I worry, like you, that not >>> all clients would handle it appropriately. >>> There would probably need to be an error defined for clients who attemp= t >>> to use `tls_client_auth` at the regular endpoint. >>> >>> Dave >>> >>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>>> Trying to summarize things somewhat here and focus in hopefully toward= s >>>> some decision. There's basically an idea on the table to add an AS met= adata >>>> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object >>>> which contains endpoints that a client doing MTLS would use rather tha= n the >>>> regular endpoints. A straw-man example might look like this (with >>>> mtls_endpoints being that new parameter). >>>> >>>> { >>>> "issuer":"https://server.example.com", >>>> "authorization_endpoint":"https://server.example.com/authz", >>>> "token_endpoint":"https://server.example.com/token", >>>> "token_endpoint_auth_methods_supported":[ >>>> "client_secret_basic","tls_client_auth", "none"], >>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>> ", >>>> "revocation_endpoint":"https://server.example.com/revo", >>>> "jwks_uri":"https://server.example.com/jwks.json", >>>> >>>> >>>> >>>> >>>> * "mtls_endpoints":{ >>>> "token_endpoint":"https://mtls.example.com/token >>>> ", "userinfo_endpoint":"https://mtl= s >>>> .example.com/userinfo >>>> ", "revocation_endpoint":"https://mtls >>>> ..example.com/revo >>>> " }* >>>> } >>>> >>>> The idea behind this is that "regular" clients (those not doing MTLS) >>>> will use the regular endpoints. And only the host/port of the endpoint= s >>>> listed in mtls_endpoints will be set up to request TLS client certific= ates >>>> during handshake.. Thus any potential impact of the CertificateRequest >>>> message being sent in the TLS handshake can be avoided for all the oth= er >>>> regular clients that are not going to do MTLS - including and most >>>> importantly in-browser javascript clients where there can be less than >>>> desirable UI presented to the end-user. >>>> >>>> The arguments in favor of that seem to be basically that it allows for >>>> AS deployments to support MTLS while still allowing for a "not broken"= UX >>>> for end-users of clients (in-browser javascript clients) that aren't d= oing >>>> MTLS. And that it's not much in terms of adding to the spec and comple= xity >>>> of implementations. >>>> >>>> The arguments against it seem to be 1) the bad UX isn't really that ba= d >>>> and/or will only happen to a subset of users 2) there are other things= that >>>> can be done, such as 307ing or renegotiation/post-handshake client aut= h, to >>>> avoid the bad UX. >>>> >>>> Speaking for myself, I'm kinda torn on it. >>>> >>>> I will say that, in addition to the folks that have pointed out that >>>> renegotiation just isn't possible in some cases, my experience trying = to do >>>> something like that in the past was not particularly successful or >>>> encouraging. That could have been my fault, of course, but still seems= a >>>> relevant data point. I also have my doubts about the actual difficulty= of >>>> getting an AS to issue a 307 like response for requests based on the >>>> calling client and the likelihood that some/all OAuth client software = would >>>> handle it appropriately. >>>> >>>> >>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>> david@alkaline-solutions.com> wrote: >>>> >>>>> >>>>> >>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden >>>>> wrote: >>>>> > >>>>> > On 9 Jan 2019, at 05:54, David Waite >>>>> wrote: >>>>> >> >>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>> >>> >>>>> >> >>>>> >> >>>>> >>> All of that is meant as an explanation of sorts to say that I >>>>> think that things are actually okay enough as is and that I'd like to >>>>> retract the proposal I'd previously made about the MTLS draft introdu= cing a >>>>> new AS metadata parameter. It is admittedly interesting (ironic?) tha= t Neil >>>>> sent a message in support of the proposal as I was writing this. It d= id >>>>> give me pause but ultimately didn't change my opinion that it's not w= orth >>>>> it to add this new AS metadata parameter. >>>>> >> >>>>> >> Note that the AS could make a decision based on the token endpoint >>>>> request - such as a policy associated with the =E2=80=9Cclient_id=E2= =80=9D, or via a >>>>> parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indic= ating MTLS was desired >>>>> by this public client installation. The AS could then to TLS 1.2 >>>>> renegotiation, 1.3 post-handshake client authentication, or even use = 307 >>>>> temporary redirects to another token endpoint to perform mutual >>>>> authentication. >>>>> > >>>>> > Renegotiation is an intriguing option, but it has some practical >>>>> difficulties. Our AS product runs in a Java servlet container, where = it is >>>>> pretty much impossible to dynamically trigger renegotiation without >>>>> accessing private internal APIs of the container. I also don=E2=80=99= t know how you >>>>> could coordinate this in the common scenario where TLS is terminated = at a >>>>> load balancer/reverse proxy? >>>>> > >>>>> > A 307 redirect could work though as the server will know if the >>>>> client either uses mTLS for client authentication or has indicated th= at it >>>>> wants certificate-bound access tokens, so it can redirect to a >>>>> mTLS-specific endpoint in those cases. >>>>> >>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t kn= ow a way >>>>> to have say a custom error code or WWW-Authenticate challenge to trig= ger >>>>> renegotiation on the reverse proxy - usually this is just a static, >>>>> location-based directive. >>>>> >>>>> > >>>>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like >>>>> indicator imply that the client has multiple forms of authentication = and is >>>>> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to = add support >>>>> for, because I see it more likely a client would use MTLS without kno= wing >>>>> it (via a device-level policy being applied to a public web or native= app) >>>>> than the reverse, where a single client (represented by a single clie= nt_id) >>>>> is dynamically picking between forms of authentication. >>>>> > >>>>> > That=E2=80=99s an interesting observation. Can you elaborate on the= sorts of >>>>> device policy you are talking about? I am aware of e.g. mobile device >>>>> management being used to push client certificates to iOS devices, but= I >>>>> think these are only available in Safari. >>>>> >>>>> The primary use is to set policy to rely on device level management i= n >>>>> controlled environments like enterprises when available. So an AS may= try >>>>> to detect a client certificate as an indicator of a managed device, u= se >>>>> that to assume a device with certain device-level authentication, sin= gle >>>>> user usage, remote wipe, etc. characteristics, and decide that it can >>>>> reduce user authentication requirements and/or expose additional scop= es. >>>>> >>>>> On more thought, this is typically done as part of the user agent >>>>> hitting the authorization endpoint, as a separate native application = may be >>>>> interacting with the token endpoint, and in some operating systems th= e >>>>> application=E2=80=99s network connections do not utilize (and may not= have access >>>>> to) the system certificate store. >>>>> >>>>> In terms of user agents, I believe you can perform similar behavior >>>>> (managed systems using client certificates on user agents transparent= ly) on >>>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typ= ically >>>>> inherits device level policy. Firefox on desktop I assume you can do = that >>>>> in limited fashion as well. >>>>> >>>>> -DW >>>> >>>> >>>> *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, plea= se >>>> notify the sender immediately by e-mail and delete the message and any= file >>>> attachments from your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000004fa705057f7f90bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know that the use of 307 would need to= be discussed in the document itself.=C2=A0

If the clients are supposed to be ready for this, yeah. For instanc= e, my client software by default doesn't follow redirects, in order for= it to be ready for mtls client authentication i'd have to know 307 is = a possibility and whitelist 307 as a valid code to be followed.

S pozdravem,
Filip Sk= okan


On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
I don&#= 39;t know that the use of 307 would need to be discussed in the document it= self.

On Tue, Jan= 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in favou= r of both 307 and metadata.=C2=A0
  • case 307 - I don't = recall ever encountering an http client software that wouldn't have an = option for following redirects, same for a server side frameworks not havin= g the option to do a 307 response with a location header.
  • case = 307 - Relying purely on a new metadata doesn't help in the scenario Dav= id put forth earlier about clients not being aware of using mtls, a device = policy of sorts.
  • case metadata - no second request if the clien= t knows there's an mtls endpoint it should use.
May= be we should specify both as optional for an AS to deploy and a client to b= e ready for?

S pozdravem,=
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@moment= umft.co.uk> wrote:
I'm in favour o= f the `mtls_endpoints` metadata parameter - although it should be optional.=
While a 307 redirect seems kind of elegant I worry, like you,=C2=A0 = that not all clients would handle it appropriately.
There would prob= ably need to be an error defined for clients who attempt to use `tls_client= _auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 2= 2:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
Trying to summari= ze things somewhat here and focus in hopefully towards some decision. There= 's basically an idea on the table to add an AS metadata parameter to th= e draft-ietf-oauth-mtls doc that would be a JSON object which contains endp= oints that a client doing MTLS would use rather than the regular endpoints.= A straw-man example might look like this (with mtls_endpoints being that n= ew parameter).

{=C2=A0
=C2=A0 "issuer":"https://server.examp= le.com",
=C2=A0 "authorization_endpoint":"https://server.exa= mple.com/authz",
=C2=A0 "token_endpoint":"https://server.exa= mple.com/token",
=C2=A0 "token_endpoint_auth_methods_suppo= rted":[=C2=A0 "client_secret_basic","tls_client_auth&qu= ot;, "none"],
=C2=A0 "userinfo_endpoint":"https://server= ..example.com/userinfo",
=C2=A0 "revocation_endpoint"= :"https:= //server.example.com/revo",
=C2=A0 "jwks_uri":"<= a href=3D"https://server.example.com/jwks.json" target=3D"_blank">https://s= erver.example.com/jwks.json",
=C2=A0 "mtls_endpoints&qu= ot;:{=C2=A0
=C2=A0=C2=A0=C2=A0 "token_endpoint":"https://mtls.example.= com/token",
=C2=A0=C2=A0=C2=A0 "userinfo_endpoint":&q= uot;https://mtls.e= xample.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocation_endpo= int":"https://mtls..example.com/revo"
=C2=A0 }
}

<= /div>
The idea behind this is that "regular" clients (those n= ot doing MTLS) will use the regular endpoints. And only the host/port of th= e endpoints listed in mtls_endpoints will be set up to request TLS client c= ertificates during handshake.. Thus any potential impact of the Certificate= Request message being sent in the TLS handshake can be avoided for all the = other regular clients that are not going to do MTLS - including and most im= portantly in-browser javascript clients where there can be less than desira= ble UI presented to the end-user.

The argumen= ts in favor of that seem to be basically that it allows for AS deployments = to support MTLS while still allowing for a "not broken" UX for en= d-users of clients (in-browser javascript clients) that aren't doing MT= LS. And that it's not much in terms of adding to the spec and complexit= y of implementations.

The arguments against i= t seem to be 1) the bad UX isn't really that bad and/or will only happe= n to a subset of users 2) there are other things that can be done, such as = 307ing or renegotiation/post-handshake client auth, to avoid the bad UX.

Speaking for myself, I'm kinda torn on it. =

I will say that, in addition to the folks tha= t have pointed out that renegotiation just isn't possible in some cases= , my experience trying to do something like that in the past was not partic= ularly successful or encouraging. That could have been my fault, of course,= but still seems a relevant data point. I also have my doubts about the act= ual difficulty of getting an AS to issue a 307 like response for requests b= ased on the calling client and the likelihood that some/all OAuth client so= ftware would handle it appropriately.
=C2=A0
=

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solut= ions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

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



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

<= 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.
--0000000000004fa705057f7f90bc-- From daniel@utilityapi.com Tue Jan 15 07:51:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8F124C04 for ; Tue, 15 Jan 2019 07:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I434GSsPW_xy for ; Tue, 15 Jan 2019 07:51:44 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E1E1228B7 for ; Tue, 15 Jan 2019 07:51:44 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id p17so3453409qtl.5 for ; Tue, 15 Jan 2019 07:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/wReaGbart2VqXCH0SG93j4NlpVVblfx7ODoyqH8e1M=; b=PnTtXJw51rXID2oCeM/Kp3yqcTEYO6Y7AbyaFXf1okCiCj6fbMDaejW/Kg2FGcraJW kA5Yifk3cG+UnwqQ+4rma5ZgWYJmVpAyRO7A5RnKYxMFWF5DDdMase2L/TiopAYoiaT9 4UeTS/EG+7Z+U8X8/3svKcgTV3ZfoNRASA744= 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=/wReaGbart2VqXCH0SG93j4NlpVVblfx7ODoyqH8e1M=; b=Tr+13So6BUTzc7sSVw0IId9DLEojvgKEE/OZ70zrFeKQhroiea3+ae2cW6MpWIXFCv Ypxiszz3IB7sJyEtn5RBc4mQIvpsx47j2BWdwfpNHQ4zzZR6DmAI0tg/duKZmIunnJh7 jGncLzSGCz/jYjd2YsgZd+gKU6KHOBAcB3S3/USSaA1mjAzeMyNC/VsoUuZeXrS81RTQ y34TW42Aux2HShK7JnSpLnIygHp8O2dF6JgR9dXcg1uMcx+FcxuD84qjIeczxw0+rx+D Y1sNiXXTXKTD9gdiOxejLMGa5/tjUc8eaYIGxbni9K3b+i8usfgjY5//uZ3vrvnuO17G ushg== X-Gm-Message-State: AJcUukc3zijaYA7GPUCRUSH8ImDRigzXhW3JYATGFGxKEdsCa5wfuHiF LEXP3oKW71Hm4eQhSGH9OPQeDwl6z9y/eGl9VfznJfy5 X-Google-Smtp-Source: ALg8bN7jRiLAP7oxGHrIabIB3FrmRMGUiVQKt+xTgn57aUzQeBkV5NjU7S4RbjbQTMXXXHJbAL8Ve4fJoIH2oClIAyE= X-Received: by 2002:a0c:c993:: with SMTP id b19mr3272757qvk.126.1547567503474; Tue, 15 Jan 2019 07:51:43 -0800 (PST) MIME-Version: 1.0 From: Daniel Roesler Date: Tue, 15 Jan 2019 09:51:07 -0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f954d057f81234d" Archived-At: Subject: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 15:53:33 -0000 --0000000000004f954d057f81234d Content-Type: text/plain; charset="UTF-8" Howdy, Rifaat recommended I post to the mailing list. Specifically, I am looking for a mentor and feedback on a potential new OAuth flow (currently called OTP-flow). Background: I am a participant in the California Public Utility Commission's Customer Data Access Committee (CPUC CDAC), and we are working on improving utility data access to accelerate deployment of more renewable and energy efficiency technologies to fight climate change. However, we are currently struggling with a use-case for which we can't seem to find a good OAuth flow. Use-case: Utility customers want to share their utility data (e.g. historical energy usage) with a client (e.g. an energy auditor, to perform some energy efficiency analysis). However, there are two problems that often occur: 1) Most utility customers do not have online accounts or forgot their login information. This makes typical OAuth user interface complex, since you have to either create an online account in the flow or do some sort of multi-step password-reset/verification process. 2) Utilities are not strongly incentivized to optimize complex UI/UX for the customer in the authorization server interface. In the committee we've gotten to the point where we have to specify number of clicks, div height requirements, and minimum pageload times for a utility to implement their OAuth flows (and then utilities want to charge rate payers for the cost of each UI/UX improvement). So, we have been brainstorming possible ways around these problems, and we think it may require a new type of authorization flow using one-time passcodes (OTP) instead of redirecting the user to the utility for normal OAuth. Luckily, even though utility customers may not have an online account at the utility, the utility usually still has (a) a way of uniquely identifying them and (b) a way of contacting them (phone, email, etc.). I'd like to see if the OAuth working group is an appropriate place to help develop this flow (or if there has already been work done such a flow). I'm happy to write the initial draft, but I would very much appreciate some mentorship from someone more experienced in the workgroup. OTP-flow diagram and example: https://pastebin.com/raw/4Gx8LAQ1 The OTP-flow (called Solution 1b in the committee) is a mix of OAuth device-flow and authorization code flow. Since we want to avoid asking utilities to implement complex authorization interfaces (problem #2 above), the client asks the utility to send the user_code directly to the user (via text/phone/email), then the client asks the user for the user_code and submits it to the utility to get an access token. Also, there is an initial step of identifying (but not authenticating) the user and determining the way in which the OTP code should be sent. If utilities are given some sort of non-secret user identification (e.g. address, phone number, account number, etc.), they should be able to send a user_code to the user that the user can give to the client for authorization. Hopefully, this can shift most of the complex UI/UX development cost away from the utility and onto the third party clients. Unfortunately, the energy industry can be quite behind on the latest and greatest OAuth developments, but we're trying to get better :) Thanks very much, Daniel Roesler daniel@utilityapi.com --0000000000004f954d057f81234d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Rifaat recommended I post to the = mailing list. Specifically, I am looking for a mentor and feedback on a pot= ential new OAuth flow (currently called OTP-flow).

Background:
I = am a participant in the California Public Utility Commission's Customer= Data Access Committee (CPUC CDAC), and we are working on improving utility= data access to accelerate deployment of more renewable and energy efficien= cy technologies to fight climate change.

However, we are currently s= truggling with a use-case for which we can't seem to find a good OAuth = flow.

Use-case:
Utility customers want to share their utility dat= a (e.g. historical energy usage) with a client (e.g. an energy auditor, to = perform some energy efficiency analysis).

However, there are two pro= blems that often occur:

1) Most utility customers do not have online= accounts or forgot their login information. This makes typical OAuth user = interface complex, since you have to either create an online account in the= flow or do some sort of multi-step password-reset/verification process.
2) Utilities are not strongly incentivized to optimize complex UI/UX f= or the customer in the authorization server interface. In the committee we&= #39;ve gotten to the point where we have to specify number of clicks, div h= eight requirements, and minimum pageload times for a utility to implement t= heir OAuth flows (and then utilities want to charge rate payers for the cos= t of each UI/UX improvement).

So, we have been brainstorming possibl= e ways around these problems, and we think it may require a new type of aut= horization flow using one-time passcodes (OTP) instead of redirecting the u= ser to the utility for normal OAuth. Luckily, even though utility customers= may not have an online account at the utility, the utility usually still h= as (a) a way of uniquely identifying them and (b) a way of contacting them = (phone, email, etc.).

I'd like to see if the OAuth working group= is an appropriate place to help develop this flow (or if there has already= been work done such a flow). I'm happy to write the initial draft, but= I would very much appreciate some mentorship from someone more experienced= in the workgroup.

OTP-flow diagram and example:
https://pastebin.com/raw/4G= x8LAQ1

The OTP-flow (called Solution 1b in the committee) is a m= ix of OAuth device-flow and authorization code flow. Since we want to avoid= asking utilities to implement complex authorization interfaces (problem #2= above), the client asks the utility to send the user_code directly to the = user (via text/phone/email), then the client asks the user for the user_cod= e and submits it to the utility to get an access token.

Also, there = is an initial step of identifying (but not authenticating) the user and det= ermining the way in which the OTP code should be sent. If utilities are giv= en some sort of non-secret user identification (e.g. address, phone number,= account number, etc.), they should be able to send a user_code to the user= that the user can give to the client for authorization. Hopefully, this ca= n shift most of the complex UI/UX development cost away from the utility an= d onto the third party clients.

Unfortunately, the energy industry c= an be quite behind on the latest and greatest OAuth developments, but we= 9;re trying to get better :)

Thanks very much,
Daniel Roesler
= daniel@utilityap= i.com

--0000000000004f954d057f81234d-- From nobody Tue Jan 15 13:04:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CADF129AA0 for ; Tue, 15 Jan 2019 13:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 ESfq4Meuo1_Z for ; Tue, 15 Jan 2019 13:04:48 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF961294D0 for ; Tue, 15 Jan 2019 13:04:48 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id i12so1886861pfo.7 for ; Tue, 15 Jan 2019 13:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GdG9gRD2ZqOzJ/XI1iIOs/stdblCpK2KQQfZ2BpKSWg=; b=t33hUGkPYqcT8ob6PJRhxqG6WU/AeDpd2OYHCvlLRfp+bs1az7wPtn5VDXkJkcjYRa SCwOEEMh+ePC7MJSn74pxKGNjddjj+dpISMgauH/xEb2+6+/cmY0ZUUWIbDItHHXpDcH uqUgKzsNvLuYoVLb8PqSkhteZUG0w3uei0Os/lllJW/I5i/zCwO6o+Bo2NgcebcsEMT4 pemx6q+QhrDyTcVsE42FeEZ6+F/kjkqRXGfeIHHv5F1zMvRmTvEkcS29PaWTgjNtaFtX rLA2ctAcrKY68vTEetTp47HFMGPM51lFbG123dgvBpVhVx89kXlj/F7nPyKzfygS9AeW FuiA== 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=GdG9gRD2ZqOzJ/XI1iIOs/stdblCpK2KQQfZ2BpKSWg=; b=kbMFJhTXzDdWdXIIsWUGzI2AoZ4xogmeznOeZ0hlyeWwhjsUclks9bxRffLxjGpkwx vkZO+8fDTSraHoKvphbNCCKLV4rEBUL16L60X0Wq+OHqU4IFY2uv2XWy2XjKiURXrN1Y beoWq1zmZ8bYhR7loyRGqsCMlz0vZg9Iyzc8SI11bnggMFOAESRPGW2GVfbV3sYA5yCj /73pnIQCc04+RHshz3CXQVnA7s5VwOiDtIIw25PsvZLMOYxOUNOb4mWiHzWI38qwu/tv CR9BuTPnRBqpPD75Aho39mlOJALlCP96lgkkGbsgXtm5aYk0ntwNZ2hXGmDmoB02dbLi NKgQ== X-Gm-Message-State: AJcUukchOLmpAJzuAa30YSLBlGfE36FFrJNDYKIVP3/72UIH62nTxWDy tUI3UVMQIrV66SvQd9YEuYKkK0eI+IVn4fmvGKBeDTi1nfa8FQ== X-Google-Smtp-Source: ALg8bN4iK2U1M4HmIO6nFrMHgRDr0151kBXN0Lqc1uj6evxTiyloKhaQQ34l0I7Vr0ncHxIJ9j/8Pp1ohMBL5ebhg64= X-Received: by 2002:a65:43c5:: with SMTP id n5mr5732590pgp.250.1547586287111; Tue, 15 Jan 2019 13:04:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Samuel Erdtman Date: Tue, 15 Jan 2019 22:04:35 +0100 Message-ID: To: Daniel Roesler Cc: "" Content-Type: multipart/alternative; boundary="000000000000e732a9057f8582f1" Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:04:53 -0000 --000000000000e732a9057f8582f1 Content-Type: text/plain; charset="UTF-8" To me this looks similar to the device flow. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 See figure 1, my interpretation of what you want to do is to split up step B so that the code goes via another channel and then revers the direction of C and D. So maybe you could ride on some of the work done in the device flow draft. On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler wrote: > Howdy, > > Rifaat recommended I post to the mailing list. Specifically, I am looking > for a mentor and feedback on a potential new OAuth flow (currently called > OTP-flow). > > Background: > I am a participant in the California Public Utility Commission's Customer > Data Access Committee (CPUC CDAC), and we are working on improving utility > data access to accelerate deployment of more renewable and energy > efficiency technologies to fight climate change. > > However, we are currently struggling with a use-case for which we can't > seem to find a good OAuth flow. > > Use-case: > Utility customers want to share their utility data (e.g. historical energy > usage) with a client (e.g. an energy auditor, to perform some energy > efficiency analysis). > > However, there are two problems that often occur: > > 1) Most utility customers do not have online accounts or forgot their > login information. This makes typical OAuth user interface complex, since > you have to either create an online account in the flow or do some sort of > multi-step password-reset/verification process. > > 2) Utilities are not strongly incentivized to optimize complex UI/UX for > the customer in the authorization server interface. In the committee we've > gotten to the point where we have to specify number of clicks, div height > requirements, and minimum pageload times for a utility to implement their > OAuth flows (and then utilities want to charge rate payers for the cost of > each UI/UX improvement). > > So, we have been brainstorming possible ways around these problems, and we > think it may require a new type of authorization flow using one-time > passcodes (OTP) instead of redirecting the user to the utility for normal > OAuth. Luckily, even though utility customers may not have an online > account at the utility, the utility usually still has (a) a way of uniquely > identifying them and (b) a way of contacting them (phone, email, etc.). > > I'd like to see if the OAuth working group is an appropriate place to help > develop this flow (or if there has already been work done such a flow). I'm > happy to write the initial draft, but I would very much appreciate some > mentorship from someone more experienced in the workgroup. > > OTP-flow diagram and example: > https://pastebin.com/raw/4Gx8LAQ1 > > The OTP-flow (called Solution 1b in the committee) is a mix of OAuth > device-flow and authorization code flow. Since we want to avoid asking > utilities to implement complex authorization interfaces (problem #2 above), > the client asks the utility to send the user_code directly to the user (via > text/phone/email), then the client asks the user for the user_code and > submits it to the utility to get an access token. > > Also, there is an initial step of identifying (but not authenticating) the > user and determining the way in which the OTP code should be sent. If > utilities are given some sort of non-secret user identification (e.g. > address, phone number, account number, etc.), they should be able to send a > user_code to the user that the user can give to the client for > authorization. Hopefully, this can shift most of the complex UI/UX > development cost away from the utility and onto the third party clients. > > Unfortunately, the energy industry can be quite behind on the latest and > greatest OAuth developments, but we're trying to get better :) > > Thanks very much, > Daniel Roesler > daniel@utilityapi.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e732a9057f8582f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To me this looks similar to the devi= ce flow.


See figure 1, my interpretatio= n of what you want to do is to split up step B so that the code goes via an= other channel and then revers the direction of C and D.

=
So maybe you could ride on some of the work done in the device f= low draft.




<= /div>

On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler <daniel=3D40utilityapi.com@dmarc.ietf.= org> wrote:
Howdy,

Ri= faat recommended I post to the mailing list. Specifically, I am looking for= a mentor and feedback on a potential new OAuth flow (currently called OTP-= flow).

Background:
I am a participant in the California Public Ut= ility Commission's Customer Data Access Committee (CPUC CDAC), and we a= re working on improving utility data access to accelerate deployment of mor= e renewable and energy efficiency technologies to fight climate change.
=
However, we are currently struggling with a use-case for which we can&#= 39;t seem to find a good OAuth flow.

Use-case:
Utility customers = want to share their utility data (e.g. historical energy usage) with a clie= nt (e.g. an energy auditor, to perform some energy efficiency analysis).
However, there are two problems that often occur:

1) Most utili= ty customers do not have online accounts or forgot their login information.= This makes typical OAuth user interface complex, since you have to either = create an online account in the flow or do some sort of multi-step password= -reset/verification process.

2) Utilities are not strongly incentivi= zed to optimize complex UI/UX for the customer in the authorization server = interface. In the committee we've gotten to the point where we have to = specify number of clicks, div height requirements, and minimum pageload tim= es for a utility to implement their OAuth flows (and then utilities want to= charge rate payers for the cost of each UI/UX improvement).

So, we = have been brainstorming possible ways around these problems, and we think i= t may require a new type of authorization flow using one-time passcodes (OT= P) instead of redirecting the user to the utility for normal OAuth. Luckily= , even though utility customers may not have an online account at the utili= ty, the utility usually still has (a) a way of uniquely identifying them an= d (b) a way of contacting them (phone, email, etc.).

I'd like to= see if the OAuth working group is an appropriate place to help develop thi= s flow (or if there has already been work done such a flow). I'm happy = to write the initial draft, but I would very much appreciate some mentorshi= p from someone more experienced in the workgroup.

OTP-flow diagram a= nd example:
https://pastebin.com/raw/4Gx8LAQ1

The OTP-flow (called Solut= ion 1b in the committee) is a mix of OAuth device-flow and authorization co= de flow. Since we want to avoid asking utilities to implement complex autho= rization interfaces (problem #2 above), the client asks the utility to send= the user_code directly to the user (via text/phone/email), then the client= asks the user for the user_code and submits it to the utility to get an ac= cess token.

Also, there is an initial step of identifying (but not a= uthenticating) the user and determining the way in which the OTP code shoul= d be sent. If utilities are given some sort of non-secret user identificati= on (e.g. address, phone number, account number, etc.), they should be able = to send a user_code to the user that the user can give to the client for au= thorization. Hopefully, this can shift most of the complex UI/UX developmen= t cost away from the utility and onto the third party clients.

Unfor= tunately, the energy industry can be quite behind on the latest and greates= t OAuth developments, but we're trying to get better :)

Thanks v= ery much,
Daniel Roesler
daniel@utilityapi.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e732a9057f8582f1-- From nobody Tue Jan 15 13:13:29 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D40130F13 for ; Tue, 15 Jan 2019 13:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 a7m2jBt7enBN for ; Tue, 15 Jan 2019 13:13:25 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA696130F14 for ; Tue, 15 Jan 2019 13:13:24 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id i6so3307656oia.6 for ; Tue, 15 Jan 2019 13:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L0E+isUOH9FqN9T2kd2GLfTP30tqM3N0pc6jRsJV+bs=; b=huwP1OO/4XYm32JCqsUhqzETYJmoTsjCCNvull/kN9Ro2YgiOqS+QsAjkTei49R6Wp /bO7+DGE3f0xPXN7s1pbyfR2JQpHEZpUdlAvxmuUoaT1wgpi/RfYDb8wvsHsNl8I741n WMBbbbO5PPgsqVOeqj4y0idsiRVEC5FR41KEFe7P6wRy1KP9xD6Vvx379jPaXdrHbeXz v/BhgXx7doFz/X5brCuu1o6227hJ6m/QWWCoT9R3KkxrCwrBvlZXoIAptML4TN8rvG3V BKFmWsd7/jG0Mvq1qSs47aqnA/5iMmCVKs6QQHxXvY1FfWuXGwdoLObYhAQ/Y3EF9LTC rafA== 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=L0E+isUOH9FqN9T2kd2GLfTP30tqM3N0pc6jRsJV+bs=; b=miRFEDc8TbQ73QWM2SdlXsp7X3OV0sSEqKDJCyaoCfIGwx7ET5n/sr9qLpQv6onBIW pMDwkzdLgNqsO0MWzraW+UjVjut1OI4qAJ9TaFThn08JBNOQFii87E3LQZ91ILis/zU1 9XhQeUEVlsvSmhvg6hMtTYC90pnm+3s7G2VgqSfQanel9GRghzynNrPFufHiAz4SjF0n O9NtvlGPQLq3bDDr7OGkskmT1/3+iA1zwDXT1NK8NQD4hWLgU1bhvw/wmZt+GeKQEctI bkJlnUasgOztVQVtgiEcR7fVUXZZRLMc3IOzYqmnvxwROad40Q8pH4wnpkDCVa+Y8vjq +qUg== X-Gm-Message-State: AJcUukfq8JCsQibDxbY8iIgDuTxCeeTaEVqM60nj6bqw4CKsNKutrhXv 0OZQZW1gxe4s3MR/Q+hnpotzK9/bjtQMRhxXbM72FyCC X-Google-Smtp-Source: ALg8bN5sVoU+9q7WxKQ7cc9ZUnMKMRCHrgOn4eFZDR5W3guvcmtgRwd7W5TXbWU6vLL+gIGTWQk+giu8iRWNH5zLKbE= X-Received: by 2002:aca:fd4a:: with SMTP id b71mr3095071oii.221.1547586803859; Tue, 15 Jan 2019 13:13:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Omer Levi Hevroni Date: Tue, 15 Jan 2019 23:13:11 +0200 Message-ID: To: Samuel Erdtman Cc: Daniel Roesler , "" Content-Type: multipart/alternative; boundary="000000000000b4082d057f85a1d4" Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:13:28 -0000 --000000000000b4082d057f85a1d4 Content-Type: text/plain; charset="UTF-8" Nope, device flow still requires interactive login flow from the user, just on another device. My flow aims for strong device authentication, without any user interaction. My flow has some similarity to oauth client assertion flow - https://tools.ietf.org/html/rfc7523, with modifications for mobile/IoT devices. On Tue, Jan 15, 2019 at 11:05 PM Samuel Erdtman wrote: > To me this looks similar to the device flow. > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > > See figure 1, my interpretation of what you want to do is to split up step > B so that the code goes via another channel and then revers the direction > of C and D. > > So maybe you could ride on some of the work done in the device flow draft. > > > > > > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler 40utilityapi.com@dmarc.ietf.org> wrote: > >> Howdy, >> >> Rifaat recommended I post to the mailing list. Specifically, I am looking >> for a mentor and feedback on a potential new OAuth flow (currently called >> OTP-flow). >> >> Background: >> I am a participant in the California Public Utility Commission's Customer >> Data Access Committee (CPUC CDAC), and we are working on improving utility >> data access to accelerate deployment of more renewable and energy >> efficiency technologies to fight climate change. >> >> However, we are currently struggling with a use-case for which we can't >> seem to find a good OAuth flow. >> >> Use-case: >> Utility customers want to share their utility data (e.g. historical >> energy usage) with a client (e.g. an energy auditor, to perform some energy >> efficiency analysis). >> >> However, there are two problems that often occur: >> >> 1) Most utility customers do not have online accounts or forgot their >> login information. This makes typical OAuth user interface complex, since >> you have to either create an online account in the flow or do some sort of >> multi-step password-reset/verification process. >> >> 2) Utilities are not strongly incentivized to optimize complex UI/UX for >> the customer in the authorization server interface. In the committee we've >> gotten to the point where we have to specify number of clicks, div height >> requirements, and minimum pageload times for a utility to implement their >> OAuth flows (and then utilities want to charge rate payers for the cost of >> each UI/UX improvement). >> >> So, we have been brainstorming possible ways around these problems, and >> we think it may require a new type of authorization flow using one-time >> passcodes (OTP) instead of redirecting the user to the utility for normal >> OAuth. Luckily, even though utility customers may not have an online >> account at the utility, the utility usually still has (a) a way of uniquely >> identifying them and (b) a way of contacting them (phone, email, etc.). >> >> I'd like to see if the OAuth working group is an appropriate place to >> help develop this flow (or if there has already been work done such a >> flow). I'm happy to write the initial draft, but I would very much >> appreciate some mentorship from someone more experienced in the workgroup. >> >> OTP-flow diagram and example: >> https://pastebin.com/raw/4Gx8LAQ1 >> >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth >> device-flow and authorization code flow. Since we want to avoid asking >> utilities to implement complex authorization interfaces (problem #2 above), >> the client asks the utility to send the user_code directly to the user (via >> text/phone/email), then the client asks the user for the user_code and >> submits it to the utility to get an access token. >> >> Also, there is an initial step of identifying (but not authenticating) >> the user and determining the way in which the OTP code should be sent. If >> utilities are given some sort of non-secret user identification (e.g. >> address, phone number, account number, etc.), they should be able to send a >> user_code to the user that the user can give to the client for >> authorization. Hopefully, this can shift most of the complex UI/UX >> development cost away from the utility and onto the third party clients. >> >> Unfortunately, the energy industry can be quite behind on the latest and >> greatest OAuth developments, but we're trying to get better :) >> >> Thanks very much, >> Daniel Roesler >> daniel@utilityapi.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b4082d057f85a1d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nope, device flow still requires interact= ive login flow from the user, just on another device. My flow aims for stro= ng device authentication, without any user interaction. My flow has some si= milarity to oauth=C2=A0client assertion flow -=C2=A0https://tools.ietf.org/html/rfc7523, with modi= fications for mobile/IoT devices.

On Tue, Jan 15, 2019 at 11:05 PM Samuel Erdtman <samuel@erdtman.se> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
To me this looks similar to the device flow.


See figure 1, my interpretation of wh= at you want to do is to split up step B so that the code goes via another c= hannel and then revers the direction of C and D.

<= div>So maybe you could ride on some of the work done in the device flow dra= ft.





On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesl= er <daniel=3D40utilityapi.com@dmarc.ietf.org> wrote:
Howdy,

Rifaat rec= ommended I post to the mailing list. Specifically, I am looking for a mento= r and feedback on a potential new OAuth flow (currently called OTP-flow).
Background:
I am a participant in the California Public Utility Co= mmission's Customer Data Access Committee (CPUC CDAC), and we are worki= ng on improving utility data access to accelerate deployment of more renewa= ble and energy efficiency technologies to fight climate change.

Howe= ver, we are currently struggling with a use-case for which we can't see= m to find a good OAuth flow.

Use-case:
Utility customers want to = share their utility data (e.g. historical energy usage) with a client (e.g.= an energy auditor, to perform some energy efficiency analysis).

How= ever, there are two problems that often occur:

1) Most utility custo= mers do not have online accounts or forgot their login information. This ma= kes typical OAuth user interface complex, since you have to either create a= n online account in the flow or do some sort of multi-step password-reset/v= erification process.

2) Utilities are not strongly incentivized to o= ptimize complex UI/UX for the customer in the authorization server interfac= e. In the committee we've gotten to the point where we have to specify = number of clicks, div height requirements, and minimum pageload times for a= utility to implement their OAuth flows (and then utilities want to charge = rate payers for the cost of each UI/UX improvement).

So, we have bee= n brainstorming possible ways around these problems, and we think it may re= quire a new type of authorization flow using one-time passcodes (OTP) inste= ad of redirecting the user to the utility for normal OAuth. Luckily, even t= hough utility customers may not have an online account at the utility, the = utility usually still has (a) a way of uniquely identifying them and (b) a = way of contacting them (phone, email, etc.).

I'd like to see if = the OAuth working group is an appropriate place to help develop this flow (= or if there has already been work done such a flow). I'm happy to write= the initial draft, but I would very much appreciate some mentorship from s= omeone more experienced in the workgroup.

OTP-flow diagram and examp= le:
http= s://pastebin.com/raw/4Gx8LAQ1

The OTP-flow (called Solution 1b i= n the committee) is a mix of OAuth device-flow and authorization code flow.= Since we want to avoid asking utilities to implement complex authorization= interfaces (problem #2 above), the client asks the utility to send the use= r_code directly to the user (via text/phone/email), then the client asks th= e user for the user_code and submits it to the utility to get an access tok= en.

Also, there is an initial step of identifying (but not authentic= ating) the user and determining the way in which the OTP code should be sen= t. If utilities are given some sort of non-secret user identification (e.g.= address, phone number, account number, etc.), they should be able to send = a user_code to the user that the user can give to the client for authorizat= ion. Hopefully, this can shift most of the complex UI/UX development cost a= way from the utility and onto the third party clients.

Unfortunately= , the energy industry can be quite behind on the latest and greatest OAuth = developments, but we're trying to get better :)

Thanks very much= ,
Daniel Roesler
daniel@utilityapi.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b4082d057f85a1d4-- From nobody Tue Jan 15 13:48:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1FA130F19 for ; Tue, 15 Jan 2019 13:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfl3dgtV0zw7 for ; Tue, 15 Jan 2019 13:48:36 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F47130F18 for ; Tue, 15 Jan 2019 13:48:33 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id g85so7597475ita.3 for ; Tue, 15 Jan 2019 13:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=11Sr8r3ubSwkY6E0Rrn4Nsdsrj3M9aiVp2VyD1fj/ts=; b=TT1kMjrghkgiIQo8Oek4Uoj2pCY6OHzCEzDY1V/8echS8UeOyLeq1BFhR5vvdZZJPp i4JYRkB5fDAGkRhG9inHQYBixKkt+QvCXxv5DVPFcmtuft8daoIDHJdlWKwXgk4Q27n3 Q+TifGdB+e3l9bhoByNSvRKL2Ui/E5Miu0V4NUTdjsupAdmXvQFYdzyuRvA3u6zuHBoi J6TDBYEcA4ux5zz+NLpNhPR+orX8jYyF0qZLI7lE4nIPUboFzPbFbtwN3po8yjO9qFtz flxf9N0HxTitmNaF/xLdS7gr7x3ajgho/B9WxZQAo33Ioohu/GJVYZClpBnaY1Wh4VHp 3ZZw== 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=11Sr8r3ubSwkY6E0Rrn4Nsdsrj3M9aiVp2VyD1fj/ts=; b=KR78wKOXTb+Nl0YRWklKDIULYLl0Ca6gsne0UVVWILnyr86BAhl/02FXgcqbsyX8Nv AJU4fc4z+QG75xdj1FiNiYUSbTxwXnmQ19XMvp0xvVqHxbkcgERFNt3x+qyhrjj+yhz9 ZoQpcMxTDVxLNAdhBdEZ+YfVeZtUtZCMnFJVz9tciKLnHw/Hedf4Mf9hZUJmNHujQN53 aAJrgipIVWf9nWJw5z3L533RylmAwkq28HYUerFvHU7k+d7PP/4K7uqwLer6kP0eg+MB obGx4EorngRxfgNRe4eZtG97LIlBV5KSq18OsXme1Q1xOUSNChWqpzH0IwNf2WWe4WJM U+mw== X-Gm-Message-State: AJcUukdfo7jT7widftCzVHIZFqC2xMse6+zWaxthefKXH6534kQ6Vc3r DLs8cQ4Fd55mR81NdQOkZZG3OGmobZShA0JvO13P4A== X-Google-Smtp-Source: ALg8bN72Bci/sCRtKW2yfqpLCmBB4rjYDCGwasGAtemkpl2gE2rkjucuqe+zEcpuD7mey/9vGU5hNO7rNiE19aYI9TM= X-Received: by 2002:a02:1217:: with SMTP id i23mr3522771jad.53.1547588912514; Tue, 15 Jan 2019 13:48:32 -0800 (PST) MIME-Version: 1.0 References: <154068186141.5657.5708171860868071302.idtracker@ietfa.amsl.com> In-Reply-To: <154068186141.5657.5708171860868071302.idtracker@ietfa.amsl.com> From: William Denniss Date: Tue, 15 Jan 2019 13:48:21 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000642050057f861fb0" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:48:38 -0000 --000000000000642050057f861fb0 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-device-flow-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss points. I would still prefer to see a > normative requirement for explicit user approval (as opposed to just the > descriptive statement that the chance to approve/deny should be offered), > but I can understand the sentiment that such a requirement on the UI is > not a matter for interoperability and could not be reliably enforced > anyway. > Thank you again for your review. The UI requirements not being a matter for interoperability is indeed why there is no normative text for that, and we're following the approach taken by other IETF OAuth specifications which also leave this up to the implementors. I understand your concerns here, but I hope that the current non-normative guidance is enough. > > Original COMMENT section preserved below. > > Please use the RFC 8174 boilerplate instead of the RFC 2119 one. > > Section 3.2 > > The example expires in 30 minutes? That seems longer than needed; wouldn't > 5 minutes do? > > Section 3.3 > > I agree with directorate reviewer that the MUST NOT requirement for > displaying the device_code should justify that requirement by discussing > the consequences of exposure. > > Section 3.5 > > authorization_pending > The authorization request is still pending as the end-user hasn't > yet completed the user interaction steps (Section 3.3). The > client should repeat the Access Token Request to the token > endpoint. > > I feel like we want to mention the 'interval' here or some other discussion > of an inter-request delay. > > Also, please clarify "reasonable default polling interval", per multiple > directorate reviews. > > Section 5.2 > > Please clarify the entities involved in "the backchannel flow" that can be > MITM'd. > > Section 5.6 > > The "short-range" part of a "short-range wireless signal" partially depends > on how big the receiver's antenna is. So perhaps we should be careful > about indicating that this has more security value than it does. > > Section 6.1 > > I'm not sure I understand the usage of "case-insensitive", here -- how > would the user have an expectation of case-insensitivity? Perhaps it is > better to just say "majuscule" or "upper case" or whatever. > > > --000000000000642050057f861fb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Benjamin Kaduk has entered the follo= wing ballot position for
draft-ietf-oauth-device-flow-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-oauth-device-flow/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points.=C2=A0 I would still prefer to s= ee a
normative requirement for explicit user approval (as opposed to=C2=A0 just = the
descriptive statement that the chance to approve/deny should be offered), but I can understand the sentiment that such a requirement=C2=A0 on=C2=A0 t= he UI is
not a matter for interoperability and could not be reliably enforced anyway= .

Thank you again for your review.

The UI requirements not being a matter for interoperab= ility is indeed why there is no normative text for that, and we're foll= owing the approach taken by other IETF OAuth specifications which also leav= e this up to the implementors. I understand your concerns here, but I hope = that the current non-normative guidance is enough.

=C2=A0

Original COMMENT=C2=A0 section preserved below.

Please use the RFC 8174 boilerplate instead of the RFC 2119 one.

Section 3.2

The example expires in 30 minutes?=C2=A0 That seems longer than needed; wou= ldn't
5 minutes do?

Section 3.3

I agree with directorate reviewer that the MUST NOT requirement for
displaying the device_code should justify that requirement by discussing the consequences of exposure.

Section 3.5

=C2=A0 =C2=A0authorization_pending
=C2=A0 =C2=A0 =C2=A0 The authorization request is still pending as the end-= user hasn't
=C2=A0 =C2=A0 =C2=A0 yet completed the user interaction steps (Section 3.3)= .=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 client should repeat the Access Token Request to the t= oken
=C2=A0 =C2=A0 =C2=A0 endpoint.

I feel like we want to mention the 'interval' here or some other di= scussion
of an inter-request delay.

Also, please clarify "reasonable default polling interval", per m= ultiple
directorate reviews.

Section 5.2

Please clarify the entities involved in "the backchannel flow" th= at can be
MITM'd.

Section 5.6

The "short-range" part of a "short-range wireless signal&quo= t; partially depends
on how big the receiver's antenna is.=C2=A0 So perhaps we should be car= eful
about indicating that this has more security value than it does.

Section 6.1

I'm not sure I understand the usage of "case-insensitive", he= re -- how
would the user have an expectation of case-insensitivity?=C2=A0 Perhaps it = is
better to just say "majuscule" or "upper case" or whate= ver.


--000000000000642050057f861fb0-- From nobody Tue Jan 15 15:38:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA011292F1 for ; Tue, 15 Jan 2019 15:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyZvdRFGQENI for ; Tue, 15 Jan 2019 15:38:46 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 02FDD12867A for ; Tue, 15 Jan 2019 15:38:45 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0FNciTk132170; Tue, 15 Jan 2019 23:38:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : cc : to; s=corp-2018-07-02; bh=l7Y/hbS6JocUYj2JwYwyc4GzQfF56+L+zaNTGAISykc=; b=Lg2NTwwF/GBFduC02DTqJEdfTwxEZ9zx0+aHP4wH8q+chiWFtTOsUgo9JBmwCTgdCUN2 XV4biMDPcGpMg5xYfelT5QFrmP/AJI7nbvSYGfbHq6qKdF5KxvgI1KyiKzATbm7RB3YV lTfdft+FC8eEnNFWK4NDZdi5y239B7BMyzt/2DkYwbVbJ4qqFMOCuydSkBW8bflgvjur R4cSUdtTsJtJ3Le8mjUMd4JKWzRQkls9tTwS504lvgAFYbpqCr0JTd1LzL3bc7GSxrVa q11q4xaN8v+igWJQ8snsk34MT8aXpDk9VPLviI6J7L/zMamm1Tg+kv+/F0qBn9Mq39AM +Q== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2pybjs6wjv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Jan 2019 23:38:44 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0FNcixw010478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Jan 2019 23:38:44 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0FNchZo028277; Tue, 15 Jan 2019 23:38:44 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jan 2019 15:38:43 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D5AF6F17-2CB1-4767-A05F-7D80639E9E94" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <0BF3B521-FD75-456F-8D67-48F1B7FAE43A@oracle.com> Date: Tue, 15 Jan 2019 15:38:42 -0800 Cc: oauth To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9137 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=4 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=854 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901150188 Archived-At: Subject: [OAUTH-WG] comment on security topics-11 - refresh authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 23:38:48 -0000 --Apple-Mail=_D5AF6F17-2CB1-4767-A05F-7D80639E9E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have had a couple reviewers comment whether this means client = authentication is optional in Sec 3.12 for token refresh: > * authentication of this client_id during token refresh, if > possible, and Do we not mean authentication of the client or some equivalent (e.g. = looking at browser cookies). Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_D5AF6F17-2CB1-4767-A05F-7D80639E9E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have had a couple reviewers comment whether this means client = authentication is optional in Sec 3.12 for token refresh:

   *  authentication of this =
client_id during token refresh, if
      possible, and

Do we not mean authentication of the = client or some equivalent (e.g. looking at browser cookies).

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_D5AF6F17-2CB1-4767-A05F-7D80639E9E94-- From nobody Tue Jan 15 17:24:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF40130F4D for ; Tue, 15 Jan 2019 17:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlTW4dajSksh for ; Tue, 15 Jan 2019 17:24:47 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29197130F80 for ; Tue, 15 Jan 2019 17:24:47 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id l12so5319444qtf.8 for ; Tue, 15 Jan 2019 17:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l5TqLTLP1Vu2Yvlp/MrbacipTIsqpPqNUM7I+CFDO54=; b=rlJTUzb/FmXE+9J89kbmQUhSQmWEaIzlpmNEBo3uzLsHgnH9P/bJx50JgSH1gVkN+C Fjx4FDryAoMF+/fIWaVbtTjm2wN4HlGrS4+KdL9nettiZRMJel5o8iEzoF0OZ8GeRLaE Mi5+IMn+7B9jlXF8tctYotHzPU/BfCghemBk4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l5TqLTLP1Vu2Yvlp/MrbacipTIsqpPqNUM7I+CFDO54=; b=tJR1CDkPFgh6BaDaNPJ31lm1D58cy7KhvBGDBSLTN/kxSTNaz3nLsesaemTzzORrNx 0luWsu5z7ttZ4j6/qiE1rAFk6/EzT5EJiggqGpasghuEV+8hfx15u1FXiydQQSs0ChNY kmY5S33fREFMfUSrgmFb8vcPDbEPyHahCfFlxesNU5WenFSqlTJw6qRkP4XbyrxCVmBi J0mpgkcTytSG/LEw9YGA0eSDByeGBblxKQanLUjkL5HImLl1xiUxeN5B6W4C3Bt6hJYs ijuyiMq5SAYRVXLgYxnsOznivtMN57B8vqlorPsSENyq2FkF9Bz8gJtLAkBF2zYXOl5s +unw== X-Gm-Message-State: AJcUukfwbDmuWiPHfM/fBnR2t3dnYkkJyEAsqgXgrwxXzemHkg3xH+5o T+UrzIq/ESD/e1OtFoBrffBUKUBHwLYgwonAykmknTIlyro= X-Google-Smtp-Source: ALg8bN5Q66Ov/C+ztvRiXv8mtwlDc7LWLHyAMxUsQ02yq8csTHX/oHyYvqfh2DQJw3dJzKqBRyxzWhIADJvmxKaoxRI= X-Received: by 2002:aed:39a1:: with SMTP id m30mr5056226qte.354.1547601886258; Tue, 15 Jan 2019 17:24:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Roesler Date: Tue, 15 Jan 2019 19:24:09 -0600 Message-ID: To: Samuel Erdtman Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 01:24:50 -0000 Thanks for the reply! Yes, that is essentially what we would like to do. We really like the "here's a code to authorize" part of device-flow, but we are trying to not require the authorization server build a user interface for the user to authenticate themselves and enter the code (because we've found it is very costly for utilities to build these interfaces). We'd much rather the user get a code directly that they can input into the client for authorization, hence reversing steps C & D in device-flow (and the client now is responsible for developing the costly user interface). However, in order to reverse C & D, steps A & B needs to provide some sort of user identifier and delivery method (so that the authorization server knows to who this authorization request is directed and how to send the user_code). In order to figure that out, we added a identification and delivery negotiation step in front of step A & B that lets the client and authorization server negotiate those things before kicking off the OTP code sending (e.g. reverse steps C & D). I'm not really sure how we'd go about building off of device-flow if we're reversing much of the process, changing what data is sent in each step, and adding a step at the start. OTP-flow is less of a "device" focused authorization and more of an on-the-go focused authorization. Our main example we sanity check this for is the "Hardware Store Kiosk" sto= ry: 1. Heather Homeowner walks into a hardware store. 2. There's a kiosk by the lighting section offering free energy audits. 3. It says it needs to pull her energy usage data to perform the energy aud= it. 4. She doesn't remember (or have) her utility login, so she enters her address instead. 6. She is asked if she'd like to receive a text or email with a verification code. 7. She selects she wants to receive a text. 8. She receives a text with a code and message about the scope of the authorization. 9. She enters the code on the kiosk. 10. The kiosk pulls her energy usage data and generates an energy audit. This story allows users who only know their address or some other basic identifier (phone number, email, etc.) to be able to get instant energy audits for lighting upgrades, solar quotes, energy star appliances, EV charging costs, etc. Unfortunately, most people only think about their energy use when they are out and about and encounter energy products (e.g. in a hardware store), so we're trying to make it easy for them to get an energy audit with minimal information input or device requirements. Thanks again, Daniel Roesler daniel@utilityapi.com On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman wrote: > > To me this looks similar to the device flow. > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > > See figure 1, my interpretation of what you want to do is to split up ste= p B so that the code goes via another channel and then revers the direction= of C and D. > > So maybe you could ride on some of the work done in the device flow draft= . > > > > > > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler wrote: >> >> Howdy, >> >> Rifaat recommended I post to the mailing list. Specifically, I am lookin= g for a mentor and feedback on a potential new OAuth flow (currently called= OTP-flow). >> >> Background: >> I am a participant in the California Public Utility Commission's Custome= r Data Access Committee (CPUC CDAC), and we are working on improving utilit= y data access to accelerate deployment of more renewable and energy efficie= ncy technologies to fight climate change. >> >> However, we are currently struggling with a use-case for which we can't = seem to find a good OAuth flow. >> >> Use-case: >> Utility customers want to share their utility data (e.g. historical ener= gy usage) with a client (e.g. an energy auditor, to perform some energy eff= iciency analysis). >> >> However, there are two problems that often occur: >> >> 1) Most utility customers do not have online accounts or forgot their lo= gin information. This makes typical OAuth user interface complex, since you= have to either create an online account in the flow or do some sort of mul= ti-step password-reset/verification process. >> >> 2) Utilities are not strongly incentivized to optimize complex UI/UX for= the customer in the authorization server interface. In the committee we've= gotten to the point where we have to specify number of clicks, div height = requirements, and minimum pageload times for a utility to implement their O= Auth flows (and then utilities want to charge rate payers for the cost of e= ach UI/UX improvement). >> >> So, we have been brainstorming possible ways around these problems, and = we think it may require a new type of authorization flow using one-time pas= scodes (OTP) instead of redirecting the user to the utility for normal OAut= h. Luckily, even though utility customers may not have an online account at= the utility, the utility usually still has (a) a way of uniquely identifyi= ng them and (b) a way of contacting them (phone, email, etc.). >> >> I'd like to see if the OAuth working group is an appropriate place to he= lp develop this flow (or if there has already been work done such a flow). = I'm happy to write the initial draft, but I would very much appreciate some= mentorship from someone more experienced in the workgroup. >> >> OTP-flow diagram and example: >> https://pastebin.com/raw/4Gx8LAQ1 >> >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth dev= ice-flow and authorization code flow. Since we want to avoid asking utiliti= es to implement complex authorization interfaces (problem #2 above), the cl= ient asks the utility to send the user_code directly to the user (via text/= phone/email), then the client asks the user for the user_code and submits i= t to the utility to get an access token. >> >> Also, there is an initial step of identifying (but not authenticating) t= he user and determining the way in which the OTP code should be sent. If ut= ilities are given some sort of non-secret user identification (e.g. address= , phone number, account number, etc.), they should be able to send a user_c= ode to the user that the user can give to the client for authorization. Hop= efully, this can shift most of the complex UI/UX development cost away from= the utility and onto the third party clients. >> >> Unfortunately, the energy industry can be quite behind on the latest and= greatest OAuth developments, but we're trying to get better :) >> >> Thanks very much, >> Daniel Roesler >> daniel@utilityapi.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 15 19:01:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06072131031 for ; Tue, 15 Jan 2019 19:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 n7U3af4LrZyp for ; Tue, 15 Jan 2019 19:01:43 -0800 (PST) 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 DC873131027 for ; Tue, 15 Jan 2019 19:01:42 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id f18so4821218otl.11 for ; Tue, 15 Jan 2019 19:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2T2fBPwyyRwg+61aJByQIDyCBgmC1C0usZK27zp0zQM=; b=TXo3pTh264X2xX5qkmV9x210ucjRp+mkH4FAjc6G3ouvutxlXm3hH4dPqzYw4e8Qy6 AEi/JpzeXPhH7vymNqME2zfpOCWA0uWtQ1c/Yfxr6PRKqJnQBNnMnCgueb2sivRDeKfQ Jgci+o7/LzwIwlpeuP8PjpV7pvwBKYDxp2qY+2EoodlsbSRrhq2PZ2K8hY3sLietXdJV D6SNCZFkOyutRnyymPmRcMEok8wsniR6+D4n7Xfou/3gM4yuQLiN6XOWouqiZutk1PWu gzv/AoBHgUml0T/h3YUWiG/8xaZWOy4CckJlucOXKqZ7F84XuDcCVABLMJw3wSrK/T6p SQLA== 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=2T2fBPwyyRwg+61aJByQIDyCBgmC1C0usZK27zp0zQM=; b=buuPl0+Ml5Uf1ycbATuYAoMxqLTVnC+Ytr0aCr6KMYCH+VHjR+mDGpR/FXlZOUmnzW hqRNLzpt6nA2e2HuAgDgBzLxXogWLWchNYV8HbdgfmbvKrQ6L0YlmjBRvlICEVkDR5Qp cwz6g2Iho4L/O9632t9cIMT3nznTIMiTFQ0WxAvRf48sGcamVwRmnKOvwGLSXM8+uQhI HDyHWBfjm1cgA9Awaqy1SLQN7zUViGJY02+N8wX1AaV0Nvf2HwvGZ9pihwe/O0ewBwil 008UpfOXJ2/+z37j2899nWxQp4o+IAKxnOvXfIw+u5osrerCSDh8eWM0N4qutHzvT5cf bGsg== X-Gm-Message-State: AJcUukfONeSr7TnJ28eWPL5bn6dg8uSRVG9LBdmWCH8w5wYLySmp1eva rkul7z224Hy5VbYdV8oyrzmvaHsJQi/3s1Cik24= X-Google-Smtp-Source: ALg8bN7s+cBxjV+zN6V46JUnfKEcBpdXm4e2bIDfJRJBtajwFBkRLQY6hfcCFJKfaD84JMfPuFuTjqF6Igic+44TmRg= X-Received: by 2002:a9d:968:: with SMTP id 95mr4375958otp.219.1547607701814; Tue, 15 Jan 2019 19:01:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: nov matake Date: Wed, 16 Jan 2019 12:01:30 +0900 Message-ID: To: Daniel Roesler Cc: Samuel Erdtman , "" Content-Type: multipart/alternative; boundary="000000000000518560057f8a7f31" Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 03:01:46 -0000 --000000000000518560057f8a7f31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your use case seems fit CIBA which is being defined in OpenID Foundation. The section6 of CIBA spec will describe how your use case fit it. https://openid.net/specs/openid-client-initiated-backchannel-authentication= -core-1_0.html#rfc.section.6 CIBA is an extension of OpenID Connect, not OAuth, but since OpenID Connect itself is an extension of OAuth2, you should be able to use it in OAuth context too. Cheers, nov 2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler : > Thanks for the reply! > > Yes, that is essentially what we would like to do. We really like the > "here's a code to authorize" part of device-flow, but we are trying to > not require the authorization server build a user interface for the > user to authenticate themselves and enter the code (because we've > found it is very costly for utilities to build these interfaces). We'd > much rather the user get a code directly that they can input into the > client for authorization, hence reversing steps C & D in device-flow > (and the client now is responsible for developing the costly user > interface). > > However, in order to reverse C & D, steps A & B needs to provide some > sort of user identifier and delivery method (so that the authorization > server knows to who this authorization request is directed and how to > send the user_code). In order to figure that out, we added a > identification and delivery negotiation step in front of step A & B > that lets the client and authorization server negotiate those things > before kicking off the OTP code sending (e.g. reverse steps C & D). > > I'm not really sure how we'd go about building off of device-flow if > we're reversing much of the process, changing what data is sent in > each step, and adding a step at the start. OTP-flow is less of a > "device" focused authorization and more of an on-the-go focused > authorization. > > Our main example we sanity check this for is the "Hardware Store Kiosk" > story: > 1. Heather Homeowner walks into a hardware store. > 2. There's a kiosk by the lighting section offering free energy audits. > 3. It says it needs to pull her energy usage data to perform the energy > audit. > 4. She doesn't remember (or have) her utility login, so she enters her > address instead. > 6. She is asked if she'd like to receive a text or email with a > verification code. > 7. She selects she wants to receive a text. > 8. She receives a text with a code and message about the scope of the > authorization. > 9. She enters the code on the kiosk. > 10. The kiosk pulls her energy usage data and generates an energy audit. > > This story allows users who only know their address or some other > basic identifier (phone number, email, etc.) to be able to get instant > energy audits for lighting upgrades, solar quotes, energy star > appliances, EV charging costs, etc. Unfortunately, most people only > think about their energy use when they are out and about and encounter > energy products (e.g. in a hardware store), so we're trying to make it > easy for them to get an energy audit with minimal information input or > device requirements. > > Thanks again, > Daniel Roesler > daniel@utilityapi.com > > On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman wrote: > > > > To me this looks similar to the device flow. > > > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > > > > See figure 1, my interpretation of what you want to do is to split up > step B so that the code goes via another channel and then revers the > direction of C and D. > > > > So maybe you could ride on some of the work done in the device flow > draft. > > > > > > > > > > > > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler 40utilityapi.com@dmarc.ietf.org> wrote: > >> > >> Howdy, > >> > >> Rifaat recommended I post to the mailing list. Specifically, I am > looking for a mentor and feedback on a potential new OAuth flow (currentl= y > called OTP-flow). > >> > >> Background: > >> I am a participant in the California Public Utility Commission's > Customer Data Access Committee (CPUC CDAC), and we are working on improvi= ng > utility data access to accelerate deployment of more renewable and energy > efficiency technologies to fight climate change. > >> > >> However, we are currently struggling with a use-case for which we can'= t > seem to find a good OAuth flow. > >> > >> Use-case: > >> Utility customers want to share their utility data (e.g. historical > energy usage) with a client (e.g. an energy auditor, to perform some ener= gy > efficiency analysis). > >> > >> However, there are two problems that often occur: > >> > >> 1) Most utility customers do not have online accounts or forgot their > login information. This makes typical OAuth user interface complex, since > you have to either create an online account in the flow or do some sort o= f > multi-step password-reset/verification process. > >> > >> 2) Utilities are not strongly incentivized to optimize complex UI/UX > for the customer in the authorization server interface. In the committee > we've gotten to the point where we have to specify number of clicks, div > height requirements, and minimum pageload times for a utility to implemen= t > their OAuth flows (and then utilities want to charge rate payers for the > cost of each UI/UX improvement). > >> > >> So, we have been brainstorming possible ways around these problems, an= d > we think it may require a new type of authorization flow using one-time > passcodes (OTP) instead of redirecting the user to the utility for normal > OAuth. Luckily, even though utility customers may not have an online > account at the utility, the utility usually still has (a) a way of unique= ly > identifying them and (b) a way of contacting them (phone, email, etc.). > >> > >> I'd like to see if the OAuth working group is an appropriate place to > help develop this flow (or if there has already been work done such a > flow). I'm happy to write the initial draft, but I would very much > appreciate some mentorship from someone more experienced in the workgroup= . > >> > >> OTP-flow diagram and example: > >> https://pastebin.com/raw/4Gx8LAQ1 > >> > >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth > device-flow and authorization code flow. Since we want to avoid asking > utilities to implement complex authorization interfaces (problem #2 above= ), > the client asks the utility to send the user_code directly to the user (v= ia > text/phone/email), then the client asks the user for the user_code and > submits it to the utility to get an access token. > >> > >> Also, there is an initial step of identifying (but not authenticating) > the user and determining the way in which the OTP code should be sent. If > utilities are given some sort of non-secret user identification (e.g. > address, phone number, account number, etc.), they should be able to send= a > user_code to the user that the user can give to the client for > authorization. Hopefully, this can shift most of the complex UI/UX > development cost away from the utility and onto the third party clients. > >> > >> Unfortunately, the energy industry can be quite behind on the latest > and greatest OAuth developments, but we're trying to get better :) > >> > >> Thanks very much, > >> Daniel Roesler > >> daniel@utilityapi.com > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 nov matake --000000000000518560057f8a7f31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your use case seems fit CIBA which is being defi= ned in OpenID Foundation.

The sect= ion6 of CIBA spec will describe how your use case fit it.

CIBA is an extension of OpenID Connect, not OAuth, but sin= ce OpenID Connect itself is an extension of OAuth2, you should be able to u= se it in OAuth context too.

Cheers,

=
nov

2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:2= 5 Daniel Roesler <daniel=3D40utilityapi.com@dmarc.ietf.org>:
= Thanks for the reply!

Yes, that is essentially what we would like to do. We really like the
"here's a code to authorize" part of device-flow, but we are = trying to
not require the authorization server build a user interface for the
user to authenticate themselves and enter the code (because we've
found it is very costly for utilities to build these interfaces). We'd<= br> much rather the user get a code directly that they can input into the
client for authorization, hence reversing steps C & D in device-flow (and the client now is responsible for developing the costly user
interface).

However, in order to reverse C & D, steps A & B needs to provide so= me
sort of user identifier and delivery method (so that the authorization
server knows to who this authorization request is directed and how to
send the user_code). In order to figure that out, we added a
identification and delivery negotiation step in front of step A & B
that lets the client and authorization server negotiate those things
before kicking off the OTP code sending (e.g. reverse steps C & D).

I'm not really sure how we'd go about building off of device-flow i= f
we're reversing much of the process, changing what data is sent in
each step, and adding a step at the start. OTP-flow is less of a
"device" focused authorization and more of an on-the-go focused authorization.

Our main example we sanity check this for is the "Hardware Store Kiosk= " story:
1. Heather Homeowner walks into a hardware store.
2. There's a kiosk by the lighting section offering free energy audits.=
3. It says it needs to pull her energy usage data to perform the energy aud= it.
4. She doesn't remember (or have) her utility login, so she enters her<= br> address instead.
6. She is asked if she'd like to receive a text or email with a
verification code.
7. She selects she wants to receive a text.
8. She receives a text with a code and message about the scope of the
authorization.
9. She enters the code on the kiosk.
10. The kiosk pulls her energy usage data and generates an energy audit.
This story allows users who only know their address or some other
basic identifier (phone number, email, etc.) to be able to get instant
energy audits for lighting upgrades, solar quotes, energy star
appliances, EV charging costs, etc. Unfortunately, most people only
think about their energy use when they are out and about and encounter
energy products (e.g. in a hardware store), so we're trying to make it<= br> easy for them to get an energy audit with minimal information input or
device requirements.

Thanks again,
Daniel Roesler
daniel@utilityap= i.com

On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman <samuel@erdtman.se> wrote:
>
> To me this looks similar to the device flow.
>
> https://tools.ietf.org/html/draft-ie= tf-oauth-device-flow-13
>
> See figure 1, my interpretation of what you want to do is to split up = step B so that the code goes via another channel and then revers the direct= ion of C and D.
>
> So maybe you could ride on some of the work done in the device flow dr= aft.
>
>
>
>
>
> On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler <daniel=3D40utilityapi.com= @dmarc.ietf.org> wrote:
>>
>> Howdy,
>>
>> Rifaat recommended I post to the mailing list. Specifically, I am = looking for a mentor and feedback on a potential new OAuth flow (currently = called OTP-flow).
>>
>> Background:
>> I am a participant in the California Public Utility Commission'= ;s Customer Data Access Committee (CPUC CDAC), and we are working on improv= ing utility data access to accelerate deployment of more renewable and ener= gy efficiency technologies to fight climate change.
>>
>> However, we are currently struggling with a use-case for which we = can't seem to find a good OAuth flow.
>>
>> Use-case:
>> Utility customers want to share their utility data (e.g. historica= l energy usage) with a client (e.g. an energy auditor, to perform some ener= gy efficiency analysis).
>>
>> However, there are two problems that often occur:
>>
>> 1) Most utility customers do not have online accounts or forgot th= eir login information. This makes typical OAuth user interface complex, sin= ce you have to either create an online account in the flow or do some sort = of multi-step password-reset/verification process.
>>
>> 2) Utilities are not strongly incentivized to optimize complex UI/= UX for the customer in the authorization server interface. In the committee= we've gotten to the point where we have to specify number of clicks, d= iv height requirements, and minimum pageload times for a utility to impleme= nt their OAuth flows (and then utilities want to charge rate payers for the= cost of each UI/UX improvement).
>>
>> So, we have been brainstorming possible ways around these problems= , and we think it may require a new type of authorization flow using one-ti= me passcodes (OTP) instead of redirecting the user to the utility for norma= l OAuth. Luckily, even though utility customers may not have an online acco= unt at the utility, the utility usually still has (a) a way of uniquely ide= ntifying them and (b) a way of contacting them (phone, email, etc.).
>>
>> I'd like to see if the OAuth working group is an appropriate p= lace to help develop this flow (or if there has already been work done such= a flow). I'm happy to write the initial draft, but I would very much a= ppreciate some mentorship from someone more experienced in the workgroup. >>
>> OTP-flow diagram and example:
>> https://pastebin.com/raw/4Gx8LAQ1
>>
>> The OTP-flow (called Solution 1b in the committee) is a mix of OAu= th device-flow and authorization code flow. Since we want to avoid asking u= tilities to implement complex authorization interfaces (problem #2 above), = the client asks the utility to send the user_code directly to the user (via= text/phone/email), then the client asks the user for the user_code and sub= mits it to the utility to get an access token.
>>
>> Also, there is an initial step of identifying (but not authenticat= ing) the user and determining the way in which the OTP code should be sent.= If utilities are given some sort of non-secret user identification (e.g. a= ddress, phone number, account number, etc.), they should be able to send a = user_code to the user that the user can give to the client for authorizatio= n. Hopefully, this can shift most of the complex UI/UX development cost awa= y from the utility and onto the third party clients.
>>
>> Unfortunately, the energy industry can be quite behind on the late= st and greatest OAuth developments, but we're trying to get better :) >>
>> Thanks very much,
>> Daniel Roesler
>> daniel@= utilityapi.com
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
nov matake
--000000000000518560057f8a7f31-- From nobody Tue Jan 15 21:01:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814B91310DA for ; Tue, 15 Jan 2019 21:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 yDDJacf3l3CV for ; Tue, 15 Jan 2019 21:01:29 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDAD130D7A for ; Tue, 15 Jan 2019 21:01:28 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id c19-v6so4325151lja.5 for ; Tue, 15 Jan 2019 21:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DsYz5ACaTEaW2DWddw20G+tCXODmhNwHz2GK/amvt4s=; b=cytOzsbCsdBO4doBRUQnUTK8avV5xMVtBgBlV3UWCUYcpIC5QBHqy0O6BSFL9bOuON 7F0Lq7tw59OO91RavdUEUDMAo1O1Fl66iD1OdPE9saT7qBAtSjq2iE2bwpeMw7/lnuo5 iPAVWONOAru5HWaZrpNyXdjQCBTbRC7zJZPh4= 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=DsYz5ACaTEaW2DWddw20G+tCXODmhNwHz2GK/amvt4s=; b=FwHn5msTsUHg14gB9XRF3Cq8wWXoaUTfh7tOv6Xk9RT5lbctXWI12WsmM55jwG3fbi nOnzd0vlYt2KcAYDwIwCab2uulwvtIObnsIIyNZQbIMQSFq7i+BUKTzK0ia/tWr6u84W YjBiBkqnpK2rM6RUBI3ONMBJ4H1kRuBnpc2qzQ3/r8V69d2OFy5Hr3waKwOwWt2P5kAX gx9zNhBZFa+7sYFQjsUNsIWmfCvYqrtfLqN3SMe59cU0KqGt3aHli/hFH0mUx6erV/es iySjRxpFfrqZo3CTE9bt/qKl2td32DqqtC0mVdj2wPStO1TKzKPKA2vPgwpigoJopNG4 085Q== X-Gm-Message-State: AJcUukf5VwP7zUn2aGt2vsUp2NoETkCox7kPWRPW5skV7AdUUDSQHPvq wGJLe5zsJBLMwW00kxuTFdSoWFSc3+142HgrCY71Ng== X-Google-Smtp-Source: ALg8bN4WVDnDDa0FawCk6bcbRvfpHkavLs01HA6zSgekHppYSY8KxYTlL1p91T6SEJMkDZmo5uqwQHlIha+S2GPd4zk= X-Received: by 2002:a2e:a0d3:: with SMTP id f19-v6mr5147370ljm.48.1547614886246; Tue, 15 Jan 2019 21:01:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Wed, 16 Jan 2019 06:01:14 +0100 Message-ID: To: nov matake Cc: Daniel Roesler , "" Content-Type: multipart/alternative; boundary="0000000000008b562a057f8c2be6" Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 05:01:33 -0000 --0000000000008b562a057f8c2be6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel This is an interesting use-case. As mentioned by nov, CIBA could potentially solve this problem. The difference would be step 9 in your user story. Instead of the user entering the code at the kiosk, they would click on a link in the email (or reply the text) to confirm that they grant access. This wouldn't require building a costly user interface, but rather the utilities would need to provide a single end-user facing route to deal with confirmations via email. >From a user experience perspective, it would be nicer as the user wouldn't have to enter any codes. They would simply enter their address (or some other identifier) at the kiosk, wait for an email or text, click the email or reply the text, and access would be granted. It is also flexible to support utilities that wanted to gain a higher lever of assurance. Such utilities could ask the user for additional knowledge factors without changing the flow. Dave On Wed, 16 Jan 2019 at 04:02, nov matake wrote: > Your use case seems fit CIBA which is being defined in OpenID Foundation. > > The section6 of CIBA spec will describe how your use case fit it. > > https://openid.net/specs/openid-client-initiated-backchannel-authenticati= on-core-1_0.html#rfc.section.6 > > CIBA is an extension of OpenID Connect, not OAuth, but since OpenID > Connect itself is an extension of OAuth2, you should be able to use it in > OAuth context too. > > Cheers, > > nov > > 2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler <40utilityapi.com@dmarc.ietf..org>>: > >> Thanks for the reply! >> >> Yes, that is essentially what we would like to do. We really like the >> "here's a code to authorize" part of device-flow, but we are trying to >> not require the authorization server build a user interface for the >> user to authenticate themselves and enter the code (because we've >> found it is very costly for utilities to build these interfaces). We'd >> much rather the user get a code directly that they can input into the >> client for authorization, hence reversing steps C & D in device-flow >> (and the client now is responsible for developing the costly user >> interface). >> >> However, in order to reverse C & D, steps A & B needs to provide some >> sort of user identifier and delivery method (so that the authorization >> server knows to who this authorization request is directed and how to >> send the user_code). In order to figure that out, we added a >> identification and delivery negotiation step in front of step A & B >> that lets the client and authorization server negotiate those things >> before kicking off the OTP code sending (e.g. reverse steps C & D). >> >> I'm not really sure how we'd go about building off of device-flow if >> we're reversing much of the process, changing what data is sent in >> each step, and adding a step at the start. OTP-flow is less of a >> "device" focused authorization and more of an on-the-go focused >> authorization. >> >> Our main example we sanity check this for is the "Hardware Store Kiosk" >> story: >> 1. Heather Homeowner walks into a hardware store. >> 2. There's a kiosk by the lighting section offering free energy audits. >> 3. It says it needs to pull her energy usage data to perform the energy >> audit. >> 4. She doesn't remember (or have) her utility login, so she enters her >> address instead. >> 6. She is asked if she'd like to receive a text or email with a >> verification code. >> 7. She selects she wants to receive a text. >> 8. She receives a text with a code and message about the scope of the >> authorization. >> 9. She enters the code on the kiosk. >> 10. The kiosk pulls her energy usage data and generates an energy audit. >> >> This story allows users who only know their address or some other >> basic identifier (phone number, email, etc.) to be able to get instant >> energy audits for lighting upgrades, solar quotes, energy star >> appliances, EV charging costs, etc. Unfortunately, most people only >> think about their energy use when they are out and about and encounter >> energy products (e.g. in a hardware store), so we're trying to make it >> easy for them to get an energy audit with minimal information input or >> device requirements. >> >> Thanks again, >> Daniel Roesler >> daniel@utilityapi.com >> >> On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman wrote= : >> > >> > To me this looks similar to the device flow. >> > >> > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 >> > >> > See figure 1, my interpretation of what you want to do is to split up >> step B so that the code goes via another channel and then revers the >> direction of C and D. >> > >> > So maybe you could ride on some of the work done in the device flow >> draft. >> > >> > >> > >> > >> > >> > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler > 40utilityapi.com@dmarc.ietf.org> wrote: >> >> >> >> Howdy, >> >> >> >> Rifaat recommended I post to the mailing list. Specifically, I am >> looking for a mentor and feedback on a potential new OAuth flow (current= ly >> called OTP-flow). >> >> >> >> Background: >> >> I am a participant in the California Public Utility Commission's >> Customer Data Access Committee (CPUC CDAC), and we are working on improv= ing >> utility data access to accelerate deployment of more renewable and energ= y >> efficiency technologies to fight climate change. >> >> >> >> However, we are currently struggling with a use-case for which we >> can't seem to find a good OAuth flow. >> >> >> >> Use-case: >> >> Utility customers want to share their utility data (e.g. historical >> energy usage) with a client (e.g. an energy auditor, to perform some ene= rgy >> efficiency analysis). >> >> >> >> However, there are two problems that often occur: >> >> >> >> 1) Most utility customers do not have online accounts or forgot their >> login information. This makes typical OAuth user interface complex, sinc= e >> you have to either create an online account in the flow or do some sort = of >> multi-step password-reset/verification process. >> >> >> >> 2) Utilities are not strongly incentivized to optimize complex UI/UX >> for the customer in the authorization server interface. In the committee >> we've gotten to the point where we have to specify number of clicks, div >> height requirements, and minimum pageload times for a utility to impleme= nt >> their OAuth flows (and then utilities want to charge rate payers for the >> cost of each UI/UX improvement). >> >> >> >> So, we have been brainstorming possible ways around these problems, >> and we think it may require a new type of authorization flow using one-t= ime >> passcodes (OTP) instead of redirecting the user to the utility for norma= l >> OAuth. Luckily, even though utility customers may not have an online >> account at the utility, the utility usually still has (a) a way of uniqu= ely >> identifying them and (b) a way of contacting them (phone, email, etc.). >> >> >> >> I'd like to see if the OAuth working group is an appropriate place to >> help develop this flow (or if there has already been work done such a >> flow). I'm happy to write the initial draft, but I would very much >> appreciate some mentorship from someone more experienced in the workgrou= p. >> >> >> >> OTP-flow diagram and example: >> >> https://pastebin.com/raw/4Gx8LAQ1 >> >> >> >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth >> device-flow and authorization code flow. Since we want to avoid asking >> utilities to implement complex authorization interfaces (problem #2 abov= e), >> the client asks the utility to send the user_code directly to the user (= via >> text/phone/email), then the client asks the user for the user_code and >> submits it to the utility to get an access token. >> >> >> >> Also, there is an initial step of identifying (but not authenticating= ) >> the user and determining the way in which the OTP code should be sent. I= f >> utilities are given some sort of non-secret user identification (e.g. >> address, phone number, account number, etc.), they should be able to sen= d a >> user_code to the user that the user can give to the client for >> authorization. Hopefully, this can shift most of the complex UI/UX >> development cost away from the utility and onto the third party clients. >> >> >> >> Unfortunately, the energy industry can be quite behind on the latest >> and greatest OAuth developments, but we're trying to get better :) >> >> >> >> Thanks very much, >> >> Daniel Roesler >> >> daniel@utilityapi.com >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > nov matake > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2018 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --0000000000008b562a057f8c2be6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel

This is an interesting use-case. = As mentioned by nov, CIBA could potentially = solve this=C2=A0problem.
The difference would be step 9 in your user s= tory. Instead of the user entering the code at the kiosk, they would click = on a link in the email (or reply the text) to confirm that they grant acces= s. This wouldn't require building a costly user interface, but rather t= he utilities would need to provide a single end-user facing route to deal w= ith confirmations via email.=C2=A0

From a user experience p= erspective, it would be nicer as the user wouldn't have to enter any co= des. They would simply enter their address (or some other identifier) at th= e kiosk, wait for an email or text, click the email or reply the text, and = access would be granted.=C2=A0

It is also flexible to suppor= t utilities that wanted to gain a higher lever of assurance. Such utilities= could ask the user for additional knowledge factors without changing the f= low.

Dave




On Wed, 16 Jan 2019 at 04:02, nov m= atake <matake@gmail.com> wrot= e:
Your use case seems fit CIBA which is being defined in OpenID= Foundation.

The section6 of CIBA = spec will describe how your use case fit it.
https://openid.net/specs/openid-clie= nt-initiated-backchannel-authentication-core-1_0.html#rfc.section.6

CIBA is an extension of OpenID Connect, not OAuth, bu= t since OpenID Connect itself is an extension of OAuth2, you should be able= to use it in OAuth context too.

Cheers,

nov

2019=E5=B9=B41=E6= =9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler <daniel=3D40utilityapi.com@= dmarc.ietf.org>:
Thanks for the reply!

Yes, that is essentially what we would like to do. We really like the
"here's a code to authorize" part of device-flow, but we are = trying to
not require the authorization server build a user interface for the
user to authenticate themselves and enter the code (because we've
found it is very costly for utilities to build these interfaces). We'd<= br> much rather the user get a code directly that they can input into the
client for authorization, hence reversing steps C & D in device-flow (and the client now is responsible for developing the costly user
interface).

However, in order to reverse C & D, steps A & B needs to provide so= me
sort of user identifier and delivery method (so that the authorization
server knows to who this authorization request is directed and how to
send the user_code). In order to figure that out, we added a
identification and delivery negotiation step in front of step A & B
that lets the client and authorization server negotiate those things
before kicking off the OTP code sending (e.g. reverse steps C & D).

I'm not really sure how we'd go about building off of device-flow i= f
we're reversing much of the process, changing what data is sent in
each step, and adding a step at the start. OTP-flow is less of a
"device" focused authorization and more of an on-the-go focused authorization.

Our main example we sanity check this for is the "Hardware Store Kiosk= " story:
1. Heather Homeowner walks into a hardware store.
2. There's a kiosk by the lighting section offering free energy audits.=
3. It says it needs to pull her energy usage data to perform the energy aud= it.
4. She doesn't remember (or have) her utility login, so she enters her<= br> address instead.
6. She is asked if she'd like to receive a text or email with a
verification code.
7. She selects she wants to receive a text.
8. She receives a text with a code and message about the scope of the
authorization.
9. She enters the code on the kiosk.
10. The kiosk pulls her energy usage data and generates an energy audit.
This story allows users who only know their address or some other
basic identifier (phone number, email, etc.) to be able to get instant
energy audits for lighting upgrades, solar quotes, energy star
appliances, EV charging costs, etc. Unfortunately, most people only
think about their energy use when they are out and about and encounter
energy products (e.g. in a hardware store), so we're trying to make it<= br> easy for them to get an energy audit with minimal information input or
device requirements.

Thanks again,
Daniel Roesler
daniel@utilityap= i.com

On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman <samuel@erdtman.se> wrote:
>
> To me this looks similar to the device flow.
>
> https://tools.ietf.org/html/draft-ie= tf-oauth-device-flow-13
>
> See figure 1, my interpretation of what you want to do is to split up = step B so that the code goes via another channel and then revers the direct= ion of C and D.
>
> So maybe you could ride on some of the work done in the device flow dr= aft.
>
>
>
>
>
> On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler <daniel=3D40utilityapi.com= @dmarc.ietf.org> wrote:
>>
>> Howdy,
>>
>> Rifaat recommended I post to the mailing list. Specifically, I am = looking for a mentor and feedback on a potential new OAuth flow (currently = called OTP-flow).
>>
>> Background:
>> I am a participant in the California Public Utility Commission'= ;s Customer Data Access Committee (CPUC CDAC), and we are working on improv= ing utility data access to accelerate deployment of more renewable and ener= gy efficiency technologies to fight climate change.
>>
>> However, we are currently struggling with a use-case for which we = can't seem to find a good OAuth flow.
>>
>> Use-case:
>> Utility customers want to share their utility data (e.g. historica= l energy usage) with a client (e.g. an energy auditor, to perform some ener= gy efficiency analysis).
>>
>> However, there are two problems that often occur:
>>
>> 1) Most utility customers do not have online accounts or forgot th= eir login information. This makes typical OAuth user interface complex, sin= ce you have to either create an online account in the flow or do some sort = of multi-step password-reset/verification process.
>>
>> 2) Utilities are not strongly incentivized to optimize complex UI/= UX for the customer in the authorization server interface. In the committee= we've gotten to the point where we have to specify number of clicks, d= iv height requirements, and minimum pageload times for a utility to impleme= nt their OAuth flows (and then utilities want to charge rate payers for the= cost of each UI/UX improvement).
>>
>> So, we have been brainstorming possible ways around these problems= , and we think it may require a new type of authorization flow using one-ti= me passcodes (OTP) instead of redirecting the user to the utility for norma= l OAuth. Luckily, even though utility customers may not have an online acco= unt at the utility, the utility usually still has (a) a way of uniquely ide= ntifying them and (b) a way of contacting them (phone, email, etc.).
>>
>> I'd like to see if the OAuth working group is an appropriate p= lace to help develop this flow (or if there has already been work done such= a flow). I'm happy to write the initial draft, but I would very much a= ppreciate some mentorship from someone more experienced in the workgroup. >>
>> OTP-flow diagram and example:
>> https://pastebin.com/raw/4Gx8LAQ1
>>
>> The OTP-flow (called Solution 1b in the committee) is a mix of OAu= th device-flow and authorization code flow. Since we want to avoid asking u= tilities to implement complex authorization interfaces (problem #2 above), = the client asks the utility to send the user_code directly to the user (via= text/phone/email), then the client asks the user for the user_code and sub= mits it to the utility to get an access token.
>>
>> Also, there is an initial step of identifying (but not authenticat= ing) the user and determining the way in which the OTP code should be sent.= If utilities are given some sort of non-secret user identification (e.g. a= ddress, phone number, account number, etc.), they should be able to send a = user_code to the user that the user can give to the client for authorizatio= n. Hopefully, this can shift most of the complex UI/UX development cost awa= y from the utility and onto the third party clients.
>>
>> Unfortunately, the energy industry can be quite behind on the late= st and greatest OAuth developments, but we're trying to get better :) >>
>> Thanks very much,
>> Daniel Roesler
>> daniel@= utilityapi.com
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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


--
Da= ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512= 0

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited whic= h is authorised and regulated by the Financial Conduct Authority ("FCA= ").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser= vices Register=C2=A0(FRN=C2=A0809360) at fca.= org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &= ; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
Moneyhub=C2=A0Financial Technology L= imited 2018=C2=A0=C2=A9<= /div>

DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.
<= /div>
--0000000000008b562a057f8c2be6-- From nobody Wed Jan 16 01:28:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D499D1310ED for ; Wed, 16 Jan 2019 01:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.129 X-Spam-Level: **** X-Spam-Status: No, score=4.129 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QXDFlFyI-ux for ; Wed, 16 Jan 2019 01:28:50 -0800 (PST) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [77.88.28.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1FF131063 for ; Wed, 16 Jan 2019 01:28:49 -0800 (PST) Received: from mxback10g.mail.yandex.net (mxback10g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:171]) by forward102p.mail.yandex.net (Yandex) with ESMTP id 82AF51D4020A; Wed, 16 Jan 2019 12:28:46 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback10g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oJ43jlD7Ai-SiPGnvld; Wed, 16 Jan 2019 12:28:44 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1547630924; bh=9RDl6+nRNsqbq2qdpOaRpr3h9crfAZOd90CoGW4iUKM=; h=From:To:Date:Message-Id; b=TZx+oFrEG3yad/42JSvE6EwxpOzYyBj1qABgg90Vz4Ij677jssXMCJoKpI23xz4d3 RGn4M2EumVUJujesUt4j2oidS5ENbe5H2wqmUCnB+bbRBZgkIYGjtAxrnaP4X5ImCn YO2BuUxfgAg0FphlwTfmNS+9cemzZb/kwXHdpK78= Authentication-Results: mxback10g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva5-d3020dc3459d.qloud-c.yandex.net with HTTP; Wed, 16 Jan 2019 12:28:44 +0300 From: =?utf-8?B?0JLQu9Cw0LTQuNC80LjRgCDQmtGA0LDQstGH0YPQug==?= To: oauth , Olga from LiveChat MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 16 Jan 2019 12:28:44 +0300 Message-Id: <15242181547630924@iva5-d3020dc3459d.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=utf-8 Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 09:28:53 -0000
вы мне все время присылаете пустые письма,смысл вашей рассылки?
From nobody Wed Jan 16 04:52:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890D130E27 for ; Wed, 16 Jan 2019 04:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 L9W645t9euKd for ; Wed, 16 Jan 2019 04:52:28 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB453130DEA for ; Wed, 16 Jan 2019 04:52:27 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id c2so4742408iom.12 for ; Wed, 16 Jan 2019 04:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v0bAOQguNfJ/3h9w/1bW+gmcbJ9aAq+4dwaRK2gSeC4=; b=ndDvFRjYGRHRCYvpLiOAwfEPdTtL1HlqxgUP+1tmdQDV0DyfHgiEru3bSsmUd54/i/ KgqtjZkpVOyJw16enWe6PEJ/XIm40ca7W+kPSAa1V2DRsWJGVFERxiAfjJ3yCvR05FJR Cx/P1tilMg95W5Mvua+R7W/6245vzUTqQyVak= 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=v0bAOQguNfJ/3h9w/1bW+gmcbJ9aAq+4dwaRK2gSeC4=; b=PgAE5U+5E8T9qVTAfQu5uy8Fq/Lnf4po9PlrdiAfceeDwPZ8sjjNNLE1eU08Jl9jaX PP53lMSxtBH+h7z+6hMZILU+s1zMYLEoiz26GRVmL1vr3mFfdQ3m3CAkOh+8tc86HVtD hnSwMzqVVkcf8ZsqdqGCOd6hvQjH+HUWCSiGfc3Bzt3mga9yPe6DTGeCX72WrMmuOqNr Bulpse2k67cItvmNRXJ+6+ZvJvRj81iu+Kw725WJqdwjLoZB4e+w4P5IDpHqcSB26kSp 0IoBa/rvdxZHZQwW+xqZG22ZoPi7n1uTuxEzFQUnw9BMU0pR5ZK2/FCPAcXYX2IEAr8u qdiA== X-Gm-Message-State: AJcUuketYnnGdbURk/kgkwYq6dends6r3Jj5npJ1pucA0RFADCwciTvP NNmWyN/hI8jaUIepwOpUjzJA0ptWOCOnJVqWB+HeIn/Nt/AtSVlkjh7QGGpPY4IXXQsWVR8Mm9x k+b/DM81PVgLKlA== X-Google-Smtp-Source: ALg8bN4Ss5m0d8sY7X0oRBiL8kr80KwWrDGQLcWZkD70yK/x7c9EMs9Kh5ixSwV47CS8L2XLVlcfvFM8Ql6v16xByyA= X-Received: by 2002:a6b:b345:: with SMTP id c66mr4745246iof.59.1547643146916; Wed, 16 Jan 2019 04:52:26 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Brian Campbell Date: Wed, 16 Jan 2019 05:52:00 -0700 Message-ID: To: Filip Skokan Cc: Dave Tonge , oauth Content-Type: multipart/alternative; boundary="00000000000002f5b5057f92c077" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 12:52:31 -0000 --00000000000002f5b5057f92c077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess I should have also said or been more straightforward in saying that I don't particularly want to try and discuss/define the use of a 307 in the document. On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan wrote: > I don't know that the use of 307 would need to be discussed in the >> document itself. > > > If the clients are supposed to be ready for this, yeah. For instance, my > client software by default doesn't follow redirects, in order for it to b= e > ready for mtls client authentication i'd have to know 307 is a possibilit= y > and whitelist 307 as a valid code to be followed. > > S pozdravem, > *Filip Skokan* > > > On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell > wrote: > >> I don't know that the use of 307 would need to be discussed in the >> document itself. >> >> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan wrote: >> >>> I'm in favour of both 307 and metadata. >>> >>> - case 307 - I don't recall ever encountering an http client >>> software that wouldn't have an option for following redirects, same = for a >>> server side frameworks not having the option to do a 307 response wi= th a >>> location header. >>> - case 307 - Relying purely on a new metadata doesn't help in the >>> scenario David put forth earlier about clients not being aware of us= ing >>> mtls, a device policy of sorts. >>> - case metadata - no second request if the client knows there's an >>> mtls endpoint it should use. >>> >>> Maybe we should specify both as optional for an AS to deploy and a >>> client to be ready for? >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge >>> wrote: >>> >>>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>>> should be optional. >>>> While a 307 redirect seems kind of elegant I worry, like you, that no= t >>>> all clients would handle it appropriately. >>>> There would probably need to be an error defined for clients who >>>> attempt to use `tls_client_auth` at the regular endpoint. >>>> >>>> Dave >>>> >>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>>>> Trying to summarize things somewhat here and focus in hopefully >>>>> towards some decision. There's basically an idea on the table to add = an AS >>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a J= SON >>>>> object which contains endpoints that a client doing MTLS would use ra= ther >>>>> than the regular endpoints. A straw-man example might look like this = (with >>>>> mtls_endpoints being that new parameter). >>>>> >>>>> { >>>>> "issuer":"https://server.example.com", >>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>> "token_endpoint":"https://server.example.com/token", >>>>> "token_endpoint_auth_methods_supported":[ >>>>> "client_secret_basic","tls_client_auth", "none"], >>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>> ", >>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>> >>>>> >>>>> >>>>> >>>>> * "mtls_endpoints":{ >>>>> "token_endpoint":"https://mtls.example.com/token >>>>> ", "userinfo_endpoint":"https://mt= ls >>>>> .example.com/userinfo >>>>> ", "revocation_endpoint":"https://mtl= s >>>>> ..example.com/revo >>>>> " }* >>>>> } >>>>> >>>>> The idea behind this is that "regular" clients (those not doing MTLS) >>>>> will use the regular endpoints. And only the host/port of the endpoin= ts >>>>> listed in mtls_endpoints will be set up to request TLS client certifi= cates >>>>> during handshake.. Thus any potential impact of the CertificateReques= t >>>>> message being sent in the TLS handshake can be avoided for all the ot= her >>>>> regular clients that are not going to do MTLS - including and most >>>>> importantly in-browser javascript clients where there can be less tha= n >>>>> desirable UI presented to the end-user. >>>>> >>>>> The arguments in favor of that seem to be basically that it allows fo= r >>>>> AS deployments to support MTLS while still allowing for a "not broken= " UX >>>>> for end-users of clients (in-browser javascript clients) that aren't = doing >>>>> MTLS. And that it's not much in terms of adding to the spec and compl= exity >>>>> of implementations. >>>>> >>>>> The arguments against it seem to be 1) the bad UX isn't really that >>>>> bad and/or will only happen to a subset of users 2) there are other t= hings >>>>> that can be done, such as 307ing or renegotiation/post-handshake clie= nt >>>>> auth, to avoid the bad UX. >>>>> >>>>> Speaking for myself, I'm kinda torn on it. >>>>> >>>>> I will say that, in addition to the folks that have pointed out that >>>>> renegotiation just isn't possible in some cases, my experience trying= to do >>>>> something like that in the past was not particularly successful or >>>>> encouraging. That could have been my fault, of course, but still seem= s a >>>>> relevant data point. I also have my doubts about the actual difficult= y of >>>>> getting an AS to issue a 307 like response for requests based on the >>>>> calling client and the likelihood that some/all OAuth client software= would >>>>> handle it appropriately. >>>>> >>>>> >>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>> david@alkaline-solutions.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden >>>>>> wrote: >>>>>> > >>>>>> > On 9 Jan 2019, at 05:54, David Waite >>>>>> wrote: >>>>>> >> >>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>> >>> >>>>>> >> >>>>>> >> >>>>>> >>> All of that is meant as an explanation of sorts to say that I >>>>>> think that things are actually okay enough as is and that I'd like t= o >>>>>> retract the proposal I'd previously made about the MTLS draft introd= ucing a >>>>>> new AS metadata parameter. It is admittedly interesting (ironic?) th= at Neil >>>>>> sent a message in support of the proposal as I was writing this. It = did >>>>>> give me pause but ultimately didn't change my opinion that it's not = worth >>>>>> it to add this new AS metadata parameter. >>>>>> >> >>>>>> >> Note that the AS could make a decision based on the token endpoin= t >>>>>> request - such as a policy associated with the =E2=80=9Cclient_id=E2= =80=9D, or via a >>>>>> parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indi= cating MTLS was desired >>>>>> by this public client installation. The AS could then to TLS 1.2 >>>>>> renegotiation, 1.3 post-handshake client authentication, or even use= 307 >>>>>> temporary redirects to another token endpoint to perform mutual >>>>>> authentication. >>>>>> > >>>>>> > Renegotiation is an intriguing option, but it has some practical >>>>>> difficulties. Our AS product runs in a Java servlet container, where= it is >>>>>> pretty much impossible to dynamically trigger renegotiation without >>>>>> accessing private internal APIs of the container. I also don=E2=80= =99t know how you >>>>>> could coordinate this in the common scenario where TLS is terminated= at a >>>>>> load balancer/reverse proxy? >>>>>> > >>>>>> > A 307 redirect could work though as the server will know if the >>>>>> client either uses mTLS for client authentication or has indicated t= hat it >>>>>> wants certificate-bound access tokens, so it can redirect to a >>>>>> mTLS-specific endpoint in those cases. >>>>>> >>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t k= now a way >>>>>> to have say a custom error code or WWW-Authenticate challenge to tri= gger >>>>>> renegotiation on the reverse proxy - usually this is just a static, >>>>>> location-based directive. >>>>>> >>>>>> > >>>>>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_ty= pe=E2=80=9D-like >>>>>> indicator imply that the client has multiple forms of authentication= and is >>>>>> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to= add support >>>>>> for, because I see it more likely a client would use MTLS without kn= owing >>>>>> it (via a device-level policy being applied to a public web or nativ= e app) >>>>>> than the reverse, where a single client (represented by a single cli= ent_id) >>>>>> is dynamically picking between forms of authentication. >>>>>> > >>>>>> > That=E2=80=99s an interesting observation. Can you elaborate on th= e sorts >>>>>> of device policy you are talking about? I am aware of e.g. mobile de= vice >>>>>> management being used to push client certificates to iOS devices, bu= t I >>>>>> think these are only available in Safari. >>>>>> >>>>>> The primary use is to set policy to rely on device level management >>>>>> in controlled environments like enterprises when available. So an AS= may >>>>>> try to detect a client certificate as an indicator of a managed devi= ce, use >>>>>> that to assume a device with certain device-level authentication, si= ngle >>>>>> user usage, remote wipe, etc. characteristics, and decide that it ca= n >>>>>> reduce user authentication requirements and/or expose additional sco= pes. >>>>>> >>>>>> On more thought, this is typically done as part of the user agent >>>>>> hitting the authorization endpoint, as a separate native application= may be >>>>>> interacting with the token endpoint, and in some operating systems t= he >>>>>> application=E2=80=99s network connections do not utilize (and may no= t have access >>>>>> to) the system certificate store. >>>>>> >>>>>> In terms of user agents, I believe you can perform similar behavior >>>>>> (managed systems using client certificates on user agents transparen= tly) on >>>>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) ty= pically >>>>>> inherits device level policy. Firefox on desktop I assume you can do= that >>>>>> in limited fashion as well. >>>>>> >>>>>> -DW >>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly >>>>> prohibited.... If you have received this communication in error, ple= ase >>>>> notify the sender immediately by e-mail and delete the message and an= y file >>>>> attachments from your computer. Thank you.* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000002f5b5057f92c077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess I should have also said or been more straightforwa= rd in saying that I don't particularly want to try and discuss/define t= he use of a 307 in the document.

<= div dir=3D"ltr">On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrote:
I do= n't know that the use of 307 would need to be discussed in the document= itself.=C2=A0

If the clients are su= pposed to be ready for this, yeah. For instance, my client software by defa= ult doesn't follow redirects, in order for it to be ready for mtls clie= nt authentication i'd have to know 307 is a possibility and whitelist 3= 07 as a valid code to be followed.

S pozdravem,
Filip Skokan


On Tue,= Jan 15, 2019 at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:<= br>
I don't know that the use of 307 would need to be discussed in the doc= ument itself.

On = Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm = in favour of both 307 and metadata.=C2=A0
  • case 307 - I do= n't recall ever encountering an http client software that wouldn't = have an option for following redirects, same for a server side frameworks n= ot having the option to do a 307 response with a location header.
    • <= li>case 307 - Relying purely on a new metadata doesn't help in the scen= ario David put forth earlier about clients not being aware of using mtls, a= device policy of sorts.
  • case metadata - no second request if t= he client knows there's an mtls endpoint it should use.
=
Maybe we should specify both as optional for an AS to deploy and a cli= ent to be ready for?

S pozdravem,
Filip Skokan

<= /div>
On Tue, Jan 15, 2019 a= t 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata parameter -= although it should be optional.
<= font face=3D"trebuchet ms, sans-serif">While a 307 redirect seems kind of e= legant I worry, like you,=C2=A0 that not all clients would handle it approp= riately.
There would probably need to be an error defined for clients= who attempt to use `tls_client_auth` at the regular endpoint.
=

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:
=
Trying to summarize things somewhat here and focus in hopefu= lly towards some decision. There's basically an idea on the table to ad= d an AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a= JSON object which contains endpoints that a client doing MTLS would use ra= ther than the regular endpoints. A straw-man example might look like this (= with mtls_endpoints being that new parameter).

{=C2=A0
= =C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authori= zation_endpoint":"https://server.example.com/authz",
=C2=A0 "= ;token_endpoint":"https://server.example.com/token",
=C2=A0 "= ;token_endpoint_auth_methods_supported":[=C2=A0 "client_secret_ba= sic","tls_client_auth", "none"],
=C2=A0 "u= serinfo_endpoint":"https://server..example.com/userinfo",
=C2= =A0 "revocation_endpoint":"https://server.example.com/revo",
= =C2=A0 "jwks_uri":"https://server.example.com/jwks.json",=C2=A0 "mtls_endpoints":{=C2=A0
=C2=A0=C2=A0=C2=A0 "= ;token_endpoint":"https://mtls.example.com/token",
=C2=A0=C2=A0=C2= =A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2= =A0=C2=A0=C2=A0 "revocation_endpoint":"https://mtls..example.com/revo"=C2=A0 }
}

The idea behind this is th= at "regular" clients (those not doing MTLS) will use the regular = endpoints. And only the host/port of the endpoints listed in mtls_endpoints= will be set up to request TLS client certificates during handshake.. Thus = any potential impact of the CertificateRequest message being sent in the TL= S handshake can be avoided for all the other regular clients that are not g= oing to do MTLS - including and most importantly in-browser javascript clie= nts where there can be less than desirable UI presented to the end-user.

The arguments in favor of that seem to be basic= ally that it allows for AS deployments to support MTLS while still allowing= for a "not broken" UX for end-users of clients (in-browser javas= cript clients) that aren't doing MTLS. And that it's not much in te= rms of adding to the spec and complexity of implementations.

The arguments against it seem to be 1) the bad UX isn't= really that bad and/or will only happen to a subset of users 2) there are = other things that can be done, such as 307ing or renegotiation/post-handsha= ke client auth, to avoid the bad UX.

Speaking= for myself, I'm kinda torn on it.

I will= say that, in addition to the folks that have pointed out that renegotiatio= n just isn't possible in some cases, my experience trying to do somethi= ng like that in the past was not particularly successful or encouraging. Th= at could have been my fault, of course, but still seems a relevant data poi= nt. I also have my doubts about the actual difficulty of getting an AS to i= ssue a 307 like response for requests based on the calling client and the l= ikelihood that some/all OAuth client software would handle it appropriately= .
=C2=A0
=

On Fri, Jan 11, 2019 = at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

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



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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000002f5b5057f92c077-- From nobody Wed Jan 16 06:36:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3755130E5F for ; Wed, 16 Jan 2019 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nSBZcguxO0O for ; Wed, 16 Jan 2019 06:35:57 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E4D130E46 for ; Wed, 16 Jan 2019 06:35:56 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id o125so3860553qkf.3 for ; Wed, 16 Jan 2019 06:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aRx/C4uRkhhqe6M1w4CDRidYadWHwNnqG8dbD0C1Vms=; b=jodLtTo5M5qdDyBo5tKp1AP9Qr63OIldQlaHSjx/BuAMfvFMg0nehkKjT8AWAiHNrR +hip59VVzckg4UB0FAOy+gN93WlWzpvBSyBNksPZ6+IMnAdlkjeZlIxe/w42IxAcAHAw Etas0XyRKQCod+UzSpoJ2Y+RA4EN03GN/oCuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aRx/C4uRkhhqe6M1w4CDRidYadWHwNnqG8dbD0C1Vms=; b=kyDbH8OEhkQS0lU04jX2EBeY8LVoFeJ3hi90og7sMa38LPZ+CseXxCirCu5/wOKOwR VSlPzx7ANHq/jrsbdu0cPMli9OLj8nnHRGD2GNEYRNvx9E8Dxb/sRrK0XKRX6UDRwz3F dn1MNCai6bZpsc1rvk1+bdYYtux4nCtGO9+PcKasD0ATCDBKkoxtTDC4VQSfIQoP8DDW qVKp70UI26o3lcPXFp02YwNZWZhc8D5GOmIrYKIRbWsvpX1Wb2l2mG/TBraUgZisG7B3 sifA0Ry+ZnmuSubMRnaW5RblGld9YMNWj4Kb2KqyVkPjfBVKze/Mu1sBkpECXcujLVnp cyKg== X-Gm-Message-State: AJcUukepWWYR5+VRTm0NGtaTaFGkf4lHUvVsuGv6ySu8joyppJzpZZjs 3j8P/50SdFYYVwxkkZj0tLxFkthWKF5Ofi2Kdwc0craO X-Google-Smtp-Source: ALg8bN6oCXzBBnQaXJwOCp1CSJGCBdT/nADsCsOQ1p5rb9vBJXzK5XDZL82QxqcAj01EE8vUuefTjUybmH4vpkkE7/A= X-Received: by 2002:a37:bc06:: with SMTP id m6mr7052277qkf.336.1547649355661; Wed, 16 Jan 2019 06:35:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Roesler Date: Wed, 16 Jan 2019 08:35:19 -0600 Message-ID: To: Dave Tonge Cc: nov matake , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 14:36:00 -0000 Thanks Nov and Dave! I have several questions about CIBA. Is this mailing list the appropriate place to ask them or is there another mailing list that is for discussions about CIBA? Daniel Roesler daniel@utilityapi.com On Tue, Jan 15, 2019 at 11:01 PM Dave Tonge w= rote: > > Hi Daniel > > This is an interesting use-case. As mentioned by nov, CIBA could potentia= lly solve this problem. > The difference would be step 9 in your user story. Instead of the user en= tering the code at the kiosk, they would click on a link in the email (or r= eply the text) to confirm that they grant access. This wouldn't require bui= lding a costly user interface, but rather the utilities would need to provi= de a single end-user facing route to deal with confirmations via email. > > From a user experience perspective, it would be nicer as the user wouldn'= t have to enter any codes. They would simply enter their address (or some o= ther identifier) at the kiosk, wait for an email or text, click the email o= r reply the text, and access would be granted. > > It is also flexible to support utilities that wanted to gain a higher lev= er of assurance. Such utilities could ask the user for additional knowledge= factors without changing the flow. > > Dave > > > > > On Wed, 16 Jan 2019 at 04:02, nov matake wrote: >> >> Your use case seems fit CIBA which is being defined in OpenID Foundation= . >> >> The section6 of CIBA spec will describe how your use case fit it. >> https://openid.net/specs/openid-client-initiated-backchannel-authenticat= ion-core-1_0.html#rfc.section.6 >> >> CIBA is an extension of OpenID Connect, not OAuth, but since OpenID Conn= ect itself is an extension of OAuth2, you should be able to use it in OAuth= context too. >> >> Cheers, >> >> nov >> >> 2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler : >>> >>> Thanks for the reply! >>> >>> Yes, that is essentially what we would like to do. We really like the >>> "here's a code to authorize" part of device-flow, but we are trying to >>> not require the authorization server build a user interface for the >>> user to authenticate themselves and enter the code (because we've >>> found it is very costly for utilities to build these interfaces). We'd >>> much rather the user get a code directly that they can input into the >>> client for authorization, hence reversing steps C & D in device-flow >>> (and the client now is responsible for developing the costly user >>> interface). >>> >>> However, in order to reverse C & D, steps A & B needs to provide some >>> sort of user identifier and delivery method (so that the authorization >>> server knows to who this authorization request is directed and how to >>> send the user_code). In order to figure that out, we added a >>> identification and delivery negotiation step in front of step A & B >>> that lets the client and authorization server negotiate those things >>> before kicking off the OTP code sending (e.g. reverse steps C & D). >>> >>> I'm not really sure how we'd go about building off of device-flow if >>> we're reversing much of the process, changing what data is sent in >>> each step, and adding a step at the start. OTP-flow is less of a >>> "device" focused authorization and more of an on-the-go focused >>> authorization. >>> >>> Our main example we sanity check this for is the "Hardware Store Kiosk"= story: >>> 1. Heather Homeowner walks into a hardware store. >>> 2. There's a kiosk by the lighting section offering free energy audits. >>> 3. It says it needs to pull her energy usage data to perform the energy= audit. >>> 4. She doesn't remember (or have) her utility login, so she enters her >>> address instead. >>> 6. She is asked if she'd like to receive a text or email with a >>> verification code. >>> 7. She selects she wants to receive a text. >>> 8. She receives a text with a code and message about the scope of the >>> authorization. >>> 9. She enters the code on the kiosk. >>> 10. The kiosk pulls her energy usage data and generates an energy audit= . >>> >>> This story allows users who only know their address or some other >>> basic identifier (phone number, email, etc.) to be able to get instant >>> energy audits for lighting upgrades, solar quotes, energy star >>> appliances, EV charging costs, etc. Unfortunately, most people only >>> think about their energy use when they are out and about and encounter >>> energy products (e.g. in a hardware store), so we're trying to make it >>> easy for them to get an energy audit with minimal information input or >>> device requirements. >>> >>> Thanks again, >>> Daniel Roesler >>> daniel@utilityapi.com >>> >>> On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman wrot= e: >>> > >>> > To me this looks similar to the device flow. >>> > >>> > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 >>> > >>> > See figure 1, my interpretation of what you want to do is to split up= step B so that the code goes via another channel and then revers the direc= tion of C and D. >>> > >>> > So maybe you could ride on some of the work done in the device flow d= raft. >>> > >>> > >>> > >>> > >>> > >>> > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler wrote: >>> >> >>> >> Howdy, >>> >> >>> >> Rifaat recommended I post to the mailing list. Specifically, I am lo= oking for a mentor and feedback on a potential new OAuth flow (currently ca= lled OTP-flow). >>> >> >>> >> Background: >>> >> I am a participant in the California Public Utility Commission's Cus= tomer Data Access Committee (CPUC CDAC), and we are working on improving ut= ility data access to accelerate deployment of more renewable and energy eff= iciency technologies to fight climate change. >>> >> >>> >> However, we are currently struggling with a use-case for which we ca= n't seem to find a good OAuth flow. >>> >> >>> >> Use-case: >>> >> Utility customers want to share their utility data (e.g. historical = energy usage) with a client (e.g. an energy auditor, to perform some energy= efficiency analysis). >>> >> >>> >> However, there are two problems that often occur: >>> >> >>> >> 1) Most utility customers do not have online accounts or forgot thei= r login information. This makes typical OAuth user interface complex, since= you have to either create an online account in the flow or do some sort of= multi-step password-reset/verification process. >>> >> >>> >> 2) Utilities are not strongly incentivized to optimize complex UI/UX= for the customer in the authorization server interface. In the committee w= e've gotten to the point where we have to specify number of clicks, div hei= ght requirements, and minimum pageload times for a utility to implement the= ir OAuth flows (and then utilities want to charge rate payers for the cost = of each UI/UX improvement). >>> >> >>> >> So, we have been brainstorming possible ways around these problems, = and we think it may require a new type of authorization flow using one-time= passcodes (OTP) instead of redirecting the user to the utility for normal = OAuth. Luckily, even though utility customers may not have an online accoun= t at the utility, the utility usually still has (a) a way of uniquely ident= ifying them and (b) a way of contacting them (phone, email, etc.). >>> >> >>> >> I'd like to see if the OAuth working group is an appropriate place t= o help develop this flow (or if there has already been work done such a flo= w). I'm happy to write the initial draft, but I would very much appreciate = some mentorship from someone more experienced in the workgroup. >>> >> >>> >> OTP-flow diagram and example: >>> >> https://pastebin.com/raw/4Gx8LAQ1 >>> >> >>> >> The OTP-flow (called Solution 1b in the committee) is a mix of OAuth= device-flow and authorization code flow. Since we want to avoid asking uti= lities to implement complex authorization interfaces (problem #2 above), th= e client asks the utility to send the user_code directly to the user (via t= ext/phone/email), then the client asks the user for the user_code and submi= ts it to the utility to get an access token. >>> >> >>> >> Also, there is an initial step of identifying (but not authenticatin= g) the user and determining the way in which the OTP code should be sent. I= f utilities are given some sort of non-secret user identification (e.g. add= ress, phone number, account number, etc.), they should be able to send a us= er_code to the user that the user can give to the client for authorization.= Hopefully, this can shift most of the complex UI/UX development cost away = from the utility and onto the third party clients. >>> >> >>> >> Unfortunately, the energy industry can be quite behind on the latest= and greatest OAuth developments, but we're trying to get better :) >>> >> >>> >> Thanks very much, >>> >> Daniel Roesler >>> >> daniel@utilityapi.com >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> nov matake >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Dave Tonge > CTO > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology L= imited which is authorised and regulated by the Financial Conduct Authority= ("FCA"). Moneyhub Financial Technology is entered on the Financial Service= s Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technolo= gy is registered in England & Wales, company registration number 06909772 = . > Moneyhub Financial Technology Limited 2018 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. = Whilst reasonable efforts are made to ensure that any attachments are virus= -free, it is the recipient's sole responsibility to scan all attachments fo= r viruses. All calls and emails to and from this company may be monitored a= nd recorded for legitimate purposes relating to this company's business. An= y opinions expressed in this email (or in any attachments) are those of the= author and do not necessarily represent the opinions of Moneyhub Financial= Technology Limited or of any other group company. From nobody Wed Jan 16 06:51:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CEE130E70 for ; Wed, 16 Jan 2019 06:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rXxJZ6Vjca0O for ; Wed, 16 Jan 2019 06:51:11 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9AD1294FA for ; Wed, 16 Jan 2019 06:51:11 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id c19-v6so5678651lja.5 for ; Wed, 16 Jan 2019 06:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ixt3LOJpv2yG9JPWSl5SvcYGRDdT+LZeoPJOHW99G1g=; b=JQdzpVQLBiBb/uAEMJuNmRb2riYn+bLa54/rnmR/zltQs4AZOfCj43kYlbMNevBURB Lh5+e8m7zBMighuHOUsoCShRC8ULMn8N2ISaEaE3n82il1TnR0EqewiuTl4FugSuP6Wz bM121fHWESHFJlfcdSU9E9S+z+SXb/0sftGME= 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=Ixt3LOJpv2yG9JPWSl5SvcYGRDdT+LZeoPJOHW99G1g=; b=glg+nueYp3cm+kS3QGLfnzwXaFl4o7BectKB7l56UXH4SYExPuexzZmT30KNTsTlYV HCLhyV3LaTgIVDOVBQxq/1zfWez2yZGdFwDwT6QN9n9x3cpwLL5wOjdVN0lUtBJoM/B8 3j9/Qj8nc/+QO+9C1PuGAWLv5/T99BbOozri3xIwvkFTfyCIdiujADpoMjyiIR03296D SyGs3VvQtxaZImTCii+YBkgMPGEy9dB6+By1KDd7UBDXxcUxvlcLwA8o2pRCboaPUA1e 8oV7p4qN8sO7k2Hh8ASk9xcrHqAhVKsrmI4xFpMmttfG690XGLtDaVLOhK0hWp39tdtj V6yw== X-Gm-Message-State: AJcUukdOyuVdxr/NdW3DTIqdKcTtRr1a9yus8ky7RsHDzTtxclw1rdie +fiaPHJ4Wlrl/TFIJ3/IzbduXmK0a08dkVWbE+Ugqg== X-Google-Smtp-Source: ALg8bN4+rEGjQYuG5c3Acof/BAlqVTWIHFUVxVr7B9u6xcGargrjOu1qCz1W7aSMvGZCrXpAGAr7mWnLr23MULkJ5/o= X-Received: by 2002:a2e:2c02:: with SMTP id s2-v6mr7035400ljs.118.1547650269123; Wed, 16 Jan 2019 06:51:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Wed, 16 Jan 2019 15:50:57 +0100 Message-ID: To: Daniel Roesler Cc: nov matake , "" Content-Type: multipart/alternative; boundary="000000000000873231057f946856" Archived-At: Subject: Re: [OAUTH-WG] OTP-flow use case (sharing energy data) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 14:51:15 -0000 --000000000000873231057f946856 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel This is the repo: https://bitbucket.org/openid/mobile/src and it has an issue tracker. This is the mailing list: http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile It would be good to get your feedback. Thanks Dave On Wed, 16 Jan 2019 at 15:35, Daniel Roesler wrote: > Thanks Nov and Dave! > > I have several questions about CIBA. Is this mailing list the > appropriate place to ask them or is there another mailing list that is > for discussions about CIBA? > > Daniel Roesler > daniel@utilityapi.com > > > On Tue, Jan 15, 2019 at 11:01 PM Dave Tonge > wrote: > > > > Hi Daniel > > > > This is an interesting use-case. As mentioned by nov, CIBA could > potentially solve this problem. > > The difference would be step 9 in your user story. Instead of the user > entering the code at the kiosk, they would click on a link in the email (= or > reply the text) to confirm that they grant access. This wouldn't require > building a costly user interface, but rather the utilities would need to > provide a single end-user facing route to deal with confirmations via ema= il. > > > > From a user experience perspective, it would be nicer as the user > wouldn't have to enter any codes. They would simply enter their address (= or > some other identifier) at the kiosk, wait for an email or text, click the > email or reply the text, and access would be granted. > > > > It is also flexible to support utilities that wanted to gain a higher > lever of assurance. Such utilities could ask the user for additional > knowledge factors without changing the flow. > > > > Dave > > > > > > > > > > On Wed, 16 Jan 2019 at 04:02, nov matake wrote: > >> > >> Your use case seems fit CIBA which is being defined in OpenID > Foundation. > >> > >> The section6 of CIBA spec will describe how your use case fit it. > >> > https://openid.net/specs/openid-client-initiated-backchannel-authenticati= on-core-1_0.html#rfc.section.6 > >> > >> CIBA is an extension of OpenID Connect, not OAuth, but since OpenID > Connect itself is an extension of OAuth2, you should be able to use it in > OAuth context too. > >> > >> Cheers, > >> > >> nov > >> > >> 2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler 40utilityapi.com@dmarc.ietf.org>: > >>> > >>> Thanks for the reply! > >>> > >>> Yes, that is essentially what we would like to do. We really like the > >>> "here's a code to authorize" part of device-flow, but we are trying t= o > >>> not require the authorization server build a user interface for the > >>> user to authenticate themselves and enter the code (because we've > >>> found it is very costly for utilities to build these interfaces). We'= d > >>> much rather the user get a code directly that they can input into the > >>> client for authorization, hence reversing steps C & D in device-flow > >>> (and the client now is responsible for developing the costly user > >>> interface). > >>> > >>> However, in order to reverse C & D, steps A & B needs to provide some > >>> sort of user identifier and delivery method (so that the authorizatio= n > >>> server knows to who this authorization request is directed and how to > >>> send the user_code). In order to figure that out, we added a > >>> identification and delivery negotiation step in front of step A & B > >>> that lets the client and authorization server negotiate those things > >>> before kicking off the OTP code sending (e.g. reverse steps C & D). > >>> > >>> I'm not really sure how we'd go about building off of device-flow if > >>> we're reversing much of the process, changing what data is sent in > >>> each step, and adding a step at the start. OTP-flow is less of a > >>> "device" focused authorization and more of an on-the-go focused > >>> authorization. > >>> > >>> Our main example we sanity check this for is the "Hardware Store > Kiosk" story: > >>> 1. Heather Homeowner walks into a hardware store. > >>> 2. There's a kiosk by the lighting section offering free energy audit= s. > >>> 3. It says it needs to pull her energy usage data to perform the > energy audit. > >>> 4. She doesn't remember (or have) her utility login, so she enters he= r > >>> address instead. > >>> 6. She is asked if she'd like to receive a text or email with a > >>> verification code. > >>> 7. She selects she wants to receive a text. > >>> 8. She receives a text with a code and message about the scope of the > >>> authorization. > >>> 9. She enters the code on the kiosk. > >>> 10. The kiosk pulls her energy usage data and generates an energy > audit. > >>> > >>> This story allows users who only know their address or some other > >>> basic identifier (phone number, email, etc.) to be able to get instan= t > >>> energy audits for lighting upgrades, solar quotes, energy star > >>> appliances, EV charging costs, etc. Unfortunately, most people only > >>> think about their energy use when they are out and about and encounte= r > >>> energy products (e.g. in a hardware store), so we're trying to make i= t > >>> easy for them to get an energy audit with minimal information input o= r > >>> device requirements. > >>> > >>> Thanks again, > >>> Daniel Roesler > >>> daniel@utilityapi.com > >>> > >>> On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman > wrote: > >>> > > >>> > To me this looks similar to the device flow. > >>> > > >>> > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > >>> > > >>> > See figure 1, my interpretation of what you want to do is to split > up step B so that the code goes via another channel and then revers the > direction of C and D. > >>> > > >>> > So maybe you could ride on some of the work done in the device flow > draft. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler 40utilityapi.com@dmarc.ietf.org> wrote: > >>> >> > >>> >> Howdy, > >>> >> > >>> >> Rifaat recommended I post to the mailing list. Specifically, I am > looking for a mentor and feedback on a potential new OAuth flow (currentl= y > called OTP-flow). > >>> >> > >>> >> Background: > >>> >> I am a participant in the California Public Utility Commission's > Customer Data Access Committee (CPUC CDAC), and we are working on improvi= ng > utility data access to accelerate deployment of more renewable and energy > efficiency technologies to fight climate change. > >>> >> > >>> >> However, we are currently struggling with a use-case for which we > can't seem to find a good OAuth flow. > >>> >> > >>> >> Use-case: > >>> >> Utility customers want to share their utility data (e.g. historica= l > energy usage) with a client (e.g. an energy auditor, to perform some ener= gy > efficiency analysis). > >>> >> > >>> >> However, there are two problems that often occur: > >>> >> > >>> >> 1) Most utility customers do not have online accounts or forgot > their login information. This makes typical OAuth user interface complex, > since you have to either create an online account in the flow or do some > sort of multi-step password-reset/verification process. > >>> >> > >>> >> 2) Utilities are not strongly incentivized to optimize complex > UI/UX for the customer in the authorization server interface. In the > committee we've gotten to the point where we have to specify number of > clicks, div height requirements, and minimum pageload times for a utility > to implement their OAuth flows (and then utilities want to charge rate > payers for the cost of each UI/UX improvement). > >>> >> > >>> >> So, we have been brainstorming possible ways around these problems= , > and we think it may require a new type of authorization flow using one-ti= me > passcodes (OTP) instead of redirecting the user to the utility for normal > OAuth. Luckily, even though utility customers may not have an online > account at the utility, the utility usually still has (a) a way of unique= ly > identifying them and (b) a way of contacting them (phone, email, etc.). > >>> >> > >>> >> I'd like to see if the OAuth working group is an appropriate place > to help develop this flow (or if there has already been work done such a > flow). I'm happy to write the initial draft, but I would very much > appreciate some mentorship from someone more experienced in the workgroup= . > >>> >> > >>> >> OTP-flow diagram and example: > >>> >> https://pastebin.com/raw/4Gx8LAQ1 > >>> >> > >>> >> The OTP-flow (called Solution 1b in the committee) is a mix of > OAuth device-flow and authorization code flow. Since we want to avoid > asking utilities to implement complex authorization interfaces (problem #= 2 > above), the client asks the utility to send the user_code directly to the > user (via text/phone/email), then the client asks the user for the > user_code and submits it to the utility to get an access token. > >>> >> > >>> >> Also, there is an initial step of identifying (but not > authenticating) the user and determining the way in which the OTP code > should be sent. If utilities are given some sort of non-secret user > identification (e.g. address, phone number, account number, etc.), they > should be able to send a user_code to the user that the user can give to > the client for authorization. Hopefully, this can shift most of the compl= ex > UI/UX development cost away from the utility and onto the third party > clients. > >>> >> > >>> >> Unfortunately, the energy industry can be quite behind on the > latest and greatest OAuth developments, but we're trying to get better :) > >>> >> > >>> >> Thanks very much, > >>> >> Daniel Roesler > >>> >> daniel@utilityapi.com > >>> >> > >>> >> _______________________________________________ > >>> >> OAuth mailing list > >>> >> OAuth@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> -- > >> nov matake > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > > Dave Tonge > > CTO > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 > 6FL > > t: +44 (0)117 280 5120 > > > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub > Financial Technology is registered in England & Wales, company registrati= on > number 06909772 . > > Moneyhub Financial Technology Limited 2018 =C2=A9 > > > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2018 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --000000000000873231057f946856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel

This is the repo:=C2=A0https://bitbucket.or= g/openid/mobile/src and it has an issue tracker.
T= his is the mailing list:=C2=A0http://lists.openid.net/mailman/listinf= o/openid-specs-mobile-profile


Thanks

Dave
On Wed, 1= 6 Jan 2019 at 15:35, Daniel Roesler <daniel@utilityapi.com> wrote:
Thanks Nov and Dave!

I have several questions about CIBA. Is this mailing list the
appropriate place to ask them or is there another mailing list that is
for discussions about CIBA?

Daniel Roesler
daniel@utilityap= i.com


On Tue, Jan 15, 2019 at 11:01 PM Dave Tonge <dave.tonge@momentumft.co.uk> w= rote:
>
> Hi Daniel
>
> This is an interesting use-case. As mentioned by nov, CIBA could poten= tially solve this problem.
> The difference would be step 9 in your user story. Instead of the user= entering the code at the kiosk, they would click on a link in the email (o= r reply the text) to confirm that they grant access. This wouldn't requ= ire building a costly user interface, but rather the utilities would need t= o provide a single end-user facing route to deal with confirmations via ema= il.
>
> From a user experience perspective, it would be nicer as the user woul= dn't have to enter any codes. They would simply enter their address (or= some other identifier) at the kiosk, wait for an email or text, click the = email or reply the text, and access would be granted.
>
> It is also flexible to support utilities that wanted to gain a higher = lever of assurance. Such utilities could ask the user for additional knowle= dge factors without changing the flow.
>
> Dave
>
>
>
>
> On Wed, 16 Jan 2019 at 04:02, nov matake <matake@gmail.com> wrote:
>>
>> Your use case seems fit CIBA which is being defined in OpenID Foun= dation.
>>
>> The section6 of CIBA spec will describe how your use case fit it.<= br> >> https://openid.net/specs/openid-client-initiated-backchannel-au= thentication-core-1_0.html#rfc.section.6
>>
>> CIBA is an extension of OpenID Connect, not OAuth, but since OpenI= D Connect itself is an extension of OAuth2, you should be able to use it in= OAuth context too.
>>
>> Cheers,
>>
>> nov
>>
>> 2019=E5=B9=B41=E6=9C=8816=E6=97=A5(=E6=B0=B4) 10:25 Daniel Roesler= <daniel=3D40utilityapi.com@dmarc.ietf.org>:
>>>
>>> Thanks for the reply!
>>>
>>> Yes, that is essentially what we would like to do. We really l= ike the
>>> "here's a code to authorize" part of device-flow= , but we are trying to
>>> not require the authorization server build a user interface fo= r the
>>> user to authenticate themselves and enter the code (because we= 've
>>> found it is very costly for utilities to build these interface= s). We'd
>>> much rather the user get a code directly that they can input i= nto the
>>> client for authorization, hence reversing steps C & D in d= evice-flow
>>> (and the client now is responsible for developing the costly u= ser
>>> interface).
>>>
>>> However, in order to reverse C & D, steps A & B needs = to provide some
>>> sort of user identifier and delivery method (so that the autho= rization
>>> server knows to who this authorization request is directed and= how to
>>> send the user_code). In order to figure that out, we added a >>> identification and delivery negotiation step in front of step = A & B
>>> that lets the client and authorization server negotiate those = things
>>> before kicking off the OTP code sending (e.g. reverse steps C = & D).
>>>
>>> I'm not really sure how we'd go about building off of = device-flow if
>>> we're reversing much of the process, changing what data is= sent in
>>> each step, and adding a step at the start. OTP-flow is less of= a
>>> "device" focused authorization and more of an on-the= -go focused
>>> authorization.
>>>
>>> Our main example we sanity check this for is the "Hardwar= e Store Kiosk" story:
>>> 1. Heather Homeowner walks into a hardware store.
>>> 2. There's a kiosk by the lighting section offering free e= nergy audits.
>>> 3. It says it needs to pull her energy usage data to perform t= he energy audit.
>>> 4. She doesn't remember (or have) her utility login, so sh= e enters her
>>> address instead.
>>> 6. She is asked if she'd like to receive a text or email w= ith a
>>> verification code.
>>> 7. She selects she wants to receive a text.
>>> 8. She receives a text with a code and message about the scope= of the
>>> authorization.
>>> 9. She enters the code on the kiosk.
>>> 10. The kiosk pulls her energy usage data and generates an ene= rgy audit.
>>>
>>> This story allows users who only know their address or some ot= her
>>> basic identifier (phone number, email, etc.) to be able to get= instant
>>> energy audits for lighting upgrades, solar quotes, energy star=
>>> appliances, EV charging costs, etc. Unfortunately, most people= only
>>> think about their energy use when they are out and about and e= ncounter
>>> energy products (e.g. in a hardware store), so we're tryin= g to make it
>>> easy for them to get an energy audit with minimal information = input or
>>> device requirements.
>>>
>>> Thanks again,
>>> Daniel Roesler
>>> dan= iel@utilityapi.com
>>>
>>> On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman <samuel@erdtman.se> wrote= :
>>> >
>>> > To me this looks similar to the device flow.
>>> >
>>> > https://tools.ietf.org/= html/draft-ietf-oauth-device-flow-13
>>> >
>>> > See figure 1, my interpretation of what you want to do is= to split up step B so that the code goes via another channel and then reve= rs the direction of C and D.
>>> >
>>> > So maybe you could ride on some of the work done in the d= evice flow draft.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler <daniel= =3D40u= tilityapi.com@dmarc.ietf.org> wrote:
>>> >>
>>> >> Howdy,
>>> >>
>>> >> Rifaat recommended I post to the mailing list. Specif= ically, I am looking for a mentor and feedback on a potential new OAuth flo= w (currently called OTP-flow).
>>> >>
>>> >> Background:
>>> >> I am a participant in the California Public Utility C= ommission's Customer Data Access Committee (CPUC CDAC), and we are work= ing on improving utility data access to accelerate deployment of more renew= able and energy efficiency technologies to fight climate change.
>>> >>
>>> >> However, we are currently struggling with a use-case = for which we can't seem to find a good OAuth flow.
>>> >>
>>> >> Use-case:
>>> >> Utility customers want to share their utility data (e= .g. historical energy usage) with a client (e.g. an energy auditor, to perf= orm some energy efficiency analysis).
>>> >>
>>> >> However, there are two problems that often occur:
>>> >>
>>> >> 1) Most utility customers do not have online accounts= or forgot their login information. This makes typical OAuth user interface= complex, since you have to either create an online account in the flow or = do some sort of multi-step password-reset/verification process.
>>> >>
>>> >> 2) Utilities are not strongly incentivized to optimiz= e complex UI/UX for the customer in the authorization server interface. In = the committee we've gotten to the point where we have to specify number= of clicks, div height requirements, and minimum pageload times for a utili= ty to implement their OAuth flows (and then utilities want to charge rate p= ayers for the cost of each UI/UX improvement).
>>> >>
>>> >> So, we have been brainstorming possible ways around t= hese problems, and we think it may require a new type of authorization flow= using one-time passcodes (OTP) instead of redirecting the user to the util= ity for normal OAuth. Luckily, even though utility customers may not have a= n online account at the utility, the utility usually still has (a) a way of= uniquely identifying them and (b) a way of contacting them (phone, email, = etc.).
>>> >>
>>> >> I'd like to see if the OAuth working group is an = appropriate place to help develop this flow (or if there has already been w= ork done such a flow). I'm happy to write the initial draft, but I woul= d very much appreciate some mentorship from someone more experienced in the= workgroup.
>>> >>
>>> >> OTP-flow diagram and example:
>>> >> https://pastebin.com/raw/4Gx8LAQ1
>>> >>
>>> >> The OTP-flow (called Solution 1b in the committee) is= a mix of OAuth device-flow and authorization code flow. Since we want to a= void asking utilities to implement complex authorization interfaces (proble= m #2 above), the client asks the utility to send the user_code directly to = the user (via text/phone/email), then the client asks the user for the user= _code and submits it to the utility to get an access token.
>>> >>
>>> >> Also, there is an initial step of identifying (but no= t authenticating) the user and determining the way in which the OTP code sh= ould be sent. If utilities are given some sort of non-secret user identific= ation (e.g. address, phone number, account number, etc.), they should be ab= le to send a user_code to the user that the user can give to the client for= authorization. Hopefully, this can shift most of the complex UI/UX develop= ment cost away from the utility and onto the third party clients.
>>> >>
>>> >> Unfortunately, the energy industry can be quite behin= d on the latest and greatest OAuth developments, but we're trying to ge= t better :)
>>> >>
>>> >> Thanks very much,
>>> >> Daniel Roesler
>>> >> daniel@utilityapi.com
>>> >>
>>> >> _______________________________________________
>>> >> OAuth mailing list
>>> >> O= Auth@ietf.org
>>> >> https://www.ietf.org/mailman/listin= fo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>>
>>
>> --
>> nov matake
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
>
> --
> Dave Tonge
> CTO
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1= 6FL
> t: +44 (0)117 280 5120
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y Limited which is authorised and regulated by the Financial Conduct Author= ity ("FCA"). Moneyhub Financial Technology is entered on the Fina= ncial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub = Financial Technology is registered in England & Wales, company registra= tion number=C2=A0 06909772 .
> Moneyhub Financial Technology Limited 2018 =C2=A9
>
> DISCLAIMER: This email (including any attachments) is subject to copyr= ight, and the information in it is confidential. Use of this email or of an= y information in it other than by the addressee is unauthorised and unlawfu= l. Whilst reasonable efforts are made to ensure that any attachments are vi= rus-free, it is the recipient's sole responsibility to scan all attachm= ents for viruses. All calls and emails to and from this company may be moni= tored and recorded for legitimate purposes relating to this company's b= usiness. Any opinions expressed in this email (or in any attachments) are t= hose of the author and do not necessarily represent the opinions of Moneyhu= b Financial Technology Limited or of any other group company.


--
=
Dave Tonge
CTO
Moneyhub Finan= cial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial Condu= ct Authority ("FCA").=C2=A0Moneyhub Financial Technology is enter= ed on the Financial Services Register=C2=A0(FRN=C2=A0809360) at fca.org.uk/register. Moneyhub=C2=A0Financial Technology is reg= istered in England & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
Moneyhu= b=C2= =A0Financial Technology Limited 2018=C2=A0=C2=A9

DISCLAIMER: This email (including any at= tachments) is subject to copyright, and the information in it is confidenti= al. Use of this email or of any information in it other than by the address= ee is unauthorised and unlawful. Whilst reasonable efforts are made to ensu= re that any attachments are virus-free, it is the recipient's sole resp= onsibility to scan all attachments for viruses. All calls and emails to and= from this company may be monitored and recorded for legitimate purposes re= lating to this company's business. Any opinions expressed in this email= (or in any attachments) are those of the author and do not necessarily rep= resent the opinions of Moneyhub Financial Technology Limited or of any othe= r group company.
--000000000000873231057f946856-- From nobody Wed Jan 16 07:00:05 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392A81294FA; Wed, 16 Jan 2019 07:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154765080316.29478.13591232888419061055.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2019 07:00:03 -0800 Archived-At: Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 104 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 15:00:03 -0000 A new meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme tls rats Second Priority: ace secevent teep suit core tokbind saag sipcore People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 16 07:19:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089FB130E57 for ; Wed, 16 Jan 2019 07:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 ViVxYb55-Vki for ; Wed, 16 Jan 2019 07:19:21 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00041.outbound.protection.outlook.com [40.107.0.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C491294FA for ; Wed, 16 Jan 2019 07:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ku9CuxAgWipwqCDp/rmPYksyUi/YQGEDOH0N0nzOhiI=; b=MSTdoc8LsnHeayqJ+AWEnKhKHnZ5sk8sCWczXT2qKL+3Uq/VIhr4+eXBz22s4UrkCDV+tv38xmo5zVL/YGFFBAFdpoJbCkxd/gQYbprBEKivoh1oBJN5zFHPJ4uiB5vFD/VDqtdLJV+GUANzQQUT429Z+g3CgJ1Bwp7xa+fub40= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1263.eurprd08.prod.outlook.com (10.167.197.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Wed, 16 Jan 2019 15:19:18 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::ec48:f7db:ee6d:c60%2]) with mapi id 15.20.1516.019; Wed, 16 Jan 2019 15:19:18 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Fixed "OAuth WG Virtual Office Hours" Conference Bridge Thread-Index: AdStrkV/mvrQ2bD1Rb+TFqoDC16DXA== Importance: high X-Priority: 1 Date: Wed, 16 Jan 2019 15:19:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1263; 6:8q7t7s6/OV9OfAPJHlcbB8/xzr1SXxRKGFMoGSPNLauy0SB6CgG6KUbbJ5oq2WWaizdUDz9MFg3mAMNDpXp0nmgm50gYaO77bV3zh0km4DTSsi+3ERU9zzjRIu6qI/3BitVNe9puDPD/C4ZlUlSkdKS73HRup8SOcbMNWW+p4pCyEYkWvBfeLkYjTDXI6r/6pyN8IHl1bNIjIpqI0TqRGjBmWR6egeo+uaeWVGdjaopo5WvQ0hG2kspm+S/Q8hWLMGlu0WF/M2mUGRrhThz9rrUxUCHhic3qhDILZFXzFLKKbI3qEkwT564tDS014hu8AC05rZ3BfdkCYzoH6STXhaoTNPqyp/KutxwKmirUPs0TIprXzspEG/5uaLUwcw9M0CcwbKEJD2wIpJuzJCCFmEeoiID2TArwJE7cIMRUku0ivIrPaWaTLr8UmWkXCahek8JswXI+IWv1B752w2o2FA==; 5:Ayr72D9EjGUkhbzQmRGjcKunXQyxx932KJsumbs+9+D6CxDXUJdoZ7ptgi5YNXWYw6URKoXlixpLCcdozMEDydWtGywGzZFBs8sj2MP1Li5sLL9ottAuLJZlQJbmRl4D2xybqk+WOhgDgIhmku45AyTFaOrG+11EuPfeGlxWkVRRAjBjz2cRGCOo9zdRaXos35nJ7jceMs8ffWz/L/AdnA==; 7:OgsGQGk1pJQjyJPGQg9194qW+GAYe+gK/qzX2pXyr4yW9QpxJiKqejQ5M1h0Mm0z4NmpnKTJeUl1PE9qjdMzA3Bor9XaDomplZyDvsomN8IHEespsGzo9A9O8IBrrFAnrj7Ryq4dvd/ncBwrgDJMMw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 66b5b660-2d44-4d01-5c9c-08d67bc5fc12 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0801MB1263; x-ms-traffictypediagnostic: VI1PR0801MB1263: x-microsoft-antispam-prvs: x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(346002)(366004)(396003)(38314003)(53754006)(13464003)(199004)(189003)(40434004)(99286004)(105586002)(106356001)(7736002)(68736007)(66066001)(316002)(6116002)(33656002)(305945005)(9686003)(3846002)(256004)(14444005)(5024004)(99936001)(25786009)(5660300001)(53936002)(6916009)(97736004)(74316002)(8676002)(4744005)(186003)(81156014)(81166006)(102836004)(2906002)(8936002)(55016002)(45080400002)(86362001)(486006)(71200400001)(476003)(478600001)(71190400001)(14454004)(81686011)(6436002)(6506007)(53546011)(72206003)(7696005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1263; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6608YKf2DQLIOZ4T6pevhV4DbGe2C2YIMjHJQD4jOxVEcBm/g0rUq9U4uoV+hgGfBaMJRkwsZ7lu2TMCi5FnVATH9uxKH1YHBA+23PdthiHotoi3NFTtblI4xHtUeSYLO8UOvaSBRVZdrsz732pvlfFGTxMoHFPZspq19IA1EEnESBXabqFgX5tSFNThTbvu+r2u/DfFg4KAkqRgkCusQ1TSoJhlCbEENOBBlnld+biK9C8fXAM+ppPC4eMJb1gB9uuDi5Tj3nSlMNnH3cV/EKuurXrcWOSosHzvcZ69uct041sl4k2XPzDKhIlTh8yEMS6psbJUeLHLOqO5Gu3nOSH3DeNoLsIggKDnMYVakhf+srvVSG0IwTQaW2FI4z5RhmSxUecCeUqetljUDAhmqZmSxY9xSNq4cugNpo8Oy/8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_VI1PR0801MB2112CF106BFD0726127421B6FA820VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66b5b660-2d44-4d01-5c9c-08d67bc5fc12 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 15:19:18.6288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1263 Archived-At: Subject: [OAUTH-WG] Fixed "OAuth WG Virtual Office Hours" Conference Bridge X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 15:19:24 -0000 --_002_VI1PR0801MB2112CF106BFD0726127421B6FA820VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rifaat noticed that the distributed Outlook calendar invite was incorrect. Here is the corrected version. Ciao Hannes -----Original Message----- From: Hannes Tschofenig Sent: Montag, 14. Januar 2019 18:24 To: oauth Subject: Updated "OAuth WG Virtual Office Hours" Conference Bridge Hi all, Please update your meeting invite for the "OAuth WG Virtual Office Hours" c= onference call. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_002_VI1PR0801MB2112CF106BFD0726127421B6FA820VI1PR0801MB2112_ Content-Type: text/calendar; name="OAuth_Webex_Meeting.ics" Content-Description: OAuth_Webex_Meeting.ics Content-Disposition: attachment; filename="OAuth_Webex_Meeting.ics"; size=3529; creation-date="Wed, 16 Jan 2019 15:14:59 GMT"; modification-date="Wed, 16 Jan 2019 15:18:17 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTcxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE3MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApDTEFTUzpQVUJMSUMKREVTQ1JJUFRJT046 XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bWE5MTA5YjQ5MjMxZWYzZmVlNTI3YmJjMjRiNmEyODViXG5NZWV0aW5nIG51bWJlciAo YWNjZXNzIGNvZGUpOiA2NDMgMTQ4IDU0OFxuSG9zdCBrZXk6IDMxNzA4NlxuTWVldGluZyBwYXNz d29yZDogQldzQUY5clRcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkgXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhv bmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDMxNDg1NDglMjMlMjMqMDEqXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250 YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tY1xuXG5cbklN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlvciB0byByZWNvcmRp bmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj4JCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW1hOTEwOWI0OTIzMWVmM2ZlZTUyN2JiYzI0YjZhMjg1YiI+PEZPTlQgU0laRT0iMyIg Q09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYmV4IG1lZXRpbmc8L0ZPTlQ+PC9h PgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQzIDE0 OCA1NDg8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJPHRhYmxlPgkJCQk8 dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5Ib3N0IGtleTogMzE3MDg2PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxl PgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QldzQUY5clQ8L0ZPTlQ+PC90ZD48L3RyPjwvdGFi bGU+CQk8L0ZPTlQ+PGJyPjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZPTlQ+PGJy PjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD48 Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjxhIGhyZWY9J3RlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0MzE0ODU0OCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBB RkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz4xLTY1MC00NzktMzIwODwvYT48L3N0cm9uZz4m bmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PC9G T05UPjxCUj48QlI+CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj4JCQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBB RkY5IiBGQUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4m bmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBP UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3Mg YXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJl IHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZ b3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5n IGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLjwvRk9OVD48L0ZPTlQ+CkFUVEVO REVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIjtST0xFPVJF US1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWlyc0BpZXRmLm9yZwpEVFNU QU1QOjIwMTkwMTI4VDE3MDAwMFoKVUlEOjIwNDVkMzU3LWZlNzgtNDkwYS1iOTA0LTU2MGRjN2Fl MzYwMgpQUklPUklUWTo1CkRUU1RBUlQ7VFpJRD0iRXVyb3BlIFRpbWUiOjIwMTkwMTI4VDE4MDAw MApEVEVORDtUWklEPSJFdXJvcGUgVGltZSI6MjAxOTAxMjhUMTgzMDAwClJSVUxFOkZSRVE9V0VF S0xZO0lOVEVSVkFMPTI7QllEQVk9TU8KU0VRVUVOQ0U6MTU0NzY1MTkwNQpTVU1NQVJZOk9BdXRo IFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzClRSQU5TUDpPUEFRVUUKT1JHQU5JWkVSO0NOPSJ3ZWJl eCI6TUFJTFRPOm1lc3NlbmdlckB3ZWJleC5jb20KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRFU0NS SVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --_002_VI1PR0801MB2112CF106BFD0726127421B6FA820VI1PR0801MB2112_-- From nobody Wed Jan 16 13:32:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089271311A1 for ; Wed, 16 Jan 2019 13:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 aqLsNgLNCu3R for ; Wed, 16 Jan 2019 13:32:43 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7541311A7 for ; Wed, 16 Jan 2019 13:32:40 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id c9so4887201itj.1 for ; Wed, 16 Jan 2019 13:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QXuj20vnQpfAp4SfL3PU77REfC447BUFXMFDriUiYf0=; b=AKhNErzhk6peLkK5fNIj6joZ7g3S2wLNXWMYyQS7/i2hdQVf5Fdju01HfcdBPuc3qs Cu98acXLot2vxpwIIYcJdTgktvWqcFT7VEqpfgyekIV6CZp9QKHkZHtHrHLQeg4Lqn45 j3zQQczbLw7K3hA1BNSKrKqyrjgSfsOTCwQguOJBK9blsc7q+5AD9JqeriOzbP9PJWYX jJKtcEPEbqxMBkXTtL0MsKVSK9WH2hXl1ye/38sKLjfnxLmngmQCAFBiTwn/wbanD1zY CrN63cE8Zau29Ka9bS1AZG6du8iNKwdmfmUYTtrYEGIEF95L/YP/UBWQrrMTICTmEmax Jh3w== 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=QXuj20vnQpfAp4SfL3PU77REfC447BUFXMFDriUiYf0=; b=Pc9lNZWrobB6fs9WojEs8DmFUe8UwcljRPt418+gWzvbgpPcigglsnOAbVug7xJKk2 4RopvgiyTLwmbXxYhkD/eKgkd+XZeESMvWzHhPaJ61GMgWKW6nhGV8HvN1Z2ysKfCaXs jHhgkKZshXZigJpXKgXGzogNJTlqeBzc+RJ3emIq+2fjUvy5RC+u4BUSHcoBfswvlKz9 XS3uYhe8HqbKdeL2E5iHvgNP/44qeNNnKsffnFksGj9u/eIkAQmzHcj1dVJ3KsaVihgS +YIcpDaek+gB2II/qDGggIZ513XE1qZ9EJVG9CIvkdx7DPo5keEPTa0suFBX5UiLXTcp xRKQ== X-Gm-Message-State: AJcUukde2d0Jw1e9AaSpYwuDGLHdSktUkf7cx58fqmSBgQN9oM6n7+Mu 1PxnV2y+Mw5V+0a7OLL0tcYIZxcp9Kr2i+yr4zuNO6pF8TA= X-Google-Smtp-Source: ALg8bN7T56bbJz05bLl7usPPOsKB622GImEa/a+j80zFhdqzNXzQLOjxlnJfMkW5QxAHaeJFtT8aDpPBphEUFzR6/pA= X-Received: by 2002:a02:b529:: with SMTP id l38mr5954963jaj.25.1547674359798; Wed, 16 Jan 2019 13:32:39 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Wed, 16 Jan 2019 16:32:28 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000071a43a057f9a0473" Archived-At: Subject: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 21:32:45 -0000 --00000000000071a43a057f9a0473 Content-Type: text/plain; charset="UTF-8" All, The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document. https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ Please, take a look and let me know if I missed anything. Regards, Rifaat --00000000000071a43a057f9a0473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

= The following is the first shepherd write-up for the=C2=A0draft-ietf-oauth-= resource-indicators-01 document.

Please, take a look and let=C2=A0me kn= ow if I missed anything.

Regards,
=C2=A0= Rifaat

--00000000000071a43a057f9a0473-- From nobody Wed Jan 16 13:51:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF8D130ECE for ; Wed, 16 Jan 2019 13:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QhseftM9S9TY for ; Wed, 16 Jan 2019 13:51:24 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40290130ECA for ; Wed, 16 Jan 2019 13:51:24 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id r62so4528336oie.1 for ; Wed, 16 Jan 2019 13:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ut+SQI8XMMm+cpm1hIrb7irmwDhFOSCZPyqtKleDb8Q=; b=C/iq6/k2g4ef6N5wZ6FTJyr4KvsjpIfahARlWXtXN0OI+INCexQcvSvfTWKj+Z8vVp oTGkCA3I3Fvljv/6x4Y7cdWiQnuKsNvSb7n8J1gz03cFNW6Zgh2GRUuB3B3PO8EW6AtY 52UnVQreSCAxN/b2TVn/qpLu3FX1I0BbiS3xQ3xIOrBbSt4ls39CSFSX32T2ysFiCve2 8/Rrszg8R+X04IiE2QmE5qvRJabPI3jq9WBDv6uZnz9VLLGExqwrQlEMFY943jAoUp2o r6CjFsz5hjoHFfxwEgeNpvQdioU3X7wNEqaULLf1rLnS6CLsuRkbyUmEfRuXfzXudJL5 CsTA== 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=ut+SQI8XMMm+cpm1hIrb7irmwDhFOSCZPyqtKleDb8Q=; b=d5P9FPHPo8RTyaXXgXjj2hlyqzAHeielErqyBY8KULRoE/WH4rld3KbGvYuavHf8Zp fVRsCTdUfbNhx6UlvsqO5JOlzxJAtnxVHR1or5/GlR+EfMRY+dz+J2+JOYnORLHRJEAO AGTcYEcd2H1EdXsKHjX2ISoYxQZoGhBhlX4QZhbU/HPB4G8WJgZWtiedRXrhYuSfFi+t MEVV4P4fzGn8mPIuSCO5g8ff33x6dbraCzkA273MMYE5Wc6uupQqp1AApSrLupp0ItEt 9ir+nayCAzB1yXBXB81QQ9dlWi4scgKlWCaaBLGH1vZRdBu3U7PHVZ+rJJ4vqHB2ipWn Hncg== X-Gm-Message-State: AJcUukcI/8kaY+9htflB1S9dUOZKEl/WCr4QGQ8aFH7VgPklRTyX9a4o j9QGC7HVw7quBIaXv12GeX3CFnhhQMo2a64s/Q== X-Google-Smtp-Source: ALg8bN7VtQcbaU1Vb28SXDhTeUl8p5w/c5wH8HE8y+0ChSLCAb6PuBsIbVk6UzUoLDXl85Jo4qSuCLg4dU9DTkWRxKk= X-Received: by 2002:aca:5987:: with SMTP id n129mr3513944oib.174.1547675483503; Wed, 16 Jan 2019 13:51:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Wed, 16 Jan 2019 22:51:12 +0100 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000006c00b0057f9a471f" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 21:51:27 -0000 --0000000000006c00b0057f9a471f Content-Type: text/plain; charset="UTF-8" Hello Rifaat, The Auth0 link points to a different implementation. Here are two correct entries replacing the one you wrote down. So * Auth0 has an implementation but with a different parameter name ("audience"): https://auth0.com/docs/api/authentication#authorize-application * Node.JS Open Source oidc-provider implements the draft in full https://github.com/panva/node-oidc-provider/blob/master/docs/configuration.md#featuresresourceindicators Sorry if my message caused confusion before. S pozdravem, *Filip Skokan* On Wed, 16 Jan 2019 at 22:33, Rifaat Shekh-Yusef wrote: > All, > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, take a look and let me know if I missed anything. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000006c00b0057f9a471f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello R= ifaat,

The Auth0 link points to a different implementati= on. Here are=C2=A0 two correct entries replacing the one you wrote down.

So

* Auth0 has an implement= ation but with a different parameter name ("audience"):
=

* Node.JS Open Source oidc-provider implements = the draft in full=C2=A0

Sorry if my= message caused confusion before.

S pozdravem,
Filip Skokan


On Wed, 16 Jan 2019 at 22:33, Rifaat She= kh-Yusef <rifaat.ietf@gmail.com= > wrote:
=
All,

= The following is the first shepherd write-up for the=C2=A0draft-ietf-oauth-= resource-indicators-01 document.

Please, take a loo= k and let=C2=A0me know if I missed anything.

Regar= ds,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000006c00b0057f9a471f-- From nobody Wed Jan 16 13:53:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014061311BF for ; Wed, 16 Jan 2019 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 C6AH-LRIcEDo for ; Wed, 16 Jan 2019 13:53:41 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A011311BD for ; Wed, 16 Jan 2019 13:53:41 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id m62so5602446ith.5 for ; Wed, 16 Jan 2019 13:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fIspTl6sg/RX37J5d91Er3bE7Pn+XdInFZt0sdz+aUw=; b=vgSQr4EoS+u3r17t+2lx/IWD2V7huk+jsTIu/M9hethLNuZmBXKaA2wOt9snV2/HN7 +EdLDnkSlsqOuPT/uh1uDPj8DL9yBYhxfNZaeL/mw4Z90K4MgWZ/0LO588ymNL0Y0M0K SJewX4frdAsifishF64iF5dYlQCtlZCC29M1YhMUink8u/6J8Db4eVPlmnZdaLn8zI1B QZE/YhcaXqkLGI87FLfCQzPxzjWPXn/fyKger++dR1UiaI7CH94JxYivwq6LKbN5O+Gi wQPZtsspVdTdAcCEkhbyWa3JpzShPaYKSG2aVHizhYcyJP7y2p8+sCTmE70Iy8YSZPqH Myfw== 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=fIspTl6sg/RX37J5d91Er3bE7Pn+XdInFZt0sdz+aUw=; b=HFqgZnzQYDbw9FR1v4wboyOwSQO22ea7F+DVNaZzPk2kvAneDNE494MADFtwP/DBT0 JIfBqDeeCzELIUR2GHSZwsUcIE/o0lBPQlv/eROXtbEFRmn2jLMUz6TUcLZL+PR64RHQ 1bwU1MibLz8MLP9E+6BTkWgo93PlvzdN8p71FCTxvU+VijFHPtQaeVlrZGsGepGXTTGi TUJc0K+PVWFg51w41cBdJkZbGqYLXk3DzFDkmaWrT0G5fEv6/08yvaJAubSEYS1Ix526 5ovE2C/0a/zEzypk2NjzQXfsTjnBn0y59HQYWVB8BSwDqGTsXVo2c1A3CdQCp1hE1iSn sRDA== X-Gm-Message-State: AJcUukdLOkZzh1i4tf9SKifn14xP7+zBjKEsbqkm7XacSkup26cUYFJl GCLEe2Stz1ZGfAWoi0+dl3htp7kmwic2gN48e/1uR1cF X-Google-Smtp-Source: ALg8bN4Aeq4nOJtQDWN9meEAwCiHV9si34nrurzak/c08x0zqU7n6pIHsHeMMawNLiZgXX+Plva4EI4AqMOdyWpxrNQ= X-Received: by 2002:a02:8785:: with SMTP id t5mr6690487jai.73.1547675621054; Wed, 16 Jan 2019 13:53:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 16 Jan 2019 16:53:30 -0500 Message-ID: To: Filip Skokan Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009edb52057f9a4ff3" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 21:53:44 -0000 --0000000000009edb52057f9a4ff3 Content-Type: text/plain; charset="UTF-8" Thanks Filip! I will update the write-up accordingly. Regards, Rifaat On Wed, Jan 16, 2019 at 4:51 PM Filip Skokan wrote: > Hello Rifaat, > > The Auth0 link points to a different implementation. Here are two correct > entries replacing the one you wrote down. > > So > > * Auth0 has an implementation but with a different parameter name > ("audience"): > https://auth0.com/docs/api/authentication#authorize-application > > * Node.JS Open Source oidc-provider implements the draft in full > > https://github.com/panva/node-oidc-provider/blob/master/docs/configuration.md#featuresresourceindicators > > Sorry if my message caused confusion before. > > S pozdravem, > *Filip Skokan* > > > On Wed, 16 Jan 2019 at 22:33, Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >> >> Please, take a look and let me know if I missed anything. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000009edb52057f9a4ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Filip!

I will update the wr= ite-up accordingly.

Regards,
=C2=A0Rifaa= t


On Wed, Jan 16, 2019 at 4:51 PM Filip Skokan <panva.ip@gmail.com> wrote:
Hello Rifaat,

The Auth0 link points to a different implementation. Here are=C2=A0 two = correct entries replacing the one you wrote down.

= So

* Auth0 has an implementation but with a differ= ent parameter name ("audience"):
https://auth0.com/docs/api/authentication#authorize-application

* Node.JS Open Source oidc-provider implements the d= raft in full=C2=A0

Sorry if my message caused confusion before.

=
S pozdravem,
Filip Skokan


On Wed, 16 Jan 2019 at 22:33, Rifaat Shekh-Yus= ef <rifaat.ie= tf@gmail.com> wrote:
All,
The following is the first shepherd write-up for the=C2=A0draft= -ietf-oauth-resource-indicators-01 document.

Please, = take a look and let=C2=A0me know if I missed anything.

=
Regards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000009edb52057f9a4ff3-- From nobody Thu Jan 17 05:19:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1271276D0 for ; Thu, 17 Jan 2019 05:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNgdX6i4WzXS for ; Thu, 17 Jan 2019 05:19:09 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866A8126C7E for ; Thu, 17 Jan 2019 05:19:09 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id a16so7765013lfg.3 for ; Thu, 17 Jan 2019 05:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdmXa9yVOUqCoXXzlEpvjUcLlnH1adJ5b3dtbTOmkPE=; b=RHE8AIjG4PqRiN8odJWMKg2InmIIO0JaU94q8kxlVai7+XK/cvqZaP5cyvHoiuIaZx ElCpWsstBLEmGw4PLHYeRYrKgZ0L56DITYd8roamtH0mcyPxAS3XzZbAo247yA3oyHuU 3BHXzwyJuFPMc+0OGiE4v2Lrlp2GQHQGC/9OnJkHJfYqVeBlXaZpiB1fjJq9B/arfofi gGczxDuvTJt5iDJQb+3xGTNnlZBuCSwsiy6lucKhZiamlJajr4ujnbb8fcgxl7HznOTm sEw4DoEf60jKCfrlWKfjS/wOvhWYjSYBmyQJCL0kFLVQcHU/AUcm9Kq49X5MKi9kkN8m pmkQ== 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=jdmXa9yVOUqCoXXzlEpvjUcLlnH1adJ5b3dtbTOmkPE=; b=hb94MGv7RjqnUmz8wqIAnsAPK+Czgu/sSnVAKULx/8V7V6MSLEOUm6yz3TjXk2gFNl uhUIfJ6A+SXNTJVaPub8vnsgIguO62O64l8NRU2qteZZh3RW5I5ZBCmsK21MvFPhVPFc XJZB3bK0QqPusjr2ghqtdZZWN6k+A0uziMK0wOUD17EebOxvF/T45o+GcXz9K7u+jteQ f4k9cTBRGr1PCQCk6yjJsQ4WKw1LPPgZqI6obBUawTmyQUOnRFmlhkBTr/Vlumfu1doU uy6Mn+q/oct1kHqgoxIMHMGWGf4C0Uh5w/S4zi9e3edrvuF+xMrFanyEz/SULSu26t0E XwHQ== X-Gm-Message-State: AJcUuke3Zyqyxbfm5lPsdUe2snHIHCCvGO8ca2No3RWT3KG823LS0KPc jM6pRg3pxXei8/P8Fzy+yKbkU4RSN1L8EX6nFUFrBw== X-Google-Smtp-Source: ALg8bN5mm4WyiPEbD9cETRu1uqHqqv5ojONUI4WXdJZoqQ8mmYz8u4w4RswvzNT6Bcf1UnPQfpnkhV1jxhoaxNmjqa8= X-Received: by 2002:ac2:4116:: with SMTP id b22mr10560458lfi.19.1547731147401; Thu, 17 Jan 2019 05:19:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Thu, 17 Jan 2019 10:18:55 -0300 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="00000000000040046e057fa73d13" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 13:19:12 -0000 --00000000000040046e057fa73d13 Content-Type: text/plain; charset="UTF-8" Hi Rifaat, one detail. The tech summary says An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the *location* of the protected resource(s) to which it is requesting access. But at least in the Microsoft implementation, the resource identifier doesn't *have* to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc). Same for Auth0, the audience parameter is a logical identifier rather than a location. On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef wrote: > All, > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, take a look and let me know if I missed anything. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000040046e057fa73d13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rifaat,
one detail. The tech summary says

An extension to the OAuth 2.0 Authorization Framework defining re=
quest=20
parameters that enable a client to explicitly signal to an authorization se=
rver=20
about the location of the protected resource(s) to which it is reque=
sting=20
access.
But at least in the Microsoft implementation, the r= esource identifier doesn't have to be a network addressable URL = (and if it is, it doesn't strictly need to match the actual resource lo= cation). It can be a logical identifier, tho using the actual resource loca= tion there has benefits (domain ownership check, prevention of token forwar= ding etc).
Same for Auth0, the audience parameter is a logical id= entifier rather than a location.


<= br>
On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <<= a href=3D"mailto:rifaat.ietf@gmail.com" target=3D"_blank">rifaat.ietf@gmail= .com> wrote:
All,

<= div>The following is the first shepherd write-up for the=C2=A0draft-ietf-oa= uth-resource-indicators-01 document.

Please, take a l= ook and let=C2=A0me know if I missed anything.

Reg= ards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000040046e057fa73d13-- From nobody Thu Jan 17 09:56:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5849130EBB for ; Thu, 17 Jan 2019 09:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iz1L-mlXn7Ho for ; Thu, 17 Jan 2019 09:56:44 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A7B130EB5 for ; Thu, 17 Jan 2019 09:56:43 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id r200so8501733iod.11 for ; Thu, 17 Jan 2019 09:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Azyyg0b8jTtm11nOcJjCrMaodXaWp+9tUruM/csifz8=; b=HbBmMxMc/5SGL6Ze5EETCZSrQ/zcK/un+iK/CMoQgo3/suhojOQLstkQ4tHa6cVs9H NnJU2MNxkaRTXJ/wHVCgCpOlIY3q/AJJ4os4GBubatd3u6iBjjnzL/BBhBZ+iJ8TULcM 83elaGJyxysDO5IgSxnhbRt8/CrzhlLtpNcoZh9foeDmoRhKNHpvp4cvUA62l7hoN5nx rYxWVSX1LKmSfOUYsjT31ZKYninUu4ii55AgnaZgAabaLQPVes44TXJga5mfb/pfCt03 kLLxAafu1iyfOzdIIRlowb3x7s2ACnwGU5rSEMzyslmcTDbb1aGrdDb3SPlk7rQ+Phnc A/Iw== 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=Azyyg0b8jTtm11nOcJjCrMaodXaWp+9tUruM/csifz8=; b=E5JffmSGo6YpMVZXLj31UpInKph1Iy9g8ZGKJvaMU1v/r/GciUcf+wvBY+4PZAip3s UGlKxtY+7/QTKMsLamy59ZZnsEiCMqMNNiqThNa5SDReScbK3D0+X/WmSFkIUXlh2AG8 eSgColL2Jv+aR6kumebI2vZFQC9u7I3xho5Kmf1OXevbkiLbUNdbGDa+tIKZ4bpznSJg bMDdhlfQSkJGtkG7iZ8Rb8XQjzzZk5K0fe7zghB/9dN/+OXyvfYxP52uDYcf+sej0T1V QMSBfBL4mgndvG8Z/k/vZlxKGUBx34I+s78Ex93gyJ1JJKmMtcj/OB6eJHoDv6JhXp/p 64Jw== X-Gm-Message-State: AJcUukedmM1NrUI7692VSpZyqGA3adNjJ03mYoIOTaOg4gdHWKVH2+HN kwPmIPmRpwlArwuR0BeiJIW+So5lnzpHw5zBbWE= X-Google-Smtp-Source: ALg8bN5GwYx28mtfY3YRuuZ99jBsRqCEiqhF3i0O5OFpw3+pYTy7DEkcdDM/bbT8dni6MKDxhQQh9j0tANqO3YQ4Ln8= X-Received: by 2002:a5d:904b:: with SMTP id v11mr8956076ioq.0.1547747803092; Thu, 17 Jan 2019 09:56:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Thu, 17 Jan 2019 12:56:32 -0500 Message-ID: To: Vittorio Bertocci Cc: oauth Content-Type: multipart/alternative; boundary="000000000000015b91057fab1ede" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:56:46 -0000 --000000000000015b91057fab1ede Content-Type: text/plain; charset="UTF-8" Hi Vittorio, The text you quoted is copied form the abstract of the draft itself. *Authors,* Should the draft be updated to cover the logical identifier case? Regards, Rifaat On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci wrote: > Hi Rifaat, > one detail. The tech summary says > > An extension to the OAuth 2.0 Authorization Framework defining request > parameters that enable a client to explicitly signal to an authorization server > about the *location* of the protected resource(s) to which it is requesting > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > Same for Auth0, the audience parameter is a logical identifier rather than > a location. > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >> >> Please, take a look and let me know if I missed anything. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000015b91057fab1ede Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vittorio,

The text you quoted is cop= ied form the abstract of the draft itself.


=
Authors,

Should the draft be= updated to cover the logical identifier case?

Regards,
=C2=A0Rifaat


On Thu, Jan 17, 2019= at 8:19 AM Vittorio Bertocci <Vit= torio@auth0.com> wrote:
Hi Rifaat,
one detail. The tech summary= says

An extension to the OA=
uth 2.0 Authorization Framework defining request=20
parameters that enable a client to explicitly signal to an authorization se=
rver=20
about the location of the protected resource(s) to which it is reque=
sting=20
access.
But at least in the Microsoft implementation, the r= esource identifier doesn't have to be a network addressable URL = (and if it is, it doesn't strictly need to match the actual resource lo= cation). It can be a logical identifier, tho using the actual resource loca= tion there has benefits (domain ownership check, prevention of token forwar= ding etc).
Same for Auth0, the audience parameter is a logical id= entifier rather than a location.


<= br>
On Wed, Jan 16, 2019 at 6:32= PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

The following is the first shepherd write-= up for the=C2=A0draft-ietf-oauth-resource-indicators-01 document.
https://datatracker.ietf.org/doc= /draft-ietf-oauth-resource-indicators/shepherdwriteup/
Please, take a look and let=C2=A0me know if I missed anything.=

Regards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000015b91057fab1ede-- From nobody Thu Jan 17 11:31:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15785130EC8 for ; Thu, 17 Jan 2019 11:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vgr1qFebzvWg for ; Thu, 17 Jan 2019 11:31:55 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CAA130E93 for ; Thu, 17 Jan 2019 11:31:54 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id r14so12702689qtp.1 for ; Thu, 17 Jan 2019 11:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=e0QR4YDixrdrY9fzf+n4eAbLT2El1iDZGU/Y1+iPTUs=; b=H5F3J4t6xDUt+erSE03SN3FerdD71Nk3K62XYATSrGDJsRkzwAbmI87HYat7f6eP22 SJYg28n9sEoWXKe1Iy9u1DekK2cC5UkddsxCbelQ2mzu4mm66iW6biswdFANY6K2SyOS 8ikE4Wk6vboAwHZ88cQdPQssmSS2Yd7idxLAt2QTd4S8uNznJHXPVmRU2Hi4moqSPm2k GxxTrH/0TVpDigMkE6ZxWOxaijAbrqe6ddK/9jMFPutjhWm53yBtX9C4Z98F1hYu6BIM taHbaGf+xw5/LvXDzXE2cZo2rKz3w4sRgH5Cw5qjtd3FEVoNdUoIPcDwc0DGJhkYX9Ui G/Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=e0QR4YDixrdrY9fzf+n4eAbLT2El1iDZGU/Y1+iPTUs=; b=in7yqAsiVI07EzFyjhXhWg8Pf2QZMIH7h3reVUg5wxEt9eAP3Ei+yu8+xJ8/SjtE3Q /+NaFngoZXFgsCg+QSOmKa4etf+nHw1C8082EhKHwWDkqsK+fcGzDQXV/DShsIA4xyuY xrZRhtBGdgzHpqoZzi+EmDsIK22gMKzBRFNjKBJoSOZ/GG3eLf1MkTQTC/qQ0+Je5V2j Xntxs6J/mZ0BJFbYHPSOzz/eYVVVkzwVitPTw8CRCRUBEn8YUPohD98j3kVNMK/hIO9I OxG/tIkYZj5NcKcCMw8C3Ci2SjxRPvYqhbO0KeHSZTRgt7bfSOdZLFl+cvjKahkNoSSy iOQg== X-Gm-Message-State: AJcUukcZrJG4doaRFF2UaO3rGF9zskxsv+rZXXuAP6F2zO/3HdCUcbBD FjPOiZLj9KAZTyDkPf8FzgmYtHSTYm1eUcaT X-Google-Smtp-Source: ALg8bN5jQTKHmYbCqXEd8/3T5j1rARuJNkKUe9+XiBsqE9iWxrrAnMtTJs8HvpPp2yZRju0qyCyH/w== X-Received: by 2002:a0c:8936:: with SMTP id 51mr12753938qvp.220.1547753512684; Thu, 17 Jan 2019 11:31:52 -0800 (PST) Received: from [192.168.86.124] (ip-40-226-107-190.nextelmovil.cl. [190.107.226.40]) by smtp.gmail.com with ESMTPSA id o22sm24104139qkk.93.2019.01.17.11.31.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jan 2019 11:31:51 -0800 (PST) To: oauth@ietf.org References: From: John Bradley Message-ID: Date: Thu, 17 Jan 2019 11:31:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------424721D74FA0C3ACD2A7A805" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 19:31:58 -0000 This is a multi-part message in MIME format. --------------424721D74FA0C3ACD2A7A805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We have discussed this. Audiences can certainly be logical identifiers. This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT. From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is. If we were to change it, how a client would validate it becomes challenging to impossible. The AS is free to do whatever mapping of locations to identifiers it needs for access tokens. Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource. John B. On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > Hi Vittorio, > > The text you quoted is copied form the abstract of the draft itself. > > * > * > *Authors,* > > Should the draft be updated to cover the logical identifier case? > > Regards, >  Rifaat > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > one detail. The tech summary says > > An extension to the OAuth 2.0 Authorization Framework defining request > parameters that enable a client to explicitly signal to an authorization server > about the*location* of the protected resource(s) to which it is requesting > access. > > But at least in the Microsoft implementation, the resource > identifier doesn't /have/ to be a network addressable URL (and if > it is, it doesn't strictly need to match the actual resource > location). It can be a logical identifier, tho using the actual > resource location there has benefits (domain ownership check, > prevention of token forwarding etc). > Same for Auth0, the audience parameter is a logical identifier > rather than a location. > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > > wrote: > > All, > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, take a look and let me know if I missed anything. > > Regards, >  Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------424721D74FA0C3ACD2A7A805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.


Authors,

Should the draft be updated to cover the logical identifier case?

Regards,
 Rifaat


On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:
Hi Rifaat,
one detail. The tech summary says

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.
But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier rather than a location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

Please, take a look and let me know if I missed anything.

Regards,
 Rifaat

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------424721D74FA0C3ACD2A7A805-- From nobody Thu Jan 17 17:32:34 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E281D130F2F; Thu, 17 Jan 2019 17:32:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154777514588.10349.2255009841104302664@ietfa.amsl.com> Date: Thu, 17 Jan 2019 17:32:25 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 01:32:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-14.txt Pages : 22 Date : 2019-01-17 Abstract: This OAuth 2.0 authorization flow is designed for devices that either lack a browser to perform a user-agent based OAuth flow, or are input-constrained to the extent that requiring the user to input a lot of text (like their credentials to authenticate with the authorization server) is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources without using an on-device user-agent, provided that they have an Internet connection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 17 17:41:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD9131067 for ; Thu, 17 Jan 2019 17:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdbGYnUcqzaw for ; Thu, 17 Jan 2019 17:41:01 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0: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 CA610130F2F for ; Thu, 17 Jan 2019 17:41:00 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id h193so3847663ita.5 for ; Thu, 17 Jan 2019 17:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fpBlGixABAx4i30jAeEAFxRIyP3K+wUc/ZMFt9o3pHQ=; b=H7gwabJCBzE8FSniTRweSw0R3fUhZiSOY4+KQzTNcjbj3DcvodpAD8ljANdYROtdeY CHAL6KWvv1AE+gTziTqEaQ6XuKbK1EVUgIex1tbTaKDZWk86v7nz9GBa/ajL7bOGA+VN oh4aDlR5rIfSbrnnIESCKKKppwaiLMsTvNS1TLIdZeVqcKe5O34pIfxQEx7ymrdXyLRv DBIAjcEDViI8m9rPdw1px3TAVfHm3+jzP88iGhX9W8wN7AX/ryPNx9LSD8Ea3w+2r3NO ggxl31JE7iqTLbzmXijIklw0tdDEW0d6h08AHecpglJgwNC06tpHTyjx4L8BkGGvgjZx iTBw== 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=fpBlGixABAx4i30jAeEAFxRIyP3K+wUc/ZMFt9o3pHQ=; b=KXfq5j0/x755LYkV+EHwb6f+7NQHeuieiDTqPrqaAGbmVBOs01ZqoLIrw/tj4qG7qL wXD7TzjLxxBt+AkgcxhFUYa0NmUv3EnBNZMBwoiMEfs6EcFnywFKC3E6I/Tag89609lr kcDpkyygy3HhHGClfjnCC4EH7+hmRHLn6aEDViRcjVzRbWt7zP0HM1/LPYIphf1/DtUB 22/b1HW35LOdZOPYyTkwK/MdY51QAcWY4OIQyCpCma/kWSBTftsQeNcH5EN/fugv0Gr3 BqBmIimhDUE+OajnS8Ti0JL3jehCs/GGStMAvb3VP117em+LVG3K0Eucl5maUn7h9s9I OuKA== X-Gm-Message-State: AJcUukd5m1sOXk/A3UjSJ+KaWkFq0NpfdTB88q++8L99m01m7oeoAydq +9EdgcpbC1p3DhGCicvr/x35rcXj8jeYka6SJoZBKw== X-Google-Smtp-Source: ALg8bN535S0ws+CjKygWkRzIPPGg7WYFnW4ANbsgHrh2ZaTFYn7a/BVPMJPmy/nNcTFoXIZVI22lPKPY3PGNlMzApt0= X-Received: by 2002:a24:8d45:: with SMTP id w66mr9335448itd.137.1547775659699; Thu, 17 Jan 2019 17:40:59 -0800 (PST) MIME-Version: 1.0 References: <153315936951.22029.4751693198552667112.idtracker@ietfa.amsl.com> In-Reply-To: <153315936951.22029.4751693198552667112.idtracker@ietfa.amsl.com> From: William Denniss Date: Thu, 17 Jan 2019 17:40:48 -0800 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000063fd06057fb19ad1" Archived-At: Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 01:41:04 -0000 --00000000000063fd06057fb19ad1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Thank you again for your comments, and sorry for the delay. I believe they are all addressed now in version 14 . Detailed replies below: On Wed, Aug 1, 2018 at 2:36 PM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-oauth-device-flow-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Major Comment: > > I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I > have a > slightly different spin on it. The device polls the server while waiting > on the > user to take action. Users are notoriously slow about that sort of thing. > They > might plug in a device then walk away for hours, days, or forever. Now, > consider that we are talking about IoT devices, so there may be millions = of > them. If they are fate shared in some way (imagine shipping day for a new > popular product, or a software update that forces reauthorization, or a > server > coming back online after getting whacked the last time around), there > could be > millions of them trying this at the roughly the same time. > > Given all that, I think the draft really needs to give more detailed > guidance > on what sort of refresh rates, maximum attempts, expirations, back off > patterns, etc might be reasonable from both network congestion and server > overload perspectives. > > Added some text to address the requirement for user action: Due to the polling nature of this protocol, care is needed to avoid overloading the capacity of the token endpoint. To avoid unneeded request= s on the token endpoint, the client SHOULD only commence a device authorization request when prompted by the user, and not automatically such as when the app starts or when the previous authorization session expires or fails. And further down, added text on network timeouts: Clients on encountering a connection timeout MUST unilaterally reduce their polling frequency before retrying. The use of an exponential backoff algorithm to achieve this, such as by doubling the polling interval on each such connection timeout is RECOMMENDED. > Other Substantive Comments: > > =C2=A73.1: What sort of events are expected to trigger the flow? In parti= cular, > I > wonder if there should be guidance to make it unlikely to start the > process by > accident. For example, if the authorization process is kicked off by a > device > simply being plugged into power, a user might plug it in then walk away > before > realizing they had more to do. (See my major comment). > Good point. Added text that there should be a user action (see above). =C2=A73.3: What sort of bad thing could happen if the device_code is > communicated to > a user? Do implementers need to worry about people guessing device-codes= ? > Users discovering their own codes falls under client impersonation (clients being impersonated can also just request new device_codes). Added a section directly discussing device_codes in Section 5.6 Non-confidential Clients. The section titled "Device Code Brute Forcing" covers the guessing problem, Section 5.2. > > =C2=A73.3, last paragraph: The "NOT RECOMMENDED" seems overly strong, giv= en > that the > next section describes a perfectly good way to do exactly that. Maybe > something > like "NOT RECOMMENDED unless the device uses a non-textual mechanism for > conveying the URL and code, such as that described in ..." would make > sense? > This section was reworded, it currently has a NOT RECOMMENDED for including the user_code specifically in the `verification_uri`, and mentions that there is a designed way to do this as well. > =C2=A75.4: Are devices expected to know the operating environment in adva= nce of > deployment? > Generally yes. > Editorial Comments: > > =C2=A71, 3rd paragraph: The first sentence is hard to parse due the list = of > long, > complex phrases. Please consider breaking into simpler sentences. > That's done. > > =C2=A72: There are lower case instances of normative keywords. Please co= nsider > using the updated boilerplate from RFC8174. > Boilerplate is now RFC8174. Best, William --00000000000063fd06057fb19ad1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thank you again for your comments, and sorry for th= e delay. I believe they are all addressed now in version 14.
Detailed replies below:

On Wed, Aug 1, 2018 at 2:36 PM Ben Campbell <ben@nostrum.com> wrote:
<= /div>
Ben Campbell has ent= ered the following ballot position for
draft-ietf-oauth-device-flow-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-oauth-device-flow/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major Comment:

I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I = have a
slightly different spin on it. The device polls the server while waiting on= the
user to take action. Users are notoriously slow about that sort of thing. T= hey
might plug in a device then walk away for hours, days, or forever.=C2=A0 No= w,
consider that we are talking about IoT devices, so there may be millions of=
them. If they are fate shared in some way (imagine shipping day for a new popular product, or a software update that forces reauthorization, or a ser= ver
coming back online after getting whacked the last time around), there could= be
millions of them trying this at the roughly the same time.

Given all that, I think the draft really needs to give more detailed guidan= ce
on what sort of refresh rates, maximum attempts, expirations, back off
patterns, etc might be reasonable from both network congestion and server overload perspectives.


Added some text to address the require= ment for user action:

=C2=A0 Due to the polling nature of this protocol, care is need= ed to avoid
=C2=A0 overloading the capacity of the token endpoint= . To avoid unneeded requests
=C2=A0 on the token endpoint, the cl= ient SHOULD only commence a device
=C2=A0 authorization request w= hen prompted by the user, and not automatically
=C2=A0 such as wh= en the app starts or when the previous authorization session
=C2= =A0 expires or fails.

=C2=A0And further down,= added text on network timeouts:

=C2=A0 Clients on encountering a connection timeout = MUST unilaterally reduce
=C2=A0 their polling frequency before re= trying. The use of an exponential
=C2=A0 backoff algorithm to ach= ieve this, such as by doubling the polling
=C2=A0 interval on eac= h such connection timeout is RECOMMENDED.
=C2=A0
Other Substantive Comments:

=C2=A73.1: What sort of events are expected to trigger the flow? In particu= lar, I
wonder if there should be guidance to make it unlikely to start the process= by
accident. For example, if the authorization process is kicked off by a devi= ce
simply being plugged into power, a user might plug it in then walk away bef= ore
realizing they had more to do. (See my major comment).

Good point. Added text that there should be a user action (= see above).

=C2=A73.3: What sort of bad thing could happen if the device_code is commun= icated to
a user? Do implementers need to worry about people=C2=A0 guessing device-co= des?

Users discovering their own codes = falls under client impersonation (clients being impersonated can also just = request new device_codes). Added a section directly discussing device_codes= in Section 5.6 Non-confidential Clients.

The sect= ion titled "Device Code Brute Forcing" covers the guessing proble= m, Section 5.2.
=C2=A0

=C2=A73.3, last paragraph: The "NOT RECOMMENDED" seems overly str= ong, given that the
next section describes a perfectly good way to do exactly that. Maybe somet= hing
like "NOT RECOMMENDED unless the device uses a non-textual mechanism f= or
conveying the URL and code, such as that described in ..." would make = sense?

This section was reworded, it cu= rrently has a NOT RECOMMENDED for including the user_code specifically in t= he `verification_uri`, and mentions that there is a designed way to do this= as well.
=C2=A0
=C2=A75.4: Are devices expected to know the operating environment in advanc= e of
deployment?

Generally yes.
= =C2=A0
Editorial Comments:

=C2=A71, 3rd paragraph: The first sentence is hard to parse due the list of= long,
complex phrases. Please consider breaking into simpler sentences.

That's done.
=C2=A0

=C2=A72: There are lower case instances of normative keywords.=C2=A0 Please= consider
using the updated boilerplate from RFC8174.

=
Boilerplate is now RFC8174.

Best,
W= illiam

=
--00000000000063fd06057fb19ad1-- From nobody Fri Jan 18 05:46:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AB7126C7E for ; Fri, 18 Jan 2019 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBD5G6VduWXt for ; Fri, 18 Jan 2019 05:46:43 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EDE124BE5 for ; Fri, 18 Jan 2019 05:46:42 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id a8so10533387lfk.5 for ; Fri, 18 Jan 2019 05:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yFarQZNGKbj+LS3YqGRyZGqWFdcHsA3B1aqqvvshN+0=; b=eSH/XD0bTDycXRA730pNo3jP95MYKScCdJtcXQlkKBDKPwCbP9D0+sIuosUzUuo51L WEOFWGFcY1XID1ay5i60S2oG6N6oOHRmFde1KCFDMoufaDQ9UMGXUb9Sg42K1YYzPf96 3mSauB3fH0ACcjJjm/TTI+7cxUjZXOzklo6HzEreUjI7BJKkWfP677G41go1r6SKdr8G UXF+GXfJ0kHRw3kqvflNICoCElPBJYu3t4pXQYPiql+hxk7JpShiIU1IDAuQEx7ImdkM YOdpCKIEIz1WRiKMwxINOK4Fjg/0T3t19ZLKl4rf66WrD1Z445Ok8Icxp10tHdpWfPMd pG7w== 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=yFarQZNGKbj+LS3YqGRyZGqWFdcHsA3B1aqqvvshN+0=; b=L+wKOUydrbw1gNMiAzP+28x2DU2ZpLfkxAHH+RQKTYbpudgjGiy0SuFR1cs9eZoCiQ jJvEhyauEKh778IZhzLFRnEw6TBzOdmhtNYtr6RO80Z3FcQAkgRqnYuC/2MhNX5GKocc nkeZ9TYtBWzSbyQ9WXkNXA1/ZsADBA++4OsraKG2K8AYssmOquxt/B8W/54qL+7/70Ga P7O2WihE7tScoaHdOE/ieZhOxu3W8GN4xat2iFK+Zg6AVs963ZzgWgOR1FrhtCda3DZJ k5MZYcBHtJvaXay/vKtNXEwAQkNS9rIH1lIeCuZ08tbQLWm36FNnVEHsjXcnJ6P8yAkQ rk6A== X-Gm-Message-State: AJcUukdOgjTCK3l8IDskAjc59enGtjbhZ3o1T59uGEkXuk7FPyE2GNxi Za3ZfISOZaG9IF2gCqMWs9H2MfxqQrdjbDmYNzg3+n3H20U= X-Google-Smtp-Source: ALg8bN4zhYMntMKnVdkGEeNbO5Rg5JgYfJFklnhVPuX+LoHJnU7Ks7VgMNEQQE2M1NgXdB7DctSpizvQiaMUnfkV1gQ= X-Received: by 2002:ac2:53bc:: with SMTP id j28mr13257937lfh.86.1547819200216; Fri, 18 Jan 2019 05:46:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Fri, 18 Jan 2019 10:46:29 -0300 Message-ID: To: John Bradley Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000009b2171057fbbbd15" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 13:46:46 -0000 --0000000000009b2171057fbbbd15 Content-Type: text/plain; charset="UTF-8" Thanks John for the background. I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid. That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on. Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach. On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resource > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it needs > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > The text you quoted is copied form the abstract of the draft itself. > > > *Authors,* > > Should the draft be updated to cover the logical identifier case? > > Regards, > Rifaat > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > >> Hi Rifaat, >> one detail. The tech summary says >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> parameters that enable a client to explicitly signal to an authorization server >> about the *location* of the protected resource(s) to which it is requesting >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logical >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >>> All, >>> >>> The following is the first shepherd write-up for >>> the draft-ietf-oauth-resource-indicators-01 document. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >>> >>> Please, take a look and let me know if I missed anything. >>> >>> Regards, >>> Rifaat >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000009b2171057fbbbd15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks John for the background.
I agree that from the = client validation PoV, having an identifier corresponding to a location mak= es things more solid.
That said: the use of logical identifiers i= s widespread, as it has significant practical advantages (think of services= that assign generated hosting URLs only at deployment time, or services th= at are somehow grouped under the same logical audience across regions/envir= onment/deployments). People won't stop using logical identifiers, becau= se they often have no alternative (generating new audiences on the fly at t= he AS every time you do a deployment and get assigned a new URL can be unfe= asible). Leaving a widely used approach as exercise to the reader seems a d= isservice to the community, given that this might lead to vendors (for exam= ple Microsoft and Auth0) keeping their own proprietary parameters, or devel= opers misusing the ones in place; would make it hard for SDK developers to = provide libraries that work out of the box with different ASes; and so on.<= /div>
Would it be feasible to add such parameter directly in this spec?= That would eliminate the interop issues, and also gives us a chance to ful= ly warn people about the security shortcomings of choosing that approach.



On Thu, Jan 17, 2019 at 4:32 PM John Brad= ley <ve7jtb@ve7jtb.com> wrot= e:
=20 =20 =20

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to ma= p the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019= 9:56 AM, Rifaat Shekh-Yusef wrote:
=20
Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.


Authors,

Should the draft be updated to cover the logical identifier case?

Regards,
=C2=A0Rifaat


O= n Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:
Hi Rifaat,
one detail. The tech summary says

An extensio=
n to the OAuth 2.0 Authorization Framework defining request=20
parameters that enable a client to explicitly signal to an authorization se=
rver=20
about the location of the protected resource(s) to which it is reque=
sting=20
access.
But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need t= o match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier rather than a location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oau= th

= 
____________=
___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf=
.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000009b2171057fbbbd15-- From nobody Fri Jan 18 11:38:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC95B131355 for ; Fri, 18 Jan 2019 11:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.352 X-Spam-Level: X-Spam-Status: No, score=-16.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lrz9Nyvuz9u for ; Fri, 18 Jan 2019 11:38:17 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F1B13134B for ; Fri, 18 Jan 2019 11:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1547840297; x=1579376297; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QTeY345RDFDSJm4GlpglNJVNgILmqhvxov20B9s34gM=; b=nTGly4ooaTNctWR/a4LvwGM4Md/Z2/cQ+o6eBem02K/OQLXY+VdOmhTW xVcvoV62FUnmD/id8elj00Gft6Ep5dV6wX82h+/Jp7T8LKorDU2R8rqEA LFOhh1mZlbNs9fy2isbKkCuXSgWEOfm7FPq6jspHEkiOEZfqgU9UopdqY U=; X-IronPort-AV: E=Sophos;i="5.56,253,1539648000"; d="scan'208,217";a="777262748" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2c-c6afef2e.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 18 Jan 2019 19:37:34 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2c-c6afef2e.us-west-2.amazon.com (Postfix) with ESMTPS id 5AFC4A2151; Fri, 18 Jan 2019 19:37:21 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 18 Jan 2019 19:37:20 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 18 Jan 2019 19:37:19 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 18 Jan 2019 19:37:19 +0000 From: "Richard Backman, Annabelle" To: Vittorio Bertocci , John Bradley CC: IETF oauth WG Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMpatiX6VtuvkKr7hK5A7ThYaWzcp6AgABNkQCAABqbAIABMdyA///b7IA= Date: Fri, 18 Jan 2019 19:37:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.245] Content-Type: multipart/alternative; boundary="_000_F5D20367D6E440E8826070C91A9B1ECDamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 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, 18 Jan 2019 19:38:21 -0000 --_000_F5D20367D6E440E8826070C91A9B1ECDamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRlIGEgbWVh bnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj8NCg0KLS0NCkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQw YXV0aDAuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDE5 IGF0IDU6NDcgQU0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPg0KQ2M6IElF VEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2hl cGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w MQ0KDQpUaGFua3MgSm9obiBmb3IgdGhlIGJhY2tncm91bmQuDQpJIGFncmVlIHRoYXQgZnJvbSB0 aGUgY2xpZW50IHZhbGlkYXRpb24gUG9WLCBoYXZpbmcgYW4gaWRlbnRpZmllciBjb3JyZXNwb25k aW5nIHRvIGEgbG9jYXRpb24gbWFrZXMgdGhpbmdzIG1vcmUgc29saWQuDQpUaGF0IHNhaWQ6IHRo ZSB1c2Ugb2YgbG9naWNhbCBpZGVudGlmaWVycyBpcyB3aWRlc3ByZWFkLCBhcyBpdCBoYXMgc2ln bmlmaWNhbnQgcHJhY3RpY2FsIGFkdmFudGFnZXMgKHRoaW5rIG9mIHNlcnZpY2VzIHRoYXQgYXNz aWduIGdlbmVyYXRlZCBob3N0aW5nIFVSTHMgb25seSBhdCBkZXBsb3ltZW50IHRpbWUsIG9yIHNl cnZpY2VzIHRoYXQgYXJlIHNvbWVob3cgZ3JvdXBlZCB1bmRlciB0aGUgc2FtZSBsb2dpY2FsIGF1 ZGllbmNlIGFjcm9zcyByZWdpb25zL2Vudmlyb25tZW50L2RlcGxveW1lbnRzKS4gUGVvcGxlIHdv bid0IHN0b3AgdXNpbmcgbG9naWNhbCBpZGVudGlmaWVycywgYmVjYXVzZSB0aGV5IG9mdGVuIGhh dmUgbm8gYWx0ZXJuYXRpdmUgKGdlbmVyYXRpbmcgbmV3IGF1ZGllbmNlcyBvbiB0aGUgZmx5IGF0 IHRoZSBBUyBldmVyeSB0aW1lIHlvdSBkbyBhIGRlcGxveW1lbnQgYW5kIGdldCBhc3NpZ25lZCBh IG5ldyBVUkwgY2FuIGJlIHVuZmVhc2libGUpLiBMZWF2aW5nIGEgd2lkZWx5IHVzZWQgYXBwcm9h Y2ggYXMgZXhlcmNpc2UgdG8gdGhlIHJlYWRlciBzZWVtcyBhIGRpc3NlcnZpY2UgdG8gdGhlIGNv bW11bml0eSwgZ2l2ZW4gdGhhdCB0aGlzIG1pZ2h0IGxlYWQgdG8gdmVuZG9ycyAoZm9yIGV4YW1w bGUgTWljcm9zb2Z0IGFuZCBBdXRoMCkga2VlcGluZyB0aGVpciBvd24gcHJvcHJpZXRhcnkgcGFy YW1ldGVycywgb3IgZGV2ZWxvcGVycyBtaXN1c2luZyB0aGUgb25lcyBpbiBwbGFjZTsgd291bGQg bWFrZSBpdCBoYXJkIGZvciBTREsgZGV2ZWxvcGVycyB0byBwcm92aWRlIGxpYnJhcmllcyB0aGF0 IHdvcmsgb3V0IG9mIHRoZSBib3ggd2l0aCBkaWZmZXJlbnQgQVNlczsgYW5kIHNvIG9uLg0KV291 bGQgaXQgYmUgZmVhc2libGUgdG8gYWRkIHN1Y2ggcGFyYW1ldGVyIGRpcmVjdGx5IGluIHRoaXMg c3BlYz8gVGhhdCB3b3VsZCBlbGltaW5hdGUgdGhlIGludGVyb3AgaXNzdWVzLCBhbmQgYWxzbyBn aXZlcyB1cyBhIGNoYW5jZSB0byBmdWxseSB3YXJuIHBlb3BsZSBhYm91dCB0aGUgc2VjdXJpdHkg c2hvcnRjb21pbmdzIG9mIGNob29zaW5nIHRoYXQgYXBwcm9hY2guDQoNCg0KDQpPbiBUaHUsIEph biAxNywgMjAxOSBhdCA0OjMyIFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFp bHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCldlIGhhdmUgZGlzY3Vzc2VkIHRoaXMu DQoNCkF1ZGllbmNlcyBjYW4gY2VydGFpbmx5IGJlIGxvZ2ljYWwgaWRlbnRpZmllcnMuDQoNClRo aXMgaG93ZXZlciBpcyBhIG1vcmUgc3BlY2lmaWMgbG9jYXRpb24uICBUaGUgQVMgaXMgZnJlZSB0 byBtYXAgdGhlIGxvY2F0aW9uIGludG8gc29tZSBhYnN0cmFjdCBhdWRpZW5jZSBpbiB0aGUgQVQu DQoNCkZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uY2UgdGhlIGNsaWVudCBzdGFydHMg YXNraW5nIGZvciBsb2dpY2FsIHJlc291cmNlcyBpdCBjYW4gYmUgdHJpY2tlZCBpbnRvIGFza2lu ZyBmb3IgdGhlIHdyb25nIG9uZSBhcyBhIGJhZCByZXNvdXJjZSBjYW4gYWx3YXlzIGxpZSBhYm91 dCB3aGF0IGxvZ2ljYWwgcmVzb3VyY2UgaXQgaXMuDQoNCklmIHdlIHdlcmUgdG8gY2hhbmdlIGl0 LCBob3cgYSBjbGllbnQgd291bGQgdmFsaWRhdGUgaXQgYmVjb21lcyBjaGFsbGVuZ2luZyB0byBp bXBvc3NpYmxlLg0KDQpUaGUgQVMgaXMgZnJlZSB0byBkbyB3aGF0ZXZlciBtYXBwaW5nIG9mIGxv Y2F0aW9ucyB0byBpZGVudGlmaWVycyBpdCBuZWVkcyBmb3IgYWNjZXNzIHRva2Vucy4NCg0KU29t ZSBpbXBsZW1lbnRhdGlvbnMgbWF5IHdhbnQgdG8ga2VlcCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMg bGlrZSBsb2dpY2FsIGF1ZGllbmNlLCBidXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgZnJvbSBy ZXNvdXJjZS4NCg0KSm9obiBCLg0KT24gMS8xNy8yMDE5IDk6NTYgQU0sIFJpZmFhdCBTaGVraC1Z dXNlZiB3cm90ZToNCkhpIFZpdHRvcmlvLA0KDQpUaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGNvcGll ZCBmb3JtIHRoZSBhYnN0cmFjdCBvZiB0aGUgZHJhZnQgaXRzZWxmLg0KDQoNCkF1dGhvcnMsDQoN ClNob3VsZCB0aGUgZHJhZnQgYmUgdXBkYXRlZCB0byBjb3ZlciB0aGUgbG9naWNhbCBpZGVudGlm aWVyIGNhc2U/DQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gVGh1LCBKYW4gMTcsIDIwMTkg YXQgODoxOSBBTSBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpW aXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCkhpIFJpZmFhdCwNCm9uZSBkZXRhaWwuIFRoZSB0 ZWNoIHN1bW1hcnkgc2F5cw0KDQoNCkFuIGV4dGVuc2lvbiB0byB0aGUgT0F1dGggMi4wIEF1dGhv cml6YXRpb24gRnJhbWV3b3JrIGRlZmluaW5nIHJlcXVlc3QNCg0KcGFyYW1ldGVycyB0aGF0IGVu YWJsZSBhIGNsaWVudCB0byBleHBsaWNpdGx5IHNpZ25hbCB0byBhbiBhdXRob3JpemF0aW9uIHNl cnZlcg0KDQphYm91dCB0aGUgbG9jYXRpb24gb2YgdGhlIHByb3RlY3RlZCByZXNvdXJjZShzKSB0 byB3aGljaCBpdCBpcyByZXF1ZXN0aW5nDQoNCmFjY2Vzcy4NCkJ1dCBhdCBsZWFzdCBpbiB0aGUg TWljcm9zb2Z0IGltcGxlbWVudGF0aW9uLCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciBkb2Vzbid0 IGhhdmUgdG8gYmUgYSBuZXR3b3JrIGFkZHJlc3NhYmxlIFVSTCAoYW5kIGlmIGl0IGlzLCBpdCBk b2Vzbid0IHN0cmljdGx5IG5lZWQgdG8gbWF0Y2ggdGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlv bikuIEl0IGNhbiBiZSBhIGxvZ2ljYWwgaWRlbnRpZmllciwgdGhvIHVzaW5nIHRoZSBhY3R1YWwg cmVzb3VyY2UgbG9jYXRpb24gdGhlcmUgaGFzIGJlbmVmaXRzIChkb21haW4gb3duZXJzaGlwIGNo ZWNrLCBwcmV2ZW50aW9uIG9mIHRva2VuIGZvcndhcmRpbmcgZXRjKS4NClNhbWUgZm9yIEF1dGgw LCB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGlzIGEgbG9naWNhbCBpZGVudGlmaWVyIHJhdGhlciB0 aGFuIGEgbG9jYXRpb24uDQoNCg0KDQpPbiBXZWQsIEphbiAxNiwgMjAxOSBhdCA2OjMyIFBNIFJp ZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0 ZkBnbWFpbC5jb20+PiB3cm90ZToNCkFsbCwNCg0KVGhlIGZvbGxvd2luZyBpcyB0aGUgZmlyc3Qg c2hlcGhlcmQgd3JpdGUtdXAgZm9yIHRoZSBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMtMDEgZG9jdW1lbnQuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvc2hlcGhlcmR3cml0ZXVwLw0KDQpQbGVh c2UsIHRha2UgYSBsb29rIGFuZCBsZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZy4NCg0K UmVnYXJkcywNCiBSaWZhYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_F5D20367D6E440E8826070C91A9B1ECDamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E7D0658E1859343A82D163287EE508B@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MiA2IDUgOSAy IDIgNSAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRlIGEg bWVhbnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRm Lm9yZyZndDsgb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51 YXJ5IDE4LCAyMDE5IGF0IDU6NDcgQU08YnI+DQo8Yj5UbzogPC9iPkpvaG4gQnJhZGxleSAmbHQ7 dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9hdXRoIFdHICZsdDtv YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gU2hl cGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIEpvaG4gZm9yIHRoZSBiYWNrZ3JvdW5kLiA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgZnJvbSB0aGUgY2xpZW50IHZh bGlkYXRpb24gUG9WLCBoYXZpbmcgYW4gaWRlbnRpZmllciBjb3JyZXNwb25kaW5nIHRvIGEgbG9j YXRpb24gbWFrZXMgdGhpbmdzIG1vcmUgc29saWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQ6IHRoZSB1c2Ugb2YgbG9naWNhbCBp ZGVudGlmaWVycyBpcyB3aWRlc3ByZWFkLCBhcyBpdCBoYXMgc2lnbmlmaWNhbnQgcHJhY3RpY2Fs IGFkdmFudGFnZXMgKHRoaW5rIG9mIHNlcnZpY2VzIHRoYXQgYXNzaWduIGdlbmVyYXRlZCBob3N0 aW5nIFVSTHMgb25seSBhdCBkZXBsb3ltZW50IHRpbWUsIG9yIHNlcnZpY2VzIHRoYXQgYXJlIHNv bWVob3cgZ3JvdXBlZCB1bmRlciB0aGUgc2FtZSBsb2dpY2FsDQogYXVkaWVuY2UgYWNyb3NzIHJl Z2lvbnMvZW52aXJvbm1lbnQvZGVwbG95bWVudHMpLiBQZW9wbGUgd29uJ3Qgc3RvcCB1c2luZyBs b2dpY2FsIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBubyBhbHRlcm5hdGl2 ZSAoZ2VuZXJhdGluZyBuZXcgYXVkaWVuY2VzIG9uIHRoZSBmbHkgYXQgdGhlIEFTIGV2ZXJ5IHRp bWUgeW91IGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFzc2lnbmVkIGEgbmV3IFVSTCBjYW4gYmUg dW5mZWFzaWJsZSkuDQogTGVhdmluZyBhIHdpZGVseSB1c2VkIGFwcHJvYWNoIGFzIGV4ZXJjaXNl IHRvIHRoZSByZWFkZXIgc2VlbXMgYSBkaXNzZXJ2aWNlIHRvIHRoZSBjb21tdW5pdHksIGdpdmVu IHRoYXQgdGhpcyBtaWdodCBsZWFkIHRvIHZlbmRvcnMgKGZvciBleGFtcGxlIE1pY3Jvc29mdCBh bmQgQXV0aDApIGtlZXBpbmcgdGhlaXIgb3duIHByb3ByaWV0YXJ5IHBhcmFtZXRlcnMsIG9yIGRl dmVsb3BlcnMgbWlzdXNpbmcgdGhlIG9uZXMgaW4gcGxhY2U7IHdvdWxkDQogbWFrZSBpdCBoYXJk IGZvciBTREsgZGV2ZWxvcGVycyB0byBwcm92aWRlIGxpYnJhcmllcyB0aGF0IHdvcmsgb3V0IG9m IHRoZSBib3ggd2l0aCBkaWZmZXJlbnQgQVNlczsgYW5kIHNvIG9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgaXQgYmUgZmVhc2libGUg dG8gYWRkIHN1Y2ggcGFyYW1ldGVyIGRpcmVjdGx5IGluIHRoaXMgc3BlYz8gVGhhdCB3b3VsZCBl bGltaW5hdGUgdGhlIGludGVyb3AgaXNzdWVzLCBhbmQgYWxzbyBnaXZlcyB1cyBhIGNoYW5jZSB0 byBmdWxseSB3YXJuIHBlb3BsZSBhYm91dCB0aGUgc2VjdXJpdHkgc2hvcnRjb21pbmdzIG9mIGNo b29zaW5nIHRoYXQgYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAxNywgMjAxOSBhdCA0OjMyIFBNIEpv aG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJA dmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdDttYXJnaW46MC4uOGV4Ij4NCjxkaXY+DQo8cD5XZSBoYXZlIGRpc2N1c3NlZCB0aGlzLjxv OnA+PC9vOnA+PC9wPg0KPHA+QXVkaWVuY2VzIGNhbiBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVu dGlmaWVycy4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cD5UaGlzIGhvd2V2ZXIgaXMg YSBtb3JlIHNwZWNpZmljIGxvY2F0aW9uLiZuYnNwOyBUaGUgQVMgaXMgZnJlZSB0byBtYXAgdGhl IGxvY2F0aW9uIGludG8gc29tZSBhYnN0cmFjdCBhdWRpZW5jZSBpbiB0aGUgQVQuPG86cD48L286 cD48L3A+DQo8cD5Gcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBvbmNlIHRoZSBjbGllbnQg c3RhcnRzIGFza2luZyBmb3IgbG9naWNhbCByZXNvdXJjZXMgaXQgY2FuIGJlIHRyaWNrZWQgaW50 byBhc2tpbmcgZm9yIHRoZSB3cm9uZyBvbmUgYXMgYSBiYWQgcmVzb3VyY2UgY2FuIGFsd2F5cyBs aWUgYWJvdXQgd2hhdCBsb2dpY2FsIHJlc291cmNlIGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+ SWYgd2Ugd2VyZSB0byBjaGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3b3VsZCB2YWxpZGF0ZSBpdCBi ZWNvbWVzIGNoYWxsZW5naW5nIHRvIGltcG9zc2libGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRo ZSBBUyBpcyBmcmVlIHRvIGRvIHdoYXRldmVyIG1hcHBpbmcgb2YgbG9jYXRpb25zIHRvIGlkZW50 aWZpZXJzIGl0IG5lZWRzIGZvciBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPHA+U29t ZSBpbXBsZW1lbnRhdGlvbnMgbWF5IHdhbnQgdG8ga2VlcCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMg bGlrZSBsb2dpY2FsIGF1ZGllbmNlLCBidXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgZnJvbSBy ZXNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzE3LzIwMTkgOTo1NiBBTSwgUmlmYWF0IFNoZWto LVl1c2VmIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBWaXR0b3JpbywgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGNvcGllZCBmb3JtIHRoZSBhYnN0 cmFjdCBvZiB0aGUgZHJhZnQgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkF1dGhvcnMsPC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhlIGRyYWZ0IGJl IHVwZGF0ZWQgdG8gY292ZXIgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBjYXNlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Umlm YWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgODoxOSBBTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZpdHRv cmlvQGF1dGgwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJpZmFhdCwgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b25lIGRldGFpbC4gVGhlIHRlY2gg c3VtbWFyeSBzYXlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJl IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtib3JkZXI6bm9u ZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5nOmJvcmRlci1ib3g7Ym9yZGVyLXJhZGl1czo0cHg7d2hp dGUtc3BhY2U6cHJlLXdyYXA7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+QW4gZXh0 ZW5zaW9uIHRvIHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsgZGVmaW5pbmcg cmVxdWVzdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7 O2NvbG9yOmJsYWNrIj5wYXJhbWV0ZXJzIHRoYXQgZW5hYmxlIGEgY2xpZW50IHRvIGV4cGxpY2l0 bHkgc2lnbmFsIHRvIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPmFib3V0IHRoZSA8Yj5s b2NhdGlvbjwvYj4gb2YgdGhlIHByb3RlY3RlZCByZXNvdXJjZShzKSB0byB3aGljaCBpdCBpcyBy ZXF1ZXN0aW5nIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVv dDs7Y29sb3I6YmxhY2siPmFjY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGF0IGxlYXN0IGluIHRoZSBN aWNyb3NvZnQgaW1wbGVtZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIGRvZXNuJ3QN CjxpPmhhdmU8L2k+IHRvIGJlIGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkwgKGFuZCBpZiBpdCBp cywgaXQgZG9lc24ndCBzdHJpY3RseSBuZWVkIHRvIG1hdGNoIHRoZSBhY3R1YWwgcmVzb3VyY2Ug bG9jYXRpb24pLiBJdCBjYW4gYmUgYSBsb2dpY2FsIGlkZW50aWZpZXIsIHRobyB1c2luZyB0aGUg YWN0dWFsIHJlc291cmNlIGxvY2F0aW9uIHRoZXJlIGhhcyBiZW5lZml0cyAoZG9tYWluIG93bmVy c2hpcCBjaGVjaywgcHJldmVudGlvbiBvZiB0b2tlbg0KIGZvcndhcmRpbmcgZXRjKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhbWUgZm9yIEF1 dGgwLCB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGlzIGEgbG9naWNhbCBpZGVudGlmaWVyIHJhdGhl ciB0aGFuIGEgbG9jYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAxNiwgMjAxOSBhdCA2OjMyIFBNIFJpZmFh dCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW46MC4uOGV4Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwgPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZm9sbG93aW5nIGlzIHRoZSBmaXJzdCBz aGVwaGVyZCB3cml0ZS11cCBmb3IgdGhlJm5ic3A7ZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLTAxIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzL3NoZXBoZXJkd3JpdGV1cC8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvc2hlcGhlcmR3cml0ZXVwLzwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlLCB0 YWtlIGEgbG9vayBhbmQgbGV0Jm5ic3A7bWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F5D20367D6E440E8826070C91A9B1ECDamazoncom_-- From nobody Fri Jan 18 12:08:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6B13137D for ; Fri, 18 Jan 2019 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ebxF87vTSbr for ; Fri, 18 Jan 2019 12:08:05 -0800 (PST) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86ECA131373 for ; Fri, 18 Jan 2019 12:08:05 -0800 (PST) Received: by mail-wm1-x343.google.com with SMTP id y139so5593819wmc.5 for ; Fri, 18 Jan 2019 12:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ChMKUSqSgWAyNWRPSaayA23zEj456Ni+pGbbGPv3cm8=; b=o3G66X77CKnVl32POwKukfv6yg2MhhYuY9ueC8L6LtktGc77kEAqrI4QOZcclLhBLR axSpnFU7K3jJRI7RaUpE+5022zqBE+O/jQMJPvZyYf5q3f49hEaCKaM7Kj1L1OeQrIOB WEH/29LA8U9fGx2352kKk/uO1ldL71GfN+G1JLrs1rRSr3CMoTiBEfzfmaMuRF5Rg46l /eX1vsBylGab/LaqAdjk62PPm8NBV6HHuBcJ+i67d+ZZmyc+Z+GN9atEdAXvx2SRHSkc uRaMIyQyolI1G16JrUGre4aRwMsD/4Sk/w1oTUjTFh2BFoKAS29e/mJwPBzSfebsB1Ev O9Eg== 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=ChMKUSqSgWAyNWRPSaayA23zEj456Ni+pGbbGPv3cm8=; b=bJedAK2SdTlr5hmyTfh9VOqOmtDpYGqBVuAKHBzGEb9RxJ2B/J0DEfOC+DhCwMOdcj lLdn5PvCu5oodawDw0O/4f2M/sYJUyiV2bvSaXcllW3LrgQk+s9sTegNAhhqeCDifwq0 AXdyx+3eq2ZsoPm+bqFHC7/SxcdqTDK9GuCuujdV98xhdBJlky4S9ogwnslzYidW1tp2 Y0J2AwPpbO0StzTeMfQFKOs94wFJGXEcmhehDvPJSCS+HrkgP3NKMDKfg7L03lFtmu45 Xi2V1RvnKbpeeynXFMGfpvsFJKNdgxONJtZOVMUVEsLChplp88hVlqFg/ZE3j2I+3xjb N3vw== X-Gm-Message-State: AJcUukfFfIOEcEzPFBeslakAkzzZD1U6AuI00LTyvVGipnfIqbna2Muk a2VyHeEJ93S8nJS+HEi82hWYBUEYw+3JBbMZwOCKeQ== X-Google-Smtp-Source: ALg8bN7FIbZJIbPhhJSC8a3Mr0lhjnvUcD0P1oIEThjGr8hK9eNuTVobaMD3cneQEPyz9xJTCj7MaF/bfAPAZx1Azq0= X-Received: by 2002:a1c:6607:: with SMTP id a7mr16255928wmc.129.1547842083315; Fri, 18 Jan 2019 12:08:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Fri, 18 Jan 2019 17:07:52 -0300 Message-ID: To: "Richard Backman, Annabelle" Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000008b814e057fc1118d" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 20:08:10 -0000 --0000000000008b814e057fc1118d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes the logical resource can be provided by "scope" Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource. Fortunately, we are using a different parameter name so not stepping on that.. We could go back and try to add text explaining the difference, but we are quite late in the process. I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft. John B. On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing 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 > > --0000000000008b814e057fc1118d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes the=C2=A0logical resource can be prov= ided by "scope"

Some impleme= ntations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permi= ssions to the resource.

Fortunately, we are using = a different=C2=A0parameter name so not stepping on that..

We could go back and try to add text explaining the difference, but= we are quite late in the process.=C2=A0

I agree t= hat a logical resource parameter=C2=A0may be helpful, but perhaps it should= be a separate draft.

John B.

On Fri, Jan 18, 2019= at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework definin=
g request 
parameters that enable a client to explicitly signal to an au=
thorization server 
about the location of the protected resource(s) to whi=
ch it is requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

--0000000000008b814e057fc1118d-- From nobody Fri Jan 18 12:18:40 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C4F130FEC for ; Fri, 18 Jan 2019 12:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 xrBETe8T-AX9 for ; Fri, 18 Jan 2019 12:18:33 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BCC130E94 for ; Fri, 18 Jan 2019 12:18:33 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id g8so11806057iok.4 for ; Fri, 18 Jan 2019 12:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MwP15IWjlfQUs+UklKf1gQ7N3aIWtT6gdI/ynzFpC7k=; b=EHp48QokieratUiupAG8d5SI30ZhhmFgP1CbTqDkK4+QkpCKiyYgRXHYcJ7s6Seu/g /u1GaToMdMOHUIKeOhbm4LIas9a3voiwED6S05GVciLkHWG4fJ+1gcMDup16fjqDHMlK RUhCrN66j1ReJ/xktCgTFIFFAG33eaD5ZCEZYAL8Bg4Pkn0YKGw8d2YkIa+S8GAITzvV Ga9gTjb3Kpazr31t0ad0LSCJzBkFw8jexBre/Y0BVc2g0nEoV3euepdC+7ibrLLqLpgV TPM4O3+KyC5FPSV+GP/Tu0dznk797Caq3juQzY1jhBdzDvLO+Wef2AOmBENzb69x8Zqd y9Sw== 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=MwP15IWjlfQUs+UklKf1gQ7N3aIWtT6gdI/ynzFpC7k=; b=bWJMaOUFwoX/HU1vPq8cIidvc/H+k2c2xI0o9zzjBsd4oCuL8QJReyZZJtjktkAun1 kn+5q7PU6I391TeWFtBnss+6gGreG0bmN1lr5CklHmjB+85s2S8Nhg0fQP3uQrf3Uf6B eSJI0nb93B1FaHDwO8rGI3R1GIxjOqn81LHbrl8MpTpS6fXQvyRUDgFmiLJNY95yvFqr 1BtZJ6iDy43KTBPGdGXDZuO8da1YOgiuoqgcEYED79zuSaJv7KeGwFw/dzVj5h7iqt5R WmZHTf+1kv6sr3fz15iG+6V/F85OfAH03faJgUji59YUAwdk6l2X0WtPMg1hCDWLKLnp WWWw== X-Gm-Message-State: AJcUukcR4p1uQVyDcDPl54rPHuWWq8uSF0rdI8FviYOX6IawEd+C7m/j EIhJcjULr2lnxJ7ulVIUY6+F5fZWKrwwcIkV5OU= X-Google-Smtp-Source: ALg8bN569VWe06fztwoO0BFGiav65wId0FkwrJX4QJeAqSDDd+ioBsZOKJFUGz2cUGCUXmuPvM3ZuKoKKLB9mVThqI0= X-Received: by 2002:a5d:9913:: with SMTP id x19mr9640470iol.99.1547842712367; Fri, 18 Jan 2019 12:18:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Fri, 18 Jan 2019 15:18:21 -0500 Message-ID: To: John Bradley Cc: "Richard Backman, Annabelle" , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000009f7e8057fc13715" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 20:18:36 -0000 --00000000000009f7e8057fc13715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wouldn't worry too much about the process. If it makes sense to update the document, then feel free to do that. Regards, Rifaat On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > Yes the logical resource can be provided by "scope" > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > Fortunately, we are using a different parameter name so not stepping on > that.. > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > John B. > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000009f7e8057fc13715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wouldn't worry too much about the process.
If it= makes sense to update the document, then feel free to do that.
<= br>
Regards,
=C2=A0Rifaat
=C2=A0
<= br>
On Fri,= Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes the=C2=A0logical= resource can be provided by "scope"

Some implementations like Ping and Auth0 have been adding another = parameter "aud" to identify the logical resource and then using s= copes to define permissions to the resource.

Fortu= nately, we are using a different=C2=A0parameter name so not stepping on tha= t..

We could go back and try to add text explainin= g the difference, but we are quite late in the process.=C2=A0
I agree that a logical resource parameter=C2=A0may be helpful, = but perhaps it should be a separate draft.

John B.=

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman= , Annabelle <ri= channa@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework definin=
g request 
parameters that enable a client to explicitly signal to an au=
thorization server 
about the location of the protected resource(s) to whi=
ch it is requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000009f7e8057fc13715-- From nobody Fri Jan 18 14:36:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813B4131444 for ; Fri, 18 Jan 2019 14:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 dG2y_VFbeni1 for ; Fri, 18 Jan 2019 14:35:58 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657C41312C1 for ; Fri, 18 Jan 2019 14:35:58 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id m19so12097255ioh.3 for ; Fri, 18 Jan 2019 14:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b23Mo9otTxxehOUe1uTlbVexHtqdRA7na7941X1VyIk=; b=Xn5TOU6V5O/VKttYmsX+GNhOcgJNZd7fw9OhRvpfnl1yQzUAS3JgIwWP3cWLil7otK vlc2hgWHMwZXfciy8l6sN4MMHIYs0sI8SsyCy1L5FIFDa2ICnPR+QJhHYa3Gc0kbpFz0 eyv973/hcgAxx9qLmsplbolBt1f12hjZmIap8= 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=b23Mo9otTxxehOUe1uTlbVexHtqdRA7na7941X1VyIk=; b=d+kRfAQg3I8J2blOfNOQIM6xvRKw4pmH3vZMizkzYK3vqQGOK6HC8oVN0LVt4nU5E/ 6qwR7uwf/xjxHXK3bKg4dmmwS/0/EAk0d+xhG/Wh6ZQMZ0CYQr6R4S2t5gGT6UMVMy1R sL4ne/RJzHeoJ2v7hKsgYVy8fKE78niGxe6EJ0Q03jRHctJ1Wv3EaW1S7vzwxVpcqdUw RXdDOhFBKhjiXcgCP4x/vyz6URiF5hIIt3/1CU8i3o3prlf+w5FTQhiWHwhmLy+GvcjQ j79DLh4vpQDWn8JWvUNOyRMCEXeBmzwSzGE5A/tPGg+jiC5fYwZkvYj7CQqJeCOdIT0r 22KA== X-Gm-Message-State: AJcUukc7t/2MSnaEMcBtxAFkQV7yKhkTO/nnSXS+cR5+5XGbW68Yhl8R 2zhuVmlCmnhxvgnzYGpgZ0k0SumQRMlI3daAYZV2Kxx68L0LynxuypDu171FLyI2Y1sqyHA6lLL 1mwDvJr4FX3pGNQ== X-Google-Smtp-Source: ALg8bN6UP+Yp2C51atEUwItvdayV/k+ngLohc9n79cRVUvmVPJy4FfG+3hLcEUN4PZ+LOHSgXSFZ63jwu5WSsFcPIwQ= X-Received: by 2002:a6b:700a:: with SMTP id l10mr10051848ioc.138.1547850957577; Fri, 18 Jan 2019 14:35:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 18 Jan 2019 15:35:30 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: John Bradley , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000007df725057fc322f8" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 22:36:03 -0000 --0000000000007df725057fc322f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it... As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread. In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay. The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft. So maybe the draft is okay as is? Or perhaps that's too much to be left as an exerciser to the reader? And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL? On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef wrote: > I wouldn't worry too much about the process. > If it makes sense to update the document, then feel free to do that. > > Regards, > Rifaat > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > >> Yes the logical resource can be provided by "scope" >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> John B. >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a= means of specifying a >>> logical identifier? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of Vittorio Bertocci >>> >>> *Date: *Friday, January 18, 2019 at 5:47 AM >>> *To: *John Bradley >>> *Cc: *IETF oauth WG >>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> >>> >>> Thanks John for the background. >>> >>> I agree that from the client validation PoV, having an identifier >>> corresponding to a location makes things more solid. >>> >>> That said: the use of logical identifiers is widespread, as it has >>> significant practical advantages (think of services that assign generat= ed >>> hosting URLs only at deployment time, or services that are somehow grou= ped >>> under the same logical audience across regions/environment/deployments)= . >>> People won't stop using logical identifiers, because they often have no >>> alternative (generating new audiences on the fly at the AS every time y= ou >>> do a deployment and get assigned a new URL can be unfeasible). Leaving = a >>> widely used approach as exercise to the reader seems a disservice to th= e >>> community, given that this might lead to vendors (for example Microsoft= and >>> Auth0) keeping their own proprietary parameters, or developers misusing= the >>> ones in place; would make it hard for SDK developers to provide librari= es >>> that work out of the box with different ASes; and so on. >>> >>> Would it be feasible to add such parameter directly in this spec? That >>> would eliminate the interop issues, and also gives us a chance to fully >>> warn people about the security shortcomings of choosing that approach. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >>> >>> We have discussed this. >>> >>> Audiences can certainly be logical identifiers. >>> >>> This however is a more specific location. The AS is free to map the >>> location into some abstract audience in the AT. >>> >>> From a security point of view once the client starts asking for logical >>> resources it can be tricked into asking for the wrong one as a bad reso= urce >>> can always lie about what logical resource it is. >>> >>> If we were to change it, how a client would validate it becomes >>> challenging to impossible. >>> >>> The AS is free to do whatever mapping of locations to identifiers it >>> needs for access tokens. >>> >>> Some implementations may want to keep additional parameters like logica= l >>> audience, but that should be separate from resource. >>> >>> John B. >>> >>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>> >>> Hi Vittorio, >>> >>> >>> >>> The text you quoted is copied form the abstract of the draft itself. >>> >>> >>> >>> >>> >>> *Authors,* >>> >>> >>> >>> Should the draft be updated to cover the logical identifier case? >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>> wrote: >>> >>> Hi Rifaat, >>> >>> one detail. The tech summary says >>> >>> >>> >>> An extension to the OAuth 2.0 Authorization Framework defining request >>> >>> parameters that enable a client to explicitly signal to an authorizatio= n server >>> >>> about the *location* of the protected resource(s) to which it is reques= ting >>> >>> access. >>> >>> But at least in the Microsoft implementation, the resource identifier >>> doesn't *have* to be a network addressable URL (and if it is, it >>> doesn't strictly need to match the actual resource location). It can be= a >>> logical identifier, tho using the actual resource location there has >>> benefits (domain ownership check, prevention of token forwarding etc). >>> >>> Same for Auth0, the audience parameter is a logical identifier rather >>> than a location. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> All, >>> >>> >>> >>> The following is the first shepherd write-up for >>> the draft-ietf-oauth-resource-indicators-01 document. >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/s= hepherdwriteup/ >>> >>> >>> >>> Please, take a look and let me know if I missed anything. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --0000000000007df725057fc322f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rifaat. Process is as process does, right? I d= o kinda want to grumble about WGCL having passed already but that's mos= tly because replying to these kinds of threads is hard for me and I'll = just get over it...

As far as I u= nderstand things, the security concerns come into play when the client is being told the by the resource how to=20 identity the resource like is described in=20 htt= ps://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using=20 the actual location in that context ,along with some other checks prescribe= d in that draft, prevents the kind of issues John=20 described earlier in the thread.

In cases where the client knows th= e resource a priori or out-of-band or configured or whatever, I don't think the same=20 security concerns arise. And using such a known value, be it an actual=20 location or logical representation, would be okay.

The=20 resource-indicators draft is admittedly somewhat location-centric in how it= talks=20 about the value of the 'resource' parameter. But ultimately it defi= nes=20 it as an absolute URI that indicates the location of the target service=20 or resource where access is being requested. A location can be varying=20 shades of abstract and I'd say that using a URI as 'resource' p= arameter=20 value that's a logical identifier that points to some resource is well= =20 within the bounds of the draft.

S= o maybe the draft is okay as is?

Or perhaps that&#= 39;s too much to be left as an exerciser to the reader?=C2=A0 And some text= should be added and/or adjusted so the resource-indicators draft would be = a little more open/clear about the parameter value potentially being more o= f a logical or abstract identifier and not necessarily a network addressabl= e URL?



On Fri, Jan 18, 2019 at 1:18 PM = Rifaat Shekh-Yusef <rifaat.ietf= @gmail.com> wrote:
I wouldn't worry too much about the process= .
If it makes sense to update the document, then feel free to do that.<= /div>

Regards,
=C2=A0Rifaat
=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley= <ve7jtb@ve7jtb.c= om> wrote:
Yes the=C2=A0logical resource can be pr= ovided by "scope"

Some imple= mentations like Ping and Auth0 have been adding another parameter "aud= " to identify the logical resource and then using scopes to define per= missions to the resource.

Fortunately, we are usin= g a different=C2=A0parameter name so not stepping on that..

<= /div>
We could go back and try to add text explaining the difference, b= ut we are quite late in the process.=C2=A0

I agree= that a logical resource parameter=C2=A0may be helpful, but perhaps it shou= ld be a separate draft.

John B.

On Fri, Jan 18, 2019 at 4:38 PM Richard= Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0=
 Authorization Framework defining request 
parameters that enable a clie=
nt to explicitly signal to an authorization server 

about the location of =
the protected resource(s) to which it is requesting 

access.<=
/pre>

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

<= 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. --0000000000007df725057fc322f8-- From nobody Fri Jan 18 17:22:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF900130F20 for ; Fri, 18 Jan 2019 17:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16tagvs6oFTA for ; Fri, 18 Jan 2019 17:22:35 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7570B130EFA for ; Fri, 18 Jan 2019 17:22:35 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id g8so12341016iok.4 for ; Fri, 18 Jan 2019 17:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pjac1v5TsQmeTZAPB/Gnn7kXCSJ4asZwuckjtti7F8M=; b=asDhXLR2h6z3hsBYDTLzE5opyguJZIoEZdYPxiz5cnKKMHQQxvW9iUKky2z+zphDY6 OUVI/ySMOL/6FQu95m22C5MNHaWOqNsw4ZYRUYMr3F3IH2Koddm79Ra56YUfaiKDfH7P 20oq09RKW2o3VlVHqOlbY7v5QqDtalL7Z+wDkYEIwyFHWHAKuSs1wNXhdUG6Zm7TZ+FH ptzM59IUOU2HNv/RzXc1V+A19vIxEIb7GiNzXi9biwd07MO/8hChoIpEb9eKWJ3kNM8E cpogFvd5Dg67JRBtOnvt1vRHM0C6TF4hGXroWFfDRPFGgyJZc7CffjkmoM3PY79GbLFd qflg== 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=pjac1v5TsQmeTZAPB/Gnn7kXCSJ4asZwuckjtti7F8M=; b=XpGqJ2isUSMJL9pSlj+Vbr0U1d7MG/dx51d4TqzZK/UyCFFGo4xy1j8yh5jrH2b68D acEQSRsf1o9RqcdoJAMGUXB4ie+Rs4GVvbEaJmlMKTJYJz2APR//UwgJJ+/QVbDJjbIz wXu41eobl6dpIJUBaw1BtdU9T+HdngovTgQDUL5DeTjzRvF9E201PF0rl7s4HPx31JAN 4bWwKP1smit1i6XLqKgX5anZqgp0phldx16CFXzWgpiLZR1LLwTogNotHDFozsX4wxm5 0sr2bwdSXt6FBzZsh0QYjHz2/hCAMlj0LYLsueKNlJMA0lo79kNqeoXvMQcX8slygVrU uDEg== X-Gm-Message-State: AJcUukeGiNJ6LrXiUhuCHzqJX6s6AU4+x9ko50LM+V1k/mNV5rXeIP/3 Q74EpdMUoBAmHkgplYkvURqCaobQONeQjdjZsas= X-Google-Smtp-Source: ALg8bN5FnXFAL3R5G6pSRNlWEShi2HnjC7hEwC2g++wO0M+ObXxvlqwRDZL6Pxk3M4Jfe2WMhYcTX+1SW8u+MWwKjx4= X-Received: by 2002:a6b:930b:: with SMTP id v11mr11598743iod.148.1547860954733; Fri, 18 Jan 2019 17:22:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Fri, 18 Jan 2019 20:22:23 -0500 Message-ID: To: Brian Campbell Cc: John Bradley , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000005e6139057fc576ba" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 01:22:40 -0000 --0000000000005e6139057fc576ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry Brian, I was not clear with my statement. I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place. Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible. Regards, Rifaat On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell wrote: > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > So maybe the draft is okay as is? > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > >> I wouldn't worry too much about the process. >> If it makes sense to update the document, then feel free to do that. >> >> Regards, >> Rifaat >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >>> Yes the logical resource can be provided by "scope" >>> >>> Some implementations like Ping and Auth0 have been adding another >>> parameter "aud" to identify the logical resource and then using scopes = to >>> define permissions to the resource. >>> >>> Fortunately, we are using a different parameter name so not stepping on >>> that.. >>> >>> We could go back and try to add text explaining the difference, but we >>> are quite late in the process. >>> >>> I agree that a logical resource parameter may be helpful, but perhaps i= t >>> should be a separate draft. >>> >>> John B. >>> >>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide = a means of specifying a >>>> logical identifier? >>>> >>>> >>>> >>>> -- >>>> >>>> Annabelle Richard Backman >>>> >>>> AWS Identity >>>> >>>> >>>> >>>> >>>> >>>> *From: *OAuth on behalf of Vittorio Bertocci >>>> >>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>> *To: *John Bradley >>>> *Cc: *IETF oauth WG >>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>> draft-ietf-oauth-resource-indicators-01 >>>> >>>> >>>> >>>> Thanks John for the background. >>>> >>>> I agree that from the client validation PoV, having an identifier >>>> corresponding to a location makes things more solid. >>>> >>>> That said: the use of logical identifiers is widespread, as it has >>>> significant practical advantages (think of services that assign genera= ted >>>> hosting URLs only at deployment time, or services that are somehow gro= uped >>>> under the same logical audience across regions/environment/deployments= ). >>>> People won't stop using logical identifiers, because they often have n= o >>>> alternative (generating new audiences on the fly at the AS every time = you >>>> do a deployment and get assigned a new URL can be unfeasible). Leaving= a >>>> widely used approach as exercise to the reader seems a disservice to t= he >>>> community, given that this might lead to vendors (for example Microsof= t and >>>> Auth0) keeping their own proprietary parameters, or developers misusin= g the >>>> ones in place; would make it hard for SDK developers to provide librar= ies >>>> that work out of the box with different ASes; and so on. >>>> >>>> Would it be feasible to add such parameter directly in this spec? That >>>> would eliminate the interop issues, and also gives us a chance to full= y >>>> warn people about the security shortcomings of choosing that approach. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote= : >>>> >>>> We have discussed this. >>>> >>>> Audiences can certainly be logical identifiers. >>>> >>>> This however is a more specific location. The AS is free to map the >>>> location into some abstract audience in the AT. >>>> >>>> From a security point of view once the client starts asking for logica= l >>>> resources it can be tricked into asking for the wrong one as a bad res= ource >>>> can always lie about what logical resource it is. >>>> >>>> If we were to change it, how a client would validate it becomes >>>> challenging to impossible. >>>> >>>> The AS is free to do whatever mapping of locations to identifiers it >>>> needs for access tokens. >>>> >>>> Some implementations may want to keep additional parameters like >>>> logical audience, but that should be separate from resource. >>>> >>>> John B. >>>> >>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>> >>>> Hi Vittorio, >>>> >>>> >>>> >>>> The text you quoted is copied form the abstract of the draft itself. >>>> >>>> >>>> >>>> >>>> >>>> *Authors,* >>>> >>>> >>>> >>>> Should the draft be updated to cover the logical identifier case? >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>> wrote: >>>> >>>> Hi Rifaat, >>>> >>>> one detail. The tech summary says >>>> >>>> >>>> >>>> An extension to the OAuth 2.0 Authorization Framework defining request >>>> >>>> parameters that enable a client to explicitly signal to an authorizati= on server >>>> >>>> about the *location* of the protected resource(s) to which it is reque= sting >>>> >>>> access. >>>> >>>> But at least in the Microsoft implementation, the resource identifier >>>> doesn't *have* to be a network addressable URL (and if it is, it >>>> doesn't strictly need to match the actual resource location). It can b= e a >>>> logical identifier, tho using the actual resource location there has >>>> benefits (domain ownership check, prevention of token forwarding etc). >>>> >>>> Same for Auth0, the audience parameter is a logical identifier rather >>>> than a location. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>> All, >>>> >>>> >>>> >>>> The following is the first shepherd write-up for >>>> the draft-ietf-oauth-resource-indicators-01 document. >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/= shepherdwriteup/ >>>> >>>> >>>> >>>> Please, take a look and let me know if I missed anything. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> >>>> https://www.ietf..org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000005e6139057fc576ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry Brian, I was not clear with my statement.
<= div>I meant to say that we should not allow the process to prevent the WG f= rom producing a quality document without issues, assuming there is an issue= in the first place.
Ideally we want to get these identified duri= ng the WGLC, but things happen and sometimes the WG misses something.=C2=A0=

I hear you and agree that this make things diffic= ult for authors. We will make sure that this does not become the norm, and = we will try to stick to the process as much as possible.

Regards,
=C2=A0Rifaat

=

= On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Thank= s Rifaat. Process is as process does, right? I do kinda want to grumble abo= ut WGCL having passed already but that's mostly because replying to the= se kinds of threads is hard for me and I'll just get over it...

As far as I understand things, the secur= ity concerns come into play when the client is being told the by the resource how to=20 identity the resource like is described in=20 https://tools.ietf.org/html/draft-ietf-oauth-distributed-01<= /a> and using=20 the actual location in that context ,along with some other checks prescribe= d in that draft, prevents the kind of issues John=20 described earlier in the thread.

In cases where the client knows th= e resource a priori or out-of-band or configured or whatever, I don't think the same=20 security concerns arise. And using such a known value, be it an actual=20 location or logical representation, would be okay.

The=20 resource-indicators draft is admittedly somewhat location-centric in how it= talks=20 about the value of the 'resource' parameter. But ultimately it defi= nes=20 it as an absolute URI that indicates the location of the target service=20 or resource where access is being requested. A location can be varying=20 shades of abstract and I'd say that using a URI as 'resource' p= arameter=20 value that's a logical identifier that points to some resource is well= =20 within the bounds of the draft.




On F= ri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
I = wouldn't worry too much about the process.
If it makes sense to upd= ate the document, then feel free to do that.

Regar= ds,
=C2=A0Rifaat
=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley &= lt;ve7jtb@ve7jtb.com= > wrote:
=
Yes the=C2=A0logical resource can be prov= ided by "scope"

Some impleme= ntations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permi= ssions to the resource.

Fortunately, we are using = a different=C2=A0parameter name so not stepping on that..

We could go back and try to add text explaining the difference, but= we are quite late in the process.=C2=A0

I agree t= hat a logical resource parameter=C2=A0may be helpful, but perhaps it should= be a separate draft.

John B.

On Fri, Jan = 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0=
 Authorization Framework defining request 
parameters that enable a clie=
nt to explicitly signal to an authorization server 

about the location of =
the protected resource(s) to which it is requesting 

access.<=
/pre>

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

<= 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.
--0000000000005e6139057fc576ba-- From nobody Sat Jan 19 05:59:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAFF12F1A5 for ; Sat, 19 Jan 2019 05:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6p1v-37sraF for ; Sat, 19 Jan 2019 05:58:59 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C111200B3 for ; Sat, 19 Jan 2019 05:58:55 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id i145so10743866ita.4 for ; Sat, 19 Jan 2019 05:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gu1IslyPNG67IFrSNwu1kkaSRGNixUn/ilG6qn9gicM=; b=E86RlU9rrpR+hUpfuetTUipxAwvjd7q5nZ/G1kgr80km5W1kYu2hzuh+JltYnnBELd kzP9Q2e7BLQVabokDwH8IBB71U1OQ5QvpZqcAQAmOqgt6ZNKEV+gSZULmkTtSWKWyS1z uwaXUZT9Th0sMWEPcpJGAhYz8USjuTBLfIAJQ= 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=gu1IslyPNG67IFrSNwu1kkaSRGNixUn/ilG6qn9gicM=; b=K/2YUmV/DjXSmHzAvbf6EVtS4xKzOUA+2jB/XfmeRnqCM7mU8dC1yCWASMN4Ql/a4v fKt9MOmxKIwvbmll75YLmiu2tvGPXYiVEZsBuKTh7IExLhLnakibdf4rqiqfML+RioCg mJL9K+41T3peYSXZNPFoxVM79iTrK9dcOtS/pzIyb3pRozwOOTBnSnfuFXx6+I/54I5J YeGOmTGBD7gQMToMXKn2bzUNsJk/cu9EKLBkH5DIc4XJ2+zw9fKFY65Y4US5CmaItaOV i8Ievk6jvBzujXH6wacruTYIrhcVV8WoPUfuepliPGJVRD4cLr1Jwa0amoQJw2hcXSF5 Mgag== X-Gm-Message-State: AJcUukfxYF+WIJEQsqB8EaeYcnvfJGUVaKoWsk251aQAZsf+t12Du8Di r0Zr1rj8A2Q20VxFOOlS8KesnzY4vZ0vZa+0icNkYkoB8Jtevqz2KYa54F6JHxFqfm3wO8kVO9U oqUzCwV/WGC0C4w== X-Google-Smtp-Source: ALg8bN75hyOpBqSYJlOTGyKBBF7ZqzAskwd4hpMId/Usd7HC12vFNfNGxRVxMZvkP3iT6zyEEn5nFDekUD8bP3d7PqI= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr13080164itl.124.1547906334096; Sat, 19 Jan 2019 05:58:54 -0800 (PST) MIME-Version: 1.0 References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> <20190111161321.GJ28515@kduck.mit.edu> In-Reply-To: <20190111161321.GJ28515@kduck.mit.edu> From: Brian Campbell Date: Sat, 19 Jan 2019 06:58:27 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000309c37057fd007c9" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 13:59:04 -0000 --000000000000309c37057fd007c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This response is slow but somewhat less slow than those that came before. So I also apologize again but somewhat less so :) I do apologize for sending on a weekend but I just wasn't able to finish and make it to the "send" button before the end of my Friday. I've endeavored to continue the exchange inline below where appropriate and removed portions that needed no further discussion. On Fri, Jan 11, 2019 at 9:13 AM Benjamin Kaduk wrote: > I also apologize for the slow response (I gave Brian a unicast heads-up > earlier) -- between vacation, the holidays, and a death in a the family I > was away from email for quite some time. > > On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > > I apologize for the slow response, Ben. I was on vacation with my famil= y > > around the Thanksgiving holiday when the ballot position came in. And > even > > on returning and starting to work on it, there's an awful lot here to g= et > > through and this kind of thing is very time consuming for me. But thank > you > > for the review - I've attempted to reply, as best I can, to your > > comments/questions inline below. > > > > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-oauth-token-exchange-16: Discuss > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > There's two obvious routes -- first, to change the text to use placeholde= rs > like "TBD1" or "the token-exchange URI" (e.g., as opposed to > urn:ietf:params:oauth:grant-type:token-exchange specifically) and request > that IANA allocate the specific suggested values; or > to get IANA to explicitly confirm that > these values can be registered and will be marked as pending until this > document is finalized (to prevent allocation "under our nose" by other > means). Ekr and I can help mediate any IANA interaction needed for > whatever route we end up taking, if needed. > > (Basically, this is a process concern -- the IESG should not give its sta= mp > of approval to a document in a state that does something we don't want > other people to do, even if the final published RFC will be able to make > these claims correctly.) > I'd then ask that the AD(s) initiate and mediate interactions with IANA to have them explicitly confirm that these values can be registered and have them somehow marked as pending until the document is finalized. > > > > > Before I start trying to tweak text, can you confirm that the actor_token > request parameter is okay to use in both delegation and impersonation > scenarios? > Yes, it's certainly okay to use the actor_token in both delegation and impersonation scenarios. It's necessary for delegation and kinda makes more sense in that scenario but could still be sent by the client and have the STS issue a new token with impersonation semantics. > > > > > > Are the privacy considerations (e.g., risk of a tailed per-request > > > error_uri) relating to the use of error_uri discussed in some other > > > document that we can refer to from this document's security > > > considerations? (I say a bit more about this in my COMMENT.) > > > > > > > I am not aware of any document with such considerations and I've search= ed > > the likely suspects of RFC 6749 and RFC 6819 but don't find anything. > > > > The error_uri token endpoint response parameter was defined in the > original > > OAuth 2.0 framework document (RFC 6749) and any considerations around i= t > > are applicable to considerably more than this document. It's also very > > rarely used in practice as far as I know. I don't think that this > document, > > which is a narrow extension of a whole framework with a series of other > > documents that use error_uri, is the appropriate place to add privacy o= r > > security considerations about error_uri. Perhaps > > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > would be > > more appropriate in scope and content? > > Oh, definitely -- I only asked if there was something existing we could > cheaply reference; this is definitely not the place to be writing this do= wn > from scratch. Thanks for doing the search! > Just to clarify, that draft doesn't currently have anything about error_uri. However, it seems like a more appropriate place for that in terms of its scope to have any such guidance. And that, to the extent such guidance or text is needed, it should go in to that draft (which is a WG draft in progress) rather than into the token exchange draft. > > I could remove the one mention of error_uri in this document? It's usag= e > > would still be possible/valid by virtue of this document being an > extension > > of RFC 6749 but, out of sight and out of mind, and this doc wouldn't th= en > > encourage new usage of it anyway. While usage isn't really happening > anyway. > > I don't mind having the reference there; it's not really causing problems > and could potentially be helpful. We should be able to get away with a > generic reference to this class of thing elsewhere and one-sentence > description ("when a proxy or similar mechanism is in place to protect > client privacy, the error_uri mechanism can induce the client to lose som= e > anonymity by dereferencing a URI pointing to a third party server that ca= n > leak information to the attacker, in a similar fashion as [ref]"). I don= 't > have a [ref] handy right now, though; I'll need to ask around. > If you can provide such a [ref], I can add such a sentence to the draft. But I'm still of the opinion that it would be out of place in this document. In a pinch we could fallback to analogy to open-redirector issues, though > we differ in which actors are receiving/conveying/acting on untrusted > input, and we can have issues just by making the request as opposed to th= e > user mis-interpreting the returned resource. But to reiterate, I'm only > looking for a brief mention that some clients might care and don't need a= n > exhaustive description. > Perhaps then the sentence you had above but without the "in a similar fashion as [ref]" part might suffice as the aforementioned brief mention? > > > > > > > > > Section 2.1 has: > > > audience > > > OPTIONAL. The logical name of the target service where the > client > > > intends to use the requested security token. This serves a > > > purpose similar to the "resource" parameter, but with the clien= t > > > providing a logical name rather than a location. Interpretatio= n > > > of the name requires that the value be something that both the > > > client and the authorization server understand. An OAuth clien= t > > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], = an > > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > > > examples of things that might be used as "audience" parameter > > > values. [...] > > > > > > How does the STS know what type of identifier it is supposed > > > to interpret the provided audience value as? > > > > > > > The STS will have policy and configuration for the target entities for > > which it supports the issuance of tokens to in this flow, even if/when > > those entities are different types of things. The STS will have to sear= ch > > that set of things to find the right one for the given name. In theory = I > > suppose there's potential ambiguity or even name collision. But in > practice > > (as it is the STS that ultimately decides the names it supports and can > > service) I don't believe there is an actual issue. > > Okay, so at some point we're essentially just doing a lookup based on > audience string, and the type information is attached to the lookup resul= ts > (along with everything else needed). > > Do you think it makes sense to add a sentence after the non-elided quoted > portion, something like ``However, "audience" values used on a given > authorization server must be unique within that server, to ensure that th= ey > are properly interpreted as the intended type of value.''? (I'm of cours= e > open to other suggestions, including "just leave it as it is"; I think wh= at > triggered me to comment here is that "both the client and the authorizati= on > server understand" leaves open the possibility that the AS might share on= e > understanding of a string with one client and a different understanding o= f > that same string with a second client, since it's only a pairwise conditi= on > but we probably are safer with a global condition.) > My inclination would be to "just leave it as it is" because well that's the easiest thing to do but it could also make sense to add something like that sentence you had. The idea/intent behind "both the client and the authorization server understand" was that they both understand the thing and understand the same way. > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > The document could perhaps benefit from greater clarity as to whether > > > "security token"s refer to inputs, outputs, or both, of the token > > > endpoint (for the interactions defined in this specification). > > > > > > > I have been aware of the potential need here and endeavored to be clear > > about it throughout the document without being overly repetitive or > wordy. > > I will take another pass through the text and look for opportunities to > > further clarity. But if there are specific points in the doc that you > > believe need attention, please point them out so I can be sure they get > > addressed. > > I made another quick pass, and it is better than I remembered. So thanks > for the efforts, and sorry for maligning the document! > No apology necessary! > Maybe 2.2.1's "token_type" description could reiterate "issued security > token" both times that "security token" appears instead of just the secon= d > time, though the context really ought to be enough to make this one clear= . > Other than that, the only potential trouble I see is in the introduction > when we get a barrage of the string all at once. And even that's in > reasonable shape, with the only potential changes I see being in the firs= t > sentence of the second paragraph, something like "capable of validing > security tokens provided to it and issuing new security tokens in > response". > Thanks for the specifics, I'll make those updates. > > > > > > > > > > > In the absence of one-time-use or other semantics specific to the > > > token type, the act of performing a token exchange has no impact o= n > > > the validity of the subject token or actor token. Furthermore, th= e > > > validity of the subject token or actor token have no impact on the > > > validity of the issued token after the exchange has occurred. > > > > > > Do we really want this strong of a statement? I suspect that in many > > > environments propagating, e.g., expiration time to the exchanged > > > credential may be desired. > > > > > > > The statement was not in any way intended to prohibit propagating > > expiration time (or other criteria) to the exchanged credential. The > > statement was added, best I can recall, in response to a question that > came > > up in a WG chair review asking if the input token(s) would somehow beco= me > > invalid once used as input to the exchange. Or if some later expiration > or > > other invalidation of the input token(s) would somehow invalidate the n= ew > > token. The point of the statement in the doc was to try and say that > there > > is no inherit linkage effectual relationship between the tokens outside > the > > exchange event. There could be but that's not a general property of the > STS > > protocol a would be specific to a particular token type or deployment. > > > > Does that make any more sense? Do you think the wording could/should be > > adjusted? > > That makes perfect sense for what we want to happen, yes. > > I wonder if we really want the second sentence to be saying something lik= e > "The exchange is a one-time event and does not create a tight linkage > betwee the input and output tokens, so that (for example) while the > expiration > time of the output token may be influenced by that of the input token, > renewal or extension of the input token is not expected to be reflected i= n > the ouput token's properties. It may still be appropriate to propagate > token revocation events, though." (This bit about revocation is perhaps > even more interesting than expiration time, and would seem to be prevente= d > by the current text.) > Yeah, I kinda think that or something along those lines might be indeed be better. Propagation of revocation wasn't intended to be prevented. Rather I was just aiming to say that such propagation wasn't required or even expected. > > > > > > > > Would it be appropriate to note (here or elsewhere) that for non-JWT > > > token formats that are a binary format, the URI used for conveying th= em > > > needs to be associated with the semantics of base64 (or otherwise) > > > encoding them for usage with OAuth? > > > > > > > My thinking had been that it'd be more or less self-evident to the very > > small group and type of people who would ever undertake such a thing. > But a > > brief note to that effect couldn't hurt. I'll add something as such. > > > > To be clear, I wouldn't mind if you decided to leave it as is. But thank= s > :) > Fair enough, thanks :) > > > > On looking at it again, I agree "May Act For" isn't a particularly good > > name nor is it helpful in understanding it. I admit to having a hard ti= me > > with the language here. But, yeah, "May Act For" isn't very good. > > > > What about "Authorized Actor" in the parenthetical and "Authorized Acto= r > - > > the party that is authorized to become the actor" for the Claim > Description > > in registration? > > > > I think that's an improvement, thanks. > > Thanks for confirming, I'll make that change. > > < snip> > > > > Appendix A.1.1 > > > > > > In the following token exchange request, a client is requesting a > > > token with impersonation semantics. [...] > > > > > > What part of the request indicates that impersonation semantics are > > > requested? > > > > > > > I guess it's not explicitly requesting impersonation semantics per se b= ut > > only a subject_token is being supplied in the request so impersonation = is > > kinda implied as there is no party identified that could be delegated t= o. > > > > Do you think the wording should be qualified as such or otherwise > adjusted? > > I could go either way, but if I was adding something, I'd go for a > parenthetical "(with only a subject_token and no actor_token, delegation = is > impossible)". > That works, I'll add that. > > > -Benjamin > --=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._ --000000000000309c37057fd007c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This response is slow but = somewhat less slow than those that came before. So I also apologize again b= ut somewhat less so :)=C2=A0 I do apologize for sending on a weekend but I = just wasn't able to finish and make it to the "send" button b= efore the end of my Friday.

I've endeavor= ed to continue the exchan= ge inline below where appropriate and removed portions that needed n= o further discussion.

On Fri, Jan 11, 201= 9 at 9:13 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
I also apologize for the slow response (I gave Br= ian a unicast heads-up
earlier) -- between vacation, the holidays, and a death in a the family I was away from email for quite some time.

On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote:
> I apologize for the slow response, Ben. I was on vacation with my fami= ly
> around the Thanksgiving holiday when the ballot position came in. And = even
> on returning and starting to work on it, there's an awful lot here= to get
> through and this kind of thing is very time consuming for me. But than= k you
> for the review - I've attempted to reply, as best I can, to your > comments/questions inline below.
>
> On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-token-exchange-16: Discuss
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.= org/doc/draft-ietf-oauth-token-exchange/
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
=C2=A0<snip>

There's two obvious routes -- first, to change the text to use placehol= ders
like "TBD1" or "the token-exchange URI" (e.g., as oppos= ed to
urn:ietf:params:oauth:grant-type:token-exchange specifically) and request that IANA allocate the specific suggested values; or
to get IANA to explicitly confirm that
these values can be registered and will be marked as pending until this
document is finalized (to prevent allocation "under our nose" by = other
means).=C2=A0 Ekr and I can help mediate any IANA interaction needed for whatever route we end up taking, if needed.

(Basically, this is a process concern -- the IESG should not give its stamp=
of approval to a document in a state that does something we don't want<= br> other people to do, even if the final published RFC will be able to make these claims correctly.)

I'd = then ask that the AD(s) initiate and mediate interactions with IANA to have= them explicitly confirm that these values can be registered and have them = somehow marked as pending until the document is finalized.
= =C2=A0

=C2=A0
>
=C2=A0<snip>

Before I start trying to tweak text, can you confirm that the actor_token request parameter is okay to use in both delegation and impersonation
scenarios?

Yes, it's certainl= y okay to use the actor_token in both delegation and impersonation scenario= s. It's necessary for delegation and kinda makes more sense in that sce= nario but could still be sent by the client and have the STS issue a new to= ken with impersonation semantics.


<= div>=C2=A0
> >
> > Are the privacy considerations (e.g., risk of a tailed per-reques= t
> > error_uri) relating to the use of error_uri discussed in some oth= er
> > document that we can refer to from this document's security > > considerations?=C2=A0 (I say a bit more about this in my COMMENT.= )
> >
>
> I am not aware of any document with such considerations and I've s= earched
> the likely suspects of RFC 6749 and RFC 6819 but don't find anythi= ng.
>
> The error_uri token endpoint response parameter was defined in the ori= ginal
> OAuth 2.0 framework document (RFC 6749) and any considerations around = it
> are applicable to considerably more than this document. It's also = very
> rarely used in practice as far as I know. I don't think that this = document,
> which is a narrow extension of a whole framework with a series of othe= r
> documents that use error_uri, is the appropriate place to add privacy = or
> security considerations about error_uri.=C2=A0 Perhaps
> https://datatracker.ietf.org/= doc/draft-ietf-oauth-security-topics/ would be
> more appropriate in scope and content?

Oh, definitely -- I only asked if there was something existing we could
cheaply reference; this is definitely not the place to be writing this down=
from scratch.=C2=A0 Thanks for doing the search!

<= /div>
Just to clarify, that draft doesn't currently have anything a= bout error_uri. However, it seems like a more appropriate place for that in= terms of its scope to have any such guidance. And that, to the extent such= guidance or text is needed, it should go in to that draft (which is a WG d= raft in progress) rather than into the token exchange draft.

=C2=A0
> I could remove the one mention of error_uri in this document? It's= usage
> would still be possible/valid by virtue of this document being an exte= nsion
> of RFC 6749 but, out of sight and out of mind, and this doc wouldn'= ;t then
> encourage new usage of it anyway. While usage isn't really happeni= ng anyway.

I don't mind having the reference there; it's not really causing pr= oblems
and could potentially be helpful.=C2=A0 We should be able to get away with = a
generic reference to this class of thing elsewhere and one-sentence
description ("when a proxy or similar mechanism is in place to protect=
client privacy, the error_uri mechanism can induce the client to lose some<= br> anonymity by dereferencing a URI pointing to a third party server that can<= br> leak information to the attacker, in a similar fashion as [ref]").=C2= =A0 I don't
have a [ref] handy right now, though; I'll need to ask around.

If you can provide such a [ref], I can add such= a sentence to the draft.

But I'm still o= f the opinion that it would be out of place in this document.
=C2=A0

In a pinch we could fallback to analogy to open-redirector issues, though we differ in which actors are receiving/conveying/acting on untrusted
input, and we can have issues just by making the request as opposed to the<= br> user mis-interpreting the returned resource.=C2=A0 But to reiterate, I'= m only
looking for a brief mention that some clients might care and don't need= an
exhaustive description.

Perhaps then th= e sentence you had above but without the "in a similar fashion as [ref= ]" part might suffice as the aforementioned brief mention?
<= br>

>
>
> >
> > Section 2.1 has:
> >=C2=A0 =C2=A0 audience
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OPTIONAL.=C2=A0 The logical name of the= target service where the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0intends to use the requested security t= oken.=C2=A0 This serves a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0purpose similar to the "resource&q= uot; parameter, but with the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0providing a logical name rather than a = location.=C2=A0 Interpretation
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of the name requires that the value be = something that both the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client and the authorization server und= erstand.=C2=A0 An OAuth client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier, a SAML entity identifier [O= ASIS.saml-core-2.0-os], an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OpenID Connect Issuer Identifier [OpenI= D.Core], or a URI are
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0examples of things that might be used a= s "audience" parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0values.=C2=A0 [...]
> >
> > How does the STS know what type of identifier it is supposed
> > to interpret the provided audience value as?
> >
>
> The STS will have policy and configuration for the target entities for=
> which it supports the issuance of tokens to in this flow, even if/when=
> those entities are different types of things. The STS will have to sea= rch
> that set of things to find the right one for the given name. In theory= I
> suppose there's potential ambiguity or even name collision. But in= practice
> (as it is the STS that ultimately decides the names it supports and ca= n
> service) I don't believe there is an actual issue.

Okay, so at some point we're essentially just doing a lookup based on audience string, and the type information is attached to the lookup results=
(along with everything else needed).

Do you think it makes sense to add a sentence after the non-elided quoted portion, something like ``However, "audience" values used on a gi= ven
authorization server must be unique within that server, to ensure that they=
are properly interpreted as the intended type of value.''?=C2=A0 (I= 'm of course
open to other suggestions, including "just leave it as it is"; I = think what
triggered me to comment here is that "both the client and the authoriz= ation
server understand" leaves open the possibility that the AS might share= one
understanding of a string with one client and a different understanding of<= br> that same string with a second client, since it's only a pairwise condi= tion
but we probably are safer with a global condition.)
My inclination would be to "just leave it as it is" = because well that's the easiest thing to do but it could also make sens= e to add something like that sentence you had.
=C2=A0
The idea/intent behind "both the client and the authorization serve= r understand" was that they both understand the thing and understand t= he same way.


>
>
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > The document could perhaps benefit from greater clarity as to whe= ther
> > "security token"s refer to inputs, outputs, or both, of= the token
> > endpoint (for the interactions defined in this specification). > >
>
> I have been aware of the potential need here and endeavored to be clea= r
> about it throughout the document without being overly repetitive or wo= rdy.
> I will take another pass through the text and look for opportunities t= o
> further clarity. But if there are specific points in the doc that you<= br> > believe need attention, please point them out so I can be sure they ge= t
> addressed.

I made another quick pass, and it is better than I remembered.=C2=A0 So tha= nks
for the efforts, and sorry for maligning the document!

No apology necessary!
=C2=A0

<= /div>

Maybe 2.2.1's "token_type" description could reiterate "= issued security
token" both times that "security token" appears instead of j= ust the second
time, though the context really ought to be enough to make this one clear.<= br> Other than that, the only potential trouble I see is in the introduction when we get a barrage of the string all at once.=C2=A0 And even that's = in
reasonable shape, with the only potential changes I see being in the first<= br> sentence of the second paragraph, something like "capable of validing<= br> security tokens provided to it and issuing new security tokens in
response".

Thanks for the specific= s, I'll make those updates.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> >=C2=A0 <snip> <snip> <snip>

>
> >
> >=C2=A0 =C2=A0 In the absence of one-time-use or other semantics sp= ecific to the
> >=C2=A0 =C2=A0 token type, the act of performing a token exchange h= as no impact on
> >=C2=A0 =C2=A0 the validity of the subject token or actor token.=C2= =A0 Furthermore, the
> >=C2=A0 =C2=A0 validity of the subject token or actor token have no= impact on the
> >=C2=A0 =C2=A0 validity of the issued token after the exchange has = occurred.
> >
> > Do we really want this strong of a statement?=C2=A0 I suspect tha= t in many
> > environments propagating, e.g., expiration time to the exchanged<= br> > > credential may be desired.
> >
>
> The statement was not in any way intended to prohibit propagating
> expiration time (or other criteria) to the exchanged credential. The > statement was added, best I can recall, in response to a question that= came
> up in a WG chair review asking if the input token(s) would somehow bec= ome
> invalid once used as input to the exchange. Or if some later expiratio= n or
> other invalidation of the input token(s) would somehow invalidate the = new
> token.=C2=A0 The point of the statement in the doc was to try and say = that there
> is no inherit linkage effectual relationship between the tokens outsid= e the
> exchange event. There could be but that's not a general property o= f the STS
> protocol a would be specific to a particular token type or deployment.=
>
> Does that make any more sense? Do you think the wording could/should b= e
> adjusted?

That makes perfect sense for what we want to happen, yes.

I wonder if we really want the second sentence to be saying something like<= br> "The exchange is a one-time event and does not create a tight linkage<= br> betwee the input and output tokens, so that (for example) while the expirat= ion
time of the output token may be influenced by that of the input token,
renewal or extension of the input token is not expected to be reflected in<= br> the ouput token's properties.=C2=A0 It may still be appropriate to prop= agate
token revocation events, though."=C2=A0 (This bit about revocation is = perhaps
even more interesting than expiration time, and would seem to be prevented<= br> by the current text.)

Yeah, I kin= da think that or something along those lines might be indeed be better. Pro= pagation of revocation wasn't intended to be prevented. Rather I was ju= st aiming to say that such propagation wasn't required or even expected= .

=C2=A0
<snip> <snip>

> >
> > Would it be appropriate to note (here or elsewhere) that for non-= JWT
> > token formats that are a binary format, the URI used for conveyin= g them
> > needs to be associated with the semantics of base64 (or otherwise= )
> > encoding them for usage with OAuth?
> >
>
> My thinking had been that it'd be more or less self-evident to the= very
> small group and type of people who would ever undertake such a thing. = But a
> brief note to that effect couldn't hurt. I'll add something as= such.
>

To be clear, I wouldn't mind if you decided to leave it as is.=C2=A0 Bu= t thanks
:)

Fair enough, thanks :)
=C2=A0


<snip> <snip> <snip>
=

> On looking at it again, I agree "May Act For" isn't a pa= rticularly good
> name nor is it helpful in understanding it. I admit to having a hard t= ime
> with the language here. But, yeah, "May Act For" isn't v= ery good.
>
> What about "Authorized Actor" in the parenthetical and "= ;Authorized Actor -
> the party that is authorized to become the actor" for the Claim D= escription
> in registration?
>

I think that's an improvement, thanks.
=C2=A0

Thanks for confirming, I'll = make that change.

=C2=A0
>=C2=A0 < snip> <snip>

> > Appendix A.1.1
> >
> >=C2=A0 =C2=A0 In the following token exchange request, a client is= requesting a
> >=C2=A0 =C2=A0 token with impersonation semantics. [...]
> >
> > What part of the request indicates that impersonation semantics a= re
> > requested?
> >
>
> I guess it's not explicitly requesting impersonation semantics per= se but
> only a subject_token is being supplied in the request so impersonation= is
> kinda implied as there is no party identified that could be delegated = to.
>
> Do you think the wording should be qualified as such or otherwise adju= sted?

I could go either way, but if I was adding something, I'd go for a
parenthetical "(with only a subject_token and no actor_token, delegati= on is
impossible)".

That works, I&= #39;ll add that.
=C2=A0


<snip> <snip>

-Benjamin

<= 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. --000000000000309c37057fd007c9-- From nobody Sat Jan 19 06:42:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB27A127133 for ; Sat, 19 Jan 2019 06:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0OrWJkyrVNXv for ; Sat, 19 Jan 2019 06:41:59 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF1F124C04 for ; Sat, 19 Jan 2019 06:41:59 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id c9so9650538itj.1 for ; Sat, 19 Jan 2019 06:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ZpRcmJdCImmNR7FcSsdneyefLqj1qn+N0zk72RQ8bE=; b=g7Y7vjkrvZLzpJ3XkGnxVhwsZBK7hXv8DjBPl0juxajE6LxGywwKwTRDbRnyzu7Mr+ /v2CXGKG0bcpJzfWBu/R/xcHyXl3fhWsdgHEcRJKP+zsBUwXnrXud35XwZqNkd068kEx rf/yySvg0Ww2eGPmKg2lNr43hLJ2s/QcnOwvI= 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=5ZpRcmJdCImmNR7FcSsdneyefLqj1qn+N0zk72RQ8bE=; b=gKnlsvXkfvo7tV6JCFzK0YH08Vj3qfDvCASuDD7ChDYbr50mGYzbXSLFzSih3a1tjb UHwvdY3lvcDod0LlnFdycxDYEbV0iWGbmjHGU9XK5V0r5rVG86lZ8UED8Vk/kPpCax1l CljqsiAXJRLF/MebDAf54y0sjcmYbtKEZ4VYjBYFFpkkXv0uFwBDw+/2spy5k0DgJFCe xYGkFWNBJGQPEoJb3PwO5mKeX8yP2KV2cZQTPOAkWnDwJPqdxb5gJ+mVLYtEkv0EaMrn MsqC8umGKLbl/1VpLzX/KUD6dmJSZiaSuzd9qZiYxBZudtZvMEpgHwk4zLcqoLvLR/j7 FeIw== X-Gm-Message-State: AJcUukcSKcds1C7570Tjw3DFUUqi8Mx76nFp0sdTacxqg8hz0RcaEPnR 5L0O/hRTQi+56Eos0NjXr/LZ5BIbmOzzz+mo9nxli46gHwyxnLKtW7VmjlfGT6DuxMgZOZA9Wrv vMr54YKuXAfrH7Q== X-Google-Smtp-Source: ALg8bN45gSvpDanLQyiAFjU4Iu0mBwwuuj5P82Dd6uly+tNIisOBC6CTlG9P6GJpyuutVi//N+O/KFBE5IhpOv657Kg= X-Received: by 2002:a24:8ac7:: with SMTP id v190mr13116956itd.174.1547908918556; Sat, 19 Jan 2019 06:41:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Sat, 19 Jan 2019 07:41:31 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: John Bradley , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000003c5702057fd0a19f" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 14:42:04 -0000 --0000000000003c5702057fd0a19f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things. On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef wrote: > Sorry Brian, I was not clear with my statement. > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > Regards, > Rifaat > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> So maybe the draft is okay as is? >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >>> I wouldn't worry too much about the process. >>> If it makes sense to update the document, then feel free to do that. >>> >>> Regards, >>> Rifaat >>> >>> >>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >>> >>>> Yes the logical resource can be provided by "scope" >>>> >>>> Some implementations like Ping and Auth0 have been adding another >>>> parameter "aud" to identify the logical resource and then using scopes= to >>>> define permissions to the resource. >>>> >>>> Fortunately, we are using a different parameter name so not stepping o= n >>>> that.. >>>> >>>> We could go back and try to add text explaining the difference, but we >>>> are quite late in the process. >>>> >>>> I agree that a logical resource parameter may be helpful, but perhaps >>>> it should be a separate draft. >>>> >>>> John B. >>>> >>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>> richanna@amazon.com> wrote: >>>> >>>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide= a means of specifying a >>>>> logical identifier? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *OAuth on behalf of Vittorio Bertocci >>>>> >>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>> *To: *John Bradley >>>>> *Cc: *IETF oauth WG >>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>>> draft-ietf-oauth-resource-indicators-01 >>>>> >>>>> >>>>> >>>>> Thanks John for the background. >>>>> >>>>> I agree that from the client validation PoV, having an identifier >>>>> corresponding to a location makes things more solid. >>>>> >>>>> That said: the use of logical identifiers is widespread, as it has >>>>> significant practical advantages (think of services that assign gener= ated >>>>> hosting URLs only at deployment time, or services that are somehow gr= ouped >>>>> under the same logical audience across regions/environment/deployment= s). >>>>> People won't stop using logical identifiers, because they often have = no >>>>> alternative (generating new audiences on the fly at the AS every time= you >>>>> do a deployment and get assigned a new URL can be unfeasible). Leavin= g a >>>>> widely used approach as exercise to the reader seems a disservice to = the >>>>> community, given that this might lead to vendors (for example Microso= ft and >>>>> Auth0) keeping their own proprietary parameters, or developers misusi= ng the >>>>> ones in place; would make it hard for SDK developers to provide libra= ries >>>>> that work out of the box with different ASes; and so on. >>>>> >>>>> Would it be feasible to add such parameter directly in this spec? Tha= t >>>>> would eliminate the interop issues, and also gives us a chance to ful= ly >>>>> warn people about the security shortcomings of choosing that approach= . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley >>>>> wrote: >>>>> >>>>> We have discussed this. >>>>> >>>>> Audiences can certainly be logical identifiers. >>>>> >>>>> This however is a more specific location. The AS is free to map the >>>>> location into some abstract audience in the AT. >>>>> >>>>> From a security point of view once the client starts asking for >>>>> logical resources it can be tricked into asking for the wrong one as = a bad >>>>> resource can always lie about what logical resource it is. >>>>> >>>>> If we were to change it, how a client would validate it becomes >>>>> challenging to impossible. >>>>> >>>>> The AS is free to do whatever mapping of locations to identifiers it >>>>> needs for access tokens. >>>>> >>>>> Some implementations may want to keep additional parameters like >>>>> logical audience, but that should be separate from resource. >>>>> >>>>> John B. >>>>> >>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>>> >>>>> Hi Vittorio, >>>>> >>>>> >>>>> >>>>> The text you quoted is copied form the abstract of the draft itself. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Authors,* >>>>> >>>>> >>>>> >>>>> Should the draft be updated to cover the logical identifier case? >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>>> wrote: >>>>> >>>>> Hi Rifaat, >>>>> >>>>> one detail. The tech summary says >>>>> >>>>> >>>>> >>>>> An extension to the OAuth 2.0 Authorization Framework defining reques= t >>>>> >>>>> parameters that enable a client to explicitly signal to an authorizat= ion server >>>>> >>>>> about the *location* of the protected resource(s) to which it is requ= esting >>>>> >>>>> access. >>>>> >>>>> But at least in the Microsoft implementation, the resource identifier >>>>> doesn't *have* to be a network addressable URL (and if it is, it >>>>> doesn't strictly need to match the actual resource location). It can = be a >>>>> logical identifier, tho using the actual resource location there has >>>>> benefits (domain ownership check, prevention of token forwarding etc)= . >>>>> >>>>> Same for Auth0, the audience parameter is a logical identifier rather >>>>> than a location. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>>> rifaat.ietf@gmail.com> wrote: >>>>> >>>>> All, >>>>> >>>>> >>>>> >>>>> The following is the first shepherd write-up for >>>>> the draft-ietf-oauth-resource-indicators-01 document. >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators= /shepherdwriteup/ >>>>> >>>>> >>>>> >>>>> Please, take a look and let me know if I missed anything. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> >>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003c5702057fd0a19f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No apology needed, Rifaat. And I apologiz= e if what I said came off the wrong way. I was just trying to make light of= the situation. And I agree that we should not be hamstrung by the process = and there are times when it makes sense to be flexible with things.

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Sorry Brian, = I was not clear with my statement.
I meant to say that we sho= uld not allow the process to prevent the WG from producing a quality docume= nt without issues, assuming there is an issue in the first place.
Ideally we want to get these identified during the WGLC, but things happen= and sometimes the WG misses something.=C2=A0

I he= ar you and agree that this make things difficult for authors. We will make = sure that this does not become the norm, and we will try to stick to the pr= ocess as much as possible.

Regards,
=C2=A0Rifaat


On= Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wr= ote:
Thanks Rifaat. Process is as process does, right? I do kinda wan= t to grumble about WGCL having passed already but that's mostly because= replying to these kinds of threads is hard for me and I'll just get ov= er it...

As far as I understand t= hings, the security concerns come into play when the client is being told the by the resource how to=20 identity the resource like is described in=20 https://tools.ietf.org/html/draft-ietf-oauth-distributed-01<= /a> and using=20 the actual location in that context ,along with some other checks prescribe= d in that draft, prevents the kind of issues John=20 described earlier in the thread.

In cases where the client knows th= e resource a priori or out-of-band or configured or whatever, I don't think the same=20 security concerns arise. And using such a known value, be it an actual=20 location or logical representation, would be okay.

The=20 resource-indicators draft is admittedly somewhat location-centric in how it= talks=20 about the value of the 'resource' parameter. But ultimately it defi= nes=20 it as an absolute URI that indicates the location of the target service=20 or resource where access is being requested. A location can be varying=20 shades of abstract and I'd say that using a URI as 'resource' p= arameter=20 value that's a logical identifier that points to some resource is well= =20 within the bounds of the draft.




On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:
I wouldn't worry too much about the process= .
If it makes sense to update the document, then feel free to do that.<= /div>

Regards,
=C2=A0Rifaat
=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
=
Yes the=C2=A0logical resource can be provided by "sco= pe"

Some implementations like Pin= g and Auth0 have been adding another parameter "aud" to identify = the logical resource and then using scopes to define permissions to the res= ource.

Fortunately, we are using a different=C2=A0= parameter name so not stepping on that..

We could = go back and try to add text explaining the difference, but we are quite lat= e in the process.=C2=A0

I agree that a logical res= ource parameter=C2=A0may be helpful, but perhaps it should be a separate dr= aft.

John B.

<= div dir=3D"ltr" class=3D"gmail-m_-1025834894463380388gmail-m_-2550519830456= 053293gmail-m_1271392835416809484gmail-m_-7647986216064606501gmail_attr">On= Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrot= e:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org><= br> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0=
 Authorization Framework defining request 
parameters that enable a clie=
nt to explicitly signal to an authorization server 

about the location of =
the protected resource(s) to which it is requesting 

access.<=
/pre>

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003c5702057fd0a19f-- From nobody Sat Jan 19 09:01:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5D3130E62 for ; Sat, 19 Jan 2019 09:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVuJcjqJr_hw for ; Sat, 19 Jan 2019 09:01:07 -0800 (PST) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EBC130DEC for ; Sat, 19 Jan 2019 09:01:06 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id y185so3134287wmd.1 for ; Sat, 19 Jan 2019 09:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vu1037WA4iGNPlMerSBxn8Swx8nY8tYYe+9NX5e7cM0=; b=aIrOYwNFX+QlBySEBFbVsP9b72H5uXZLW3Z2qpZzgVoIxeYy1rivHYlliWcNpTX1y1 eGgXdFI57TRCVHFv1Z3dxtN5Bt9dHQcwYjGgCFxGUxFOUfNvttfEfUGfEoAr9DoAbxLR 6MCQe1xkBrJcu4uZ2ASyBwoTIPau6GTLEUqplU8MUc1zi+lXuviOh03ApqZA1XeaSK53 izgUBkL7U4x5II6bXNFIWLdFqE6l27s+Z/gN3zZRt+a01hszhY8D1Vnwr7r6lQKWFwd2 NMZgmWjCDvOd159QNSbt9/zQ0WNPQGlVCWZufhiiN7+44ib4JrV0luR7l+HBus41SBwX DoHQ== 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=Vu1037WA4iGNPlMerSBxn8Swx8nY8tYYe+9NX5e7cM0=; b=nxAO4Oyn7PXxOU37mE1t/0xlq568hDyaxk2mEQ63C606wfi6oHFXn0mA2N6NyIJFTU kAgjMjRfJUodoeIetjyZeKWKbvxRT3mv6mCl0UFwX9RY2MTbCUhJIb8rz5ON6lPXFJNh qrel69u+Ku3L4C4iVKmMC3/1ybD3p7j4gs70XPLDIkwoiH/7Gm8gclXzz4lnQxYH1rtT oATrhhUMpw46NV0UjlI3jOlOBUc3sfqJY7jBdE60pRMplSORRTYJlZkIAYtPvpBenRi4 sSfod1VX2ETcRlN8XkR6wcz/J+zzt3upjx3nwEgkXXFFUzx9+uajmSHv6fUESRSGd8j0 femw== X-Gm-Message-State: AJcUukf5q3lU4inNjRFQ56tSV2s1fiCh9p8G5voBlm6TnekjtwIGrJq9 oTOI50ZYJioHYSAlfRo0zlt78IKIG+buqngHoDUCg0Jg0rxqlQ== X-Google-Smtp-Source: ALg8bN56Uv+fCfs5UAcItXlDjHyLGD0m+vWutZ5RuGcu0dCOp+Z5Tv4EPguj0QoxeE8545OeKIuUnfnIcw1cqRL0IO4= X-Received: by 2002:a1c:2501:: with SMTP id l1mr20112806wml.102.1547917264553; Sat, 19 Jan 2019 09:01:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Sat, 19 Jan 2019 14:00:48 -0300 Message-ID: To: Brian Campbell Cc: Rifaat Shekh-Yusef , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000b221a6057fd292a1" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 17:01:13 -0000 --000000000000b221a6057fd292a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We need to decide if we want to make a change. For security we are location centric. I prefer to keep resource location separate from logical audience that can be a scope or other parameter. If becomes harder for people to use the parameter correctly if we are too flexible. I would rather have a separate logical audience parameter if we think we want one. John B. On Sat, Jan 19, 2019, 11:41 AM Brian Campbell No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > >> Sorry Brian, I was not clear with my statement. >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> Regards, >> Rifaat >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>> grumble about WGCL having passed already but that's mostly because repl= ying >>> to these kinds of threads is hard for me and I'll just get over it... >>> >>> As far as I understand things, the security concerns come into play whe= n >>> the client is being told the by the resource how to identity the resour= ce >>> like is described in >>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >>> the actual location in that context ,along with some other checks >>> prescribed in that draft, prevents the kind of issues John described >>> earlier in the thread. >>> >>> In cases where the client knows the resource a priori or out-of-band or >>> configured or whatever, I don't think the same security concerns arise.= And >>> using such a known value, be it an actual location or logical >>> representation, would be okay. >>> >>> The resource-indicators draft is admittedly somewhat location-centric i= n >>> how it talks about the value of the 'resource' parameter. But ultimatel= y it >>> defines it as an absolute URI that indicates the location of the target >>> service or resource where access is being requested. A location can be >>> varying shades of abstract and I'd say that using a URI as 'resource' >>> parameter value that's a logical identifier that points to some resourc= e is >>> well within the bounds of the draft. >>> >>> So maybe the draft is okay as is? >>> >>> Or perhaps that's too much to be left as an exerciser to the reader? >>> And some text should be added and/or adjusted so the resource-indicator= s >>> draft would be a little more open/clear about the parameter value >>> potentially being more of a logical or abstract identifier and not >>> necessarily a network addressable URL? >>> >>> >>> >>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>>> I wouldn't worry too much about the process. >>>> If it makes sense to update the document, then feel free to do that. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote= : >>>> >>>>> Yes the logical resource can be provided by "scope" >>>>> >>>>> Some implementations like Ping and Auth0 have been adding another >>>>> parameter "aud" to identify the logical resource and then using scope= s to >>>>> define permissions to the resource. >>>>> >>>>> Fortunately, we are using a different parameter name so not stepping >>>>> on that.. >>>>> >>>>> We could go back and try to add text explaining the difference, but w= e >>>>> are quite late in the process. >>>>> >>>>> I agree that a logical resource parameter may be helpful, but perhaps >>>>> it should be a separate draft. >>>>> >>>>> John B. >>>>> >>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>>> richanna@amazon.com> wrote: >>>>> >>>>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provid= e a means of specifying a >>>>>> logical identifier? >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From: *OAuth on behalf of Vittorio >>>>>> Bertocci >>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>>> *To: *John Bradley >>>>>> *Cc: *IETF oauth WG >>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>>>> draft-ietf-oauth-resource-indicators-01 >>>>>> >>>>>> >>>>>> >>>>>> Thanks John for the background. >>>>>> >>>>>> I agree that from the client validation PoV, having an identifier >>>>>> corresponding to a location makes things more solid. >>>>>> >>>>>> That said: the use of logical identifiers is widespread, as it has >>>>>> significant practical advantages (think of services that assign gene= rated >>>>>> hosting URLs only at deployment time, or services that are somehow g= rouped >>>>>> under the same logical audience across regions/environment/deploymen= ts). >>>>>> People won't stop using logical identifiers, because they often have= no >>>>>> alternative (generating new audiences on the fly at the AS every tim= e you >>>>>> do a deployment and get assigned a new URL can be unfeasible). Leavi= ng a >>>>>> widely used approach as exercise to the reader seems a disservice to= the >>>>>> community, given that this might lead to vendors (for example Micros= oft and >>>>>> Auth0) keeping their own proprietary parameters, or developers misus= ing the >>>>>> ones in place; would make it hard for SDK developers to provide libr= aries >>>>>> that work out of the box with different ASes; and so on. >>>>>> >>>>>> Would it be feasible to add such parameter directly in this spec? >>>>>> That would eliminate the interop issues, and also gives us a chance = to >>>>>> fully warn people about the security shortcomings of choosing that a= pproach. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley >>>>>> wrote: >>>>>> >>>>>> We have discussed this. >>>>>> >>>>>> Audiences can certainly be logical identifiers. >>>>>> >>>>>> This however is a more specific location. The AS is free to map the >>>>>> location into some abstract audience in the AT. >>>>>> >>>>>> From a security point of view once the client starts asking for >>>>>> logical resources it can be tricked into asking for the wrong one as= a bad >>>>>> resource can always lie about what logical resource it is. >>>>>> >>>>>> If we were to change it, how a client would validate it becomes >>>>>> challenging to impossible. >>>>>> >>>>>> The AS is free to do whatever mapping of locations to identifiers it >>>>>> needs for access tokens. >>>>>> >>>>>> Some implementations may want to keep additional parameters like >>>>>> logical audience, but that should be separate from resource. >>>>>> >>>>>> John B. >>>>>> >>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> >>>>>> >>>>>> The text you quoted is copied form the abstract of the draft itself. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Authors,* >>>>>> >>>>>> >>>>>> >>>>>> Should the draft be updated to cover the logical identifier case? >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>>>> wrote: >>>>>> >>>>>> Hi Rifaat, >>>>>> >>>>>> one detail. The tech summary says >>>>>> >>>>>> >>>>>> >>>>>> An extension to the OAuth 2.0 Authorization Framework defining reque= st >>>>>> >>>>>> parameters that enable a client to explicitly signal to an authoriza= tion server >>>>>> >>>>>> about the *location* of the protected resource(s) to which it is req= uesting >>>>>> >>>>>> access. >>>>>> >>>>>> But at least in the Microsoft implementation, the resource identifie= r >>>>>> doesn't *have* to be a network addressable URL (and if it is, it >>>>>> doesn't strictly need to match the actual resource location). It can= be a >>>>>> logical identifier, tho using the actual resource location there has >>>>>> benefits (domain ownership check, prevention of token forwarding etc= ). >>>>>> >>>>>> Same for Auth0, the audience parameter is a logical identifier rathe= r >>>>>> than a location. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>>>> rifaat.ietf@gmail.com> wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> >>>>>> >>>>>> The following is the first shepherd write-up for >>>>>> the draft-ietf-oauth-resource-indicators-01 document. >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicator= s/shepherdwriteup/ >>>>>> >>>>>> >>>>>> >>>>>> Please, take a look and let me know if I missed anything. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --000000000000b221a6057fd292a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We need to decide if we want to make a change.=C2=A0=C2= =A0

For security we are locati= on centric.=C2=A0=C2=A0

= I prefer to keep resource location separate from logical audience that can = be a scope or other parameter.=C2=A0=C2=A0

If becomes harder for people to use the parameter correc= tly if we are too flexible.=C2=A0=C2=A0

I would rather have a separate logical audience parameter i= f we think we want one.=C2=A0=C2=A0

John B.=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:
No apol= ogy needed, Rifaat. And I apologize if what I said came off the wrong way. = I was just trying to make light of the situation. And I agree that we shoul= d not be hamstrung by the process and there are times when it makes sense t= o be flexible with things.

<= div dir=3D"ltr" class=3D"m_2914958611980428470gmail_attr">On Fri, Jan 18, 2= 019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrot= e:
Sorry Brian, I was not clear with my statement.
I meant t= o say that we should not allow the process to prevent the WG from producing= a quality document without issues, assuming there is an issue in the first= place.
Ideally we want to get these identified during the WGLC, = but things happen and sometimes the WG misses something.=C2=A0
I hear you and agree that this make things difficult for autho= rs. We will make sure that this does not become the norm, and we will try t= o stick to the process as much as possible.

<= div>Regards,
=C2=A0Rifaat


On Fri, Jan 18, 2019 at 5:35 PM Brian C= ampbell <bcampbell@pingidentity.com> wrote:
Thanks = Rifaat. Process is as process does, right? I do kinda want to grumble about= WGCL having passed already but that's mostly because replying to these= kinds of threads is hard for me and I'll just get over it...

As far as I understand things, the securit= y concerns come into play when the client is being told the by the resource how to=20 identity the resource like is described in=20 https://tools.ietf.org/html/draft-ietf-oa= uth-distributed-01 and using=20 the actual location in that context ,along with some other checks prescribe= d in that draft, prevents the kind of issues John=20 described earlier in the thread.

In cases where the client knows th= e resource a priori or out-of-band or configured or whatever, I don't think the same=20 security concerns arise. And using such a known value, be it an actual=20 location or logical representation, would be okay.

The=20 resource-indicators draft is admittedly somewhat location-centric in how it= talks=20 about the value of the 'resource' parameter. But ultimately it defi= nes=20 it as an absolute URI that indicates the location of the target service=20 or resource where access is being requested. A location can be varying=20 shades of abstract and I'd say that using a URI as 'resource' p= arameter=20 value that's a logical identifier that points to some resource is well= =20 within the bounds of the draft.

S= o maybe the draft is okay as is?

Or perhaps that&#= 39;s too much to be left as an exerciser to the reader?=C2=A0 And some text= should be added and/or adjusted so the resource-indicators draft would be = a little more open/clear about the parameter value potentially being more o= f a logical or abstract identifier and not necessarily a network addressabl= e URL?



On Fri, Jan 18, 2019 at 1:18 P= M Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I wouldn&= #39;t worry too much about the process.
If it makes sense to update the= document, then feel free to do that.

Regards,
=C2=A0Rifaat
=C2=A0

On F= ri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote= :
Yes the=C2=A0logical resource can be provided by "= scope"

Some implementations like = Ping and Auth0 have been adding another parameter "aud" to identi= fy the logical resource and then using scopes to define permissions to the = resource.

Fortunately, we are using a different=C2= =A0parameter name so not stepping on that..

We cou= ld go back and try to add text explaining the difference, but we are quite = late in the process.=C2=A0

I agree that a logical = resource parameter=C2=A0may be helpful, but perhaps it should be a separate= draft.

John B.

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Anna= belle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-b= ounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are so= mehow grouped under the same logical audience across regions/environment/deployments). People won't stop us= ing logical identifiers, because they often have no alternative (generating= new audiences on the fly at the AS every time you do a deployment and get = assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservic= e to the community, given that this might lead to vendors (for example Micr= osoft and Auth0) keeping their own proprietary parameters, or developers mi= susing the ones in place; would make it hard for SDK developers to provide libraries that work out of the = box with different ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing tha= t approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7j= tb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0=
 Authorization Framework defining request 
parameters that enable a clie=
nt to explicitly signal to an authorization server 

about the location of =
the protected resource(s) to which it is requesting 

access.<=
/pre>

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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



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

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

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--000000000000b221a6057fd292a1-- From nobody Sat Jan 19 12:34:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AAD130E93 for ; Sat, 19 Jan 2019 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfwPQWw0w0oP for ; Sat, 19 Jan 2019 12:34:25 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AB8130E8B for ; Sat, 19 Jan 2019 12:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5LGBxHDFELzyGwLFLcXimu0CuEygOHnU5PZ3P0yHhzc=; b=DOQ4c7oD8fe4EY22L/jo8qe6H+q6ZZOUSBpH5cond8yvek5DVtlooxsLgfofXSo05UosojyGM1qtx51G9RwUyR259Ne1QP+66SyhB4ovKfTP/amP2vU6CastEp9RwnxwDOCajKkewWJlsY2xVd9fwXH9dzbzpykmyR/brvq65Ug= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1579.0; Sat, 19 Jan 2019 20:34:13 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::997b:f79f:cbc7:2fa9]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::997b:f79f:cbc7:2fa9%5]) with mapi id 15.20.1579.000; Sat, 19 Jan 2019 20:34:13 +0000 From: Mike Jones To: John Bradley , Brian Campbell CC: Vittorio Bertocci , IETF oauth WG Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMSm6zRRv4Nr0eerioJ6LCFT6Wzcp6AgABNkQCAABqbAIABMd2AgABiBYCAAAiJAIAAAu6AgAAmUgCAAC6ggIAA30eAgAAm6gCAADowsA== Date: Sat, 19 Jan 2019 20:34:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-01-19T20:34:04.2267323Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6ab79e62-e284-42da-aa67-9a711c00735c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [50.47.86.113] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0292; 6:xRO7TbMURKGHfvNwEd2em4dLfs1vkI4g1A2uBlv3KTBfOPVPsaVinKkZMP0cFd+2WjK0cCh+VhOQ+5SJu7bDuhLLgKYA2lrsE+fR6zypkj8KM00WR6+I2oF98/jmFCaxErnniRZDq/5hsP9BhKpaUAOLASDsdjEGn5+yc+5Az4p9qR8x9ezCBGLwpdf00uLgjgtG0OwAlih6UThx7dbw9zdnfK6vfBZ2vZsYLjJrX4C9MtSlpj7l3SQMGRXcWFK/JGf4rAFNHRAkRakYdMSuN4b14pdBADVVIAe/Fbmiqmaz9dPpLLgTjnoxeDLXrovQ5nYuwz6aX1aIoOYq3DfP1bt8wNhlHsBY0s8HtXbrRQbgDzlGhGOwmoZHSVNZgNB6wo2iCXhDwirth57ixcx2sy6kdJJKC0S+o4bNxuClhIJu9xdRzCoDWPTQCkyK/GM+OJ20ZYvXCVR7Wr25S7s5cg==; 5:PXcaKtZSsRYULHqX4IBDgLMSdHl9ccbRTPzCqky9iEllg8NxcWdOnc7IhBoG/y9WpWp9VR2TRRqhnb04f/k8i8u7P8OXRL8xEhC52Uquib3yshI6t+wDOMSDKywbw+7C5NYYuV6OgB/X9jpNxRaDoEYxYSPj5Ts1NrLo+r9T1wFx3OMpL5ocH5NQY//xJxNBRuuAmL1KznA5dyQz3eLgNA==; 7:0EWj49epGfpmQ44QYEkp1n+oCcU5fYtgW0USN6Kvzif6qLwrFIUO+IeC4J01OKdt0SI/AZ6NCuQh4drCROp6xVCbjVFuHxc+48AshX4OrWz9+UqADhEzqrUcCyw2/88WlowPznK7RFBt8RyMoS8u5Q== x-ms-office365-filtering-correlation-id: 43a34b85-8610-4eea-2d35-08d67e4d79a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:BL0PR00MB0292; x-ms-traffictypediagnostic: BL0PR00MB0292: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 09222B39F5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(136003)(39860400002)(199004)(189003)(25786009)(6116002)(66066001)(68736007)(6306002)(790700001)(10090500001)(10290500003)(97736004)(71190400001)(30864003)(606006)(81156014)(81166006)(8676002)(7736002)(86362001)(71200400001)(8936002)(3846002)(5024004)(6436002)(478600001)(14444005)(74316002)(86612001)(256004)(53936002)(54906003)(2906002)(76176011)(8990500004)(53546011)(102836004)(22452003)(476003)(110136005)(99286004)(11346002)(446003)(72206003)(55016002)(6506007)(106356001)(966005)(229853002)(486006)(14454004)(93886005)(33656002)(6246003)(105586002)(236005)(316002)(7696005)(9686003)(54896002)(6346003)(26005)(186003)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PTkbyoRqgCLHW2hxh6i4RFbatxcqfv0exggWYGYxQEghAi4LBxzgIGXAKivqvjlVl1iMN2C6JFaizqePMIYAXx8K9F1v7roCvHKFRpdHPX8bQ3ESgduOsNOSJUdmoPLx0ByoahL6hISz6xOABLQI+PB5NXsOfaORkhX7tLUnZzGBINjnmAYYUbgIKUenSjw+k6YE6xkhyk8cCEyAyADLH/INpsPf7LKxH5XNMaxObgHOc2QLj8elz7Fpw6KNKGP+xxt2knee3JWoRXW/AqMYWJfuwEjis5dToFBsGttyS/rLIS5+XlNolp1ALON7S0Nh8jIwIneKOtffhilEbLlx23iYEGXeL9bYNFUctJyk/dIb1carvYxMBoZsDB07P9O15H/eidLw1UPOVhe5OKOpP8DrjoIPNFnniopi+rvM/DA= Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292F3C224D081198866F89CF59D0BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43a34b85-8610-4eea-2d35-08d67e4d79a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2019 20:34:13.5874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 20:34:31 -0000 --_000_BL0PR00MB0292F3C224D081198866F89CF59D0BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHRoYXQg4oCccmVzb3VyY2XigJ0gc2hvdWxkIGJlIGEgc3BlY2lmaWMgbmV0 d29yay1hZGRyZXNzYWJsZSBVUkwgd2hlcmVhcyBhIHNlcGFyYXRlIGF1ZGllbmNlIHBhcmFtZXRl ciAobGlrZSDigJxhdWTigJ0gaW4gSldUcykgY2FuIHJlZmVyIHRvIG9uZSBvciBtb3JlIGxvZ2lj YWwgcmVzb3VyY2VzLiAgVGhleSBhcmUgZGlmZmVyZW50LCBpZiByZWxhdGVkLCB0aGluZ3MuDQoN Ck5vdGUgdGhhdCB0aGUgQUNFIFdHIGlzIHByb3Bvc2luZyB0byByZWdpc3RlciBhIGxvZ2ljYWwg YXVkaWVuY2UgcGFyYW1ldGVyIOKAnHJlcV9hdWTigJ0gaW4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wMSAtIHBhcnRseSBiYXNlZCBvbiBm ZWVkYmFjayBmcm9tIE9BdXRoIFdHIG1lbWJlcnMuICBUaGlzIGlzIGEgZ2VuZXJhbCBPQXV0aCBw YXJhbWV0ZXIsIHdoaWNoIGFueSBPQXV0aCBkZXBsb3ltZW50IHdpbGwgYmUgYWJsZSB0byB1c2Uu DQoNCkkgdGhlcmVmb3JlIGJlbGlldmUgdGhhdCBubyBjaGFuZ2VzIGFyZSBuZWVkZWQgdG8gZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLCBhcyB0aGUgbG9naWNhbCBhdWRpZW5j ZSB3b3JrIGlzIGFscmVhZHkgaGFwcGVuaW5nIGluIGFub3RoZXIgZHJhZnQuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSm9o biBCcmFkbGV5DQpTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxOSwgMjAxOSA5OjAxIEFNDQpUbzog QnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IFZpdHRvcmlv IEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz47IElFVEYgb2F1 dGggV0cgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2hlcGhlcmQg d3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0KDQpX ZSBuZWVkIHRvIGRlY2lkZSBpZiB3ZSB3YW50IHRvIG1ha2UgYSBjaGFuZ2UuDQoNCkZvciBzZWN1 cml0eSB3ZSBhcmUgbG9jYXRpb24gY2VudHJpYy4NCg0KSSBwcmVmZXIgdG8ga2VlcCByZXNvdXJj ZSBsb2NhdGlvbiBzZXBhcmF0ZSBmcm9tIGxvZ2ljYWwgYXVkaWVuY2UgdGhhdCBjYW4gYmUgYSBz Y29wZSBvciBvdGhlciBwYXJhbWV0ZXIuDQoNCklmIGJlY29tZXMgaGFyZGVyIGZvciBwZW9wbGUg dG8gdXNlIHRoZSBwYXJhbWV0ZXIgY29ycmVjdGx5IGlmIHdlIGFyZSB0b28gZmxleGlibGUuDQoN Ckkgd291bGQgcmF0aGVyIGhhdmUgYSBzZXBhcmF0ZSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRl ciBpZiB3ZSB0aGluayB3ZSB3YW50IG9uZS4NCg0KSm9obiBCLg0KDQpPbiBTYXQsIEphbiAxOSwg MjAxOSwgMTE6NDEgQU0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4gd3JvdGU6DQpObyBhcG9sb2d5IG5l ZWRlZCwgUmlmYWF0LiBBbmQgSSBhcG9sb2dpemUgaWYgd2hhdCBJIHNhaWQgY2FtZSBvZmYgdGhl IHdyb25nIHdheS4gSSB3YXMganVzdCB0cnlpbmcgdG8gbWFrZSBsaWdodCBvZiB0aGUgc2l0dWF0 aW9uLiBBbmQgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgYmUgaGFtc3RydW5nIGJ5IHRoZSBw cm9jZXNzIGFuZCB0aGVyZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBzZW5zZSB0byBiZSBmbGV4 aWJsZSB3aXRoIHRoaW5ncy4NCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNjoyMiBQTSBSaWZh YXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQpTb3JyeSBCcmlhbiwgSSB3YXMgbm90IGNsZWFyIHdpdGggbXkg c3RhdGVtZW50Lg0KSSBtZWFudCB0byBzYXkgdGhhdCB3ZSBzaG91bGQgbm90IGFsbG93IHRoZSBw cm9jZXNzIHRvIHByZXZlbnQgdGhlIFdHIGZyb20gcHJvZHVjaW5nIGEgcXVhbGl0eSBkb2N1bWVu dCB3aXRob3V0IGlzc3VlcywgYXNzdW1pbmcgdGhlcmUgaXMgYW4gaXNzdWUgaW4gdGhlIGZpcnN0 IHBsYWNlLg0KSWRlYWxseSB3ZSB3YW50IHRvIGdldCB0aGVzZSBpZGVudGlmaWVkIGR1cmluZyB0 aGUgV0dMQywgYnV0IHRoaW5ncyBoYXBwZW4gYW5kIHNvbWV0aW1lcyB0aGUgV0cgbWlzc2VzIHNv bWV0aGluZy4NCg0KSSBoZWFyIHlvdSBhbmQgYWdyZWUgdGhhdCB0aGlzIG1ha2UgdGhpbmdzIGRp ZmZpY3VsdCBmb3IgYXV0aG9ycy4gV2Ugd2lsbCBtYWtlIHN1cmUgdGhhdCB0aGlzIGRvZXMgbm90 IGJlY29tZSB0aGUgbm9ybSwgYW5kIHdlIHdpbGwgdHJ5IHRvIHN0aWNrIHRvIHRoZSBwcm9jZXNz IGFzIG11Y2ggYXMgcG9zc2libGUuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gRnJpLCBK YW4gMTgsIDIwMTkgYXQgNTozNSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpUaGFu a3MgUmlmYWF0LiBQcm9jZXNzIGlzIGFzIHByb2Nlc3MgZG9lcywgcmlnaHQ/IEkgZG8ga2luZGEg d2FudCB0byBncnVtYmxlIGFib3V0IFdHQ0wgaGF2aW5nIHBhc3NlZCBhbHJlYWR5IGJ1dCB0aGF0 J3MgbW9zdGx5IGJlY2F1c2UgcmVwbHlpbmcgdG8gdGhlc2Uga2luZHMgb2YgdGhyZWFkcyBpcyBo YXJkIGZvciBtZSBhbmQgSSdsbCBqdXN0IGdldCBvdmVyIGl0Li4uDQoNCkFzIGZhciBhcyBJIHVu ZGVyc3RhbmQgdGhpbmdzLCB0aGUgc2VjdXJpdHkgY29uY2VybnMgY29tZSBpbnRvIHBsYXkgd2hl biB0aGUgY2xpZW50IGlzIGJlaW5nIHRvbGQgdGhlIGJ5IHRoZSByZXNvdXJjZSBob3cgdG8gaWRl bnRpdHkgdGhlIHJlc291cmNlIGxpa2UgaXMgZGVzY3JpYmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVkLTAxIGFuZCB1c2luZyB0aGUg YWN0dWFsIGxvY2F0aW9uIGluIHRoYXQgY29udGV4dCAsYWxvbmcgd2l0aCBzb21lIG90aGVyIGNo ZWNrcyBwcmVzY3JpYmVkIGluIHRoYXQgZHJhZnQsIHByZXZlbnRzIHRoZSBraW5kIG9mIGlzc3Vl cyBKb2huIGRlc2NyaWJlZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQuDQoNCkluIGNhc2VzIHdoZXJl IHRoZSBjbGllbnQga25vd3MgdGhlIHJlc291cmNlIGEgcHJpb3JpIG9yIG91dC1vZi1iYW5kIG9y IGNvbmZpZ3VyZWQgb3Igd2hhdGV2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIHNhbWUgc2VjdXJpdHkg Y29uY2VybnMgYXJpc2UuIEFuZCB1c2luZyBzdWNoIGEga25vd24gdmFsdWUsIGJlIGl0IGFuIGFj dHVhbCBsb2NhdGlvbiBvciBsb2dpY2FsIHJlcHJlc2VudGF0aW9uLCB3b3VsZCBiZSBva2F5Lg0K DQpUaGUgcmVzb3VyY2UtaW5kaWNhdG9ycyBkcmFmdCBpcyBhZG1pdHRlZGx5IHNvbWV3aGF0IGxv Y2F0aW9uLWNlbnRyaWMgaW4gaG93IGl0IHRhbGtzIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgJ3Jl c291cmNlJyBwYXJhbWV0ZXIuIEJ1dCB1bHRpbWF0ZWx5IGl0IGRlZmluZXMgaXQgYXMgYW4gYWJz b2x1dGUgVVJJIHRoYXQgaW5kaWNhdGVzIHRoZSBsb2NhdGlvbiBvZiB0aGUgdGFyZ2V0IHNlcnZp Y2Ugb3IgcmVzb3VyY2Ugd2hlcmUgYWNjZXNzIGlzIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2NhdGlv biBjYW4gYmUgdmFyeWluZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1c2lu ZyBhIFVSSSBhcyAncmVzb3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2FsIGlk ZW50aWZpZXIgdGhhdCBwb2ludHMgdG8gc29tZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0aGUg Ym91bmRzIG9mIHRoZSBkcmFmdC4NCg0KU28gbWF5YmUgdGhlIGRyYWZ0IGlzIG9rYXkgYXMgaXM/ DQoNCk9yIHBlcmhhcHMgdGhhdCdzIHRvbyBtdWNoIHRvIGJlIGxlZnQgYXMgYW4gZXhlcmNpc2Vy IHRvIHRoZSByZWFkZXI/ICBBbmQgc29tZSB0ZXh0IHNob3VsZCBiZSBhZGRlZCBhbmQvb3IgYWRq dXN0ZWQgc28gdGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQgd291bGQgYmUgYSBsaXR0bGUg bW9yZSBvcGVuL2NsZWFyIGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFsdWUgcG90ZW50aWFsbHkgYmVp bmcgbW9yZSBvZiBhIGxvZ2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBhbmQgbm90IG5lY2Vz c2FyaWx5IGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkw/DQoNCg0KDQpPbiBGcmksIEphbiAxOCwg MjAxOSBhdCAxOjE4IFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29t PG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgd291bGRuJ3Qgd29ycnkg dG9vIG11Y2ggYWJvdXQgdGhlIHByb2Nlc3MuDQpJZiBpdCBtYWtlcyBzZW5zZSB0byB1cGRhdGUg dGhlIGRvY3VtZW50LCB0aGVuIGZlZWwgZnJlZSB0byBkbyB0aGF0Lg0KDQpSZWdhcmRzLA0KIFJp ZmFhdA0KDQoNCk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9obiBCcmFkbGV5IDx2 ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNClllcyB0 aGUgbG9naWNhbCByZXNvdXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgInNjb3BlIg0KDQpTb21lIGlt cGxlbWVudGF0aW9ucyBsaWtlIFBpbmcgYW5kIEF1dGgwIGhhdmUgYmVlbiBhZGRpbmcgYW5vdGhl ciBwYXJhbWV0ZXIgImF1ZCIgdG8gaWRlbnRpZnkgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgYW5kIHRo ZW4gdXNpbmcgc2NvcGVzIHRvIGRlZmluZSBwZXJtaXNzaW9ucyB0byB0aGUgcmVzb3VyY2UuDQoN CkZvcnR1bmF0ZWx5LCB3ZSBhcmUgdXNpbmcgYSBkaWZmZXJlbnQgcGFyYW1ldGVyIG5hbWUgc28g bm90IHN0ZXBwaW5nIG9uIHRoYXQuLg0KDQpXZSBjb3VsZCBnbyBiYWNrIGFuZCB0cnkgdG8gYWRk IHRleHQgZXhwbGFpbmluZyB0aGUgZGlmZmVyZW5jZSwgYnV0IHdlIGFyZSBxdWl0ZSBsYXRlIGlu IHRoZSBwcm9jZXNzLg0KDQpJIGFncmVlIHRoYXQgYSBsb2dpY2FsIHJlc291cmNlIHBhcmFtZXRl ciBtYXkgYmUgaGVscGZ1bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZHJh ZnQuDQoNCkpvaG4gQi4NCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNDozOCBQTSBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFA YW1hem9uLmNvbT4+IHdyb3RlOg0KRG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIg YWxyZWFkeSBwcm92aWRlIGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmll cj8NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZy b206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgw LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0K RGF0ZTogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDE5IGF0IDU6NDcgQU0NClRvOiBKb2huIEJyYWRs ZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpDYzogSUVU RiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnMtMDENCg0KVGhhbmtzIEpvaG4gZm9yIHRoZSBiYWNrZ3JvdW5k Lg0KSSBhZ3JlZSB0aGF0IGZyb20gdGhlIGNsaWVudCB2YWxpZGF0aW9uIFBvViwgaGF2aW5nIGFu IGlkZW50aWZpZXIgY29ycmVzcG9uZGluZyB0byBhIGxvY2F0aW9uIG1ha2VzIHRoaW5ncyBtb3Jl IHNvbGlkLg0KVGhhdCBzYWlkOiB0aGUgdXNlIG9mIGxvZ2ljYWwgaWRlbnRpZmllcnMgaXMgd2lk ZXNwcmVhZCwgYXMgaXQgaGFzIHNpZ25pZmljYW50IHByYWN0aWNhbCBhZHZhbnRhZ2VzICh0aGlu ayBvZiBzZXJ2aWNlcyB0aGF0IGFzc2lnbiBnZW5lcmF0ZWQgaG9zdGluZyBVUkxzIG9ubHkgYXQg ZGVwbG95bWVudCB0aW1lLCBvciBzZXJ2aWNlcyB0aGF0IGFyZSBzb21laG93IGdyb3VwZWQgdW5k ZXIgdGhlIHNhbWUgbG9naWNhbCBhdWRpZW5jZSBhY3Jvc3MgcmVnaW9ucy9lbnZpcm9ubWVudC9k ZXBsb3ltZW50cykuIFBlb3BsZSB3b24ndCBzdG9wIHVzaW5nIGxvZ2ljYWwgaWRlbnRpZmllcnMs IGJlY2F1c2UgdGhleSBvZnRlbiBoYXZlIG5vIGFsdGVybmF0aXZlIChnZW5lcmF0aW5nIG5ldyBh dWRpZW5jZXMgb24gdGhlIGZseSBhdCB0aGUgQVMgZXZlcnkgdGltZSB5b3UgZG8gYSBkZXBsb3lt ZW50IGFuZCBnZXQgYXNzaWduZWQgYSBuZXcgVVJMIGNhbiBiZSB1bmZlYXNpYmxlKS4gTGVhdmlu ZyBhIHdpZGVseSB1c2VkIGFwcHJvYWNoIGFzIGV4ZXJjaXNlIHRvIHRoZSByZWFkZXIgc2VlbXMg YSBkaXNzZXJ2aWNlIHRvIHRoZSBjb21tdW5pdHksIGdpdmVuIHRoYXQgdGhpcyBtaWdodCBsZWFk IHRvIHZlbmRvcnMgKGZvciBleGFtcGxlIE1pY3Jvc29mdCBhbmQgQXV0aDApIGtlZXBpbmcgdGhl aXIgb3duIHByb3ByaWV0YXJ5IHBhcmFtZXRlcnMsIG9yIGRldmVsb3BlcnMgbWlzdXNpbmcgdGhl IG9uZXMgaW4gcGxhY2U7IHdvdWxkIG1ha2UgaXQgaGFyZCBmb3IgU0RLIGRldmVsb3BlcnMgdG8g cHJvdmlkZSBsaWJyYXJpZXMgdGhhdCB3b3JrIG91dCBvZiB0aGUgYm94IHdpdGggZGlmZmVyZW50 IEFTZXM7IGFuZCBzbyBvbi4NCldvdWxkIGl0IGJlIGZlYXNpYmxlIHRvIGFkZCBzdWNoIHBhcmFt ZXRlciBkaXJlY3RseSBpbiB0aGlzIHNwZWM/IFRoYXQgd291bGQgZWxpbWluYXRlIHRoZSBpbnRl cm9wIGlzc3VlcywgYW5kIGFsc28gZ2l2ZXMgdXMgYSBjaGFuY2UgdG8gZnVsbHkgd2FybiBwZW9w bGUgYWJvdXQgdGhlIHNlY3VyaXR5IHNob3J0Y29taW5ncyBvZiBjaG9vc2luZyB0aGF0IGFwcHJv YWNoLg0KDQoNCg0KT24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgNDozMiBQTSBKb2huIEJyYWRsZXkg PHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpX ZSBoYXZlIGRpc2N1c3NlZCB0aGlzLg0KDQpBdWRpZW5jZXMgY2FuIGNlcnRhaW5seSBiZSBsb2dp Y2FsIGlkZW50aWZpZXJzLg0KDQpUaGlzIGhvd2V2ZXIgaXMgYSBtb3JlIHNwZWNpZmljIGxvY2F0 aW9uLiAgVGhlIEFTIGlzIGZyZWUgdG8gbWFwIHRoZSBsb2NhdGlvbiBpbnRvIHNvbWUgYWJzdHJh Y3QgYXVkaWVuY2UgaW4gdGhlIEFULg0KDQpGcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBv bmNlIHRoZSBjbGllbnQgc3RhcnRzIGFza2luZyBmb3IgbG9naWNhbCByZXNvdXJjZXMgaXQgY2Fu IGJlIHRyaWNrZWQgaW50byBhc2tpbmcgZm9yIHRoZSB3cm9uZyBvbmUgYXMgYSBiYWQgcmVzb3Vy Y2UgY2FuIGFsd2F5cyBsaWUgYWJvdXQgd2hhdCBsb2dpY2FsIHJlc291cmNlIGl0IGlzLg0KDQpJ ZiB3ZSB3ZXJlIHRvIGNoYW5nZSBpdCwgaG93IGEgY2xpZW50IHdvdWxkIHZhbGlkYXRlIGl0IGJl Y29tZXMgY2hhbGxlbmdpbmcgdG8gaW1wb3NzaWJsZS4NCg0KVGhlIEFTIGlzIGZyZWUgdG8gZG8g d2hhdGV2ZXIgbWFwcGluZyBvZiBsb2NhdGlvbnMgdG8gaWRlbnRpZmllcnMgaXQgbmVlZHMgZm9y IGFjY2VzcyB0b2tlbnMuDQoNClNvbWUgaW1wbGVtZW50YXRpb25zIG1heSB3YW50IHRvIGtlZXAg YWRkaXRpb25hbCBwYXJhbWV0ZXJzIGxpa2UgbG9naWNhbCBhdWRpZW5jZSwgYnV0IHRoYXQgc2hv dWxkIGJlIHNlcGFyYXRlIGZyb20gcmVzb3VyY2UuDQoNCkpvaG4gQi4NCk9uIDEvMTcvMjAxOSA5 OjU2IEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgd3JvdGU6DQpIaSBWaXR0b3JpbywNCg0KVGhlIHRl eHQgeW91IHF1b3RlZCBpcyBjb3BpZWQgZm9ybSB0aGUgYWJzdHJhY3Qgb2YgdGhlIGRyYWZ0IGl0 c2VsZi4NCg0KDQpBdXRob3JzLA0KDQpTaG91bGQgdGhlIGRyYWZ0IGJlIHVwZGF0ZWQgdG8gY292 ZXIgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBjYXNlPw0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoN Ck9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDg6MTkgQU0gVml0dG9yaW8gQmVydG9jY2kgPFZpdHRv cmlvQGF1dGgwLmNvbTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpIaSBSaWZh YXQsDQpvbmUgZGV0YWlsLiBUaGUgdGVjaCBzdW1tYXJ5IHNheXMNCg0KDQpBbiBleHRlbnNpb24g dG8gdGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayBkZWZpbmluZyByZXF1ZXN0 DQoNCnBhcmFtZXRlcnMgdGhhdCBlbmFibGUgYSBjbGllbnQgdG8gZXhwbGljaXRseSBzaWduYWwg dG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXINCg0KYWJvdXQgdGhlIGxvY2F0aW9uIG9mIHRoZSBw cm90ZWN0ZWQgcmVzb3VyY2UocykgdG8gd2hpY2ggaXQgaXMgcmVxdWVzdGluZw0KDQphY2Nlc3Mu DQpCdXQgYXQgbGVhc3QgaW4gdGhlIE1pY3Jvc29mdCBpbXBsZW1lbnRhdGlvbiwgdGhlIHJlc291 cmNlIGlkZW50aWZpZXIgZG9lc24ndCBoYXZlIHRvIGJlIGEgbmV0d29yayBhZGRyZXNzYWJsZSBV UkwgKGFuZCBpZiBpdCBpcywgaXQgZG9lc24ndCBzdHJpY3RseSBuZWVkIHRvIG1hdGNoIHRoZSBh Y3R1YWwgcmVzb3VyY2UgbG9jYXRpb24pLiBJdCBjYW4gYmUgYSBsb2dpY2FsIGlkZW50aWZpZXIs IHRobyB1c2luZyB0aGUgYWN0dWFsIHJlc291cmNlIGxvY2F0aW9uIHRoZXJlIGhhcyBiZW5lZml0 cyAoZG9tYWluIG93bmVyc2hpcCBjaGVjaywgcHJldmVudGlvbiBvZiB0b2tlbiBmb3J3YXJkaW5n IGV0YykuDQpTYW1lIGZvciBBdXRoMCwgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciBpcyBhIGxvZ2lj YWwgaWRlbnRpZmllciByYXRoZXIgdGhhbiBhIGxvY2F0aW9uLg0KDQoNCg0KT24gV2VkLCBKYW4g MTYsIDIwMTkgYXQgNjozMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWls LmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpBbGwsDQoNClRoZSBm b2xsb3dpbmcgaXMgdGhlIGZpcnN0IHNoZXBoZXJkIHdyaXRlLXVwIGZvciB0aGUgZHJhZnQtaWV0 Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxIGRvY3VtZW50Lg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzL3No ZXBoZXJkd3JpdGV1cC8NCg0KUGxlYXNlLCB0YWtlIGEgbG9vayBhbmQgbGV0IG1lIGtub3cgaWYg SSBtaXNzZWQgYW55dGhpbmcuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoN CkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZp bGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_BL0PR00MB0292F3C224D081198866F89CF59D0BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBhbHNvIGFn cmVlIHRoYXQg4oCccmVzb3VyY2XigJ0gc2hvdWxkIGJlIGEgc3BlY2lmaWMgbmV0d29yay1hZGRy ZXNzYWJsZSBVUkwgd2hlcmVhcyBhIHNlcGFyYXRlIGF1ZGllbmNlIHBhcmFtZXRlciAobGlrZSDi gJxhdWTigJ0gaW4gSldUcykgY2FuIHJlZmVyIHRvIG9uZSBvciBtb3JlIGxvZ2ljYWwgcmVzb3Vy Y2VzLiZuYnNwOyBUaGV5IGFyZSBkaWZmZXJlbnQsIGlmIHJlbGF0ZWQsDQogdGhpbmdzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Tm90ZSB0aGF0IHRoZSBBQ0UgV0cgaXMg cHJvcG9zaW5nIHRvIHJlZ2lzdGVyIGEgbG9naWNhbCBhdWRpZW5jZSBwYXJhbWV0ZXIg4oCccmVx X2F1ZOKAnSBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYWNlLW9hdXRoLXBhcmFtcy0wMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wMTwvYT4gLSBwYXJ0bHkgYmFzZWQgb24gZmVlZGJhY2sg ZnJvbSBPQXV0aCBXRyBtZW1iZXJzLiZuYnNwOyBUaGlzIGlzIGEgZ2VuZXJhbCBPQXV0aCBwYXJh bWV0ZXIsIHdoaWNoIGFueSBPQXV0aCBkZXBsb3ltZW50IHdpbGwgYmUgYWJsZQ0KIHRvIHVzZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgdGhlcmVmb3JlIGJlbGlldmUg dGhhdCBubyBjaGFuZ2VzIGFyZSBuZWVkZWQgdG8gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLCBhcyB0aGUgbG9naWNhbCBhdWRpZW5jZSB3b3JrIGlzIGFscmVhZHkgaGFwcGVu aW5nIGluIGFub3RoZXIgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpKb2huIEJyYWRsZXk8YnI+DQo8Yj5T ZW50OjwvYj4gU2F0dXJkYXksIEphbnVhcnkgMTksIDIwMTkgOTowMSBBTTxicj4NCjxiPlRvOjwv Yj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gVml0dG9yaW8gQmVydG9jY2kgJmx0O1ZpdHRvcmlvPTQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnJmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVwIGZvciBk cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDE8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIG5lZWQgdG8gZGVjaWRlIGlmIHdlIHdhbnQgdG8gbWFrZSBhIGNoYW5n ZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZvciBzZWN1cml0eSB3ZSBhcmUgbG9jYXRpb24gY2VudHJpYy4mbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcmVm ZXIgdG8ga2VlcCByZXNvdXJjZSBsb2NhdGlvbiBzZXBhcmF0ZSBmcm9tIGxvZ2ljYWwgYXVkaWVu Y2UgdGhhdCBjYW4gYmUgYSBzY29wZSBvciBvdGhlciBwYXJhbWV0ZXIuJm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGJl Y29tZXMgaGFyZGVyIGZvciBwZW9wbGUgdG8gdXNlIHRoZSBwYXJhbWV0ZXIgY29ycmVjdGx5IGlm IHdlIGFyZSB0b28gZmxleGlibGUuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcmF0aGVyIGhhdmUgYSBzZXBh cmF0ZSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciBpZiB3ZSB0aGluayB3ZSB3YW50IG9uZS4m bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Sm9obiBCLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEphbiAxOSwgMjAxOSwgMTE6NDEgQU0gQnJpYW4g Q2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBh cG9sb2d5IG5lZWRlZCwgUmlmYWF0LiBBbmQgSSBhcG9sb2dpemUgaWYgd2hhdCBJIHNhaWQgY2Ft ZSBvZmYgdGhlIHdyb25nIHdheS4gSSB3YXMganVzdCB0cnlpbmcgdG8gbWFrZSBsaWdodCBvZiB0 aGUgc2l0dWF0aW9uLiBBbmQgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgYmUgaGFtc3RydW5n IGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVyZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBzZW5zZSB0 byBiZQ0KIGZsZXhpYmxlIHdpdGggdGhpbmdzLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNjoyMiBQ TSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luOjAuLjhleCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29ycnkgQnJpYW4sIEkgd2FzIG5vdCBjbGVhciB3 aXRoIG15IHN0YXRlbWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgbWVhbnQgdG8gc2F5IHRoYXQgd2Ugc2hvdWxkIG5vdCBhbGxv dyB0aGUgcHJvY2VzcyB0byBwcmV2ZW50IHRoZSBXRyBmcm9tIHByb2R1Y2luZyBhIHF1YWxpdHkg ZG9jdW1lbnQgd2l0aG91dCBpc3N1ZXMsIGFzc3VtaW5nIHRoZXJlIGlzIGFuIGlzc3VlIGluIHRo ZSBmaXJzdCBwbGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklkZWFsbHkgd2Ugd2FudCB0byBnZXQgdGhlc2UgaWRlbnRpZmllZCBkdXJpbmcg dGhlIFdHTEMsIGJ1dCB0aGluZ3MgaGFwcGVuIGFuZCBzb21ldGltZXMgdGhlIFdHIG1pc3NlcyBz b21ldGhpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGVhciB5b3UgYW5kIGFncmVlIHRoYXQgdGhpcyBtYWtlIHRoaW5ncyBk aWZmaWN1bHQgZm9yIGF1dGhvcnMuIFdlIHdpbGwgbWFrZSBzdXJlIHRoYXQgdGhpcyBkb2VzIG5v dCBiZWNvbWUgdGhlIG5vcm0sIGFuZCB3ZSB3aWxsIHRyeSB0byBzdGljayB0byB0aGUgcHJvY2Vz cyBhcyBtdWNoIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgSmFuIDE4LCAyMDE5IGF0IDU6MzUgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBS aWZhYXQuIFByb2Nlc3MgaXMgYXMgcHJvY2VzcyBkb2VzLCByaWdodD8gSSBkbyBraW5kYSB3YW50 IHRvIGdydW1ibGUgYWJvdXQgV0dDTCBoYXZpbmcgcGFzc2VkIGFscmVhZHkgYnV0IHRoYXQncyBt b3N0bHkgYmVjYXVzZSByZXBseWluZyB0byB0aGVzZSBraW5kcyBvZiB0aHJlYWRzIGlzIGhhcmQg Zm9yIG1lIGFuZCBJJ2xsIGp1c3QgZ2V0IG92ZXIgaXQuLi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmYXIgYXMgSSB1bmRlcnN0YW5k IHRoaW5ncywgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGNvbWUgaW50byBwbGF5IHdoZW4gdGhlIGNs aWVudCBpcyBiZWluZyB0b2xkIHRoZSBieSB0aGUgcmVzb3VyY2UgaG93IHRvIGlkZW50aXR5IHRo ZSByZXNvdXJjZSBsaWtlIGlzIGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzdHJpYnV0ZWQtMDEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc3Ry aWJ1dGVkLTAxPC9hPiBhbmQgdXNpbmcgdGhlIGFjdHVhbCBsb2NhdGlvbiBpbiB0aGF0IGNvbnRl eHQgLGFsb25nIHdpdGggc29tZSBvdGhlciBjaGVja3MgcHJlc2NyaWJlZCBpbiB0aGF0IGRyYWZ0 LCBwcmV2ZW50cyB0aGUga2luZCBvZiBpc3N1ZXMgSm9obiBkZXNjcmliZWQgZWFybGllciBpbiB0 aGUgdGhyZWFkLg0KPGJyPg0KPGJyPg0KSW4gY2FzZXMgd2hlcmUgdGhlIGNsaWVudCBrbm93cyB0 aGUgcmVzb3VyY2UgYSBwcmlvcmkgb3Igb3V0LW9mLWJhbmQgb3IgY29uZmlndXJlZCBvciB3aGF0 ZXZlciwgSSBkb24ndCB0aGluayB0aGUgc2FtZSBzZWN1cml0eSBjb25jZXJucyBhcmlzZS4gQW5k IHVzaW5nIHN1Y2ggYSBrbm93biB2YWx1ZSwgYmUgaXQgYW4gYWN0dWFsIGxvY2F0aW9uIG9yIGxv Z2ljYWwgcmVwcmVzZW50YXRpb24sIHdvdWxkIGJlIG9rYXkuPGJyPg0KPGJyPg0KVGhlIHJlc291 cmNlLWluZGljYXRvcnMgZHJhZnQgaXMgYWRtaXR0ZWRseSBzb21ld2hhdCBsb2NhdGlvbi1jZW50 cmljIGluIGhvdyBpdCB0YWxrcyBhYm91dCB0aGUgdmFsdWUgb2YgdGhlICdyZXNvdXJjZScgcGFy YW1ldGVyLiBCdXQgdWx0aW1hdGVseSBpdCBkZWZpbmVzIGl0IGFzIGFuIGFic29sdXRlIFVSSSB0 aGF0IGluZGljYXRlcyB0aGUgbG9jYXRpb24gb2YgdGhlIHRhcmdldCBzZXJ2aWNlIG9yIHJlc291 cmNlIHdoZXJlIGFjY2VzcyBpcw0KIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2NhdGlvbiBjYW4gYmUg dmFyeWluZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1c2luZyBhIFVSSSBh cyAncmVzb3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2FsIGlkZW50aWZpZXIg dGhhdCBwb2ludHMgdG8gc29tZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0aGUgYm91bmRzIG9m IHRoZSBkcmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TbyBtYXliZSB0aGUgZHJhZnQgaXMgb2theSBhcyBpcz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IgcGVyaGFwcyB0aGF0 J3MgdG9vIG11Y2ggdG8gYmUgbGVmdCBhcyBhbiBleGVyY2lzZXIgdG8gdGhlIHJlYWRlcj8mbmJz cDsgQW5kIHNvbWUgdGV4dCBzaG91bGQgYmUgYWRkZWQgYW5kL29yIGFkanVzdGVkIHNvIHRoZSBy ZXNvdXJjZS1pbmRpY2F0b3JzIGRyYWZ0IHdvdWxkIGJlIGEgbGl0dGxlIG1vcmUgb3Blbi9jbGVh ciBhYm91dCB0aGUgcGFyYW1ldGVyIHZhbHVlIHBvdGVudGlhbGx5IGJlaW5nIG1vcmUgb2YgYQ0K IGxvZ2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0 d29yayBhZGRyZXNzYWJsZSBVUkw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxOjE4IFBNIFJp ZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd291bGRuJ3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQgdGhlIHByb2Nlc3MuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgbWFrZXMgc2Vuc2Ug dG8gdXBkYXRlIHRoZSBkb2N1bWVudCwgdGhlbiBmZWVsIGZyZWUgdG8gZG8gdGhhdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw O1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9obiBCcmFkbGV5ICZsdDs8 YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJA dmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgdGhlJm5ic3A7bG9n aWNhbCByZXNvdXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgJnF1b3Q7c2NvcGUmcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBpbXBs ZW1lbnRhdGlvbnMgbGlrZSBQaW5nIGFuZCBBdXRoMCBoYXZlIGJlZW4gYWRkaW5nIGFub3RoZXIg cGFyYW1ldGVyICZxdW90O2F1ZCZxdW90OyB0byBpZGVudGlmeSB0aGUgbG9naWNhbCByZXNvdXJj ZSBhbmQgdGhlbiB1c2luZyBzY29wZXMgdG8gZGVmaW5lIHBlcm1pc3Npb25zIHRvIHRoZSByZXNv dXJjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Rm9ydHVuYXRlbHksIHdlIGFyZSB1c2luZyBhIGRpZmZlcmVudCZuYnNwO3BhcmFtZXRlciBu YW1lIHNvIG5vdCBzdGVwcGluZyBvbiB0aGF0Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgY291bGQgZ28gYmFjayBhbmQgdHJ5IHRvIGFk ZCB0ZXh0IGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVuY2UsIGJ1dCB3ZSBhcmUgcXVpdGUgbGF0ZSBp biB0aGUgcHJvY2Vzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IGEgbG9naWNhbCByZXNvdXJjZSBwYXJhbWV0 ZXImbmJzcDttYXkgYmUgaGVscGZ1bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxkIGJlIGEgc2VwYXJh dGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDQ6MzggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9i bGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkRvZXNu4oCZdCB0aGUg4oCcc2NvcGXigJ0gcGFyYW1ldGVyIGFscmVhZHkgcHJvdmlkZSBhIG1l YW5zIG9mIHNwZWNpZnlpbmcgYSBsb2dpY2FsIGlkZW50aWZpZXI/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5B bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJl bnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89PGEg aHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Gcmlk YXksIEphbnVhcnkgMTgsIDIwMTkgYXQgNTo0NyBBTTxicj4NCjxiPlRvOiA8L2I+Sm9obiBCcmFk bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5r Ij52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9hdXRoIFdH ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0 aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFNo ZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMt MDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGFua3MgSm9obiBmb3IgdGhlIGJhY2tncm91bmQuDQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgdGhhdCBmcm9tIHRoZSBj bGllbnQgdmFsaWRhdGlvbiBQb1YsIGhhdmluZyBhbiBpZGVudGlmaWVyIGNvcnJlc3BvbmRpbmcg dG8gYSBsb2NhdGlvbiBtYWtlcyB0aGluZ3MgbW9yZSBzb2xpZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBzYWlkOiB0aGUgdXNlIG9m IGxvZ2ljYWwgaWRlbnRpZmllcnMgaXMgd2lkZXNwcmVhZCwgYXMgaXQgaGFzIHNpZ25pZmljYW50 IHByYWN0aWNhbCBhZHZhbnRhZ2VzICh0aGluayBvZiBzZXJ2aWNlcyB0aGF0IGFzc2lnbiBnZW5l cmF0ZWQgaG9zdGluZyBVUkxzIG9ubHkgYXQgZGVwbG95bWVudCB0aW1lLA0KIG9yIHNlcnZpY2Vz IHRoYXQgYXJlIHNvbWVob3cgZ3JvdXBlZCB1bmRlciB0aGUgc2FtZSBsb2dpY2FsIGF1ZGllbmNl IGFjcm9zcyByZWdpb25zL2Vudmlyb25tZW50L2RlcGxveW1lbnRzKS4gUGVvcGxlIHdvbid0IHN0 b3AgdXNpbmcgbG9naWNhbCBpZGVudGlmaWVycywgYmVjYXVzZSB0aGV5IG9mdGVuIGhhdmUgbm8g YWx0ZXJuYXRpdmUgKGdlbmVyYXRpbmcgbmV3IGF1ZGllbmNlcyBvbiB0aGUgZmx5IGF0IHRoZSBB UyBldmVyeSB0aW1lIHlvdQ0KIGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFzc2lnbmVkIGEgbmV3 IFVSTCBjYW4gYmUgdW5mZWFzaWJsZSkuIExlYXZpbmcgYSB3aWRlbHkgdXNlZCBhcHByb2FjaCBh cyBleGVyY2lzZSB0byB0aGUgcmVhZGVyIHNlZW1zIGEgZGlzc2VydmljZSB0byB0aGUgY29tbXVu aXR5LCBnaXZlbiB0aGF0IHRoaXMgbWlnaHQgbGVhZCB0byB2ZW5kb3JzIChmb3IgZXhhbXBsZSBN aWNyb3NvZnQgYW5kIEF1dGgwKSBrZWVwaW5nIHRoZWlyIG93biBwcm9wcmlldGFyeQ0KIHBhcmFt ZXRlcnMsIG9yIGRldmVsb3BlcnMgbWlzdXNpbmcgdGhlIG9uZXMgaW4gcGxhY2U7IHdvdWxkIG1h a2UgaXQgaGFyZCBmb3IgU0RLIGRldmVsb3BlcnMgdG8gcHJvdmlkZSBsaWJyYXJpZXMgdGhhdCB3 b3JrIG91dCBvZiB0aGUgYm94IHdpdGggZGlmZmVyZW50IEFTZXM7IGFuZCBzbyBvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V291bGQgaXQg YmUgZmVhc2libGUgdG8gYWRkIHN1Y2ggcGFyYW1ldGVyIGRpcmVjdGx5IGluIHRoaXMgc3BlYz8g VGhhdCB3b3VsZCBlbGltaW5hdGUgdGhlIGludGVyb3AgaXNzdWVzLCBhbmQgYWxzbyBnaXZlcyB1 cyBhIGNoYW5jZSB0byBmdWxseSB3YXJuIHBlb3BsZSBhYm91dCB0aGUgc2VjdXJpdHkgc2hvcnRj b21pbmdzDQogb2YgY2hvb3NpbmcgdGhhdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4g MTcsIDIwMTkgYXQgNDozMiBQTSBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdq dGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPldlIGhhdmUgZGlzY3Vz c2VkIHRoaXMuPG86cD48L286cD48L3A+DQo8cD5BdWRpZW5jZXMgY2FuIGNlcnRhaW5seSBiZSBs b2dpY2FsIGlkZW50aWZpZXJzLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMg aG93ZXZlciBpcyBhIG1vcmUgc3BlY2lmaWMgbG9jYXRpb24uJm5ic3A7IFRoZSBBUyBpcyBmcmVl IHRvIG1hcCB0aGUgbG9jYXRpb24gaW50byBzb21lIGFic3RyYWN0IGF1ZGllbmNlIGluIHRoZSBB VC48bzpwPjwvbzpwPjwvcD4NCjxwPkZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uY2Ug dGhlIGNsaWVudCBzdGFydHMgYXNraW5nIGZvciBsb2dpY2FsIHJlc291cmNlcyBpdCBjYW4gYmUg dHJpY2tlZCBpbnRvIGFza2luZyBmb3IgdGhlIHdyb25nIG9uZSBhcyBhIGJhZCByZXNvdXJjZSBj YW4gYWx3YXlzIGxpZSBhYm91dCB3aGF0IGxvZ2ljYWwgcmVzb3VyY2UgaXQgaXMuPG86cD48L286 cD48L3A+DQo8cD5JZiB3ZSB3ZXJlIHRvIGNoYW5nZSBpdCwgaG93IGEgY2xpZW50IHdvdWxkIHZh bGlkYXRlIGl0IGJlY29tZXMgY2hhbGxlbmdpbmcgdG8gaW1wb3NzaWJsZS4NCjxvOnA+PC9vOnA+ PC9wPg0KPHA+VGhlIEFTIGlzIGZyZWUgdG8gZG8gd2hhdGV2ZXIgbWFwcGluZyBvZiBsb2NhdGlv bnMgdG8gaWRlbnRpZmllcnMgaXQgbmVlZHMgZm9yIGFjY2VzcyB0b2tlbnMuPG86cD48L286cD48 L3A+DQo8cD5Tb21lIGltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byBrZWVwIGFkZGl0aW9uYWwg cGFyYW1ldGVycyBsaWtlIGxvZ2ljYWwgYXVkaWVuY2UsIGJ1dCB0aGF0IHNob3VsZCBiZSBzZXBh cmF0ZSBmcm9tIHJlc291cmNlLjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMS8xNy8yMDE5IDk6NTYgQU0s IFJpZmFhdCBTaGVraC1ZdXNlZiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBWaXR0b3JpbywNCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMg Y29waWVkIGZvcm0gdGhlIGFic3RyYWN0IG9mIHRoZSBkcmFmdCBpdHNlbGYuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+QXV0 aG9ycyw8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TaG91bGQgdGhlIGRyYWZ0IGJlIHVwZGF0ZWQgdG8gY292ZXIgdGhlIGxvZ2lj YWwgaWRlbnRpZmllciBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4g MTcsIDIwMTkgYXQgODoxOSBBTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlZpdHRvcmlvQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZpdHRvcmlvQGF1dGgwLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIFJpZmFhdCwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+b25lIGRldGFpbC4gVGhlIHRlY2ggc3VtbWFyeSBzYXlzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kLWF0dGFj aG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9u LXk6MCUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE RjUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1v bm8mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPkFuIGV4dGVuc2lvbiB0byB0aGUgT0F1dGggMi4w IEF1dGhvcml6YXRpb24gRnJhbWV3b3JrIGRlZmluaW5nIHJlcXVlc3QgPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDow JTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPnBhcmFt ZXRlcnMgdGhhdCBlbmFibGUgYSBjbGllbnQgdG8gZXhwbGljaXRseSBzaWduYWwgdG8gYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtiYWNrZ3JvdW5kLWF0dGFjaG1l bnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6 MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1v bm8mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPmFib3V0IHRoZSA8Yj5sb2NhdGlvbjwvYj4gb2Yg dGhlIHByb3RlY3RlZCByZXNvdXJjZShzKSB0byB3aGljaCBpdCBpcyByZXF1ZXN0aW5nIDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBv c2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7LHNlcmlmO2NvbG9yOmJs YWNrIj5hY2Nlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IGF0IGxlYXN0IGluIHRoZSBNaWNyb3NvZnQg aW1wbGVtZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIGRvZXNuJ3QNCjxpPmhhdmU8 L2k+IHRvIGJlIGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkwgKGFuZCBpZiBpdCBpcywgaXQgZG9l c24ndCBzdHJpY3RseSBuZWVkIHRvIG1hdGNoIHRoZSBhY3R1YWwgcmVzb3VyY2UgbG9jYXRpb24p LiBJdCBjYW4gYmUgYSBsb2dpY2FsIGlkZW50aWZpZXIsIHRobyB1c2luZyB0aGUgYWN0dWFsIHJl c291cmNlIGxvY2F0aW9uIHRoZXJlIGhhcyBiZW5lZml0cyAoZG9tYWluIG93bmVyc2hpcCBjaGVj aywgcHJldmVudGlvbiBvZiB0b2tlbg0KIGZvcndhcmRpbmcgZXRjKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2FtZSBmb3IgQXV0aDAsIHRo ZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIgcmF0aGVyIHRoYW4g YSBsb2NhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKYW4gMTYsIDIwMTkgYXQgNjozMiBQTSBSaWZh YXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkFsbCwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBmb2xsb3dpbmcgaXMgdGhlIGZpcnN0IHNoZXBoZXJkIHdyaXRlLXVwIGZv ciB0aGUmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEgZG9jdW1l bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzL3NoZXBoZXJkd3JpdGV1cC88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UsIHRha2UgYSBsb29rIGFu ZCBsZXQmbmJzcDttZSBrbm93IGlmIEkgbWlzc2VkIGFueXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Umlm YWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJz cDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh bmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNlLCBk aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR00MB0292F3C224D081198866F89CF59D0BL0PR00MB0292namp_-- From nobody Sat Jan 19 12:38:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEA0130E90 for ; Sat, 19 Jan 2019 12:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqaVoEz3PXcK for ; Sat, 19 Jan 2019 12:38:50 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 728FC130E95 for ; Sat, 19 Jan 2019 12:38:50 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0JKclqO050567; Sat, 19 Jan 2019 20:38:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=KzgF+aRRK3B0yJBq8D4KGxk4B6KwVKYnQ/m+Z7l1AZ8=; b=0yrIabmSBjveW7zMXmreedqeFcOHl/yWQPk3NKwxw0gP6s/qDIaAdrStWxCqNT+7mSAq RlyY8eQyQ2+bJ0VZ0dqQ27OeBDJkQLdV08Z8tt4170UJxEfRzgu6ofQd5EdpvLs62CuQ faXDX30ah+AV1hRCvHvbcPq0se3zZlXCIZzufma5NbsbQGsDr5xeF/xPx+oizKqTu+f0 No9TBzM+cT0QL9z6KqQOodkUdXodjSMahBqlX8DrJRTai1BKbzL3OBH8TLvFsj+2OzR2 6C4jomRhrIOJ6PgyZDXWOc2kpX16Q67jOD5tlrHCoDT0mWxQ0TVH6YQiWUMcX8Ykm9Yr hg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2q3sde2338-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 19 Jan 2019 20:38:47 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0JKckxr016704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 19 Jan 2019 20:38:46 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0JKcjTM013986; Sat, 19 Jan 2019 20:38:45 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 19 Jan 2019 12:38:45 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-18E0DF63-19C1-484C-8BCB-E1530CD3A08F Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Sat, 19 Jan 2019 12:38:43 -0800 Cc: John Bradley , Brian Campbell , Vittorio Bertocci , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> References: To: Mike Jones X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9141 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901190167 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 20:38:54 -0000 --Apple-Mail-18E0DF63-19C1-484C-8BCB-E1530CD3A08F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to Mike and John=E2=80=99s comments.=20 Phil > On Jan 19, 2019, at 12:34 PM, Mike Jones wrote: >=20 > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-= addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80= =9D in JWTs) can refer to one or more logical resources. They are different= , if related, things. > =20 > Note that the ACE WG is proposing to register a logical audience parameter= =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oau= th-params-01 - partly based on feedback from OAuth WG members. This is a ge= neral OAuth parameter, which any OAuth deployment will be able to use. > =20 > I therefore believe that no changes are needed to draft-ietf-oauth-resourc= e-indicators, as the logical audience work is already happening in another d= raft. > =20 > -- Mike > =20 > From: OAuth On Behalf Of John Bradley > Sent: Saturday, January 19, 2019 9:01 AM > To: Brian Campbell > Cc: Vittorio Bertocci ; IETF oauth W= G > Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-in= dicators-01 > =20 > We need to decide if we want to make a change. =20 > =20 > For security we are location centric. =20 > =20 > I prefer to keep resource location separate from logical audience that can= be a scope or other parameter. =20 > =20 > If becomes harder for people to use the parameter correctly if we are too f= lexible. =20 > =20 > I would rather have a separate logical audience parameter if we think we w= ant one. =20 > =20 > John B.=20 > =20 > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell No apology needed, Rifaat. And I apologize if what I said came off the wro= ng way. I was just trying to make light of the situation. And I agree that w= e should not be hamstrung by the process and there are times when it makes s= ense to be flexible with things. > =20 > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef = wrote: > Sorry Brian, I was not clear with my statement. > I meant to say that we should not allow the process to prevent the WG from= producing a quality document without issues, assuming there is an issue in t= he first place. > Ideally we want to get these identified during the WGLC, but things happen= and sometimes the WG misses something.=20 > =20 > I hear you and agree that this make things difficult for authors. We will m= ake sure that this does not become the norm, and we will try to stick to the= process as much as possible. > =20 > Regards, > Rifaat > =20 > =20 > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell wrote: > Thanks Rifaat. Process is as process does, right? I do kinda want to grumb= le about WGCL having passed already but that's mostly because replying to th= ese kinds of threads is hard for me and I'll just get over it... > =20 > As far as I understand things, the security concerns come into play when t= he client is being told the by the resource how to identity the resource lik= e is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-0= 1 and using the actual location in that context ,along with some other check= s prescribed in that draft, prevents the kind of issues John described earli= er in the thread.=20 >=20 > In cases where the client knows the resource a priori or out-of-band or co= nfigured or whatever, I don't think the same security concerns arise. And us= ing such a known value, be it an actual location or logical representation, w= ould be okay. >=20 > The resource-indicators draft is admittedly somewhat location-centric in h= ow it talks about the value of the 'resource' parameter. But ultimately it d= efines it as an absolute URI that indicates the location of the target servi= ce or resource where access is being requested. A location can be varying sh= ades of abstract and I'd say that using a URI as 'resource' parameter value t= hat's a logical identifier that points to some resource is well within the b= ounds of the draft. > =20 > So maybe the draft is okay as is? > =20 > Or perhaps that's too much to be left as an exerciser to the reader? And s= ome text should be added and/or adjusted so the resource-indicators draft wo= uld be a little more open/clear about the parameter value potentially being m= ore of a logical or abstract identifier and not necessarily a network addres= sable URL? > =20 > =20 > =20 > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef = wrote: > I wouldn't worry too much about the process. > If it makes sense to update the document, then feel free to do that. > =20 > Regards, > Rifaat > =20 > =20 > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > Yes the logical resource can be provided by "scope" > =20 > Some implementations like Ping and Auth0 have been adding another paramete= r "aud" to identify the logical resource and then using scopes to define per= missions to the resource. > =20 > Fortunately, we are using a different parameter name so not stepping on th= at.. > =20 > We could go back and try to add text explaining the difference, but we are= quite late in the process.=20 > =20 > I agree that a logical resource parameter may be helpful, but perhaps it s= hould be a separate draft. > =20 > John B. > =20 > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle wrote: > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a me= ans of specifying a logical identifier? > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Vittorio Bertocci > Date: Friday, January 18, 2019 at 5:47 AM > To: John Bradley > Cc: IETF oauth WG > Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-in= dicators-01 > =20 > Thanks John for the background. > I agree that from the client validation PoV, having an identifier correspo= nding to a location makes things more solid. > That said: the use of logical identifiers is widespread, as it has signifi= cant practical advantages (think of services that assign generated hosting U= RLs only at deployment time, or services that are somehow grouped under the s= ame logical audience across regions/environment/deployments). People won't s= top using logical identifiers, because they often have no alternative (gener= ating new audiences on the fly at the AS every time you do a deployment and g= et assigned a new URL can be unfeasible). Leaving a widely used approach as e= xercise to the reader seems a disservice to the community, given that this m= ight lead to vendors (for example Microsoft and Auth0) keeping their own pro= prietary parameters, or developers misusing the ones in place; would make it= hard for SDK developers to provide libraries that work out of the box with d= ifferent ASes; and so on. > Would it be feasible to add such parameter directly in this spec? That wou= ld eliminate the interop issues, and also gives us a chance to fully warn pe= ople about the security shortcomings of choosing that approach. > =20 > =20 > =20 > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > We have discussed this. >=20 > Audiences can certainly be logical identifiers. =20 >=20 > This however is a more specific location. The AS is free to map the locat= ion into some abstract audience in the AT. >=20 > =46rom a security point of view once the client starts asking for logical r= esources it can be tricked into asking for the wrong one as a bad resource c= an always lie about what logical resource it is. >=20 > If we were to change it, how a client would validate it becomes challengin= g to impossible. >=20 > The AS is free to do whatever mapping of locations to identifiers it needs= for access tokens. >=20 > Some implementations may want to keep additional parameters like logical a= udience, but that should be separate from resource. >=20 > John B. >=20 > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > Hi Vittorio, > =20 > The text you quoted is copied form the abstract of the draft itself. > =20 > =20 > Authors, > =20 > Should the draft be updated to cover the logical identifier case? > =20 > Regards, > Rifaat > =20 > =20 > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci wro= te: > Hi Rifaat, > one detail. The tech summary says > =20 > An extension to the OAuth 2.0 Authorization Framework defining request=20 > parameters that enable a client to explicitly signal to an authorization s= erver=20 > about the location of the protected resource(s) to which it is requesting=20= > access. > But at least in the Microsoft implementation, the resource identifier does= n't have to be a network addressable URL (and if it is, it doesn't strictly n= eed to match the actual resource location). It can be a logical identifier, t= ho using the actual resource location there has benefits (domain ownership c= heck, prevention of token forwarding etc). > Same for Auth0, the audience parameter is a logical identifier rather than= a location. > =20 > =20 > =20 > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef = wrote: > All, > =20 > The following is the first shepherd write-up for the draft-ietf-oauth-reso= urce-indicators-01 document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shep= herdwriteup/ > =20 > Please, take a look and let me know if I missed anything. > =20 > Regards, > Rifaat > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf..org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing 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= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-18E0DF63-19C1-484C-8BCB-E1530CD3A08F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to Mike and John=E2=80=99s comments.&nbs= p;

Phil

I also agree that =E2=80= =9Cresource=E2=80=9D should be a specific network-addressable URL whereas a s= eparate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) can refer to= one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is= proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D= in https= ://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on f= eedback from OAuth WG members.  This is a general OAuth parameter, whic= h any OAuth deployment will be able to use.

 

I therefore believe tha= t no changes are needed to draft-ietf-oauth-resource-indicators, as the logi= cal audience work is already happening in another draft.

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <= bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG &= lt;oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resour= ce-indicators-01

 

We need to decide if we want to make a change. &= nbsp;

 

For security we are location centric.  

 

I prefer to keep resource location separate from logi= cal audience that can be a scope or other parameter.  <= /p>

 

If becomes harder for people to use the parameter cor= rectly if we are too flexible.  

 

I would rather have a separate logical audience param= eter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wro= te:

No apology needed, Rifaat. And I apologize if what I s= aid came off the wrong way. I was just trying to make light of the situation= . And I agree that we should not be hamstrung by the process and there are t= imes when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &l= t;rifaat.ietf@gma= il.com> wrote:

Sorry Brian, I was not clear with my statement.<= /o:p>

I meant to say that we should not allow the process t= o prevent the WG from producing a quality document without issues, assuming t= here is an issue in the first place.

Ideally we want to get these identified during the WG= LC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult f= or authors. We will make sure that this does not become the norm, and we wil= l try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@ping= identity.com> wrote:

Thanks Rifaat. Process is as process does, right? I d= o kinda want to grumble about WGCL having passed already but that's mostly b= ecause replying to these kinds of threads is hard for me and I'll just get o= ver it...

 

As far as I understand things, the security concerns c= ome into play when the client is being told the by the resource how to ident= ity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using th= e actual location in that context ,along with some other checks prescribed i= n that draft, prevents the kind of issues John described earlier in the thre= ad.

In cases where the client knows the resource a priori or out-of-band or conf= igured or whatever, I don't think the same security concerns arise. And usin= g such a known value, be it an actual location or logical representation, wo= uld be okay.

The resource-indicators draft is admittedly somewhat location-centric in how= it talks about the value of the 'resource' parameter. But ultimately it def= ines it as an absolute URI that indicates the location of the target service= or resource where access is being requested. A location can be varying shades of abstract and I'd say t= hat using a URI as 'resource' parameter value that's a logical identifier th= at points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser= to the reader?  And some text should be added and/or adjusted so the r= esource-indicators draft would be a little more open/clear about the paramet= er value potentially being more of a logical or abstract identifier and not necessarily a network addressable UR= L?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &l= t;rifaat.ietf@gma= il.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel f= ree to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com>= wrote:

Yes the logical resource can be provided by "sco= pe"

 

Some implementations like Ping and Auth0 have been ad= ding another parameter "aud" to identify the logical resource and then using= scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter n= ame so not stepping on that..

 

We could go back and try to add text explaining the d= ifference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be= helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Anna= belle <richanna@= amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provid= e a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resour= ce-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier co= rresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has s= ignificant practical advantages (think of services that assign generated hos= ting URLs only at deployment time, or services that are somehow grouped under the same logical audience across= regions/environment/deployments). People won't stop using logical identifie= rs, because they often have no alternative (generating new audiences on the f= ly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a wi= dely used approach as exercise to the reader seems a disservice to the commu= nity, given that this might lead to vendors (for example Microsoft and Auth0= ) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard fo= r SDK developers to provide libraries that work out of the box with differen= t ASes; and so on.

Would it be feasible to add such parameter directly in this spec? Th= at would eliminate the interop issues, and also gives us a chance to fully w= arn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the= location into some abstract audience in the AT.

=46rom a security point of view once the client starts asking for logical= resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challengi= ng to impossible.

The AS is free to do whatever mapping of locations to identifiers it need= s for access tokens.

Some implementations may want to keep additional parameters like logical a= udience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.=

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:<= o:p>

Hi Rifaat,

one detail. The tech summary says

 

An extension to=
 the OAuth 2.0 Authorization Framework defining request 

parameters t=
hat enable a client to explicitly signal to an authorization server <=
o:p>


about the location of the protected resource(s) to which it is requesting =



access.

But at least in the Microsoft implementation, the resource identifie= r doesn't have to be a network addressable URL (and if it is, it doesn't strict= ly need to match the actual resource location). It can be a logical identifi= er, tho using the actual resource location there has benefits (domain owners= hip check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rathe= r than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> w= rote:

All,

 

The following is the first shepherd write-up for the draft-ietf= -oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.<= /o:p>

 

Regards,

 Rifaat

 

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

 

_______________________________________________
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

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

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


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


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

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-18E0DF63-19C1-484C-8BCB-E1530CD3A08F-- From nobody Sun Jan 20 15:59:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193EB131129 for ; Sun, 20 Jan 2019 15:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDFXn6BnFvXc for ; Sun, 20 Jan 2019 15:59:53 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C150913110E for ; Sun, 20 Jan 2019 15:59:52 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id v1-v6so16046005ljd.0 for ; Sun, 20 Jan 2019 15:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0LHPCeQOxtXoVjyesUqHGm4ulyZFbS7HgJ0R1pivIqQ=; b=hMYGHtxUgmOwXpsOoJ8RurTjhDTpX2SvJSvkhKZZgQ5zZECpYbYMcxMetyU/1ltPwt uxaGV0Br0ebHP14zjhMdlU0vbH8S4+7RnGqZ+WFbcxR3CFzbTPs6/McFtnHhzW8KgrU/ D5paiXZb8avuP6XtEv//Nz1FUx1lSDr6IwYt8Sw6G+KPjz+U/8kYIs4WaUXyESgyNTRH 6OIBH1FWP63GlLy/juc2I+uIpCXM8dqdkkwFr8zw+HkaMJQYikY6FmwP5vMsGq8b4x7T BwUwif9bjfuRL8lzIXeOla9QCuuKbRKis/8s3asesca8UUniW5eqH3pdsenJ5efgxlAD ql0w== 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=0LHPCeQOxtXoVjyesUqHGm4ulyZFbS7HgJ0R1pivIqQ=; b=Dts0RhLNv/SMBiTn3zcQ0eRNayYNix4FH0E9ikS1Sumv6Ek4M9nHdyrD7gsi4arbtj Q5yC4mpaQ1la9NRDquVDjn5KvDwhJ1CHrh9u5/HWsMSn96Cg3wM1cwWBYwabeab73y0p 0CDbMaWvQui09L0XTS1eOFzbDz3RPWLwGk5OQRs647c+e054RMEF9L8kNwxDmx0MKVWp 3LA1kAoDFKVItJoiWT1kSsGFCGmlFwMBH4GiDPFazrc/wKDEX24IPsKtiqmFj6YJgxKD 01Fh1/qLZPDCMU2d4drf0s32u/Wva2N1fJzUix04wR3zNj4gA1WScCnufSmqOMTcF3T8 YV2A== X-Gm-Message-State: AJcUukcv4W/+uhN1gRdL6ZW2+Dlw5+/jnX4WzQMBK69j6KzXZzjbFXBo 9WR+3vMluugSH4vGEMm9lr5+eOt0gRrD7PtQSIIxjQ== X-Google-Smtp-Source: ALg8bN54yAvaQIjhI9OY60BRjZnJcjfkF7veknHvr0NCp22yyhvMxYtP9aZx9I3Knsjn5Jq7klETIJG/KwhXJwTGCgM= X-Received: by 2002:a2e:a289:: with SMTP id k9-v6mr4234101lja.24.1548028790540; Sun, 20 Jan 2019 15:59:50 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> In-Reply-To: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> From: Vittorio Bertocci Date: Sun, 20 Jan 2019 15:59:39 -0800 Message-ID: To: Phil Hunt Cc: Brian Campbell , IETF oauth WG , John Bradley , Mike Jones Content-Type: multipart/alternative; boundary="00000000000029ac83057fec8ae8" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2019 23:59:57 -0000 --00000000000029ac83057fec8ae8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble= . Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere. That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the *concrete *security advantages don't apply to the their case, people will simply not comply. In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be. On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > +1 to Mike and John=E2=80=99s comments. > > Phil > > On Jan 19, 2019, at 12:34 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network= -addressable URL > whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs= ) can refer to one > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience paramete= r > =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-o= auth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > *Cc:* Vittorio Bertocci ; IETF oau= th > WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that ca= n > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > > > I would rather have a separate logical audience parameter if we think we > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > that.. > > > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000029ac83057fec8ae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
First of all, = it wasn't my intent to disrupt the established process. In my former po= sition I wasn't monitoring those discussions hence I didn't have a = chance to offer feedback. When I saw something that gave me the impression = might lead to issues, and given that I worked with actual deployments and d= evelopers using a similar parameter for a long time, I thought prudent to b= ring this up. I really appreciate Rifaat's stance on this. End of pream= ble.

Ultimately my goal is for developers to= have guidance on how to work with the concept of logical resource in a sta= ndard compliant way, hence it doesn't strictly matter whether the defin= ition of the corresponding parameter lives in=C2=A0oauth-resource-indicator= s or elsewhere.
That said. Reading through the draft, it would ap= pear that most of the reasons for which the spec was created apply to both = the network addressable and the logical resource types: knowing what keys t= o use to encrypt the token, constrain access tokens to the intended audienc= e, avoiding overloading scopes with resource indicating parts... those all = apply to network addressable and logic identifiers alike. And both paramete= rs are expected to result in audience restricted tokens. It seems the only = difference comes at token usage time, with the network addressable case giv= ing more guarantees that the token will go to its intended recipient, but t= he request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered= in the wild in the last 5 years of using the resource parameter in the MS = ecosystem, the resource identifier was known at design time: the developer = discovered it out of band and placed it in the app config at deployment tim= e. Those aren't fringe cases I occasionally encountered: the resource p= arameter in Azure AD v1 and ADFS was mandatory, hence literally every solut= ion i saw or touched used it. As Brian suggested, this is a scenario where = the security advantages of the network addressable case aren't as prono= unced as in the case in which the client discovers the resource identifier = at runtime. This isn't just because there is no specification suggestin= g location should be explicitly indicated, it's because there are many = practical advantages at development and deployment time to be able to use l= ogical identifiers- and if the concrete security advantages don'= t apply to the their case, people will simply not comply.=C2=A0
<= br>
In summary: creating two different parameters in two differen= t documents is better than ignoring he logical identifier case altogether, = however I think that not acknowledging the logical id case in=C2=A0oauth-re= source-indicators is going to create confusion and ultimately not be as use= ful to the developer community as it could be.


On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:
=
+1 to M= ike and John=E2=80=99s comments.=C2=A0

Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Mi= chael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if rela= ted, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general= OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there = are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

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

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll= just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the = parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable U= RL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>=
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An =
extension to the OAuth 2.0 Authorization Framework defining request =

par=
ameters that enable a client to explicitly signal to an authorization serve=
r 
abo=
ut the location of the protected resource(s) to which it is requesti=
ng 
acc=
ess.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


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

_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
--00000000000029ac83057fec8ae8-- From nobody Sun Jan 20 17:58:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92871130DD8 for ; Sun, 20 Jan 2019 17:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YJV28iaes5Rk for ; Sun, 20 Jan 2019 17:58:39 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C401294D0 for ; Sun, 20 Jan 2019 17:58:39 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id l12so21783168qtf.8 for ; Sun, 20 Jan 2019 17:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7TKTb6RrbG7H/PuSRCw4Gld7UDEgaj16alvmHjWGSP0=; b=TX7jr0amhyKPjm6uVdBCpNjZJZFK/yyakm+EDngSdKSke4S3363r0rPmLm/pi+VcZP HTfSetx2dcFEnnSI+FTzpXP0CICSTHzt/h7dVG1T6opyBP+usdLy0wF7xzQ1RRjdDcjx DvzmrAntGeXRc4Xl0x9qMGgOGrAEtkuer9aQ3teeexBRfMbmsSGjDThlnLJa6k7Jnkte Te5le+VRM66yalq8UXFmLX3STiArF/XoTSqDp4gexpLBhS/mndlHqdSEQddWC7WQCjB4 20iMGxDqZxK8eezhgiResR8T1oOBzWCiYEowiRD8uw26r+1dARuY+sGtQQbM5U2fCepv D3hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7TKTb6RrbG7H/PuSRCw4Gld7UDEgaj16alvmHjWGSP0=; b=HqgkUnDMHiM1bf6o+wuMbvzQrUmmXZqzi/Y6Wwc+9rP8uo2KGnnuRoU31s310aDkBT /BW0nGyKSEPrR01lFdgbxzMuaBQmgQN91LqmsYgn5kfMLjwhEVq3onIx4MgHCAHcjpKJ 1td3kBpC1NGufbeVfd17GnIldoqxUoswnX0lzHE+vEuX9wuOTsTuZ4l6HmATh5suQ3Xw R4pPVBbcNZNFvngsvEywUB1dl03Ax7XWS8dkWNJIgVPYWiL4hO6dshVTdFMRrwR02ZqY yIxBv2RYB6P7xgC2+PnOth5SjD1pM+eUHnNMyDh8rFmp1iU82JclubgVAda6jdKEc2Bf Bklg== X-Gm-Message-State: AJcUukc80L+ji+bTwIJZwrE8ys4MXiWq9UPJwsmfRtptDQgeReS3xU7q G2ubzZ3uF6GKHvPM//5dTrcSWg== X-Google-Smtp-Source: ALg8bN51FMFIFiLABuUhLiVl62ldlXhxd1Mm2l2ygOiX3eJR8ddNMVDBKggXHiScm60AHAxO1Rsefg== X-Received: by 2002:ac8:2502:: with SMTP id 2mr25198743qtm.53.1548035917623; Sun, 20 Jan 2019 17:58:37 -0800 (PST) Received: from [192.168.8.104] ([191.126.161.228]) by smtp.gmail.com with ESMTPSA id l195sm33468555qke.58.2019.01.20.17.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jan 2019 17:58:36 -0800 (PST) To: Vittorio Bertocci , Phil Hunt Cc: Brian Campbell , IETF oauth WG , Mike Jones References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> From: John Bradley Message-ID: <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> Date: Sun, 20 Jan 2019 17:58:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55B249F47A8718F562BC091A" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 01:58:44 -0000 This is a multi-part message in MIME format. --------------55B249F47A8718F562BC091A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit What is the parameter that Microsoft is using? On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > First of all, it wasn't my intent to disrupt the established process. > In my former position I wasn't monitoring those discussions hence I > didn't have a chance to offer feedback. When I saw something that gave > me the impression might lead to issues, and given that I worked with > actual deployments and developers using a similar parameter for a long > time, I thought prudent to bring this up. I really appreciate Rifaat's > stance on this. End of preamble. > > Ultimately my goal is for developers to have guidance on how to work > with the concept of logical resource in a standard compliant way, > hence it doesn't strictly matter whether the definition of the > corresponding parameter lives in oauth-resource-indicators or elsewhere. > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use > to encrypt the token, constrain access tokens to the intended > audience, avoiding overloading scopes with resource indicating > parts... those all apply to network addressable and logic identifiers > alike. And both parameters are expected to result in audience > restricted tokens. It seems the only difference comes at token usage > time, with the network addressable case giving more guarantees that > the token will go to its intended recipient, but the request and > audience restriction syntax seems to be exactly the same. > On top of this: in the 99.999% of the scenarios I encountered in the > wild in the last 5 years of using the resource parameter in the MS > ecosystem, the resource identifier was known at design time: the > developer discovered it out of band and placed it in the app config at > deployment time. Those aren't fringe cases I occasionally encountered: > the resource parameter in Azure AD v1 and ADFS was mandatory, hence > literally every solution i saw or touched used it. As Brian suggested, > this is a scenario where the security advantages of the network > addressable case aren't as pronounced as in the case in which the > client discovers the resource identifier at runtime. This isn't just > because there is no specification suggesting location should be > explicitly indicated, it's because there are many practical advantages > at development and deployment time to be able to use logical > identifiers- and if the /concrete /security advantages don't apply to > the their case, people will simply not comply. > > In summary: creating two different parameters in two different > documents is better than ignoring he logical identifier case > altogether, however I think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and > ultimately not be as useful to the developer community as it could be. > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt > wrote: > > +1 to Mike and John’s comments. > > Phil > > On Jan 19, 2019, at 12:34 PM, Mike Jones > > wrote: > >> I also agree that “resource” should be a specific >> network-addressable URL whereas a separate audience parameter >> (like “aud” in JWTs) can refer to one or more logical resources.  >> They are different, if related, things. >> >> Note that the ACE WG is proposing to register a logical audience >> parameter “req_aud” in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - >> partly based on feedback from OAuth WG members.  This is a >> general OAuth parameter, which any OAuth deployment will be able >> to use. >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience >> work is already happening in another draft. >> >> -- Mike >> >> *From:* OAuth > > *On Behalf Of * John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell > > >> *Cc:* Vittorio Bertocci > >; IETF oauth WG >> > >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> We need to decide if we want to make a change. >> >> For security we are location centric. >> >> I prefer to keep resource location separate from logical audience >> that can be a scope or other parameter. >> >> If becomes harder for people to use the parameter correctly if we >> are too flexible. >> >> I would rather have a separate logical audience parameter if we >> think we want one. >> >> John B. >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell >> >> wrote: >> >> No apology needed, Rifaat. And I apologize if what I said >> came off the wrong way. I was just trying to make light of >> the situation.. And I agree that we should not be hamstrung >> by the process and there are times when it makes sense to be >> flexible with things. >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> > wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to >> prevent the WG from producing a quality document without >> issues, assuming there is an issue in the first place. >> >> Ideally we want to get these identified during the WGLC, >> but things happen and sometimes the WG misses something. >> >> I hear you and agree that this make things difficult for >> authors. We will make sure that this does not become the >> norm, and we will try to stick to the process as much as >> possible. >> >> Regards, >> >>  Rifaat >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell >> > > wrote: >> >> Thanks Rifaat. Process is as process does, right? I >> do kinda want to grumble about WGCL having passed >> already but that's mostly because replying to these >> kinds of threads is hard for me and I'll just get >> over it... >> >> As far as I understand things, the security concerns >> come into play when the client is being told the by >> the resource how to identity the resource like is >> described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 >> and using the actual location in that context ,along >> with some other checks prescribed in that draft, >> prevents the kind of issues John described earlier in >> the thread. >> >> In cases where the client knows the resource a priori >> or out-of-band or configured or whatever, I don't >> think the same security concerns arise. And using >> such a known value, be it an actual location or >> logical representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat >> location-centric in how it talks about the value of >> the 'resource' parameter. But ultimately it defines >> it as an absolute URI that indicates the location of >> the target service or resource where access is being >> requested. A location can be varying shades of >> abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that >> points to some resource is well within the bounds of >> the draft. >> >> So maybe the draft is okay as is? >> >> Or perhaps that's too much to be left as an exerciser >> to the reader?  And some text should be added and/or >> adjusted so the resource-indicators draft would be a >> little more open/clear about the parameter value >> potentially being more of a logical or abstract >> identifier and not necessarily a network addressable URL? >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> > > wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then >> feel free to do that. >> >> Regards, >> >>  Rifaat >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley >> > wrote: >> >> Yes the logical resource can be provided by >> "scope" >> >> Some implementations like Ping and Auth0 have >> been adding another parameter "aud" to >> identify the logical resource and then using >> scopes to define permissions to the resource. >> >> Fortunately, we are using a >> different parameter name so not stepping on >> that.. >> >> We could go back and try to add text >> explaining the difference, but we are quite >> late in the process. >> >> I agree that a logical resource parameter may >> be helpful, but perhaps it should be a >> separate draft. >> >> John B. >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard >> Backman, Annabelle > > wrote: >> >> Doesn’t the “scope” parameter already >> provide a means of specifying a logical >> identifier? >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> *From: *OAuth > > on >> behalf of Vittorio Bertocci >> > > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley > > >> *Cc: *IETF oauth WG > > >> *Subject: *Re: [OAUTH-WG] Shepherd >> write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> Thanks John for the background. >> >> I agree that from the client validation >> PoV, having an identifier corresponding >> to a location makes things more solid. >> >> That said: the use of logical identifiers >> is widespread, as it has significant >> practical advantages (think of services >> that assign generated hosting URLs only >> at deployment time, or services that are >> somehow grouped under the same logical >> audience across >> regions/environment/deployments). People >> won't stop using logical identifiers, >> because they often have no alternative >> (generating new audiences on the fly at >> the AS every time you do a deployment and >> get assigned a new URL can be >> unfeasible). Leaving a widely used >> approach as exercise to the reader seems >> a disservice to the community, given that >> this might lead to vendors (for example >> Microsoft and Auth0) keeping their own >> proprietary parameters, or developers >> misusing the ones in place; would make it >> hard for SDK developers to provide >> libraries that work out of the box with >> different ASes; and so on. >> >> Would it be feasible to add such >> parameter directly in this spec? That >> would eliminate the interop issues, and >> also gives us a chance to fully warn >> people about the security shortcomings of >> choosing that approach. >> >> On Thu, Jan 17, 2019 at 4:32 PM John >> Bradley > > wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical >> identifiers. >> >> This however is a more specific >> location.  The AS is free to map the >> location into some abstract audience >> in the AT. >> >> From a security point of view once >> the client starts asking for logical >> resources it can be tricked into >> asking for the wrong one as a bad >> resource can always lie about what >> logical resource it is. >> >> If we were to change it, how a client >> would validate it becomes challenging >> to impossible. >> >> The AS is free to do whatever mapping >> of locations to identifiers it needs >> for access tokens. >> >> Some implementations may want to keep >> additional parameters like logical >> audience, but that should be separate >> from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat >> Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> The text you quoted is copied >> form the abstract of the draft >> itself. >> >> *Authors,* >> >> Should the draft be updated to >> cover the logical identifier case? >> >> Regards, >> >>  Rifaat >> >> On Thu, Jan 17, 2019 at 8:19 AM >> Vittorio Bertocci >> > > wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> An extension to the OAuth 2.0 >> Authorization Framework >> defining request >> >> parameters that enable a >> client to explicitly signal >> to an authorization server >> >> about the *location* of the >> protected resource(s) to >> which it is requesting >> >> access. >> >> But at least in the Microsoft >> implementation, the resource >> identifier doesn't /have/ to >> be a network addressable URL >> (and if it is, it doesn't >> strictly need to match the >> actual resource location). It >> can be a logical identifier, >> tho using the actual resource >> location there has benefits >> (domain ownership check, >> prevention of token >> forwarding etc). >> >> Same for Auth0, the audience >> parameter is a logical >> identifier rather than a >> location. >> >> On Wed, Jan 16, 2019 at 6:32 >> PM Rifaat Shekh-Yusef >> > > >> wrote: >> >> All, >> >> The following is the >> first shepherd write-up >> for >> the draft-ietf-oauth-resource-indicators-01 >> document. >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >> >> Please, take a look and >> let me know if I missed >> anything. >> >> Regards, >> >>  Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> */CONFIDENTIALITY NOTICE: This email may contain >> confidential and privileged material for the sole use >> of the intended recipient(s). Any review, use, >> distribution or disclosure by others is strictly >> prohibited.  If you have received this communication >> in error, please notify the sender immediately by >> e-mail and delete the message and any file >> attachments from your computer. Thank you./* >> >> >> */CONFIDENTIALITY NOTICE: This email may contain confidential >> and privileged material for the sole use of the intended >> recipient(s). Any review, use, distribution or disclosure by >> others is strictly prohibited..  If you have received this >> communication in error, please notify the sender immediately >> by e-mail and delete the message and any file attachments >> from your computer. Thank you./* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------55B249F47A8718F562BC091A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:
+1 to Mike and John’s comments. 

Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------55B249F47A8718F562BC091A-- From nobody Sun Jan 20 18:39:29 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6888F1294D0 for ; Sun, 20 Jan 2019 18:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd35nef3RLim for ; Sun, 20 Jan 2019 18:39:21 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAAB5127AC2 for ; Sun, 20 Jan 2019 18:39:20 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id t9-v6so16196036ljh.6 for ; Sun, 20 Jan 2019 18:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mj1hbAOL+AEQxSQfnTMdjWs97VOp9ibHgh81vpliZIQ=; b=OTFm4J818Ca7xRGxOOu94vEtxpSwkrsumTrUDCVyCQk7SfgYyzfh25Nd7dgtw1rj0U jKI+pKbwIAZ4Jt66Eq950N8XuWV1Z6VUX8tvlGncKLgBuXylSWVXKpWYQLmYePf3mvG+ xluJUiOZx53PCqw6TMa65gRtaEwTei0rZ7lGPRphT0MvX7Oa98YAHIhU8tXIqFB3cbF4 g8egoYbaNTB1GsWd3Fk13vU5IXFThV8S0HsOkgXBkXoBhJI5YlwYQDssKZRSfLab6Kr1 XiVclAJ69okR9RlFmEW3tChJdpDQq3MByf/MY1FCf0OLaxWaKS7Il000Moc7ajn2UdVK BIEw== 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=mj1hbAOL+AEQxSQfnTMdjWs97VOp9ibHgh81vpliZIQ=; b=gJ5zPg1731ZWmeLDuE7o2bvzJfpur4HGYLt4NwfGab7a/eIHzw+oFJVNH4R14UXns5 aox8dTsy05s+IZHTlS3DVQLLQbjOYDE/XqSobmXO1IrKsRefRhOx7wPvovsq+cdZvs6u pZhv0iPOYIqEP7M1A1PjDL5bwUueaiHDBwDqO/5fLufNfcWp0DddLz2TYFnfSEUGfeZE H/moN+jt5UhpEMZwvTud4y/pYPe1vv8h8A4joWWr/wcQHd9N4+TRLE2prE3IsJt5ekMB RmPECxadZtCvuu/C8SFZiwbQPU/lt6jmpDLhW2Pr3rubpeSA3z5zIPPwbeKUX+XyEBzv 9utw== X-Gm-Message-State: AJcUukfwyMem9vJ41WdmJdAZ702BU83iIxG89Rhv3DEVJWFJtsNtfkYX 6kNFkp4OlaqCRV5cYzzKv00Hg1pjyRnmUNotgttDhA== X-Google-Smtp-Source: ALg8bN5tcYCIxiw2A60B3EleqLEFOGp2mJm07aMkgaXVkyZD5BCf8mSE+VibQv2j2smU1qoxyQae97yZyGxtvUNR/sA= X-Received: by 2002:a2e:58b:: with SMTP id 133-v6mr18047410ljf.127.1548038358557; Sun, 20 Jan 2019 18:39:18 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> From: Vittorio Bertocci Date: Sun, 20 Jan 2019 18:39:06 -0800 Message-ID: To: John Bradley Cc: Brian Campbell , IETF oauth WG , Mike Jones , Phil Hunt Content-Type: multipart/alternative; boundary="00000000000075f9c4057feec4ee" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 02:39:26 -0000 --00000000000075f9c4057feec4ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [sent to John only by mistake, resending to the ML] In Azure AD v1 & ADFS, that's resource. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier. In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token. This is 9 months old info hence On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > What is the parameter that Microsoft is using? > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressab= le > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovere= d > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw = or > touched used it. As Brian suggested, this is a scenario where the securit= y > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. Th= is > isn't just because there is no specification suggesting location should b= e > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- an= d > if the *concrete *security advantages don't apply to the their case, > people will simply not comply. > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and ultimately > not be as useful to the developer community as it could be. > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > >> +1 to Mike and John=E2=80=99s comments. >> >> Phil >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific networ= k-addressable URL >> whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWT= s) can refer to one >> or more logical resources. They are different, if related, things. >> >> >> >> Note that the ACE WG is proposing to register a logical audience >> parameter =E2=80=9Creq_aud=E2=80=9D in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >> based on feedback from OAuth WG members. This is a general OAuth >> parameter, which any OAuth deployment will be able to use. >> >> >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience work is >> already happening in another draft. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> We need to decide if we want to make a change. >> >> >> >> For security we are location centric. >> >> >> >> I prefer to keep resource location separate from logical audience that >> can be a scope or other parameter. >> >> >> >> If becomes harder for people to use the parameter correctly if we are to= o >> flexible. >> >> >> >> I would rather have a separate logical audience parameter if we think we >> want one. >> >> >> >> John B. >> >> >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell > wrote: >> >> No apology needed, Rifaat. And I apologize if what I said came off the >> wrong way. I was just trying to make light of the situation.. And I agre= e >> that we should not be hamstrung by the process and there are times when = it >> makes sense to be flexible with things. >> >> >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> >> >> So maybe the draft is okay as is? >> >> >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then feel free to do that. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >> Yes the logical resource can be provided by "scope" >> >> >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> >> >> John B. >> >> >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --00000000000075f9c4057feec4ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[sent to John only by mistake, resending to= the ML]

In Azure AD v1 & A= DFS, that's=C2=A0resource. It could be used for both network and logical ids, with= the concrete usage in the wild I described earlier.
In Azure AD= v2, the resource as explicit parameter (network, logic or otherwise) is go= ne and is expressed as part of the scope string of all the scopes requested= for a given resource- but it still exist in practice tho as it still end u= p in the resulting=C2=A0aud=C2=A0of the issued token.
This is 9 months o= ld info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 P= M, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the O=
Auth 2.0 Authorization Framework defining request 
parameters that enabl=
e a client to explicitly signal to an authorization server 
about the location=
 of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

____________________________________= ___________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000075f9c4057feec4ee-- From nobody Mon Jan 21 07:32:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0189B130DC8 for ; Mon, 21 Jan 2019 07:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SnvpG8zIvg5x for ; Mon, 21 Jan 2019 07:32:08 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1DF5130DC0 for ; Mon, 21 Jan 2019 07:32:07 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id z7so16894534iti.0 for ; Mon, 21 Jan 2019 07:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vgycV3ByvW0N466l5wxWbqAGZg92pLifLW7wMrhUFT4=; b=kSoWdu30tojpi0TiMkBzf9Te0Vt8TE/PNy1UOxLb7Bc+J2wTb5ONQ4+84lcT65/62I NtyWnAa/CCMz830fZcOSphU/chZ7qPRKaLGJsbegZRonGCKHUbGzJWETK4HrauCjZvlM QmQqZoJo/rAVabNs0Q+duHeeMUZml0k4UtMXY= 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=vgycV3ByvW0N466l5wxWbqAGZg92pLifLW7wMrhUFT4=; b=ryxW5odZO4BRVDLKGCxedTF6ThaG6LRhoUWxU9hrS9c9634m3hSfeF9wsZdLb3Kc8k K/KvnokKT94WNp+VWDqJ81sGhVS41x40f8Z7rU5k60Ffm/NUP0/WHt+T/l7l73pJLvVw l4YVEfH4O6wL9wqy4yEwgYAdjzIv69JDERT25ieBDCtyvWIydxNwJTKP172VcxYvLQiF AJcmDd+77iNa9JCiqk73Ou/Z8z7Pf9OUyAOruKNTdMknEOfFgpfq+2HmIu2QPdl4a3v9 Gj5NdhrKk3jSGpEhAwziz357ieEOQlS2AyQTKoa46LchVY7zv9QwnsVkP+O7kffDvWol 8w7Q== X-Gm-Message-State: AJcUukcGMhvUA3gHicI1BUJC3vz8PVq5cSQ91r6DZ1UOMK/IHuMT93al aLTOgdXirU9EvHn1bxjo1nGcxX4ak03eS97uMPg7drYQYtoqdRhZDmhZam6MVt56vRhU0/6Xygy kk0j4O6/kcVn9QGFQ X-Google-Smtp-Source: ALg8bN6CqP1fGboM3YBseslD9bzuOtMaewVnXQIa3NGgZ4Vizb9mbUtJuNbEInHyI3Blv2DnzYK+aztPcJ5WEXstzyI= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr16943630itl.124.1548084726857; Mon, 21 Jan 2019 07:32:06 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: From: Brian Campbell Date: Mon, 21 Jan 2019 08:31:39 -0700 Message-ID: To: Vittorio Bertocci Cc: John Bradley , IETF oauth WG , Mike Jones , Phil Hunt Content-Type: multipart/alternative; boundary="0000000000003a26e6057ff9907b" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 15:32:12 -0000 --0000000000003a26e6057ff9907b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear. On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci wrote: > [sent to John only by mistake, resending to the ML] > > In Azure AD v1 & ADFS, that's resource. It could be used for both network > and logical ids, with the concrete usage in the wild I described earlier. > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > >> What is the parameter that Microsoft is using? >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >>> +1 to Mike and John=E2=80=99s comments. >>> >>> Phil >>> >>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>> >>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific netwo= rk-addressable >>> URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D i= n JWTs) can refer to >>> one or more logical resources. They are different, if related, things. >>> >>> >>> >>> Note that the ACE WG is proposing to register a logical audience >>> parameter =E2=80=9Creq_aud=E2=80=9D in >>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>> based on feedback from OAuth WG members. This is a general OAuth >>> parameter, which any OAuth deployment will be able to use. >>> >>> >>> >>> I therefore believe that no changes are needed to >>> draft-ietf-oauth-resource-indicators, as the logical audience work is >>> already happening in another draft. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth *On Behalf Of * John Bradley >>> *Sent:* Saturday, January 19, 2019 9:01 AM >>> *To:* Brian Campbell >>> *Cc:* Vittorio Bertocci ; IETF >>> oauth WG >>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> >>> >>> We need to decide if we want to make a change. >>> >>> >>> >>> For security we are location centric. >>> >>> >>> >>> I prefer to keep resource location separate from logical audience that >>> can be a scope or other parameter. >>> >>> >>> >>> If becomes harder for people to use the parameter correctly if we are >>> too flexible. >>> >>> >>> >>> I would rather have a separate logical audience parameter if we think w= e >>> want one. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>> bcampbell@pingidentity.com wrote: >>> >>> No apology needed, Rifaat. And I apologize if what I said came off the >>> wrong way. I was just trying to make light of the situation.. And I agr= ee >>> that we should not be hamstrung by the process and there are times when= it >>> makes sense to be flexible with things. >>> >>> >>> >>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> Sorry Brian, I was not clear with my statement. >>> >>> I meant to say that we should not allow the process to prevent the WG >>> from producing a quality document without issues, assuming there is an >>> issue in the first place. >>> >>> Ideally we want to get these identified during the WGLC, but things >>> happen and sometimes the WG misses something. >>> >>> >>> >>> I hear you and agree that this make things difficult for authors. We >>> will make sure that this does not become the norm, and we will try to s= tick >>> to the process as much as possible. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>> grumble about WGCL having passed already but that's mostly because repl= ying >>> to these kinds of threads is hard for me and I'll just get over it... >>> >>> >>> >>> As far as I understand things, the security concerns come into play whe= n >>> the client is being told the by the resource how to identity the resour= ce >>> like is described in >>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >>> the actual location in that context ,along with some other checks >>> prescribed in that draft, prevents the kind of issues John described >>> earlier in the thread. >>> >>> In cases where the client knows the resource a priori or out-of-band or >>> configured or whatever, I don't think the same security concerns arise.= And >>> using such a known value, be it an actual location or logical >>> representation, would be okay. >>> >>> The resource-indicators draft is admittedly somewhat location-centric i= n >>> how it talks about the value of the 'resource' parameter. But ultimatel= y it >>> defines it as an absolute URI that indicates the location of the target >>> service or resource where access is being requested. A location can be >>> varying shades of abstract and I'd say that using a URI as 'resource' >>> parameter value that's a logical identifier that points to some resourc= e is >>> well within the bounds of the draft. >>> >>> >>> >>> So maybe the draft is okay as is? >>> >>> >>> >>> Or perhaps that's too much to be left as an exerciser to the reader? >>> And some text should be added and/or adjusted so the resource-indicator= s >>> draft would be a little more open/clear about the parameter value >>> potentially being more of a logical or abstract identifier and not >>> necessarily a network addressable URL? >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> I wouldn't worry too much about the process. >>> >>> If it makes sense to update the document, then feel free to do that. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >>> >>> Yes the logical resource can be provided by "scope" >>> >>> >>> >>> Some implementations like Ping and Auth0 have been adding another >>> parameter "aud" to identify the logical resource and then using scopes = to >>> define permissions to the resource. >>> >>> >>> >>> Fortunately, we are using a different parameter name so not stepping on >>> that.. >>> >>> >>> >>> We could go back and try to add text explaining the difference, but we >>> are quite late in the process. >>> >>> >>> >>> I agree that a logical resource parameter may be helpful, but perhaps i= t >>> should be a separate draft. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a= means of specifying a >>> logical identifier? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of Vittorio Bertocci >>> > >>> *Date: *Friday, January 18, 2019 at 5:47 AM >>> *To: *John Bradley >>> *Cc: *IETF oauth WG >>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> >>> >>> Thanks John for the background. >>> >>> I agree that from the client validation PoV, having an identifier >>> corresponding to a location makes things more solid. >>> >>> That said: the use of logical identifiers is widespread, as it has >>> significant practical advantages (think of services that assign generat= ed >>> hosting URLs only at deployment time, or services that are somehow grou= ped >>> under the same logical audience across regions/environment/deployments)= . >>> People won't stop using logical identifiers, because they often have no >>> alternative (generating new audiences on the fly at the AS every time y= ou >>> do a deployment and get assigned a new URL can be unfeasible). Leaving = a >>> widely used approach as exercise to the reader seems a disservice to th= e >>> community, given that this might lead to vendors (for example Microsoft= and >>> Auth0) keeping their own proprietary parameters, or developers misusing= the >>> ones in place; would make it hard for SDK developers to provide librari= es >>> that work out of the box with different ASes; and so on. >>> >>> Would it be feasible to add such parameter directly in this spec? That >>> would eliminate the interop issues, and also gives us a chance to fully >>> warn people about the security shortcomings of choosing that approach. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >>> >>> We have discussed this. >>> >>> Audiences can certainly be logical identifiers. >>> >>> This however is a more specific location. The AS is free to map the >>> location into some abstract audience in the AT. >>> >>> From a security point of view once the client starts asking for logical >>> resources it can be tricked into asking for the wrong one as a bad reso= urce >>> can always lie about what logical resource it is. >>> >>> If we were to change it, how a client would validate it becomes >>> challenging to impossible. >>> >>> The AS is free to do whatever mapping of locations to identifiers it >>> needs for access tokens. >>> >>> Some implementations may want to keep additional parameters like logica= l >>> audience, but that should be separate from resource. >>> >>> John B. >>> >>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>> >>> Hi Vittorio, >>> >>> >>> >>> The text you quoted is copied form the abstract of the draft itself. >>> >>> >>> >>> >>> >>> *Authors,* >>> >>> >>> >>> Should the draft be updated to cover the logical identifier case? >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>> wrote: >>> >>> Hi Rifaat, >>> >>> one detail. The tech summary says >>> >>> >>> >>> An extension to the OAuth 2.0 Authorization Framework defining request >>> >>> parameters that enable a client to explicitly signal to an authorizatio= n server >>> >>> about the *location* of the protected resource(s) to which it is reques= ting >>> >>> access. >>> >>> But at least in the Microsoft implementation, the resource identifier >>> doesn't *have* to be a network addressable URL (and if it is, it >>> doesn't strictly need to match the actual resource location). It can be= a >>> logical identifier, tho using the actual resource location there has >>> benefits (domain ownership check, prevention of token forwarding etc). >>> >>> Same for Auth0, the audience parameter is a logical identifier rather >>> than a location. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> All, >>> >>> >>> >>> The following is the first shepherd write-up for >>> the draft-ietf-oauth-resource-indicators-01 document. >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/s= hepherdwriteup/ >>> >>> >>> >>> Please, take a look and let me know if I missed anything. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> --=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._ --0000000000003a26e6057ff9907b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I suggested before, I do think that's within the bo= unds of the draft's definition of 'resource' as a URI. And that= perhaps all that's needed is some minor adjustment and/or augmentation= of some text to make it more clear.

On Sun= , Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's=C2=A0= resource. It could= be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.
In Azure AD v2, the resource as explici= t parameter (network, logic or otherwise) is gone and is expressed as part = of the scope string of all the scopes requested for a given resource- but i= t still exist in practice tho as it still end up in the resulting=C2=A0aud=C2=A0of= the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 1= 7:58 John Bradley <ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request =

parameters that enable a client to explicitly signal to an authorizatio=
n server 
about the location of the protected resource(s) to which it is r=
equesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

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

<= 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. --0000000000003a26e6057ff9907b-- From nobody Mon Jan 21 07:53:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9148813107E for ; Mon, 21 Jan 2019 07:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 FGO_5mFmYpKH for ; Mon, 21 Jan 2019 07:53:02 -0800 (PST) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BE913107B for ; Mon, 21 Jan 2019 07:53:01 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id t200so11356636wmt.0 for ; Mon, 21 Jan 2019 07:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d+ZH9gRzASuVXz305xwdvEB631NBOeiN/SwNnHmnf5k=; b=1pmBKdL7k3M+lKsREYjX5UTRkOrT8Qk67r3PP1J/QAT2EMgoHR0veHotGO5cjsRjdg fLb70fMDOtuX1gKK7LlvRz3V1YYpn8/B63A/gpkYqEKjb1GXFWb0J+zJ6gwBOrcBz6Fi W8eC+5OBnoGPewIAzBdIjWdCQbl5qOA/exrsMaZskQCqlPjS9F1du2eR/zxTfC1WEVOl rxDKzhYDPEcIVmOQsGc6FNB16rctGH+zzXvMtUKnj4d+tHdjWza2BmoLfrRS49k7aaSw 7xh+4xb5NLfV37xfJhZSD3q2X0PtN5gsN1dVTKRJSAx/WFUJt74KtuAkLMH/fPCeXVGa J9ZA== 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=d+ZH9gRzASuVXz305xwdvEB631NBOeiN/SwNnHmnf5k=; b=rZn+hEyYFFvnJsZukHVOvzCgLPakSV2fyvaQaoJ74EGl7uhHdWSd6cAAlNw/tNjS5Y XpTmPypt4heJn0+52dy0uuMIHH5zPlgtefLpGczuA1mJubd3gBRcxr+RFbzaH9qUEPak fNHrSFBT8zRInrQqoWUzy+zM17R2NelVtl5+FlSZbQTAcT9ch5unajBlQ808WTdOa67G hqFO0+weu5vg9zlZ9vGtAH7oJ2J1GoXu3pqCUPmO69lrJ3aXCbDct/VsEIndDO7mnA8g AIpiC7zoOY7au8TARJYxYhiBTMuC9+/0PD+tIT6+SRyinHHt5kf9rRMH6gUawOWaY8vI 0vWg== X-Gm-Message-State: AJcUukeVjth91zA1DQHfGVv5bec5xcjBwCQv6S73zL1w0D916JwbPlAO g53X686H1oIwoftDjPS5cRHcTIJWhjWt0n5zz78OHQ== X-Google-Smtp-Source: ALg8bN7oqvDdP0FFX81rnhgjeDoTqdglB+wyfmOmoJnGnLBh5MJz5LkpcBqZxkBmeHr9C65dNlYwFxR8Oaf64cYqIhE= X-Received: by 2002:a1c:2501:: with SMTP id l1mr26383951wml.102.1548085979253; Mon, 21 Jan 2019 07:52:59 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: From: John Bradley Date: Mon, 21 Jan 2019 12:52:48 -0300 Message-ID: To: Vittorio Bertocci Cc: Brian Campbell , IETF oauth WG , Mike Jones , Phil Hunt Content-Type: multipart/alternative; boundary="000000000000e0258b057ff9dae8" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 15:53:08 -0000 --000000000000e0258b057ff9dae8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, This is the first mention that I have heard that resource was already in use by someone. On Sun, Jan 20, 2019 at 11:39 PM Vittorio Bertocci wrote: > [sent to John only by mistake, resending to the ML] > > In Azure AD v1 & ADFS, that's resource. It could be used for both network > and logical ids, with the concrete usage in the wild I described earlier. > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > >> What is the parameter that Microsoft is using? >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >>> +1 to Mike and John=E2=80=99s comments. >>> >>> Phil >>> >>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>> >>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific netwo= rk-addressable >>> URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D i= n JWTs) can refer to >>> one or more logical resources. They are different, if related, things. >>> >>> >>> >>> Note that the ACE WG is proposing to register a logical audience >>> parameter =E2=80=9Creq_aud=E2=80=9D in >>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>> based on feedback from OAuth WG members. This is a general OAuth >>> parameter, which any OAuth deployment will be able to use. >>> >>> >>> >>> I therefore believe that no changes are needed to >>> draft-ietf-oauth-resource-indicators, as the logical audience work is >>> already happening in another draft. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth *On Behalf Of * John Bradley >>> *Sent:* Saturday, January 19, 2019 9:01 AM >>> *To:* Brian Campbell >>> *Cc:* Vittorio Bertocci ; IETF >>> oauth WG >>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> >>> >>> We need to decide if we want to make a change. >>> >>> >>> >>> For security we are location centric. >>> >>> >>> >>> I prefer to keep resource location separate from logical audience that >>> can be a scope or other parameter. >>> >>> >>> >>> If becomes harder for people to use the parameter correctly if we are >>> too flexible. >>> >>> >>> >>> I would rather have a separate logical audience parameter if we think w= e >>> want one. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>> bcampbell@pingidentity.com wrote: >>> >>> No apology needed, Rifaat. And I apologize if what I said came off the >>> wrong way. I was just trying to make light of the situation.. And I agr= ee >>> that we should not be hamstrung by the process and there are times when= it >>> makes sense to be flexible with things. >>> >>> >>> >>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> Sorry Brian, I was not clear with my statement. >>> >>> I meant to say that we should not allow the process to prevent the WG >>> from producing a quality document without issues, assuming there is an >>> issue in the first place. >>> >>> Ideally we want to get these identified during the WGLC, but things >>> happen and sometimes the WG misses something. >>> >>> >>> >>> I hear you and agree that this make things difficult for authors. We >>> will make sure that this does not become the norm, and we will try to s= tick >>> to the process as much as possible. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>> grumble about WGCL having passed already but that's mostly because repl= ying >>> to these kinds of threads is hard for me and I'll just get over it... >>> >>> >>> >>> As far as I understand things, the security concerns come into play whe= n >>> the client is being told the by the resource how to identity the resour= ce >>> like is described in >>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >>> the actual location in that context ,along with some other checks >>> prescribed in that draft, prevents the kind of issues John described >>> earlier in the thread. >>> >>> In cases where the client knows the resource a priori or out-of-band or >>> configured or whatever, I don't think the same security concerns arise.= And >>> using such a known value, be it an actual location or logical >>> representation, would be okay. >>> >>> The resource-indicators draft is admittedly somewhat location-centric i= n >>> how it talks about the value of the 'resource' parameter. But ultimatel= y it >>> defines it as an absolute URI that indicates the location of the target >>> service or resource where access is being requested. A location can be >>> varying shades of abstract and I'd say that using a URI as 'resource' >>> parameter value that's a logical identifier that points to some resourc= e is >>> well within the bounds of the draft. >>> >>> >>> >>> So maybe the draft is okay as is? >>> >>> >>> >>> Or perhaps that's too much to be left as an exerciser to the reader? >>> And some text should be added and/or adjusted so the resource-indicator= s >>> draft would be a little more open/clear about the parameter value >>> potentially being more of a logical or abstract identifier and not >>> necessarily a network addressable URL? >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> I wouldn't worry too much about the process. >>> >>> If it makes sense to update the document, then feel free to do that. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >>> >>> Yes the logical resource can be provided by "scope" >>> >>> >>> >>> Some implementations like Ping and Auth0 have been adding another >>> parameter "aud" to identify the logical resource and then using scopes = to >>> define permissions to the resource. >>> >>> >>> >>> Fortunately, we are using a different parameter name so not stepping on >>> that.. >>> >>> >>> >>> We could go back and try to add text explaining the difference, but we >>> are quite late in the process. >>> >>> >>> >>> I agree that a logical resource parameter may be helpful, but perhaps i= t >>> should be a separate draft. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a= means of specifying a >>> logical identifier? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of Vittorio Bertocci >>> > >>> *Date: *Friday, January 18, 2019 at 5:47 AM >>> *To: *John Bradley >>> *Cc: *IETF oauth WG >>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> >>> >>> Thanks John for the background. >>> >>> I agree that from the client validation PoV, having an identifier >>> corresponding to a location makes things more solid. >>> >>> That said: the use of logical identifiers is widespread, as it has >>> significant practical advantages (think of services that assign generat= ed >>> hosting URLs only at deployment time, or services that are somehow grou= ped >>> under the same logical audience across regions/environment/deployments)= . >>> People won't stop using logical identifiers, because they often have no >>> alternative (generating new audiences on the fly at the AS every time y= ou >>> do a deployment and get assigned a new URL can be unfeasible). Leaving = a >>> widely used approach as exercise to the reader seems a disservice to th= e >>> community, given that this might lead to vendors (for example Microsoft= and >>> Auth0) keeping their own proprietary parameters, or developers misusing= the >>> ones in place; would make it hard for SDK developers to provide librari= es >>> that work out of the box with different ASes; and so on. >>> >>> Would it be feasible to add such parameter directly in this spec? That >>> would eliminate the interop issues, and also gives us a chance to fully >>> warn people about the security shortcomings of choosing that approach. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >>> >>> We have discussed this. >>> >>> Audiences can certainly be logical identifiers. >>> >>> This however is a more specific location. The AS is free to map the >>> location into some abstract audience in the AT. >>> >>> From a security point of view once the client starts asking for logical >>> resources it can be tricked into asking for the wrong one as a bad reso= urce >>> can always lie about what logical resource it is. >>> >>> If we were to change it, how a client would validate it becomes >>> challenging to impossible. >>> >>> The AS is free to do whatever mapping of locations to identifiers it >>> needs for access tokens. >>> >>> Some implementations may want to keep additional parameters like logica= l >>> audience, but that should be separate from resource. >>> >>> John B. >>> >>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>> >>> Hi Vittorio, >>> >>> >>> >>> The text you quoted is copied form the abstract of the draft itself. >>> >>> >>> >>> >>> >>> *Authors,* >>> >>> >>> >>> Should the draft be updated to cover the logical identifier case? >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>> wrote: >>> >>> Hi Rifaat, >>> >>> one detail. The tech summary says >>> >>> >>> >>> An extension to the OAuth 2.0 Authorization Framework defining request >>> >>> parameters that enable a client to explicitly signal to an authorizatio= n server >>> >>> about the *location* of the protected resource(s) to which it is reques= ting >>> >>> access. >>> >>> But at least in the Microsoft implementation, the resource identifier >>> doesn't *have* to be a network addressable URL (and if it is, it >>> doesn't strictly need to match the actual resource location). It can be= a >>> logical identifier, tho using the actual resource location there has >>> benefits (domain ownership check, prevention of token forwarding etc). >>> >>> Same for Auth0, the audience parameter is a logical identifier rather >>> than a location. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> All, >>> >>> >>> >>> The following is the first shepherd write-up for >>> the draft-ietf-oauth-resource-indicators-01 document. >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/s= hepherdwriteup/ >>> >>> >>> >>> Please, take a look and let me know if I missed anything. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> --000000000000e0258b057ff9dae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks,=C2=A0 =C2=A0This is the first mention that I have = heard that resource was already=C2=A0in use by someone.=C2=A0

On Sun, Jan 20= , 2019 at 11:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
[sent to John only by= mistake, resending to the ML]

= In Azure AD v1 & ADFS, that's=C2=A0re= source. It could be used for both network= and logical ids, with the concrete usage in the wild I described earlier.<= /span>
In Azure AD v2, the resource as explicit parameter (network, log= ic or otherwise) is gone and is expressed as part of the scope string of al= l the scopes requested for a given resource- but it still exist in practice= tho as it still end up in the resulting=C2=A0aud=C2=A0of the issued token.
<= div style=3D"font-size:1rem;color:rgb(49,49,49);word-spacing:1px" dir=3D"au= to">This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the O=
Auth 2.0 Authorization Framework defining request 
parameters that enabl=
e a client to explicitly signal to an authorization server 
about the location=
 of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

____________________________________= ___________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e0258b057ff9dae8-- From nobody Mon Jan 21 09:35:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835A0126C7E for ; Mon, 21 Jan 2019 09:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmwR8LAFpg6Q for ; Mon, 21 Jan 2019 09:35:06 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EDD12426E for ; Mon, 21 Jan 2019 09:35:06 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id h193so16280848ita.5 for ; Mon, 21 Jan 2019 09:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IECUVUs69Vca2g4BUaQmxcbzCpx9PkacBeCkuuP04Uw=; b=IbtkeaoGk94ipXmbTx+iGBLJwlWycPETx3eBml27FhLFY5w7YDX6qS1notDz0eyPmz Dg9yxSCDXKao3Z+G4vRbqiH2mEIY7LAhIQF/XdrNZHB7tmJS88XWhds/mfbUa7AVVD2e mvXYZQP/Fi2jZAsO9LBXjecz2unsRMs/FMuY0SXLeZ4NB4zbJuOFnLbQf6bDXQiebDPf 1bLx+RmLSqu4f47hLV3nyEgneBzISCf7BgRRt819g2Z1vWoEdCynIFAOn+aHlZQPAJd1 ol1sWfzF7DOIa0y/I/Sa+kSS4FSH8prudu9uyo3WpAF3Dpbg8yMcKxjccKCXwFmxqUR7 OL/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IECUVUs69Vca2g4BUaQmxcbzCpx9PkacBeCkuuP04Uw=; b=afMGHj1YqWV8k0PDYNhWVG3HC4jzUms5mcOh5lSmq0+QH6T9hY+CBitJNztpDdnjLI W8YcivDQVUz/ltathv/OflSnJ4rr1MApRs/k+68+x9UPVtUq9Q/V1Xzmkd28jEALNCXH m6WHVYCBLiJkktfNGRYsHDsjDhENEf36ikxaqHy7Dz38vHGnr8UeyEwOSuzCDz36/W+4 Dta+uI1QYerJkmZ/TF06MJuqjV27IlvY7kPugJln8mNLra1tKBEzrGDK4TRUzJALvJA8 SdGg1ayPK9s7Hf8qkJc0Bl6C3lNBm/tcy4Narucuy9fmtVIqFH7/fWj3nkM178/HWkuE NHFw== X-Gm-Message-State: AJcUukd612pqRXFEgN9zRdKZFc6cNM3zW14kHym+WJzoktILyVede+WA PKT7m27RXby68Q+K2eWwsSe1imyAu8YsB5M7jlnE5gZX X-Google-Smtp-Source: ALg8bN57spTepbVzsVcd+cIVe+smqHQanxctNEmbH4VEFJ7a0SbeOw2JU6uvKa/EElrBjJlLPtaz7oe4OAIiTB+0dTI= X-Received: by 2002:a24:cfc1:: with SMTP id y184mr213951itf.72.1548092105356; Mon, 21 Jan 2019 09:35:05 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 21 Jan 2019 12:34:54 -0500 Message-ID: To: Brian Campbell Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000004fa6a057ffb48a9" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 17:35:12 -0000 --00000000000004fa6a057ffb48a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, Vittorio, To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer? Regards, Rifaat On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell wrote: > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > >> [sent to John only by mistake, resending to the ML] >> >> In Azure AD v1 & ADFS, that's resource. It could be used for both >> network and logical ids, with the concrete usage in the wild I described >> earlier. >> In Azure AD v2, the resource as explicit parameter (network, logic or >> otherwise) is gone and is expressed as part of the scope string of all t= he >> scopes requested for a given resource- but it still exist in practice th= o >> as it still end up in the resulting aud of the issued token. >> This is 9 months old info hence >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >> >>> What is the parameter that Microsoft is using? >>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >>> >>> First of all, it wasn't my intent to disrupt the established process. I= n >>> my former position I wasn't monitoring those discussions hence I didn't >>> have a chance to offer feedback. When I saw something that gave me the >>> impression might lead to issues, and given that I worked with actual >>> deployments and developers using a similar parameter for a long time, I >>> thought prudent to bring this up. I really appreciate Rifaat's stance o= n >>> this. End of preamble. >>> >>> Ultimately my goal is for developers to have guidance on how to work >>> with the concept of logical resource in a standard compliant way, hence= it >>> doesn't strictly matter whether the definition of the corresponding >>> parameter lives in oauth-resource-indicators or elsewhere. >>> That said. Reading through the draft, it would appear that most of the >>> reasons for which the spec was created apply to both the network >>> addressable and the logical resource types: knowing what keys to use to >>> encrypt the token, constrain access tokens to the intended audience, >>> avoiding overloading scopes with resource indicating parts... those all >>> apply to network addressable and logic identifiers alike. And both >>> parameters are expected to result in audience restricted tokens. It see= ms >>> the only difference comes at token usage time, with the network address= able >>> case giving more guarantees that the token will go to its intended >>> recipient, but the request and audience restriction syntax seems to be >>> exactly the same. >>> On top of this: in the 99.999% of the scenarios I encountered in the >>> wild in the last 5 years of using the resource parameter in the MS >>> ecosystem, the resource identifier was known at design time: the develo= per >>> discovered it out of band and placed it in the app config at deployment >>> time. Those aren't fringe cases I occasionally encountered: the resourc= e >>> parameter in Azure AD v1 and ADFS was mandatory, hence literally every >>> solution i saw or touched used it. As Brian suggested, this is a scenar= io >>> where the security advantages of the network addressable case aren't as >>> pronounced as in the case in which the client discovers the resource >>> identifier at runtime. This isn't just because there is no specificatio= n >>> suggesting location should be explicitly indicated, it's because there = are >>> many practical advantages at development and deployment time to be able= to >>> use logical identifiers- and if the *concrete *security advantages >>> don't apply to the their case, people will simply not comply. >>> >>> In summary: creating two different parameters in two different document= s >>> is better than ignoring he logical identifier case altogether, however = I >>> think that not acknowledging the logical id case >>> in oauth-resource-indicators is going to create confusion and ultimatel= y >>> not be as useful to the developer community as it could be. >>> >>> >>> >>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >>> >>>> +1 to Mike and John=E2=80=99s comments. >>>> >>>> Phil >>>> >>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>>> >>>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific netw= ork-addressable >>>> URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D = in JWTs) can refer to >>>> one or more logical resources. They are different, if related, things= . >>>> >>>> >>>> >>>> Note that the ACE WG is proposing to register a logical audience >>>> parameter =E2=80=9Creq_aud=E2=80=9D in >>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>>> based on feedback from OAuth WG members. This is a general OAuth >>>> parameter, which any OAuth deployment will be able to use. >>>> >>>> >>>> >>>> I therefore believe that no changes are needed to >>>> draft-ietf-oauth-resource-indicators, as the logical audience work is >>>> already happening in another draft. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth *On Behalf Of * John Bradley >>>> *Sent:* Saturday, January 19, 2019 9:01 AM >>>> *To:* Brian Campbell >>>> *Cc:* Vittorio Bertocci ; IETF >>>> oauth WG >>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>>> draft-ietf-oauth-resource-indicators-01 >>>> >>>> >>>> >>>> We need to decide if we want to make a change. >>>> >>>> >>>> >>>> For security we are location centric. >>>> >>>> >>>> >>>> I prefer to keep resource location separate from logical audience that >>>> can be a scope or other parameter. >>>> >>>> >>>> >>>> If becomes harder for people to use the parameter correctly if we are >>>> too flexible. >>>> >>>> >>>> >>>> I would rather have a separate logical audience parameter if we think >>>> we want one. >>>> >>>> >>>> >>>> John B. >>>> >>>> >>>> >>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>>> bcampbell@pingidentity.com wrote: >>>> >>>> No apology needed, Rifaat. And I apologize if what I said came off the >>>> wrong way. I was just trying to make light of the situation.. And I ag= ree >>>> that we should not be hamstrung by the process and there are times whe= n it >>>> makes sense to be flexible with things. >>>> >>>> >>>> >>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>> Sorry Brian, I was not clear with my statement. >>>> >>>> I meant to say that we should not allow the process to prevent the WG >>>> from producing a quality document without issues, assuming there is an >>>> issue in the first place. >>>> >>>> Ideally we want to get these identified during the WGLC, but things >>>> happen and sometimes the WG misses something. >>>> >>>> >>>> >>>> I hear you and agree that this make things difficult for authors. We >>>> will make sure that this does not become the norm, and we will try to = stick >>>> to the process as much as possible. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>>> grumble about WGCL having passed already but that's mostly because rep= lying >>>> to these kinds of threads is hard for me and I'll just get over it... >>>> >>>> >>>> >>>> As far as I understand things, the security concerns come into play >>>> when the client is being told the by the resource how to identity the >>>> resource like is described in >>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >>>> the actual location in that context ,along with some other checks >>>> prescribed in that draft, prevents the kind of issues John described >>>> earlier in the thread. >>>> >>>> In cases where the client knows the resource a priori or out-of-band o= r >>>> configured or whatever, I don't think the same security concerns arise= . And >>>> using such a known value, be it an actual location or logical >>>> representation, would be okay. >>>> >>>> The resource-indicators draft is admittedly somewhat location-centric >>>> in how it talks about the value of the 'resource' parameter. But ultim= ately >>>> it defines it as an absolute URI that indicates the location of the ta= rget >>>> service or resource where access is being requested. A location can be >>>> varying shades of abstract and I'd say that using a URI as 'resource' >>>> parameter value that's a logical identifier that points to some resour= ce is >>>> well within the bounds of the draft. >>>> >>>> >>>> >>>> So maybe the draft is okay as is? >>>> >>>> >>>> >>>> Or perhaps that's too much to be left as an exerciser to the reader? >>>> And some text should be added and/or adjusted so the resource-indicato= rs >>>> draft would be a little more open/clear about the parameter value >>>> potentially being more of a logical or abstract identifier and not >>>> necessarily a network addressable URL? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>> I wouldn't worry too much about the process. >>>> >>>> If it makes sense to update the document, then feel free to do that. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote= : >>>> >>>> Yes the logical resource can be provided by "scope" >>>> >>>> >>>> >>>> Some implementations like Ping and Auth0 have been adding another >>>> parameter "aud" to identify the logical resource and then using scopes= to >>>> define permissions to the resource. >>>> >>>> >>>> >>>> Fortunately, we are using a different parameter name so not stepping o= n >>>> that.. >>>> >>>> >>>> >>>> We could go back and try to add text explaining the difference, but we >>>> are quite late in the process. >>>> >>>> >>>> >>>> I agree that a logical resource parameter may be helpful, but perhaps >>>> it should be a separate draft. >>>> >>>> >>>> >>>> John B. >>>> >>>> >>>> >>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>> richanna@amazon.com> wrote: >>>> >>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide = a means of specifying a >>>> logical identifier? >>>> >>>> >>>> >>>> -- >>>> >>>> Annabelle Richard Backman >>>> >>>> AWS Identity >>>> >>>> >>>> >>>> >>>> >>>> *From: *OAuth on behalf of Vittorio Bertocci >>>> > >>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>> *To: *John Bradley >>>> *Cc: *IETF oauth WG >>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>> draft-ietf-oauth-resource-indicators-01 >>>> >>>> >>>> >>>> Thanks John for the background. >>>> >>>> I agree that from the client validation PoV, having an identifier >>>> corresponding to a location makes things more solid. >>>> >>>> That said: the use of logical identifiers is widespread, as it has >>>> significant practical advantages (think of services that assign genera= ted >>>> hosting URLs only at deployment time, or services that are somehow gro= uped >>>> under the same logical audience across regions/environment/deployments= ). >>>> People won't stop using logical identifiers, because they often have n= o >>>> alternative (generating new audiences on the fly at the AS every time = you >>>> do a deployment and get assigned a new URL can be unfeasible). Leaving= a >>>> widely used approach as exercise to the reader seems a disservice to t= he >>>> community, given that this might lead to vendors (for example Microsof= t and >>>> Auth0) keeping their own proprietary parameters, or developers misusin= g the >>>> ones in place; would make it hard for SDK developers to provide librar= ies >>>> that work out of the box with different ASes; and so on. >>>> >>>> Would it be feasible to add such parameter directly in this spec? That >>>> would eliminate the interop issues, and also gives us a chance to full= y >>>> warn people about the security shortcomings of choosing that approach. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote= : >>>> >>>> We have discussed this. >>>> >>>> Audiences can certainly be logical identifiers. >>>> >>>> This however is a more specific location. The AS is free to map the >>>> location into some abstract audience in the AT. >>>> >>>> From a security point of view once the client starts asking for logica= l >>>> resources it can be tricked into asking for the wrong one as a bad res= ource >>>> can always lie about what logical resource it is. >>>> >>>> If we were to change it, how a client would validate it becomes >>>> challenging to impossible. >>>> >>>> The AS is free to do whatever mapping of locations to identifiers it >>>> needs for access tokens. >>>> >>>> Some implementations may want to keep additional parameters like >>>> logical audience, but that should be separate from resource. >>>> >>>> John B. >>>> >>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>> >>>> Hi Vittorio, >>>> >>>> >>>> >>>> The text you quoted is copied form the abstract of the draft itself. >>>> >>>> >>>> >>>> >>>> >>>> *Authors,* >>>> >>>> >>>> >>>> Should the draft be updated to cover the logical identifier case? >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>> wrote: >>>> >>>> Hi Rifaat, >>>> >>>> one detail. The tech summary says >>>> >>>> >>>> >>>> An extension to the OAuth 2.0 Authorization Framework defining request >>>> >>>> parameters that enable a client to explicitly signal to an authorizati= on server >>>> >>>> about the *location* of the protected resource(s) to which it is reque= sting >>>> >>>> access. >>>> >>>> But at least in the Microsoft implementation, the resource identifier >>>> doesn't *have* to be a network addressable URL (and if it is, it >>>> doesn't strictly need to match the actual resource location). It can b= e a >>>> logical identifier, tho using the actual resource location there has >>>> benefits (domain ownership check, prevention of token forwarding etc). >>>> >>>> Same for Auth0, the audience parameter is a logical identifier rather >>>> than a location. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>> rifaat.ietf@gmail.com> wrote: >>>> >>>> All, >>>> >>>> >>>> >>>> The following is the first shepherd write-up for >>>> the draft-ietf-oauth-resource-indicators-01 document. >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/= shepherdwriteup/ >>>> >>>> >>>> >>>> Please, take a look and let me know if I missed anything. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> >>>> https://www.ietf..org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000004fa6a057ffb48a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian, Vittorio,

To move this discussio= n forward, can you guys suggest some text to make the logical identifier us= age clearer?

Regards,
=C2=A0Rifaat
=


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbe= ll=3D40pingidentity.co= m@dmarc.ietf.org> wrote:
As I suggested before, I do think that'= ;s within the bounds of the draft's definition of 'resource' as= a URI. And that perhaps all that's needed is some minor adjustment and= /or augmentation of some text to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittor= io Bertocci <Vit= torio@auth0.com> wrote:
[sent to John only by mistak= e, resending to the ML]

In Azur= e AD v1 & ADFS, that's=C2=A0resource<= /font>. It could be used for both network and lo= gical ids, with the concrete usage in the wild I described earlier.<= div style=3D"font-size:1rem;color:rgb(49,49,49);word-spacing:1px" dir=3D"au= to">In Azure AD v2, the resource as explicit parameter (network, logic or o= therwise) is gone and is expressed as part of the scope string of all the s= copes requested for a given resource- but it still exist in practice tho as= it still end up in the resulting=C2=A0aud=C2=A0of the issued token.
Th= is is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> w= rote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019= 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request =

parameters that enable a client to explicitly signal to an authorizatio=
n server 
about the location of the protected resource(s) to which it is r=
equesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000004fa6a057ffb48a9-- From nobody Mon Jan 21 16:39:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8E130E09 for ; Mon, 21 Jan 2019 16:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pafJg6G6Ed5b for ; Mon, 21 Jan 2019 16:39:02 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8DF130DFA for ; Mon, 21 Jan 2019 16:39:01 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id c16so16775215lfj.8 for ; Mon, 21 Jan 2019 16:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yy9rgt9RAIFYn0a8fQhqkFIxTZmsTMDUfxusPbwz/VM=; b=S8zzJECP7dPKkiqhy5Bfh6eOLxg5BznRRfW7cg0r92ckRNFhg17QOHWQ7e830WFXlF t5GYSCOhwbdJrwW9AIwHKRWlimgZP/pUuG8amGCTSeVmX20U9EJBBfvVsFPfFggVAJO6 DdfZZELuPbXsJlxzlo9oXBJMZDZ166r7F59UGbydE2SrYfNya9Sl13V099Oll3gttI8D TE0RkrhKAgt4JmQxLbfjM9bo+j6LI87dIssFAwEQ4FnFa5Y95vi05NDva4Dfw78Z33J8 VgaNEJWedgb6oQM/wgMCHzKjkiGW4Lp79uMb9dqEBoJPVMVmdKhdXZPs+gSFPsDeCzcH xq6w== 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=yy9rgt9RAIFYn0a8fQhqkFIxTZmsTMDUfxusPbwz/VM=; b=bcPLRemcy8hmU5wjpPqaTNzwHkhzGu1Fa3ENjQZGg+YqVFIVWvwxNpVa+3MdGN3vPg t92DR657UPKcUFr5KxHysia3V2zsS2F16hzxFEco1r/Z+3qPEC420yA/ylBsqTC8q0nK PrRSQj+UVxyN5u2/g+hSdcrtu//upsAoCkjNz/GwZz1ytQSm1CXd51wHRg7KIyMsZPPT NObrZWz+cJ8FIe96kiHGeoVCttjh7CqLBPNhiWXOIV2++ZjPrsDv4jyweYeb33nPlJQH 6CSB0srHT5OnQbS9ok82HRrNqAQz1o9Igd+kGSgefTp61lUHV/scG+vL0IJ7NJV7Ei9X 3omg== X-Gm-Message-State: AJcUukfXOfEfp73OTjBlZypIYQDLuFPSOiwDkabfKJiKy4+ZwthuKRYY Nzh6NX3ng005T433azngfUsj1EzjgPkS3JCrY2W5wg== X-Google-Smtp-Source: ALg8bN45bRWri04InBZ061Ds1vo0HE7mS5vYQ9kpcft2XlKkQBouUxMN2bJYI0Qv2h8LgAdxFAUrqMjPV3tgurelnAk= X-Received: by 2002:a19:4dd0:: with SMTP id a199mr18603673lfb.42.1548117539271; Mon, 21 Jan 2019 16:38:59 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 21 Jan 2019 16:38:47 -0800 Message-ID: To: Rifaat Shekh-Yusef Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000fff42b0580013318" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 00:39:08 -0000 --000000000000fff42b0580013318 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rifaat, absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something. Cheers, V. On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef wrote: > Brian, Vittorio, > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > Regards, > Rifaat > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> As I suggested before, I do think that's within the bounds of the draft'= s >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> wrote: >> >>> [sent to John only by mistake, resending to the ML] >>> >>> In Azure AD v1 & ADFS, that's resource. It could be used for both >>> network and logical ids, with the concrete usage in the wild I describe= d >>> earlier. >>> In Azure AD v2, the resource as explicit parameter (network, logic or >>> otherwise) is gone and is expressed as part of the scope string of all = the >>> scopes requested for a given resource- but it still exist in practice t= ho >>> as it still end up in the resulting aud of the issued token. >>> This is 9 months old info hence >>> >>> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >>> >>>> What is the parameter that Microsoft is using? >>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >>>> >>>> First of all, it wasn't my intent to disrupt the established process. >>>> In my former position I wasn't monitoring those discussions hence I di= dn't >>>> have a chance to offer feedback. When I saw something that gave me the >>>> impression might lead to issues, and given that I worked with actual >>>> deployments and developers using a similar parameter for a long time, = I >>>> thought prudent to bring this up. I really appreciate Rifaat's stance = on >>>> this. End of preamble. >>>> >>>> Ultimately my goal is for developers to have guidance on how to work >>>> with the concept of logical resource in a standard compliant way, henc= e it >>>> doesn't strictly matter whether the definition of the corresponding >>>> parameter lives in oauth-resource-indicators or elsewhere. >>>> That said. Reading through the draft, it would appear that most of the >>>> reasons for which the spec was created apply to both the network >>>> addressable and the logical resource types: knowing what keys to use t= o >>>> encrypt the token, constrain access tokens to the intended audience, >>>> avoiding overloading scopes with resource indicating parts... those al= l >>>> apply to network addressable and logic identifiers alike. And both >>>> parameters are expected to result in audience restricted tokens. It se= ems >>>> the only difference comes at token usage time, with the network addres= sable >>>> case giving more guarantees that the token will go to its intended >>>> recipient, but the request and audience restriction syntax seems to be >>>> exactly the same. >>>> On top of this: in the 99.999% of the scenarios I encountered in the >>>> wild in the last 5 years of using the resource parameter in the MS >>>> ecosystem, the resource identifier was known at design time: the devel= oper >>>> discovered it out of band and placed it in the app config at deploymen= t >>>> time. Those aren't fringe cases I occasionally encountered: the resour= ce >>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally every >>>> solution i saw or touched used it. As Brian suggested, this is a scena= rio >>>> where the security advantages of the network addressable case aren't a= s >>>> pronounced as in the case in which the client discovers the resource >>>> identifier at runtime. This isn't just because there is no specificati= on >>>> suggesting location should be explicitly indicated, it's because there= are >>>> many practical advantages at development and deployment time to be abl= e to >>>> use logical identifiers- and if the *concrete *security advantages >>>> don't apply to the their case, people will simply not comply. >>>> >>>> In summary: creating two different parameters in two different >>>> documents is better than ignoring he logical identifier case altogethe= r, >>>> however I think that not acknowledging the logical id case >>>> in oauth-resource-indicators is going to create confusion and ultimate= ly >>>> not be as useful to the developer community as it could be. >>>> >>>> >>>> >>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >>>> >>>>> +1 to Mike and John=E2=80=99s comments. >>>>> >>>>> Phil >>>>> >>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>>>> >>>>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific net= work-addressable >>>>> URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D= in JWTs) can refer to >>>>> one or more logical resources. They are different, if related, thing= s. >>>>> >>>>> >>>>> >>>>> Note that the ACE WG is proposing to register a logical audience >>>>> parameter =E2=80=9Creq_aud=E2=80=9D in >>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>>>> based on feedback from OAuth WG members. This is a general OAuth >>>>> parameter, which any OAuth deployment will be able to use. >>>>> >>>>> >>>>> >>>>> I therefore believe that no changes are needed to >>>>> draft-ietf-oauth-resource-indicators, as the logical audience work is >>>>> already happening in another draft. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* OAuth *On Behalf Of * John Bradley >>>>> *Sent:* Saturday, January 19, 2019 9:01 AM >>>>> *To:* Brian Campbell >>>>> *Cc:* Vittorio Bertocci ; IETF >>>>> oauth WG >>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>>>> draft-ietf-oauth-resource-indicators-01 >>>>> >>>>> >>>>> >>>>> We need to decide if we want to make a change. >>>>> >>>>> >>>>> >>>>> For security we are location centric. >>>>> >>>>> >>>>> >>>>> I prefer to keep resource location separate from logical audience tha= t >>>>> can be a scope or other parameter. >>>>> >>>>> >>>>> >>>>> If becomes harder for people to use the parameter correctly if we are >>>>> too flexible. >>>>> >>>>> >>>>> >>>>> I would rather have a separate logical audience parameter if we think >>>>> we want one. >>>>> >>>>> >>>>> >>>>> John B. >>>>> >>>>> >>>>> >>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>>>> bcampbell@pingidentity.com wrote: >>>>> >>>>> No apology needed, Rifaat. And I apologize if what I said came off th= e >>>>> wrong way. I was just trying to make light of the situation.. And I a= gree >>>>> that we should not be hamstrung by the process and there are times wh= en it >>>>> makes sense to be flexible with things. >>>>> >>>>> >>>>> >>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>>>> rifaat.ietf@gmail.com> wrote: >>>>> >>>>> Sorry Brian, I was not clear with my statement. >>>>> >>>>> I meant to say that we should not allow the process to prevent the WG >>>>> from producing a quality document without issues, assuming there is a= n >>>>> issue in the first place. >>>>> >>>>> Ideally we want to get these identified during the WGLC, but things >>>>> happen and sometimes the WG misses something. >>>>> >>>>> >>>>> >>>>> I hear you and agree that this make things difficult for authors. We >>>>> will make sure that this does not become the norm, and we will try to= stick >>>>> to the process as much as possible. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>>>> grumble about WGCL having passed already but that's mostly because re= plying >>>>> to these kinds of threads is hard for me and I'll just get over it... >>>>> >>>>> >>>>> >>>>> As far as I understand things, the security concerns come into play >>>>> when the client is being told the by the resource how to identity the >>>>> resource like is described in >>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >>>>> the actual location in that context ,along with some other checks >>>>> prescribed in that draft, prevents the kind of issues John described >>>>> earlier in the thread. >>>>> >>>>> In cases where the client knows the resource a priori or out-of-band >>>>> or configured or whatever, I don't think the same security concerns a= rise. >>>>> And using such a known value, be it an actual location or logical >>>>> representation, would be okay. >>>>> >>>>> The resource-indicators draft is admittedly somewhat location-centric >>>>> in how it talks about the value of the 'resource' parameter. But ulti= mately >>>>> it defines it as an absolute URI that indicates the location of the t= arget >>>>> service or resource where access is being requested. A location can b= e >>>>> varying shades of abstract and I'd say that using a URI as 'resource' >>>>> parameter value that's a logical identifier that points to some resou= rce is >>>>> well within the bounds of the draft. >>>>> >>>>> >>>>> >>>>> So maybe the draft is okay as is? >>>>> >>>>> >>>>> >>>>> Or perhaps that's too much to be left as an exerciser to the reader? >>>>> And some text should be added and/or adjusted so the resource-indicat= ors >>>>> draft would be a little more open/clear about the parameter value >>>>> potentially being more of a logical or abstract identifier and not >>>>> necessarily a network addressable URL? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>>>> rifaat.ietf@gmail.com> wrote: >>>>> >>>>> I wouldn't worry too much about the process. >>>>> >>>>> If it makes sense to update the document, then feel free to do that. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley >>>>> wrote: >>>>> >>>>> Yes the logical resource can be provided by "scope" >>>>> >>>>> >>>>> >>>>> Some implementations like Ping and Auth0 have been adding another >>>>> parameter "aud" to identify the logical resource and then using scope= s to >>>>> define permissions to the resource. >>>>> >>>>> >>>>> >>>>> Fortunately, we are using a different parameter name so not stepping >>>>> on that.. >>>>> >>>>> >>>>> >>>>> We could go back and try to add text explaining the difference, but w= e >>>>> are quite late in the process. >>>>> >>>>> >>>>> >>>>> I agree that a logical resource parameter may be helpful, but perhaps >>>>> it should be a separate draft. >>>>> >>>>> >>>>> >>>>> John B. >>>>> >>>>> >>>>> >>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>>> richanna@amazon.com> wrote: >>>>> >>>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide= a means of specifying a >>>>> logical identifier? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *OAuth on behalf of Vittorio Bertocci >>>>> > >>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>> *To: *John Bradley >>>>> *Cc: *IETF oauth WG >>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>>> draft-ietf-oauth-resource-indicators-01 >>>>> >>>>> >>>>> >>>>> Thanks John for the background. >>>>> >>>>> I agree that from the client validation PoV, having an identifier >>>>> corresponding to a location makes things more solid. >>>>> >>>>> That said: the use of logical identifiers is widespread, as it has >>>>> significant practical advantages (think of services that assign gener= ated >>>>> hosting URLs only at deployment time, or services that are somehow gr= ouped >>>>> under the same logical audience across regions/environment/deployment= s). >>>>> People won't stop using logical identifiers, because they often have = no >>>>> alternative (generating new audiences on the fly at the AS every time= you >>>>> do a deployment and get assigned a new URL can be unfeasible). Leavin= g a >>>>> widely used approach as exercise to the reader seems a disservice to = the >>>>> community, given that this might lead to vendors (for example Microso= ft and >>>>> Auth0) keeping their own proprietary parameters, or developers misusi= ng the >>>>> ones in place; would make it hard for SDK developers to provide libra= ries >>>>> that work out of the box with different ASes; and so on. >>>>> >>>>> Would it be feasible to add such parameter directly in this spec? Tha= t >>>>> would eliminate the interop issues, and also gives us a chance to ful= ly >>>>> warn people about the security shortcomings of choosing that approach= . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley >>>>> wrote: >>>>> >>>>> We have discussed this. >>>>> >>>>> Audiences can certainly be logical identifiers. >>>>> >>>>> This however is a more specific location. The AS is free to map the >>>>> location into some abstract audience in the AT. >>>>> >>>>> From a security point of view once the client starts asking for >>>>> logical resources it can be tricked into asking for the wrong one as = a bad >>>>> resource can always lie about what logical resource it is. >>>>> >>>>> If we were to change it, how a client would validate it becomes >>>>> challenging to impossible. >>>>> >>>>> The AS is free to do whatever mapping of locations to identifiers it >>>>> needs for access tokens. >>>>> >>>>> Some implementations may want to keep additional parameters like >>>>> logical audience, but that should be separate from resource. >>>>> >>>>> John B. >>>>> >>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>>> >>>>> Hi Vittorio, >>>>> >>>>> >>>>> >>>>> The text you quoted is copied form the abstract of the draft itself. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Authors,* >>>>> >>>>> >>>>> >>>>> Should the draft be updated to cover the logical identifier case? >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>>> wrote: >>>>> >>>>> Hi Rifaat, >>>>> >>>>> one detail. The tech summary says >>>>> >>>>> >>>>> >>>>> An extension to the OAuth 2.0 Authorization Framework defining reques= t >>>>> >>>>> parameters that enable a client to explicitly signal to an authorizat= ion server >>>>> >>>>> about the *location* of the protected resource(s) to which it is requ= esting >>>>> >>>>> access. >>>>> >>>>> But at least in the Microsoft implementation, the resource identifier >>>>> doesn't *have* to be a network addressable URL (and if it is, it >>>>> doesn't strictly need to match the actual resource location). It can = be a >>>>> logical identifier, tho using the actual resource location there has >>>>> benefits (domain ownership check, prevention of token forwarding etc)= . >>>>> >>>>> Same for Auth0, the audience parameter is a logical identifier rather >>>>> than a location. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>>> rifaat.ietf@gmail.com> wrote: >>>>> >>>>> All, >>>>> >>>>> >>>>> >>>>> The following is the first shepherd write-up for >>>>> the draft-ietf-oauth-resource-indicators-01 document. >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators= /shepherdwriteup/ >>>>> >>>>> >>>>> >>>>> Please, take a look and let me know if I missed anything. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> >>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly prohibi= ted. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you.* >>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly prohibi= ted.. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you.* >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000fff42b0580013318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rifaat,
absolutely. Brian and myself already starte= d working on some language, however this week he is in vacation hence it mi= ght take few days before we come back to the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yus= ef <rifaat.ietf@gmail.com&g= t; wrote:
Brian, Vittorio,

To move this discussion forw= ard, can you guys suggest some text to make the logical identifier usage cl= earer?

Regards,
=C2=A0Rifaat
<= br>

On Mon, Jan 21, 2019 at 10:32 AM Brian= Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<= /div>
As = I suggested before, I do think that's within the bounds of the draft= 9;s definition of 'resource' as a URI. And that perhaps all that= 9;s needed is some minor adjustment and/or augmentation of some text to mak= e it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Berto= cci <Vittorio@au= th0.com> wrote:
[sent to John only by mistake, resen= ding to the ML]
In Azure AD v1 = & ADFS, that's=C2=A0resource. It could be used for both network and logical id= s, with the concrete usage in the wild I described earlier.
In A= zure AD v2, the resource as explicit parameter (network, logic or otherwise= ) is gone and is expressed as part of the scope string of all the scopes re= quested for a given resource- but it still exist in practice tho as it stil= l end up in the resulting=C2=A0aud=C2=A0of the issued token.
This is 9 m= onths old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request =

parameters that enable a client to explicitly signal to an authorizatio=
n server 
about the location of the protected resource(s) to which it is r=
equesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000fff42b0580013318-- From nobody Mon Jan 21 17:35:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110A8130E93 for ; Mon, 21 Jan 2019 17:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 eX57CGRI8cqo for ; Mon, 21 Jan 2019 17:35:51 -0800 (PST) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874A8130E90 for ; Mon, 21 Jan 2019 17:35:51 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id g76so19168475itg.2 for ; Mon, 21 Jan 2019 17:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0UTY5F6DUm+FrGEEjyYhfuJ3oM6S6Y/lnoH1S92g7OM=; b=oNb9aFtAekjWvHCbRSj1g+MzXBifihhz8HKjVx2P//Uw/qhs7aAlFRGtEPZd9Fanx2 e8fKOqdA76NDCZXxGOIguSRRB3COldPvpihiu1MLtZBTBFlrcyJ1Dypc972y3MqaL6gg EtkonUEk9Q0i1GNNmMWfeCvVSDBeFr5SIXNoomOiLWPYZODqzemPYczwwpkdE9VWmNWp 62E5AoGj3UX5/thFQG/Z4XlQ4qNna/o0aqdhBrQ1tj9lr+CihhWAMkdNavPdy+2k5iyV XQRfVwZeBthLbd1wqkvmlkLsPZAkmyQzQeM1WbgoKRKAY3yrxnNyfO9gnz66n3SulRlh tqSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0UTY5F6DUm+FrGEEjyYhfuJ3oM6S6Y/lnoH1S92g7OM=; b=SffK97nrNcq4tddo08lK1CiphkpWQkQw36EdPjzDkZ61xkj/Nmuv2Me3PexSx1gdNL pvF94EvhV0Rb8Q+MzJc2iX/VhV1H22xW261hAcpwywEe/0HZorbFYxv3T1Y/wGoEdgzG BpnUmpHpLYYOog/1G8G7k6ZbTaf9xkWWG7CVpe2Iq2/ZDv+8wo11vzDtw2UB5X9H7/EG +IHBx0zgAl8C9k86QFxKTqcvbkvXV9bicBeqCsVDbBK8FNgK5X4+fHl9T9CK+sUdVQvX wn3xLoAkbN3wvynPuyI+AeCDJSi4YGfJQ73Vwv2ynsF9ylL5FSar1qZ9+c3QdOsuj3Td uHlg== X-Gm-Message-State: AJcUukcNwPS0UktIz4nitycnHTPdEDZwk4PSLrf14j++tY8G9XGuqDQ1 ga8W9IzApChw6YlkBy5Npnn7exz2SuGhNb+vaz8= X-Google-Smtp-Source: ALg8bN5Yfy/VONiyy7mXo04QI6Y887MB6IkuvjTsuubrnAbojphcU5TRMGy027htnOH3RmQr4NrXjQQS7K5hkOthOAg= X-Received: by 2002:a02:b529:: with SMTP id l38mr17598974jaj.25.1548120950650; Mon, 21 Jan 2019 17:35:50 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a4f:1f43:0:0:0:0:0 with HTTP; Mon, 21 Jan 2019 17:35:49 -0800 (PST) In-Reply-To: References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> From: Rifaat Shekh-Yusef Date: Mon, 21 Jan 2019 20:35:49 -0500 Message-ID: To: Vittorio Bertocci Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000553a74058001ff06" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 01:35:56 -0000 --000000000000553a74058001ff06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you guys! On Monday, January 21, 2019, Vittorio Bertocci wrote: > Hi Rifaat, > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before w= e > come back to the list with something. > Cheers, > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > >> Brian, Vittorio, >> >> To move this discussion forward, can you guys suggest some text to make >> the logical identifier usage clearer? >> >> Regards, >> Rifaat >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> As I suggested before, I do think that's within the bounds of the >>> draft's definition of 'resource' as a URI. And that perhaps all that's >>> needed is some minor adjustment and/or augmentation of some text to mak= e it >>> more clear. >>> >>> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >>> wrote: >>> >>>> [sent to John only by mistake, resending to the ML] >>>> >>>> In Azure AD v1 & ADFS, that's resource. It could be used for both >>>> network and logical ids, with the concrete usage in the wild I describ= ed >>>> earlier. >>>> In Azure AD v2, the resource as explicit parameter (network, logic or >>>> otherwise) is gone and is expressed as part of the scope string of all= the >>>> scopes requested for a given resource- but it still exist in practice = tho >>>> as it still end up in the resulting aud of the issued token. >>>> This is 9 months old info hence >>>> >>>> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >>>> >>>>> What is the parameter that Microsoft is using? >>>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >>>>> >>>>> First of all, it wasn't my intent to disrupt the established process. >>>>> In my former position I wasn't monitoring those discussions hence I d= idn't >>>>> have a chance to offer feedback. When I saw something that gave me th= e >>>>> impression might lead to issues, and given that I worked with actual >>>>> deployments and developers using a similar parameter for a long time,= I >>>>> thought prudent to bring this up. I really appreciate Rifaat's stance= on >>>>> this. End of preamble. >>>>> >>>>> Ultimately my goal is for developers to have guidance on how to work >>>>> with the concept of logical resource in a standard compliant way, hen= ce it >>>>> doesn't strictly matter whether the definition of the corresponding >>>>> parameter lives in oauth-resource-indicators or elsewhere. >>>>> That said. Reading through the draft, it would appear that most of th= e >>>>> reasons for which the spec was created apply to both the network >>>>> addressable and the logical resource types: knowing what keys to use = to >>>>> encrypt the token, constrain access tokens to the intended audience, >>>>> avoiding overloading scopes with resource indicating parts... those a= ll >>>>> apply to network addressable and logic identifiers alike. And both >>>>> parameters are expected to result in audience restricted tokens. It s= eems >>>>> the only difference comes at token usage time, with the network addre= ssable >>>>> case giving more guarantees that the token will go to its intended >>>>> recipient, but the request and audience restriction syntax seems to b= e >>>>> exactly the same. >>>>> On top of this: in the 99.999% of the scenarios I encountered in the >>>>> wild in the last 5 years of using the resource parameter in the MS >>>>> ecosystem, the resource identifier was known at design time: the deve= loper >>>>> discovered it out of band and placed it in the app config at deployme= nt >>>>> time. Those aren't fringe cases I occasionally encountered: the resou= rce >>>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally ever= y >>>>> solution i saw or touched used it. As Brian suggested, this is a scen= ario >>>>> where the security advantages of the network addressable case aren't = as >>>>> pronounced as in the case in which the client discovers the resource >>>>> identifier at runtime. This isn't just because there is no specificat= ion >>>>> suggesting location should be explicitly indicated, it's because ther= e are >>>>> many practical advantages at development and deployment time to be ab= le to >>>>> use logical identifiers- and if the *concrete *security advantages >>>>> don't apply to the their case, people will simply not comply. >>>>> >>>>> In summary: creating two different parameters in two different >>>>> documents is better than ignoring he logical identifier case altogeth= er, >>>>> however I think that not acknowledging the logical id case >>>>> in oauth-resource-indicators is going to create confusion and ultimat= ely >>>>> not be as useful to the developer community as it could be. >>>>> >>>>> >>>>> >>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >>>>> >>>>>> +1 to Mike and John=E2=80=99s comments. >>>>>> >>>>>> Phil >>>>>> >>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones >>>>> com@dmarc.ietf.org> wrote: >>>>>> >>>>>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific ne= twork-addressable >>>>>> URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80= =9D in JWTs) can refer to >>>>>> one or more logical resources. They are different, if related, thin= gs. >>>>>> >>>>>> >>>>>> >>>>>> Note that the ACE WG is proposing to register a logical audience >>>>>> parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/ >>>>>> draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth >>>>>> WG members. This is a general OAuth parameter, which any OAuth depl= oyment >>>>>> will be able to use. >>>>>> >>>>>> >>>>>> >>>>>> I therefore believe that no changes are needed to >>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work >>>>>> is already happening in another draft. >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> *From:* OAuth *On Behalf Of * John Bradley >>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM >>>>>> *To:* Brian Campbell >>>>>> *Cc:* Vittorio Bertocci ; IET= F >>>>>> oauth WG >>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>>>>> draft-ietf-oauth-resource-indicators-01 >>>>>> >>>>>> >>>>>> >>>>>> We need to decide if we want to make a change. >>>>>> >>>>>> >>>>>> >>>>>> For security we are location centric. >>>>>> >>>>>> >>>>>> >>>>>> I prefer to keep resource location separate from logical audience >>>>>> that can be a scope or other parameter. >>>>>> >>>>>> >>>>>> >>>>>> If becomes harder for people to use the parameter correctly if we ar= e >>>>>> too flexible. >>>>>> >>>>>> >>>>>> >>>>>> I would rather have a separate logical audience parameter if we thin= k >>>>>> we want one. >>>>>> >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>>>>> bcampbell@pingidentity.com wrote: >>>>>> >>>>>> No apology needed, Rifaat. And I apologize if what I said came off >>>>>> the wrong way. I was just trying to make light of the situation.. An= d I >>>>>> agree that we should not be hamstrung by the process and there are t= imes >>>>>> when it makes sense to be flexible with things. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>>>>> rifaat.ietf@gmail.com> wrote: >>>>>> >>>>>> Sorry Brian, I was not clear with my statement. >>>>>> >>>>>> I meant to say that we should not allow the process to prevent the W= G >>>>>> from producing a quality document without issues, assuming there is = an >>>>>> issue in the first place. >>>>>> >>>>>> Ideally we want to get these identified during the WGLC, but things >>>>>> happen and sometimes the WG misses something. >>>>>> >>>>>> >>>>>> >>>>>> I hear you and agree that this make things difficult for authors. We >>>>>> will make sure that this does not become the norm, and we will try t= o stick >>>>>> to the process as much as possible. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>> Thanks Rifaat. Process is as process does, right? I do kinda want to >>>>>> grumble about WGCL having passed already but that's mostly because r= eplying >>>>>> to these kinds of threads is hard for me and I'll just get over it..= . >>>>>> >>>>>> >>>>>> >>>>>> As far as I understand things, the security concerns come into play >>>>>> when the client is being told the by the resource how to identity th= e >>>>>> resource like is described in https://tools.ietf.org/html/ >>>>>> draft-ietf-oauth-distributed-01 and using the actual location in >>>>>> that context ,along with some other checks prescribed in that draft, >>>>>> prevents the kind of issues John described earlier in the thread. >>>>>> >>>>>> In cases where the client knows the resource a priori or out-of-band >>>>>> or configured or whatever, I don't think the same security concerns = arise. >>>>>> And using such a known value, be it an actual location or logical >>>>>> representation, would be okay. >>>>>> >>>>>> The resource-indicators draft is admittedly somewhat location-centri= c >>>>>> in how it talks about the value of the 'resource' parameter. But ult= imately >>>>>> it defines it as an absolute URI that indicates the location of the = target >>>>>> service or resource where access is being requested. A location can = be >>>>>> varying shades of abstract and I'd say that using a URI as 'resource= ' >>>>>> parameter value that's a logical identifier that points to some reso= urce is >>>>>> well within the bounds of the draft. >>>>>> >>>>>> >>>>>> >>>>>> So maybe the draft is okay as is? >>>>>> >>>>>> >>>>>> >>>>>> Or perhaps that's too much to be left as an exerciser to the reader? >>>>>> And some text should be added and/or adjusted so the resource-indica= tors >>>>>> draft would be a little more open/clear about the parameter value >>>>>> potentially being more of a logical or abstract identifier and not >>>>>> necessarily a network addressable URL? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>>>>> rifaat.ietf@gmail.com> wrote: >>>>>> >>>>>> I wouldn't worry too much about the process. >>>>>> >>>>>> If it makes sense to update the document, then feel free to do that. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley >>>>>> wrote: >>>>>> >>>>>> Yes the logical resource can be provided by "scope" >>>>>> >>>>>> >>>>>> >>>>>> Some implementations like Ping and Auth0 have been adding another >>>>>> parameter "aud" to identify the logical resource and then using scop= es to >>>>>> define permissions to the resource. >>>>>> >>>>>> >>>>>> >>>>>> Fortunately, we are using a different parameter name so not stepping >>>>>> on that.. >>>>>> >>>>>> >>>>>> >>>>>> We could go back and try to add text explaining the difference, but >>>>>> we are quite late in the process. >>>>>> >>>>>> >>>>>> >>>>>> I agree that a logical resource parameter may be helpful, but perhap= s >>>>>> it should be a separate draft. >>>>>> >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>>>> richanna@amazon.com> wrote: >>>>>> >>>>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provid= e a means of specifying a >>>>>> logical identifier? >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From: *OAuth on behalf of Vittorio >>>>>> Bertocci >>>>> <40auth0..com@dmarc.ietf.org>> >>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>>> *To: *John Bradley >>>>>> *Cc: *IETF oauth WG >>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>>>> draft-ietf-oauth-resource-indicators-01 >>>>>> >>>>>> >>>>>> >>>>>> Thanks John for the background. >>>>>> >>>>>> I agree that from the client validation PoV, having an identifier >>>>>> corresponding to a location makes things more solid. >>>>>> >>>>>> That said: the use of logical identifiers is widespread, as it has >>>>>> significant practical advantages (think of services that assign gene= rated >>>>>> hosting URLs only at deployment time, or services that are somehow g= rouped >>>>>> under the same logical audience across regions/environment/deploymen= ts). >>>>>> People won't stop using logical identifiers, because they often have= no >>>>>> alternative (generating new audiences on the fly at the AS every tim= e you >>>>>> do a deployment and get assigned a new URL can be unfeasible). Leavi= ng a >>>>>> widely used approach as exercise to the reader seems a disservice to= the >>>>>> community, given that this might lead to vendors (for example Micros= oft and >>>>>> Auth0) keeping their own proprietary parameters, or developers misus= ing the >>>>>> ones in place; would make it hard for SDK developers to provide libr= aries >>>>>> that work out of the box with different ASes; and so on. >>>>>> >>>>>> Would it be feasible to add such parameter directly in this spec? >>>>>> That would eliminate the interop issues, and also gives us a chance = to >>>>>> fully warn people about the security shortcomings of choosing that a= pproach. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley >>>>>> wrote: >>>>>> >>>>>> We have discussed this. >>>>>> >>>>>> Audiences can certainly be logical identifiers. >>>>>> >>>>>> This however is a more specific location. The AS is free to map the >>>>>> location into some abstract audience in the AT. >>>>>> >>>>>> From a security point of view once the client starts asking for >>>>>> logical resources it can be tricked into asking for the wrong one as= a bad >>>>>> resource can always lie about what logical resource it is. >>>>>> >>>>>> If we were to change it, how a client would validate it becomes >>>>>> challenging to impossible. >>>>>> >>>>>> The AS is free to do whatever mapping of locations to identifiers it >>>>>> needs for access tokens. >>>>>> >>>>>> Some implementations may want to keep additional parameters like >>>>>> logical audience, but that should be separate from resource. >>>>>> >>>>>> John B. >>>>>> >>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> >>>>>> >>>>>> The text you quoted is copied form the abstract of the draft itself. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Authors,* >>>>>> >>>>>> >>>>>> >>>>>> Should the draft be updated to cover the logical identifier case? >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >>>>>> wrote: >>>>>> >>>>>> Hi Rifaat, >>>>>> >>>>>> one detail. The tech summary says >>>>>> >>>>>> >>>>>> >>>>>> An extension to the OAuth 2.0 Authorization Framework defining reque= st >>>>>> >>>>>> parameters that enable a client to explicitly signal to an authoriza= tion server >>>>>> >>>>>> about the *location* of the protected resource(s) to which it is req= uesting >>>>>> >>>>>> access. >>>>>> >>>>>> But at least in the Microsoft implementation, the resource identifie= r >>>>>> doesn't *have* to be a network addressable URL (and if it is, it >>>>>> doesn't strictly need to match the actual resource location). It can= be a >>>>>> logical identifier, tho using the actual resource location there has >>>>>> benefits (domain ownership check, prevention of token forwarding etc= ). >>>>>> >>>>>> Same for Auth0, the audience parameter is a logical identifier rathe= r >>>>>> than a location. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>>>> rifaat.ietf@gmail.com> wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> >>>>>> >>>>>> The following is the first shepherd write-up for >>>>>> the draft-ietf-oauth-resource-indicators-01 document. >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource- >>>>>> indicators/shepherdwriteup/ >>>>>> >>>>>> >>>>>> >>>>>> Please, take a look and let me know if I missed anything. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly prohib= ited. >>>>>> If you have received this communication in error, please notify the = sender >>>>>> immediately by e-mail and delete the message and any file attachment= s from >>>>>> your computer. Thank you.* >>>>>> >>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly prohib= ited.. >>>>>> If you have received this communication in error, please notify the = sender >>>>>> immediately by e-mail and delete the message and any file attachment= s from >>>>>> your computer. Thank you.* >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.*__________________________ >>> _____________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --000000000000553a74058001ff06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci = <Vittorio@auth0.com> wrote:=
Hi Rifaat,
absolute= ly. Brian and myself already started working on some language, however this= week he is in vacation hence it might take few days before we come back to= the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Ri= faat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Brian, Vittorio,

<= div>To move this discussion forward, can you guys suggest some text to make= the logical identifier usage clearer?

Regards,
=C2=A0Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bca= mpbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
As I suggested = before, I do think that's within the bounds of the draft's definiti= on of 'resource' as a URI. And that perhaps all that's needed i= s some minor adjustment and/or augmentation of some text to make it more cl= ear.

On Sun, Jan = 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
[s= ent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's=C2=A0resource. It could be us= ed for both network and logical ids, with the concrete usage in the wild I = described earlier.
In Azure AD v2, the resource as explicit para= meter (network, logic or otherwise) is gone and is expressed as part of the= scope string of all the scopes requested for a given resource- but it stil= l exist in practice tho as it still end up in the resulting=C2=A0aud=C2=A0of the i= ssued token.
This is 9 months old info hence

=
On Sun, Jan 20, 2019 at 17:58 J= ohn Bradley <ve7j= tb@ve7jtb.com> wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draf= t-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 a= nd using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request =

parameters that enable a client to explicitly signal to an authorizatio=
n server 
about the location of the protected resource(s) to which it is r=
equesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

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

________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


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


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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000553a74058001ff06-- From nobody Tue Jan 22 10:19:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31010130E2F for ; Tue, 22 Jan 2019 10:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 b6afmjtbouOB for ; Tue, 22 Jan 2019 10:19:41 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650108.outbound.protection.outlook.com [40.107.65.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B79A130EA4 for ; Tue, 22 Jan 2019 10:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=83GnSAJivF1J7b/m5JZWTLg73bKF3TVeS/B4K4797dQ=; b=ixC1Mr/xuK2M6jBmNfMKFTTK4ErYN6CivG6Rk423li+zJXhwynC/nW27KRwUmD+yC6aeiQVRfTIa5+hKSvMiX+TlXb3CJytnWtRYVUlx/YciUlk0tmqCb14y54IP+Edmw4BMp+fvxJog7JMUS2Y1i4Fy70VuUvbJT/tlafI7zSs= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (52.132.148.31) by MW2PR00MB0297.namprd00.prod.outlook.com (52.132.148.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1594.0; Tue, 22 Jan 2019 18:19:31 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::8112:4011:8b17:fce9]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::8112:4011:8b17:fce9%9]) with mapi id 15.20.1594.000; Tue, 22 Jan 2019 18:19:31 +0000 From: Mike Jones To: Rifaat Shekh-Yusef , Vittorio Bertocci CC: Brian Campbell , IETF oauth WG Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMSm6zRRv4Nr0eerioJ6LCFT6Wzcp6AgABNkQCAABqbAIABMd2AgABiBYCAAAiJAIAAAu6AgAAmUgCAAC6ggIAA30eAgAAm6gCAADowsIAAArOAgAHKeICAACE4AIAAC1UAgADX2YCAACJwAIAAdm6AgAAP8ICAARgQYA== Date: Tue, 22 Jan 2019 18:19:31 +0000 Message-ID: References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-01-22T18:19:27.7103517Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5c566e95-3e0e-4128-a4ec-cb0150a7577a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:3:95bf:cc4f:aee3:e40c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0297; 6:s+rkjCJ5NsoLktGY41C4sYhQ2jo/iZKXRkO1YCS3iXbrBV2ooaDBjHq6Hb8BRonnS3EKBdsvgwv3vn20nNINybDZAkpvrkO7IECGqEYw/9vy9GSqaNwKm6To7PS+YIFtVini1ibrlGCd9/TNT9gpig0nO43vXUH26UcYirYR3ikkDa77VNzBt+cqrvC3eDFzSx739oL/QQiwcEd89JuQDvCyRY4JigDeTJ9LvbIXS5oSDL1on/MrOA4qwPjbJu4BVEo632YskDoF3ldvOLhCzHMalmgsDMv+T7u5HbdlfTWG/OZHVPhy3hLOO5cibUVkbELAA1yKzNiODAgqK01qXBmvWOCCBQZMTo/Y1YAEPdpACWCO0C4t1tpar64HL8YdYqaHwCpk+vmrTsOdDzsvTir8advmCmqo1KT1K5sFuruBdsg07/n8S5F16CI8iAALBIhgdYehPiERHf2TTP5OpQ==; 5:RnzLAWRKNEh/IJZ+xdMn5q0jLM0t3YvpNn7ZCa51dJtD/MudnedBwpCOGRn2Ymo2HTZu9J8wLu+QK35dNeVlNNZooadSeA57/iUfJ3mCwsQec25dEOXZBGmSXSuTIBd3O30dKP8AXm8PFdbFBUdkSYJkdZp77zqbsNQXciboAK5iQPU+2bwwZZFmtbxvzwmSLZbFw+0ODUlw/WNfrPhwcg==; 7:6u7yr3JvJ0I0YxNbMg+4208NS/nqgJOwIqzpXygQj4ZIQqAgumOtZGTx7iaDob5oEfLiuKBa2Vv0D5JxkK44I90sP2JHsbzLMAcgoIMTfYllb5QNuIZwxhT0sFJcYS+DpZNu5lDCTVlD01fr0HyV0A== x-ms-office365-filtering-correlation-id: 52db4663-8968-4d68-33e1-08d68096277a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0297; x-ms-traffictypediagnostic: MW2PR00MB0297: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(136003)(39860400002)(366004)(376002)(346002)(396003)(189003)(199004)(51444003)(606006)(186003)(33656002)(86362001)(22452003)(46003)(7736002)(55016002)(10290500003)(72206003)(14454004)(30864003)(53546011)(86612001)(9686003)(229853002)(478600001)(6506007)(8990500004)(6306002)(54896002)(236005)(256004)(966005)(53946003)(5024004)(14444005)(10090500001)(6436002)(486006)(97736004)(6246003)(39060400002)(476003)(74316002)(6346003)(25786009)(4326008)(93886005)(7696005)(71190400001)(76176011)(71200400001)(790700001)(8936002)(81166006)(81156014)(6116002)(54906003)(110136005)(68736007)(8676002)(102836004)(106356001)(53936002)(316002)(99286004)(105586002)(446003)(2906002)(11346002)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0297; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lfhLwypeaNd3UeVHJp2BKg+Lk3ZZpi16pWH2yZfhFTi4QJpl9zTHLasgYyhHTsLg+Di9DxL1/WeRLXwwoSfkhe2BlTWYKz6wXQNmQAH3W5mQ/C+rlvP/AioHLRbkh8jO8wS3EUbWDmYW82sRSuJx1d99iJkQVIwimeFlZwwqQYeXuRrby816Oqyb7U/FWRunNP8wJ0lqdL+CUk4qovIHQs3bsaPLTDgu7uLCPAmwZVumT/38dItRQ9W7aonMtnb7sj2skAIuJ6vhTnaWTZUyOCCqG/2jicWPsKuJvUpOUlo/rNQK6C/BvULhJWVdep0wHID5DIblX5/DGIxFveZsoE6wANQ4BOE16pCGspgY1faGkZsGk3m5ymDmmRivoywf+0OvdE3CTdKVF9t/G6JQMXZD/G1x7dQZEzuI7YNwFZ4= Content-Type: multipart/alternative; boundary="_000_MW2PR00MB030099E717A31D46BCAA4F9AF5980MW2PR00MB0300namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52db4663-8968-4d68-33e1-08d68096277a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2019 18:19:31.3834 (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-Transport-CrossTenantHeadersStamped: MW2PR00MB0297 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 18:19:46 -0000 --_000_MW2PR00MB030099E717A31D46BCAA4F9AF5980MW2PR00MB0300namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGEgbm9uLW5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gIOKAnHJlcV9hdWTigJ0g aW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFt cy0wMSBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIHJlc291cmNlIGluZGljYXRvcnMgZG9jIHRvIGlu Zm9ybSBkZXZlbG9wZXJzIHRoYXQgcmVxX2F1ZCBpcyBhbHNvIGF2YWlsYWJsZSB0byB0aGVuLCBh bmQgdGhlbiB3ZSBzaG91bGQgY2FsbCBpdCBhIGRheS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWZhYXQgU2hl a2gtWXVzZWYNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyMSwgMjAxOSA1OjM2IFBNDQpUbzogVml0 dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNvbT4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz47IElFVEYgb2F1dGgg V0cgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2hlcGhlcmQgd3Jp dGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0KDQpUaGFu ayB5b3UgZ3V5cyENCg0KDQpPbiBNb25kYXksIEphbnVhcnkgMjEsIDIwMTksIFZpdHRvcmlvIEJl cnRvY2NpIDxWaXR0b3Jpb0BhdXRoMC5jb208bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+IHdy b3RlOg0KSGkgUmlmYWF0LA0KYWJzb2x1dGVseS4gQnJpYW4gYW5kIG15c2VsZiBhbHJlYWR5IHN0 YXJ0ZWQgd29ya2luZyBvbiBzb21lIGxhbmd1YWdlLCBob3dldmVyIHRoaXMgd2VlayBoZSBpcyBp biB2YWNhdGlvbiBoZW5jZSBpdCBtaWdodCB0YWtlIGZldyBkYXlzIGJlZm9yZSB3ZSBjb21lIGJh Y2sgdG8gdGhlIGxpc3Qgd2l0aCBzb21ldGhpbmcuDQpDaGVlcnMsDQpWLg0KDQpPbiBNb24sIEph biAyMSwgMjAxOSBhdCA5OjM1IEFNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21h aWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkJyaWFuLCBWaXR0 b3JpbywNCg0KVG8gbW92ZSB0aGlzIGRpc2N1c3Npb24gZm9yd2FyZCwgY2FuIHlvdSBndXlzIHN1 Z2dlc3Qgc29tZSB0ZXh0IHRvIG1ha2UgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciB1c2FnZSBjbGVh cmVyPw0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDEw OjMyIEFNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90 ZToNCkFzIEkgc3VnZ2VzdGVkIGJlZm9yZSwgSSBkbyB0aGluayB0aGF0J3Mgd2l0aGluIHRoZSBi b3VuZHMgb2YgdGhlIGRyYWZ0J3MgZGVmaW5pdGlvbiBvZiAncmVzb3VyY2UnIGFzIGEgVVJJLiBB bmQgdGhhdCBwZXJoYXBzIGFsbCB0aGF0J3MgbmVlZGVkIGlzIHNvbWUgbWlub3IgYWRqdXN0bWVu dCBhbmQvb3IgYXVnbWVudGF0aW9uIG9mIHNvbWUgdGV4dCB0byBtYWtlIGl0IG1vcmUgY2xlYXIu DQoNCk9uIFN1biwgSmFuIDIwLCAyMDE5IGF0IDc6MzkgUE0gVml0dG9yaW8gQmVydG9jY2kgPFZp dHRvcmlvQGF1dGgwLmNvbTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpbc2Vu dCB0byBKb2huIG9ubHkgYnkgbWlzdGFrZSwgcmVzZW5kaW5nIHRvIHRoZSBNTF0NCg0KSW4gQXp1 cmUgQUQgdjEgJiBBREZTLCB0aGF0J3MgcmVzb3VyY2UuIEl0IGNvdWxkIGJlIHVzZWQgZm9yIGJv dGggbmV0d29yayBhbmQgbG9naWNhbCBpZHMsIHdpdGggdGhlIGNvbmNyZXRlIHVzYWdlIGluIHRo ZSB3aWxkIEkgZGVzY3JpYmVkIGVhcmxpZXIuDQpJbiBBenVyZSBBRCB2MiwgdGhlIHJlc291cmNl IGFzIGV4cGxpY2l0IHBhcmFtZXRlciAobmV0d29yaywgbG9naWMgb3Igb3RoZXJ3aXNlKSBpcyBn b25lIGFuZCBpcyBleHByZXNzZWQgYXMgcGFydCBvZiB0aGUgc2NvcGUgc3RyaW5nIG9mIGFsbCB0 aGUgc2NvcGVzIHJlcXVlc3RlZCBmb3IgYSBnaXZlbiByZXNvdXJjZS0gYnV0IGl0IHN0aWxsIGV4 aXN0IGluIHByYWN0aWNlIHRobyBhcyBpdCBzdGlsbCBlbmQgdXAgaW4gdGhlIHJlc3VsdGluZyBh dWQgb2YgdGhlIGlzc3VlZCB0b2tlbi4NClRoaXMgaXMgOSBtb250aHMgb2xkIGluZm8gaGVuY2UN Cg0KT24gU3VuLCBKYW4gMjAsIDIwMTkgYXQgMTc6NTggSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3 anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KV2hhdCBpcyB0aGUg cGFyYW1ldGVyIHRoYXQgTWljcm9zb2Z0IGlzIHVzaW5nPw0KT24gMS8yMC8yMDE5IDM6NTkgUE0s IFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOg0KRmlyc3Qgb2YgYWxsLCBpdCB3YXNuJ3QgbXkgaW50 ZW50IHRvIGRpc3J1cHQgdGhlIGVzdGFibGlzaGVkIHByb2Nlc3MuIEluIG15IGZvcm1lciBwb3Np dGlvbiBJIHdhc24ndCBtb25pdG9yaW5nIHRob3NlIGRpc2N1c3Npb25zIGhlbmNlIEkgZGlkbid0 IGhhdmUgYSBjaGFuY2UgdG8gb2ZmZXIgZmVlZGJhY2suIFdoZW4gSSBzYXcgc29tZXRoaW5nIHRo YXQgZ2F2ZSBtZSB0aGUgaW1wcmVzc2lvbiBtaWdodCBsZWFkIHRvIGlzc3VlcywgYW5kIGdpdmVu IHRoYXQgSSB3b3JrZWQgd2l0aCBhY3R1YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNp bmcgYSBzaW1pbGFyIHBhcmFtZXRlciBmb3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50 IHRvIGJyaW5nIHRoaXMgdXAuIEkgcmVhbGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9u IHRoaXMuIEVuZCBvZiBwcmVhbWJsZS4NCg0KVWx0aW1hdGVseSBteSBnb2FsIGlzIGZvciBkZXZl bG9wZXJzIHRvIGhhdmUgZ3VpZGFuY2Ugb24gaG93IHRvIHdvcmsgd2l0aCB0aGUgY29uY2VwdCBv ZiBsb2dpY2FsIHJlc291cmNlIGluIGEgc3RhbmRhcmQgY29tcGxpYW50IHdheSwgaGVuY2UgaXQg ZG9lc24ndCBzdHJpY3RseSBtYXR0ZXIgd2hldGhlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgY29y cmVzcG9uZGluZyBwYXJhbWV0ZXIgbGl2ZXMgaW4gb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBv ciBlbHNld2hlcmUuDQpUaGF0IHNhaWQuIFJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQsIGl0IHdv dWxkIGFwcGVhciB0aGF0IG1vc3Qgb2YgdGhlIHJlYXNvbnMgZm9yIHdoaWNoIHRoZSBzcGVjIHdh cyBjcmVhdGVkIGFwcGx5IHRvIGJvdGggdGhlIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIHRoZSBs b2dpY2FsIHJlc291cmNlIHR5cGVzOiBrbm93aW5nIHdoYXQga2V5cyB0byB1c2UgdG8gZW5jcnlw dCB0aGUgdG9rZW4sIGNvbnN0cmFpbiBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBpbnRlbmRlZCBhdWRp ZW5jZSwgYXZvaWRpbmcgb3ZlcmxvYWRpbmcgc2NvcGVzIHdpdGggcmVzb3VyY2UgaW5kaWNhdGlu ZyBwYXJ0cy4uLiB0aG9zZSBhbGwgYXBwbHkgdG8gbmV0d29yayBhZGRyZXNzYWJsZSBhbmQgbG9n aWMgaWRlbnRpZmllcnMgYWxpa2UuIEFuZCBib3RoIHBhcmFtZXRlcnMgYXJlIGV4cGVjdGVkIHRv IHJlc3VsdCBpbiBhdWRpZW5jZSByZXN0cmljdGVkIHRva2Vucy4gSXQgc2VlbXMgdGhlIG9ubHkg ZGlmZmVyZW5jZSBjb21lcyBhdCB0b2tlbiB1c2FnZSB0aW1lLCB3aXRoIHRoZSBuZXR3b3JrIGFk ZHJlc3NhYmxlIGNhc2UgZ2l2aW5nIG1vcmUgZ3VhcmFudGVlcyB0aGF0IHRoZSB0b2tlbiB3aWxs IGdvIHRvIGl0cyBpbnRlbmRlZCByZWNpcGllbnQsIGJ1dCB0aGUgcmVxdWVzdCBhbmQgYXVkaWVu Y2UgcmVzdHJpY3Rpb24gc3ludGF4IHNlZW1zIHRvIGJlIGV4YWN0bHkgdGhlIHNhbWUuDQpPbiB0 b3Agb2YgdGhpczogaW4gdGhlIDk5Ljk5OSUgb2YgdGhlIHNjZW5hcmlvcyBJIGVuY291bnRlcmVk IGluIHRoZSB3aWxkIGluIHRoZSBsYXN0IDUgeWVhcnMgb2YgdXNpbmcgdGhlIHJlc291cmNlIHBh cmFtZXRlciBpbiB0aGUgTVMgZWNvc3lzdGVtLCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciB3YXMg a25vd24gYXQgZGVzaWduIHRpbWU6IHRoZSBkZXZlbG9wZXIgZGlzY292ZXJlZCBpdCBvdXQgb2Yg YmFuZCBhbmQgcGxhY2VkIGl0IGluIHRoZSBhcHAgY29uZmlnIGF0IGRlcGxveW1lbnQgdGltZS4g VGhvc2UgYXJlbid0IGZyaW5nZSBjYXNlcyBJIG9jY2FzaW9uYWxseSBlbmNvdW50ZXJlZDogdGhl IHJlc291cmNlIHBhcmFtZXRlciBpbiBBenVyZSBBRCB2MSBhbmQgQURGUyB3YXMgbWFuZGF0b3J5 LCBoZW5jZSBsaXRlcmFsbHkgZXZlcnkgc29sdXRpb24gaSBzYXcgb3IgdG91Y2hlZCB1c2VkIGl0 LiBBcyBCcmlhbiBzdWdnZXN0ZWQsIHRoaXMgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgc2VjdXJp dHkgYWR2YW50YWdlcyBvZiB0aGUgbmV0d29yayBhZGRyZXNzYWJsZSBjYXNlIGFyZW4ndCBhcyBw cm9ub3VuY2VkIGFzIGluIHRoZSBjYXNlIGluIHdoaWNoIHRoZSBjbGllbnQgZGlzY292ZXJzIHRo ZSByZXNvdXJjZSBpZGVudGlmaWVyIGF0IHJ1bnRpbWUuIFRoaXMgaXNuJ3QganVzdCBiZWNhdXNl IHRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24gc3VnZ2VzdGluZyBsb2NhdGlvbiBzaG91bGQgYmUg ZXhwbGljaXRseSBpbmRpY2F0ZWQsIGl0J3MgYmVjYXVzZSB0aGVyZSBhcmUgbWFueSBwcmFjdGlj YWwgYWR2YW50YWdlcyBhdCBkZXZlbG9wbWVudCBhbmQgZGVwbG95bWVudCB0aW1lIHRvIGJlIGFi bGUgdG8gdXNlIGxvZ2ljYWwgaWRlbnRpZmllcnMtIGFuZCBpZiB0aGUgY29uY3JldGUgc2VjdXJp dHkgYWR2YW50YWdlcyBkb24ndCBhcHBseSB0byB0aGUgdGhlaXIgY2FzZSwgcGVvcGxlIHdpbGwg c2ltcGx5IG5vdCBjb21wbHkuDQoNCkluIHN1bW1hcnk6IGNyZWF0aW5nIHR3byBkaWZmZXJlbnQg cGFyYW1ldGVycyBpbiB0d28gZGlmZmVyZW50IGRvY3VtZW50cyBpcyBiZXR0ZXIgdGhhbiBpZ25v cmluZyBoZSBsb2dpY2FsIGlkZW50aWZpZXIgY2FzZSBhbHRvZ2V0aGVyLCBob3dldmVyIEkgdGhp bmsgdGhhdCBub3QgYWNrbm93bGVkZ2luZyB0aGUgbG9naWNhbCBpZCBjYXNlIGluIG9hdXRoLXJl c291cmNlLWluZGljYXRvcnMgaXMgZ29pbmcgdG8gY3JlYXRlIGNvbmZ1c2lvbiBhbmQgdWx0aW1h dGVseSBub3QgYmUgYXMgdXNlZnVsIHRvIHRoZSBkZXZlbG9wZXIgY29tbXVuaXR5IGFzIGl0IGNv dWxkIGJlLg0KDQoNCg0KT24gU2F0LCBKYW4gMTksIDIwMTkgYXQgMTI6MzggUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToN CisxIHRvIE1pa2UgYW5kIEpvaG7igJlzIGNvbW1lbnRzLg0KUGhpbA0KDQpPbiBKYW4gMTksIDIw MTksIGF0IDEyOjM0IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgYWxzbyBhZ3JlZSB0aGF0IOKAnHJlc291cmNl4oCdIHNo b3VsZCBiZSBhIHNwZWNpZmljIG5ldHdvcmstYWRkcmVzc2FibGUgVVJMIHdoZXJlYXMgYSBzZXBh cmF0ZSBhdWRpZW5jZSBwYXJhbWV0ZXIgKGxpa2Ug4oCcYXVk4oCdIGluIEpXVHMpIGNhbiByZWZl ciB0byBvbmUgb3IgbW9yZSBsb2dpY2FsIHJlc291cmNlcy4gIFRoZXkgYXJlIGRpZmZlcmVudCwg aWYgcmVsYXRlZCwgdGhpbmdzLg0KDQpOb3RlIHRoYXQgdGhlIEFDRSBXRyBpcyBwcm9wb3Npbmcg dG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciDigJxyZXFfYXVk4oCdIGlu IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMt MDEgLSBwYXJ0bHkgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBPQXV0aCBXRyBtZW1iZXJzLiAgVGhp cyBpcyBhIGdlbmVyYWwgT0F1dGggcGFyYW1ldGVyLCB3aGljaCBhbnkgT0F1dGggZGVwbG95bWVu dCB3aWxsIGJlIGFibGUgdG8gdXNlLg0KDQpJIHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hh bmdlcyBhcmUgbmVlZGVkIHRvIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywg YXMgdGhlIGxvZ2ljYWwgYXVkaWVuY2Ugd29yayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90 aGVyIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKb2huIEJy YWRsZXkNClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDE5LCAyMDE5IDk6MDEgQU0NClRvOiBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPj4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRo MC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOlZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmll dGYub3JnPj47IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNCldlIG5lZWQgdG8gZGVjaWRl IGlmIHdlIHdhbnQgdG8gbWFrZSBhIGNoYW5nZS4NCg0KRm9yIHNlY3VyaXR5IHdlIGFyZSBsb2Nh dGlvbiBjZW50cmljLg0KDQpJIHByZWZlciB0byBrZWVwIHJlc291cmNlIGxvY2F0aW9uIHNlcGFy YXRlIGZyb20gbG9naWNhbCBhdWRpZW5jZSB0aGF0IGNhbiBiZSBhIHNjb3BlIG9yIG90aGVyIHBh cmFtZXRlci4NCg0KSWYgYmVjb21lcyBoYXJkZXIgZm9yIHBlb3BsZSB0byB1c2UgdGhlIHBhcmFt ZXRlciBjb3JyZWN0bHkgaWYgd2UgYXJlIHRvbyBmbGV4aWJsZS4NCg0KSSB3b3VsZCByYXRoZXIg aGF2ZSBhIHNlcGFyYXRlIGxvZ2ljYWwgYXVkaWVuY2UgcGFyYW1ldGVyIGlmIHdlIHRoaW5rIHdl IHdhbnQgb25lLg0KDQpKb2huIEIuDQoNCk9uIFNhdCwgSmFuIDE5LCAyMDE5LCAxMTo0MSBBTSBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPiB3cm90ZToNCk5vIGFwb2xvZ3kgbmVlZGVkLCBSaWZhYXQuIEFu ZCBJIGFwb2xvZ2l6ZSBpZiB3aGF0IEkgc2FpZCBjYW1lIG9mZiB0aGUgd3Jvbmcgd2F5LiBJIHdh cyBqdXN0IHRyeWluZyB0byBtYWtlIGxpZ2h0IG9mIHRoZSBzaXR1YXRpb24uLiBBbmQgSSBhZ3Jl ZSB0aGF0IHdlIHNob3VsZCBub3QgYmUgaGFtc3RydW5nIGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVy ZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBzZW5zZSB0byBiZSBmbGV4aWJsZSB3aXRoIHRoaW5n cy4NCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNjoyMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYg PHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3Jv dGU6DQpTb3JyeSBCcmlhbiwgSSB3YXMgbm90IGNsZWFyIHdpdGggbXkgc3RhdGVtZW50Lg0KSSBt ZWFudCB0byBzYXkgdGhhdCB3ZSBzaG91bGQgbm90IGFsbG93IHRoZSBwcm9jZXNzIHRvIHByZXZl bnQgdGhlIFdHIGZyb20gcHJvZHVjaW5nIGEgcXVhbGl0eSBkb2N1bWVudCB3aXRob3V0IGlzc3Vl cywgYXNzdW1pbmcgdGhlcmUgaXMgYW4gaXNzdWUgaW4gdGhlIGZpcnN0IHBsYWNlLg0KSWRlYWxs eSB3ZSB3YW50IHRvIGdldCB0aGVzZSBpZGVudGlmaWVkIGR1cmluZyB0aGUgV0dMQywgYnV0IHRo aW5ncyBoYXBwZW4gYW5kIHNvbWV0aW1lcyB0aGUgV0cgbWlzc2VzIHNvbWV0aGluZy4NCg0KSSBo ZWFyIHlvdSBhbmQgYWdyZWUgdGhhdCB0aGlzIG1ha2UgdGhpbmdzIGRpZmZpY3VsdCBmb3IgYXV0 aG9ycy4gV2Ugd2lsbCBtYWtlIHN1cmUgdGhhdCB0aGlzIGRvZXMgbm90IGJlY29tZSB0aGUgbm9y bSwgYW5kIHdlIHdpbGwgdHJ5IHRvIHN0aWNrIHRvIHRoZSBwcm9jZXNzIGFzIG11Y2ggYXMgcG9z c2libGUuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQg NTozNSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpUaGFua3MgUmlmYWF0LiBQcm9j ZXNzIGlzIGFzIHByb2Nlc3MgZG9lcywgcmlnaHQ/IEkgZG8ga2luZGEgd2FudCB0byBncnVtYmxl IGFib3V0IFdHQ0wgaGF2aW5nIHBhc3NlZCBhbHJlYWR5IGJ1dCB0aGF0J3MgbW9zdGx5IGJlY2F1 c2UgcmVwbHlpbmcgdG8gdGhlc2Uga2luZHMgb2YgdGhyZWFkcyBpcyBoYXJkIGZvciBtZSBhbmQg SSdsbCBqdXN0IGdldCBvdmVyIGl0Li4uDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhpbmdz LCB0aGUgc2VjdXJpdHkgY29uY2VybnMgY29tZSBpbnRvIHBsYXkgd2hlbiB0aGUgY2xpZW50IGlz IGJlaW5nIHRvbGQgdGhlIGJ5IHRoZSByZXNvdXJjZSBob3cgdG8gaWRlbnRpdHkgdGhlIHJlc291 cmNlIGxpa2UgaXMgZGVzY3JpYmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVkLTAxIGFuZCB1c2luZyB0aGUgYWN0dWFsIGxvY2F0aW9u IGluIHRoYXQgY29udGV4dCAsYWxvbmcgd2l0aCBzb21lIG90aGVyIGNoZWNrcyBwcmVzY3JpYmVk IGluIHRoYXQgZHJhZnQsIHByZXZlbnRzIHRoZSBraW5kIG9mIGlzc3VlcyBKb2huIGRlc2NyaWJl ZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQuDQoNCkluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQga25v d3MgdGhlIHJlc291cmNlIGEgcHJpb3JpIG9yIG91dC1vZi1iYW5kIG9yIGNvbmZpZ3VyZWQgb3Ig d2hhdGV2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIHNhbWUgc2VjdXJpdHkgY29uY2VybnMgYXJpc2Uu IEFuZCB1c2luZyBzdWNoIGEga25vd24gdmFsdWUsIGJlIGl0IGFuIGFjdHVhbCBsb2NhdGlvbiBv ciBsb2dpY2FsIHJlcHJlc2VudGF0aW9uLCB3b3VsZCBiZSBva2F5Lg0KDQpUaGUgcmVzb3VyY2Ut aW5kaWNhdG9ycyBkcmFmdCBpcyBhZG1pdHRlZGx5IHNvbWV3aGF0IGxvY2F0aW9uLWNlbnRyaWMg aW4gaG93IGl0IHRhbGtzIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgJ3Jlc291cmNlJyBwYXJhbWV0 ZXIuIEJ1dCB1bHRpbWF0ZWx5IGl0IGRlZmluZXMgaXQgYXMgYW4gYWJzb2x1dGUgVVJJIHRoYXQg aW5kaWNhdGVzIHRoZSBsb2NhdGlvbiBvZiB0aGUgdGFyZ2V0IHNlcnZpY2Ugb3IgcmVzb3VyY2Ug d2hlcmUgYWNjZXNzIGlzIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2NhdGlvbiBjYW4gYmUgdmFyeWlu ZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1c2luZyBhIFVSSSBhcyAncmVz b3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2FsIGlkZW50aWZpZXIgdGhhdCBw b2ludHMgdG8gc29tZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBk cmFmdC4NCg0KU28gbWF5YmUgdGhlIGRyYWZ0IGlzIG9rYXkgYXMgaXM/DQoNCk9yIHBlcmhhcHMg dGhhdCdzIHRvbyBtdWNoIHRvIGJlIGxlZnQgYXMgYW4gZXhlcmNpc2VyIHRvIHRoZSByZWFkZXI/ ICBBbmQgc29tZSB0ZXh0IHNob3VsZCBiZSBhZGRlZCBhbmQvb3IgYWRqdXN0ZWQgc28gdGhlIHJl c291cmNlLWluZGljYXRvcnMgZHJhZnQgd291bGQgYmUgYSBsaXR0bGUgbW9yZSBvcGVuL2NsZWFy IGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFsdWUgcG90ZW50aWFsbHkgYmVpbmcgbW9yZSBvZiBhIGxv Z2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0d29y ayBhZGRyZXNzYWJsZSBVUkw/DQoNCg0KDQpPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxOjE4IFBN IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQu aWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgd291bGRuJ3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQg dGhlIHByb2Nlc3MuDQpJZiBpdCBtYWtlcyBzZW5zZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50LCB0 aGVuIGZlZWwgZnJlZSB0byBkbyB0aGF0Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIEZy aSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNClllcyB0aGUgbG9naWNhbCByZXNv dXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgInNjb3BlIg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyBs aWtlIFBpbmcgYW5kIEF1dGgwIGhhdmUgYmVlbiBhZGRpbmcgYW5vdGhlciBwYXJhbWV0ZXIgImF1 ZCIgdG8gaWRlbnRpZnkgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgYW5kIHRoZW4gdXNpbmcgc2NvcGVz IHRvIGRlZmluZSBwZXJtaXNzaW9ucyB0byB0aGUgcmVzb3VyY2UuDQoNCkZvcnR1bmF0ZWx5LCB3 ZSBhcmUgdXNpbmcgYSBkaWZmZXJlbnQgcGFyYW1ldGVyIG5hbWUgc28gbm90IHN0ZXBwaW5nIG9u IHRoYXQuLg0KDQpXZSBjb3VsZCBnbyBiYWNrIGFuZCB0cnkgdG8gYWRkIHRleHQgZXhwbGFpbmlu ZyB0aGUgZGlmZmVyZW5jZSwgYnV0IHdlIGFyZSBxdWl0ZSBsYXRlIGluIHRoZSBwcm9jZXNzLg0K DQpJIGFncmVlIHRoYXQgYSBsb2dpY2FsIHJlc291cmNlIHBhcmFtZXRlciBtYXkgYmUgaGVscGZ1 bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZHJhZnQuDQoNCkpvaG4gQi4N Cg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNDozOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdy b3RlOg0KRG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRl IGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj8NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRm Lm9yZzxtYWlsdG86NDBhdXRoMC4uY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwg SmFudWFyeSAxOCwgMjAxOSBhdCA1OjQ3IEFNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3 anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KQ2M6IElFVEYgb2F1dGggV0cgPG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzLTAxDQoNClRoYW5rcyBKb2huIGZvciB0aGUgYmFja2dyb3VuZC4NCkkgYWdyZWUgdGhh dCBmcm9tIHRoZSBjbGllbnQgdmFsaWRhdGlvbiBQb1YsIGhhdmluZyBhbiBpZGVudGlmaWVyIGNv cnJlc3BvbmRpbmcgdG8gYSBsb2NhdGlvbiBtYWtlcyB0aGluZ3MgbW9yZSBzb2xpZC4NClRoYXQg c2FpZDogdGhlIHVzZSBvZiBsb2dpY2FsIGlkZW50aWZpZXJzIGlzIHdpZGVzcHJlYWQsIGFzIGl0 IGhhcyBzaWduaWZpY2FudCBwcmFjdGljYWwgYWR2YW50YWdlcyAodGhpbmsgb2Ygc2VydmljZXMg dGhhdCBhc3NpZ24gZ2VuZXJhdGVkIGhvc3RpbmcgVVJMcyBvbmx5IGF0IGRlcGxveW1lbnQgdGlt ZSwgb3Igc2VydmljZXMgdGhhdCBhcmUgc29tZWhvdyBncm91cGVkIHVuZGVyIHRoZSBzYW1lIGxv Z2ljYWwgYXVkaWVuY2UgYWNyb3NzIHJlZ2lvbnMvZW52aXJvbm1lbnQvZGVwbG95bWVudHMpLiBQ ZW9wbGUgd29uJ3Qgc3RvcCB1c2luZyBsb2dpY2FsIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkg b2Z0ZW4gaGF2ZSBubyBhbHRlcm5hdGl2ZSAoZ2VuZXJhdGluZyBuZXcgYXVkaWVuY2VzIG9uIHRo ZSBmbHkgYXQgdGhlIEFTIGV2ZXJ5IHRpbWUgeW91IGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFz c2lnbmVkIGEgbmV3IFVSTCBjYW4gYmUgdW5mZWFzaWJsZSkuIExlYXZpbmcgYSB3aWRlbHkgdXNl ZCBhcHByb2FjaCBhcyBleGVyY2lzZSB0byB0aGUgcmVhZGVyIHNlZW1zIGEgZGlzc2VydmljZSB0 byB0aGUgY29tbXVuaXR5LCBnaXZlbiB0aGF0IHRoaXMgbWlnaHQgbGVhZCB0byB2ZW5kb3JzIChm b3IgZXhhbXBsZSBNaWNyb3NvZnQgYW5kIEF1dGgwKSBrZWVwaW5nIHRoZWlyIG93biBwcm9wcmll dGFyeSBwYXJhbWV0ZXJzLCBvciBkZXZlbG9wZXJzIG1pc3VzaW5nIHRoZSBvbmVzIGluIHBsYWNl OyB3b3VsZCBtYWtlIGl0IGhhcmQgZm9yIFNESyBkZXZlbG9wZXJzIHRvIHByb3ZpZGUgbGlicmFy aWVzIHRoYXQgd29yayBvdXQgb2YgdGhlIGJveCB3aXRoIGRpZmZlcmVudCBBU2VzOyBhbmQgc28g b24uDQpXb3VsZCBpdCBiZSBmZWFzaWJsZSB0byBhZGQgc3VjaCBwYXJhbWV0ZXIgZGlyZWN0bHkg aW4gdGhpcyBzcGVjPyBUaGF0IHdvdWxkIGVsaW1pbmF0ZSB0aGUgaW50ZXJvcCBpc3N1ZXMsIGFu ZCBhbHNvIGdpdmVzIHVzIGEgY2hhbmNlIHRvIGZ1bGx5IHdhcm4gcGVvcGxlIGFib3V0IHRoZSBz ZWN1cml0eSBzaG9ydGNvbWluZ3Mgb2YgY2hvb3NpbmcgdGhhdCBhcHByb2FjaC4NCg0KDQoNCk9u IFRodSwgSmFuIDE3LCAyMDE5IGF0IDQ6MzIgUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi LmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KV2UgaGF2ZSBkaXNjdXNz ZWQgdGhpcy4NCg0KQXVkaWVuY2VzIGNhbiBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVudGlmaWVy cy4NCg0KVGhpcyBob3dldmVyIGlzIGEgbW9yZSBzcGVjaWZpYyBsb2NhdGlvbi4gIFRoZSBBUyBp cyBmcmVlIHRvIG1hcCB0aGUgbG9jYXRpb24gaW50byBzb21lIGFic3RyYWN0IGF1ZGllbmNlIGlu IHRoZSBBVC4NCg0KRnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcgb25jZSB0aGUgY2xpZW50 IHN0YXJ0cyBhc2tpbmcgZm9yIGxvZ2ljYWwgcmVzb3VyY2VzIGl0IGNhbiBiZSB0cmlja2VkIGlu dG8gYXNraW5nIGZvciB0aGUgd3Jvbmcgb25lIGFzIGEgYmFkIHJlc291cmNlIGNhbiBhbHdheXMg bGllIGFib3V0IHdoYXQgbG9naWNhbCByZXNvdXJjZSBpdCBpcy4NCg0KSWYgd2Ugd2VyZSB0byBj aGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3b3VsZCB2YWxpZGF0ZSBpdCBiZWNvbWVzIGNoYWxsZW5n aW5nIHRvIGltcG9zc2libGUuDQoNClRoZSBBUyBpcyBmcmVlIHRvIGRvIHdoYXRldmVyIG1hcHBp bmcgb2YgbG9jYXRpb25zIHRvIGlkZW50aWZpZXJzIGl0IG5lZWRzIGZvciBhY2Nlc3MgdG9rZW5z Lg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byBrZWVwIGFkZGl0aW9uYWwgcGFy YW1ldGVycyBsaWtlIGxvZ2ljYWwgYXVkaWVuY2UsIGJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0 ZSBmcm9tIHJlc291cmNlLg0KDQpKb2huIEIuDQpPbiAxLzE3LzIwMTkgOTo1NiBBTSwgUmlmYWF0 IFNoZWtoLVl1c2VmIHdyb3RlOg0KSGkgVml0dG9yaW8sDQoNClRoZSB0ZXh0IHlvdSBxdW90ZWQg aXMgY29waWVkIGZvcm0gdGhlIGFic3RyYWN0IG9mIHRoZSBkcmFmdCBpdHNlbGYuDQoNCg0KQXV0 aG9ycywNCg0KU2hvdWxkIHRoZSBkcmFmdCBiZSB1cGRhdGVkIHRvIGNvdmVyIHRoZSBsb2dpY2Fs IGlkZW50aWZpZXIgY2FzZT8NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBUaHUsIEphbiAx NywgMjAxOSBhdCA4OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRoMC5jb208 bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+IHdyb3RlOg0KSGkgUmlmYWF0LA0Kb25lIGRldGFp bC4gVGhlIHRlY2ggc3VtbWFyeSBzYXlzDQoNCg0KQW4gZXh0ZW5zaW9uIHRvIHRoZSBPQXV0aCAy LjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsgZGVmaW5pbmcgcmVxdWVzdA0KDQpwYXJhbWV0ZXJz IHRoYXQgZW5hYmxlIGEgY2xpZW50IHRvIGV4cGxpY2l0bHkgc2lnbmFsIHRvIGFuIGF1dGhvcml6 YXRpb24gc2VydmVyDQoNCmFib3V0IHRoZSBsb2NhdGlvbiBvZiB0aGUgcHJvdGVjdGVkIHJlc291 cmNlKHMpIHRvIHdoaWNoIGl0IGlzIHJlcXVlc3RpbmcNCg0KYWNjZXNzLg0KQnV0IGF0IGxlYXN0 IGluIHRoZSBNaWNyb3NvZnQgaW1wbGVtZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVy IGRvZXNuJ3QgaGF2ZSB0byBiZSBhIG5ldHdvcmsgYWRkcmVzc2FibGUgVVJMIChhbmQgaWYgaXQg aXMsIGl0IGRvZXNuJ3Qgc3RyaWN0bHkgbmVlZCB0byBtYXRjaCB0aGUgYWN0dWFsIHJlc291cmNl IGxvY2F0aW9uKS4gSXQgY2FuIGJlIGEgbG9naWNhbCBpZGVudGlmaWVyLCB0aG8gdXNpbmcgdGhl IGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbiB0aGVyZSBoYXMgYmVuZWZpdHMgKGRvbWFpbiBvd25l cnNoaXAgY2hlY2ssIHByZXZlbnRpb24gb2YgdG9rZW4gZm9yd2FyZGluZyBldGMpLg0KU2FtZSBm b3IgQXV0aDAsIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIg cmF0aGVyIHRoYW4gYSBsb2NhdGlvbi4NCg0KDQoNCk9uIFdlZCwgSmFuIDE2LCAyMDE5IGF0IDY6 MzIgUE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJp ZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KQWxsLA0KDQpUaGUgZm9sbG93aW5nIGlzIHRo ZSBmaXJzdCBzaGVwaGVyZCB3cml0ZS11cCBmb3IgdGhlIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycy0wMSBkb2N1bWVudC4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAv DQoNClBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IGlmIEkgbWlzc2VkIGFueXRo aW5nLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJ VFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo cykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJz IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLi4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r IHlvdS5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_MW2PR00MB030099E717A31D46BCAA4F9AF5980MW2PR00MB0300namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSB0aGluayB0aGF0IGEg bm9uLW5vcm1hdGl2ZSByZWZlcmVuY2UgdG8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A74oCccmVxX2F1ZOKAnSBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1z LTAxPC9hPiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIHJlc291cmNlIGluZGljYXRvcnMgZG9jIHRv IGluZm9ybSBkZXZlbG9wZXJzIHRoYXQgcmVxX2F1ZCBpcyBhbHNvIGF2YWlsYWJsZSB0byB0aGVu LCBhbmQgdGhlbiB3ZSBzaG91bGQgY2FsbCBpdCBhIGRheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg PC9iPg0KUmlmYWF0IFNoZWtoLVl1c2VmPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFy eSAyMSwgMjAxOSA1OjM2IFBNPGJyPg0KPGI+VG86PC9iPiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 Vml0dG9yaW9AYXV0aDAuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0 O2JjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBJRVRGIG9h dXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZ3V5cyE8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiBN b25kYXksIEphbnVhcnkgMjEsIDIwMTksIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJt YWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIj5WaXR0b3Jpb0BhdXRoMC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgUmlmYWF0LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFic29sdXRlbHkuIEJyaWFuIGFuZCBteXNlbGYgYWxyZWFkeSBzdGFydGVkIHdvcmtpbmcgb24g c29tZSBsYW5ndWFnZSwgaG93ZXZlciB0aGlzIHdlZWsgaGUgaXMgaW4gdmFjYXRpb24gaGVuY2Ug aXQgbWlnaHQgdGFrZSBmZXcgZGF5cyBiZWZvcmUgd2UgY29tZSBiYWNrIHRvIHRoZSBsaXN0IHdp dGggc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Vi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMjEsIDIwMTkgYXQgOTozNSBBTSBSaWZhYXQgU2hla2gt WXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlh biwgVml0dG9yaW8sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UbyBtb3ZlIHRoaXMgZGlzY3Vzc2lvbiBmb3J3YXJkLCBjYW4geW91IGd1eXMgc3VnZ2VzdCBz b21lIHRleHQgdG8gbWFrZSB0aGUgbG9naWNhbCBpZGVudGlmaWVyIHVzYWdlIGNsZWFyZXI/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEphbiAyMSwgMjAxOSBhdCAxMDozMiBBTSBCcmlhbiBDYW1wYmVs bCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHN1Z2dlc3RlZCBiZWZvcmUsIEkgZG8gdGhp bmsgdGhhdCdzIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkcmFmdCdzIGRlZmluaXRpb24gb2Yg J3Jlc291cmNlJyBhcyBhIFVSSS4gQW5kIHRoYXQgcGVyaGFwcyBhbGwgdGhhdCdzIG5lZWRlZCBp cyBzb21lIG1pbm9yIGFkanVzdG1lbnQgYW5kL29yIGF1Z21lbnRhdGlvbiBvZiBzb21lIHRleHQg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTdW4sIEphbiAyMCwgMjAxOSBhdCA3OjM5IFBNIFZpdHRvcmlvIEJl cnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9i bGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNi41cHQ7Y29sb3I6IzMxMzEzMTtiYWNrZ3JvdW5kOndoaXRlIj5bc2Vu dCB0byBKb2huIG9ubHkgYnkgbWlzdGFrZSwgcmVzZW5kaW5nIHRvIHRoZSBNTF08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTYuNXB0O2NvbG9yOiMzMTMxMzE7YmFja2dyb3VuZDp3aGl0ZSI+ SW4gQXp1cmUgQUQgdjEgJmFtcDsgQURGUywgdGhhdCdzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMzEzMTMxIj5yZXNv dXJjZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjVwdDtjb2xvcjojMzEzMTMxO2Jh Y2tncm91bmQ6d2hpdGUiPi4gSXQgY291bGQNCiBiZSB1c2VkIGZvciBib3RoIG5ldHdvcmsgYW5k IGxvZ2ljYWwgaWRzLCB3aXRoIHRoZSBjb25jcmV0ZSB1c2FnZSBpbiB0aGUgd2lsZCBJIGRlc2Ny aWJlZCBlYXJsaWVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzMxMzEzMSI+SW4gQXp1cmUgQUQgdjIsIHRoZSBy ZXNvdXJjZSBhcyBleHBsaWNpdCBwYXJhbWV0ZXIgKG5ldHdvcmssIGxvZ2ljIG9yIG90aGVyd2lz ZSkgaXMgZ29uZSBhbmQgaXMgZXhwcmVzc2VkIGFzIHBhcnQgb2YgdGhlIHNjb3BlIHN0cmluZyBv ZiBhbGwgdGhlIHNjb3BlcyByZXF1ZXN0ZWQgZm9yIGEgZ2l2ZW4gcmVzb3VyY2UtIGJ1dCBpdCBz dGlsbCBleGlzdCBpbiBwcmFjdGljZQ0KIHRobyBhcyBpdCBzdGlsbCBlbmQgdXAgaW4gdGhlIHJl c3VsdGluZyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzMxMzEzMSI+YXVkPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MzEzMTMxIj4mbmJzcDtvZiB0aGUgaXNzdWVkIHRva2VuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MzEzMTMxIj5UaGlzIGlzIDkgbW9udGhzIG9sZCBpbmZvIGhlbmNlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3Vu LCBKYW4gMjAsIDIwMTkgYXQgMTc6NTggSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86 dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxw PldoYXQgaXMgdGhlIHBhcmFtZXRlciB0aGF0IE1pY3Jvc29mdCBpcyB1c2luZz88bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzIwLzIwMTkgMzo1OSBQTSwg Vml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJzdCBv ZiBhbGwsIGl0IHdhc24ndCBteSBpbnRlbnQgdG8gZGlzcnVwdCB0aGUgZXN0YWJsaXNoZWQgcHJv Y2Vzcy4gSW4gbXkgZm9ybWVyIHBvc2l0aW9uIEkgd2Fzbid0IG1vbml0b3JpbmcgdGhvc2UgZGlz Y3Vzc2lvbnMgaGVuY2UgSSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBvZmZlciBmZWVkYmFjay4g V2hlbiBJIHNhdyBzb21ldGhpbmcgdGhhdCBnYXZlIG1lIHRoZSBpbXByZXNzaW9uIG1pZ2h0IGxl YWQNCiB0byBpc3N1ZXMsIGFuZCBnaXZlbiB0aGF0IEkgd29ya2VkIHdpdGggYWN0dWFsIGRlcGxv eW1lbnRzIGFuZCBkZXZlbG9wZXJzIHVzaW5nIGEgc2ltaWxhciBwYXJhbWV0ZXIgZm9yIGEgbG9u ZyB0aW1lLCBJIHRob3VnaHQgcHJ1ZGVudCB0byBicmluZyB0aGlzIHVwLiBJIHJlYWxseSBhcHBy ZWNpYXRlIFJpZmFhdCdzIHN0YW5jZSBvbiB0aGlzLiBFbmQgb2YgcHJlYW1ibGUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VWx0 aW1hdGVseSBteSBnb2FsIGlzIGZvciBkZXZlbG9wZXJzIHRvIGhhdmUgZ3VpZGFuY2Ugb24gaG93 IHRvIHdvcmsgd2l0aCB0aGUgY29uY2VwdCBvZiBsb2dpY2FsIHJlc291cmNlIGluIGEgc3RhbmRh cmQgY29tcGxpYW50IHdheSwgaGVuY2UgaXQgZG9lc24ndCBzdHJpY3RseSBtYXR0ZXIgd2hldGhl ciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgY29ycmVzcG9uZGluZyBwYXJhbWV0ZXIgbGl2ZXMgaW4m bmJzcDtvYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzDQogb3IgZWxzZXdoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzYWlkLiBSZWFk aW5nIHRocm91Z2ggdGhlIGRyYWZ0LCBpdCB3b3VsZCBhcHBlYXIgdGhhdCBtb3N0IG9mIHRoZSBy ZWFzb25zIGZvciB3aGljaCB0aGUgc3BlYyB3YXMgY3JlYXRlZCBhcHBseSB0byBib3RoIHRoZSBu ZXR3b3JrIGFkZHJlc3NhYmxlIGFuZCB0aGUgbG9naWNhbCByZXNvdXJjZSB0eXBlczoga25vd2lu ZyB3aGF0IGtleXMgdG8gdXNlIHRvIGVuY3J5cHQgdGhlIHRva2VuLCBjb25zdHJhaW4NCiBhY2Nl c3MgdG9rZW5zIHRvIHRoZSBpbnRlbmRlZCBhdWRpZW5jZSwgYXZvaWRpbmcgb3ZlcmxvYWRpbmcg c2NvcGVzIHdpdGggcmVzb3VyY2UgaW5kaWNhdGluZyBwYXJ0cy4uLiB0aG9zZSBhbGwgYXBwbHkg dG8gbmV0d29yayBhZGRyZXNzYWJsZSBhbmQgbG9naWMgaWRlbnRpZmllcnMgYWxpa2UuIEFuZCBi b3RoIHBhcmFtZXRlcnMgYXJlIGV4cGVjdGVkIHRvIHJlc3VsdCBpbiBhdWRpZW5jZSByZXN0cmlj dGVkIHRva2Vucy4gSXQgc2VlbXMgdGhlDQogb25seSBkaWZmZXJlbmNlIGNvbWVzIGF0IHRva2Vu IHVzYWdlIHRpbWUsIHdpdGggdGhlIG5ldHdvcmsgYWRkcmVzc2FibGUgY2FzZSBnaXZpbmcgbW9y ZSBndWFyYW50ZWVzIHRoYXQgdGhlIHRva2VuIHdpbGwgZ28gdG8gaXRzIGludGVuZGVkIHJlY2lw aWVudCwgYnV0IHRoZSByZXF1ZXN0IGFuZCBhdWRpZW5jZSByZXN0cmljdGlvbiBzeW50YXggc2Vl bXMgdG8gYmUgZXhhY3RseSB0aGUgc2FtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRvcCBvZiB0aGlzOiBpbiB0aGUgOTkuOTk5 JSBvZiB0aGUgc2NlbmFyaW9zIEkgZW5jb3VudGVyZWQgaW4gdGhlIHdpbGQgaW4gdGhlIGxhc3Qg NSB5ZWFycyBvZiB1c2luZyB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGluIHRoZSBNUyBlY29zeXN0 ZW0sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIHdhcyBrbm93biBhdCBkZXNpZ24gdGltZTogdGhl IGRldmVsb3BlciBkaXNjb3ZlcmVkIGl0IG91dCBvZiBiYW5kDQogYW5kIHBsYWNlZCBpdCBpbiB0 aGUgYXBwIGNvbmZpZyBhdCBkZXBsb3ltZW50IHRpbWUuIFRob3NlIGFyZW4ndCBmcmluZ2UgY2Fz ZXMgSSBvY2Nhc2lvbmFsbHkgZW5jb3VudGVyZWQ6IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4g QXp1cmUgQUQgdjEgYW5kIEFERlMgd2FzIG1hbmRhdG9yeSwgaGVuY2UgbGl0ZXJhbGx5IGV2ZXJ5 IHNvbHV0aW9uIGkgc2F3IG9yIHRvdWNoZWQgdXNlZCBpdC4gQXMgQnJpYW4gc3VnZ2VzdGVkLCB0 aGlzIGlzIGEgc2NlbmFyaW8NCiB3aGVyZSB0aGUgc2VjdXJpdHkgYWR2YW50YWdlcyBvZiB0aGUg bmV0d29yayBhZGRyZXNzYWJsZSBjYXNlIGFyZW4ndCBhcyBwcm9ub3VuY2VkIGFzIGluIHRoZSBj YXNlIGluIHdoaWNoIHRoZSBjbGllbnQgZGlzY292ZXJzIHRoZSByZXNvdXJjZSBpZGVudGlmaWVy IGF0IHJ1bnRpbWUuIFRoaXMgaXNuJ3QganVzdCBiZWNhdXNlIHRoZXJlIGlzIG5vIHNwZWNpZmlj YXRpb24gc3VnZ2VzdGluZyBsb2NhdGlvbiBzaG91bGQgYmUgZXhwbGljaXRseSBpbmRpY2F0ZWQs DQogaXQncyBiZWNhdXNlIHRoZXJlIGFyZSBtYW55IHByYWN0aWNhbCBhZHZhbnRhZ2VzIGF0IGRl dmVsb3BtZW50IGFuZCBkZXBsb3ltZW50IHRpbWUgdG8gYmUgYWJsZSB0byB1c2UgbG9naWNhbCBp ZGVudGlmaWVycy0gYW5kIGlmIHRoZQ0KPGk+Y29uY3JldGUgPC9pPnNlY3VyaXR5IGFkdmFudGFn ZXMgZG9uJ3QgYXBwbHkgdG8gdGhlIHRoZWlyIGNhc2UsIHBlb3BsZSB3aWxsIHNpbXBseSBub3Qg Y29tcGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBzdW1tYXJ5OiBjcmVhdGluZyB0d28gZGlmZmVyZW50IHBhcmFtZXRlcnMg aW4gdHdvIGRpZmZlcmVudCBkb2N1bWVudHMgaXMgYmV0dGVyIHRoYW4gaWdub3JpbmcgaGUgbG9n aWNhbCBpZGVudGlmaWVyIGNhc2UgYWx0b2dldGhlciwgaG93ZXZlciBJIHRoaW5rIHRoYXQgbm90 IGFja25vd2xlZGdpbmcgdGhlIGxvZ2ljYWwgaWQgY2FzZSBpbiZuYnNwO29hdXRoLXJlc291cmNl LWluZGljYXRvcnMgaXMgZ29pbmcgdG8NCiBjcmVhdGUgY29uZnVzaW9uIGFuZCB1bHRpbWF0ZWx5 IG5vdCBiZSBhcyB1c2VmdWwgdG8gdGhlIGRldmVsb3BlciBjb21tdW5pdHkgYXMgaXQgY291bGQg YmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgSmFuIDE5LCAyMDE5IGF0IDEyOjM4 IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiYjNDM7MSB0byBNaWtlIGFuZCBKb2hu4oCZcyBj b21tZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEphbiAxOSwgMjAxOSwgYXQg MTI6MzQgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u ZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFsc28gYWdyZWUgdGhhdCDigJxyZXNvdXJjZeKA nSBzaG91bGQgYmUgYSBzcGVjaWZpYyBuZXR3b3JrLWFkZHJlc3NhYmxlIFVSTCB3aGVyZWFzIGEg c2VwYXJhdGUgYXVkaWVuY2UgcGFyYW1ldGVyIChsaWtlIOKAnGF1ZOKAnSBpbiBKV1RzKSBjYW4g cmVmZXIgdG8gb25lDQogb3IgbW9yZSBsb2dpY2FsIHJlc291cmNlcy4mbmJzcDsgVGhleSBhcmUg ZGlmZmVyZW50LCBpZiByZWxhdGVkLCB0aGluZ3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Tm90ZSB0aGF0IHRoZSBBQ0UgV0cgaXMgcHJvcG9zaW5nIHRvIHJlZ2lz dGVyIGEgbG9naWNhbCBhdWRpZW5jZSBwYXJhbWV0ZXIg4oCccmVxX2F1ZOKAnSBpbg0KPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFt cy0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wMTwvYT4gLSBwYXJ0bHkgYmFzZWQgb24gZmVlZGJhY2sg ZnJvbSBPQXV0aCBXRyBtZW1iZXJzLiZuYnNwOyBUaGlzIGlzIGEgZ2VuZXJhbCBPQXV0aCBwYXJh bWV0ZXIsIHdoaWNoIGFueSBPQXV0aCBkZXBsb3ltZW50IHdpbGwgYmUgYWJsZSB0byB1c2UuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSB0aGVyZWZvcmUgYmVsaWV2 ZSB0aGF0IG5vIGNoYW5nZXMgYXJlIG5lZWRlZCB0byBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNl LWluZGljYXRvcnMsIGFzIHRoZSBsb2dpY2FsIGF1ZGllbmNlIHdvcmsgaXMgYWxyZWFkeSBoYXBw ZW5pbmcgaW4gYW5vdGhlcg0KIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJh ZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSmFudWFyeSAxOSwgMjAxOSA5OjAxIEFN PGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVml0dG9yaW8gQmVydG9jY2kgJmx0Ozxh IGhyZWY9Im1haWx0bzpWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPlZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs7IElF VEYgb2F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG5lZWQg dG8gZGVjaWRlIGlmIHdlIHdhbnQgdG8gbWFrZSBhIGNoYW5nZS4mbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3Igc2VjdXJpdHkg d2UgYXJlIGxvY2F0aW9uIGNlbnRyaWMuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHByZWZlciB0byBrZWVwIHJl c291cmNlIGxvY2F0aW9uIHNlcGFyYXRlIGZyb20gbG9naWNhbCBhdWRpZW5jZSB0aGF0IGNhbiBi ZSBhIHNjb3BlIG9yIG90aGVyIHBhcmFtZXRlci4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIGJlY29tZXMgaGFy ZGVyIGZvciBwZW9wbGUgdG8gdXNlIHRoZSBwYXJhbWV0ZXIgY29ycmVjdGx5IGlmIHdlIGFyZSB0 b28gZmxleGlibGUuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIHJhdGhlciBoYXZlIGEgc2VwYXJhdGUg bG9naWNhbCBhdWRpZW5jZSBwYXJhbWV0ZXIgaWYgd2UgdGhpbmsgd2Ugd2FudCBvbmUuJm5ic3A7 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Kb2huIEIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTYXQsIEphbiAxOSwgMjAxOSwgMTE6NDEgQU0gQnJp YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBj dXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Tm8gYXBvbG9neSBuZWVkZWQsIFJpZmFhdC4gQW5kIEkgYXBvbG9naXplIGlm IHdoYXQgSSBzYWlkIGNhbWUgb2ZmIHRoZSB3cm9uZyB3YXkuIEkgd2FzIGp1c3QgdHJ5aW5nIHRv IG1ha2UgbGlnaHQgb2YgdGhlIHNpdHVhdGlvbi4uIEFuZCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxk IG5vdCBiZSBoYW1zdHJ1bmcNCiBieSB0aGUgcHJvY2VzcyBhbmQgdGhlcmUgYXJlIHRpbWVzIHdo ZW4gaXQgbWFrZXMgc2Vuc2UgdG8gYmUgZmxleGlibGUgd2l0aCB0aGluZ3MuDQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwg SmFuIDE4LCAyMDE5IGF0IDY6MjIgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJt YWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29ycnkgQnJpYW4sIEkgd2FzIG5vdCBjbGVhciB3aXRo IG15IHN0YXRlbWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBtZWFudCB0byBzYXkgdGhhdCB3ZSBzaG91bGQgbm90IGFsbG93 IHRoZSBwcm9jZXNzIHRvIHByZXZlbnQgdGhlIFdHIGZyb20gcHJvZHVjaW5nIGEgcXVhbGl0eSBk b2N1bWVudCB3aXRob3V0IGlzc3VlcywgYXNzdW1pbmcgdGhlcmUgaXMgYW4gaXNzdWUgaW4gdGhl IGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JZGVhbGx5IHdlIHdhbnQgdG8gZ2V0IHRoZXNlIGlkZW50aWZpZWQgZHVyaW5n IHRoZSBXR0xDLCBidXQgdGhpbmdzIGhhcHBlbiBhbmQgc29tZXRpbWVzIHRoZSBXRyBtaXNzZXMg c29tZXRoaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBoZWFyIHlvdSBhbmQgYWdyZWUgdGhhdCB0aGlzIG1ha2UgdGhp bmdzIGRpZmZpY3VsdCBmb3IgYXV0aG9ycy4gV2Ugd2lsbCBtYWtlIHN1cmUgdGhhdCB0aGlzIGRv ZXMgbm90IGJlY29tZSB0aGUgbm9ybSwgYW5kIHdlIHdpbGwgdHJ5IHRvIHN0aWNrIHRvIHRoZSBw cm9jZXNzIGFzIG11Y2ggYXMgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNTozNSBQTSBCcmlhbiBDYW1wYmVs bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50 Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIFJpZmFhdC4gUHJvY2VzcyBpcyBhcyBwcm9jZXNzIGRvZXMsIHJpZ2h0PyBJ IGRvIGtpbmRhIHdhbnQgdG8gZ3J1bWJsZSBhYm91dCBXR0NMIGhhdmluZyBwYXNzZWQgYWxyZWFk eSBidXQgdGhhdCdzIG1vc3RseSBiZWNhdXNlIHJlcGx5aW5nIHRvIHRoZXNlIGtpbmRzIG9mIHRo cmVhZHMgaXMgaGFyZA0KIGZvciBtZSBhbmQgSSdsbCBqdXN0IGdldCBvdmVyIGl0Li4uIDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGluZ3MsIHRoZSBzZWN1cml0eSBjb25jZXJucyBjb21lIGlu dG8gcGxheSB3aGVuIHRoZSBjbGllbnQgaXMgYmVpbmcgdG9sZCB0aGUgYnkgdGhlIHJlc291cmNl IGhvdyB0byBpZGVudGl0eSB0aGUgcmVzb3VyY2UgbGlrZSBpcyBkZXNjcmliZWQgaW4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc3RyaWJ1 dGVkLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1kaXN0cmlidXRlZC0wMTwvYT4gYW5kIHVzaW5nIHRoZSBhY3R1YWwgbG9j YXRpb24gaW4gdGhhdCBjb250ZXh0ICxhbG9uZyB3aXRoIHNvbWUgb3RoZXIgY2hlY2tzIHByZXNj cmliZWQgaW4gdGhhdCBkcmFmdCwgcHJldmVudHMgdGhlIGtpbmQgb2YgaXNzdWVzIEpvaG4gZGVz Y3JpYmVkIGVhcmxpZXIgaW4gdGhlIHRocmVhZC4NCjxicj4NCjxicj4NCkluIGNhc2VzIHdoZXJl IHRoZSBjbGllbnQga25vd3MgdGhlIHJlc291cmNlIGEgcHJpb3JpIG9yIG91dC1vZi1iYW5kIG9y IGNvbmZpZ3VyZWQgb3Igd2hhdGV2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIHNhbWUgc2VjdXJpdHkg Y29uY2VybnMgYXJpc2UuIEFuZCB1c2luZyBzdWNoIGEga25vd24gdmFsdWUsIGJlIGl0IGFuIGFj dHVhbCBsb2NhdGlvbiBvciBsb2dpY2FsIHJlcHJlc2VudGF0aW9uLCB3b3VsZCBiZSBva2F5Ljxi cj4NCjxicj4NClRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIGRyYWZ0IGlzIGFkbWl0dGVkbHkgc29t ZXdoYXQgbG9jYXRpb24tY2VudHJpYyBpbiBob3cgaXQgdGFsa3MgYWJvdXQgdGhlIHZhbHVlIG9m IHRoZSAncmVzb3VyY2UnIHBhcmFtZXRlci4gQnV0IHVsdGltYXRlbHkgaXQgZGVmaW5lcyBpdCBh cyBhbiBhYnNvbHV0ZSBVUkkgdGhhdCBpbmRpY2F0ZXMgdGhlIGxvY2F0aW9uIG9mIHRoZSB0YXJn ZXQgc2VydmljZSBvciByZXNvdXJjZSB3aGVyZSBhY2Nlc3MgaXMNCiBiZWluZyByZXF1ZXN0ZWQu IEEgbG9jYXRpb24gY2FuIGJlIHZhcnlpbmcgc2hhZGVzIG9mIGFic3RyYWN0IGFuZCBJJ2Qgc2F5 IHRoYXQgdXNpbmcgYSBVUkkgYXMgJ3Jlc291cmNlJyBwYXJhbWV0ZXIgdmFsdWUgdGhhdCdzIGEg bG9naWNhbCBpZGVudGlmaWVyIHRoYXQgcG9pbnRzIHRvIHNvbWUgcmVzb3VyY2UgaXMgd2VsbCB3 aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgZHJhZnQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIG1heWJlIHRoZSBkcmFmdCBpcyBv a2F5IGFzIGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T3IgcGVyaGFwcyB0aGF0J3MgdG9vIG11Y2ggdG8gYmUgbGVmdCBhcyBhbiBl eGVyY2lzZXIgdG8gdGhlIHJlYWRlcj8mbmJzcDsgQW5kIHNvbWUgdGV4dCBzaG91bGQgYmUgYWRk ZWQgYW5kL29yIGFkanVzdGVkIHNvIHRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIGRyYWZ0IHdvdWxk IGJlIGEgbGl0dGxlIG1vcmUgb3Blbi9jbGVhcg0KIGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFsdWUg cG90ZW50aWFsbHkgYmVpbmcgbW9yZSBvZiBhIGxvZ2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmll ciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkw/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDE6MTggUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8 YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlm YWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVy LWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0 LDIwNCkiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3b3VsZG4ndCB3b3JyeSB0 b28gbXVjaCBhYm91dCB0aGUgcHJvY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklmIGl0IG1ha2VzIHNlbnNlIHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQs IHRoZW4gZmVlbCBmcmVlIHRvIGRvIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBG cmksIEphbiAxOCwgMjAxOSBhdCAzOjA4IFBNIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzIHRoZSZuYnNwO2xvZ2ljYWwgcmVzb3VyY2Ug Y2FuIGJlIHByb3ZpZGVkIGJ5ICZxdW90O3Njb3BlJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb21lIGltcGxlbWVudGF0aW9u cyBsaWtlIFBpbmcgYW5kIEF1dGgwIGhhdmUgYmVlbiBhZGRpbmcgYW5vdGhlciBwYXJhbWV0ZXIg JnF1b3Q7YXVkJnF1b3Q7IHRvIGlkZW50aWZ5IHRoZSBsb2dpY2FsIHJlc291cmNlIGFuZCB0aGVu IHVzaW5nIHNjb3BlcyB0byBkZWZpbmUgcGVybWlzc2lvbnMgdG8gdGhlIHJlc291cmNlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9y dHVuYXRlbHksIHdlIGFyZSB1c2luZyBhIGRpZmZlcmVudCZuYnNwO3BhcmFtZXRlciBuYW1lIHNv IG5vdCBzdGVwcGluZyBvbiB0aGF0Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGNvdWxkIGdvIGJhY2sgYW5kIHRyeSB0byBhZGQg dGV4dCBleHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlLCBidXQgd2UgYXJlIHF1aXRlIGxhdGUgaW4g dGhlIHByb2Nlc3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVlIHRoYXQgYSBsb2dpY2FsIHJlc291cmNlIHBhcmFt ZXRlciZuYnNwO21heSBiZSBoZWxwZnVsLCBidXQgcGVyaGFwcyBpdCBzaG91bGQgYmUgYSBzZXBh cmF0ZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBGcmksIEphbiAxOCwgMjAxOSBhdCA0OjM4IFBNIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50 Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+RG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRl IGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3Ii Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBvbiBiZWhhbGYgb2YgVml0dG9yaW8gQmVydG9jY2kgJmx0O1ZpdHRvcmlvPTxhIGhyZWY9Im1h aWx0bzo0MGF1dGgwLi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1dGgw LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSmFu dWFyeSAxOCwgMjAxOSBhdCA1OjQ3IEFNPGJyPg0KPGI+VG86IDwvYj5Kb2huIEJyYWRsZXkgJmx0 OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0 YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPklFVEYgb2F1dGggV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gU2hlcGhlcmQg d3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoYW5rcyBKb2huIGZvciB0aGUgYmFja2dyb3VuZC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB0aGF0IGZyb20gdGhlIGNsaWVudCB2 YWxpZGF0aW9uIFBvViwgaGF2aW5nIGFuIGlkZW50aWZpZXIgY29ycmVzcG9uZGluZyB0byBhIGxv Y2F0aW9uIG1ha2VzIHRoaW5ncyBtb3JlIHNvbGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IHNhaWQ6IHRoZSB1c2Ugb2YgbG9naWNh bCBpZGVudGlmaWVycyBpcyB3aWRlc3ByZWFkLCBhcyBpdCBoYXMgc2lnbmlmaWNhbnQgcHJhY3Rp Y2FsIGFkdmFudGFnZXMgKHRoaW5rIG9mIHNlcnZpY2VzIHRoYXQgYXNzaWduIGdlbmVyYXRlZCBo b3N0aW5nIFVSTHMgb25seSBhdCBkZXBsb3ltZW50IHRpbWUsDQogb3Igc2VydmljZXMgdGhhdCBh cmUgc29tZWhvdyBncm91cGVkIHVuZGVyIHRoZSBzYW1lIGxvZ2ljYWwgYXVkaWVuY2UgYWNyb3Nz IHJlZ2lvbnMvZW52aXJvbm1lbnQvZGVwbG95bWVudHMpLiBQZW9wbGUgd29uJ3Qgc3RvcCB1c2lu ZyBsb2dpY2FsIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBubyBhbHRlcm5h dGl2ZSAoZ2VuZXJhdGluZyBuZXcgYXVkaWVuY2VzIG9uIHRoZSBmbHkgYXQgdGhlIEFTIGV2ZXJ5 IHRpbWUgeW91DQogZG8gYSBkZXBsb3ltZW50IGFuZCBnZXQgYXNzaWduZWQgYSBuZXcgVVJMIGNh biBiZSB1bmZlYXNpYmxlKS4gTGVhdmluZyBhIHdpZGVseSB1c2VkIGFwcHJvYWNoIGFzIGV4ZXJj aXNlIHRvIHRoZSByZWFkZXIgc2VlbXMgYSBkaXNzZXJ2aWNlIHRvIHRoZSBjb21tdW5pdHksIGdp dmVuIHRoYXQgdGhpcyBtaWdodCBsZWFkIHRvIHZlbmRvcnMgKGZvciBleGFtcGxlIE1pY3Jvc29m dCBhbmQgQXV0aDApIGtlZXBpbmcgdGhlaXIgb3duIHByb3ByaWV0YXJ5DQogcGFyYW1ldGVycywg b3IgZGV2ZWxvcGVycyBtaXN1c2luZyB0aGUgb25lcyBpbiBwbGFjZTsgd291bGQgbWFrZSBpdCBo YXJkIGZvciBTREsgZGV2ZWxvcGVycyB0byBwcm92aWRlIGxpYnJhcmllcyB0aGF0IHdvcmsgb3V0 IG9mIHRoZSBib3ggd2l0aCBkaWZmZXJlbnQgQVNlczsgYW5kIHNvIG9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Xb3VsZCBpdCBiZSBmZWFz aWJsZSB0byBhZGQgc3VjaCBwYXJhbWV0ZXIgZGlyZWN0bHkgaW4gdGhpcyBzcGVjPyBUaGF0IHdv dWxkIGVsaW1pbmF0ZSB0aGUgaW50ZXJvcCBpc3N1ZXMsIGFuZCBhbHNvIGdpdmVzIHVzIGEgY2hh bmNlIHRvIGZ1bGx5IHdhcm4gcGVvcGxlIGFib3V0IHRoZSBzZWN1cml0eSBzaG9ydGNvbWluZ3MN CiBvZiBjaG9vc2luZyB0aGF0IGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEphbiAxNywgMjAx OSBhdCA0OjMyIFBNIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdq dGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+V2UgaGF2ZSBkaXNjdXNzZWQgdGhp cy48bzpwPjwvbzpwPjwvcD4NCjxwPkF1ZGllbmNlcyBjYW4gY2VydGFpbmx5IGJlIGxvZ2ljYWwg aWRlbnRpZmllcnMuJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBob3dldmVy IGlzIGEgbW9yZSBzcGVjaWZpYyBsb2NhdGlvbi4mbmJzcDsgVGhlIEFTIGlzIGZyZWUgdG8gbWFw IHRoZSBsb2NhdGlvbiBpbnRvIHNvbWUgYWJzdHJhY3QgYXVkaWVuY2UgaW4gdGhlIEFULjxvOnA+ PC9vOnA+PC9wPg0KPHA+RnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcgb25jZSB0aGUgY2xp ZW50IHN0YXJ0cyBhc2tpbmcgZm9yIGxvZ2ljYWwgcmVzb3VyY2VzIGl0IGNhbiBiZSB0cmlja2Vk IGludG8gYXNraW5nIGZvciB0aGUgd3Jvbmcgb25lIGFzIGEgYmFkIHJlc291cmNlIGNhbiBhbHdh eXMgbGllIGFib3V0IHdoYXQgbG9naWNhbCByZXNvdXJjZSBpdCBpcy48bzpwPjwvbzpwPjwvcD4N CjxwPklmIHdlIHdlcmUgdG8gY2hhbmdlIGl0LCBob3cgYSBjbGllbnQgd291bGQgdmFsaWRhdGUg aXQgYmVjb21lcyBjaGFsbGVuZ2luZyB0byBpbXBvc3NpYmxlLg0KPG86cD48L286cD48L3A+DQo8 cD5UaGUgQVMgaXMgZnJlZSB0byBkbyB3aGF0ZXZlciBtYXBwaW5nIG9mIGxvY2F0aW9ucyB0byBp ZGVudGlmaWVycyBpdCBuZWVkcyBmb3IgYWNjZXNzIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjxw PlNvbWUgaW1wbGVtZW50YXRpb25zIG1heSB3YW50IHRvIGtlZXAgYWRkaXRpb25hbCBwYXJhbWV0 ZXJzIGxpa2UgbG9naWNhbCBhdWRpZW5jZSwgYnV0IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGZy b20gcmVzb3VyY2UuPG86cD48L286cD48L3A+DQo8cD5Kb2huIEIuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxLzE3LzIwMTkgOTo1NiBBTSwgUmlmYWF0 IFNoZWtoLVl1c2VmIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIFZpdHRvcmlvLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRleHQgeW91IHF1b3RlZCBpcyBjb3BpZWQg Zm9ybSB0aGUgYWJzdHJhY3Qgb2YgdGhlIGRyYWZ0IGl0c2VsZi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5BdXRob3JzLDwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlNob3VsZCB0aGUgZHJhZnQgYmUgdXBkYXRlZCB0byBjb3ZlciB0aGUgbG9naWNhbCBpZGVu dGlmaWVyIGNhc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEphbiAxNywgMjAx OSBhdCA4OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9y aW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGkgUmlmYWF0LA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5vbmUgZGV0YWlsLiBUaGUgdGVjaCBzdW1tYXJ5IHNheXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i b3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JhY2tncm91bmQtYXR0YWNobWVudDpzY3Jv bGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5BbiBleHRlbnNpb24gdG8gdGhlIE9BdXRoIDIu MCBBdXRob3JpemF0aW9uIEZyYW1ld29yayBkZWZpbmluZyByZXF1ZXN0IDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6 MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6Ymxh Y2siPnBhcmFtZXRlcnMgdGhhdCBlbmFibGUgYSBjbGllbnQgdG8gZXhwbGljaXRseSBzaWduYWwg dG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtiYWNrZ3JvdW5k LWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBv c2l0aW9uLXk6MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+YWJvdXQgdGhlIDxi PmxvY2F0aW9uPC9iPiBvZiB0aGUgcHJvdGVjdGVkIHJlc291cmNlKHMpIHRvIHdoaWNoIGl0IGlz IHJlcXVlc3RpbmcgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Ny b2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+YWNjZXNzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1dCBh dCBsZWFzdCBpbiB0aGUgTWljcm9zb2Z0IGltcGxlbWVudGF0aW9uLCB0aGUgcmVzb3VyY2UgaWRl bnRpZmllciBkb2Vzbid0DQo8aT5oYXZlPC9pPiB0byBiZSBhIG5ldHdvcmsgYWRkcmVzc2FibGUg VVJMIChhbmQgaWYgaXQgaXMsIGl0IGRvZXNuJ3Qgc3RyaWN0bHkgbmVlZCB0byBtYXRjaCB0aGUg YWN0dWFsIHJlc291cmNlIGxvY2F0aW9uKS4gSXQgY2FuIGJlIGEgbG9naWNhbCBpZGVudGlmaWVy LCB0aG8gdXNpbmcgdGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbiB0aGVyZSBoYXMgYmVuZWZp dHMgKGRvbWFpbiBvd25lcnNoaXAgY2hlY2ssIHByZXZlbnRpb24gb2YgdG9rZW4NCiBmb3J3YXJk aW5nIGV0YykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlNhbWUgZm9yIEF1dGgwLCB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGlzIGEgbG9naWNh bCBpZGVudGlmaWVyIHJhdGhlciB0aGFuIGEgbG9jYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgSmFu IDE2LCAyMDE5IGF0IDY6MzIgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWls dG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGwsDQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZm9sbG93aW5nIGlzIHRoZSBm aXJzdCBzaGVwaGVyZCB3cml0ZS11cCBmb3IgdGhlJm5ic3A7ZHJhZnQtaWV0Zi1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3JzLTAxIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvc2hlcGhlcmR3 cml0ZXVwLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAvPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+UGxlYXNlLCB0YWtlIGEgbG9vayBhbmQgbGV0Jm5ic3A7bWUga25vdyBpZiBJIG1pc3NlZCBh bnl0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcs IHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp bg0KIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWls IGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91 ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQo8Yj48aT5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNw OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24NCiBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_MW2PR00MB030099E717A31D46BCAA4F9AF5980MW2PR00MB0300namp_-- From nobody Wed Jan 23 08:45:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6906130E9E for ; Wed, 23 Jan 2019 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEyMzoLZT_Je for ; Wed, 23 Jan 2019 08:44:58 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E6212E043 for ; Wed, 23 Jan 2019 08:44:58 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id n18-v6so2528934lji.7 for ; Wed, 23 Jan 2019 08:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RKRI91B4u53PQIQAJYjWnTL6QjbWudAG/6dklm3UKc8=; b=CZ5NsSwBbIOwKRbneNTXRAXGfPg+6zNW2r680XZsv+oJp7PF1baA5QxN1uj0e6T92w 8MzMuvVK1Cs9T0MM1XGmEDncunvHFTsPyeuWqcusAasn5U6KiAjIPPvs0kjIZnp43VK7 Jo31ImPqYWydDDvbQtIVyDegIyc12pFNLU4H96ZpvrL+ePaDyEG1nzA81yq9zXw/I+1B tNMdcBFXpwAb1l6ils04E5J1h8Z19fv+XHLuKUoW/3FNmeuD4yuXlLunJrfzzieWtOkS gvtY2GqYaGSHcX4WoUxijwfNvxhwvOdFtv9ZTMsSYBX1kh6ZH491cuWGNDMdXG19eiEh mpDw== 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=RKRI91B4u53PQIQAJYjWnTL6QjbWudAG/6dklm3UKc8=; b=Fq3K5qfZOSqb/1DDVk1DFY65jU4TkW8loEapgNZW9YMhy+bziJB0ndaPFCbdyWKaRR PL62IRR5L/ShQaTyc3/U8BbyBz+EnfGnley5vJIpVf2xzOtJuUWH5j+PqBBcNRnMVmFF KOdiEX1cpJJ+PvqkPpSzR1Q685pjys6qH7JxwsMdnAqf25GMyFRQNoNtwslahi0HUmdp TQJA4hhhGGktq8ZD09CaJKQfXL0W7f04Qjk6U3udX0UXmVEjpMu2IAVQzSCvaXqUyV4V jpJz9lpKfl6aF9CIPhPmqBewv9ivw9yl+AH7ub7X103tJm5bG99Lk6soa/gDqiHGq/w4 yQHw== X-Gm-Message-State: AJcUukcj2X+ElqaJP+Mhr34IyWGqCXQ1ea5rgkM0wWP5upVGgKlZA2LO Fg69M+70M5jol7LncvgNOB23orNKfZzb6kYDKH0bPQ== X-Google-Smtp-Source: ALg8bN5mNAOXDmulOpdmkOYIqLeacToCfVDvArcUmN7zaPqY7LFw8IVeBq06qao6xR++QB4PpQUYaPhwmR7zlWO4Sg4= X-Received: by 2002:a2e:8187:: with SMTP id e7-v6mr2533981ljg.67.1548261895601; Wed, 23 Jan 2019 08:44:55 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Wed, 23 Jan 2019 08:44:43 -0800 Message-ID: To: Rifaat Shekh-Yusef Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000004e9c16058022d094" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 16:45:04 -0000 --0000000000004e9c16058022d094 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indic= ators.xml, see the commits in the history from January 21 for the specific changes. Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week. On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef wrote: > Thank you guys! > > > On Monday, January 21, 2019, Vittorio Bertocci wrote= : > >> Hi Rifaat, >> absolutely. Brian and myself already started working on some language, >> however this week he is in vacation hence it might take few days before = we >> come back to the list with something. >> Cheers, >> V. >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> wrote: >> >>> Brian, Vittorio, >>> >>> To move this discussion forward, can you guys suggest some text to make >>> the logical identifier usage clearer? >>> >>> Regards, >>> Rifaat >>> >>> >>> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>>> As I suggested before, I do think that's within the bounds of the >>>> draft's definition of 'resource' as a URI. And that perhaps all that's >>>> needed is some minor adjustment and/or augmentation of some text to ma= ke it >>>> more clear. >>>> >>>> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >>>> wrote: >>>> >>>>> [sent to John only by mistake, resending to the ML] >>>>> >>>>> In Azure AD v1 & ADFS, that's resource. It could be used for both >>>>> network and logical ids, with the concrete usage in the wild I descri= bed >>>>> earlier. >>>>> In Azure AD v2, the resource as explicit parameter (network, logic or >>>>> otherwise) is gone and is expressed as part of the scope string of al= l the >>>>> scopes requested for a given resource- but it still exist in practice= tho >>>>> as it still end up in the resulting aud of the issued token. >>>>> This is 9 months old info hence >>>>> >>>>> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >>>>> >>>>>> What is the parameter that Microsoft is using? >>>>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >>>>>> >>>>>> First of all, it wasn't my intent to disrupt the established process= . >>>>>> In my former position I wasn't monitoring those discussions hence I = didn't >>>>>> have a chance to offer feedback. When I saw something that gave me t= he >>>>>> impression might lead to issues, and given that I worked with actual >>>>>> deployments and developers using a similar parameter for a long time= , I >>>>>> thought prudent to bring this up. I really appreciate Rifaat's stanc= e on >>>>>> this. End of preamble. >>>>>> >>>>>> Ultimately my goal is for developers to have guidance on how to work >>>>>> with the concept of logical resource in a standard compliant way, he= nce it >>>>>> doesn't strictly matter whether the definition of the corresponding >>>>>> parameter lives in oauth-resource-indicators or elsewhere. >>>>>> That said. Reading through the draft, it would appear that most of >>>>>> the reasons for which the spec was created apply to both the network >>>>>> addressable and the logical resource types: knowing what keys to use= to >>>>>> encrypt the token, constrain access tokens to the intended audience, >>>>>> avoiding overloading scopes with resource indicating parts... those = all >>>>>> apply to network addressable and logic identifiers alike. And both >>>>>> parameters are expected to result in audience restricted tokens. It = seems >>>>>> the only difference comes at token usage time, with the network addr= essable >>>>>> case giving more guarantees that the token will go to its intended >>>>>> recipient, but the request and audience restriction syntax seems to = be >>>>>> exactly the same. >>>>>> On top of this: in the 99.999% of the scenarios I encountered in the >>>>>> wild in the last 5 years of using the resource parameter in the MS >>>>>> ecosystem, the resource identifier was known at design time: the dev= eloper >>>>>> discovered it out of band and placed it in the app config at deploym= ent >>>>>> time. Those aren't fringe cases I occasionally encountered: the reso= urce >>>>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally eve= ry >>>>>> solution i saw or touched used it. As Brian suggested, this is a sce= nario >>>>>> where the security advantages of the network addressable case aren't= as >>>>>> pronounced as in the case in which the client discovers the resource >>>>>> identifier at runtime. This isn't just because there is no specifica= tion >>>>>> suggesting location should be explicitly indicated, it's because the= re are >>>>>> many practical advantages at development and deployment time to be a= ble to >>>>>> use logical identifiers- and if the *concrete *security advantages >>>>>> don't apply to the their case, people will simply not comply. >>>>>> >>>>>> In summary: creating two different parameters in two different >>>>>> documents is better than ignoring he logical identifier case altoget= her, >>>>>> however I think that not acknowledging the logical id case >>>>>> in oauth-resource-indicators is going to create confusion and ultima= tely >>>>>> not be as useful to the developer community as it could be. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote= : >>>>>> >>>>>>> +1 to Mike and John=E2=80=99s comments. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < >>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific >>>>>>> network-addressable URL whereas a separate audience parameter (like= =E2=80=9Caud=E2=80=9D >>>>>>> in JWTs) can refer to one or more logical resources. They are diff= erent, >>>>>>> if related, things. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that the ACE WG is proposing to register a logical audience >>>>>>> parameter =E2=80=9Creq_aud=E2=80=9D in >>>>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >>>>>>> based on feedback from OAuth WG members. This is a general OAuth >>>>>>> parameter, which any OAuth deployment will be able to use. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I therefore believe that no changes are needed to >>>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work = is >>>>>>> already happening in another draft. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* OAuth *On Behalf Of * John Bradley >>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM >>>>>>> *To:* Brian Campbell >>>>>>> *Cc:* Vittorio Bertocci ; IE= TF >>>>>>> oauth WG >>>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >>>>>>> draft-ietf-oauth-resource-indicators-01 >>>>>>> >>>>>>> >>>>>>> >>>>>>> We need to decide if we want to make a change. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For security we are location centric. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I prefer to keep resource location separate from logical audience >>>>>>> that can be a scope or other parameter. >>>>>>> >>>>>>> >>>>>>> >>>>>>> If becomes harder for people to use the parameter correctly if we >>>>>>> are too flexible. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would rather have a separate logical audience parameter if we >>>>>>> think we want one. >>>>>>> >>>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >>>>>>> bcampbell@pingidentity.com wrote: >>>>>>> >>>>>>> No apology needed, Rifaat. And I apologize if what I said came off >>>>>>> the wrong way. I was just trying to make light of the situation.. A= nd I >>>>>>> agree that we should not be hamstrung by the process and there are = times >>>>>>> when it makes sense to be flexible with things. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >>>>>>> rifaat.ietf@gmail.com> wrote: >>>>>>> >>>>>>> Sorry Brian, I was not clear with my statement. >>>>>>> >>>>>>> I meant to say that we should not allow the process to prevent the >>>>>>> WG from producing a quality document without issues, assuming there= is an >>>>>>> issue in the first place. >>>>>>> >>>>>>> Ideally we want to get these identified during the WGLC, but things >>>>>>> happen and sometimes the WG misses something. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I hear you and agree that this make things difficult for authors. W= e >>>>>>> will make sure that this does not become the norm, and we will try = to stick >>>>>>> to the process as much as possible. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rifaat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>> >>>>>>> Thanks Rifaat. Process is as process does, right? I do kinda want t= o >>>>>>> grumble about WGCL having passed already but that's mostly because = replying >>>>>>> to these kinds of threads is hard for me and I'll just get over it.= .. >>>>>>> >>>>>>> >>>>>>> >>>>>>> As far as I understand things, the security concerns come into play >>>>>>> when the client is being told the by the resource how to identity t= he >>>>>>> resource like is described in >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and >>>>>>> using the actual location in that context ,along with some other ch= ecks >>>>>>> prescribed in that draft, prevents the kind of issues John describe= d >>>>>>> earlier in the thread. >>>>>>> >>>>>>> In cases where the client knows the resource a priori or out-of-ban= d >>>>>>> or configured or whatever, I don't think the same security concerns= arise. >>>>>>> And using such a known value, be it an actual location or logical >>>>>>> representation, would be okay. >>>>>>> >>>>>>> The resource-indicators draft is admittedly somewhat >>>>>>> location-centric in how it talks about the value of the 'resource' >>>>>>> parameter. But ultimately it defines it as an absolute URI that ind= icates >>>>>>> the location of the target service or resource where access is bein= g >>>>>>> requested. A location can be varying shades of abstract and I'd say= that >>>>>>> using a URI as 'resource' parameter value that's a logical identifi= er that >>>>>>> points to some resource is well within the bounds of the draft. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So maybe the draft is okay as is? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Or perhaps that's too much to be left as an exerciser to the >>>>>>> reader? And some text should be added and/or adjusted so the >>>>>>> resource-indicators draft would be a little more open/clear about t= he >>>>>>> parameter value potentially being more of a logical or abstract ide= ntifier >>>>>>> and not necessarily a network addressable URL? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >>>>>>> rifaat.ietf@gmail.com> wrote: >>>>>>> >>>>>>> I wouldn't worry too much about the process. >>>>>>> >>>>>>> If it makes sense to update the document, then feel free to do that= . >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rifaat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley >>>>>>> wrote: >>>>>>> >>>>>>> Yes the logical resource can be provided by "scope" >>>>>>> >>>>>>> >>>>>>> >>>>>>> Some implementations like Ping and Auth0 have been adding another >>>>>>> parameter "aud" to identify the logical resource and then using sco= pes to >>>>>>> define permissions to the resource. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fortunately, we are using a different parameter name so not steppin= g >>>>>>> on that.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We could go back and try to add text explaining the difference, but >>>>>>> we are quite late in the process. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that a logical resource parameter may be helpful, but >>>>>>> perhaps it should be a separate draft. >>>>>>> >>>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >>>>>>> richanna@amazon.com> wrote: >>>>>>> >>>>>>> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provi= de a means of specifying >>>>>>> a logical identifier? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Annabelle Richard Backman >>>>>>> >>>>>>> AWS Identity >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From: *OAuth on behalf of Vittorio >>>>>>> Bertocci >>>>>> <40auth0..com@dmarc.ietf.org>> >>>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>>>> *To: *John Bradley >>>>>>> *Cc: *IETF oauth WG >>>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >>>>>>> draft-ietf-oauth-resource-indicators-01 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks John for the background. >>>>>>> >>>>>>> I agree that from the client validation PoV, having an identifier >>>>>>> corresponding to a location makes things more solid. >>>>>>> >>>>>>> That said: the use of logical identifiers is widespread, as it has >>>>>>> significant practical advantages (think of services that assign gen= erated >>>>>>> hosting URLs only at deployment time, or services that are somehow = grouped >>>>>>> under the same logical audience across regions/environment/deployme= nts). >>>>>>> People won't stop using logical identifiers, because they often hav= e no >>>>>>> alternative (generating new audiences on the fly at the AS every ti= me you >>>>>>> do a deployment and get assigned a new URL can be unfeasible). Leav= ing a >>>>>>> widely used approach as exercise to the reader seems a disservice t= o the >>>>>>> community, given that this might lead to vendors (for example Micro= soft and >>>>>>> Auth0) keeping their own proprietary parameters, or developers misu= sing the >>>>>>> ones in place; would make it hard for SDK developers to provide lib= raries >>>>>>> that work out of the box with different ASes; and so on. >>>>>>> >>>>>>> Would it be feasible to add such parameter directly in this spec? >>>>>>> That would eliminate the interop issues, and also gives us a chance= to >>>>>>> fully warn people about the security shortcomings of choosing that = approach. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley >>>>>>> wrote: >>>>>>> >>>>>>> We have discussed this. >>>>>>> >>>>>>> Audiences can certainly be logical identifiers. >>>>>>> >>>>>>> This however is a more specific location. The AS is free to map th= e >>>>>>> location into some abstract audience in the AT. >>>>>>> >>>>>>> From a security point of view once the client starts asking for >>>>>>> logical resources it can be tricked into asking for the wrong one a= s a bad >>>>>>> resource can always lie about what logical resource it is. >>>>>>> >>>>>>> If we were to change it, how a client would validate it becomes >>>>>>> challenging to impossible. >>>>>>> >>>>>>> The AS is free to do whatever mapping of locations to identifiers i= t >>>>>>> needs for access tokens. >>>>>>> >>>>>>> Some implementations may want to keep additional parameters like >>>>>>> logical audience, but that should be separate from resource. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >>>>>>> >>>>>>> Hi Vittorio, >>>>>>> >>>>>>> >>>>>>> >>>>>>> The text you quoted is copied form the abstract of the draft itself= . >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Authors,* >>>>>>> >>>>>>> >>>>>>> >>>>>>> Should the draft be updated to cover the logical identifier case? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rifaat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci < >>>>>>> Vittorio@auth0.com> wrote: >>>>>>> >>>>>>> Hi Rifaat, >>>>>>> >>>>>>> one detail. The tech summary says >>>>>>> >>>>>>> >>>>>>> >>>>>>> An extension to the OAuth 2.0 Authorization Framework defining requ= est >>>>>>> >>>>>>> parameters that enable a client to explicitly signal to an authoriz= ation server >>>>>>> >>>>>>> about the *location* of the protected resource(s) to which it is re= questing >>>>>>> >>>>>>> access. >>>>>>> >>>>>>> But at least in the Microsoft implementation, the resource >>>>>>> identifier doesn't *have* to be a network addressable URL (and if >>>>>>> it is, it doesn't strictly need to match the actual resource locati= on). It >>>>>>> can be a logical identifier, tho using the actual resource location= there >>>>>>> has benefits (domain ownership check, prevention of token forwardin= g etc). >>>>>>> >>>>>>> Same for Auth0, the audience parameter is a logical identifier >>>>>>> rather than a location. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >>>>>>> rifaat.ietf@gmail.com> wrote: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> >>>>>>> >>>>>>> The following is the first shepherd write-up for >>>>>>> the draft-ietf-oauth-resource-indicators-01 document. >>>>>>> >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicato= rs/shepherdwriteup/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please, take a look and let me know if I missed anything. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rifaat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> OAuth mailing list >>>>>>> >>>>>>> OAuth@ietf.org >>>>>>> >>>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). = Any >>>>>>> review, use, distribution or disclosure by others is strictly prohi= bited. >>>>>>> If you have received this communication in error, please notify the= sender >>>>>>> immediately by e-mail and delete the message and any file attachmen= ts from >>>>>>> your computer. Thank you.* >>>>>>> >>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). = Any >>>>>>> review, use, distribution or disclosure by others is strictly prohi= bited.. >>>>>>> If you have received this communication in error, please notify the= sender >>>>>>> immediately by e-mail and delete the message and any file attachmen= ts from >>>>>>> your computer. Thank you.* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> --0000000000004e9c16058022d094 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
thanks for you patience. Bria= n and myself iterated on modifying the text to cover the logical identifier= use case, highlighting the security implications of going that route. You = can find the revised text in=C2=A0https://github.com/= vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see = the commits in the history from January 21 for the specific changes.
<= div>Note: I also had a chat with John offline, and he expressed the desire = to split the resource parameter in two distinct parameters to better signal= the intended usage. I am sure he can elaborate. I have nothing against it = in principle, as long as we leave nothing as exercise to the reader and we = are very clear on usage (e.g. mutual exclusivity, etc) but didn't have = a chance to speak w Brian about it. If the discussion stretches further, I = would suggest we pause it and let him enjoy his time off for the rest of th= e week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <<= a href=3D"mailto:rifaat.ietf@gmail.com">rifaat.ietf@gmail.com> wrote= :
Thank you guys= !


On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wr= ote:
= Hi Rifaat,
absolutely. Brian and myself already started working on some= language, however this week he is in vacation hence it might take few days= before we come back to the list with something.
Cheers,
V.

On Mon, Jan= 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Brian, Vi= ttorio,

To move this discussion forward, can you guys su= ggest some text to make the logical identifier usage clearer?
Regards,
=C2=A0Rifaat


<= div class=3D"gmail_quote">
On Mon, Jan 21, 2019 at 10:32 AM= Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote= :
As I suggested before, I do think that's within the bounds of the dr= aft's definition of 'resource' as a URI. And that perhaps all t= hat's needed is some minor adjustment and/or augmentation of some text = to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:<= br>
[sent to John only by mistake, resending to the ML]<= /div>

In Azure AD v1 & ADFS, that's= =C2=A0resource. It could be used for both network and logical ids, with the concrete u= sage in the wild I described earlier.
In Azure AD v2, the resour= ce as explicit parameter (network, logic or otherwise) is gone and is expre= ssed as part of the scope string of all the scopes requested for a given re= source- but it still exist in practice tho as it still end up in the result= ing=C2=A0aud=C2=A0of the issued token.
This is 9 months old info hence

On Sun, Jan = 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
=20
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2= =A0
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete securi= ty advantages don't apply to the their case, people will simply not comply.=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confusio= n and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
+1 to Mike and John=E2=80=99s comments.=C2=A0=

Phil

I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in J= WTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing to register a logical audience parameter =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 This is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>=
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c= om@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0=C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource&= #39; parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter v= alue that's a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exerciser to the reader?=C2=A0 And so= me text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat=

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope&qu= ot;

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud&q= uot; to identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunat= ely, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may be helpful= , but perhaps it should be a separate draft.

=C2=A0

John B.<= /p>

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Do= esn=E2=80=99t the =E2=80=9Cscope=E2= =80=9D parameter already provide a means of specifying a logical identifier?

= =C2=A0

= = = = =C2=A0

= =C2=A0

= From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dm= arc.ietf.org>
Date: Friday= , January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com> Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-re= source-indicators-01

= =C2=A0

= Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request =

parameters that enable a client to explicitly signal to an authorizatio=
n server 
about the location of the protected resource(s) to which it is r=
equesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

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


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


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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000004e9c16058022d094-- From nobody Wed Jan 23 09:24:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AF2130ED0 for ; Wed, 23 Jan 2019 09:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 RmBFUwfDcs1b for ; Wed, 23 Jan 2019 09:24:51 -0800 (PST) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D19B130EBF for ; Wed, 23 Jan 2019 09:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548264290; bh=gDp3ztaBfnwJ7R0g/Rpby0IxzsfG/6yhI/RvPmOwnXE=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=m8w42cVPfZbZnulia2c+DrbPe7coq51poHiJhdcfrOtp+7MnSn5DJrBOYOxUM+GG5MMarYnXEkXL2mlRkTz7zYtwI+rj2UKMabjqRzzhvkPdwzs/kAEQZqNeCJfs/7ZKoSfT8qSNS9ILiAIBagG2D/ZtMSAIf12ucxy3toXUfALMjCXvjZWFZTGOPpCkILjEdSWGTtBwO9uWu+h+ZDHv7ofukS5M7SCJoqbGRx4OO7NwYZOZs6FRTF0yFvxGA1DGfR1p9561FuNS795l6C6C5XxvDUxnnBa+Xfk50S0LQ7Pq39ybZq15JGumc0K94x/LaoayKTUk2KeSC0LjEs+PqA== X-YMail-OSG: eVjI1QIVM1nBwSJX_ixwxXomjIodS6HGL0kULqnzsuPpCLJBkbNXexlGIGUQs1k OVIyHn9PM0Rb9ISXV5fHSQcaDgQ3PrIQ0Y5EIVJyGWRdEup7u83zcbcH3Dudu1sBgf1HEYcKRMMD Q3.QjokUlu_2mxbUOSIxLKeBSQiu8S8gFuWQ9AWTsTKeqBMSv9KUlqBpxnpBONPOHf8d8Vht8rrk FttOpdV3UJm2U6tU3Nvnu9rXo0nOvnzjl0tnwhKMPVUutHxsbu72d7PyaRWXAajEy792utg8LJOp ..xWBWHaHm8QoqBMyvopuUoH43D9uaCzgdRU2yaIBwsZ9CBzXALz7aiYqa8dbMWhLUoUsCH_D6VT EZVTj51ui8C7nnaE7pgzwiBTIDt_l5mIsabRVt11xBwIdLQJpdnDfgpNO6QfcEWacZXsA.hP8BUH M2y_IUO7F.3BFtU7yEx0nrCxxyJNJWcC.nzsR1sBNFLFuVHWL94eRyMXi2QWS5Ep4Q4.Qcsxlley xMeG..gee8z5M87Am5eXVPu4CE8b0cT.9DCu.9O0C1itqGPRVmbq3C9bARqFDRGQUhtstOfVPimp KoafaSJ09aXQ3HsqEuV3sTyOCDV5iJp9X6QbNOePz5Y9QvCn_VKE_SGEgMssESGKuCBy2yYx8V46 qk72sUrOJVe8o7cfZ5nc2G4WsJbYwKKgZq2uGxXLasvoFUbvGw1Ba0Jt_CjYj3ZXJ91W4EJ2JJH5 CQ2NXmZgRFFDuoiTrx5QL4Hds95bpmpfZaOBv_E1ytBCxagugZrDPMiZtoUgMVIBVhzP_rajCga. 0atQ._Kj3K25Zfe1oUAw_pKjS.HnzoI.cU5YIHhCcGmRoJUuNSoI.Z8qiJi1YzIFeJC9DSqzPbwW _J43L7UGKFuB_ZaN85Xh0ko.UNSpwXl58qsQ.YSpqDotw_sOKt420S4wXmjO70TnFqBlyJ_sDSv2 CvEz5SZAb5Uxp4at98qKH2Zl15KD6By1CiMt4QGNmAKqdpARaIOAxC2Qb1aN8CRKfo8y0pNVifDY 9kgezgvIl27Upa6XcaSBoHWuySxeLIj2fe9SR6nkwES7z Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 23 Jan 2019 17:24:50 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0b310f841c565f09ac4b1e6a500295e4 for ; Wed, 23 Jan 2019 17:24:48 +0000 (UTC) To: oauth@ietf.org References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> From: George Fletcher Organization: AOL LLC Message-ID: <089ed859-af9e-e612-b58d-f2c8e598443d@aol.com> Date: Wed, 23 Jan 2019 12:24:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------916742FDF98177623EE76022" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 17:24:57 -0000 This is a multi-part message in MIME format. --------------916742FDF98177623EE76022 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I worry about these kind of references because it does not give clear guidance to developers on what to do. It also significantly increases the complexity of implementing something correctly because of all the specs that have to be followed in order to understand the full picture of what's required. The current "spec set" is already pretty large for someone starting out with OAuth2/JOSE/etc. I'd much prefer we add non-normative guidance in the current doc to make the use case for logical resource identifiers clear as that will most likely lead to better implementations and deployments. Thanks, George On 1/22/19 1:19 PM, Mike Jones wrote: > > I think that a non-normative reference to  “req_aud” in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > should be > added to the resource indicators doc to inform developers that req_aud > is also available to then, and then we should call it a day. > > -- Mike > > *From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef > *Sent:* Monday, January 21, 2019 5:36 PM > *To:* Vittorio Bertocci > *Cc:* Brian Campbell ; > IETF oauth WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci > wrote: > > Hi Rifaat, > > absolutely. Brian and myself already started working on some > language, however this week he is in vacation hence it might take > few days before we come back to the list with something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > > wrote: > > Brian, Vittorio, > > To move this discussion forward, can you guys suggest some > text to make the logical identifier usage clearer? > > Regards, > >  Rifaat > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > > wrote: > > As I suggested before, I do think that's within the bounds > of the draft's definition of 'resource' as a URI. And that > perhaps all that's needed is some minor adjustment and/or > augmentation of some text to make it more clear. > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > > wrote: > > [sent to John only by mistake, resending to the ML] > > In Azure AD v1 & ADFS, that's resource. It could be > used for both network and logical ids, with the > concrete usage in the wild I described earlier. > > In Azure AD v2, the resource as explicit parameter > (network, logic or otherwise) is gone and is expressed > as part of the scope string of all the scopes > requested for a given resource- but it still exist in > practice tho as it still end up in the resulting > aud of the issued token. > > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley > > wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt > the established process. In my former position > I wasn't monitoring those discussions hence I > didn't have a chance to offer feedback. When I > saw something that gave me the impression > might lead to issues, and given that I worked > with actual deployments and developers using a > similar parameter for a long time, I thought > prudent to bring this up. I really appreciate > Rifaat's stance on this. End of preamble. > > Ultimately my goal is for developers to have > guidance on how to work with the concept of > logical resource in a standard compliant way, > hence it doesn't strictly matter whether the > definition of the corresponding parameter > lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would > appear that most of the reasons for which the > spec was created apply to both the network > addressable and the logical resource types: > knowing what keys to use to encrypt the token, > constrain access tokens to the intended > audience, avoiding overloading scopes with > resource indicating parts... those all apply > to network addressable and logic identifiers > alike. And both parameters are expected to > result in audience restricted tokens. It seems > the only difference comes at token usage time, > with the network addressable case giving more > guarantees that the token will go to its > intended recipient, but the request and > audience restriction syntax seems to be > exactly the same. > > On top of this: in the 99.999% of the > scenarios I encountered in the wild in the > last 5 years of using the resource parameter > in the MS ecosystem, the resource identifier > was known at design time: the developer > discovered it out of band and placed it in the > app config at deployment time. Those aren't > fringe cases I occasionally encountered: the > resource parameter in Azure AD v1 and ADFS was > mandatory, hence literally every solution i > saw or touched used it. As Brian suggested, > this is a scenario where the security > advantages of the network addressable case > aren't as pronounced as in the case in which > the client discovers the resource identifier > at runtime. This isn't just because there is > no specification suggesting location should be > explicitly indicated, it's because there are > many practical advantages at development and > deployment time to be able to use logical > identifiers- and if the /concrete /security > advantages don't apply to the their case, > people will simply not comply. > > In summary: creating two different parameters > in two different documents is better than > ignoring he logical identifier case > altogether, however I think that not > acknowledging the logical id case > in oauth-resource-indicators is going to > create confusion and ultimately not be as > useful to the developer community as it could be. > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt > > wrote: > > +1 to Mike and John’s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, Mike Jones > > > wrote: > > I also agree that “resource” should be > a specific network-addressable URL > whereas a separate audience parameter > (like “aud” in JWTs) can refer to one > or more logical resources. They are > different, if related, things. > > Note that the ACE WG is proposing to > register a logical audience parameter > “req_aud” in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - partly based on feedback from OAuth > WG members.  This is a general OAuth > parameter, which any OAuth deployment > will be able to use. > > I therefore believe that no changes > are needed to > draft-ietf-oauth-resource-indicators, > as the logical audience work is > already happening in another draft. > > -- Mike > > *From:* OAuth > *On > Behalf Of *John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > > > *Cc:* Vittorio Bertocci > >; > IETF oauth WG > > *Subject:* Re: [OAUTH-WG] Shepherd > write-up for > draft-ietf-oauth-resource-indicators-01 > > We need to decide if we want to make a > change. > > For security we are location centric. > > I prefer to keep resource location > separate from logical audience that > can be a scope or other parameter. > > If becomes harder for people to use > the parameter correctly if we are too > flexible. > > I would rather have a separate logical > audience parameter if we think we want > one. > > John B. > > On Sat, Jan 19, 2019, 11:41 AM Brian > Campbell wrote: > > No apology needed, Rifaat. And I > apologize if what I said came off > the wrong way. I was just trying > to make light of the situation.. > And I agree that we should not be > hamstrung by the process and there > are times when it makes sense to > be flexible with things. > > On Fri, Jan 18, 2019 at 6:22 PM > Rifaat Shekh-Yusef > > wrote: > > Sorry Brian, I was not clear > with my statement. > > I meant to say that we should > not allow the process to > prevent the WG from producing > a quality document without > issues, assuming there is an > issue in the first place. > > Ideally we want to get these > identified during the WGLC, > but things happen and > sometimes the WG misses > something. > > I hear you and agree that this > make things difficult for > authors. We will make sure > that this does not become the > norm, and we will try to stick > to the process as much as > possible. > > Regards, > >  Rifaat > > On Fri, Jan 18, 2019 at 5:35 > PM Brian Campbell > > > wrote: > > Thanks Rifaat. Process is > as process does, right? I > do kinda want to grumble > about WGCL having passed > already but that's mostly > because replying to these > kinds of threads is hard > for me and I'll just get > over it... > > As far as I understand > things, the security > concerns come into play > when the client is being > told the by the resource > how to identity the > resource like is described > in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and using the actual > location in that context > ,along with some other > checks prescribed in that > draft, prevents the kind > of issues John described > earlier in the thread. > > In cases where the client > knows the resource a > priori or out-of-band or > configured or whatever, I > don't think the same > security concerns arise. > And using such a known > value, be it an actual > location or logical > representation, would be okay. > > The resource-indicators > draft is admittedly > somewhat location-centric > in how it talks about the > value of the 'resource' > parameter. But ultimately > it defines it as an > absolute URI that > indicates the location of > the target service or > resource where access is > being requested. A > location can be varying > shades of abstract and I'd > say that using a URI as > 'resource' parameter value > that's a logical > identifier that points to > some resource is well > within the bounds of the > draft. > > So maybe the draft is okay > as is? > > Or perhaps that's too much > to be left as an exerciser > to the reader? And some > text should be added > and/or adjusted so the > resource-indicators draft > would be a little more > open/clear about the > parameter value > potentially being more of > a logical or abstract > identifier and not > necessarily a network > addressable URL? > > On Fri, Jan 18, 2019 at > 1:18 PM Rifaat Shekh-Yusef > > > wrote: > > I wouldn't worry too > much about the process. > > If it makes sense to > update the document, > then feel free to do that. > > Regards, > >  Rifaat > > On Fri, Jan 18, 2019 > at 3:08 PM John > Bradley > > > wrote: > > Yes the logical > resource can be > provided by "scope" > > Some > implementations > like Ping and > Auth0 have been > adding another > parameter "aud" to > identify the > logical resource > and then using > scopes to define > permissions to the > resource. > > Fortunately, we > are using a > different parameter > name so not > stepping on that.. > > We could go back > and try to add > text explaining > the difference, > but we are quite > late in the process. > > I agree that a > logical resource > parameter may be > helpful, but > perhaps it should > be a separate draft. > > John B. > > On Fri, Jan 18, > 2019 at 4:38 PM > Richard Backman, > Annabelle > > > wrote: > > Doesn’t the > “scope” > parameter > already > provide a > means of > specifying a > logical > identifier? > > -- > > Annabelle > Richard Backman > > AWS Identity > > *From: *OAuth > > > on behalf of > Vittorio > Bertocci > > > *Date: > *Friday, > January 18, > 2019 at 5:47 AM > *To: *John > Bradley > > > *Cc: *IETF > oauth WG > > > *Subject: *Re: > [OAUTH-WG] > Shepherd > write-up for > draft-ietf-oauth-resource-indicators-01 > > Thanks John > for the > background. > > I agree that > from the > client > validation > PoV, having an > identifier > corresponding > to a location > makes things > more solid. > > That said: the > use of logical > identifiers is > widespread, as > it has > significant > practical > advantages > (think of > services that > assign > generated > hosting URLs > only at > deployment > time, or > services that > are somehow > grouped under > the same > logical > audience > across > regions/environment/deployments). > People won't > stop using > logical > identifiers, > because they > often have no > alternative > (generating > new audiences > on the fly at > the AS every > time you do a > deployment and > get assigned a > new URL can be > unfeasible). > Leaving a > widely used > approach as > exercise to > the reader > seems a > disservice to > the community, > given that > this might > lead to > vendors (for > example > Microsoft and > Auth0) keeping > their own > proprietary > parameters, or > developers > misusing the > ones in place; > would make it > hard for SDK > developers to > provide > libraries that > work out of > the box with > different > ASes; and so on. > > Would it be > feasible to > add such > parameter > directly in > this spec? > That would > eliminate the > interop > issues, and > also gives us > a chance to > fully warn > people about > the security > shortcomings > of choosing > that approach. > > On Thu, Jan > 17, 2019 at > 4:32 PM John > Bradley > > > wrote: > > We have > discussed > this. > > Audiences > can > certainly > be logical > identifiers. > > This > however is > a more > specific > location.  > The AS is > free to > map the > location > into some > abstract > audience > in the AT. > > From a > security > point of > view once > the client > starts > asking for > logical > resources > it can be > tricked > into > asking for > the wrong > one as a > bad > resource > can always > lie about > what > logical > resource > it is. > > If we were > to change > it, how a > client > would > validate > it becomes > challenging > to > impossible. > > The AS is > free to do > whatever > mapping of > locations > to > identifiers > it needs > for access > tokens. > > Some > implementations > may want > to keep > additional > parameters > like > logical > audience, > but that > should be > separate > from resource. > > John B. > > On > 1/17/2019 > 9:56 AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > The > text > you > quoted > is > copied > form > the > abstract > of the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > >  Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > > > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > > > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > >  Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY NOTICE: > This email may contain > confidential and > privileged material for > the sole use of the > intended recipient(s). Any > review, use, distribution > or disclosure by others is > strictly prohibited. If > you have received this > communication in error, > please notify the sender > immediately by e-mail and > delete the message and any > file attachments from your > computer. Thank you./* > > > */CONFIDENTIALITY NOTICE: This > email may contain confidential and > privileged material for the sole > use of the intended recipient(s). > Any review, use, distribution or > disclosure by others is strictly > prohibited.. If you have received > this communication in error, > please notify the sender > immediately by e-mail and delete > the message and any file > attachments from your computer. > Thank you./* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY NOTICE: This email may contain > confidential and privileged material for the sole use of > the intended recipient(s). Any review, use, distribution > or disclosure by others is strictly prohibited...  If you > have received this communication in error, please notify > the sender immediately by e-mail and delete the message > and any file attachments from your computer. Thank > you./*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------916742FDF98177623EE76022 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I worry about these kind of references because it does not give clear guidance to developers on what to do. It also significantly increases the complexity of implementing something correctly because of all the specs that have to be followed in order to understand the full picture of what's required. The current "spec set" is already pretty large for someone starting out with OAuth2/JOSE/etc.

I'd much prefer we add non-normative guidance in the current doc to make the use case for logical resource identifiers clear as that will most likely lead to better implementations and deployments.

Thanks,
George

On 1/22/19 1:19 PM, Mike Jones wrote:

I think that a non-normative reference to  “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be added to the resource indicators doc to inform developers that req_aud is also available to then, and then we should call it a day.

 

                                                                -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, January 21, 2019 5:36 PM
To: Vittorio Bertocci <Vittorio@auth0.com>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

 

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

 

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

 

Regards,

 Rifaat

 

 

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

 

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]

 

In Azure AD v1 & ADFS, that's resource. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.

This is 9 months old info hence

 

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

 

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

 

 

 

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:

+1 to Mike and John’s comments. 

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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


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


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

--------------916742FDF98177623EE76022-- From nobody Wed Jan 23 10:58:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA4123FFD for ; Wed, 23 Jan 2019 10:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 S9BZSGk9h5Z1 for ; Wed, 23 Jan 2019 10:58:32 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99D7130EDE for ; Wed, 23 Jan 2019 10:56:31 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id t33so3636726qtt.4 for ; Wed, 23 Jan 2019 10:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AvY6svIIYAzTiZ516OnwMDN0DTmIcczvsTULn1gM6Uc=; b=sUn54A5KFmk4OynS5an8E1H9mDpnBTUhw+zj+VbQz8Rg01wi0lBMDi8axBBtjhMngU nKKLIHZyG1d4CyjKIBqvI7/JtbNEMpm3yoZQhJjGPyzg5Fh/wB+xtLDcfOTZu1TNX7aB KtEChT2hS1S3Qf6P1cQrwjju4KJyV3gUb5EADno25by8NO9mAhCN1ycgdFVwVcddlzqj v6hyet3jI8HK5uGP0raE5aE63Gx5vaieG61Bye+8xqbFsgV1pNBIW8GwaXabN6+GyRjK KwS7BjdaDKCNGrpfPz9/KXuvQRR/FEVs6dWwPQVdrDGuaZ9/UnM+glLuNZqQAHRHQfKp r7PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AvY6svIIYAzTiZ516OnwMDN0DTmIcczvsTULn1gM6Uc=; b=TzpD31VRhjuwBIFXjmLT+/n9lJhYxDpXv5RamMGasdxw9P0V21w2vQIdDb+yh6K8ZK LuJdL0vaF/qmUcRs2jA7JBTBuXhgQbsj7Nt0CIhS8HY/DpfN/38S/p1VKzZIob8nb4qw v+/+xVTLDFVOdfMprcB+41+dJeD9qRQ/Esfond+NbVJc10hoI3vkBdVYqHCuetdahiIF +PmP58RvdnRQ2d+0lflKe53BfRq025UCjBLKpVgEh8J/WhVyOzgbzoTq2NXRq1Ssm3UT TtNeSSxIY9ck9ckakD2vAdOxZBsWnbSMIk+aafgGdzzgLPCwIojZwgdeJLGJDInlKbDJ /BMg== X-Gm-Message-State: AJcUukfR9JgYljR85YehRXYfZOwwwNpQ0yBulPUn0bJiLrsMZBVkOXv9 k1DAxJvfD+/8ASuJ/FYooW6PgHjyH5qSlk4E X-Google-Smtp-Source: ALg8bN6aR+4MKgSY2rfaybV28ITXmJo9I07HAtdDI6rmT3r0CnyQCXIF/6zZ05BmXghHIvY4USbGOA== X-Received: by 2002:aed:23c5:: with SMTP id k5mr3681057qtc.39.1548269789689; Wed, 23 Jan 2019 10:56:29 -0800 (PST) Received: from [192.168.8.104] ([191.126.161.228]) by smtp.gmail.com with ESMTPSA id m14sm48226691qka.21.2019.01.23.10.56.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 10:56:28 -0800 (PST) To: oauth@ietf.org References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> From: John Bradley Message-ID: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> Date: Wed, 23 Jan 2019 15:56:25 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Thunderbird/65.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------48770EA73C3D0DDCE32D46A3" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 18:58:38 -0000 This is a multi-part message in MIME format. --------------48770EA73C3D0DDCE32D46A3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately. As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read. Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed. I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT. I prefer to keep that separate from the logical resource that may span more than one RS endpoint. Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road. John B. On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > Hi all, > thanks for you patience. Brian and myself iterated on modifying the > text to cover the logical identifier use case, highlighting the > security implications of going that route. You can find the revised > text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from January 21 for the specific changes. > Note: I also had a chat with John offline, and he expressed the desire > to split the resource parameter in two distinct parameters to better > signal the intended usage. I am sure he can elaborate. I have nothing > against it in principle, as long as we leave nothing as exercise to > the reader and we are very clear on usage (e.g. mutual exclusivity, > etc) but didn't have a chance to speak w Brian about it. If the > discussion stretches further, I would suggest we pause it and let him > enjoy his time off for the rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > > wrote: > > Thank you guys! > > > On Monday, January 21, 2019, Vittorio Bertocci > wrote: > > Hi Rifaat, > absolutely. Brian and myself already started working on some > language, however this week he is in vacation hence it might > take few days before we come back to the list with something. > Cheers, > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > > wrote: > > Brian, Vittorio, > > To move this discussion forward, can you guys suggest some > text to make the logical identifier usage clearer? > > Regards, >  Rifaat > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > > wrote: > > As I suggested before, I do think that's within the > bounds of the draft's definition of 'resource' as a > URI. And that perhaps all that's needed is some minor > adjustment and/or augmentation of some text to make it > more clear. > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > > wrote: > > [sent to John only by mistake, resending to the ML] > > In Azure AD v1 & ADFS, that's resource. It could > be used for both network and logical ids, with the > concrete usage in the wild I described earlier. > In Azure AD v2, the resource as explicit parameter > (network, logic or otherwise) is gone and is > expressed as part of the scope string of all the > scopes requested for a given resource- but it > still exist in practice tho as it still end up in > the resulting aud of the issued token. > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley > > wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> First of all, it wasn't my intent to disrupt >> the established process. In my former >> position I wasn't monitoring those >> discussions hence I didn't have a chance to >> offer feedback. When I saw something that >> gave me the impression might lead to issues, >> and given that I worked with actual >> deployments and developers using a similar >> parameter for a long time, I thought prudent >> to bring this up. I really appreciate >> Rifaat's stance on this. End of preamble. >> >> Ultimately my goal is for developers to have >> guidance on how to work with the concept of >> logical resource in a standard compliant way, >> hence it doesn't strictly matter whether the >> definition of the corresponding parameter >> lives in oauth-resource-indicators or elsewhere. >> That said. Reading through the draft, it >> would appear that most of the reasons for >> which the spec was created apply to both the >> network addressable and the logical resource >> types: knowing what keys to use to encrypt >> the token, constrain access tokens to the >> intended audience, avoiding overloading >> scopes with resource indicating parts... >> those all apply to network addressable and >> logic identifiers alike. And both parameters >> are expected to result in audience restricted >> tokens. It seems the only difference comes at >> token usage time, with the network >> addressable case giving more guarantees that >> the token will go to its intended recipient, >> but the request and audience restriction >> syntax seems to be exactly the same. >> On top of this: in the 99.999% of the >> scenarios I encountered in the wild in the >> last 5 years of using the resource parameter >> in the MS ecosystem, the resource identifier >> was known at design time: the developer >> discovered it out of band and placed it in >> the app config at deployment time. Those >> aren't fringe cases I occasionally >> encountered: the resource parameter in Azure >> AD v1 and ADFS was mandatory, hence literally >> every solution i saw or touched used it. As >> Brian suggested, this is a scenario where the >> security advantages of the network >> addressable case aren't as pronounced as in >> the case in which the client discovers the >> resource identifier at runtime. This isn't >> just because there is no specification >> suggesting location should be explicitly >> indicated, it's because there are many >> practical advantages at development and >> deployment time to be able to use logical >> identifiers- and if the /concrete /security >> advantages don't apply to the their case, >> people will simply not comply. >> >> In summary: creating two different parameters >> in two different documents is better than >> ignoring he logical identifier case >> altogether, however I think that not >> acknowledging the logical id case >> in oauth-resource-indicators is going to >> create confusion and ultimately not be as >> useful to the developer community as it could be. >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt >> > > wrote: >> >> +1 to Mike and John’s comments. >> >> Phil >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones >> > > >> wrote: >> >>> I also agree that “resource” should be a >>> specific network-addressable URL whereas >>> a separate audience parameter (like >>> “aud” in JWTs) can refer to one or more >>> logical resources.  They are different, >>> if related, things. >>> >>> Note that the ACE WG is proposing to >>> register a logical audience parameter >>> “req_aud” in >>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 >>> - partly based on feedback from OAuth WG >>> members. This is a general OAuth >>> parameter, which any OAuth deployment >>> will be able to use. >>> >>> I therefore believe that no changes are >>> needed to >>> draft-ietf-oauth-resource-indicators, as >>> the logical audience work is already >>> happening in another draft. >>> >>> -- Mike >>> >>> *From:* OAuth >> > *On >>> Behalf Of * John Bradley >>> *Sent:* Saturday, January 19, 2019 9:01 AM >>> *To:* Brian Campbell >>> >> > >>> *Cc:* Vittorio Bertocci >>> >> >; >>> IETF oauth WG >> > >>> *Subject:* Re: [OAUTH-WG] Shepherd >>> write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> We need to decide if we want to make a >>> change. >>> >>> For security we are location centric. >>> >>> I prefer to keep resource location >>> separate from logical audience that can >>> be a scope or other parameter. >>> >>> If becomes harder for people to use the >>> parameter correctly if we are too flexible. >>> >>> I would rather have a separate logical >>> audience parameter if we think we want one. >>> >>> John B. >>> >>> On Sat, Jan 19, 2019, 11:41 AM Brian >>> Campbell >> wrote: >>> >>> No apology needed, Rifaat. And I >>> apologize if what I said came off >>> the wrong way. I was just trying to >>> make light of the situation.. And I >>> agree that we should not be >>> hamstrung by the process and there >>> are times when it makes sense to be >>> flexible with things. >>> >>> On Fri, Jan 18, 2019 at 6:22 PM >>> Rifaat Shekh-Yusef >>> >> > wrote: >>> >>> Sorry Brian, I was not clear >>> with my statement. >>> >>> I meant to say that we should >>> not allow the process to prevent >>> the WG from producing a quality >>> document without issues, >>> assuming there is an issue in >>> the first place. >>> >>> Ideally we want to get these >>> identified during the WGLC, but >>> things happen and sometimes the >>> WG misses something. >>> >>> I hear you and agree that this >>> make things difficult for >>> authors. We will make sure that >>> this does not become the norm, >>> and we will try to stick to the >>> process as much as possible. >>> >>> Regards, >>> >>>  Rifaat >>> >>> On Fri, Jan 18, 2019 at 5:35 PM >>> Brian Campbell >>> >> > >>> wrote: >>> >>> Thanks Rifaat. Process is as >>> process does, right? I do >>> kinda want to grumble about >>> WGCL having passed already >>> but that's mostly because >>> replying to these kinds of >>> threads is hard for me and >>> I'll just get over it... >>> >>> As far as I understand >>> things, the security >>> concerns come into play when >>> the client is being told the >>> by the resource how to >>> identity the resource like >>> is described in >>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 >>> and using the actual >>> location in that context >>> ,along with some other >>> checks prescribed in that >>> draft, prevents the kind of >>> issues John described >>> earlier in the thread. >>> >>> In cases where the client >>> knows the resource a priori >>> or out-of-band or configured >>> or whatever, I don't think >>> the same security concerns >>> arise. And using such a >>> known value, be it an actual >>> location or logical >>> representation, would be okay. >>> >>> The resource-indicators >>> draft is admittedly somewhat >>> location-centric in how it >>> talks about the value of the >>> 'resource' parameter. But >>> ultimately it defines it as >>> an absolute URI that >>> indicates the location of >>> the target service or >>> resource where access is >>> being requested. A location >>> can be varying shades of >>> abstract and I'd say that >>> using a URI as 'resource' >>> parameter value that's a >>> logical identifier that >>> points to some resource is >>> well within the bounds of >>> the draft. >>> >>> So maybe the draft is okay >>> as is? >>> >>> Or perhaps that's too much >>> to be left as an exerciser >>> to the reader? And some text >>> should be added and/or >>> adjusted so the >>> resource-indicators draft >>> would be a little more >>> open/clear about the >>> parameter value potentially >>> being more of a logical or >>> abstract identifier and not >>> necessarily a network >>> addressable URL? >>> >>> On Fri, Jan 18, 2019 at 1:18 >>> PM Rifaat Shekh-Yusef >>> >> > >>> wrote: >>> >>> I wouldn't worry too >>> much about the process. >>> >>> If it makes sense to >>> update the document, >>> then feel free to do that. >>> >>> Regards, >>> >>>  Rifaat >>> >>> On Fri, Jan 18, 2019 at >>> 3:08 PM John Bradley >>> >> > >>> wrote: >>> >>> Yes the logical >>> resource can be >>> provided by "scope" >>> >>> Some implementations >>> like Ping and Auth0 >>> have been adding >>> another parameter >>> "aud" to identify >>> the logical resource >>> and then using >>> scopes to define >>> permissions to the >>> resource. >>> >>> Fortunately, we are >>> using a >>> different parameter >>> name so not stepping >>> on that.. >>> >>> We could go back and >>> try to add text >>> explaining the >>> difference, but we >>> are quite late in >>> the process. >>> >>> I agree that a >>> logical resource >>> parameter may be >>> helpful, but perhaps >>> it should be a >>> separate draft. >>> >>> John B. >>> >>> On Fri, Jan 18, 2019 >>> at 4:38 PM Richard >>> Backman, Annabelle >>> >> > >>> wrote: >>> >>> Doesn’t the >>> “scope” >>> parameter >>> already provide >>> a means of >>> specifying a >>> logical identifier? >>> >>> -- >>> >>> Annabelle >>> Richard Backman >>> >>> AWS Identity >>> >>> *From: *OAuth >>> >> > >>> on behalf of >>> Vittorio >>> Bertocci >>> >> > >>> *Date: *Friday, >>> January 18, 2019 >>> at 5:47 AM >>> *To: *John >>> Bradley >>> >> > >>> *Cc: *IETF oauth >>> WG >>> >> > >>> *Subject: *Re: >>> [OAUTH-WG] >>> Shepherd >>> write-up for >>> draft-ietf-oauth-resource-indicators-01 >>> >>> Thanks John for >>> the background. >>> >>> I agree that >>> from the client >>> validation PoV, >>> having an >>> identifier >>> corresponding to >>> a location makes >>> things more solid. >>> >>> That said: the >>> use of logical >>> identifiers is >>> widespread, as >>> it has >>> significant >>> practical >>> advantages >>> (think of >>> services that >>> assign generated >>> hosting URLs >>> only at >>> deployment time, >>> or services that >>> are somehow >>> grouped under >>> the same logical >>> audience across >>> regions/environment/deployments). >>> People won't >>> stop using >>> logical >>> identifiers, >>> because they >>> often have no >>> alternative >>> (generating new >>> audiences on the >>> fly at the AS >>> every time you >>> do a deployment >>> and get assigned >>> a new URL can be >>> unfeasible). >>> Leaving a widely >>> used approach as >>> exercise to the >>> reader seems a >>> disservice to >>> the community, >>> given that this >>> might lead to >>> vendors (for >>> example >>> Microsoft and >>> Auth0) keeping >>> their own >>> proprietary >>> parameters, or >>> developers >>> misusing the >>> ones in place; >>> would make it >>> hard for SDK >>> developers to >>> provide >>> libraries that >>> work out of the >>> box with >>> different ASes; >>> and so on. >>> >>> Would it be >>> feasible to add >>> such parameter >>> directly in this >>> spec? That would >>> eliminate the >>> interop issues, >>> and also gives >>> us a chance to >>> fully warn >>> people about the >>> security >>> shortcomings of >>> choosing that >>> approach. >>> >>> On Thu, Jan 17, >>> 2019 at 4:32 PM >>> John Bradley >>> >> > >>> wrote: >>> >>> We have >>> discussed this. >>> >>> Audiences >>> can >>> certainly be >>> logical >>> identifiers. >>> >>> This however >>> is a more >>> specific >>> location.  >>> The AS is >>> free to map >>> the location >>> into some >>> abstract >>> audience in >>> the AT. >>> >>> From a >>> security >>> point of >>> view once >>> the client >>> starts >>> asking for >>> logical >>> resources it >>> can be >>> tricked into >>> asking for >>> the wrong >>> one as a bad >>> resource can >>> always lie >>> about what >>> logical >>> resource it is. >>> >>> If we were >>> to change >>> it, how a >>> client would >>> validate it >>> becomes >>> challenging >>> to impossible. >>> >>> The AS is >>> free to do >>> whatever >>> mapping of >>> locations to >>> identifiers >>> it needs for >>> access tokens. >>> >>> Some >>> implementations >>> may want to >>> keep >>> additional >>> parameters >>> like logical >>> audience, >>> but that >>> should be >>> separate >>> from resource. >>> >>> John B. >>> >>> On 1/17/2019 >>> 9:56 AM, >>> Rifaat >>> Shekh-Yusef >>> wrote: >>> >>> Hi >>> Vittorio, >>> >>> The text >>> you >>> quoted >>> is >>> copied >>> form the >>> abstract >>> of the >>> draft >>> itself. >>> >>> *Authors,* >>> >>> Should >>> the >>> draft be >>> updated >>> to cover >>> the >>> logical >>> identifier >>> case? >>> >>> Regards, >>> >>>  Rifaat >>> >>> On Thu, >>> Jan 17, >>> 2019 at >>> 8:19 AM >>> Vittorio >>> Bertocci >>> >> > >>> wrote: >>> >>> Hi >>> Rifaat, >>> >>> one >>> detail. >>> The >>> tech >>> summary >>> says >>> >>> An >>> extension >>> to >>> the >>> OAuth >>> 2.0 >>> Authorization >>> Framework >>> defining >>> request >>> >>> parameters >>> that >>> enable >>> a >>> client >>> to >>> explicitly >>> signal >>> to >>> an >>> authorization >>> server >>> >>> about >>> the >>> *location* >>> of >>> the >>> protected >>> resource(s) >>> to >>> which >>> it >>> is >>> requesting >>> >>> >>> access. >>> >>> But >>> at >>> least >>> in >>> the >>> Microsoft >>> implementation, >>> the >>> resource >>> identifier >>> doesn't >>> /have/ >>> to >>> be a >>> network >>> addressable >>> URL >>> (and >>> if >>> it >>> is, >>> it >>> doesn't >>> strictly >>> need >>> to >>> match >>> the >>> actual >>> resource >>> location). >>> It >>> can >>> be a >>> logical >>> identifier, >>> tho >>> using >>> the >>> actual >>> resource >>> location >>> there >>> has >>> benefits >>> (domain >>> ownership >>> check, >>> prevention >>> of >>> token >>> forwarding >>> etc). >>> >>> Same >>> for >>> Auth0, >>> the >>> audience >>> parameter >>> is a >>> logical >>> identifier >>> rather >>> than >>> a >>> location. >>> >>> On >>> Wed, >>> Jan >>> 16, >>> 2019 >>> at >>> 6:32 >>> PM >>> Rifaat >>> Shekh-Yusef >>> >> > >>> wrote: >>> >>> All, >>> >>> >>> The >>> following >>> is >>> the >>> first >>> shepherd >>> write-up >>> for >>> the draft-ietf-oauth-resource-indicators-01 >>> document. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >>> >>> Please, >>> take >>> a >>> look >>> and >>> let me >>> know >>> if >>> I >>> missed >>> anything. >>> >>> Regards, >>> >>>  Rifaat >>> >>> _______________________________________________ >>> OAuth >>> mailing >>> list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth >>> mailing list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> */CONFIDENTIALITY NOTICE: >>> This email may contain >>> confidential and privileged >>> material for the sole use of >>> the intended recipient(s). >>> Any review, use, >>> distribution or disclosure >>> by others is strictly >>> prohibited. If you have >>> received this communication >>> in error, please notify the >>> sender immediately by e-mail >>> and delete the message and >>> any file attachments from >>> your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email >>> may contain confidential and >>> privileged material for the sole use >>> of the intended recipient(s). Any >>> review, use, distribution or >>> disclosure by others is strictly >>> prohibited.. If you have received >>> this communication in error, please >>> notify the sender immediately by >>> e-mail and delete the message and >>> any file attachments from your >>> computer. Thank you./* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > /CONFIDENTIALITY NOTICE: This email may contain > confidential and privileged material for the sole use > of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly > prohibited...  If you have received this communication > in error, please notify the sender immediately by > e-mail and delete the message and any file attachments > from your computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------48770EA73C3D0DDCE32D46A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.
Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Brian, Vittorio,

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

Regards,
 Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's resource. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:
+1 to Mike and John’s comments. 

Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------48770EA73C3D0DDCE32D46A3-- From nobody Wed Jan 23 11:03:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95070130ED0 for ; Wed, 23 Jan 2019 11:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LspdYrkjkLM2 for ; Wed, 23 Jan 2019 11:02:59 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A011277BB for ; Wed, 23 Jan 2019 11:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vLN1xwX4zR6BzWJq+0vuyye13iV0PAwO9uPOEN35I+Q=; b=NCxkjicydXzwjVn/94sUFMd3pD02f2N+fEOn1AXhmd45ke+XZ10CtNxPoSpP8ygDf13dmHUBMNMQwp2O6ZR8q4EghvAVASqjMLKrb/BG45jCXD9uQ0v9bQprmQep+QDe7QjjyPIou0VsmHAqm7MRVWtbcB0vYwRXyWmdxJyxqB8= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0421.namprd00.prod.outlook.com (52.132.129.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1594.0; Wed, 23 Jan 2019 19:02:55 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::8dc9:f1fb:bf1:4b57]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::8dc9:f1fb:bf1:4b57%7]) with mapi id 15.20.1598.000; Wed, 23 Jan 2019 19:02:55 +0000 From: Mike Jones To: John Bradley , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMSm6zRRv4Nr0eerioJ6LCFT6Wzcp6AgABNkQCAABqbAIABMd2AgABiBYCAAAiJAIAAAu6AgAAmUgCAAC6ggIAA30eAgAAm6gCAADowsIAAArOAgAHKeICAACE4AIAAC1UAgADX2YCAACJwAIAAdm6AgAAP8ICAApBGgIAAJMyAgAABgfA= Date: Wed, 23 Jan 2019 19:02:55 +0000 Message-ID: References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> In-Reply-To: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.86.113] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0421; 6:eNX6El8+jDz6NVK9B7bvy2eetvpOUTsZaN4eC3MtnFUfHkHnFQmQ6hpYPI9BveZTfti/w43p6yAUBLNacGdqDR7kuqd0fPk7zEzyoCSEzIeVe8F/t0eOmrilNNQPk8dn88vrtQKAmZxRu4dN/sHAmRr6wd1obdRhLKBEBVTGhUe9gAjoTBuwF092YT+1gZkO1ZT5E+8WMnPq4DGGGsYkDhlHXvZZNkR04HvmMgmX6zf+kvARm9UcYQubIYkGaglAfh4PYCaWohVvt+qA60VMD8osorxHl9gZ17SjZzjLd7dmiImlhuUQWAi51FTNKIOZo5LLkMm5gK6UGzr8mg8cbPKDyZsrzrEgPogE0vgCD4PRII7E4D6hsWPHuHajWK1Xuwn5PsPIxpn0ZFXOT2uA0eCX/70so1bQqr7D075OZ3h71qhAPwtnHnzSHK+A+k3jBPTKFOJkL+jXW2mstjjcAA==; 5:n9XMX4z9emvMkCNTNCiGk85WwN2nIT413G061XMJsC8xNW3mpAM2YNdGIEJDuGfuLZgWmDGvMQvMrfXKj26Jmr2rKFS0Ba4efT/WisTuTYQh8Vel40OgfJBUqMMR5vpfx+OB+7gXywQMKpj0h0kOjkCFUg9io6pkH5d30Rz5Dlc87tWPhctz3sQ49Wlg7O/sPgZBFJ/zY5lYkR6F3CHQuA==; 7:pkUOGS5hfOl9vzT22I5shL8h3DdttwEHJ4Uz0euY2eeg8c1MketvQQ2mnXzrP2PXdYzOpIiHUXkeb1qITDVfUfNYNjSK30mEtEkx1kT5oXMEdjwG06H4vveVzQ2H3m2p5ZC8IE4MgNCj2mgLjLvYMw== x-ms-office365-filtering-correlation-id: 92bd6d7c-e172-4b50-5871-08d6816561da x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR00MB0421; x-ms-traffictypediagnostic: DM5PR00MB0421: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(376002)(366004)(136003)(199004)(189003)(51444003)(53754006)(966005)(14454004)(8990500004)(14444005)(256004)(97736004)(5024004)(446003)(10290500003)(478600001)(72206003)(8936002)(81166006)(476003)(8676002)(486006)(81156014)(10090500001)(11346002)(74316002)(7736002)(6246003)(3846002)(2906002)(53946003)(25786009)(33656002)(790700001)(6116002)(68736007)(53936002)(229853002)(106356001)(105586002)(86362001)(86612001)(9686003)(55016002)(54896002)(6306002)(236005)(6436002)(6346003)(26005)(99286004)(316002)(66066001)(2501003)(606006)(110136005)(93886005)(30864003)(71200400001)(7696005)(76176011)(71190400001)(102836004)(6506007)(186003)(22452003)(53546011)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0421; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LrPy8K5ojPdUdCb0rnWDVHMhfYc9BHZN5I5o2LCQ5OBipH0EiZ6DgJDNyRLpO1sit2gS+3YsKlMSxlottbDsPiSzTucHDYfbBkAc/q2hdibNdIjjmRlcwRm5BJNAh5Ym1kVHKYeDFljNg3O0tgkUB1XJOalsnT/8J6uruX3CcR2yalzsiQVi0G1ynq1+1oLaN56Xp+x2S9ZBcBJuwmEI96cgh65RE89qnkCLOhvihZ65pnTsIitM+834OlE27rQZM2+a5fcO1XrbMhdDXgJw7ztatXHDr4WoCzK7T6X2iApZYzTCz5ZpQKaGm1CzQp211DnvyosmGbvUmoUVU6yAVZm/uiVk4XaZvOY3M9DARLBGvLrYnE8PbDEB5lSReyBa8P/yINL2lFjB9nq4rF8IcnzxGXyc6SYkObWfG0+ooHg= Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0293B214D198F4D9DBD08814F5990DM5PR00MB0293namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92bd6d7c-e172-4b50-5871-08d6816561da X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 19:02:55.0884 (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-Transport-CrossTenantHeadersStamped: DM5PR00MB0421 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 19:03:04 -0000 --_000_DM5PR00MB0293B214D198F4D9DBD08814F5990DM5PR00MB0293namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEpvaG7igJlzIGxvZ2ljLiAgVGhlIHBoeXNpY2FsIHJlc291cmNlIGFuZCBs b2dpY2FsIHJlc291cmNlIHNob3VsZCB1c2UgZGlmZmVyZW50IGlkZW50aWZpZXJzLiAgRm9ydHVu YXRlbHksIHdlIGFscmVhZHkgaGF2ZSDigJxyZXNvdXJjZeKAnSBhbmQg4oCccmVxX2F1ZOKAnSBm b3IgdGhlc2UgcGFyYW1ldGVycy4gIEkgYmVsaWV2ZSB3ZeKAmXJlIGdvb2QgdG8gZ28sIGFzLWlz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDE5IDEw OjU2IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNoZXBo ZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEN Cg0KDQpJIGRvbid0IHRoaW5rIHRoZXkgYXJlIG5lY2Vzc2FyaWx5IG11dHVhbGx5IGV4Y2x1c2l2 ZSwgdGhhdCBpcyB3aHkgSSB0aGluayB0aGVyZSBpcyB2YWx1ZSBpbiBhbGxvd2luZyB0aGVtIHRv IGJlIHNwZWNpZmllZCBzZXBhcmF0ZWx5Lg0KDQpBcyBhbiBBUyBpbiB0aGUgZGlzdHJpYnV0ZWQg T0F1dGggY2FzZSBrbm93aW5nIHRoYXQgYSBjbGllbnQgaW50ZXJhY3Rpbmcgd2l0aCBSUyBodHRw czovL2ZpcmUuaGhzLmNvbSBhcyB0aGUgcmVzb3VyY2Ugd2FudHMgYSBPQXV0aCB0b2tlbiB3aXRo IGFuIGF1ZGllbmNlIG9mIEhIUyBhbmQgYSBzY29wZSBvZiByZWFkLg0KDQpXaXRob3V0IHByb29m IG9mIHBvc3Nlc3Npb24gd2UgbmVlZCB0byBrZWVwIGJhZCBSUyBmcm9tIGFza2luZyBmb3IgdG9r ZW5zIHdpdGggc2NvcGVzIGFuZCBhdWRpZW5jZXMgb2Ygb3RoZXIgUlMgdGhhdCBjYW4gYmUgcmVw bGF5ZWQuDQoNCkkgcmVhbGx5IGxpa2Uga2VlcGluZyB0aGUgcmVzb3VyY2Ugc2ltcGxlIGFuZCB1 bnNwb29mYWJsZSwgaXQgaXMgdGhlIFVSSSBvZiB0aGUgUlMgd2hlcmUgeW91IGFyZSBwcmVzZW50 aW5nIHRoZSBBVC4NCg0KSSBwcmVmZXIgdG8ga2VlcCB0aGF0IHNlcGFyYXRlIGZyb20gdGhlIGxv Z2ljYWwgcmVzb3VyY2UgdGhhdCBtYXkgc3BhbiBtb3JlIHRoYW4gb25lIFJTIGVuZHBvaW50Lg0K DQpNZXJnaW5nIHRoZSB0d28gYW5kIHdlIGFyZSBwcm9iYWJseSBiYWNrIGF0IHRoZSBBUyBsb29r aW5nIGludG8gdGhlIFVSSSB0byBmaWd1cmUgb3V0IHdoaWNoIG9uZSBpdCBpcy4gIEkgdGhpbmsg dGhhdCBpcyBoYXJkZXIgZm9yIGltcGxlbWVudGF0aW9ucyBhbmQgbW9yZSBsaWtlbHkgdG8gaGF2 ZSBzZWN1cml0eSBpc3N1ZXMgZG93biB0aGUgcm9hZC4NCg0KSm9obiBCLg0KT24gMS8yMy8yMDE5 IDE6NDQgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOg0KSGkgYWxsLA0KdGhhbmtzIGZvciB5 b3UgcGF0aWVuY2UuIEJyaWFuIGFuZCBteXNlbGYgaXRlcmF0ZWQgb24gbW9kaWZ5aW5nIHRoZSB0 ZXh0IHRvIGNvdmVyIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgdXNlIGNhc2UsIGhpZ2hsaWdodGlu ZyB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIGdvaW5nIHRoYXQgcm91dGUuIFlvdSBjYW4g ZmluZCB0aGUgcmV2aXNlZCB0ZXh0IGluIGh0dHBzOi8vZ2l0aHViLmNvbS92aWJyb25ldC9pLWQv YmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLnhtbCwgc2Vl IHRoZSBjb21taXRzIGluIHRoZSBoaXN0b3J5IGZyb20gSmFudWFyeSAyMSBmb3IgdGhlIHNwZWNp ZmljIGNoYW5nZXMuDQpOb3RlOiBJIGFsc28gaGFkIGEgY2hhdCB3aXRoIEpvaG4gb2ZmbGluZSwg YW5kIGhlIGV4cHJlc3NlZCB0aGUgZGVzaXJlIHRvIHNwbGl0IHRoZSByZXNvdXJjZSBwYXJhbWV0 ZXIgaW4gdHdvIGRpc3RpbmN0IHBhcmFtZXRlcnMgdG8gYmV0dGVyIHNpZ25hbCB0aGUgaW50ZW5k ZWQgdXNhZ2UuIEkgYW0gc3VyZSBoZSBjYW4gZWxhYm9yYXRlLiBJIGhhdmUgbm90aGluZyBhZ2Fp bnN0IGl0IGluIHByaW5jaXBsZSwgYXMgbG9uZyBhcyB3ZSBsZWF2ZSBub3RoaW5nIGFzIGV4ZXJj aXNlIHRvIHRoZSByZWFkZXIgYW5kIHdlIGFyZSB2ZXJ5IGNsZWFyIG9uIHVzYWdlIChlLmcuIG11 dHVhbCBleGNsdXNpdml0eSwgZXRjKSBidXQgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gc3BlYWsg dyBCcmlhbiBhYm91dCBpdC4gSWYgdGhlIGRpc2N1c3Npb24gc3RyZXRjaGVzIGZ1cnRoZXIsIEkg d291bGQgc3VnZ2VzdCB3ZSBwYXVzZSBpdCBhbmQgbGV0IGhpbSBlbmpveSBoaXMgdGltZSBvZmYg Zm9yIHRoZSByZXN0IG9mIHRoZSB3ZWVrLg0KDQpPbiBNb24sIEphbiAyMSwgMjAxOSBhdCA1OjM1 IFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZh YXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNClRoYW5rIHlvdSBndXlzIQ0KDQoNCk9uIE1vbmRh eSwgSmFudWFyeSAyMSwgMjAxOSwgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvQGF1dGgwLmNv bTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpIaSBSaWZhYXQsDQphYnNvbHV0 ZWx5LiBCcmlhbiBhbmQgbXlzZWxmIGFscmVhZHkgc3RhcnRlZCB3b3JraW5nIG9uIHNvbWUgbGFu Z3VhZ2UsIGhvd2V2ZXIgdGhpcyB3ZWVrIGhlIGlzIGluIHZhY2F0aW9uIGhlbmNlIGl0IG1pZ2h0 IHRha2UgZmV3IGRheXMgYmVmb3JlIHdlIGNvbWUgYmFjayB0byB0aGUgbGlzdCB3aXRoIHNvbWV0 aGluZy4NCkNoZWVycywNClYuDQoNCk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDk6MzUgQU0gUmlm YWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRm QGdtYWlsLmNvbT4+IHdyb3RlOg0KQnJpYW4sIFZpdHRvcmlvLA0KDQpUbyBtb3ZlIHRoaXMgZGlz Y3Vzc2lvbiBmb3J3YXJkLCBjYW4geW91IGd1eXMgc3VnZ2VzdCBzb21lIHRleHQgdG8gbWFrZSB0 aGUgbG9naWNhbCBpZGVudGlmaWVyIHVzYWdlIGNsZWFyZXI/DQoNClJlZ2FyZHMsDQogUmlmYWF0 DQoNCg0KT24gTW9uLCBKYW4gMjEsIDIwMTkgYXQgMTA6MzIgQU0gQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KQXMgSSBzdWdnZXN0ZWQgYmVmb3Jl LCBJIGRvIHRoaW5rIHRoYXQncyB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgZHJhZnQncyBkZWZp bml0aW9uIG9mICdyZXNvdXJjZScgYXMgYSBVUkkuIEFuZCB0aGF0IHBlcmhhcHMgYWxsIHRoYXQn cyBuZWVkZWQgaXMgc29tZSBtaW5vciBhZGp1c3RtZW50IGFuZC9vciBhdWdtZW50YXRpb24gb2Yg c29tZSB0ZXh0IHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCg0KT24gU3VuLCBKYW4gMjAsIDIwMTkg YXQgNzozOSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpW aXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCltzZW50IHRvIEpvaG4gb25seSBieSBtaXN0YWtl LCByZXNlbmRpbmcgdG8gdGhlIE1MXQ0KDQoNCkluIEF6dXJlIEFEIHYxICYgQURGUywgdGhhdCdz IHJlc291cmNlLiBJdCBjb3VsZCBiZSB1c2VkIGZvciBib3RoIG5ldHdvcmsgYW5kIGxvZ2ljYWwg aWRzLCB3aXRoIHRoZSBjb25jcmV0ZSB1c2FnZSBpbiB0aGUgd2lsZCBJIGRlc2NyaWJlZCBlYXJs aWVyLg0KSW4gQXp1cmUgQUQgdjIsIHRoZSByZXNvdXJjZSBhcyBleHBsaWNpdCBwYXJhbWV0ZXIg KG5ldHdvcmssIGxvZ2ljIG9yIG90aGVyd2lzZSkgaXMgZ29uZSBhbmQgaXMgZXhwcmVzc2VkIGFz IHBhcnQgb2YgdGhlIHNjb3BlIHN0cmluZyBvZiBhbGwgdGhlIHNjb3BlcyByZXF1ZXN0ZWQgZm9y IGEgZ2l2ZW4gcmVzb3VyY2UtIGJ1dCBpdCBzdGlsbCBleGlzdCBpbiBwcmFjdGljZSB0aG8gYXMg aXQgc3RpbGwgZW5kIHVwIGluIHRoZSByZXN1bHRpbmcgYXVkIG9mIHRoZSBpc3N1ZWQgdG9rZW4u DQpUaGlzIGlzIDkgbW9udGhzIG9sZCBpbmZvIGhlbmNlDQoNCk9uIFN1biwgSmFuIDIwLCAyMDE5 IGF0IDE3OjU4IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tPj4gd3JvdGU6DQoNCldoYXQgaXMgdGhlIHBhcmFtZXRlciB0aGF0IE1pY3Jvc29m dCBpcyB1c2luZz8NCk9uIDEvMjAvMjAxOSAzOjU5IFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSB3cm90 ZToNCkZpcnN0IG9mIGFsbCwgaXQgd2Fzbid0IG15IGludGVudCB0byBkaXNydXB0IHRoZSBlc3Rh Ymxpc2hlZCBwcm9jZXNzLiBJbiBteSBmb3JtZXIgcG9zaXRpb24gSSB3YXNuJ3QgbW9uaXRvcmlu ZyB0aG9zZSBkaXNjdXNzaW9ucyBoZW5jZSBJIGRpZG4ndCBoYXZlIGEgY2hhbmNlIHRvIG9mZmVy IGZlZWRiYWNrLiBXaGVuIEkgc2F3IHNvbWV0aGluZyB0aGF0IGdhdmUgbWUgdGhlIGltcHJlc3Np b24gbWlnaHQgbGVhZCB0byBpc3N1ZXMsIGFuZCBnaXZlbiB0aGF0IEkgd29ya2VkIHdpdGggYWN0 dWFsIGRlcGxveW1lbnRzIGFuZCBkZXZlbG9wZXJzIHVzaW5nIGEgc2ltaWxhciBwYXJhbWV0ZXIg Zm9yIGEgbG9uZyB0aW1lLCBJIHRob3VnaHQgcHJ1ZGVudCB0byBicmluZyB0aGlzIHVwLiBJIHJl YWxseSBhcHByZWNpYXRlIFJpZmFhdCdzIHN0YW5jZSBvbiB0aGlzLiBFbmQgb2YgcHJlYW1ibGUu DQoNClVsdGltYXRlbHkgbXkgZ29hbCBpcyBmb3IgZGV2ZWxvcGVycyB0byBoYXZlIGd1aWRhbmNl IG9uIGhvdyB0byB3b3JrIHdpdGggdGhlIGNvbmNlcHQgb2YgbG9naWNhbCByZXNvdXJjZSBpbiBh IHN0YW5kYXJkIGNvbXBsaWFudCB3YXksIGhlbmNlIGl0IGRvZXNuJ3Qgc3RyaWN0bHkgbWF0dGVy IHdoZXRoZXIgdGhlIGRlZmluaXRpb24gb2YgdGhlIGNvcnJlc3BvbmRpbmcgcGFyYW1ldGVyIGxp dmVzIGluIG9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgb3IgZWxzZXdoZXJlLg0KVGhhdCBzYWlk LiBSZWFkaW5nIHRocm91Z2ggdGhlIGRyYWZ0LCBpdCB3b3VsZCBhcHBlYXIgdGhhdCBtb3N0IG9m IHRoZSByZWFzb25zIGZvciB3aGljaCB0aGUgc3BlYyB3YXMgY3JlYXRlZCBhcHBseSB0byBib3Ro IHRoZSBuZXR3b3JrIGFkZHJlc3NhYmxlIGFuZCB0aGUgbG9naWNhbCByZXNvdXJjZSB0eXBlczog a25vd2luZyB3aGF0IGtleXMgdG8gdXNlIHRvIGVuY3J5cHQgdGhlIHRva2VuLCBjb25zdHJhaW4g YWNjZXNzIHRva2VucyB0byB0aGUgaW50ZW5kZWQgYXVkaWVuY2UsIGF2b2lkaW5nIG92ZXJsb2Fk aW5nIHNjb3BlcyB3aXRoIHJlc291cmNlIGluZGljYXRpbmcgcGFydHMuLi4gdGhvc2UgYWxsIGFw cGx5IHRvIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIGxvZ2ljIGlkZW50aWZpZXJzIGFsaWtlLiBB bmQgYm90aCBwYXJhbWV0ZXJzIGFyZSBleHBlY3RlZCB0byByZXN1bHQgaW4gYXVkaWVuY2UgcmVz dHJpY3RlZCB0b2tlbnMuIEl0IHNlZW1zIHRoZSBvbmx5IGRpZmZlcmVuY2UgY29tZXMgYXQgdG9r ZW4gdXNhZ2UgdGltZSwgd2l0aCB0aGUgbmV0d29yayBhZGRyZXNzYWJsZSBjYXNlIGdpdmluZyBt b3JlIGd1YXJhbnRlZXMgdGhhdCB0aGUgdG9rZW4gd2lsbCBnbyB0byBpdHMgaW50ZW5kZWQgcmVj aXBpZW50LCBidXQgdGhlIHJlcXVlc3QgYW5kIGF1ZGllbmNlIHJlc3RyaWN0aW9uIHN5bnRheCBz ZWVtcyB0byBiZSBleGFjdGx5IHRoZSBzYW1lLg0KT24gdG9wIG9mIHRoaXM6IGluIHRoZSA5OS45 OTklIG9mIHRoZSBzY2VuYXJpb3MgSSBlbmNvdW50ZXJlZCBpbiB0aGUgd2lsZCBpbiB0aGUgbGFz dCA1IHllYXJzIG9mIHVzaW5nIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4gdGhlIE1TIGVjb3N5 c3RlbSwgdGhlIHJlc291cmNlIGlkZW50aWZpZXIgd2FzIGtub3duIGF0IGRlc2lnbiB0aW1lOiB0 aGUgZGV2ZWxvcGVyIGRpc2NvdmVyZWQgaXQgb3V0IG9mIGJhbmQgYW5kIHBsYWNlZCBpdCBpbiB0 aGUgYXBwIGNvbmZpZyBhdCBkZXBsb3ltZW50IHRpbWUuIFRob3NlIGFyZW4ndCBmcmluZ2UgY2Fz ZXMgSSBvY2Nhc2lvbmFsbHkgZW5jb3VudGVyZWQ6IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4g QXp1cmUgQUQgdjEgYW5kIEFERlMgd2FzIG1hbmRhdG9yeSwgaGVuY2UgbGl0ZXJhbGx5IGV2ZXJ5 IHNvbHV0aW9uIGkgc2F3IG9yIHRvdWNoZWQgdXNlZCBpdC4gQXMgQnJpYW4gc3VnZ2VzdGVkLCB0 aGlzIGlzIGEgc2NlbmFyaW8gd2hlcmUgdGhlIHNlY3VyaXR5IGFkdmFudGFnZXMgb2YgdGhlIG5l dHdvcmsgYWRkcmVzc2FibGUgY2FzZSBhcmVuJ3QgYXMgcHJvbm91bmNlZCBhcyBpbiB0aGUgY2Fz ZSBpbiB3aGljaCB0aGUgY2xpZW50IGRpc2NvdmVycyB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciBh dCBydW50aW1lLiBUaGlzIGlzbid0IGp1c3QgYmVjYXVzZSB0aGVyZSBpcyBubyBzcGVjaWZpY2F0 aW9uIHN1Z2dlc3RpbmcgbG9jYXRpb24gc2hvdWxkIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLCBp dCdzIGJlY2F1c2UgdGhlcmUgYXJlIG1hbnkgcHJhY3RpY2FsIGFkdmFudGFnZXMgYXQgZGV2ZWxv cG1lbnQgYW5kIGRlcGxveW1lbnQgdGltZSB0byBiZSBhYmxlIHRvIHVzZSBsb2dpY2FsIGlkZW50 aWZpZXJzLSBhbmQgaWYgdGhlIGNvbmNyZXRlIHNlY3VyaXR5IGFkdmFudGFnZXMgZG9uJ3QgYXBw bHkgdG8gdGhlIHRoZWlyIGNhc2UsIHBlb3BsZSB3aWxsIHNpbXBseSBub3QgY29tcGx5Lg0KDQpJ biBzdW1tYXJ5OiBjcmVhdGluZyB0d28gZGlmZmVyZW50IHBhcmFtZXRlcnMgaW4gdHdvIGRpZmZl cmVudCBkb2N1bWVudHMgaXMgYmV0dGVyIHRoYW4gaWdub3JpbmcgaGUgbG9naWNhbCBpZGVudGlm aWVyIGNhc2UgYWx0b2dldGhlciwgaG93ZXZlciBJIHRoaW5rIHRoYXQgbm90IGFja25vd2xlZGdp bmcgdGhlIGxvZ2ljYWwgaWQgY2FzZSBpbiBvYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIGlzIGdv aW5nIHRvIGNyZWF0ZSBjb25mdXNpb24gYW5kIHVsdGltYXRlbHkgbm90IGJlIGFzIHVzZWZ1bCB0 byB0aGUgZGV2ZWxvcGVyIGNvbW11bml0eSBhcyBpdCBjb3VsZCBiZS4NCg0KDQoNCk9uIFNhdCwg SmFuIDE5LCAyMDE5IGF0IDEyOjM4IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMSB0byBNaWtlIGFuZCBKb2hu4oCZ cyBjb21tZW50cy4NClBoaWwNCg0KT24gSmFuIDE5LCAyMDE5LCBhdCAxMjozNCBQTSwgTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv Ok1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJ IGFsc28gYWdyZWUgdGhhdCDigJxyZXNvdXJjZeKAnSBzaG91bGQgYmUgYSBzcGVjaWZpYyBuZXR3 b3JrLWFkZHJlc3NhYmxlIFVSTCB3aGVyZWFzIGEgc2VwYXJhdGUgYXVkaWVuY2UgcGFyYW1ldGVy IChsaWtlIOKAnGF1ZOKAnSBpbiBKV1RzKSBjYW4gcmVmZXIgdG8gb25lIG9yIG1vcmUgbG9naWNh bCByZXNvdXJjZXMuICBUaGV5IGFyZSBkaWZmZXJlbnQsIGlmIHJlbGF0ZWQsIHRoaW5ncy4NCg0K Tm90ZSB0aGF0IHRoZSBBQ0UgV0cgaXMgcHJvcG9zaW5nIHRvIHJlZ2lzdGVyIGEgbG9naWNhbCBh dWRpZW5jZSBwYXJhbWV0ZXIg4oCccmVxX2F1ZOKAnSBpbiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxIC0gcGFydGx5IGJhc2VkIG9uIGZl ZWRiYWNrIGZyb20gT0F1dGggV0cgbWVtYmVycy4gIFRoaXMgaXMgYSBnZW5lcmFsIE9BdXRoIHBh cmFtZXRlciwgd2hpY2ggYW55IE9BdXRoIGRlcGxveW1lbnQgd2lsbCBiZSBhYmxlIHRvIHVzZS4N Cg0KSSB0aGVyZWZvcmUgYmVsaWV2ZSB0aGF0IG5vIGNoYW5nZXMgYXJlIG5lZWRlZCB0byBkcmFm dC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMsIGFzIHRoZSBsb2dpY2FsIGF1ZGllbmNl IHdvcmsgaXMgYWxyZWFkeSBoYXBwZW5pbmcgaW4gYW5vdGhlciBkcmFmdC4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBTYXR1cmRheSwg SmFudWFyeSAxOSwgMjAxOSA5OjAxIEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQpDYzog Vml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzpWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBJRVRGIG9hdXRoIFdH IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMQ0KDQpXZSBuZWVkIHRvIGRlY2lkZSBpZiB3ZSB3YW50IHRvIG1ha2UgYSBj aGFuZ2UuDQoNCkZvciBzZWN1cml0eSB3ZSBhcmUgbG9jYXRpb24gY2VudHJpYy4NCg0KSSBwcmVm ZXIgdG8ga2VlcCByZXNvdXJjZSBsb2NhdGlvbiBzZXBhcmF0ZSBmcm9tIGxvZ2ljYWwgYXVkaWVu Y2UgdGhhdCBjYW4gYmUgYSBzY29wZSBvciBvdGhlciBwYXJhbWV0ZXIuDQoNCklmIGJlY29tZXMg aGFyZGVyIGZvciBwZW9wbGUgdG8gdXNlIHRoZSBwYXJhbWV0ZXIgY29ycmVjdGx5IGlmIHdlIGFy ZSB0b28gZmxleGlibGUuDQoNCkkgd291bGQgcmF0aGVyIGhhdmUgYSBzZXBhcmF0ZSBsb2dpY2Fs IGF1ZGllbmNlIHBhcmFtZXRlciBpZiB3ZSB0aGluayB3ZSB3YW50IG9uZS4NCg0KSm9obiBCLg0K DQpPbiBTYXQsIEphbiAxOSwgMjAxOSwgMTE6NDEgQU0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4gd3Jv dGU6DQpObyBhcG9sb2d5IG5lZWRlZCwgUmlmYWF0LiBBbmQgSSBhcG9sb2dpemUgaWYgd2hhdCBJ IHNhaWQgY2FtZSBvZmYgdGhlIHdyb25nIHdheS4gSSB3YXMganVzdCB0cnlpbmcgdG8gbWFrZSBs aWdodCBvZiB0aGUgc2l0dWF0aW9uLi4gQW5kIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IGJl IGhhbXN0cnVuZyBieSB0aGUgcHJvY2VzcyBhbmQgdGhlcmUgYXJlIHRpbWVzIHdoZW4gaXQgbWFr ZXMgc2Vuc2UgdG8gYmUgZmxleGlibGUgd2l0aCB0aGluZ3MuDQoNCk9uIEZyaSwgSmFuIDE4LCAy MDE5IGF0IDY6MjIgUE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KU29ycnkgQnJpYW4sIEkgd2Fz IG5vdCBjbGVhciB3aXRoIG15IHN0YXRlbWVudC4NCkkgbWVhbnQgdG8gc2F5IHRoYXQgd2Ugc2hv dWxkIG5vdCBhbGxvdyB0aGUgcHJvY2VzcyB0byBwcmV2ZW50IHRoZSBXRyBmcm9tIHByb2R1Y2lu ZyBhIHF1YWxpdHkgZG9jdW1lbnQgd2l0aG91dCBpc3N1ZXMsIGFzc3VtaW5nIHRoZXJlIGlzIGFu IGlzc3VlIGluIHRoZSBmaXJzdCBwbGFjZS4NCklkZWFsbHkgd2Ugd2FudCB0byBnZXQgdGhlc2Ug aWRlbnRpZmllZCBkdXJpbmcgdGhlIFdHTEMsIGJ1dCB0aGluZ3MgaGFwcGVuIGFuZCBzb21ldGlt ZXMgdGhlIFdHIG1pc3NlcyBzb21ldGhpbmcuDQoNCkkgaGVhciB5b3UgYW5kIGFncmVlIHRoYXQg dGhpcyBtYWtlIHRoaW5ncyBkaWZmaWN1bHQgZm9yIGF1dGhvcnMuIFdlIHdpbGwgbWFrZSBzdXJl IHRoYXQgdGhpcyBkb2VzIG5vdCBiZWNvbWUgdGhlIG5vcm0sIGFuZCB3ZSB3aWxsIHRyeSB0byBz dGljayB0byB0aGUgcHJvY2VzcyBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KDQpSZWdhcmRzLA0KIFJp ZmFhdA0KDQoNCk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDU6MzUgUE0gQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbT4+IHdyb3RlOg0KVGhhbmtzIFJpZmFhdC4gUHJvY2VzcyBpcyBhcyBwcm9jZXNzIGRvZXMs IHJpZ2h0PyBJIGRvIGtpbmRhIHdhbnQgdG8gZ3J1bWJsZSBhYm91dCBXR0NMIGhhdmluZyBwYXNz ZWQgYWxyZWFkeSBidXQgdGhhdCdzIG1vc3RseSBiZWNhdXNlIHJlcGx5aW5nIHRvIHRoZXNlIGtp bmRzIG9mIHRocmVhZHMgaXMgaGFyZCBmb3IgbWUgYW5kIEknbGwganVzdCBnZXQgb3ZlciBpdC4u Lg0KDQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoaW5ncywgdGhlIHNlY3VyaXR5IGNvbmNlcm5z IGNvbWUgaW50byBwbGF5IHdoZW4gdGhlIGNsaWVudCBpcyBiZWluZyB0b2xkIHRoZSBieSB0aGUg cmVzb3VyY2UgaG93IHRvIGlkZW50aXR5IHRoZSByZXNvdXJjZSBsaWtlIGlzIGRlc2NyaWJlZCBp biBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXN0cmlidXRl ZC0wMSBhbmQgdXNpbmcgdGhlIGFjdHVhbCBsb2NhdGlvbiBpbiB0aGF0IGNvbnRleHQgLGFsb25n IHdpdGggc29tZSBvdGhlciBjaGVja3MgcHJlc2NyaWJlZCBpbiB0aGF0IGRyYWZ0LCBwcmV2ZW50 cyB0aGUga2luZCBvZiBpc3N1ZXMgSm9obiBkZXNjcmliZWQgZWFybGllciBpbiB0aGUgdGhyZWFk Lg0KDQpJbiBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGtub3dzIHRoZSByZXNvdXJjZSBhIHByaW9y aSBvciBvdXQtb2YtYmFuZCBvciBjb25maWd1cmVkIG9yIHdoYXRldmVyLCBJIGRvbid0IHRoaW5r IHRoZSBzYW1lIHNlY3VyaXR5IGNvbmNlcm5zIGFyaXNlLiBBbmQgdXNpbmcgc3VjaCBhIGtub3du IHZhbHVlLCBiZSBpdCBhbiBhY3R1YWwgbG9jYXRpb24gb3IgbG9naWNhbCByZXByZXNlbnRhdGlv biwgd291bGQgYmUgb2theS4NCg0KVGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQgaXMgYWRt aXR0ZWRseSBzb21ld2hhdCBsb2NhdGlvbi1jZW50cmljIGluIGhvdyBpdCB0YWxrcyBhYm91dCB0 aGUgdmFsdWUgb2YgdGhlICdyZXNvdXJjZScgcGFyYW1ldGVyLiBCdXQgdWx0aW1hdGVseSBpdCBk ZWZpbmVzIGl0IGFzIGFuIGFic29sdXRlIFVSSSB0aGF0IGluZGljYXRlcyB0aGUgbG9jYXRpb24g b2YgdGhlIHRhcmdldCBzZXJ2aWNlIG9yIHJlc291cmNlIHdoZXJlIGFjY2VzcyBpcyBiZWluZyBy ZXF1ZXN0ZWQuIEEgbG9jYXRpb24gY2FuIGJlIHZhcnlpbmcgc2hhZGVzIG9mIGFic3RyYWN0IGFu ZCBJJ2Qgc2F5IHRoYXQgdXNpbmcgYSBVUkkgYXMgJ3Jlc291cmNlJyBwYXJhbWV0ZXIgdmFsdWUg dGhhdCdzIGEgbG9naWNhbCBpZGVudGlmaWVyIHRoYXQgcG9pbnRzIHRvIHNvbWUgcmVzb3VyY2Ug aXMgd2VsbCB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgZHJhZnQuDQoNClNvIG1heWJlIHRoZSBk cmFmdCBpcyBva2F5IGFzIGlzPw0KDQpPciBwZXJoYXBzIHRoYXQncyB0b28gbXVjaCB0byBiZSBs ZWZ0IGFzIGFuIGV4ZXJjaXNlciB0byB0aGUgcmVhZGVyPyAgQW5kIHNvbWUgdGV4dCBzaG91bGQg YmUgYWRkZWQgYW5kL29yIGFkanVzdGVkIHNvIHRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIGRyYWZ0 IHdvdWxkIGJlIGEgbGl0dGxlIG1vcmUgb3Blbi9jbGVhciBhYm91dCB0aGUgcGFyYW1ldGVyIHZh bHVlIHBvdGVudGlhbGx5IGJlaW5nIG1vcmUgb2YgYSBsb2dpY2FsIG9yIGFic3RyYWN0IGlkZW50 aWZpZXIgYW5kIG5vdCBuZWNlc3NhcmlseSBhIG5ldHdvcmsgYWRkcmVzc2FibGUgVVJMPw0KDQoN Cg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgMToxOCBQTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJp ZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6 DQpJIHdvdWxkbid0IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHRoZSBwcm9jZXNzLg0KSWYgaXQgbWFr ZXMgc2Vuc2UgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCwgdGhlbiBmZWVsIGZyZWUgdG8gZG8gdGhh dC4NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAzOjA4 IFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIu Y29tPj4gd3JvdGU6DQpZZXMgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgY2FuIGJlIHByb3ZpZGVkIGJ5 ICJzY29wZSINCg0KU29tZSBpbXBsZW1lbnRhdGlvbnMgbGlrZSBQaW5nIGFuZCBBdXRoMCBoYXZl IGJlZW4gYWRkaW5nIGFub3RoZXIgcGFyYW1ldGVyICJhdWQiIHRvIGlkZW50aWZ5IHRoZSBsb2dp Y2FsIHJlc291cmNlIGFuZCB0aGVuIHVzaW5nIHNjb3BlcyB0byBkZWZpbmUgcGVybWlzc2lvbnMg dG8gdGhlIHJlc291cmNlLg0KDQpGb3J0dW5hdGVseSwgd2UgYXJlIHVzaW5nIGEgZGlmZmVyZW50 IHBhcmFtZXRlciBuYW1lIHNvIG5vdCBzdGVwcGluZyBvbiB0aGF0Li4NCg0KV2UgY291bGQgZ28g YmFjayBhbmQgdHJ5IHRvIGFkZCB0ZXh0IGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVuY2UsIGJ1dCB3 ZSBhcmUgcXVpdGUgbGF0ZSBpbiB0aGUgcHJvY2Vzcy4NCg0KSSBhZ3JlZSB0aGF0IGEgbG9naWNh bCByZXNvdXJjZSBwYXJhbWV0ZXIgbWF5IGJlIGhlbHBmdWwsIGJ1dCBwZXJoYXBzIGl0IHNob3Vs ZCBiZSBhIHNlcGFyYXRlIGRyYWZ0Lg0KDQpKb2huIEIuDQoNCk9uIEZyaSwgSmFuIDE4LCAyMDE5 IGF0IDQ6MzggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5j b208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCkRvZXNu4oCZdCB0aGUg4oCc c2NvcGXigJ0gcGFyYW1ldGVyIGFscmVhZHkgcHJvdmlkZSBhIG1lYW5zIG9mIHNwZWNpZnlpbmcg YSBsb2dpY2FsIGlkZW50aWZpZXI/DQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpB V1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2Nj aSA8Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuLmNv bUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBGcmlkYXksIEphbnVhcnkgMTgsIDIwMTkgYXQgNTo0 NyBBTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tPj4NCkNjOiBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAg Zm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0KDQpUaGFua3MgSm9o biBmb3IgdGhlIGJhY2tncm91bmQuDQpJIGFncmVlIHRoYXQgZnJvbSB0aGUgY2xpZW50IHZhbGlk YXRpb24gUG9WLCBoYXZpbmcgYW4gaWRlbnRpZmllciBjb3JyZXNwb25kaW5nIHRvIGEgbG9jYXRp b24gbWFrZXMgdGhpbmdzIG1vcmUgc29saWQuDQpUaGF0IHNhaWQ6IHRoZSB1c2Ugb2YgbG9naWNh bCBpZGVudGlmaWVycyBpcyB3aWRlc3ByZWFkLCBhcyBpdCBoYXMgc2lnbmlmaWNhbnQgcHJhY3Rp Y2FsIGFkdmFudGFnZXMgKHRoaW5rIG9mIHNlcnZpY2VzIHRoYXQgYXNzaWduIGdlbmVyYXRlZCBo b3N0aW5nIFVSTHMgb25seSBhdCBkZXBsb3ltZW50IHRpbWUsIG9yIHNlcnZpY2VzIHRoYXQgYXJl IHNvbWVob3cgZ3JvdXBlZCB1bmRlciB0aGUgc2FtZSBsb2dpY2FsIGF1ZGllbmNlIGFjcm9zcyBy ZWdpb25zL2Vudmlyb25tZW50L2RlcGxveW1lbnRzKS4gUGVvcGxlIHdvbid0IHN0b3AgdXNpbmcg bG9naWNhbCBpZGVudGlmaWVycywgYmVjYXVzZSB0aGV5IG9mdGVuIGhhdmUgbm8gYWx0ZXJuYXRp dmUgKGdlbmVyYXRpbmcgbmV3IGF1ZGllbmNlcyBvbiB0aGUgZmx5IGF0IHRoZSBBUyBldmVyeSB0 aW1lIHlvdSBkbyBhIGRlcGxveW1lbnQgYW5kIGdldCBhc3NpZ25lZCBhIG5ldyBVUkwgY2FuIGJl IHVuZmVhc2libGUpLiBMZWF2aW5nIGEgd2lkZWx5IHVzZWQgYXBwcm9hY2ggYXMgZXhlcmNpc2Ug dG8gdGhlIHJlYWRlciBzZWVtcyBhIGRpc3NlcnZpY2UgdG8gdGhlIGNvbW11bml0eSwgZ2l2ZW4g dGhhdCB0aGlzIG1pZ2h0IGxlYWQgdG8gdmVuZG9ycyAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IGFu ZCBBdXRoMCkga2VlcGluZyB0aGVpciBvd24gcHJvcHJpZXRhcnkgcGFyYW1ldGVycywgb3IgZGV2 ZWxvcGVycyBtaXN1c2luZyB0aGUgb25lcyBpbiBwbGFjZTsgd291bGQgbWFrZSBpdCBoYXJkIGZv ciBTREsgZGV2ZWxvcGVycyB0byBwcm92aWRlIGxpYnJhcmllcyB0aGF0IHdvcmsgb3V0IG9mIHRo ZSBib3ggd2l0aCBkaWZmZXJlbnQgQVNlczsgYW5kIHNvIG9uLg0KV291bGQgaXQgYmUgZmVhc2li bGUgdG8gYWRkIHN1Y2ggcGFyYW1ldGVyIGRpcmVjdGx5IGluIHRoaXMgc3BlYz8gVGhhdCB3b3Vs ZCBlbGltaW5hdGUgdGhlIGludGVyb3AgaXNzdWVzLCBhbmQgYWxzbyBnaXZlcyB1cyBhIGNoYW5j ZSB0byBmdWxseSB3YXJuIHBlb3BsZSBhYm91dCB0aGUgc2VjdXJpdHkgc2hvcnRjb21pbmdzIG9m IGNob29zaW5nIHRoYXQgYXBwcm9hY2guDQoNCg0KDQpPbiBUaHUsIEphbiAxNywgMjAxOSBhdCA0 OjMyIFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdq dGIuY29tPj4gd3JvdGU6DQoNCldlIGhhdmUgZGlzY3Vzc2VkIHRoaXMuDQoNCkF1ZGllbmNlcyBj YW4gY2VydGFpbmx5IGJlIGxvZ2ljYWwgaWRlbnRpZmllcnMuDQoNClRoaXMgaG93ZXZlciBpcyBh IG1vcmUgc3BlY2lmaWMgbG9jYXRpb24uICBUaGUgQVMgaXMgZnJlZSB0byBtYXAgdGhlIGxvY2F0 aW9uIGludG8gc29tZSBhYnN0cmFjdCBhdWRpZW5jZSBpbiB0aGUgQVQuDQoNCkZyb20gYSBzZWN1 cml0eSBwb2ludCBvZiB2aWV3IG9uY2UgdGhlIGNsaWVudCBzdGFydHMgYXNraW5nIGZvciBsb2dp Y2FsIHJlc291cmNlcyBpdCBjYW4gYmUgdHJpY2tlZCBpbnRvIGFza2luZyBmb3IgdGhlIHdyb25n IG9uZSBhcyBhIGJhZCByZXNvdXJjZSBjYW4gYWx3YXlzIGxpZSBhYm91dCB3aGF0IGxvZ2ljYWwg cmVzb3VyY2UgaXQgaXMuDQoNCklmIHdlIHdlcmUgdG8gY2hhbmdlIGl0LCBob3cgYSBjbGllbnQg d291bGQgdmFsaWRhdGUgaXQgYmVjb21lcyBjaGFsbGVuZ2luZyB0byBpbXBvc3NpYmxlLg0KDQpU aGUgQVMgaXMgZnJlZSB0byBkbyB3aGF0ZXZlciBtYXBwaW5nIG9mIGxvY2F0aW9ucyB0byBpZGVu dGlmaWVycyBpdCBuZWVkcyBmb3IgYWNjZXNzIHRva2Vucy4NCg0KU29tZSBpbXBsZW1lbnRhdGlv bnMgbWF5IHdhbnQgdG8ga2VlcCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbGlrZSBsb2dpY2FsIGF1 ZGllbmNlLCBidXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgZnJvbSByZXNvdXJjZS4NCg0KSm9o biBCLg0KT24gMS8xNy8yMDE5IDk6NTYgQU0sIFJpZmFhdCBTaGVraC1ZdXNlZiB3cm90ZToNCkhp IFZpdHRvcmlvLA0KDQpUaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGNvcGllZCBmb3JtIHRoZSBhYnN0 cmFjdCBvZiB0aGUgZHJhZnQgaXRzZWxmLg0KDQoNCkF1dGhvcnMsDQoNClNob3VsZCB0aGUgZHJh ZnQgYmUgdXBkYXRlZCB0byBjb3ZlciB0aGUgbG9naWNhbCBpZGVudGlmaWVyIGNhc2U/DQoNClJl Z2FyZHMsDQogUmlmYWF0DQoNCg0KT24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgODoxOSBBTSBWaXR0 b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5j b20+PiB3cm90ZToNCkhpIFJpZmFhdCwNCm9uZSBkZXRhaWwuIFRoZSB0ZWNoIHN1bW1hcnkgc2F5 cw0KDQoNCkFuIGV4dGVuc2lvbiB0byB0aGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3 b3JrIGRlZmluaW5nIHJlcXVlc3QNCg0KcGFyYW1ldGVycyB0aGF0IGVuYWJsZSBhIGNsaWVudCB0 byBleHBsaWNpdGx5IHNpZ25hbCB0byBhbiBhdXRob3JpemF0aW9uIHNlcnZlcg0KDQphYm91dCB0 aGUgbG9jYXRpb24gb2YgdGhlIHByb3RlY3RlZCByZXNvdXJjZShzKSB0byB3aGljaCBpdCBpcyBy ZXF1ZXN0aW5nDQoNCmFjY2Vzcy4NCkJ1dCBhdCBsZWFzdCBpbiB0aGUgTWljcm9zb2Z0IGltcGxl bWVudGF0aW9uLCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciBkb2Vzbid0IGhhdmUgdG8gYmUgYSBu ZXR3b3JrIGFkZHJlc3NhYmxlIFVSTCAoYW5kIGlmIGl0IGlzLCBpdCBkb2Vzbid0IHN0cmljdGx5 IG5lZWQgdG8gbWF0Y2ggdGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbikuIEl0IGNhbiBiZSBh IGxvZ2ljYWwgaWRlbnRpZmllciwgdGhvIHVzaW5nIHRoZSBhY3R1YWwgcmVzb3VyY2UgbG9jYXRp b24gdGhlcmUgaGFzIGJlbmVmaXRzIChkb21haW4gb3duZXJzaGlwIGNoZWNrLCBwcmV2ZW50aW9u IG9mIHRva2VuIGZvcndhcmRpbmcgZXRjKS4NClNhbWUgZm9yIEF1dGgwLCB0aGUgYXVkaWVuY2Ug cGFyYW1ldGVyIGlzIGEgbG9naWNhbCBpZGVudGlmaWVyIHJhdGhlciB0aGFuIGEgbG9jYXRpb24u DQoNCg0KDQpPbiBXZWQsIEphbiAxNiwgMjAxOSBhdCA2OjMyIFBNIFJpZmFhdCBTaGVraC1ZdXNl ZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCkFsbCwNCg0KVGhlIGZvbGxvd2luZyBpcyB0aGUgZmlyc3Qgc2hlcGhlcmQgd3JpdGUt dXAgZm9yIHRoZSBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEgZG9jdW1l bnQuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMvc2hlcGhlcmR3cml0ZXVwLw0KDQpQbGVhc2UsIHRha2UgYSBsb29r IGFuZCBsZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZy4NCg0KUmVnYXJkcywNCiBSaWZh YXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcg bGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklE RU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k IHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0K --_000_DM5PR00MB0293B214D198F4D9DBD08814F5990DM5PR00MB0293namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5JIGFncmVlIHdpdGggSm9obuKAmXMgbG9naWMuJm5ic3A7IFRoZSBwaHlzaWNhbCByZXNvdXJj ZSBhbmQgbG9naWNhbCByZXNvdXJjZSBzaG91bGQgdXNlIGRpZmZlcmVudCBpZGVudGlmaWVycy4m bmJzcDsgRm9ydHVuYXRlbHksIHdlIGFscmVhZHkgaGF2ZSDigJxyZXNvdXJjZeKAnSBhbmQg4oCc cmVxX2F1ZOKAnSBmb3IgdGhlc2UgcGFyYW1ldGVycy4mbmJzcDsgSSBiZWxpZXZlIHdl4oCZcmUg Z29vZCB0byBnbywNCiBhcy1pcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0 O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpKb2huIEJy YWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDE5IDEwOjU2 IEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3JzLTAxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIGRvbid0IHRoaW5rIHRo ZXkgYXJlIG5lY2Vzc2FyaWx5IG11dHVhbGx5IGV4Y2x1c2l2ZSwgdGhhdCBpcyB3aHkgSSB0aGlu ayB0aGVyZSBpcyB2YWx1ZSBpbiBhbGxvd2luZyB0aGVtIHRvIGJlIHNwZWNpZmllZCBzZXBhcmF0 ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHA+QXMgYW4gQVMgaW4gdGhlIGRpc3RyaWJ1dGVkIE9BdXRo IGNhc2Uga25vd2luZyB0aGF0IGEgY2xpZW50IGludGVyYWN0aW5nIHdpdGggUlMNCjxhIGhyZWY9 Imh0dHBzOi8vZmlyZS5oaHMuY29tIj5odHRwczovL2ZpcmUuaGhzLmNvbTwvYT4gYXMgdGhlIHJl c291cmNlIHdhbnRzIGEgT0F1dGggdG9rZW4gd2l0aCBhbiBhdWRpZW5jZSBvZiBISFMgYW5kIGEg c2NvcGUgb2YgcmVhZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+V2l0aG91dCBwcm9vZiBvZiBwb3Nz ZXNzaW9uIHdlIG5lZWQgdG8ga2VlcCBiYWQgUlMgZnJvbSBhc2tpbmcgZm9yIHRva2VucyB3aXRo IHNjb3BlcyBhbmQgYXVkaWVuY2VzIG9mIG90aGVyIFJTIHRoYXQgY2FuIGJlIHJlcGxheWVkLjxv OnA+PC9vOnA+PC9wPg0KPHA+SSByZWFsbHkgbGlrZSBrZWVwaW5nIHRoZSByZXNvdXJjZSBzaW1w bGUgYW5kIHVuc3Bvb2ZhYmxlLCBpdCBpcyB0aGUgVVJJIG9mIHRoZSBSUyB3aGVyZSB5b3UgYXJl IHByZXNlbnRpbmcgdGhlIEFULjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBwcmVmZXIgdG8ga2VlcCB0 aGF0IHNlcGFyYXRlIGZyb20gdGhlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCBtYXkgc3BhbiBtb3Jl IHRoYW4gb25lIFJTIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+TWVyZ2luZyB0aGUgdHdv IGFuZCB3ZSBhcmUgcHJvYmFibHkgYmFjayBhdCB0aGUgQVMgbG9va2luZyBpbnRvIHRoZSBVUkkg dG8gZmlndXJlIG91dCB3aGljaCBvbmUgaXQgaXMuJm5ic3A7IEkgdGhpbmsgdGhhdCBpcyBoYXJk ZXIgZm9yIGltcGxlbWVudGF0aW9ucyBhbmQgbW9yZSBsaWtlbHkgdG8gaGF2ZSBzZWN1cml0eSBp c3N1ZXMgZG93biB0aGUgcm9hZC48bzpwPjwvbzpwPjwvcD4NCjxwPkpvaG4gQi48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxLzIzLzIwMTkgMTo0NCBQTSwg Vml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rcyBmb3IgeW91IHBhdGllbmNlLiBCcmlhbiBh bmQgbXlzZWxmIGl0ZXJhdGVkIG9uIG1vZGlmeWluZyB0aGUgdGV4dCB0byBjb3ZlciB0aGUgbG9n aWNhbCBpZGVudGlmaWVyIHVzZSBjYXNlLCBoaWdobGlnaHRpbmcgdGhlIHNlY3VyaXR5IGltcGxp Y2F0aW9ucyBvZiBnb2luZyB0aGF0IHJvdXRlLiBZb3UgY2FuIGZpbmQgdGhlIHJldmlzZWQgdGV4 dCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS92aWJyb25ldC9pLWQvYmxvYi9t YXN0ZXIvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLnhtbCI+aHR0cHM6Ly9n aXRodWIuY29tL3ZpYnJvbmV0L2ktZC9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLW9hdXRoLXJlc291 cmNlLWluZGljYXRvcnMueG1sPC9hPiwNCiBzZWUgdGhlIGNvbW1pdHMgaW4gdGhlIGhpc3Rvcnkg ZnJvbSBKYW51YXJ5IDIxIGZvciB0aGUgc3BlY2lmaWMgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGU6IEkgYWxzbyBoYWQgYSBj aGF0IHdpdGggSm9obiBvZmZsaW5lLCBhbmQgaGUgZXhwcmVzc2VkIHRoZSBkZXNpcmUgdG8gc3Bs aXQgdGhlIHJlc291cmNlIHBhcmFtZXRlciBpbiB0d28gZGlzdGluY3QgcGFyYW1ldGVycyB0byBi ZXR0ZXIgc2lnbmFsIHRoZSBpbnRlbmRlZCB1c2FnZS4gSSBhbSBzdXJlIGhlIGNhbiBlbGFib3Jh dGUuIEkgaGF2ZSBub3RoaW5nIGFnYWluc3QgaXQgaW4gcHJpbmNpcGxlLCBhcw0KIGxvbmcgYXMg d2UgbGVhdmUgbm90aGluZyBhcyBleGVyY2lzZSB0byB0aGUgcmVhZGVyIGFuZCB3ZSBhcmUgdmVy eSBjbGVhciBvbiB1c2FnZSAoZS5nLiBtdXR1YWwgZXhjbHVzaXZpdHksIGV0YykgYnV0IGRpZG4n dCBoYXZlIGEgY2hhbmNlIHRvIHNwZWFrIHcgQnJpYW4gYWJvdXQgaXQuIElmIHRoZSBkaXNjdXNz aW9uIHN0cmV0Y2hlcyBmdXJ0aGVyLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgcGF1c2UgaXQgYW5kIGxl dCBoaW0gZW5qb3kgaGlzIHRpbWUNCiBvZmYgZm9yIHRoZSByZXN0IG9mIHRoZSB3ZWVrLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDU6MzUgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8 YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIj5yaWZhYXQuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBndXlzISA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiBNb25kYXksIEphbnVhcnkgMjEs IDIwMTksIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0 aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFJpZmFhdCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YWJzb2x1dGVseS4gQnJpYW4gYW5kIG15c2VsZiBhbHJlYWR5IHN0YXJ0ZWQgd29ya2luZyBvbiBz b21lIGxhbmd1YWdlLCBob3dldmVyIHRoaXMgd2VlayBoZSBpcyBpbiB2YWNhdGlvbiBoZW5jZSBp dCBtaWdodCB0YWtlIGZldyBkYXlzIGJlZm9yZSB3ZSBjb21lIGJhY2sgdG8gdGhlIGxpc3Qgd2l0 aCBzb21ldGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5WLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEphbiAyMSwgMjAxOSBhdCA5OjM1IEFNIFJpZmFhdCBTaGVraC1Z dXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaWFu LCBWaXR0b3JpbywgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UbyBtb3ZlIHRoaXMgZGlzY3Vzc2lvbiBmb3J3YXJkLCBjYW4geW91IGd1eXMgc3VnZ2VzdCBz b21lIHRleHQgdG8gbWFrZSB0aGUgbG9naWNhbCBpZGVudGlmaWVyIHVzYWdlIGNsZWFyZXI/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEphbiAyMSwgMjAxOSBhdCAxMDozMiBBTSBCcmlhbiBDYW1wYmVs bCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHN1Z2dlc3RlZCBiZWZvcmUsIEkgZG8gdGhp bmsgdGhhdCdzIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkcmFmdCdzIGRlZmluaXRpb24gb2Yg J3Jlc291cmNlJyBhcyBhIFVSSS4gQW5kIHRoYXQgcGVyaGFwcyBhbGwgdGhhdCdzIG5lZWRlZCBp cyBzb21lIG1pbm9yIGFkanVzdG1lbnQgYW5kL29yIGF1Z21lbnRhdGlvbiBvZiBzb21lIHRleHQg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTdW4sIEphbiAyMCwgMjAxOSBhdCA3OjM5IFBNIFZpdHRvcmlvIEJl cnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9i bGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNi41cHQ7Y29sb3I6IzMxMzEzMTtiYWNrZ3JvdW5kOndoaXRlIj5bc2Vu dCB0byBKb2huIG9ubHkgYnkgbWlzdGFrZSwgcmVzZW5kaW5nIHRvIHRoZSBNTF08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE2LjVwdDtjb2xvcjojMzEzMTMxO2JhY2tncm91bmQ6d2hpdGUiPjxi cj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuNXB0O2NvbG9yOiMzMTMxMzE7 YmFja2dyb3VuZDp3aGl0ZSI+SW4gQXp1cmUgQUQgdjEgJmFtcDsgQURGUywgdGhhdCdzJm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMzEzMTMxIj5yZXNvdXJjZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjVw dDtjb2xvcjojMzEzMTMxO2JhY2tncm91bmQ6d2hpdGUiPi4gSXQgY291bGQNCiBiZSB1c2VkIGZv ciBib3RoIG5ldHdvcmsgYW5kIGxvZ2ljYWwgaWRzLCB3aXRoIHRoZSBjb25jcmV0ZSB1c2FnZSBp biB0aGUgd2lsZCBJIGRlc2NyaWJlZCBlYXJsaWVyLjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzEzMTMxIj5J biBBenVyZSBBRCB2MiwgdGhlIHJlc291cmNlIGFzIGV4cGxpY2l0IHBhcmFtZXRlciAobmV0d29y aywgbG9naWMgb3Igb3RoZXJ3aXNlKSBpcyBnb25lIGFuZCBpcyBleHByZXNzZWQgYXMgcGFydCBv ZiB0aGUgc2NvcGUgc3RyaW5nIG9mIGFsbCB0aGUgc2NvcGVzIHJlcXVlc3RlZCBmb3IgYSBnaXZl biByZXNvdXJjZS0gYnV0IGl0IHN0aWxsIGV4aXN0IGluIHByYWN0aWNlDQogdGhvIGFzIGl0IHN0 aWxsIGVuZCB1cCBpbiB0aGUgcmVzdWx0aW5nJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMzEzMTMxIj5hdWQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiMzMTMxMzEiPiZuYnNwO29mIHRoZSBpc3N1ZWQgdG9rZW4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMzMTMxMzEiPlRoaXMgaXMgOSBtb250aHMgb2xkIGluZm8gaGVu Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTdW4sIEphbiAyMCwgMjAxOSBhdCAxNzo1OCBKb2huIEJyYWRsZXkg Jmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZl N2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHA+V2hhdCBpcyB0aGUgcGFyYW1ldGVyIHRoYXQgTWljcm9zb2Z0 IGlzIHVzaW5nPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDEvMjAvMjAxOSAzOjU5IFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZpcnN0IG9mIGFsbCwgaXQgd2Fzbid0IG15IGludGVudCB0byBkaXNydXB0 IHRoZSBlc3RhYmxpc2hlZCBwcm9jZXNzLiBJbiBteSBmb3JtZXIgcG9zaXRpb24gSSB3YXNuJ3Qg bW9uaXRvcmluZyB0aG9zZSBkaXNjdXNzaW9ucyBoZW5jZSBJIGRpZG4ndCBoYXZlIGEgY2hhbmNl IHRvIG9mZmVyIGZlZWRiYWNrLiBXaGVuIEkgc2F3IHNvbWV0aGluZyB0aGF0IGdhdmUgbWUgdGhl IGltcHJlc3Npb24gbWlnaHQgbGVhZA0KIHRvIGlzc3VlcywgYW5kIGdpdmVuIHRoYXQgSSB3b3Jr ZWQgd2l0aCBhY3R1YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNpbmcgYSBzaW1pbGFy IHBhcmFtZXRlciBmb3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50IHRvIGJyaW5nIHRo aXMgdXAuIEkgcmVhbGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9uIHRoaXMuIEVuZCBv ZiBwcmVhbWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5VbHRpbWF0ZWx5IG15IGdvYWwgaXMgZm9yIGRldmVsb3BlcnMgdG8g aGF2ZSBndWlkYW5jZSBvbiBob3cgdG8gd29yayB3aXRoIHRoZSBjb25jZXB0IG9mIGxvZ2ljYWwg cmVzb3VyY2UgaW4gYSBzdGFuZGFyZCBjb21wbGlhbnQgd2F5LCBoZW5jZSBpdCBkb2Vzbid0IHN0 cmljdGx5IG1hdHRlciB3aGV0aGVyIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBjb3JyZXNwb25kaW5n IHBhcmFtZXRlciBsaXZlcyBpbiZuYnNwO29hdXRoLXJlc291cmNlLWluZGljYXRvcnMNCiBvciBl bHNld2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IHNhaWQuIFJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQsIGl0IHdvdWxkIGFwcGVh ciB0aGF0IG1vc3Qgb2YgdGhlIHJlYXNvbnMgZm9yIHdoaWNoIHRoZSBzcGVjIHdhcyBjcmVhdGVk IGFwcGx5IHRvIGJvdGggdGhlIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIHRoZSBsb2dpY2FsIHJl c291cmNlIHR5cGVzOiBrbm93aW5nIHdoYXQga2V5cyB0byB1c2UgdG8gZW5jcnlwdCB0aGUgdG9r ZW4sIGNvbnN0cmFpbg0KIGFjY2VzcyB0b2tlbnMgdG8gdGhlIGludGVuZGVkIGF1ZGllbmNlLCBh dm9pZGluZyBvdmVybG9hZGluZyBzY29wZXMgd2l0aCByZXNvdXJjZSBpbmRpY2F0aW5nIHBhcnRz Li4uIHRob3NlIGFsbCBhcHBseSB0byBuZXR3b3JrIGFkZHJlc3NhYmxlIGFuZCBsb2dpYyBpZGVu dGlmaWVycyBhbGlrZS4gQW5kIGJvdGggcGFyYW1ldGVycyBhcmUgZXhwZWN0ZWQgdG8gcmVzdWx0 IGluIGF1ZGllbmNlIHJlc3RyaWN0ZWQgdG9rZW5zLiBJdCBzZWVtcyB0aGUNCiBvbmx5IGRpZmZl cmVuY2UgY29tZXMgYXQgdG9rZW4gdXNhZ2UgdGltZSwgd2l0aCB0aGUgbmV0d29yayBhZGRyZXNz YWJsZSBjYXNlIGdpdmluZyBtb3JlIGd1YXJhbnRlZXMgdGhhdCB0aGUgdG9rZW4gd2lsbCBnbyB0 byBpdHMgaW50ZW5kZWQgcmVjaXBpZW50LCBidXQgdGhlIHJlcXVlc3QgYW5kIGF1ZGllbmNlIHJl c3RyaWN0aW9uIHN5bnRheCBzZWVtcyB0byBiZSBleGFjdGx5IHRoZSBzYW1lLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdG9wIG9m IHRoaXM6IGluIHRoZSA5OS45OTklIG9mIHRoZSBzY2VuYXJpb3MgSSBlbmNvdW50ZXJlZCBpbiB0 aGUgd2lsZCBpbiB0aGUgbGFzdCA1IHllYXJzIG9mIHVzaW5nIHRoZSByZXNvdXJjZSBwYXJhbWV0 ZXIgaW4gdGhlIE1TIGVjb3N5c3RlbSwgdGhlIHJlc291cmNlIGlkZW50aWZpZXIgd2FzIGtub3du IGF0IGRlc2lnbiB0aW1lOiB0aGUgZGV2ZWxvcGVyIGRpc2NvdmVyZWQgaXQgb3V0IG9mIGJhbmQN CiBhbmQgcGxhY2VkIGl0IGluIHRoZSBhcHAgY29uZmlnIGF0IGRlcGxveW1lbnQgdGltZS4gVGhv c2UgYXJlbid0IGZyaW5nZSBjYXNlcyBJIG9jY2FzaW9uYWxseSBlbmNvdW50ZXJlZDogdGhlIHJl c291cmNlIHBhcmFtZXRlciBpbiBBenVyZSBBRCB2MSBhbmQgQURGUyB3YXMgbWFuZGF0b3J5LCBo ZW5jZSBsaXRlcmFsbHkgZXZlcnkgc29sdXRpb24gaSBzYXcgb3IgdG91Y2hlZCB1c2VkIGl0LiBB cyBCcmlhbiBzdWdnZXN0ZWQsIHRoaXMgaXMgYSBzY2VuYXJpbw0KIHdoZXJlIHRoZSBzZWN1cml0 eSBhZHZhbnRhZ2VzIG9mIHRoZSBuZXR3b3JrIGFkZHJlc3NhYmxlIGNhc2UgYXJlbid0IGFzIHBy b25vdW5jZWQgYXMgaW4gdGhlIGNhc2UgaW4gd2hpY2ggdGhlIGNsaWVudCBkaXNjb3ZlcnMgdGhl IHJlc291cmNlIGlkZW50aWZpZXIgYXQgcnVudGltZS4gVGhpcyBpc24ndCBqdXN0IGJlY2F1c2Ug dGhlcmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBzdWdnZXN0aW5nIGxvY2F0aW9uIHNob3VsZCBiZSBl eHBsaWNpdGx5IGluZGljYXRlZCwNCiBpdCdzIGJlY2F1c2UgdGhlcmUgYXJlIG1hbnkgcHJhY3Rp Y2FsIGFkdmFudGFnZXMgYXQgZGV2ZWxvcG1lbnQgYW5kIGRlcGxveW1lbnQgdGltZSB0byBiZSBh YmxlIHRvIHVzZSBsb2dpY2FsIGlkZW50aWZpZXJzLSBhbmQgaWYgdGhlDQo8aT5jb25jcmV0ZSA8 L2k+c2VjdXJpdHkgYWR2YW50YWdlcyBkb24ndCBhcHBseSB0byB0aGUgdGhlaXIgY2FzZSwgcGVv cGxlIHdpbGwgc2ltcGx5IG5vdCBjb21wbHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHN1bW1hcnk6IGNyZWF0aW5nIHR3byBk aWZmZXJlbnQgcGFyYW1ldGVycyBpbiB0d28gZGlmZmVyZW50IGRvY3VtZW50cyBpcyBiZXR0ZXIg dGhhbiBpZ25vcmluZyBoZSBsb2dpY2FsIGlkZW50aWZpZXIgY2FzZSBhbHRvZ2V0aGVyLCBob3dl dmVyIEkgdGhpbmsgdGhhdCBub3QgYWNrbm93bGVkZ2luZyB0aGUgbG9naWNhbCBpZCBjYXNlIGlu Jm5ic3A7b2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBpcyBnb2luZyB0bw0KIGNyZWF0ZSBjb25m dXNpb24gYW5kIHVsdGltYXRlbHkgbm90IGJlIGFzIHVzZWZ1bCB0byB0aGUgZGV2ZWxvcGVyIGNv bW11bml0eSBhcyBpdCBjb3VsZCBiZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBK YW4gMTksIDIwMTkgYXQgMTI6MzggUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIHRv IE1pa2UgYW5kIEpvaG7igJlzIGNvbW1lbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K T24gSmFuIDE5LCAyMDE5LCBhdCAxMjozNCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWxzbyBhZ3Jl ZSB0aGF0IOKAnHJlc291cmNl4oCdIHNob3VsZCBiZSBhIHNwZWNpZmljIG5ldHdvcmstYWRkcmVz c2FibGUgVVJMIHdoZXJlYXMgYSBzZXBhcmF0ZSBhdWRpZW5jZSBwYXJhbWV0ZXIgKGxpa2Ug4oCc YXVk4oCdIGluIEpXVHMpIGNhbiByZWZlciB0byBvbmUNCiBvciBtb3JlIGxvZ2ljYWwgcmVzb3Vy Y2VzLiZuYnNwOyBUaGV5IGFyZSBkaWZmZXJlbnQsIGlmIHJlbGF0ZWQsIHRoaW5ncy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Ob3RlIHRoYXQgdGhlIEFDRSBXRyBp cyBwcm9wb3NpbmcgdG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciDigJxy ZXFfYXVk4oCdIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxPC9hPiAtIHBhcnRs eSBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIE9BdXRoIFdHIG1lbWJlcnMuJm5ic3A7IFRoaXMgaXMg YSBnZW5lcmFsIE9BdXRoIHBhcmFtZXRlciwgd2hpY2ggYW55IE9BdXRoIGRlcGxveW1lbnQgd2ls bCBiZSBhYmxlIHRvIHVzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5JIHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hhbmdlcyBhcmUgbmVlZGVkIHRvIGRyYWZ0 LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywgYXMgdGhlIGxvZ2ljYWwgYXVkaWVuY2Ug d29yayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90aGVyDQogZHJhZnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy b206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJl aGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51 YXJ5IDE5LCAyMDE5IDk6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDs8 YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5r Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBWaXR0 b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvPTQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQt aWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+V2UgbmVlZCB0byBkZWNpZGUgaWYgd2Ugd2FudCB0byBtYWtlIGEgY2hhbmdl LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkZvciBzZWN1cml0eSB3ZSBhcmUgbG9jYXRpb24gY2VudHJpYy4mbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgcHJlZmVyIHRvIGtlZXAgcmVzb3VyY2UgbG9jYXRpb24gc2VwYXJhdGUgZnJvbSBsb2dpY2Fs IGF1ZGllbmNlIHRoYXQgY2FuIGJlIGEgc2NvcGUgb3Igb3RoZXIgcGFyYW1ldGVyLiZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SWYgYmVjb21lcyBoYXJkZXIgZm9yIHBlb3BsZSB0byB1c2UgdGhlIHBhcmFtZXRlciBj b3JyZWN0bHkgaWYgd2UgYXJlIHRvbyBmbGV4aWJsZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgcmF0 aGVyIGhhdmUgYSBzZXBhcmF0ZSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciBpZiB3ZSB0aGlu ayB3ZSB3YW50IG9uZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFNhdCwgSmFuIDE5 LCAyMDE5LCAxMTo0MSBBTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50 Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGN1cnJlbnRjb2xvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY3VycmVudGNvbG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObyBhcG9sb2d5IG5lZWRlZCwgUmlmYWF0LiBBbmQg SSBhcG9sb2dpemUgaWYgd2hhdCBJIHNhaWQgY2FtZSBvZmYgdGhlIHdyb25nIHdheS4gSSB3YXMg anVzdCB0cnlpbmcgdG8gbWFrZSBsaWdodCBvZiB0aGUgc2l0dWF0aW9uLi4gQW5kIEkgYWdyZWUg dGhhdCB3ZSBzaG91bGQgbm90IGJlIGhhbXN0cnVuZw0KIGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVy ZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBzZW5zZSB0byBiZSBmbGV4aWJsZSB3aXRoIHRoaW5n cy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNjoyMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb3JyeSBCcmlhbiwgSSB3YXMg bm90IGNsZWFyIHdpdGggbXkgc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIG1lYW50IHRvIHNheSB0aGF0IHdlIHNo b3VsZCBub3QgYWxsb3cgdGhlIHByb2Nlc3MgdG8gcHJldmVudCB0aGUgV0cgZnJvbSBwcm9kdWNp bmcgYSBxdWFsaXR5IGRvY3VtZW50IHdpdGhvdXQgaXNzdWVzLCBhc3N1bWluZyB0aGVyZSBpcyBh biBpc3N1ZSBpbiB0aGUgZmlyc3QgcGxhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklkZWFsbHkgd2Ugd2FudCB0byBnZXQgdGhlc2UgaWRl bnRpZmllZCBkdXJpbmcgdGhlIFdHTEMsIGJ1dCB0aGluZ3MgaGFwcGVuIGFuZCBzb21ldGltZXMg dGhlIFdHIG1pc3NlcyBzb21ldGhpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhlYXIgeW91IGFuZCBhZ3JlZSB0aGF0 IHRoaXMgbWFrZSB0aGluZ3MgZGlmZmljdWx0IGZvciBhdXRob3JzLiBXZSB3aWxsIG1ha2Ugc3Vy ZSB0aGF0IHRoaXMgZG9lcyBub3QgYmVjb21lIHRoZSBub3JtLCBhbmQgd2Ugd2lsbCB0cnkgdG8g c3RpY2sgdG8gdGhlIHByb2Nlc3MgYXMgbXVjaCBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEphbiAxOCwgMjAxOSBhdCA1OjM1IFBN IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3INCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJy ZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgUmlmYWF0LiBQcm9jZXNzIGlzIGFzIHBy b2Nlc3MgZG9lcywgcmlnaHQ/IEkgZG8ga2luZGEgd2FudCB0byBncnVtYmxlIGFib3V0IFdHQ0wg aGF2aW5nIHBhc3NlZCBhbHJlYWR5IGJ1dCB0aGF0J3MgbW9zdGx5IGJlY2F1c2UgcmVwbHlpbmcg dG8gdGhlc2Uga2luZHMgb2YgdGhyZWFkcyBpcyBoYXJkDQogZm9yIG1lIGFuZCBJJ2xsIGp1c3Qg Z2V0IG92ZXIgaXQuLi4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoaW5ncywgdGhlIHNlY3Vy aXR5IGNvbmNlcm5zIGNvbWUgaW50byBwbGF5IHdoZW4gdGhlIGNsaWVudCBpcyBiZWluZyB0b2xk IHRoZSBieSB0aGUgcmVzb3VyY2UgaG93IHRvIGlkZW50aXR5IHRoZSByZXNvdXJjZSBsaWtlIGlz IGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtZGlzdHJpYnV0ZWQtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVkLTAxPC9hPiBhbmQg dXNpbmcgdGhlIGFjdHVhbCBsb2NhdGlvbiBpbiB0aGF0IGNvbnRleHQgLGFsb25nIHdpdGggc29t ZSBvdGhlciBjaGVja3MgcHJlc2NyaWJlZCBpbiB0aGF0IGRyYWZ0LCBwcmV2ZW50cyB0aGUga2lu ZCBvZiBpc3N1ZXMgSm9obiBkZXNjcmliZWQgZWFybGllciBpbiB0aGUgdGhyZWFkLg0KPGJyPg0K PGJyPg0KSW4gY2FzZXMgd2hlcmUgdGhlIGNsaWVudCBrbm93cyB0aGUgcmVzb3VyY2UgYSBwcmlv cmkgb3Igb3V0LW9mLWJhbmQgb3IgY29uZmlndXJlZCBvciB3aGF0ZXZlciwgSSBkb24ndCB0aGlu ayB0aGUgc2FtZSBzZWN1cml0eSBjb25jZXJucyBhcmlzZS4gQW5kIHVzaW5nIHN1Y2ggYSBrbm93 biB2YWx1ZSwgYmUgaXQgYW4gYWN0dWFsIGxvY2F0aW9uIG9yIGxvZ2ljYWwgcmVwcmVzZW50YXRp b24sIHdvdWxkIGJlIG9rYXkuPGJyPg0KPGJyPg0KVGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJh ZnQgaXMgYWRtaXR0ZWRseSBzb21ld2hhdCBsb2NhdGlvbi1jZW50cmljIGluIGhvdyBpdCB0YWxr cyBhYm91dCB0aGUgdmFsdWUgb2YgdGhlICdyZXNvdXJjZScgcGFyYW1ldGVyLiBCdXQgdWx0aW1h dGVseSBpdCBkZWZpbmVzIGl0IGFzIGFuIGFic29sdXRlIFVSSSB0aGF0IGluZGljYXRlcyB0aGUg bG9jYXRpb24gb2YgdGhlIHRhcmdldCBzZXJ2aWNlIG9yIHJlc291cmNlIHdoZXJlIGFjY2VzcyBp cw0KIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2NhdGlvbiBjYW4gYmUgdmFyeWluZyBzaGFkZXMgb2Yg YWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1c2luZyBhIFVSSSBhcyAncmVzb3VyY2UnIHBhcmFt ZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2FsIGlkZW50aWZpZXIgdGhhdCBwb2ludHMgdG8gc29t ZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkcmFmdC4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28g bWF5YmUgdGhlIGRyYWZ0IGlzIG9rYXkgYXMgaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PciBwZXJoYXBzIHRoYXQncyB0b28gbXVj aCB0byBiZSBsZWZ0IGFzIGFuIGV4ZXJjaXNlciB0byB0aGUgcmVhZGVyPyZuYnNwOyBBbmQgc29t ZSB0ZXh0IHNob3VsZCBiZSBhZGRlZCBhbmQvb3IgYWRqdXN0ZWQgc28gdGhlIHJlc291cmNlLWlu ZGljYXRvcnMgZHJhZnQgd291bGQgYmUgYSBsaXR0bGUgbW9yZSBvcGVuL2NsZWFyDQogYWJvdXQg dGhlIHBhcmFtZXRlciB2YWx1ZSBwb3RlbnRpYWxseSBiZWluZyBtb3JlIG9mIGEgbG9naWNhbCBv ciBhYnN0cmFjdCBpZGVudGlmaWVyIGFuZCBub3QgbmVjZXNzYXJpbHkgYSBuZXR3b3JrIGFkZHJl c3NhYmxlIFVSTD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgMToxOCBQTSBSaWZh YXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y3VycmVudGNvbG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIHdvdWxkbid0IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHRoZSBwcm9jZXNzLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgaXQgbWFrZXMgc2Vu c2UgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCwgdGhlbiBmZWVsIGZyZWUgdG8gZG8gdGhhdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9o biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0i X2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5ZZXMgdGhlJm5ic3A7bG9naWNhbCByZXNvdXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgJnF1b3Q7 c2NvcGUmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlNvbWUgaW1wbGVtZW50YXRpb25zIGxpa2UgUGluZyBhbmQgQXV0aDAgaGF2 ZSBiZWVuIGFkZGluZyBhbm90aGVyIHBhcmFtZXRlciAmcXVvdDthdWQmcXVvdDsgdG8gaWRlbnRp ZnkgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgYW5kIHRoZW4gdXNpbmcgc2NvcGVzIHRvIGRlZmluZSBw ZXJtaXNzaW9ucyB0byB0aGUgcmVzb3VyY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3J0dW5hdGVseSwgd2UgYXJlIHVzaW5nIGEg ZGlmZmVyZW50Jm5ic3A7cGFyYW1ldGVyIG5hbWUgc28gbm90IHN0ZXBwaW5nIG9uIHRoYXQuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ V2UgY291bGQgZ28gYmFjayBhbmQgdHJ5IHRvIGFkZCB0ZXh0IGV4cGxhaW5pbmcgdGhlIGRpZmZl cmVuY2UsIGJ1dCB3ZSBhcmUgcXVpdGUgbGF0ZSBpbiB0aGUgcHJvY2Vzcy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdy ZWUgdGhhdCBhIGxvZ2ljYWwgcmVzb3VyY2UgcGFyYW1ldGVyJm5ic3A7bWF5IGJlIGhlbHBmdWws IGJ1dCBwZXJoYXBzIGl0IHNob3VsZCBiZSBhIHNlcGFyYXRlIGRyYWZ0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFu IDE4LCAyMDE5IGF0IDQ6MzggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFA YW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpj dXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwy MDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb2VzbuKAmXQgdGhl IOKAnHNjb3Bl4oCdIHBhcmFtZXRlciBhbHJlYWR5IHByb3ZpZGUgYSBtZWFucyBvZiBzcGVjaWZ5 aW5nIGEgbG9naWNhbCBpZGVudGlmaWVyPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBWaXR0 b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuLmNvbUBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51YXJ5IDE4LCAyMDE5IGF0IDU6 NDcgQU08YnI+DQo8Yj5UbzogPC9iPkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOiA8L2I+SUVURiBvYXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQt aWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIEpvaG4gZm9y IHRoZSBiYWNrZ3JvdW5kLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGFncmVlIHRoYXQgZnJvbSB0aGUgY2xpZW50IHZhbGlkYXRpb24gUG9WLCBoYXZp bmcgYW4gaWRlbnRpZmllciBjb3JyZXNwb25kaW5nIHRvIGEgbG9jYXRpb24gbWFrZXMgdGhpbmdz IG1vcmUgc29saWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoYXQgc2FpZDogdGhlIHVzZSBvZiBsb2dpY2FsIGlkZW50aWZpZXJzIGlzIHdp ZGVzcHJlYWQsIGFzIGl0IGhhcyBzaWduaWZpY2FudCBwcmFjdGljYWwgYWR2YW50YWdlcyAodGhp bmsgb2Ygc2VydmljZXMgdGhhdCBhc3NpZ24gZ2VuZXJhdGVkIGhvc3RpbmcgVVJMcyBvbmx5IGF0 IGRlcGxveW1lbnQgdGltZSwNCiBvciBzZXJ2aWNlcyB0aGF0IGFyZSBzb21laG93IGdyb3VwZWQg dW5kZXIgdGhlIHNhbWUgbG9naWNhbCBhdWRpZW5jZSBhY3Jvc3MgcmVnaW9ucy9lbnZpcm9ubWVu dC9kZXBsb3ltZW50cykuIFBlb3BsZSB3b24ndCBzdG9wIHVzaW5nIGxvZ2ljYWwgaWRlbnRpZmll cnMsIGJlY2F1c2UgdGhleSBvZnRlbiBoYXZlIG5vIGFsdGVybmF0aXZlIChnZW5lcmF0aW5nIG5l dyBhdWRpZW5jZXMgb24gdGhlIGZseSBhdCB0aGUgQVMgZXZlcnkgdGltZSB5b3UNCiBkbyBhIGRl cGxveW1lbnQgYW5kIGdldCBhc3NpZ25lZCBhIG5ldyBVUkwgY2FuIGJlIHVuZmVhc2libGUpLiBM ZWF2aW5nIGEgd2lkZWx5IHVzZWQgYXBwcm9hY2ggYXMgZXhlcmNpc2UgdG8gdGhlIHJlYWRlciBz ZWVtcyBhIGRpc3NlcnZpY2UgdG8gdGhlIGNvbW11bml0eSwgZ2l2ZW4gdGhhdCB0aGlzIG1pZ2h0 IGxlYWQgdG8gdmVuZG9ycyAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IGFuZCBBdXRoMCkga2VlcGlu ZyB0aGVpciBvd24gcHJvcHJpZXRhcnkNCiBwYXJhbWV0ZXJzLCBvciBkZXZlbG9wZXJzIG1pc3Vz aW5nIHRoZSBvbmVzIGluIHBsYWNlOyB3b3VsZCBtYWtlIGl0IGhhcmQgZm9yIFNESyBkZXZlbG9w ZXJzIHRvIHByb3ZpZGUgbGlicmFyaWVzIHRoYXQgd29yayBvdXQgb2YgdGhlIGJveCB3aXRoIGRp ZmZlcmVudCBBU2VzOyBhbmQgc28gb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPldvdWxkIGl0IGJlIGZlYXNpYmxlIHRvIGFkZCBzdWNoIHBh cmFtZXRlciBkaXJlY3RseSBpbiB0aGlzIHNwZWM/IFRoYXQgd291bGQgZWxpbWluYXRlIHRoZSBp bnRlcm9wIGlzc3VlcywgYW5kIGFsc28gZ2l2ZXMgdXMgYSBjaGFuY2UgdG8gZnVsbHkgd2FybiBw ZW9wbGUgYWJvdXQgdGhlIHNlY3VyaXR5IHNob3J0Y29taW5ncw0KIG9mIGNob29zaW5nIHRoYXQg YXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDQ6MzIgUE0gSm9obiBC cmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2Js YW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cD5XZSBoYXZlIGRpc2N1c3NlZCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0K PHA+QXVkaWVuY2VzIGNhbiBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVudGlmaWVycy4mbmJzcDsm bmJzcDsgPG86cD48L286cD48L3A+DQo8cD5UaGlzIGhvd2V2ZXIgaXMgYSBtb3JlIHNwZWNpZmlj IGxvY2F0aW9uLiZuYnNwOyBUaGUgQVMgaXMgZnJlZSB0byBtYXAgdGhlIGxvY2F0aW9uIGludG8g c29tZSBhYnN0cmFjdCBhdWRpZW5jZSBpbiB0aGUgQVQuPG86cD48L286cD48L3A+DQo8cD5Gcm9t IGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBvbmNlIHRoZSBjbGllbnQgc3RhcnRzIGFza2luZyBm b3IgbG9naWNhbCByZXNvdXJjZXMgaXQgY2FuIGJlIHRyaWNrZWQgaW50byBhc2tpbmcgZm9yIHRo ZSB3cm9uZyBvbmUgYXMgYSBiYWQgcmVzb3VyY2UgY2FuIGFsd2F5cyBsaWUgYWJvdXQgd2hhdCBs b2dpY2FsIHJlc291cmNlIGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYgd2Ugd2VyZSB0byBj aGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3b3VsZCB2YWxpZGF0ZSBpdCBiZWNvbWVzIGNoYWxsZW5n aW5nIHRvIGltcG9zc2libGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBBUyBpcyBmcmVlIHRv IGRvIHdoYXRldmVyIG1hcHBpbmcgb2YgbG9jYXRpb25zIHRvIGlkZW50aWZpZXJzIGl0IG5lZWRz IGZvciBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPHA+U29tZSBpbXBsZW1lbnRhdGlv bnMgbWF5IHdhbnQgdG8ga2VlcCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbGlrZSBsb2dpY2FsIGF1 ZGllbmNlLCBidXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgZnJvbSByZXNvdXJjZS48bzpwPjwv bzpwPjwvcD4NCjxwPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIDEvMTcvMjAxOSA5OjU2IEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGkgVml0dG9yaW8sDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGNvcGllZCBmb3JtIHRoZSBhYnN0cmFjdCBv ZiB0aGUgZHJhZnQgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkF1dGhvcnMsPC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2hvdWxkIHRoZSBkcmFm dCBiZSB1cGRhdGVkIHRvIGNvdmVyIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgY2FzZT88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDg6MTkgQU0gVml0dG9y aW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20iIHRhcmdl dD0iX2JsYW5rIj5WaXR0b3Jpb0BhdXRoMC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBSaWZhYXQsDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm9uZSBkZXRhaWwu IFRoZSB0ZWNoIHN1bW1hcnkgc2F5czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4w cHQgOC4wcHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0 aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPkFuIGV4dGVuc2lvbiB0byB0aGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJh bWV3b3JrIGRlZmluaW5nIHJlcXVlc3QgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtiYWNrZ3JvdW5kLWF0 dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0 aW9uLXk6MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+cGFyYW1ldGVycyB0aGF0 IGVuYWJsZSBhIGNsaWVudCB0byBleHBsaWNpdGx5IHNpZ25hbCB0byBhbiBhdXRob3JpemF0aW9u IHNlcnZlciA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7 YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5hYm91dCB0aGUgPGI+bG9jYXRpb248L2I+IG9mIHRo ZSBwcm90ZWN0ZWQgcmVzb3VyY2UocykgdG8gd2hpY2ggaXQgaXMgcmVxdWVzdGluZyA8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3Np dGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsYWNrIj5hY2Nlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IGF0IGxlYXN0IGluIHRoZSBNaWNy b3NvZnQgaW1wbGVtZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIGRvZXNuJ3QNCjxp PmhhdmU8L2k+IHRvIGJlIGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkwgKGFuZCBpZiBpdCBpcywg aXQgZG9lc24ndCBzdHJpY3RseSBuZWVkIHRvIG1hdGNoIHRoZSBhY3R1YWwgcmVzb3VyY2UgbG9j YXRpb24pLiBJdCBjYW4gYmUgYSBsb2dpY2FsIGlkZW50aWZpZXIsIHRobyB1c2luZyB0aGUgYWN0 dWFsIHJlc291cmNlIGxvY2F0aW9uIHRoZXJlIGhhcyBiZW5lZml0cyAoZG9tYWluIG93bmVyc2hp cCBjaGVjaywgcHJldmVudGlvbiBvZiB0b2tlbg0KIGZvcndhcmRpbmcgZXRjKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2FtZSBmb3IgQXV0 aDAsIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIgcmF0aGVy IHRoYW4gYSBsb2NhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKYW4gMTYsIDIwMTkgYXQgNjozMiBQ TSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFsbCwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBmb2xsb3dpbmcgaXMgdGhlIGZpcnN0IHNoZXBoZXJkIHdyaXRl LXVwIGZvciB0aGUmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEg ZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1y ZXNvdXJjZS1pbmRpY2F0b3JzL3NoZXBoZXJkd3JpdGV1cC88L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UsIHRha2UgYSBs b29rIGFuZCBsZXQmbmJzcDttZSBrbm93IGlmIEkgbWlzc2VkIGFueXRoaW5nLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiPjxpPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluDQogZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbg0KIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMNCiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4uJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9p Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR00MB0293B214D198F4D9DBD08814F5990DM5PR00MB0293namp_-- From nobody Wed Jan 23 11:51:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735D8130EDD for ; Wed, 23 Jan 2019 11:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iLCiagvmRXs for ; Wed, 23 Jan 2019 11:51:07 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB21212785F for ; Wed, 23 Jan 2019 11:51:06 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id x85-v6so3083811ljb.2 for ; Wed, 23 Jan 2019 11:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N2/4WAV3ou6FqTBO26dQaPuf+aXGc34ZyS73Hb3C0zI=; b=rOf2cFVR1uQ0FINlZ9a2Ioar/FRj0hqjv3VY6AyYScUu+SuIJjngcu9L+PIGYeWdJL Z8ayjNIoLTbOxjBcLFFk+r3OPbrAGXIZXro5+8Xo5lm4L1fCV403vK3S0u45Io+3LJWR b/1i5QWTbKcVs+RMC6IhU1LSCzoKq4SPXYdWuSRP9yNeAfCx6kIQoChhktBzzzBYooA+ QFFFLPA2hpk5/WLMCzXYVWJnxAsGyckF8FO0K1hhjruquZbFEBS7r1Ag7otTy9ALj5so 5QQk5uPN/Np6SUTgyqYfg64Ex651xcc/58b5i8jk+azUehDxWWU6wmLuMUR2wQA7y+y/ SZkw== 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=N2/4WAV3ou6FqTBO26dQaPuf+aXGc34ZyS73Hb3C0zI=; b=CZ7SXB8buMFZlCCexaeT7a+K9jMpakzKgWESEwb0xVKqQbhmtLlp9kCugCRM3Tjezy 9ZM7PmyHd62RF4SXfN0SrUeBvD8L1U/EiF3bOthGXJwRBOU0XTbMgxAJhmedVEGYbfml DpRbeKk59fCnpoi3C5EE9yZGruHPFgHzsKao3IOntjCw9qvjTje1pQgWUX5Rx9sDoO31 Yt3wvgRPchrlK/J446LIiZPMm5hH/8h39+Hl4mWBBQu9h91QcDR3hDu6Vx6n8Yj/MnTT P1qPFLT0Sj3Q73+LDW8Y5/cBoxiiCY9tBzgQZ5kAYYmABN3azGbEcqRzxZDnrHsJSUT6 HJGA== X-Gm-Message-State: AJcUukd5xbbIu7N5t8Cv97bdVNs6hcztpRE6K0zIuPuEcC5PI/Cjs2Je Ysvy3263gll47mOloytGGGUX+7UdWz28p1tMUWSXjw== X-Google-Smtp-Source: ALg8bN5D8YKDJhXCQxKE09yqyfNAGl9SJ8K+yNLbcssUY/Z76HsxkOd8GVeUdBj6gnxaUVJEQ+bWqRWMD1w6iQlOyPA= X-Received: by 2002:a2e:4503:: with SMTP id s3-v6mr3011840lja.44.1548273064683; Wed, 23 Jan 2019 11:51:04 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Wed, 23 Jan 2019 11:50:52 -0800 Message-ID: To: Mike Jones Cc: John Bradley , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000948e00580256a26" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 19:51:14 -0000 --0000000000000948e00580256a26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers. Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs. One additional complication is that this specification is reusing a parameter that is already used in a *very* large number of production systems (small example here ), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion. On Wed, Jan 23, 2019 at 11:03 AM Mike Jones wrote: > I agree with John=E2=80=99s logic. The physical resource and logical res= ource > should use different identifiers. Fortunately, we already have =E2=80=9C= resource=E2=80=9D > and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > I don't think they are necessarily mutually exclusive, that is why I thin= k > there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client interacting > with RS https://fire.hhs.com as the resource wants a OAuth token with an > audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for tokens > with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is the URI > of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the URI t= o > figure out which one it is. I think that is harder for implementations a= nd > more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself iterated on modifying the text > to cover the logical identifier use case, highlighting the security > implications of going that route. You can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-ind= icators.xml, > see the commits in the history from January 21 for the specific changes. > > Note: I also had a chat with John offline, and he expressed the desire to > split the resource parameter in two distinct parameters to better signal > the intended usage. I am sure he can elaborate. I have nothing against it > in principle, as long as we leave nothing as exercise to the reader and w= e > are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a > chance to speak w Brian about it. If the discussion stretches further, I > would suggest we pause it and let him enjoy his time off for the rest of > the week. > > > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci wrote= : > > Hi Rifaat, > > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before w= e > come back to the list with something. > > Cheers, > > V. > > > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > > [sent to John only by mistake, resending to the ML] > > > > In Azure AD v1 & ADFS, that's resource. It could be used for both network > and logical ids, with the concrete usage in the wild I described earlier. > > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > > This is 9 months old info hence > > > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressab= le > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovere= d > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw = or > touched used it. As Brian suggested, this is a scenario where the securit= y > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. Th= is > isn't just because there is no specification suggesting location should b= e > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- an= d > if the *concrete *security advantages don't apply to the their case, > people will simply not comply. > > > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and ultimately > not be as useful to the developer community as it could be. > > > > > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > > +1 to Mike and John=E2=80=99s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network= -addressable URL > whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs= ) can refer to one > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience paramete= r > =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-o= auth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > *Cc:* Vittorio Bertocci ; IETF oau= th > WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that ca= n > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > > > I would rather have a separate logical audience parameter if we think we > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > that.. > > > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000000948e00580256a26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As mentioned below, I agree the two can be separated- but = I also agree with George on the need to be clear an easy to reference for d= evelopers.
Just adding a reference to req_aud would just raise the cycl= omatic complexity of the specs, which is already unusably high for mere mor= tals in the OAuth2/OIDC family of specs.

One addit= ional complication is that this specification is reusing a parameter that i= s already used in a very large number of production systems (small e= xample here), and whose concrete semantic happ= ens to be prevalently logic identifier. If the parameter you are defining h= ere has a different semantic, at the very least it would seem good hygiene = to rename it to avoid collision and confusion.

On Wed, Jan 23, 2019 at= 11:03 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John= =E2=80=99s logic.=C2=A0 The physical resource and logical resource should u= se different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresou= rce=E2=80=9D and =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I be= lieve we=E2=80=99re good to go, as-is.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I= think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting= with RS https://fire.hhs.com= as the resource wants a OAuth token with an audience of HHS and a scope of= read.

Without proof of possession we need to keep bad RS from asking for token= s with scopes and audiences of other RS that can be replayed.=

I really like keeping the resource simple and unspoofable, it is the URI= of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span m= ore than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI = to figure out which one it is.=C2=A0 I think that is harder for implementat= ions and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated o= n modifying the text to cover the logical identifier use case, highlighting= the security implications of going that route. You can find the revised te= xt in=C2=A0https://github.com/vibro= net/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he ex= pressed the desire to split the resource parameter in two distinct paramete= rs to better signal the intended usage. I am sure he can elaborate. I have = nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear o= n usage (e.g. mutual exclusivity, etc) but didn't have a chance to spea= k w Brian about it. If the discussion stretches further, I would suggest we= pause it and let him enjoy his time off for the rest of the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:=

Hi Rifaat,

absolutely. Brian and myself already started working= on some language, however this week he is in vacation hence it might take = few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys sugges= t some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:

As I suggested before, I do think that's within = the bounds of the draft's definition of 'resource' as a URI. An= d that perhaps all that's needed is some minor adjustment and/or augmen= tation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

[sent to John only by mistake, resending to the ML]



In Azure AD v1 & ADFS, that's=C2=A0resource= . It could be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.

In Azure AD v2, = the resource as explicit parameter (network, logic or otherwise) is gone an= d is expressed as part of the scope string of all the scopes requested for = a given resource- but it still exist in practice tho as it still end up in the resulting=C2=A0aud=C2=A0of the issued token.

This is 9 months= old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com>= wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the= established process. In my former position I wasn't monitoring those d= iscussions hence I didn't have a chance to offer feedback. When I saw s= omething that gave me the impression might lead to issues, and given that I worked with actual deployments and developers = using a similar parameter for a long time, I thought prudent to bring this = up. I really appreciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidanc= e on how to work with the concept of logical resource in a standard complia= nt way, hence it doesn't strictly matter whether the definition of the = corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appea= r that most of the reasons for which the spec was created apply to both the= network addressable and the logical resource types: knowing what keys to u= se to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with r= esource indicating parts... those all apply to network addressable and logi= c identifiers alike. And both parameters are expected to result in audience= restricted tokens. It seems the only difference comes at token usage time, with the network addressable ca= se giving more guarantees that the token will go to its intended recipient,= but the request and audience restriction syntax seems to be exactly the sa= me.=C2=A0

On top of this: in the 99.999% of the scenarios I en= countered in the wild in the last 5 years of using the resource parameter i= n the MS ecosystem, the resource identifier was known at design time: the d= eveloper discovered it out of band and placed it in the app config at deployment time. Those aren't fring= e cases I occasionally encountered: the resource parameter in Azure AD v1 a= nd ADFS was mandatory, hence literally every solution i saw or touched used= it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't a= s pronounced as in the case in which the client discovers the resource iden= tifier at runtime. This isn't just because there is no specification su= ggesting location should be explicitly indicated, it's because there are many practical advantages at development and de= ployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, peop= le will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two= different documents is better than ignoring he logical identifier case alt= ogether, however I think that not acknowledging the logical id case in=C2= =A0oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer communit= y as it could be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2= =80=99s comments.=C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40mic= rosoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly bas= ed on feedback from OAuth WG members.=C2=A0 This is a general OAuth paramet= er, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with= things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

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

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract = identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>=
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request=
 
parameters that enable a client to explicitly signal to an authorizati=
on server 
about the location of the protected resource(s) to which it is =
requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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


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


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, 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 me= ssage and any file attachments from your computer. Thank you.

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


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution 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 messa= ge and any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000000948e00580256a26-- From nobody Wed Jan 23 11:55:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A4F130ED0 for ; Wed, 23 Jan 2019 11:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no 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 HXfxuGquRUR5 for ; Wed, 23 Jan 2019 11:55:28 -0800 (PST) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9318412785F for ; Wed, 23 Jan 2019 11:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548273326; bh=r0nWYvRt9fyVr1ScEM1nnAYxzGajV6nM7nCSp6PQBrg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=bLU793ptUryQwThAGIUmWqcxNMBVVmuBYwv9A1OJLPCvrfFqxo7EUugH87xVM5ThNudPP87XNDJJEe5goYB0w+kpNaXIDCkEhKTRLgkFyZPffP+pJPOP3qQ6Utzj3A8No1xermT/IFz+XzKTBr+FGmz50MpA6XZpmGH8TBpAnpKV6xo7EJNBzdZ1KCR+KwG8tsQEsGYBognkRqOLK7g8s1TlCTUd6Y5Xoj7DgOEpSEg8TAPT7Cs1YzLT0BeKnus6W0CPOnaZGK0DpBSD5KKxnLUwQDB85Qkqj/dc1pmI2WRl5u6sLQ0YS3cBcMqxJZgn9nx+IHMaA0PXXoVqNBjJjA== X-YMail-OSG: WasmSEEVM1k33mJjznFoDSUJe6EOubdbNU1UpdRtQFvYWoNLxVbCw0RcfDYCNea gRCHx.9yuLUbrONGrpiyYhYZvJsao3qrhc6ClB90PR_Dtrfx42oqScO2kR7nXcmgIPs.6PCI5uIV _Q4zCy5QpbmF0l0ltksi_zmJC6E2D4E9aYL22OlRDjW0N7yncQ8sKmqa6duMQS5CqGuMD9xZjsid YMm3Fo708mlvXWm4u0OOKwwK.9Ot6Cnz3zTiVbbhvygf6.rPlDq.g6Ipe3FR11vTwI1vZLoaQVLq GrXh_KPqJeagTr0WtJC0wrmeEwGppzxf5NR7S7fYgRUMNjN6OS36feUTgc.BJ4C3b0atuA6m07lK 6JWxnfgTp1H3.ZQAf8Xgkyr72.9jf4QNGfBO2X2oke0hOpz199AnuG4nRFZ30dlK_cT9G2OdanUP Dxcdqoo8jh1VE0RgngW75azknEVI6Ym1UrSmFiZ8GVa01jdR4Vq8QBHAjaMQSpxHbj0ggO8rFvja 3k9pY0tft1d1.rnI_3ZP1M9WQlrVGXSf79jXoUusPXk92yCzDX2xrTm3g6JsQQjz9iYAiu91JHO8 2nZxjg.UxLe7byu3DuuPaMxuEpdPFGJbpGNT_Xplen..1p9X20rk4rGgtlrRaKw7qhGCZbSs2vHn GXIpWjG0qCkBUh2XA79UH.yA8p4m1pJuTP6ZLzJCPn.yqbg4wT.46LcqDNPNNllsKNq4GzgqmMLb iVgETQOsWCY4iobP2oJfcYBNu3IY4U7TDrn97MlCJ8nKWbUiXtQ9vcPRAOleS.GNY2d7tQ6VKA9B 1yud9sislPfXL4ZJWDE9adVj1UbvwRoWetmFFs3VOipAbZU73W_HCIPESnT6qSVihGT_Qv66LwF5 ZiqVaEQMLKpUrxof5hkezlAIzuUkCVapo6YueG848tZa_QNRTPOrBN5QEwXPqS_1NRKiGPyGJA3U oYG1SgpKseEVGNMaRsQbRErzuqkHMDHdWghAM3E6MoNI2ZI50bMhdWP0L0KyKsc35ea11c.np1lr Vbil2Y41B.zfYGa3cGnJ33LG8GMtD3w8I7rlQ5BddRe_9HVuOrLLab4lX4qFLyvjt Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 23 Jan 2019 19:55:26 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9452207dfe015b2a7e22eecd0dcd4f7a; Wed, 23 Jan 2019 19:55:22 +0000 (UTC) To: John Bradley , oauth@ietf.org References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> From: George Fletcher Organization: AOL LLC Message-ID: <57c9bd5a-48ea-601a-f064-8f1c27aadc9c@aol.com> Date: Wed, 23 Jan 2019 14:55:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------837FB3F8AD97254F7C2ECBD1" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 19:55:32 -0000 This is a multi-part message in MIME format. --------------837FB3F8AD97254F7C2ECBD1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit What about deployments where the logical endpoint (https://api.service.example.com/foo) is actually deployed at https://2354353-.api.service.example.com/foo? I've worked with partners where the endpoint URI is unique to a geo-location and that endpoint is returned to the client when providing the token. Requiring exact location URLs force a client to make two token requests in order to get a token for the exact specified location. Maybe I'm missing something? Thanks, George On 1/23/19 1:56 PM, John Bradley wrote: > > I don't think they are necessarily mutually exclusive, that is why I > think there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client > interacting with RS https://fire.hhs.com as the resource wants a OAuth > token with an audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for > tokens with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is the > URI of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the > URI to figure out which one it is.  I think that is harder for > implementations and more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: >> Hi all, >> thanks for you patience. Brian and myself iterated on modifying the >> text to cover the logical identifier use case, highlighting the >> security implications of going that route. You can find the revised >> text in >> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, >> see the commits in the history from January 21 for the specific changes. >> Note: I also had a chat with John offline, and he expressed the >> desire to split the resource parameter in two distinct parameters to >> better signal the intended usage. I am sure he can elaborate. I have >> nothing against it in principle, as long as we leave nothing as >> exercise to the reader and we are very clear on usage (e.g. mutual >> exclusivity, etc) but didn't have a chance to speak w Brian about it. >> If the discussion stretches further, I would suggest we pause it and >> let him enjoy his time off for the rest of the week. >> >> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef >> > wrote: >> >> Thank you guys! >> >> >> On Monday, January 21, 2019, Vittorio Bertocci >> > wrote: >> >> Hi Rifaat, >> absolutely. Brian and myself already started working on some >> language, however this week he is in vacation hence it might >> take few days before we come back to the list with something. >> Cheers, >> V. >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> > wrote: >> >> Brian, Vittorio, >> >> To move this discussion forward, can you guys suggest >> some text to make the logical identifier usage clearer? >> >> Regards, >>  Rifaat >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell >> > > wrote: >> >> As I suggested before, I do think that's within the >> bounds of the draft's definition of 'resource' as a >> URI. And that perhaps all that's needed is some minor >> adjustment and/or augmentation of some text to make >> it more clear. >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> > wrote: >> >> [sent to John only by mistake, resending to the ML] >> >> In Azure AD v1 & ADFS, that's resource. It could >> be used for both network and logical ids, with >> the concrete usage in the wild I described earlier. >> In Azure AD v2, the resource as explicit >> parameter (network, logic or otherwise) is gone >> and is expressed as part of the scope string of >> all the scopes requested for a given resource- >> but it still exist in practice tho as it still >> end up in the resulting aud of the issued token. >> This is 9 months old info hence >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley >> > wrote: >> >> What is the parameter that Microsoft is using? >> >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >>> First of all, it wasn't my intent to disrupt >>> the established process. In my former >>> position I wasn't monitoring those >>> discussions hence I didn't have a chance to >>> offer feedback. When I saw something that >>> gave me the impression might lead to issues, >>> and given that I worked with actual >>> deployments and developers using a similar >>> parameter for a long time, I thought prudent >>> to bring this up. I really appreciate >>> Rifaat's stance on this. End of preamble. >>> >>> Ultimately my goal is for developers to have >>> guidance on how to work with the concept of >>> logical resource in a standard compliant >>> way, hence it doesn't strictly matter >>> whether the definition of the corresponding >>> parameter lives in oauth-resource-indicators >>> or elsewhere. >>> That said. Reading through the draft, it >>> would appear that most of the reasons for >>> which the spec was created apply to both the >>> network addressable and the logical resource >>> types: knowing what keys to use to encrypt >>> the token, constrain access tokens to the >>> intended audience, avoiding overloading >>> scopes with resource indicating parts... >>> those all apply to network addressable and >>> logic identifiers alike. And both parameters >>> are expected to result in audience >>> restricted tokens. It seems the only >>> difference comes at token usage time, with >>> the network addressable case giving more >>> guarantees that the token will go to its >>> intended recipient, but the request and >>> audience restriction syntax seems to be >>> exactly the same. >>> On top of this: in the 99.999% of the >>> scenarios I encountered in the wild in the >>> last 5 years of using the resource parameter >>> in the MS ecosystem, the resource identifier >>> was known at design time: the developer >>> discovered it out of band and placed it in >>> the app config at deployment time. Those >>> aren't fringe cases I occasionally >>> encountered: the resource parameter in Azure >>> AD v1 and ADFS was mandatory, hence >>> literally every solution i saw or touched >>> used it. As Brian suggested, this is a >>> scenario where the security advantages of >>> the network addressable case aren't as >>> pronounced as in the case in which the >>> client discovers the resource identifier at >>> runtime. This isn't just because there is no >>> specification suggesting location should be >>> explicitly indicated, it's because there are >>> many practical advantages at development and >>> deployment time to be able to use logical >>> identifiers- and if the /concrete /security >>> advantages don't apply to the their case, >>> people will simply not comply. >>> >>> In summary: creating two different >>> parameters in two different documents is >>> better than ignoring he logical identifier >>> case altogether, however I think that not >>> acknowledging the logical id case >>> in oauth-resource-indicators is going to >>> create confusion and ultimately not be as >>> useful to the developer community as it >>> could be. >>> >>> >>> >>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt >>> >> > wrote: >>> >>> +1 to Mike and John’s comments. >>> >>> Phil >>> >>> On Jan 19, 2019, at 12:34 PM, Mike Jones >>> >> > >>> wrote: >>> >>>> I also agree that “resource” should be >>>> a specific network-addressable URL >>>> whereas a separate audience parameter >>>> (like “aud” in JWTs) can refer to one >>>> or more logical resources.  They are >>>> different, if related, things. >>>> >>>> Note that the ACE WG is proposing to >>>> register a logical audience parameter >>>> “req_aud” in >>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 >>>> - partly based on feedback from OAuth >>>> WG members.  This is a general OAuth >>>> parameter, which any OAuth deployment >>>> will be able to use. >>>> >>>> I therefore believe that no changes are >>>> needed to >>>> draft-ietf-oauth-resource-indicators, >>>> as the logical audience work is already >>>> happening in another draft. >>>> >>>> -- Mike >>>> >>>> *From:* OAuth >>> > *On >>>> Behalf Of * John Bradley >>>> *Sent:* Saturday, January 19, 2019 9:01 AM >>>> *To:* Brian Campbell >>>> >>> > >>>> *Cc:* Vittorio Bertocci >>>> >>> >; >>>> IETF oauth WG >>> > >>>> *Subject:* Re: [OAUTH-WG] Shepherd >>>> write-up for >>>> draft-ietf-oauth-resource-indicators-01 >>>> >>>> We need to decide if we want to make a >>>> change. >>>> >>>> For security we are location centric. >>>> >>>> I prefer to keep resource location >>>> separate from logical audience that can >>>> be a scope or other parameter. >>>> >>>> If becomes harder for people to use the >>>> parameter correctly if we are too >>>> flexible. >>>> >>>> I would rather have a separate logical >>>> audience parameter if we think we want >>>> one. >>>> >>>> John B. >>>> >>>> On Sat, Jan 19, 2019, 11:41 AM Brian >>>> Campbell >>> wrote: >>>> >>>> No apology needed, Rifaat. And I >>>> apologize if what I said came off >>>> the wrong way. I was just trying to >>>> make light of the situation.. And I >>>> agree that we should not be >>>> hamstrung by the process and there >>>> are times when it makes sense to be >>>> flexible with things. >>>> >>>> On Fri, Jan 18, 2019 at 6:22 PM >>>> Rifaat Shekh-Yusef >>>> >>> > wrote: >>>> >>>> Sorry Brian, I was not clear >>>> with my statement. >>>> >>>> I meant to say that we should >>>> not allow the process to >>>> prevent the WG from producing a >>>> quality document without >>>> issues, assuming there is an >>>> issue in the first place. >>>> >>>> Ideally we want to get these >>>> identified during the WGLC, but >>>> things happen and sometimes the >>>> WG misses something. >>>> >>>> I hear you and agree that this >>>> make things difficult for >>>> authors. We will make sure that >>>> this does not become the norm, >>>> and we will try to stick to the >>>> process as much as possible. >>>> >>>> Regards, >>>> >>>>  Rifaat >>>> >>>> On Fri, Jan 18, 2019 at 5:35 PM >>>> Brian Campbell >>>> >>> > >>>> wrote: >>>> >>>> Thanks Rifaat. Process is >>>> as process does, right? I >>>> do kinda want to grumble >>>> about WGCL having passed >>>> already but that's mostly >>>> because replying to these >>>> kinds of threads is hard >>>> for me and I'll just get >>>> over it... >>>> >>>> As far as I understand >>>> things, the security >>>> concerns come into play >>>> when the client is being >>>> told the by the resource >>>> how to identity the >>>> resource like is described >>>> in >>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 >>>> and using the actual >>>> location in that context >>>> ,along with some other >>>> checks prescribed in that >>>> draft, prevents the kind of >>>> issues John described >>>> earlier in the thread. >>>> >>>> In cases where the client >>>> knows the resource a priori >>>> or out-of-band or >>>> configured or whatever, I >>>> don't think the same >>>> security concerns arise. >>>> And using such a known >>>> value, be it an actual >>>> location or logical >>>> representation, would be okay. >>>> >>>> The resource-indicators >>>> draft is admittedly >>>> somewhat location-centric >>>> in how it talks about the >>>> value of the 'resource' >>>> parameter. But ultimately >>>> it defines it as an >>>> absolute URI that indicates >>>> the location of the target >>>> service or resource where >>>> access is being requested. >>>> A location can be varying >>>> shades of abstract and I'd >>>> say that using a URI as >>>> 'resource' parameter value >>>> that's a logical identifier >>>> that points to some >>>> resource is well within the >>>> bounds of the draft. >>>> >>>> So maybe the draft is okay >>>> as is? >>>> >>>> Or perhaps that's too much >>>> to be left as an exerciser >>>> to the reader? And some >>>> text should be added and/or >>>> adjusted so the >>>> resource-indicators draft >>>> would be a little more >>>> open/clear about the >>>> parameter value potentially >>>> being more of a logical or >>>> abstract identifier and not >>>> necessarily a network >>>> addressable URL? >>>> >>>> On Fri, Jan 18, 2019 at >>>> 1:18 PM Rifaat Shekh-Yusef >>>> >>> > >>>> wrote: >>>> >>>> I wouldn't worry too >>>> much about the process. >>>> >>>> If it makes sense to >>>> update the document, >>>> then feel free to do that. >>>> >>>> Regards, >>>> >>>>  Rifaat >>>> >>>> On Fri, Jan 18, 2019 at >>>> 3:08 PM John Bradley >>>> >>> > >>>> wrote: >>>> >>>> Yes the logical >>>> resource can be >>>> provided by "scope" >>>> >>>> Some >>>> implementations >>>> like Ping and Auth0 >>>> have been adding >>>> another parameter >>>> "aud" to identify >>>> the logical >>>> resource and then >>>> using scopes to >>>> define permissions >>>> to the resource. >>>> >>>> Fortunately, we are >>>> using a >>>> different parameter >>>> name so not >>>> stepping on that.. >>>> >>>> We could go back >>>> and try to add text >>>> explaining the >>>> difference, but we >>>> are quite late in >>>> the process. >>>> >>>> I agree that a >>>> logical resource >>>> parameter may be >>>> helpful, but >>>> perhaps it should >>>> be a separate draft. >>>> >>>> John B. >>>> >>>> On Fri, Jan 18, >>>> 2019 at 4:38 PM >>>> Richard Backman, >>>> Annabelle >>>> >>> > >>>> wrote: >>>> >>>> Doesn’t the >>>> “scope” >>>> parameter >>>> already provide >>>> a means of >>>> specifying a >>>> logical identifier? >>>> >>>> -- >>>> >>>> Annabelle >>>> Richard Backman >>>> >>>> AWS Identity >>>> >>>> *From: *OAuth >>>> >>> > >>>> on behalf of >>>> Vittorio >>>> Bertocci >>>> >>> > >>>> *Date: *Friday, >>>> January 18, >>>> 2019 at 5:47 AM >>>> *To: *John >>>> Bradley >>>> >>> > >>>> *Cc: *IETF >>>> oauth WG >>>> >>> > >>>> *Subject: *Re: >>>> [OAUTH-WG] >>>> Shepherd >>>> write-up for >>>> draft-ietf-oauth-resource-indicators-01 >>>> >>>> Thanks John for >>>> the background. >>>> >>>> I agree that >>>> from the client >>>> validation PoV, >>>> having an >>>> identifier >>>> corresponding >>>> to a location >>>> makes things >>>> more solid. >>>> >>>> That said: the >>>> use of logical >>>> identifiers is >>>> widespread, as >>>> it has >>>> significant >>>> practical >>>> advantages >>>> (think of >>>> services that >>>> assign >>>> generated >>>> hosting URLs >>>> only at >>>> deployment >>>> time, or >>>> services that >>>> are somehow >>>> grouped under >>>> the same >>>> logical >>>> audience across >>>> regions/environment/deployments). >>>> People won't >>>> stop using >>>> logical >>>> identifiers, >>>> because they >>>> often have no >>>> alternative >>>> (generating new >>>> audiences on >>>> the fly at the >>>> AS every time >>>> you do a >>>> deployment and >>>> get assigned a >>>> new URL can be >>>> unfeasible). >>>> Leaving a >>>> widely used >>>> approach as >>>> exercise to the >>>> reader seems a >>>> disservice to >>>> the community, >>>> given that this >>>> might lead to >>>> vendors (for >>>> example >>>> Microsoft and >>>> Auth0) keeping >>>> their own >>>> proprietary >>>> parameters, or >>>> developers >>>> misusing the >>>> ones in place; >>>> would make it >>>> hard for SDK >>>> developers to >>>> provide >>>> libraries that >>>> work out of the >>>> box with >>>> different ASes; >>>> and so on. >>>> >>>> Would it be >>>> feasible to add >>>> such parameter >>>> directly in >>>> this spec? That >>>> would eliminate >>>> the interop >>>> issues, and >>>> also gives us a >>>> chance to fully >>>> warn people >>>> about the >>>> security >>>> shortcomings of >>>> choosing that >>>> approach. >>>> >>>> On Thu, Jan 17, >>>> 2019 at 4:32 PM >>>> John Bradley >>>> >>> > >>>> wrote: >>>> >>>> We have >>>> discussed this. >>>> >>>> Audiences >>>> can >>>> certainly >>>> be logical >>>> identifiers. >>>> >>>> This >>>> however is >>>> a more >>>> specific >>>> location.  >>>> The AS is >>>> free to map >>>> the >>>> location >>>> into some >>>> abstract >>>> audience in >>>> the AT. >>>> >>>> From a >>>> security >>>> point of >>>> view once >>>> the client >>>> starts >>>> asking for >>>> logical >>>> resources >>>> it can be >>>> tricked >>>> into asking >>>> for the >>>> wrong one >>>> as a bad >>>> resource >>>> can always >>>> lie about >>>> what >>>> logical >>>> resource it is. >>>> >>>> If we were >>>> to change >>>> it, how a >>>> client >>>> would >>>> validate it >>>> becomes >>>> challenging >>>> to impossible. >>>> >>>> The AS is >>>> free to do >>>> whatever >>>> mapping of >>>> locations >>>> to >>>> identifiers >>>> it needs >>>> for access >>>> tokens. >>>> >>>> Some >>>> implementations >>>> may want to >>>> keep >>>> additional >>>> parameters >>>> like >>>> logical >>>> audience, >>>> but that >>>> should be >>>> separate >>>> from resource. >>>> >>>> John B. >>>> >>>> On >>>> 1/17/2019 >>>> 9:56 AM, >>>> Rifaat >>>> Shekh-Yusef >>>> wrote: >>>> >>>> Hi >>>> Vittorio, >>>> >>>> The >>>> text >>>> you >>>> quoted >>>> is >>>> copied >>>> form >>>> the >>>> abstract >>>> of the >>>> draft >>>> itself. >>>> >>>> *Authors,* >>>> >>>> Should >>>> the >>>> draft >>>> be >>>> updated >>>> to >>>> cover >>>> the >>>> logical >>>> identifier >>>> case? >>>> >>>> Regards, >>>> >>>>  Rifaat >>>> >>>> On Thu, >>>> Jan 17, >>>> 2019 at >>>> 8:19 AM >>>> Vittorio >>>> Bertocci >>>> >>> > >>>> wrote: >>>> >>>> Hi >>>> Rifaat, >>>> >>>> >>>> one >>>> detail. >>>> The >>>> tech >>>> summary >>>> says >>>> >>>> An >>>> extension >>>> to >>>> the >>>> OAuth >>>> 2.0 >>>> Authorization >>>> Framework >>>> defining >>>> request >>>> >>>> >>>> parameters >>>> that >>>> enable >>>> a >>>> client >>>> to >>>> explicitly >>>> signal >>>> to >>>> an >>>> authorization >>>> server >>>> >>>> about >>>> the >>>> *location* >>>> of >>>> the >>>> protected >>>> resource(s) >>>> to >>>> which >>>> it >>>> is >>>> requesting >>>> >>>> >>>> access. >>>> >>>> But >>>> at >>>> least >>>> in >>>> the >>>> Microsoft >>>> implementation, >>>> the >>>> resource >>>> identifier >>>> doesn't >>>> /have/ >>>> to >>>> be >>>> a >>>> network >>>> addressable >>>> URL >>>> (and >>>> if >>>> it >>>> is, >>>> it >>>> doesn't >>>> strictly >>>> need >>>> to >>>> match >>>> the >>>> actual >>>> resource >>>> location). >>>> It >>>> can >>>> be >>>> a >>>> logical >>>> identifier, >>>> tho >>>> using >>>> the >>>> actual >>>> resource >>>> location >>>> there >>>> has >>>> benefits >>>> (domain >>>> ownership >>>> check, >>>> prevention >>>> of >>>> token >>>> forwarding >>>> etc). >>>> >>>> Same >>>> for >>>> Auth0, >>>> the >>>> audience >>>> parameter >>>> is >>>> a >>>> logical >>>> identifier >>>> rather >>>> than >>>> a >>>> location. >>>> >>>> On >>>> Wed, >>>> Jan >>>> 16, >>>> 2019 >>>> at >>>> 6:32 >>>> PM >>>> Rifaat >>>> Shekh-Yusef >>>> >>> > >>>> wrote: >>>> >>>> All, >>>> >>>> >>>> The >>>> following >>>> is >>>> the >>>> first >>>> shepherd >>>> write-up >>>> for >>>> the draft-ietf-oauth-resource-indicators-01 >>>> document. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >>>> >>>> Please, >>>> take >>>> a >>>> look >>>> and >>>> let me >>>> know >>>> if >>>> I >>>> missed >>>> anything. >>>> >>>> Regards, >>>> >>>>  Rifaat >>>> >>>> _______________________________________________ >>>> OAuth >>>> mailing >>>> list >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> >>>> https://www.ietf..org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth >>>> mailing list >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> */CONFIDENTIALITY NOTICE: >>>> This email may contain >>>> confidential and privileged >>>> material for the sole use >>>> of the intended >>>> recipient(s). Any review, >>>> use, distribution or >>>> disclosure by others is >>>> strictly prohibited. If you >>>> have received this >>>> communication in error, >>>> please notify the sender >>>> immediately by e-mail and >>>> delete the message and any >>>> file attachments from your >>>> computer. Thank you./* >>>> >>>> >>>> */CONFIDENTIALITY NOTICE: This >>>> email may contain confidential and >>>> privileged material for the sole >>>> use of the intended recipient(s). >>>> Any review, use, distribution or >>>> disclosure by others is strictly >>>> prohibited.. If you have received >>>> this communication in error, please >>>> notify the sender immediately by >>>> e-mail and delete the message and >>>> any file attachments from your >>>> computer. Thank you./* >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> /CONFIDENTIALITY NOTICE: This email may contain >> confidential and privileged material for the sole use >> of the intended recipient(s). Any review, use, >> distribution or disclosure by others is strictly >> prohibited...  If you have received this >> communication in error, please notify the sender >> immediately by e-mail and delete the message and any >> file attachments from your computer. Thank >> you./_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------837FB3F8AD97254F7C2ECBD1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit What about deployments where the logical endpoint (https://api.service.example.com/foo) is actually deployed at https://2354353-<geo-location>.api.service.example.com/foo? I've worked with partners where the endpoint URI is unique to a geo-location and that endpoint is returned to the client when providing the token. Requiring exact location URLs force a client to make two token requests in order to get a token for the exact specified location.

Maybe I'm missing something?

Thanks,
George

On 1/23/19 1:56 PM, John Bradley wrote:

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.
Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Brian, Vittorio,

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

Regards,
 Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's resource. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 
On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:
+1 to Mike and John’s comments. 

Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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

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

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


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

--------------837FB3F8AD97254F7C2ECBD1-- From nobody Wed Jan 23 11:59:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21D130EDD for ; Wed, 23 Jan 2019 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 OmkzLly7POYr for ; Wed, 23 Jan 2019 11:59:46 -0800 (PST) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574BD12785F for ; Wed, 23 Jan 2019 11:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548273584; bh=bXYmZngr17UpTdm4Jeyo3a/2mZf1EdhWAKv692gWMo8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=eh3Qc7FEMdvl7iIhV3T5BrA6WEhwqafQg3pHW9/NJ/EmqtOPc1DJgvR4UsdeZWfk3Xq3g07JyYa+a5/b859G2256FDbfUJyw5HaP/PYZF4wgqNVme1J9YkX1llYzMScJG9MxrUWGUC42vAJ34auxesdVkJq9WC4tGq0u0Q8DL24GiXQEgY62/YRQ6yT1Z5oy8LmW7PLJHJUw24Ks2tqm15tzppsVBlY52vZ7A8NBxckylCFfH3qKOWXxOwBmu7EQfPzyjjAofMpCzWQF2Tb7qFrjXnB3jcPza6Aj+5RBN7rnFViBStF9fwfDEL4Lsy1k0awVWAPthooWOafuGdeh4g== X-YMail-OSG: O51C6wUVM1nP9dMbw_hXxDYyt5PrAUi4NI7r2l_kNVrCHnKxocfm0arMb9331qR 58Ecpj2pcntay7ZxeuN7eRwyyqlYAmywW.Bv3w2.Ppeb7f3ppv1WpSsq8X.MD7JtgyCH2XXXZZpS OUGHsCGlphRsz6XRG1FSGfGMeuTmyM6USNEesRBpsCCFVraDpJmqDY1bazDtLzRcMBE5g8thPqlK cgmG_tCLqyc7HoXdVtwrA50CRbYJWHj0WV9T2CCueQkPQ8vFzX78Ilmc0NYyH8Pt0XS_Z7GjNUKu IVOaM.WUdgHQ1eUqoFJ0gEdeS2SHU4OgUzh6BmLqE529re4wRkiePk0p.vHE7KkqemimlHxXSB_b FoabjlkmpQfoQRonMtExuklqqZkthwSuSp5x_REY9eXqlQIB0XXqBzrtgSoHw0ErUXCCnQ4JCW0d u6lhRxu8y2dpi9pbYnx_xyIUrc3liWAO9iRlKyP49uKceImEwHA.k6nwc1Q1pB8agEwlc0ihkzn. rFsW2yFuYMKfaDUudkbKYg60gBeJLdb53Kqv3xU4htOgDVAeffHaEiRM4ez0NvtvYqTzUyjX3s3N gTvSxXTwnKpeBr8jrQTutkUu1_edeuFfemyN6Bo1SJgdBtFrPOTqMXcT25mis9Jqf2UikpaEiRdP 4yOl61uLyFve27VXKnFY907K_g3syA7ygKKkI0ct4HcTMiph5XL7qBbEO8Y8znE1nUQbuOob_e0b NOXwWsT6ZpaPrnf17VE4ViGBbf0WGy5SMoKHPyvjgajLLEVzulKKA1iHB5jPWrBFWIi.kSP8CSjv ZE2SfxLs23Is9q1J3gn0PISoJRyegrgKndNNZuvqavibFR2N5.BGcsCdoJUNHdxQSmfk_QScDtNr xaJbzd9qhtTZY4rpi_8h9rjGmgwIZgjO_2iHW6hfjCrClLdPWrKrQFHRqlNRLOlOsJrM80h0L6YG UpBOpFPxZwIDe8J4BPemL.FapbeDsF0BdZ0i6dtcVvz_YZRj5C6CJmao5qNru67nPCPX_FTmJNth RFvac2wy90W8fruGQgnBMg4yMxUOu43hr194m6TeOVv8r1aArMCIZazItGeeJOTnnSwUE7tkSxGJ q Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 23 Jan 2019 19:59:44 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3d723fbc3b16816e492b298e468dedda; Wed, 23 Jan 2019 19:59:43 +0000 (UTC) To: Vittorio Bertocci , Mike Jones Cc: "oauth@ietf.org" References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> From: George Fletcher Organization: AOL LLC Message-ID: <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> Date: Wed, 23 Jan 2019 14:59:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------453456ED469053C5C0680A48" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 19:59:52 -0000 This is a multi-part message in MIME format. --------------453456ED469053C5C0680A48 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 Also, I don't really like the parameter name 'req_aud' :) I'm not 100% convinced that 'audience' and 'logical resource' are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect. I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email). Thanks, George On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > As mentioned below, I agree the two can be separated- but I also agree > with George on the need to be clear an easy to reference for developers. > Just adding a reference to req_aud would just raise the cyclomatic > complexity of the specs, which is already unusably high for mere > mortals in the OAuth2/OIDC family of specs. > > One additional complication is that this specification is reusing a > parameter that is already used in a *very* large number of production > systems (small example here > ), > and whose concrete semantic happens to be prevalently logic > identifier. If the parameter you are defining here has a different > semantic, at the very least it would seem good hygiene to rename it to > avoid collision and confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > > wrote: > > I agree with John’s logic.  The physical resource and logical > resource should use different identifiers. Fortunately, we already > have “resource” and “req_aud” for these parameters.  I believe > we’re good to go, as-is. > > -- Mike > > *From:* OAuth > *On Behalf Of * John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > I don't think they are necessarily mutually exclusive, that is why > I think there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client > interacting with RS https://fire.hhs.com as the resource wants a > OAuth token with an audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for > tokens with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is > the URI of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may > span more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into > the URI to figure out which one it is.  I think that is harder for > implementations and more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself iterated on > modifying the text to cover the logical identifier use case, > highlighting the security implications of going that route. > You can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from January 21 for the > specific changes. > > Note: I also had a chat with John offline, and he expressed > the desire to split the resource parameter in two distinct > parameters to better signal the intended usage. I am sure he > can elaborate. I have nothing against it in principle, as long > as we leave nothing as exercise to the reader and we are very > clear on usage (e.g. mutual exclusivity, etc) but didn't have > a chance to speak w Brian about it. If the discussion > stretches further, I would suggest we pause it and let him > enjoy his time off for the rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci > > wrote: > > Hi Rifaat, > > absolutely. Brian and myself already started working > on some language, however this week he is in vacation > hence it might take few days before we come back to > the list with something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > > > wrote: > > Brian, Vittorio, > > To move this discussion forward, can you guys > suggest some text to make the logical identifier > usage clearer? > > Regards, > >  Rifaat > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > > wrote: > > As I suggested before, I do think that's > within the bounds of the draft's definition of > 'resource' as a URI. And that perhaps all > that's needed is some minor adjustment and/or > augmentation of some text to make it more clear. > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio > Bertocci > wrote: > > [sent to John only by mistake, resending > to the ML] > > > > In Azure AD v1 & ADFS, that's resource.. > It could be used for both network and > logical ids, with the concrete usage in > the wild I described earlier. > > In Azure AD v2, the resource as explicit > parameter (network, logic or otherwise) is > gone and is expressed as part of the scope > string of all the scopes requested for a > given resource- but it still exist in > practice tho as it still end up in the > resulting aud of the issued token. > > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley > > wrote: > > What is the parameter that Microsoft > is using? > > On 1/20/2019 3:59 PM, Vittorio > Bertocci wrote: > > First of all, it wasn't my intent > to disrupt the established > process. In my former position I > wasn't monitoring those > discussions hence I didn't have a > chance to offer feedback. When I > saw something that gave me the > impression might lead to issues, > and given that I worked with > actual deployments and developers > using a similar parameter for a > long time, I thought prudent to > bring this up. I really appreciate > Rifaat's stance on this. End of > preamble. > > Ultimately my goal is for > developers to have guidance on how > to work with the concept of > logical resource in a standard > compliant way, hence it doesn't > strictly matter whether the > definition of the corresponding > parameter lives > in oauth-resource-indicators or > elsewhere. > > That said. Reading through the > draft, it would appear that most > of the reasons for which the spec > was created apply to both the > network addressable and the > logical resource types: knowing > what keys to use to encrypt the > token, constrain access tokens to > the intended audience, avoiding > overloading scopes with resource > indicating parts... those all > apply to network addressable and > logic identifiers alike. And both > parameters are expected to result > in audience restricted tokens. It > seems the only difference comes at > token usage time, with the network > addressable case giving more > guarantees that the token will go > to its intended recipient, but the > request and audience restriction > syntax seems to be exactly the same. > > On top of this: in the 99.999% of > the scenarios I encountered in the > wild in the last 5 years of using > the resource parameter in the MS > ecosystem, the resource identifier > was known at design time: the > developer discovered it out of > band and placed it in the app > config at deployment time. Those > aren't fringe cases I occasionally > encountered: the resource > parameter in Azure AD v1 and ADFS > was mandatory, hence literally > every solution i saw or touched > used it. As Brian suggested, this > is a scenario where the security > advantages of the network > addressable case aren't as > pronounced as in the case in which > the client discovers the resource > identifier at runtime. This isn't > just because there is no > specification suggesting location > should be explicitly indicated, > it's because there are many > practical advantages at > development and deployment time to > be able to use logical > identifiers- and if the /concrete > /security advantages don't apply > to the their case, people will > simply not comply. > > In summary: creating two different > parameters in two different > documents is better than ignoring > he logical identifier case > altogether, however I think that > not acknowledging the logical id > case in oauth-resource-indicators > is going to create confusion and > ultimately not be as useful to the > developer community as it could be. > > On Sat, Jan 19, 2019 at 12:38 Phil > Hunt > wrote: > > +1 to Mike and John’s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, > Mike Jones > > > wrote: > > I also agree that > “resource” should be a > specific > network-addressable URL > whereas a separate > audience parameter (like > “aud” in JWTs) can refer > to one or more logical > resources. They are > different, if related, things. > > Note that the ACE WG is > proposing to register a > logical audience parameter > “req_aud” in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - partly based on feedback > from OAuth WG members.  > This is a general OAuth > parameter, which any OAuth > deployment will be able to > use. > > I therefore believe that > no changes are needed to > draft-ietf-oauth-resource-indicators, > as the logical audience > work is already happening > in another draft. > > -- Mike > > *From:* OAuth > > > *On Behalf Of *John Bradley > *Sent:* Saturday, January > 19, 2019 9:01 AM > *To:* Brian Campbell > > > *Cc:* Vittorio Bertocci > >; > IETF oauth WG > > > *Subject:* Re: [OAUTH-WG] > Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > We need to decide if we > want to make a change. > > For security we are > location centric. > > I prefer to keep resource > location separate from > logical audience that can > be a scope or other > parameter. > > If becomes harder for > people to use the > parameter correctly if we > are too flexible. > > I would rather have a > separate logical audience > parameter if we think we > want one. > > John B. > > On Sat, Jan 19, 2019, > 11:41 AM Brian Campbell > > wrote: > > No apology needed, > Rifaat. And I > apologize if what I > said came off the > wrong way. I was just > trying to make light > of the situation.. And > I agree that we should > not be hamstrung by > the process and there > are times when it > makes sense to be > flexible with things. > > On Fri, Jan 18, 2019 > at 6:22 PM Rifaat > Shekh-Yusef > > > wrote: > > Sorry Brian, I was > not clear with my > statement. > > I meant to say > that we should not > allow the process > to prevent the WG > from producing a > quality document > without issues, > assuming there is > an issue in the > first place. > > Ideally we want to > get these > identified during > the WGLC, but > things happen and > sometimes the WG > misses something. > > I hear you and > agree that this > make things > difficult for > authors. We will > make sure that > this does not > become the norm, > and we will try to > stick to the > process as much as > possible. > > Regards, > >  Rifaat > > On Fri, Jan 18, > 2019 at 5:35 PM > Brian Campbell > > > wrote: > > Thanks Rifaat. > Process is as > process does, > right? I do > kinda want to > grumble about > WGCL having > passed already > but that's > mostly because > replying to > these kinds of > threads is > hard for me > and I'll just > get over it... > > As far as I > understand > things, the > security > concerns come > into play when > the client is > being told the > by the > resource how > to identity > the resource > like is > described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and using the > actual > location in > that context > ,along with > some other > checks > prescribed in > that draft, > prevents the > kind of issues > John described > earlier in the > thread. > > In cases where > the client > knows the > resource a > priori or > out-of-band or > configured or > whatever, I > don't think > the same > security > concerns > arise. And > using such a > known value, > be it an > actual > location or > logical > representation, > would be okay. > > The > resource-indicators > draft is > admittedly > somewhat > location-centric > in how it > talks about > the value of > the 'resource' > parameter. But > ultimately it > defines it as > an absolute > URI that > indicates the > location of > the target > service or > resource where > access is > being > requested. A > location can > be varying > shades of > abstract and > I'd say that > using a URI as > 'resource' > parameter > value that's a > logical > identifier > that points to > some resource > is well within > the bounds of > the draft. > > So maybe the > draft is okay > as is? > > Or perhaps > that's too > much to be > left as an > exerciser to > the reader? > And some text > should be > added and/or > adjusted so > the > resource-indicators > draft would be > a little more > open/clear > about the > parameter > value > potentially > being more of > a logical or > abstract > identifier and > not > necessarily a > network > addressable URL? > > On Fri, Jan > 18, 2019 at > 1:18 PM Rifaat > Shekh-Yusef > > > wrote: > > I wouldn't > worry too > much about > the process. > > If it > makes > sense to > update the > document, > then feel > free to do > that. > > Regards, > >  Rifaat > > On Fri, > Jan 18, > 2019 at > 3:08 PM > John > Bradley > > > wrote: > > Yes > the logical > resource > can be > provided > by "scope" > > Some > implementations > like > Ping > and > Auth0 > have > been > adding > another > parameter > "aud" > to > identify > the > logical > resource > and > then > using > scopes > to > define > permissions > to the > resource. > > Fortunately, > we are > using > a > different parameter > name > so not > stepping > on that.. > > We > could > go > back > and > try to > add > text > explaining > the > difference, > but we > are > quite > late > in the > process. > > I > agree > that a > logical > resource > parameter may > be > helpful, > but > perhaps > it > should > be a > separate > draft. > > John B. > > On > Fri, > Jan > 18, > 2019 > at > 4:38 > PM > Richard > Backman, > Annabelle > > > wrote: > > Doesn’t > the > “scope” > parameter > already > provide > a > means > of > specifying > a > logical > identifier? > > -- > > Annabelle > Richard > Backman > > AWS > Identity > > *From: > *OAuth > > > on > behalf > of > Vittorio > Bertocci > > > *Date: > *Friday, > January > 18, > 2019 > at > 5:47 > AM > *To: > *John > Bradley > > > *Cc: > *IETF > oauth > WG > > > *Subject: > *Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > Thanks > John > for > the > background. > > > I > agree > that > from > the > client > validation > PoV, > having > an > identifier > corresponding > to > a > location > makes > things > more > solid. > > That > said: > the > use > of > logical > identifiers > is > widespread, > as > it > has > significant > practical > advantages > (think > of > services > that > assign > generated > hosting > URLs > only > at > deployment > time, > or > services > that > are > somehow > grouped > under > the > same > logical > audience > across > regions/environment/deployments). > People > won't > stop > using > logical > identifiers, > because > they > often > have > no > alternative > (generating > new > audiences > on > the > fly > at > the > AS > every > time > you > do > a > deployment > and > get > assigned > a > new > URL > can > be > unfeasible). > Leaving > a > widely > used > approach > as > exercise > to > the > reader > seems > a > disservice > to > the > community, > given > that > this > might > lead > to > vendors > (for > example > Microsoft > and > Auth0) > keeping > their > own > proprietary > parameters, > or > developers > misusing > the > ones > in > place; > would > make > it > hard > for > SDK > developers > to > provide > libraries > that > work > out > of > the > box > with > different > ASes; > and > so on. > > Would > it > be > feasible > to > add > such > parameter > directly > in > this > spec? > That > would > eliminate > the > interop > issues, > and > also > gives > us > a > chance > to > fully > warn > people > about > the > security > shortcomings > of > choosing > that > approach. > > On > Thu, > Jan > 17, > 2019 > at > 4:32 > PM > John > Bradley > > > wrote: > > We > have > discussed > this. > > Audiences > can > certainly > be > logical > identifiers. > > > This > however > is > a > more > specific > location.  > The > AS > is > free > to > map > the > location > into > some > abstract > audience > in > the > AT. > > From > a > security > point > of > view > once > the > client > starts > asking > for > logical > resources > it > can > be > tricked > into > asking > for > the > wrong > one > as > a > bad > resource > can > always > lie > about > what > logical > resource > it > is. > > If > we > were > to > change > it, > how > a > client > would > validate > it > becomes > challenging > to > impossible. > > > The > AS > is > free > to > do > whatever > mapping > of > locations > to > identifiers > it > needs > for > access > tokens. > > Some > implementations > may > want > to > keep > additional > parameters > like > logical > audience, > but > that > should > be > separate > from > resource. > > John > B. > > On > 1/17/2019 > 9:56 > AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > > The > text > you > quoted > is > copied > form > the > abstract > of > the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > >  Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > > > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > > > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > >  Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY > NOTICE: This > email may > contain > confidential > and privileged > material for > the sole use > of the > intended > recipient(s). > Any review, > use, > distribution > or disclosure > by others is > strictly > prohibited. If > you have > received this > communication > in error, > please notify > the sender > immediately by > e-mail and > delete the > message and > any file > attachments > from your > computer. > Thank you./* > > > */CONFIDENTIALITY > NOTICE: This email may > contain confidential > and privileged > material for the sole > use of the intended > recipient(s). Any > review, use, > distribution or > disclosure by others > is strictly > prohibited.. If you > have received this > communication in > error, please notify > the sender immediately > by e-mail and delete > the message and any > file attachments from > your computer. Thank > you./* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may > contain confidential and privileged material > for the sole use of the intended recipient(s). > Any review, use, distribution or disclosure by > others is strictly prohibited... If you have > received this communication in error, please > notify the sender immediately by e-mail and > delete the message and any file attachments > from your computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------453456ED469053C5C0680A48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% convinced that 'audience' and 'logical resource' are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:
As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers.
Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs.

One additional complication is that this specification is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion.

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I agree with John’s logic.  The physical resource and logical resource should use different identifiers.  Fortunately, we already have “resource” and “req_aud” for these parameters.  I believe we’re good to go, as-is.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

 

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

 

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

 

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

 

Regards,

 Rifaat

 

 

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

 

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]



In Azure AD v1 & ADFS, that's resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.

This is 9 months old info hence

 

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

 

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

 

 

 

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:

+1 to Mike and John’s comments. 

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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


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



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

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

--------------453456ED469053C5C0680A48-- From nobody Thu Jan 24 12:46:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD931131157 for ; Thu, 24 Jan 2019 12:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 aOp67UWKjCCZ for ; Thu, 24 Jan 2019 12:45:57 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096D6130F0B for ; Thu, 24 Jan 2019 12:45:57 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id x6so5916565ioa.9 for ; Thu, 24 Jan 2019 12:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ld1u4H8pYj9atg4kPlQJOWR/3GPxHgM3XyyHHnlZrqM=; b=QRngkDC7OQN3d0y8wBT1bOpYXzLdNxD+b9Asstx6C/bRhDYFxybgMJJenm2/Qa8q1R 9wezIde/bANW48biB4HYx486dyHIv6DW0DMQ9K1ZsjMPytAAniR3qJoUdqRLgoQa4/X4 WOjPJwj8bWSjB/bidkIscd77lDdvn5KOU19QrwP9siPO7Pw23xiC3Gqt65//iAqiVeTa 3Pe9I+0kWHtxMTNJRfEm4uhP6fx/2zCtWyH/uTyKgPKCL2Os/LV4m7RuxM95jCvEGm6Y 7IYUgPWZ61A/lQYkV89hJYsKC2/Bgr1EKIRvdNYk8pGstSNjaonDyKZr5VgE9o7R0r1O eSDw== 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=ld1u4H8pYj9atg4kPlQJOWR/3GPxHgM3XyyHHnlZrqM=; b=CroGXTkQDd/dYDQr36DzR5nB2TgI9YuhWQoeGrjVA9k+fgqA6O0lhqpbfy1MTdYmh9 MJBXWifxwydp7l5aONAgYVod39b6aelkEzErV/jA7njcOIlOREX6KhfklmVOJFdpMiVs ACSkIF6vvl1e1EjJMmZ1gNRCK+F5c2vhfAITEo1f0eehyYLPIxzAKFIJEmXxk3YLpK79 2kH9PyBvM9fVFV9keIkz0yQmsoyM/R3t6dZfJCYHd8H0uRGg10hUPDato97jRyb5qCnj 1N3RJBjl3iX9MHonNX7muBCBd+8svf5P/2FJJaRExg80s1JRq7BFSMpPhAQXircgce9N 1ZVg== X-Gm-Message-State: AHQUAubiKhH+YolEaGgHWzc1qqWr7uxPxJbGIG6pu2LXv32vAXEaM82g V6aJjBO1pJ/bvkLAkD4CRJNUgPjzv1h0RyRPhb7yozdBwXk= X-Google-Smtp-Source: ALg8bN7vnUQlersXBlVKXY4kErz50sg33ocO6+DRdu/7XKEl7N+bShkkBiOGNL8TvRyqgOzS4kyrIAspfjSJsVnzD/o= X-Received: by 2002:a5d:9913:: with SMTP id x19mr4156595iol.99.1548362756048; Thu, 24 Jan 2019 12:45:56 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> In-Reply-To: <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> From: Rifaat Shekh-Yusef Date: Thu, 24 Jan 2019 15:45:44 -0500 Message-ID: To: George Fletcher Cc: Vittorio Bertocci , Mike Jones , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000ecbe205803a4cf3" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 20:46:03 -0000 --0000000000000ecbe205803a4cf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting. Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this. Regards, Rifaat On Wed, Jan 23, 2019 at 3:00 PM George Fletcher wrote: > +1 > > Also, I don't really like the parameter name 'req_aud' :) I'm not 100% > convinced that 'audience' and 'logical resource' are completely overlappi= ng > concepts. We can potentially make them completely overlapping but we need > text to that effect. > > I also believe that we don't have a complete solution for all deployments > using exact locations (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be separated- but I also agree > with George on the need to be clear an easy to reference for developers. > Just adding a reference to req_aud would just raise the cyclomatic > complexity of the specs, which is already unusably high for mere mortals = in > the OAuth2/OIDC family of specs. > > One additional complication is that this specification is reusing a > parameter that is already used in a *very* large number of production > systems (small example here > ), > and whose concrete semantic happens to be prevalently logic identifier. I= f > the parameter you are defining here has a different semantic, at the very > least it would seem good hygiene to rename it to avoid collision and > confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> I agree with John=E2=80=99s logic. The physical resource and logical re= source >> should use different identifiers. Fortunately, we already have =E2=80= =9Cresource=E2=80=9D >> and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * John Bradley >> *Sent:* Wednesday, January 23, 2019 10:56 AM >> *To:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> I don't think they are necessarily mutually exclusive, that is why I >> think there is value in allowing them to be specified separately. >> >> As an AS in the distributed OAuth case knowing that a client interacting >> with RS https://fire.hhs.com as the resource wants a OAuth token with an >> audience of HHS and a scope of read. >> >> Without proof of possession we need to keep bad RS from asking for token= s >> with scopes and audiences of other RS that can be replayed. >> >> I really like keeping the resource simple and unspoofable, it is the URI >> of the RS where you are presenting the AT. >> >> I prefer to keep that separate from the logical resource that may span >> more than one RS endpoint. >> >> Merging the two and we are probably back at the AS looking into the URI >> to figure out which one it is. I think that is harder for implementatio= ns >> and more likely to have security issues down the road. >> >> John B. >> >> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: >> >> Hi all, >> >> thanks for you patience. Brian and myself iterated on modifying the text >> to cover the logical identifier use case, highlighting the security >> implications of going that route. You can find the revised text in >> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-in= dicators.xml, >> see the commits in the history from January 21 for the specific changes. >> >> Note: I also had a chat with John offline, and he expressed the desire t= o >> split the resource parameter in two distinct parameters to better signal >> the intended usage. I am sure he can elaborate. I have nothing against i= t >> in principle, as long as we leave nothing as exercise to the reader and = we >> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a >> chance to speak w Brian about it. If the discussion stretches further, I >> would suggest we pause it and let him enjoy his time off for the rest of >> the week. >> >> >> >> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef >> wrote: >> >> Thank you guys! >> >> >> >> On Monday, January 21, 2019, Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> absolutely. Brian and myself already started working on some language, >> however this week he is in vacation hence it might take few days before = we >> come back to the list with something. >> >> Cheers, >> >> V. >> >> >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> wrote: >> >> Brian, Vittorio, >> >> >> >> To move this discussion forward, can you guys suggest some text to make >> the logical identifier usage clearer? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >> As I suggested before, I do think that's within the bounds of the draft'= s >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> wrote: >> >> [sent to John only by mistake, resending to the ML] >> >> >> >> In Azure AD v1 & ADFS, that's resource.. It could be used for both >> network and logical ids, with the concrete usage in the wild I described >> earlier. >> >> In Azure AD v2, the resource as explicit parameter (network, logic or >> otherwise) is gone and is expressed as part of the scope string of all t= he >> scopes requested for a given resource- but it still exist in practice th= o >> as it still end up in the resulting aud of the issued token. >> >> This is 9 months old info hence >> >> >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >> >> What is the parameter that Microsoft is using? >> >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >> +1 to Mike and John=E2=80=99s comments. >> >> Phil >> >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific networ= k-addressable URL >> whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWT= s) can refer to one >> or more logical resources. They are different, if related, things. >> >> >> >> Note that the ACE WG is proposing to register a logical audience >> parameter =E2=80=9Creq_aud=E2=80=9D in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >> based on feedback from OAuth WG members. This is a general OAuth >> parameter, which any OAuth deployment will be able to use. >> >> >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience work is >> already happening in another draft. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> We need to decide if we want to make a change. >> >> >> >> For security we are location centric. >> >> >> >> I prefer to keep resource location separate from logical audience that >> can be a scope or other parameter. >> >> >> >> If becomes harder for people to use the parameter correctly if we are to= o >> flexible. >> >> >> >> I would rather have a separate logical audience parameter if we think we >> want one. >> >> >> >> John B. >> >> >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell > wrote: >> >> No apology needed, Rifaat. And I apologize if what I said came off the >> wrong way. I was just trying to make light of the situation.. And I agre= e >> that we should not be hamstrung by the process and there are times when = it >> makes sense to be flexible with things. >> >> >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> >> >> So maybe the draft is okay as is? >> >> >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then feel free to do that. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >> Yes the logical resource can be provided by "scope" >> >> >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> >> >> John B. >> >> >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000000ecbe205803a4cf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

<= /div>
This coming Monday, J= an 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office m= eeting.
Feel f= ree to attend the meeting to discuss this topic to try to get to a conclusi= on on this.
Regards,
=C2=A0Rifaat

=

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrot= e:
=20 =20 =20
+1

Also, I don't really like the parameter name 'req_aud' :)= I'm not 100% convinced that 'audience' and 'logical resource'= are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2= :50 PM, Vittorio Bertocci wrote:
=20
As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers.
Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs.

One additional complication is that this specification is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion.

O= n Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John=E2=80=99s logic.=C2=A0 The physical resou= rce and logical resource should use different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresource=E2=80=9D a= nd =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I believe we=E2=80=99re good = to go, as-is.

=C2= =A0

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

=C2= =A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://= fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.=C2=A0 I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in=C2=A0<= a href=3D"https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-reso= urce-indicators.xml" target=3D"_blank">https://github.com/vibronet/i-d/blob= /master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf= .org> wrote:

As I suggested before, I do think that's within th= e bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]



In Azure AD v1 & ADFS, that's=C2=A0reso= urce.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting=C2=A0=C2=A0of the issued token.

This is 9 months old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn'= t have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn'= t strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete sec= urity advantages don'= t apply to the their case, people will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resou= rce-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

=C2=A0

=C2=A0

=C2= =A0

= On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote= :

+1 to Mike and John=E2=80=99s comments.=C2= =A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I also agree that =E2=80=9Cresourc= e=E2=80=9D should be a specific network-addressab= le URL whereas a separate audience parameter (like =E2=80=9Cau= d=E2=80=9D in JWTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing = to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 Th= is is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no change= s are needed to draft-ietf-oauth-= resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.c= om>
Cc: Vittorio Bertocci <Vitt= orio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2= =A0

=C2=A0

For security we are location centric.=C2=A0=C2= =A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0= =C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0= =C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0= =C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.c= om wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0<= /p>

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.
The resource-indicato= rs draft is admittedly somewhat location-centric in how it talks about the value of the 'resource= ' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource'= ; parameter value that's = a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that'= s too much to be left as an exerciser to the reader?=C2=A0 And some text should be added and/or adjusted so the resource-indicato= rs draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worr= y too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope"=

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud" t= o identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2= =A0

=C2=A0

I agree that a logical resource parameter=C2=A0ma= y be helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscop= e=E2=80=9D parameter already provide a means of specifying a logical identifier?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@= dmarc.ietf.org>
Date: Frid= ay, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>=
Cc: IETF oauth WG <oauth@ietf.org>
Subject: R= e: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environme= nt/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension =
to the OAuth 2.0 Authorization Framework defining request 
parameters th=
at enable a client to explicitly signal to an authorization server <=
/pre>
                                                          
about the =
location of the protected resource(s) to which it is requesting =


                                                          
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

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

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


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


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

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


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



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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000000ecbe205803a4cf3-- From nobody Thu Jan 24 15:20:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BC81311F1 for ; Thu, 24 Jan 2019 15:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 bOiGJuEf1UaH for ; Thu, 24 Jan 2019 15:20:07 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8470313108C for ; Thu, 24 Jan 2019 15:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cWaclaqZRvlC55l4fTKqw2sqXlg1nQLk2Kp25Yxj4Vg=; b=bucU+g9xVg7HQ0htoS/+N5LQdtWolg49M44tk4O44EK3mj9J7u26uJc0pDoiprlAi1Xi7ynXqpCOFCEugmN8mTzuxCXVxb7EqS7ctUsPvXwF5ivBq2JKFAIIJgVkuVmWuZkFBo7oGkMnFLVKNmXUC+wqTlCIAiEbOQDErMrQo9k= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0337.namprd00.prod.outlook.com (52.132.20.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1600.0; Thu, 24 Jan 2019 23:19:57 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65%6]) with mapi id 15.20.1602.000; Thu, 24 Jan 2019 23:19:57 +0000 From: Mike Jones To: Rifaat Shekh-Yusef , George Fletcher CC: Vittorio Bertocci , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMSm6zRRv4Nr0eerioJ6LCFT6Wzcp6AgABNkQCAABqbAIABMd2AgABiBYCAAAiJAIAAAu6AgAAmUgCAAC6ggIAA30eAgAAm6gCAADowsIAAArOAgAHKeICAACE4AIAAC1UAgADX2YCAACJwAIAAdm6AgAAP8ICAApBGgIAAJMyAgAABgfCAAA21AIAAAngAgAGfMgCAACq5MA== Date: Thu, 24 Jan 2019 23:19:57 +0000 Message-ID: References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-01-24T23:19:55.0907645Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=dd250240-5642-4958-b9f4-cc3135157fea; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [50.47.86.113] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0337; 6:pnNjjHwMDAjzRoGPi7WRBQDVN6EnH6PWJ4fCBgLiUEttCMy/EIu2avpzktjUXobfgo9ikowbcEbMTn+3YV9uQpyKp+iRsa3+elr4Ayibj9yONfyUudB1B7sxXMk580Yn5tz9WcxwdmLnKOIELVrqCCoSixzNMsDt9CVS9Vkiw6CRDp0Ta/Cygjgjom5b1ZUxv0gflawn8TD5v86ecvbM8hN+Hv/wv4ETrCxQ4gP5yHeQCXaWf752NqN0qwwhb3DtRmIgREQzRxLDK+trmKUGD5IZQewExQNYZFHm3d1icutY332iX+MKE2Zs5dYdw0lHe/dX/u05KOpTiKdU4vmUJTOmwjSZxEgyjJhpCImacebW2isvoN/1qDmQ4/S1n/POXsGGd+jpx0iSU3RAtQASWqRv8xM3iRmUG482k2tGhGOMzovE0R8MdVpGVfM4rlJKY8gcA9eMQ9rjwQYneIbHDA==; 5:uQ4AIZBXVDlENJOa7qscc+FbcRwqZEBf708m8jxy07GQZdZLbB05VF5xaNVljCpl7EquAR6RAWN3G9L81MUEQ3kmdrMHq4mKxu1mkastOa6v4avsmVNRd3KsznsJQnxTHNsYSKcdp7dNz0szO9yQjyhfwhAhC8EQDro8HhMIaU1hz8lJEVhTpvct8XphKmE+KM9Bf8iu3nb5W3kynpGbUw==; 7:CDZ0L3QotHMEo1nF0ade/+mIYHNC+2qJm/GoFgUNgi7N9qA6tjOoxPu1vR7Fx60GNbBgY90wxc49lxQTK3XVKB02Cv1Q3uUmnuFg9xqZqv7xrXglU7q0lWRbwusOEc1lYOVfm/zc6iRMu95nA5RWPg== x-ms-office365-filtering-correlation-id: 6c9ee8c3-2ba1-43e3-35d7-08d6825274cb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7193020); SRVR:BL0PR00MB0337; x-ms-traffictypediagnostic: BL0PR00MB0337: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(396003)(136003)(51444003)(53754006)(199004)(189003)(38314003)(76176011)(229853002)(7696005)(54896002)(478600001)(99286004)(10290500003)(316002)(256004)(14444005)(5024004)(54906003)(110136005)(606006)(6436002)(71200400001)(86362001)(10090500001)(22452003)(71190400001)(30864003)(2906002)(8990500004)(86612001)(236005)(55016002)(53946003)(9686003)(6306002)(93886005)(26005)(6346003)(102836004)(68736007)(7736002)(446003)(6246003)(74316002)(6506007)(66066001)(11346002)(53546011)(186003)(39060400002)(476003)(25786009)(53936002)(105586002)(4326008)(966005)(106356001)(8676002)(790700001)(3846002)(6116002)(97736004)(14454004)(8936002)(33656002)(81166006)(81156014)(72206003)(486006)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0337; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vhEPCAuVIjLxPnjUyXdNOksmAYxnfYaOJ0qoLoUbNnU9VH6GyWpF+smLNxWhUgI6b6HmRYDoTjFLW/m2S6T3PGSzNkRiciFVCpQqHXynZMSUzzKIasFTNpYkB9xRXMQqsv1kGmn1CAQyEUQZnbaGffBZe8oCgyQceDA6Shc01wUNKMkj3xNShkF8gqrITC+89tDzKqFHaJjKQvVt0YIhQQ+YctO+2W6ODoGas5LStdc7de/NeSuSVzyqEJQo0IbMjeyzeaGMijjTHQZKya2A1PiN4RKgYuQErA05eEaYDGODEUKZjN+J+fWJ7t3Ix0gofgLFT73uM+pQ/HumxZQ4yx8KyIFglY1ZyvoAfP8z4pUtkhxAXBRkoZ1P6KlzUZYUS2uGQSexib3rSceJqSRJ2vcbmnaxKL9PA0AnOqiZcew= Content-Type: multipart/alternative; boundary="_000_BL0PR00MB02920F6A16D28D1652F21B2DF59A0BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c9ee8c3-2ba1-43e3-35d7-08d6825274cb X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 23:19:57.6068 (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-Transport-CrossTenantHeadersStamped: BL0PR00MB0337 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 23:20:14 -0000 --_000_BL0PR00MB02920F6A16D28D1652F21B2DF59A0BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHZpcnR1YWwgb2ZmaWNlIGhvdXJzIGluIG15IGNhbGVuZGFyIHN0YXJ0IDEvMiBob3VyIGJl Zm9yZSB0aGF0LiAgSWYgdGhlIHRpbWUgaGFzIGNoYW5nZWQsIGNhbiB5b3UgaGF2ZSB0aGUgbWVl dGluZyBvcmdhbml6ZXIgdXBkYXRlIHRoZSBjYWxlbmRhciBlbnRyeT8NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29t Pg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjQsIDIwMTkgMTI6NDYgUE0NClRvOiBHZW9yZ2Ug RmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb20+DQpDYzogVml0dG9yaW8gQmVydG9jY2kgPFZpdHRv cmlvQGF1dGgwLmNvbT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47 IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11 cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNCkFsbCwNCg0K VGhpcyBjb21pbmcgTW9uZGF5LCBKYW4gMjggQCAxMjowMHBtIEVhc3Rlcm4gVGltZSwgd2UgaGF2 ZSBhIHNjaGVkdWxlZCBPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBtZWV0aW5nLg0KRmVlbCBmcmVl IHRvIGF0dGVuZCB0aGUgbWVldGluZyB0byBkaXNjdXNzIHRoaXMgdG9waWMgdG8gdHJ5IHRvIGdl dCB0byBhIGNvbmNsdXNpb24gb24gdGhpcy4NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBX ZWQsIEphbiAyMywgMjAxOSBhdCAzOjAwIFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBh b2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3 cm90ZToNCisxDQoNCkFsc28sIEkgZG9uJ3QgcmVhbGx5IGxpa2UgdGhlIHBhcmFtZXRlciBuYW1l ICdyZXFfYXVkJyA6KSBJJ20gbm90IDEwMCUgY29udmluY2VkIHRoYXQgJ2F1ZGllbmNlJyBhbmQg J2xvZ2ljYWwgcmVzb3VyY2UnIGFyZSBjb21wbGV0ZWx5IG92ZXJsYXBwaW5nIGNvbmNlcHRzLiBX ZSBjYW4gcG90ZW50aWFsbHkgbWFrZSB0aGVtIGNvbXBsZXRlbHkgb3ZlcmxhcHBpbmcgYnV0IHdl IG5lZWQgdGV4dCB0byB0aGF0IGVmZmVjdC4NCg0KSSBhbHNvIGJlbGlldmUgdGhhdCB3ZSBkb24n dCBoYXZlIGEgY29tcGxldGUgc29sdXRpb24gZm9yIGFsbCBkZXBsb3ltZW50cyB1c2luZyBleGFj dCBsb2NhdGlvbnMgKHNlZSBteSBwcmV2aW91cyBlbWFpbCkuDQoNClRoYW5rcywNCkdlb3JnZQ0K T24gMS8yMy8xOSAyOjUwIFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSB3cm90ZToNCkFzIG1lbnRpb25l ZCBiZWxvdywgSSBhZ3JlZSB0aGUgdHdvIGNhbiBiZSBzZXBhcmF0ZWQtIGJ1dCBJIGFsc28gYWdy ZWUgd2l0aCBHZW9yZ2Ugb24gdGhlIG5lZWQgdG8gYmUgY2xlYXIgYW4gZWFzeSB0byByZWZlcmVu Y2UgZm9yIGRldmVsb3BlcnMuDQpKdXN0IGFkZGluZyBhIHJlZmVyZW5jZSB0byByZXFfYXVkIHdv dWxkIGp1c3QgcmFpc2UgdGhlIGN5Y2xvbWF0aWMgY29tcGxleGl0eSBvZiB0aGUgc3BlY3MsIHdo aWNoIGlzIGFscmVhZHkgdW51c2FibHkgaGlnaCBmb3IgbWVyZSBtb3J0YWxzIGluIHRoZSBPQXV0 aDIvT0lEQyBmYW1pbHkgb2Ygc3BlY3MuDQoNCk9uZSBhZGRpdGlvbmFsIGNvbXBsaWNhdGlvbiBp cyB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyByZXVzaW5nIGEgcGFyYW1ldGVyIHRoYXQgaXMg YWxyZWFkeSB1c2VkIGluIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgcHJvZHVjdGlvbiBzeXN0ZW1z IChzbWFsbCBleGFtcGxlIGhlcmU8aHR0cHM6Ly9kb2NzLm1pY3Jvc29mdC5jb20vZW4tdXMvYXp1 cmUvYWN0aXZlLWRpcmVjdG9yeS9kZXZlbG9wL3YxLXByb3RvY29scy1vYXV0aC1jb2RlPiksIGFu ZCB3aG9zZSBjb25jcmV0ZSBzZW1hbnRpYyBoYXBwZW5zIHRvIGJlIHByZXZhbGVudGx5IGxvZ2lj IGlkZW50aWZpZXIuIElmIHRoZSBwYXJhbWV0ZXIgeW91IGFyZSBkZWZpbmluZyBoZXJlIGhhcyBh IGRpZmZlcmVudCBzZW1hbnRpYywgYXQgdGhlIHZlcnkgbGVhc3QgaXQgd291bGQgc2VlbSBnb29k IGh5Z2llbmUgdG8gcmVuYW1lIGl0IHRvIGF2b2lkIGNvbGxpc2lvbiBhbmQgY29uZnVzaW9uLg0K DQpPbiBXZWQsIEphbiAyMywgMjAxOSBhdCAxMTowMyBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggSm9obuKAmXMgbG9naWMuICBU aGUgcGh5c2ljYWwgcmVzb3VyY2UgYW5kIGxvZ2ljYWwgcmVzb3VyY2Ugc2hvdWxkIHVzZSBkaWZm ZXJlbnQgaWRlbnRpZmllcnMuICBGb3J0dW5hdGVseSwgd2UgYWxyZWFkeSBoYXZlIOKAnHJlc291 cmNl4oCdIGFuZCDigJxyZXFfYXVk4oCdIGZvciB0aGVzZSBwYXJhbWV0ZXJzLiAgSSBiZWxpZXZl IHdl4oCZcmUgZ29vZCB0byBnbywgYXMtaXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVo YWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDE5IDEw OjU2IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgt cmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgbmVjZXNz YXJpbHkgbXV0dWFsbHkgZXhjbHVzaXZlLCB0aGF0IGlzIHdoeSBJIHRoaW5rIHRoZXJlIGlzIHZh bHVlIGluIGFsbG93aW5nIHRoZW0gdG8gYmUgc3BlY2lmaWVkIHNlcGFyYXRlbHkuDQoNCkFzIGFu IEFTIGluIHRoZSBkaXN0cmlidXRlZCBPQXV0aCBjYXNlIGtub3dpbmcgdGhhdCBhIGNsaWVudCBp bnRlcmFjdGluZyB3aXRoIFJTIGh0dHBzOi8vZmlyZS5oaHMuY29tIGFzIHRoZSByZXNvdXJjZSB3 YW50cyBhIE9BdXRoIHRva2VuIHdpdGggYW4gYXVkaWVuY2Ugb2YgSEhTIGFuZCBhIHNjb3BlIG9m IHJlYWQuDQoNCldpdGhvdXQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiB3ZSBuZWVkIHRvIGtlZXAgYmFk IFJTIGZyb20gYXNraW5nIGZvciB0b2tlbnMgd2l0aCBzY29wZXMgYW5kIGF1ZGllbmNlcyBvZiBv dGhlciBSUyB0aGF0IGNhbiBiZSByZXBsYXllZC4NCg0KSSByZWFsbHkgbGlrZSBrZWVwaW5nIHRo ZSByZXNvdXJjZSBzaW1wbGUgYW5kIHVuc3Bvb2ZhYmxlLCBpdCBpcyB0aGUgVVJJIG9mIHRoZSBS UyB3aGVyZSB5b3UgYXJlIHByZXNlbnRpbmcgdGhlIEFULg0KDQpJIHByZWZlciB0byBrZWVwIHRo YXQgc2VwYXJhdGUgZnJvbSB0aGUgbG9naWNhbCByZXNvdXJjZSB0aGF0IG1heSBzcGFuIG1vcmUg dGhhbiBvbmUgUlMgZW5kcG9pbnQuDQoNCk1lcmdpbmcgdGhlIHR3byBhbmQgd2UgYXJlIHByb2Jh Ymx5IGJhY2sgYXQgdGhlIEFTIGxvb2tpbmcgaW50byB0aGUgVVJJIHRvIGZpZ3VyZSBvdXQgd2hp Y2ggb25lIGl0IGlzLiAgSSB0aGluayB0aGF0IGlzIGhhcmRlciBmb3IgaW1wbGVtZW50YXRpb25z IGFuZCBtb3JlIGxpa2VseSB0byBoYXZlIHNlY3VyaXR5IGlzc3VlcyBkb3duIHRoZSByb2FkLg0K DQpKb2huIEIuDQpPbiAxLzIzLzIwMTkgMTo0NCBQTSwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6 DQpIaSBhbGwsDQp0aGFua3MgZm9yIHlvdSBwYXRpZW5jZS4gQnJpYW4gYW5kIG15c2VsZiBpdGVy YXRlZCBvbiBtb2RpZnlpbmcgdGhlIHRleHQgdG8gY292ZXIgdGhlIGxvZ2ljYWwgaWRlbnRpZmll ciB1c2UgY2FzZSwgaGlnaGxpZ2h0aW5nIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgZ29p bmcgdGhhdCByb3V0ZS4gWW91IGNhbiBmaW5kIHRoZSByZXZpc2VkIHRleHQgaW4gaHR0cHM6Ly9n aXRodWIuY29tL3ZpYnJvbmV0L2ktZC9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLW9hdXRoLXJlc291 cmNlLWluZGljYXRvcnMueG1sLCBzZWUgdGhlIGNvbW1pdHMgaW4gdGhlIGhpc3RvcnkgZnJvbSBK YW51YXJ5IDIxIGZvciB0aGUgc3BlY2lmaWMgY2hhbmdlcy4NCk5vdGU6IEkgYWxzbyBoYWQgYSBj aGF0IHdpdGggSm9obiBvZmZsaW5lLCBhbmQgaGUgZXhwcmVzc2VkIHRoZSBkZXNpcmUgdG8gc3Bs aXQgdGhlIHJlc291cmNlIHBhcmFtZXRlciBpbiB0d28gZGlzdGluY3QgcGFyYW1ldGVycyB0byBi ZXR0ZXIgc2lnbmFsIHRoZSBpbnRlbmRlZCB1c2FnZS4gSSBhbSBzdXJlIGhlIGNhbiBlbGFib3Jh dGUuIEkgaGF2ZSBub3RoaW5nIGFnYWluc3QgaXQgaW4gcHJpbmNpcGxlLCBhcyBsb25nIGFzIHdl IGxlYXZlIG5vdGhpbmcgYXMgZXhlcmNpc2UgdG8gdGhlIHJlYWRlciBhbmQgd2UgYXJlIHZlcnkg Y2xlYXIgb24gdXNhZ2UgKGUuZy4gbXV0dWFsIGV4Y2x1c2l2aXR5LCBldGMpIGJ1dCBkaWRuJ3Qg aGF2ZSBhIGNoYW5jZSB0byBzcGVhayB3IEJyaWFuIGFib3V0IGl0LiBJZiB0aGUgZGlzY3Vzc2lv biBzdHJldGNoZXMgZnVydGhlciwgSSB3b3VsZCBzdWdnZXN0IHdlIHBhdXNlIGl0IGFuZCBsZXQg aGltIGVuam95IGhpcyB0aW1lIG9mZiBmb3IgdGhlIHJlc3Qgb2YgdGhlIHdlZWsuDQoNCk9uIE1v biwgSmFuIDIxLCAyMDE5IGF0IDU6MzUgUE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmsg eW91IGd1eXMhDQoNCg0KT24gTW9uZGF5LCBKYW51YXJ5IDIxLCAyMDE5LCBWaXR0b3JpbyBCZXJ0 b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90 ZToNCkhpIFJpZmFhdCwNCmFic29sdXRlbHkuIEJyaWFuIGFuZCBteXNlbGYgYWxyZWFkeSBzdGFy dGVkIHdvcmtpbmcgb24gc29tZSBsYW5ndWFnZSwgaG93ZXZlciB0aGlzIHdlZWsgaGUgaXMgaW4g dmFjYXRpb24gaGVuY2UgaXQgbWlnaHQgdGFrZSBmZXcgZGF5cyBiZWZvcmUgd2UgY29tZSBiYWNr IHRvIHRoZSBsaXN0IHdpdGggc29tZXRoaW5nLg0KQ2hlZXJzLA0KVi4NCg0KT24gTW9uLCBKYW4g MjEsIDIwMTkgYXQgOTozNSBBTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWls LmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpCcmlhbiwgVml0dG9y aW8sDQoNClRvIG1vdmUgdGhpcyBkaXNjdXNzaW9uIGZvcndhcmQsIGNhbiB5b3UgZ3V5cyBzdWdn ZXN0IHNvbWUgdGV4dCB0byBtYWtlIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgdXNhZ2UgY2xlYXJl cj8NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBNb24sIEphbiAyMSwgMjAxOSBhdCAxMDoz MiBBTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KQXMgSSBzdWdnZXN0ZWQgYmVmb3JlLCBJIGRvIHRoaW5rIHRoYXQncyB3aXRoaW4gdGhlIGJv dW5kcyBvZiB0aGUgZHJhZnQncyBkZWZpbml0aW9uIG9mICdyZXNvdXJjZScgYXMgYSBVUkkuIEFu ZCB0aGF0IHBlcmhhcHMgYWxsIHRoYXQncyBuZWVkZWQgaXMgc29tZSBtaW5vciBhZGp1c3RtZW50 IGFuZC9vciBhdWdtZW50YXRpb24gb2Ygc29tZSB0ZXh0IHRvIG1ha2UgaXQgbW9yZSBjbGVhci4N Cg0KT24gU3VuLCBKYW4gMjAsIDIwMTkgYXQgNzozOSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0 dG9yaW9AYXV0aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCltzZW50 IHRvIEpvaG4gb25seSBieSBtaXN0YWtlLCByZXNlbmRpbmcgdG8gdGhlIE1MXQ0KDQpJbiBBenVy ZSBBRCB2MSAmIEFERlMsIHRoYXQncyByZXNvdXJjZS4uIEl0IGNvdWxkIGJlIHVzZWQgZm9yIGJv dGggbmV0d29yayBhbmQgbG9naWNhbCBpZHMsIHdpdGggdGhlIGNvbmNyZXRlIHVzYWdlIGluIHRo ZSB3aWxkIEkgZGVzY3JpYmVkIGVhcmxpZXIuDQpJbiBBenVyZSBBRCB2MiwgdGhlIHJlc291cmNl IGFzIGV4cGxpY2l0IHBhcmFtZXRlciAobmV0d29yaywgbG9naWMgb3Igb3RoZXJ3aXNlKSBpcyBn b25lIGFuZCBpcyBleHByZXNzZWQgYXMgcGFydCBvZiB0aGUgc2NvcGUgc3RyaW5nIG9mIGFsbCB0 aGUgc2NvcGVzIHJlcXVlc3RlZCBmb3IgYSBnaXZlbiByZXNvdXJjZS0gYnV0IGl0IHN0aWxsIGV4 aXN0IGluIHByYWN0aWNlIHRobyBhcyBpdCBzdGlsbCBlbmQgdXAgaW4gdGhlIHJlc3VsdGluZyBh dWQgb2YgdGhlIGlzc3VlZCB0b2tlbi4NClRoaXMgaXMgOSBtb250aHMgb2xkIGluZm8gaGVuY2UN Cg0KT24gU3VuLCBKYW4gMjAsIDIwMTkgYXQgMTc6NTggSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3 anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KV2hhdCBpcyB0aGUg cGFyYW1ldGVyIHRoYXQgTWljcm9zb2Z0IGlzIHVzaW5nPw0KT24gMS8yMC8yMDE5IDM6NTkgUE0s IFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOg0KRmlyc3Qgb2YgYWxsLCBpdCB3YXNuJ3QgbXkgaW50 ZW50IHRvIGRpc3J1cHQgdGhlIGVzdGFibGlzaGVkIHByb2Nlc3MuIEluIG15IGZvcm1lciBwb3Np dGlvbiBJIHdhc24ndCBtb25pdG9yaW5nIHRob3NlIGRpc2N1c3Npb25zIGhlbmNlIEkgZGlkbid0 IGhhdmUgYSBjaGFuY2UgdG8gb2ZmZXIgZmVlZGJhY2suIFdoZW4gSSBzYXcgc29tZXRoaW5nIHRo YXQgZ2F2ZSBtZSB0aGUgaW1wcmVzc2lvbiBtaWdodCBsZWFkIHRvIGlzc3VlcywgYW5kIGdpdmVu IHRoYXQgSSB3b3JrZWQgd2l0aCBhY3R1YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNp bmcgYSBzaW1pbGFyIHBhcmFtZXRlciBmb3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50 IHRvIGJyaW5nIHRoaXMgdXAuIEkgcmVhbGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9u IHRoaXMuIEVuZCBvZiBwcmVhbWJsZS4NCg0KVWx0aW1hdGVseSBteSBnb2FsIGlzIGZvciBkZXZl bG9wZXJzIHRvIGhhdmUgZ3VpZGFuY2Ugb24gaG93IHRvIHdvcmsgd2l0aCB0aGUgY29uY2VwdCBv ZiBsb2dpY2FsIHJlc291cmNlIGluIGEgc3RhbmRhcmQgY29tcGxpYW50IHdheSwgaGVuY2UgaXQg ZG9lc24ndCBzdHJpY3RseSBtYXR0ZXIgd2hldGhlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgY29y cmVzcG9uZGluZyBwYXJhbWV0ZXIgbGl2ZXMgaW4gb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBv ciBlbHNld2hlcmUuDQpUaGF0IHNhaWQuIFJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQsIGl0IHdv dWxkIGFwcGVhciB0aGF0IG1vc3Qgb2YgdGhlIHJlYXNvbnMgZm9yIHdoaWNoIHRoZSBzcGVjIHdh cyBjcmVhdGVkIGFwcGx5IHRvIGJvdGggdGhlIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIHRoZSBs b2dpY2FsIHJlc291cmNlIHR5cGVzOiBrbm93aW5nIHdoYXQga2V5cyB0byB1c2UgdG8gZW5jcnlw dCB0aGUgdG9rZW4sIGNvbnN0cmFpbiBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBpbnRlbmRlZCBhdWRp ZW5jZSwgYXZvaWRpbmcgb3ZlcmxvYWRpbmcgc2NvcGVzIHdpdGggcmVzb3VyY2UgaW5kaWNhdGlu ZyBwYXJ0cy4uLiB0aG9zZSBhbGwgYXBwbHkgdG8gbmV0d29yayBhZGRyZXNzYWJsZSBhbmQgbG9n aWMgaWRlbnRpZmllcnMgYWxpa2UuIEFuZCBib3RoIHBhcmFtZXRlcnMgYXJlIGV4cGVjdGVkIHRv IHJlc3VsdCBpbiBhdWRpZW5jZSByZXN0cmljdGVkIHRva2Vucy4gSXQgc2VlbXMgdGhlIG9ubHkg ZGlmZmVyZW5jZSBjb21lcyBhdCB0b2tlbiB1c2FnZSB0aW1lLCB3aXRoIHRoZSBuZXR3b3JrIGFk ZHJlc3NhYmxlIGNhc2UgZ2l2aW5nIG1vcmUgZ3VhcmFudGVlcyB0aGF0IHRoZSB0b2tlbiB3aWxs IGdvIHRvIGl0cyBpbnRlbmRlZCByZWNpcGllbnQsIGJ1dCB0aGUgcmVxdWVzdCBhbmQgYXVkaWVu Y2UgcmVzdHJpY3Rpb24gc3ludGF4IHNlZW1zIHRvIGJlIGV4YWN0bHkgdGhlIHNhbWUuDQpPbiB0 b3Agb2YgdGhpczogaW4gdGhlIDk5Ljk5OSUgb2YgdGhlIHNjZW5hcmlvcyBJIGVuY291bnRlcmVk IGluIHRoZSB3aWxkIGluIHRoZSBsYXN0IDUgeWVhcnMgb2YgdXNpbmcgdGhlIHJlc291cmNlIHBh cmFtZXRlciBpbiB0aGUgTVMgZWNvc3lzdGVtLCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciB3YXMg a25vd24gYXQgZGVzaWduIHRpbWU6IHRoZSBkZXZlbG9wZXIgZGlzY292ZXJlZCBpdCBvdXQgb2Yg YmFuZCBhbmQgcGxhY2VkIGl0IGluIHRoZSBhcHAgY29uZmlnIGF0IGRlcGxveW1lbnQgdGltZS4g VGhvc2UgYXJlbid0IGZyaW5nZSBjYXNlcyBJIG9jY2FzaW9uYWxseSBlbmNvdW50ZXJlZDogdGhl IHJlc291cmNlIHBhcmFtZXRlciBpbiBBenVyZSBBRCB2MSBhbmQgQURGUyB3YXMgbWFuZGF0b3J5 LCBoZW5jZSBsaXRlcmFsbHkgZXZlcnkgc29sdXRpb24gaSBzYXcgb3IgdG91Y2hlZCB1c2VkIGl0 LiBBcyBCcmlhbiBzdWdnZXN0ZWQsIHRoaXMgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgc2VjdXJp dHkgYWR2YW50YWdlcyBvZiB0aGUgbmV0d29yayBhZGRyZXNzYWJsZSBjYXNlIGFyZW4ndCBhcyBw cm9ub3VuY2VkIGFzIGluIHRoZSBjYXNlIGluIHdoaWNoIHRoZSBjbGllbnQgZGlzY292ZXJzIHRo ZSByZXNvdXJjZSBpZGVudGlmaWVyIGF0IHJ1bnRpbWUuIFRoaXMgaXNuJ3QganVzdCBiZWNhdXNl IHRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24gc3VnZ2VzdGluZyBsb2NhdGlvbiBzaG91bGQgYmUg ZXhwbGljaXRseSBpbmRpY2F0ZWQsIGl0J3MgYmVjYXVzZSB0aGVyZSBhcmUgbWFueSBwcmFjdGlj YWwgYWR2YW50YWdlcyBhdCBkZXZlbG9wbWVudCBhbmQgZGVwbG95bWVudCB0aW1lIHRvIGJlIGFi bGUgdG8gdXNlIGxvZ2ljYWwgaWRlbnRpZmllcnMtIGFuZCBpZiB0aGUgY29uY3JldGUgc2VjdXJp dHkgYWR2YW50YWdlcyBkb24ndCBhcHBseSB0byB0aGUgdGhlaXIgY2FzZSwgcGVvcGxlIHdpbGwg c2ltcGx5IG5vdCBjb21wbHkuDQoNCkluIHN1bW1hcnk6IGNyZWF0aW5nIHR3byBkaWZmZXJlbnQg cGFyYW1ldGVycyBpbiB0d28gZGlmZmVyZW50IGRvY3VtZW50cyBpcyBiZXR0ZXIgdGhhbiBpZ25v cmluZyBoZSBsb2dpY2FsIGlkZW50aWZpZXIgY2FzZSBhbHRvZ2V0aGVyLCBob3dldmVyIEkgdGhp bmsgdGhhdCBub3QgYWNrbm93bGVkZ2luZyB0aGUgbG9naWNhbCBpZCBjYXNlIGluIG9hdXRoLXJl c291cmNlLWluZGljYXRvcnMgaXMgZ29pbmcgdG8gY3JlYXRlIGNvbmZ1c2lvbiBhbmQgdWx0aW1h dGVseSBub3QgYmUgYXMgdXNlZnVsIHRvIHRoZSBkZXZlbG9wZXIgY29tbXVuaXR5IGFzIGl0IGNv dWxkIGJlLg0KDQoNCg0KT24gU2F0LCBKYW4gMTksIDIwMTkgYXQgMTI6MzggUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToN CisxIHRvIE1pa2UgYW5kIEpvaG7igJlzIGNvbW1lbnRzLg0KUGhpbA0KDQpPbiBKYW4gMTksIDIw MTksIGF0IDEyOjM0IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgYWxzbyBhZ3JlZSB0aGF0IOKAnHJlc291cmNl4oCdIHNo b3VsZCBiZSBhIHNwZWNpZmljIG5ldHdvcmstYWRkcmVzc2FibGUgVVJMIHdoZXJlYXMgYSBzZXBh cmF0ZSBhdWRpZW5jZSBwYXJhbWV0ZXIgKGxpa2Ug4oCcYXVk4oCdIGluIEpXVHMpIGNhbiByZWZl ciB0byBvbmUgb3IgbW9yZSBsb2dpY2FsIHJlc291cmNlcy4gIFRoZXkgYXJlIGRpZmZlcmVudCwg aWYgcmVsYXRlZCwgdGhpbmdzLg0KDQpOb3RlIHRoYXQgdGhlIEFDRSBXRyBpcyBwcm9wb3Npbmcg dG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciDigJxyZXFfYXVk4oCdIGlu IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMt MDEgLSBwYXJ0bHkgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBPQXV0aCBXRyBtZW1iZXJzLiAgVGhp cyBpcyBhIGdlbmVyYWwgT0F1dGggcGFyYW1ldGVyLCB3aGljaCBhbnkgT0F1dGggZGVwbG95bWVu dCB3aWxsIGJlIGFibGUgdG8gdXNlLg0KDQpJIHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hh bmdlcyBhcmUgbmVlZGVkIHRvIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywg YXMgdGhlIGxvZ2ljYWwgYXVkaWVuY2Ugd29yayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90 aGVyIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKb2huIEJy YWRsZXkNClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDE5LCAyMDE5IDk6MDEgQU0NClRvOiBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPj4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRo MC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOlZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmll dGYub3JnPj47IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNCldlIG5lZWQgdG8gZGVjaWRl IGlmIHdlIHdhbnQgdG8gbWFrZSBhIGNoYW5nZS4NCg0KRm9yIHNlY3VyaXR5IHdlIGFyZSBsb2Nh dGlvbiBjZW50cmljLg0KDQpJIHByZWZlciB0byBrZWVwIHJlc291cmNlIGxvY2F0aW9uIHNlcGFy YXRlIGZyb20gbG9naWNhbCBhdWRpZW5jZSB0aGF0IGNhbiBiZSBhIHNjb3BlIG9yIG90aGVyIHBh cmFtZXRlci4NCg0KSWYgYmVjb21lcyBoYXJkZXIgZm9yIHBlb3BsZSB0byB1c2UgdGhlIHBhcmFt ZXRlciBjb3JyZWN0bHkgaWYgd2UgYXJlIHRvbyBmbGV4aWJsZS4NCg0KSSB3b3VsZCByYXRoZXIg aGF2ZSBhIHNlcGFyYXRlIGxvZ2ljYWwgYXVkaWVuY2UgcGFyYW1ldGVyIGlmIHdlIHRoaW5rIHdl IHdhbnQgb25lLg0KDQpKb2huIEIuDQoNCk9uIFNhdCwgSmFuIDE5LCAyMDE5LCAxMTo0MSBBTSBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPiB3cm90ZToNCk5vIGFwb2xvZ3kgbmVlZGVkLCBSaWZhYXQuIEFu ZCBJIGFwb2xvZ2l6ZSBpZiB3aGF0IEkgc2FpZCBjYW1lIG9mZiB0aGUgd3Jvbmcgd2F5LiBJIHdh cyBqdXN0IHRyeWluZyB0byBtYWtlIGxpZ2h0IG9mIHRoZSBzaXR1YXRpb24uLiBBbmQgSSBhZ3Jl ZSB0aGF0IHdlIHNob3VsZCBub3QgYmUgaGFtc3RydW5nIGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVy ZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBzZW5zZSB0byBiZSBmbGV4aWJsZSB3aXRoIHRoaW5n cy4NCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNjoyMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYg PHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3Jv dGU6DQpTb3JyeSBCcmlhbiwgSSB3YXMgbm90IGNsZWFyIHdpdGggbXkgc3RhdGVtZW50Lg0KSSBt ZWFudCB0byBzYXkgdGhhdCB3ZSBzaG91bGQgbm90IGFsbG93IHRoZSBwcm9jZXNzIHRvIHByZXZl bnQgdGhlIFdHIGZyb20gcHJvZHVjaW5nIGEgcXVhbGl0eSBkb2N1bWVudCB3aXRob3V0IGlzc3Vl cywgYXNzdW1pbmcgdGhlcmUgaXMgYW4gaXNzdWUgaW4gdGhlIGZpcnN0IHBsYWNlLg0KSWRlYWxs eSB3ZSB3YW50IHRvIGdldCB0aGVzZSBpZGVudGlmaWVkIGR1cmluZyB0aGUgV0dMQywgYnV0IHRo aW5ncyBoYXBwZW4gYW5kIHNvbWV0aW1lcyB0aGUgV0cgbWlzc2VzIHNvbWV0aGluZy4NCg0KSSBo ZWFyIHlvdSBhbmQgYWdyZWUgdGhhdCB0aGlzIG1ha2UgdGhpbmdzIGRpZmZpY3VsdCBmb3IgYXV0 aG9ycy4gV2Ugd2lsbCBtYWtlIHN1cmUgdGhhdCB0aGlzIGRvZXMgbm90IGJlY29tZSB0aGUgbm9y bSwgYW5kIHdlIHdpbGwgdHJ5IHRvIHN0aWNrIHRvIHRoZSBwcm9jZXNzIGFzIG11Y2ggYXMgcG9z c2libGUuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQg NTozNSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpUaGFua3MgUmlmYWF0LiBQcm9j ZXNzIGlzIGFzIHByb2Nlc3MgZG9lcywgcmlnaHQ/IEkgZG8ga2luZGEgd2FudCB0byBncnVtYmxl IGFib3V0IFdHQ0wgaGF2aW5nIHBhc3NlZCBhbHJlYWR5IGJ1dCB0aGF0J3MgbW9zdGx5IGJlY2F1 c2UgcmVwbHlpbmcgdG8gdGhlc2Uga2luZHMgb2YgdGhyZWFkcyBpcyBoYXJkIGZvciBtZSBhbmQg SSdsbCBqdXN0IGdldCBvdmVyIGl0Li4uDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhpbmdz LCB0aGUgc2VjdXJpdHkgY29uY2VybnMgY29tZSBpbnRvIHBsYXkgd2hlbiB0aGUgY2xpZW50IGlz IGJlaW5nIHRvbGQgdGhlIGJ5IHRoZSByZXNvdXJjZSBob3cgdG8gaWRlbnRpdHkgdGhlIHJlc291 cmNlIGxpa2UgaXMgZGVzY3JpYmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVkLTAxIGFuZCB1c2luZyB0aGUgYWN0dWFsIGxvY2F0aW9u IGluIHRoYXQgY29udGV4dCAsYWxvbmcgd2l0aCBzb21lIG90aGVyIGNoZWNrcyBwcmVzY3JpYmVk IGluIHRoYXQgZHJhZnQsIHByZXZlbnRzIHRoZSBraW5kIG9mIGlzc3VlcyBKb2huIGRlc2NyaWJl ZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQuDQoNCkluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQga25v d3MgdGhlIHJlc291cmNlIGEgcHJpb3JpIG9yIG91dC1vZi1iYW5kIG9yIGNvbmZpZ3VyZWQgb3Ig d2hhdGV2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIHNhbWUgc2VjdXJpdHkgY29uY2VybnMgYXJpc2Uu IEFuZCB1c2luZyBzdWNoIGEga25vd24gdmFsdWUsIGJlIGl0IGFuIGFjdHVhbCBsb2NhdGlvbiBv ciBsb2dpY2FsIHJlcHJlc2VudGF0aW9uLCB3b3VsZCBiZSBva2F5Lg0KDQpUaGUgcmVzb3VyY2Ut aW5kaWNhdG9ycyBkcmFmdCBpcyBhZG1pdHRlZGx5IHNvbWV3aGF0IGxvY2F0aW9uLWNlbnRyaWMg aW4gaG93IGl0IHRhbGtzIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgJ3Jlc291cmNlJyBwYXJhbWV0 ZXIuIEJ1dCB1bHRpbWF0ZWx5IGl0IGRlZmluZXMgaXQgYXMgYW4gYWJzb2x1dGUgVVJJIHRoYXQg aW5kaWNhdGVzIHRoZSBsb2NhdGlvbiBvZiB0aGUgdGFyZ2V0IHNlcnZpY2Ugb3IgcmVzb3VyY2Ug d2hlcmUgYWNjZXNzIGlzIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2NhdGlvbiBjYW4gYmUgdmFyeWlu ZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1c2luZyBhIFVSSSBhcyAncmVz b3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2FsIGlkZW50aWZpZXIgdGhhdCBw b2ludHMgdG8gc29tZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBk cmFmdC4NCg0KU28gbWF5YmUgdGhlIGRyYWZ0IGlzIG9rYXkgYXMgaXM/DQoNCk9yIHBlcmhhcHMg dGhhdCdzIHRvbyBtdWNoIHRvIGJlIGxlZnQgYXMgYW4gZXhlcmNpc2VyIHRvIHRoZSByZWFkZXI/ ICBBbmQgc29tZSB0ZXh0IHNob3VsZCBiZSBhZGRlZCBhbmQvb3IgYWRqdXN0ZWQgc28gdGhlIHJl c291cmNlLWluZGljYXRvcnMgZHJhZnQgd291bGQgYmUgYSBsaXR0bGUgbW9yZSBvcGVuL2NsZWFy IGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFsdWUgcG90ZW50aWFsbHkgYmVpbmcgbW9yZSBvZiBhIGxv Z2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0d29y ayBhZGRyZXNzYWJsZSBVUkw/DQoNCg0KDQpPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxOjE4IFBN IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQu aWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgd291bGRuJ3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQg dGhlIHByb2Nlc3MuDQpJZiBpdCBtYWtlcyBzZW5zZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50LCB0 aGVuIGZlZWwgZnJlZSB0byBkbyB0aGF0Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIEZy aSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNClllcyB0aGUgbG9naWNhbCByZXNv dXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgInNjb3BlIg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyBs aWtlIFBpbmcgYW5kIEF1dGgwIGhhdmUgYmVlbiBhZGRpbmcgYW5vdGhlciBwYXJhbWV0ZXIgImF1 ZCIgdG8gaWRlbnRpZnkgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgYW5kIHRoZW4gdXNpbmcgc2NvcGVz IHRvIGRlZmluZSBwZXJtaXNzaW9ucyB0byB0aGUgcmVzb3VyY2UuDQoNCkZvcnR1bmF0ZWx5LCB3 ZSBhcmUgdXNpbmcgYSBkaWZmZXJlbnQgcGFyYW1ldGVyIG5hbWUgc28gbm90IHN0ZXBwaW5nIG9u IHRoYXQuLg0KDQpXZSBjb3VsZCBnbyBiYWNrIGFuZCB0cnkgdG8gYWRkIHRleHQgZXhwbGFpbmlu ZyB0aGUgZGlmZmVyZW5jZSwgYnV0IHdlIGFyZSBxdWl0ZSBsYXRlIGluIHRoZSBwcm9jZXNzLg0K DQpJIGFncmVlIHRoYXQgYSBsb2dpY2FsIHJlc291cmNlIHBhcmFtZXRlciBtYXkgYmUgaGVscGZ1 bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZHJhZnQuDQoNCkpvaG4gQi4N Cg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNDozOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdy b3RlOg0KRG9lc27igJl0IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRl IGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj8NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRm Lm9yZzxtYWlsdG86NDBhdXRoMC4uY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwg SmFudWFyeSAxOCwgMjAxOSBhdCA1OjQ3IEFNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3 anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KQ2M6IElFVEYgb2F1dGggV0cgPG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzLTAxDQoNClRoYW5rcyBKb2huIGZvciB0aGUgYmFja2dyb3VuZC4NCkkgYWdyZWUgdGhh dCBmcm9tIHRoZSBjbGllbnQgdmFsaWRhdGlvbiBQb1YsIGhhdmluZyBhbiBpZGVudGlmaWVyIGNv cnJlc3BvbmRpbmcgdG8gYSBsb2NhdGlvbiBtYWtlcyB0aGluZ3MgbW9yZSBzb2xpZC4NClRoYXQg c2FpZDogdGhlIHVzZSBvZiBsb2dpY2FsIGlkZW50aWZpZXJzIGlzIHdpZGVzcHJlYWQsIGFzIGl0 IGhhcyBzaWduaWZpY2FudCBwcmFjdGljYWwgYWR2YW50YWdlcyAodGhpbmsgb2Ygc2VydmljZXMg dGhhdCBhc3NpZ24gZ2VuZXJhdGVkIGhvc3RpbmcgVVJMcyBvbmx5IGF0IGRlcGxveW1lbnQgdGlt ZSwgb3Igc2VydmljZXMgdGhhdCBhcmUgc29tZWhvdyBncm91cGVkIHVuZGVyIHRoZSBzYW1lIGxv Z2ljYWwgYXVkaWVuY2UgYWNyb3NzIHJlZ2lvbnMvZW52aXJvbm1lbnQvZGVwbG95bWVudHMpLiBQ ZW9wbGUgd29uJ3Qgc3RvcCB1c2luZyBsb2dpY2FsIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkg b2Z0ZW4gaGF2ZSBubyBhbHRlcm5hdGl2ZSAoZ2VuZXJhdGluZyBuZXcgYXVkaWVuY2VzIG9uIHRo ZSBmbHkgYXQgdGhlIEFTIGV2ZXJ5IHRpbWUgeW91IGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFz c2lnbmVkIGEgbmV3IFVSTCBjYW4gYmUgdW5mZWFzaWJsZSkuIExlYXZpbmcgYSB3aWRlbHkgdXNl ZCBhcHByb2FjaCBhcyBleGVyY2lzZSB0byB0aGUgcmVhZGVyIHNlZW1zIGEgZGlzc2VydmljZSB0 byB0aGUgY29tbXVuaXR5LCBnaXZlbiB0aGF0IHRoaXMgbWlnaHQgbGVhZCB0byB2ZW5kb3JzIChm b3IgZXhhbXBsZSBNaWNyb3NvZnQgYW5kIEF1dGgwKSBrZWVwaW5nIHRoZWlyIG93biBwcm9wcmll dGFyeSBwYXJhbWV0ZXJzLCBvciBkZXZlbG9wZXJzIG1pc3VzaW5nIHRoZSBvbmVzIGluIHBsYWNl OyB3b3VsZCBtYWtlIGl0IGhhcmQgZm9yIFNESyBkZXZlbG9wZXJzIHRvIHByb3ZpZGUgbGlicmFy aWVzIHRoYXQgd29yayBvdXQgb2YgdGhlIGJveCB3aXRoIGRpZmZlcmVudCBBU2VzOyBhbmQgc28g b24uDQpXb3VsZCBpdCBiZSBmZWFzaWJsZSB0byBhZGQgc3VjaCBwYXJhbWV0ZXIgZGlyZWN0bHkg aW4gdGhpcyBzcGVjPyBUaGF0IHdvdWxkIGVsaW1pbmF0ZSB0aGUgaW50ZXJvcCBpc3N1ZXMsIGFu ZCBhbHNvIGdpdmVzIHVzIGEgY2hhbmNlIHRvIGZ1bGx5IHdhcm4gcGVvcGxlIGFib3V0IHRoZSBz ZWN1cml0eSBzaG9ydGNvbWluZ3Mgb2YgY2hvb3NpbmcgdGhhdCBhcHByb2FjaC4NCg0KDQoNCk9u IFRodSwgSmFuIDE3LCAyMDE5IGF0IDQ6MzIgUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi LmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KV2UgaGF2ZSBkaXNjdXNz ZWQgdGhpcy4NCg0KQXVkaWVuY2VzIGNhbiBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVudGlmaWVy cy4NCg0KVGhpcyBob3dldmVyIGlzIGEgbW9yZSBzcGVjaWZpYyBsb2NhdGlvbi4gIFRoZSBBUyBp cyBmcmVlIHRvIG1hcCB0aGUgbG9jYXRpb24gaW50byBzb21lIGFic3RyYWN0IGF1ZGllbmNlIGlu IHRoZSBBVC4NCg0KRnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcgb25jZSB0aGUgY2xpZW50 IHN0YXJ0cyBhc2tpbmcgZm9yIGxvZ2ljYWwgcmVzb3VyY2VzIGl0IGNhbiBiZSB0cmlja2VkIGlu dG8gYXNraW5nIGZvciB0aGUgd3Jvbmcgb25lIGFzIGEgYmFkIHJlc291cmNlIGNhbiBhbHdheXMg bGllIGFib3V0IHdoYXQgbG9naWNhbCByZXNvdXJjZSBpdCBpcy4NCg0KSWYgd2Ugd2VyZSB0byBj aGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3b3VsZCB2YWxpZGF0ZSBpdCBiZWNvbWVzIGNoYWxsZW5n aW5nIHRvIGltcG9zc2libGUuDQoNClRoZSBBUyBpcyBmcmVlIHRvIGRvIHdoYXRldmVyIG1hcHBp bmcgb2YgbG9jYXRpb25zIHRvIGlkZW50aWZpZXJzIGl0IG5lZWRzIGZvciBhY2Nlc3MgdG9rZW5z Lg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byBrZWVwIGFkZGl0aW9uYWwgcGFy YW1ldGVycyBsaWtlIGxvZ2ljYWwgYXVkaWVuY2UsIGJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0 ZSBmcm9tIHJlc291cmNlLg0KDQpKb2huIEIuDQpPbiAxLzE3LzIwMTkgOTo1NiBBTSwgUmlmYWF0 IFNoZWtoLVl1c2VmIHdyb3RlOg0KSGkgVml0dG9yaW8sDQoNClRoZSB0ZXh0IHlvdSBxdW90ZWQg aXMgY29waWVkIGZvcm0gdGhlIGFic3RyYWN0IG9mIHRoZSBkcmFmdCBpdHNlbGYuDQoNCg0KQXV0 aG9ycywNCg0KU2hvdWxkIHRoZSBkcmFmdCBiZSB1cGRhdGVkIHRvIGNvdmVyIHRoZSBsb2dpY2Fs IGlkZW50aWZpZXIgY2FzZT8NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBUaHUsIEphbiAx NywgMjAxOSBhdCA4OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRoMC5jb208 bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+IHdyb3RlOg0KSGkgUmlmYWF0LA0Kb25lIGRldGFp bC4gVGhlIHRlY2ggc3VtbWFyeSBzYXlzDQoNCg0KQW4gZXh0ZW5zaW9uIHRvIHRoZSBPQXV0aCAy LjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsgZGVmaW5pbmcgcmVxdWVzdA0KDQpwYXJhbWV0ZXJz IHRoYXQgZW5hYmxlIGEgY2xpZW50IHRvIGV4cGxpY2l0bHkgc2lnbmFsIHRvIGFuIGF1dGhvcml6 YXRpb24gc2VydmVyDQoNCmFib3V0IHRoZSBsb2NhdGlvbiBvZiB0aGUgcHJvdGVjdGVkIHJlc291 cmNlKHMpIHRvIHdoaWNoIGl0IGlzIHJlcXVlc3RpbmcNCg0KYWNjZXNzLg0KQnV0IGF0IGxlYXN0 IGluIHRoZSBNaWNyb3NvZnQgaW1wbGVtZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVy IGRvZXNuJ3QgaGF2ZSB0byBiZSBhIG5ldHdvcmsgYWRkcmVzc2FibGUgVVJMIChhbmQgaWYgaXQg aXMsIGl0IGRvZXNuJ3Qgc3RyaWN0bHkgbmVlZCB0byBtYXRjaCB0aGUgYWN0dWFsIHJlc291cmNl IGxvY2F0aW9uKS4gSXQgY2FuIGJlIGEgbG9naWNhbCBpZGVudGlmaWVyLCB0aG8gdXNpbmcgdGhl IGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbiB0aGVyZSBoYXMgYmVuZWZpdHMgKGRvbWFpbiBvd25l cnNoaXAgY2hlY2ssIHByZXZlbnRpb24gb2YgdG9rZW4gZm9yd2FyZGluZyBldGMpLg0KU2FtZSBm b3IgQXV0aDAsIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIg cmF0aGVyIHRoYW4gYSBsb2NhdGlvbi4NCg0KDQoNCk9uIFdlZCwgSmFuIDE2LCAyMDE5IGF0IDY6 MzIgUE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJp ZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KQWxsLA0KDQpUaGUgZm9sbG93aW5nIGlzIHRo ZSBmaXJzdCBzaGVwaGVyZCB3cml0ZS11cCBmb3IgdGhlIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycy0wMSBkb2N1bWVudC4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAv DQoNClBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IGlmIEkgbWlzc2VkIGFueXRo aW5nLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJ VFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo cykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJz IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLi4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r IHlvdS5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBs aXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_BL0PR00MB02920F6A16D28D1652F21B2DF59A0BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIHZpcnR1YWwgb2ZmaWNlIGhvdXJz IGluIG15IGNhbGVuZGFyIHN0YXJ0IDEvMiBob3VyIGJlZm9yZSB0aGF0LiAmbmJzcDtJZiB0aGUg dGltZSBoYXMgY2hhbmdlZCwgY2FuIHlvdSBoYXZlIHRoZSBtZWV0aW5nIG9yZ2FuaXplciB1cGRh dGUgdGhlIGNhbGVuZGFyIGVudHJ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwuY29tJmd0OyA8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjQsIDIwMTkgMTI6NDYgUE08YnI+DQo8Yj5U bzo8L2I+IEdlb3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2hAYW9sLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpb0BhdXRoMC5jb20mZ3Q7OyBNaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBm b3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBjb21pbmcgTW9uZGF5LCBKYW4gMjggQCAxMjowMHBt IEVhc3Rlcm4gVGltZSwgd2UgaGF2ZSBhIHNjaGVkdWxlZCBPQXV0aCBXRyBWaXJ0dWFsIE9mZmlj ZSBtZWV0aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5GZWVsIGZyZWUgdG8gYXR0ZW5kIHRoZSBtZWV0aW5nIHRvIGRpc2N1c3MgdGhp cyB0b3BpYyB0byB0cnkgdG8gZ2V0IHRvIGEgY29uY2x1c2lvbiBvbiB0aGlzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwO1JpZmFhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDIzLCAyMDE5IGF0IDM6MDAg UE0gR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29t QGRtYXJjLmlldGYub3JnIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luOjAuLjhleCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiYj NDM7MTxicj4NCjxicj4NCkFsc28sIEkgZG9uJ3QgcmVhbGx5IGxpa2UgdGhlIHBhcmFtZXRlciBu YW1lICdyZXFfYXVkJyA6KSBJJ20gbm90IDEwMCUgY29udmluY2VkIHRoYXQgJ2F1ZGllbmNlJyBh bmQgJ2xvZ2ljYWwgcmVzb3VyY2UnIGFyZSBjb21wbGV0ZWx5IG92ZXJsYXBwaW5nIGNvbmNlcHRz LiBXZSBjYW4gcG90ZW50aWFsbHkgbWFrZSB0aGVtIGNvbXBsZXRlbHkgb3ZlcmxhcHBpbmcgYnV0 IHdlIG5lZWQgdGV4dCB0byB0aGF0IGVmZmVjdC4NCjxicj4NCjxicj4NCkkgYWxzbyBiZWxpZXZl IHRoYXQgd2UgZG9uJ3QgaGF2ZSBhIGNvbXBsZXRlIHNvbHV0aW9uIGZvciBhbGwgZGVwbG95bWVu dHMgdXNpbmcgZXhhY3QgbG9jYXRpb25zIChzZWUgbXkgcHJldmlvdXMgZW1haWwpLjxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQpHZW9yZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMS8yMy8xOSAyOjUwIFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgbWVudGlvbmVkIGJlbG93LCBJIGFncmVlIHRoZSB0d28gY2FuIGJlIHNlcGFyYXRlZC0g YnV0IEkgYWxzbyBhZ3JlZSB3aXRoIEdlb3JnZSBvbiB0aGUgbmVlZCB0byBiZSBjbGVhciBhbiBl YXN5IHRvIHJlZmVyZW5jZSBmb3IgZGV2ZWxvcGVycy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgYWRkaW5nIGEgcmVmZXJlbmNlIHRvIHJlcV9hdWQg d291bGQganVzdCByYWlzZSB0aGUgY3ljbG9tYXRpYyBjb21wbGV4aXR5IG9mIHRoZSBzcGVjcywg d2hpY2ggaXMgYWxyZWFkeSB1bnVzYWJseSBoaWdoIGZvciBtZXJlIG1vcnRhbHMgaW4gdGhlIE9B dXRoMi9PSURDIGZhbWlseSBvZiBzcGVjcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGFkZGl0aW9uYWwgY29tcGxpY2F0aW9uIGlzIHRo YXQgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHJldXNpbmcgYSBwYXJhbWV0ZXIgdGhhdCBpcyBhbHJl YWR5IHVzZWQgaW4gYQ0KPGI+dmVyeTwvYj4gbGFyZ2UgbnVtYmVyIG9mIHByb2R1Y3Rpb24gc3lz dGVtcyAoc21hbGwgZXhhbXBsZSA8YSBocmVmPSJodHRwczovL2RvY3MubWljcm9zb2Z0LmNvbS9l bi11cy9henVyZS9hY3RpdmUtZGlyZWN0b3J5L2RldmVsb3AvdjEtcHJvdG9jb2xzLW9hdXRoLWNv ZGUiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+KSwgYW5kIHdob3NlIGNvbmNyZXRlIHNlbWFu dGljIGhhcHBlbnMgdG8gYmUgcHJldmFsZW50bHkgbG9naWMgaWRlbnRpZmllci4gSWYgdGhlIHBh cmFtZXRlciB5b3UgYXJlIGRlZmluaW5nIGhlcmUgaGFzIGEgZGlmZmVyZW50IHNlbWFudGljLCBh dCB0aGUgdmVyeSBsZWFzdCBpdCB3b3VsZCBzZWVtIGdvb2QgaHlnaWVuZSB0byByZW5hbWUgaXQg dG8gYXZvaWQgY29sbGlzaW9uIGFuZCBjb25mdXNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDIzLCAyMDE5IGF0IDEx OjAzIEFNIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHdpdGggSm9obuKAmXMgbG9naWMuJm5ic3A7IFRo ZSBwaHlzaWNhbCByZXNvdXJjZSBhbmQgbG9naWNhbCByZXNvdXJjZSBzaG91bGQgdXNlIGRpZmZl cmVudCBpZGVudGlmaWVycy4mbmJzcDsgRm9ydHVuYXRlbHksIHdlIGFscmVhZHkgaGF2ZSDigJxy ZXNvdXJjZeKAnSBhbmQNCiDigJxyZXFfYXVk4oCdIGZvciB0aGVzZSBwYXJhbWV0ZXJzLiZuYnNw OyBJIGJlbGlldmUgd2XigJlyZSBnb29kIHRvIGdvLCBhcy1pcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsN CjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgSmFudWFyeSAyMywgMjAxOSAxMDo1NiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVwIGZv ciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+SSBkb24ndCB0aGluayB0aGV5IGFyZSBuZWNlc3NhcmlseSBtdXR1YWxseSBleGNs dXNpdmUsIHRoYXQgaXMgd2h5IEkgdGhpbmsgdGhlcmUgaXMgdmFsdWUgaW4gYWxsb3dpbmcgdGhl bSB0byBiZSBzcGVjaWZpZWQgc2VwYXJhdGVseS48bzpwPjwvbzpwPjwvcD4NCjxwPkFzIGFuIEFT IGluIHRoZSBkaXN0cmlidXRlZCBPQXV0aCBjYXNlIGtub3dpbmcgdGhhdCBhIGNsaWVudCBpbnRl cmFjdGluZyB3aXRoIFJTDQo8YSBocmVmPSJodHRwczovL2ZpcmUuaGhzLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZmlyZS5oaHMuY29tPC9hPiBhcyB0aGUgcmVzb3VyY2Ugd2FudHMgYSBP QXV0aCB0b2tlbiB3aXRoIGFuIGF1ZGllbmNlIG9mIEhIUyBhbmQgYSBzY29wZSBvZiByZWFkLg0K PG86cD48L286cD48L3A+DQo8cD5XaXRob3V0IHByb29mIG9mIHBvc3Nlc3Npb24gd2UgbmVlZCB0 byBrZWVwIGJhZCBSUyBmcm9tIGFza2luZyBmb3IgdG9rZW5zIHdpdGggc2NvcGVzIGFuZCBhdWRp ZW5jZXMgb2Ygb3RoZXIgUlMgdGhhdCBjYW4gYmUgcmVwbGF5ZWQuPG86cD48L286cD48L3A+DQo8 cD5JIHJlYWxseSBsaWtlIGtlZXBpbmcgdGhlIHJlc291cmNlIHNpbXBsZSBhbmQgdW5zcG9vZmFi bGUsIGl0IGlzIHRoZSBVUkkgb2YgdGhlIFJTIHdoZXJlIHlvdSBhcmUgcHJlc2VudGluZyB0aGUg QVQuPG86cD48L286cD48L3A+DQo8cD5JIHByZWZlciB0byBrZWVwIHRoYXQgc2VwYXJhdGUgZnJv bSB0aGUgbG9naWNhbCByZXNvdXJjZSB0aGF0IG1heSBzcGFuIG1vcmUgdGhhbiBvbmUgUlMgZW5k cG9pbnQuPG86cD48L286cD48L3A+DQo8cD5NZXJnaW5nIHRoZSB0d28gYW5kIHdlIGFyZSBwcm9i YWJseSBiYWNrIGF0IHRoZSBBUyBsb29raW5nIGludG8gdGhlIFVSSSB0byBmaWd1cmUgb3V0IHdo aWNoIG9uZSBpdCBpcy4mbmJzcDsgSSB0aGluayB0aGF0IGlzIGhhcmRlciBmb3IgaW1wbGVtZW50 YXRpb25zIGFuZCBtb3JlIGxpa2VseSB0byBoYXZlIHNlY3VyaXR5IGlzc3VlcyBkb3duIHRoZSBy b2FkLjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMS8yMy8yMDE5IDE6NDQgUE0sIFZpdHRvcmlvIEJlcnRv Y2NpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBhbGwsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnRoYW5rcyBmb3IgeW91IHBhdGllbmNlLiBCcmlhbiBhbmQgbXlzZWxm IGl0ZXJhdGVkIG9uIG1vZGlmeWluZyB0aGUgdGV4dCB0byBjb3ZlciB0aGUgbG9naWNhbCBpZGVu dGlmaWVyIHVzZSBjYXNlLCBoaWdobGlnaHRpbmcgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBv ZiBnb2luZyB0aGF0IHJvdXRlLiBZb3UNCiBjYW4gZmluZCB0aGUgcmV2aXNlZCB0ZXh0IGluJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3ZpYnJvbmV0L2ktZC9ibG9iL21hc3Rlci9k cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMueG1sIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9naXRodWIuY29tL3ZpYnJvbmV0L2ktZC9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLW9h dXRoLXJlc291cmNlLWluZGljYXRvcnMueG1sPC9hPiwgc2VlIHRoZSBjb21taXRzIGluIHRoZSBo aXN0b3J5DQogZnJvbSBKYW51YXJ5IDIxIGZvciB0aGUgc3BlY2lmaWMgY2hhbmdlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90ZTogSSBh bHNvIGhhZCBhIGNoYXQgd2l0aCBKb2huIG9mZmxpbmUsIGFuZCBoZSBleHByZXNzZWQgdGhlIGRl c2lyZSB0byBzcGxpdCB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGluIHR3byBkaXN0aW5jdCBwYXJh bWV0ZXJzIHRvIGJldHRlciBzaWduYWwgdGhlIGludGVuZGVkIHVzYWdlLiBJIGFtIHN1cmUNCiBo ZSBjYW4gZWxhYm9yYXRlLiBJIGhhdmUgbm90aGluZyBhZ2FpbnN0IGl0IGluIHByaW5jaXBsZSwg YXMgbG9uZyBhcyB3ZSBsZWF2ZSBub3RoaW5nIGFzIGV4ZXJjaXNlIHRvIHRoZSByZWFkZXIgYW5k IHdlIGFyZSB2ZXJ5IGNsZWFyIG9uIHVzYWdlIChlLmcuIG11dHVhbCBleGNsdXNpdml0eSwgZXRj KSBidXQgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gc3BlYWsgdyBCcmlhbiBhYm91dCBpdC4gSWYg dGhlIGRpc2N1c3Npb24gc3RyZXRjaGVzIGZ1cnRoZXIsDQogSSB3b3VsZCBzdWdnZXN0IHdlIHBh dXNlIGl0IGFuZCBsZXQgaGltIGVuam95IGhpcyB0aW1lIG9mZiBmb3IgdGhlIHJlc3Qgb2YgdGhl IHdlZWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDU6MzUgUE0gUmlmYWF0IFNo ZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFuayB5b3UgZ3V5cyEN CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJy Pg0KT24gTW9uZGF5LCBKYW51YXJ5IDIxLCAyMDE5LCBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZpdHRvcmlv QGF1dGgwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBSaWZhYXQsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPmFic29sdXRlbHkuIEJyaWFuIGFuZCBteXNlbGYgYWxyZWFkeSBz dGFydGVkIHdvcmtpbmcgb24gc29tZSBsYW5ndWFnZSwgaG93ZXZlciB0aGlzIHdlZWsgaGUgaXMg aW4gdmFjYXRpb24gaGVuY2UgaXQgbWlnaHQgdGFrZSBmZXcgZGF5cyBiZWZvcmUgd2UgY29tZSBi YWNrIHRvIHRoZSBsaXN0IHdpdGggc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlYuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEphbiAyMSwgMjAx OSBhdCA5OjM1IEFNIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFh dC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkJyaWFuLCBWaXR0b3JpbywNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIG1vdmUgdGhpcyBkaXNjdXNzaW9uIGZvcndhcmQs IGNhbiB5b3UgZ3V5cyBzdWdnZXN0IHNvbWUgdGV4dCB0byBtYWtlIHRoZSBsb2dpY2FsIGlkZW50 aWZpZXIgdXNhZ2UgY2xlYXJlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSmFu IDIxLCAyMDE5IGF0IDEwOjMyIEFNIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJl Zj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBJ IHN1Z2dlc3RlZCBiZWZvcmUsIEkgZG8gdGhpbmsgdGhhdCdzIHdpdGhpbiB0aGUgYm91bmRzIG9m IHRoZSBkcmFmdCdzIGRlZmluaXRpb24gb2YgJ3Jlc291cmNlJyBhcyBhIFVSSS4gQW5kIHRoYXQg cGVyaGFwcyBhbGwgdGhhdCdzIG5lZWRlZCBpcyBzb21lIG1pbm9yIGFkanVzdG1lbnQgYW5kL29y IGF1Z21lbnRhdGlvbg0KIG9mIHNvbWUgdGV4dCB0byBtYWtlIGl0IG1vcmUgY2xlYXIuIDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgSmFu IDIwLCAyMDE5IGF0IDc6MzkgUE0gVml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0 bzpWaXR0b3Jpb0BhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5rIj5WaXR0b3Jpb0BhdXRoMC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjVwdDtjb2xvcjojMzEzMTMx O2JhY2tncm91bmQ6d2hpdGUiPltzZW50IHRvIEpvaG4gb25seSBieSBtaXN0YWtlLCByZXNlbmRp bmcgdG8gdGhlIE1MXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuNXB0O2NvbG9yOiMzMTMx MzE7YmFja2dyb3VuZDp3aGl0ZSI+SW4gQXp1cmUgQUQgdjEgJmFtcDsgQURGUywgdGhhdCdzJm5i c3A7PC9zcGFuPnJlc291cmNlPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi41cHQ7Y29sb3I6IzMx MzEzMTtiYWNrZ3JvdW5kOndoaXRlIj4uLiBJdCBjb3VsZA0KIGJlIHVzZWQgZm9yIGJvdGggbmV0 d29yayBhbmQgbG9naWNhbCBpZHMsIHdpdGggdGhlIGNvbmNyZXRlIHVzYWdlIGluIHRoZSB3aWxk IEkgZGVzY3JpYmVkIGVhcmxpZXIuPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzMxMzEzMSI+SW4gQXp1cmUg QUQgdjIsIHRoZSByZXNvdXJjZSBhcyBleHBsaWNpdCBwYXJhbWV0ZXIgKG5ldHdvcmssIGxvZ2lj IG9yIG90aGVyd2lzZSkgaXMgZ29uZSBhbmQgaXMgZXhwcmVzc2VkIGFzIHBhcnQgb2YgdGhlIHNj b3BlIHN0cmluZyBvZiBhbGwgdGhlIHNjb3Blcw0KIHJlcXVlc3RlZCBmb3IgYSBnaXZlbiByZXNv dXJjZS0gYnV0IGl0IHN0aWxsIGV4aXN0IGluIHByYWN0aWNlIHRobyBhcyBpdCBzdGlsbCBlbmQg dXAgaW4gdGhlIHJlc3VsdGluZyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzMxMzEzMSI+YXVkPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojMzEzMTMxIj4mbmJzcDtvZiB0aGUgaXNzdWVkIHRva2VuLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMzMTMxMzEiPlRoaXMgaXMgOSBtb250aHMgb2xkIGluZm8gaGVuY2U8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gU3VuLCBKYW4gMjAsIDIwMTkgYXQgMTc6NTggSm9obiBCcmFkbGV5ICZs dDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdq dGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cD5XaGF0IGlzIHRoZSBwYXJhbWV0ZXIgdGhhdCBNaWNyb3NvZnQgaXMgdXNpbmc/PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxLzIwLzIwMTkg Mzo1OSBQTSwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkZpcnN0IG9mIGFsbCwgaXQgd2Fzbid0IG15IGludGVudCB0byBkaXNydXB0IHRoZSBlc3Rh Ymxpc2hlZCBwcm9jZXNzLiBJbiBteSBmb3JtZXIgcG9zaXRpb24gSSB3YXNuJ3QgbW9uaXRvcmlu ZyB0aG9zZSBkaXNjdXNzaW9ucyBoZW5jZSBJIGRpZG4ndCBoYXZlIGEgY2hhbmNlIHRvIG9mZmVy IGZlZWRiYWNrLg0KIFdoZW4gSSBzYXcgc29tZXRoaW5nIHRoYXQgZ2F2ZSBtZSB0aGUgaW1wcmVz c2lvbiBtaWdodCBsZWFkIHRvIGlzc3VlcywgYW5kIGdpdmVuIHRoYXQgSSB3b3JrZWQgd2l0aCBh Y3R1YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNpbmcgYSBzaW1pbGFyIHBhcmFtZXRl ciBmb3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50IHRvIGJyaW5nIHRoaXMgdXAuIEkg cmVhbGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9uIHRoaXMuDQogRW5kIG9mIHByZWFt YmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5VbHRpbWF0ZWx5IG15IGdvYWwgaXMgZm9yIGRldmVsb3BlcnMgdG8gaGF2 ZSBndWlkYW5jZSBvbiBob3cgdG8gd29yayB3aXRoIHRoZSBjb25jZXB0IG9mIGxvZ2ljYWwgcmVz b3VyY2UgaW4gYSBzdGFuZGFyZCBjb21wbGlhbnQgd2F5LCBoZW5jZSBpdCBkb2Vzbid0IHN0cmlj dGx5IG1hdHRlciB3aGV0aGVyIHRoZQ0KIGRlZmluaXRpb24gb2YgdGhlIGNvcnJlc3BvbmRpbmcg cGFyYW1ldGVyIGxpdmVzIGluJm5ic3A7b2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBvciBlbHNl d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoYXQgc2FpZC4gUmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCwgaXQgd291bGQgYXBwZWFy IHRoYXQgbW9zdCBvZiB0aGUgcmVhc29ucyBmb3Igd2hpY2ggdGhlIHNwZWMgd2FzIGNyZWF0ZWQg YXBwbHkgdG8gYm90aCB0aGUgbmV0d29yayBhZGRyZXNzYWJsZSBhbmQgdGhlIGxvZ2ljYWwgcmVz b3VyY2UgdHlwZXM6DQoga25vd2luZyB3aGF0IGtleXMgdG8gdXNlIHRvIGVuY3J5cHQgdGhlIHRv a2VuLCBjb25zdHJhaW4gYWNjZXNzIHRva2VucyB0byB0aGUgaW50ZW5kZWQgYXVkaWVuY2UsIGF2 b2lkaW5nIG92ZXJsb2FkaW5nIHNjb3BlcyB3aXRoIHJlc291cmNlIGluZGljYXRpbmcgcGFydHMu Li4gdGhvc2UgYWxsIGFwcGx5IHRvIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIGxvZ2ljIGlkZW50 aWZpZXJzIGFsaWtlLiBBbmQgYm90aCBwYXJhbWV0ZXJzIGFyZSBleHBlY3RlZA0KIHRvIHJlc3Vs dCBpbiBhdWRpZW5jZSByZXN0cmljdGVkIHRva2Vucy4gSXQgc2VlbXMgdGhlIG9ubHkgZGlmZmVy ZW5jZSBjb21lcyBhdCB0b2tlbiB1c2FnZSB0aW1lLCB3aXRoIHRoZSBuZXR3b3JrIGFkZHJlc3Nh YmxlIGNhc2UgZ2l2aW5nIG1vcmUgZ3VhcmFudGVlcyB0aGF0IHRoZSB0b2tlbiB3aWxsIGdvIHRv IGl0cyBpbnRlbmRlZCByZWNpcGllbnQsIGJ1dCB0aGUgcmVxdWVzdCBhbmQgYXVkaWVuY2UgcmVz dHJpY3Rpb24gc3ludGF4IHNlZW1zDQogdG8gYmUgZXhhY3RseSB0aGUgc2FtZS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gdG9w IG9mIHRoaXM6IGluIHRoZSA5OS45OTklIG9mIHRoZSBzY2VuYXJpb3MgSSBlbmNvdW50ZXJlZCBp biB0aGUgd2lsZCBpbiB0aGUgbGFzdCA1IHllYXJzIG9mIHVzaW5nIHRoZSByZXNvdXJjZSBwYXJh bWV0ZXIgaW4gdGhlIE1TIGVjb3N5c3RlbSwgdGhlIHJlc291cmNlIGlkZW50aWZpZXIgd2FzIGtu b3duDQogYXQgZGVzaWduIHRpbWU6IHRoZSBkZXZlbG9wZXIgZGlzY292ZXJlZCBpdCBvdXQgb2Yg YmFuZCBhbmQgcGxhY2VkIGl0IGluIHRoZSBhcHAgY29uZmlnIGF0IGRlcGxveW1lbnQgdGltZS4g VGhvc2UgYXJlbid0IGZyaW5nZSBjYXNlcyBJIG9jY2FzaW9uYWxseSBlbmNvdW50ZXJlZDogdGhl IHJlc291cmNlIHBhcmFtZXRlciBpbiBBenVyZSBBRCB2MSBhbmQgQURGUyB3YXMgbWFuZGF0b3J5 LCBoZW5jZSBsaXRlcmFsbHkgZXZlcnkgc29sdXRpb24gaQ0KIHNhdyBvciB0b3VjaGVkIHVzZWQg aXQuIEFzIEJyaWFuIHN1Z2dlc3RlZCwgdGhpcyBpcyBhIHNjZW5hcmlvIHdoZXJlIHRoZSBzZWN1 cml0eSBhZHZhbnRhZ2VzIG9mIHRoZSBuZXR3b3JrIGFkZHJlc3NhYmxlIGNhc2UgYXJlbid0IGFz IHByb25vdW5jZWQgYXMgaW4gdGhlIGNhc2UgaW4gd2hpY2ggdGhlIGNsaWVudCBkaXNjb3ZlcnMg dGhlIHJlc291cmNlIGlkZW50aWZpZXIgYXQgcnVudGltZS4gVGhpcyBpc24ndCBqdXN0IGJlY2F1 c2UgdGhlcmUNCiBpcyBubyBzcGVjaWZpY2F0aW9uIHN1Z2dlc3RpbmcgbG9jYXRpb24gc2hvdWxk IGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLCBpdCdzIGJlY2F1c2UgdGhlcmUgYXJlIG1hbnkgcHJh Y3RpY2FsIGFkdmFudGFnZXMgYXQgZGV2ZWxvcG1lbnQgYW5kIGRlcGxveW1lbnQgdGltZSB0byBi ZSBhYmxlIHRvIHVzZSBsb2dpY2FsIGlkZW50aWZpZXJzLSBhbmQgaWYgdGhlDQo8aT5jb25jcmV0 ZSA8L2k+c2VjdXJpdHkgYWR2YW50YWdlcyBkb24ndCBhcHBseSB0byB0aGUgdGhlaXIgY2FzZSwg cGVvcGxlIHdpbGwgc2ltcGx5IG5vdCBjb21wbHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBzdW1tYXJ5OiBjcmVhdGlu ZyB0d28gZGlmZmVyZW50IHBhcmFtZXRlcnMgaW4gdHdvIGRpZmZlcmVudCBkb2N1bWVudHMgaXMg YmV0dGVyIHRoYW4gaWdub3JpbmcgaGUgbG9naWNhbCBpZGVudGlmaWVyIGNhc2UgYWx0b2dldGhl ciwgaG93ZXZlciBJIHRoaW5rIHRoYXQgbm90IGFja25vd2xlZGdpbmcgdGhlDQogbG9naWNhbCBp ZCBjYXNlIGluJm5ic3A7b2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBpcyBnb2luZyB0byBjcmVh dGUgY29uZnVzaW9uIGFuZCB1bHRpbWF0ZWx5IG5vdCBiZSBhcyB1c2VmdWwgdG8gdGhlIGRldmVs b3BlciBjb21tdW5pdHkgYXMgaXQgY291bGQgYmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gU2F0LCBKYW4gMTksIDIwMTkgYXQgMTI6MzggUGhpbCBIdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPiYjNDM7MSB0byBNaWtlIGFuZCBKb2hu4oCZcyBjb21tZW50cy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBoaWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24g SmFuIDE5LCAyMDE5LCBhdCAxMjozNCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWxzbyBhZ3JlZSB0 aGF0IOKAnHJlc291cmNl4oCdIHNob3VsZCBiZSBhIHNwZWNpZmljIG5ldHdvcmstYWRkcmVzc2Fi bGUgVVJMIHdoZXJlYXMgYSBzZXBhcmF0ZSBhdWRpZW5jZSBwYXJhbWV0ZXIgKGxpa2Ug4oCcYXVk 4oCdIGluIEpXVHMpIGNhbiByZWZlciB0byBvbmUNCiBvciBtb3JlIGxvZ2ljYWwgcmVzb3VyY2Vz LiZuYnNwOyBUaGV5IGFyZSBkaWZmZXJlbnQsIGlmIHJlbGF0ZWQsIHRoaW5ncy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Ob3RlIHRoYXQgdGhlIEFDRSBXRyBpcyBw cm9wb3NpbmcgdG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciDigJxyZXFf YXVk4oCdIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1hY2Utb2F1dGgtcGFyYW1zLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxPC9hPiAtIHBhcnRseSBi YXNlZCBvbiBmZWVkYmFjayBmcm9tIE9BdXRoIFdHIG1lbWJlcnMuJm5ic3A7IFRoaXMgaXMgYSBn ZW5lcmFsIE9BdXRoIHBhcmFtZXRlciwgd2hpY2ggYW55IE9BdXRoIGRlcGxveW1lbnQgd2lsbCBi ZSBhYmxlIHRvIHVzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J IHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hhbmdlcyBhcmUgbmVlZGVkIHRvIGRyYWZ0LWll dGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywgYXMgdGhlIGxvZ2ljYWwgYXVkaWVuY2Ugd29y ayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90aGVyDQogZHJhZnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5 IDE5LCAyMDE5IDk6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDs8YSBo cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5i Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBWaXR0b3Jp byBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0 Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V2UgbmVlZCB0byBkZWNpZGUgaWYgd2Ugd2FudCB0byBtYWtlIGEgY2hhbmdlLiZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkZvciBzZWN1cml0eSB3ZSBhcmUgbG9jYXRpb24gY2VudHJpYy4mbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg cHJlZmVyIHRvIGtlZXAgcmVzb3VyY2UgbG9jYXRpb24gc2VwYXJhdGUgZnJvbSBsb2dpY2FsIGF1 ZGllbmNlIHRoYXQgY2FuIGJlIGEgc2NvcGUgb3Igb3RoZXIgcGFyYW1ldGVyLiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SWYgYmVjb21lcyBoYXJkZXIgZm9yIHBlb3BsZSB0byB1c2UgdGhlIHBhcmFtZXRlciBjb3Jy ZWN0bHkgaWYgd2UgYXJlIHRvbyBmbGV4aWJsZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgcmF0aGVy IGhhdmUgYSBzZXBhcmF0ZSBsb2dpY2FsIGF1ZGllbmNlIHBhcmFtZXRlciBpZiB3ZSB0aGluayB3 ZSB3YW50IG9uZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFNhdCwgSmFuIDE5LCAy MDE5LCAxMTo0MSBBTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci10b3A6Y3VycmVudGNvbG9yO2Jv cmRlci1yaWdodDpjdXJyZW50Y29sb3I7Ym9yZGVyLWJvdHRvbTpjdXJyZW50Y29sb3IiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vIGFwb2xvZ3kgbmVlZGVkLCBSaWZh YXQuIEFuZCBJIGFwb2xvZ2l6ZSBpZiB3aGF0IEkgc2FpZCBjYW1lIG9mZiB0aGUgd3Jvbmcgd2F5 LiBJIHdhcyBqdXN0IHRyeWluZyB0byBtYWtlIGxpZ2h0IG9mIHRoZSBzaXR1YXRpb24uLiBBbmQg SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgYmUgaGFtc3RydW5nDQogYnkgdGhlIHByb2Nlc3Mg YW5kIHRoZXJlIGFyZSB0aW1lcyB3aGVuIGl0IG1ha2VzIHNlbnNlIHRvIGJlIGZsZXhpYmxlIHdp dGggdGhpbmdzLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBGcmksIEphbiAxOCwgMjAxOSBhdCA2OjIyIFBNIFJpZmFhdCBTaGVr aC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvcnJ5IEJyaWFu LCBJIHdhcyBub3QgY2xlYXIgd2l0aCBteSBzdGF0ZW1lbnQuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgbWVhbnQgdG8gc2F5IHRo YXQgd2Ugc2hvdWxkIG5vdCBhbGxvdyB0aGUgcHJvY2VzcyB0byBwcmV2ZW50IHRoZSBXRyBmcm9t IHByb2R1Y2luZyBhIHF1YWxpdHkgZG9jdW1lbnQgd2l0aG91dCBpc3N1ZXMsIGFzc3VtaW5nIHRo ZXJlIGlzIGFuIGlzc3VlIGluIHRoZSBmaXJzdCBwbGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWRlYWxseSB3ZSB3YW50IHRvIGdldCB0 aGVzZSBpZGVudGlmaWVkIGR1cmluZyB0aGUgV0dMQywgYnV0IHRoaW5ncyBoYXBwZW4gYW5kIHNv bWV0aW1lcyB0aGUgV0cgbWlzc2VzIHNvbWV0aGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGVhciB5b3UgYW5kIGFn cmVlIHRoYXQgdGhpcyBtYWtlIHRoaW5ncyBkaWZmaWN1bHQgZm9yIGF1dGhvcnMuIFdlIHdpbGwg bWFrZSBzdXJlIHRoYXQgdGhpcyBkb2VzIG5vdCBiZWNvbWUgdGhlIG5vcm0sIGFuZCB3ZSB3aWxs IHRyeSB0byBzdGljayB0byB0aGUgcHJvY2VzcyBhcyBtdWNoIGFzIHBvc3NpYmxlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0 IDU6MzUgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLXRvcDpjdXJyZW50Y29sb3I7Ym9y ZGVyLXJpZ2h0OmN1cnJlbnRjb2xvcjtib3JkZXItYm90dG9tOmN1cnJlbnRjb2xvciI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIFJpZmFhdC4gUHJvY2VzcyBp cyBhcyBwcm9jZXNzIGRvZXMsIHJpZ2h0PyBJIGRvIGtpbmRhIHdhbnQgdG8gZ3J1bWJsZSBhYm91 dCBXR0NMIGhhdmluZyBwYXNzZWQgYWxyZWFkeSBidXQgdGhhdCdzIG1vc3RseSBiZWNhdXNlIHJl cGx5aW5nIHRvIHRoZXNlIGtpbmRzIG9mIHRocmVhZHMgaXMgaGFyZA0KIGZvciBtZSBhbmQgSSds bCBqdXN0IGdldCBvdmVyIGl0Li4uIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGluZ3MsIHRo ZSBzZWN1cml0eSBjb25jZXJucyBjb21lIGludG8gcGxheSB3aGVuIHRoZSBjbGllbnQgaXMgYmVp bmcgdG9sZCB0aGUgYnkgdGhlIHJlc291cmNlIGhvdyB0byBpZGVudGl0eSB0aGUgcmVzb3VyY2Ug bGlrZSBpcyBkZXNjcmliZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVkLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXN0cmlidXRlZC0wMTwv YT4gYW5kIHVzaW5nIHRoZSBhY3R1YWwgbG9jYXRpb24gaW4gdGhhdCBjb250ZXh0ICxhbG9uZyB3 aXRoIHNvbWUgb3RoZXIgY2hlY2tzIHByZXNjcmliZWQgaW4gdGhhdCBkcmFmdCwgcHJldmVudHMg dGhlIGtpbmQgb2YgaXNzdWVzIEpvaG4gZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhlIHRocmVhZC4N Cjxicj4NCjxicj4NCkluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQga25vd3MgdGhlIHJlc291cmNl IGEgcHJpb3JpIG9yIG91dC1vZi1iYW5kIG9yIGNvbmZpZ3VyZWQgb3Igd2hhdGV2ZXIsIEkgZG9u J3QgdGhpbmsgdGhlIHNhbWUgc2VjdXJpdHkgY29uY2VybnMgYXJpc2UuIEFuZCB1c2luZyBzdWNo IGEga25vd24gdmFsdWUsIGJlIGl0IGFuIGFjdHVhbCBsb2NhdGlvbiBvciBsb2dpY2FsIHJlcHJl c2VudGF0aW9uLCB3b3VsZCBiZSBva2F5Ljxicj4NCjxicj4NClRoZSByZXNvdXJjZS1pbmRpY2F0 b3JzIGRyYWZ0IGlzIGFkbWl0dGVkbHkgc29tZXdoYXQgbG9jYXRpb24tY2VudHJpYyBpbiBob3cg aXQgdGFsa3MgYWJvdXQgdGhlIHZhbHVlIG9mIHRoZSAncmVzb3VyY2UnIHBhcmFtZXRlci4gQnV0 IHVsdGltYXRlbHkgaXQgZGVmaW5lcyBpdCBhcyBhbiBhYnNvbHV0ZSBVUkkgdGhhdCBpbmRpY2F0 ZXMgdGhlIGxvY2F0aW9uIG9mIHRoZSB0YXJnZXQgc2VydmljZSBvciByZXNvdXJjZSB3aGVyZSBh Y2Nlc3MgaXMNCiBiZWluZyByZXF1ZXN0ZWQuIEEgbG9jYXRpb24gY2FuIGJlIHZhcnlpbmcgc2hh ZGVzIG9mIGFic3RyYWN0IGFuZCBJJ2Qgc2F5IHRoYXQgdXNpbmcgYSBVUkkgYXMgJ3Jlc291cmNl JyBwYXJhbWV0ZXIgdmFsdWUgdGhhdCdzIGEgbG9naWNhbCBpZGVudGlmaWVyIHRoYXQgcG9pbnRz IHRvIHNvbWUgcmVzb3VyY2UgaXMgd2VsbCB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgZHJhZnQu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlNvIG1heWJlIHRoZSBkcmFmdCBpcyBva2F5IGFzIGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3IgcGVyaGFwcyB0aGF0J3Mg dG9vIG11Y2ggdG8gYmUgbGVmdCBhcyBhbiBleGVyY2lzZXIgdG8gdGhlIHJlYWRlcj8mbmJzcDsg QW5kIHNvbWUgdGV4dCBzaG91bGQgYmUgYWRkZWQgYW5kL29yIGFkanVzdGVkIHNvIHRoZSByZXNv dXJjZS1pbmRpY2F0b3JzIGRyYWZ0IHdvdWxkIGJlIGEgbGl0dGxlIG1vcmUgb3Blbi9jbGVhcg0K IGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFsdWUgcG90ZW50aWFsbHkgYmVpbmcgbW9yZSBvZiBhIGxv Z2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRpZmllciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0d29y ayBhZGRyZXNzYWJsZSBVUkw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDE6MTgg UE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLXRvcDpjdXJyZW50Y29sb3I7Ym9yZGVyLXJpZ2h0OmN1 cnJlbnRjb2xvcjtib3JkZXItYm90dG9tOmN1cnJlbnRjb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIHdvdWxkbid0IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHRoZSBwcm9jZXNz LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgaXQgbWFr ZXMgc2Vuc2UgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCwgdGhlbiBmZWVsIGZyZWUgdG8gZG8gdGhh dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDM6MDgg UE0gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRh cmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0O2JvcmRlci10b3A6Y3VycmVudGNvbG9yO2JvcmRlci1yaWdodDpjdXJyZW50Y29sb3I7Ym9y ZGVyLWJvdHRvbTpjdXJyZW50Y29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlllcyB0aGUmbmJzcDtsb2dpY2FsIHJlc291cmNlIGNhbiBiZSBwcm92aWRlZCBieSAm cXVvdDtzY29wZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U29tZSBpbXBsZW1lbnRhdGlvbnMgbGlrZSBQaW5nIGFuZCBBdXRo MCBoYXZlIGJlZW4gYWRkaW5nIGFub3RoZXIgcGFyYW1ldGVyICZxdW90O2F1ZCZxdW90OyB0byBp ZGVudGlmeSB0aGUgbG9naWNhbCByZXNvdXJjZSBhbmQgdGhlbiB1c2luZyBzY29wZXMgdG8gZGVm aW5lIHBlcm1pc3Npb25zIHRvIHRoZSByZXNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvcnR1bmF0ZWx5LCB3ZSBhcmUgdXNp bmcgYSBkaWZmZXJlbnQmbmJzcDtwYXJhbWV0ZXIgbmFtZSBzbyBub3Qgc3RlcHBpbmcgb24gdGhh dC4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5XZSBjb3VsZCBnbyBiYWNrIGFuZCB0cnkgdG8gYWRkIHRleHQgZXhwbGFpbmluZyB0aGUg ZGlmZmVyZW5jZSwgYnV0IHdlIGFyZSBxdWl0ZSBsYXRlIGluIHRoZSBwcm9jZXNzLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBhZ3JlZSB0aGF0IGEgbG9naWNhbCByZXNvdXJjZSBwYXJhbWV0ZXImbmJzcDttYXkgYmUgaGVs cGZ1bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZHJhZnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb2huIEIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJp LCBKYW4gMTgsIDIwMTkgYXQgNDozOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNo YW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLXRvcDpj dXJyZW50Y29sb3I7Ym9yZGVyLXJpZ2h0OmN1cnJlbnRjb2xvcjtib3JkZXItYm90dG9tOmN1cnJl bnRjb2xvciI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9lc27igJl0 IHRoZSDigJxzY29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRlIGEgbWVhbnMgb2Ygc3Bl Y2lmeWluZyBhIGxvZ2ljYWwgaWRlbnRpZmllcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQw YXV0aDAuLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBKYW51YXJ5IDE4 LCAyMDE5IGF0IDU6NDcgQU08YnI+DQo8Yj5UbzogPC9iPkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0 Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SUVURiBvYXV0aCBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11 cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh bmtzIEpvaG4gZm9yIHRoZSBiYWNrZ3JvdW5kLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVlIHRoYXQgZnJvbSB0aGUgY2xpZW50IHZhbGlkYXRp b24gUG9WLCBoYXZpbmcgYW4gaWRlbnRpZmllciBjb3JyZXNwb25kaW5nIHRvIGEgbG9jYXRpb24g bWFrZXMgdGhpbmdzIG1vcmUgc29saWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgc2FpZDogdGhlIHVzZSBvZiBsb2dpY2FsIGlkZW50 aWZpZXJzIGlzIHdpZGVzcHJlYWQsIGFzIGl0IGhhcyBzaWduaWZpY2FudCBwcmFjdGljYWwgYWR2 YW50YWdlcyAodGhpbmsgb2Ygc2VydmljZXMgdGhhdCBhc3NpZ24gZ2VuZXJhdGVkIGhvc3Rpbmcg VVJMcyBvbmx5IGF0IGRlcGxveW1lbnQgdGltZSwNCiBvciBzZXJ2aWNlcyB0aGF0IGFyZSBzb21l aG93IGdyb3VwZWQgdW5kZXIgdGhlIHNhbWUgbG9naWNhbCBhdWRpZW5jZSBhY3Jvc3MgcmVnaW9u cy9lbnZpcm9ubWVudC9kZXBsb3ltZW50cykuIFBlb3BsZSB3b24ndCBzdG9wIHVzaW5nIGxvZ2lj YWwgaWRlbnRpZmllcnMsIGJlY2F1c2UgdGhleSBvZnRlbiBoYXZlIG5vIGFsdGVybmF0aXZlIChn ZW5lcmF0aW5nIG5ldyBhdWRpZW5jZXMgb24gdGhlIGZseSBhdCB0aGUgQVMgZXZlcnkgdGltZSB5 b3UNCiBkbyBhIGRlcGxveW1lbnQgYW5kIGdldCBhc3NpZ25lZCBhIG5ldyBVUkwgY2FuIGJlIHVu ZmVhc2libGUpLiBMZWF2aW5nIGEgd2lkZWx5IHVzZWQgYXBwcm9hY2ggYXMgZXhlcmNpc2UgdG8g dGhlIHJlYWRlciBzZWVtcyBhIGRpc3NlcnZpY2UgdG8gdGhlIGNvbW11bml0eSwgZ2l2ZW4gdGhh dCB0aGlzIG1pZ2h0IGxlYWQgdG8gdmVuZG9ycyAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IGFuZCBB dXRoMCkga2VlcGluZyB0aGVpciBvd24gcHJvcHJpZXRhcnkNCiBwYXJhbWV0ZXJzLCBvciBkZXZl bG9wZXJzIG1pc3VzaW5nIHRoZSBvbmVzIGluIHBsYWNlOyB3b3VsZCBtYWtlIGl0IGhhcmQgZm9y IFNESyBkZXZlbG9wZXJzIHRvIHByb3ZpZGUgbGlicmFyaWVzIHRoYXQgd29yayBvdXQgb2YgdGhl IGJveCB3aXRoIGRpZmZlcmVudCBBU2VzOyBhbmQgc28gb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvdWxkIGl0IGJlIGZlYXNpYmxlIHRv IGFkZCBzdWNoIHBhcmFtZXRlciBkaXJlY3RseSBpbiB0aGlzIHNwZWM/IFRoYXQgd291bGQgZWxp bWluYXRlIHRoZSBpbnRlcm9wIGlzc3VlcywgYW5kIGFsc28gZ2l2ZXMgdXMgYSBjaGFuY2UgdG8g ZnVsbHkgd2FybiBwZW9wbGUgYWJvdXQgdGhlIHNlY3VyaXR5IHNob3J0Y29taW5ncw0KIG9mIGNo b29zaW5nIHRoYXQgYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDQ6 MzIgUE0gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20i IHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD5XZSBoYXZlIGRpc2N1c3NlZCB0aGlzLjxvOnA+ PC9vOnA+PC9wPg0KPHA+QXVkaWVuY2VzIGNhbiBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVudGlm aWVycy4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cD5UaGlzIGhvd2V2ZXIgaXMgYSBt b3JlIHNwZWNpZmljIGxvY2F0aW9uLiZuYnNwOyBUaGUgQVMgaXMgZnJlZSB0byBtYXAgdGhlIGxv Y2F0aW9uIGludG8gc29tZSBhYnN0cmFjdCBhdWRpZW5jZSBpbiB0aGUgQVQuPG86cD48L286cD48 L3A+DQo8cD5Gcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyBvbmNlIHRoZSBjbGllbnQgc3Rh cnRzIGFza2luZyBmb3IgbG9naWNhbCByZXNvdXJjZXMgaXQgY2FuIGJlIHRyaWNrZWQgaW50byBh c2tpbmcgZm9yIHRoZSB3cm9uZyBvbmUgYXMgYSBiYWQgcmVzb3VyY2UgY2FuIGFsd2F5cyBsaWUg YWJvdXQgd2hhdCBsb2dpY2FsIHJlc291cmNlIGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYg d2Ugd2VyZSB0byBjaGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3b3VsZCB2YWxpZGF0ZSBpdCBiZWNv bWVzIGNoYWxsZW5naW5nIHRvIGltcG9zc2libGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBB UyBpcyBmcmVlIHRvIGRvIHdoYXRldmVyIG1hcHBpbmcgb2YgbG9jYXRpb25zIHRvIGlkZW50aWZp ZXJzIGl0IG5lZWRzIGZvciBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPHA+U29tZSBp bXBsZW1lbnRhdGlvbnMgbWF5IHdhbnQgdG8ga2VlcCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbGlr ZSBsb2dpY2FsIGF1ZGllbmNlLCBidXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgZnJvbSByZXNv dXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTcvMjAxOSA5OjU2IEFNLCBSaWZhYXQgU2hla2gt WXVzZWYgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGkgVml0dG9yaW8sDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGUgdGV4dCB5b3UgcXVvdGVkIGlzIGNvcGllZCBmb3JtIHRo ZSBhYnN0cmFjdCBvZiB0aGUgZHJhZnQgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkF1dGhvcnMsPC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2hv dWxkIHRoZSBkcmFmdCBiZSB1cGRhdGVkIHRvIGNvdmVyIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIg Y2FzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDg6 MTkgQU0gVml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpWaXR0b3Jpb0BhdXRo MC5jb20iIHRhcmdldD0iX2JsYW5rIj5WaXR0b3Jpb0BhdXRoMC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSBSaWZhYXQsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pm9uZSBkZXRhaWwuIFRoZSB0ZWNoIHN1bW1hcnkgc2F5czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+ QW4gZXh0ZW5zaW9uIHRvIHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsgZGVm aW5pbmcgcmVxdWVzdCA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPnBhcmFtZXRlcnMgdGhhdCBlbmFibGUgYSBjbGllbnQgdG8gZXhwbGljaXRseSBz aWduYWwgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5hYm91dCB0aGUgPGI+bG9jYXRpb248L2I+IG9m IHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UocykgdG8gd2hpY2ggaXQgaXMgcmVxdWVzdGluZyA8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPmFjY2Vzcy48 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5CdXQgYXQgbGVhc3QgaW4gdGhlIE1pY3Jvc29mdCBpbXBsZW1lbnRhdGlv biwgdGhlIHJlc291cmNlIGlkZW50aWZpZXIgZG9lc24ndA0KPGk+aGF2ZTwvaT4gdG8gYmUgYSBu ZXR3b3JrIGFkZHJlc3NhYmxlIFVSTCAoYW5kIGlmIGl0IGlzLCBpdCBkb2Vzbid0IHN0cmljdGx5 IG5lZWQgdG8gbWF0Y2ggdGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbikuIEl0IGNhbiBiZSBh IGxvZ2ljYWwgaWRlbnRpZmllciwgdGhvIHVzaW5nIHRoZSBhY3R1YWwgcmVzb3VyY2UgbG9jYXRp b24gdGhlcmUgaGFzIGJlbmVmaXRzIChkb21haW4gb3duZXJzaGlwIGNoZWNrLCBwcmV2ZW50aW9u IG9mIHRva2VuDQogZm9yd2FyZGluZyBldGMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TYW1lIGZvciBBdXRoMCwgdGhlIGF1ZGllbmNlIHBh cmFtZXRlciBpcyBhIGxvZ2ljYWwgaWRlbnRpZmllciByYXRoZXIgdGhhbiBhIGxvY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBXZWQsIEphbiAxNiwgMjAxOSBhdCA2OjMyIFBNIFJpZmFhdCBTaGVraC1ZdXNl ZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxs LA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IGZvbGxvd2luZyBpcyB0aGUgZmlyc3Qgc2hlcGhlcmQgd3JpdGUtdXAgZm9yIHRoZSZuYnNwO2Ry YWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMSBkb2N1bWVudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzL3NoZXBoZXJkd3JpdGV1cC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMv c2hlcGhlcmR3cml0ZXVwLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCZuYnNwO21l IGtub3cgaWYgSSBtaXNzZWQgYW55dGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9B dXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4NCiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJp YWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uDQogaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxicj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMNCiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL0PR00MB02920F6A16D28D1652F21B2DF59A0BL0PR00MB0292namp_-- From nobody Thu Jan 24 16:13:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36F130F40 for ; Thu, 24 Jan 2019 16:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 xCJXuBscK3k4 for ; Thu, 24 Jan 2019 16:13:13 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E76130EC8 for ; Thu, 24 Jan 2019 16:13:13 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id f4so6355649ion.2 for ; Thu, 24 Jan 2019 16:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8zMEadcbRkqJf2TwXmyNnRG4/IvJiYe+Vw4f0mNp7Wo=; b=ZWiwWLjmvErvzVEMBwOVKZHa15351W+oGD88li/2tgzen9dC4EROlEPssjsyGPUSn+ 2P5rzND6As/dhr++Zs8aWKOZ/40ZeuVuZ3L2XKx/P3f74yFW5IxxpNYg5juwkfYoyCLf xWcoAXvAJUJV7e1f7pl0/vICDHA+46l5w9PDCzF88ZVbvpjnFl4W7/NxSpAENmjDJR4l PFJybe68glYqqQGa7NAsYRyOKYtfudTEtgiKJEiYZuqIGTvwcTslGuhytDkvg3EfOJql dSYtf4wid2C9FXFuGlh+zEwdeLgNjfjSdln4zXIfST4XaJhiWIETz67/zq8amgTVHXlL AVxw== 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=8zMEadcbRkqJf2TwXmyNnRG4/IvJiYe+Vw4f0mNp7Wo=; b=YshYoKA18XCbi/XAKC4NbwRXlFeey+n/F5CV5GOIInrUWjIYgJ4s3+y79yj6dVHGej ow4QADVmgrAZHHI2XmRjOP/65N41/xp2CR1WCEnJWtYimbbmqHb2NBzVkmo/jrrxEAta NUkf4+DyWBpaopB8uQGQsNLmQT5RC5TBdXvqtztzTTy1UtXgWYkd3oKht8sRCt/Y2OQ1 okxd9vQZMvU/l5Wv+7f9bg1sbn4eyw94EGZhnQd8YHerX3uk/ODOyomTghx0OPSl8F3o /MPAYMcoEiao+5wH5LXsZ2GhNLqsBMc75QarX78vdExDPE3Gj9o+4SBXcV8uZBbvN38w C+wA== X-Gm-Message-State: AHQUAuZ8BgkcxAgXI8jVRFAG1rWvsBh1UKzKEPOk7+UxxeXkKgGpKnCA p/fmLGSn3wF4Q4gOZytmDXNazkbRTgoeZUi/hIM= X-Google-Smtp-Source: ALg8bN6ABFAT4CuC7hiSDOXdAtlZIqpa7AWaPOAEUzkDUQWypZSZ7ALZuZs1wtdR+zDsoNpK+RD5et774rN5Z6TU8U4= X-Received: by 2002:a5d:9913:: with SMTP id x19mr4494146iol.99.1548375192666; Thu, 24 Jan 2019 16:13:12 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Thu, 24 Jan 2019 19:13:00 -0500 Message-ID: To: Mike Jones Cc: George Fletcher , Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000056879805803d3155" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 00:13:18 -0000 --00000000000056879805803d3155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hannes sent an update to this meeting here: https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU Regards, Rifaat On Thu, Jan 24, 2019 at 6:20 PM Mike Jones wrote: > The virtual office hours in my calendar start 1/2 hour before that. If > the time has changed, can you have the meeting organizer update the > calendar entry? > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > *Cc:* Vittorio Bertocci ; Mike Jones < > Michael.Jones@microsoft.com>; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > All, > > > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled > OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic to try to get to a > conclusion on this. > > > > Regards, > > Rifaat > > > > > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > +1 > > Also, I don't really like the parameter name 'req_aud' :) I'm not 100% > convinced that 'audience' and 'logical resource' are completely overlappi= ng > concepts. We can potentially make them completely overlapping but we need > text to that effect. > > I also believe that we don't have a complete solution for all deployments > using exact locations (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be separated- but I also agree > with George on the need to be clear an easy to reference for developers. > > Just adding a reference to req_aud would just raise the cyclomatic > complexity of the specs, which is already unusably high for mere mortals = in > the OAuth2/OIDC family of specs. > > > > One additional complication is that this specification is reusing a > parameter that is already used in a *very* large number of production > systems (small example here > ), > and whose concrete semantic happens to be prevalently logic identifier. I= f > the parameter you are defining here has a different semantic, at the very > least it would seem good hygiene to rename it to avoid collision and > confusion. > > > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > I agree with John=E2=80=99s logic. The physical resource and logical res= ource > should use different identifiers. Fortunately, we already have =E2=80=9C= resource=E2=80=9D > and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > I don't think they are necessarily mutually exclusive, that is why I thin= k > there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client interacting > with RS https://fire.hhs.com as the resource wants a OAuth token with an > audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for tokens > with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is the URI > of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the URI t= o > figure out which one it is. I think that is harder for implementations a= nd > more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself iterated on modifying the text > to cover the logical identifier use case, highlighting the security > implications of going that route. You can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-ind= icators.xml, > see the commits in the history from January 21 for the specific changes. > > Note: I also had a chat with John offline, and he expressed the desire to > split the resource parameter in two distinct parameters to better signal > the intended usage. I am sure he can elaborate. I have nothing against it > in principle, as long as we leave nothing as exercise to the reader and w= e > are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a > chance to speak w Brian about it. If the discussion stretches further, I > would suggest we pause it and let him enjoy his time off for the rest of > the week. > > > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci wrote= : > > Hi Rifaat, > > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before w= e > come back to the list with something. > > Cheers, > > V. > > > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> > wrote: > > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > > [sent to John only by mistake, resending to the ML] > > > > In Azure AD v1 & ADFS, that's resource.. It could be used for both > network and logical ids, with the concrete usage in the wild I described > earlier. > > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > > This is 9 months old info hence > > > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressab= le > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovere= d > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw = or > touched used it. As Brian suggested, this is a scenario where the securit= y > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. Th= is > isn't just because there is no specification suggesting location should b= e > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- an= d > if the *concrete *security advantages don't apply to the their case, > people will simply not comply. > > > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and ultimately > not be as useful to the developer community as it could be. > > > > > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > > +1 to Mike and John=E2=80=99s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network= -addressable URL > whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs= ) can refer to one > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience paramete= r > =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-o= auth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > *Cc:* Vittorio Bertocci ; IETF oau= th > WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that ca= n > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > > > I would rather have a separate logical audience parameter if we think we > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > that.. > > > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000056879805803d3155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hannes sent an update to this meeting her= e:

Regards,
=C2=A0Rifaat


= On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@microsoft.com> wr= ote:

The virtual offic= e hours in my calendar start 1/2 hour before that.=C2=A0 If the time has ch= anged, can you have the meeting organizer update the calendar entry?=

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

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

=C2=A0<= /u>

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org=
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

All,

=C2=A0

This co= ming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Vi= rtual Office meeting.

Feel fr= ee to attend the meeting to discuss this topic to try to get to a conclusio= n on this.

=C2=A0

Regards= ,

=C2=A0R= ifaat

=C2=A0

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <= gffletch=3D40= aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'= ;m not 100% convinced that 'audience' and 'logical resource'= ; are completely overlapping concepts. We can potentially make them complet= ely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deploymen= ts using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:<= u>

As mentioned below, I agree the two can be separated= - but I also agree with George on the need to be clear an easy to reference= for developers.

Just adding a reference to req_aud would just raise = the cyclomatic complexity of the specs, which is already unusably high for = mere mortals in the OAuth2/OIDC family of specs.

=C2=A0

One additional complication is that this specificati= on is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic iden= tifier. If the parameter you are defining here has a different semantic, at= the very least it would seem good hygiene to rename it to avoid collision = and confusion.

=C2=A0

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John= =E2=80=99s logic.=C2=A0 The physical resource and logical resource should u= se different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresou= rce=E2=80=9D and =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I believe we=E2=80= =99re good to go, as-is.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I= think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting= with RS https://fire.hhs.com= as the resource wants a OAuth token with an audience of HHS and a scope of= read.

Without proof of possession we need to keep bad RS from asking for token= s with scopes and audiences of other RS that can be replayed.=

I really like keeping the resource simple and unspoofable, it is the URI= of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span m= ore than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI = to figure out which one it is.=C2=A0 I think that is harder for implementat= ions and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated o= n modifying the text to cover the logical identifier use case, highlighting= the security implications of going that route. You can find the revised text in=C2=A0= https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indic= ators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he ex= pressed the desire to split the resource parameter in two distinct paramete= rs to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we le= ave nothing as exercise to the reader and we are very clear on usage (e.g. = mutual exclusivity, etc) but didn't have a chance to speak w Brian abou= t it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of= the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:=

Hi Rifaat,

absolutely. Brian and myself already started working= on some language, however this week he is in vacation hence it might take = few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys sugges= t some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within = the bounds of the draft's definition of 'resource' as a URI. An= d that perhaps all that's needed is some minor adjustment and/or augmen= tation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

[sent to John only by mistake, resending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that's=C2=A0resourc= e.. I= t could be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.

In Azure AD v2, = the resource as explicit parameter (network, logic or otherwise) is gone an= d is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it s= till end up in the resulting=C2=A0aud=C2=A0of the issued token.

This is 9 months= old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com>= wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the= established process. In my former position I wasn't monitoring those d= iscussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and= given that I worked with actual deployments and developers using a similar= parameter for a long time, I thought prudent to bring this up. I really ap= preciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidanc= e on how to work with the concept of logical resource in a standard complia= nt way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-ind= icators or elsewhere.

That said. Reading through the draft, it would appea= r that most of the reasons for which the spec was created apply to both the= network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to = the intended audience, avoiding overloading scopes with resource indicating= parts... those all apply to network addressable and logic identifiers alik= e. And both parameters are expected to result in audience restricted tokens. It seems the only difference come= s at token usage time, with the network addressable case giving more guaran= tees that the token will go to its intended recipient, but the request and = audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I en= countered in the wild in the last 5 years of using the resource parameter i= n the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in t= he app config at deployment time. Those aren't fringe cases I occasiona= lly encountered: the resource parameter in Azure AD v1 and ADFS was mandato= ry, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the s= ecurity advantages of the network addressable case aren't as pronounced= as in the case in which the client discovers the resource identifier at ru= ntime. This isn't just because there is no specification suggesting location should be explicitly indicated, it= 's because there are many practical advantages at development and deplo= yment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, peop= le will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two= different documents is better than ignoring he logical identifier case alt= ogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confu= sion and ultimately not be as useful to the developer community as it could= be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2= =80=99s comments.=C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40mic= rosoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly bas= ed on feedback from OAuth WG members.=C2=A0 This is a general OAuth paramet= er, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with= things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

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

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract = identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>=
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defining request=
 
parameters that enable a client to explicitly signal to an authorizati=
on server 
about the location of the protected resource(s) to which it is =
requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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


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


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, 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 me= ssage and any file attachments from your computer. Thank you.

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


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution 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 messa= ge and any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

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

--00000000000056879805803d3155-- From nobody Thu Jan 24 16:53:40 2019 Return-Path: <4all7the5time@gmail.com> X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887E013123E for ; Thu, 24 Jan 2019 16:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yXv694ecRncz for ; Thu, 24 Jan 2019 16:53:33 -0800 (PST) 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 2FEE1128D09 for ; Thu, 24 Jan 2019 16:53:32 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id c16so5721943lfj.8 for ; Thu, 24 Jan 2019 16:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bskSlo8oNIhes0oSPTtiOuHvr7sJSgOOUqrVyZ85SQU=; b=ctm99XWF+8Sw40318l0e7OHV5AsLL+RV1xffntfzjSUMAm8k6T+enm90BGXXxXsidM KfMZnT4jt0mVflz5hPdbA1P4rrZdYBeIPnx+bQ9Z4tgmP5tFKDS4+OU9Huz2+YuEoI4p 3+GCMSzOpddJUy7JCUwt77lGE1u/wIsY93OFpqaLFS640IWOhuU0vYAjO6FTKf7H2d78 jYHmZKkZn4OKRQtZ9Lqx05Bb8rCX09TxBd7PffyaHF89dL+LAWegsvEezEVBpYDzNdkI UYtZhgJwxMaRTSdbeNx2QXCc9sWTV2aCsoxhksigMjn6Z3tuwgxbPANzQpA+BRBWaEKm M7ng== 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=bskSlo8oNIhes0oSPTtiOuHvr7sJSgOOUqrVyZ85SQU=; b=cAqjmJDvNd3nGB2J3pMY1krVE32m+AurHFAPPH1QmHg5wYbUTcKN2BbgJ4piOPuGtA oQ3ODk0t/ADTpbjfYt3IXUPSyQFJpudmoIChCS86OpfdGrRs/gB3CkEX4Ngk0CpasCIW jsRvEQEA7TwpEqvYQbpLt9J7IqMleaz9U07+LkeCAobzrKjDYasea5LkiwyPgVI8Rcwa CWF4L2ajFUe0qqJVufUcIW4XdC3JA4w/39VQTRomRQEn8bKzGpKAvBBNbhX3c9aM0DQK uWImZ+hPDdawPs1oWFM8c9puWLM5LxmmAxlQCGwgMssf6y2bS9af/jwfw3D6iqK1DEGc P2RQ== X-Gm-Message-State: AJcUukcNxZGcpE5AZwkwK6JGEJLJ75cARrOgCLaiiEdTuxObd3o+euF/ wY1baCWCyyncejJLiUi9g2AxU3a0aZq6htJ5YjCv4Q== X-Google-Smtp-Source: ALg8bN5ROf0LS84Feb20VP4Rk9zFjx9RHg/WAwT+FV+yLMrxg99zR90/VvZB06k6/LyiBLygHI8aJgSC/aQFaRWz6MY= X-Received: by 2002:a19:3b45:: with SMTP id i66mr7240196lfa.28.1548377609682; Thu, 24 Jan 2019 16:53:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lao Vang <4all7the5time@gmail.com> Date: Thu, 24 Jan 2019 16:51:11 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000067442505803dc1eb" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 45 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 00:53:39 -0000 --00000000000067442505803dc1eb Content-Type: text/plain; charset="UTF-8" Reply all On Wed, Jan 23, 2019, 8:45 AM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 (Vittorio Bertocci) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Jan 2019 08:44:43 -0800 > From: Vittorio Bertocci > To: Rifaat Shekh-Yusef > Cc: Brian Campbell , > IETF oauth WG > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > Message-ID: > < > CAO_FVe6+2eexcqkreKnV43stoAsA8-+RMRZEK7_EhJk+OA7X_A@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > thanks for you patience. Brian and myself iterated on modifying the text to > cover the logical identifier use case, highlighting the security > implications of going that route. You can find the revised text in > > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml > , > see the commits in the history from January 21 for the specific changes. > Note: I also had a chat with John offline, and he expressed the desire to > split the resource parameter in two distinct parameters to better signal > the intended usage. I am sure he can elaborate. I have nothing against it > in principle, as long as we leave nothing as exercise to the reader and we > are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a > chance to speak w Brian about it. If the discussion stretches further, I > would suggest we pause it and let him enjoy his time off for the rest of > the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > wrote: > > > Thank you guys! > > > > > > On Monday, January 21, 2019, Vittorio Bertocci > wrote: > > > >> Hi Rifaat, > >> absolutely. Brian and myself already started working on some language, > >> however this week he is in vacation hence it might take few days before > we > >> come back to the list with something. > >> Cheers, > >> V. > >> > >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > >> wrote: > >> > >>> Brian, Vittorio, > >>> > >>> To move this discussion forward, can you guys suggest some text to make > >>> the logical identifier usage clearer? > >>> > >>> Regards, > >>> Rifaat > >>> > >>> > >>> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: > >>> > >>>> As I suggested before, I do think that's within the bounds of the > >>>> draft's definition of 'resource' as a URI. And that perhaps all that's > >>>> needed is some minor adjustment and/or augmentation of some text to > make it > >>>> more clear. > >>>> > >>>> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > > >>>> wrote: > >>>> > >>>>> [sent to John only by mistake, resending to the ML] > >>>>> > >>>>> In Azure AD v1 & ADFS, that's resource. It could be used for both > >>>>> network and logical ids, with the concrete usage in the wild I > described > >>>>> earlier. > >>>>> In Azure AD v2, the resource as explicit parameter (network, logic or > >>>>> otherwise) is gone and is expressed as part of the scope string of > all the > >>>>> scopes requested for a given resource- but it still exist in > practice tho > >>>>> as it still end up in the resulting aud of the issued token. > >>>>> This is 9 months old info hence > >>>>> > >>>>> On Sun, Jan 20, 2019 at 17:58 John Bradley > wrote: > >>>>> > >>>>>> What is the parameter that Microsoft is using? > >>>>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > >>>>>> > >>>>>> First of all, it wasn't my intent to disrupt the established > process. > >>>>>> In my former position I wasn't monitoring those discussions hence I > didn't > >>>>>> have a chance to offer feedback. When I saw something that gave me > the > >>>>>> impression might lead to issues, and given that I worked with actual > >>>>>> deployments and developers using a similar parameter for a long > time, I > >>>>>> thought prudent to bring this up. I really appreciate Rifaat's > stance on > >>>>>> this. End of preamble. > >>>>>> > >>>>>> Ultimately my goal is for developers to have guidance on how to work > >>>>>> with the concept of logical resource in a standard compliant way, > hence it > >>>>>> doesn't strictly matter whether the definition of the corresponding > >>>>>> parameter lives in oauth-resource-indicators or elsewhere. > >>>>>> That said. Reading through the draft, it would appear that most of > >>>>>> the reasons for which the spec was created apply to both the network > >>>>>> addressable and the logical resource types: knowing what keys to > use to > >>>>>> encrypt the token, constrain access tokens to the intended audience, > >>>>>> avoiding overloading scopes with resource indicating parts... those > all > >>>>>> apply to network addressable and logic identifiers alike. And both > >>>>>> parameters are expected to result in audience restricted tokens. It > seems > >>>>>> the only difference comes at token usage time, with the network > addressable > >>>>>> case giving more guarantees that the token will go to its intended > >>>>>> recipient, but the request and audience restriction syntax seems to > be > >>>>>> exactly the same. > >>>>>> On top of this: in the 99.999% of the scenarios I encountered in the > >>>>>> wild in the last 5 years of using the resource parameter in the MS > >>>>>> ecosystem, the resource identifier was known at design time: the > developer > >>>>>> discovered it out of band and placed it in the app config at > deployment > >>>>>> time. Those aren't fringe cases I occasionally encountered: the > resource > >>>>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally > every > >>>>>> solution i saw or touched used it. As Brian suggested, this is a > scenario > >>>>>> where the security advantages of the network addressable case > aren't as > >>>>>> pronounced as in the case in which the client discovers the resource > >>>>>> identifier at runtime. This isn't just because there is no > specification > >>>>>> suggesting location should be explicitly indicated, it's because > there are > >>>>>> many practical advantages at development and deployment time to be > able to > >>>>>> use logical identifiers- and if the *concrete *security advantages > >>>>>> don't apply to the their case, people will simply not comply. > >>>>>> > >>>>>> In summary: creating two different parameters in two different > >>>>>> documents is better than ignoring he logical identifier case > altogether, > >>>>>> however I think that not acknowledging the logical id case > >>>>>> in oauth-resource-indicators is going to create confusion and > ultimately > >>>>>> not be as useful to the developer community as it could be. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt > wrote: > >>>>>> > >>>>>>> +1 to Mike and John?s comments. > >>>>>>> > >>>>>>> Phil > >>>>>>> > >>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < > >>>>>>> Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote: > >>>>>>> > >>>>>>> I also agree that ?resource? should be a specific > >>>>>>> network-addressable URL whereas a separate audience parameter > (like ?aud? > >>>>>>> in JWTs) can refer to one or more logical resources. They are > different, > >>>>>>> if related, things. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Note that the ACE WG is proposing to register a logical audience > >>>>>>> parameter ?req_aud? in > >>>>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - > partly > >>>>>>> based on feedback from OAuth WG members. This is a general OAuth > >>>>>>> parameter, which any OAuth deployment will be able to use. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I therefore believe that no changes are needed to > >>>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work > is > >>>>>>> already happening in another draft. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- Mike > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *From:* OAuth *On Behalf Of * John > Bradley > >>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM > >>>>>>> *To:* Brian Campbell > >>>>>>> *Cc:* Vittorio Bertocci ; > IETF > >>>>>>> oauth WG > >>>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for > >>>>>>> draft-ietf-oauth-resource-indicators-01 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> We need to decide if we want to make a change. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> For security we are location centric. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I prefer to keep resource location separate from logical audience > >>>>>>> that can be a scope or other parameter. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> If becomes harder for people to use the parameter correctly if we > >>>>>>> are too flexible. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I would rather have a separate logical audience parameter if we > >>>>>>> think we want one. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> John B. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < > >>>>>>> bcampbell@pingidentity.com wrote: > >>>>>>> > >>>>>>> No apology needed, Rifaat. And I apologize if what I said came off > >>>>>>> the wrong way. I was just trying to make light of the situation.. > And I > >>>>>>> agree that we should not be hamstrung by the process and there are > times > >>>>>>> when it makes sense to be flexible with things. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < > >>>>>>> rifaat.ietf@gmail.com> wrote: > >>>>>>> > >>>>>>> Sorry Brian, I was not clear with my statement. > >>>>>>> > >>>>>>> I meant to say that we should not allow the process to prevent the > >>>>>>> WG from producing a quality document without issues, assuming > there is an > >>>>>>> issue in the first place. > >>>>>>> > >>>>>>> Ideally we want to get these identified during the WGLC, but things > >>>>>>> happen and sometimes the WG misses something. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I hear you and agree that this make things difficult for authors. > We > >>>>>>> will make sure that this does not become the norm, and we will try > to stick > >>>>>>> to the process as much as possible. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Rifaat > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < > >>>>>>> bcampbell@pingidentity.com> wrote: > >>>>>>> > >>>>>>> Thanks Rifaat. Process is as process does, right? I do kinda want > to > >>>>>>> grumble about WGCL having passed already but that's mostly because > replying > >>>>>>> to these kinds of threads is hard for me and I'll just get over > it... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> As far as I understand things, the security concerns come into play > >>>>>>> when the client is being told the by the resource how to identity > the > >>>>>>> resource like is described in > >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and > >>>>>>> using the actual location in that context ,along with some other > checks > >>>>>>> prescribed in that draft, prevents the kind of issues John > described > >>>>>>> earlier in the thread. > >>>>>>> > >>>>>>> In cases where the client knows the resource a priori or > out-of-band > >>>>>>> or configured or whatever, I don't think the same security > concerns arise. > >>>>>>> And using such a known value, be it an actual location or logical > >>>>>>> representation, would be okay. > >>>>>>> > >>>>>>> The resource-indicators draft is admittedly somewhat > >>>>>>> location-centric in how it talks about the value of the 'resource' > >>>>>>> parameter. But ultimately it defines it as an absolute URI that > indicates > >>>>>>> the location of the target service or resource where access is > being > >>>>>>> requested. A location can be varying shades of abstract and I'd > say that > >>>>>>> using a URI as 'resource' parameter value that's a logical > identifier that > >>>>>>> points to some resource is well within the bounds of the draft. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So maybe the draft is okay as is? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Or perhaps that's too much to be left as an exerciser to the > >>>>>>> reader? And some text should be added and/or adjusted so the > >>>>>>> resource-indicators draft would be a little more open/clear about > the > >>>>>>> parameter value potentially being more of a logical or abstract > identifier > >>>>>>> and not necessarily a network addressable URL? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < > >>>>>>> rifaat.ietf@gmail.com> wrote: > >>>>>>> > >>>>>>> I wouldn't worry too much about the process. > >>>>>>> > >>>>>>> If it makes sense to update the document, then feel free to do > that. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Rifaat > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley > >>>>>>> wrote: > >>>>>>> > >>>>>>> Yes the logical resource can be provided by "scope" > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Some implementations like Ping and Auth0 have been adding another > >>>>>>> parameter "aud" to identify the logical resource and then using > scopes to > >>>>>>> define permissions to the resource. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Fortunately, we are using a different parameter name so not > stepping > >>>>>>> on that.. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> We could go back and try to add text explaining the difference, but > >>>>>>> we are quite late in the process. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I agree that a logical resource parameter may be helpful, but > >>>>>>> perhaps it should be a separate draft. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> John B. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > >>>>>>> richanna@amazon.com> wrote: > >>>>>>> > >>>>>>> Doesn?t the ?scope? parameter already provide a means of specifying > >>>>>>> a logical identifier? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Annabelle Richard Backman > >>>>>>> > >>>>>>> AWS Identity > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *From: *OAuth on behalf of Vittorio > >>>>>>> Bertocci >>>>>>> <40auth0..com@dmarc.ietf.org>> > >>>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM > >>>>>>> *To: *John Bradley > >>>>>>> *Cc: *IETF oauth WG > >>>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for > >>>>>>> draft-ietf-oauth-resource-indicators-01 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks John for the background. > >>>>>>> > >>>>>>> I agree that from the client validation PoV, having an identifier > >>>>>>> corresponding to a location makes things more solid. > >>>>>>> > >>>>>>> That said: the use of logical identifiers is widespread, as it has > >>>>>>> significant practical advantages (think of services that assign > generated > >>>>>>> hosting URLs only at deployment time, or services that are somehow > grouped > >>>>>>> under the same logical audience across > regions/environment/deployments). > >>>>>>> People won't stop using logical identifiers, because they often > have no > >>>>>>> alternative (generating new audiences on the fly at the AS every > time you > >>>>>>> do a deployment and get assigned a new URL can be unfeasible). > Leaving a > >>>>>>> widely used approach as exercise to the reader seems a disservice > to the > >>>>>>> community, given that this might lead to vendors (for example > Microsoft and > >>>>>>> Auth0) keeping their own proprietary parameters, or developers > misusing the > >>>>>>> ones in place; would make it hard for SDK developers to provide > libraries > >>>>>>> that work out of the box with different ASes; and so on. > >>>>>>> > >>>>>>> Would it be feasible to add such parameter directly in this spec? > >>>>>>> That would eliminate the interop issues, and also gives us a > chance to > >>>>>>> fully warn people about the security shortcomings of choosing that > approach. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley > >>>>>>> wrote: > >>>>>>> > >>>>>>> We have discussed this. > >>>>>>> > >>>>>>> Audiences can certainly be logical identifiers. > >>>>>>> > >>>>>>> This however is a more specific location. The AS is free to map > the > >>>>>>> location into some abstract audience in the AT. > >>>>>>> > >>>>>>> From a security point of view once the client starts asking for > >>>>>>> logical resources it can be tricked into asking for the wrong one > as a bad > >>>>>>> resource can always lie about what logical resource it is. > >>>>>>> > >>>>>>> If we were to change it, how a client would validate it becomes > >>>>>>> challenging to impossible. > >>>>>>> > >>>>>>> The AS is free to do whatever mapping of locations to identifiers > it > >>>>>>> needs for access tokens. > >>>>>>> > >>>>>>> Some implementations may want to keep additional parameters like > >>>>>>> logical audience, but that should be separate from resource. > >>>>>>> > >>>>>>> John B. > >>>>>>> > >>>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > >>>>>>> > >>>>>>> Hi Vittorio, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The text you quoted is copied form the abstract of the draft > itself. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *Authors,* > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Should the draft be updated to cover the logical identifier case? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Rifaat > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci < > >>>>>>> Vittorio@auth0.com> wrote: > >>>>>>> > >>>>>>> Hi Rifaat, > >>>>>>> > >>>>>>> one detail. The tech summary says > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> An extension to the OAuth 2.0 Authorization Framework defining > request > >>>>>>> > >>>>>>> parameters that enable a client to explicitly signal to an > authorization server > >>>>>>> > >>>>>>> about the *location* of the protected resource(s) to which it is > requesting > >>>>>>> > >>>>>>> access. > >>>>>>> > >>>>>>> But at least in the Microsoft implementation, the resource > >>>>>>> identifier doesn't *have* to be a network addressable URL (and if > >>>>>>> it is, it doesn't strictly need to match the actual resource > location). It > >>>>>>> can be a logical identifier, tho using the actual resource > location there > >>>>>>> has benefits (domain ownership check, prevention of token > forwarding etc). > >>>>>>> > >>>>>>> Same for Auth0, the audience parameter is a logical identifier > >>>>>>> rather than a location. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < > >>>>>>> rifaat.ietf@gmail.com> wrote: > >>>>>>> > >>>>>>> All, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The following is the first shepherd write-up for > >>>>>>> the draft-ietf-oauth-resource-indicators-01 document. > >>>>>>> > >>>>>>> > >>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Please, take a look and let me know if I missed anything. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Rifaat > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> > >>>>>>> OAuth mailing list > >>>>>>> > >>>>>>> OAuth@ietf.org > >>>>>>> > >>>>>>> https://www.ietf..org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> > >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >>>>>>> privileged material for the sole use of the intended recipient(s). > Any > >>>>>>> review, use, distribution or disclosure by others is strictly > prohibited. > >>>>>>> If you have received this communication in error, please notify > the sender > >>>>>>> immediately by e-mail and delete the message and any file > attachments from > >>>>>>> your computer. Thank you.* > >>>>>>> > >>>>>>> > >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >>>>>>> privileged material for the sole use of the intended recipient(s). > Any > >>>>>>> review, use, distribution or disclosure by others is strictly > prohibited.. > >>>>>>> If you have received this communication in error, please notify > the sender > >>>>>>> immediately by e-mail and delete the message and any file > attachments from > >>>>>>> your computer. Thank you.* > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> > >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >>>> privileged material for the sole use of the intended recipient(s). Any > >>>> review, use, distribution or disclosure by others is strictly > prohibited.. > >>>> If you have received this communication in error, please notify the > sender > >>>> immediately by e-mail and delete the message and any file attachments > from > >>>> your computer. Thank you.* > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190123/9199c27a/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 45 > ************************************** > --00000000000067442505803dc1eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Reply all



On Wed, Jan 23, 2019, 8= :45 AM <oauth-request@ietf.or= g> wrote:
Send OAuth mailing= list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01 (Vittorio Bert= occi)


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

Message: 1
Date: Wed, 23 Jan 2019 08:44:43 -0800
From: Vittorio Bertocci <Vittorio@auth0.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>, =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAO_FVe6= +2eexcqkreKnV43stoAsA8-+RMRZEK7_EhJk+OA7X_A@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to=
cover the logical identifier use case, highlighting the security
implications of going that route. You can find the revised text in
https://github.c= om/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes. Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we<= br> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have = a
chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
wrote:

> Thank you guys!
>
>
> On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:
>
>> Hi Rifaat,
>> absolutely. Brian and myself already started working on some langu= age,
>> however this week he is in vacation hence it might take few days b= efore we
>> come back to the list with something.
>> Cheers,
>> V.
>>
>> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t;
>> wrote:
>>
>>> Brian, Vittorio,
>>>
>>> To move this discussion forward, can you guys suggest some tex= t to make
>>> the logical identifier usage clearer?
>>>
>>> Regards,
>>>=C2=A0 Rifaat
>>>
>>>
>>> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell= =3D
>>> 40pingidentity.com@dmarc.ietf.org> wrote:
>>>
>>>> As I suggested before, I do think that's within the bo= unds of the
>>>> draft's definition of 'resource' as a URI. And= that perhaps all that's
>>>> needed is some minor adjustment and/or augmentation of som= e text to make it
>>>> more clear.
>>>>
>>>> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com&= gt;
>>>> wrote:
>>>>
>>>>> [sent to John only by mistake, resending to the ML] >>>>>
>>>>> In Azure AD v1 & ADFS, that's resource. It cou= ld be used for both
>>>>> network and logical ids, with the concrete usage in th= e wild I described
>>>>> earlier.
>>>>> In Azure AD v2, the resource as explicit parameter (ne= twork, logic or
>>>>> otherwise) is gone and is expressed as part of the sco= pe string of all the
>>>>> scopes requested for a given resource- but it still ex= ist in practice tho
>>>>> as it still end up in the resulting aud of the issued = token.
>>>>> This is 9 months old info hence
>>>>>
>>>>> On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> w= rote:
>>>>>
>>>>>> What is the parameter that Microsoft is using?
>>>>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
>>>>>>
>>>>>> First of all, it wasn't my intent to disrupt t= he established process.
>>>>>> In my former position I wasn't monitoring thos= e discussions hence I didn't
>>>>>> have a chance to offer feedback. When I saw someth= ing that gave me the
>>>>>> impression might lead to issues, and given that I = worked with actual
>>>>>> deployments and developers using a similar paramet= er for a long time, I
>>>>>> thought prudent to bring this up. I really appreci= ate Rifaat's stance on
>>>>>> this. End of preamble.
>>>>>>
>>>>>> Ultimately my goal is for developers to have guida= nce on how to work
>>>>>> with the concept of logical resource in a standard= compliant way, hence it
>>>>>> doesn't strictly matter whether the definition= of the corresponding
>>>>>> parameter lives in oauth-resource-indicators or el= sewhere.
>>>>>> That said. Reading through the draft, it would app= ear that most of
>>>>>> the reasons for which the spec was created apply t= o both the network
>>>>>> addressable and the logical resource types: knowin= g what keys to use to
>>>>>> encrypt the token, constrain access tokens to the = intended audience,
>>>>>> avoiding overloading scopes with resource indicati= ng parts... those all
>>>>>> apply to network addressable and logic identifiers= alike. And both
>>>>>> parameters are expected to result in audience rest= ricted tokens. It seems
>>>>>> the only difference comes at token usage time, wit= h the network addressable
>>>>>> case giving more guarantees that the token will go= to its intended
>>>>>> recipient, but the request and audience restrictio= n syntax seems to be
>>>>>> exactly the same.
>>>>>> On top of this: in the 99.999% of the scenarios I = encountered in the
>>>>>> wild in the last 5 years of using the resource par= ameter in the MS
>>>>>> ecosystem, the resource identifier was known at de= sign time: the developer
>>>>>> discovered it out of band and placed it in the app= config at deployment
>>>>>> time. Those aren't fringe cases I occasionally= encountered: the resource
>>>>>> parameter in Azure AD v1 and ADFS was mandatory, h= ence literally every
>>>>>> solution i saw or touched used it. As Brian sugges= ted, this is a scenario
>>>>>> where the security advantages of the network addre= ssable case aren't as
>>>>>> pronounced as in the case in which the client disc= overs the resource
>>>>>> identifier at runtime. This isn't just because= there is no specification
>>>>>> suggesting location should be explicitly indicated= , it's because there are
>>>>>> many practical advantages at development and deplo= yment time to be able to
>>>>>> use logical identifiers- and if the *concrete *sec= urity advantages
>>>>>> don't apply to the their case, people will sim= ply not comply.
>>>>>>
>>>>>> In summary: creating two different parameters in t= wo different
>>>>>> documents is better than ignoring he logical ident= ifier case altogether,
>>>>>> however I think that not acknowledging the logical= id case
>>>>>> in oauth-resource-indicators is going to create co= nfusion and ultimately
>>>>>> not be as useful to the developer community as it = could be.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:
>>>>>>
>>>>>>> +1 to Mike and John?s comments.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones <<= br> >>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>= ; wrote:
>>>>>>>
>>>>>>> I also agree that ?resource? should be a speci= fic
>>>>>>> network-addressable URL whereas a separate aud= ience parameter (like ?aud?
>>>>>>> in JWTs) can refer to one or more logical reso= urces.=C2=A0 They are different,
>>>>>>> if related, things.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note that the ACE WG is proposing to register = a logical audience
>>>>>>> parameter ?req_aud? in
>>>>>>> https://tools= .ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>>>>>>> based on feedback from OAuth WG members.=C2=A0= This is a general OAuth
>>>>>>> parameter, which any OAuth deployment will be = able to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I therefore believe that no changes are needed= to
>>>>>>> draft-ietf-oauth-resource-indicators, as the l= ogical audience work is
>>>>>>> already happening in another draft.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-- Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf O= f * John Bradley
>>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>>>>> *To:* Brian Campbell <bcampbell@pingidentity.com&g= t;
>>>>>>> *Cc:* Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.= ietf.org>; IETF
>>>>>>> oauth WG <oauth@ietf.org>
>>>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up fo= r
>>>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We need to decide if we want to make a change.=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For security we are location centric.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I prefer to keep resource location separate fr= om logical audience
>>>>>>> that can be a scope or other parameter.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If becomes harder for people to use the parame= ter correctly if we
>>>>>>> are too flexible.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would rather have a separate logical audienc= e parameter if we
>>>>>>> think we want one.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell = <
>>>>>>> bcampbell@pingidentity.com wrote:
>>>>>>>
>>>>>>> No apology needed, Rifaat. And I apologize if = what I said came off
>>>>>>> the wrong way. I was just trying to make light= of the situation.. And I
>>>>>>> agree that we should not be hamstrung by the p= rocess and there are times
>>>>>>> when it makes sense to be flexible with things= .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Y= usef <
>>>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>> Sorry Brian, I was not clear with my statement= .
>>>>>>>
>>>>>>> I meant to say that we should not allow the pr= ocess to prevent the
>>>>>>> WG from producing a quality document without i= ssues, assuming there is an
>>>>>>> issue in the first place.
>>>>>>>
>>>>>>> Ideally we want to get these identified during= the WGLC, but things
>>>>>>> happen and sometimes the WG misses something.<= br> >>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I hear you and agree that this make things dif= ficult for authors. We
>>>>>>> will make sure that this does not become the n= orm, and we will try to stick
>>>>>>> to the process as much as possible.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>=C2=A0 Rifaat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell= <
>>>>>>> bcampbell@pingidentity.com> wrote:
>>>>>>>
>>>>>>> Thanks Rifaat. Process is as process does, rig= ht? I do kinda want to
>>>>>>> grumble about WGCL having passed already but t= hat's mostly because replying
>>>>>>> to these kinds of threads is hard for me and I= 'll just get over it...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As far as I understand things, the security co= ncerns come into play
>>>>>>> when the client is being told the by the resou= rce how to identity the
>>>>>>> resource like is described in
>>>>>>> https://tool= s.ietf.org/html/draft-ietf-oauth-distributed-01 and
>>>>>>> using the actual location in that context ,alo= ng with some other checks
>>>>>>> prescribed in that draft, prevents the kind of= issues John described
>>>>>>> earlier in the thread.
>>>>>>>
>>>>>>> In cases where the client knows the resource a= priori or out-of-band
>>>>>>> or configured or whatever, I don't think t= he same security concerns arise.
>>>>>>> And using such a known value, be it an actual = location or logical
>>>>>>> representation, would be okay.
>>>>>>>
>>>>>>> The resource-indicators draft is admittedly so= mewhat
>>>>>>> location-centric in how it talks about the val= ue of the 'resource'
>>>>>>> parameter. But ultimately it defines it as an = absolute URI that indicates
>>>>>>> the location of the target service or resource= where access is being
>>>>>>> requested. A location can be varying shades of= abstract and I'd say that
>>>>>>> using a URI as 'resource' parameter va= lue that's a logical identifier that
>>>>>>> points to some resource is well within the bou= nds of the draft.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So maybe the draft is okay as is?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Or perhaps that's too much to be left as a= n exerciser to the
>>>>>>> reader?=C2=A0 And some text should be added an= d/or adjusted so the
>>>>>>> resource-indicators draft would be a little mo= re open/clear about the
>>>>>>> parameter value potentially being more of a lo= gical or abstract identifier
>>>>>>> and not necessarily a network addressable URL?=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Y= usef <
>>>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>> I wouldn't worry too much about the proces= s.
>>>>>>>
>>>>>>> If it makes sense to update the document, then= feel free to do that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>=C2=A0 Rifaat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley &= lt;ve7jtb@ve7jtb.com= >
>>>>>>> wrote:
>>>>>>>
>>>>>>> Yes the logical resource can be provided by &q= uot;scope"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Some implementations like Ping and Auth0 have = been adding another
>>>>>>> parameter "aud" to identify the logi= cal resource and then using scopes to
>>>>>>> define permissions to the resource.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fortunately, we are using a different paramete= r name so not stepping
>>>>>>> on that..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We could go back and try to add text explainin= g the difference, but
>>>>>>> we are quite late in the process.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I agree that a logical resource parameter may = be helpful, but
>>>>>>> perhaps it should be a separate draft.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backma= n, Annabelle <
>>>>>>> richanna@amazon.com> wrote:
>>>>>>>
>>>>>>> Doesn?t the ?scope? parameter already provide = a means of specifying
>>>>>>> a logical identifier?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Annabelle Richard Backman
>>>>>>>
>>>>>>> AWS Identity
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From: *OAuth <oauth-bounces@ietf.org> on behalf of= Vittorio
>>>>>>> Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org >>>>>>> <40auth0..com@dmarc.ietf.org>>
>>>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM >>>>>>> *To: *John Bradley <ve7jtb@ve7jtb.com>
>>>>>>> *Cc: *IETF oauth WG <oauth@ietf.org>
>>>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up fo= r
>>>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks John for the background.
>>>>>>>
>>>>>>> I agree that from the client validation PoV, h= aving an identifier
>>>>>>> corresponding to a location makes things more = solid.
>>>>>>>
>>>>>>> That said: the use of logical identifiers is w= idespread, as it has
>>>>>>> significant practical advantages (think of ser= vices that assign generated
>>>>>>> hosting URLs only at deployment time, or servi= ces that are somehow grouped
>>>>>>> under the same logical audience across regions= /environment/deployments).
>>>>>>> People won't stop using logical identifier= s, because they often have no
>>>>>>> alternative (generating new audiences on the f= ly at the AS every time you
>>>>>>> do a deployment and get assigned a new URL can= be unfeasible). Leaving a
>>>>>>> widely used approach as exercise to the reader= seems a disservice to the
>>>>>>> community, given that this might lead to vendo= rs (for example Microsoft and
>>>>>>> Auth0) keeping their own proprietary parameter= s, or developers misusing the
>>>>>>> ones in place; would make it hard for SDK deve= lopers to provide libraries
>>>>>>> that work out of the box with different ASes; = and so on.
>>>>>>>
>>>>>>> Would it be feasible to add such parameter dir= ectly in this spec?
>>>>>>> That would eliminate the interop issues, and a= lso gives us a chance to
>>>>>>> fully warn people about the security shortcomi= ngs of choosing that approach.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley &= lt;ve7jtb@ve7jtb.com= >
>>>>>>> wrote:
>>>>>>>
>>>>>>> We have discussed this.
>>>>>>>
>>>>>>> Audiences can certainly be logical identifiers= .
>>>>>>>
>>>>>>> This however is a more specific location.=C2= =A0 The AS is free to map the
>>>>>>> location into some abstract audience in the AT= .
>>>>>>>
>>>>>>> From a security point of view once the client = starts asking for
>>>>>>> logical resources it can be tricked into askin= g for the wrong one as a bad
>>>>>>> resource can always lie about what logical res= ource it is.
>>>>>>>
>>>>>>> If we were to change it, how a client would va= lidate it becomes
>>>>>>> challenging to impossible.
>>>>>>>
>>>>>>> The AS is free to do whatever mapping of locat= ions to identifiers it
>>>>>>> needs for access tokens.
>>>>>>>
>>>>>>> Some implementations may want to keep addition= al parameters like
>>>>>>> logical audience, but that should be separate = from resource.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote= :
>>>>>>>
>>>>>>> Hi Vittorio,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The text you quoted is copied form the abstrac= t of the draft itself.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Authors,*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Should the draft be updated to cover the logic= al identifier case?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>=C2=A0 Rifaat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Berto= cci <
>>>>>>> Vittorio@auth0.com> wrote:
>>>>>>>
>>>>>>> Hi Rifaat,
>>>>>>>
>>>>>>> one detail. The tech summary says
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> An extension to the OAuth 2.0 Authorization Fr= amework defining request
>>>>>>>
>>>>>>> parameters that enable a client to explicitly = signal to an authorization server
>>>>>>>
>>>>>>> about the *location* of the protected resource= (s) to which it is requesting
>>>>>>>
>>>>>>> access.
>>>>>>>
>>>>>>> But at least in the Microsoft implementation, = the resource
>>>>>>> identifier doesn't *have* to be a network = addressable URL (and if
>>>>>>> it is, it doesn't strictly need to match t= he actual resource location). It
>>>>>>> can be a logical identifier, tho using the act= ual resource location there
>>>>>>> has benefits (domain ownership check, preventi= on of token forwarding etc).
>>>>>>>
>>>>>>> Same for Auth0, the audience parameter is a lo= gical identifier
>>>>>>> rather than a location.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Y= usef <
>>>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The following is the first shepherd write-up f= or
>>>>>>> the draft-ietf-oauth-resource-indicators-01 do= cument.
>>>>>>>
>>>>>>>
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-i= ndicators/shepherdwriteup/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please, take a look and let me know if I misse= d anything.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>=C2=A0 Rifaat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>>
>>>>>>> OAuth mailing list
>>>>>>>
>>>>>>> OAuth@ietf.org
>>>>>>>
>>>>>>> https://www.ietf..org/mailman/listinfo/oauth <<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" rel=3D"noreferrer" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>> *CONFIDENTIALITY NOTICE: This email may contai= n confidential and
>>>>>>> privileged material for the sole use of the in= tended recipient(s). Any
>>>>>>> review, use, distribution or disclosure by oth= ers is strictly prohibited.
>>>>>>> If you have received this communication in err= or, please notify the sender
>>>>>>> immediately by e-mail and delete the message a= nd any file attachments from
>>>>>>> your computer. Thank you.*
>>>>>>>
>>>>>>>
>>>>>>> *CONFIDENTIALITY NOTICE: This email may contai= n confidential and
>>>>>>> privileged material for the sole use of the in= tended recipient(s). Any
>>>>>>> review, use, distribution or disclosure by oth= ers is strictly prohibited..
>>>>>>> If you have received this communication in err= or, please notify the sender
>>>>>>> immediately by e-mail and delete the message a= nd any file attachments from
>>>>>>> your computer. Thank you.*
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman= /listinfo/oauth
>>>>>>>
>>>>>>>
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidenti= al and
>>>> privileged material for the sole use of the intended recip= ient(s). Any
>>>> review, use, distribution or disclosure by others is stric= tly prohibited..
>>>> If you have received this communication in error, please n= otify the sender
>>>> immediately by e-mail and delete the message and any file = attachments from
>>>> your computer. Thank you.*
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oa= uth
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190123/9199c2= 7a/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 123, Issue 45
**************************************
--00000000000067442505803dc1eb-- From nobody Thu Jan 24 16:53:50 2019 Return-Path: <4all7the5time@gmail.com> X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B32B131329 for ; Thu, 24 Jan 2019 16:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01] 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 lPpBKr65U97y for ; Thu, 24 Jan 2019 16:53:38 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B4313123D for ; Thu, 24 Jan 2019 16:53:35 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id u18so5707084lff.10 for ; Thu, 24 Jan 2019 16:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vLS3nf5j4ZXCVqZiovYNTJDVzhtGGaWDCoFl+OTRUt8=; b=oUYo2x7dVA3NItmnYpdGW1kPpeVxP6TMqivE0q+FGo1wraCJbVWpLQ/Ser/TMdX7hB zKBob4ZEjuUvWa3cW5d0J38x8FWlxP0CwRi4vV+mfjtlxWd5GcpT620tn8b/rzRPldVi WjpsIlDmAT7qCpR6w+j7V/gvHjI2kjZunRVQW4DB2XWXmen+nP5NioX36ohgGzvSjl8i tlapbJshdRUirX+wfKpEj5QH67EkfCarpIHsCSfZYTdQyGGm3ZATzAY/0UVgHtwmP9YI u9X7OCeWPZQ4mevvhFxDTHj9CauHwzyJS1LF7BqRsbf+QnScgL3xPsI3DY+ESd2RPRzo 3/lg== 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=vLS3nf5j4ZXCVqZiovYNTJDVzhtGGaWDCoFl+OTRUt8=; b=VTZxlNxAXVAXICBerrLHrT0WHMvpDwlKLqDZB1AXcqrQPjgRcHu1jQzevCeJfcekcz jIRbKStT6+AGxeEV+m4a0+bEfWvOBOPO7/NsmG2TnAiKh+vbVN2NuifDWA35H5upC51P Hp+ZrHEMktswWIpGqvWNTuHwhw0ojpG9vnXYAZblowzPCAF4UpihjgzEFiofP5d36zSz NxqnzONyuY6JWR3Dq6arzrAdtdHDgLVTM6TBx9tidNS/JQrfnSYpmYjde4qkTBSf3ul3 2fnVhpTvleA3dcHNlWL6fTbCoy+Yv73+0NxJYrAW6A2aGFKt6kLkmTBW7SNtjZqmmPmr AVeQ== X-Gm-Message-State: AJcUukd/NeRUVs1mk/2vNIV2XMbWv0DwPd7FklK0YzANObNGSkuTzitB BwluDXMCx3gaywLmuDh+CGd87iUOcLVhwmnbyelWxw== X-Google-Smtp-Source: ALg8bN5PiHCKpOKrZgd4onG52ZcRViJKJVvCKJtKvMbZVx9TH4KVDlRb3VTKQdz1LhXAVMSFB7skFFUHR0W/fabZJ8Y= X-Received: by 2002:a19:a9d2:: with SMTP id s201mr1540302lfe.154.1548377613190; Thu, 24 Jan 2019 16:53:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lao Vang <4all7the5time@gmail.com> Date: Thu, 24 Jan 2019 16:51:52 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000009cce2005803dc128" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 00:53:49 -0000 --0000000000009cce2005803dc128 Content-Type: text/plain; charset="UTF-8" Reply all On Tue, Jan 22, 2019, 10:20 AM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 (Mike Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Jan 2019 18:19:31 +0000 > From: Mike Jones > To: Rifaat Shekh-Yusef , Vittorio Bertocci > > Cc: Brian Campbell , IETF > oauth WG > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > Message-ID: > < > MW2PR00MB030099E717A31D46BCAA4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > I think that a non-normative reference to ?req_aud? in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be > added to the resource indicators doc to inform developers that req_aud is > also available to then, and then we should call it a day. > > -- Mike > > From: OAuth On Behalf Of Rifaat Shekh-Yusef > Sent: Monday, January 21, 2019 5:36 PM > To: Vittorio Bertocci > Cc: Brian Campbell ; IETF > oauth WG > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > Thank you guys! > > > On Monday, January 21, 2019, Vittorio Bertocci Vittorio@auth0.com>> wrote: > Hi Rifaat, > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before we > come back to the list with something. > Cheers, > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > Brian, Vittorio, > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > Regards, > Rifaat > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> > wrote: > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > [sent to John only by mistake, resending to the ML] > > In Azure AD v1 & ADFS, that's resource. It could be used for both network > and logical ids, with the concrete usage in the wild I described earlier. > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all the > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley ve7jtb@ve7jtb.com>> wrote: > > What is the parameter that Microsoft is using? > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressable > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovered > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or > touched used it. As Brian suggested, this is a scenario where the security > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. This > isn't just because there is no specification suggesting location should be > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- and > if the concrete security advantages don't apply to the their case, people > will simply not comply. > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case in > oauth-resource-indicators is going to create confusion and ultimately not > be as useful to the developer community as it could be. > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt phil.hunt@oracle.com>> wrote: > +1 to Mike and John?s comments. > Phil > > On Jan 19, 2019, at 12:34 PM, Mike Jones 40microsoft.com@dmarc.ietf.org 40microsoft.com@dmarc.ietf.org>> wrote: > I also agree that ?resource? should be a specific network-addressable URL > whereas a separate audience parameter (like ?aud? in JWTs) can refer to one > or more logical resources. They are different, if related, things. > > Note that the ACE WG is proposing to register a logical audience parameter > ?req_aud? in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > -- Mike > > From: OAuth > On > Behalf Of John Bradley > Sent: Saturday, January 19, 2019 9:01 AM > To: Brian Campbell bcampbell@pingidentity.com>> > Cc: Vittorio Bertocci =40auth0.com@dmarc.ietf.org>>; IETF oauth WG oauth@ietf.org>> > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > We need to decide if we want to make a change. > > For security we are location centric. > > I prefer to keep resource location separate from logical audience that can > be a scope or other parameter. > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > I would rather have a separate logical audience parameter if we think we > want one. > > John B. > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when it > makes sense to be flexible with things. > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > Sorry Brian, I was not clear with my statement. > I meant to say that we should not allow the process to prevent the WG from > producing a quality document without issues, assuming there is an issue in > the first place. > Ideally we want to get these identified during the WGLC, but things happen > and sometimes the WG misses something. > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > Regards, > Rifaat > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replying > to these kinds of threads is hard for me and I'll just get over it... > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. And > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource is > well within the bounds of the draft. > > So maybe the draft is okay as is? > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draft > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > I wouldn't worry too much about the process. > If it makes sense to update the document, then feel free to do that. > > Regards, > Rifaat > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley ve7jtb@ve7jtb.com>> wrote: > Yes the logical resource can be provided by "scope" > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > Fortunately, we are using a different parameter name so not stepping on > that.. > > We could go back and try to add text explaining the difference, but we are > quite late in the process. > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > John B. > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > Doesn?t the ?scope? parameter already provide a means of specifying a > logical identifier? > > -- > Annabelle Richard Backman > AWS Identity > > > From: OAuth > on > behalf of Vittorio Bertocci 40auth0..com@dmarc.ietf.org>> > Date: Friday, January 18, 2019 at 5:47 AM > To: John Bradley > > Cc: IETF oauth WG > > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > Thanks John for the background. > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow grouped > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft and > Auth0) keeping their own proprietary parameters, or developers misusing the > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley ve7jtb@ve7jtb.com>> wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resource > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it needs > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > Hi Vittorio, > > The text you quoted is copied form the abstract of the draft itself. > > > Authors, > > Should the draft be updated to cover the logical identifier case? > > Regards, > Rifaat > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > Hi Rifaat, > one detail. The tech summary says > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization > server > > about the location of the protected resource(s) to which it is requesting > > access. > But at least in the Microsoft implementation, the resource identifier > doesn't have to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > Same for Auth0, the audience parameter is a logical identifier rather than > a location. > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > All, > > The following is the first shepherd write-up for the > draft-ietf-oauth-resource-indicators-01 document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, take a look and let me know if I missed anything. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth< > https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited... If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 44 > ************************************** > --0000000000009cce2005803dc128 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Reply all



On Tue, Jan 22, 2019, 1= 0:20 AM <oauth-request@ietf.o= rg> wrote:
Send OAuth mailin= g list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01 (Mike Jones)

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

Message: 1
Date: Tue, 22 Jan 2019 18:19:31 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertocci
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <Vittorio@auth0.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>, I= ETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <MW= 2PR00MB030099E717A31D46BCAA4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.co= m>

Content-Type: text/plain; charset=3D"utf-8"

I think that a non-normative reference to=C2=A0 ?req_aud? in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-= 01 should be added to the resource indicators doc to inform developers = that req_aud is also available to then, and then we should call it a day.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 -- Mike

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, January 21, 2019 5:36 PM
To: Vittorio Bertocci <Vittorio@auth0.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>; I= ETF oauth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-ind= icators-01

Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com<mailto:Vittorio@auth0.com>>= ; wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, howe= ver this week he is in vacation hence it might take few days before we come= back to the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com<mailto:= rifaat.ietf@gmai= l.com>> wrote:
Brian, Vittorio,

To move this discussion forward, can you guys suggest some text to make the= logical identifier usage clearer?

Regards,
=C2=A0Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D40pingidentity.= com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.org>> = wrote:
As I suggested before, I do think that's within the bounds of the draft= 's definition of 'resource' as a URI. And that perhaps all that= 's needed is some minor adjustment and/or augmentation of some text to = make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com<mailto:Vittorio@auth0.com>= > wrote:
[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's resource. It could be used for both n= etwork and logical ids, with the concrete usage in the wild I described ear= lier.
In Azure AD v2, the resource as explicit parameter (network, logic or other= wise) is gone and is expressed as part of the scope string of all the scope= s requested for a given resource- but it still exist in practice tho as it = still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrote:=

What is the parameter that Microsoft is using?
On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. I= n my former position I wasn't monitoring those discussions hence I didn= 't have a chance to offer feedback. When I saw something that gave me t= he impression might lead to issues, and given that I worked with actual dep= loyments and developers using a similar parameter for a long time, I though= t prudent to bring this up. I really appreciate Rifaat's stance on this= . End of preamble.

Ultimately my goal is for developers to have guidance on how to work with t= he concept of logical resource in a standard compliant way, hence it doesn&= #39;t strictly matter whether the definition of the corresponding parameter= lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reas= ons for which the spec was created apply to both the network addressable an= d the logical resource types: knowing what keys to use to encrypt the token= , constrain access tokens to the intended audience, avoiding overloading sc= opes with resource indicating parts... those all apply to network addressab= le and logic identifiers alike. And both parameters are expected to result = in audience restricted tokens. It seems the only difference comes at token = usage time, with the network addressable case giving more guarantees that t= he token will go to its intended recipient, but the request and audience re= striction syntax seems to be exactly the same.
On top of this: in the 99.999% of the scenarios I encountered in the wild i= n the last 5 years of using the resource parameter in the MS ecosystem, the= resource identifier was known at design time: the developer discovered it = out of band and placed it in the app config at deployment time. Those aren&= #39;t fringe cases I occasionally encountered: the resource parameter in Az= ure AD v1 and ADFS was mandatory, hence literally every solution i saw or t= ouched used it. As Brian suggested, this is a scenario where the security a= dvantages of the network addressable case aren't as pronounced as in th= e case in which the client discovers the resource identifier at runtime. Th= is isn't just because there is no specification suggesting location sho= uld be explicitly indicated, it's because there are many practical adva= ntages at development and deployment time to be able to use logical identif= iers- and if the concrete security advantages don't apply to the their = case, people will simply not comply.

In summary: creating two different parameters in two different documents is= better than ignoring he logical identifier case altogether, however I thin= k that not acknowledging the logical id case in oauth-resource-indicators i= s going to create confusion and ultimately not be as useful to the develope= r community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>&g= t; wrote:
+1 to Mike and John?s comments.
Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc= .ietf.org<mailto:= Michael.Jones=3D40microsoft.com@dmarc.ietf.org>> wrote:
I also agree that ?resource? should be a specific network-addressable URL w= hereas a separate audience parameter (like ?aud? in JWTs) can refer to one = or more logical resources.=C2=A0 They are different, if related, things.
Note that the ACE WG is proposing to register a logical audience parameter = ?req_aud? in https://tools.ietf.org/html/d= raft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG = members.=C2=A0 This is a general OAuth parameter, which any OAuth deploymen= t will be able to use.

I therefore believe that no changes are needed to draft-ietf-oauth-resource= -indicators, as the logical audience work is already happening in another d= raft.

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

From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> On Behalf Of John= Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>= ;>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mailto:Vittorio=3D40auth0.com@dmarc.ietf.org&g= t;>; IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-ind= icators-01

We need to decide if we want to make a change.

For security we are location centric.

I prefer to keep resource location separate from logical audience that can = be a scope or other parameter.

If becomes harder for people to use the parameter correctly if we are too f= lexible.

I would rather have a separate logical audience parameter if we think we wa= nt one.

John B.

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com<ma= ilto:bcampb= ell@pingidentity.com> wrote:
No apology needed, Rifaat. And I apologize if what I said came off the wron= g way. I was just trying to make light of the situation.. And I agree that = we should not be hamstrung by the process and there are times when it makes= sense to be flexible with things.

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com<mailto:= rifaat.ietf@gmai= l.com>> wrote:
Sorry Brian, I was not clear with my statement.
I meant to say that we should not allow the process to prevent the WG from = producing a quality document without issues, assuming there is an issue in = the first place.
Ideally we want to get these identified during the WGLC, but things happen = and sometimes the WG misses something.

I hear you and agree that this make things difficult for authors. We will m= ake sure that this does not become the norm, and we will try to stick to th= e process as much as possible.

Regards,
=C2=A0Rifaat


On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com<m= ailto:bcamp= bell@pingidentity.com>> wrote:
Thanks Rifaat. Process is as process does, right? I do kinda want to grumbl= e about WGCL having passed already but that's mostly because replying t= o these kinds of threads is hard for me and I'll just get over it...
As far as I understand things, the security concerns come into play when th= e client is being told the by the resource how to identity the resource lik= e is described in https://tools.ietf.org/= html/draft-ietf-oauth-distributed-01 and using the actual location in t= hat context ,along with some other checks prescribed in that draft, prevent= s the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be = varying shades of abstract and I'd say that using a URI as 'resourc= e' parameter value that's a logical identifier that points to some = resource is well within the bounds of the draft.

So maybe the draft is okay as is?

Or perhaps that's too much to be left as an exerciser to the reader?=C2= =A0 And some text should be added and/or adjusted so the resource-indicator= s draft would be a little more open/clear about the parameter value potenti= ally being more of a logical or abstract identifier and not necessarily a n= etwork addressable URL?



On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com<mailto:= rifaat.ietf@gmai= l.com>> wrote:
I wouldn't worry too much about the process.
If it makes sense to update the document, then feel free to do that.

Regards,
=C2=A0Rifaat


On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrot= e:
Yes the logical resource can be provided by "scope"

Some implementations like Ping and Auth0 have been adding another parameter= "aud" to identify the logical resource and then using scopes to = define permissions to the resource.

Fortunately, we are using a different parameter name so not stepping on tha= t..

We could go back and try to add text explaining the difference, but we are = quite late in the process.

I agree that a logical resource parameter may be helpful, but perhaps it sh= ould be a separate draft.

John B.

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com<mai= lto:richanna@amazo= n.com>> wrote:
Doesn?t the ?scope? parameter already provide a means of specifying a logic= al identifier?

--
Annabelle Richard Backman
AWS Identity


From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> on behalf of Vitt= orio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mailto:40auth0..com@dmarc.ietf.or= g>>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
Cc: IETF oauth WG <o= auth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-ind= icators-01

Thanks John for the background.
I agree that from the client validation PoV, having an identifier correspon= ding to a location makes things more solid.
That said: the use of logical identifiers is widespread, as it has signific= ant practical advantages (think of services that assign generated hosting U= RLs only at deployment time, or services that are somehow grouped under the= same logical audience across regions/environment/deployments). People won&= #39;t stop using logical identifiers, because they often have no alternativ= e (generating new audiences on the fly at the AS every time you do a deploy= ment and get assigned a new URL can be unfeasible). Leaving a widely used a= pproach as exercise to the reader seems a disservice to the community, give= n that this might lead to vendors (for example Microsoft and Auth0) keeping= their own proprietary parameters, or developers misusing the ones in place= ; would make it hard for SDK developers to provide libraries that work out = of the box with different ASes; and so on.
Would it be feasible to add such parameter directly in this spec? That woul= d eliminate the interop issues, and also gives us a chance to fully warn pe= ople about the security shortcomings of choosing that approach.



On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrot= e:

We have discussed this.

Audiences can certainly be logical identifiers.

This however is a more specific location.=C2=A0 The AS is free to map the l= ocation into some abstract audience in the AT.

>From a security point of view once the client starts asking for logical res= ources it can be tricked into asking for the wrong one as a bad resource ca= n always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging= to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs = for access tokens.

Some implementations may want to keep additional parameters like logical au= dience, but that should be separate from resource.

John B.
On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.


Authors,

Should the draft be updated to cover the logical identifier case?

Regards,
=C2=A0Rifaat


On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com<mailto:Vittorio@auth0.com>= > wrote:
Hi Rifaat,
one detail. The tech summary says


An extension to the OAuth 2.0 Authorization Framework defining request

parameters that enable a client to explicitly signal to an authorization se= rver

about the location of the protected resource(s) to which it is requesting
access.
But at least in the Microsoft implementation, the resource identifier doesn= 't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier rather than = a location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com<mailto:= rifaat.ietf@gmai= l.com>> wrote:
All,

The following is the first shepherd write-up for the draft-ietf-oauth-resou= rce-indicators-01 document.
https://datatr= acker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/

Please, take a look and let me know if I missed anything.

Regards,
=C2=A0Rifaat

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


_______________________________________________

OAuth mailing list

OAuth@ietf.org<m= ailto:OAuth@ietf.org>

https://= www.ietf..org/mailman/listinfo/oauth<https://www.i= etf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<m= ailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<m= ailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<m= ailto: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, di= stribution or disclosure by others is strictly prohibited.=C2=A0 If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited..=C2=A0 If you ha= ve received this communication in error, please notify the sender immediate= ly by e-mail and delete the message and any file attachments from your comp= uter. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<m= ailto: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, di= stribution or disclosure by others is strictly prohibited...=C2=A0 If you h= ave received this communication in error, please notify the sender immediat= ely by e-mail and delete the message and any file attachments from your com= puter. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org<m= ailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c476= 1d/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 123, Issue 44
**************************************
--0000000000009cce2005803dc128-- From nobody Thu Jan 24 16:56:39 2019 Return-Path: <4all7the5time@gmail.com> X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4BA12D4E9 for ; Thu, 24 Jan 2019 16:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YEAsOBGDuKRe for ; Thu, 24 Jan 2019 16:56:33 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224AD128D09 for ; Thu, 24 Jan 2019 16:56:33 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id c16so5725527lfj.8 for ; Thu, 24 Jan 2019 16:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EaMtHK25hNoMVXWvYdHsuMRVx/RGhoC0HRRAw4CDlSM=; b=jLZ29SuNwnSMyooKK7HK1+92shRYofo5ixfrODRAezvmAIqRHRCmQjsjDlqy8JCwbe 1EsBKAd/pdcpGKLxXD8FQ23OnDjrVv0hKMWXsCRz0jZhq8e8oXpL3iCSUHfv2ovtm2A0 3UT3RmO5WTZrl/So/h2BoxABk2b0aFmHdtclbTiP5IRxW18fdDXBOURa82UkIUuYMNaJ fyzJz2bQIXYB46QXGamHcWeW73Cx84l91eHHnjW+/PFm4u0AYptD4cuW+1FxaNXCl34s PqkItbCgrXSNgFgaOpZ1KMdjkLS9DsAenD2ZLzl3SOoKCatz2lNaXMrpug3cAeVPG+l4 bW6w== 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=EaMtHK25hNoMVXWvYdHsuMRVx/RGhoC0HRRAw4CDlSM=; b=GEYlEByVHK9XPtKujMpjtpDA8ygvbDeJ1dKK0M/5Vt8WG7SXh+cyvMZWDFRHuTt9H2 C+J0crt+gKMolFKRuiNzx7HSHRzGZHUUwm8tBWiFt/mg78+ZgcOv/fDNqPAsxoHrdzZv L0hyWi82kJoi4fVRzwOM0fHyqqCiObOF0JUlc4wyoUqJQcXb+SJJYCVRnJggQYVrOnoK qhodtgPFKONmHol5T27TL49wqycMUffivemQkVflpSOUpBsNRT3A3oe8XsoT5+JN2lZo 7N+EfpDFa3QQmO7X5QvmAdNjOJxJLyFeew0QqtKZw3T4uBot30obAVSMoHecnPNhNAml /jDg== X-Gm-Message-State: AJcUukdmxGjBG8xE5UZkSwvc9xBr/ejp9XrQOq9oTcgicUtlyIbSq6qK 0HPEks82qpybZu37atDw7m8tduIBn7jXowLGZKRBoQ== X-Google-Smtp-Source: ALg8bN7XAieTXibJTihh87XKXcC1Io0tjOGMQGc4UNNhYWVKAlsoavkAMlPX20RbCmBtOI/S6iFpsOtnVlrhqnzuiCg= X-Received: by 2002:a19:c115:: with SMTP id r21mr6891498lff.144.1548377790747; Thu, 24 Jan 2019 16:56:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lao Vang <4all7the5time@gmail.com> Date: Thu, 24 Jan 2019 16:53:58 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000321f7705803dcc82" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 42 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 00:56:39 -0000 --000000000000321f7705803dcc82 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 21, 2019, 4:39 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 (Vittorio Bertocci) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Jan 2019 16:38:47 -0800 > From: Vittorio Bertocci > To: Rifaat Shekh-Yusef > Cc: Brian Campbell , > IETF oauth WG > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > Message-ID: > myTbejutD7PpXdNGhVBgnjUA@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Rifaat, > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before we > come back to the list with something. > Cheers, > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: > > > >> As I suggested before, I do think that's within the bounds of the > draft's > >> definition of 'resource' as a URI. And that perhaps all that's needed is > >> some minor adjustment and/or augmentation of some text to make it more > >> clear. > >> > >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > >> wrote: > >> > >>> [sent to John only by mistake, resending to the ML] > >>> > >>> In Azure AD v1 & ADFS, that's resource. It could be used for both > >>> network and logical ids, with the concrete usage in the wild I > described > >>> earlier. > >>> In Azure AD v2, the resource as explicit parameter (network, logic or > >>> otherwise) is gone and is expressed as part of the scope string of all > the > >>> scopes requested for a given resource- but it still exist in practice > tho > >>> as it still end up in the resulting aud of the issued token. > >>> This is 9 months old info hence > >>> > >>> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > >>> > >>>> What is the parameter that Microsoft is using? > >>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > >>>> > >>>> First of all, it wasn't my intent to disrupt the established process. > >>>> In my former position I wasn't monitoring those discussions hence I > didn't > >>>> have a chance to offer feedback. When I saw something that gave me the > >>>> impression might lead to issues, and given that I worked with actual > >>>> deployments and developers using a similar parameter for a long time, > I > >>>> thought prudent to bring this up. I really appreciate Rifaat's stance > on > >>>> this. End of preamble. > >>>> > >>>> Ultimately my goal is for developers to have guidance on how to work > >>>> with the concept of logical resource in a standard compliant way, > hence it > >>>> doesn't strictly matter whether the definition of the corresponding > >>>> parameter lives in oauth-resource-indicators or elsewhere. > >>>> That said. Reading through the draft, it would appear that most of the > >>>> reasons for which the spec was created apply to both the network > >>>> addressable and the logical resource types: knowing what keys to use > to > >>>> encrypt the token, constrain access tokens to the intended audience, > >>>> avoiding overloading scopes with resource indicating parts... those > all > >>>> apply to network addressable and logic identifiers alike. And both > >>>> parameters are expected to result in audience restricted tokens. It > seems > >>>> the only difference comes at token usage time, with the network > addressable > >>>> case giving more guarantees that the token will go to its intended > >>>> recipient, but the request and audience restriction syntax seems to be > >>>> exactly the same. > >>>> On top of this: in the 99.999% of the scenarios I encountered in the > >>>> wild in the last 5 years of using the resource parameter in the MS > >>>> ecosystem, the resource identifier was known at design time: the > developer > >>>> discovered it out of band and placed it in the app config at > deployment > >>>> time. Those aren't fringe cases I occasionally encountered: the > resource > >>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally every > >>>> solution i saw or touched used it. As Brian suggested, this is a > scenario > >>>> where the security advantages of the network addressable case aren't > as > >>>> pronounced as in the case in which the client discovers the resource > >>>> identifier at runtime. This isn't just because there is no > specification > >>>> suggesting location should be explicitly indicated, it's because > there are > >>>> many practical advantages at development and deployment time to be > able to > >>>> use logical identifiers- and if the *concrete *security advantages > >>>> don't apply to the their case, people will simply not comply. > >>>> > >>>> In summary: creating two different parameters in two different > >>>> documents is better than ignoring he logical identifier case > altogether, > >>>> however I think that not acknowledging the logical id case > >>>> in oauth-resource-indicators is going to create confusion and > ultimately > >>>> not be as useful to the developer community as it could be. > >>>> > >>>> > >>>> > >>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > >>>> > >>>>> +1 to Mike and John?s comments. > >>>>> > >>>>> Phil > >>>>> > >>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < > >>>>> Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote: > >>>>> > >>>>> I also agree that ?resource? should be a specific network-addressable > >>>>> URL whereas a separate audience parameter (like ?aud? in JWTs) can > refer to > >>>>> one or more logical resources. They are different, if related, > things. > >>>>> > >>>>> > >>>>> > >>>>> Note that the ACE WG is proposing to register a logical audience > >>>>> parameter ?req_aud? in > >>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly > >>>>> based on feedback from OAuth WG members. This is a general OAuth > >>>>> parameter, which any OAuth deployment will be able to use. > >>>>> > >>>>> > >>>>> > >>>>> I therefore believe that no changes are needed to > >>>>> draft-ietf-oauth-resource-indicators, as the logical audience work is > >>>>> already happening in another draft. > >>>>> > >>>>> > >>>>> > >>>>> -- Mike > >>>>> > >>>>> > >>>>> > >>>>> *From:* OAuth *On Behalf Of * John Bradley > >>>>> *Sent:* Saturday, January 19, 2019 9:01 AM > >>>>> *To:* Brian Campbell > >>>>> *Cc:* Vittorio Bertocci ; IETF > >>>>> oauth WG > >>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for > >>>>> draft-ietf-oauth-resource-indicators-01 > >>>>> > >>>>> > >>>>> > >>>>> We need to decide if we want to make a change. > >>>>> > >>>>> > >>>>> > >>>>> For security we are location centric. > >>>>> > >>>>> > >>>>> > >>>>> I prefer to keep resource location separate from logical audience > that > >>>>> can be a scope or other parameter. > >>>>> > >>>>> > >>>>> > >>>>> If becomes harder for people to use the parameter correctly if we are > >>>>> too flexible. > >>>>> > >>>>> > >>>>> > >>>>> I would rather have a separate logical audience parameter if we think > >>>>> we want one. > >>>>> > >>>>> > >>>>> > >>>>> John B. > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < > >>>>> bcampbell@pingidentity.com wrote: > >>>>> > >>>>> No apology needed, Rifaat. And I apologize if what I said came off > the > >>>>> wrong way. I was just trying to make light of the situation.. And I > agree > >>>>> that we should not be hamstrung by the process and there are times > when it > >>>>> makes sense to be flexible with things. > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < > >>>>> rifaat.ietf@gmail.com> wrote: > >>>>> > >>>>> Sorry Brian, I was not clear with my statement. > >>>>> > >>>>> I meant to say that we should not allow the process to prevent the WG > >>>>> from producing a quality document without issues, assuming there is > an > >>>>> issue in the first place. > >>>>> > >>>>> Ideally we want to get these identified during the WGLC, but things > >>>>> happen and sometimes the WG misses something. > >>>>> > >>>>> > >>>>> > >>>>> I hear you and agree that this make things difficult for authors. We > >>>>> will make sure that this does not become the norm, and we will try > to stick > >>>>> to the process as much as possible. > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Rifaat > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < > >>>>> bcampbell@pingidentity.com> wrote: > >>>>> > >>>>> Thanks Rifaat. Process is as process does, right? I do kinda want to > >>>>> grumble about WGCL having passed already but that's mostly because > replying > >>>>> to these kinds of threads is hard for me and I'll just get over it... > >>>>> > >>>>> > >>>>> > >>>>> As far as I understand things, the security concerns come into play > >>>>> when the client is being told the by the resource how to identity the > >>>>> resource like is described in > >>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and > using > >>>>> the actual location in that context ,along with some other checks > >>>>> prescribed in that draft, prevents the kind of issues John described > >>>>> earlier in the thread. > >>>>> > >>>>> In cases where the client knows the resource a priori or out-of-band > >>>>> or configured or whatever, I don't think the same security concerns > arise. > >>>>> And using such a known value, be it an actual location or logical > >>>>> representation, would be okay. > >>>>> > >>>>> The resource-indicators draft is admittedly somewhat location-centric > >>>>> in how it talks about the value of the 'resource' parameter. But > ultimately > >>>>> it defines it as an absolute URI that indicates the location of the > target > >>>>> service or resource where access is being requested. A location can > be > >>>>> varying shades of abstract and I'd say that using a URI as 'resource' > >>>>> parameter value that's a logical identifier that points to some > resource is > >>>>> well within the bounds of the draft. > >>>>> > >>>>> > >>>>> > >>>>> So maybe the draft is okay as is? > >>>>> > >>>>> > >>>>> > >>>>> Or perhaps that's too much to be left as an exerciser to the reader? > >>>>> And some text should be added and/or adjusted so the > resource-indicators > >>>>> draft would be a little more open/clear about the parameter value > >>>>> potentially being more of a logical or abstract identifier and not > >>>>> necessarily a network addressable URL? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < > >>>>> rifaat.ietf@gmail.com> wrote: > >>>>> > >>>>> I wouldn't worry too much about the process. > >>>>> > >>>>> If it makes sense to update the document, then feel free to do that. > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Rifaat > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley > >>>>> wrote: > >>>>> > >>>>> Yes the logical resource can be provided by "scope" > >>>>> > >>>>> > >>>>> > >>>>> Some implementations like Ping and Auth0 have been adding another > >>>>> parameter "aud" to identify the logical resource and then using > scopes to > >>>>> define permissions to the resource. > >>>>> > >>>>> > >>>>> > >>>>> Fortunately, we are using a different parameter name so not stepping > >>>>> on that.. > >>>>> > >>>>> > >>>>> > >>>>> We could go back and try to add text explaining the difference, but > we > >>>>> are quite late in the process. > >>>>> > >>>>> > >>>>> > >>>>> I agree that a logical resource parameter may be helpful, but perhaps > >>>>> it should be a separate draft. > >>>>> > >>>>> > >>>>> > >>>>> John B. > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > >>>>> richanna@amazon.com> wrote: > >>>>> > >>>>> Doesn?t the ?scope? parameter already provide a means of specifying a > >>>>> logical identifier? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Annabelle Richard Backman > >>>>> > >>>>> AWS Identity > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> *From: *OAuth on behalf of Vittorio > Bertocci > >>>>> > > >>>>> *Date: *Friday, January 18, 2019 at 5:47 AM > >>>>> *To: *John Bradley > >>>>> *Cc: *IETF oauth WG > >>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for > >>>>> draft-ietf-oauth-resource-indicators-01 > >>>>> > >>>>> > >>>>> > >>>>> Thanks John for the background. > >>>>> > >>>>> I agree that from the client validation PoV, having an identifier > >>>>> corresponding to a location makes things more solid. > >>>>> > >>>>> That said: the use of logical identifiers is widespread, as it has > >>>>> significant practical advantages (think of services that assign > generated > >>>>> hosting URLs only at deployment time, or services that are somehow > grouped > >>>>> under the same logical audience across > regions/environment/deployments). > >>>>> People won't stop using logical identifiers, because they often have > no > >>>>> alternative (generating new audiences on the fly at the AS every > time you > >>>>> do a deployment and get assigned a new URL can be unfeasible). > Leaving a > >>>>> widely used approach as exercise to the reader seems a disservice to > the > >>>>> community, given that this might lead to vendors (for example > Microsoft and > >>>>> Auth0) keeping their own proprietary parameters, or developers > misusing the > >>>>> ones in place; would make it hard for SDK developers to provide > libraries > >>>>> that work out of the box with different ASes; and so on. > >>>>> > >>>>> Would it be feasible to add such parameter directly in this spec? > That > >>>>> would eliminate the interop issues, and also gives us a chance to > fully > >>>>> warn people about the security shortcomings of choosing that > approach. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley > >>>>> wrote: > >>>>> > >>>>> We have discussed this. > >>>>> > >>>>> Audiences can certainly be logical identifiers. > >>>>> > >>>>> This however is a more specific location. The AS is free to map the > >>>>> location into some abstract audience in the AT. > >>>>> > >>>>> From a security point of view once the client starts asking for > >>>>> logical resources it can be tricked into asking for the wrong one as > a bad > >>>>> resource can always lie about what logical resource it is. > >>>>> > >>>>> If we were to change it, how a client would validate it becomes > >>>>> challenging to impossible. > >>>>> > >>>>> The AS is free to do whatever mapping of locations to identifiers it > >>>>> needs for access tokens. > >>>>> > >>>>> Some implementations may want to keep additional parameters like > >>>>> logical audience, but that should be separate from resource. > >>>>> > >>>>> John B. > >>>>> > >>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > >>>>> > >>>>> Hi Vittorio, > >>>>> > >>>>> > >>>>> > >>>>> The text you quoted is copied form the abstract of the draft itself. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> *Authors,* > >>>>> > >>>>> > >>>>> > >>>>> Should the draft be updated to cover the logical identifier case? > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Rifaat > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci < > Vittorio@auth0.com> > >>>>> wrote: > >>>>> > >>>>> Hi Rifaat, > >>>>> > >>>>> one detail. The tech summary says > >>>>> > >>>>> > >>>>> > >>>>> An extension to the OAuth 2.0 Authorization Framework defining > request > >>>>> > >>>>> parameters that enable a client to explicitly signal to an > authorization server > >>>>> > >>>>> about the *location* of the protected resource(s) to which it is > requesting > >>>>> > >>>>> access. > >>>>> > >>>>> But at least in the Microsoft implementation, the resource identifier > >>>>> doesn't *have* to be a network addressable URL (and if it is, it > >>>>> doesn't strictly need to match the actual resource location). It can > be a > >>>>> logical identifier, tho using the actual resource location there has > >>>>> benefits (domain ownership check, prevention of token forwarding > etc). > >>>>> > >>>>> Same for Auth0, the audience parameter is a logical identifier rather > >>>>> than a location. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < > >>>>> rifaat.ietf@gmail.com> wrote: > >>>>> > >>>>> All, > >>>>> > >>>>> > >>>>> > >>>>> The following is the first shepherd write-up for > >>>>> the draft-ietf-oauth-resource-indicators-01 document. > >>>>> > >>>>> > >>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > >>>>> > >>>>> > >>>>> > >>>>> Please, take a look and let me know if I missed anything. > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Rifaat > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>>> OAuth mailing list > >>>>> > >>>>> OAuth@ietf.org > >>>>> > >>>>> https://www.ietf..org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >>>>> privileged material for the sole use of the intended recipient(s). > Any > >>>>> review, use, distribution or disclosure by others is strictly > prohibited. > >>>>> If you have received this communication in error, please notify the > sender > >>>>> immediately by e-mail and delete the message and any file > attachments from > >>>>> your computer. Thank you.* > >>>>> > >>>>> > >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >>>>> privileged material for the sole use of the intended recipient(s). > Any > >>>>> review, use, distribution or disclosure by others is strictly > prohibited.. > >>>>> If you have received this communication in error, please notify the > sender > >>>>> immediately by e-mail and delete the message and any file > attachments from > >>>>> your computer. Thank you.* > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >> *CONFIDENTIALITY NOTICE: This email may contain confidential and > >> privileged material for the sole use of the intended recipient(s). Any > >> review, use, distribution or disclosure by others is strictly > prohibited.. > >> If you have received this communication in error, please notify the > sender > >> immediately by e-mail and delete the message and any file attachments > from > >> your computer. Thank > you.*_______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190121/46482262/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 42 > ************************************** > --000000000000321f7705803dcc82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 21, 2019, 4= :39 PM <oauth-request@ietf.or= g> wrote:
Send OAuth mailing= list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01 (Vittorio Bert= occi)


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

Message: 1
Date: Mon, 21 Jan 2019 16:38:47 -0800
From: Vittorio Bertocci <Vittorio@auth0.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>, =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-resource-indicators-01
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAO_FVe4+X0uZVDATcZSSGhzcv=3DmyTbejutD7Pp= XdNGhVBgnjUA@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi Rifaat,
absolutely. Brian and myself already started working on some language,
however this week he is in vacation hence it might take few days before we<= br> come back to the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
wrote:

> Brian, Vittorio,
>
> To move this discussion forward, can you guys suggest some text to mak= e
> the logical identifier usage clearer?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D
> 40pingidentity.com@dmarc.ietf.org> wrote:
>
>> As I suggested before, I do think that's within the bounds of = the draft's
>> definition of 'resource' as a URI. And that perhaps all th= at's needed is
>> some minor adjustment and/or augmentation of some text to make it = more
>> clear.
>>
>> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com>
>> wrote:
>>
>>> [sent to John only by mistake, resending to the ML]
>>>
>>> In Azure AD v1 & ADFS, that's resource. It could be us= ed for both
>>> network and logical ids, with the concrete usage in the wild I= described
>>> earlier.
>>> In Azure AD v2, the resource as explicit parameter (network, l= ogic or
>>> otherwise) is gone and is expressed as part of the scope strin= g of all the
>>> scopes requested for a given resource- but it still exist in p= ractice tho
>>> as it still end up in the resulting aud of the issued token. >>> This is 9 months old info hence
>>>
>>> On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote: >>>
>>>> What is the parameter that Microsoft is using?
>>>> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
>>>>
>>>> First of all, it wasn't my intent to disrupt the estab= lished process.
>>>> In my former position I wasn't monitoring those discus= sions hence I didn't
>>>> have a chance to offer feedback. When I saw something that= gave me the
>>>> impression might lead to issues, and given that I worked w= ith actual
>>>> deployments and developers using a similar parameter for a= long time, I
>>>> thought prudent to bring this up. I really appreciate Rifa= at's stance on
>>>> this. End of preamble.
>>>>
>>>> Ultimately my goal is for developers to have guidance on h= ow to work
>>>> with the concept of logical resource in a standard complia= nt way, hence it
>>>> doesn't strictly matter whether the definition of the = corresponding
>>>> parameter lives in oauth-resource-indicators or elsewhere.=
>>>> That said. Reading through the draft, it would appear that= most of the
>>>> reasons for which the spec was created apply to both the n= etwork
>>>> addressable and the logical resource types: knowing what k= eys to use to
>>>> encrypt the token, constrain access tokens to the intended= audience,
>>>> avoiding overloading scopes with resource indicating parts= ... those all
>>>> apply to network addressable and logic identifiers alike. = And both
>>>> parameters are expected to result in audience restricted t= okens. It seems
>>>> the only difference comes at token usage time, with the ne= twork addressable
>>>> case giving more guarantees that the token will go to its = intended
>>>> recipient, but the request and audience restriction syntax= seems to be
>>>> exactly the same.
>>>> On top of this: in the 99.999% of the scenarios I encounte= red in the
>>>> wild in the last 5 years of using the resource parameter i= n the MS
>>>> ecosystem, the resource identifier was known at design tim= e: the developer
>>>> discovered it out of band and placed it in the app config = at deployment
>>>> time. Those aren't fringe cases I occasionally encount= ered: the resource
>>>> parameter in Azure AD v1 and ADFS was mandatory, hence lit= erally every
>>>> solution i saw or touched used it. As Brian suggested, thi= s is a scenario
>>>> where the security advantages of the network addressable c= ase aren't as
>>>> pronounced as in the case in which the client discovers th= e resource
>>>> identifier at runtime. This isn't just because there i= s no specification
>>>> suggesting location should be explicitly indicated, it'= ;s because there are
>>>> many practical advantages at development and deployment ti= me to be able to
>>>> use logical identifiers- and if the *concrete *security ad= vantages
>>>> don't apply to the their case, people will simply not = comply.
>>>>
>>>> In summary: creating two different parameters in two diffe= rent
>>>> documents is better than ignoring he logical identifier ca= se altogether,
>>>> however I think that not acknowledging the logical id case=
>>>> in oauth-resource-indicators is going to create confusion = and ultimately
>>>> not be as useful to the developer community as it could be= .
>>>>
>>>>
>>>>
>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wr= ote:
>>>>
>>>>> +1 to Mike and John?s comments.
>>>>>
>>>>> Phil
>>>>>
>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones <
>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=
>>>>>
>>>>> I also agree that ?resource? should be a specific netw= ork-addressable
>>>>> URL whereas a separate audience parameter (like ?aud? = in JWTs) can refer to
>>>>> one or more logical resources.=C2=A0 They are differen= t, if related, things.
>>>>>
>>>>>
>>>>>
>>>>> Note that the ACE WG is proposing to register a logica= l audience
>>>>> parameter ?req_aud? in
>>>>> https://tools.ietf.or= g/html/draft-ietf-ace-oauth-params-01 - partly
>>>>> based on feedback from OAuth WG members.=C2=A0 This is= a general OAuth
>>>>> parameter, which any OAuth deployment will be able to = use.
>>>>>
>>>>>
>>>>>
>>>>> I therefore believe that no changes are needed to
>>>>> draft-ietf-oauth-resource-indicators, as the logical a= udience work is
>>>>> already happening in another draft.
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- Mike
>>>>>
>>>>>
>>>>>
>>>>> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of * John= Bradley
>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>>> *To:* Brian Campbell <bcampbell@pingidentity.com>
>>>>> *Cc:* Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org= >; IETF
>>>>> oauth WG <oauth@ietf.org>
>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>
>>>>>
>>>>>
>>>>> We need to decide if we want to make a change.
>>>>>
>>>>>
>>>>>
>>>>> For security we are location centric.
>>>>>
>>>>>
>>>>>
>>>>> I prefer to keep resource location separate from logic= al audience that
>>>>> can be a scope or other parameter.
>>>>>
>>>>>
>>>>>
>>>>> If becomes harder for people to use the parameter corr= ectly if we are
>>>>> too flexible.
>>>>>
>>>>>
>>>>>
>>>>> I would rather have a separate logical audience parame= ter if we think
>>>>> we want one.
>>>>>
>>>>>
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <
>>>>> bcampbell@pingidentity.com wrote:
>>>>>
>>>>> No apology needed, Rifaat. And I apologize if what I s= aid came off the
>>>>> wrong way. I was just trying to make light of the situ= ation.. And I agree
>>>>> that we should not be hamstrung by the process and the= re are times when it
>>>>> makes sense to be flexible with things.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <= ;
>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>
>>>>> Sorry Brian, I was not clear with my statement.
>>>>>
>>>>> I meant to say that we should not allow the process to= prevent the WG
>>>>> from producing a quality document without issues, assu= ming there is an
>>>>> issue in the first place.
>>>>>
>>>>> Ideally we want to get these identified during the WGL= C, but things
>>>>> happen and sometimes the WG misses something.
>>>>>
>>>>>
>>>>>
>>>>> I hear you and agree that this make things difficult f= or authors. We
>>>>> will make sure that this does not become the norm, and= we will try to stick
>>>>> to the process as much as possible.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>=C2=A0 Rifaat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote:
>>>>>
>>>>> Thanks Rifaat. Process is as process does, right? I do= kinda want to
>>>>> grumble about WGCL having passed already but that'= s mostly because replying
>>>>> to these kinds of threads is hard for me and I'll = just get over it...
>>>>>
>>>>>
>>>>>
>>>>> As far as I understand things, the security concerns c= ome into play
>>>>> when the client is being told the by the resource how = to identity the
>>>>> resource like is described in
>>>>> https://tools.ietf.o= rg/html/draft-ietf-oauth-distributed-01 and using
>>>>> the actual location in that context ,along with some o= ther checks
>>>>> prescribed in that draft, prevents the kind of issues = John described
>>>>> earlier in the thread.
>>>>>
>>>>> In cases where the client knows the resource a priori = or out-of-band
>>>>> or configured or whatever, I don't think the same = security concerns arise.
>>>>> And using such a known value, be it an actual location= or logical
>>>>> representation, would be okay.
>>>>>
>>>>> The resource-indicators draft is admittedly somewhat l= ocation-centric
>>>>> in how it talks about the value of the 'resource&#= 39; parameter. But ultimately
>>>>> it defines it as an absolute URI that indicates the lo= cation of the target
>>>>> service or resource where access is being requested. A= location can be
>>>>> varying shades of abstract and I'd say that using = a URI as 'resource'
>>>>> parameter value that's a logical identifier that p= oints to some resource is
>>>>> well within the bounds of the draft.
>>>>>
>>>>>
>>>>>
>>>>> So maybe the draft is okay as is?
>>>>>
>>>>>
>>>>>
>>>>> Or perhaps that's too much to be left as an exerci= ser to the reader?
>>>>> And some text should be added and/or adjusted so the r= esource-indicators
>>>>> draft would be a little more open/clear about the para= meter value
>>>>> potentially being more of a logical or abstract identi= fier and not
>>>>> necessarily a network addressable URL?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <= ;
>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>
>>>>> I wouldn't worry too much about the process.
>>>>>
>>>>> If it makes sense to update the document, then feel fr= ee to do that.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>=C2=A0 Rifaat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com>=
>>>>> wrote:
>>>>>
>>>>> Yes the logical resource can be provided by "scop= e"
>>>>>
>>>>>
>>>>>
>>>>> Some implementations like Ping and Auth0 have been add= ing another
>>>>> parameter "aud" to identify the logical reso= urce and then using scopes to
>>>>> define permissions to the resource.
>>>>>
>>>>>
>>>>>
>>>>> Fortunately, we are using a different parameter name s= o not stepping
>>>>> on that..
>>>>>
>>>>>
>>>>>
>>>>> We could go back and try to add text explaining the di= fference, but we
>>>>> are quite late in the process.
>>>>>
>>>>>
>>>>>
>>>>> I agree that a logical resource parameter may be helpf= ul, but perhaps
>>>>> it should be a separate draft.
>>>>>
>>>>>
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annab= elle <
>>>>> richanna@amazon.com> wrote:
>>>>>
>>>>> Doesn?t the ?scope? parameter already provide a means = of specifying a
>>>>> logical identifier?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Annabelle Richard Backman
>>>>>
>>>>> AWS Identity
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From: *OAuth <oauth-bounces@ietf.org> on behalf of Vittori= o Bertocci
>>>>> <Vittorio=3D40auth0.com@dmarc.ietf.org <40auth0..com@dmarc.ietf.o= rg>>
>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM
>>>>> *To: *John Bradley <ve7jtb@ve7jtb.com>
>>>>> *Cc: *IETF oauth WG <oauth@ietf.org>
>>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>
>>>>>
>>>>>
>>>>> Thanks John for the background.
>>>>>
>>>>> I agree that from the client validation PoV, having an= identifier
>>>>> corresponding to a location makes things more solid. >>>>>
>>>>> That said: the use of logical identifiers is widesprea= d, as it has
>>>>> significant practical advantages (think of services th= at assign generated
>>>>> hosting URLs only at deployment time, or services that= are somehow grouped
>>>>> under the same logical audience across regions/environ= ment/deployments).
>>>>> People won't stop using logical identifiers, becau= se they often have no
>>>>> alternative (generating new audiences on the fly at th= e AS every time you
>>>>> do a deployment and get assigned a new URL can be unfe= asible). Leaving a
>>>>> widely used approach as exercise to the reader seems a= disservice to the
>>>>> community, given that this might lead to vendors (for = example Microsoft and
>>>>> Auth0) keeping their own proprietary parameters, or de= velopers misusing the
>>>>> ones in place; would make it hard for SDK developers t= o provide libraries
>>>>> that work out of the box with different ASes; and so o= n.
>>>>>
>>>>> Would it be feasible to add such parameter directly in= this spec? That
>>>>> would eliminate the interop issues, and also gives us = a chance to fully
>>>>> warn people about the security shortcomings of choosin= g that approach.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com>=
>>>>> wrote:
>>>>>
>>>>> We have discussed this.
>>>>>
>>>>> Audiences can certainly be logical identifiers.
>>>>>
>>>>> This however is a more specific location.=C2=A0 The AS= is free to map the
>>>>> location into some abstract audience in the AT.
>>>>>
>>>>> From a security point of view once the client starts a= sking for
>>>>> logical resources it can be tricked into asking for th= e wrong one as a bad
>>>>> resource can always lie about what logical resource it= is.
>>>>>
>>>>> If we were to change it, how a client would validate i= t becomes
>>>>> challenging to impossible.
>>>>>
>>>>> The AS is free to do whatever mapping of locations to = identifiers it
>>>>> needs for access tokens.
>>>>>
>>>>> Some implementations may want to keep additional param= eters like
>>>>> logical audience, but that should be separate from res= ource.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
>>>>>
>>>>> Hi Vittorio,
>>>>>
>>>>>
>>>>>
>>>>> The text you quoted is copied form the abstract of the= draft itself.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Authors,*
>>>>>
>>>>>
>>>>>
>>>>> Should the draft be updated to cover the logical ident= ifier case?
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>=C2=A0 Rifaat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <= Vittorio@auth0.com<= /a>>
>>>>> wrote:
>>>>>
>>>>> Hi Rifaat,
>>>>>
>>>>> one detail. The tech summary says
>>>>>
>>>>>
>>>>>
>>>>> An extension to the OAuth 2.0 Authorization Framework = defining request
>>>>>
>>>>> parameters that enable a client to explicitly signal t= o an authorization server
>>>>>
>>>>> about the *location* of the protected resource(s) to w= hich it is requesting
>>>>>
>>>>> access.
>>>>>
>>>>> But at least in the Microsoft implementation, the reso= urce identifier
>>>>> doesn't *have* to be a network addressable URL (an= d if it is, it
>>>>> doesn't strictly need to match the actual resource= location). It can be a
>>>>> logical identifier, tho using the actual resource loca= tion there has
>>>>> benefits (domain ownership check, prevention of token = forwarding etc).
>>>>>
>>>>> Same for Auth0, the audience parameter is a logical id= entifier rather
>>>>> than a location.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <= ;
>>>>> rifaat.ietf@gmail.com> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>>
>>>>>
>>>>> The following is the first shepherd write-up for
>>>>> the draft-ietf-oauth-resource-indicators-01 document.<= br> >>>>>
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicator= s/shepherdwriteup/
>>>>>
>>>>>
>>>>>
>>>>> Please, take a look and let me know if I missed anythi= ng.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>=C2=A0 Rifaat
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> OAuth mailing list
>>>>>
>>>>> OA= uth@ietf.org
>>>>>
>>>>> https://www.ietf..org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/oauth
>>>>>
>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confid= ential and
>>>>> privileged material for the sole use of the intended r= ecipient(s). Any
>>>>> review, use, distribution or disclosure by others is s= trictly prohibited.
>>>>> If you have received this communication in error, plea= se notify the sender
>>>>> immediately by e-mail and delete the message and any f= ile attachments from
>>>>> your computer. Thank you.*
>>>>>
>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confid= ential and
>>>>> privileged material for the sole use of the intended r= ecipient(s). Any
>>>>> review, use, distribution or disclosure by others is s= trictly prohibited..
>>>>> If you have received this communication in error, plea= se notify the sender
>>>>> immediately by e-mail and delete the message and any f= ile attachments from
>>>>> your computer. Thank you.*
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/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 proh= ibited..
>> If you have received this communication in error, please notify th= e sender
>> immediately by e-mail and delete the message and any file attachme= nts from
>> your computer. Thank you.*________________________________________= _______
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190121/464822= 62/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 123, Issue 42
**************************************
--000000000000321f7705803dcc82-- From nobody Thu Jan 24 17:17:51 2019 Return-Path: <4all7the5time@gmail.com> X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D73128D09 for ; Thu, 24 Jan 2019 17:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0ga6fMde0yub for ; Thu, 24 Jan 2019 17:17:45 -0800 (PST) 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 DE10C12950A for ; Thu, 24 Jan 2019 17:17:44 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id l10so5730278lfh.9 for ; Thu, 24 Jan 2019 17:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gClw68f4c69X8HVHUC9UkEYqJwu3TDIm8KUy1Hh83xA=; b=aPW8IQmzR0OgtD539BbX8EZRa2+tORjrGiTY8Etl8Tc8WluIKFv2gObyrbCl7xthRT 0EFKg5Q22Tk//VU03TaICGJRWC/wjVNbPQwA5jtY1FafS5OdejkefJtbvHLMiF6/yOCy fDevjG94fVB1JB+F26miSt0cj+xTccaS/I+w9tA8+Vrm21+8XDpLIq5Pvead3M4xhwG8 6wY6DtgM5IjoSH1CRnBn0p63MSXMJ7zpd4AevaHvMvrxlIyrLwpBn0IgYYZKF3TeOatv RH1pJsuDYceKA+jK6RqNZgsoykLI/PFvaHDBn4HZtzlrq87irzVtQpUgsA0m6WA4uP0g uCgw== 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=gClw68f4c69X8HVHUC9UkEYqJwu3TDIm8KUy1Hh83xA=; b=XQeTzg68t9RLLo6aVdQSS5HBxlGW7uLdWEFR7COoReOUoA9Hakh8TKtE8earwKIMmN u0XQr72GpFC0OwScrH8jzDeSO6RjzMwNMthgM+5kMug/ALl7pD67GLWkx01rG3ebIDLg Ot9Zn4X7kVNdRChO35mztAf6dpyIGzc3xpn6NyOkdKlpiIs9HXpQQlQ64NmoPZeKpwQB 6aqOM6qja8eblBD1hTM0iKy3yHkl8ARdOUT7ymxcqtpPFM/q7V7cEumfZTMH0AP/vUcv cxEu7p/YHenaZCOn9SAmJiOGwM2BkyHPxfxPO/xf7NQL92453+JrU6twrzUcEVBK2QH8 7VLw== X-Gm-Message-State: AJcUukeGr5j1Q6r26klle4wJcVMekgSPc7CMFMEfPwEi2PXZVnkQN/cd vtjiCKX5r2lXR7je7AHo8jOVAQ1w0UhuduFzl5dJ5Q== X-Google-Smtp-Source: ALg8bN6QhKvzZMQ5n0BfXYELBfo8vjrXQR+V8FkOE6ORptsfgZenYckzsrwb34kFkIvJV3V39n8AjUWiyMkKqGpx/tI= X-Received: by 2002:a19:a9d2:: with SMTP id s201mr1586183lfe.154.1548379062562; Thu, 24 Jan 2019 17:17:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lao Vang <4all7the5time@gmail.com> Date: Thu, 24 Jan 2019 17:17:25 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000000750705803e1896" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 56 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 01:17:50 -0000 --00000000000000750705803e1896 Content-Type: text/plain; charset="UTF-8" 445-67 claim money Direct deposit: Acct: checking Routing#: 031101169 Acct#: 8847548304001 Or send to my pay.google acct: 209hns@gmail.com On Thu, Jan 24, 2019, 4:54 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 123, Issue 44 (Lao Vang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Jan 2019 16:51:52 -0800 > From: Lao Vang <4all7the5time@gmail.com> > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44 > Message-ID: > 3KtoeDW5sr-FoPWXRq62_HFUhS_XQN+tf_14AQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Reply all > > > On Tue, Jan 22, 2019, 10:20 AM wrote: > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-request@ietf.org > > > > You can reach the person managing the list at > > oauth-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 (Mike Jones) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 22 Jan 2019 18:19:31 +0000 > > From: Mike Jones > > To: Rifaat Shekh-Yusef , Vittorio Bertocci > > > > Cc: Brian Campbell , IETF > > oauth WG > > Subject: Re: [OAUTH-WG] Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 > > Message-ID: > > < > > > MW2PR00MB030099E717A31D46BCAA4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.com > > > > > > > Content-Type: text/plain; charset="utf-8" > > > > I think that a non-normative reference to ?req_aud? in > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be > > added to the resource indicators doc to inform developers that req_aud is > > also available to then, and then we should call it a day. > > > > -- Mike > > > > From: OAuth On Behalf Of Rifaat Shekh-Yusef > > Sent: Monday, January 21, 2019 5:36 PM > > To: Vittorio Bertocci > > Cc: Brian Campbell ; IETF > > oauth WG > > Subject: Re: [OAUTH-WG] Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 > > > > Thank you guys! > > > > > > On Monday, January 21, 2019, Vittorio Bertocci > Vittorio@auth0.com>> wrote: > > Hi Rifaat, > > absolutely. Brian and myself already started working on some language, > > however this week he is in vacation hence it might take few days before > we > > come back to the list with something. > > Cheers, > > V. > > > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com > > > wrote: > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org 40pingidentity.com@dmarc.ietf.org>> > > wrote: > > As I suggested before, I do think that's within the bounds of the draft's > > definition of 'resource' as a URI. And that perhaps all that's needed is > > some minor adjustment and/or augmentation of some text to make it more > > clear. > > > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > > wrote: > > [sent to John only by mistake, resending to the ML] > > > > In Azure AD v1 & ADFS, that's resource. It could be used for both network > > and logical ids, with the concrete usage in the wild I described earlier. > > In Azure AD v2, the resource as explicit parameter (network, logic or > > otherwise) is gone and is expressed as part of the scope string of all > the > > scopes requested for a given resource- but it still exist in practice tho > > as it still end up in the resulting aud of the issued token. > > This is 9 months old info hence > > > > On Sun, Jan 20, 2019 at 17:58 John Bradley > ve7jtb@ve7jtb.com>> wrote: > > > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > > my former position I wasn't monitoring those discussions hence I didn't > > have a chance to offer feedback. When I saw something that gave me the > > impression might lead to issues, and given that I worked with actual > > deployments and developers using a similar parameter for a long time, I > > thought prudent to bring this up. I really appreciate Rifaat's stance on > > this. End of preamble. > > > > Ultimately my goal is for developers to have guidance on how to work with > > the concept of logical resource in a standard compliant way, hence it > > doesn't strictly matter whether the definition of the corresponding > > parameter lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would appear that most of the > > reasons for which the spec was created apply to both the network > > addressable and the logical resource types: knowing what keys to use to > > encrypt the token, constrain access tokens to the intended audience, > > avoiding overloading scopes with resource indicating parts... those all > > apply to network addressable and logic identifiers alike. And both > > parameters are expected to result in audience restricted tokens. It seems > > the only difference comes at token usage time, with the network > addressable > > case giving more guarantees that the token will go to its intended > > recipient, but the request and audience restriction syntax seems to be > > exactly the same. > > On top of this: in the 99.999% of the scenarios I encountered in the wild > > in the last 5 years of using the resource parameter in the MS ecosystem, > > the resource identifier was known at design time: the developer > discovered > > it out of band and placed it in the app config at deployment time. Those > > aren't fringe cases I occasionally encountered: the resource parameter in > > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw > or > > touched used it. As Brian suggested, this is a scenario where the > security > > advantages of the network addressable case aren't as pronounced as in the > > case in which the client discovers the resource identifier at runtime. > This > > isn't just because there is no specification suggesting location should > be > > explicitly indicated, it's because there are many practical advantages at > > development and deployment time to be able to use logical identifiers- > and > > if the concrete security advantages don't apply to the their case, people > > will simply not comply. > > > > In summary: creating two different parameters in two different documents > > is better than ignoring he logical identifier case altogether, however I > > think that not acknowledging the logical id case in > > oauth-resource-indicators is going to create confusion and ultimately not > > be as useful to the developer community as it could be. > > > > > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt > phil.hunt@oracle.com>> wrote: > > +1 to Mike and John?s comments. > > Phil > > > > On Jan 19, 2019, at 12:34 PM, Mike Jones > 40microsoft.com@dmarc.ietf.org > 40microsoft.com@dmarc.ietf.org>> wrote: > > I also agree that ?resource? should be a specific network-addressable URL > > whereas a separate audience parameter (like ?aud? in JWTs) can refer to > one > > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience > parameter > > ?req_aud? in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - > > partly based on feedback from OAuth WG members. This is a general OAuth > > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > > draft-ietf-oauth-resource-indicators, as the logical audience work is > > already happening in another draft. > > > > -- Mike > > > > From: OAuth > On > > Behalf Of John Bradley > > Sent: Saturday, January 19, 2019 9:01 AM > > To: Brian Campbell > bcampbell@pingidentity.com>> > > Cc: Vittorio Bertocci Vittorio > > =40auth0.com@dmarc.ietf.org>>; IETF oauth WG > oauth@ietf.org>> > > Subject: Re: [OAUTH-WG] Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that > can > > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > > flexible. > > > > I would rather have a separate logical audience parameter if we think we > > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < > bcampbell@pingidentity.com > > wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > > wrong way. I was just trying to make light of the situation.. And I agree > > that we should not be hamstrung by the process and there are times when > it > > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com > > > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG > from > > producing a quality document without issues, assuming there is an issue > in > > the first place. > > Ideally we want to get these identified during the WGLC, but things > happen > > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > > make sure that this does not become the norm, and we will try to stick to > > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < > bcampbell@pingidentity.com > > > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > > grumble about WGCL having passed already but that's mostly because > replying > > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > > the client is being told the by the resource how to identity the resource > > like is described in > > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using > the > > actual location in that context ,along with some other checks prescribed > in > > that draft, prevents the kind of issues John described earlier in the > > thread. > > > > In cases where the client knows the resource a priori or out-of-band or > > configured or whatever, I don't think the same security concerns arise. > And > > using such a known value, be it an actual location or logical > > representation, would be okay. > > > > The resource-indicators draft is admittedly somewhat location-centric in > > how it talks about the value of the 'resource' parameter. But ultimately > it > > defines it as an absolute URI that indicates the location of the target > > service or resource where access is being requested. A location can be > > varying shades of abstract and I'd say that using a URI as 'resource' > > parameter value that's a logical identifier that points to some resource > is > > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > > some text should be added and/or adjusted so the resource-indicators > draft > > would be a little more open/clear about the parameter value potentially > > being more of a logical or abstract identifier and not necessarily a > > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com > > > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley > ve7jtb@ve7jtb.com>> wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > > parameter "aud" to identify the logical resource and then using scopes to > > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > > that.. > > > > We could go back and try to add text explaining the difference, but we > are > > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > > richanna@amazon.com> wrote: > > Doesn?t the ?scope? parameter already provide a means of specifying a > > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > From: OAuth > on > > behalf of Vittorio Bertocci > 40auth0..com@dmarc.ietf.org>> > > Date: Friday, January 18, 2019 at 5:47 AM > > To: John Bradley > > > Cc: IETF oauth WG > > > Subject: Re: [OAUTH-WG] Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > > significant practical advantages (think of services that assign generated > > hosting URLs only at deployment time, or services that are somehow > grouped > > under the same logical audience across regions/environment/deployments). > > People won't stop using logical identifiers, because they often have no > > alternative (generating new audiences on the fly at the AS every time you > > do a deployment and get assigned a new URL can be unfeasible). Leaving a > > widely used approach as exercise to the reader seems a disservice to the > > community, given that this might lead to vendors (for example Microsoft > and > > Auth0) keeping their own proprietary parameters, or developers misusing > the > > ones in place; would make it hard for SDK developers to provide libraries > > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > > would eliminate the interop issues, and also gives us a chance to fully > > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley > ve7jtb@ve7jtb.com>> wrote: > > > > We have discussed this. > > > > Audiences can certainly be logical identifiers. > > > > This however is a more specific location. The AS is free to map the > > location into some abstract audience in the AT. > > > > From a security point of view once the client starts asking for logical > > resources it can be tricked into asking for the wrong one as a bad > resource > > can always lie about what logical resource it is. > > > > If we were to change it, how a client would validate it becomes > > challenging to impossible. > > > > The AS is free to do whatever mapping of locations to identifiers it > needs > > for access tokens. > > > > Some implementations may want to keep additional parameters like logical > > audience, but that should be separate from resource. > > > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > Authors, > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > > > parameters that enable a client to explicitly signal to an authorization > > server > > > > about the location of the protected resource(s) to which it is requesting > > > > access. > > But at least in the Microsoft implementation, the resource identifier > > doesn't have to be a network addressable URL (and if it is, it doesn't > > strictly need to match the actual resource location). It can be a logical > > identifier, tho using the actual resource location there has benefits > > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather > than > > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com > > > wrote: > > All, > > > > The following is the first shepherd write-up for the > > draft-ietf-oauth-resource-indicators-01 document. > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf..org/mailman/listinfo/oauth< > > https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited.. If you > have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited... If you > have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > ------------------------------ > > > > End of OAuth Digest, Vol 123, Issue 44 > > ************************************** > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190124/50055095/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 56 > ************************************** > --00000000000000750705803e1896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 445-67 claim money=C2=A0

Direct deposit:
Acct:= checking

Routing#: 031101169
Acct#: 884= 7548304001

Or send to my pay.google acct:

<= a href=3D"mailto:209hns@gmail.com">209hns@gmail.com


<= div class=3D"gmail_quote">
On Thu, Jan 24, 2019, 4:54 PM &= lt;oauth-request@ietf.org>= wrote:
Send OAuth mailing list sub= missions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: OAuth Digest, Vol 123, Issue 44 (Lao Vang)


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

Message: 1
Date: Thu, 24 Jan 2019 16:51:52 -0800
From: Lao Vang <4all7the5time@gmail.com>
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAKPLo8+nqDA=3D3KtoeDW5sr= -FoPWXRq62_HFUhS_XQN+tf_14AQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Reply all


On Tue, Jan 22, 2019, 10:20 AM <oauth-request@ietf.org> wrote:

> Send OAuth mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.or= g/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>=C2=A0 =C2=A0 1. Re: Shepherd write-up for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-resource-indicators-01 (Mik= e Jones)
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Tue, 22 Jan 2019 18:19:31 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertocci
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Vittorio@auth0.com>
> Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;, IETF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth WG <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-resource-indicators-= 01
> Message-ID:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<
> MW2PR00MB030099E717A31D46BCAA= 4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.com
> >
>
> Content-Type: text/plain; charset=3D"utf-8"
>
> I think that a non-normative reference to=C2=A0 ?req_aud? in
> https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 should be
> added to the resource indicators doc to inform developers that req_aud= is
> also available to then, and then we should call it a day.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-- Mike
>
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
> Sent: Monday, January 21, 2019 5:36 PM
> To: Vittorio Bertocci <Vittorio@auth0.com>
> Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;; IETF
> oauth WG <oauth= @ietf.org>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> Thank you guys!
>
>
> On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com<mailto:
> Vittorio@auth0= .com>> wrote:
> Hi Rifaat,
> absolutely. Brian and myself already started working on some language,=
> however this week he is in vacation hence it might take few days befor= e we
> come back to the list with something.
> Cheers,
> V.
>
> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> Brian, Vittorio,
>
> To move this discussion forward, can you guys suggest some text to mak= e
> the logical identifier usage clearer?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D
> 40pingidentity.com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.= org>>
> wrote:
> As I suggested before, I do think that's within the bounds of the = draft's
> definition of 'resource' as a URI. And that perhaps all that&#= 39;s needed is
> some minor adjustment and/or augmentation of some text to make it more=
> clear.
>
> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com
> <mailto:Vit= torio@auth0.com>> wrote:
> [sent to John only by mistake, resending to the ML]
>
> In Azure AD v1 & ADFS, that's resource. It could be used for b= oth network
> and logical ids, with the concrete usage in the wild I described earli= er.
> In Azure AD v2, the resource as explicit parameter (network, logic or<= br> > otherwise) is gone and is expressed as part of the scope string of all= the
> scopes requested for a given resource- but it still exist in practice = tho
> as it still end up in the resulting aud of the issued token.
> This is 9 months old info hence
>
> On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
>
> What is the parameter that Microsoft is using?
> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
> First of all, it wasn't my intent to disrupt the established proce= ss. In
> my former position I wasn't monitoring those discussions hence I d= idn't
> have a chance to offer feedback. When I saw something that gave me the=
> impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, = I
> thought prudent to bring this up. I really appreciate Rifaat's sta= nce on
> this. End of preamble.
>
> Ultimately my goal is for developers to have guidance on how to work w= ith
> the concept of logical resource in a standard compliant way, hence it<= br> > doesn't strictly matter whether the definition of the correspondin= g
> parameter lives in oauth-resource-indicators or elsewhere.
> That said. Reading through the draft, it would appear that most of the=
> reasons for which the spec was created apply to both the network
> addressable and the logical resource types: knowing what keys to use t= o
> encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those al= l
> apply to network addressable and logic identifiers alike. And both
> parameters are expected to result in audience restricted tokens. It se= ems
> the only difference comes at token usage time, with the network addres= sable
> case giving more guarantees that the token will go to its intended
> recipient, but the request and audience restriction syntax seems to be=
> exactly the same.
> On top of this: in the 99.999% of the scenarios I encountered in the w= ild
> in the last 5 years of using the resource parameter in the MS ecosyste= m,
> the resource identifier was known at design time: the developer discov= ered
> it out of band and placed it in the app config at deployment time. Tho= se
> aren't fringe cases I occasionally encountered: the resource param= eter in
> Azure AD v1 and ADFS was mandatory, hence literally every solution i s= aw or
> touched used it. As Brian suggested, this is a scenario where the secu= rity
> advantages of the network addressable case aren't as pronounced as= in the
> case in which the client discovers the resource identifier at runtime.= This
> isn't just because there is no specification suggesting location s= hould be
> explicitly indicated, it's because there are many practical advant= ages at
> development and deployment time to be able to use logical identifiers-= and
> if the concrete security advantages don't apply to the their case,= people
> will simply not comply.
>
> In summary: creating two different parameters in two different documen= ts
> is better than ignoring he logical identifier case altogether, however= I
> think that not acknowledging the logical id case in
> oauth-resource-indicators is going to create confusion and ultimately = not
> be as useful to the developer community as it could be.
>
>
>
> On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<mailto:
> phil.hunt@or= acle.com>> wrote:
> +1 to Mike and John?s comments.
> Phil
>
> On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D
> 40= microsoft.com@dmarc.ietf.org<mailto:Michael.Jones=3D
> 40= microsoft.com@dmarc.ietf.org>> wrote:
> I also agree that ?resource? should be a specific network-addressable = URL
> whereas a separate audience parameter (like ?aud? in JWTs) can refer t= o one
> or more logical resources.=C2=A0 They are different, if related, thing= s.
>
> Note that the ACE WG is proposing to register a logical audience param= eter
> ?req_aud? in https://tools.ietf.org/h= tml/draft-ietf-ace-oauth-params-01 -
> partly based on feedback from OAuth WG members.=C2=A0 This is a genera= l OAuth
> parameter, which any OAuth deployment will be able to use.
>
> I therefore believe that no changes are needed to
> draft-ietf-oauth-resource-indicators, as the logical audience work is<= br> > already happening in another draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike >
> From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> On
> Behalf Of John Bradley
> Sent: Saturday, January 19, 2019 9:01 AM
> To: Brian Campbell <bcampbell@pingidentity.com<mailto:
> bcampb= ell@pingidentity.com>>
> Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mailto:Vittorio
> =3D40a= uth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org<mailto:
> oauth@ietf.org= >>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> We need to decide if we want to make a change.
>
> For security we are location centric.
>
> I prefer to keep resource location separate from logical audience that= can
> be a scope or other parameter.
>
> If becomes harder for people to use the parameter correctly if we are = too
> flexible.
>
> I would rather have a separate logical audience parameter if we think = we
> want one.
>
> John B.
>
> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com<= br> > <mailto:bcampbell@pingidentity.com> wrote:
> No apology needed, Rifaat. And I apologize if what I said came off the=
> wrong way. I was just trying to make light of the situation.. And I ag= ree
> that we should not be hamstrung by the process and there are times whe= n it
> makes sense to be flexible with things.
>
> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> Sorry Brian, I was not clear with my statement.
> I meant to say that we should not allow the process to prevent the WG = from
> producing a quality document without issues, assuming there is an issu= e in
> the first place.
> Ideally we want to get these identified during the WGLC, but things ha= ppen
> and sometimes the WG misses something.
>
> I hear you and agree that this make things difficult for authors. We w= ill
> make sure that this does not become the norm, and we will try to stick= to
> the process as much as possible.
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com=
> <mailto:bcampbell@pingidentity.com>> wrote:
> Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because= replying
> to these kinds of threads is hard for me and I'll just get over it= ...
>
> As far as I understand things, the security concerns come into play wh= en
> the client is being told the by the resource how to identity the resou= rce
> like is described in
> https://tools.ietf.org/html/draft-ie= tf-oauth-distributed-01 and using the
> actual location in that context ,along with some other checks prescrib= ed in
> that draft, prevents the kind of issues John described earlier in the<= br> > thread.
>
> In cases where the client knows the resource a priori or out-of-band o= r
> configured or whatever, I don't think the same security concerns a= rise. And
> using such a known value, be it an actual location or logical
> representation, would be okay.
>
> The resource-indicators draft is admittedly somewhat location-centric = in
> how it talks about the value of the 'resource' parameter. But = ultimately it
> defines it as an absolute URI that indicates the location of the targe= t
> service or resource where access is being requested. A location can be=
> varying shades of abstract and I'd say that using a URI as 're= source'
> parameter value that's a logical identifier that points to some re= source is
> well within the bounds of the draft.
>
> So maybe the draft is okay as is?
>
> Or perhaps that's too much to be left as an exerciser to the reade= r?=C2=A0 And
> some text should be added and/or adjusted so the resource-indicators d= raft
> would be a little more open/clear about the parameter value potentiall= y
> being more of a logical or abstract identifier and not necessarily a > network addressable URL?
>
>
>
> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> I wouldn't worry too much about the process.
> If it makes sense to update the document, then feel free to do that. >
> Regards,
>=C2=A0 Rifaat
>
>
> On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
> Yes the logical resource can be provided by "scope"
>
> Some implementations like Ping and Auth0 have been adding another
> parameter "aud" to identify the logical resource and then us= ing scopes to
> define permissions to the resource.
>
> Fortunately, we are using a different parameter name so not stepping o= n
> that..
>
> We could go back and try to add text explaining the difference, but we= are
> quite late in the process.
>
> I agree that a logical resource parameter may be helpful, but perhaps = it
> should be a separate draft.
>
> John B.
>
> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
> richanna@amaz= on.com<mailto:richanna@amazon.com>> wrote:
> Doesn?t the ?scope? parameter already provide a means of specifying a<= br> > logical identifier?
>
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> on
> behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mail= to:
> 40aut= h0..com@dmarc.ietf.org>>
> Date: Friday, January 18, 2019 at 5:47 AM
> To: John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
> Cc: IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> Thanks John for the background.
> I agree that from the client validation PoV, having an identifier
> corresponding to a location makes things more solid.
> That said: the use of logical identifiers is widespread, as it has
> significant practical advantages (think of services that assign genera= ted
> hosting URLs only at deployment time, or services that are somehow gro= uped
> under the same logical audience across regions/environment/deployments= ).
> People won't stop using logical identifiers, because they often ha= ve no
> alternative (generating new audiences on the fly at the AS every time = you
> do a deployment and get assigned a new URL can be unfeasible). Leaving= a
> widely used approach as exercise to the reader seems a disservice to t= he
> community, given that this might lead to vendors (for example Microsof= t and
> Auth0) keeping their own proprietary parameters, or developers misusin= g the
> ones in place; would make it hard for SDK developers to provide librar= ies
> that work out of the box with different ASes; and so on.
> Would it be feasible to add such parameter directly in this spec? That=
> would eliminate the interop issues, and also gives us a chance to full= y
> warn people about the security shortcomings of choosing that approach.=
>
>
>
> On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
>
> We have discussed this.
>
> Audiences can certainly be logical identifiers.
>
> This however is a more specific location.=C2=A0 The AS is free to map = the
> location into some abstract audience in the AT.
>
> From a security point of view once the client starts asking for logica= l
> resources it can be tricked into asking for the wrong one as a bad res= ource
> can always lie about what logical resource it is.
>
> If we were to change it, how a client would validate it becomes
> challenging to impossible.
>
> The AS is free to do whatever mapping of locations to identifiers it n= eeds
> for access tokens.
>
> Some implementations may want to keep additional parameters like logic= al
> audience, but that should be separate from resource.
>
> John B.
> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
> Hi Vittorio,
>
> The text you quoted is copied form the abstract of the draft itself. >
>
> Authors,
>
> Should the draft be updated to cover the logical identifier case?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com
> <mailto:Vit= torio@auth0.com>> wrote:
> Hi Rifaat,
> one detail. The tech summary says
>
>
> An extension to the OAuth 2.0 Authorization Framework defining request=
>
> parameters that enable a client to explicitly signal to an authorizati= on
> server
>
> about the location of the protected resource(s) to which it is request= ing
>
> access.
> But at least in the Microsoft implementation, the resource identifier<= br> > doesn't have to be a network addressable URL (and if it is, it doe= sn't
> strictly need to match the actual resource location). It can be a logi= cal
> identifier, tho using the actual resource location there has benefits<= br> > (domain ownership check, prevention of token forwarding etc).
> Same for Auth0, the audience parameter is a logical identifier rather = than
> a location.
>
>
>
> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> All,
>
> The following is the first shepherd write-up for the
> draft-ietf-oauth-resource-indicators-01 document.
>
> https://d= atatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteu= p/
>
> Please, take a look and let me know if I missed anything.
>
> Regards,
>=C2=A0 Rifaat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
>
> htt= ps://www.ietf..org/mailman/listinfo/oauth<
> https://www.ietf.org/mailman/listinfo/oauth><= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited..=C2=A0 If= you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited...=C2=A0 I= f you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you._______________________________________________ > OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> htt= ps://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/a= ttachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 123, Issue 44
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190124/500550= 95/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 123, Issue 56
**************************************
--00000000000000750705803e1896-- From nobody Thu Jan 24 18:20:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22E12950A for ; Thu, 24 Jan 2019 18:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PYl8scvEc9pE for ; Thu, 24 Jan 2019 18:20:51 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35B11277D2 for ; Thu, 24 Jan 2019 18:20:50 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id x124so3910618itd.1 for ; Thu, 24 Jan 2019 18:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WmZy8zLnkMKccQh36DslX06w6t2PyX+chyJ2PiTArNU=; b=pH9CzN4LzXEK4UhgSj554ffmqkI0OxWocK155aFOrzKUdup+CDXx7hJU3wwggSjheo Jdb81qWTBuPeWeC+3sXHIzU6wqonYkUKsWXL9OdJBFvIWquXPRc2oxki9713afv2F+CC GMnsskNdSeOj0LfBUM0HEefQkQZccmAcxuG/5YhuFzk2iFPpTLdSduxXgFLRVFmJeFQB 5wfAW3ObsC9FhecDKDD6TzBH1fvXvKkS0yoHCaNisHgDd+P+U0kUt7hL05ZjL1syQbow 4hn2umjwLhrFmSwQ9UZgAwJsR670RHyMtECE80kGsXxngWjur4JtQ10C0j946B5DTuQk xakA== 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=WmZy8zLnkMKccQh36DslX06w6t2PyX+chyJ2PiTArNU=; b=I66+wiNutmdLtMNdpLItBHa9/Bv4/0AXMFmzXrTqnGDCWXZUFq1DAPRPtZ5ATTqiek UjvDH5rvLkJe6uUXhROW5Ic21O+5O2WO4mONFH4gCDmb/zVgvNVixfbwxhPS1pPreYH1 /KL0g6UdT1wB6RGRGilE4dO0EUUqHFO/kgsy4+qkdOZOs5/kQHZqFyLkkIVEowHmfUjP b7VC97ccg9Z03UdGtNqGVnJiulAdCumqtvaq+nvtSw4cH0/CsvJwcI4EzED/HH7QSQGN 1qNh5WP34QrPWNK9/35d9hXQ917HG5owi7P0DCdK3pVNxTIXMMCtc5snSRFdJVRkXWH/ Hnzw== X-Gm-Message-State: AJcUukc/wKbfpr+Ee2/n9dAeS9MQZlA/BH1spfbco6gwcou907EPHjzz aalGaxTAVYFuUhozr2w3zXxMpIgK8Yi1hQsYS7er3VFA X-Google-Smtp-Source: ALg8bN5Ua3ubK6UL6KgjEHpJTAbVIFrtYL9syxq/haE1Fy33J27TA8GN/PJGdqoVrROO64y6PiJs0mawt+Z7+iJQoIE= X-Received: by 2002:a02:b529:: with SMTP id l38mr5496035jaj.25.1548382850101; Thu, 24 Jan 2019 18:20:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Thu, 24 Jan 2019 21:20:39 -0500 Message-ID: To: Lao Vang <4all7the5time@gmail.com> Cc: oauth Content-Type: multipart/alternative; boundary="000000000000c1b9c705803ef96d" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 56 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 02:20:56 -0000 --000000000000c1b9c705803ef96d Content-Type: text/plain; charset="UTF-8" Please, do not send him money :) I unsubscribed and blocked this email from the list. Regards, Rifaat On Thu, Jan 24, 2019 at 8:18 PM Lao Vang <4all7the5time@gmail.com> wrote: > 445-67 claim money > > Direct deposit: > Acct: checking > > Routing#: 031101169 > Acct#: 8847548304001 > > Or send to my pay.google acct: > > 209hns@gmail.com > > > On Thu, Jan 24, 2019, 4:54 PM wrote: > >> Send OAuth mailing list submissions to >> oauth@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/oauth >> or, via email, send a message with subject or body 'help' to >> oauth-request@ietf.org >> >> You can reach the person managing the list at >> oauth-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of OAuth digest..." >> >> >> Today's Topics: >> >> 1. Re: OAuth Digest, Vol 123, Issue 44 (Lao Vang) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 24 Jan 2019 16:51:52 -0800 >> From: Lao Vang <4all7the5time@gmail.com> >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44 >> Message-ID: >> > 3KtoeDW5sr-FoPWXRq62_HFUhS_XQN+tf_14AQ@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Reply all >> >> >> On Tue, Jan 22, 2019, 10:20 AM wrote: >> >> > Send OAuth mailing list submissions to >> > oauth@ietf.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > https://www.ietf.org/mailman/listinfo/oauth >> > or, via email, send a message with subject or body 'help' to >> > oauth-request@ietf.org >> > >> > You can reach the person managing the list at >> > oauth-owner@ietf.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of OAuth digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Re: Shepherd write-up for >> > draft-ietf-oauth-resource-indicators-01 (Mike Jones) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Tue, 22 Jan 2019 18:19:31 +0000 >> > From: Mike Jones >> > To: Rifaat Shekh-Yusef , Vittorio Bertocci >> > >> > Cc: Brian Campbell , IETF >> > oauth WG >> > Subject: Re: [OAUTH-WG] Shepherd write-up for >> > draft-ietf-oauth-resource-indicators-01 >> > Message-ID: >> > < >> > >> MW2PR00MB030099E717A31D46BCAA4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.com >> >> > > >> > >> > Content-Type: text/plain; charset="utf-8" >> > >> > I think that a non-normative reference to ?req_aud? in >> > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be >> > added to the resource indicators doc to inform developers that req_aud >> is >> > also available to then, and then we should call it a day. >> > >> > -- Mike >> > >> > From: OAuth On Behalf Of Rifaat Shekh-Yusef >> > Sent: Monday, January 21, 2019 5:36 PM >> > To: Vittorio Bertocci >> > Cc: Brian Campbell ; IETF >> > oauth WG >> > Subject: Re: [OAUTH-WG] Shepherd write-up for >> > draft-ietf-oauth-resource-indicators-01 >> > >> > Thank you guys! >> > >> > >> > On Monday, January 21, 2019, Vittorio Bertocci > > > Vittorio@auth0..com >> wrote: >> > Hi Rifaat, >> > absolutely. Brian and myself already started working on some language, >> > however this week he is in vacation hence it might take few days before >> we >> > come back to the list with something. >> > Cheers, >> > V. >> > >> > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com >> > > wrote: >> > Brian, Vittorio, >> > >> > To move this discussion forward, can you guys suggest some text to make >> > the logical identifier usage clearer? >> > >> > Regards, >> > Rifaat >> > >> > >> > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > > 40pingidentity.com@dmarc.ietf.org> 40pingidentity.com@dmarc.ietf.org>> >> > wrote: >> > As I suggested before, I do think that's within the bounds of the >> draft's >> > definition of 'resource' as a URI. And that perhaps all that's needed is >> > some minor adjustment and/or augmentation of some text to make it more >> > clear. >> > >> > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > > > wrote: >> > [sent to John only by mistake, resending to the ML] >> > >> > In Azure AD v1 & ADFS, that's resource. It could be used for both >> network >> > and logical ids, with the concrete usage in the wild I described >> earlier. >> > In Azure AD v2, the resource as explicit parameter (network, logic or >> > otherwise) is gone and is expressed as part of the scope string of all >> the >> > scopes requested for a given resource- but it still exist in practice >> tho >> > as it still end up in the resulting aud of the issued token. >> > This is 9 months old info hence >> > >> > On Sun, Jan 20, 2019 at 17:58 John Bradley > > ve7jtb@ve7jtb.com>> wrote: >> > >> > What is the parameter that Microsoft is using? >> > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> > First of all, it wasn't my intent to disrupt the established process. In >> > my former position I wasn't monitoring those discussions hence I didn't >> > have a chance to offer feedback. When I saw something that gave me the >> > impression might lead to issues, and given that I worked with actual >> > deployments and developers using a similar parameter for a long time, I >> > thought prudent to bring this up. I really appreciate Rifaat's stance on >> > this. End of preamble. >> > >> > Ultimately my goal is for developers to have guidance on how to work >> with >> > the concept of logical resource in a standard compliant way, hence it >> > doesn't strictly matter whether the definition of the corresponding >> > parameter lives in oauth-resource-indicators or elsewhere. >> > That said. Reading through the draft, it would appear that most of the >> > reasons for which the spec was created apply to both the network >> > addressable and the logical resource types: knowing what keys to use to >> > encrypt the token, constrain access tokens to the intended audience, >> > avoiding overloading scopes with resource indicating parts... those all >> > apply to network addressable and logic identifiers alike. And both >> > parameters are expected to result in audience restricted tokens. It >> seems >> > the only difference comes at token usage time, with the network >> addressable >> > case giving more guarantees that the token will go to its intended >> > recipient, but the request and audience restriction syntax seems to be >> > exactly the same. >> > On top of this: in the 99.999% of the scenarios I encountered in the >> wild >> > in the last 5 years of using the resource parameter in the MS ecosystem, >> > the resource identifier was known at design time: the developer >> discovered >> > it out of band and placed it in the app config at deployment time. Those >> > aren't fringe cases I occasionally encountered: the resource parameter >> in >> > Azure AD v1 and ADFS was mandatory, hence literally every solution i >> saw or >> > touched used it. As Brian suggested, this is a scenario where the >> security >> > advantages of the network addressable case aren't as pronounced as in >> the >> > case in which the client discovers the resource identifier at runtime. >> This >> > isn't just because there is no specification suggesting location should >> be >> > explicitly indicated, it's because there are many practical advantages >> at >> > development and deployment time to be able to use logical identifiers- >> and >> > if the concrete security advantages don't apply to the their case, >> people >> > will simply not comply. >> > >> > In summary: creating two different parameters in two different documents >> > is better than ignoring he logical identifier case altogether, however I >> > think that not acknowledging the logical id case in >> > oauth-resource-indicators is going to create confusion and ultimately >> not >> > be as useful to the developer community as it could be. >> > >> > >> > >> > On Sat, Jan 19, 2019 at 12:38 Phil Hunt > > phil.hunt@oracle.com>> wrote: >> > +1 to Mike and John?s comments. >> > Phil >> > >> > On Jan 19, 2019, at 12:34 PM, Mike Jones > > 40microsoft.com@dmarc.ietf.org> > 40microsoft.com@dmarc.ietf.org>> wrote: >> > I also agree that ?resource? should be a specific network-addressable >> URL >> > whereas a separate audience parameter (like ?aud? in JWTs) can refer to >> one >> > or more logical resources. They are different, if related, things. >> > >> > Note that the ACE WG is proposing to register a logical audience >> parameter >> > ?req_aud? in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 >> - >> > partly based on feedback from OAuth WG members. This is a general OAuth >> > parameter, which any OAuth deployment will be able to use. >> > >> > I therefore believe that no changes are needed to >> > draft-ietf-oauth-resource-indicators, as the logical audience work is >> > already happening in another draft. >> > >> > -- Mike >> > >> > From: OAuth > On >> > Behalf Of John Bradley >> > Sent: Saturday, January 19, 2019 9:01 AM >> > To: Brian Campbell > > bcampbell@pingidentity.com>> >> > Cc: Vittorio Bertocci > Vittorio >> > =40auth0.com@dmarc.ietf.org>>; IETF oauth WG > > oauth@ietf.org>> >> > Subject: Re: [OAUTH-WG] Shepherd write-up for >> > draft-ietf-oauth-resource-indicators-01 >> > >> > We need to decide if we want to make a change. >> > >> > For security we are location centric. >> > >> > I prefer to keep resource location separate from logical audience that >> can >> > be a scope or other parameter. >> > >> > If becomes harder for people to use the parameter correctly if we are >> too >> > flexible. >> > >> > I would rather have a separate logical audience parameter if we think we >> > want one. >> > >> > John B. >> > >> > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell < >> bcampbell@pingidentity.com >> > wrote: >> > No apology needed, Rifaat. And I apologize if what I said came off the >> > wrong way. I was just trying to make light of the situation.. And I >> agree >> > that we should not be hamstrung by the process and there are times when >> it >> > makes sense to be flexible with things. >> > >> > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com >> > > wrote: >> > Sorry Brian, I was not clear with my statement. >> > I meant to say that we should not allow the process to prevent the WG >> from >> > producing a quality document without issues, assuming there is an issue >> in >> > the first place. >> > Ideally we want to get these identified during the WGLC, but things >> happen >> > and sometimes the WG misses something. >> > >> > I hear you and agree that this make things difficult for authors. We >> will >> > make sure that this does not become the norm, and we will try to stick >> to >> > the process as much as possible. >> > >> > Regards, >> > Rifaat >> > >> > >> > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com >> > > wrote: >> > Thanks Rifaat. Process is as process does, right? I do kinda want to >> > grumble about WGCL having passed already but that's mostly because >> replying >> > to these kinds of threads is hard for me and I'll just get over it.... >> > >> > As far as I understand things, the security concerns come into play when >> > the client is being told the by the resource how to identity the >> resource >> > like is described in >> > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the >> > actual location in that context ,along with some other checks >> prescribed in >> > that draft, prevents the kind of issues John described earlier in the >> > thread. >> > >> > In cases where the client knows the resource a priori or out-of-band or >> > configured or whatever, I don't think the same security concerns arise. >> And >> > using such a known value, be it an actual location or logical >> > representation, would be okay. >> > >> > The resource-indicators draft is admittedly somewhat location-centric in >> > how it talks about the value of the 'resource' parameter. But >> ultimately it >> > defines it as an absolute URI that indicates the location of the target >> > service or resource where access is being requested. A location can be >> > varying shades of abstract and I'd say that using a URI as 'resource' >> > parameter value that's a logical identifier that points to some >> resource is >> > well within the bounds of the draft. >> > >> > So maybe the draft is okay as is? >> > >> > Or perhaps that's too much to be left as an exerciser to the reader? >> And >> > some text should be added and/or adjusted so the resource-indicators >> draft >> > would be a little more open/clear about the parameter value potentially >> > being more of a logical or abstract identifier and not necessarily a >> > network addressable URL? >> > >> > >> > >> > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com >> > > wrote: >> > I wouldn't worry too much about the process. >> > If it makes sense to update the document, then feel free to do that. >> > >> > Regards, >> > Rifaat >> > >> > >> > On Fri, Jan 18, 2019 at 3:08 PM John Bradley > > ve7jtb@ve7jtb.com>> wrote: >> > Yes the logical resource can be provided by "scope" >> > >> > Some implementations like Ping and Auth0 have been adding another >> > parameter "aud" to identify the logical resource and then using scopes >> to >> > define permissions to the resource. >> > >> > Fortunately, we are using a different parameter name so not stepping on >> > that.. >> > >> > We could go back and try to add text explaining the difference, but we >> are >> > quite late in the process. >> > >> > I agree that a logical resource parameter may be helpful, but perhaps it >> > should be a separate draft. >> > >> > John B. >> > >> > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> > richanna@amazon.com> wrote: >> > Doesn?t the ?scope? parameter already provide a means of specifying a >> > logical identifier? >> > >> > -- >> > Annabelle Richard Backman >> > AWS Identity >> > >> > >> > From: OAuth > on >> > behalf of Vittorio Bertocci > > > 40auth0..com@dmarc.ietf.org>> >> > Date: Friday, January 18, 2019 at 5:47 AM >> > To: John Bradley > >> > Cc: IETF oauth WG > >> > Subject: Re: [OAUTH-WG] Shepherd write-up for >> > draft-ietf-oauth-resource-indicators-01 >> > >> > Thanks John for the background. >> > I agree that from the client validation PoV, having an identifier >> > corresponding to a location makes things more solid. >> > That said: the use of logical identifiers is widespread, as it has >> > significant practical advantages (think of services that assign >> generated >> > hosting URLs only at deployment time, or services that are somehow >> grouped >> > under the same logical audience across regions/environment/deployments). >> > People won't stop using logical identifiers, because they often have no >> > alternative (generating new audiences on the fly at the AS every time >> you >> > do a deployment and get assigned a new URL can be unfeasible). Leaving a >> > widely used approach as exercise to the reader seems a disservice to the >> > community, given that this might lead to vendors (for example Microsoft >> and >> > Auth0) keeping their own proprietary parameters, or developers misusing >> the >> > ones in place; would make it hard for SDK developers to provide >> libraries >> > that work out of the box with different ASes; and so on. >> > Would it be feasible to add such parameter directly in this spec? That >> > would eliminate the interop issues, and also gives us a chance to fully >> > warn people about the security shortcomings of choosing that approach. >> > >> > >> > >> > On Thu, Jan 17, 2019 at 4:32 PM John Bradley > > ve7jtb@ve7jtb.com>> wrote: >> > >> > We have discussed this. >> > >> > Audiences can certainly be logical identifiers. >> > >> > This however is a more specific location. The AS is free to map the >> > location into some abstract audience in the AT. >> > >> > From a security point of view once the client starts asking for logical >> > resources it can be tricked into asking for the wrong one as a bad >> resource >> > can always lie about what logical resource it is. >> > >> > If we were to change it, how a client would validate it becomes >> > challenging to impossible. >> > >> > The AS is free to do whatever mapping of locations to identifiers it >> needs >> > for access tokens. >> > >> > Some implementations may want to keep additional parameters like logical >> > audience, but that should be separate from resource. >> > >> > John B. >> > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> > Hi Vittorio, >> > >> > The text you quoted is copied form the abstract of the draft itself. >> > >> > >> > Authors, >> > >> > Should the draft be updated to cover the logical identifier case? >> > >> > Regards, >> > Rifaat >> > >> > >> > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > > > wrote: >> > Hi Rifaat, >> > one detail. The tech summary says >> > >> > >> > An extension to the OAuth 2.0 Authorization Framework defining request >> > >> > parameters that enable a client to explicitly signal to an authorization >> > server >> > >> > about the location of the protected resource(s) to which it is >> requesting >> > >> > access. >> > But at least in the Microsoft implementation, the resource identifier >> > doesn't have to be a network addressable URL (and if it is, it doesn't >> > strictly need to match the actual resource location). It can be a >> logical >> > identifier, tho using the actual resource location there has benefits >> > (domain ownership check, prevention of token forwarding etc). >> > Same for Auth0, the audience parameter is a logical identifier rather >> than >> > a location. >> > >> > >> > >> > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com >> > > wrote: >> > All, >> > >> > The following is the first shepherd write-up for the >> > draft-ietf-oauth-resource-indicators-01 document. >> > >> > >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >> > >> > Please, take a look and let me know if I missed anything. >> > >> > Regards, >> > Rifaat >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > >> > OAuth mailing list >> > >> > OAuth@ietf.org >> > >> > https://www.ietf..org/mailman/listinfo/oauth< >> > https://www.ietf.org/mailman/listinfo/oauth> >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited. If you >> have >> > received this communication in error, please notify the sender >> immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you. >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited.. If you >> have >> > received this communication in error, please notify the sender >> immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you. >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited... If you >> have >> > received this communication in error, please notify the sender >> immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you._______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> > >> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/attachment.html >> > > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > ------------------------------ >> > >> > End of OAuth Digest, Vol 123, Issue 44 >> > ************************************** >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190124/50055095/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> ------------------------------ >> >> End of OAuth Digest, Vol 123, Issue 56 >> ************************************** >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c1b9c705803ef96d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please, do not send him money :)

=
I unsubscribed and blocked this email from the list.

Regards,
=C2=A0Rifaat


On Thu, Jan 24, 2019= at 8:18 PM Lao Vang <4all7th= e5time@gmail.com> wrote:
445-67 claim money=C2=A0

Direct deposit:=
Acct: checking

Routing#: 031101169
Acct#: 8847548304001

Or send to my pay.google acct:
=


On Thu, Jan 24, 2019, 4:54 PM <oauth-request@ietf.org> wrote:
Send OAuth mailing list submiss= ions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: OAuth Digest, Vol 123, Issue 44 (Lao Vang)


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

Message: 1
Date: Thu, 24 Jan 2019 16:51:52 -0800
From: Lao Vang <4all7the5time@gmail.com>
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAKPLo8+nqDA=3D3KtoeDW5sr= -FoPWXRq62_HFUhS_XQN+tf_14AQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Reply all


On Tue, Jan 22, 2019, 10:20 AM <oauth-request@ietf.org> wrote:

> Send OAuth mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.or= g/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>=C2=A0 =C2=A0 1. Re: Shepherd write-up for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-resource-indicators-01 (Mik= e Jones)
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Tue, 22 Jan 2019 18:19:31 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertocci
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Vittorio@auth0.com>
> Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;, IETF
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oauth WG <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-resource-indicators-= 01
> Message-ID:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<
> MW2PR00MB030099E717A31D46BCA= A4F9AF5980@MW2PR00MB0300.namprd00.prod.outlook.com
> >
>
> Content-Type: text/plain; charset=3D"utf-8"
>
> I think that a non-normative reference to=C2=A0 ?req_aud? in
> https://tools.ietf.org/html/draft-iet= f-ace-oauth-params-01 should be
> added to the resource indicators doc to inform developers that req_aud= is
> also available to then, and then we should call it a day.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-- Mike
>
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
> Sent: Monday, January 21, 2019 5:36 PM
> To: Vittorio Bertocci <Vittorio@auth0.com>
> Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;; IETF
> oauth WG <oauth= @ietf.org>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> Thank you guys!
>
>
> On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com<mailto:
> Vittorio@auth0= ..com>> wrote:
> Hi Rifaat,
> absolutely. Brian and myself already started working on some language,=
> however this week he is in vacation hence it might take few days befor= e we
> come back to the list with something.
> Cheers,
> V.
>
> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> Brian, Vittorio,
>
> To move this discussion forward, can you guys suggest some text to mak= e
> the logical identifier usage clearer?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D
> 40pingidentity.com@dmarc.ietf.org<mailto:40pingidentity.com@dmarc.ietf.= org>>
> wrote:
> As I suggested before, I do think that's within the bounds of the = draft's
> definition of 'resource' as a URI. And that perhaps all that&#= 39;s needed is
> some minor adjustment and/or augmentation of some text to make it more=
> clear.
>
> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com
> <mailto:Vit= torio@auth0.com>> wrote:
> [sent to John only by mistake, resending to the ML]
>
> In Azure AD v1 & ADFS, that's resource. It could be used for b= oth network
> and logical ids, with the concrete usage in the wild I described earli= er.
> In Azure AD v2, the resource as explicit parameter (network, logic or<= br> > otherwise) is gone and is expressed as part of the scope string of all= the
> scopes requested for a given resource- but it still exist in practice = tho
> as it still end up in the resulting aud of the issued token.
> This is 9 months old info hence
>
> On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
>
> What is the parameter that Microsoft is using?
> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
> First of all, it wasn't my intent to disrupt the established proce= ss. In
> my former position I wasn't monitoring those discussions hence I d= idn't
> have a chance to offer feedback. When I saw something that gave me the=
> impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, = I
> thought prudent to bring this up. I really appreciate Rifaat's sta= nce on
> this. End of preamble.
>
> Ultimately my goal is for developers to have guidance on how to work w= ith
> the concept of logical resource in a standard compliant way, hence it<= br> > doesn't strictly matter whether the definition of the correspondin= g
> parameter lives in oauth-resource-indicators or elsewhere.
> That said. Reading through the draft, it would appear that most of the=
> reasons for which the spec was created apply to both the network
> addressable and the logical resource types: knowing what keys to use t= o
> encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those al= l
> apply to network addressable and logic identifiers alike. And both
> parameters are expected to result in audience restricted tokens. It se= ems
> the only difference comes at token usage time, with the network addres= sable
> case giving more guarantees that the token will go to its intended
> recipient, but the request and audience restriction syntax seems to be=
> exactly the same.
> On top of this: in the 99.999% of the scenarios I encountered in the w= ild
> in the last 5 years of using the resource parameter in the MS ecosyste= m,
> the resource identifier was known at design time: the developer discov= ered
> it out of band and placed it in the app config at deployment time. Tho= se
> aren't fringe cases I occasionally encountered: the resource param= eter in
> Azure AD v1 and ADFS was mandatory, hence literally every solution i s= aw or
> touched used it. As Brian suggested, this is a scenario where the secu= rity
> advantages of the network addressable case aren't as pronounced as= in the
> case in which the client discovers the resource identifier at runtime.= This
> isn't just because there is no specification suggesting location s= hould be
> explicitly indicated, it's because there are many practical advant= ages at
> development and deployment time to be able to use logical identifiers-= and
> if the concrete security advantages don't apply to the their case,= people
> will simply not comply.
>
> In summary: creating two different parameters in two different documen= ts
> is better than ignoring he logical identifier case altogether, however= I
> think that not acknowledging the logical id case in
> oauth-resource-indicators is going to create confusion and ultimately = not
> be as useful to the developer community as it could be.
>
>
>
> On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com<mailto:
> phil.hunt@or= acle.com>> wrote:
> +1 to Mike and John?s comments.
> Phil
>
> On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D
> 40= microsoft.com@dmarc.ietf.org<mailto:Michael.Jones=3D
> 40= microsoft.com@dmarc.ietf.org>> wrote:
> I also agree that ?resource? should be a specific network-addressable = URL
> whereas a separate audience parameter (like ?aud? in JWTs) can refer t= o one
> or more logical resources.=C2=A0 They are different, if related, thing= s.
>
> Note that the ACE WG is proposing to register a logical audience param= eter
> ?req_aud? in https://tools.ietf.org/h= tml/draft-ietf-ace-oauth-params-01 -
> partly based on feedback from OAuth WG members.=C2=A0 This is a genera= l OAuth
> parameter, which any OAuth deployment will be able to use.
>
> I therefore believe that no changes are needed to
> draft-ietf-oauth-resource-indicators, as the logical audience work is<= br> > already happening in another draft.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike >
> From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> On
> Behalf Of John Bradley
> Sent: Saturday, January 19, 2019 9:01 AM
> To: Brian Campbell <bcampbell@pingidentity.com<mailto:
> bcampb= ell@pingidentity.com>>
> Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mailto:Vittorio
> =3D40a= uth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org<mailto:
> oauth@ietf.org= >>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> We need to decide if we want to make a change.
>
> For security we are location centric.
>
> I prefer to keep resource location separate from logical audience that= can
> be a scope or other parameter.
>
> If becomes harder for people to use the parameter correctly if we are = too
> flexible.
>
> I would rather have a separate logical audience parameter if we think = we
> want one.
>
> John B.
>
> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com<= br> > <mailto:bcampbell@pingidentity.com> wrote:
> No apology needed, Rifaat. And I apologize if what I said came off the=
> wrong way. I was just trying to make light of the situation.. And I ag= ree
> that we should not be hamstrung by the process and there are times whe= n it
> makes sense to be flexible with things.
>
> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> Sorry Brian, I was not clear with my statement.
> I meant to say that we should not allow the process to prevent the WG = from
> producing a quality document without issues, assuming there is an issu= e in
> the first place.
> Ideally we want to get these identified during the WGLC, but things ha= ppen
> and sometimes the WG misses something.
>
> I hear you and agree that this make things difficult for authors. We w= ill
> make sure that this does not become the norm, and we will try to stick= to
> the process as much as possible.
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com=
> <mailto:bcampbell@pingidentity.com>> wrote:
> Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because= replying
> to these kinds of threads is hard for me and I'll just get over it= ....
>
> As far as I understand things, the security concerns come into play wh= en
> the client is being told the by the resource how to identity the resou= rce
> like is described in
> https://tools.ietf.org/html/draft-ie= tf-oauth-distributed-01 and using the
> actual location in that context ,along with some other checks prescrib= ed in
> that draft, prevents the kind of issues John described earlier in the<= br> > thread.
>
> In cases where the client knows the resource a priori or out-of-band o= r
> configured or whatever, I don't think the same security concerns a= rise. And
> using such a known value, be it an actual location or logical
> representation, would be okay.
>
> The resource-indicators draft is admittedly somewhat location-centric = in
> how it talks about the value of the 'resource' parameter. But = ultimately it
> defines it as an absolute URI that indicates the location of the targe= t
> service or resource where access is being requested. A location can be=
> varying shades of abstract and I'd say that using a URI as 're= source'
> parameter value that's a logical identifier that points to some re= source is
> well within the bounds of the draft.
>
> So maybe the draft is okay as is?
>
> Or perhaps that's too much to be left as an exerciser to the reade= r?=C2=A0 And
> some text should be added and/or adjusted so the resource-indicators d= raft
> would be a little more open/clear about the parameter value potentiall= y
> being more of a logical or abstract identifier and not necessarily a > network addressable URL?
>
>
>
> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> I wouldn't worry too much about the process.
> If it makes sense to update the document, then feel free to do that. >
> Regards,
>=C2=A0 Rifaat
>
>
> On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
> Yes the logical resource can be provided by "scope"
>
> Some implementations like Ping and Auth0 have been adding another
> parameter "aud" to identify the logical resource and then us= ing scopes to
> define permissions to the resource.
>
> Fortunately, we are using a different parameter name so not stepping o= n
> that..
>
> We could go back and try to add text explaining the difference, but we= are
> quite late in the process.
>
> I agree that a logical resource parameter may be helpful, but perhaps = it
> should be a separate draft.
>
> John B.
>
> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
> richanna@amaz= on.com<mailto:richanna@amazon.com>> wrote:
> Doesn?t the ?scope? parameter already provide a means of specifying a<= br> > logical identifier?
>
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> on
> behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org<mail= to:
> 40aut= h0..com@dmarc.ietf.org>>
> Date: Friday, January 18, 2019 at 5:47 AM
> To: John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
> Cc: IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
> Thanks John for the background.
> I agree that from the client validation PoV, having an identifier
> corresponding to a location makes things more solid.
> That said: the use of logical identifiers is widespread, as it has
> significant practical advantages (think of services that assign genera= ted
> hosting URLs only at deployment time, or services that are somehow gro= uped
> under the same logical audience across regions/environment/deployments= ).
> People won't stop using logical identifiers, because they often ha= ve no
> alternative (generating new audiences on the fly at the AS every time = you
> do a deployment and get assigned a new URL can be unfeasible). Leaving= a
> widely used approach as exercise to the reader seems a disservice to t= he
> community, given that this might lead to vendors (for example Microsof= t and
> Auth0) keeping their own proprietary parameters, or developers misusin= g the
> ones in place; would make it hard for SDK developers to provide librar= ies
> that work out of the box with different ASes; and so on.
> Would it be feasible to add such parameter directly in this spec? That=
> would eliminate the interop issues, and also gives us a chance to full= y
> warn people about the security shortcomings of choosing that approach.=
>
>
>
> On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com<mailto:
> ve7jtb@ve7jtb.c= om>> wrote:
>
> We have discussed this.
>
> Audiences can certainly be logical identifiers.
>
> This however is a more specific location.=C2=A0 The AS is free to map = the
> location into some abstract audience in the AT.
>
> From a security point of view once the client starts asking for logica= l
> resources it can be tricked into asking for the wrong one as a bad res= ource
> can always lie about what logical resource it is.
>
> If we were to change it, how a client would validate it becomes
> challenging to impossible.
>
> The AS is free to do whatever mapping of locations to identifiers it n= eeds
> for access tokens.
>
> Some implementations may want to keep additional parameters like logic= al
> audience, but that should be separate from resource.
>
> John B.
> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
> Hi Vittorio,
>
> The text you quoted is copied form the abstract of the draft itself. >
>
> Authors,
>
> Should the draft be updated to cover the logical identifier case?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com
> <mailto:Vit= torio@auth0.com>> wrote:
> Hi Rifaat,
> one detail. The tech summary says
>
>
> An extension to the OAuth 2.0 Authorization Framework defining request=
>
> parameters that enable a client to explicitly signal to an authorizati= on
> server
>
> about the location of the protected resource(s) to which it is request= ing
>
> access.
> But at least in the Microsoft implementation, the resource identifier<= br> > doesn't have to be a network addressable URL (and if it is, it doe= sn't
> strictly need to match the actual resource location). It can be a logi= cal
> identifier, tho using the actual resource location there has benefits<= br> > (domain ownership check, prevention of token forwarding etc).
> Same for Auth0, the audience parameter is a logical identifier rather = than
> a location.
>
>
>
> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
> <mailto:= rifaat.ietf@gmail.com>> wrote:
> All,
>
> The following is the first shepherd write-up for the
> draft-ietf-oauth-resource-indicators-01 document.
>
> https://d= atatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteu= p/
>
> Please, take a look and let me know if I missed anything.
>
> Regards,
>=C2=A0 Rifaat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
>
> htt= ps://www.ietf..org/mailman/listinfo/oauth<
> https://www.ietf.org/mailman/listinfo/oauth><= br> > _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited..=C2=A0 If= you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited...=C2=A0 I= f you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you._______________________________________________ > OAuth mailing list
> OAuth@ietf.org= <mailto:OAuth@ietf.o= rg>
> https://www.ietf.org/mailman/listinfo/oauth
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> htt= ps://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/a= ttachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 123, Issue 44
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190124/500550= 95/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 123, Issue 56
**************************************
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c1b9c705803ef96d-- From nobody Fri Jan 25 08:42:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66860130F15 for ; Fri, 25 Jan 2019 08:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 21bhmPx6xYHo for ; Fri, 25 Jan 2019 08:42:41 -0800 (PST) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634AF130F0E for ; Fri, 25 Jan 2019 08:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548434560; bh=gd3TyXfP8cLMUNBJt1bplJ3Xg/wEuCAr8cHZKjFmaCI=; h=To:From:Subject:Date:From:Subject; b=QiuPEjzp4x0SY8c+pMmJz+9ylMqNqPq/flnGhBgx5booMLHDuIX6wZgyuQYVCkDudd48klzH7lzsf/YmzN9t1ayizunNuYkZ3KRsKkikGtoQGy/Foc1MaPp3txCOlwEt3/+Df7NCyvwOxNpE90MUt8xYPHQg7LZfQuV3Re2ITkfrzblTpVAyY63gS4iN1DocUdoXpQQQ8rG+W7er+Pq4nDp3FLfXNjAUIPCkDCQMTZi7Ejr45WFsRPypth8AOx5It0vIXh1u2xJ5D8KCeXTrs1op0xixB6zuqe/h4n7Inza+SHSM61yFj5J0sn3w4CTuZlYW1DvYZPcMpR4dGY+JqA== X-YMail-OSG: fO_DXaUVM1krtPS68xvNFFJjptNRHIg7bwq7EIFReCyppUgjXG62yiOLlI_e0F8 MvGOMCH2Mnbc9asQK1zG5cPRJDd0ZCDp1BiiIejGsadqQFH7DFT7i.ecVusJYqvbdLzUnEgFVcIB 7WQykPP.zhQKp5foR9pyTlX.vB0Ru6feirFbdggF0lIwiG5U6y7ZU2vDjmS7mhHvu0BqISPskZ4T qigTW4OHcJg9.KOiRPGGzLy5nImUeUu2KrdbiTjeU_HF6DmS8xrDdw3bIzs4BLbegjJx.IIrhxCC yZBMLyJbfRcysPkHgcAdFZFLtWz3AGsuNk.2wpb1PEPu3FWM23DA8bJDF0cRv6pDe9oF70gJMWmB waGOHZxWxJUlfgbVwVADyZcSvSRTvntlm1UgaGfJ3qTM.SbKICDsRczcseo.UrhAoRw61aw1pF1f RI3FBXx7JeZ7WOw_I2D2QWd3.1n87JQeTofR1HJcpoCsJWjq5kLRXtGKu9vdKvsSXHeN9mR.7ELW 7yKg0ykSBVr7ozd33Uvo6d6GiPnEIWWYOjZ4lENonb_6Pov7uRawkrICKgEoLQnfLf6iM41l0cVQ jSBqSPqST2Y6UNpnirwCz2jHcEPL4fnNkpJpWMNCjv0Dl16_pCEVk4JWAJzL45cjwGqST950qKm5 lvStoVNlpA_xBYUQYPAvSRC4cDgeY5x4LylM4ICsWc1BlR.WbMJjWnciTni.4mE747G302E368cW fmaL5K0qGOzxE3sS7aEAQt_XC8WRUQoynUkzjRfR77q9YZjvdNT8xvI8N9i86ZDcs311AHRXRxol VCViJ4pZuEaM19xfKwLRjReh9OtHBIjOpYnvgzjyhAcrZwOsLnxMElNizGRmqYncMLoM6hS4dXHK _QTeF0nVvU_yuLOqSUjE4H0rC0zJKQZ7_kNASnSPwFrh3mbIFt5ZXrnUz2BiwljAjPzKqt_QsXEB .oET_orbEN2RP1ARh1ncrv7X2mSxBOgT.CP2AOYJEupwTG.NG5pF2GD0L7cfz6dbnIXjP3RPixa9 _uTZHE9id6C_sIJus4aTqNxRZsxCqvSRhWCzawPMYLAnj Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 25 Jan 2019 16:42:40 +0000 Received: from 208.72.78.175 (EHLO [192.168.50.170]) ([208.72.78.175]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f1c8705526804e799b660e72c8f7b1a6 for ; Fri, 25 Jan 2019 16:42:38 +0000 (UTC) To: "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 25 Jan 2019 11:42:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Issues with Android and UC Browser X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 16:42:44 -0000 Hi, We are seeing issues with the authorization code flow on an Android device where the system browser is the UC browser (https://www.ucweb.com/). Basically, the deep link back to the application to deliver the code value fails. Just curious if others have experienced this behavior and if there are any known work-arounds. Thanks, George From nobody Fri Jan 25 12:24:19 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36F130F09 for ; Fri, 25 Jan 2019 12:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.354 X-Spam-Level: X-Spam-Status: No, score=-16.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im1XJMyyuW6c for ; Fri, 25 Jan 2019 12:24:16 -0800 (PST) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CEA1277BB for ; Fri, 25 Jan 2019 12:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1548447856; x=1579983856; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=J4ddOhTGlYuyaXn+t1UbxOJWa1j8rMl+25k7hg9g35w=; b=MD+PSoXUJ8o9d+V6DWsy4Jk/lRRHadHNrpcxfeZydd6DjXkTgOUQ6Lqg z/Dh0+TFcIbJGREVvGQVywpwiOrtmBG88F2JYiRv5sC332jJPVuAbYmT4 zns4qdWc1msQ6FJH4MnPVgUCArTv576qcxIgT1xjTzesnl6unsGIKxjTN g=; X-IronPort-AV: E=Sophos;i="5.56,522,1539648000"; d="scan'208";a="378239697" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 25 Jan 2019 20:24:13 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com (Postfix) with ESMTPS id F421AA1D59; Fri, 25 Jan 2019 20:24:12 +0000 (UTC) Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 25 Jan 2019 20:24: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.1367.3; Fri, 25 Jan 2019 20:24:11 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 25 Jan 2019 20:24:11 +0000 From: "Richard Backman, Annabelle" To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Issues with Android and UC Browser Thread-Index: AQHUtM0KvxDKN/8tQkaSDnKGpZ/wwaW/6CaA Date: Fri, 25 Jan 2019 20:24:11 +0000 Message-ID: <224359A0-E2F1-465D-8563-E162F9EA59AF@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.9] Content-Type: text/plain; charset="utf-8" Content-ID: <8A671B009CBA0547BCDC1C9E557B8A0F@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Issues with Android and UC Browser X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 20:24:18 -0000 KENvbnRlbnQgd2FybmluZyBmb3IgYWR2aWNlIGdpdmVuIHdpdGhvdXQgZGlyZWN0IGV4cGVyaWVu Y2Ugd2l0aCB0aGUgc3BlY2lmaWMgcHJvYmxlbSBfXykNCg0KQXJlIHRoZXNlIGRlZXAgbGlua3Mg dXNpbmcgY3VzdG9tIHNjaGVtZXMgb3IgIkFuZHJvaWQgQXBwIExpbmtzIj8gSWYgdGhlIGZvcm1l ciwgdHJ5IHN3aXRjaGluZyB0byB0aGUgbGF0dGVyPw0KDQotLSANCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KIA0KDQrvu79PbiAxLzI1LzE5LCA4OjQzIEFNLCAiT0F1 dGggb24gYmVoYWxmIG9mIEdlb3JnZSBGbGV0Y2hlciIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoN CiAgICBIaSwNCiAgICANCiAgICBXZSBhcmUgc2VlaW5nIGlzc3VlcyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgZmxvdyBvbiBhbiBBbmRyb2lkIA0KICAgIGRldmljZSB3aGVyZSB0aGUgc3lz dGVtIGJyb3dzZXIgaXMgdGhlIFVDIGJyb3dzZXIgDQogICAgKGh0dHBzOi8vd3d3LnVjd2ViLmNv bS8pLiBCYXNpY2FsbHksIHRoZSBkZWVwIGxpbmsgYmFjayB0byB0aGUgDQogICAgYXBwbGljYXRp b24gdG8gZGVsaXZlciB0aGUgY29kZSB2YWx1ZSBmYWlscy4NCiAgICANCiAgICBKdXN0IGN1cmlv dXMgaWYgb3RoZXJzIGhhdmUgZXhwZXJpZW5jZWQgdGhpcyBiZWhhdmlvciBhbmQgaWYgdGhlcmUg YXJlIA0KICAgIGFueSBrbm93biB3b3JrLWFyb3VuZHMuDQogICAgDQogICAgVGhhbmtzLA0KICAg IEdlb3JnZQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgT0F1dGggbWFpbGluZyBsaXN0DQogICAgT0F1dGhAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQogICAgDQoNCg== From nobody Mon Jan 28 06:08:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815D12426A for ; Mon, 28 Jan 2019 06:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 J9cHGKWxogSY for ; Mon, 28 Jan 2019 06:08:09 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEC91228B7 for ; Mon, 28 Jan 2019 06:08:08 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id h193so19439811ita.5 for ; Mon, 28 Jan 2019 06:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=zN7xW6IunC3AwRQk+41koZkd7SmRWjoS7ZxJuxawdJc=; b=hdLFYtinpmBA7jGYr0MRQiQiaPs+pdL7km+r10JK5sS3pHm/CRSMTmANGIgJWEL8jZ 4ydhZkJlkLB/LJ7IvS4ZYL/ChW1VCsrr4lYn+pCT4bz1R/VrcY7y/BFy7NxML7uL9ejP sl8W+sUMZAXItrMiU+eM3qDi+eqX6U2yO4wEI= 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=zN7xW6IunC3AwRQk+41koZkd7SmRWjoS7ZxJuxawdJc=; b=BWtT+Lu2rlYYMIERO0k6uLGswXu5Dg1b3tT+rFB/i+PB5WiivEaFAe8uW+2BVdYcqO JtHOO/ZOnkgfchFcojB7oIYHBcjL+nyTo7bvZyCd71XdzB4/RuES0rZq/IZXEWR7JtgZ GUcymeg/5k3Q4tESpr0x5jwXhGVGJed83OMCsEGjdXvkaeZyfzN6g/kS/YKvd4vgmz1p iEkTAJYsPh/SxiFXUQMLs4PSNYmRqqla1vt5/6Xe2vJBAI9MpZYPSEwc2aSRQ163nKGJ CSdCCQZdHKAXY2WnQmmyp7ZaEkBp07sh9dJ1usUDjfJxRnzcyA7dF8ya5j+MRqIpH5lA bDBw== X-Gm-Message-State: AJcUukelNYHKOK+Vk0DTcHGmDR1EK333o5for2ftjhQwZipyrHtK9heg mNAfreVorjaE72REFA4vJ2yj93XK14yPpib4ozbKc4M5yoFgbG4v7BKCkZlniyzC0EhTuMadk6+ I8b/hlMsdPkvDLxh//Mg= X-Received: by 2002:a24:6293:: with SMTP id d141mt9308654itc.124.1548684486994; Mon, 28 Jan 2019 06:08:06 -0800 (PST) MIME-Version: 1.0 References: <480E777C-F5E1-4062-9CE6-7C476F4A990B@oracle.com> <5860f29e-3280-ac6f-342e-38a3c859d827@ve7jtb.com> <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> In-Reply-To: From: Brian Campbell Date: Mon, 28 Jan 2019 07:07:39 -0700 Message-ID: Cc: "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000b7e8e3058085347f" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 14:08:13 -0000 --000000000000b7e8e3058085347f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too. The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deployment specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both? In addition to the concerns others have expressed about "req_aud", I"d note that draft-ietf-ace-oauth-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would be a disservice to just about everyone. On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef wrote: > Hannes sent an update to this meeting here: > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > Regards, > Rifaat > > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > wrote: > >> The virtual office hours in my calendar start 1/2 hour before that. If >> the time has changed, can you have the meeting organizer update the >> calendar entry? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> *From:* Rifaat Shekh-Yusef >> *Sent:* Thursday, January 24, 2019 12:46 PM >> *To:* George Fletcher >> *Cc:* Vittorio Bertocci ; Mike Jones < >> Michael.Jones@microsoft.com>; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> All, >> >> >> >> This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled >> OAuth WG Virtual Office meeting. >> >> Feel free to attend the meeting to discuss this topic to try to get to a >> conclusion on this. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> +1 >> >> Also, I don't really like the parameter name 'req_aud' :) I'm not 100% >> convinced that 'audience' and 'logical resource' are completely overlapp= ing >> concepts. We can potentially make them completely overlapping but we nee= d >> text to that effect. >> >> I also believe that we don't have a complete solution for all deployment= s >> using exact locations (see my previous email). >> >> Thanks, >> George >> >> On 1/23/19 2:50 PM, Vittorio Bertocci wrote: >> >> As mentioned below, I agree the two can be separated- but I also agree >> with George on the need to be clear an easy to reference for developers. >> >> Just adding a reference to req_aud would just raise the cyclomatic >> complexity of the specs, which is already unusably high for mere mortals= in >> the OAuth2/OIDC family of specs. >> >> >> >> One additional complication is that this specification is reusing a >> parameter that is already used in a *very* large number of production >> systems (small example here >> ), >> and whose concrete semantic happens to be prevalently logic identifier. = If >> the parameter you are defining here has a different semantic, at the ver= y >> least it would seem good hygiene to rename it to avoid collision and >> confusion. >> >> >> >> On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >> I agree with John=E2=80=99s logic. The physical resource and logical re= source >> should use different identifiers. Fortunately, we already have =E2=80= =9Cresource=E2=80=9D >> and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Wednesday, January 23, 2019 10:56 AM >> *To:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> I don't think they are necessarily mutually exclusive, that is why I >> think there is value in allowing them to be specified separately. >> >> As an AS in the distributed OAuth case knowing that a client interacting >> with RS https://fire.hhs.com as the resource wants a OAuth token with an >> audience of HHS and a scope of read. >> >> Without proof of possession we need to keep bad RS from asking for token= s >> with scopes and audiences of other RS that can be replayed. >> >> I really like keeping the resource simple and unspoofable, it is the URI >> of the RS where you are presenting the AT. >> >> I prefer to keep that separate from the logical resource that may span >> more than one RS endpoint. >> >> Merging the two and we are probably back at the AS looking into the URI >> to figure out which one it is. I think that is harder for implementatio= ns >> and more likely to have security issues down the road. >> >> John B. >> >> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: >> >> Hi all, >> >> thanks for you patience. Brian and myself iterated on modifying the text >> to cover the logical identifier use case, highlighting the security >> implications of going that route. You can find the revised text in >> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-in= dicators.xml, >> see the commits in the history from January 21 for the specific changes. >> >> Note: I also had a chat with John offline, and he expressed the desire t= o >> split the resource parameter in two distinct parameters to better signal >> the intended usage. I am sure he can elaborate. I have nothing against i= t >> in principle, as long as we leave nothing as exercise to the reader and = we >> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a >> chance to speak w Brian about it. If the discussion stretches further, I >> would suggest we pause it and let him enjoy his time off for the rest of >> the week. >> >> >> >> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef >> wrote: >> >> Thank you guys! >> >> >> >> On Monday, January 21, 2019, Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> absolutely. Brian and myself already started working on some language, >> however this week he is in vacation hence it might take few days before = we >> come back to the list with something. >> >> Cheers, >> >> V. >> >> >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> wrote: >> >> Brian, Vittorio, >> >> >> >> To move this discussion forward, can you guys suggest some text to make >> the logical identifier usage clearer? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> >> wrote: >> >> As I suggested before, I do think that's within the bounds of the draft'= s >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> wrote: >> >> [sent to John only by mistake, resending to the ML] >> >> >> >> In Azure AD v1 & ADFS, that's resource.. It could be used for both >> network and logical ids, with the concrete usage in the wild I described >> earlier. >> >> In Azure AD v2, the resource as explicit parameter (network, logic or >> otherwise) is gone and is expressed as part of the scope string of all t= he >> scopes requested for a given resource- but it still exist in practice th= o >> as it still end up in the resulting aud of the issued token. >> >> This is 9 months old info hence >> >> >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >> >> What is the parameter that Microsoft is using? >> >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >> +1 to Mike and John=E2=80=99s comments. >> >> Phil >> >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific networ= k-addressable URL >> whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWT= s) can refer to one >> or more logical resources. They are different, if related, things. >> >> >> >> Note that the ACE WG is proposing to register a logical audience >> parameter =E2=80=9Creq_aud=E2=80=9D in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >> based on feedback from OAuth WG members. This is a general OAuth >> parameter, which any OAuth deployment will be able to use. >> >> >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience work is >> already happening in another draft. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> We need to decide if we want to make a change. >> >> >> >> For security we are location centric. >> >> >> >> I prefer to keep resource location separate from logical audience that >> can be a scope or other parameter. >> >> >> >> If becomes harder for people to use the parameter correctly if we are to= o >> flexible. >> >> >> >> I would rather have a separate logical audience parameter if we think we >> want one. >> >> >> >> John B. >> >> >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell > wrote: >> >> No apology needed, Rifaat. And I apologize if what I said came off the >> wrong way. I was just trying to make light of the situation.. And I agre= e >> that we should not be hamstrung by the process and there are times when = it >> makes sense to be flexible with things. >> >> >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> >> >> So maybe the draft is okay as is? >> >> >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then feel free to do that. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >> Yes the logical resource can be provided by "scope" >> >> >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> >> >> John B. >> >> >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _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._ --000000000000b7e8e3058085347f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I pl= an on joining the meeting today at noon eastern time to discuses this littl= e ditty. I hope others who have a stake in it can too.

The proposed changes that Vittorio and I put togeth= er can be seen in the diff of this pull request https= ://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I eve= n put a xml2rfc'ed text version on https://github.com/i= etf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maint= ain that is the most straightforward way forward with all this. Yet another= new additional parameter could be defined for the logical case but I strug= gle to see the value in doing so. The 'resource' is URI that points= to the resource. The level of specificity of that pointer is intentionally= a bit fuzzy and application/deployment specific. Is https://graph.microsoft.com (mentioned in the documen= tation previously linked) a location or an abstract identifier or both? The= document already (somewhat awkwardly) describes using a "base URI&quo= t; for the application or resource. Is that a a location or an abstract ide= ntifier? Or kinda both?

In addition to the co= ncerns others have expressed about "req_aud", I"d note that = draft-ietf-ace-oauth-params defines its use only at the token endpoint as o= ne of the "additional parameters for requesting an access token from a= token endpoint in the ACE framework". Whereas the resource-indicators= draft scope includes the authorization endpoint too. Furthermore, while th= e ACE WG is building on OAuth, for all intents and purposes ACE and regular= OAuth are different worlds and I think a reference in regular OAuth docume= nt like this one to "Additional OAuth Parameters for Authorization in = Constrained Environments (ACE)" would be a disservice to just about ev= eryone.



=



On Thu, Jan 24,= 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hannes sent an update to this meeting here:

Regards,
=C2=A0Rifaat


On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@= microsoft.com> wrote:

The virtual offic= e hours in my calendar start 1/2 hour before that.=C2=A0 If the time has ch= anged, can you have the meeting organizer update the calendar entry?=

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

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

=C2=A0<= /u>

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org=
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

All,

=C2=A0

This co= ming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Vi= rtual Office meeting.

Feel fr= ee to attend the meeting to discuss this topic to try to get to a conclusio= n on this.

=C2=A0

Regards= ,

=C2=A0R= ifaat

=C2=A0

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <= gffletch=3D40= aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'= ;m not 100% convinced that 'audience' and 'logical resource'= ; are completely overlapping concepts. We can potentially make them complet= ely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deploymen= ts using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:<= u>

As mentioned below, I agree the two can be separated= - but I also agree with George on the need to be clear an easy to reference= for developers.

Just adding a reference to req_aud would just raise = the cyclomatic complexity of the specs, which is already unusably high for = mere mortals in the OAuth2/OIDC family of specs.

=C2=A0

One additional complication is that this specificati= on is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic iden= tifier. If the parameter you are defining here has a different semantic, at= the very least it would seem good hygiene to rename it to avoid collision = and confusion.

=C2=A0

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John= =E2=80=99s logic.=C2=A0 The physical resource and logical resource should u= se different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresou= rce=E2=80=9D and =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I believe we=E2=80= =99re good to go, as-is.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I= think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting= with RS https://fire.hhs.com= as the resource wants a OAuth token with an audience of HHS and a scope of= read.

Without proof of possession we need to keep bad RS from asking for token= s with scopes and audiences of other RS that can be replayed.=

I really like keeping the resource simple and unspoofable, it is the URI= of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span m= ore than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI = to figure out which one it is.=C2=A0 I think that is harder for implementat= ions and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated o= n modifying the text to cover the logical identifier use case, highlighting= the security implications of going that route. You can find the revised text in=C2=A0= https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indic= ators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he ex= pressed the desire to split the resource parameter in two distinct paramete= rs to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we le= ave nothing as exercise to the reader and we are very clear on usage (e.g. = mutual exclusivity, etc) but didn't have a chance to speak w Brian abou= t it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of= the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:=

Hi Rifaat,

absolutely. Brian and myself already started working= on some language, however this week he is in vacation hence it might take = few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys sugges= t some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within = the bounds of the draft's definition of 'resource' as a URI. An= d that perhaps all that's needed is some minor adjustment and/or augmen= tation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

[sent to John only by mistake, r= esending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that&= #39;s=C2=A0resource.. It could be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.

In Azure AD v2, = the resource as explicit parameter (network, logic or otherwise) is gone an= d is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it s= till end up in the resulting=C2=A0aud=C2=A0of the issued token.

This is 9 months= old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com>= wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the= established process. In my former position I wasn't monitoring those d= iscussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and= given that I worked with actual deployments and developers using a similar= parameter for a long time, I thought prudent to bring this up. I really ap= preciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidanc= e on how to work with the concept of logical resource in a standard complia= nt way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-ind= icators or elsewhere.

That said. Reading through the draft, it would appea= r that most of the reasons for which the spec was created apply to both the= network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to = the intended audience, avoiding overloading scopes with resource indicating= parts... those all apply to network addressable and logic identifiers alik= e. And both parameters are expected to result in audience restricted tokens. It seems the only difference come= s at token usage time, with the network addressable case giving more guaran= tees that the token will go to its intended recipient, but the request and = audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I en= countered in the wild in the last 5 years of using the resource parameter i= n the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in t= he app config at deployment time. Those aren't fringe cases I occasiona= lly encountered: the resource parameter in Azure AD v1 and ADFS was mandato= ry, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the s= ecurity advantages of the network addressable case aren't as pronounced= as in the case in which the client discovers the resource identifier at ru= ntime. This isn't just because there is no specification suggesting location should be explicitly indicated, it= 's because there are many practical advantages at development and deplo= yment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, peop= le will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two= different documents is better than ignoring he logical identifier case alt= ogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confu= sion and ultimately not be as useful to the developer community as it could= be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2= =80=99s comments.=C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40mic= rosoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly bas= ed on feedback from OAuth WG members.=C2=A0 This is a general OAuth paramet= er, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with= things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

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

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract = identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>=
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Fr=
amework defining request 
parameters that enable a client to explicitly =
signal to an authorization server 
about the location of the protected res=
ource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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


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


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, 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 me= ssage and any file attachments from your computer. Thank you.

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


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution 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 messa= ge and any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

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

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

<= 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. --000000000000b7e8e3058085347f-- From nobody Mon Jan 28 07:08:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE8124408 for ; Mon, 28 Jan 2019 07:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 Y8nbHi0bJmrS for ; Mon, 28 Jan 2019 07:08:36 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60052.outbound.protection.outlook.com [40.107.6.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454FE1200D7 for ; Mon, 28 Jan 2019 07:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TZ6SY+NJGdDly4E3pwH1QjRCyKqwQOpkvV2jkFZErCE=; b=cDS0Nei3K3HDiOPz9E2Iz5Zjwfin3fDhUMWND2hrtIaJpuZ9llbfqNMYojfipv/Sk+M26bdIEAZ8sdXOQ6Kj4NZZxmu5PbX4G7v1jFQ/tfzy3Aq0jA4i69ULqNKtmfEtKk404xCGx8eB/4NR78KXHcaCuIdcf+1Hu5W9z4z15Gg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1983.eurprd08.prod.outlook.com (10.173.74.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.20; Mon, 28 Jan 2019 15:08:33 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%7]) with mapi id 15.20.1558.023; Mon, 28 Jan 2019 15:08:33 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: draft-parecki-oauth-browser-based-apps-02: Concluding the call for adoption Thread-Index: AdS3G05kap0xG1cXRYuPuzEorBKzJw== Date: Mon, 28 Jan 2019 15:08:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1983; 6:lCdIBr5qBb8+mrFFqifUikb7JZLdF0vCH/jiPM0XyWu9okApnla58PjFpIPBxr9ktDiprH3PYfhyOKkKrjIJ7knIXFDFkXzFRYDmaSSZK48uLhEwNE8/C0qG0KQ4m2IzAEmGUpnfgVlJ53d5gIeIYaswaMGHeG0s7Ms1yJaTnnhZuzxDlQ3vYKieHjZbJ9auD0B1SwXx4dnWG53vnHOc05oOOh/aAnpSAzv09dEya37hI6wsmg0eg+Qvv/P40f6WhfjgGD8W/Y7h2aU8yUY/xzQvk0xS3NqAqln/RBiVWmX2K1OD4tbYy7rlOUWNszN+AAlA+3ZTzdmFjqerqRXXo1QHaMCqTFpiUvXyk2h1hY1BFKcpFp/O1Q5Lks8u2ix9z73hCPueBcHCOzVOyUyc0wLEcvf3ArPRuk6Ma4p0noqfbEZV2EPlkctLba/zdOv9vQ3GerlG5j0heYrB63A0NQ==; 5:2zGaMGWPx0m5t10ijLnjmHp3PsC7U0Vx7udJ8O4JIkgEGRxzpqSuF8+ziglEtTs2JA04JvVxf0deoE5B9oFQiJcOsQdyQ3SxewiccD7Dzp3P29louAZ4+sLuo/8GsgQV4IvyFWe12wQJKhEC2vxo927uDdrPvePQw2maLJymRT+YdIdgJY03/P2byD0amUAtooNstYYlxVbfSCSVnxZcUQ==; 7:LKg3mJq+rNW2eh8BiRZ8T0DuW/5RAUlXtPkwsIjHprOayeAR4u2ODZS/zUsoD+PKxDkh8PiRCejvjr3OHR2toKGdg4HMrO9UV+PyAMRjDXmGyJNu1h42alIokDfjoa7Rf2SAeCl4lAtZO+cr60JA1w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a6922488-85c6-4484-db54-08d685327850 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1983; x-ms-traffictypediagnostic: VI1PR0801MB1983: x-microsoft-antispam-prvs: x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(376002)(136003)(346002)(53754006)(199004)(189003)(51914003)(40434004)(478600001)(66066001)(6116002)(66574012)(54896002)(6506007)(6306002)(97736004)(6436002)(14454004)(53936002)(9686003)(236005)(3846002)(316002)(2906002)(7736002)(606006)(71190400001)(7696005)(966005)(86362001)(106356001)(5024004)(486006)(14444005)(186003)(790700001)(4744005)(99286004)(6916009)(72206003)(105586002)(81166006)(25786009)(81156014)(33656002)(55016002)(102836004)(71200400001)(8676002)(68736007)(476003)(74316002)(256004)(8936002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1983; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Fh9WENKZ7k7HNKrnlu1/W/5caa9/F97U6hTJTlJ+YLq5ZdFvghn3W+7IOKA8DADlpkgmFn5O5udU8d4DlnAQpVs3HBn7NNb8IDmixcm9vLbQM1vEg78Sxx/HkgRlmw5DK1PPGyxgzCg9HJy8BAM1ZF0j44iBt0bMS7fjsAlCDRJX0lc5/Ry7D+oWtw8Wz/e55N1wCpkiEYCd2dy34CZhuV/llm/hcDMVoHLDSnR6mIDr6XHTDL71q0uODFujpEteExDMvC40B34C31miRHVIE9YofxWtBaVeeT6nMV0EBGQpD1OSN0kO95G800d/p72Jts31xufkE+m72TTlTrIaRYavDPAWH5keqO8ixcfnFdAv3mlRnWAWw9B/wnkl8ndfOMvAa2HCcqdKgO/tixS6yGz+k9LZZHB2qyy+bSx0u/U= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21126535ED46F9AC9BCC8DDEFA960VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6922488-85c6-4484-db54-08d685327850 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 15:08:33.1521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1983 Archived-At: Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-02: Concluding the call for adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 15:08:39 -0000 --_000_VI1PR0801MB21126535ED46F9AC9BCC8DDEFA960VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, in https://mailarchive.ietf.org/arch/msg/oauth/KVzyK3ROQuuMWkZIZ5PqIM3ol8Y = we started a call for adoption and we only received positive feedback. Hence, we have asked the draft authors (after discussion with the AD) to re= -submit it as draft-ietf-oauth-browser-based-apps-00 version. Thanks for the feedback. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21126535ED46F9AC9BCC8DDEFA960VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

in https://mailarchive.ietf.org/arch/msg/oauth/KVzyK3ROQuuMWkZIZ5PqIM3ol8Y= we started a call for adoption and we only received positive feedback.

Hence, we have asked the draft authors (after discus= sion with the AD) to re-submit it as draft-ietf-oauth-browser-based-apps-00= version.

 

Thanks for the feedback.

 

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21126535ED46F9AC9BCC8DDEFA960VI1PR0801MB2112_-- From nobody Mon Jan 28 08:04:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C733130E96 for ; Mon, 28 Jan 2019 08:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 pbMyDZRYOCcv for ; Mon, 28 Jan 2019 08:04:52 -0800 (PST) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19992130E8E for ; Mon, 28 Jan 2019 08:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548691489; bh=Tq/oRb5W8Rp90NsEEk8nGhNeS2zltNpGelssDYcqfYM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=El0WkxYe47FubHq3GoK8aEp2Ylr5aFOeq+KlnnIp5ZwrGMvKYYNoFQkMiyijDixs4hFdGuvHrtlbBRI1bptTir6vKzCmTZNeNZJAixct3gOR/2kSXZS56+YECMe4wMmnXlmygUUOEdmIih8HIkT8g+yUmBVov6L0eJlOtyoaUYH/J9avs5Pfd6ZaK8AmeDPNFynmMRsFPDFukUTchEXZE9eHXUy4TTW0cGtAB3K5RItu5eHcyg0aj4rAoWwanh3ZZ4DPCB1QyoraZwAR7yJ2KSK+Rd0c5cLyDfydK/dKRciWqgIR6SbJYEpmZNr8jQzs9KaahuMQVVdUn2qMe6zGyQ== X-YMail-OSG: qYfBc5YVM1kgTy6nvAU.pGVUnt1XjeUvUaNrF703aXYgG61UyuKWie0yiOgpiTy AcEPRf.Zk2RPdmE_gik6tKA6QlIm6uEFXzWFXa6Lx9aXmrmHyptrU34y6uqztIXTXlbU3KqR6joz 2x8g2Et5uTJFkYhuZnLZ2QHQFcA3YD0AEY.8gJt0FZO7T6VOm2ds5Mtwp54HcDT.s3PFEo3XQpQo sBPt8TH0Qmv5UsO20_2BkFmlahIN1U_613GqJxUlyJpgyls2jhccbITWwblDjg_RdvHXqH7QegBK 8bQ.HKSH7IU6EYYpAEAQjmL7rqvTBUeozdiAyadbKesCH5EmzMCQYNeKEOilzVHra83IYIPCIrKX gG3raCoXXwy_oxqI6rkT2.ENVQEuEy2H12ZA8xw7iyOJi4hbXTmRuyKqaN7.50meicDa0AaeY9.H 25Ad8NvZnzQyICnmNzrTOO9BydMspFmJ0iJ19peXR0OXaWOJtARM96qM.iI5WYg9e1CIbtsoac8E 683P_1IdF25JI1TUVZIhL0mVJTO39nZ7mVVj8frFCex22X_elMEK0OQQ6zgVgf7TFM.LPNdTcBf8 7E1_ADgnE7p4m41fRSCzy73EU1M02ZnRhhKSIfbucQpV0xouti_OmqrId_3SGzeBv21s4GjvCRaq iShqQPZwpF4WPUvuOu6IiaEdXj3hPJag3ohWXpsHwSdCpE.ZNG3i9gJ4JVgWmFYoW9ZcTNCL0XPh lv_OHpNe9ceYM1z1iZWGvorkOYAuCIozj2Qh3VsrHSNUIfA0OkgdJbGTUeNpfc9BJjfQkHPml.IT myDZDxGjpQi1Ay7AO4520.qmUD5CWR2YfR9FcVILA_V5dApnVa30Fcwv8ByH8zlItU_XigZDvucg aEg7lxYliDQTBeVwtx6M16AGQi5S.imdoHZZgT8SG8DnY6rRGuTrw3gW4JoFhns35km1gHnm1OLj TYOZITBoMax.ToMKNKHtwaGDn6b2W.TP5f1XRHnN97hjXH3YaCMwQxR4deVrnPEBg.mbgPNKjFMX Gz_FG0ntEiueEPVsYG2d5Xc6P7jW9NVLpYgAtyMlYReX4I3144HZSh0IbA7o09Bkx Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jan 2019 16:04:49 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f53999bd278fbc2f126a777ee6997801; Mon, 28 Jan 2019 16:04:44 +0000 (UTC) To: Brian Campbell Cc: "oauth@ietf.org" , Vittorio Bertocci References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> Date: Mon, 28 Jan 2019 11:04:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CDE6E360523360A260F9E1D1" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 16:04:57 -0000 This is a multi-part message in MIME format. --------------CDE6E360523360A260F9E1D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possible there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the "real" endpoints, then it's also "logical" in that context and not an exact location. This brings me to the conclusion that all the resource identifiers are "logical" along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS. Thanks, George On 1/28/19 9:07 AM, Brian Campbell wrote: > I plan on joining the meeting today at noon eastern time to discuses > this little ditty. I hope others who have a stake in it can too. > > The proposed changes that Vittorio and I put together can be seen in > the diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and > I even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease > of reference. I maintain that is the most straightforward way forward > with all this. Yet another new additional parameter could be defined > for the logical case but I struggle to see the value in doing so. The > 'resource' is URI that points to the resource. The level of > specificity of that pointer is intentionally a bit fuzzy and > application/deployment specific. Is https://graph.microsoft.com > (mentioned in the documentation previously linked) a location or an > abstract identifier or both? The document already (somewhat awkwardly) > describes using a "base URI" for the application or resource. Is that > a a location or an abstract identifier? Or kinda both? > > In addition to the concerns others have expressed about "req_aud", I"d > note that draft-ietf-ace-oauth-params defines its use only at the > token endpoint as one of the "additional parameters for requesting an > access token from a token endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization endpoint > too. Furthermore, while the ACE WG is building on OAuth, for all > intents and purposes ACE and regular OAuth are different worlds and I > think a reference in regular OAuth document like this one to > "Additional OAuth Parameters for Authorization in Constrained > Environments (ACE)" would be a disservice to just about everyone. > > > > > > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > > wrote: > > Hannes sent an update to this meeting here: > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > Regards, >  Rifaat > > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > > > wrote: > > The virtual office hours in my calendar start 1/2 hour before > that.  If the time has changed, can you have the meeting > organizer update the calendar entry? > > Thanks, > > -- Mike > > *From:* Rifaat Shekh-Yusef > > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > > *Cc:* Vittorio Bertocci >; Mike Jones > >; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > All, > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a > scheduled OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic to try > to get to a conclusion on this. > > Regards, > >  Rifaat > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > > wrote: > > +1 > > Also, I don't really like the parameter name 'req_aud' :) > I'm not 100% convinced that 'audience' and 'logical > resource' are completely overlapping concepts. We can > potentially make them completely overlapping but we need > text to that effect. > > I also believe that we don't have a complete solution for > all deployments using exact locations (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be separated- > but I also agree with George on the need to be clear > an easy to reference for developers. > > Just adding a reference to req_aud would just raise > the cyclomatic complexity of the specs, which is > already unusably high for mere mortals in the > OAuth2/OIDC family of specs. > > One additional complication is that this specification > is reusing a parameter that is already used in a > *very* large number of production systems (small > example here > ), > and whose concrete semantic happens to be prevalently > logic identifier. If the parameter you are defining > here has a different semantic, at the very least it > would seem good hygiene to rename it to avoid > collision and confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > > wrote: > > I agree with John’s logic.  The physical resource > and logical resource should use different > identifiers. Fortunately, we already have > “resource” and “req_aud” for these parameters.  I > believe we’re good to go, as-is. > > -- Mike > > *From:* OAuth > *On Behalf Of > *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > I don't think they are necessarily mutually > exclusive, that is why I think there is value in > allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing > that a client interacting with RS > https://fire.hhs.com as the resource wants a OAuth > token with an audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS > from asking for tokens with scopes and audiences > of other RS that can be replayed. > > I really like keeping the resource simple and > unspoofable, it is the URI of the RS where you are > presenting the AT. > > I prefer to keep that separate from the logical > resource that may span more than one RS endpoint. > > Merging the two and we are probably back at the AS > looking into the URI to figure out which one it > is.  I think that is harder for implementations > and more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself > iterated on modifying the text to cover the > logical identifier use case, highlighting the > security implications of going that route. You > can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from January 21 > for the specific changes. > > Note: I also had a chat with John offline, and > he expressed the desire to split the resource > parameter in two distinct parameters to better > signal the intended usage. I am sure he can > elaborate. I have nothing against it in > principle, as long as we leave nothing as > exercise to the reader and we are very clear > on usage (e.g. mutual exclusivity, etc) but > didn't have a chance to speak w Brian about > it. If the discussion stretches further, I > would suggest we pause it and let him enjoy > his time off for the rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat > Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio > Bertocci > wrote: > > Hi Rifaat, > > absolutely. Brian and myself already > started working on some language, > however this week he is in vacation > hence it might take few days before we > come back to the list with something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat > Shekh-Yusef > wrote: > > Brian, Vittorio, > > To move this discussion forward, > can you guys suggest some text to > make the logical identifier usage > clearer? > > Regards, > >  Rifaat > > On Mon, Jan 21, 2019 at 10:32 AM > Brian Campbell > > > wrote: > > As I suggested before, I do > think that's within the bounds > of the draft's definition of > 'resource' as a URI. And that > perhaps all that's needed is > some minor adjustment and/or > augmentation of some text to > make it more clear. > > On Sun, Jan 20, 2019 at 7:39 > PM Vittorio Bertocci > > > wrote: > > [sent to John only by > mistake, resending to the ML] > > In Azure AD v1 & ADFS, > that's resource.. It could > be used for both network > and logical ids, with the > concrete usage in the wild > I described earlier. > > In Azure AD v2, the > resource as explicit > parameter (network, logic > or otherwise) is gone and > is expressed as part of > the scope string of all > the scopes requested for a > given resource- but it > still exist in practice > tho as it still end up in > the resulting aud of the > issued token. > > This is 9 months old info > hence > > On Sun, Jan 20, 2019 at > 17:58 John Bradley > > > wrote: > > What is the parameter > that Microsoft is using? > > On 1/20/2019 3:59 PM, > Vittorio Bertocci wrote: > > First of all, it > wasn't my intent > to disrupt the > established > process. In my > former position I > wasn't monitoring > those discussions > hence I didn't > have a chance to > offer feedback. > When I saw > something that > gave me the > impression might > lead to issues, > and given that I > worked with actual > deployments and > developers using a > similar parameter > for a long time, I > thought prudent to > bring this up. I > really appreciate > Rifaat's stance on > this. End of preamble. > > Ultimately my goal > is for developers > to have guidance > on how to work > with the concept > of logical > resource in a > standard compliant > way, hence it > doesn't strictly > matter whether the > definition of the > corresponding > parameter lives > in oauth-resource-indicators > or elsewhere. > > That said. Reading > through the draft, > it would appear > that most of the > reasons for which > the spec was > created apply to > both the network > addressable and > the logical > resource types: > knowing what keys > to use to encrypt > the token, > constrain access > tokens to the > intended audience, > avoiding > overloading scopes > with resource > indicating > parts... those all > apply to network > addressable and > logic identifiers > alike. And both > parameters are > expected to result > in audience > restricted tokens. > It seems the only > difference comes > at token usage > time, with the > network > addressable case > giving more > guarantees that > the token will go > to its intended > recipient, but the > request and > audience > restriction syntax > seems to be > exactly the same. > > On top of this: in > the 99.999% of the > scenarios I > encountered in the > wild in the last 5 > years of using the > resource parameter > in the MS > ecosystem, the > resource > identifier was > known at design > time: the > developer > discovered it out > of band and placed > it in the app > config at > deployment time. > Those aren't > fringe cases I > occasionally > encountered: the > resource parameter > in Azure AD v1 and > ADFS was > mandatory, hence > literally every > solution i saw or > touched used it. > As Brian > suggested, this is > a scenario where > the security > advantages of the > network > addressable case > aren't as > pronounced as in > the case in which > the client > discovers the > resource > identifier at > runtime. This > isn't just because > there is no > specification > suggesting > location should be > explicitly > indicated, it's > because there are > many practical > advantages at > development and > deployment time to > be able to use > logical > identifiers- and > if the /concrete > /security > advantages don't > apply to the their > case, people will > simply not comply. > > In summary: > creating two > different > parameters in two > different > documents is > better than > ignoring he > logical identifier > case altogether, > however I think > that not > acknowledging the > logical id case > in oauth-resource-indicators > is going to create > confusion and > ultimately not be > as useful to the > developer > community as it > could be. > > On Sat, Jan 19, > 2019 at 12:38 Phil > Hunt > > > wrote: > > +1 to Mike and > John’s comments. > > Phil > > > On Jan 19, > 2019, at 12:34 > PM, Mike Jones > > > wrote: > > I also > agree that > “resource” > should be > a specific > network-addressable > URL > whereas a > separate > audience > parameter > (like > “aud” in > JWTs) can > refer to > one or > more > logical > resources. > They are > different, > if > related, > things. > > Note that > the ACE WG > is > proposing > to > register a > logical > audience > parameter > “req_aud” > in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - partly > based on > feedback > from OAuth > WG > members.  > This is a > general > OAuth > parameter, > which any > OAuth > deployment > will be > able to use. > > I > therefore > believe > that no > changes > are needed > to > draft-ietf-oauth-resource-indicators, > as the > logical > audience > work is > already > happening > in another > draft. > > -- Mike > > *From:* > OAuth > > > *On Behalf > Of *John > Bradley > *Sent:* > Saturday, > January > 19, 2019 > 9:01 AM > *To:* > Brian > Campbell > > > *Cc:* > Vittorio > Bertocci > >; > IETF oauth > WG > > > *Subject:* > Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > We need to > decide if > we want to > make a > change. > > For > security > we are > location > centric. > > I prefer > to keep > resource > location > separate > from > logical > audience > that can > be a scope > or other > parameter. > > If becomes > harder for > people to > use the > parameter > correctly > if we are > too flexible. > > I would > rather > have a > separate > logical > audience > parameter > if we > think we > want one. > > John B. > > On Sat, > Jan 19, > 2019, > 11:41 AM > Brian > Campbell > > wrote: > > No > apology > needed, > Rifaat. > And I > apologize > if > what I > said > came > off > the > wrong > way. I > was > just > trying > to > make > light > of the > situation.. > And I > agree > that > we > should > not be > hamstrung > by the > process > and > there > are > times > when > it > makes > sense > to be > flexible > with > things. > > On > Fri, > Jan > 18, > 2019 > at > 6:22 > PM > Rifaat > Shekh-Yusef > > > wrote: > > Sorry > Brian, > I > was > not > clear > with > my > statement. > > I > meant > to > say > that > we > should > not > allow > the > process > to > prevent > the > WG > from > producing > a > quality > document > without > issues, > assuming > there > is > an > issue > in > the > first > place. > > Ideally > we > want > to > get > these > identified > during > the > WGLC, > but > things > happen > and > sometimes > the > WG > misses > something. > > > I > hear > you > and > agree > that > this > make > things > difficult > for > authors. > We > will > make > sure > that > this > does > not > become > the > norm, > and > we > will > try > to > stick > to > the > process > as > much > as > possible. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 5:35 > PM > Brian > Campbell > > > wrote: > > Thanks > Rifaat. > Process > is > as > process > does, > right? > I > do > kinda > want > to > grumble > about > WGCL > having > passed > already > but > that's > mostly > because > replying > to > these > kinds > of > threads > is > hard > for > me > and > I'll > just > get > over > it... > > > As > far > as > I > understand > things, > the > security > concerns > come > into > play > when > the > client > is > being > told > the > by > the > resource > how > to > identity > the > resource > like > is > described > in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and > using > the > actual > location > in > that > context > ,along > with > some > other > checks > prescribed > in > that > draft, > prevents > the > kind > of > issues > John > described > earlier > in > the > thread. > > > In > cases > where > the > client > knows > the > resource > a > priori > or > out-of-band > or > configured > or > whatever, > I > don't > think > the > same > security > concerns > arise. > And > using > such > a > known > value, > be > it > an > actual > location > or > logical > representation, > would > be > okay. > > The > resource-indicators > draft > is > admittedly > somewhat > location-centric > in > how > it > talks > about > the > value > of > the > 'resource' > parameter. > But > ultimately > it > defines > it > as > an > absolute > URI > that > indicates > the > location > of > the > target > service > or > resource > where > access > is > being > requested. > A > location > can > be > varying > shades > of > abstract > and > I'd > say > that > using > a > URI > as > 'resource' > parameter > value > that's > a > logical > identifier > that > points > to > some > resource > is > well > within > the > bounds > of > the > draft. > > > So > maybe > the > draft > is > okay > as > is? > > Or > perhaps > that's > too > much > to > be > left > as > an > exerciser > to > the > reader? > And > some > text > should > be > added > and/or > adjusted > so > the > resource-indicators > draft > would > be > a > little > more > open/clear > about > the > parameter > value > potentially > being > more > of > a > logical > or > abstract > identifier > and > not > necessarily > a > network > addressable > URL? > > On > Fri, > Jan > 18, > 2019 > at > 1:18 > PM > Rifaat > Shekh-Yusef > > > wrote: > > I > wouldn't > worry > too > much > about > the > process. > > If > it > makes > sense > to > update > the > document, > then > feel > free > to > do > that. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 3:08 > PM > John > Bradley > > > wrote: > > Yes > the logical > resource > can > be > provided > by > "scope" > > Some > implementations > like > Ping > and > Auth0 > have > been > adding > another > parameter > "aud" > to > identify > the > logical > resource > and > then > using > scopes > to > define > permissions > to > the > resource. > > Fortunately, > we > are > using > a > different parameter > name > so > not > stepping > on > that.. > > We > could > go > back > and > try > to > add > text > explaining > the > difference, > but > we > are > quite > late > in > the > process. > > > I > agree > that > a > logical > resource > parameter may > be > helpful, > but > perhaps > it > should > be > a > separate > draft. > > John > B. > > On > Fri, > Jan > 18, > 2019 > at > 4:38 > PM > Richard > Backman, > Annabelle > > > wrote: > > Doesn’t > the > “scope” > parameter > already > provide > a > means > of > specifying > a > logical > identifier? > > -- > > > Annabelle > Richard > Backman > > AWS > Identity > > *From: > *OAuth > > > on > behalf > of > Vittorio > Bertocci > > > *Date: > *Friday, > January > 18, > 2019 > at > 5:47 > AM > *To: > *John > Bradley > > > *Cc: > *IETF > oauth > WG > > > *Subject: > *Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > Thanks > John > for > the > background. > > > I > agree > that > from > the > client > validation > PoV, > having > an > identifier > corresponding > to > a > location > makes > things > more > solid. > > That > said: > the > use > of > logical > identifiers > is > widespread, > as > it > has > significant > practical > advantages > (think > of > services > that > assign > generated > hosting > URLs > only > at > deployment > time, > or > services > that > are > somehow > grouped > under > the > same > logical > audience > across > regions/environment/deployments). > People > won't > stop > using > logical > identifiers, > because > they > often > have > no > alternative > (generating > new > audiences > on > the > fly > at > the > AS > every > time > you > do > a > deployment > and > get > assigned > a > new > URL > can > be > unfeasible). > Leaving > a > widely > used > approach > as > exercise > to > the > reader > seems > a > disservice > to > the > community, > given > that > this > might > lead > to > vendors > (for > example > Microsoft > and > Auth0) > keeping > their > own > proprietary > parameters, > or > developers > misusing > the > ones > in > place; > would > make > it > hard > for > SDK > developers > to > provide > libraries > that > work > out > of > the > box > with > different > ASes; > and > so > on. > > Would > it > be > feasible > to > add > such > parameter > directly > in > this > spec? > That > would > eliminate > the > interop > issues, > and > also > gives > us > a > chance > to > fully > warn > people > about > the > security > shortcomings > of > choosing > that > approach. > > On > Thu, > Jan > 17, > 2019 > at > 4:32 > PM > John > Bradley > > > wrote: > > We > have > discussed > this. > > Audiences > can > certainly > be > logical > identifiers. > > > This > however > is > a > more > specific > location.  > The > AS > is > free > to > map > the > location > into > some > abstract > audience > in > the > AT. > > From > a > security > point > of > view > once > the > client > starts > asking > for > logical > resources > it > can > be > tricked > into > asking > for > the > wrong > one > as > a > bad > resource > can > always > lie > about > what > logical > resource > it > is. > > If > we > were > to > change > it, > how > a > client > would > validate > it > becomes > challenging > to > impossible. > > > The > AS > is > free > to > do > whatever > mapping > of > locations > to > identifiers > it > needs > for > access > tokens. > > Some > implementations > may > want > to > keep > additional > parameters > like > logical > audience, > but > that > should > be > separate > from > resource. > > John > B. > > On > 1/17/2019 > 9:56 > AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > > The > text > you > quoted > is > copied > form > the > abstract > of > the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > >  Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > > > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > > > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > >  Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use > of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited. > If > you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited.. > If you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > _______________________________________________ > OAuth > mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This > email may contain confidential > and privileged material for > the sole use of the intended > recipient(s). Any review, use, > distribution or disclosure by > others is strictly > prohibited... If you have > received this communication in > error, please notify the > sender immediately by e-mail > and delete the message and any > file attachments from your > computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------CDE6E360523360A260F9E1D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possible there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the "real" endpoints, then it's also "logical" in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are "logical" along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS.

Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:
I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too.

The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deployment specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both?

In addition to the concerns others have expressed about "req_aud", I"d note that draft-ietf-ace-oauth-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would be a disservice to just about everyone.






On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hannes sent an update to this meeting here:

Regards,
 Rifaat


On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@microsoft.com> wrote:

The virtual office hours in my calendar start 1/2 hour before that.  If the time has changed, can you have the meeting organizer update the calendar entry?

 

                                                          Thanks,

                                                          -- Mike

 

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

All,

 

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this.

 

Regards,

 Rifaat

 

 

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% convinced that 'audience' and 'logical resource' are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:

As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers.

Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs.

 

One additional complication is that this specification is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion.

 

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I agree with John’s logic.  The physical resource and logical resource should use different identifiers.  Fortunately, we already have “resource” and “req_aud” for these parameters.  I believe we’re good to go, as-is.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

 

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

 

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

 

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

 

Regards,

 Rifaat

 

 

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

 

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]

 

In Azure AD v1 & ADFS, that's resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.

This is 9 months old info hence

 

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

 

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

 

 

 

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:

+1 to Mike and John’s comments. 

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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


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

 

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

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

 

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

 

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

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

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

--------------CDE6E360523360A260F9E1D1-- From nobody Mon Jan 28 10:28:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26213102D for ; Mon, 28 Jan 2019 10:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 iWMFJ8FGbyIa for ; Mon, 28 Jan 2019 10:28:15 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650095.outbound.protection.outlook.com [40.107.65.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75602131110 for ; Mon, 28 Jan 2019 10:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+U87KDGc6z6Qu22IM4f8J97zO0Wuvziad4CA9ZG8Nvo=; b=Hml9PZ6GmisdUs670+TjhmXdTiHerGepF32Pg0Z2hXZOrAaT5HXBUiOBi9Voa6+VUhdjHVHhomZqh+42HkN+jbQJwZkc5Mm6lV7hXJe6TNLH/DZE/RYvMTTss2I2l1QiJ4/gzPJvyzFVjtQUquAVlduMdZkQNO937BFWhho3GL4= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0305.namprd00.prod.outlook.com (52.132.19.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1611.0; Mon, 28 Jan 2019 18:28:12 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::142f:63b7:9c88:3e65%6]) with mapi id 15.20.1614.000; Mon, 28 Jan 2019 18:28:12 +0000 From: Mike Jones To: George Fletcher at aol.com , "bcampbell@pingidentity.com" CC: "oauth@ietf.org" , Vittorio Bertocci Thread-Topic: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUreMSm6zRRv4Nr0eerioJ6LCFT6Wzcp6AgABNkQCAABqbAIABMd2AgABiBYCAAAiJAIAAAu6AgAAmUgCAAC6ggIAA30eAgAAm6gCAADowsIAAArOAgAHKeICAACE4AIAAC1UAgADX2YCAACJwAIAAdm6AgAAP8ICAApBGgIAAJMyAgAABgfCAAA21AIAAAngAgAGfMgCAACq5MIAADzAAgAWgMYCAACC1gIAAJ2gg Date: Mon, 28 Jan 2019 18:28:12 +0000 Message-ID: References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> In-Reply-To: <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-01-28T18:28:10.0333899Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=665581f7-17e5-426f-a31c-b2ef4492937e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [100.44.199.18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0305; 6:KaSDBtyAnzC2eTDLZ243yHY3g2L+8hjyKc9UXat3LIuewQeJ1ht7EpyDf8dmoQPl/SncfeKgrKmS+M5qwboqmeXsiU4/iGZ8icT/3vSV/YV+XTzxVg2M0c5OSXL5A1GoA8FC824pfZcPRUoYecQwjRkhNkS39gcSq5r+j+ZFLPwVgg/Q+swiPDzCH4WJ19SQfFACfTqAUfYiLSymKU2bFDQ+SmYU3VTM3QBm37bmkPkRlxFm7893mM9+NwsY5irAlV5W0UV+EZWO9vzUFIphq3Npi2ZpMqj9iWfVfy0SdV/quQmtwqaBPdb5Ul/nPnfi2izo8cl/6HD/+3lN8GkE5QLIc9pvL59J2gAdnUD6prWgrcnerf1K4HIABFkIQk8Z/gn0E9lenYRPQ1w6IP9if6nUiliZX4Yi44HE5KXkkfvU8eehain6hgrBmNRIwfiz4TvjmR7wmhNB6ho3Cf9k6g==; 5:7uFTNj1N6lrtMjSY5h/u0r22j7Z5tlBhg570GuADlqpQMJ5DOWtrUp9YdILRy6ZpEEZ7en6ojD7AYALMmAufoN9xwGSGR09CcuyY45wgVHQzqA8P2NzHflnvoiIAAbgiMOiHG8wBfdvvVqcUnShrKCvLVTaZ4JfQhEccc4P8NSpAlSZebmZDGE6Ug/Rz3EuwKlzIj2hBkN+11XJxb0vsug==; 7:1iTKm/wAyIIs4KY6sfYW3LFyDdqoJFF4qwnahaZEfSJtUoJPgAf68qYsG2f3iB0Jj1uIFStEMPZOQcyXjAn1ftJQaq3v1HK7rlPWeWwU8fmHQ9KCiMfiCFi1/tXujVImzEPmgC3XARbYzkfWSGZ6XA== x-ms-office365-filtering-correlation-id: c0c9cbe6-9757-4f36-9b9b-08d6854e5cc5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600126)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0305; x-ms-traffictypediagnostic: BL0PR00MB0305: x-ms-exchange-purlcount: 13 x-microsoft-antispam-prvs: x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(366004)(136003)(376002)(38314003)(199004)(189003)(51444003)(53754006)(606006)(8990500004)(106356001)(105586002)(74316002)(7736002)(93886005)(53946003)(229853002)(26005)(102836004)(10090500001)(6436002)(54896002)(66066001)(186003)(9686003)(33656002)(6246003)(97736004)(2906002)(53546011)(71200400001)(71190400001)(39060400002)(55016002)(236005)(6306002)(6506007)(68736007)(4326008)(22452003)(2501003)(53936002)(8676002)(476003)(86612001)(30864003)(316002)(966005)(6116002)(790700001)(3846002)(81156014)(81166006)(14454004)(478600001)(10290500003)(7696005)(72206003)(25786009)(8936002)(99286004)(86362001)(14444005)(486006)(256004)(5024004)(446003)(54906003)(110136005)(11346002)(76176011)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0305; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jtR+eNYc+aXqx2968lghhlD7RdOObqRViJ2X9733KRkoUptL3cl3oy6LL0w6idmhm4QpR0hiY/HMxpkFucJ0iU+0Cn8W71+mw2YsYO/25Le5HwVI7ZVm9aa0Gkwf2Rln94fMqGs1zVY/B2Jp2wFp1/O869oWaEB0jUlXCy7YkaTfO0uhTNMK7eo8PUnmufIFQH9ufFFdPUSAUYObNsRst+noE/k3F2yqu1gxtBRxMHOM1c27KSYq5KEBLlyjqNefZ6hR0VjFBNphktjOVbWq0MUIDWwHQntZZDXPsQwQUsMEOh0Gk1dxsZqegQm8CytCQuvpPNvPQAvwKid98p10W5w7TkRqKRE+3+WPByHRwTzA/K9XZZApW6ck8hSnqppvaBknbw8WuBNol7NejKM+mgGaMGMqrcHsi7vt5Mrbzg8= Content-Type: multipart/alternative; boundary="_000_BL0PR00MB029262B150B2D8F3C3792302F5960BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0c9cbe6-9757-4f36-9b9b-08d6854e5cc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2019 18:28:12.8142 (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-Transport-CrossTenantHeadersStamped: BL0PR00MB0305 Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 18:28:22 -0000 --_000_BL0PR00MB029262B150B2D8F3C3792302F5960BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sIGV0Yy4gIElmIHlvdSBoYXZlIGNvbmNlcm5zIGFib3V0IOKAnHJlcV9hdWTigJ0sIG5v d+KAmXMgdGhlIHRpbWUgdG8gcHJvdmlkZSB0aGF0IGZlZWRiYWNrIHRvIHRoZSBBQ0UgV0csIGFz IHRoZXnigJlyZSB0cnlpbmcgdG8gY29tcGxldGUgdGhhdCBkcmFmdCBzb29uLiAgUGxlYXNlIGpv aW4gdGhlIEFDRSBXRyBtYWlsaW5nIGxpc3QgYW5kIHNlbmQgeW91ciBmZWVkYmFjayB0aGVyZSBk aXJlY3RseS4NCg0KWW91IGFuZCBJIG1heSBrbm93IHRoYXQgQUNFIE9BdXRoIGFuZCBPQXV0aCAy IGFyZSBwcmV0dHkgZGlmZmVyZW50IGJ1dCBkZXZlbG9wZXJzIGxhdGVyIHdpbGwganVzdCBzZWUg dGhlIE9BdXRoIHBhcmFtZXRlciByZWdpc3RyYXRpb24gYW5kIHdvbuKAmXQgcmVhbGl6ZSB0aGF0 IGl04oCZcyBjb21pbmcgZnJvbSBhIGRpZmZlcmVudCB1bml2ZXJzZS4gIElmIHdlIGNhbiBoYXJt b25pemUgdGhpbmdzIG5vdywgd2Ugc2hvdWxkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8 b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEdlb3JnZSBGbGV0Y2hlcg0KU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDE5IDEwOjA1IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogb2F1dGhA aWV0Zi5vcmc7IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0 Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNCisxDQoNCkkgY2FtZSB0byBhIHNpbWls YXIgY29uY2x1c2lvbiBvdmVyIHRoZSB3ZWVrZW5kLiBJZiBodHRwczovL2FwaS5leGFtcGxlLmNv bS9tYWlsIGlzIGFuIGFsbG93ZWQgbG9jYXRpb24gVVJJLCBob3cgaXMgaXQgbm90IGFsc28gYSBs b2dpY2FsIGxvY2F0aW9uIGNvbnNpZGVyaW5nIGl0J3MgcG9zc2libGUgdGhlcmUgYXJlIG11bHRp cGxlIGVuZHBvaW50cyAiYmVsb3ciIGh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWw/IChlLmcu IGh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWwvdXNlci9tYWlsYm94KS4gQWxzbyBpZiBodHRw czovL2FwaS5leGFtcGxlLmNvbSBpcyByZWFsbHkgYSBsb2FkIGJhbGFuY2VyIHRoYXQgZnJvbnRz IHRoZSAiPGh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWw/KGUuZy5odHRwczovL2FwaS5leGFt cGxlLmNvbS9tYWlsL3VzZXIvbWFpbGJveCkuQWxzb2lmaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb21p c3JlYWxseWFsb2FkYmFsYW5jZXJ0aGF0ZnJvbnRzdGhlPnJlYWwiIGVuZHBvaW50cywgdGhlbiBp dCdzIGFsc28gImxvZ2ljYWwiIGluIHRoYXQgY29udGV4dCBhbmQgbm90IGFuIGV4YWN0IGxvY2F0 aW9uLg0KDQpUaGlzIGJyaW5ncyBtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGFsbCB0aGUgcmVz b3VyY2UgaWRlbnRpZmllcnMgYXJlICJsb2dpY2FsIiBhbG9uZyBhIHJhbmdlIG9mIHNwZWNpZmlj aXR5LiBIb3cgc3BlY2lmaWMgYSByZXNvdXJjZSBpcyBpZGVudGlmaWVkIGlzIHJlYWxseSBhIHJp c2sgZGVjaXNpb24gYW5kIGJhc2VkIG9uIHRoZSBkZXBsb3ltZW50IG1vZGVsIGNhbiBiZSBtYW5h Z2VkIGF0IGVpdGhlciB0aGUgUlMgb3IgdGhlIEFTLg0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDEv MjgvMTkgOTowNyBBTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpJIHBsYW4gb24gam9pbmluZyB0 aGUgbWVldGluZyB0b2RheSBhdCBub29uIGVhc3Rlcm4gdGltZSB0byBkaXNjdXNlcyB0aGlzIGxp dHRsZSBkaXR0eS4gSSBob3BlIG90aGVycyB3aG8gaGF2ZSBhIHN0YWtlIGluIGl0IGNhbiB0b28u DQoNClRoZSBwcm9wb3NlZCBjaGFuZ2VzIHRoYXQgVml0dG9yaW8gYW5kIEkgcHV0IHRvZ2V0aGVy IGNhbiBiZSBzZWVuIGluIHRoZSBkaWZmIG9mIHRoaXMgcHVsbCByZXF1ZXN0IGh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvaS1kL3B1bGwvMS9maWxlcyBh bmQgSSBldmVuIHB1dCBhIHhtbDJyZmMnZWQgdGV4dCB2ZXJzaW9uIG9uIGh0dHBzOi8vZ2l0aHVi LmNvbS9pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvaS1kL3B1bGwvMSBmb3IgZWFzZSBv ZiByZWZlcmVuY2UuIEkgbWFpbnRhaW4gdGhhdCBpcyB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQg d2F5IGZvcndhcmQgd2l0aCBhbGwgdGhpcy4gWWV0IGFub3RoZXIgbmV3IGFkZGl0aW9uYWwgcGFy YW1ldGVyIGNvdWxkIGJlIGRlZmluZWQgZm9yIHRoZSBsb2dpY2FsIGNhc2UgYnV0IEkgc3RydWdn bGUgdG8gc2VlIHRoZSB2YWx1ZSBpbiBkb2luZyBzby4gVGhlICdyZXNvdXJjZScgaXMgVVJJIHRo YXQgcG9pbnRzIHRvIHRoZSByZXNvdXJjZS4gVGhlIGxldmVsIG9mIHNwZWNpZmljaXR5IG9mIHRo YXQgcG9pbnRlciBpcyBpbnRlbnRpb25hbGx5IGEgYml0IGZ1enp5IGFuZCBhcHBsaWNhdGlvbi9k ZXBsb3ltZW50IHNwZWNpZmljLiBJcyBodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20gKG1lbnRp b25lZCBpbiB0aGUgZG9jdW1lbnRhdGlvbiBwcmV2aW91c2x5IGxpbmtlZCkgYSBsb2NhdGlvbiBv ciBhbiBhYnN0cmFjdCBpZGVudGlmaWVyIG9yIGJvdGg/IFRoZSBkb2N1bWVudCBhbHJlYWR5IChz b21ld2hhdCBhd2t3YXJkbHkpIGRlc2NyaWJlcyB1c2luZyBhICJiYXNlIFVSSSIgZm9yIHRoZSBh cHBsaWNhdGlvbiBvciByZXNvdXJjZS4gSXMgdGhhdCBhIGEgbG9jYXRpb24gb3IgYW4gYWJzdHJh Y3QgaWRlbnRpZmllcj8gT3Iga2luZGEgYm90aD8NCg0KSW4gYWRkaXRpb24gdG8gdGhlIGNvbmNl cm5zIG90aGVycyBoYXZlIGV4cHJlc3NlZCBhYm91dCAicmVxX2F1ZCIsIEkiZCBub3RlIHRoYXQg ZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zIGRlZmluZXMgaXRzIHVzZSBvbmx5IGF0IHRoZSB0 b2tlbiBlbmRwb2ludCBhcyBvbmUgb2YgdGhlICJhZGRpdGlvbmFsIHBhcmFtZXRlcnMgZm9yIHJl cXVlc3RpbmcgYW4gYWNjZXNzIHRva2VuIGZyb20gYSB0b2tlbiBlbmRwb2ludCBpbiB0aGUgQUNF IGZyYW1ld29yayIuIFdoZXJlYXMgdGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQgc2NvcGUg aW5jbHVkZXMgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgdG9vLiBGdXJ0aGVybW9yZSwgd2hp bGUgdGhlIEFDRSBXRyBpcyBidWlsZGluZyBvbiBPQXV0aCwgZm9yIGFsbCBpbnRlbnRzIGFuZCBw dXJwb3NlcyBBQ0UgYW5kIHJlZ3VsYXIgT0F1dGggYXJlIGRpZmZlcmVudCB3b3JsZHMgYW5kIEkg dGhpbmsgYSByZWZlcmVuY2UgaW4gcmVndWxhciBPQXV0aCBkb2N1bWVudCBsaWtlIHRoaXMgb25l IHRvICJBZGRpdGlvbmFsIE9BdXRoIFBhcmFtZXRlcnMgZm9yIEF1dGhvcml6YXRpb24gaW4gQ29u c3RyYWluZWQgRW52aXJvbm1lbnRzIChBQ0UpIiB3b3VsZCBiZSBhIGRpc3NlcnZpY2UgdG8ganVz dCBhYm91dCBldmVyeW9uZS4NCg0KDQoNCg0KDQoNCk9uIFRodSwgSmFuIDI0LCAyMDE5IGF0IDU6 MTMgUE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJp ZmFhdC5pZXRmQGdtYWlsLi5jb20+PiB3cm90ZToNCkhhbm5lcyBzZW50IGFuIHVwZGF0ZSB0byB0 aGlzIG1lZXRpbmcgaGVyZToNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv b2F1dGgvdjhzVU1FQkdNQzI0QWRXTGV3QXltUC1YNGtVDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoN Cg0KT24gVGh1LCBKYW4gMjQsIDIwMTkgYXQgNjoyMCBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KVGhlIHZpcnR1YWwgb2ZmaWNlIGhvdXJzIGluIG15IGNhbGVuZGFyIHN0YXJ0IDEvMiBo b3VyIGJlZm9yZSB0aGF0LiAgSWYgdGhlIHRpbWUgaGFzIGNoYW5nZWQsIGNhbiB5b3UgaGF2ZSB0 aGUgbWVldGluZyBvcmdhbml6ZXIgdXBkYXRlIHRoZSBjYWxlbmRhciBlbnRyeT8NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5r cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21h aWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEph bnVhcnkgMjQsIDIwMTkgMTI6NDYgUE0NClRvOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFv bC5jb208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+Pg0KQ2M6IFZpdHRvcmlvIEJlcnRvY2NpIDxW aXR0b3Jpb0BhdXRoMC5jb208bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+OyBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1y ZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNCkFsbCwNCg0KVGhpcyBjb21pbmcgTW9uZGF5LCBKYW4g MjggQCAxMjowMHBtIEVhc3Rlcm4gVGltZSwgd2UgaGF2ZSBhIHNjaGVkdWxlZCBPQXV0aCBXRyBW aXJ0dWFsIE9mZmljZSBtZWV0aW5nLg0KRmVlbCBmcmVlIHRvIGF0dGVuZCB0aGUgbWVldGluZyB0 byBkaXNjdXNzIHRoaXMgdG9waWMgdG8gdHJ5IHRvIGdldCB0byBhIGNvbmNsdXNpb24gb24gdGhp cy4NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpPbiBXZWQsIEphbiAyMywgMjAxOSBhdCAzOjAw IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCisxDQoNCkFsc28sIEkgZG9u J3QgcmVhbGx5IGxpa2UgdGhlIHBhcmFtZXRlciBuYW1lICdyZXFfYXVkJyA6KSBJJ20gbm90IDEw MCUgY29udmluY2VkIHRoYXQgJ2F1ZGllbmNlJyBhbmQgJ2xvZ2ljYWwgcmVzb3VyY2UnIGFyZSBj b21wbGV0ZWx5IG92ZXJsYXBwaW5nIGNvbmNlcHRzLiBXZSBjYW4gcG90ZW50aWFsbHkgbWFrZSB0 aGVtIGNvbXBsZXRlbHkgb3ZlcmxhcHBpbmcgYnV0IHdlIG5lZWQgdGV4dCB0byB0aGF0IGVmZmVj dC4NCg0KSSBhbHNvIGJlbGlldmUgdGhhdCB3ZSBkb24ndCBoYXZlIGEgY29tcGxldGUgc29sdXRp b24gZm9yIGFsbCBkZXBsb3ltZW50cyB1c2luZyBleGFjdCBsb2NhdGlvbnMgKHNlZSBteSBwcmV2 aW91cyBlbWFpbCkuDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gMS8yMy8xOSAyOjUwIFBNLCBWaXR0 b3JpbyBCZXJ0b2NjaSB3cm90ZToNCkFzIG1lbnRpb25lZCBiZWxvdywgSSBhZ3JlZSB0aGUgdHdv IGNhbiBiZSBzZXBhcmF0ZWQtIGJ1dCBJIGFsc28gYWdyZWUgd2l0aCBHZW9yZ2Ugb24gdGhlIG5l ZWQgdG8gYmUgY2xlYXIgYW4gZWFzeSB0byByZWZlcmVuY2UgZm9yIGRldmVsb3BlcnMuDQpKdXN0 IGFkZGluZyBhIHJlZmVyZW5jZSB0byByZXFfYXVkIHdvdWxkIGp1c3QgcmFpc2UgdGhlIGN5Y2xv bWF0aWMgY29tcGxleGl0eSBvZiB0aGUgc3BlY3MsIHdoaWNoIGlzIGFscmVhZHkgdW51c2FibHkg aGlnaCBmb3IgbWVyZSBtb3J0YWxzIGluIHRoZSBPQXV0aDIvT0lEQyBmYW1pbHkgb2Ygc3BlY3Mu DQoNCk9uZSBhZGRpdGlvbmFsIGNvbXBsaWNhdGlvbiBpcyB0aGF0IHRoaXMgc3BlY2lmaWNhdGlv biBpcyByZXVzaW5nIGEgcGFyYW1ldGVyIHRoYXQgaXMgYWxyZWFkeSB1c2VkIGluIGEgdmVyeSBs YXJnZSBudW1iZXIgb2YgcHJvZHVjdGlvbiBzeXN0ZW1zIChzbWFsbCBleGFtcGxlIGhlcmU8aHR0 cHM6Ly9kb2NzLm1pY3Jvc29mdC5jb20vZW4tdXMvYXp1cmUvYWN0aXZlLWRpcmVjdG9yeS9kZXZl bG9wL3YxLXByb3RvY29scy1vYXV0aC1jb2RlPiksIGFuZCB3aG9zZSBjb25jcmV0ZSBzZW1hbnRp YyBoYXBwZW5zIHRvIGJlIHByZXZhbGVudGx5IGxvZ2ljIGlkZW50aWZpZXIuIElmIHRoZSBwYXJh bWV0ZXIgeW91IGFyZSBkZWZpbmluZyBoZXJlIGhhcyBhIGRpZmZlcmVudCBzZW1hbnRpYywgYXQg dGhlIHZlcnkgbGVhc3QgaXQgd291bGQgc2VlbSBnb29kIGh5Z2llbmUgdG8gcmVuYW1lIGl0IHRv IGF2b2lkIGNvbGxpc2lvbiBhbmQgY29uZnVzaW9uLg0KDQpPbiBXZWQsIEphbiAyMywgMjAxOSBh dCAxMTowMyBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQpJIGFncmVlIHdpdGggSm9obuKAmXMgbG9naWMuICBUaGUgcGh5c2ljYWwgcmVzb3VyY2UgYW5k IGxvZ2ljYWwgcmVzb3VyY2Ugc2hvdWxkIHVzZSBkaWZmZXJlbnQgaWRlbnRpZmllcnMuICBGb3J0 dW5hdGVseSwgd2UgYWxyZWFkeSBoYXZlIOKAnHJlc291cmNl4oCdIGFuZCDigJxyZXFfYXVk4oCd IGZvciB0aGVzZSBwYXJhbWV0ZXJzLiAgSSBiZWxpZXZlIHdl4oCZcmUgZ29vZCB0byBnbywgYXMt aXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDE5IDEwOjU2IEFNDQpUbzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2hlcGhl cmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0K DQoNCkkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgbmVjZXNzYXJpbHkgbXV0dWFsbHkgZXhjbHVzaXZl LCB0aGF0IGlzIHdoeSBJIHRoaW5rIHRoZXJlIGlzIHZhbHVlIGluIGFsbG93aW5nIHRoZW0gdG8g YmUgc3BlY2lmaWVkIHNlcGFyYXRlbHkuDQoNCkFzIGFuIEFTIGluIHRoZSBkaXN0cmlidXRlZCBP QXV0aCBjYXNlIGtub3dpbmcgdGhhdCBhIGNsaWVudCBpbnRlcmFjdGluZyB3aXRoIFJTIGh0dHBz Oi8vZmlyZS5oaHMuY29tIGFzIHRoZSByZXNvdXJjZSB3YW50cyBhIE9BdXRoIHRva2VuIHdpdGgg YW4gYXVkaWVuY2Ugb2YgSEhTIGFuZCBhIHNjb3BlIG9mIHJlYWQuDQoNCldpdGhvdXQgcHJvb2Yg b2YgcG9zc2Vzc2lvbiB3ZSBuZWVkIHRvIGtlZXAgYmFkIFJTIGZyb20gYXNraW5nIGZvciB0b2tl bnMgd2l0aCBzY29wZXMgYW5kIGF1ZGllbmNlcyBvZiBvdGhlciBSUyB0aGF0IGNhbiBiZSByZXBs YXllZC4NCg0KSSByZWFsbHkgbGlrZSBrZWVwaW5nIHRoZSByZXNvdXJjZSBzaW1wbGUgYW5kIHVu c3Bvb2ZhYmxlLCBpdCBpcyB0aGUgVVJJIG9mIHRoZSBSUyB3aGVyZSB5b3UgYXJlIHByZXNlbnRp bmcgdGhlIEFULg0KDQpJIHByZWZlciB0byBrZWVwIHRoYXQgc2VwYXJhdGUgZnJvbSB0aGUgbG9n aWNhbCByZXNvdXJjZSB0aGF0IG1heSBzcGFuIG1vcmUgdGhhbiBvbmUgUlMgZW5kcG9pbnQuDQoN Ck1lcmdpbmcgdGhlIHR3byBhbmQgd2UgYXJlIHByb2JhYmx5IGJhY2sgYXQgdGhlIEFTIGxvb2tp bmcgaW50byB0aGUgVVJJIHRvIGZpZ3VyZSBvdXQgd2hpY2ggb25lIGl0IGlzLiAgSSB0aGluayB0 aGF0IGlzIGhhcmRlciBmb3IgaW1wbGVtZW50YXRpb25zIGFuZCBtb3JlIGxpa2VseSB0byBoYXZl IHNlY3VyaXR5IGlzc3VlcyBkb3duIHRoZSByb2FkLg0KDQpKb2huIEIuDQpPbiAxLzIzLzIwMTkg MTo0NCBQTSwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6DQpIaSBhbGwsDQp0aGFua3MgZm9yIHlv dSBwYXRpZW5jZS4gQnJpYW4gYW5kIG15c2VsZiBpdGVyYXRlZCBvbiBtb2RpZnlpbmcgdGhlIHRl eHQgdG8gY292ZXIgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciB1c2UgY2FzZSwgaGlnaGxpZ2h0aW5n IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgZ29pbmcgdGhhdCByb3V0ZS4gWW91IGNhbiBm aW5kIHRoZSByZXZpc2VkIHRleHQgaW4gaHR0cHM6Ly9naXRodWIuY29tL3ZpYnJvbmV0L2ktZC9i bG9iL21hc3Rlci9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMueG1sLCBzZWUg dGhlIGNvbW1pdHMgaW4gdGhlIGhpc3RvcnkgZnJvbSBKYW51YXJ5IDIxIGZvciB0aGUgc3BlY2lm aWMgY2hhbmdlcy4NCk5vdGU6IEkgYWxzbyBoYWQgYSBjaGF0IHdpdGggSm9obiBvZmZsaW5lLCBh bmQgaGUgZXhwcmVzc2VkIHRoZSBkZXNpcmUgdG8gc3BsaXQgdGhlIHJlc291cmNlIHBhcmFtZXRl ciBpbiB0d28gZGlzdGluY3QgcGFyYW1ldGVycyB0byBiZXR0ZXIgc2lnbmFsIHRoZSBpbnRlbmRl ZCB1c2FnZS4gSSBhbSBzdXJlIGhlIGNhbiBlbGFib3JhdGUuIEkgaGF2ZSBub3RoaW5nIGFnYWlu c3QgaXQgaW4gcHJpbmNpcGxlLCBhcyBsb25nIGFzIHdlIGxlYXZlIG5vdGhpbmcgYXMgZXhlcmNp c2UgdG8gdGhlIHJlYWRlciBhbmQgd2UgYXJlIHZlcnkgY2xlYXIgb24gdXNhZ2UgKGUuZy4gbXV0 dWFsIGV4Y2x1c2l2aXR5LCBldGMpIGJ1dCBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBzcGVhayB3 IEJyaWFuIGFib3V0IGl0LiBJZiB0aGUgZGlzY3Vzc2lvbiBzdHJldGNoZXMgZnVydGhlciwgSSB3 b3VsZCBzdWdnZXN0IHdlIHBhdXNlIGl0IGFuZCBsZXQgaGltIGVuam95IGhpcyB0aW1lIG9mZiBm b3IgdGhlIHJlc3Qgb2YgdGhlIHdlZWsuDQoNCk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDU6MzUg UE0gUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFh dC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IGd1eXMhDQoNCg0KT24gTW9uZGF5 LCBKYW51YXJ5IDIxLCAyMDE5LCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29t PG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCkhpIFJpZmFhdCwNCmFic29sdXRl bHkuIEJyaWFuIGFuZCBteXNlbGYgYWxyZWFkeSBzdGFydGVkIHdvcmtpbmcgb24gc29tZSBsYW5n dWFnZSwgaG93ZXZlciB0aGlzIHdlZWsgaGUgaXMgaW4gdmFjYXRpb24gaGVuY2UgaXQgbWlnaHQg dGFrZSBmZXcgZGF5cyBiZWZvcmUgd2UgY29tZSBiYWNrIHRvIHRoZSBsaXN0IHdpdGggc29tZXRo aW5nLg0KQ2hlZXJzLA0KVi4NCg0KT24gTW9uLCBKYW4gMjEsIDIwMTkgYXQgOTozNSBBTSBSaWZh YXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQpCcmlhbiwgVml0dG9yaW8sDQoNClRvIG1vdmUgdGhpcyBkaXNj dXNzaW9uIGZvcndhcmQsIGNhbiB5b3UgZ3V5cyBzdWdnZXN0IHNvbWUgdGV4dCB0byBtYWtlIHRo ZSBsb2dpY2FsIGlkZW50aWZpZXIgdXNhZ2UgY2xlYXJlcj8NCg0KUmVnYXJkcywNCiBSaWZhYXQN Cg0KDQpPbiBNb24sIEphbiAyMSwgMjAxOSBhdCAxMDozMiBBTSBCcmlhbiBDYW1wYmVsbCA8YmNh bXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLi5vcmc8bWFpbHRvOjQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KQXMgSSBzdWdnZXN0ZWQgYmVmb3Jl LCBJIGRvIHRoaW5rIHRoYXQncyB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgZHJhZnQncyBkZWZp bml0aW9uIG9mICdyZXNvdXJjZScgYXMgYSBVUkkuIEFuZCB0aGF0IHBlcmhhcHMgYWxsIHRoYXQn cyBuZWVkZWQgaXMgc29tZSBtaW5vciBhZGp1c3RtZW50IGFuZC9vciBhdWdtZW50YXRpb24gb2Yg c29tZSB0ZXh0IHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCg0KT24gU3VuLCBKYW4gMjAsIDIwMTkg YXQgNzozOSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1haWx0bzpW aXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCltzZW50IHRvIEpvaG4gb25seSBieSBtaXN0YWtl LCByZXNlbmRpbmcgdG8gdGhlIE1MXQ0KDQpJbiBBenVyZSBBRCB2MSAmIEFERlMsIHRoYXQncyBy ZXNvdXJjZS4uIEl0IGNvdWxkIGJlIHVzZWQgZm9yIGJvdGggbmV0d29yayBhbmQgbG9naWNhbCBp ZHMsIHdpdGggdGhlIGNvbmNyZXRlIHVzYWdlIGluIHRoZSB3aWxkIEkgZGVzY3JpYmVkIGVhcmxp ZXIuDQpJbiBBenVyZSBBRCB2MiwgdGhlIHJlc291cmNlIGFzIGV4cGxpY2l0IHBhcmFtZXRlciAo bmV0d29yaywgbG9naWMgb3Igb3RoZXJ3aXNlKSBpcyBnb25lIGFuZCBpcyBleHByZXNzZWQgYXMg cGFydCBvZiB0aGUgc2NvcGUgc3RyaW5nIG9mIGFsbCB0aGUgc2NvcGVzIHJlcXVlc3RlZCBmb3Ig YSBnaXZlbiByZXNvdXJjZS0gYnV0IGl0IHN0aWxsIGV4aXN0IGluIHByYWN0aWNlIHRobyBhcyBp dCBzdGlsbCBlbmQgdXAgaW4gdGhlIHJlc3VsdGluZyBhdWQgb2YgdGhlIGlzc3VlZCB0b2tlbi4N ClRoaXMgaXMgOSBtb250aHMgb2xkIGluZm8gaGVuY2UNCg0KT24gU3VuLCBKYW4gMjAsIDIwMTkg YXQgMTc6NTggSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl N2p0Yi5jb20+PiB3cm90ZToNCg0KV2hhdCBpcyB0aGUgcGFyYW1ldGVyIHRoYXQgTWljcm9zb2Z0 IGlzIHVzaW5nPw0KT24gMS8yMC8yMDE5IDM6NTkgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3Rl Og0KRmlyc3Qgb2YgYWxsLCBpdCB3YXNuJ3QgbXkgaW50ZW50IHRvIGRpc3J1cHQgdGhlIGVzdGFi bGlzaGVkIHByb2Nlc3MuIEluIG15IGZvcm1lciBwb3NpdGlvbiBJIHdhc24ndCBtb25pdG9yaW5n IHRob3NlIGRpc2N1c3Npb25zIGhlbmNlIEkgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gb2ZmZXIg ZmVlZGJhY2suIFdoZW4gSSBzYXcgc29tZXRoaW5nIHRoYXQgZ2F2ZSBtZSB0aGUgaW1wcmVzc2lv biBtaWdodCBsZWFkIHRvIGlzc3VlcywgYW5kIGdpdmVuIHRoYXQgSSB3b3JrZWQgd2l0aCBhY3R1 YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNpbmcgYSBzaW1pbGFyIHBhcmFtZXRlciBm b3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50IHRvIGJyaW5nIHRoaXMgdXAuIEkgcmVh bGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9uIHRoaXMuIEVuZCBvZiBwcmVhbWJsZS4N Cg0KVWx0aW1hdGVseSBteSBnb2FsIGlzIGZvciBkZXZlbG9wZXJzIHRvIGhhdmUgZ3VpZGFuY2Ug b24gaG93IHRvIHdvcmsgd2l0aCB0aGUgY29uY2VwdCBvZiBsb2dpY2FsIHJlc291cmNlIGluIGEg c3RhbmRhcmQgY29tcGxpYW50IHdheSwgaGVuY2UgaXQgZG9lc24ndCBzdHJpY3RseSBtYXR0ZXIg d2hldGhlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgY29ycmVzcG9uZGluZyBwYXJhbWV0ZXIgbGl2 ZXMgaW4gb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBvciBlbHNld2hlcmUuDQpUaGF0IHNhaWQu IFJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQsIGl0IHdvdWxkIGFwcGVhciB0aGF0IG1vc3Qgb2Yg dGhlIHJlYXNvbnMgZm9yIHdoaWNoIHRoZSBzcGVjIHdhcyBjcmVhdGVkIGFwcGx5IHRvIGJvdGgg dGhlIG5ldHdvcmsgYWRkcmVzc2FibGUgYW5kIHRoZSBsb2dpY2FsIHJlc291cmNlIHR5cGVzOiBr bm93aW5nIHdoYXQga2V5cyB0byB1c2UgdG8gZW5jcnlwdCB0aGUgdG9rZW4sIGNvbnN0cmFpbiBh Y2Nlc3MgdG9rZW5zIHRvIHRoZSBpbnRlbmRlZCBhdWRpZW5jZSwgYXZvaWRpbmcgb3ZlcmxvYWRp bmcgc2NvcGVzIHdpdGggcmVzb3VyY2UgaW5kaWNhdGluZyBwYXJ0cy4uLiB0aG9zZSBhbGwgYXBw bHkgdG8gbmV0d29yayBhZGRyZXNzYWJsZSBhbmQgbG9naWMgaWRlbnRpZmllcnMgYWxpa2UuIEFu ZCBib3RoIHBhcmFtZXRlcnMgYXJlIGV4cGVjdGVkIHRvIHJlc3VsdCBpbiBhdWRpZW5jZSByZXN0 cmljdGVkIHRva2Vucy4gSXQgc2VlbXMgdGhlIG9ubHkgZGlmZmVyZW5jZSBjb21lcyBhdCB0b2tl biB1c2FnZSB0aW1lLCB3aXRoIHRoZSBuZXR3b3JrIGFkZHJlc3NhYmxlIGNhc2UgZ2l2aW5nIG1v cmUgZ3VhcmFudGVlcyB0aGF0IHRoZSB0b2tlbiB3aWxsIGdvIHRvIGl0cyBpbnRlbmRlZCByZWNp cGllbnQsIGJ1dCB0aGUgcmVxdWVzdCBhbmQgYXVkaWVuY2UgcmVzdHJpY3Rpb24gc3ludGF4IHNl ZW1zIHRvIGJlIGV4YWN0bHkgdGhlIHNhbWUuDQpPbiB0b3Agb2YgdGhpczogaW4gdGhlIDk5Ljk5 OSUgb2YgdGhlIHNjZW5hcmlvcyBJIGVuY291bnRlcmVkIGluIHRoZSB3aWxkIGluIHRoZSBsYXN0 IDUgeWVhcnMgb2YgdXNpbmcgdGhlIHJlc291cmNlIHBhcmFtZXRlciBpbiB0aGUgTVMgZWNvc3lz dGVtLCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllciB3YXMga25vd24gYXQgZGVzaWduIHRpbWU6IHRo ZSBkZXZlbG9wZXIgZGlzY292ZXJlZCBpdCBvdXQgb2YgYmFuZCBhbmQgcGxhY2VkIGl0IGluIHRo ZSBhcHAgY29uZmlnIGF0IGRlcGxveW1lbnQgdGltZS4gVGhvc2UgYXJlbid0IGZyaW5nZSBjYXNl cyBJIG9jY2FzaW9uYWxseSBlbmNvdW50ZXJlZDogdGhlIHJlc291cmNlIHBhcmFtZXRlciBpbiBB enVyZSBBRCB2MSBhbmQgQURGUyB3YXMgbWFuZGF0b3J5LCBoZW5jZSBsaXRlcmFsbHkgZXZlcnkg c29sdXRpb24gaSBzYXcgb3IgdG91Y2hlZCB1c2VkIGl0LiBBcyBCcmlhbiBzdWdnZXN0ZWQsIHRo aXMgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgc2VjdXJpdHkgYWR2YW50YWdlcyBvZiB0aGUgbmV0 d29yayBhZGRyZXNzYWJsZSBjYXNlIGFyZW4ndCBhcyBwcm9ub3VuY2VkIGFzIGluIHRoZSBjYXNl IGluIHdoaWNoIHRoZSBjbGllbnQgZGlzY292ZXJzIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIGF0 IHJ1bnRpbWUuIFRoaXMgaXNuJ3QganVzdCBiZWNhdXNlIHRoZXJlIGlzIG5vIHNwZWNpZmljYXRp b24gc3VnZ2VzdGluZyBsb2NhdGlvbiBzaG91bGQgYmUgZXhwbGljaXRseSBpbmRpY2F0ZWQsIGl0 J3MgYmVjYXVzZSB0aGVyZSBhcmUgbWFueSBwcmFjdGljYWwgYWR2YW50YWdlcyBhdCBkZXZlbG9w bWVudCBhbmQgZGVwbG95bWVudCB0aW1lIHRvIGJlIGFibGUgdG8gdXNlIGxvZ2ljYWwgaWRlbnRp ZmllcnMtIGFuZCBpZiB0aGUgY29uY3JldGUgc2VjdXJpdHkgYWR2YW50YWdlcyBkb24ndCBhcHBs eSB0byB0aGUgdGhlaXIgY2FzZSwgcGVvcGxlIHdpbGwgc2ltcGx5IG5vdCBjb21wbHkuDQoNCklu IHN1bW1hcnk6IGNyZWF0aW5nIHR3byBkaWZmZXJlbnQgcGFyYW1ldGVycyBpbiB0d28gZGlmZmVy ZW50IGRvY3VtZW50cyBpcyBiZXR0ZXIgdGhhbiBpZ25vcmluZyBoZSBsb2dpY2FsIGlkZW50aWZp ZXIgY2FzZSBhbHRvZ2V0aGVyLCBob3dldmVyIEkgdGhpbmsgdGhhdCBub3QgYWNrbm93bGVkZ2lu ZyB0aGUgbG9naWNhbCBpZCBjYXNlIGluIG9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgaXMgZ29p bmcgdG8gY3JlYXRlIGNvbmZ1c2lvbiBhbmQgdWx0aW1hdGVseSBub3QgYmUgYXMgdXNlZnVsIHRv IHRoZSBkZXZlbG9wZXIgY29tbXVuaXR5IGFzIGl0IGNvdWxkIGJlLg0KDQoNCg0KT24gU2F0LCBK YW4gMTksIDIwMTkgYXQgMTI6MzggUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCisxIHRvIE1pa2UgYW5kIEpvaG7igJlz IGNvbW1lbnRzLg0KUGhpbA0KDQpPbiBKYW4gMTksIDIwMTksIGF0IDEyOjM0IFBNLCBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkg YWxzbyBhZ3JlZSB0aGF0IOKAnHJlc291cmNl4oCdIHNob3VsZCBiZSBhIHNwZWNpZmljIG5ldHdv cmstYWRkcmVzc2FibGUgVVJMIHdoZXJlYXMgYSBzZXBhcmF0ZSBhdWRpZW5jZSBwYXJhbWV0ZXIg KGxpa2Ug4oCcYXVk4oCdIGluIEpXVHMpIGNhbiByZWZlciB0byBvbmUgb3IgbW9yZSBsb2dpY2Fs IHJlc291cmNlcy4gIFRoZXkgYXJlIGRpZmZlcmVudCwgaWYgcmVsYXRlZCwgdGhpbmdzLg0KDQpO b3RlIHRoYXQgdGhlIEFDRSBXRyBpcyBwcm9wb3NpbmcgdG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1 ZGllbmNlIHBhcmFtZXRlciDigJxyZXFfYXVk4oCdIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDEgLSBwYXJ0bHkgYmFzZWQgb24gZmVl ZGJhY2sgZnJvbSBPQXV0aCBXRyBtZW1iZXJzLiAgVGhpcyBpcyBhIGdlbmVyYWwgT0F1dGggcGFy YW1ldGVyLCB3aGljaCBhbnkgT0F1dGggZGVwbG95bWVudCB3aWxsIGJlIGFibGUgdG8gdXNlLg0K DQpJIHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hhbmdlcyBhcmUgbmVlZGVkIHRvIGRyYWZ0 LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywgYXMgdGhlIGxvZ2ljYWwgYXVkaWVuY2Ug d29yayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90aGVyIGRyYWZ0Lg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFNhdHVyZGF5LCBK YW51YXJ5IDE5LCAyMDE5IDk6MDEgQU0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCkNjOiBW aXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOlZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj47IElFVEYgb2F1dGggV0cg PG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLTAxDQoNCldlIG5lZWQgdG8gZGVjaWRlIGlmIHdlIHdhbnQgdG8gbWFrZSBhIGNo YW5nZS4NCg0KRm9yIHNlY3VyaXR5IHdlIGFyZSBsb2NhdGlvbiBjZW50cmljLg0KDQpJIHByZWZl ciB0byBrZWVwIHJlc291cmNlIGxvY2F0aW9uIHNlcGFyYXRlIGZyb20gbG9naWNhbCBhdWRpZW5j ZSB0aGF0IGNhbiBiZSBhIHNjb3BlIG9yIG90aGVyIHBhcmFtZXRlci4NCg0KSWYgYmVjb21lcyBo YXJkZXIgZm9yIHBlb3BsZSB0byB1c2UgdGhlIHBhcmFtZXRlciBjb3JyZWN0bHkgaWYgd2UgYXJl IHRvbyBmbGV4aWJsZS4NCg0KSSB3b3VsZCByYXRoZXIgaGF2ZSBhIHNlcGFyYXRlIGxvZ2ljYWwg YXVkaWVuY2UgcGFyYW1ldGVyIGlmIHdlIHRoaW5rIHdlIHdhbnQgb25lLg0KDQpKb2huIEIuDQoN Ck9uIFNhdCwgSmFuIDE5LCAyMDE5LCAxMTo0MSBBTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiB3cm90 ZToNCk5vIGFwb2xvZ3kgbmVlZGVkLCBSaWZhYXQuIEFuZCBJIGFwb2xvZ2l6ZSBpZiB3aGF0IEkg c2FpZCBjYW1lIG9mZiB0aGUgd3Jvbmcgd2F5LiBJIHdhcyBqdXN0IHRyeWluZyB0byBtYWtlIGxp Z2h0IG9mIHRoZSBzaXR1YXRpb24uLiBBbmQgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgYmUg aGFtc3RydW5nIGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVyZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtl cyBzZW5zZSB0byBiZSBmbGV4aWJsZSB3aXRoIHRoaW5ncy4NCg0KT24gRnJpLCBKYW4gMTgsIDIw MTkgYXQgNjoyMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxt YWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpTb3JyeSBCcmlhbiwgSSB3YXMg bm90IGNsZWFyIHdpdGggbXkgc3RhdGVtZW50Lg0KSSBtZWFudCB0byBzYXkgdGhhdCB3ZSBzaG91 bGQgbm90IGFsbG93IHRoZSBwcm9jZXNzIHRvIHByZXZlbnQgdGhlIFdHIGZyb20gcHJvZHVjaW5n IGEgcXVhbGl0eSBkb2N1bWVudCB3aXRob3V0IGlzc3VlcywgYXNzdW1pbmcgdGhlcmUgaXMgYW4g aXNzdWUgaW4gdGhlIGZpcnN0IHBsYWNlLg0KSWRlYWxseSB3ZSB3YW50IHRvIGdldCB0aGVzZSBp ZGVudGlmaWVkIGR1cmluZyB0aGUgV0dMQywgYnV0IHRoaW5ncyBoYXBwZW4gYW5kIHNvbWV0aW1l cyB0aGUgV0cgbWlzc2VzIHNvbWV0aGluZy4NCg0KSSBoZWFyIHlvdSBhbmQgYWdyZWUgdGhhdCB0 aGlzIG1ha2UgdGhpbmdzIGRpZmZpY3VsdCBmb3IgYXV0aG9ycy4gV2Ugd2lsbCBtYWtlIHN1cmUg dGhhdCB0aGlzIGRvZXMgbm90IGJlY29tZSB0aGUgbm9ybSwgYW5kIHdlIHdpbGwgdHJ5IHRvIHN0 aWNrIHRvIHRoZSBwcm9jZXNzIGFzIG11Y2ggYXMgcG9zc2libGUuDQoNClJlZ2FyZHMsDQogUmlm YWF0DQoNCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgNTozNSBQTSBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPj4gd3JvdGU6DQpUaGFua3MgUmlmYWF0LiBQcm9jZXNzIGlzIGFzIHByb2Nlc3MgZG9lcywg cmlnaHQ/IEkgZG8ga2luZGEgd2FudCB0byBncnVtYmxlIGFib3V0IFdHQ0wgaGF2aW5nIHBhc3Nl ZCBhbHJlYWR5IGJ1dCB0aGF0J3MgbW9zdGx5IGJlY2F1c2UgcmVwbHlpbmcgdG8gdGhlc2Uga2lu ZHMgb2YgdGhyZWFkcyBpcyBoYXJkIGZvciBtZSBhbmQgSSdsbCBqdXN0IGdldCBvdmVyIGl0Li4u DQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhpbmdzLCB0aGUgc2VjdXJpdHkgY29uY2VybnMg Y29tZSBpbnRvIHBsYXkgd2hlbiB0aGUgY2xpZW50IGlzIGJlaW5nIHRvbGQgdGhlIGJ5IHRoZSBy ZXNvdXJjZSBob3cgdG8gaWRlbnRpdHkgdGhlIHJlc291cmNlIGxpa2UgaXMgZGVzY3JpYmVkIGlu IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc3RyaWJ1dGVk LTAxIGFuZCB1c2luZyB0aGUgYWN0dWFsIGxvY2F0aW9uIGluIHRoYXQgY29udGV4dCAsYWxvbmcg d2l0aCBzb21lIG90aGVyIGNoZWNrcyBwcmVzY3JpYmVkIGluIHRoYXQgZHJhZnQsIHByZXZlbnRz IHRoZSBraW5kIG9mIGlzc3VlcyBKb2huIGRlc2NyaWJlZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQu DQoNCkluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQga25vd3MgdGhlIHJlc291cmNlIGEgcHJpb3Jp IG9yIG91dC1vZi1iYW5kIG9yIGNvbmZpZ3VyZWQgb3Igd2hhdGV2ZXIsIEkgZG9uJ3QgdGhpbmsg dGhlIHNhbWUgc2VjdXJpdHkgY29uY2VybnMgYXJpc2UuIEFuZCB1c2luZyBzdWNoIGEga25vd24g dmFsdWUsIGJlIGl0IGFuIGFjdHVhbCBsb2NhdGlvbiBvciBsb2dpY2FsIHJlcHJlc2VudGF0aW9u LCB3b3VsZCBiZSBva2F5Lg0KDQpUaGUgcmVzb3VyY2UtaW5kaWNhdG9ycyBkcmFmdCBpcyBhZG1p dHRlZGx5IHNvbWV3aGF0IGxvY2F0aW9uLWNlbnRyaWMgaW4gaG93IGl0IHRhbGtzIGFib3V0IHRo ZSB2YWx1ZSBvZiB0aGUgJ3Jlc291cmNlJyBwYXJhbWV0ZXIuIEJ1dCB1bHRpbWF0ZWx5IGl0IGRl ZmluZXMgaXQgYXMgYW4gYWJzb2x1dGUgVVJJIHRoYXQgaW5kaWNhdGVzIHRoZSBsb2NhdGlvbiBv ZiB0aGUgdGFyZ2V0IHNlcnZpY2Ugb3IgcmVzb3VyY2Ugd2hlcmUgYWNjZXNzIGlzIGJlaW5nIHJl cXVlc3RlZC4gQSBsb2NhdGlvbiBjYW4gYmUgdmFyeWluZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5k IEknZCBzYXkgdGhhdCB1c2luZyBhIFVSSSBhcyAncmVzb3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0 aGF0J3MgYSBsb2dpY2FsIGlkZW50aWZpZXIgdGhhdCBwb2ludHMgdG8gc29tZSByZXNvdXJjZSBp cyB3ZWxsIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkcmFmdC4NCg0KU28gbWF5YmUgdGhlIGRy YWZ0IGlzIG9rYXkgYXMgaXM/DQoNCk9yIHBlcmhhcHMgdGhhdCdzIHRvbyBtdWNoIHRvIGJlIGxl ZnQgYXMgYW4gZXhlcmNpc2VyIHRvIHRoZSByZWFkZXI/ICBBbmQgc29tZSB0ZXh0IHNob3VsZCBi ZSBhZGRlZCBhbmQvb3IgYWRqdXN0ZWQgc28gdGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQg d291bGQgYmUgYSBsaXR0bGUgbW9yZSBvcGVuL2NsZWFyIGFib3V0IHRoZSBwYXJhbWV0ZXIgdmFs dWUgcG90ZW50aWFsbHkgYmVpbmcgbW9yZSBvZiBhIGxvZ2ljYWwgb3IgYWJzdHJhY3QgaWRlbnRp ZmllciBhbmQgbm90IG5lY2Vzc2FyaWx5IGEgbmV0d29yayBhZGRyZXNzYWJsZSBVUkw/DQoNCg0K DQpPbiBGcmksIEphbiAxOCwgMjAxOSBhdCAxOjE4IFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlm YWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToN Ckkgd291bGRuJ3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQgdGhlIHByb2Nlc3MuDQpJZiBpdCBtYWtl cyBzZW5zZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50LCB0aGVuIGZlZWwgZnJlZSB0byBkbyB0aGF0 Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDM6MDgg UE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20+PiB3cm90ZToNClllcyB0aGUgbG9naWNhbCByZXNvdXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkg InNjb3BlIg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyBsaWtlIFBpbmcgYW5kIEF1dGgwIGhhdmUg YmVlbiBhZGRpbmcgYW5vdGhlciBwYXJhbWV0ZXIgImF1ZCIgdG8gaWRlbnRpZnkgdGhlIGxvZ2lj YWwgcmVzb3VyY2UgYW5kIHRoZW4gdXNpbmcgc2NvcGVzIHRvIGRlZmluZSBwZXJtaXNzaW9ucyB0 byB0aGUgcmVzb3VyY2UuDQoNCkZvcnR1bmF0ZWx5LCB3ZSBhcmUgdXNpbmcgYSBkaWZmZXJlbnQg cGFyYW1ldGVyIG5hbWUgc28gbm90IHN0ZXBwaW5nIG9uIHRoYXQuLg0KDQpXZSBjb3VsZCBnbyBi YWNrIGFuZCB0cnkgdG8gYWRkIHRleHQgZXhwbGFpbmluZyB0aGUgZGlmZmVyZW5jZSwgYnV0IHdl IGFyZSBxdWl0ZSBsYXRlIGluIHRoZSBwcm9jZXNzLg0KDQpJIGFncmVlIHRoYXQgYSBsb2dpY2Fs IHJlc291cmNlIHBhcmFtZXRlciBtYXkgYmUgaGVscGZ1bCwgYnV0IHBlcmhhcHMgaXQgc2hvdWxk IGJlIGEgc2VwYXJhdGUgZHJhZnQuDQoNCkpvaG4gQi4NCg0KT24gRnJpLCBKYW4gMTgsIDIwMTkg YXQgNDozOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KRG9lc27igJl0IHRoZSDigJxz Y29wZeKAnSBwYXJhbWV0ZXIgYWxyZWFkeSBwcm92aWRlIGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBh IGxvZ2ljYWwgaWRlbnRpZmllcj8NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFX UyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2Np IDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC4uY29t QGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwgSmFudWFyeSAxOCwgMjAxOSBhdCA1OjQ3 IEFNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl N2p0Yi5jb20+Pg0KQ2M6IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3cml0ZS11cCBm b3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoNClRoYW5rcyBKb2hu IGZvciB0aGUgYmFja2dyb3VuZC4NCkkgYWdyZWUgdGhhdCBmcm9tIHRoZSBjbGllbnQgdmFsaWRh dGlvbiBQb1YsIGhhdmluZyBhbiBpZGVudGlmaWVyIGNvcnJlc3BvbmRpbmcgdG8gYSBsb2NhdGlv biBtYWtlcyB0aGluZ3MgbW9yZSBzb2xpZC4NClRoYXQgc2FpZDogdGhlIHVzZSBvZiBsb2dpY2Fs IGlkZW50aWZpZXJzIGlzIHdpZGVzcHJlYWQsIGFzIGl0IGhhcyBzaWduaWZpY2FudCBwcmFjdGlj YWwgYWR2YW50YWdlcyAodGhpbmsgb2Ygc2VydmljZXMgdGhhdCBhc3NpZ24gZ2VuZXJhdGVkIGhv c3RpbmcgVVJMcyBvbmx5IGF0IGRlcGxveW1lbnQgdGltZSwgb3Igc2VydmljZXMgdGhhdCBhcmUg c29tZWhvdyBncm91cGVkIHVuZGVyIHRoZSBzYW1lIGxvZ2ljYWwgYXVkaWVuY2UgYWNyb3NzIHJl Z2lvbnMvZW52aXJvbm1lbnQvZGVwbG95bWVudHMpLiBQZW9wbGUgd29uJ3Qgc3RvcCB1c2luZyBs b2dpY2FsIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBubyBhbHRlcm5hdGl2 ZSAoZ2VuZXJhdGluZyBuZXcgYXVkaWVuY2VzIG9uIHRoZSBmbHkgYXQgdGhlIEFTIGV2ZXJ5IHRp bWUgeW91IGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFzc2lnbmVkIGEgbmV3IFVSTCBjYW4gYmUg dW5mZWFzaWJsZSkuIExlYXZpbmcgYSB3aWRlbHkgdXNlZCBhcHByb2FjaCBhcyBleGVyY2lzZSB0 byB0aGUgcmVhZGVyIHNlZW1zIGEgZGlzc2VydmljZSB0byB0aGUgY29tbXVuaXR5LCBnaXZlbiB0 aGF0IHRoaXMgbWlnaHQgbGVhZCB0byB2ZW5kb3JzIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgYW5k IEF1dGgwKSBrZWVwaW5nIHRoZWlyIG93biBwcm9wcmlldGFyeSBwYXJhbWV0ZXJzLCBvciBkZXZl bG9wZXJzIG1pc3VzaW5nIHRoZSBvbmVzIGluIHBsYWNlOyB3b3VsZCBtYWtlIGl0IGhhcmQgZm9y IFNESyBkZXZlbG9wZXJzIHRvIHByb3ZpZGUgbGlicmFyaWVzIHRoYXQgd29yayBvdXQgb2YgdGhl IGJveCB3aXRoIGRpZmZlcmVudCBBU2VzOyBhbmQgc28gb24uDQpXb3VsZCBpdCBiZSBmZWFzaWJs ZSB0byBhZGQgc3VjaCBwYXJhbWV0ZXIgZGlyZWN0bHkgaW4gdGhpcyBzcGVjPyBUaGF0IHdvdWxk IGVsaW1pbmF0ZSB0aGUgaW50ZXJvcCBpc3N1ZXMsIGFuZCBhbHNvIGdpdmVzIHVzIGEgY2hhbmNl IHRvIGZ1bGx5IHdhcm4gcGVvcGxlIGFib3V0IHRoZSBzZWN1cml0eSBzaG9ydGNvbWluZ3Mgb2Yg Y2hvb3NpbmcgdGhhdCBhcHByb2FjaC4NCg0KDQoNCk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDQ6 MzIgUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20+PiB3cm90ZToNCg0KV2UgaGF2ZSBkaXNjdXNzZWQgdGhpcy4NCg0KQXVkaWVuY2VzIGNh biBjZXJ0YWlubHkgYmUgbG9naWNhbCBpZGVudGlmaWVycy4NCg0KVGhpcyBob3dldmVyIGlzIGEg bW9yZSBzcGVjaWZpYyBsb2NhdGlvbi4gIFRoZSBBUyBpcyBmcmVlIHRvIG1hcCB0aGUgbG9jYXRp b24gaW50byBzb21lIGFic3RyYWN0IGF1ZGllbmNlIGluIHRoZSBBVC4NCg0KRnJvbSBhIHNlY3Vy aXR5IHBvaW50IG9mIHZpZXcgb25jZSB0aGUgY2xpZW50IHN0YXJ0cyBhc2tpbmcgZm9yIGxvZ2lj YWwgcmVzb3VyY2VzIGl0IGNhbiBiZSB0cmlja2VkIGludG8gYXNraW5nIGZvciB0aGUgd3Jvbmcg b25lIGFzIGEgYmFkIHJlc291cmNlIGNhbiBhbHdheXMgbGllIGFib3V0IHdoYXQgbG9naWNhbCBy ZXNvdXJjZSBpdCBpcy4NCg0KSWYgd2Ugd2VyZSB0byBjaGFuZ2UgaXQsIGhvdyBhIGNsaWVudCB3 b3VsZCB2YWxpZGF0ZSBpdCBiZWNvbWVzIGNoYWxsZW5naW5nIHRvIGltcG9zc2libGUuDQoNClRo ZSBBUyBpcyBmcmVlIHRvIGRvIHdoYXRldmVyIG1hcHBpbmcgb2YgbG9jYXRpb25zIHRvIGlkZW50 aWZpZXJzIGl0IG5lZWRzIGZvciBhY2Nlc3MgdG9rZW5zLg0KDQpTb21lIGltcGxlbWVudGF0aW9u cyBtYXkgd2FudCB0byBrZWVwIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBsaWtlIGxvZ2ljYWwgYXVk aWVuY2UsIGJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0ZSBmcm9tIHJlc291cmNlLg0KDQpKb2hu IEIuDQpPbiAxLzE3LzIwMTkgOTo1NiBBTSwgUmlmYWF0IFNoZWtoLVl1c2VmIHdyb3RlOg0KSGkg Vml0dG9yaW8sDQoNClRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgY29waWVkIGZvcm0gdGhlIGFic3Ry YWN0IG9mIHRoZSBkcmFmdCBpdHNlbGYuDQoNCg0KQXV0aG9ycywNCg0KU2hvdWxkIHRoZSBkcmFm dCBiZSB1cGRhdGVkIHRvIGNvdmVyIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgY2FzZT8NCg0KUmVn YXJkcywNCiBSaWZhYXQNCg0KDQpPbiBUaHUsIEphbiAxNywgMjAxOSBhdCA4OjE5IEFNIFZpdHRv cmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRoMC5jb208bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNv bT4+IHdyb3RlOg0KSGkgUmlmYWF0LA0Kb25lIGRldGFpbC4gVGhlIHRlY2ggc3VtbWFyeSBzYXlz DQoNCg0KQW4gZXh0ZW5zaW9uIHRvIHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdv cmsgZGVmaW5pbmcgcmVxdWVzdA0KDQpwYXJhbWV0ZXJzIHRoYXQgZW5hYmxlIGEgY2xpZW50IHRv IGV4cGxpY2l0bHkgc2lnbmFsIHRvIGFuIGF1dGhvcml6YXRpb24gc2VydmVyDQoNCmFib3V0IHRo ZSBsb2NhdGlvbiBvZiB0aGUgcHJvdGVjdGVkIHJlc291cmNlKHMpIHRvIHdoaWNoIGl0IGlzIHJl cXVlc3RpbmcNCg0KYWNjZXNzLg0KQnV0IGF0IGxlYXN0IGluIHRoZSBNaWNyb3NvZnQgaW1wbGVt ZW50YXRpb24sIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyIGRvZXNuJ3QgaGF2ZSB0byBiZSBhIG5l dHdvcmsgYWRkcmVzc2FibGUgVVJMIChhbmQgaWYgaXQgaXMsIGl0IGRvZXNuJ3Qgc3RyaWN0bHkg bmVlZCB0byBtYXRjaCB0aGUgYWN0dWFsIHJlc291cmNlIGxvY2F0aW9uKS4gSXQgY2FuIGJlIGEg bG9naWNhbCBpZGVudGlmaWVyLCB0aG8gdXNpbmcgdGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlv biB0aGVyZSBoYXMgYmVuZWZpdHMgKGRvbWFpbiBvd25lcnNoaXAgY2hlY2ssIHByZXZlbnRpb24g b2YgdG9rZW4gZm9yd2FyZGluZyBldGMpLg0KU2FtZSBmb3IgQXV0aDAsIHRoZSBhdWRpZW5jZSBw YXJhbWV0ZXIgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIgcmF0aGVyIHRoYW4gYSBsb2NhdGlvbi4N Cg0KDQoNCk9uIFdlZCwgSmFuIDE2LCAyMDE5IGF0IDY6MzIgUE0gUmlmYWF0IFNoZWtoLVl1c2Vm IDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdy b3RlOg0KQWxsLA0KDQpUaGUgZm9sbG93aW5nIGlzIHRoZSBmaXJzdCBzaGVwaGVyZCB3cml0ZS11 cCBmb3IgdGhlIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMSBkb2N1bWVu dC4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtcmVz b3VyY2UtaW5kaWNhdG9ycy9zaGVwaGVyZHdyaXRldXAvDQoNClBsZWFzZSwgdGFrZSBhIGxvb2sg YW5kIGxldCBtZSBrbm93IGlmIEkgbWlzc2VkIGFueXRoaW5nLg0KDQpSZWdhcmRzLA0KIFJpZmFh dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBs aXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93 d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBk ZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21w dXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh bmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05GSURF TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkg b3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRh Y2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9z dXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5n IGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_BL0PR00MB029262B150B2D8F3C3792302F5960BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QnJpYW4sIGV0Yy4mbmJzcDsgSWYg eW91IGhhdmUgY29uY2VybnMgYWJvdXQg4oCccmVxX2F1ZOKAnSwgbm934oCZcyB0aGUgdGltZSB0 byBwcm92aWRlIHRoYXQgZmVlZGJhY2sgdG8gdGhlIEFDRSBXRywgYXMgdGhleeKAmXJlIHRyeWlu ZyB0byBjb21wbGV0ZSB0aGF0IGRyYWZ0IHNvb24uJm5ic3A7IFBsZWFzZSBqb2luIHRoZSBBQ0Ug V0cgbWFpbGluZyBsaXN0IGFuZCBzZW5kIHlvdXIgZmVlZGJhY2sNCiB0aGVyZSBkaXJlY3RseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPllvdSBhbmQgSSBtYXkga25vdyB0 aGF0IEFDRSBPQXV0aCBhbmQgT0F1dGggMiBhcmUgcHJldHR5IGRpZmZlcmVudCBidXQgZGV2ZWxv cGVycyBsYXRlciB3aWxsIGp1c3Qgc2VlIHRoZSBPQXV0aCBwYXJhbWV0ZXIgcmVnaXN0cmF0aW9u IGFuZCB3b27igJl0IHJlYWxpemUgdGhhdCBpdOKAmXMgY29taW5nIGZyb20gYSBkaWZmZXJlbnQg dW5pdmVyc2UuJm5ic3A7IElmIHdlIGNhbg0KIGhhcm1vbml6ZSB0aGluZ3Mgbm93LCB3ZSBzaG91 bGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9m IDwvYj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDI4 LCAyMDE5IDEwOjA1IEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBi ZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+ IG9hdXRoQGlldGYub3JnOyBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2lA YXV0aDAuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaGVwaGVy ZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiYjNDM7MTxicj4NCjxicj4NCkkgY2FtZSB0byBhIHNpbWlsYXIg Y29uY2x1c2lvbiBvdmVyIHRoZSB3ZWVrZW5kLiBJZiA8YSBocmVmPSJodHRwczovL2FwaS5leGFt cGxlLmNvbS9tYWlsIj4NCmh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWw8L2E+IGlzIGFuIGFs bG93ZWQgbG9jYXRpb24gVVJJLCBob3cgaXMgaXQgbm90IGFsc28gYSBsb2dpY2FsIGxvY2F0aW9u IGNvbnNpZGVyaW5nIGl0J3MgcG9zc2libGUgdGhlcmUgYXJlIG11bHRpcGxlIGVuZHBvaW50cyAm cXVvdDtiZWxvdzxhIGhyZWY9Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWw/KGUuZy5odHRw czovL2FwaS5leGFtcGxlLmNvbS9tYWlsL3VzZXIvbWFpbGJveCkuQWxzb2lmaHR0cHM6Ly9hcGku ZXhhbXBsZS5jb21pc3JlYWxseWFsb2FkYmFsYW5jZXJ0aGF0ZnJvbnRzdGhlIj4mcXVvdDsNCiBo dHRwczovL2FwaS5leGFtcGxlLmNvbS9tYWlsPyAoZS5nLiBodHRwczovL2FwaS5leGFtcGxlLmNv bS9tYWlsL3VzZXIvbWFpbGJveCkuIEFsc28gaWYgaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20gaXMg cmVhbGx5IGEgbG9hZCBiYWxhbmNlciB0aGF0IGZyb250cyB0aGUgJnF1b3Q7PC9hPnJlYWwmcXVv dDsgZW5kcG9pbnRzLCB0aGVuIGl0J3MgYWxzbyAmcXVvdDtsb2dpY2FsJnF1b3Q7IGluIHRoYXQg Y29udGV4dCBhbmQgbm90IGFuIGV4YWN0IGxvY2F0aW9uLjxicj4NCjxicj4NClRoaXMgYnJpbmdz IG1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgYWxsIHRoZSByZXNvdXJjZSBpZGVudGlmaWVycyBh cmUgJnF1b3Q7bG9naWNhbCZxdW90OyBhbG9uZyBhIHJhbmdlIG9mIHNwZWNpZmljaXR5LiBIb3cg c3BlY2lmaWMgYSByZXNvdXJjZSBpcyBpZGVudGlmaWVkIGlzIHJlYWxseSBhIHJpc2sgZGVjaXNp b24gYW5kIGJhc2VkIG9uIHRoZSBkZXBsb3ltZW50IG1vZGVsIGNhbiBiZSBtYW5hZ2VkIGF0IGVp dGhlciB0aGUgUlMgb3IgdGhlIEFTLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpHZW9yZ2U8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8yOC8x OSA5OjA3IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBwbGFuIG9uIGpvaW5pbmcgdGhlIG1lZXRpbmcgdG9kYXkgYXQgbm9vbiBlYXN0ZXJuIHRpbWUg dG8gZGlzY3VzZXMgdGhpcyBsaXR0bGUgZGl0dHkuIEkgaG9wZSBvdGhlcnMgd2hvIGhhdmUgYSBz dGFrZSBpbiBpdCBjYW4gdG9vLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9wb3NlZCBjaGFuZ2VzIHRoYXQgVml0dG9yaW8gYW5k IEkgcHV0IHRvZ2V0aGVyIGNhbiBiZSBzZWVuIGluIHRoZSBkaWZmIG9mIHRoaXMgcHVsbCByZXF1 ZXN0DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzL2ktZC9wdWxsLzEvZmlsZXMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHVi LmNvbS9pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvaS1kL3B1bGwvMS9maWxlczwvYT4g YW5kIEkgZXZlbiBwdXQgYSB4bWwycmZjJ2VkIHRleHQgdmVyc2lvbiBvbg0KPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2lldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy9pLWQvcHVsbC8x IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzL2ktZC9wdWxsLzE8L2E+IGZvciBlYXNlIG9mIHJlZmVyZW5jZS4gSSBtYWlu dGFpbiB0aGF0IGlzIHRoZSBtb3N0IHN0cmFpZ2h0Zm9yd2FyZCB3YXkgZm9yd2FyZCB3aXRoIGFs bCB0aGlzLiBZZXQgYW5vdGhlciBuZXcgYWRkaXRpb25hbCBwYXJhbWV0ZXIgY291bGQgYmUgZGVm aW5lZCBmb3IgdGhlIGxvZ2ljYWwgY2FzZSBidXQgSSBzdHJ1Z2dsZSB0byBzZWUgdGhlDQogdmFs dWUgaW4gZG9pbmcgc28uIFRoZSAncmVzb3VyY2UnIGlzIFVSSSB0aGF0IHBvaW50cyB0byB0aGUg cmVzb3VyY2UuIFRoZSBsZXZlbCBvZiBzcGVjaWZpY2l0eSBvZiB0aGF0IHBvaW50ZXIgaXMgaW50 ZW50aW9uYWxseSBhIGJpdCBmdXp6eSBhbmQgYXBwbGljYXRpb24vZGVwbG95bWVudCBzcGVjaWZp Yy4gSXMNCjxhIGhyZWY9Imh0dHBzOi8vZ3JhcGgubWljcm9zb2Z0LmNvbSI+aHR0cHM6Ly9ncmFw aC5taWNyb3NvZnQuY29tPC9hPiAobWVudGlvbmVkIGluIHRoZSBkb2N1bWVudGF0aW9uIHByZXZp b3VzbHkgbGlua2VkKSBhIGxvY2F0aW9uIG9yIGFuIGFic3RyYWN0IGlkZW50aWZpZXIgb3IgYm90 aD8gVGhlIGRvY3VtZW50IGFscmVhZHkgKHNvbWV3aGF0IGF3a3dhcmRseSkgZGVzY3JpYmVzIHVz aW5nIGEgJnF1b3Q7YmFzZSBVUkkmcXVvdDsgZm9yIHRoZSBhcHBsaWNhdGlvbg0KIG9yIHJlc291 cmNlLiBJcyB0aGF0IGEgYSBsb2NhdGlvbiBvciBhbiBhYnN0cmFjdCBpZGVudGlmaWVyPyBPciBr aW5kYSBib3RoPyA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byB0aGUgY29uY2VybnMgb3RoZXJzIGhhdmUgZXhwcmVz c2VkIGFib3V0ICZxdW90O3JlcV9hdWQmcXVvdDssIEkmcXVvdDtkIG5vdGUgdGhhdCBkcmFmdC1p ZXRmLWFjZS1vYXV0aC1wYXJhbXMgZGVmaW5lcyBpdHMgdXNlIG9ubHkgYXQgdGhlIHRva2VuIGVu ZHBvaW50IGFzIG9uZSBvZiB0aGUgJnF1b3Q7YWRkaXRpb25hbCBwYXJhbWV0ZXJzIGZvciByZXF1 ZXN0aW5nIGFuIGFjY2VzcyB0b2tlbiBmcm9tIGEgdG9rZW4gZW5kcG9pbnQNCiBpbiB0aGUgQUNF IGZyYW1ld29yayZxdW90Oy4gV2hlcmVhcyB0aGUgcmVzb3VyY2UtaW5kaWNhdG9ycyBkcmFmdCBz Y29wZSBpbmNsdWRlcyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0b28uIEZ1cnRoZXJtb3Jl LCB3aGlsZSB0aGUgQUNFIFdHIGlzIGJ1aWxkaW5nIG9uIE9BdXRoLCBmb3IgYWxsIGludGVudHMg YW5kIHB1cnBvc2VzIEFDRSBhbmQgcmVndWxhciBPQXV0aCBhcmUgZGlmZmVyZW50IHdvcmxkcyBh bmQgSSB0aGluayBhIHJlZmVyZW5jZQ0KIGluIHJlZ3VsYXIgT0F1dGggZG9jdW1lbnQgbGlrZSB0 aGlzIG9uZSB0byAmcXVvdDtBZGRpdGlvbmFsIE9BdXRoIFBhcmFtZXRlcnMgZm9yIEF1dGhvcml6 YXRpb24gaW4gQ29uc3RyYWluZWQgRW52aXJvbm1lbnRzIChBQ0UpJnF1b3Q7IHdvdWxkIGJlIGEg ZGlzc2VydmljZSB0byBqdXN0IGFib3V0IGV2ZXJ5b25lLg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjQsIDIwMTkgYXQgNToxMyBQTSBSaWZhYXQg U2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC4uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhhbm5lcyBzZW50IGFuIHVwZGF0ZSB0byB0aGlzIG1lZXRpbmcgaGVyZTogPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC92OHNVTUVCR01DMjRBZFdMZXdB eW1QLVg0a1UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL29hdXRoL3Y4c1VNRUJHTUMyNEFkV0xld0F5bVAtWDRrVTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFh dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBKYW4gMjQsIDIwMTkgYXQgNjoyMCBQTSBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZSB2aXJ0dWFsIG9mZmljZSBob3Vy cyBpbiBteSBjYWxlbmRhciBzdGFydCAxLzIgaG91ciBiZWZvcmUgdGhhdC4mbmJzcDsgSWYgdGhl IHRpbWUgaGFzIGNoYW5nZWQsIGNhbiB5b3UgaGF2ZSB0aGUgbWVldGluZyBvcmdhbml6ZXIgdXBk YXRlIHRoZSBjYWxlbmRhcg0KIGVudHJ5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPkZyb206PC9iPiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZh YXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDI0LCAyMDE5IDEy OjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpnZmZsZXRjaEBhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlZpdHRvcmlvQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZpdHRvcmlvQGF1dGgwLmNvbTwv YT4mZ3Q7OyBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5v YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gU2hl cGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QWxsLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBjb21pbmcg TW9uZGF5LCBKYW4gMjggQCAxMjowMHBtIEVhc3Rlcm4gVGltZSwgd2UgaGF2ZSBhIHNjaGVkdWxl ZCBPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBtZWV0aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZlZWwgZnJlZSB0byBhdHRlbmQg dGhlIG1lZXRpbmcgdG8gZGlzY3VzcyB0aGlzIHRvcGljIHRvIHRyeSB0byBnZXQgdG8gYSBjb25j bHVzaW9uIG9uIHRoaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7UmlmYWF0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gV2VkLCBKYW4gMjMsIDIwMTkgYXQgMzowMCBQTSBHZW9yZ2UgRmxldGNoZXIg Jmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiYjNDM7MTxi cj4NCjxicj4NCkFsc28sIEkgZG9uJ3QgcmVhbGx5IGxpa2UgdGhlIHBhcmFtZXRlciBuYW1lICdy ZXFfYXVkJyA6KSBJJ20gbm90IDEwMCUgY29udmluY2VkIHRoYXQgJ2F1ZGllbmNlJyBhbmQgJ2xv Z2ljYWwgcmVzb3VyY2UnIGFyZSBjb21wbGV0ZWx5IG92ZXJsYXBwaW5nIGNvbmNlcHRzLiBXZSBj YW4gcG90ZW50aWFsbHkgbWFrZSB0aGVtIGNvbXBsZXRlbHkgb3ZlcmxhcHBpbmcgYnV0IHdlIG5l ZWQgdGV4dCB0byB0aGF0IGVmZmVjdC4NCjxicj4NCjxicj4NCkkgYWxzbyBiZWxpZXZlIHRoYXQg d2UgZG9uJ3QgaGF2ZSBhIGNvbXBsZXRlIHNvbHV0aW9uIGZvciBhbGwgZGVwbG95bWVudHMgdXNp bmcgZXhhY3QgbG9jYXRpb25zIChzZWUgbXkgcHJldmlvdXMgZW1haWwpLjxicj4NCjxicj4NClRo YW5rcyw8YnI+DQpHZW9yZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiAxLzIzLzE5IDI6NTAgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFzIG1lbnRpb25lZCBiZWxvdywgSSBhZ3JlZSB0aGUgdHdvIGNhbiBiZSBzZXBhcmF0ZWQtIGJ1 dCBJIGFsc28gYWdyZWUgd2l0aCBHZW9yZ2Ugb24gdGhlIG5lZWQgdG8gYmUgY2xlYXIgYW4gZWFz eSB0byByZWZlcmVuY2UgZm9yIGRldmVsb3BlcnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3QgYWRkaW5nIGEgcmVmZXJlbmNlIHRvIHJlcV9hdWQg d291bGQganVzdCByYWlzZSB0aGUgY3ljbG9tYXRpYyBjb21wbGV4aXR5IG9mIHRoZSBzcGVjcywg d2hpY2ggaXMgYWxyZWFkeSB1bnVzYWJseSBoaWdoIGZvciBtZXJlIG1vcnRhbHMgaW4gdGhlIE9B dXRoMi9PSURDIGZhbWlseSBvZiBzcGVjcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uZSBhZGRpdGlvbmFsIGNvbXBsaWNhdGlvbiBp cyB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyByZXVzaW5nIGEgcGFyYW1ldGVyIHRoYXQgaXMg YWxyZWFkeSB1c2VkIGluIGENCjxiPnZlcnk8L2I+IGxhcmdlIG51bWJlciBvZiBwcm9kdWN0aW9u IHN5c3RlbXMgKHNtYWxsIGV4YW1wbGUgPGEgaHJlZj0iaHR0cHM6Ly9kb2NzLm1pY3Jvc29mdC5j b20vZW4tdXMvYXp1cmUvYWN0aXZlLWRpcmVjdG9yeS9kZXZlbG9wL3YxLXByb3RvY29scy1vYXV0 aC1jb2RlIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPiksIGFuZCB3aG9zZSBjb25jcmV0ZSBz ZW1hbnRpYyBoYXBwZW5zIHRvIGJlIHByZXZhbGVudGx5IGxvZ2ljIGlkZW50aWZpZXIuIElmIHRo ZSBwYXJhbWV0ZXIgeW91IGFyZSBkZWZpbmluZyBoZXJlIGhhcyBhIGRpZmZlcmVudCBzZW1hbnRp YywgYXQgdGhlIHZlcnkgbGVhc3QgaXQgd291bGQgc2VlbSBnb29kIGh5Z2llbmUgdG8gcmVuYW1l IGl0IHRvIGF2b2lkIGNvbGxpc2lvbiBhbmQgY29uZnVzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKYW4gMjMsIDIw MTkgYXQgMTE6MDMgQU0gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWls dG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNy b3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHdpdGggSm9obuKAmXMgbG9naWMuJm5ic3A7IFRoZSBw aHlzaWNhbCByZXNvdXJjZSBhbmQgbG9naWNhbCByZXNvdXJjZSBzaG91bGQgdXNlIGRpZmZlcmVu dCBpZGVudGlmaWVycy4mbmJzcDsgRm9ydHVuYXRlbHksIHdlIGFscmVhZHkgaGF2ZSDigJxyZXNv dXJjZeKAnSBhbmQNCiDigJxyZXFfYXVk4oCdIGZvciB0aGVzZSBwYXJhbWV0ZXJzLiZuYnNwOyBJ IGJlbGlldmUgd2XigJlyZSBnb29kIHRvIGdvLCBhcy1pcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNv bG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxOSAxMDo1NiBBTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IFNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRv cnMtMDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBkb24ndCB0aGluayB0aGV5IGFyZSBuZWNl c3NhcmlseSBtdXR1YWxseSBleGNsdXNpdmUsIHRoYXQgaXMgd2h5IEkgdGhpbmsgdGhlcmUgaXMg dmFsdWUgaW4gYWxsb3dpbmcgdGhlbSB0byBiZSBzcGVjaWZpZWQgc2VwYXJhdGVseS48bzpwPjwv bzpwPjwvcD4NCjxwPkFzIGFuIEFTIGluIHRoZSBkaXN0cmlidXRlZCBPQXV0aCBjYXNlIGtub3dp bmcgdGhhdCBhIGNsaWVudCBpbnRlcmFjdGluZyB3aXRoIFJTDQo8YSBocmVmPSJodHRwczovL2Zp cmUuaGhzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZmlyZS5oaHMuY29tPC9hPiBhcyB0 aGUgcmVzb3VyY2Ugd2FudHMgYSBPQXV0aCB0b2tlbiB3aXRoIGFuIGF1ZGllbmNlIG9mIEhIUyBh bmQgYSBzY29wZSBvZiByZWFkLg0KPG86cD48L286cD48L3A+DQo8cD5XaXRob3V0IHByb29mIG9m IHBvc3Nlc3Npb24gd2UgbmVlZCB0byBrZWVwIGJhZCBSUyBmcm9tIGFza2luZyBmb3IgdG9rZW5z IHdpdGggc2NvcGVzIGFuZCBhdWRpZW5jZXMgb2Ygb3RoZXIgUlMgdGhhdCBjYW4gYmUgcmVwbGF5 ZWQuPG86cD48L286cD48L3A+DQo8cD5JIHJlYWxseSBsaWtlIGtlZXBpbmcgdGhlIHJlc291cmNl IHNpbXBsZSBhbmQgdW5zcG9vZmFibGUsIGl0IGlzIHRoZSBVUkkgb2YgdGhlIFJTIHdoZXJlIHlv dSBhcmUgcHJlc2VudGluZyB0aGUgQVQuPG86cD48L286cD48L3A+DQo8cD5JIHByZWZlciB0byBr ZWVwIHRoYXQgc2VwYXJhdGUgZnJvbSB0aGUgbG9naWNhbCByZXNvdXJjZSB0aGF0IG1heSBzcGFu IG1vcmUgdGhhbiBvbmUgUlMgZW5kcG9pbnQuPG86cD48L286cD48L3A+DQo8cD5NZXJnaW5nIHRo ZSB0d28gYW5kIHdlIGFyZSBwcm9iYWJseSBiYWNrIGF0IHRoZSBBUyBsb29raW5nIGludG8gdGhl IFVSSSB0byBmaWd1cmUgb3V0IHdoaWNoIG9uZSBpdCBpcy4mbmJzcDsgSSB0aGluayB0aGF0IGlz IGhhcmRlciBmb3IgaW1wbGVtZW50YXRpb25zIGFuZCBtb3JlIGxpa2VseSB0byBoYXZlIHNlY3Vy aXR5IGlzc3VlcyBkb3duIHRoZSByb2FkLjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMS8yMy8yMDE5IDE6 NDQgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBhbGwsDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoYW5rcyBmb3IgeW91IHBhdGll bmNlLiBCcmlhbiBhbmQgbXlzZWxmIGl0ZXJhdGVkIG9uIG1vZGlmeWluZyB0aGUgdGV4dCB0byBj b3ZlciB0aGUgbG9naWNhbCBpZGVudGlmaWVyIHVzZSBjYXNlLCBoaWdobGlnaHRpbmcgdGhlIHNl Y3VyaXR5IGltcGxpY2F0aW9ucyBvZiBnb2luZyB0aGF0IHJvdXRlLiBZb3UNCiBjYW4gZmluZCB0 aGUgcmV2aXNlZCB0ZXh0IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3ZpYnJv bmV0L2ktZC9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMu eG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3ZpYnJvbmV0L2ktZC9ibG9i L21hc3Rlci9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMueG1sPC9hPiwgc2Vl IHRoZSBjb21taXRzIGluIHRoZSBoaXN0b3J5DQogZnJvbSBKYW51YXJ5IDIxIGZvciB0aGUgc3Bl Y2lmaWMgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Tm90ZTogSSBhbHNvIGhhZCBhIGNoYXQgd2l0aCBKb2huIG9mZmxpbmUsIGFu ZCBoZSBleHByZXNzZWQgdGhlIGRlc2lyZSB0byBzcGxpdCB0aGUgcmVzb3VyY2UgcGFyYW1ldGVy IGluIHR3byBkaXN0aW5jdCBwYXJhbWV0ZXJzIHRvIGJldHRlciBzaWduYWwgdGhlIGludGVuZGVk IHVzYWdlLiBJIGFtIHN1cmUNCiBoZSBjYW4gZWxhYm9yYXRlLiBJIGhhdmUgbm90aGluZyBhZ2Fp bnN0IGl0IGluIHByaW5jaXBsZSwgYXMgbG9uZyBhcyB3ZSBsZWF2ZSBub3RoaW5nIGFzIGV4ZXJj aXNlIHRvIHRoZSByZWFkZXIgYW5kIHdlIGFyZSB2ZXJ5IGNsZWFyIG9uIHVzYWdlIChlLmcuIG11 dHVhbCBleGNsdXNpdml0eSwgZXRjKSBidXQgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gc3BlYWsg dyBCcmlhbiBhYm91dCBpdC4gSWYgdGhlIGRpc2N1c3Npb24gc3RyZXRjaGVzIGZ1cnRoZXIsDQog SSB3b3VsZCBzdWdnZXN0IHdlIHBhdXNlIGl0IGFuZCBsZXQgaGltIGVuam95IGhpcyB0aW1lIG9m ZiBmb3IgdGhlIHJlc3Qgb2YgdGhlIHdlZWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSmFuIDIxLCAyMDE5 IGF0IDU6MzUgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0 LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFuayB5b3UgZ3V5cyENCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KT24gTW9uZGF5LCBKYW51YXJ5IDIxLCAyMDE5LCBWaXR0 b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPlZpdHRvcmlvQGF1dGgwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBSaWZhYXQsDQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFic29sdXRlbHkuIEJyaWFu IGFuZCBteXNlbGYgYWxyZWFkeSBzdGFydGVkIHdvcmtpbmcgb24gc29tZSBsYW5ndWFnZSwgaG93 ZXZlciB0aGlzIHdlZWsgaGUgaXMgaW4gdmFjYXRpb24gaGVuY2UgaXQgbWlnaHQgdGFrZSBmZXcg ZGF5cyBiZWZvcmUgd2UgY29tZSBiYWNrIHRvIHRoZSBsaXN0IHdpdGggc29tZXRoaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlYu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBNb24sIEphbiAyMSwgMjAxOSBhdCA5OjM1IEFNIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJp ZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJyaWFuLCBWaXR0b3JpbywNCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIG1vdmUgdGhp cyBkaXNjdXNzaW9uIGZvcndhcmQsIGNhbiB5b3UgZ3V5cyBzdWdnZXN0IHNvbWUgdGV4dCB0byBt YWtlIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgdXNhZ2UgY2xlYXJlcj88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1Jp ZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIE1vbiwgSmFuIDIxLCAyMDE5IGF0IDEwOjMyIEFNIEJyaWFuIENhbXBiZWxs ICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BcyBJIHN1Z2dlc3RlZCBiZWZvcmUsIEkgZG8gdGhpbmsgdGhhdCdz IHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkcmFmdCdzIGRlZmluaXRpb24gb2YgJ3Jlc291cmNl JyBhcyBhIFVSSS4gQW5kIHRoYXQgcGVyaGFwcyBhbGwgdGhhdCdzIG5lZWRlZCBpcyBzb21lIG1p bm9yIGFkanVzdG1lbnQgYW5kL29yIGF1Z21lbnRhdGlvbg0KIG9mIHNvbWUgdGV4dCB0byBtYWtl IGl0IG1vcmUgY2xlYXIuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFN1biwgSmFuIDIwLCAyMDE5IGF0IDc6MzkgUE0gVml0dG9yaW8gQmVydG9j Y2kgJmx0OzxhIGhyZWY9Im1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5r Ij5WaXR0b3Jpb0BhdXRoMC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE2LjVwdDtjb2xvcjojMzEzMTMxO2JhY2tncm91bmQ6d2hpdGUiPltzZW50IHRvIEpvaG4gb25s eSBieSBtaXN0YWtlLCByZXNlbmRpbmcgdG8gdGhlIE1MXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTYuNXB0O2NvbG9yOiMzMTMxMzE7YmFja2dyb3VuZDp3aGl0ZSI+SW4gQXp1cmUgQUQgdjEg JmFtcDsgQURGUywgdGhhdCdzJm5ic3A7PC9zcGFuPnJlc291cmNlPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNi41cHQ7Y29sb3I6IzMxMzEzMTtiYWNrZ3JvdW5kOndoaXRlIj4uLiBJdCBjb3VsZA0K IGJlIHVzZWQgZm9yIGJvdGggbmV0d29yayBhbmQgbG9naWNhbCBpZHMsIHdpdGggdGhlIGNvbmNy ZXRlIHVzYWdlIGluIHRoZSB3aWxkIEkgZGVzY3JpYmVkIGVhcmxpZXIuPC9zcGFuPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzMxMzEzMSI+SW4gQXp1cmUgQUQgdjIsIHRoZSByZXNvdXJjZSBhcyBleHBsaWNpdCBwYXJh bWV0ZXIgKG5ldHdvcmssIGxvZ2ljIG9yIG90aGVyd2lzZSkgaXMgZ29uZSBhbmQgaXMgZXhwcmVz c2VkIGFzIHBhcnQgb2YgdGhlIHNjb3BlIHN0cmluZyBvZiBhbGwgdGhlIHNjb3Blcw0KIHJlcXVl c3RlZCBmb3IgYSBnaXZlbiByZXNvdXJjZS0gYnV0IGl0IHN0aWxsIGV4aXN0IGluIHByYWN0aWNl IHRobyBhcyBpdCBzdGlsbCBlbmQgdXAgaW4gdGhlIHJlc3VsdGluZyZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzMxMzEz MSI+YXVkPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMzEzMTMxIj4mbmJzcDtvZiB0aGUgaXNz dWVkIHRva2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMTMxMzEiPlRoaXMgaXMgOSBtb250 aHMgb2xkIGluZm8gaGVuY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBKYW4gMjAsIDIwMTkgYXQg MTc6NTggSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20i IHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD5XaGF0IGlzIHRoZSBwYXJhbWV0ZXIgdGhhdCBN aWNyb3NvZnQgaXMgdXNpbmc/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiAxLzIwLzIwMTkgMzo1OSBQTSwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZpcnN0IG9mIGFsbCwgaXQgd2Fzbid0IG15IGludGVu dCB0byBkaXNydXB0IHRoZSBlc3RhYmxpc2hlZCBwcm9jZXNzLiBJbiBteSBmb3JtZXIgcG9zaXRp b24gSSB3YXNuJ3QgbW9uaXRvcmluZyB0aG9zZSBkaXNjdXNzaW9ucyBoZW5jZSBJIGRpZG4ndCBo YXZlIGEgY2hhbmNlIHRvIG9mZmVyIGZlZWRiYWNrLg0KIFdoZW4gSSBzYXcgc29tZXRoaW5nIHRo YXQgZ2F2ZSBtZSB0aGUgaW1wcmVzc2lvbiBtaWdodCBsZWFkIHRvIGlzc3VlcywgYW5kIGdpdmVu IHRoYXQgSSB3b3JrZWQgd2l0aCBhY3R1YWwgZGVwbG95bWVudHMgYW5kIGRldmVsb3BlcnMgdXNp bmcgYSBzaW1pbGFyIHBhcmFtZXRlciBmb3IgYSBsb25nIHRpbWUsIEkgdGhvdWdodCBwcnVkZW50 IHRvIGJyaW5nIHRoaXMgdXAuIEkgcmVhbGx5IGFwcHJlY2lhdGUgUmlmYWF0J3Mgc3RhbmNlIG9u IHRoaXMuDQogRW5kIG9mIHByZWFtYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VbHRpbWF0ZWx5IG15IGdvYWwgaXMg Zm9yIGRldmVsb3BlcnMgdG8gaGF2ZSBndWlkYW5jZSBvbiBob3cgdG8gd29yayB3aXRoIHRoZSBj b25jZXB0IG9mIGxvZ2ljYWwgcmVzb3VyY2UgaW4gYSBzdGFuZGFyZCBjb21wbGlhbnQgd2F5LCBo ZW5jZSBpdCBkb2Vzbid0IHN0cmljdGx5IG1hdHRlciB3aGV0aGVyIHRoZQ0KIGRlZmluaXRpb24g b2YgdGhlIGNvcnJlc3BvbmRpbmcgcGFyYW1ldGVyIGxpdmVzIGluJm5ic3A7b2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycyBvciBlbHNld2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgc2FpZC4gUmVhZGluZyB0aHJvdWdoIHRoZSBk cmFmdCwgaXQgd291bGQgYXBwZWFyIHRoYXQgbW9zdCBvZiB0aGUgcmVhc29ucyBmb3Igd2hpY2gg dGhlIHNwZWMgd2FzIGNyZWF0ZWQgYXBwbHkgdG8gYm90aCB0aGUgbmV0d29yayBhZGRyZXNzYWJs ZSBhbmQgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgdHlwZXM6DQoga25vd2luZyB3aGF0IGtleXMgdG8g dXNlIHRvIGVuY3J5cHQgdGhlIHRva2VuLCBjb25zdHJhaW4gYWNjZXNzIHRva2VucyB0byB0aGUg aW50ZW5kZWQgYXVkaWVuY2UsIGF2b2lkaW5nIG92ZXJsb2FkaW5nIHNjb3BlcyB3aXRoIHJlc291 cmNlIGluZGljYXRpbmcgcGFydHMuLi4gdGhvc2UgYWxsIGFwcGx5IHRvIG5ldHdvcmsgYWRkcmVz c2FibGUgYW5kIGxvZ2ljIGlkZW50aWZpZXJzIGFsaWtlLiBBbmQgYm90aCBwYXJhbWV0ZXJzIGFy ZSBleHBlY3RlZA0KIHRvIHJlc3VsdCBpbiBhdWRpZW5jZSByZXN0cmljdGVkIHRva2Vucy4gSXQg c2VlbXMgdGhlIG9ubHkgZGlmZmVyZW5jZSBjb21lcyBhdCB0b2tlbiB1c2FnZSB0aW1lLCB3aXRo IHRoZSBuZXR3b3JrIGFkZHJlc3NhYmxlIGNhc2UgZ2l2aW5nIG1vcmUgZ3VhcmFudGVlcyB0aGF0 IHRoZSB0b2tlbiB3aWxsIGdvIHRvIGl0cyBpbnRlbmRlZCByZWNpcGllbnQsIGJ1dCB0aGUgcmVx dWVzdCBhbmQgYXVkaWVuY2UgcmVzdHJpY3Rpb24gc3ludGF4IHNlZW1zDQogdG8gYmUgZXhhY3Rs eSB0aGUgc2FtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gdG9wIG9mIHRoaXM6IGluIHRoZSA5OS45OTklIG9mIHRoZSBzY2Vu YXJpb3MgSSBlbmNvdW50ZXJlZCBpbiB0aGUgd2lsZCBpbiB0aGUgbGFzdCA1IHllYXJzIG9mIHVz aW5nIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4gdGhlIE1TIGVjb3N5c3RlbSwgdGhlIHJlc291 cmNlIGlkZW50aWZpZXIgd2FzIGtub3duDQogYXQgZGVzaWduIHRpbWU6IHRoZSBkZXZlbG9wZXIg ZGlzY292ZXJlZCBpdCBvdXQgb2YgYmFuZCBhbmQgcGxhY2VkIGl0IGluIHRoZSBhcHAgY29uZmln IGF0IGRlcGxveW1lbnQgdGltZS4gVGhvc2UgYXJlbid0IGZyaW5nZSBjYXNlcyBJIG9jY2FzaW9u YWxseSBlbmNvdW50ZXJlZDogdGhlIHJlc291cmNlIHBhcmFtZXRlciBpbiBBenVyZSBBRCB2MSBh bmQgQURGUyB3YXMgbWFuZGF0b3J5LCBoZW5jZSBsaXRlcmFsbHkgZXZlcnkgc29sdXRpb24gaQ0K IHNhdyBvciB0b3VjaGVkIHVzZWQgaXQuIEFzIEJyaWFuIHN1Z2dlc3RlZCwgdGhpcyBpcyBhIHNj ZW5hcmlvIHdoZXJlIHRoZSBzZWN1cml0eSBhZHZhbnRhZ2VzIG9mIHRoZSBuZXR3b3JrIGFkZHJl c3NhYmxlIGNhc2UgYXJlbid0IGFzIHByb25vdW5jZWQgYXMgaW4gdGhlIGNhc2UgaW4gd2hpY2gg dGhlIGNsaWVudCBkaXNjb3ZlcnMgdGhlIHJlc291cmNlIGlkZW50aWZpZXIgYXQgcnVudGltZS4g VGhpcyBpc24ndCBqdXN0IGJlY2F1c2UgdGhlcmUNCiBpcyBubyBzcGVjaWZpY2F0aW9uIHN1Z2dl c3RpbmcgbG9jYXRpb24gc2hvdWxkIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLCBpdCdzIGJlY2F1 c2UgdGhlcmUgYXJlIG1hbnkgcHJhY3RpY2FsIGFkdmFudGFnZXMgYXQgZGV2ZWxvcG1lbnQgYW5k IGRlcGxveW1lbnQgdGltZSB0byBiZSBhYmxlIHRvIHVzZSBsb2dpY2FsIGlkZW50aWZpZXJzLSBh bmQgaWYgdGhlDQo8aT5jb25jcmV0ZSA8L2k+c2VjdXJpdHkgYWR2YW50YWdlcyBkb24ndCBhcHBs eSB0byB0aGUgdGhlaXIgY2FzZSwgcGVvcGxlIHdpbGwgc2ltcGx5IG5vdCBjb21wbHkuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JbiBzdW1tYXJ5OiBjcmVhdGluZyB0d28gZGlmZmVyZW50IHBhcmFtZXRlcnMgaW4gdHdvIGRp ZmZlcmVudCBkb2N1bWVudHMgaXMgYmV0dGVyIHRoYW4gaWdub3JpbmcgaGUgbG9naWNhbCBpZGVu dGlmaWVyIGNhc2UgYWx0b2dldGhlciwgaG93ZXZlciBJIHRoaW5rIHRoYXQgbm90IGFja25vd2xl ZGdpbmcgdGhlDQogbG9naWNhbCBpZCBjYXNlIGluJm5ic3A7b2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9ycyBpcyBnb2luZyB0byBjcmVhdGUgY29uZnVzaW9uIGFuZCB1bHRpbWF0ZWx5IG5vdCBiZSBh cyB1c2VmdWwgdG8gdGhlIGRldmVsb3BlciBjb21tdW5pdHkgYXMgaXQgY291bGQgYmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBKYW4gMTksIDIwMTkgYXQgMTI6Mzgg UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiYjNDM7MSB0byBNaWtlIGFu ZCBKb2hu4oCZcyBjb21tZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT24gSmFuIDE5LCAyMDE5LCBhdCAxMjozNCBQTSwgTWlrZSBKb25l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPkkgYWxzbyBhZ3JlZSB0aGF0IOKAnHJlc291cmNl4oCdIHNob3VsZCBiZSBhIHNwZWNp ZmljIG5ldHdvcmstYWRkcmVzc2FibGUgVVJMIHdoZXJlYXMgYSBzZXBhcmF0ZSBhdWRpZW5jZSBw YXJhbWV0ZXIgKGxpa2Ug4oCcYXVk4oCdIGluIEpXVHMpIGNhbiByZWZlciB0byBvbmUNCiBvciBt b3JlIGxvZ2ljYWwgcmVzb3VyY2VzLiZuYnNwOyBUaGV5IGFyZSBkaWZmZXJlbnQsIGlmIHJlbGF0 ZWQsIHRoaW5ncy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Ob3Rl IHRoYXQgdGhlIEFDRSBXRyBpcyBwcm9wb3NpbmcgdG8gcmVnaXN0ZXIgYSBsb2dpY2FsIGF1ZGll bmNlIHBhcmFtZXRlciDigJxyZXFfYXVk4oCdIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTAxIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFy YW1zLTAxPC9hPiAtIHBhcnRseSBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIE9BdXRoIFdHIG1lbWJl cnMuJm5ic3A7IFRoaXMgaXMgYSBnZW5lcmFsIE9BdXRoIHBhcmFtZXRlciwgd2hpY2ggYW55IE9B dXRoIGRlcGxveW1lbnQgd2lsbCBiZSBhYmxlIHRvIHVzZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5JIHRoZXJlZm9yZSBiZWxpZXZlIHRoYXQgbm8gY2hhbmdlcyBh cmUgbmVlZGVkIHRvIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycywgYXMgdGhl IGxvZ2ljYWwgYXVkaWVuY2Ugd29yayBpcyBhbHJlYWR5IGhhcHBlbmluZyBpbiBhbm90aGVyDQog ZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDE5LCAyMDE5IDk6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEJy aWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRv cmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW89 NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTaGVwaGVyZCB3 cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgbmVlZCB0byBkZWNpZGUgaWYgd2Ugd2Fu dCB0byBtYWtlIGEgY2hhbmdlLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBzZWN1cml0eSB3ZSBhcmUgbG9jYXRpb24gY2Vu dHJpYy4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkkgcHJlZmVyIHRvIGtlZXAgcmVzb3VyY2UgbG9jYXRpb24gc2Vw YXJhdGUgZnJvbSBsb2dpY2FsIGF1ZGllbmNlIHRoYXQgY2FuIGJlIGEgc2NvcGUgb3Igb3RoZXIg cGFyYW1ldGVyLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgYmVjb21lcyBoYXJkZXIgZm9yIHBlb3BsZSB0byB1 c2UgdGhlIHBhcmFtZXRlciBjb3JyZWN0bHkgaWYgd2UgYXJlIHRvbyBmbGV4aWJsZS4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgd291bGQgcmF0aGVyIGhhdmUgYSBzZXBhcmF0ZSBsb2dpY2FsIGF1ZGllbmNlIHBh cmFtZXRlciBpZiB3ZSB0aGluayB3ZSB3YW50IG9uZS4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFNhdCwgSmFuIDE5LCAyMDE5LCAxMTo0MSBBTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2Jv cmRlci1jb2xvcjpjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy Z2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O byBhcG9sb2d5IG5lZWRlZCwgUmlmYWF0LiBBbmQgSSBhcG9sb2dpemUgaWYgd2hhdCBJIHNhaWQg Y2FtZSBvZmYgdGhlIHdyb25nIHdheS4gSSB3YXMganVzdCB0cnlpbmcgdG8gbWFrZSBsaWdodCBv ZiB0aGUgc2l0dWF0aW9uLi4gQW5kIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IGJlIGhhbXN0 cnVuZw0KIGJ5IHRoZSBwcm9jZXNzIGFuZCB0aGVyZSBhcmUgdGltZXMgd2hlbiBpdCBtYWtlcyBz ZW5zZSB0byBiZSBmbGV4aWJsZSB3aXRoIHRoaW5ncy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMTgsIDIwMTkg YXQgNjoyMiBQTSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQu aWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Tb3JyeSBCcmlhbiwgSSB3YXMgbm90IGNsZWFyIHdpdGggbXkgc3RhdGVtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JIG1lYW50IHRvIHNheSB0aGF0IHdlIHNob3VsZCBub3QgYWxsb3cgdGhlIHByb2Nlc3Mg dG8gcHJldmVudCB0aGUgV0cgZnJvbSBwcm9kdWNpbmcgYSBxdWFsaXR5IGRvY3VtZW50IHdpdGhv dXQgaXNzdWVzLCBhc3N1bWluZyB0aGVyZSBpcyBhbiBpc3N1ZSBpbiB0aGUgZmlyc3QgcGxhY2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklk ZWFsbHkgd2Ugd2FudCB0byBnZXQgdGhlc2UgaWRlbnRpZmllZCBkdXJpbmcgdGhlIFdHTEMsIGJ1 dCB0aGluZ3MgaGFwcGVuIGFuZCBzb21ldGltZXMgdGhlIFdHIG1pc3NlcyBzb21ldGhpbmcuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JIGhlYXIgeW91IGFuZCBhZ3JlZSB0aGF0IHRoaXMgbWFrZSB0aGluZ3MgZGlmZmljdWx0 IGZvciBhdXRob3JzLiBXZSB3aWxsIG1ha2Ugc3VyZSB0aGF0IHRoaXMgZG9lcyBub3QgYmVjb21l IHRoZSBub3JtLCBhbmQgd2Ugd2lsbCB0cnkgdG8gc3RpY2sgdG8gdGhlIHByb2Nlc3MgYXMgbXVj aCBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBGcmksIEphbiAxOCwgMjAxOSBhdCA1OjM1IFBNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2Jv cmRlci1jb2xvcjpjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy Z2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MgUmlmYWF0LiBQcm9jZXNzIGlzIGFzIHByb2Nlc3MgZG9lcywgcmlnaHQ/IEkgZG8ga2lu ZGEgd2FudCB0byBncnVtYmxlIGFib3V0IFdHQ0wgaGF2aW5nIHBhc3NlZCBhbHJlYWR5IGJ1dCB0 aGF0J3MgbW9zdGx5IGJlY2F1c2UgcmVwbHlpbmcgdG8gdGhlc2Uga2luZHMgb2YgdGhyZWFkcyBp cyBoYXJkDQogZm9yIG1lIGFuZCBJJ2xsIGp1c3QgZ2V0IG92ZXIgaXQuLi4gPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBmYXIgYXMg SSB1bmRlcnN0YW5kIHRoaW5ncywgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGNvbWUgaW50byBwbGF5 IHdoZW4gdGhlIGNsaWVudCBpcyBiZWluZyB0b2xkIHRoZSBieSB0aGUgcmVzb3VyY2UgaG93IHRv IGlkZW50aXR5IHRoZSByZXNvdXJjZSBsaWtlIGlzIGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzdHJpYnV0ZWQtMDEi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWRpc3RyaWJ1dGVkLTAxPC9hPiBhbmQgdXNpbmcgdGhlIGFjdHVhbCBsb2NhdGlvbiBp biB0aGF0IGNvbnRleHQgLGFsb25nIHdpdGggc29tZSBvdGhlciBjaGVja3MgcHJlc2NyaWJlZCBp biB0aGF0IGRyYWZ0LCBwcmV2ZW50cyB0aGUga2luZCBvZiBpc3N1ZXMgSm9obiBkZXNjcmliZWQg ZWFybGllciBpbiB0aGUgdGhyZWFkLg0KPGJyPg0KPGJyPg0KSW4gY2FzZXMgd2hlcmUgdGhlIGNs aWVudCBrbm93cyB0aGUgcmVzb3VyY2UgYSBwcmlvcmkgb3Igb3V0LW9mLWJhbmQgb3IgY29uZmln dXJlZCBvciB3aGF0ZXZlciwgSSBkb24ndCB0aGluayB0aGUgc2FtZSBzZWN1cml0eSBjb25jZXJu cyBhcmlzZS4gQW5kIHVzaW5nIHN1Y2ggYSBrbm93biB2YWx1ZSwgYmUgaXQgYW4gYWN0dWFsIGxv Y2F0aW9uIG9yIGxvZ2ljYWwgcmVwcmVzZW50YXRpb24sIHdvdWxkIGJlIG9rYXkuPGJyPg0KPGJy Pg0KVGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQgaXMgYWRtaXR0ZWRseSBzb21ld2hhdCBs b2NhdGlvbi1jZW50cmljIGluIGhvdyBpdCB0YWxrcyBhYm91dCB0aGUgdmFsdWUgb2YgdGhlICdy ZXNvdXJjZScgcGFyYW1ldGVyLiBCdXQgdWx0aW1hdGVseSBpdCBkZWZpbmVzIGl0IGFzIGFuIGFi c29sdXRlIFVSSSB0aGF0IGluZGljYXRlcyB0aGUgbG9jYXRpb24gb2YgdGhlIHRhcmdldCBzZXJ2 aWNlIG9yIHJlc291cmNlIHdoZXJlIGFjY2VzcyBpcw0KIGJlaW5nIHJlcXVlc3RlZC4gQSBsb2Nh dGlvbiBjYW4gYmUgdmFyeWluZyBzaGFkZXMgb2YgYWJzdHJhY3QgYW5kIEknZCBzYXkgdGhhdCB1 c2luZyBhIFVSSSBhcyAncmVzb3VyY2UnIHBhcmFtZXRlciB2YWx1ZSB0aGF0J3MgYSBsb2dpY2Fs IGlkZW50aWZpZXIgdGhhdCBwb2ludHMgdG8gc29tZSByZXNvdXJjZSBpcyB3ZWxsIHdpdGhpbiB0 aGUgYm91bmRzIG9mIHRoZSBkcmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28gbWF5YmUgdGhlIGRyYWZ0IGlzIG9rYXkgYXMg aXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PciBwZXJoYXBzIHRoYXQncyB0b28gbXVjaCB0byBiZSBsZWZ0IGFzIGFuIGV4ZXJjaXNl ciB0byB0aGUgcmVhZGVyPyZuYnNwOyBBbmQgc29tZSB0ZXh0IHNob3VsZCBiZSBhZGRlZCBhbmQv b3IgYWRqdXN0ZWQgc28gdGhlIHJlc291cmNlLWluZGljYXRvcnMgZHJhZnQgd291bGQgYmUgYSBs aXR0bGUgbW9yZSBvcGVuL2NsZWFyDQogYWJvdXQgdGhlIHBhcmFtZXRlciB2YWx1ZSBwb3RlbnRp YWxseSBiZWluZyBtb3JlIG9mIGEgbG9naWNhbCBvciBhYnN0cmFjdCBpZGVudGlmaWVyIGFuZCBu b3QgbmVjZXNzYXJpbHkgYSBuZXR3b3JrIGFkZHJlc3NhYmxlIFVSTD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJp LCBKYW4gMTgsIDIwMTkgYXQgMToxOCBQTSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6 Y3VycmVudGNvbG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY3VycmVudGNvbG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQs MjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkbid0IHdvcnJ5IHRv byBtdWNoIGFib3V0IHRoZSBwcm9jZXNzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SWYgaXQgbWFrZXMgc2Vuc2UgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCwg dGhlbiBmZWVsIGZyZWUgdG8gZG8gdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZy aSwgSmFuIDE4LCAyMDE5IGF0IDM6MDggUE0gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWls dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMgdGhlJm5ic3A7bG9naWNhbCByZXNv dXJjZSBjYW4gYmUgcHJvdmlkZWQgYnkgJnF1b3Q7c2NvcGUmcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgaW1wbGVtZW50 YXRpb25zIGxpa2UgUGluZyBhbmQgQXV0aDAgaGF2ZSBiZWVuIGFkZGluZyBhbm90aGVyIHBhcmFt ZXRlciAmcXVvdDthdWQmcXVvdDsgdG8gaWRlbnRpZnkgdGhlIGxvZ2ljYWwgcmVzb3VyY2UgYW5k IHRoZW4gdXNpbmcgc2NvcGVzIHRvIGRlZmluZSBwZXJtaXNzaW9ucyB0byB0aGUgcmVzb3VyY2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Gb3J0dW5hdGVseSwgd2UgYXJlIHVzaW5nIGEgZGlmZmVyZW50Jm5ic3A7cGFyYW1ldGVyIG5h bWUgc28gbm90IHN0ZXBwaW5nIG9uIHRoYXQuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgY291bGQgZ28gYmFjayBhbmQgdHJ5IHRv IGFkZCB0ZXh0IGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVuY2UsIGJ1dCB3ZSBhcmUgcXVpdGUgbGF0 ZSBpbiB0aGUgcHJvY2Vzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgdGhhdCBhIGxvZ2ljYWwgcmVzb3VyY2Ug cGFyYW1ldGVyJm5ic3A7bWF5IGJlIGhlbHBmdWwsIGJ1dCBwZXJoYXBzIGl0IHNob3VsZCBiZSBh IHNlcGFyYXRlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDQ6MzggUE0gUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjdXJyZW50Y29sb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Eb2VzbuKAmXQgdGhlIOKAnHNjb3Bl4oCdIHBhcmFtZXRlciBhbHJl YWR5IHByb3ZpZGUgYSBtZWFucyBvZiBzcGVjaWZ5aW5nIGEgbG9naWNhbCBpZGVudGlmaWVyPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRl bnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz08YSBocmVmPSJtYWlsdG86 NDBhdXRoMC4uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEphbnVhcnkg MTgsIDIwMTkgYXQgNTo0NyBBTTxicj4NCjxiPlRvOiA8L2I+Sm9obiBCcmFkbGV5ICZsdDs8YSBo cmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3 anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRVRGIG9hdXRoIFdHICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRl LXVwIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MgSm9obiBmb3IgdGhlIGJhY2tncm91bmQuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgdGhhdCBmcm9tIHRoZSBjbGllbnQgdmFsaWRh dGlvbiBQb1YsIGhhdmluZyBhbiBpZGVudGlmaWVyIGNvcnJlc3BvbmRpbmcgdG8gYSBsb2NhdGlv biBtYWtlcyB0aGluZ3MgbW9yZSBzb2xpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBzYWlkOiB0aGUgdXNlIG9mIGxvZ2ljYWwgaWRl bnRpZmllcnMgaXMgd2lkZXNwcmVhZCwgYXMgaXQgaGFzIHNpZ25pZmljYW50IHByYWN0aWNhbCBh ZHZhbnRhZ2VzICh0aGluayBvZiBzZXJ2aWNlcyB0aGF0IGFzc2lnbiBnZW5lcmF0ZWQgaG9zdGlu ZyBVUkxzIG9ubHkgYXQgZGVwbG95bWVudCB0aW1lLA0KIG9yIHNlcnZpY2VzIHRoYXQgYXJlIHNv bWVob3cgZ3JvdXBlZCB1bmRlciB0aGUgc2FtZSBsb2dpY2FsIGF1ZGllbmNlIGFjcm9zcyByZWdp b25zL2Vudmlyb25tZW50L2RlcGxveW1lbnRzKS4gUGVvcGxlIHdvbid0IHN0b3AgdXNpbmcgbG9n aWNhbCBpZGVudGlmaWVycywgYmVjYXVzZSB0aGV5IG9mdGVuIGhhdmUgbm8gYWx0ZXJuYXRpdmUg KGdlbmVyYXRpbmcgbmV3IGF1ZGllbmNlcyBvbiB0aGUgZmx5IGF0IHRoZSBBUyBldmVyeSB0aW1l IHlvdQ0KIGRvIGEgZGVwbG95bWVudCBhbmQgZ2V0IGFzc2lnbmVkIGEgbmV3IFVSTCBjYW4gYmUg dW5mZWFzaWJsZSkuIExlYXZpbmcgYSB3aWRlbHkgdXNlZCBhcHByb2FjaCBhcyBleGVyY2lzZSB0 byB0aGUgcmVhZGVyIHNlZW1zIGEgZGlzc2VydmljZSB0byB0aGUgY29tbXVuaXR5LCBnaXZlbiB0 aGF0IHRoaXMgbWlnaHQgbGVhZCB0byB2ZW5kb3JzIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgYW5k IEF1dGgwKSBrZWVwaW5nIHRoZWlyIG93biBwcm9wcmlldGFyeQ0KIHBhcmFtZXRlcnMsIG9yIGRl dmVsb3BlcnMgbWlzdXNpbmcgdGhlIG9uZXMgaW4gcGxhY2U7IHdvdWxkIG1ha2UgaXQgaGFyZCBm b3IgU0RLIGRldmVsb3BlcnMgdG8gcHJvdmlkZSBsaWJyYXJpZXMgdGhhdCB3b3JrIG91dCBvZiB0 aGUgYm94IHdpdGggZGlmZmVyZW50IEFTZXM7IGFuZCBzbyBvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V291bGQgaXQgYmUgZmVhc2libGUg dG8gYWRkIHN1Y2ggcGFyYW1ldGVyIGRpcmVjdGx5IGluIHRoaXMgc3BlYz8gVGhhdCB3b3VsZCBl bGltaW5hdGUgdGhlIGludGVyb3AgaXNzdWVzLCBhbmQgYWxzbyBnaXZlcyB1cyBhIGNoYW5jZSB0 byBmdWxseSB3YXJuIHBlb3BsZSBhYm91dCB0aGUgc2VjdXJpdHkgc2hvcnRjb21pbmdzDQogb2Yg Y2hvb3NpbmcgdGhhdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4gMTcsIDIwMTkgYXQg NDozMiBQTSBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwPldlIGhhdmUgZGlzY3Vzc2VkIHRoaXMuPG86 cD48L286cD48L3A+DQo8cD5BdWRpZW5jZXMgY2FuIGNlcnRhaW5seSBiZSBsb2dpY2FsIGlkZW50 aWZpZXJzLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgaG93ZXZlciBpcyBh IG1vcmUgc3BlY2lmaWMgbG9jYXRpb24uJm5ic3A7IFRoZSBBUyBpcyBmcmVlIHRvIG1hcCB0aGUg bG9jYXRpb24gaW50byBzb21lIGFic3RyYWN0IGF1ZGllbmNlIGluIHRoZSBBVC48bzpwPjwvbzpw PjwvcD4NCjxwPkZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uY2UgdGhlIGNsaWVudCBz dGFydHMgYXNraW5nIGZvciBsb2dpY2FsIHJlc291cmNlcyBpdCBjYW4gYmUgdHJpY2tlZCBpbnRv IGFza2luZyBmb3IgdGhlIHdyb25nIG9uZSBhcyBhIGJhZCByZXNvdXJjZSBjYW4gYWx3YXlzIGxp ZSBhYm91dCB3aGF0IGxvZ2ljYWwgcmVzb3VyY2UgaXQgaXMuPG86cD48L286cD48L3A+DQo8cD5J ZiB3ZSB3ZXJlIHRvIGNoYW5nZSBpdCwgaG93IGEgY2xpZW50IHdvdWxkIHZhbGlkYXRlIGl0IGJl Y29tZXMgY2hhbGxlbmdpbmcgdG8gaW1wb3NzaWJsZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhl IEFTIGlzIGZyZWUgdG8gZG8gd2hhdGV2ZXIgbWFwcGluZyBvZiBsb2NhdGlvbnMgdG8gaWRlbnRp ZmllcnMgaXQgbmVlZHMgZm9yIGFjY2VzcyB0b2tlbnMuPG86cD48L286cD48L3A+DQo8cD5Tb21l IGltcGxlbWVudGF0aW9ucyBtYXkgd2FudCB0byBrZWVwIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBs aWtlIGxvZ2ljYWwgYXVkaWVuY2UsIGJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0ZSBmcm9tIHJl c291cmNlLjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMS8xNy8yMDE5IDk6NTYgQU0sIFJpZmFhdCBTaGVr aC1ZdXNlZiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSBWaXR0b3JpbywNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgY29waWVkIGZvcm0g dGhlIGFic3RyYWN0IG9mIHRoZSBkcmFmdCBpdHNlbGYuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+QXV0aG9ycyw8L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5T aG91bGQgdGhlIGRyYWZ0IGJlIHVwZGF0ZWQgdG8gY292ZXIgdGhlIGxvZ2ljYWwgaWRlbnRpZmll ciBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4gMTcsIDIwMTkgYXQg ODoxOSBBTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvQGF1 dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZpdHRvcmlvQGF1dGgwLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhpIFJpZmFhdCwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+b25lIGRldGFpbC4gVGhlIHRlY2ggc3VtbWFyeSBzYXlzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2Jh Y2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+QW4gZXh0ZW5zaW9uIHRvIHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBG cmFtZXdvcmsgZGVmaW5pbmcgcmVxdWVzdCA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JhY2tncm91bmQt YXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9z aXRpb24teTowJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5wYXJhbWV0ZXJzIHRoYXQgZW5hYmxlIGEg Y2xpZW50IHRvIGV4cGxpY2l0bHkgc2lnbmFsIHRvIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIDwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti YWNrZ3JvdW5kOiNGRkZERjU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5k LXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPmFib3V0IHRoZSA8Yj5sb2NhdGlvbjwvYj4gb2YgdGhlIHByb3RlY3RlZCByZXNvdXJjZShz KSB0byB3aGljaCBpdCBpcyByZXF1ZXN0aW5nIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7YmFja2dyb3Vu ZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1w b3NpdGlvbi15OjAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPmFjY2Vzcy48L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C dXQgYXQgbGVhc3QgaW4gdGhlIE1pY3Jvc29mdCBpbXBsZW1lbnRhdGlvbiwgdGhlIHJlc291cmNl IGlkZW50aWZpZXIgZG9lc24ndA0KPGk+aGF2ZTwvaT4gdG8gYmUgYSBuZXR3b3JrIGFkZHJlc3Nh YmxlIFVSTCAoYW5kIGlmIGl0IGlzLCBpdCBkb2Vzbid0IHN0cmljdGx5IG5lZWQgdG8gbWF0Y2gg dGhlIGFjdHVhbCByZXNvdXJjZSBsb2NhdGlvbikuIEl0IGNhbiBiZSBhIGxvZ2ljYWwgaWRlbnRp ZmllciwgdGhvIHVzaW5nIHRoZSBhY3R1YWwgcmVzb3VyY2UgbG9jYXRpb24gdGhlcmUgaGFzIGJl bmVmaXRzIChkb21haW4gb3duZXJzaGlwIGNoZWNrLCBwcmV2ZW50aW9uIG9mIHRva2VuDQogZm9y d2FyZGluZyBldGMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TYW1lIGZvciBBdXRoMCwgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciBpcyBhIGxv Z2ljYWwgaWRlbnRpZmllciByYXRoZXIgdGhhbiBhIGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQs IEphbiAxNiwgMjAxOSBhdCA2OjMyIFBNIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxsLA0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGZvbGxvd2luZyBpcyB0 aGUgZmlyc3Qgc2hlcGhlcmQgd3JpdGUtdXAgZm9yIHRoZSZuYnNwO2RyYWZ0LWlldGYtb2F1dGgt cmVzb3VyY2UtaW5kaWNhdG9ycy0wMSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzL3NoZXBo ZXJkd3JpdGV1cC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvc2hlcGhlcmR3cml0ZXVw LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCZuYnNwO21lIGtub3cgaWYgSSBtaXNz ZWQgYW55dGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJp YWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4NCiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUt bWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9t IHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4m bmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBk aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMNCiBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N CjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJl Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMNCiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91Ljwvc3Bhbj48L2k+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR00MB029262B150B2D8F3C3792302F5960BL0PR00MB0292namp_-- From nobody Mon Jan 28 12:55:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171961311BB for ; Mon, 28 Jan 2019 12:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kk8dPbTXliM0 for ; Mon, 28 Jan 2019 12:54:45 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D7F1311F6 for ; Mon, 28 Jan 2019 12:54:45 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id m62so700715ith.5 for ; Mon, 28 Jan 2019 12:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=axqc8SPM4Lr0OYb7IwijSKuiuKbw41GeAH0kBNdDFkI=; b=Yf5uDPA9n5zW3jIbC5jn/t9qJhW9VJ+LvlW1cj55I3z+QIlOjKiI2ykJGa/hN5vC2a nYTYeCpPC92ToNAtetc3AY+AXvFBEhDhTanv9zMSMvOfutYlHxkizCce+DZhuR73klJ1 +9QjzVnoN8Nfms+wNhjnbndC+9S08M6MCdQnE= 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=axqc8SPM4Lr0OYb7IwijSKuiuKbw41GeAH0kBNdDFkI=; b=pt3/SPhwVark4OwTF20OdGmJcT0SrJBbTVdFZCTDcpxz1IpUEcAjdWi0O1WUtauTON ZIF4M1G9qRqYeii1s27YPX5Z/J7agGWvrnllGfqXKX/hRrFm4s70yqPVOcWHP3tv9vII 8Y89OOqShr7opG0h9iv0BHvLWLXc29ZQhJkBdVkZsCYJC6xo0X2OGbfEIU3fsOPf1An6 28bVBatcckpF+mGsJZOD3TPb27uH32Fnoj9EJHA3fYroCve/FBUtUNnkxNquZHjw5iZW ZP+xu4xa1ofrdov7htSKoQ8vlqFsWKGOCCywMqIRF6bDoG2aSBYr+vXkj7pmODHTAQ5K 6mZw== X-Gm-Message-State: AJcUukcw1xhksX5zBoj0M5jgd9k5/ELa/fM7Ly1YGDzqB7M+Rxbrw7xO GqGesnW0XB0eH2wXhSzRPhjUXySK6wlNM3S0n1yPc/IiLtkEKC/BsR4nSBYTLTi/8FmtYuzcCx7 EsKyrzdqgEoz06w== X-Google-Smtp-Source: ALg8bN5wgdEAq0ktvbRhjpMreTuW21z4FUeL0rbZtegOGiudO9xVSkip01aAEOl9Rn/W8F30OK18/J4Nboci4USX1Ig= X-Received: by 2002:a24:6293:: with SMTP id d141mr9538601itc.124.1548708884080; Mon, 28 Jan 2019 12:54:44 -0800 (PST) MIME-Version: 1.0 References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> In-Reply-To: From: Brian Campbell Date: Mon, 28 Jan 2019 13:54:16 -0700 Message-ID: To: Mike Jones , ace@ietf.org Cc: "George Fletcher at aol.com" , "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000e5896805808ae2c6" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 20:54:54 -0000 --000000000000e5896805808ae2c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [added ace@ietf.org kinda per suggestion from Mike] I don't know that there are concerns about =E2=80=9Creq_aud=E2=80=9D per se= . Admittedly, I did use the word "concerns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80=9D= is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway. I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different. On Mon, Jan 28, 2019 at 11:28 AM Mike Jones wrote: > Brian, etc. If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now=E2= =80=99s the time to > provide that feedback to the ACE WG, as they=E2=80=99re trying to complet= e that > draft soon. Please join the ACE WG mailing list and send your feedback > there directly. > > > > You and I may know that ACE OAuth and OAuth 2 are pretty different but > developers later will just see the OAuth parameter registration and won= =E2=80=99t > realize that it=E2=80=99s coming from a different universe. If we can ha= rmonize > things now, we should. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *George Fletcher > *Sent:* Monday, January 28, 2019 10:05 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org; Vittorio Bertocci > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > +1 > > I came to a similar conclusion over the weekend. If > https://api.example.com/mail is an allowed location URI, how is it not > also a logical location considering it's possible there are multiple > endpoints "below" https://api.example.com/mail? (e.g. > https://api.example.com/mail/user/mailbox). Also if https://api.example.c= om > is really a load balancer that fronts the " > real" > endpoints, then it's also "logical" in that context and not an exact > location. > > This brings me to the conclusion that all the resource identifiers are > "logical" along a range of specificity. How specific a resource is > identified is really a risk decision and based on the deployment model ca= n > be managed at either the RS or the AS. > > Thanks, > George > > On 1/28/19 9:07 AM, Brian Campbell wrote: > > I plan on joining the meeting today at noon eastern time to discuses this > little ditty. I hope others who have a stake in it can too. > > > > The proposed changes that Vittorio and I put together can be seen in the > diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I > even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of > reference. I maintain that is the most straightforward way forward with a= ll > this. Yet another new additional parameter could be defined for the logic= al > case but I struggle to see the value in doing so. The 'resource' is URI > that points to the resource. The level of specificity of that pointer is > intentionally a bit fuzzy and application/deployment specific. Is > https://graph.microsoft.com (mentioned in the documentation previously > linked) a location or an abstract identifier or both? The document alread= y > (somewhat awkwardly) describes using a "base URI" for the application or > resource. Is that a a location or an abstract identifier? Or kinda both? > > > > In addition to the concerns others have expressed about "req_aud", I"d > note that draft-ietf-ace-oauth-params defines its use only at the token > endpoint as one of the "additional parameters for requesting an access > token from a token endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization endpoint too. > Furthermore, while the ACE WG is building on OAuth, for all intents and > purposes ACE and regular OAuth are different worlds and I think a referen= ce > in regular OAuth document like this one to "Additional OAuth Parameters f= or > Authorization in Constrained Environments (ACE)" would be a disservice to > just about everyone. > > > > > > > > > > > > > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > wrote: > > Hannes sent an update to this meeting here: > > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > wrote: > > The virtual office hours in my calendar start 1/2 hour before that. If > the time has changed, can you have the meeting organizer update the > calendar entry? > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > *Cc:* Vittorio Bertocci ; Mike Jones < > Michael.Jones@microsoft.com>; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > All, > > > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled > OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic to try to get to a > conclusion on this. > > > > Regards, > > Rifaat > > > > > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > +1 > > Also, I don't really like the parameter name 'req_aud' :) I'm not 100% > convinced that 'audience' and 'logical resource' are completely overlappi= ng > concepts. We can potentially make them completely overlapping but we need > text to that effect. > > I also believe that we don't have a complete solution for all deployments > using exact locations (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be separated- but I also agree > with George on the need to be clear an easy to reference for developers. > > Just adding a reference to req_aud would just raise the cyclomatic > complexity of the specs, which is already unusably high for mere mortals = in > the OAuth2/OIDC family of specs. > > > > One additional complication is that this specification is reusing a > parameter that is already used in a *very* large number of production > systems (small example here > ), > and whose concrete semantic happens to be prevalently logic identifier. I= f > the parameter you are defining here has a different semantic, at the very > least it would seem good hygiene to rename it to avoid collision and > confusion. > > > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > I agree with John=E2=80=99s logic. The physical resource and logical res= ource > should use different identifiers. Fortunately, we already have =E2=80=9C= resource=E2=80=9D > and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > I don't think they are necessarily mutually exclusive, that is why I thin= k > there is value in allowing them to be specified separately. > > As an AS in the distributed OAuth case knowing that a client interacting > with RS https://fire.hhs.com as the resource wants a OAuth token with an > audience of HHS and a scope of read. > > Without proof of possession we need to keep bad RS from asking for tokens > with scopes and audiences of other RS that can be replayed. > > I really like keeping the resource simple and unspoofable, it is the URI > of the RS where you are presenting the AT. > > I prefer to keep that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the URI t= o > figure out which one it is. I think that is harder for implementations a= nd > more likely to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and myself iterated on modifying the text > to cover the logical identifier use case, highlighting the security > implications of going that route. You can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-ind= icators.xml, > see the commits in the history from January 21 for the specific changes. > > Note: I also had a chat with John offline, and he expressed the desire to > split the resource parameter in two distinct parameters to better signal > the intended usage. I am sure he can elaborate. I have nothing against it > in principle, as long as we leave nothing as exercise to the reader and w= e > are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a > chance to speak w Brian about it. If the discussion stretches further, I > would suggest we pause it and let him enjoy his time off for the rest of > the week. > > > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, Vittorio Bertocci wrote= : > > Hi Rifaat, > > absolutely. Brian and myself already started working on some language, > however this week he is in vacation hence it might take few days before w= e > come back to the list with something. > > Cheers, > > V. > > > > On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef > wrote: > > Brian, Vittorio, > > > > To move this discussion forward, can you guys suggest some text to make > the logical identifier usage clearer? > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> > wrote: > > As I suggested before, I do think that's within the bounds of the draft's > definition of 'resource' as a URI. And that perhaps all that's needed is > some minor adjustment and/or augmentation of some text to make it more > clear. > > > > On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci > wrote: > > [sent to John only by mistake, resending to the ML] > > > > In Azure AD v1 & ADFS, that's resource.. It could be used for both > network and logical ids, with the concrete usage in the wild I described > earlier. > > In Azure AD v2, the resource as explicit parameter (network, logic or > otherwise) is gone and is expressed as part of the scope string of all th= e > scopes requested for a given resource- but it still exist in practice tho > as it still end up in the resulting aud of the issued token. > > This is 9 months old info hence > > > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > > What is the parameter that Microsoft is using? > > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw something that gave me the > impression might lead to issues, and given that I worked with actual > deployments and developers using a similar parameter for a long time, I > thought prudent to bring this up. I really appreciate Rifaat's stance on > this. End of preamble. > > > > Ultimately my goal is for developers to have guidance on how to work with > the concept of logical resource in a standard compliant way, hence it > doesn't strictly matter whether the definition of the corresponding > parameter lives in oauth-resource-indicators or elsewhere. > > That said. Reading through the draft, it would appear that most of the > reasons for which the spec was created apply to both the network > addressable and the logical resource types: knowing what keys to use to > encrypt the token, constrain access tokens to the intended audience, > avoiding overloading scopes with resource indicating parts... those all > apply to network addressable and logic identifiers alike. And both > parameters are expected to result in audience restricted tokens. It seems > the only difference comes at token usage time, with the network addressab= le > case giving more guarantees that the token will go to its intended > recipient, but the request and audience restriction syntax seems to be > exactly the same. > > On top of this: in the 99.999% of the scenarios I encountered in the wild > in the last 5 years of using the resource parameter in the MS ecosystem, > the resource identifier was known at design time: the developer discovere= d > it out of band and placed it in the app config at deployment time. Those > aren't fringe cases I occasionally encountered: the resource parameter in > Azure AD v1 and ADFS was mandatory, hence literally every solution i saw = or > touched used it. As Brian suggested, this is a scenario where the securit= y > advantages of the network addressable case aren't as pronounced as in the > case in which the client discovers the resource identifier at runtime. Th= is > isn't just because there is no specification suggesting location should b= e > explicitly indicated, it's because there are many practical advantages at > development and deployment time to be able to use logical identifiers- an= d > if the *concrete *security advantages don't apply to the their case, > people will simply not comply. > > > > In summary: creating two different parameters in two different documents > is better than ignoring he logical identifier case altogether, however I > think that not acknowledging the logical id case > in oauth-resource-indicators is going to create confusion and ultimately > not be as useful to the developer community as it could be. > > > > > > > > On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: > > +1 to Mike and John=E2=80=99s comments. > > Phil > > > On Jan 19, 2019, at 12:34 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I also agree that =E2=80=9Cresource=E2=80=9D should be a specific network= -addressable URL > whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs= ) can refer to one > or more logical resources. They are different, if related, things. > > > > Note that the ACE WG is proposing to register a logical audience paramete= r > =E2=80=9Creq_aud=E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-o= auth-params-01 - > partly based on feedback from OAuth WG members. This is a general OAuth > parameter, which any OAuth deployment will be able to use. > > > > I therefore believe that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *John Bradley > *Sent:* Saturday, January 19, 2019 9:01 AM > *To:* Brian Campbell > *Cc:* Vittorio Bertocci ; IETF oau= th > WG > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > We need to decide if we want to make a change. > > > > For security we are location centric. > > > > I prefer to keep resource location separate from logical audience that ca= n > be a scope or other parameter. > > > > If becomes harder for people to use the parameter correctly if we are too > flexible. > > > > I would rather have a separate logical audience parameter if we think we > want one. > > > > John B. > > > > On Sat, Jan 19, 2019, 11:41 AM Brian Campbell wrote: > > No apology needed, Rifaat. And I apologize if what I said came off the > wrong way. I was just trying to make light of the situation.. And I agree > that we should not be hamstrung by the process and there are times when i= t > makes sense to be flexible with things. > > > > On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef > wrote: > > Sorry Brian, I was not clear with my statement. > > I meant to say that we should not allow the process to prevent the WG fro= m > producing a quality document without issues, assuming there is an issue i= n > the first place. > > Ideally we want to get these identified during the WGLC, but things happe= n > and sometimes the WG misses something. > > > > I hear you and agree that this make things difficult for authors. We will > make sure that this does not become the norm, and we will try to stick to > the process as much as possible. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell > wrote: > > Thanks Rifaat. Process is as process does, right? I do kinda want to > grumble about WGCL having passed already but that's mostly because replyi= ng > to these kinds of threads is hard for me and I'll just get over it... > > > > As far as I understand things, the security concerns come into play when > the client is being told the by the resource how to identity the resource > like is described in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the > actual location in that context ,along with some other checks prescribed = in > that draft, prevents the kind of issues John described earlier in the > thread. > > In cases where the client knows the resource a priori or out-of-band or > configured or whatever, I don't think the same security concerns arise. A= nd > using such a known value, be it an actual location or logical > representation, would be okay. > > The resource-indicators draft is admittedly somewhat location-centric in > how it talks about the value of the 'resource' parameter. But ultimately = it > defines it as an absolute URI that indicates the location of the target > service or resource where access is being requested. A location can be > varying shades of abstract and I'd say that using a URI as 'resource' > parameter value that's a logical identifier that points to some resource = is > well within the bounds of the draft. > > > > So maybe the draft is okay as is? > > > > Or perhaps that's too much to be left as an exerciser to the reader? And > some text should be added and/or adjusted so the resource-indicators draf= t > would be a little more open/clear about the parameter value potentially > being more of a logical or abstract identifier and not necessarily a > network addressable URL? > > > > > > > > On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef > wrote: > > I wouldn't worry too much about the process. > > If it makes sense to update the document, then feel free to do that. > > > > Regards, > > Rifaat > > > > > > On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: > > Yes the logical resource can be provided by "scope" > > > > Some implementations like Ping and Auth0 have been adding another > parameter "aud" to identify the logical resource and then using scopes to > define permissions to the resource. > > > > Fortunately, we are using a different parameter name so not stepping on > that.. > > > > We could go back and try to add text explaining the difference, but we ar= e > quite late in the process. > > > > I agree that a logical resource parameter may be helpful, but perhaps it > should be a separate draft. > > > > John B. > > > > On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a m= eans of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bertocci > > > *Date: *Friday, January 18, 2019 at 5:47 AM > *To: *John Bradley > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > > > Thanks John for the background. > > I agree that from the client validation PoV, having an identifier > corresponding to a location makes things more solid. > > That said: the use of logical identifiers is widespread, as it has > significant practical advantages (think of services that assign generated > hosting URLs only at deployment time, or services that are somehow groupe= d > under the same logical audience across regions/environment/deployments). > People won't stop using logical identifiers, because they often have no > alternative (generating new audiences on the fly at the AS every time you > do a deployment and get assigned a new URL can be unfeasible). Leaving a > widely used approach as exercise to the reader seems a disservice to the > community, given that this might lead to vendors (for example Microsoft a= nd > Auth0) keeping their own proprietary parameters, or developers misusing t= he > ones in place; would make it hard for SDK developers to provide libraries > that work out of the box with different ASes; and so on. > > Would it be feasible to add such parameter directly in this spec? That > would eliminate the interop issues, and also gives us a chance to fully > warn people about the security shortcomings of choosing that approach. > > > > > > > > On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: > > We have discussed this. > > Audiences can certainly be logical identifiers. > > This however is a more specific location. The AS is free to map the > location into some abstract audience in the AT. > > From a security point of view once the client starts asking for logical > resources it can be tricked into asking for the wrong one as a bad resour= ce > can always lie about what logical resource it is. > > If we were to change it, how a client would validate it becomes > challenging to impossible. > > The AS is free to do whatever mapping of locations to identifiers it need= s > for access tokens. > > Some implementations may want to keep additional parameters like logical > audience, but that should be separate from resource. > > John B. > > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > > > The text you quoted is copied form the abstract of the draft itself. > > > > > > *Authors,* > > > > Should the draft be updated to cover the logical identifier case? > > > > Regards, > > Rifaat > > > > > > On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote: > > Hi Rifaat, > > one detail. The tech summary says > > > > An extension to the OAuth 2.0 Authorization Framework defining request > > parameters that enable a client to explicitly signal to an authorization = server > > about the *location* of the protected resource(s) to which it is requesti= ng > > access. > > But at least in the Microsoft implementation, the resource identifier > doesn't *have* to be a network addressable URL (and if it is, it doesn't > strictly need to match the actual resource location). It can be a logical > identifier, tho using the actual resource location there has benefits > (domain ownership check, prevention of token forwarding etc). > > Same for Auth0, the audience parameter is a logical identifier rather tha= n > a location. > > > > > > > > On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following is the first shepherd write-up for > the draft-ietf-oauth-resource-indicators-01 document. > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > > Please, take a look and let me know if I missed anything. > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e5896805808ae2c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[added ace@ietf.org kinda per suggestion from Mike]<= br>
I don't know that there are concerns about =E2=80=9Creq_aud=E2= =80=9D per se.=C2=A0 Admittedly, I did use the word "concerns" bu= t I was more trying to say that referencing it from the draft-ietf-oauth-re= source-indicators document wasn't needed to address Vittorio's requ= est. And pointing out that =E2=80=9Creq_aud=E2=80=9D=C2=A0 is defined for t= he token endpoint while the draft-ietf-oauth-resource-indicators document a= lso deals with the authorization endpoint so such a reference wouldn't = really work anyway.

I don't k= now of anyone that just works from the OAuth parameter registration but may= be I'm just out of touch. And I don't think its a stretch at all to= observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan= 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

Brian, etc.=C2=A0= If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now=E2=80=99s the ti= me to provide that feedback to the ACE WG, as they=E2=80=99re trying to com= plete that draft soon.=C2=A0 Please join the ACE WG mailing list and send y= our feedback there directly.

=C2=A0<= /u>

You and I may kno= w that ACE OAuth and OAuth 2 are pretty different but developers later will= just see the OAuth parameter registration and won=E2=80=99t realize that i= t=E2=80=99s coming from a different universe.=C2=A0 If we can harmonize things now, we should.

=C2=A0<= /u>

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

=C2=A0<= /u>

From:= OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >
Cc: oauth@ietf.o= rg; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not = also a logical location considering it's possible there are multiple en= dpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mail= box). Also if https://api.example.com is really a load balancer that fronts= the "real" endpoints, then it's also "logical"= in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are &quo= t;logical" along a range of specificity. How specific a resource is id= entified is really a risk decision and based on the deployment model can be= managed at either the RS or the AS.

Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:<= /u>

I plan on joining the meeting today at noon eastern = time to discuses this little ditty. I hope others who have a stake in it ca= n too.

=C2=A0

The proposed changes that Vittorio and I put togethe= r can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and = I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease o= f reference. I maintain that is the most straightforward way forward with a= ll this. Yet another new additional parameter could be defined for the logi= cal case but I struggle to see the value in doing so. The 'resource' is URI that points to the resour= ce. The level of specificity of that pointer is intentionally a bit fuzzy a= nd application/deployment specific. Is https://graph.mic= rosoft.com (mentioned in the documentation previously linked) a locatio= n or an abstract identifier or both? The document already (somewhat awkward= ly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both= ?

=C2=A0

In addition to the concerns others have expressed ab= out "req_aud", I"d note that draft-ietf-ace-oauth-params def= ines its use only at the token endpoint as one of the "additional para= meters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope in= cludes the authorization endpoint too. Furthermore, while the ACE WG is bui= lding on OAuth, for all intents and purposes ACE and regular OAuth are diff= erent worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Paramete= rs for Authorization in Constrained Environments (ACE)" would be a dis= service to just about everyone.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@= gmail.com> wrote:

Hannes sent an update to this meeting here: <= u>

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

The virtual offic= e hours in my calendar start 1/2 hour before that.=C2=A0 If the time has ch= anged, can you have the meeting organizer update the calendar entry?

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

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

=C2=A0<= /u>

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

All,

=C2=A0

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled= OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to= a conclusion on this.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <= gffletch=3D40= aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'= ;m not 100% convinced that 'audience' and 'logical resource'= ; are completely overlapping concepts. We can potentially make them complet= ely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deploymen= ts using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:<= u>

As mentioned below, I agree the two can be separated= - but I also agree with George on the need to be clear an easy to reference= for developers.

Just adding a reference to req_aud would just raise = the cyclomatic complexity of the specs, which is already unusably high for = mere mortals in the OAuth2/OIDC family of specs.

=C2=A0

One additional complication is that this specificati= on is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic iden= tifier. If the parameter you are defining here has a different semantic, at= the very least it would seem good hygiene to rename it to avoid collision = and confusion.

=C2=A0

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree with John= =E2=80=99s logic.=C2=A0 The physical resource and logical resource should u= se different identifiers.=C2=A0 Fortunately, we already have =E2=80=9Cresou= rce=E2=80=9D and =E2=80=9Creq_aud=E2=80=9D for these parameters.=C2=A0 I believe we=E2=80= =99re good to go, as-is.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

I don't think they are necessarily mutually exclusive, that is why I= think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting= with RS https://fire.hhs.com= as the resource wants a OAuth token with an audience of HHS and a scope of= read.

Without proof of possession we need to keep bad RS from asking for token= s with scopes and audiences of other RS that can be replayed.=

I really like keeping the resource simple and unspoofable, it is the URI= of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span m= ore than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI = to figure out which one it is.=C2=A0 I think that is harder for implementat= ions and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated o= n modifying the text to cover the logical identifier use case, highlighting= the security implications of going that route. You can find the revised text in=C2=A0= https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indic= ators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he ex= pressed the desire to split the resource parameter in two distinct paramete= rs to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we le= ave nothing as exercise to the reader and we are very clear on usage (e.g. = mutual exclusivity, etc) but didn't have a chance to speak w Brian abou= t it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of= the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:=

Hi Rifaat,

absolutely. Brian and myself already started working= on some language, however this week he is in vacation hence it might take = few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys sugges= t some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <= bcampbell=3D40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within = the bounds of the draft's definition of 'resource' as a URI. An= d that perhaps all that's needed is some minor adjustment and/or augmen= tation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

[sent to John only by mistake, r= esending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that&= #39;s=C2=A0resource.. It could be used for both network and logical ids, with the concrete usage in the w= ild I described earlier.

In Azure AD v2, = the resource as explicit parameter (network, logic or otherwise) is gone an= d is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it s= till end up in the resulting=C2=A0aud=C2=A0of the issued token.

This is 9 months= old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com>= wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the= established process. In my former position I wasn't monitoring those d= iscussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and= given that I worked with actual deployments and developers using a similar= parameter for a long time, I thought prudent to bring this up. I really ap= preciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidanc= e on how to work with the concept of logical resource in a standard complia= nt way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-resource-ind= icators or elsewhere.

That said. Reading through the draft, it would appea= r that most of the reasons for which the spec was created apply to both the= network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to = the intended audience, avoiding overloading scopes with resource indicating= parts... those all apply to network addressable and logic identifiers alik= e. And both parameters are expected to result in audience restricted tokens. It seems the only difference come= s at token usage time, with the network addressable case giving more guaran= tees that the token will go to its intended recipient, but the request and = audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I en= countered in the wild in the last 5 years of using the resource parameter i= n the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in t= he app config at deployment time. Those aren't fringe cases I occasiona= lly encountered: the resource parameter in Azure AD v1 and ADFS was mandato= ry, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the s= ecurity advantages of the network addressable case aren't as pronounced= as in the case in which the client discovers the resource identifier at ru= ntime. This isn't just because there is no specification suggesting location should be explicitly indicated, it= 's because there are many practical advantages at development and deplo= yment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, peop= le will simply not comply.=C2=A0

=C2=A0

In summary: creating two different parameters in two= different documents is better than ignoring he logical identifier case alt= ogether, however I think that not acknowledging the logical id case in=C2=A0oauth-resource-indicators is going to create confu= sion and ultimately not be as useful to the developer community as it could= be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2= =80=99s comments.=C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=3D40mic= rosoft.com@dmarc.ietf.org> wrote:

I also agree that= =E2=80=9Cresource=E2=80=9D should be a specific network-addressable URL wh= ereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWTs) ca= n refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0<= /u>

Note that the ACE= WG is proposing to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly bas= ed on feedback from OAuth WG members.=C2=A0 This is a general OAuth paramet= er, which any OAuth deployment will be able to use.

=C2=A0<= /u>

I therefore belie= ve that no changes are needed to draft-ietf-oauth-resource-indicators, as t= he logical audience work is already happening in another draft.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&= gt;; IETF oauth WG <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0= =C2=A0

=C2=A0

For security we are location centric.=C2=A0=C2=A0=

=C2=A0

I prefer to keep resource location separate from log= ical audience that can be a scope or other parameter.=C2=A0=C2=A0=

=C2=A0

If becomes harder for people to use the parameter co= rrectly if we are too flexible.=C2=A0=C2=A0

=C2=A0

I would rather have a separate logical audience para= meter if we think we want one.=C2=A0=C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pin= gidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I= said came off the wrong way. I was just trying to make light of the situat= ion.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with= things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process = to prevent the WG from producing a quality document without issues, assumin= g there is an issue in the first place.

Ideally we want to get these identified during the W= GLC, but things happen and sometimes the WG misses something.=C2=A0<= u>

=C2=A0

I hear you and agree that this make things difficult= for authors. We will make sure that this does not become the norm, and we = will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

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

Thanks Rifaat. Process is as process does, right? I = do kinda want to grumble about WGCL having passed already but that's mo= stly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns= come into play when the client is being told the by the resource how to id= entity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using t= he actual location in that context ,along with some other checks prescribed= in that draft, prevents the kind of issues John described earlier in the t= hread.

In cases where the client knows the resource a priori or out-of-band or con= figured or whatever, I don't think the same security concerns arise. An= d using such a known value, be it an actual location or logical representat= ion, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in ho= w it talks about the value of the 'resource' parameter. But ultimat= ely it defines it as an absolute URI that indicates the location of the tar= get service or resource where access is being requested. A location can be varying shades of abstract and I'd = say that using a URI as 'resource' parameter value that's a log= ical identifier that points to some resource is well within the bounds of t= he draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that's too much to be left as an exer= ciser to the reader?=C2=A0 And some text should be added and/or adjusted so= the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract = identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

I wouldn't worry too much about the process.<= /u>

If it makes sense to update the document, then feel = free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

Yes the=C2=A0logical resource can be provided by &qu= ot;scope"

=C2=A0

Some implementations like Ping and Auth0 have been a= dding another parameter "aud" to identify the logical resource an= d then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter= name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the = difference, but we are quite late in the process.=C2=A0

=C2=A0

I agree that a logical resource parameter=C2=A0may b= e helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D paramete= r already provide a means of specifying a logical identifier?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on beha= lf of Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resou= rce-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having = an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespr= ead, as it has significant practical advantages (think of services that ass= ign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience acros= s regions/environment/deployments). People won't stop using logical ide= ntifiers, because they often have no alternative (generating new audiences = on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a w= idely used approach as exercise to the reader seems a disservice to the com= munity, given that this might lead to vendors (for example Microsoft and Au= th0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard f= or SDK developers to provide libraries that work out of the box with differ= ent ASes; and so on.

Would it be feasible to add such parameter directly = in this spec? That would eliminate the interop issues, and also gives us a = chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2=A0=C2=A0

This however is a more specific location.=C2=A0 The AS is free to map th= e location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical = resources it can be tricked into asking for the wrong one as a bad resource= can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challeng= ing to impossible.

The AS is free to do whatever mapping of locations to identifiers it nee= ds for access tokens.

Some implementations may want to keep additional parameters like logical= audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of t= he draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical ide= ntifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci &l= t;Vittorio@auth0.co= m> wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

An extension to the OAuth 2.0 Authorization Framework defi=
ning request 
parameters that enable a client to explicitly signal to an=
 authorization server 
about the location of the protected resource(s) to =
which it is requesting 
access.

But at least in the Microsoft implementation, the re= source identifier doesn't have to be a network addressable URL (and if it is, it doesn't s= trictly need to match the actual resource location). It can be a logical id= entifier, tho using the actual resource location there has benefits (domain= ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical = identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the= =C2=A0draft-ietf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed= anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

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

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


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


CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, u= se, 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 me= ssage and any file attachments from your computer. Thank you.

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


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution 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 messa= ge and any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0

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

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


CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution 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 messag= e and any file attachments from your computer. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e5896805808ae2c6-- From nobody Mon Jan 28 14:12:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76C130EE5 for ; Mon, 28 Jan 2019 14:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cnUs3jKzik3i for ; Mon, 28 Jan 2019 14:12:10 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.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 0AE17130EDD for ; Mon, 28 Jan 2019 14:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548713527; bh=vQvhLQcIXJWbVb6tvCRNuVIxiVGA5CbWUmTjOF7XG84=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qEydn8aeUC61culQ8rpQEhxISgg5+M6M0wbNe70o15Fl3JXYtFTSpIiJkgKODi6Qcg+GFMOZF7M/40IAtTiNExvh5s/lF8wT3nqzk0LYbPGqj2VCr7PEKrfkmXdamGhSWJyZEGRQOGgaRL+mFv3aXNW09IOe1Awx653qB/Q+C6jVSE8BGpJ4FQo1aMzxQKcikNQu+70UsBEJ3hATuS73A7TqHYiXsvPHbq2Ex7EFDj7FVbKNTXCJJI3Jyc+Vs+20PLTXTdMyXmtPSOdNklFeagSe1isRxEgQcrHYZsn/GdDgHoZLktBDHxwNjHQY42S0C8aKVS0XWRmc0jYytmJ/LA== X-YMail-OSG: BqN2C74VM1lcCVEnVsy19KhljNmH.3.BYOJPZFFX5BmUyg06wut0xY5rk9.lwU_ md.ssBgUWO3FyNhiUdekDNGzN40YznhnL7gFFxRhvV58DofFyUA3o4TekdcOyuSQQNLeYdapr1j8 pIRj3yoYPndT84h2elzMnRNrj9mG5.u4hJW5_GKM.gBdxerYNWXljd253j4QNll.6golHrJkBLcd AV7VfOHK2H2X3mN4jPQMbPd0cMYZ1ISxYZFpann51nd0T26eQUTJVxuaOHZIoos5rb8z7YOGTYE7 Zpftvg9OcfUgELgUBsxBV3bPEhfPOw3cjSTXPUaLjS6RBS98AcW5LoW_H042dyYeLPzDgbhbkHki uJOw4.T.yvfMoYwrVDimodCaxbLiIj9k3hAZ60j0V8ZZS2BfeZYeIzabGmE5gKnKjKC_BD.FiOk0 er7OFu.nSicTtDiJaCO4eD3BwBfn.pzyGB_yKn03bt.n5b5FlkHQN7CrJueHU1iEkn89WLCdhPws msVo_BHjQ9porWJKPM_3nSAzD2ZPOenod_AKtaC9SpZ2jtsB_a9f4kkus7xk3v8PPJC9XbGI1_dI NGV4fZ2FKmnUoS5a8oJdCm.oMrNjFrl4QWIbqGnkWG_CNGv_gJrjhkaCAsi5IbQddxmT_aQv5zh3 x9fih822WF8hIDmRQ1qxDChxXBIC_oYln99NG8s4szyaHjJq_AYCdJF2Gl5EF6uRXEbOsgceCubj kh8xowBB50VtdFTkBaEk2g64JsUv8G9nu.tVvWpeccg3uzXHVNJENSIGfr02h7.vNVKOrx7JZnS9 TiLub76A18xHMFUDpd8zO7ATQOkcKGGbSVyhGJBYQpyE786eVkXUP6iTbHCZQJSNe_THi6z_Y5RH QJolchPJjS7hLh.osMknmn6_wMqBnhgv2Shva.neREzGRrpzsHf_jBoR1zP.Ehv2a_YQEgVk0tkq trCPdU3Dx_taD5r2omzGwF8uigXteK.GQaV2Tc1AWlmO3M36.ubw7HwmtBD3UDVgHcYzS2Bd3the prek5OUwN1fTQEqyHrr3_LHGfRmP.Cz79hoS3.WheFryIGZF9NYk1jMkV5bKTF0Xp.w0PpW_nVA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jan 2019 22:12:07 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e30a89303b267a154ac0f0d07589e754; Mon, 28 Jan 2019 22:12:03 +0000 (UTC) To: Brian Campbell , Mike Jones , ace@ietf.org Cc: "oauth@ietf.org" , Vittorio Bertocci References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> Date: Mon, 28 Jan 2019 17:12:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1CD0A9136094A3FD1F9AE843" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 22:12:17 -0000 This is a multi-part message in MIME format. --------------1CD0A9136094A3FD1F9AE843 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:) I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate? Thanks, George On 1/28/19 3:54 PM, Brian Campbell wrote: > [added ace@ietf.org kinda per suggestion from Mike] > > I don't know that there are concerns about “req_aud” per se.  > Admittedly, I did use the word "concerns" but I was more trying to say > that referencing it from the draft-ietf-oauth-resource-indicators > document wasn't needed to address Vittorio's request. And pointing out > that “req_aud”  is defined for the token endpoint while the > draft-ietf-oauth-resource-indicators document also deals with the > authorization endpoint so such a reference wouldn't really work anyway. > > I don't know of anyone that just works from the OAuth parameter > registration but maybe I'm just out of touch. And I don't think its a > stretch at all to observe that ACE OAuth and OAuth 2 are different. > > > > On Mon, Jan 28, 2019 at 11:28 AM Mike Jones > > wrote: > > Brian, etc.  If you have concerns about “req_aud”, now’s the time > to provide that feedback to the ACE WG, as they’re trying to > complete that draft soon.  Please join the ACE WG mailing list and > send your feedback there directly. > > You and I may know that ACE OAuth and OAuth 2 are pretty different > but developers later will just see the OAuth parameter > registration and won’t realize that it’s coming from a different > universe.  If we can harmonize things now, we should. > > -- Mike > > *From:*OAuth > *On Behalf Of *George Fletcher > *Sent:* Monday, January 28, 2019 10:05 AM > *To:* Brian Campbell > > *Cc:* oauth@ietf.org ; Vittorio Bertocci > > > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > +1 > > I came to a similar conclusion over the weekend. If > https://api.example.com/mail is an > allowed location URI, how is it not also a logical location > considering it's possible there are multiple endpoints "below" > https://api.example.com/mail? (e.g. > https://api.example.com/mail/user/mailbox). Also if > https://api.example.com is really a load balancer that fronts the > " > real" > endpoints, then it's also "logical" in that context and not an > exact location. > > This brings me to the conclusion that all the resource identifiers > are "logical" along a range of specificity. How specific a > resource is identified is really a risk decision and based on the > deployment model can be managed at either the RS or the AS. > > Thanks, > George > > On 1/28/19 9:07 AM, Brian Campbell wrote: > > I plan on joining the meeting today at noon eastern time to > discuses this little ditty. I hope others who have a stake in > it can too. > > The proposed changes that Vittorio and I put together can be > seen in the diff of this pull request > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files > and I even put a xml2rfc'ed text version on > https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 > for ease of reference. I maintain that is the most > straightforward way forward with all this. Yet another new > additional parameter could be defined for the logical case but > I struggle to see the value in doing so. The 'resource' is URI > that points to the resource. The level of specificity of that > pointer is intentionally a bit fuzzy and > application/deployment specific. Is > https://graph.microsoft.com (mentioned in the documentation > previously linked) a location or an abstract identifier or > both? The document already (somewhat awkwardly) describes > using a "base URI" for the application or resource. Is that a > a location or an abstract identifier? Or kinda both? > > In addition to the concerns others have expressed about > "req_aud", I"d note that draft-ietf-ace-oauth-params defines > its use only at the token endpoint as one of the "additional > parameters for requesting an access token from a token > endpoint in the ACE framework". Whereas the > resource-indicators draft scope includes the authorization > endpoint too. Furthermore, while the ACE WG is building on > OAuth, for all intents and purposes ACE and regular OAuth are > different worlds and I think a reference in regular OAuth > document like this one to "Additional OAuth Parameters for > Authorization in Constrained Environments (ACE)" would be a > disservice to just about everyone. > > On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > > wrote: > > Hannes sent an update to this meeting here: > > https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU > > Regards, > >  Rifaat > > On Thu, Jan 24, 2019 at 6:20 PM Mike Jones > > wrote: > > The virtual office hours in my calendar start 1/2 hour > before that.  If the time has changed, can you have > the meeting organizer update the calendar entry? > > Thanks, > > -- Mike > > *From:* Rifaat Shekh-Yusef > > *Sent:* Thursday, January 24, 2019 12:46 PM > *To:* George Fletcher > > *Cc:* Vittorio Bertocci >; Mike Jones > >; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > All, > > This coming Monday, Jan 28 @ 12:00pm Eastern Time, we > have a scheduled OAuth WG Virtual Office meeting. > > Feel free to attend the meeting to discuss this topic > to try to get to a conclusion on this. > > Regards, > >  Rifaat > > On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > > wrote: > > +1 > > Also, I don't really like the parameter name > 'req_aud' :) I'm not 100% convinced that > 'audience' and 'logical resource' are completely > overlapping concepts. We can potentially make them > completely overlapping but we need text to that > effect. > > I also believe that we don't have a complete > solution for all deployments using exact locations > (see my previous email). > > Thanks, > George > > On 1/23/19 2:50 PM, Vittorio Bertocci wrote: > > As mentioned below, I agree the two can be > separated- but I also agree with George on the > need to be clear an easy to reference for > developers. > > Just adding a reference to req_aud would just > raise the cyclomatic complexity of the specs, > which is already unusably high for mere > mortals in the OAuth2/OIDC family of specs. > > One additional complication is that this > specification is reusing a parameter that is > already used in a *very* large number of > production systems (small example here > ), > and whose concrete semantic happens to be > prevalently logic identifier. If the parameter > you are defining here has a different > semantic, at the very least it would seem good > hygiene to rename it to avoid collision and > confusion. > > On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > > wrote: > > I agree with John’s logic.  The physical > resource and logical resource should use > different identifiers. Fortunately, we > already have “resource” and “req_aud” for > these parameters.  I believe we’re good to > go, as-is. > > -- Mike > > *From:* OAuth > *On > Behalf Of *John Bradley > *Sent:* Wednesday, January 23, 2019 10:56 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Shepherd > write-up for > draft-ietf-oauth-resource-indicators-01 > > I don't think they are necessarily > mutually exclusive, that is why I think > there is value in allowing them to be > specified separately. > > As an AS in the distributed OAuth case > knowing that a client interacting with RS > https://fire.hhs.com as the resource wants > a OAuth token with an audience of HHS and > a scope of read. > > Without proof of possession we need to > keep bad RS from asking for tokens with > scopes and audiences of other RS that can > be replayed. > > I really like keeping the resource simple > and unspoofable, it is the URI of the RS > where you are presenting the AT. > > I prefer to keep that separate from the > logical resource that may span more than > one RS endpoint. > > Merging the two and we are probably back > at the AS looking into the URI to figure > out which one it is.  I think that is > harder for implementations and more likely > to have security issues down the road. > > John B. > > On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: > > Hi all, > > thanks for you patience. Brian and > myself iterated on modifying the text > to cover the logical identifier use > case, highlighting the security > implications of going that route. You > can find the revised text in > https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, > see the commits in the history from > January 21 for the specific changes. > > Note: I also had a chat with John > offline, and he expressed the desire > to split the resource parameter in two > distinct parameters to better signal > the intended usage. I am sure he can > elaborate. I have nothing against it > in principle, as long as we leave > nothing as exercise to the reader and > we are very clear on usage (e.g. > mutual exclusivity, etc) but didn't > have a chance to speak w Brian about > it. If the discussion stretches > further, I would suggest we pause it > and let him enjoy his time off for the > rest of the week. > > On Mon, Jan 21, 2019 at 5:35 PM Rifaat > Shekh-Yusef > wrote: > > Thank you guys! > > > > On Monday, January 21, 2019, > Vittorio Bertocci > > wrote: > > Hi Rifaat, > > absolutely. Brian and myself > already started working on > some language, however this > week he is in vacation hence > it might take few days before > we come back to the list with > something. > > Cheers, > > V. > > On Mon, Jan 21, 2019 at 9:35 > AM Rifaat Shekh-Yusef > > > wrote: > > Brian, Vittorio, > > To move this discussion > forward, can you guys > suggest some text to make > the logical identifier > usage clearer? > > Regards, > >  Rifaat > > On Mon, Jan 21, 2019 at > 10:32 AM Brian Campbell > > > wrote: > > As I suggested before, > I do think that's > within the bounds of > the draft's definition > of 'resource' as a > URI. And that perhaps > all that's needed is > some minor adjustment > and/or augmentation of > some text to make it > more clear. > > On Sun, Jan 20, 2019 > at 7:39 PM Vittorio > Bertocci > > > wrote: > > [sent to John only > by mistake, > resending to the ML] > > In Azure AD v1 & > ADFS, that's > resource.. It > could be used for > both network and > logical ids, with > the concrete usage > in the wild I > described earlier. > > In Azure AD v2, > the resource as > explicit parameter > (network, logic or > otherwise) is gone > and is expressed > as part of the > scope string of > all the scopes > requested for a > given resource- > but it still exist > in practice tho as > it still end up in > the resulting > aud of the issued > token. > > This is 9 months > old info hence > > On Sun, Jan 20, > 2019 at 17:58 John > Bradley > > > wrote: > > What is the > parameter that > Microsoft is > using? > > On 1/20/2019 > 3:59 PM, > Vittorio > Bertocci wrote: > > First of > all, it > wasn't my > intent to > disrupt > the > established > process. > In my > former > position I > wasn't > monitoring > those > discussions > hence I > didn't > have a > chance to > offer > feedback. > When I saw > something > that gave > me the > impression > might lead > to issues, > and given > that I > worked > with > actual > deployments > and > developers > using a > similar > parameter > for a long > time, I > thought > prudent to > bring this > up. I > really > appreciate > Rifaat's > stance on > this. End > of preamble. > > Ultimately > my goal is > for > developers > to have > guidance > on how to > work with > the > concept of > logical > resource > in a > standard > compliant > way, hence > it doesn't > strictly > matter > whether > the > definition > of the > corresponding > parameter > lives > in oauth-resource-indicators > or elsewhere. > > That said. > Reading > through > the draft, > it would > appear > that most > of the > reasons > for which > the spec > was > created > apply to > both the > network > addressable > and the > logical > resource > types: > knowing > what keys > to use to > encrypt > the token, > constrain > access > tokens to > the > intended > audience, > avoiding > overloading > scopes > with > resource > indicating > parts... > those all > apply to > network > addressable > and logic > identifiers > alike. And > both > parameters > are > expected > to result > in > audience > restricted > tokens. It > seems the > only > difference > comes at > token > usage > time, with > the > network > addressable > case > giving > more > guarantees > that the > token will > go to its > intended > recipient, > but the > request > and > audience > restriction > syntax > seems to > be exactly > the same. > > On top of > this: in > the > 99.999% of > the > scenarios > I > encountered > in the > wild in > the last 5 > years of > using the > resource > parameter > in the MS > ecosystem, > the > resource > identifier > was known > at design > time: the > developer > discovered > it out of > band and > placed it > in the app > config at > deployment > time. > Those > aren't > fringe > cases I > occasionally > encountered: > the > resource > parameter > in Azure > AD v1 and > ADFS was > mandatory, > hence > literally > every > solution i > saw or > touched > used it. > As Brian > suggested, > this is a > scenario > where the > security > advantages > of the > network > addressable > case > aren't as > pronounced > as in the > case in > which the > client > discovers > the > resource > identifier > at > runtime. > This isn't > just > because > there is > no > specification > suggesting > location > should be > explicitly > indicated, > it's > because > there are > many > practical > advantages > at > development > and > deployment > time to be > able to > use > logical > identifiers- > and if the > /concrete > /security > advantages > don't > apply to > the their > case, > people > will > simply not > comply. > > In > summary: > creating > two > different > parameters > in two > different > documents > is better > than > ignoring > he logical > identifier > case > altogether, > however I > think that > not > acknowledging > the > logical id > case > in oauth-resource-indicators > is going > to create > confusion > and > ultimately > not be as > useful to > the > developer > community > as it > could be. > > On Sat, > Jan 19, > 2019 at > 12:38 Phil > Hunt > > > wrote: > > +1 to > Mike > and > John’s > comments. > > Phil > > > On Jan > 19, > 2019, > at > 12:34 > PM, > Mike > Jones > > > wrote: > > I > also > agree > that > “resource” > should > be > a > specific > network-addressable > URL > whereas > a > separate > audience > parameter > (like > “aud” > in > JWTs) > can > refer > to > one > or > more > logical > resources. > They > are > different, > if > related, > things. > > Note > that > the > ACE > WG > is > proposing > to > register > a > logical > audience > parameter > “req_aud” > in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > - > partly > based > on > feedback > from > OAuth > WG > members.  > This > is > a > general > OAuth > parameter, > which > any > OAuth > deployment > will > be > able > to > use. > > I > therefore > believe > that > no > changes > are > needed > to > draft-ietf-oauth-resource-indicators, > as > the > logical > audience > work > is > already > happening > in > another > draft. > > -- > Mike > > *From:* > OAuth > > > *On > Behalf > Of > *John > Bradley > *Sent:* > Saturday, > January > 19, > 2019 > 9:01 > AM > *To:* > Brian > Campbell > > > *Cc:* > Vittorio > Bertocci > >; > IETF > oauth > WG > > > *Subject:* > Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > We > need > to > decide > if > we > want > to > make > a > change. > > > For > security > we > are > location > centric. > > > I > prefer > to > keep > resource > location > separate > from > logical > audience > that > can > be > a > scope > or > other > parameter. > > > If > becomes > harder > for > people > to > use > the > parameter > correctly > if > we > are > too > flexible. > > > I > would > rather > have > a > separate > logical > audience > parameter > if > we > think > we > want > one. > > John > B. > > On > Sat, > Jan > 19, > 2019, > 11:41 > AM > Brian > Campbell > > wrote: > > No > apology > needed, > Rifaat. > And > I > apologize > if > what > I > said > came > off > the > wrong > way. > I > was > just > trying > to > make > light > of > the > situation.. > And > I > agree > that > we > should > not > be > hamstrung > by > the > process > and > there > are > times > when > it > makes > sense > to > be > flexible > with > things. > > > On > Fri, > Jan > 18, > 2019 > at > 6:22 > PM > Rifaat > Shekh-Yusef > > > wrote: > > Sorry > Brian, > I > was > not > clear > with > my > statement. > > I > meant > to > say > that > we > should > not > allow > the > process > to > prevent > the > WG > from > producing > a > quality > document > without > issues, > assuming > there > is > an > issue > in > the > first > place. > > Ideally > we > want > to > get > these > identified > during > the > WGLC, > but > things > happen > and > sometimes > the > WG > misses > something. > > > I > hear > you > and > agree > that > this > make > things > difficult > for > authors. > We > will > make > sure > that > this > does > not > become > the > norm, > and > we > will > try > to > stick > to > the > process > as > much > as > possible. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 5:35 > PM > Brian > Campbell > > > wrote: > > Thanks > Rifaat. > Process > is > as > process > does, > right? > I > do > kinda > want > to > grumble > about > WGCL > having > passed > already > but > that's > mostly > because > replying > to > these > kinds > of > threads > is > hard > for > me > and > I'll > just > get > over > it... > > > As > far > as > I > understand > things, > the > security > concerns > come > into > play > when > the > client > is > being > told > the > by > the > resource > how > to > identity > the > resource > like > is > described > in > https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 > and > using > the > actual > location > in > that > context > ,along > with > some > other > checks > prescribed > in > that > draft, > prevents > the > kind > of > issues > John > described > earlier > in > the > thread. > > > In > cases > where > the > client > knows > the > resource > a > priori > or > out-of-band > or > configured > or > whatever, > I > don't > think > the > same > security > concerns > arise. > And > using > such > a > known > value, > be > it > an > actual > location > or > logical > representation, > would > be > okay. > > The > resource-indicators > draft > is > admittedly > somewhat > location-centric > in > how > it > talks > about > the > value > of > the > 'resource' > parameter. > But > ultimately > it > defines > it > as > an > absolute > URI > that > indicates > the > location > of > the > target > service > or > resource > where > access > is > being > requested. > A > location > can > be > varying > shades > of > abstract > and > I'd > say > that > using > a > URI > as > 'resource' > parameter > value > that's > a > logical > identifier > that > points > to > some > resource > is > well > within > the > bounds > of > the > draft. > > > So > maybe > the > draft > is > okay > as > is? > > Or > perhaps > that's > too > much > to > be > left > as > an > exerciser > to > the > reader? > And > some > text > should > be > added > and/or > adjusted > so > the > resource-indicators > draft > would > be > a > little > more > open/clear > about > the > parameter > value > potentially > being > more > of > a > logical > or > abstract > identifier > and > not > necessarily > a > network > addressable > URL? > > On > Fri, > Jan > 18, > 2019 > at > 1:18 > PM > Rifaat > Shekh-Yusef > > > wrote: > > I > wouldn't > worry > too > much > about > the > process. > > If > it > makes > sense > to > update > the > document, > then > feel > free > to > do > that. > > Regards, > >  Rifaat > > On > Fri, > Jan > 18, > 2019 > at > 3:08 > PM > John > Bradley > > > wrote: > > Yes > the logical > resource > can > be > provided > by > "scope" > > Some > implementations > like > Ping > and > Auth0 > have > been > adding > another > parameter > "aud" > to > identify > the > logical > resource > and > then > using > scopes > to > define > permissions > to > the > resource. > > Fortunately, > we > are > using > a > different parameter > name > so > not > stepping > on > that.. > > We > could > go > back > and > try > to > add > text > explaining > the > difference, > but > we > are > quite > late > in > the > process. > > > I > agree > that > a > logical > resource > parameter may > be > helpful, > but > perhaps > it > should > be > a > separate > draft. > > John > B. > > On > Fri, > Jan > 18, > 2019 > at > 4:38 > PM > Richard > Backman, > Annabelle > > > wrote: > > Doesn’t > the > “scope” > parameter > already > provide > a > means > of > specifying > a > logical > identifier? > > -- > > > Annabelle > Richard > Backman > > AWS > Identity > > *From: > *OAuth > > > on > behalf > of > Vittorio > Bertocci > > > *Date: > *Friday, > January > 18, > 2019 > at > 5:47 > AM > *To: > *John > Bradley > > > *Cc: > *IETF > oauth > WG > > > *Subject: > *Re: > [OAUTH-WG] > Shepherd > write-up > for > draft-ietf-oauth-resource-indicators-01 > > Thanks > John > for > the > background. > > > I > agree > that > from > the > client > validation > PoV, > having > an > identifier > corresponding > to > a > location > makes > things > more > solid. > > That > said: > the > use > of > logical > identifiers > is > widespread, > as > it > has > significant > practical > advantages > (think > of > services > that > assign > generated > hosting > URLs > only > at > deployment > time, > or > services > that > are > somehow > grouped > under > the > same > logical > audience > across > regions/environment/deployments). > People > won't > stop > using > logical > identifiers, > because > they > often > have > no > alternative > (generating > new > audiences > on > the > fly > at > the > AS > every > time > you > do > a > deployment > and > get > assigned > a > new > URL > can > be > unfeasible). > Leaving > a > widely > used > approach > as > exercise > to > the > reader > seems > a > disservice > to > the > community, > given > that > this > might > lead > to > vendors > (for > example > Microsoft > and > Auth0) > keeping > their > own > proprietary > parameters, > or > developers > misusing > the > ones > in > place; > would > make > it > hard > for > SDK > developers > to > provide > libraries > that > work > out > of > the > box > with > different > ASes; > and > so > on. > > Would > it > be > feasible > to > add > such > parameter > directly > in > this > spec? > That > would > eliminate > the > interop > issues, > and > also > gives > us > a > chance > to > fully > warn > people > about > the > security > shortcomings > of > choosing > that > approach. > > On > Thu, > Jan > 17, > 2019 > at > 4:32 > PM > John > Bradley > > > wrote: > > We > have > discussed > this. > > Audiences > can > certainly > be > logical > identifiers. > > > This > however > is > a > more > specific > location.  > The > AS > is > free > to > map > the > location > into > some > abstract > audience > in > the > AT. > > From > a > security > point > of > view > once > the > client > starts > asking > for > logical > resources > it > can > be > tricked > into > asking > for > the > wrong > one > as > a > bad > resource > can > always > lie > about > what > logical > resource > it > is. > > If > we > were > to > change > it, > how > a > client > would > validate > it > becomes > challenging > to > impossible. > > > The > AS > is > free > to > do > whatever > mapping > of > locations > to > identifiers > it > needs > for > access > tokens. > > Some > implementations > may > want > to > keep > additional > parameters > like > logical > audience, > but > that > should > be > separate > from > resource. > > John > B. > > On > 1/17/2019 > 9:56 > AM, > Rifaat > Shekh-Yusef > wrote: > > Hi > Vittorio, > > > The > text > you > quoted > is > copied > form > the > abstract > of > the > draft > itself. > > *Authors,* > > Should > the > draft > be > updated > to > cover > the > logical > identifier > case? > > Regards, > >  Rifaat > > On > Thu, > Jan > 17, > 2019 > at > 8:19 > AM > Vittorio > Bertocci > > > wrote: > > Hi > Rifaat, > > > one > detail. > The > tech > summary > says > > An > extension > to > the > OAuth > 2.0 > Authorization > Framework > defining > request > > > parameters > that > enable > a > client > to > explicitly > signal > to > an > authorization > server > > > about > the > *location* > of > the > protected > resource(s) > to > which > it > is > requesting > > > access. > > But > at > least > in > the > Microsoft > implementation, > the > resource > identifier > doesn't > /have/ > to > be > a > network > addressable > URL > (and > if > it > is, > it > doesn't > strictly > need > to > match > the > actual > resource > location). > It > can > be > a > logical > identifier, > tho > using > the > actual > resource > location > there > has > benefits > (domain > ownership > check, > prevention > of > token > forwarding > etc). > > Same > for > Auth0, > the > audience > parameter > is > a > logical > identifier > rather > than > a > location. > > On > Wed, > Jan > 16, > 2019 > at > 6:32 > PM > Rifaat > Shekh-Yusef > > > wrote: > > All, > > > The > following > is > the > first > shepherd > write-up > for > the draft-ietf-oauth-resource-indicators-01 > document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ > > Please, > take > a > look > and > let me > know > if > I > missed > anything. > > Regards, > >  Rifaat > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use > of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited. > If > you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > > */CONFIDENTIALITY > NOTICE: > This > email > may > contain > confidential > and > privileged > material > for > the > sole > use > of > the > intended > recipient(s). > Any > review, > use, > distribution > or > disclosure > by > others > is > strictly > prohibited.. > If > you > have > received > this > communication > in > error, > please > notify > the > sender > immediately > by > e-mail > and > delete > the > message > and > any > file > attachments > from > your > computer. > Thank > you./* > > _______________________________________________ > OAuth > mailing > list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY > NOTICE: This email may > contain confidential > and privileged > material for the sole > use of the intended > recipient(s). Any > review, use, > distribution or > disclosure by others > is strictly > prohibited... If you > have received this > communication in > error, please notify > the sender immediately > by e-mail and delete > the message and any > file attachments from > your computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential > and privileged material for the sole use of the intended > recipient(s). Any review, use, distribution or disclosure by > others is strictly prohibited..  If you have received this > communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from > your computer. Thank you./ > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ --------------1CD0A9136094A3FD1F9AE843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?

Thanks,
George

On 1/28/19 3:54 PM, Brian Campbell wrote:
[added ace@ietf.org kinda per suggestion from Mike]

I don't know that there are concerns about “req_aud” per se.  Admittedly, I did use the word "concerns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that “req_aud”  is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway.

I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

Brian, etc.  If you have concerns about “req_aud”, now’s the time to provide that feedback to the ACE WG, as they’re trying to complete that draft soon.  Please join the ACE WG mailing list and send your feedback there directly.

 

You and I may know that ACE OAuth and OAuth 2 are pretty different but developers later will just see the OAuth parameter registration and won’t realize that it’s coming from a different universe.  If we can harmonize things now, we should.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth@ietf.org; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possible there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the "real" endpoints, then it's also "logical" in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are "logical" along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS.

Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:

I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too.

 

The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deployment specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI" for the application or resource. Is that a a location or an abstract identifier? Or kinda both?

 

In addition to the concerns others have expressed about "req_aud", I"d note that draft-ietf-ace-oauth-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework". Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would be a disservice to just about everyone.

 

 

 

 

 

 

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hannes sent an update to this meeting here:

 

Regards,

 Rifaat

 

 

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@microsoft.com> wrote:

The virtual office hours in my calendar start 1/2 hour before that.  If the time has changed, can you have the meeting organizer update the calendar entry?

 

                                                          Thanks,

                                                          -- Mike

 

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

All,

 

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this.

 

Regards,

 Rifaat

 

 

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% convinced that 'audience' and 'logical resource' are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:

As mentioned below, I agree the two can be separated- but I also agree with George on the need to be clear an easy to reference for developers.

Just adding a reference to req_aud would just raise the cyclomatic complexity of the specs, which is already unusably high for mere mortals in the OAuth2/OIDC family of specs.

 

One additional complication is that this specification is reusing a parameter that is already used in a very large number of production systems (small example here), and whose concrete semantic happens to be prevalently logic identifier. If the parameter you are defining here has a different semantic, at the very least it would seem good hygiene to rename it to avoid collision and confusion.

 

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I agree with John’s logic.  The physical resource and logical resource should use different identifiers.  Fortunately, we already have “resource” and “req_aud” for these parameters.  I believe we’re good to go, as-is.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

I don't think they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.  I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

 

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

 

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

 

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

 

Regards,

 Rifaat

 

 

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource' as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

 

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:

[sent to John only by mistake, resending to the ML]

 

In Azure AD v1 & ADFS, that's resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as explicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting aud of the issued token.

This is 9 months old info hence

 

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn't have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

 

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in oauth-resource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same. 

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't as pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete security advantages don't apply to the their case, people will simply not comply. 

 

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in oauth-resource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

 

 

 

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com> wrote:

+1 to Mike and John’s comments. 

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources.  They are different, if related, things.

 

Note that the ACE WG is proposing to register a logical audience parameter “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.  This is a general OAuth parameter, which any OAuth deployment will be able to use.

 

I therefore believe that no changes are needed to draft-ietf-oauth-resource-indicators, as the logical audience work is already happening in another draft.

 

                                                          -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

We need to decide if we want to make a change.  

 

For security we are location centric.  

 

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.  

 

If becomes harder for people to use the parameter correctly if we are too flexible.  

 

I would rather have a separate logical audience parameter if we think we want one.  

 

John B. 

 

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.com wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

 

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something. 

 

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

 

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it talks about the value of the 'resource' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource' parameter value that's a logical identifier that points to some resource is well within the bounds of the draft.

 

So maybe the draft is okay as is?

 

Or perhaps that's too much to be left as an exerciser to the reader?  And some text should be added and/or adjusted so the resource-indicators draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

 

 

 

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worry too much about the process.

If it makes sense to update the document, then feel free to do that.

 

Regards,

 Rifaat

 

 

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the logical resource can be provided by "scope"

 

Some implementations like Ping and Auth0 have been adding another parameter "aud" to identify the logical resource and then using scopes to define permissions to the resource.

 

Fortunately, we are using a different parameter name so not stepping on that..

 

We could go back and try to add text explaining the difference, but we are quite late in the process. 

 

I agree that a logical resource parameter may be helpful, but perhaps it should be a separate draft.

 

John B.

 

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environment/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

 

 

 

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.  

This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

 

The text you quoted is copied form the abstract of the draft itself.

 

 

Authors,

 

Should the draft be updated to cover the logical identifier case?

 

Regards,

 Rifaat

 

 

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Rifaat,

one detail. The tech summary says

 

An extension to the OAuth 2.0 Authorization Framework defining request 
parameters that enable a client to explicitly signal to an authorization server 
about the location of the protected resource(s) to which it is requesting 
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn't strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

 

 

 

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

 

The following is the first shepherd write-up for the draft-ietf-oauth-resource-indicators-01 document.

 

Please, take a look and let me know if I missed anything.

 

Regards,

 Rifaat

 

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

 

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

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

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

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


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


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

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


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

 

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

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

 

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

 

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

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


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

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

 


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

--------------1CD0A9136094A3FD1F9AE843-- From nobody Mon Jan 28 15:14:23 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE291311CD; Mon, 28 Jan 2019 15:14:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154871725544.2952.4788953447063838330@ietfa.amsl.com> Date: Mon, 28 Jan 2019 15:14:15 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 23:14:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-02.txt Pages : 13 Date : 2019-01-28 Abstract: An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 28 15:26:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55C13122B for ; Mon, 28 Jan 2019 15:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leZD5rSoGHXA for ; Mon, 28 Jan 2019 15:26:22 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA94E131142 for ; Mon, 28 Jan 2019 15:26:21 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id m19so15034550ioh.3 for ; Mon, 28 Jan 2019 15:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BICFn3GCMOrtgaOVX2XbOz3BYEdsgnwVJtN/xr/qJho=; b=ZanF46zoKOqhyrsqdGaX/P6HvpfvtSyWMj0xN0oEgPxT2HWkXTC3N+erCsw6oDAPGh jeoFxDqsojsAnKUFyBs1uUzjxcxnSyRXxpkbhqERYl686uto7feDeUpdabhmXU7HrNDy 2AnTnnPlFS1pPgY/GX27D+kjHaEgYuLuWge30= 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=BICFn3GCMOrtgaOVX2XbOz3BYEdsgnwVJtN/xr/qJho=; b=prs7aVtcqzw6o8ruPurAdWkDJI2LzYvJh4r4Y+8+nAinY2ZE0C1OYLe1lsr+BZq9ay F2oUeyHXNzI1VXAdM23EANL0OGV9w3rQ/fVVPOxHbfIFvxuv4ndujlIPAzdoiHeGL/S4 gWYpH17X/Pt42WkgWfOpu6BV+qLyIAFfm3NtvUmQbhYbLWTjRt4+fje/WE8t9afDbWmh J8nIAZ6p2gpVJ1hT3VIP7pf3cPPwHOwWJ/nLkpNyvOkaN3CGuGeSVUeZoHn0V7ofI+Yz gUSljOOiu/qu+pZ/14wZe3Xl0oa15ed+YPB5KgMaRCi7rsnVyajuWus1sJmByCsiYwK2 qLBw== X-Gm-Message-State: AHQUAuYQqjk7NQHIrKnzh6R5btQVhXjDHiP72wOP6S+dmIP+8+adYcdL bSP70ewkhjG43iPrSicdAJak6YIS2yS0LfAmRxdsznhIBRlepTejGPlNCGTEWugvAECJGnNpnt6 Lr9vJK9xr5+Z0/w== X-Google-Smtp-Source: ALg8bN4vXz4x+cQUzaa1c4jNzSULYdjEp6RElTUubDSvDbzpEgxxqt5bLSkAjlOL407si7BTIzhQ26XrR9RzlcRsQeA= X-Received: by 2002:a6b:b345:: with SMTP id c66mr14067742iof.59.1548717980480; Mon, 28 Jan 2019 15:26:20 -0800 (PST) MIME-Version: 1.0 References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> In-Reply-To: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> From: Brian Campbell Date: Mon, 28 Jan 2019 16:25:50 -0700 Message-ID: To: George Fletcher Cc: Mike Jones , ace@ietf.org, "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000001599c705808d0199" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 23:26:28 -0000 --0000000000001599c705808d0199 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Following up on the thread here and the discussion earlier during the "OAuth WG Virtual Office Hours" call, draft-ietf-oauth-resource-indicators-02 has been published with some minor updates to clarify that the value of the "resource" parameter is a URI which can be an abstract identifier for the target resource and doesn't necessarily have to correspond to a network addressable location. On Mon, Jan 28, 2019 at 3:12 PM George Fletcher wrote: > I also don't know that this raises to the level of "concern" but I find > the parameter name of "req_aud" odd. Given that the parameter in the > resource-indicators spec is 'resource' why not use a parameter name of > 'audience'. That said, I have not read the thread on the ACE working grou= p > list so there could be very good reasons for the chosen name:) > > I do think that there is a lot of overlap (in most cases) between > 'resource' and 'audience' and having two parameters that cover a lot of t= he > same semantics is going to be confusing for developers. When calling an A= PI > at a resource server, the 'audience' and the 'resource' are pretty > equivalent. Maybe in other use cases they are distinctly separate? > > Thanks, > George > > On 1/28/19 3:54 PM, Brian Campbell wrote: > > [added ace@ietf.org kinda per suggestion from Mike] > > I don't know that there are concerns about =E2=80=9Creq_aud=E2=80=9D per = se. Admittedly, > I did use the word "concerns" but I was more trying to say that referenci= ng > it from the draft-ietf-oauth-resource-indicators document wasn't needed t= o > address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80= =9D is defined for > the token endpoint while the draft-ietf-oauth-resource-indicators documen= t > also deals with the authorization endpoint so such a reference wouldn't > really work anyway. > > I don't know of anyone that just works from the OAuth parameter > registration but maybe I'm just out of touch. And I don't think its a > stretch at all to observe that ACE OAuth and OAuth 2 are different. > > > > On Mon, Jan 28, 2019 at 11:28 AM Mike Jones > wrote: > >> Brian, etc. If you have concerns about =E2=80=9Creq_aud=E2=80=9D, now= =E2=80=99s the time to >> provide that feedback to the ACE WG, as they=E2=80=99re trying to comple= te that >> draft soon. Please join the ACE WG mailing list and send your feedback >> there directly. >> >> >> >> You and I may know that ACE OAuth and OAuth 2 are pretty different but >> developers later will just see the OAuth parameter registration and won= =E2=80=99t >> realize that it=E2=80=99s coming from a different universe. If we can h= armonize >> things now, we should. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *George Fletcher >> *Sent:* Monday, January 28, 2019 10:05 AM >> *To:* Brian Campbell >> *Cc:* oauth@ietf.org; Vittorio Bertocci >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> +1 >> >> I came to a similar conclusion over the weekend. If >> https://api.example.com/mail is an allowed location URI, how is it not >> also a logical location considering it's possible there are multiple >> endpoints "below" https://api.example.com/mail? (e.g. >> https://api.example.com/mail/user/mailbox). Also if https://api.example.= com >> is really a load balancer that fronts the " >> real" >> endpoints, then it's also "logical" in that context and not an exact >> location. >> >> This brings me to the conclusion that all the resource identifiers are >> "logical" along a range of specificity. How specific a resource is >> identified is really a risk decision and based on the deployment model c= an >> be managed at either the RS or the AS. >> >> Thanks, >> George >> >> On 1/28/19 9:07 AM, Brian Campbell wrote: >> >> I plan on joining the meeting today at noon eastern time to discuses thi= s >> little ditty. I hope others who have a stake in it can too. >> >> >> >> The proposed changes that Vittorio and I put together can be seen in the >> diff of this pull request >> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I >> even put a xml2rfc'ed text version on >> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of >> reference. I maintain that is the most straightforward way forward with = all >> this. Yet another new additional parameter could be defined for the logi= cal >> case but I struggle to see the value in doing so. The 'resource' is URI >> that points to the resource. The level of specificity of that pointer is >> intentionally a bit fuzzy and application/deployment specific. Is >> https://graph.microsoft.com (mentioned in the documentation previously >> linked) a location or an abstract identifier or both? The document alrea= dy >> (somewhat awkwardly) describes using a "base URI" for the application or >> resource. Is that a a location or an abstract identifier? Or kinda both? >> >> >> >> In addition to the concerns others have expressed about "req_aud", I"d >> note that draft-ietf-ace-oauth-params defines its use only at the token >> endpoint as one of the "additional parameters for requesting an access >> token from a token endpoint in the ACE framework". Whereas the >> resource-indicators draft scope includes the authorization endpoint too. >> Furthermore, while the ACE WG is building on OAuth, for all intents and >> purposes ACE and regular OAuth are different worlds and I think a refere= nce >> in regular OAuth document like this one to "Additional OAuth Parameters = for >> Authorization in Constrained Environments (ACE)" would be a disservice t= o >> just about everyone. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef > > wrote: >> >> Hannes sent an update to this meeting here: >> >> https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 24, 2019 at 6:20 PM Mike Jones >> wrote: >> >> The virtual office hours in my calendar start 1/2 hour before that. If >> the time has changed, can you have the meeting organizer update the >> calendar entry? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> *From:* Rifaat Shekh-Yusef >> *Sent:* Thursday, January 24, 2019 12:46 PM >> *To:* George Fletcher >> *Cc:* Vittorio Bertocci ; Mike Jones < >> Michael.Jones@microsoft.com>; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> All, >> >> >> >> This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled >> OAuth WG Virtual Office meeting. >> >> Feel free to attend the meeting to discuss this topic to try to get to a >> conclusion on this. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> +1 >> >> Also, I don't really like the parameter name 'req_aud' :) I'm not 100% >> convinced that 'audience' and 'logical resource' are completely overlapp= ing >> concepts. We can potentially make them completely overlapping but we nee= d >> text to that effect. >> >> I also believe that we don't have a complete solution for all deployment= s >> using exact locations (see my previous email). >> >> Thanks, >> George >> >> On 1/23/19 2:50 PM, Vittorio Bertocci wrote: >> >> As mentioned below, I agree the two can be separated- but I also agree >> with George on the need to be clear an easy to reference for developers. >> >> Just adding a reference to req_aud would just raise the cyclomatic >> complexity of the specs, which is already unusably high for mere mortals= in >> the OAuth2/OIDC family of specs. >> >> >> >> One additional complication is that this specification is reusing a >> parameter that is already used in a *very* large number of production >> systems (small example here >> ), >> and whose concrete semantic happens to be prevalently logic identifier. = If >> the parameter you are defining here has a different semantic, at the ver= y >> least it would seem good hygiene to rename it to avoid collision and >> confusion. >> >> >> >> On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >> I agree with John=E2=80=99s logic. The physical resource and logical re= source >> should use different identifiers. Fortunately, we already have =E2=80= =9Cresource=E2=80=9D >> and =E2=80=9Creq_aud=E2=80=9D for these parameters. I believe we=E2=80= =99re good to go, as-is. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Wednesday, January 23, 2019 10:56 AM >> *To:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> I don't think they are necessarily mutually exclusive, that is why I >> think there is value in allowing them to be specified separately. >> >> As an AS in the distributed OAuth case knowing that a client interacting >> with RS https://fire.hhs.com as the resource wants a OAuth token with an >> audience of HHS and a scope of read. >> >> Without proof of possession we need to keep bad RS from asking for token= s >> with scopes and audiences of other RS that can be replayed. >> >> I really like keeping the resource simple and unspoofable, it is the URI >> of the RS where you are presenting the AT. >> >> I prefer to keep that separate from the logical resource that may span >> more than one RS endpoint. >> >> Merging the two and we are probably back at the AS looking into the URI >> to figure out which one it is. I think that is harder for implementatio= ns >> and more likely to have security issues down the road. >> >> John B. >> >> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote: >> >> Hi all, >> >> thanks for you patience. Brian and myself iterated on modifying the text >> to cover the logical identifier use case, highlighting the security >> implications of going that route. You can find the revised text in >> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-in= dicators.xml, >> see the commits in the history from January 21 for the specific changes. >> >> Note: I also had a chat with John offline, and he expressed the desire t= o >> split the resource parameter in two distinct parameters to better signal >> the intended usage. I am sure he can elaborate. I have nothing against i= t >> in principle, as long as we leave nothing as exercise to the reader and = we >> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a >> chance to speak w Brian about it. If the discussion stretches further, I >> would suggest we pause it and let him enjoy his time off for the rest of >> the week. >> >> >> >> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef >> wrote: >> >> Thank you guys! >> >> >> >> On Monday, January 21, 2019, Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> absolutely. Brian and myself already started working on some language, >> however this week he is in vacation hence it might take few days before = we >> come back to the list with something. >> >> Cheers, >> >> V. >> >> >> >> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef >> wrote: >> >> Brian, Vittorio, >> >> >> >> To move this discussion forward, can you guys suggest some text to make >> the logical identifier usage clearer? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell > 40pingidentity.com@dmarc.ietf..org <40pingidentity.com@dmarc.ietf.org>> >> wrote: >> >> As I suggested before, I do think that's within the bounds of the draft'= s >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci >> wrote: >> >> [sent to John only by mistake, resending to the ML] >> >> >> >> In Azure AD v1 & ADFS, that's resource.. It could be used for both >> network and logical ids, with the concrete usage in the wild I described >> earlier. >> >> In Azure AD v2, the resource as explicit parameter (network, logic or >> otherwise) is gone and is expressed as part of the scope string of all t= he >> scopes requested for a given resource- but it still exist in practice th= o >> as it still end up in the resulting aud of the issued token. >> >> This is 9 months old info hence >> >> >> >> On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: >> >> What is the parameter that Microsoft is using? >> >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: >> >> First of all, it wasn't my intent to disrupt the established process. In >> my former position I wasn't monitoring those discussions hence I didn't >> have a chance to offer feedback. When I saw something that gave me the >> impression might lead to issues, and given that I worked with actual >> deployments and developers using a similar parameter for a long time, I >> thought prudent to bring this up. I really appreciate Rifaat's stance on >> this. End of preamble. >> >> >> >> Ultimately my goal is for developers to have guidance on how to work wit= h >> the concept of logical resource in a standard compliant way, hence it >> doesn't strictly matter whether the definition of the corresponding >> parameter lives in oauth-resource-indicators or elsewhere. >> >> That said. Reading through the draft, it would appear that most of the >> reasons for which the spec was created apply to both the network >> addressable and the logical resource types: knowing what keys to use to >> encrypt the token, constrain access tokens to the intended audience, >> avoiding overloading scopes with resource indicating parts... those all >> apply to network addressable and logic identifiers alike. And both >> parameters are expected to result in audience restricted tokens. It seem= s >> the only difference comes at token usage time, with the network addressa= ble >> case giving more guarantees that the token will go to its intended >> recipient, but the request and audience restriction syntax seems to be >> exactly the same. >> >> On top of this: in the 99.999% of the scenarios I encountered in the wil= d >> in the last 5 years of using the resource parameter in the MS ecosystem, >> the resource identifier was known at design time: the developer discover= ed >> it out of band and placed it in the app config at deployment time. Those >> aren't fringe cases I occasionally encountered: the resource parameter i= n >> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw= or >> touched used it. As Brian suggested, this is a scenario where the securi= ty >> advantages of the network addressable case aren't as pronounced as in th= e >> case in which the client discovers the resource identifier at runtime. T= his >> isn't just because there is no specification suggesting location should = be >> explicitly indicated, it's because there are many practical advantages a= t >> development and deployment time to be able to use logical identifiers- a= nd >> if the *concrete *security advantages don't apply to the their case, >> people will simply not comply. >> >> >> >> In summary: creating two different parameters in two different documents >> is better than ignoring he logical identifier case altogether, however I >> think that not acknowledging the logical id case >> in oauth-resource-indicators is going to create confusion and ultimately >> not be as useful to the developer community as it could be. >> >> >> >> >> >> >> >> On Sat, Jan 19, 2019 at 12:38 Phil Hunt wrote: >> >> +1 to Mike and John=E2=80=99s comments. >> >> Phil >> >> >> On Jan 19, 2019, at 12:34 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I also agree that =E2=80=9Cresource=E2=80=9D should be a specific networ= k-addressable URL >> whereas a separate audience parameter (like =E2=80=9Caud=E2=80=9D in JWT= s) can refer to one >> or more logical resources. They are different, if related, things. >> >> >> >> Note that the ACE WG is proposing to register a logical audience >> parameter =E2=80=9Creq_aud=E2=80=9D in >> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly >> based on feedback from OAuth WG members. This is a general OAuth >> parameter, which any OAuth deployment will be able to use. >> >> >> >> I therefore believe that no changes are needed to >> draft-ietf-oauth-resource-indicators, as the logical audience work is >> already happening in another draft. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *John Bradley >> *Sent:* Saturday, January 19, 2019 9:01 AM >> *To:* Brian Campbell >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> We need to decide if we want to make a change. >> >> >> >> For security we are location centric. >> >> >> >> I prefer to keep resource location separate from logical audience that >> can be a scope or other parameter. >> >> >> >> If becomes harder for people to use the parameter correctly if we are to= o >> flexible. >> >> >> >> I would rather have a separate logical audience parameter if we think we >> want one. >> >> >> >> John B. >> >> >> >> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell > wrote: >> >> No apology needed, Rifaat. And I apologize if what I said came off the >> wrong way. I was just trying to make light of the situation.. And I agre= e >> that we should not be hamstrung by the process and there are times when = it >> makes sense to be flexible with things. >> >> >> >> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef >> wrote: >> >> Sorry Brian, I was not clear with my statement. >> >> I meant to say that we should not allow the process to prevent the WG >> from producing a quality document without issues, assuming there is an >> issue in the first place. >> >> Ideally we want to get these identified during the WGLC, but things >> happen and sometimes the WG misses something. >> >> >> >> I hear you and agree that this make things difficult for authors. We wil= l >> make sure that this does not become the norm, and we will try to stick t= o >> the process as much as possible. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Thanks Rifaat. Process is as process does, right? I do kinda want to >> grumble about WGCL having passed already but that's mostly because reply= ing >> to these kinds of threads is hard for me and I'll just get over it... >> >> >> >> As far as I understand things, the security concerns come into play when >> the client is being told the by the resource how to identity the resourc= e >> like is described in >> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using >> the actual location in that context ,along with some other checks >> prescribed in that draft, prevents the kind of issues John described >> earlier in the thread. >> >> In cases where the client knows the resource a priori or out-of-band or >> configured or whatever, I don't think the same security concerns arise. = And >> using such a known value, be it an actual location or logical >> representation, would be okay. >> >> The resource-indicators draft is admittedly somewhat location-centric in >> how it talks about the value of the 'resource' parameter. But ultimately= it >> defines it as an absolute URI that indicates the location of the target >> service or resource where access is being requested. A location can be >> varying shades of abstract and I'd say that using a URI as 'resource' >> parameter value that's a logical identifier that points to some resource= is >> well within the bounds of the draft. >> >> >> >> So maybe the draft is okay as is? >> >> >> >> Or perhaps that's too much to be left as an exerciser to the reader? An= d >> some text should be added and/or adjusted so the resource-indicators dra= ft >> would be a little more open/clear about the parameter value potentially >> being more of a logical or abstract identifier and not necessarily a >> network addressable URL? >> >> >> >> >> >> >> >> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef >> wrote: >> >> I wouldn't worry too much about the process. >> >> If it makes sense to update the document, then feel free to do that. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Fri, Jan 18, 2019 at 3:08 PM John Bradley wrote: >> >> Yes the logical resource can be provided by "scope" >> >> >> >> Some implementations like Ping and Auth0 have been adding another >> parameter "aud" to identify the logical resource and then using scopes t= o >> define permissions to the resource. >> >> >> >> Fortunately, we are using a different parameter name so not stepping on >> that.. >> >> >> >> We could go back and try to add text explaining the difference, but we >> are quite late in the process. >> >> >> >> I agree that a logical resource parameter may be helpful, but perhaps it >> should be a separate draft. >> >> >> >> John B. >> >> >> >> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Doesn=E2=80=99t the =E2=80=9Cscope=E2=80=9D parameter already provide a = means of specifying a >> logical identifier? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Vittorio Bertocci >> > >> *Date: *Friday, January 18, 2019 at 5:47 AM >> *To: *John Bradley >> *Cc: *IETF oauth WG >> *Subject: *Re: [OAUTH-WG] Shepherd write-up for >> draft-ietf-oauth-resource-indicators-01 >> >> >> >> Thanks John for the background. >> >> I agree that from the client validation PoV, having an identifier >> corresponding to a location makes things more solid. >> >> That said: the use of logical identifiers is widespread, as it has >> significant practical advantages (think of services that assign generate= d >> hosting URLs only at deployment time, or services that are somehow group= ed >> under the same logical audience across regions/environment/deployments). >> People won't stop using logical identifiers, because they often have no >> alternative (generating new audiences on the fly at the AS every time yo= u >> do a deployment and get assigned a new URL can be unfeasible). Leaving a >> widely used approach as exercise to the reader seems a disservice to the >> community, given that this might lead to vendors (for example Microsoft = and >> Auth0) keeping their own proprietary parameters, or developers misusing = the >> ones in place; would make it hard for SDK developers to provide librarie= s >> that work out of the box with different ASes; and so on. >> >> Would it be feasible to add such parameter directly in this spec? That >> would eliminate the interop issues, and also gives us a chance to fully >> warn people about the security shortcomings of choosing that approach. >> >> >> >> >> >> >> >> On Thu, Jan 17, 2019 at 4:32 PM John Bradley wrote: >> >> We have discussed this. >> >> Audiences can certainly be logical identifiers. >> >> This however is a more specific location. The AS is free to map the >> location into some abstract audience in the AT. >> >> From a security point of view once the client starts asking for logical >> resources it can be tricked into asking for the wrong one as a bad resou= rce >> can always lie about what logical resource it is. >> >> If we were to change it, how a client would validate it becomes >> challenging to impossible. >> >> The AS is free to do whatever mapping of locations to identifiers it >> needs for access tokens. >> >> Some implementations may want to keep additional parameters like logical >> audience, but that should be separate from resource. >> >> John B. >> >> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Vittorio, >> >> >> >> The text you quoted is copied form the abstract of the draft itself. >> >> >> >> >> >> *Authors,* >> >> >> >> Should the draft be updated to cover the logical identifier case? >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci >> wrote: >> >> Hi Rifaat, >> >> one detail. The tech summary says >> >> >> >> An extension to the OAuth 2.0 Authorization Framework defining request >> >> parameters that enable a client to explicitly signal to an authorization= server >> >> about the *location* of the protected resource(s) to which it is request= ing >> >> access. >> >> But at least in the Microsoft implementation, the resource identifier >> doesn't *have* to be a network addressable URL (and if it is, it doesn't >> strictly need to match the actual resource location). It can be a logica= l >> identifier, tho using the actual resource location there has benefits >> (domain ownership check, prevention of token forwarding etc). >> >> Same for Auth0, the audience parameter is a logical identifier rather >> than a location. >> >> >> >> >> >> >> >> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> >> >> The following is the first shepherd write-up for >> the draft-ietf-oauth-resource-indicators-01 document. >> >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/sh= epherdwriteup/ >> >> >> >> Please, take a look and let me know if I missed anything. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000001599c705808d0199 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following up on the thre= ad here and the discussion earlier during the "OAuth WG Virtual Office= Hours" call, draft-ietf-oauth-resource-indicat= ors-02 has been published with some minor updates to clarify that the v= alue of the "resource" parameter is a URI which can be an abstrac= t identifier for the target resource and doesn't necessarily have to co= rrespond to a network addressable location.

On= Mon, Jan 28, 2019 at 3:12 PM George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
I also don't know that this raises to the level of "concern&qu= ot; but I find the parameter name of "req_aud" odd. Given that the para= meter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the th= read on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters tha= t cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they= are distinctly separate?

Thanks,
George

On 1/28/19 3:54 PM, Brian Campbell wrote:
=20
[added ace@ietf.org kinda per suggestion from Mike]

I don't know that there are concerns about =E2=80= =9Creq_aud=E2=80=9D per se.=C2=A0 Admittedly, I did use the word "conc= erns" but I was more trying to say that referencing it from the draft-ietf-oauth-resource-indicators document wasn't needed to address Vittorio's request. And pointing out that =E2=80=9Creq_aud=E2=80= =9D=C2=A0 is defined for the token endpoint while the draft-ietf-oauth-resource-indicators document also deals with the authorization endpoint so such a reference wouldn't really work anyway.

I don't know of anyone that just works from the OAuth parameter registration but maybe I'm just out of touch. And I don't think its a stretch at all to observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan 28, 2019 at 11:28 AM Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Brian, etc.=C2=A0 If you have concerns about =E2=80=9Creq_aud=E2= =80=9D, now=E2=80=99s the time to provide that feedback to the ACE WG, as they=E2=80=99re trying to complete= that draft soon.=C2=A0 Please join the ACE WG mailing list and send your feedback there directly.

=C2=A0

You and I may know that ACE OAuth and OAuth 2 are pretty different but developers later will just see the OAuth parameter registration and won=E2=80=99t realize that it=E2=80=99s comin= g from a different universe.=C2=A0 If we can harmonize things now, we should.

=C2=A0

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

=C2=A0

From: OAuth <<= a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ie= tf.org> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf= .org>
Cc: oauth@ietf.org; Vittorio Bertocci <vittorio.bertocci@auth0.com>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

=C2=A0

+1

I came to a similar conclusion over the weekend. If https://api.example.com/mail is an allowed location URI, how is it not also a logical location considering it's possibl= e there are multiple endpoints "below" https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). Also if https://api.example.com is really a load balancer that fronts the &quo= t;real" endpoints, then it's also "logical&q= uot; in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are "logical&qu= ot; along a range of specificity. How specific a resource is identified is really a risk decision and based on the deployment model can be managed at either the RS or the AS.
Thanks,
George

On 1/28/19 9:07 AM, Brian Campbell wrote:

I plan on joining the meeting today at noon eastern time to discuses this little ditty. I hope others who have a stake in it can too.

=C2=A0

The proposed changes that Vittorio and I put together can be seen in the diff of this pull request https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even put a xml2rfc'ed text version on https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of reference. I maintain that is the most straightforward way forward with all this. Yet another new additional parameter could be defined for the logical case but I struggle to see the value in doing so. The 'resource' = is URI that points to the resource. The level of specificity of that pointer is intentionally a bit fuzzy and application/deploym= ent specific. Is https://graph.microsoft.com (mentioned in the documentation previously linked) a location or an abstract identifier or both? The document already (somewhat awkwardly) describes using a "base URI&qu= ot; for the application or resource. Is that a a location or an abstract identifier? Or kinda both?

=C2=A0

In addition to the concerns others have expressed about "req_aud= ", I"d note that draft-ietf-ace-oaut= h-params defines its use only at the token endpoint as one of the "additional parameters for requesting an access token from a token endpoint in the ACE framework"= . Whereas the resource-indicators draft scope includes the authorization endpoint too. Furthermore, while the ACE WG is building on OAuth, for all intents and purposes ACE and regular OAuth are different worlds and I think a reference in regular OAuth document like this one to "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)" would b= e a disservice to just about everyone.

=C2=A0

=C2=A0

= =C2=A0

= =C2=A0

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hannes sent an update to this meeting here:

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 24, 2019 at 6:20 PM Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

The virtual office hours in my calendar start 1/2 hour before that.=C2=A0 If the time has changed, can you have the meeting organizer update the calendar entry?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

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

=C2=A0

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&= gt;
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <gffletch@aol.com>
Cc: Vittorio Bertocci <Vittorio@auth0.com>; Mike Jones <Michael.Jones@microsoft.com<= /a>>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicat= ors-01

=C2=A0

All,

=C2=A0=

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG Virtual Office meeting.

Feel free to attend the meeting to discuss this topic to try to get to a conclusion on this.

=C2=A0=

Regards,

=C2=A0Rifaat

=C2=A0=

=C2=A0

On Wed, Jan 23, 2019 at 3:00 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

+1

Also, I don't really like the parameter name 'req_aud' :)= I'm not 100% convinced that 'audience' a= nd 'logical resource'= ; are completely overlapping concepts. We can potentially make them completely overlapping but we need text to that effect.

I also believe that we don't have a complete solution for all deployments using exact locations (see my previous email).

Thanks,
George

On 1/23/19 2:50 PM, Vittorio Bertocci wrote:

=C2= =A0

= On Wed, Jan 23, 2019 at 11:03 AM Mike Jones <Michael.Jones=3D<= a href=3D"mailto:40microsoft.com@dmarc.ietf.org" target=3D"_blank">40micros= oft.com@dmarc.ietf.org> wrote:

I agree with John=E2=80=99s logic.= =C2=A0 The physical resource and logical resource should use different identifiers.=C2= =A0 Fortunately, we already have =E2=80=9Cresource= =E2=80=9D and =E2=80=9Creq_aud= =E2=80=9D for these parameters.=C2=A0= I believe we=E2=80= =99re good to go, as-is.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

I don't thin= k they are necessarily mutually exclusive, that is why I think there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with RS https://fire.hhs.com as the resource wants a OAuth token with an audience of HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to figure out which one it is.=C2=A0 I think that is harder for implementations and more likely to have security issues down the road.

John B.

On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:

Hi all,

thanks for you patience. Brian and myself iterated on modifying the text to cover the logical identifier use case, highlighting the security implications of going that route. You can find the revised text in=C2=A0https://github.com/vibronet/i-d/blob/maste= r/draft-ietf-oauth-resource-indicators.xml, see the commits in the history from January 21 for the specific changes.

Note: I also had a chat with John offline, and he expressed the desire to split the resource parameter in two distinct parameters to better signal the intended usage. I am sure he can elaborate. I have nothing against it in principle, as long as we leave nothing as exercise to the reader and we are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian about it. If the discussion stretches further, I would suggest we pause it and let him enjoy his time off for the rest of the week.

=C2=A0

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thank you guys!



On Monday, January 21, 2019, Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

absolutely. Brian and myself already started working on some language, however this week he is in vacation hence it might take few days before we come back to the list with something.

Cheers,

V.

=C2=A0

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Brian, Vittorio,

=C2=A0

To move this discussion forward, can you guys suggest some text to make the logical identifier usage clearer?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf..org> wrote:

As I suggested before, I do think that's within the bounds of the draft's definition of 'resource'= ; as a URI. And that perhaps all that's needed is some minor adjustment and/or augmentation of some text to make it more clear.

=C2=A0

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

[sent to John only by mistake, resending to the ML]

=C2=A0

In Azure AD v1 & ADFS, that's=C2=A0<= /span>resource.. It could be used for both network and logical ids, with the concrete usage in the wild I described earlier.

In Azure AD v2, the resource as e= xplicit parameter (network, logic or otherwise) is gone and is expressed as part of the scope string of all the scopes requested for a given resource- but it still exist in practice tho as it still end up in the resulting=C2=A0=C2=A0of the issued token.<= /span>

This is 9 months old info hence

=C2=A0

On Sun, Jan 20, 2019 at 17:58 John Bradley <ve7jtb@ve7jtb.com> wrote:<= /p>

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:

First of all, it wasn't my intent to disrupt the established process. In my former position I wasn't monitoring those discussions hence I didn'= t have a chance to offer feedback. When I saw something that gave me the impression might lead to issues, and given that I worked with actual deployments and developers using a similar parameter for a long time, I thought prudent to bring this up. I really appreciate Rifaat's stance on this. End of preamble.

=C2=A0

Ultimately my goal is for developers to have guidance on how to work with the concept of logical resource in a standard compliant way, hence it doesn't strictly matter whether the definition of the corresponding parameter lives in=C2=A0oauth-res= ource-indicators or elsewhere.

That said. Reading through the draft, it would appear that most of the reasons for which the spec was created apply to both the network addressable and the logical resource types: knowing what keys to use to encrypt the token, constrain access tokens to the intended audience, avoiding overloading scopes with resource indicating parts... those all apply to network addressable and logic identifiers alike. And both parameters are expected to result in audience restricted tokens. It seems the only difference comes at token usage time, with the network addressable case giving more guarantees that the token will go to its intended recipient, but the request and audience restriction syntax seems to be exactly the same.=C2=A0

On top of this: in the 99.999% of the scenarios I encountered in the wild in the last 5 years of using the resource parameter in the MS ecosystem, the resource identifier was known at design time: the developer discovered it out of band and placed it in the app config at deployment time. Those aren't fringe cases I occasionally encountered: the resource parameter in Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or touched used it. As Brian suggested, this is a scenario where the security advantages of the network addressable case aren't a= s pronounced as in the case in which the client discovers the resource identifier at runtime. This isn't just because there is no specification suggesting location should be explicitly indicated, it's because there are many practical advantages at development and deployment time to be able to use logical identifiers- and if the concrete s= ecurity advantages don't apply t= o the their case, people will simply not comply.=C2=A0=

=C2=A0

In summary: creating two different parameters in two different documents is better than ignoring he logical identifier case altogether, however I think that not acknowledging the logical id case in=C2=A0oauth-res= ource-indicators is going to create confusion and ultimately not be as useful to the developer community as it could be.

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 19, 2019 at 12:38 Phil Hunt <phil.hunt@oracle.com= > wrote:

+1 to Mike and John=E2=80=99s comments.= =C2=A0

Phil


On Jan 19, 2019, at 12:34 PM, Mike Jones <Mich= ael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I also agree that =E2=80=9Cresourc= e=E2=80=9D should be a specific network-addressab= le URL whereas a separate audience parameter (like =E2=80=9Cau= d=E2=80=9D in JWTs) can refer to one or more logical resources.=C2=A0 They are different, if related, things.

=C2=A0

Note that the ACE WG is proposing = to register a logical audience parameter =E2=80=9Creq_aud= =E2=80=9D in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth WG members.=C2=A0 Th= is is a general OAuth parameter, which any OAuth deployment will be able to use.

=C2=A0

I therefore believe that no change= s are needed to draft-ietf-oauth-= resource-indicators, as the logical audience work is already happening in another draft.

=C2=A0

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

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <bcampbell@pingidentity.c= om>
Cc: Vittorio Bertocci <Vitt= orio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

We need to decide if we want to make a change.=C2=A0=C2= =A0

=C2=A0

For security we are location centric.=C2=A0=C2= =A0

=C2=A0

I prefer to keep resource location separate from logical audience that can be a scope or other parameter.=C2=A0= =C2=A0

=C2=A0

If becomes harder for people to use the parameter correctly if we are too flexible.=C2=A0= =C2=A0

=C2=A0

I would rather have a separate logical audience parameter if we think we want one.=C2=A0= =C2=A0

=C2=A0

John B.=C2=A0

=C2=A0

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <bcampbell@pingidentity.c= om wrote:

No apology needed, Rifaat. And I apologize if what I said came off the wrong way. I was just trying to make light of the situation.. And I agree that we should not be hamstrung by the process and there are times when it makes sense to be flexible with things.

=C2=A0

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Sorry Brian, I was not clear with my statement.

I meant to say that we should not allow the process to prevent the WG from producing a quality document without issues, assuming there is an issue in the first place.

Ideally we want to get these identified during the WGLC, but things happen and sometimes the WG misses something.=C2=A0<= /p>

=C2=A0

I hear you and agree that this make things difficult for authors. We will make sure that this does not become the norm, and we will try to stick to the process as much as possible.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

Thanks Rifaat. Process is as process does, right? I do kinda want to grumble about WGCL having passed already but that's mostly because replying to these kinds of threads is hard for me and I'll just get over it...

=C2=A0

As far as I understand things, the security concerns come into play when the client is being told the by the resource how to identity the resource like is described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the actual location in that context ,along with some other checks prescribed in that draft, prevents the kind of issues John described earlier in the thread.

In cases where the client knows the resource a priori or out-of-band or configured or whatever, I don't think the same security concerns arise. And using such a known value, be it an actual location or logical representation, would be okay.
The resource-indicato= rs draft is admittedly somewhat location-centric in how it talks about the value of the 'resource= ' parameter. But ultimately it defines it as an absolute URI that indicates the location of the target service or resource where access is being requested. A location can be varying shades of abstract and I'd say that using a URI as 'resource'= ; parameter value that's = a logical identifier that points to some resource is well within the bounds of the draft.

=C2=A0

So maybe the draft is okay as is?

=C2=A0

Or perhaps that'= s too much to be left as an exerciser to the reader?=C2=A0 And some text should be added and/or adjusted so the resource-indicato= rs draft would be a little more open/clear about the parameter value potentially being more of a logical or abstract identifier and not necessarily a network addressable URL?

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

I wouldn't worr= y too much about the process.

If it makes sense to update the document, then feel free to do that.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Fri, Jan 18, 2019 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the=C2=A0logical resource can be provided by "scope"=

=C2=A0

Some implementations like Ping and Auth0 have been adding another parameter "aud" t= o identify the logical resource and then using scopes to define permissions to the resource.

=C2=A0

Fortunately, we are using a different=C2=A0parameter name so not stepping on that..

=C2=A0

We could go back and try to add text explaining the difference, but we are quite late in the process.=C2= =A0

=C2=A0

I agree that a logical resource parameter=C2=A0ma= y be helpful, but perhaps it should be a separate draft.

=C2=A0

John B.

=C2=A0

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Doesn=E2=80=99t the =E2=80=9Cscop= e=E2=80=9D parameter already provide a means of specifying a logical identifier?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci <Vittorio=3D40auth0.com@= dmarc.ietf.org>
Date: Frid= ay, January 18, 2019 at 5:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>=
Cc: IETF oauth WG <oauth@ietf.org>
Subject: R= e: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-= resource-indicators-01

=C2=A0

Thanks John for the background.

I agree that from the client validation PoV, having an identifier corresponding to a location makes things more solid.

That said: the use of logical identifiers is widespread, as it has significant practical advantages (think of services that assign generated hosting URLs only at deployment time, or services that are somehow grouped under the same logical audience across regions/environme= nt/deployments). People won't stop using logical identifiers, because they often have no alternative (generating new audiences on the fly at the AS every time you do a deployment and get assigned a new URL can be unfeasible). Leaving a widely used approach as exercise to the reader seems a disservice to the community, given that this might lead to vendors (for example Microsoft and Auth0) keeping their own proprietary parameters, or developers misusing the ones in place; would make it hard for SDK developers to provide libraries that work out of the box with different ASes; and so on.

Would it be feasible to add such parameter directly in this spec? That would eliminate the interop issues, and also gives us a chance to fully warn people about the security shortcomings of choosing that approach.

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 4:32 PM John Bradley <ve7jtb@ve7jtb.com> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.=C2= =A0=C2=A0

This however is a more specific location.=C2=A0 T= he AS is free to map the location into some abstract audience in the AT.

From a security point of view once the client starts asking for logical resources it can be tricked into asking for the wrong one as a bad resource can always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for access tokens.

Some implementations may want to keep additional parameters like logical audience, but that should be separate from resource.

John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

=C2=A0

The text you quoted is copied form the abstract of the draft itself.

=C2=A0

=C2=A0

Authors,

=C2=A0

Should the draft be updated to cover the logical identifier case?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:

Hi Rifaat,

one detail. The tech summary says

=C2=A0

=
An extension to the OAuth 2.0 Authorization Framework defining request 
=
parameters that enable a client to explicitly signal to an authorization se=
rver 
=
about the location of the protected resource(s) to which it is reque=
sting 
=
access.

But at least in the Microsoft implementation, the resource identifier doesn't have to be a network addressable URL (and if it is, it doesn'= t strictly need to match the actual resource location). It can be a logical identifier, tho using the actual resource location there has benefits (domain ownership check, prevention of token forwarding etc).

Same for Auth0, the audience parameter is a logical identifier rather than a location.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

=C2=A0

The following is the first shepherd write-up for the=C2=A0draft-ie= tf-oauth-resource-indicators-01 document.

=C2=A0

Please, take a look and let=C2=A0me know if I missed anything.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

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

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

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


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


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

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


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

=C2=A0

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf.org/mailman/listinfo/oauth

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

=C2= =A0

______________________=
_________________________
OAuth mailing list
                                                
OAuth@ietf.org

                                                
https://www.ietf..org/m=
ailman/listinfo/oauth

=C2=A0=

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

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


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

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

=C2=A0


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


<= 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. --0000000000001599c705808d0199-- From nobody Mon Jan 28 23:56:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55477130F29; Mon, 28 Jan 2019 23:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO37zxhfISDC; Mon, 28 Jan 2019 23:56:21 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40085.outbound.protection.outlook.com [40.107.4.85]) (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 4A583130F26; Mon, 28 Jan 2019 23:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LOXZN/bv5QEEHtF/j7ZEY6i7d2sWoRwJ+HgTEH3flnw=; b=BLDIGLuL+L2dQpBFDoG6B6DdgnglzlPgZ5ObZlI0ia0ZD6cV0fd3zwhDU7bQ7KIELCe799whmrbOGQTC0v5SLM5jy/pQg0PcCkh22RV+/RgidjGD7Do7UgKoegWJEZqZ1XsL9W7oxrP606GHHjmr7VBmglvr0qRGtcq3vS1JuIw= Received: from HE1P189CA0014.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::27) by AM5P18901MB0098.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:78::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16; Tue, 29 Jan 2019 07:56:18 +0000 Received: from HE1EUR02FT022.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::206) by HE1P189CA0014.outlook.office365.com (2603:10a6:7:53::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.16 via Frontend Transport; Tue, 29 Jan 2019 07:56:18 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT022.mail.protection.outlook.com (10.152.10.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Tue, 29 Jan 2019 07:56:18 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 29 Jan 2019 08:56:16 +0100 To: , References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> From: Ludwig Seitz Message-ID: <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> Date: Tue, 29 Jan 2019 08:56:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(136003)(39860400002)(2980300002)(189003)(199004)(230700001)(7736002)(2906002)(65806001)(68736007)(22746008)(50466002)(14444005)(53546011)(386003)(31696002)(8936002)(126002)(47776003)(65826007)(305945005)(476003)(53936002)(65956001)(229853002)(8676002)(81156014)(450100002)(81166006)(356004)(478600001)(6246003)(3846002)(186003)(16526019)(336012)(446003)(64126003)(93886005)(6116002)(2616005)(104016004)(26005)(16576012)(22756006)(316002)(11346002)(69596002)(77096007)(23676004)(2486003)(31686004)(33896004)(58126008)(36756003)(106466001)(74482002)(86362001)(44832011)(110136005)(76176011)(106002)(97736004)(486006)(40036005)(67846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0098; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT022; 1:iOWZEkDub4vodtgOVJvTQ28LSIldCerqWWDByBAUq8Njw4OWrdL5AiwiSxD/xRfgKqCTonvKYxo/2XPepnXJKOPpa2RLQQJYuUVJqrg8UbAtfnZ5COpKyAcyBQNvpTYBrcZu3wG/+BmhNI4rgzITsu8Wy/ciCKvGy1z6gSy9Ov8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f5f5c850-bc49-4e23-490f-08d685bf4033 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:AM5P18901MB0098; X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 3:SNqhRoIZuXiooFmSz9iZqhX2offIfr2YwU6GFDSjOSKtWJQoeQrcU1YGYW34e/BGjelyaiPtY5KdbHO3Y4YlS3whMwW3iwfqYWvj9Jx2Mo8NHelt6qcSTijoWLAXm9fubRRM2Tk7hRVpIzF/z1yv4mYZxzs5bO5S0MiinYVj1Z76gbjvrkbmvVeZfuuH2h89NkXQGYQ4fIv0QVt+vI18+JGZ9ZWlrCqU0GLDUoPaNkiYUNVbmQns7cYuR7QQKuFphSAoLjd8qvDw6q8OjGKDI+0+0poYmqxXsNdhdcvASa+yr/sa0DHDSPeMu4fvy0Uq8andoJO1zXGw//3nl8X96z5KHkwPCxRDCADBiCblMT0DQFVy5yYZnVqk+xlnab+/; 25:A35rd7fGrdiozpIU4M3I8zuGB3CxwrwKxGJOxOFCvRhK8YtRw7koCeWuNjXRM9qT39YPSLZnIdOH+GXnqUJcoeAJvh1MsZzM6K2Q3F0rsgLEydl9QU6Y5qQxz6LIj2m7P70fJJGJR6YUV8Z+v0HHFufg2099S1upfndj8tkSp8xsNn/3iyWoLHNeCkMf34DA+OJWLToTc+M4U4aW8CsuOj/lDZWMJmqjG6ZjBr+V1/hOwCqodfk/A+kLhxGVnho9npKRM12fv+RVc8DAJzuRxuMvvHhvQr2kGtvncmbJEhuB8E3HPiauVoEUnyRStwx3j/15MH0Er8X2QtlWt+wRIg== X-MS-TrafficTypeDiagnostic: AM5P18901MB0098: X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 31:bU3k2/jyRh7tKtHLUlZEj+/ApRwUMGzNsKNPc/jABHPR4MB6TPwFfEMOnnG9OqD4Up40rikpgfTTLto3XzzC9lNpY8xKC6+JBXZ9l3XMV/Q0XzZCXSA8UT0ABDhuJt/cYwMJO2JLk33x/vi5pGG0rJ1kHhfJZD27pbhX0Fy1ejIHORiQptlvFGACUkjCHgWzslILyTyXJP76e6Wufl3qBatDzd7VE5iYmYT/dGM+MuM=; 20:HZVbTnK3kZk80XyXOggtAhXvmqxfCwsDsUPXWnLI82TDhN5zKJzaJqQbTdrBZVJTrK8eGGnk7B1LOHYvxhDQpFI77qI9P2xErymFiv+tM2qhzDkjJy37aIGbbzTielfUVnCVoXELxa148jV9AhWSnfXajl23+6wzwG1QtnQysdPkZL6gyB+2ICHltn8hzI5ytYJOHca4WsvEh8p9NU/NJb3Dqmf/F+9OCL80TcQEebcRhhsyv4u0ZKQmc10JvsEl; 4:y9eUTKMLeUNn9gbRo2L7CPMK/zp9U75Czn8mqtvVMao2Z2LdZAmRcO/UHevdTdJCtaCBD8aiFLqxkk3wJVSd156XYiiiPjQ5Vsv08VD7xS8kU9zjFzvsgtpCTde3lmcKZVwg1Qr8hZKMhJHMvqhpbPvWfWxjawUqOULFWK/AmVSleeSbmfTdy18bO07puu3dD3AWiaunf8Heby8TjoVERHTSJAfMidl+N5QJuN4aZbwi1jnMaEOERPOe5Sx1D91z2UbQqM8wRPsJkThk7B/QjhXDnCLSWUDvv8eYpLcGKRs9687wZI4grBz6XlG16o1+ X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 093290AD39 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQMTg5MDFNQjAwOTg7MjM6TU1OLzFWL3dpUkRiUEF3aDg2RTlKdS9V?= =?utf-8?B?ZWxCRE5pa3U5aEpoT3hpakhmMnQycldVQ2ZTS3NhSW4rQm4ydEQxOUtRTGxj?= =?utf-8?B?NFViZ3l2cGJGQkw0Ukw0SnNMK0paeWsvWlZ6TE9zV2hkSUtKNU4yQi84bnlj?= =?utf-8?B?L3dqMDJzVFV5K0M1SE5lekoyUmJ2S3g0VDQxcXljbTNvL1dGU1FHRVNxQ1Fk?= =?utf-8?B?cTMrV0ZscVdjUXo5SmozOXVJMXZsdzR4MURjcS9lMHJNTVFtb0o5N3A5OWNt?= =?utf-8?B?WEM2NHIvRHJSc2YxcXFFc1RRc25IY0o1VUhsV090N3VhQWl2YnBjcm90cm05?= =?utf-8?B?Z1ZnRGJMUDRZVXczcnNUb2s3ZlJ4N0l2SnZpaGE5Wmp3ZlRFZW85SlhqU21a?= =?utf-8?B?T0tDK0lrbEV5TzBvWVorM2V4TzhUb1Q3MVJ6ai9XQlBmYnlFWVFFdzB6clJV?= =?utf-8?B?NEErdFRnZk5UcXpZMlJmOEhBMXVTK1ZKMDIrUG1vZDZmeWZidDhqWjY1QXYx?= =?utf-8?B?YmRsbGE1ZDRMeFo1ZnpNMzh1bldQM093citYWTBMM3VxbHZ3Y0w0RmN5cWgr?= =?utf-8?B?VkNGcDMyWURiMDFhdnAzV1lPc3BjN043QjMzSVpaOVJFWkwzQXdqQk4xQjkv?= =?utf-8?B?aitCenBBZCtmQ0kybE1JdVN4d2h5VHZzWm5HWlkwT2Q0OGJzRWN1NXIrMGRD?= =?utf-8?B?REl5WC9lK1I0QmV6dmMxa2t1QlZDYVErYldmbndqRWFLRW5KVHh4ZkNwQjVp?= =?utf-8?B?blFCTVBSRS84b1VIbmxOUkFCNW1ON1VCTkVvVEtFQ0p6bVZ2T2lFSUhwdVUy?= =?utf-8?B?WFljSTdZbGNwQTBnaDN6VUpmNWc0NC9PSnNJdG1ud1lqSlVBTWtFdW02TGlC?= =?utf-8?B?bGI4a3kxVFJJOEtvN3dUSjQzQUJSdjJkTVNtdUxSWGVUZ3NjY0FtV1ZOc0lv?= =?utf-8?B?N3ZMbXBlZ1hxMEZEc1NncFdFbHBpODNBT0dycjI5L1FIbVcwK21TdURxc2Y0?= =?utf-8?B?dDJjRGU0UFpJcXJlTklvdzFvZjZncjRYbVloeVFCZTQ0Qjc4bkFabEx3Vjdm?= =?utf-8?B?Mjl5OXJjS0w0Wm9kNWJoLzZyU1l0VkY4SlpsMGNDc0NQN0xlZS9YSUREZFpS?= =?utf-8?B?TGUrcWdhZG5uNkdwU2NtN2J4Y3lzOFVmNHI5WjRBTXBLUHY1eVE1OTlXN29E?= =?utf-8?B?bytTbmVZU2J2UXNMUGFnQnZoNCs5M3lyWnRRUlNkL1E4d29XY3hEQjVEMjhV?= =?utf-8?B?V0w1Tjk4bkU4czNOVUU4ZFFyU3d6elo4NVR0Mzlldnpsb0ZWVG1idTFLd3By?= =?utf-8?B?Sk0rZC80ZnRLeUw3MGlSYk5Sa0pLMVRDcHNFYldwMFNHeGwzazN2OW1iU0Rl?= =?utf-8?B?cmlDaTRJOVRvTUpvRDllNXkvWEFSRFNPY0dkZDJYVHFRTElaRzhsaTIzNnBK?= =?utf-8?B?L3N5ekREMzF2UW95eWVBclMwRGFRNHp5VXRnVjZvZHBVMHRaSXJsV1pueDg2?= =?utf-8?B?dFBQcUhKbE1qTWdwU2RxTVNwNUFZQmZZUldiNm16NmJVWWRCaVB5eXZlRVhs?= =?utf-8?B?Nmw0UzN5Ulowb2dMMXpJTk01WkVLV1ErSFdJS3hHUmpkVXlaUnVIbW5YZGsz?= =?utf-8?B?ZW91L285N1l0NEI3anFMaXlBNWt2c2d2SFZ3OEFYRU42NGRRUTJ4SDBIU2c2?= =?utf-8?B?aTE1V2VPZ3plSXpNcTBoeWlCN1VJcGxacmo2eWUyMldCdGkvVmw4ZXpSd1B1?= =?utf-8?B?Q3oyWDZwOGFieXJUeEtKM1Mrd0NlMTRxQ1BiUnNZK2RYWlBUcjdvUi9SMVNE?= =?utf-8?B?dEd6OWxzeG13ZHoxWk1QcThEcUVXWHBZdFJ0bHlOblFBYUxEaExtT3BScDRO?= =?utf-8?B?Z3RJdUZSQTZ3TFphWkZHV2hmcCs3QzJQQXVwSUFSb3pHektubEFNOWUwZGtU?= =?utf-8?B?Y1hqN20yR0JXZDQ4aGRVbnRkZ1NkeFkrcGlhdkw2MS96aGV1d1RhQUVZOVJO?= =?utf-8?B?bGN0eDQ0enBGb2xldGd3UWF1VXQ4QkZqaXpKeC9vbCtmQ3FqVGovWE1uSmlG?= =?utf-8?Q?c2L3fg=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: bMtUKpvuYOMjUMZsaAS/xpNL/nt25d8lW2pRhX4cGDL3KJIWnB71yBfOIRrgEzb5nxKQZSygDYJivez7/O13hIjBmXyMDQDU25JQGm2Mf+mmIXoGjb8IofnY5R7rWWab2sveQnZxF6yoJbTKzJrhjrwgGi64jUkPv3hopqxjvKYaj/zG+XCUqM4D8KZDkeWIAlVJfeEoqDHqlm5y8ycP9zBl2uGt0tWCmoO5D89F2+Au2l4Hrvvy6rwCoo0zU3M88P/RFAb1TfUWdQEEJGZaSeqY1hjrNGkuOcdO81vmhecfXlSE4qLXVrCe7wbWFuH89P0oK0ESbEum77SgjXVMcIg9fMeZFifCKtAJTYWPOxkbYcRaHokRpYp/RnDaLc3OiuEnJha5Gq0Yja6oECfMF4utlIM5eWzL66/QCE0KyJY= X-Microsoft-Exchange-Diagnostics: 1; AM5P18901MB0098; 6:UQ7utAAVtRhQGabiRcJiyFsQzaePUH2yE2AYOft8RLMolEIiv3ZVKLGNNZlpt0/mj//Gi8DX6NPxnoQml+ZWBDmDizTtFLydkol+48IsZXvzdXm8VGjVAeXrLGy+Fc4wjwVT24Lii/NnOpLVaZV4QgAE1UP9tvnyIgAD4NF/w7KenMVQJeMAmQw385g/4cMVbhf0k/lnbbtZYL/YeyNsbiqE7MJRfL5fUGpnkRoNRtCtaDwxvzxSjVxjriJcgQfHMXl4ABGoGjkLv1rehg2YenKGzzyn7fL0S4nk3tnEvmr4VbpIH4PmBTp4U+ZqQKfFTVkApjRRgPwkLQFMlkcwGq75KJVmXA0zmsSzLrlzpw8wUSzRB+gP4XXqxcMYyIFlTRJ44R7c87XlbPDozdismOZQnwNY1WX41i/DW3HLXN8x49dImvDeQiKS5TUevmCZCtD5zKVQACzqnthgedH/Aw==; 5:tJ2iMHemLT6ZrYyOQuyo1jPWDtnM21x1BChr7fzjnGmWsFh+adm/rOITPbD7qtLuJMGWSpw2eK5VjEh17/YVO04Zd34qOMTTx8bj8JUPtX8KEcGVXK8/oiAKYN8fg7RexiDi0TfnEwAkNtvkdAjM9pXKRZkmmAWqfToP8hR3YSxQOv4NqgevpMhC7PJaeliwyKIAw8qb6J0ez32pj7/Y6A==; 7:Ogxi7AMmbLxrP+cdZJh87TSuWR4THucFm05moiRSIOJE6w8Dd97kJuoH3K+ZG9MnjQCpgf2ht1asoeWQPjhPMQty+peDY7F/vZF6BVwNNxXWtiI8njsdJCdFfpb2qJumZWB7SXf02iBNKq4BsBnmrg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2019 07:56:18.0653 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5f5c850-bc49-4e23-490f-08d685bf4033 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0098 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 07:56:24 -0000 On 28/01/2019 23:12, George Fletcher wrote: > I also don't know that this raises to the level of "concern" but I find > the parameter name of "req_aud" odd. Given that the parameter in the > resource-indicators spec is 'resource' why not use a parameter name of > 'audience'. That said, I have not read the thread on the ACE working > group list so there could be very good reasons for the chosen name:) > > I do think that there is a lot of overlap (in most cases) between > 'resource' and 'audience' and having two parameters that cover a lot of > the same semantics is going to be confusing for developers. When calling > an API at a resource server, the 'audience' and the 'resource' are > pretty equivalent. Maybe in other use cases they are distinctly separate? > To give you all the background of "req_aud" from ACE (sorry for the long text): Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token). We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience". Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states: "Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource" My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value. For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource". We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource". Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 From nobody Tue Jan 29 05:15:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12512D4E8 for ; Tue, 29 Jan 2019 05:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 q8FarJeFb677 for ; Tue, 29 Jan 2019 05:15:07 -0800 (PST) Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com [74.6.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82CA12E043 for ; Tue, 29 Jan 2019 05:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1548767706; bh=/GXDzE4L+riIHn7kpgGnDsn4DlQBaHSZ40+rY3eSyJI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Onee/SINUTlfwlrmiakK3vhymOf4/M4D5qWKJ1ZJfUvtdU6yEhqDqIwCB4HjkVWWLplzFyGMp0R2x2ZHI+sTzbgVz0fb7gIiT6nkWjJXce3wr6TD2/PuvbzcuIA98WUNrR/3buaIgc7zY+5qCW5Q+oa1QyTU/Bp58jQyylEA00b2WuP7Yw+nl3oqvx7jQxWKPj4IAiEtaqfTSLhd81dZw6Pk2/dBU5kgobWOMOGMWr7UEyvsiw4jApg9b+L2Y9l05LIWvVU7/e/yrFgYG03sO0Ct9nDH1JhaIrerPS0c8fDJDrOT7JFJBsehht7mjL0czF1R8oehOEAk0f4y+363YA== X-YMail-OSG: _lIGNVkVM1k.iPROOvnnwrIEB4e_XbWGl1.I0T2sikUwsg5dTAo6pK1E0SHqKIV uwmcKlBB05sxspGqe1jhY4DD8ae10p7iiIXgutfD9T2084l8B2Xi1uuKMXlgTwIhOM8bXhQsviqo u5T6_t0K1nRhaDb6aJOWpfjtxEZ.95o8srooznoUA.7StBYClMhNTe.Dyr8Ao3.Mf9YUCZjHE68e 3JWyvTYcwYYwxzxZyexz8ghnrpYdwb1m5Pq.LiC5zlP8ZoCEccYz_1FIP7Qmn1K2BMoAjOyFIwp6 KRtNB3m7wmEwAsg6zAEexL8CsLp6zyxCTBFwEdq6PITwaJ02pCkiiSm2a_QO9rwuepjonqapCXXr TB8OEDrAA5727Twazdn4mHZ9sjeIpaKlVGwaB1CbffmGRlAk0iQCcK1BBFRN86OeJV_QJhYe4RWr L_Kt4mq.dp1dMi0RfLTUFmrMqj.visy7BE1RAORKPpJjaXE2J1sc.ryQeH0hseGp.6AsRPCCyhag iDbN_mgdAJGKHwFpcqwRRcNRZvDvRwDiKDGNdCb09x99ZGmhAc.XaI_4A4yS404U_NZArjEuyU.. 7C_WMykaYesM4Hn72x1ILdxMRCGQ67_B_6FqgcTGrRsCcqsEU.95dCXR.KBtiSAoKuCMwXWo7gCl frTTFnlF27nRKCdqvr_b5drltaesjI.4QDmi6JL29X8PSZfUGaeeExMxp9kObJEVOmAcvtfCstJb btTnOMvCULj88cVD1.BkKJdBv2DMrbzqyMBsiwqedk84OpSEbE7YJrNsGVMQt9GqAN0mKtw.UfX5 d4L1a38v70hSFLRM3iAzpuYiaH9pnmfKcRYq1px1IYyOu.NC0AbUNAV2MVJVwNix9zHLlH6xc.1M jkjI_uMr8XzfoBwx.1ax12mcBffJ7Udli6FejNc8DzjmGVy3L4LdO0HiudZ130ZjWsvUGysX6gQ9 .N8kDcbJ1LEY6YuixkmvZ.qvhVCLemzI7toUO_HrMZNO3oDCwfYavde6OcfsdDxiWyfKSoxG3hZk WlYteZyxVn8.z6X18paMCBjcui7jVQNT.zCCtNvKiguNfDWQ0eGoBBPfOOLh_iVI6vw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 Jan 2019 13:15:06 +0000 Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.138.233]) ([184.165.8.97]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 759dc410db180f06b2e23284340785dc; Tue, 29 Jan 2019 13:15:02 +0000 (UTC) To: Ludwig Seitz , ace@ietf.org, oauth@ietf.org References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 29 Jan 2019 08:15:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> Content-Type: multipart/alternative; boundary="------------735FC6F53AF1B8CBF59CD64C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 13:15:10 -0000 This is a multi-part message in MIME format. --------------735FC6F53AF1B8CBF59CD64C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you so much for the background! I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email. resource=urn:x-mydevices:temperatureSensorGroup4711 The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. Another example, for an API like SCIM [RFC7644 ] that has multiple endpoints such as "https://apps.example.com/scim/Users", "https://apps.example.com/scim/Groups", and "https://apps.example.com/scim/Schemas" The client would use "https://apps.example.com/scim/" as the resource so that the issued access token is valid for all the endpoints of the SCIM API. Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:) Thanks, George [1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 On 1/29/19 2:56 AM, Ludwig Seitz wrote: > On 28/01/2019 23:12, George Fletcher wrote: >> I also don't know that this raises to the level of "concern" but I >> find the parameter name of "req_aud" odd. Given that the parameter in >> the resource-indicators spec is 'resource' why not use a parameter >> name of 'audience'. That said, I have not read the thread on the ACE >> working group list so there could be very good reasons for the chosen >> name:) >> >> I do think that there is a lot of overlap (in most cases) between >> 'resource' and 'audience' and having two parameters that cover a lot >> of the same semantics is going to be confusing for developers. When >> calling an API at a resource server, the 'audience' and the >> 'resource' are pretty equivalent. Maybe in other use cases they are >> distinctly separate? >> > > To give you all the background of "req_aud" from ACE (sorry for the > long text): > > Originally in ACE we had defined the "aud" parameter for requests to > the token endpoint with the semantics that the client was requesting a > token for a certain audience (i.e. requesting that the AS copy the > "aud" parameter value into the "aud" claim value of the token). > We were then told that this collided with a use of "aud" in OAuth, > that specifies the intended audience of Authorization Servers (if I > remember correctly), so we decided to rename our parameter to > "req_aud" for "requested audience". > Mike Jones then made us aware of the work on resource indicators, but > upon closer examination I found the "resource" parameter to be more > limited than the "req_aud", since resource specifically states: > > "Its value MUST be an absolute URI ... the "resource" parameter URI > value is an identifier representing the identity of the resource" > > My interpretation of this is that "resource" refers to a single > resource, which is more constrained than the definition of the "aud" > claim from 7519, which uses a StringOrURI value.  For example my > intent was to use "aud" and "req_aud" for group identifiers > ("temperatureSensorGroup4711") and other non-uri strings > (hash-of-public-key), which I cannot do with "resource". We therefore > decided to keep the "req_aud" parameter in > draft-ietf-ace-oauth-params, even though is clearly overlaps with > "resource". > > Any comments and suggestions about that line of reasoning (especially > from the OAuth point of view) are very welcome. > > /Ludwig > > -- Identity Standards Architect Verizon Media Work: george.fletcher@oath.com Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------735FC6F53AF1B8CBF59CD64C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. 
Another example, for an API like SCIM [RFC7644] that has
   multiple endpoints such as "https://apps.example.com/scim/Users",
   "https://apps.example.com/scim/Groups", and
   "https://apps.example.com/scim/Schemas" The client would use
   "https://apps.example.com/scim/" as the resource so that the issued
   access token is valid for all the endpoints of the SCIM API.
Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:
On 28/01/2019 23:12, George Fletcher wrote:
I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?


To give you all the background of "req_aud" from ACE (sorry for the long text):

Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience".
Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value.  For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource".  We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource".

Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome.

/Ludwig 



-- 
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------735FC6F53AF1B8CBF59CD64C-- From nobody Tue Jan 29 15:50:31 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B162C13104B; Tue, 29 Jan 2019 15:50:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <154880582967.7633.3453518872821082050@ietfa.amsl.com> Date: Tue, 29 Jan 2019 15:50:29 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 23:50:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-00.txt Pages : 14 Date : 2019-01-29 Abstract: OAuth 2.0 authorization requests from apps running entirely in a browser are unable to use a Client Secret during the process, since they have no way to keep a secret confidential. This specification details the security considerations that must be taken into account when developing browser-based applications, as well as best practices for how they can securely implement OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 31 07:50:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D08126BED for ; Thu, 31 Jan 2019 07:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 0Q3oXc8gOtcg for ; Thu, 31 Jan 2019 07:50:22 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EF7123FFD for ; Thu, 31 Jan 2019 07:50:21 -0800 (PST) Received: from [84.158.236.227] (helo=[192.168.71.126]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gpEbX-0005PZ-Co; Thu, 31 Jan 2019 16:50:15 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-45F9AA3F-ACFD-460C-ADAB-2328E92C44EA; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16C50) In-Reply-To: <0BF3B521-FD75-456F-8D67-48F1B7FAE43A@oracle.com> Date: Thu, 31 Jan 2019 16:50:16 +0100 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <86202980-FDD7-4079-806D-C46A2D7FDB02@lodderstedt.net> References: <0BF3B521-FD75-456F-8D67-48F1B7FAE43A@oracle.com> To: Phil Hunt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] comment on security topics-11 - refresh authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 15:50:26 -0000 --Apple-Mail-45F9AA3F-ACFD-460C-ADAB-2328E92C44EA Content-Type: multipart/alternative; boundary=Apple-Mail-CA7806CF-1C14-4B68-B3EF-D87D952E2449 Content-Transfer-Encoding: 7bit --Apple-Mail-CA7806CF-1C14-4B68-B3EF-D87D952E2449 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phil, > Am 16.01.2019 um 00:38 schrieb Phil Hunt : >=20 > I have had a couple reviewers comment whether this means client authentica= tion is optional in Sec 3.12 for token refresh: >=20 >> * authentication of this client_id during token refresh, if >> possible, and This just cites RFC 6749, where authentication for refresh is not required i= f not possible, I.e. refresh for public clients is unauthenticated. > Do we not mean authentication of the client or some equivalent (e.g. looki= ng at browser cookies). The BCP goes beyond RFC 6749 by expecting the AS bind refresh tokens to a ce= rtain instance of a public client. Pls. see=20 =E2=80=9EAuthorization server MUST utilize one of the methods listed below t= o detect refresh token replay for public clients:=E2=80=9C ... kind regards, Torsten. >=20 > Phil >=20 > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 --Apple-Mail-CA7806CF-1C14-4B68-B3EF-D87D952E2449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

Am 16.01.2019 um 00:38 schrieb Phil Hunt <phil.hunt@oracle.com>:

I have had a couple reviewers comment whether th= is means client authentication is optional in Sec 3.12 for token refresh:
   *  authentication of this client_id during t=
oken refresh, if
      possible, and

<= /div>

This just cites RFC 6749, where authe= ntication for refresh is not required if not possible, I.e.  refresh fo= r public clients is unauthenticated.

Do we not mean authentication of t= he client or some equivalent (e.g. looking at browser cookies).
<= /div>

The BCP goes beyond RFC 6749 by expecting t= he AS bind refresh tokens to a certain instance of a public client. Pls. see=  

=E2=80=9EAuthorization s=
erver MUST utilize one of the methods listed below to
   detect refresh token replay for public clients:=E2=80=9C

...

kind regards,
Torsten.




Phil

Oracle Corporation, Cloud=
 Security and Identity Architect
@independentid
www.indepe=
ndentid.com
phil.hunt@oracle.com
= --Apple-Mail-CA7806CF-1C14-4B68-B3EF-D87D952E2449-- --Apple-Mail-45F9AA3F-ACFD-460C-ADAB-2328E92C44EA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCnQw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBTowggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0G CSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0x ODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSm v9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+pUy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7 P3GcYleN1waJRH981U81XzH2clCg9+YRnIUpvof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UO VblWAeQvGCvsV2TlPNCOXOtphvG137/0s048LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5 sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btpWfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb 2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCCAekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCB iwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA67MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZby CyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQkoKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/u U092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0n NI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQb k4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJeQ0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggPJ MIIDxQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwDQYJYIZIAWUDBAIBBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE5MDEzMTE1NTAxNlowLwYJKoZIhvcNAQkEMSIEIGHDBToWD8VjUVNH rgjrHc9oLDtQCPdn1f2IxWjbuYiiMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQCg91sKnuuerYbZ7A2o0ps9VSUDGw7PNt+NPY+C XUqesO0m/f4MhWEqcSnyhSaORa0MPFY9S3lJplsz/08SOSFTY6ANwXKCXTTuDC/si64JLOzW0Os3 lyW60gh1xnN2gROp1rHoxCSakypMlC1FSDHZ/QfYXMqkYQTNCr/+s6Kpsr06sIx30am7qdNQArca TJkewiTc1pCvRvUmAGJKPQzwya48IKgLJuMUHzde1NBInMUU0jerUNdbZgqb+ifvtHcmMmIwMMJq fv6pNLsfRDbLWOV6/FrOZUiY4WYq//u3duE0YDIj+knKaXpm2ieb4MpndIviH+ny7q6G1Ax3pYKc AAAAAAAA --Apple-Mail-45F9AA3F-ACFD-460C-ADAB-2328E92C44EA--