How does OpenID4VC interoperability fail between compliant implementations?

Why compliant OpenID4VC implementations still fail to interoperate

OpenID4VC interoperability breaks when two implementations choose different but still valid options inside the specification. The usual fault line is not basic compliance, but mismatched profile decisions around formats, cryptographic choices, request semantics, or how trust is resolved. The result is a pair of implementations that each pass their own checks, yet still cannot complete a transaction reliably.

That is why “spec-compliant” and “interoperable” are not the same thing. Compliance says an implementation stays within allowed behaviour; interoperability requires two implementations to make compatible choices within that allowed space. In practice, the gap is closed by a shared profile that narrows optionality enough for both sides to behave consistently, then by conformance testing that exercises both expected and invalid flows.

One useful way to think about the problem is that OpenID4VC is a coordination standard as much as a protocol standard. If two wallet or issuer implementations differ on which credential representation they prefer, how they validate signatures, or how strictly they interpret a request parameter, each side can remain correct in isolation while still failing at the boundary.

Where compatible choices become incompatible behaviour

The most common failure mode is divergence in what each implementation treats as acceptable default behaviour. One side may support multiple credential formats, another may support only a subset; one may accept a broader set of signing algorithms, another may require a narrower one. Even when both are following the spec, the overlap may be too small for real-world exchange.

Request handling is another frequent source of failure. Small differences in how implementations parse, order, or validate request objects can cause one party to reject a message the other party believes is valid. The same pattern appears in trust resolution, where each side may resolve issuer, verifier, or metadata trust in a different but defensible way. In a distributed ecosystem, these differences matter more than they would in a single integrated stack.

Interoperability also fails when the profile is underspecified. If the standard leaves room for several legitimate options but no profile says which combination to use, implementers will make local decisions that are reasonable on their own. The mismatch only appears when two independently reasonable choices collide during live exchange.

What a shared profile and conformance testing need to prove

A shared interoperability profile should reduce ambiguity without trying to rewrite the standard. Its job is to specify the common subset that participants must implement, especially where multiple valid choices otherwise fragment the ecosystem. That usually means pinning down supported formats, required algorithms, mandatory request behaviour, and the trust assumptions that both parties will use.

Conformance testing then proves two things: that the implementation accepts what it should accept, and that it rejects what it should reject. The negative tests matter as much as the positive ones because they expose whether implementations are silently tolerant in ways that another compliant peer will not be. For interoperability, “lenient enough to pass locally” can be a defect.

Testing should therefore include cross-implementation exchange, not only self-tests against the local codebase. A system can appear compliant when tested against a single interpretation of the spec and still fail when paired with a different implementation that chooses another valid path.

Risk and Threat Considerations

Interoperability gaps create operational risk because the failure often appears only when two independently compliant parties meet in production. That makes the issue hard to spot in pre-release testing and easy to misdiagnose as a local bug, especially when the failure is caused by a valid but different interpretation rather than an obvious protocol error.

Failure mechanism: Each implementation selects a different acceptable option for formats, algorithms, request validation, or trust handling, so the intersection of supported behaviour becomes too small for the exchange to succeed.

Impact: Transactions fail unpredictably, integration efforts stall, and teams may overcorrect by loosening validation or adding ad hoc exceptions that reduce assurance across the ecosystem.

Practitioner Guidance

What to prioritise: Define the interoperability profile before scaling integrations. If you are joining multiple issuers, wallets, or verifiers, agree the supported credential formats, signing suites, request rules, and trust sources up front rather than relying on “spec-compliant” as a sufficient contract.

What to verify: Test the exact pairings you intend to run in production, then add negative cases that confirm invalid or out-of-profile messages are rejected. That is the fastest way to expose hidden assumptions about parsing tolerance, algorithm support, and trust resolution.

Practitioner takeaway: The practical standard for OpenID4VC is not “does this implementation conform in isolation?” but “do these two implementations share enough of the same valid choices to work together safely and predictably?”

Related resources from NHI Mgmt Group

• Why do MFA implementations still fail even when a second factor is enabled?
• Why do digital identity programmes fail when interoperability is weak?
• Why do GCC High MFA implementations fail when commercial Microsoft guidance is copied over?
• Why does interoperability fail in national PKI deployments?