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]
