[OAUTH-WG] Re: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

Michael Jones <michael_b_jones@hotmail.com> Thu, 03 October 2024 17:37 UTC

Return-Path: <michael_b_jones@hotmail.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 C792FC1D4A75; Thu, 3 Oct 2024 10:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izle3WQCFXHm; Thu, 3 Oct 2024 10:37:31 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02olkn2085.outbound.protection.outlook.com [40.92.44.85]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899FEC14F6A2; Thu, 3 Oct 2024 10:37:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wuOpJco9Fi02W/H/ikXpB5uNM0hY0GhdcjkdZlAmjLGlcJ3wKDFjwgtwpJTL4P3dE394UXqmXv6+NL33416kDVkk67RfWu+XaopLYysygzgUweRxO/Dqzud/m6QB2Gt5j8/B5BHQ1EMGOdUVw6spZQ2n5zXiMdPzSn5Ig2V1fyhq58MI1GXcBBDq1RKj/rA8fybRqF+goH8Fri4A+qnmtbbJkww+KJRmLNgyAoTx+t7ihUKXjqGwk3Hel8zakGi1Dn0GbDdlUMgrNTngp7secPAjxGM9pWzfbbeF+AdJDSE6pA44jgwg1z+GbVuvcXcuASpU3xO5Bngx6tZ83O+QAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XfP2jqPiqeJx0duL66HuwBHSoFLD3bIg44znnTmw6Ws=; b=XkHKmHnhiIv0UmQiT3CMzySWqQGR5F7hRfDPNAuBbyCyOEYT5owRulHi35Cr680ImASvlMBzVgU31AJs3clp7ZZqLU151pBc4lVAreEu3YDXDwmVBSfYke8f2J1SGSS6omTQULIOb+lNeMr+tsY17AyA9XK/1DVIgfjt84bYJBeVAy8lj5p5hjsUAUH1sKpFv9gwejTg84Sad+97G/oXkduCO8iAO3EgPcVboYw4QjBH18JC9QaZTBSsg1ruHjdmVcVWGY2FepxFQPuK2jnRsAfk2U2W4PGJvtpnWBEjTX3sTTRXl77ekykng8aXzpArLIPKa+IhD9N4qtinlnlQKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XfP2jqPiqeJx0duL66HuwBHSoFLD3bIg44znnTmw6Ws=; b=ls4KxjNQ6tgkVWMSD9y+UAXXbFWP5jVMF+TH9B7RCb1f2m/jmDC2VRBC1Vjf7fpTqtyhCzmtBl+CwPAaXBNKszUdaHqOCVINDWWRwLW6iA0+1/IULHT4u0Lc0twNe/XSbfzogmo1hsXIvtdp4YiXM6WIlNC7l+h9zE4ap6g2Skj/FU6q13ZI3urEA4CL20QBtEiL1jsfqeB4wdevXKIDKk0N0ahu4IAhMA68+rMFfpYqNkQgeAXyyYy6FdqgAqXQIFBCuv7OhSjgo5IAbGmkekKLtjLepZhjgmVHcg4l5/pkmm642A17SdUQ0dhsfy747x6yLCz7nMQ8KGudfz0Wyg==
Received: from SJ0PR02MB7439.namprd02.prod.outlook.com (2603:10b6:a03:295::14) by CH3PR02MB9809.namprd02.prod.outlook.com (2603:10b6:610:17d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.18; Thu, 3 Oct 2024 17:37:29 +0000
Received: from SJ0PR02MB7439.namprd02.prod.outlook.com ([fe80::6394:e79c:c32a:4c6a]) by SJ0PR02MB7439.namprd02.prod.outlook.com ([fe80::6394:e79c:c32a:4c6a%3]) with mapi id 15.20.8026.016; Thu, 3 Oct 2024 17:37:28 +0000
From: Michael Jones <michael_b_jones@hotmail.com>
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
Thread-Topic: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)
Thread-Index: AQHbFVLmTBf0uJViz06wt3Klgcr3/rJ0gIHggADJW1A=
Date: Thu, 03 Oct 2024 17:37:28 +0000
Message-ID: <SJ0PR02MB74390EF4E62A369E16A40F96B7712@SJ0PR02MB7439.namprd02.prod.outlook.com>
References: <172793236988.1105259.6830337518090622561@dt-datatracker-7bbd96684-zjf54> <PH0PR02MB743070CC3DFE361611BC1BD7B7712@PH0PR02MB7430.namprd02.prod.outlook.com>
In-Reply-To: <PH0PR02MB743070CC3DFE361611BC1BD7B7712@PH0PR02MB7430.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SJ0PR02MB7439:EE_|CH3PR02MB9809:EE_
x-ms-office365-filtering-correlation-id: f886fcea-1ee5-4920-8c22-08dce3d20d7b
x-microsoft-antispam: BCL:0;ARA:14566002|7092599003|8060799006|19110799003|15080799006|461199028|8062599003|102099032|1602099012|10035399004|4302099013|440099028|3412199025;
x-microsoft-antispam-message-info: 53MbZBfBUMONPoRIxeleUArY47chO3+XqV7OFSkQlt7emD/QNCzt2QYHdTT0P4DwW2lIOuPqDuSu+XpL3Z0dJE+2eKEbdrHu0NA1cC3kjXk3sjKfFKVf3ISj3prYvVaBJOjnJDnKbVsMvnYKod34ytjP0N37DxtdH11NnUANDT4U6+JfQH6ZMoGKbOHaRUp5zVGgkxN+/wFKweLhatyC8N/47jZIYG9J/w7d8zxNDKWzqvO1bUKPSEywyOTK5Q+u3uUJhwLqQqAK0XCsM6Zo60pYgA80ToQ1FaGWSguOS61eHDR0jB2gg7IwPOvtNY+y49sD9HWA6RYCsP7UkOBgo1eAY/GB9zfKZCKkKpnDUYjzLKQKQ8y+XWdaSJARwpUk2AuFEqQsTqxQP06nVvRII0ZBlRW7ZJAJ5DEnZD4GOaN6Ml6IMw3M3PK+cs23gTELP3Z5ushhqjPMgt0+AAUT3SJr+EevUinSyDKQx4oQubLQmFfzaSdH2OvRyg4HWixL+5okYpWxWmqo/efFBV1gmniDbDiLHlxZl64U2z9GNCmL+fgJd+pzXySZhbUFMbJBjGdGXhdCPAgfgVUnO40kTYqg5JzdV5ghDZRvc/qmItdlQZFiN11HTZlI19c0eegzqkjzwZYqjzG3C6Vgxx9kFjFroa++A5/kALbAg00bVy+rqv9xgsDro2aSxnDxvhgQG7l67rqrWbLUUZiulYNpqP/vav/dhqbgLvHOmmn2JBhjNCK6qMcIJEOa/eDrTHZdTgJcwcMRsXERd8uuzLlygITu8CfgtuJ3QWlkelrGun9KJVPtZ8nT2Wyuv8luMOk2OXB1tRr9fo7Z8zuQYSTwfzkvu/yYr8V77sxSeF+ryTvdCj0OX1T/CcAxplTCPIoW
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: U6B5EZEPhVYjwaWzCIkQ6Tfm8U/EPKb3Ouwy0hSVye5Gk//2/prOhr7qjhQfP8zFCOr0QB1i1qtAzC5DRd2mM10zg3F9bZjn+/uuv2PYF/ib6oHAoP5+9+NThOAxwm6zKbYzxstrz+T43V1FySr+NrmhoDBC6fVRa1USMZ/0d1hZFyu26Y3WJwN+uIRqIzSjXST0HTIlfxtk5paI6cYYHBBn5k7nTmQSMcogvU/DqsD2KtqG789FGSxRD4hxRa4ssCmTMG6z/gENEd/0q6FSXYh+YUkRuMnYpgiNKLa9A4HV+pTGhYrU+JV7vy9sfzJl5MakFqRLbyxgP3endtwCRSMOT1CXTEo2r3F5sRl7HPahkRUUk+Tf5sJ4YdEggmAsc1SDsXjpL+Jb/5WpkoYsOKBtSyOYgs2MGDi/iTW9PUyOA671IrDKNHm6HNOobINiio6mRVqOunX+kI5aJ9Qi6wJQZ6qSTDEzu6cmgIvMmGpFKNa4sXDC2QgjkC2a5lvrd0TRrA1jvz9o8lpKCZ9vPcT/5sLLEWMM/mvRqvNf9xQDOCYaTwB7pAen15nuWVqZtBLyyBOjdwMcnV2UsIALpfgnw+lIw3DcEyKksJXB7wwsr16pY2xoy7KPOAN3mgUzbNgw2jdIsNfag1ukbC38qe8fe57wObbgEzxeQjyfRYES3zmzSYwtF3kNgwgfZ78xr78OknSB8k238ieet7WDBUt3Anna483Ho6G2QcSBtVF+48h4tHLuJTX2Bg2L3oDapca4mowz4eWLw/+zkQ/S2LVbmih9HbVyV1VIdEjt1ONc7XcyOU8VGglsQRiP7BPG0lsoxnOfDc5J9J6cxaIZeaCPq46wxPiMMfXmFCFMhT398eokppIiWy6+tbpBexdCZzJMm+nhtse0TNQBVF4apVXjxq4S3JyCGjJeZ3ax8+05QKzhVPchlfxiO5HvPR63npL2gN6xYxwmI9Y+ZUXdO8cltHWvcfNn8YnChl5URoeqTe/9BhSSf8w0j21CiPtd5M/ZIKB0Ma83xBu3jTQRbsWXS1tILh+oRtgJ+ui7N88J5gZNRarmGYloHwyTZ9JkoP96d/J70/FOAAQ1oN/umV9Qk3+/w26EWKr+ngCCGgdKARskRfjFaLFRWcONRDyqW5vKrZCJGVDf9yE7dKOneeRQMbVIsc/tPnaolq2GlDO57EUkndJ4zVgf9f0iTZlIlGw/kwDHscLti6HBCLl2Wg6mNhPlKYGSh0EBD8cludDNGEXJSGt+YnRbqiS9B5n+H/id3uYH6XqKX/oKgxRYzfPwaAVICIVvlhag6hGYJJAx2x8oT84v0cXw8wqTeLDu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-3d941.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB7439.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f886fcea-1ee5-4920-8c22-08dce3d20d7b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2024 17:37:28.8105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR02MB9809
Message-ID-Hash: DXIJGWOHHW5DOCMJXV4CGCZAWEMVJNB7
X-Message-ID-Hash: DXIJGWOHHW5DOCMJXV4CGCZAWEMVJNB7
X-MailFrom: michael_b_jones@hotmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-ietf-oauth-resource-metadata@ietf.org" <draft-ietf-oauth-resource-metadata@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [OAUTH-WG] Re: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PzSQnQkuu2RCD4GQlMIKAmO99kQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hi Murray,

The IANA registration procedure language was updated in https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-12.html as discussed on today's IESG telechat and per Deb's suggestions to me.  It now says:

"The IANA escalation process is followed when the Designated Experts are not responsive within 14 days."

I also acknowledged the additional reviewers.

Thanks all for your useful feedback on the draft!

                                -- Mike

P.S.  I look forward to participating in the proposed working group on IANA procedures.  Is there a draft charter I can review?

-----Original Message-----
From: Michael Jones
Sent: Wednesday, October 2, 2024 11:01 PM
To: Murray Kucherawy <superuser@gmail.com>; The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-resource-metadata@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org; rifaat.s.ietf@gmail.com
Subject: RE: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

Hi Murray.  Thanks for taking the time to review the draft.  My responses are inline below, prefixed by "Mike>".

-----Original Message-----
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
Sent: Wednesday, October 2, 2024 10:13 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-resource-metadata@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org; rifaat.s.ietf@gmail.com
Subject: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-resource-metadata-11: Discuss

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


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I concur strongly enough with John Scudder's comment about the IANA registry that I'd like to discuss it.  Moreover, Section 4 of BCP 26 says:

   [...]  Newly minted policies,
   including ones that combine the elements of procedures associated
   with these terms in novel ways, may be used if none of these policies
   are suitable; it will help the review process if an explanation is
   included as to why that is the case.

Is that explanation available anywhere?  I think John's right, this is a peculiar loophole, and it would be helpful to know why the WG thinks this is necessary.  There's already a debate in progress about whether an I-D (which
expires) is viable in a Specification Required registry, and we're about to charter a WG to revise BCP 26, so this is actually quite topical.

Mike> The explanation for the OAuth registration language is that we want to give authors of specifications proposing to register OAuth parameters the benefit of review by designated experts *before* the spec is completely done, so that if problems are found, they can iterate and fix them before making their specifications final.  I've been in many situations, both as the party registering and as the Designated Expert, where this pre-final review was priceless and resulted in improvements in the specification.  I'd be open to different (possibly more standard) language that still achieves this possibility.

Mike> For what it's worth, remember too that this language was written before RFC 8126 was.  If there's a more modern equivalent you can suggest, I'm all for it.

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

On the flipside, I appreciate that so much good guidance was given to the Designated Experts and even to us on how we should go about selecting them.  It would be helpful if candidates could be nominated (if that hasn't already
happened) for approval by the IESG.

Mike> Deb and I have discussed some possible good candidates.

As rendered on the datatracker's HTML page, the numerous initial entries in Section 8.1.2 are all run together.  Could we get them separated?

Mike> The rendering at
Mike> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata
Mike> -11.html#name-initial-registry-contents has extra vertical space
Mike> between the entries.  The rendering at
Mike> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata
Mike> -11.txt also has a blank line between the entries.  What rendering
Mike> are you viewing?  (I can work with the RFC Editor to make sure the
Mike> visuals are good if I know where the problem rendering is.)

In Section 2, why is "resource_name" only RECOMMENDED?

Mike> Neither of the other OAuth metadata specs require a human-readable name.  "client_name" is RECOMMENDED at https://www.rfc-editor.org/rfc/rfc7591.html#section-2.  "service_documentation" is OPTIONAL at https://www.rfc-editor.org/rfc/rfc8414.html#section-2.  Consistency led me to the same treatment here.  Also, remember that the metadata is primarily for machine consumption - not human consumption.

In Section 2.1, second paragraph, the RECOMMENDED and SHOULD seem bare to me.
Why would we allow anything other than what's specified, especially since BCP
47 prescribes a particular behavior?

Mike> This is exactly the same language as used for OAuth Client metadata at https://www.rfc-editor.org/rfc/rfc7591.html#section-2.2.  Since this spec is entering the same OAuth ecosystem, I'm reluctant to make it different in any way.

Mike> I look forward to hearing back from you, particularly about the IANA registration goals and language.

                                Best wishes,
                                -- Mike