Decentralized Identity: DIDs, Soulbound Tokens, and Why This Problem Is Harder Than It Looks

Decentralized identity is one of those problems that seems obviously solvable until you actually try to solve it. The basic concept is appealing: instead of your identity being held by a collection of corporate silos — Google, Apple, your bank, your government — you control a cryptographic identity that you can use selectively, without any single intermediary being required.

The technology for this exists. Decentralized Identifiers (DIDs) are a W3C standard. Verifiable Credentials (VCs) have a well-developed specification. The Ethereum community has explored Soulbound Tokens (SBTs) as a non-transferable on-chain representation of credentials and affiliations. None of these have achieved meaningful mainstream adoption. Understanding why is more revealing than cataloging what they are.

## The technical layer is the easy part

A DID is a URI that resolves to a DID Document — a JSON-LD object containing public keys and service endpoints. You generate a key pair, publish the document to some registry (a blockchain, a distributed hash table, a simple HTTPS endpoint), and you have an identifier you control. Verifiable Credentials are cryptographically signed attestations issued by one DID to another — "DID:example:1234 is a medical doctor, issued by DID:example:hospital, signed with this key."

This is genuinely elegant. It separates the identifier (which you control) from the attestation (which an authority issues) from the verification (which a relying party performs). No database of personal information at the issuer; just a signed credential in the holder's wallet. Privacy-preserving cryptography like zero-knowledge proofs can let you prove specific attributes ("I am over 18") without revealing the underlying data ("I was born on this specific date").

The technical architecture is sound. So why doesn't it work in practice?

## The bootstrapping problem

For a verifiable credential to mean anything, the issuer has to be trustworthy, and relying parties have to have some way of knowing which issuers they trust. This is, in various forms, the same problem as SSL certificate authorities, OAuth providers, and every other federated trust infrastructure.

In the current internet, Google's OpenID Connect works because Google is Google — a trusted entity with strong network effects that developers and users already rely on. A decentralized identity system requires building a trust registry from scratch, without network effects, and getting both issuers (governments, universities, employers) and verifiers (websites, services) to participate before either side has a reason to.

*This isn't a technology problem. It's a coordination problem.* And coordination problems in identity are particularly hard because the existing issuers — governments especially — have regulatory reasons to maintain control over official identity documents and no obvious incentive to cede that to a decentralized infrastructure.

## What Soulbound Tokens add and don't add

Vitalik Buterin's 2022 paper on Soulbound Tokens introduced the concept of non-transferable on-chain tokens as attestations of credentials, affiliations, and achievements. The basic idea: because SBTs can't be sold, they can represent genuine attributes of an identity rather than purchased status symbols.

The on-chain approach has a specific advantage over off-chain VCs: composability. If my wallet holds an SBT attesting to educational credentials, a DeFi protocol can read that on-chain without any off-chain API call or oracle. The credential is programmable — protocols can gate access or modify parameters based on credential holdings.

The on-chain approach also has specific disadvantages. Blockchains are public by default. Putting credential attestations on a public ledger creates privacy risks that off-chain VCs, stored in a holder's wallet, don't. Zero-knowledge versions of SBTs exist conceptually, but they add complexity. And the same bootstrapping problem applies: an SBT from an issuer nobody trusts is worthless, and getting trusted issuers on-chain requires the same coordination that off-chain VC systems haven't been able to achieve.

## Why the problem remains unsolved

The honest assessment is that decentralized identity has been "promising" for over a decade, with real technical progress and minimal real deployment. The reasons aren't primarily technical. They're structural: existing identity infrastructure, for all its problems, works well enough that switching costs are high. Governments have regulatory and sovereignty reasons to maintain control. Corporations have business reasons to maintain their identity infrastructure. End users, presented with "self-sovereign identity" versus "just log in with Google," almost universally choose Google.

The use cases where decentralized identity has gained traction — credentialing in crypto-native contexts, anonymous attestation schemes, specific professional credential verification — share a common feature: the relevant relying parties and issuers are already operating in crypto contexts where the infrastructure exists.

> **Key Takeaway:** DIDs and SBTs are technically sound building blocks for decentralized identity. The adoption barrier is a coordination problem: without simultaneous participation from trusted issuers and widespread verifiers, the system can't build the network effects that make any identity infrastructure valuable.

Decentralized Identity: DIDs, Soulbound Tokens, and Why This Problem Is Harder Than It Looks

// COMMENTS

ON THIS PAGE