- News
OpenID4VC and HAIP: Turning Interoperability from Hope into Verification
ㅣ
Bart van der Geest
1. What OpenID4VC and HAIP Actually Are
OpenID4VC is the family of digital credential protocols developed by the OpenID Foundation's Digital Credentials Protocols (DCP) Working Group. It has two pillars:
OpenID4VCI (Issuance) — an OAuth 2.0-based API for Issuers to issue credentials into Wallets
OpenID4VP (Presentation) — the protocol by which a Wallet presents credentials to a Verifier for verification
HAIP (High Assurance Interoperability Profile) is a profile for using those two protocols together with the IETF SD-JWT VC and ISO mdoc credential formats. It is not a new protocol — it is a document that narrows the choices left open by the existing specifications.
When each went Final
Specification | Final |
|---|---|
OpenID4VP 1.0 | 9 July 2025 |
OpenID4VCI 1.0 | 16 September 2025 |
HAIP 1.0 | 24 December 2025 |
Final status is a prerequisite for regulators to name a technical standard directly in legislation. With eIDAS 2.0 and more than 30 jurisdictions now building their national digital identity programs on top of these protocols, that carries real weight.
2. Why HAIP Was Needed
It is common for two implementations that are each 100% compliant with a specification to be unable to talk to each other. "Spec-compliant" and "interoperable" are not the same thing.
OpenID4VP and OpenID4VCI carry a great deal of optionality by design. You choose a credential format, a signature algorithm, a wallet invocation mechanism, a client authentication method. Every one of those choices is legitimate — but if the combinations don't line up, the connection fails.
HAIP pins those choices down for high assurance environments. A few of the most significant:
Common
Credential format must be at least one of SD-JWT VC (
dc+sd-jwt) or ISO mdoc (mso_mdoc)Signatures must support at least ES256 (P-256 + SHA-256); digests use SHA-256
Issuer key resolution must be X.509 certificate-based (
x5c); self-signed certificates are prohibited, and the trust anchor must not be included in the chain
Issuance (OpenID4VCI)
Authorization Code Flow is mandatory
FAPI 2.0 Security Profile compliance — PKCE (S256), PAR, and the
issresponse parameterDPoP is mandatory for sender-constrained access tokens
Client authentication via Wallet Attestation; Key Attestation support is mandatory
Presentation (OpenID4VP)
Response type must be
vp_token; queries must use DCQLResponse encryption is mandatory — ECDH-ES (P-256) with A128GCM/A256GCM, using an ephemeral key per request
Signed requests must use the
x509_hashClient Identifier PrefixThe redirect flow requires JAR (
request_uri),direct_post.jwt, the same-device flow, and session binding verificationThe W3C Digital Credentials API flow uses the
dc_api.jwtresponse mode
To be candid about the limits: HAIP itself states that it does not fulfil all of the requirements for eIDAS Level of Assurance "High." Trust management — authorizing Issuers and Verifiers, obtaining root certificates — remains out of scope, and extension points such as which attestation format or which X.509 certificate profile to use are deliberately left to each ecosystem. HAIP is not a master key; it is a common floor. But without that floor, nothing can be built on top of it.
3. Why Hopae Took Part in HAIP Testing
Until now there was effectively one way to confirm interoperability: plug your implementation into someone else's and see what happens.
That approach has a structural limitation. A passing test means "our interpretation and their interpretation happened to align" — not "we implemented the specification correctly." If two implementations share the same misunderstanding, the test passes cleanly. On top of that, pairwise testing demands n² combinations for n implementations. At the OpenID4VP interop event OIDF ran in May 2025, 153 of 224 possible pairings were tested. That scale is not something anyone can repeat on demand.
A conformance test suite changes the structure. The reference is the specification itself, not the other party. And it covers not only success scenarios but negative tests — whether an invalid request is properly rejected. For anyone building a Verifier, that side matters more. Accepting a valid presentation is not what a Verifier is for; not missing an invalid one is.
Hopae operates EUDI Wallet verification infrastructure serving multiple EU Member States. We needed an independent standard against which to judge whether our implementation matched the spec, and at the same time we wanted feedback from real production conditions to make its way into how that standard was built. The November 2025 interop event targeting HAIP 1.0 was the final gate before HAIP went Final, and the results and feedback from it were fed through the DCP WG into the test suites. OpenID4VP 1.0 + HAIP 1.0 recorded a 98% pass rate.
The comment we contributed to the announcement summarizes the point: what we have long needed as implementers is a way to validate conformance against the specification rather than against each other's interpretations of it. That is what makes interoperability real instead of aspirational.
4. What Comes Next
Self-certification is now open. Under OpenID4VP, implementers can certify as a Wallet or as a Verifier; under OpenID4VCI, as an Issuer or a Wallet Provider. Wallets can additionally certify against the W3C Browser API appendix of OpenID4VP. The tests themselves are free to run.
A standard does not become a standard when it exists as a document. It becomes one when independently built implementations actually mesh. We intend to keep working on closing that gap.
References
