Skip to content
ARالعربية Request a Demo
All articles

OpenID4VC HAIP 1.0 Explained: The Interoperability Profile for High-Assurance Digital Credentials

· 6 min read

In December 2025 the OpenID Foundation published the final version of the OpenID4VC High Assurance Interoperability Profile 1.0 (HAIP). If you work on national eID, mobile driving licences, digital wallets or regulated KYC, this is a specification worth understanding. It is quickly becoming the common baseline that issuers, wallets and verifiers are expected to meet when security and privacy really matter.

This post explains what HAIP is, what it requires, and how it relates to the PKI model that the travel-document world has relied on for two decades.

What HAIP is, and what it is not

HAIP is not a new protocol. It is a profile: it takes existing standards, chooses which of their many optional features must be implemented, and tightens the security requirements so that products from different vendors work together out of the box. The profiled standards are:

  • OpenID for Verifiable Credential Issuance (OpenID4VCI): how a credential gets from an issuer into a wallet
  • OpenID for Verifiable Presentations (OpenID4VP): how a wallet presents a credential to a verifier
  • IETF SD-JWT VC: a JSON-based credential format with selective disclosure
  • ISO/IEC 18013-5 mdoc: the CBOR-based format behind mobile driving licences

Its target audience includes eIDAS 2.0 implementers, the California DMV, the Open Wallet Foundation and Japan’s Trusted Web initiative, among others.

Two boundaries are important. First, HAIP alone does not make a system “Level of Assurance High” under eIDAS. It supplies the technical building blocks, which still need policy and procedural controls around them. Second, trust management is out of scope. HAIP uses X.509 everywhere, but it does not say who runs the root CAs or how they are distributed. That is left to each ecosystem.

Issuance: FAPI 2.0 security plus attestations

For issuance, HAIP requires the OAuth authorization code flow, secured according to the FAPI 2.0 Security Profile. That means:

  • PKCE with S256
  • Pushed Authorization Requests (PAR)
  • Issuer identification in the authorization response
  • DPoP sender-constrained access tokens

Credential types are requested through OAuth scope values.

On top of this, HAIP adds two attestations:

  • Wallet attestation authenticates the wallet app as an OAuth client. It proves to the issuer that it is talking to a genuine, certified wallet. For privacy, the attestation must not identify an individual installation, and it must not be reused across issuers.
  • Key attestation proves that the key the credential will be bound to was generated and is stored in secure hardware, such as a secure element or TEE. Wallets must support it.

Presentation: two paths, one secure response

HAIP defines two ways for a verifier to reach the wallet.

  • Redirect-based flow. The verifier sends a signed request (JAR) and the wallet returns an encrypted response with direct_post.jwt. In the same-device flow, the verifier must check that the user returns to the same session it started, which defeats a whole class of phishing and relay attacks.
  • W3C Digital Credentials API. A website asks the browser or operating system for a credential. The platform shows a wallet picker and supplies the verified web origin, which gives built-in phishing resistance. The response comes back encrypted with dc_api.jwt.

Some requirements apply in every case:

  • DCQL is the query language.
  • Responses are always encrypted, using ECDH-ES on P-256 with a fresh key for each request.
  • Signed requests identify the verifier with the x509_hash client identifier, a hash of its X.509 certificate.
  • Verifiers can restrict a request to credentials from specific trusted issuers using the Authority Key Identifier (AKI). Because this matches on certificate key identifiers, it works with ISO mDL VICALs, ETSI Trusted Lists or national lists alike.

Holder binding: why a copied credential is useless

A high-assurance credential has to be usable only by its rightful holder. In HAIP this is done with cryptographic holder binding:

  1. At issuance, the issuer signs the wallet’s public key into the credential (the cnf claim in SD-JWT VC).
  2. At every presentation, the wallet signs a Key Binding JWT with the matching private key.
  3. The verifier checks that signature against the key inside the credential.

The Key Binding JWT covers the verifier’s fresh nonce, the verifier’s identity and a hash of exactly the data being disclosed. This blocks replay, forwarding to another verifier, and tampering with what is disclosed. Anyone who copies the credential file still lacks the private key, which never leaves secure hardware.

For readers from the ePassport world, this is the same idea as Active Authentication: the public key is protected by the issuer’s signature (as DG15 is protected by the SOD), and the holder proves possession by signing a fresh challenge.

Revocation, crypto and the familiar PKI pattern

For SD-JWT VC, revocation uses the IETF Token Status List. Each credential has its own random index, so verifiers checking status cannot correlate users.

All parties must support ES256 (ECDSA P-256 with SHA-256) and SHA-256 digests as a minimum. Ecosystems may add other algorithms.

Across the specification, one rule is repeated for every signed object: credentials, status lists, wallet and key attestations, signed metadata and verifier requests.

  • The signing certificate travels in the x5c header.
  • The root certificate is never included; the receiver must already trust it.
  • The signing certificate must not be self-signed.

Anyone who has worked with ICAO 9303 will recognise the pattern immediately. The trust anchor plays the role of the CSCA, the issuer signing certificate plays the role of the Document Signer, and the trusted issuer list plays the role of the master list.

What HAIP leaves to the ecosystem

HAIP deliberately leaves a set of decisions to each deployment:

  • which flows to support
  • SD-JWT VC, mdoc or both
  • Digital Credentials API, redirects or both
  • how credential offers are delivered
  • which wallet and key attestation formats to use
  • the X.509 certificate profiles
  • any additional cryptography

The biggest open area is the trust framework itself: who operates the issuer, verifier and wallet-provider CAs, how verifiers are registered, and what each verifier is allowed to request. The EU fills this gap with access certificates and registration certificates defined by ETSI. National programmes outside the EU need to make equivalent decisions of their own.

Two of the referenced specifications, SD-JWT VC and Token Status List, were still drafts when HAIP was finalised. HAIP pins specific versions of each so that implementations stay stable. The OpenID Foundation also provides conformance test suites for both issuance and presentation, which are the practical way to demonstrate compliance.

Why it matters

For governments and regulated industries, HAIP turns a large and flexible family of standards into a concrete, testable baseline. Issuers, wallet providers and relying parties can build to one profile instead of negotiating dozens of options bilaterally. Because it keeps X.509 at its core, it can be built on the same PKI governance, HSM practices and audit regimes that already protect passports and national ID cards.

At T4Trust we work on national identity and document systems, from ePassport and eID issuance to PKI and biometric integration. We follow HAIP closely as digital credentials move from pilots to national deployments. If you are planning a wallet, issuer or verifier programme and want to discuss architecture or trust-framework design, get in touch.

Reference: OpenID4VC High Assurance Interoperability Profile 1.0, OpenID Foundation, December 2025.

Latest from the blog