HAIP makes wallet interoperability a conformance test, not guesswork

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Hopae's blog post: HAIP narrows OpenID4VC implementation choices and makes interoperability depend on conformance testing rather than bilateral guesswork.

Why it matters: Identity teams need to treat wallet interoperability as a governed verification surface, because optional protocol choices can break trust even when implementations are individually compliant.

By the numbers:

• HAIP 1.0 reached final specification status on 24 December 2025, giving regulators a named interoperability profile to reference.
• The OpenID4VP interop event tested 153 of 224 possible pairings, showing how quickly pairwise testing becomes difficult to scale.
• OpenID4VP 1.0 plus HAIP 1.0 recorded a 98% pass rate, showing that conformance can be measured rather than assumed.

Context

Wallet interoperability fails when two implementations are individually correct but still make different choices about credential formats, signing, key resolution, or response handling. In digital identity, that gap matters because trust depends on both parties following the same rules, not just on each side meeting its own checklist.

OpenID4VC narrows the problem space for issuance and presentation, while HAIP adds a high-assurance profile that removes much of the optionality that normally causes integration drift. That is the right direction for national identity ecosystems, where even small implementation differences can become a verification failure.

The governance question is whether interoperability is being treated as a test outcome or as a production control. For identity programmes, the answer should be the latter.

Key questions

Q: How does OpenID4VC interoperability fail between compliant implementations?

A: Interoperability fails when two implementations make different valid choices about credential formats, signing algorithms, request handling, or trust resolution. Each side can still be spec-compliant, but the pair will not necessarily work together. The practical fix is a shared interoperability profile plus conformance testing against the specification, including negative tests that verify invalid messages are rejected.

Q: Why do verifiable credential wallets need conformance testing?

A: Verifiable credential wallets need conformance testing to prove they implement the required data formats, cryptographic checks, and protocol steps consistently. It catches failures in DID handling, presentation verification, selective disclosure, and issuer or verifier interoperability before production, where mismatched implementations can break authentication or acceptance of credentials.

Q: What is the difference between OpenID4VCI and OpenID4VP?

A: OpenID4VCI is the issuance flow for getting a verifiable credential into a wallet, while OpenID4VP is the presentation flow for sending a credential or proof from a wallet to a verifier. The first covers credential acquisition, issuer metadata, and binding; the second covers request handling, consent, and proof presentation.

Q: Where does interoperability testing stop covering digital identity wallets?

A: Interoperability testing stops at the defined wallet protocol and format boundary, so it does not cover the full user experience, business policy, trust framework rules, or every issuer and verifier implementation choice. It usually checks whether wallets can issue, store, present, and verify the agreed credential types and message flows.

Technical breakdown

Why optionality breaks OpenID4VC interoperability

OpenID4VC is not one protocol but a family: OpenID4VCI handles issuance into wallets, while OpenID4VP handles presentation from wallets to verifiers. The specifications intentionally leave room for different formats, algorithms, flows, and client-authentication methods. That flexibility supports adoption, but it also creates interoperability drift when two teams make different valid choices. HAIP reduces that drift by constraining the allowed combinations for high-assurance deployments, so the parties can implement to the same baseline rather than negotiate one during integration. Read the Ultimate Guide to NHIs: Standards.

Practical implication: Standardise the approved protocol profile before rollout so issuance and presentation teams are building to one interoperability baseline.

How conformance testing differs from pairwise interop

Pairwise interoperability testing checks whether one implementation can talk to another, but it can hide shared misunderstandings. If both systems interpret a requirement the same wrong way, the test still passes. Conformance testing reverses that logic by comparing implementation behaviour against the specification itself, and by including negative tests that verify invalid requests are rejected. For verifiers, those negative cases matter as much as successful presentation flows because acceptance logic is part of the trust boundary.

Practical implication: Use specification-based conformance tests, not only partner-to-partner integration tests, before declaring a wallet or verifier ready.

What HAIP fixes in high-assurance wallet flows

HAIP is a profile, not a new protocol. It tightens choices around credential formats, cryptographic algorithms, X.509-based issuer trust, mandatory DPoP, wallet attestation, and encrypted presentation responses. That matters because high-assurance environments need fewer degrees of freedom, not more. HAIP does not solve trust anchor governance or every requirement for the highest eIDAS assurance level, but it creates a common floor that ecosystems can use to reduce integration ambiguity before they add local policy on top. See the Relying Party Integration with Digital Identity Wallets Guide.

Practical implication: Treat HAIP as the minimum interoperable baseline and build trust-anchor governance separately around issuer and verifier onboarding.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HAIP converts interoperability from a compatibility exercise into a governance control. Once a digital identity ecosystem allows many technically valid combinations, implementation differences become a policy problem rather than a coding problem. That is why profile-based standardisation matters for wallet ecosystems: it reduces the room for silent divergence and makes verification behaviour predictable. Practitioners should see the profile as a control for reducing trust ambiguity across issuers, wallets, and verifiers.

Specification compliance is not enough when the verification boundary is shared across ecosystems. The article shows that two 100% compliant implementations can still fail to interoperate, which is exactly the kind of failure that creates operational friction in national wallet programmes. In identity governance terms, that means the control objective is not just correctness in isolation but repeatability across independent parties. Teams should evaluate interoperability as a lifecycle control, not a one-time certification event.

Conformance testing is now the real assurance layer for wallet ecosystems. Pairwise testing can prove a specific connection works, but it cannot prove a broader ecosystem will behave consistently under change. A conformance suite shifts assurance toward the specification, which is where durable governance belongs. That makes verification behaviour auditable across implementations and reduces the chance that shared mistakes masquerade as interoperability.

OpenID4VC interoperability now depends on a narrower trust vocabulary. HAIP does not eliminate trust management, but it does define which cryptographic and protocol decisions must be consistent for high-assurance exchange. That narrowing is valuable because identity ecosystems fail most often at the seams, where trust assumptions are left implicit. Practitioners should treat profile selection as part of identity architecture, not as an implementation footnote.

Interoperability failure in wallet ecosystems is a form of identity governance debt. Every unresolved choice about formats, flows, attestations, or key resolution becomes future friction for issuers, wallets, and verifiers. The debt is not only technical; it is organisational, because each participant can remain correct locally while the ecosystem remains unreliable globally. The practical response is to govern the ecosystem profile early, then validate it continuously.

What this signals

Interoperability profiles will become a governance gate, not a documentation appendix. As wallet ecosystems scale, the real question is whether every participant is building to the same constrained profile. Programmes that rely on loose interpretation will see more verification friction, more failed integrations, and more time spent resolving mismatched assumptions. Teams should expect profile selection to move earlier in architecture reviews and procurement decisions.

Conformance assurance is becoming the control that replaces handshake optimism. The old model assumed that if two parties could exchange messages once, the integration was sound enough. That assumption breaks down in multi-party identity ecosystems, where behaviour must stay consistent across upgrades, vendors, and jurisdictions. Practitioners should plan for continuous regression testing against the specification, not just one-off partner validation.

Wallet ecosystems need a narrower trust vocabulary before they can support broad federation. The more optionality remains in cryptography, client authentication, and response handling, the more local exceptions accumulate. That creates operational fragility even when the underlying standard is strong. Identity teams should treat profile governance, not implementation enthusiasm, as the factor that determines whether interoperability survives production change.

For practitioners

• Define a single wallet interoperability profile Lock down supported credential formats, response modes, signature algorithms, and key-resolution rules before implementation teams diverge on local preferences.
• Adopt specification-based conformance testing Test against the protocol specification and negative cases, not only against one partner implementation, so shared misunderstandings do not pass as success.
• Separate trust governance from protocol choice Treat issuer onboarding, verifier authorisation, and root-certificate governance as a distinct control plane rather than assuming the protocol profile covers it.
• Validate wallet attestation requirements early Check that wallet attestation, client authentication, and sender-constrained token handling are supported before production onboarding begins.

Key takeaways

• OpenID4VC interoperability fails most often when compliant implementations choose different allowed options, so profile governance matters as much as protocol design.
• Pairwise testing can hide shared misunderstandings, which is why specification-based conformance tests are the stronger assurance model for wallet ecosystems.
• HAIP narrows the implementation surface for high-assurance exchanges, but trust-anchor governance still has to be handled separately.

Related NHI Mgmt Group resources: OpenID for Verifiable Presentations Guide · Relying Party Integration with Digital Identity Wallets Guide · Ultimate Guide to NHIs: Standards · OAuth Attestation-Based Client Authentication Guide

Key terms

• OpenID4VC: OpenID4VC is a family of specifications for issuing, presenting and verifying verifiable credentials using OpenID-style flows. It defines how wallets, issuers and verifiers exchange credential data with standardised protocols, so identity proofing and attribute sharing can work across different systems.
• OpenID4VCI: OpenID4VCI is the protocol used for verifiable credential issuance. It defines how a wallet requests a credential from an issuer, how client settings are established, and how the resulting credential is delivered in a standardised way that can be integrated across different identity systems.
• OpenID4VP: OpenID4VP is the protocol used for verifiable credential presentation. It lets a wallet respond to a verifier’s request by presenting an appropriate credential, while supporting trust configuration so the wallet can determine which verifier endpoints and keys it should accept.
• Verifiable Credentials (VCs): Verifiable Credentials are digital statements that prove a claim about a person, device, or service without exposing unnecessary underlying data. They use cryptographic signatures and standardized presentation rules so a relying party can check authenticity, integrity, and issuer trust, supporting privacy-preserving identity verification across human and non-human identity flows.

Deepen your knowledge

NHI Foundation Level course covers NHI governance, machine identity security, and workload identity alongside the control patterns that support digital identity ecosystems. It helps practitioners translate protocol choices into governance decisions across identity programmes.