Skip to main content

High Assurance Interoperability Profile (HAIP)

When multiple wallet providers, attestation providers, and Relying Parties implement the same protocol, small differences in how they interpret optional features can break interoperability. The High Assurance Interoperability Profile (HAIP) solves this by narrowing the choices available in the OpenID for Verifiable Presentations (OID4VP) and OpenID for Verifiable Credential Issuance (OID4VCI) protocols to a single, well-defined path that all participants follow.

The specific version referenced by the Architecture Reference Framework (ARF) is OpenID4VC High Assurance Interoperability Profile 1.0.

Why HAIP matters​

OID4VP and OID4VCI are flexible protocols with many optional parameters, credential formats, and transport mechanisms. This flexibility is useful for experimentation, but it creates a problem for production deployments: two implementations that both "support OID4VP" might not work together if they made different choices about which options to use.

HAIP eliminates this ambiguity. By specifying exactly which credential formats, proof mechanisms, and transport options to use, HAIP ensures that any compliant wallet can interact with any compliant Relying Party or credential issuer without negotiation or fallback logic.

What HAIP constrains​

HAIP defines requirements across both credential verification and credential issuance.

Verification (OID4VP)​

  • Credential format—HAIP mandates SD-JWT VC with key binding as the credential format for remote presentations. Every credential presentation must include cryptographic proof that the presenter holds the credential's private key. This ensures that credentials cannot be replayed by unauthorized parties.
  • Query language—HAIP mandates Digital Credentials Query Language (DCQL) as the query language for specifying which credentials and claims a Relying Party needs. This replaces older query mechanisms with a single standardized approach.
  • Request transport—HAIP requires signed request objects, which the wallet verifies before responding. Request objects may also be optionally encrypted for additional confidentiality. The wallet authenticates the Relying Party and confirms the integrity of the request before disclosing any credentials.
  • Response transport—HAIP mandates a response mode that ensures encrypted delivery of credentials back to the Relying Party. The wallet encrypts the presentation response so that only the requesting Relying Party can read it, protecting credential data in transit.

HAIP also profiles the presentation of ISO/IEC 18013-5-compliant (mDoc) attestations over OID4VP for remote flows, in addition to SD-JWT VC. The connector currently focuses on SD-JWT VC presentations.

Issuance (OID4VCI)​

  • Credential format—HAIP requires support for at least one of SD-JWT VC or mDoc as the credential format for issuance. The connector implements SD-JWT VC, the same format used for verification. This ensures credentials are issued in a format that any HAIP-compliant Relying Party can verify.
  • Token binding—HAIP requires DPoP (Demonstrating Proof-of-Possession) to bind access tokens to the wallet's key pair. This prevents token theft and replay attacks during the issuance exchange.
  • Key resolution—HAIP mandates X.509 certificate chains for issuer key resolution, allowing wallets to verify the issuer's identity through a trust chain rather than pre-shared keys.
  • Cryptographic holder binding—every issued credential must bind to the wallet's key pair, ensuring only the legitimate holder can present the credential later.

How the connector implements HAIP​

The Truvity EUDIW Connector implements the HAIP profile by default for both verification and issuance flows. When you create a presentation request or a credential offer, the connector automatically applies HAIP-compliant settings. This means you don't need to manually configure protocol options or worry about compatibility with different wallet implementations.

For verification, the connector handles:

  • Generating signed authorization requests that wallets can verify.
  • Accepting SD-JWT VC credential presentations with key binding proof.
  • Validating credential integrity and proof of possession.
  • Delivering results through the encrypted response mechanism defined by the profile.

For issuance, the connector handles:

  • Issuing credentials in SD-JWT VC format with cryptographic holder binding.
  • Enforcing DPoP token binding throughout the issuance exchange.
  • Resolving issuer identity through X.509 certificate chains.

HAIP and the EUDI Wallet ecosystem​

The European Digital Identity Wallet ecosystem relies on HAIP as the baseline interoperability profile. Member state wallet implementations, certified Relying Parties, and credential issuers are expected to support HAIP, making it the common language for cross-border credential exchange.

By building on HAIP, the connector ensures compatibility with wallets from different member states and different wallet providers, without requiring you to handle protocol-level differences in your integration.

Further reading​