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

[Ballot 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.

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.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot 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.

[Ballot 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.

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?

[Ballot comment]
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.

[Ballot comment]
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

[Ballot discuss]
## Discuss

### Forbidden Query & Fragment

```
175       The Protected resource's resource identifier, which is a URL that
176       uses the https scheme and has no query or fragment components.
```

I can understand the decision to keep fragment off, per:

https://url.spec.whatwg.org/#url-equivalence

But I don't understand why query is forbidden, especially considering:

https://datatracker.ietf.org/doc/html/rfc3986#section-3.4

I would expect query to be allowed, and for some comment about canonical URI encoding based on query ordering to be made.

I assume query is omitted to make processing rules described in Section 3 simpler... This also restricts the set of existing resources which this specification could apply to... and implies that resource identifiers that are URLs do not contain queries.

It seems like a specification should be able to describe transformation rules that use query or hostname rewriting, even if the current spec sees no need to use query or hostname structures, why should other specifications be forbidden from doing so?

For an example:

https://example.com/oauth-protected-resource
https://example.com/.well-known/oauth-protected-resource

vs

https://oauth-protected.example.com/.well-known/fancy-index?key=value
https://example.com/.well-known/oauth-protected?key=value...

I searched github and the mailing list to see if there was discussion regarding this, please point it out if I somehow missed it.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-oauth-resource-metadata-10
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-10.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Arnt Gulbrandsen for the ART ART review.

### JSON Serialization Forbidden?

```
158   Compact Serialization or the JWE Compact Serialization; the JWS JSON
159   Serialization and the JWE JSON Serialization are not used.
```

This is descriptive, but I wonder if there is an intention to enable better interoperability by explicitly forbidding JSON Serialization.

### signed_metadata in JWT claims

```
346       JWT.  A signed_metadata metadata value SHOULD NOT appear as a
347       claim in the JWT.
```

When this should is ignored what happens? Raise and error or ignore?


### media type of response

```
425   configuration.  A successful response MUST use the 200 OK HTTP status
426   code and return a JSON object using the application/json content type
427   that contains a set of claims as its members that are a subset of the
428   metadata values defined in Section 2.  Other claims MAY also be
429   returned.
```

Based on the last sentence, it seems like the metadata resource is intended to be extended, should it be possible to negotiate its extended representations?

Why restrict the media type to "application/json" ?


### Identical URIs

```
460   metadata.  If these values are not identical, the data contained in
461   the response MUST NOT be used.
```

Consider being more precise regarding what "identical" means here, see the URL equivalence section of WHATWG URL spec for example:

https://url.spec.whatwg.org/#url-equivalence

I also wonder if URL patterns are useful here...

https://urlpattern.spec.whatwg.org/

You might also consider calling out Section 6 here.

## Nits

### Missing owner?

```
627   At any point, for any reason determined by the protected resource,
628   the protected resource MAY respond with a new WWW-Authenticate
```

[Ballot comment]
** 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-oauth-resource-metadata-08. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are three actions which we must complete. We also have a question about the first action.

First, a new registry is to be created called the OAuth Protected Resource Metadata registry. The new registry will be located in the OAuth Parameters registry group located at:

https://www.iana.org/assignments/oauth-parameters/

The new registry will be managed by Specification Required as defined in [RFC8126]. All registrations in the new registry will be subject to a two week mailing list review as defined in [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Metadata Name: resource
Metadata Description: Protected resource's resource identifier URL
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: authorization_servers
Metadata Description: JSON array containing a list of OAuth authorization server issuer identifiers
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: jwks_uri
Metadata Description: URL of the protected resource's JWK Set document
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: scopes_supported
Metadata Description: JSON array containing a list of the OAuth 2.0 scope values that are used in authorization requests to request access this protected resource
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: bearer_methods_supported
Metadata Description: JSON array containing a list of the OAuth 2.0 Bearer Token presentation methods that this protected resource supports
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: resource_signing_alg_values_supported
Metadata Description: JSON array containing a list of the JWS signing algorithms (alg values) supported by the protected resource for signed content
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: resource_documentation
Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the protected resource
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: resource_policy_uri
Metadata Description: URL that the protected resource provides to read about the protected resource's requirements on how the client can use the data provided by the protected resource
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: resource_tos_uri
Metadata Description: URL that the protected resource provides to read about the protected resource's terms of service
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2 ]

Metadata Name: signed_metadata
Metadata Description: Signed JWT containing metadata values about the protected resource as claims
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 2.1 ]

IANA Question -> Is there a missing "to" in the Metadata Description for "scopes_supported"? "JSON array containing a list of the OAuth 2.0 scope values that are used in authorization requests to request access [to] this protected resource".

Second, in the OAuth Authorization Server Metadata registry also in the OAuth Parameters registry group located at:

https://www.iana.org/assignments/oauth-parameters/

A single new registration will be made as follows:

Metadata Name: protected_resources
Metadata Description: JSON array containing a list of resource identifiers for OAuth protected resources
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 4 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

A single registration will be made as follows:

URI Suffix: oauth-protected-resource
Change Controller: IETF
Reference: [ RFC-to-be; Section 3 ]
Status: permanent
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

We understand that these three actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-08-26):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-oauth-resource-metadata@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rifaat.s.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OAuth 2.0 Protected Resource Metadata) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Protected Resource
Metadata'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-08-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a metadata format that an OAuth 2.0 client
  or authorization server can use to obtain the information needed to
  interact with an OAuth 2.0 protected resource.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/



No IPR declarations have been submitted directly on this I-D.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There was a broad support for this document.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No such controversy.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  OpenID Federation implementations use the Protected Resource Metadata definitions in this specification. 
  Connect2ID and Authlete have OpenID Federation implementations. 
  Italian SPID CIE national federation.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  No


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  None is needed, as no new types are defined by this document.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No YANG model


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There is no formal language in the document.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is well written and addresses a specific need.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Not applicable


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

  Standards Track, as this is a defined a metadata format to be used by resource
  servers, and a mechanims to access thia metadata.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    All authors provided their IP disclosure on the mailing list:

    Mike: https://mailarchive.ietf.org/arch/msg/oauth/NZNmDtAlC3gYUb46u25NuYUpFeM/
    Phil: https://mailarchive.ietf.org/arch/msg/oauth/f3Elb9jKQ461Fvv1YuRTU9nRJPw/
    Aaron: https://mailarchive.ietf.org/arch/msg/oauth/CNthgap0GMMzI7A7acm5AJxOHCM/
   

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    The authors addressed the nits identified in the shepherd review.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All normative references are freely available.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No change to existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA consideration section is consistent with the body of the document.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The document establishes the new IANA "OAuth Protected Resource Metadata" registry.
    The document provides clear instruction to the desginated expert.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There was a broad support for this document.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No such controversy.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No such threats.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  OpenID Federation implementations use the Protected Resource Metadata definitions in this specification. 
  Connect2ID and Authlete have OpenID Federation implementations. 
  Italian SPID CIE national federation.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  No


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  None is needed, as no new types are defined by this document.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  No YANG model


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There is no formal language in the document.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes, the document is well written and addresses a specific need.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Not applicable


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

  Standards Track, as this is a defined a metadata format to be used by resource
  servers, and a mechanims to access thia metadata.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    All authors provided their IP disclosure on the mailing list:

    Mike: https://mailarchive.ietf.org/arch/msg/oauth/NZNmDtAlC3gYUb46u25NuYUpFeM/
    Phil: https://mailarchive.ietf.org/arch/msg/oauth/f3Elb9jKQ461Fvv1YuRTU9nRJPw/
    Aaron: https://mailarchive.ietf.org/arch/msg/oauth/CNthgap0GMMzI7A7acm5AJxOHCM/
   

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    The authors addressed the nits identified in the shepherd review.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All normative references are freely available.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No such references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No such references.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No change to existing RFCs.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA consideration section is consistent with the body of the document.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The document establishes the new IANA "OAuth Protected Resource Metadata" registry.
    The document provides clear instruction to the desginated expert.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/