I am the assigned ARTART reviewer for this draft. While I have some familiarity with OAuth, I am not qualified to evaluate the security aspects of the protocol.

The document is generally clear and well written.

Miscellaneous comments:

Section 1 paragraph 3: "values of the metadata are not directly validated": Perhaps "are not required to be validated" to make it clear that validation is permitted?

Section 2 last paragraph: "can be used to indicate": perhaps "MUST be used to indicate" (or is this just an optional capability)?

Section 3, item 2 of section 3 replacement text: "is responsible for ensuring": Should this be stated normatively, i.e., "MUST ensure"?

Perhaps I'm taking the text replacements too literally in the following comments:

Section 4 section 3 replacement text,  paragraph (b): "the aud value specified in [RFC7523]" refers to the document and section that the replacement text is going into. It seems like this sentence and perhaps others belong outside the indented (replacement text) part of this section.

Section 4.1, in the example claims set the iss and sub claims have a trailing slash that doesn't show up elsewhere. It probably doesn't matter, but it looks inconsistent.

Section 5, the indented replacement text isn't worded like it would in that document. Specifically, "This update resolves..." would be out of context there. [OpenID.Core] references a newer revision of the OIDC specification than RFC 9126 uses; is it intended to use this revision in this context only or throughout 9126? Again, the reference to [RFC9126] here is self-referential in the replacement text so perhaps it belongs outside the intented section.

Section 5, replacement text paragraph 3: Strong typing alone does not prevent the attacks so it is RECOMMENDED. But it seems like it should be RECOMMENDED only if the audience restrictions alone are sufficient to prevent the attacks. Also, while I'm generally a fan of strong typing, if the audience restrictions are sufficient, I'm wondering how it fits with the vulnerability identified in the abstract. Perhaps it's just being used as a signaling mechanism to indicate that the vulnerability has been addressed, but as you point out it's not a signal that can be acted upon for interoperablity reasons.