OAuth 2.0 Protected Resource Metadata
draft-ietf-oauth-resource-metadata-13

Thank you for this document.

Many thanks to Mike Bishop for the HTTPDIR review.

One more IANA point. Section 8 states:

> Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

Maybe it is me not being a native speaker, but it is not clear to me what is requested of the IESG. If the goal is to add a "IESG Approval" (see https://www.rfc-editor.org/rfc/rfc8126#section-4.10 ), then it should be stated clearly, and by the way I do not think that is a good idea. If it is escalation, then IANA already has procedures in place for that, and I don't think this text adds anything to that. Can you expand?

Thanks for the well-written document. I have a couple of comments —

- Section 1 “This use of WWW-Authenticate can indicate that the protected resource metadata MAY have changed.” That’s a misuse of the RFC 2119 MAY. You aren’t specifying procedure here, so you should be using lowercase “may”. This recurs in Section 5.2, “its metadata MAY have changed”. 

- In Section 8, you say the registration policy is Specification Required, but then you go on to say “However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.” As far as I can tell, that is not compatible with the plain language of the policy called “Specification Required“ as described in RFC 8126. I also wonder how the experts could possibly do a proper review if all they have to look at is an IOU for a specification.

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.

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?

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

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?

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.

I strongly suggest including a sentence or two in your IANA Considerations that explains the innovated registration policy being created here.  I would also recommend saying something about the possibility of a registration being made against the promise of a future specification that, in the end, never actually appears.

Thanks for addressing my comments.

I'm clearing my discuss: https://mailarchive.ietf.org/arch/msg/oauth/1VFHst9xvvP6AxW3lmwemx0mLCU/

La mia bella recensione


resource_signing_alg_values_supported
        No default algorithms are implied if this entry is omitted.

What does this imply? Does it mean a value can be supplied later? Or
that the request will never be able to succeed?


In Section 5.1 there is an error message, but unlike earlier in the
document, there seems to be no language support here. I guess that
is a shortcoming of RFC6750.

I am also interested to hear the response to Orie's DISCUSS

** Section 2.2

   signed_metadata
      A JWT containing metadata values about the protected resource as
      claims.  This is a string value consisting of the entire signed
      JWT.  A signed_metadata metadata value SHOULD NOT appear as a
      claim in the JWT.

If signed_metadata appears as a claim, what should be done with it?

** Section 7.1
    Implementations SHOULD follow the guidance in BCP
   195 [RFC8996] [RFC9325], which provides recommendations and
   requirements for improving the security of deployed services that use
   TLS.

Why can’t this document require (MUST) conformance to BCP 195 and delegate responsibility to maintaining those recommendations to the BCP?

** Section 7.3
    TLS certificate checking MUST be performed by the client, as
   described in Section 7.1,

What guidance in Section 7.1 discusses TLS certificate checking?

** Section 8.1.1

   Change Controller:
      For Standards Track RFCs, list the "IETF". 


Wouldn’t “IETF” be listed for all RFCs in the IETF stream?

** Section 8.3.1

   *  URI suffix: oauth-protected-resource
   *  Change controller: IETF
   *  Specification document: Section 3 of [[ this specification ]]
   *  Related information: (none)

For editorial clarity, https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml uses “Reference” not “Specification document”.  Consider harmonizing the column names.

Thanks for the document and thanks to Rifaat Shekh-Yusef  for the shepherd write-up including the WG consensus and the justification of the intended status.

As a Belgian French-speaking person, I smiled when reading `using fr might be sufficient in many contexts, rather than fr-CA or fr-FR` :-)

More seriously, should the examples in section 3.1 use a more recent HTTP version ?

Superb use of SVG in section 5, suggest to introduce the "AS" acronym used in step 6 in the text below the figure (this comment could possibly apply to other acronyms).

Finally, I agree with John and Murray about their comments about the IANA section.