Interoperability Is Not a Standards Checklist

One of the easiest things to say about a technology deployment is that it is standards based. It is such a reassuring phrase. Standards should make systems easier to connect, reduce dependence on a single vendor, and give organizations some confidence that what they build today will still have options tomorrow. The problem is that implementing a standard does not necessarily mean two systems will interoperate.

Anyone who has spent enough time around standards has seen this happen. Two vendors support the same protocol. Both implementations pass their own tests. Both can point to the same specification. Then someone tries to connect them and discovers that they made different choices about optional features, profiles, metadata, trust, discovery, identifiers, or the exact point where one specification hands work off to another.

The standard may be doing exactly what it was designed to do. The gap is often somewhere around it. We need to keep that in mind as identity architecture becomes more distributed and more dependent on combinations of standards.

A Specification Only Solves the Problem It Was Written to Solve

Standards documents are deliberately scoped. For example, the World Wide Web Consortium’s (W3C) Verifiable Credentials Data Model 2.0 describes a data model for credentials and presentations and the roles of issuers, holders, and verifiers. OpenID for Verifiable Presentations 1.0 describes a protocol for requesting and presenting credentials. It can carry several credential formats and can be used with the web's Digital Credentials Application Programming Interface (API). The W3C Digital Credentials API gives websites a browser-mediated way to request issuance or presentation of digital credentials while trying to protect the holder from unnecessary disclosure. It explicitly leaves a great deal of functionality outside the API itself.

Each specification can be useful and well-designed while still leaving significant decisions to implementers and ecosystem profiles. Standards bodies scope their work this way by design. A specification that attempted to settle every deployment decision would probably become unusable.

Trouble often starts when organizations mistake the existence of the specification for the resolution of the entire interoperability problem.

Optionality Adds Up

Standards need extensibility and optional features because different environments have different requirements. A specification that is rigid enough to cover only one deployment model will not travel very far. The downside to that flexibility, however, is the cost: Every optional feature becomes another potential point of disagreement.

Format neutrality is a deliberate strength of the OpenID specifications for verifiable credentials. It allows issuers and verifiers to support the different formats in use in Europe and the US. Each ecosystem must still agree on the formats its participants accept.

One implementation supports one credential format; another supports three. One requires a particular client authentication mechanism; another treats it as optional. One ecosystem defines issuer trust through a curated list; another expects trust to be established through federation metadata or bilateral configuration.

None of these implementations necessarily violates the relevant specification. They may still fail to work together.

OAuth provides plenty of examples. Over the years, profiles have developed around OAuth precisely because "supports OAuth" does not tell an implementer enough about how a particular deployment behaves. Standards such as OAuth 2.0 Authorization Server Metadata help clients discover server capabilities and endpoint information. More recent work, such as OAuth 2.0 Protected Resource Metadata, continues to make relationships between authorization servers and protected resources more explicit.

Those standards improve interoperability because they reduce the amount of information that has to be configured or guessed. They do not eliminate the need for deployment agreements.

Profiles Do a Lot of the Real Work

A profile takes a general-purpose standard and narrows it for a particular environment. Some security profiles, such as the Financial-grade API (FAPI) profile, also make mechanisms from other specifications mandatory. A profile might say which algorithms are allowed, which options must be supported, which metadata is required, how identifiers are constructed, which credential formats may be used, or how trust is established. That narrowing can sound unglamorous, but this is where a large amount of practical interoperability comes from.

The European Digital Identity (EUDI) Wallet Architecture and Reference Framework is a useful example. It describes an ecosystem with wallet providers, relying parties, credential providers, trust anchors, trusted lists, certification requirements, and operational rules.

Supporting one of the underlying technical standards does not automatically make a product interoperable with the EUDI Wallet ecosystem. The surrounding profile and trust framework determine what "support" means in practice.

The same pattern appears elsewhere in identity.

Enterprises regularly discover that a standard protocol gets them to the point where systems can exchange messages. That still leaves questions about whether they agree on the meaning of those messages and whether each side is willing to trust the other.

Trust Is Often Outside the Protocol

This is probably the part that receives the least attention when organizations evaluate interoperability claims.

A verifier may be technically capable of validating a credential. That does not tell the verifier whether it should accept the issuer. An OAuth resource server may be capable of validating a token. It still needs to know whether that authorization server is trusted to issue tokens for that resource. A browser may mediate a federated identity interaction, but the organizations involved still have relationships, policies, and expectations that exist beyond the browser API. Many standards are intentionally neutral about these decisions because the answers depend on governance.

Verifiable credentials allow a verifier to accept a credential without any direct relationship with the issuer. The verifier still relies on some form of governance to decide which issuers to accept. The EUDI Wallet architecture makes that particularly visible by describing trusted lists and relationships among ecosystem participants. The European Commission’s own interoperability testing in December 2025 found that onboarding to the EUDI trust framework remained a weak point. Use of the available trusted lists was also limited. Other ecosystems may use contracts, federation metadata, certificate hierarchies, regulatory status, preconfigured trust anchors, or some combination of these. Organizations evaluating a "standards-based" solution should therefore ask a second question: What establishes trust between participants?

If the answer is "manual configuration," that may be perfectly acceptable. It is simply a different interoperability story from one based on dynamic federation or an ecosystem-wide trust framework.

Discovery Deserves More Attention

Before two systems can interoperate, they have to find each other and determine what the other side supports. We call that the discovery problem, and while discovery is sometimes treated as straightforward, it is a critical part of interoperability.

OAuth authorization server metadata lets clients discover endpoints and supported capabilities. OpenID Connect has similar mechanisms. Digital credential ecosystems are developing their own approaches for communicating verifier, issuer, and wallet capabilities.

Without good discovery, implementers fall back to configuration. Configuration works, particularly in smaller environments, but it scales poorly and creates another source of drift.

Discovery also creates its own security questions. Who publishes the metadata? How does the relying party know it is authentic? What happens when capabilities change? Can a client safely follow information obtained from a newly discovered service?

Interoperability depends on more than agreeing on the syntax of the messages exchanged after two systems have connected.

Conformance Testing Helps, But It Cannot Test Everything

Good conformance testing is one activity that is often offered as a way to solve the interoperability problem, and yet it is really more in the “necessary but not sufficient” category.

OpenID four Verifiable Presentations (OpenID4VP), for example, has conformance testing for wallets and verifiers. That gives implementers a common baseline and catches many of the kinds of subtle interpretation differences that otherwise appear only during integration.

Conformance testing, however, is still testing against a defined target. If an ecosystem profile has not defined a behavior, conformance testing cannot magically create agreement about it. If two implementations choose different optional features that are both allowed, both may pass.

Interoperability testing goes a step further by asking whether independently developed implementations actually work together. Mature ecosystems usually need both.

The Seams Between Standards Are Where Things Get Interesting

Modern identity systems increasingly depend on stacks rather than individual protocols. This is a feature, not a bug, despite the challenges it introduces with practical interoperability. Layering keeps each specification focused on a single job, but it also creates practical interoperability challenges.

A deployment might use one specification for credential format, another for presentation, another for transport through the browser, another for cryptographic proof, and yet another mechanism for establishing trust. The difficult engineering decisions often appear at the intersection between different specifications.

Who generates and checks the nonce that binds a presentation to a specific request? Which layer is responsible for replay protection? Where does wallet selection happen? Which component decides that an issuer is trusted? How is a verifier identified to the holder? Which metadata is authoritative when two layers expose similar information?

Standards groups spend a surprising amount of time on such questions because interoperability failures frequently happen at boundaries rather than inside individual specifications. The growing overlap between digital credentials, wallets, APIs, and agentic systems adds more of these boundaries. A single transaction may involve technology standardized by W3C, Internet Engineering Task Force (IETF), OpenID Foundation, International Organization for Standardization (ISO), or other organizations.

The resulting architecture can be completely standards based and still require substantial integration work.

What Enterprises Should Ask

"Does this support the standard?" remains a useful procurement question, but it cannot be the last one. A more useful evaluation looks at the entire interoperability model.

Which version of the specification is supported? Which optional features are implemented? Is there a profile? Are there conformance tests? Has the product been tested against independent implementations? How are capabilities discovered? How is trust established? Who governs the ecosystem? What happens when implementations disagree? Perhaps most importantly: Where does the standard stop? A good vendor should be able to answer that.

Standards are enormously valuable. Much of today's internet works because independently developed systems implement shared specifications. Their value does not come from eliminating every decision that has to be made. Standards create the common ground on which those decisions can be made.

For organizations building identity infrastructure, understanding what remains outside the specification is therefore just as important as knowing which standards appear on the architecture diagram.