Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Atul Tulshibagwale <[e-mail]>]

Continuing my review notes from section 3.2:

   1. Section 3.2 paragraph 2 says "Claims that return multiple values are
   represented as JSON arrays." should this be "MUST be represented as JSON
   arrays"? "Are" is probably OK because it is a statement of fact, but since
   this spec will be used by implementers, "MUST be" is more prescriptive
   2. Section 3.2: Is there any ordering condition to multi-valued claims?
   I.e. A client MUST / SHOULD try to use the smallest indexed value of a
   multi-valued claim and if that is unsuccessful, then use the next smallest
   indexed value? I don't know if this matters. If not, should we clarify that
   clients MAY use any subset of values?
   3. Section 3.2 example: Not having "scopes_supported" in the example is
   a miss I think, although it does not affect the correctness of the document
   4. Section 4 protected_resources: "would not be used" is ambiguous. Can
   we say "MUST NOT be present in the Authorization Server Metadata"?
   5. Section 5. Step 4 should read "The resource server responds with..."
   6. Section 5.1: Does this introduce any IANA consideration? How would we
   know if some other spec is not using "resource_metadata" in some other way
   in the WWW-Authenticate response header? (Unlikely, but if there is a way
   to reserve it, we should)
   7. Section 5.2: "...it is expected retrieve..." has a typo, should be
   "expected to retrieve". The language can also be more normative: "...The
   client SHOULD retrieve..."
   8. Section 5.3: Do we need this section? The spec doesn't use "Client
   Identifier" anywhere, so the section may not be needed in this spec.

-- Review completed.

Atul

On Wed, Mar 27, 2024 at 12:00 PM Atul Tulshibagwale <[e-mail]> wrote:

> 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:
>       1. Typo: "protected resource's URL" instead of "protect
>       resource's URL"
>       2. This contradicts the statement in section 3, which states the
>       "well-known" should be inserted between the host and path components
>    2. 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 ...".
>    3. 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."
>    4. 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.
>    5. Section 3, paragraph 2: The first sentence should capitalize "MAY"
>    in "...application-specific ways may define and register..."
>    6. 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.
>    7. 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
>    8. Section 3, paragraph 3: "...specify what well-known URI string..."
>    should be changed to "...specify what well-known URI path-suffix..."
>    9. 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''?
>    10. 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.
>
> 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 <
> [e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>