[OAUTH-WG] Re: Mike Bishop's No Objection on draft-ietf-oauth-rfc8725bis-07: (with COMMENT)

[Yaron Sheffer <[e-mail]>]

Thank you Mike for your comments!

Opened issues 60, 61 and 62 at 
https://github.com/oauth-wg/draft-ietf-oauth-rfc8725bis/issues

Best,
     Yaron


------ Original Message ------
>From "Mike Bishop via Datatracker" <[e-mail]>
To "The IESG" <[e-mail]>
Cc [e-mail]; [e-mail]; 
[e-mail]; [e-mail]
Date 11/08/2026 0:11:25
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".
>
>
>