The Wallet Your Customers Will Carry Is Not Going to Be Ours

We do not ship a certified European wallet and are not going to. Nothing here is legal advice.

The distribution fact that reorders this whole market

Every EU Member State is obliged to make a digital identity wallet available to its citizens. Not permitted, obliged.

That single sentence does more to this industry than a decade of standards work did, because it solves the distribution problem no private vendor has ever solved. Wallets get onto phones because a government put them there, and the acceptance obligations that come with the regulation mean businesses have a reason to read them.

Every identity vendor's plan should start from the assumption that the wallet is somebody else's, and most vendor material still reads as though the wallet were the product.

What we are, stated so nobody has to guess

We do not ship a certified European wallet. Nothing we run is recognised by any Member State, assessed by any conformity body, or notified under the regulation.

Our own wallet product is a different thing entirely. It holds credentials under our own identifier method and has no relationship to the European wallet specification. It is not a smaller version, not a precursor, and not on a path to becoming one.

Stating that plainly matters, because "wallet" is doing double duty in this market and a buyer comparing two products with the same noun may be comparing very different objects.

Where a credential system fits when the wallet is somebody else's

This is the useful question, and it has three real answers.

Being an issuer whose credentials the wallet can carry. The wallet holds credentials; somebody has to issue them, and most of them will not come from a government.

Being a verifier that can accept what the wallet presents. The acceptance side is where most businesses actually sit, and it is a genuine integration problem rather than a solved one.

And serving the long tail the regulation does not reach. Non-government issuers (an employer, a university, an exchange, a marketplace) have attestations to make and appear on no national trusted list.

Those three are where the work is. None of them is "ship a competing wallet."

What we can and cannot say about interoperability

Could a credential we issue be presented to a wallet built to the European specification? In principle, through a wrapping step, because several of the underlying protocols are shared.

Has that been done? No. Not by us, not by anyone, and there is no test we can point you to. So it is an architectural possibility rather than a demonstrated capability, and the difference is exactly the kind that collapses under a procurement question.

What is not done is the conformance work, the binary credential format, and any demonstration against a real certified wallet.

Why we are not planning to compete on the wallet

Because it would be a distribution fight against governments, and losing it slowly is the predictable outcome.

The value moves to whoever makes the credentials worth carrying and the acceptance worth building. A wallet with nothing useful in it is an app nobody opens, and that gap is where a private company can be genuinely useful without pretending to be a Member State.

What to ask any vendor about this

"Do you ship a wallet, and is it certified?" Two questions. Many vendors answer the first and let the second be assumed. Ours: yes to a wallet, no to certification, and it is not the same category of thing.

"Have you presented a credential to a certified wallet?" Not "could you". Has it happened, and can you show it.

"What is your plan when the state wallet is the default?" A vendor without an answer is planning for a market that is being legislated away.

"Which side are you on: issuing, verifying, or both?" These are different products and the honest answer is rarely both, well.

Where this leaves a decision

If you need a wallet your users can be required to accept, that is a Member State's job and no vendor can substitute for it.