[OAUTH-WG] Re: Opsdir last call review of draft-ietf-oauth-resource-metadata-08

"Wubo (lana)" <lana.wubo@huawei.com> Sat, 14 September 2024 10:27 UTC

Return-Path: <lana.wubo@huawei.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 4A707C1519BA; Sat, 14 Sep 2024 03:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 qvlMntWO-bNz; Sat, 14 Sep 2024 03:27:19 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1D8C14F5F2; Sat, 14 Sep 2024 03:27:19 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4X5S1z1Q3kz67nbs; Sat, 14 Sep 2024 18:23:35 +0800 (CST)
Received: from lhrpeml100003.china.huawei.com (unknown [7.191.160.210]) by mail.maildlp.com (Postfix) with ESMTPS id 8ACBE1400DD; Sat, 14 Sep 2024 18:27:16 +0800 (CST)
Received: from kwepemg500005.china.huawei.com (7.202.181.42) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sat, 14 Sep 2024 11:27:15 +0100
Received: from kwepemd500012.china.huawei.com (7.221.188.25) by kwepemg500005.china.huawei.com (7.202.181.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 14 Sep 2024 18:27:13 +0800
Received: from kwepemd500012.china.huawei.com ([7.221.188.25]) by kwepemd500012.china.huawei.com ([7.221.188.25]) with mapi id 15.02.1258.034; Sat, 14 Sep 2024 18:27:13 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Michael Jones <michael_b_jones@hotmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-oauth-resource-metadata-08
Thread-Index: AQHa+hJmOkXDd+LTj0GlyBMBXBmFFrJR380wgAFp21CAAzqFMIAAo+3Q
Date: Sat, 14 Sep 2024 10:27:13 +0000
Message-ID: <c719ec8c5fa3420a857d95038f6ce9cf@huawei.com>
References: <172493598435.69923.1519783976733419021@dt-datatracker-68b7b78cf9-q8rsp> <SJ0PR02MB743976BC0D1849638E4769FBB79B2@SJ0PR02MB7439.namprd02.prod.outlook.com> <SJ0PR02MB743924F507AD1B1915B9AD24B79B2@SJ0PR02MB7439.namprd02.prod.outlook.com> <SJ0PR02MB7439D383C8ADA42759D078A4B7662@SJ0PR02MB7439.namprd02.prod.outlook.com>
In-Reply-To: <SJ0PR02MB7439D383C8ADA42759D078A4B7662@SJ0PR02MB7439.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.114.167]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: 4H4RVB2XSJA2D5RQSWHP4PCVQATPOPK6
X-Message-ID-Hash: 4H4RVB2XSJA2D5RQSWHP4PCVQATPOPK6
X-MailFrom: lana.wubo@huawei.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.all@ietf.org" <draft-ietf-oauth-resource-metadata.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, Qin Wu <bill.wu@huawei.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Opsdir last call review of draft-ietf-oauth-resource-metadata-08
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xgJQeaw1VtNn3Qn4vw3-7icFmUo>
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 Mike,

Thanks for addressing my comments. I have review the new version and it looks good to me.

Regards,
Bo

-----Original Message-----
From: Michael Jones <michael_b_jones@hotmail.com> 
Sent: Saturday, September 14, 2024 8:23 AM
To: Wubo (lana) <lana.wubo@huawei.com>; ops-dir@ietf.org
Cc: draft-ietf-oauth-resource-metadata.all@ietf.org; last-call@ietf.org; oauth@ietf.org; Deb Cooley <debcooley1@gmail.com>
Subject: RE: Opsdir last call review of draft-ietf-oauth-resource-metadata-08

Bo, the newly published version of https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ incorporates the changes to address your review comments.

                                Thanks again!
                                -- Mike

-----Original Message-----
From: Michael Jones
Sent: Wednesday, September 11, 2024 4:07 PM
To: Bo Wu <lana.wubo@huawei.com>; ops-dir@ietf.org
Cc: draft-ietf-oauth-resource-metadata.all@ietf.org; last-call@ietf.org; oauth@ietf.org; Deb Cooley <debcooley1@gmail.com>
Subject: RE: Opsdir last call review of draft-ietf-oauth-resource-metadata-08

Bo, your review comments are addressed in https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51/commits/699182c7c4d6c4e06e99c1463ae51a18cc64f4fa, which is part of https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51, and https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/commit/fe6fd613eae34e3c63acbec340d21de21a3a1176, which adds sequence numbers to the diagram.

                                Thanks again!
                                -- Mike

-----Original Message-----
From: Michael Jones <michael_b_jones@hotmail.com>
Sent: Tuesday, September 10, 2024 7:26 PM
To: Bo Wu <lana.wubo@huawei.com>; ops-dir@ietf.org
Cc: draft-ietf-oauth-resource-metadata.all@ietf.org; last-call@ietf.org; oauth@ietf.org; Deb Cooley <debcooley1@gmail.com>
Subject: RE: Opsdir last call review of draft-ietf-oauth-resource-metadata-08

Thanks for your review, Bo.  My replies are inline below, prefixed by "Mike>".

-----Original Message-----
From: Bo Wu via Datatracker <noreply@ietf.org>
Sent: Thursday, August 29, 2024 5:53 AM
To: ops-dir@ietf.org
Cc: draft-ietf-oauth-resource-metadata.all@ietf.org; last-call@ietf.org; oauth@ietf.org
Subject: Opsdir last call review of draft-ietf-oauth-resource-metadata-08

Reviewer: Bo Wu
Review result: Has Nits

Hi,

I'm the assigned Ops reviewer. I think this document is ready with nits.

Here are some nits and questions:

nits:

1)
The Figure 1 Sequence Diagram does not seem to match the text in the steps.
For example, step 5 in the diagram corresponds to step 5 and the first half of step 6 in the text description, and there is no "user agent" (step 8) in the diagram. Therefore, it is recommended that sequence numbers be added to the diagram.

Mike> I'll plan to work with Aaron Parecki to add numbers to the diagram, if possible.  (It may be tricky, because there are both SVG https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#name-sequence-diagram and ASCII ART https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-08.txt versions of the diagram.)  This issue is tracked at https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/issues/49.

2)
s/The resource value returned/The "resource" value returned

Mike> In both cases, the word "resource" is in a fixed-width font as a result of denoting it as <spanx style="verb">resource</spanx> in the XML source (which will be transformed to <tt>resource</tt> in the XML2RFC v3 source) to mark it as being a protocol element.  In xml2rfc v1 this would have resulted a fixed width font in the HTML output and "resource" in the .txt output, but the newer tooling omits the double quotes in the .txt output for some reason.  I'm prone to go with the choices made by the IETF's tooling and not manually add the double quotes.

3)
s/specific member names such as resource/specific member names such as "resource"

Mike> Same situation.  "resource" here is already in a fixed-width font because its source is <spanx style="verb">resource</spanx>.

Some questions:

1)

Section 1 Introduction

 The metadata for a protected resource is retrieved from a well-known
   location as a JSON [RFC8259] document, which declares information
   about its capabilities and optionally, its relationships to other
   services.

Do other services refer to authorization servers? If yes, then it is recommended to use authorization servers directly.

Mike> Yes, the metadata for Authorization Servers is also retrieved from a well-known URL, as described at https://www.rfc-editor.org/rfc/rfc8414.html#section-3.  This specification follows that pattern.  The "authorization_servers" value is a set of AS issuer identifiers, as defined in RFC 8414.  That enables retrieving their metadata in that way.

2)
Section 1 Introduction

The means by which the client obtains the location of the protected resource is out of scope. In some cases, the location may be manually configured into the client.

In Section 5.3, there is also text:

   This specification is intended to be deployed in scenarios where the
   client has no prior knowledge about the resource server,

It seems that text in Introduction means that the resource server is prior knowledge of the client if I understand correctly. Am I correct?

Mike> Actually, the client may learn about the resource server at runtime as a result of user interface actions by the person using the client.  The client might be, for instance, an e-mail reader and the resource might be an e-mail server.  The client can be pointed at any of thousands of e-mail servers worldwide, which would be the resources.

Aaron Parecki did a good job explaining that motivating use case several IETFs ago.  I'll try to dig that up and we'll consider describing it in the draft.

3)

 Section 1.2. Terminology

 Resource Identifier:

The Protected resource's resource identifier, which is a URL that uses the https scheme and has no query or fragment components.
Protected resource metadata is published at a .well-known location [RFC8615] derived from this resource identifier, as described in Section 3.

resource
REQUIRED. The protected resource's resource identifier, which is a URL that uses the https scheme and has no query or fragment components. Using these well-known resources is described in Section 3.

The two descriptions look almost same. Perhaps the reference of the definition can be used, for example:

 Resource Identifier:
The Protected resource's resource identifier, which is a URL (see Section 2).

Mike> I agree that adding the reference makes sense.

4)

Section 5.3 Client Identifier and Client Authentication

There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client Registration [RFC7591] to register the client prior to initiating the authorization flow. Future extensions might define alternatives, such as using URLs to identify clients.

On “Future extensions",does this mean the extensions of RFC 7591?

Mike> Good point.  We mean future extensions to OAuth.  I'll clarify in the draft.

Thanks,
Bo Wu

Thanks again for your useful review!

                                -- Mike