Thanks, these look good. ________________________________ From: Michael Jones <[email protected]> Sent: Tuesday, August 11, 2026 4:08 PM To: Mike Bishop <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: Mike Bishop's No Objection on draft-ietf-oauth-rfc8725bis-07: (with COMMENT)
Thanks for the review comments, Mike. https://www.ietf.org/archive/id/draft-ietf-oauth-rfc8725bis-09.html is intended to address your comments. Per the history entries, the changes made were: - Clarified that the JWE decompression size limit is a ballpark drawn from deployed libraries (IESG review). - IESG nits: replaced "blindly" and added a missing comma after "However". Best wishes, -- Mike -----Original Message----- From: Mike Bishop via Datatracker <[email protected]> Sent: Monday, August 10, 2026 2:11 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mike Bishop's No Objection on draft-ietf-oauth-rfc8725bis-07: (with COMMENT) Mike Bishop 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: ---------------------------------------------------------------------- # IESG review of draft-ietf-oauth-rfc8725bis-07 CC @MikeBishop ## Comments ### Section 3.15, paragraph 1 ``` Implementations are RECOMMENDED to set a reasonable upper limit on the decompressed size of a JWE such as 250 KB, because without such a limit, decompression can impose an unreasonable memory or CPU burden on recipients. ``` Where is the 250 KB value coming from? When would someone select a different value? I read this as RECOMMENDing a limit and providing an example value, but then I'm not sure the example value adds anything besides a risk people will infer it as part of the recommendation. (A similar recommendation in 3.13 points to OWASP guidance for a particular combination with a note that it's merely a time-of-publishing value.) ### "Appendix A.", paragraph 3 ``` 2. Encryption-Signature Confusion: Added mitigation for attacks where verifiers don't distinguish between successful decryption and successful signature validation (Section 3.12). ``` Is 3.12 the intended reference? This seems more related to 3.3's "MUST ... distinguish between signed JWTs (JWSes) and encrypted JWTs (JWEs)." ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `blindly`; alternatives might be `without consideration`, `negligently`, `uncritically`, `unthinkingly`, `hastily`, etc. ### Grammar/style #### Section 2.1, paragraph 3 ``` simple signed JWT as their token. However verifiers don't always check that ^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "However".
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
