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) protocol 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 is a flexible protocol 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 without negotiation or fallback logic.

What HAIP constrains​

HAIP defines requirements across several areas of the verification flow:

  • 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.

How the connector implements HAIP​

The Truvity EUDIW Connector implements the HAIP profile by default. When you create a presentation request, 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.

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.

HAIP and the EUDI Wallet ecosystem​

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

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​