Thanks for your review, Roman. My responses are inline below, prefixed by "Mike>".
The proposed resolutions below are incorporated in https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/58. Please let me know if you'd like to see any changes before we apply them. -----Original Message----- From: Roman Danyliw via Datatracker <nore...@ietf.org> Sent: Monday, September 30, 2024 9:07 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-oauth-resource-metad...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; rifaat.s.i...@gmail.com; rifaat.s.i...@gmail.com Subject: Roman Danyliw's No Objection on draft-ietf-oauth-resource-metadata-10: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-oauth-resource-metadata-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ ---------------------------------------------------------------------- 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? Mike> This is the same language as used in https://www.rfc-editor.org/rfc/rfc8414.html#section-2.1, for what it's worth, but it's a fair question. We can add language saying that this is grounds for rejecting the metadata as being invalid. ** 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? Mike> Will do. (This language is a remnant of a time before BCP 195 existed.) ** 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? Mike> I'll update this to instead describe the use of RFC 9525 (Service Identity in TLS). ** 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? Mike> More old language. I'll change "For Standards Track RFCs" to "For IETF stream RFCs". ** 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. Mike> Will do Thanks for your useful review! -- Mike _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
