Clarification about trust anchor limitations

Hello,

I would like to ask about the requirement from HAIP 1.0:

6.1.1. Issuer identification and key resolution to validate an issued Credential
This specification mandates the support for X.509 certificate-based key resolution to validate the issuer signature of an SD-JWT VC. This MUST be supported by all entities (Issuer, Wallet, Verifier). The SD-JWT VC MUST contain the credential issuer's signing certificate along with a trust chain in the x5c JOSE header parameter as described in section 3.5 of [I-D.ietf-oauth-sd-jwt-vc]. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the SD-JWT VC. The X.509 certificate signing the request MUST NOT be self-signed.

We believe we have identified a situation where this might not be desired.

In some ecosystems, it might be desirable to have the leaf X.509 certificate as a trust anchor. We are currently discussing whether this could be the case in EUDIW. From our understanding, this might be possible in EUDIW.

If this were the case, including the signing certificate (which would also be the trust anchor) in the x5c would violate HAIP because of:

... The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the SD-JWT VC. The X.509 certificate signing the request MUST NOT be self-signed. ...

On the other hand, not including the signing certificate would also violate HAIP:

... The SD-JWT VC MUST contain the credential issuer's signing certificate...

In that case, it might be necessary to specify in the EUDIW ecosystem that HAIP should be used except for this condition.
Was this intentional, or did we overlook something?

Start with HAIP 1.0 section 6.1.1 and its references to SD-JWT VC section 3.5, then review the discussion in this issue about leaf certificates used as trust anchors. Done means determining whether the requirement is intentional and whether the specification needs clarification or an explicit ecosystem exception.