What the EU digital identity wallet means for decentralized identity standards
The standards for the EU digital identity wallet are largely set. Markus Sabadello argues the framework chose the older, established options over the ones the decentralized-identity community built, and while these choices were practical, they were never merely technical, and this matters because each shaped who ends up in control and who you have to trust.
Technology is not neutral. There are certain values and worldviews and assumptions built into technical choices.
By the end of 2026, every EU member state must offer its citizens a digital identity wallet, and the framework that defines it, now at version 2.8, has mostly settled the standards those wallets will run on. They run on OpenID's protocols for issuance and presentation, and on the SD-JWT VC and ISO mobile-document credential formats.
Built-in assumptions
For anyone building on this stack or evaluating it, these are points worth looking into, and Markus Sabadello is well placed to provide perspective. For more than a decade he has built a core part of this technology, yet one the EU's wallet does not rely on. Danube Tech, his company, started the Universal Resolver, the open-source infrastructure that resolves decentralized identifiers across dozens of competing methods, and he runs its commercial counterpart, Godiddy.com.
About three years ago Sabadello began expressing his concern that technical standards are not neutral. The self-sovereign identity movement he came out of set out to build identity that an individual controls, that no authority can revoke, an independent digital existence, and it invented a set of technologies to get there, through verifiable credentials, DIDComm, and decentralized identifiers. As it happens, the people building those technologies did not agree on how they should work, and the landscape fragmented. There are now several competing formats for a verifiable credential. A digital driver's license or a university diploma can be expressed as a W3C document, an IETF token, or an ISO record, and they are mostly incompatible. Why keep building new standards for problems that are already solved?
Sabadello points to three forks. For the protocol that moves credentials, the framework requires OpenID4VC, built on OAuth and OpenID, rather than DIDComm. For the format of the credential, it makes SD-JWT VC and the ISO mobile-document format mandatory and leaves the W3C's model optional, available but not required. For binding a credential to its holder, the required profile uses a public key rather than a decentralized identifier. The pattern he draws from the three is that each time, the mandated choice is the older one, with the larger installed base.
Of the three, the protocol choice is the one Sabadello likes least. The case for OpenID4VC is that it reuses mature technology, the OAuth and OpenID and JSON Web Tokens that have been in production for years, with tooling developers already know. But the wallet model of an issuer, holder, and verifier, with an individual holding their own credentials on their own device, was not what OpenID was built for, and making it fit required so many extensions that the result is, in his description, almost an entire new protocol. The claim that it is easier to adopt because it sits on something familiar is, then, only partly accurate. DIDComm, by contrast, was symmetric from the start, designed for communication in both directions between equal parties. The drift Sabadello sees is the one OpenID already made once before, from a user-centric protocol where you logged in with your own server to the federated "log in with Google" that replaced it.
Why simple wins, and what it leaves out
Is that shift engineered or simply the path of least resistance? Large companies with existing identity products have an economic interest in reusing what they have already built. Furthermore, building a national wallet on OAuth and JSON Web Tokens is easier than building it on the less mature, more idealistically pure alternatives, and a government shipping to millions has reason to prefer the well-worn path. The people on the other side of these choices, Sabadello acknowledges, would say the community's standards are elegant but not yet ready to deploy, and that they built on what was already working.
He does not dispute that the simpler standards are sometimes the better fit, or that building on public infrastructure rather than reinventing it is a defensible position. The simpler option has won this kind of contest before. When Amazon opened its web services to outside developers in the mid-2000s, it offered two interfaces side by side, a formal SOAP version wrapped in the WS-* security and messaging stack, and a simpler REST one that passed requests over plain HTTP. Developers chose REST by a wide margin, around eighty-five percent by the figures reported at the time, and it became the default for public web APIs. What bothers him is the argument that "simple is a feature", because it leaves out the question of what assumptions are built into a standard, and makes it sound as though the only thing at stake is which option is easiest to implement, as if the choices were interchangeable and the decision purely technical. That erasure is what he means by "standards populism," a term he takes from politics, where it describes simple answers offered to complicated questions with the side effects left unsaid.
Asked where simplicity stops being a feature and becomes the slide he is warning about, Sabadello declines to draw the line. These things are rarely visible at the start, he says, and the communities involved are not divided into good actors and bad ones.
Coexistence rather than convergence
The hope across the field is interoperability, wallets that work across use cases and across borders, and he thinks mapping between standards will be possible to a degree. But he does not expect the field to converge on one agreed standard the way the web converged on TCP/IP and HTTP, where any browser can open any site. The divergence in worldviews runs too deep. The EU wallet's design makes sense for what it is, he says, an instrument organized around governments and public-sector use, where a citizen's identity is verified by the state. It cannot do the peer-to-peer case at all. The community he comes from imagined credentials that people issue to each other, a note that someone is a reliable host, an attestation that someone is a capable journalist, a web of trust built from the bottom up. The wallet puts that entirely out of scope, and the projects that care about it, like Harvard's Keyring, a reference wallet for issuing peer-to-peer credentials with no institution in the middle, will keep choosing other standards.
What a standards choice commits you to
A standards choice commits you to more than a wire format. OpenID's roles are asymmetric and DIDComm's are symmetric. One credential format lets anyone define the meaning of a field, another leans on a central registry. One way of binding a credential lets you swap your key infrastructure later, another does not.
What the field is trying to do, he says, is model in software how identity works in the world, which is a cultural and philosophical question before it is an engineering one, and the work should be driven by who a person is rather than by how to make the know-your-customer process more effective for a given business. The larger concern is not entirely that a wallet is centralized or that its standards are wrong, but that a field can settle questions this consequential while describing them as nothing more than engineering, and that the description, once accepted, is hard to reopen.
