Compliance
HAIP 1.0
OpenID4VC High Assurance Interoperability Profile compliance
The OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 was approved in December 2025. It defines mandatory requirements for verifiers and issuers operating in high-assurance environments such as the EU Digital Identity ecosystem.
Spec: openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0
Verifier compliance
| Requirement | Spec ref | Status | Notes |
|---|---|---|---|
Client ID scheme x509_hash | §5 | Compliant | SHA-256 of leaf cert DER, base64url |
Response encryption ECDH-ES with P-256 | §5 | Compliant | Ephemeral ECDH key per request |
| Supported encryption algorithms (A128GCM + A256GCM) | §5 | Compliant | In client_metadata |
| DCQL query format | §5 | Compliant | V1 service uses DCQL exclusively |
trusted_authorities with aki type | §5 | Compliant | Validator + types support; passthrough to DCQL |
Response type vp_token | §5 | Compliant | |
Response mode direct_post.jwt | §5.1 | Compliant | |
JAR with request_uri | §5.1 | Compliant | x5c signing, 600s expiry |
X.509 cert in x5c | §7 | Compliant | Configurable via env |
| ES256 algorithm | §7 | Compliant | |
Both mso_mdoc and dc+sd-jwt | §5.3 | Compliant | Separate verification flows |
| Session transcript (OID4VP Annex B.3.4.1) | §5.3.1 | Compliant | SessionTranscript.forOid4Vp() |
| KB-JWT validation for SD-JWT | §5.3.2 | Compliant | In sd_jwt_verifier.ts |
| Status/revocation checking (SD-JWT) | §5.3 | Compliant | Fetches + checks when status claim present |
redirect_uri in same-device response | §5.1 | Compliant | Returns { redirect_uri } pointing at the server-configured callback (VERIFIER_CALLBACK_URI), only for requests created with callback: true |
| Ephemeral encryption keys per request | §5 | Compliant | #generateAndStoreEcdhKeys() |
Issuer compliance
| Requirement | Spec ref | Status | Notes |
|---|---|---|---|
| Authorization code flow | §4 | Compliant | PAR → authorize → token |
| PKCE with S256 | §4 | Compliant | code_challenge/code_verifier verified |
| PAR endpoint (RFC 9126) | §4.3 | Compliant | POST /oid4vci/par returns request_uri |
pushed_authorization_request_endpoint in metadata | §4.1 | Compliant | |
require_pushed_authorization_requests: true | §4.1 | Compliant | |
| DPoP (RFC 9449) | §4 | Compliant | Token binding via JWK thumbprint |
| Wallet attestation | §4.4.1 | Partial (optional) | attest_jwt_client_auth verified at token + PAR when supplied, but not enforced: none is also advertised in token_endpoint_auth_methods_supported, so unattested clients are accepted |
| Key attestation proof type | §4.5.1 | Compliant | attestation proof type in validators |
| Nonce endpoint | §4.1 | Compliant | POST /oid4vci/nonce |
scope in credential configurations | §4.1 | Compliant | Template type used as scope |
Credential offer with authorization_code grant | §4.2 | Compliant | Via useAuthorizationCode flag |
Both mso_mdoc and dc+sd-jwt formats | §4 | Compliant | |
| ES256 algorithm | §7 | Compliant | |
| Batch credential issuance | §4 | Compliant | batch_credential_issuance in metadata |
| RFC 8414 AS metadata | §4.1 | Compliant | /.well-known/oauth-authorization-server |
code_challenge_methods_supported: ['S256'] | §4.1 | Compliant | |
| Pre-authorized code flow | §4 | Compliant | Both grant types supported |
Remaining items
These are optional or not yet needed:
| Item | Spec ref | Status | Notes |
|---|---|---|---|
| W3C Digital Credentials API | §5.2 | Compliant | Both OpenID4VP and ISO 18013-7 Annex C protocols supported |
haip-vp:// URL scheme | §5.1 | Compliant | Supported via scheme selector; openid4vp:// also works with HAIP payload |
haip-vci:// URL scheme | §4.2 | Not implemented | MAY support; we use openid-credential-offer:// |
| Status/revocation checking (SD-JWT) | §5.3 | Compliant | Token Status List with signed JWT endpoint |
| Status/revocation checking (mDoc) | §5.3 | Not applicable | No standard mDoc revocation mechanism; short-lived certs used instead |
| Refresh tokens | §4.4 | Not implemented | RECOMMENDED, not required |
| Signed issuer metadata | §4.1 | Not implemented | Only when ecosystem policy demands it |