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

[Michael Jones <[e-mail]>]

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 <[e-mail]>
Sent: Monday, August 10, 2026 2:11 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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".