This document is clearly a product of a fairly mature standards process, but as always happens with fresh eyes, there are a number of points to call out.

I'll try to not revisit items unlikely to change, such as the excessive use of 3-letter tags (I suppose for shorter headers, despite the fact that compression would make that irrelevant) and the use of the term "rich", which by this time is as meaningless as that other IETF cozy-word "simple".

With that off my chest - commentary about details and nits follow. This document is, to my mind, close to being "ready" - but fixing the issues would, I think, make it better.

By section:
Section 4 mode 3-4 uses the term “forward control”, which is a confusing term. The term seems to indicate that “the entity that signs the RCD object can include within the JWT object a statement about what the signer of the PASSporT object can claim to include”. This mechanism (and the need for it) is still obscure to me after reading the spec. See also comments on section 7.

Section 5.1 talks about fields being “derived from” things like display-name component of From header field value of SIP. This seems like an improper constraint on how applications are built.
More likely usage is that the passport object is signed first, and the display-name is set from the same data source; instead of saying “derived from”, a spec should say “the same as” - what comes first and last is not a concern for the spec.

Section 6 - spec says MUST SHA512, MUST NOT SHA-1. Given that this is a document format, is this the right place for that kind of statement? If specs that use it already specify something about hash functions, they are unlikely to change their usages just because this document says so. What will not be obeyed should not be stated.

Section 6 says that it uses “JSON pointer with a minor additional rule”, is it clear what the additional rule is? If it’s only the 6.1.4 “jump the indirect”, that might be worth calling out.

Section 7, The JWT Claim Constraints section, talks about “constrain the signer”. That’s an odd form if this is a document format description. RFC 8226 seems to say that it is part of the format for requesting a signature (the unsigned or self-signed version of the cert), and is part of the cert only to verify what the signer was asked to sign.

Section 9.1 talks about “the certificate used to sign the PASSporT”. This terminology seems suspect. RFC 7515 section 5.1 is the “compute the signature” step. It doesn’t talk about a certificate used as input. 12.1 also contains this odd construct. Does it mean "the certificate containing the public key associated with the private key used to sign the PASSporT"? If so, it should say that this is what it means. (An alternative would be "the PKCS#11 object that contains both the public and private keys" - but that would seem like a *really* odd construct.)

Section 9.3 examples - it would be good to say which elements are protected by what for each case - for instance, example 2 will have the protection for th PASSPorT object of the icn URL, but has no protection for the content of the image - it’s not verifiable - while examples 3 and 4 have protected the content of the external references using “rcdi”.

The note in section 10.1 about reconstructing “nam” from the display-name string means that use of this format with the SIP protocol requires them to be identical, which seems to be a common assumption (see comment on 5.1).

Section 13 introduced “first” and “third” parties without defining them. Presumably the "first" party is the signer of the PASSPorT, while the "third" party is the signer of the RCD - making this explicit would be good.

14.2 says that one has to extract From and use it to check the rcd (which constrains it to be the same, no?) - while the next para talks about pulling the nam out and displaying it instead of the name in From. This is odd, given that they are identical.

14.2 at first seems to constrain what a relying entity shold do, but the section ends with a statement equivalent to “but do what you want” ("It's going to be determined by policy"), so what’s the point of the section?

All that said - this specification seems to be clear for its purpose. It could just be somewhat better.