You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Signed Credential Issuer Metadata — the thing signed is the Issuer Metadata.
SD-JWT VC Status List Token — the thing signed is the Status List Token.
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.
(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:
Clarification about trust anchor limitations #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 Clarification about trust anchor limitations #372.
text around self-signed certificates / excluding trust anchor not present in wallet attestation section #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.
Discovery of public key / certificates of Verifier by Wallet #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.
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
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:
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:
Proposed text:
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:
Proposed text:
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:
Proposed text:
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:{#issuer-metadata}{#sd-jwt-vc}{#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:
x5c/ self-signed boilerplate across sections and could be handled together.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 otherx5cclauses, which is how "the request" propagated into sections that involve no request.