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>