“Digital identity people use the word ‘interoperability’ a lot.”

Usually, we mean that independently developed systems can exchange information successfully: a wallet can present a credential, a verifier can request it, both understand the protocol and data format, and the cryptography works.

That is an important definition, but eventually someone has to deploy this into a real product. At that point, interoperability starts to look rather different.

In my previous post, “Someone Still Has to Accept the Credential”, I looked at the relying party business case for wallets and verifiable digital credentials. Regulation can create pressure to accept credentials, but relying parties still need a reason to want them. Ideally, something in the old process becomes cheaper, faster, safer, or disappears entirely.

There is another part of that equation, though. Even when the benefit is clear, how difficult is it for the relying party to make the credential work in practice?

A relying party does not experience interoperability as a standards conformance statement. It experiences it as a customer attempting to complete a transaction on a particular device, using a particular browser, with a particular wallet, and a particular credential. Those are not quite the same thing.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Interoperable with what?

Consider the problem facing relying parties as European digital identity wallets enter the market. There will not be one European wallet, and national wallet implementations will arrive at different times and will not necessarily behave identically. Users will be on different operating systems and browsers, while more than one mechanism may be available for moving a credential presentation from wallet to verifier.

At the recent Global Digital Collaboration conference, one session laid out some of the dimensions an RP may need to consider. There are 27 national wallet environments, multiple operating systems and browsers, several possible data-flow mechanisms, and multiple data formats.

Any individual transaction may be straightforward. The implementation space is not.

This is not an argument that the standards are badly designed, nor does it mean that every relying party must directly support every theoretical combination. It does mean that “the ecosystem is interoperable” and “this is simple for a verifier to deploy” are very different claims.

One happy path, eleven unhappy ones

The line from the conference session that stuck with me was: “One happy path, eleven potential unhappy paths that must be handled with consistent messaging.”

That sounds like a UX problem, and it certainly is one, but the issue goes beyond interface design. Suppose the verifier requests a credential and nothing happens. The browser may have failed to invoke the wallet, the user may not have an appropriate wallet installed, the wallet may not contain the requested credential, the credential may not be supported, the user may have declined the request, the issuer may not be acceptable, or the interaction may simply have timed out.

The user neither knows nor cares which standards organization owns the failing component. They know that the button did not work.

The relying party has to turn all of those protocol, platform, wallet, policy, and credential states into something a normal person can understand well enough to decide what to do next. That is not trivial work, and it is one of the places where standards-level interoperability and deployment-level interoperability start to diverge.

Standards interoperability is necessary, but it is not sufficient

This reminds me of a broader problem I keep returning to when people describe systems as interoperable. Standards give us shared building blocks, but they do not eliminate profiles, implementation choices, optional features, extensions, deployment assumptions, trust decisions, policy, platform behavior, or product design.

Two systems can implement compatible standards and still leave substantial integration work for the organization trying to connect them. Wallets make this especially visible because a single transaction can cross so many boundaries at once.

The relying party’s site or application, the browser, the operating system, the wallet, the credential, the issuer’s trust information, and possibly additional verifier infrastructure may all be involved. Each piece can be behaving correctly according to its own rules while the overall transaction still fails.

Technically interoperable components can therefore produce an operationally messy system. That distinction matters much more once we move from pilots and demonstrations into routine consumer use.

The relying party does not want to become a wallet laboratory

One answer to complexity is expertise. An organization can hire people who understand the standards, build and test every relevant flow, monitor implementation changes, track wallet behavior, update trust configuration, and maintain consistent fallback experiences.

Some organizations will do exactly that. I am skeptical that most relying parties want to.

Think about a retailer, employer, hotel chain, university, or regional bank. Its core competency is not understanding every permutation of credential presentation. The identity flow exists to support some other transaction, and every layer of wallet-specific expertise becomes another cost attached to that transaction.

The more wallet acceptance requires the relying party to become deeply expert in wallet protocols and credential ecosystems, the weaker the deployment proposition becomes. The technology may be interoperable while the market still finds it inconvenient.

Complexity tends to create abstraction

There is a predictable response when infrastructure becomes important enough to use but complicated enough that most organizations do not want to understand it. Someone puts an API in front of it.

That pattern is already familiar in identity. Organizations rarely implement every fraud signal, identity-proofing check, payment network, messaging protocol, or federation integration themselves. Providers absorb complexity and expose a smaller interface to their customers.

European wallet discussions already include the concept of an intermediary service provider acting on behalf of the relying party. Other markets may not formally define that role, but that does not mean they will not develop one through ordinary market pressure.

If the ecosystem presents relying parties with enough combinations of wallets, protocols, formats, trust frameworks, platform behavior, and regulatory requirements, “we make all of that one API” starts looking like a fairly obvious product. It may even be an inevitable one.

But abstraction moves the problem

There is an appealing version of this future. The verifier tells a service what information it needs, while the service handles wallet invocation, protocol negotiation, credential validation, format differences, trust information, and error normalization. The relying party gets one integration and avoids becoming expert in every implementation detail underneath it.

That would solve a real problem, but it also raises a different set of questions. Who is now in the transaction? What information can that provider see? What does it retain? Can it correlate the same person appearing at multiple relying parties? Who decides which credentials or issuers are acceptable? Does the intermediary merely translate protocols, or does it gradually become the place where trust decisions are made?

Those questions deserve their own treatment. For now, the more immediate point is that verifier-side complexity does not disappear just because the underlying standards interoperate.

The verifier has its own definition of interoperability

For a verifier, interoperability is not complete when two implementations can successfully exchange a credential. It becomes useful when the relying party can incorporate that exchange into a reliable product without needing an unreasonable amount of ecosystem-specific expertise.

That includes the happy path, but it also includes the eleven unhappy ones. The standards community cannot solve every implementation problem for every relying party, nor should it try. Still, if we declare victory at protocol interoperability and leave the complexity of making all the pieces behave coherently to each verifier, the market will solve that problem for us.

It will introduce abstraction layers, platforms, gateways, intermediaries, and service providers. Some of those may be exactly what the ecosystem needs, while others may introduce problems we were hoping wallets would help us avoid.

Either way, the next stage of interoperability is not just getting wallets and verifiers to speak the same language. It is making sure relying parties do not need to become linguists.

📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Have you ever noticed that technology people in general, and digital identity people in particular, use the word interoperability a lot?

Usually, what we mean is that independently developed systems can exchange information successfully.

A wallet can present a credential. A verifier can request it. Both sides understand the protocol, they agree on a data format, and the cryptography works.

That’s interoperability.

At least, it’s one kind of interoperability.

The problem is that eventually somebody has to put all of this into a real application and let a real customer use it. At that point, the definition starts to get a little messier.

In my previous post, “Someone Still Has to Accept the Credential,” I looked at the business case for relying parties, or the need for one.

Regulation can create plenty of pressure to accept wallets and digital credentials. However, that doesn’t mean the relying party actually wants them.

The carrot appears when accepting the credential makes something else cheaper, faster, safer, or unnecessary.

But even if we can identify that benefit, there’s another question:

How difficult is it really for the relying party to make the whole thing work?

---

Interoperability Looks Different to the Verifier

A relying party doesn’t experience interoperability as a standards conformance test.

It experiences it as a customer on a particular device, using a particular browser, with a particular wallet, trying to present a particular credential.

That’s actually a much more demanding definition.

Europe is a useful example because the wallet ecosystem there is becoming very real very quickly.

There isn’t going to be a single European wallet. Instead, there will be national wallet implementations arriving on different schedules and operating within different national contexts.

Now think about that.

You have 27 different national wallets. Then you have to layer on top of that:

• Different operating systems
• Different browsers
• Different ways of invoking a wallet
• Different ways of moving a credential presentation
• Different credential formats

Any one of these pieces may be perfectly reasonable on its own.

However, the combination creates a much more complicated implementation problem for the relying party.

At the Global Digital Collaboration Conference in Geneva, one session mapped out some of the dimensions European relying parties may have to deal with.

It gets to the point where you want to draw a giant matrix.

I’m resisting that temptation.

---

Interoperable Does Not Mean Easy to Deploy

The exact number of theoretical combinations isn’t really the important part.

I also don’t want to imply that every relying party will be expected to directly support every possible permutation.

The point is simpler:

The ecosystem is interoperable and this is easy for a relying party to deploy are not the same statement.

That distinction matters.

One line I kept coming back to from that session was that there may be one happy path and 11 potential unhappy paths that must be handled with consistent messaging.

That sounds like a user experience problem.

And it is.

But it also reveals something important about how the relying party experiences the architecture.

---

The Happy Path Is Only the Beginning

Imagine the verifier asks for a credential and nothing useful happens.

Maybe the browser didn’t invoke the wallet correctly.

Maybe the user has a wallet, but not one that can handle the request.

Maybe the wallet works, but it doesn’t contain the requested credential.

Maybe the credential is there, but the format isn’t supported.

Maybe the user declined the request.

Maybe the credential can’t be validated.

Maybe the issuer isn’t acceptable.

Maybe the request times out.

Maybe the user gets halfway through the process and needs a fallback plan.

Each of those things may be a distinct technical state.

To the customer, however, they’re all variations of:

Well, that didn’t work.

And the verifier has to decide what to say next.

That means turning protocol errors, wallet behavior, platform behavior, trust decisions, and credential states into an experience that a normal person can understand.

That’s a significant piece of interoperability work, even if it doesn’t live in a standards document.

---

Standards Do Not Eliminate Deployment Choices

This is part of a broader problem with the way we sometimes use the word interoperable.

Standards are tremendously useful. I love them dearly. Obviously, I spend a large part of my professional life working on them.

But standards don’t eliminate:

• Deployment choices
• Profiles
• Optional features
• Extensions
• Policy decisions
• Trust models
• Platform differences
• Product design

They also don’t guarantee that the combination of several individually conformant components produces a coherent user experience.

Wallets make that especially obvious because a credential presentation can cross so many boundaries.

The relying party application is involved.

The browser may be involved.

The operating system may be involved.

The wallet is involved.

The credential is involved.

Trust information about the issuer may be involved.

There’s a whole lot going on.

Each component can be behaving correctly according to its own rules while the transaction as a whole still doesn’t work particularly well.

So yes, the systems may be technically interoperable.

Operationally, the result may be an absolute mess.

---

Production Systems Are Different From Demonstrations

All of this matters much more once we get past pilot projects and demonstrations that prove limited use cases.

A standards demonstration only has to prove that something can work.

A production system has to work when the user does something unexpected.

It has to work when:

• The software is out of date
• The credential is missing
• A browser behaves differently
• One part of the transaction fails
• The user needs a fallback

And then it has to explain exactly what happened.

That’s a very different standard.

---

Most Relying Parties Do Not Want to Become Identity Experts

Most relying parties do not want to become digital identity wallet experts.

Specialist expertise is an obvious answer to this complexity.

A large organization can build a specialist team that understands the standards, follows the profiles, tests wallet behavior, monitors browser changes, manages trust configuration, and builds consistent error handling.

Some organizations will absolutely do this.

They’re usually referred to as big tech, and nobody likes them.

I’m not actually convinced most relying parties want to do this kind of thing.

Think about organizations such as:

• A regional bank
• A small or medium-sized retailer
• A university
• A hotel chain
• An employer

Their business is not credential presentation.

Identity exists to support some other transaction.

At some point, every additional piece of wallet-specific expertise becomes another cost attached to that transaction.

This creates a very odd situation.

We may have built something that is interoperable enough to work, but complicated enough that the relying party doesn’t want to operate it directly.

---

The Market Will Create an Abstraction Layer

That’s usually when markets create an abstraction.

We’ve seen this many times before.

Infrastructure becomes very important, but the infrastructure is complicated, so most organizations don’t want to become experts in it.

Instead, somebody puts an API in front of it.

Identity has plenty of examples:

• Organizations don’t generally build every identity proofing capability themselves.
• They don’t build every fraud signal.
• They don’t directly implement every payment network.
• They don’t implement every communications protocol.

Vendors absorb some of that complexity and expose a smaller interface.

European wallet discussions already have a concept for an intermediary service provider acting on behalf of the relying party.

Other markets may not formally define the role at all.

That doesn’t mean they won’t develop it.

---

The Intermediary Becomes the New Layer

Imagine a relying party has to deal with enough combinations of wallet behavior, protocols, formats, trust frameworks, and other variables.

Then a vendor can say:

Don’t worry about it. We’ll normalize all of that and give you an API.

It has an obvious sales pitch.

It may also be a very good sales pitch.

In fact, I suspect something like this may be necessary for broad adoption.

But abstraction doesn’t actually make the underlying problem disappear.

It just moves it.

And that creates another set of questions.

Imagine the appealing version.

The verifier says:

“I need proof that this person is over 18.”

Or:

“I need these three verified attributes.”

The intermediary handles:

• Wallet invocation
• Presentation protocols
• Credential format validation
• Issuer trust
• Error handling

The relying party gets a normalized result that solves a very real integration problem.

But now there’s another participant in the identity transaction.

---

What Does the Intermediary See?

Once an intermediary enters the identity transaction, important questions follow.

What information does the intermediary actually see?

What information does it retain?

Can it correlate the same individual across several relying parties?

Does it simply handle protocols?

Or does it become a place where trust decisions are made?

Who decides which issuers are acceptable?

What telemetry gets collected?

None of these are small questions.

They are probably a topic for a whole other post.

For this one, the main point is that when verifier-side complexity becomes too high, the market will not politely wait for standards bodies to simplify it.

The market will create layers.

---

The Verifier Has Its Own Definition of Interoperability

The verifier does have its own definition of interoperability.

And that’s important.

It isn’t enough that two conformant implementations can exchange a credential successfully.

For the verifier, interoperability becomes useful when that credential exchange can be incorporated into a reliable product without requiring an unreasonable amount of ecosystem-specific expertise.

That includes both the happy path and all of the unhappy ones.

The standards community cannot solve every deployment problem for every organization.

And I don’t think it should try.

But we shouldn’t declare victory at protocol interoperability and assume the rest is merely implementation detail.

---

Implementation Detail Is Where the Customer Lives

Implementation detail is where the customer lives.

If the cost of handling that detail becomes too high, someone else will step in to absorb it.

We’ll get:

• Gateways
• Intermediaries
• Verification platforms
• Abstraction services

Some of those may be exactly what the wallet ecosystem needs.

Some may recreate problems that wallets were supposed to help us avoid.

Either way, the next stage of wallet interoperability isn’t just getting wallets and verifiers to speak the same language.

It’s making sure that the verifier doesn’t need to become a linguist.

The verifier shouldn’t have to know everything.

And that, I suspect, is going to be an important part of what comes next.