HAIP 1.1: "certificate signing the request" is a copy-paste artifact in three clauses that do not involve a request

HAIP 1.1: "certificate signing the request" is a copy-paste artifact in three clauses that do not involve a request

Spec / revision: OpenID4VC High Assurance Interoperability Profile 1.1 (draft)
Pinned source: https://github.com/openid/OpenID4VC-HAIP/blob/8f45ca301e822d4abe944d1085d60d7cd015087f/1.1/openid4vc-high-assurance-interoperability-profile-1_1.md

Summary

The sentence

The X.509 certificate signing the request MUST NOT be self-signed.

appears verbatim in several clauses. In two of them it is correct, because a request is genuinely what is being signed (the signed key attestation, and the signed OpenID4VP authorization request). In three other clauses the same sentence was copied without adapting the noun, and the object being signed is not a request:

1. Signed Credential Issuer Metadata — the thing signed is the Issuer Metadata.
2. SD-JWT VC Status List Token — the thing signed is the Status List Token.
3. SD-JWT VC issuer signature (key resolution) — the thing signed is the SD-JWT VC itself.

In all three, the phrase "the request" has no antecedent in its paragraph — none of these paragraphs mention or involve a request. The requirement (no self-signed signer certificate) is presumably intended, but the wording is wrong and confusing for implementers and conformance testers, who must guess which "request" is meant.

The fix is editorial only: replace "the request" with the object that each clause actually signs. No normative change is intended.

This is not a 1.1 regression: all three occurrences are inherited unchanged from the final published HAIP 1.0, with byte-identical wording (see "Provenance" below).

Locations to change

Section references use the heading title and its stable {#anchor}; the current text is quoted exactly as it appears at the pinned commit.

---

1. Issuer Metadata — ## Issuer Metadata {#issuer-metadata}

(within "OpenID for Verifiable Credential Issuance")

Current text:

Key resolution to validate the signed Issuer Metadata MUST be supported using the x5c JOSE header parameter as defined in [@!RFC7515]. In this case, the X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the signed request. The X.509 certificate signing the request MUST NOT be self-signed.

Proposed text:

Key resolution to validate the signed Issuer Metadata MUST be supported using the x5c JOSE header parameter as defined in [@!RFC7515]. In this case, the X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the signed Issuer Metadata. The X.509 certificate signing the Issuer Metadata MUST NOT be self-signed.

Note: in this paragraph the preceding sentence has the same defect — "the x5c JOSE header of the signed request" also refers to the signed Issuer Metadata, not a request. Both occurrences are corrected in the proposal above.

---

2. Status List Token — ## IETF SD-JWT VC Profile {#sd-jwt-vc}

(the bullet on the Status List Token, within "OpenID4VC Credential Format Profiles")

Current text:

• The public key used to validate the signature on the Status List Token defined in [I-D.ietf-oauth-status-list] MUST be included in the x5c JOSE header of the Token. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the Status List Token. The X.509 certificate signing the request MUST NOT be self-signed.

Proposed text:

• The public key used to validate the signature on the Status List Token defined in [I-D.ietf-oauth-status-list] MUST be included in the x5c JOSE header of the Token. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the Status List Token. The X.509 certificate signing the Status List Token MUST NOT be self-signed.

---

3. SD-JWT VC issuer signature — ### Issuer identification and key resolution to validate an issued Credential {#issuer-key-resolution}

(subsection of "IETF SD-JWT VC Profile")

Current text:

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.

Proposed text:

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 SD-JWT VC MUST NOT be self-signed.

---

Occurrences that are already correct (no change needed)

For completeness, so the fix is not applied too broadly:

• ### Key Attestation {#key-attestation} — "The X.509 certificate signing the key attestation MUST NOT be self-signed." The noun was already adapted correctly here.
• # OpenID for Verifiable Presentations {#openid-for-verifiable-presentations} — "For signed requests, ... The X.509 certificate signing the request MUST NOT be self-signed." Here the object genuinely is a (signed authorization) request, so "the request" is correct.

These two are almost certainly the origin of the template sentence that was then copied into the three clauses above.

Provenance: already present in HAIP 1.0

All three defective occurrences already exist in the final, published HAIP 1.0, with wording byte-identical to 1.1 (verified against https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html). The published 1.0 rendering assigns them these section numbers:

#	HAIP 1.0 section	HAIP 1.1 heading / anchor
1	4.1 Issuer Metadata	Issuer Metadata {#issuer-metadata}
2	6.1 IETF SD-JWT VC Profile (Status List Token bullet)	IETF SD-JWT VC Profile {#sd-jwt-vc}
3	6.1.1 Issuer identification and key resolution to validate an issued Credential	{#issuer-key-resolution}

In each of these three 1.0 sections the sentence reads exactly "The X.509 certificate signing the request MUST NOT be self-signed." So this is a long-standing editorial defect carried forward into the 1.1 draft, not something newly introduced in 1.1 — worth fixing in 1.1 rather than perpetuating it further.

Related issues (checked 2026-07-15)

No open issue targets this editorial "the request" wording defect directly; this is not a duplicate. Adjacent open issues, and how this one differs:

• #372 — "Clarification about trust anchor limitations" (open): discusses the same paragraph as Location 3 (§6.1.1), and quotes "...signing the request MUST NOT be self-signed" verbatim, but only as a substantive/normative question — whether a leaf or self-signed certificate may serve as a trust anchor (incl. the EUDIW PID / ETSI TS 119 412-6 self-certified case). No participant there flags "the request" as a wording error. This issue is purely editorial and deliberately does not touch the normative question raised in #372.
• #368 — "text around self-signed certificates / excluding trust anchor not present in wallet attestation section" (open): the same boilerplate family, but the opposite defect — it notes the trust-anchor-exclusion and not-self-signed sentences are missing from the Wallet Attestation section and should be added for consistency. Orthogonal to this issue (missing text vs. wrong noun), though both aim at normalizing the x5c / self-signed boilerplate across sections and could be handled together.
• #371 — "Discovery of public key / certificates of Verifier by Wallet" (open): quotes the §5 (OpenID for Verifiable Presentations) occurrence, which is one of the correct ones — there "the request" genuinely denotes a signed authorization request. Not affected by this fix.

For context, this boilerplate originates from the closed issues #236 ("Clarify that x509_hash certificates shall not be self-signed certificates") and #237 ("Trust anchor certificate shall not be included in the x5c"), which introduced the sentence for the OID4VP signed request; it was subsequently copied into the other x5c clauses, which is how "the request" propagated into sections that involve no request.

Open the pinned 1.1 specification Markdown file and locate the three headings and anchors listed: Issuer Metadata, IETF SD-JWT VC Profile, and issuer key resolution. Update only the incorrect signed-object wording described in the issue, including the preceding Issuer Metadata reference, while leaving the two already-correct occurrences unchanged. Done means all three clauses name the object they actually sign.