[Credential Issuance] Alignment of IT‑Wallet vs OpenID4VCI and HAIP

[peppelinux]

This issue aims to track the misalignments that might cause interoperability issues with wallet solution different than the domestic one.

Please note that domestic extensions do not break interoperability when all OpenID4VCI baseline requirements are implemented and differences are documented. Items already compliant remain in the checklist for traceability and can be closed with evidence links or moved to separate issues.

References:

• OpenID4VCI Implementer’s Draft (Sept 2025): https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html
• OpenID4VC High Assurance Interoperability Profile (Sept 2025): https://openid.github.io/OpenID4VC-HAIP/openid4vc-high-assurance-interoperability-profile-wg-draft.html

A) Confirmed as compliant (no action required)

• Batch Credential Issuance supported with proofs and multi-credentials response (OK) - see OID4VCI 3.3.2 “Batch Credential Issuance”
• Supported credential formats include dc+sd-jwt (SD-JWT VC) and mso_mdoc (OK) - see OID4VCI Appendix A.2 (mdoc), A.3 (SD-JWT VC)
• Status management: OAuth Status Lists as base and OAuth Status Assertions as a domestic extension (OK; interoperability preserved) - see OID4VCI 13.7

B) Checks and potential discrepancies to address (OID4VCI)

• Signed Issuer Metadata: verify if openid_credential_issuer is also published as signed metadata (in addition to by-value JWKS); if missing, decide and document scope - see OID4VCI 12.2.3 “Signed Metadata”. Signed metadata: implement now or keep as “nice to have” (by-value only for now)?
• Credential Offer: ensure both “by value” (credential_offer) and “by reference” (credential_offer_uri) are supported; align semantics and security - see OID4VCI §4
• Authorization details vs scope: support requests via authorization_details and/or scope where applicable; document any limitations - see OID4VCI 5.1.1, 5.1.2
• PAR/Authorization/Token: re-validate client auth expectations at PAR (per RFC 9126) and full alignment of client auth at Token Endpoint - see OID4VCI 5.1.4, 6
• Nonce Endpoint: verify handling of c_nonce and c_nonce_expires_in, replay prevention, timing, and error mapping - see OID4VCI §7, §8.1–§8.2
• Credential Endpoint error mapping: align error codes/payload per OID4VCI 8.3.1
• OID4VCI permits optional, application-layer encryption of Credential requests and/or responses on top of TLS, typically using JWE. Wallets can indicate encryption parameters and keys so the Issuer can encrypt the Credential response back to the Wallet. See: OID4VCI §10 “Encrypted Credential Requests and Responses” (https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#name-encrypted-credential-request). Application-layer encryption for issuance: any national requirements mandating it in specific scenarios?
• Relationship between metadata credential_issuer and Credential iss: verify/document correspondence - see OID4VCI 14.4
• Domestic metadata batch_credential_issuance: clearly label as non-standard extension; keep discovery interoperable (wallet must work in standard mode if absent) - see OID4VCI 3.3.2
• pointers for both JSON (SD‑JWT VC) and mdoc can be improved, by replacing any free‑form paths with array-of-segments (and docType-qualified for mdoc) - see OID4VCI Appendix C and examples below about the requirement of having the pid in both sd-jwt vc and mdoc cbor format.

{
  "credential_configurations_supported": {
    "pid_sdjwt": {
      "format": "dc+sd-jwt",
      "claims": [
        { "path": ["given_name"], "display": [{ "name": "Given name", "locale": "en-US" }] },
        { "path": ["address", "locality"], "display": [{ "name": "City", "locale": "en-US" }] },
        { "path": ["emails", "0", "value"], "display": [{ "name": "Email", "locale": "en-US" }] }
      ]
    }
  }
}

{
  "credential_configurations_supported": {
    "pid_mdoc": {
      "format": "mso_mdoc",
      "doctype": "iso.org.18013.5.1.mDL",
      "claims": [
        { "path": ["iso.org.18013.5.1.mDL", "family_name"], "display": [{ "name": "Family name", "locale": "en-US" }] },
        { "path": ["iso.org.18013.5.1.mDL", "given_name"], "display": [{ "name": "Given name", "locale": "en-US" }] }
      ]
    }
  }
}

D) HAIP Addendum – Additional alignment items

• Signed Issuer Metadata: HAIP adds a requirement for signed Issuer Metadata. Confirm publication of signed metadata for the Credential Issuer (and, where applicable, Authorization Server) in addition to by-value JWKS - see HAIP §4.1 and document history (“add signed Issuer Metadata”)
• Wallet Attestation (at Token Endpoint): Confirm Wallet Attestation usage and binding in Access Token requests per HAIP profiling (headers, PoP, freshness, lifetimes) - see HAIP §4.4.1 “Wallet Attestation”
• Key Attestation (at Credential Endpoint): Confirm Key Attestation requirements and verification when issuing Credentials (e.g., platform attestation inputs, validation steps) - see HAIP §4.5.1 “Key Attestation”
• SD‑JWT VC issuer key resolution via X.509: HAIP mandates X.509‑based issuer key resolution for SD‑JWT VC. Ensure issued SD‑JWT VCs (and verification material) include resolvable X.509 chain (x5c) and that the validation path is documented - see HAIP document history (“x.509 certificates are now the mandatory mechanism for SD‑JWT VC issuer key resolution”)
• Status List Token x5c: Ensure the Status List Token responses include the x5c header as mandated by HAIP - see HAIP document history (“x5c header in Status List Token must be present”)
• Nonce Endpoint presence and DPoP nonce nuances: HAIP clarifies presence conditions for nonce endpoint when cryptographic_binding_methods_supported is set, and notes about DPoP nonces. See HAIP notes/doc history (“clarify nonce endpoint must be present…”, “say something about DPoP nonces”)
• Application‑layer encryption strength: HAIP increases encryption requirements (e.g., mandatory encryption for OpenID4VP responses; issuance may have profiled expectations). Confirm stance for issuance (VCI §10) and document defaults consistent with HAIP - see HAIP §§5, 7; OID4VCI §10
• Combined issuance in one transaction (SD‑JWT VC + mdoc): HAIP lists this as an ecosystem scenario. Confirm if supported or explicitly out‑of‑scope; if not supported, document roadmap/position - see HAIP §3.2 Scenarios and §4 Issuance profile
• Interoperable key attestations: HAIP adds guidance on interoperable key attestations and notes ecosystems may choose alternate key attestation types. Confirm which attestations are accepted and how they’re validated and advertised in metadata - see HAIP §9.1, §11.1, document history
• Custom URL schemes (wallet invocation): HAIP registers haip-vci:// and haip-vp:// schemes. If relevant to wallet invocation in the ecosystem, document compatibility or ecosystem decision - see HAIP Appendix A.1.1/A.1.2

[peppelinux]

regarding client auth at PAR, see oauth-wg/draft-ietf-oauth-attestation-based-client-auth@02add0a#diff-d7c73869a35c5ee2a4628cd69307033e738fb3d344e6d05ce08a4c1df304aaeeR372