Ask ten people what "decentralized identity" means and you'll get some version of: no single company controls who you are online. True, but it's the easy half of the problem. The hard half is the one almost nobody names.
Two questions, not one
Every identity system, centralized or not, has to answer two separate questions:
Who issued this claim? — can I trust that "verified human," "over 18," or "employee of X" actually came from a legitimate source, without calling that source to double-check?
Who can read this in the first place? — regardless of who issued it, who is actually allowed to see the underlying data?
Most of what gets called "decentralized identity" today — W3C Decentralized Identifiers (DIDs), Verifiable Credentials, blockchain-anchored public keys, self-sovereign identity wallets — is very good at question 1. Signature verification without a central issuer is a real, solved, useful piece of engineering.
Question 2 usually doesn't get the same treatment. A signed credential still has to live somewhere, and that somewhere usually decides who can read it through an access-control policy sitting beside the data — not through the data's own structure. Decentralize the issuer, and the storage layer is still one party deciding who gets to look.
Why this gap matters
When one party controls both storage and readability, they can revoke, alter, or quietly change what's visible about you — and you have no independent way to check, because checking would require going through the same party you're trying to check.
This isn't hypothetical: platforms suspend accounts, change verification policy, or shut down, and whatever "identity" lived there goes with them.
Formally, this is the same failure mode as a Byzantine system with n = 1 — a single controller has no internal quorum to contradict itself. Full argument here.
Closing the second half .me treats readability as the thing to decentralize, not just issuance.
Audience membership is a structural, cryptographic property of a path — declared with one operator, _ — instead of a policy checked beside the data:
me.identity["_"]("scope-key");
me.identity.claim("verified-human");
me("identity") // undefined — root stays invisible
me("identity.claim") // readable only with the effective key
Topology — where the encrypted bytes physically live or replicate — and audience — who can derive the key to read them — become independent variables. Replicating the ciphertext to a new host, a backup, or another device never expands who can read it.
That's the actual content of "decentralize identity": not just moving who signs the claim, but removing any single party's ability to unilaterally decide who reads it.
These aren't competing — a real system could use verifiable credentials for issuance and .me's audience model for readability. The point is that "decentralized identity" conversations usually stop at the first column.
Full piece, with the honest survey of DID/VC approaches and where .me fits without overselling it: What Is Decentralized Identity?
Formal version — the structural claim stated precisely, with the boundary between what's shipped and what's still direction: The User-Centric System
Top comments (0)