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

KuppingerCole

Message History

Delivery option(s)