Self Sovereign Identity: Over before it started?
Monty Pythons parrot sketch is an all time classic because it plays on a very human experience of being defenseless when someone is just blatantly refusing to acknowledge the obvious. Shared reality is a matter of perception, not objective observation. Supported also by various mental biases, including the sunk cost fallacy, and the desire to agree with people we perceive as sympathetic or competent, virtually all humans can fall into this trap. Technical experts on Self Sovereign Identity included.
Instead of recognizing that the parrot of Web security is deceased, has gone to meet its maker, is pushing up the daisies, some people keep insisting that it is merely napping, and use trinkets and all kinds of strings and wires to hold it up.
The result is did:tdw, recently rebranded to did:webvh.
Web based DID methods belong to the family of federated identity methods, not Self Sovereign Identity
Using the web for Decentralized Identifiers (DIDs) violates some of the basic principles of Self Sovereign Identity, and effectively restricts the possible properties of the system to that of a classic federated identity protocol, such as OpenID.
Federated identity systems have their uses, and are often “good enough” for usage by large corporations and governments. But they also enable and encourage platform strategies, which has dramatic implications for personal usage, as well as Small and Medium Enterprises (SMEs). The result has been the Surveillance Industry, and a dependency of 95% of our economy on a few, large platform companies.
Self Sovereign Identity has been developed as a concept to break that dependency, and give people control over their own privacy, security and data. Instead, thanks to did:web and its descendants, it increasingly looks like an exercise of putting SSI lipstick on the pig of the federated Web.
You may think this is just hyperbole. So let’s go back to the beginning.
About the principles of SSI
The design goals of Decentralized Identifiers are listed in Section 1.2 of the W3C DID specificaton:
So how well do Web based DID methods meet these goals?
All web based methods, including did:web, did:tdw, did:webvh, and any other web based method anyone might ever come up with depend on a domain name pointing to a web server. The method specific identifier is always being transformed into a HTTPS request. The DID to HTTPS Transformation is the same for did:webvh as it is for did:web.
Reaching the correct web server is therefore contingent on access control by the administrator of the web server, the security of the web server, the longevity of the organization operating the web server, the Certificate Authority issuing the certificates identifying the web server, the configuration of the Transport Layer Security (TLS) parameters, and the Domain Name System to identify which web server to contact.
Users have two choices:
- Operate their own web server, or
- Use the web server of some organization that provides them their “decentralized” identifier.
The former is the “let them eat cake” of modern technologies.
Despite many people working for decades to make self-hosting easier and more attractive, self-hosting has been declining. But even if we reverted that trend and enabled and motivated people to self-host with some amazing self-hosting offers: How hard would it be to correlate did:tdw:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ:petermueller.ch to did:tdw:QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n:petermueller.ch ?
How difficult would it be to figure out these might both belong to the same person, whose name might be Peter Müller? Especially considering that the web server at petermueller.ch presents a certificate that lists the owner of the certificate to be a “Peter Müller”, and the whois record for the domain lists his full name, address and phone number?
Which brings us to the second choice, above, which is today’s reality for most people in a federated identity world: Trust the platform intermediary.
How much decentralization is there in Apple Mail? How decentralized are today’s Certificate Authorities? How much privacy and control do users of Gmail have? How secure are today’s web services? How well does today’s world fare in terms of data protection from compromise and loss? How good is today’s Web security?
In reality, Web based DID methods give up on Decentralization, Control, Privacy and Security to the same level that today’s federated identity solutions have given up on them.
They use protocols like OpenID Connect for Verifiable Credentials and Verifiable Presentations (OIDC4VC & OIDC4VP) because they ARE OpenID methods. Which is why if use cases building on top of Web based DIDs were using truth in labelling, they would inform their users about being based on OpenID.
But much of the technology world thrives on buzzwords and hypes, and too often, the technical reality is obfuscated by layers of technical complexity and marketing. So the market rarely penalises false advertising.
Using the Web for “Decentralized” Identifiers and advertising it as revolutionary SSI technology is a bit like selling an “Electric Vehicle” that avoids all the complexities of battery development by using a diesel generator on a towed trailer to power the car. Yes, the propulsion is now electric.
But is the end result fundamentally better than a diesel car?
But what about the added security?
When reading about did:webvh, one could get the impression a lot of security is being added. In reality, it's mostly added complexity because everything goes over a single channel, the same one that is being used by did:web, as well.
It adds security in the same way that web sites get more secure if you ask users to enter not a single password, but three passwords, subsequently, in the correct order.
There is a reason no-one does that. Three passwords are not fundamentally more secure, because there is no additional channel. Add a real second factor, and security actually goes up. Which is why Multi Factor Authentication (MFA) has been invented.
Most likely the Web based DID methods can be developed to the point they will provide actual MFA security at a similar level to today’s federated identity protocols. Maybe did:webvh is even close to that point.
But that only makes it just as secure as “Login with Google”, today. And it does nothing to make it meet the SSI criteria of Decentralization, Control and Privacy.
Perhaps it is time to acknowledge that this parrot is not just a heavy sleeper.
Embrace, Extend, Extinguish
So what’s the problem if some people like did:web and its relatives? As long as we are aware of the limitations, and never use it for systems that are supposed to be used in production by end users or SMEs, there is nothing wrong with did:web.
As I’ve written in a previous article, it’s really useful for rapid prototyping, and can be used as a placeholder during experimentation before switching to a real Decentralized Identifier. We’ve done so ourselves when Vereign has been working on Proof of Concept for the Swiss health sector in 2023. But once we started working on the production system in 2024, we switched to an Autonomous Identifier (AID) that meets the definition of Self Sovereign Identity.
The problem starts when people put Web based identifiers into production.
Not only is it an issue of misleading users with false promises of decentralization, control, privacy and security. It runs much deeper than that. Increasing adoption of Web based identifiers under the moniker of Self Sovereign Identity makes it impossible for actual Self Sovereign Identity to differentiate itself from federated identity protocols. It sucks the air out of the room for actual SSI.
At a technology strategy level, adoption of Web based identifiers makes SSI susceptible to something it was originally designed to prevent: Platform capture.
Whether accidentally or by design, the movement for Web based identifiers perfectly executes a strategy coined by Microsoft in the 90s, labelled Embrace, Extend, Extinguish. I’ve gotten to study that particular script extensively when coordinating the technical and communication activities of the Free Software Foundation Europe around the EU Microsoft antitrust case in order to obtain much needed interoperability information for Samba.
The script is not super complicated. First, become a champion of Self Sovereign Identity, embrace it visibly, participate in the conferences, champion it at the political level. Then come up with ideas to extend it, for instance by proposing to speed up adoption by falling back on “proven”” technologies from the Web. Provided enough Kool-Aid, nobody might notice that it violates the principles of SSI and you’ll find many willing participants.
And lastly, once it has become the dominant flavour to however misleadingly claim the label Self Sovereign Identity, extinguish what is left in terms of actual SSI by aggressively using your economic and political might to push a platform play to suck the air out of the market. While Sovrin had its issues, including political, it undoubtedly lived up to all the SSI principles. Recently, the Sovrin Foundation announced that it was shutting down in March 2025 due to its community moving to the Web.
So, what’s left?
Microsoft had originally championed did:ion, a fully Self Sovereign Identifier based on the Sidetree specification. But as of 2023, it unsurprisingly also switched to did:web. Old habits die hard. Other large tech platforms are also pushing in the same direction, as are several of the former governmental monopolists with strong political ties, such as T-Systems.
The most promising design for a decentralized identifier is the Key Event Receipt Infrastructure (KERI), and at conceptual level it solves some very hard problems that no other method even attempts to address. The problem is how long it has been the promising next thing, without achieving sufficient adoption, and without finding its way into the regulatory documents in the European Union eIDAS (for “electronic IDentification, Authentication and trust Services”) working group, which is strongly pushing in the direction of Web based identifiers.
Unsurprisingly, technical experts have raised security and privacy concerns. In fact, it seems the current draft of the EU Architecture and Reference Framework (ARF) may be in violation of the EU privacy provisions it is supposed to provide.
Also, and it’s already been a topic in the DICE2024 retrospective, KERI is currently available in Python only. Which leaves adoption hamstrung. Not everyone in the KERI community agrees with that, but I’m aware of a number of people and initiatives who would love to adopt KERI, but not in Python. And its completeness as a concept puts the effort required for implementation in another language outside what is feasible for any of these parties individually.
So, when looking at the W3C DID Traits draft, the table looks pretty bleak, with two actual SSI methods left on it: did:key and did:peer. Both limited in relation to quite a few use cases.
What we ended up doing…
We anticipated this picture when designing our use case and solution for the Swiss health sector back in January 2024. The Web identifiers were obvious non-starters, as were did:key and did:peer, due to them being overly limited for our purpose.
We also did not like the idea of putting Python into a mission critical production application for large number of users. Especially since we did not want to put Python on the phone, and also did not want remote wallets that do not actually live on the phone.
So we did what XKCD told us not to do. Stay tuned.
