Ketan Talaulikar has entered the following ballot position for draft-ietf-oauth-rfc8725bis-07: 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-rfc8725bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for the work on this document. Please note that my review focussed largely on the diff from the base: https://author-tools.ietf.org/iddiff?url1=rfc8725&url2=draft-ietf-oauth-rfc8725bis-07&difftype=--html Before the inline comments, one point that has no specific text to attach to: The Obsoletes and Updates relationships appear on the title page and in the Abstract, but Section 1 says nothing about either. There is no mention of RFC 8725 anywhere in the Introduction, and nothing that identifies what in RFC 7519 is being updated. For a document that changes the status of two RFCs, a reader arriving at Section 1 gets no account of what changed or why. Suggest a short paragraph in Section 1 stating that this document obsoletes RFC 8725, summarising at a high level what is new with a pointer to Appendix A for the detail, and naming what it updates in RFC 7519. Please find below the rest of my comments inline in the idnits output of v07. Lookout for the <EoRv07> tag at the end to ensure you are seeing the full review. 371 Some JWS implementations support both the Compact and JSON 372 Serializations. While JWTs must use the Compact Serialization, if an <nit> This seems like a statement about what RFC 7519 requires rather than a requirement this document is imposing? If so, it would read better carrying the citation than restating the constraint unattributed. Please consider adding a reference to the relevant section of RFC 7519. <question> I see that RFC 9864 updates both RFC 7518 and RFC 8037, each of which is a normative reference in this document. I am not positioned to judge whether the implications of RFC 9864. Was it considered for this revision? 549 If the same issuer can issue JWTs that are intended for use by more 550 than one relying party or application, or may do so in the future, 551 the JWT MUST contain an "aud" (audience) claim that can be used to 552 determine whether the JWT is being used by an intended party or was 553 substituted by an attacker. <minor> The phrase "or may do so in the future" seems odd to me; the corresponding condition in RFC 8725 stopped at "more than one relying party or application". Almost any issuer may in future serve more than one relying party, so the added clause appears to make the condition effectively always true - and it is not something that can be evaluated at the moment a token is issued. Am I missing something? By the way, this is a change in normative scope relative to RFC 8725 that Appendix A does not record - see my comment on Appendix A below. 625 Distinct types make cross-JWT substitution harder when validators 626 check "typ". Misapplying the Section 4.1.9 prefix rule can cause 627 validators to reject otherwise valid tokens or accept the wrong type. <minor> Line 626 refers to "the Section 4.1.9 prefix rule" without naming a document. RFC 7515 was last named at line 605, with a paragraph and two bullet lists intervening, so the reference does not resolve for a reader arriving at this sentence. s/the Section 4.1.9 prefix rule/the prefix rule in Section 4.1.9 of [RFC7515] 946 Appendix A. Changes from RFC 8725 948 This document obsoletes RFC 8725 and provides several significant 949 improvements and additions: <minor> Comparing the text against RFC 8725, I saw more changes and some of them seem substantial/normative to my novice eyes but not listed in this appendix. Since this appendix is what a reader of the published BCP will use to understand what changed between RFC 8725 and its replacement, and some of the omissions seem important, completing it seems worth doing rather than leaving readers to diff the two documents? 969 6. Described relationship between explicit typing and kinds of JWTs 970 not already employing it. <nit> This is the only entry in the appendix carrying no section reference. It should point at Section 3.11? <EoRv07> _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
