Hi Atul,
I’ve created
https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/23
addressing many of your comments. Dispositions of all the comments are
described inline below.
Thanks again,
-- Mike
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Atul Tulshibagwale
Sent: Wednesday, March 27, 2024 12:01 PM
To: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Hi all,
I'd committed to reviewing the draft at IETF 119, so here is my feedback up to
section 3.1:
1. Section 1: The sentence "Each protected resource publishing metadata
about itself makes its own metadata document available at a well-known location
rooted at the protect resource's URL, even when the resource server implements
multiple protected resources." has two issues:
* Typo: "protected resource's URL" instead of "protect resource's URL"
Corrected
* This contradicts the statement in section 3, which states the
"well-known" should be inserted between the host and path components
Corrected
1. Section 1: The sentence "The means by which the client obtains the
location of the protected resource metadata document is out of scope" conflicts
with Section 3, which says "Protected resources MUST make ... (it) available at
a path ...".
This was actually about locating the resource – not its metadata. Corrected.
1. Section 2, "authorization_servers": since this is normative language,
instead of saying "Protected resources MAY choose not to advertise some
supported authorization servers even when this parameter is used.", should we
say "the list of OAuth authorization servers MAY be a subset of the
authorization servers supported by the protected resource."
The “MAY choose not to advertise” language comes from RFC 8414 (OAuth 2.0
Authorization Server Metadata), where it is used in the “scopes_supported”
description. It’s likewise used in this specification’s “scopes_supported”
description and the “authorization_servers” description. I’m reluctant to use
different language than RFC 8414 does for expressing the same concept unless
you believe the current language is in some way factually wrong.
1. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path
suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit
confusing. Should it say something like "If not using the default well-known
URI, such URI path suffix MUST be registered..." This last sentence of
paragraph 1 can actually be dropped, and the first sentence in the 2nd
paragraph can be updated to refer to the IANA well-known registry.
This language comes from RFC 8414 and therefore I’m reluctant to change it.
1. Section 3, paragraph 2: The first sentence should capitalize "MAY" in
"...application-specific ways may define and register..."
Corrected
1. Section 3, paragraph 2: The first sentence can drop the word "used" here:
"...URI path suffixes used to publish..." The sentence will make more sense
with that word dropped.
Corrected
1. Section 3, paragraph 2: The last sentence is additional non-normative
language, and could be removed, or could be moved to the "IANA Considerations"
section
Again, this parallels language in RFC 8414.
1. Section 3, paragraph 3: "...specify what well-known URI string..." should
be changed to "...specify what well-known URI path-suffix..."
Corrected. Note that the correction also makes the language parallel to the
corresponding language RFC 8414.
1. Section 3, paragraph 3: Instead of saying "...publish its metadata at
multiple well-known locations'', should we say "...publish its metadata using
multiple well-known path-suffixes''?
Again, this parallels language in RFC 8414.
1. Section 3.1, last paragraph: The sentence "This is required in some
multi-tenant hosting configurations" may be removed as it is not the only
situation in which a host may have multiple OPRM documents.
Again, this parallels language in RFC 8414.
I will continue the review but I wanted to update the WG on my review so far.
Atul
On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef
<rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>> wrote:
All,
This is a WG Last Call for the OAuth 2.0 Protected Resource Metadata document.
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html
Please, review this document and reply on the mailing list if you have any
comments or concerns, by April 12.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
