When wallets cross borders: what Switzerland reveals about global interoperability

Interoperability usually means "inside the EU"

When people in the European digital identity space say "interoperability," they almost always mean one thing: making the national EUDI Wallets talk to each other. A French wallet proving age to a German service. A Danish credential accepted by a Spanish platform. That is a real and hard problem, and the EU is doing serious work to solve it — a common regulation (eIDAS2), a common reference framework (the ARF), a shared age-verification Blueprint, and a coordination mechanism meant, in the Commission's own words, to converge on one interoperable solution rather than twenty-seven divergent ones.

But the world is bigger than the EU. And the moment you step outside the eIDAS2 umbrella, "interoperability" stops being a coordination problem and becomes an architecture problem — because the ecosystems you meet out there were built on different foundations.

You don't have to go far to see it. Switzerland — a neighbour, not a member state — already runs one of the most mature wallet ecosystems in Europe. Its e-ID has a legal basis, a public-beta infrastructure, and real credentials in circulation. And it does age verification too. Same goal as the EU. Almost none of the same technical choices.

Switzerland is the clearest window we have into a question the EU's inward-facing interoperability work doesn't answer: when the world fills up with sovereign national wallets, how do they interoperate with each other?

Same intention, different everything

Start with what's shared, because it's substantial. Switzerland's ecosystem — built around the government's swiyu infrastructure — wants exactly what the EU wants for age verification: let a user prove they are over 18 without handing over their name, birthdate, or document. Privacy by design. Data minimisation. Keys held on the user's device. The proof reveals a single fact and nothing else.

In intent, the two systems are twins. A Swiss resident proving "over 18" to a website and an Italian resident doing the same are having the identical privacy-preserving experience, conceptually.

Under the hood, they are speaking different languages — and not dialects of the same one. Different languages.

Where the two ecosystems actually diverge

This is where a design decision made in Brussels and a design decision made in Bern stop being compatible. Three axes matter most.

Credential format: mdoc vs SD-JWT VC

The EU age-verification Blueprint, and the national wallets integrating it, are built on mdoc — the ISO/IEC 18013-5 (and 18013-7) mobile document format. It's the same lineage as the mobile driving licence. It's binary, CBOR-encoded, and it carries its own selective-disclosure machinery.

Switzerland went the other way. swiyu is built on SD-JWT VC — selective-disclosure JSON Web Tokens. The credential is a signed JSON structure with salted, individually-disclosable claims. Switzerland's technical profile is explicit that ISO mdoc credentials are not supported in its verification flow.

One clarification matters here, because it's easy to get wrong. SD-JWT VC is not some non-European exotic: it is one of the two credential formats the EUDI Architecture and Reference Framework supports, right alongside mdoc. The split isn't "EU format versus foreign format." What actually happened is narrower — the EU's age-verification Blueprint standardised specifically on mdoc, while Switzerland built its whole stack on SD-JWT VC. Both formats are first-class citizens of the broader European wallet framework; the two ecosystems simply picked different options from an overlapping menu, and for age verification in particular landed on different ones.

These are not two encodings of the same thing. They are two different credential paradigms, with different libraries, different signing conventions, different selective-disclosure mechanics. A verifier built to validate one does not, by adding a config flag, validate the other. It has to implement the second paradigm from the ground up.

Trust model: X.509 trust list vs DID + trust registry

Even if the formats matched, the harder gap is trust. When a verifier receives a proof, it has to answer one question: can I trust the issuer that signed this? The two ecosystems answer it in incompatible ways.

The EU age-verification model anchors trust in a signed X.509 trusted list — the EU Age Verification Trusted List, an ETSI-style structure that enumerates the accredited issuers and lets a verifier walk a certificate chain to a known root. This is classic PKI: certificates, chains, a signed list you fetch and validate.

Switzerland anchors trust in decentralised identifiers. Issuers are identified by DIDs (the did:webvh method), resolved and validated against swiyu's own trust registry. There is no X.509 trusted list to walk. The verifier resolves a DID, checks it against a Swiss registry, and trusts on that basis.

This is the deepest incompatibility of the three. Credential format is a matter of parsing; trust anchoring is a matter of governance made technical. One ecosystem says "trust flows from a signed list of certificates." The other says "trust flows from a registry of decentralised identifiers." A verifier that wants to accept both has to run two entirely separate trust-establishment paths.

Further down the stack, more agreement than you'd expect

It would be tidy to say the divergence continues all the way down, but it doesn't — and it's worth being accurate about where the incompatibility actually lives. At the cryptographic layer the two ecosystems largely agree: both standardise on ES256 signatures over the NIST P-256 curve, and both reach for a status list — the IETF Token Status List — for revocation when they need one. (For age verification the credential is typically single-use and short-lived, so revocation barely comes up in the first place.) The one thing Switzerland genuinely adds of its own is OCA (Overlays Capture Architecture), for the visual presentation of credentials — a piece the EU age-verification model has no direct equivalent for.

So the picture isn't "every layer is incompatible." Curve and revocation converge. The incompatibility is concentrated exactly where it hurts most: the credential format, and — the deeper one — the trust model. Those are the two layers a verifier cannot paper over, and they're the two that don't line up.

To be fair to both: these are well-engineered systems, and Switzerland's is still in public beta and explicitly subject to change. This isn't a story about one side getting it wrong. It's a story about two capable teams making coherent, internally-consistent choices that happen not to line up.

Why this is the interoperability problem nobody has solved

Here's the uncomfortable part. The EU has done the hard work of making interoperability work inside its own framework — and that work is genuinely impressive. But it solved interoperability by mandating a shared framework. That only works for the countries inside the mandate.

Switzerland is one neighbour, and already the seams are structural: different format, different trust model, different crypto conventions. Now multiply that by every jurisdiction on earth that is building — or will build — its own sovereign digital wallet. The UK. Various US state initiatives. Singapore. Every country that decides digital identity is national infrastructure and builds it to its own specifications.

A relying party — a service that needs to verify age or identity — doesn't get to say "I only accept EU wallets." Its users come from everywhere. And "accept another wallet" is not a configuration change when the other wallet lives in a different credential paradigm with a different trust root. It's a second implementation.

The EU solved internal interoperability. Global interoperability — between ecosystems built on incompatible foundations — is unsolved, and it's not obviously on anyone's roadmap as a single owner's problem. It falls in the gap between standards bodies, national governments, and whoever ends up having to actually accept credentials from more than one world.

The part that gets solved, and the part that doesn't

There's a useful way to see this split, and the EU itself has just handed us the evidence.

In mid-2026, the European Commission and Japan's Digital Agency published the results of a cross-border interoperability pilot: a prototype EUDI Wallet and a Japanese wallet issuing, holding, presenting and verifying each other's academic credentials, in both directions. On the technical side, it worked. They aligned on common protocols — the OpenID4VC High Assurance Interoperability Profile and SD-JWT VC — and credentials flowed across two jurisdictions whose frameworks were designed completely independently. The headline conclusion was upbeat: interoperability doesn't require a single shared framework, only alignment on common protocols.

But read past the headline and you find exactly where the wall is. The report itself flags that the biggest remaining hurdles are not technical but legal — specifically, the mutual recognition and trust frameworks that would give a cross-border credential any legal standing. To make trust work at all in the pilot, the two sides had to lean on out-of-band knowledge and Japan's national e-seal certification scheme — that is, they closed the trust loop partly by hand, with agreements outside the system, rather than through any automatic, interoperable mechanism. The pilot proved you can move the format across a border. It did not solve moving the trust across a border.

That distinction is the whole game. Aligning protocols is the tractable part — a profile here, a credential format there, and the bits flow. Establishing mutual trust is the hard part, because it isn't an engineering problem at all: it needs international agreements, aligned liability rules, and legally binding recognition between states. A recent World Bank policy note on digital wallet frameworks lands on the same point, naming legal recognition as a decisive factor for wallet interoperability and trust. And you can see the cost of not having it closer to home: the UK, post-Brexit, sits outside the EU's mutual-recognition architecture, so UK trust services operate as a "third country" — technically capable of aligning on protocols, but without the automatic legal standing that recognition inside the framework confers.

So the pattern repeats at every scale. Switzerland shows the divergence structurally — different foundations, next door. The EU-Japan pilot shows that even a deliberate, well-resourced effort to bridge two ecosystems aligns the protocols and then stalls on the trust framework. The UK shows that even a former member sits outside the trust perimeter the moment it steps out of the shared legal frame. Formats are converging. Trust isn't — and trust is the part that actually decides whether a verifier can accept a credential.

The open question

So where does this go? Two futures, roughly.

In one, the ecosystems slowly converge — the standards bodies do their work, mdoc and SD-JWT VC grow bridges, trust models find common ground, and a decade from now a wallet is a wallet wherever you are. It's possible. Standards do sometimes win.

In the other, the future is sovereign wallets that never fully converge, because national digital identity is too tied to national governance to be standardised away — and interoperability happens through translation layers that speak every ecosystem's language so the relying party doesn't have to. In that world, someone has to build the thing that accepts an EU mdoc proof and a Swiss SD-JWT proof and a UK credential and returns the same clean answer to the service behind it.

I don't know which future we get. But I know that today, if you want to verify age against both a Danish wallet and a Swiss one, you are not configuring a product — you are speaking two languages. And the number of languages is only going to grow.

That's the real interoperability problem. Not making Europe talk to itself. Making Europe talk to everyone else.

---

This article draws on public documentation: the EU age-verification Blueprint (ageverification.dev) and the Swiss swiyu technical specifications (swiyu-admin-ch.github.io), which are in public beta and subject to change, and the European Commission's published report on the EU-Japan interoperability pilot. It reflects my own reading as an engineer working on the relying-party side of EUDI age verification; it doesn't represent any organisation.