Thanks for the work put into this document, and thanks to Valery Smyslov for the ARTART review and to the authors for addressing the ARTART review.

Thanks to Valery Smyslov for the ARTART review and to the authors for addressing the points raised. 

## Comments

### Section 3.11, RECOMMENDED vs REQUIRED use of "typ"

681	   Explicit typing is RECOMMENDED for new uses of JWTs, because without
682	   it, mutually exclusive validation rules are harder to enforce and
683	   cross-JWT confusion becomes more likely.
 
Is there a specific reason the "typ" requirement is "RECOMMENDED" rather than "REQUIRED" for new uses of JWTs?

Thanks for the work done in this easy to read and useful documents. 

Special thanks for providing the BCP 14 guidance when using "SHOULD".

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>

# 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".

Hi Yaron, Dick, and Mike, 

Thank you for the effort out into this BCP refresh.

# I only reviewed the diff vs. RFC8725. I found the changes well-articulated with clear reasoning, overall. 

# “reasonable” limits

The document argues for implementations to use “reasonable” limits and provides examples of such “reasonable” values. The document is silent about how these implementations should expose configuration knobs for those who deploy to actually adjust these values.

Likewise, for auditing and management purposes, these implementations should expose the actual limits put into affect.

# (nit) “Existing BCP” won’t age as soon as this draft will be published as RFC. I sent you a PR to fix this: https://github.com/oauth-wg/draft-ietf-oauth-rfc8725bis/pull/67 

Cheers,
Med