#OpenID4VC HAIP Profile: A Developer's Guide to High-Assurance Digital Credentials

In the rapidly evolving world of digital identity, interoperability and security are often at odds. Different wallets, issuers, and verifiers implement the same specifications in subtly different ways, leading to fragmentation and security gaps. The OpenID4VC High Assurance Interoperability Profile (HAIP) v1.0 solves this problem by defining a strict, security-focused profile that ensures all parties in a credential ecosystem speak the same language—and speak it securely.

This guide provides a comprehensive walkthrough of HAIP v1.0: what it is, what it enforces, and why it's becoming the foundation for high-assurance digital identity ecosystems worldwide.

#What is the HAIP Profile? (The Simple Explanation)

HAIP (High Assurance Interoperability Profile) is a technical specification published by the OpenID Foundation that defines a strict subset of the OpenID for Verifiable Credentials (OpenID4VC) specifications. Think of it as a "security-hardened configuration" for digital credential systems.

While OpenID4VCI and OpenID4VP define flexible protocols with many optional features, HAIP takes these specifications and says: "If you want high security and guaranteed interoperability, here's exactly what you MUST implement."

The profile was approved as a Final Specification by the OpenID Foundation membership on December 24, 2025, with 87 approval votes. It successfully passed interoperability testing in November 2025, achieving 98% passing rates on credential presentation workflows—demonstrating that the specification delivers on its promise of interoperability.

#TL;DR:

HAIP is a security-focused profile of OpenID4VCI and OpenID4VP
It mandates specific credential formats: SD-JWT VC and ISO mdoc
It requires FAPI 2.0 security controls, including DPoP and PKCE
It enforces X.509 certificate-based trust for issuer and verifier authentication
It's designed for ecosystems requiring high security and privacy, including eIDAS 2.0 implementations

#Why Does HAIP Exist? The Problem It Solves

#The Interoperability Challenge

Digital identity specifications like OpenID4VCI and OpenID4VP are intentionally flexible. They support multiple credential formats, various authentication methods, and numerous optional features. This flexibility is valuable for adoption, but it creates a problem: two implementations can both be "compliant" with the specification yet completely unable to communicate with each other.

Consider a scenario where:

Wallet A supports only SD-JWT VC credentials with jwk binding
Wallet B supports only ISO mdoc credentials
Issuer X uses unsigned metadata and pre-authorized code flow
Issuer Y requires signed metadata and authorization code flow with PAR

All four implementations might be valid according to the base specifications, but they can't interoperate. This fragmentation undermines the entire value proposition of standardized digital credentials.

#The Security Gap

Beyond interoperability, the base specifications allow configurations that may not meet the security requirements of high-assurance use cases. For example:

Optional encryption of responses could be skipped
Weak cryptographic algorithms might be used
Trust establishment mechanisms could be inconsistent

HAIP addresses both challenges by defining a mandatory baseline that ensures both interoperability and security.

#Core Security Goals of HAIP

HAIP v1.0 targets two primary security properties that are essential for high-assurance digital identity:

#1. Authenticity of Claims

There must be strong assurance that the claims within a Credential or Presentation are valid and bound to the correct Holder. This encompasses:

Issuance Security: The process by which credentials are created and delivered must be secure
Credential Protection: Credentials must be protected both at rest (in the wallet) and during presentation
Issuer Trust: Verifiers must have access to trustworthy information about the Issuer to validate credentials

#2. Holder Authentication

There must be strong assurance that the Credential is presented by its legitimate Holder in a given transaction. This involves:

Proof of Holder Binding: Cryptographic proof that the presenter controls the key bound to the credential
Claim-based Binding: Support for additional binding mechanisms built on top of cryptographic binding

These security goals directly address the most critical threats in digital identity systems: credential theft, impersonation, and unauthorized disclosure.

#What HAIP Enforces: The Technical Requirements

HAIP v1.0 profiles four core specifications and defines mandatory requirements for each. Let's examine what the profile enforces across the credential lifecycle.

#Credential Formats: SD-JWT VC and ISO mdoc

HAIP mandates support for at least one of two credential formats:

IETF SD-JWT VC (Selective Disclosure JWT Verifiable Credentials):

Compact serialization MUST be supported
The cnf claim MUST include a JWK for cryptographic holder binding
Status management via Token Status List is required when using the status claim
X.509 certificate chain MUST be included in the x5c JOSE header for issuer key resolution

ISO mdoc (Mobile Document as defined in ISO/IEC 18013-5):

Used for mobile Driver's Licenses (mDL) and similar documents
DeviceResponse structure for presentations
MSO revocation mechanisms as defined in ISO/IEC 18013-5

Both formats support selective disclosure, allowing holders to share only the specific claims required for a transaction—a fundamental privacy feature.

#OpenID4VCI Requirements (Credential Issuance)

For credential issuance, HAIP enforces:

Authorization Flow:

Authorization code flow MUST be supported
PKCE with S256 challenge method is REQUIRED
Pushed Authorization Requests (PAR) MUST be used when using the Authorization Endpoint
DPoP (Demonstrating Proof of Possession) MUST be supported for sender-constrained access tokens

Wallet Attestation:

Wallets MUST authenticate at OAuth2 endpoints using Wallet Attestation
Attestations MUST NOT be reused across different Issuers (preventing tracking)
X.509 certificates MUST be used for attestation validation

Key Attestation:

Wallets MUST support key attestations to prove key properties
The jwt proof type with key_attestation and attestation proof type are supported
X.509 certificates validate key attestation signatures

Issuer Metadata:

Credential Issuer metadata MUST include a scope for every Credential Configuration
When higher assurance is required, signed Credential Issuer Metadata MUST be supported
X.509 certificate-based key resolution for metadata validation

#OpenID4VP Requirements (Credential Presentation)

For credential presentation, HAIP enforces:

Request Authentication:

Verifiers MUST use the x509_hash Client Identifier Prefix for signed requests
X.509 certificates authenticate the Verifier to the Wallet
Self-signed certificates are NOT allowed

Query Language:

DCQL (Digital Credentials Query Language) MUST be used for credential requests
Authority Key Identifier (AKI)-based Trusted Authority Query MUST be supported

Response Encryption:

Response encryption is MANDATORY
ECDH-ES with P-256 curve for key agreement
A128GCM and A256GCM encryption algorithms
Ephemeral encryption keys specific to each request

Same-Device Flow:

Verifiers and Wallets MUST support same-device flow
Redirect back to Verifier is REQUIRED for session binding
Verifiers MUST reject presentations if redirect is not followed

W3C Digital Credentials API:

Support for browser-based credential presentation via DC-API
Response mode dc_api.jwt MUST be supported
Unsigned, signed, and multi-signed requests are supported

#Cryptographic Requirements

HAIP mandates specific cryptographic algorithms to ensure consistent security:

Digital Signatures:

ECDSA with P-256 and SHA-256 (ES256) MUST be supported at minimum
COSE algorithm identifiers -7 or -9 for mdoc contexts

Hash Algorithms:

SHA-256 MUST be supported for all digest operations

Key Sizes:

Implementations must follow guidance from NIST SP 800-131A, NIST SP 800-57, or BSI TR-02102-1

#HAIP and eIDAS 2.0: The Regulatory Connection

One of the most significant drivers for HAIP adoption is the European Union's eIDAS 2.0 regulation, which mandates that by 2026, every EU member state must offer a European Digital Identity Wallet (EUDI Wallet).

HAIP is explicitly designed to support eIDAS 2.0 implementations. The specification notes:

"This specification fulfils some, but not all, of the requirements to meet the 'High' Level of Assurance (LoA) as defined in the eIDAS Regulation. While this specification defines features intended for scenarios targeting a high level of security, these features must be combined with additional measures outside of the scope of HAIP to achieve LoA High compliance."

This means HAIP provides the technical foundation for eIDAS 2.0 compliance, but ecosystems must layer additional policy and procedural requirements on top.

#Trust Establishment

At the foundation, HAIP uses X.509 PKI (Public Key Infrastructure) for trust establishment across all parties:

Issuer Trust: Credentials include the issuer's X.509 certificate chain in the x5c header, allowing verifiers to validate the issuer's identity against trusted root certificates
Verifier Trust: Presentation requests are signed with X.509 certificates, allowing wallets to verify the verifier's identity before sharing credentials
Wallet Trust: Wallet Attestations prove the wallet's authenticity to issuers, preventing rogue applications from obtaining credentials
Key Trust: Key Attestations prove that cryptographic keys are properly protected (e.g., in secure hardware)

#Credential Protection

HAIP ensures credentials are protected throughout their lifecycle:

At Issuance: DPoP tokens prevent token theft; Wallet Attestation ensures only legitimate wallets receive credentials
At Rest: Holder binding ensures credentials are cryptographically bound to keys the holder controls
At Presentation: Response encryption prevents eavesdropping; session binding prevents phishing

#Ecosystem Extension Points

HAIP intentionally leaves certain decisions to ecosystems, recognizing that different contexts have different requirements:

Extension Point	Options
Flows	Presentation only, issuance only, or both
Presentation Method	DC-API, redirects with custom URL schemes, or claimed HTTPS URIs
Credential Format	SD-JWT VC, ISO mdoc, or both
Issuer Metadata	Signed or unsigned
Credential Offer Delivery	QR code, deep link, or other mechanisms
Attestation Formats	HAIP-defined or ecosystem-specific
X.509 Profiles	Ecosystem-defined certificate policies
Additional Crypto	Ecosystem may mandate additional algorithms

This flexibility allows HAIP to serve as a foundation that ecosystems can build upon while maintaining baseline interoperability.

#Practical Implementation Considerations

#Custom URL Schemes

HAIP defines two custom URL schemes for wallet invocation:

haip-vci:// - For credential issuance flows
haip-vp:// - For credential presentation flows

These schemes allow verifiers and issuers to invoke HAIP-compliant wallets directly.

#Real-World HAIP Use Cases

#Government Digital Identity

A national government implementing digital identity cards can use HAIP to ensure:

All approved wallets meet security requirements via Wallet Attestation
Citizens can present credentials to any compliant verifier
Credentials cannot be stolen or impersonated due to holder binding
Privacy is protected through selective disclosure

#Financial Services KYC

Banks implementing digital KYC can use HAIP to:

Receive cryptographically verified identity attributes
Trust that credentials come from authorized issuers via X.509 trust chains
Ensure presentations are encrypted and session-bound
Meet regulatory requirements for identity verification

#Cross-Border Credential Recognition

International credential recognition (e.g., EU-US driver's license verification) can use HAIP to:

Establish mutual trust through X.509 certificate hierarchies
Ensure consistent security regardless of issuing country
Support both SD-JWT VC and ISO mdoc formats for flexibility

OpenID4VCI - Understand the credential issuance protocol that HAIP profiles
OpenID4VP - Learn about the presentation protocol and DCQL queries
DC-API - Explore browser-based credential presentation supported by HAIP
SD-JWT VC - Deep dive into the SD-JWT VC credential format
ISO mdoc - Learn about the ISO mobile document format

#Additional Resources

HAIP v1.0 Final Specification - The official specification document
OpenID Foundation HAIP Announcement - Official announcement of HAIP 1.0 approval
HAIP GitHub Repository - Source repository for the specification
OIDF Interoperability Testing Results - Results from the November 2025 interop event

Last updated on April 8, 2026

What is the Digital Credentials API? The Developer's Guide (2026)Getting Started