Self-sovereign identity has been described, correctly, as a paradigm shift. It has also been described, incorrectly, as a solved problem. Decentralized identifiers reached W3C Recommendation status in 2022, and the verifiable credentials data model is now in its second major revision. The specification work is mature. The deployment reality is not.
This article is a technical review of what the DID and VC stack actually delivers, where it creates new problems rather than solving old ones, and why the two most prominent production implementations chose fundamentally different paths. It is written for practitioners who need a clear-eyed account, not a promotional one.
What Decentralized Identifiers Actually Are
A decentralized identifier is a URI. Specifically, it follows the pattern did:method:method-specific-id. When resolved, it returns a DID Document: a JSON-LD structure containing public keys, authentication methods and optional service endpoints. The W3C DID Core 1.0 specification defines the data model and the resolution interface. It does not define any single ledger or storage substrate.
That last point matters. DID methods are the per-substrate implementations: did:web resolves via HTTPS, did:key is entirely self-contained in the identifier string, did:ion anchors to Bitcoin, did:sov resolves against the Sovrin ledger. The DIF (Decentralized Identity Foundation) maintains a registry of over 100 published methods. Interoperability across methods is a policy decision, not a technical guarantee from the specification.
The critical property DIDs introduce is that the identifier is not issued by a third party. The controller generates a key pair, derives the identifier from the public key or from a ledger transaction hash, and publishes the DID Document. Control is proven by signing with the corresponding private key. This breaks the dependency on a registrar or identity provider that could revoke access, sell the identifier or disappear.
The Verifiable Credentials Layer
DIDs answer the question of who controls an identifier. Verifiable credentials answer the question of what claims are asserted about that identifier.
A verifiable credential under the W3C VC Data Model 2.0 is a JSON-LD document containing a set of claims, an issuer DID, a subject DID, validity period, and a cryptographic proof. The proof is typically a linked data proof or a JOSE-based signature. The credential is issued by an entity (a university, an employer, a government agency) and held by the subject in a wallet. When a verifier requests proof, the holder presents a verifiable presentation: a wrapper containing one or more credentials, optionally with a holder signature binding the presentation to the request.
Selective disclosure is where the VC stack becomes genuinely powerful. With BBS+ signatures (standardized in the W3C VC Data Integrity specification) a holder can reveal a subset of claims from a credential without revealing the rest, and the verifier can confirm the partial disclosure is cryptographically consistent with the original credential. A holder with a government-issued credential containing name, date of birth and address can prove they are over 18 without disclosing their exact birth date or any other attribute.
What SSI Genuinely Solves
Three real problems have partial but meaningful solutions in the SSI stack.
Platform lock-in for identity. Today, signing in with Google or Apple means those companies can terminate your access to every service built on that identity. A DID-based identity is portable across any verifier that supports the relevant DID method. No single platform controls your identifier.
Credential portability. Academic transcripts, professional licenses and employment history are currently siloed in institutional databases. A verifiable credential issued once by the institution can be presented to any verifier without calling back to the issuer, as long as the credential has not expired and has not been revoked. This reduces friction in background verification workflows significantly.
Minimal disclosure by design. Traditional identity systems are all-or-nothing. OAuth scopes are coarse. SSI with selective disclosure moves the disclosure decision to the holder and makes it cryptographically enforced rather than policy-enforced. This is architecturally better for privacy.
The W3C Verifiable Credentials Working Group, the Decentralized Identity Foundation and implementers like Microsoft, Ping Identity and Spruce Systems have demonstrated these three properties work at scale in pilot deployments. The EU Digital Identity Wallet (eIDAS 2.0) mandates VC-compatible architecture for member state identity infrastructure, which is the largest policy-driven SSI deployment in history.
The Recovery Problem
Every experienced cryptographic engineer asked to evaluate SSI eventually lands on the same question: what happens when a user loses their private key?
This is not an edge case. Surveys of consumer wallet users consistently show key loss as the primary reason for abandonment. Hardware wallets fail. Seed phrases are lost in floods and fires. People die without transferring credentials to heirs.
The DID specification does not define key recovery. DID methods handle it differently, which means there is no portable recovery story across the ecosystem.
did:key has no recovery mechanism at all. The identifier is derived from the public key. If the private key is gone, the DID is gone.
did:ion supports recovery keys: a separate key pair committed at DID creation time that can be used to rotate the operational key set. This requires the user to manage two distinct key materials rather than one, which is operationally more complex and does not help if both are lost together.
Social recovery schemes, popularized by Ethereum smart contract wallets, allow a set of guardians to collaboratively authorize key rotation. The Sovrin Governance Framework allows for delegated recovery through trustees. These schemes work but they reintroduce social trust dependencies that SSI was supposed to eliminate. You are still dependent on the honesty and availability of other humans.
The deeper issue is that key recovery is not just a technical problem. It is a human factors problem. NIST SP 800-63-3 dedicates significant space to identity proofing and authenticator recovery precisely because cryptographic systems fail when humans cannot meet their operational requirements. SSI advocates have not yet produced a recovery model that works for non-technical users at population scale. This is the largest unsolved problem in the stack.
The Revocation Problem
Credential revocation is architecturally awkward in a decentralized system by design. If there is no central authority, there is no central revocation list. If there is a central revocation list, you have reintroduced centralization.
The W3C VC Data Model 2.0 supports pluggable status mechanisms. The most widely deployed is StatusList2021, maintained by the DIF. The issuer publishes a bitstring (a compressed list where each bit corresponds to a credential index) at a known URL. Verifiers fetch the bitstring and check the relevant bit. This works but has two problems. First, the issuer's status endpoint becomes a required dependency: if it is offline, verifiers cannot confirm status. Second, the pattern of verifier fetches can leak information about which credentials are being presented, because the bitstring fetch is tied to the issuer's infrastructure.
Cryptographic accumulator-based revocation (using RSA accumulators or Merkle trees) allows issuers to publish a compact value that proves membership or non-membership without revealing the full list. This is more privacy-preserving but computationally heavier and requires more sophisticated wallet and verifier implementations.
On-ledger revocation registries, used in some Hyperledger Indy deployments, move the revocation list to the shared ledger. This removes the issuer as a liveness dependency but increases ledger storage requirements and requires governance around who can write revocation entries.
None of these solutions is clearly dominant. Production deployments in 2026 typically implement StatusList2021 because it is simplest, then accept the liveness and privacy trade-offs as acceptable for their use case. The absence of a universal solution means interoperating systems must negotiate which revocation method they support, which fragments the verifier ecosystem.
ION and Sovrin: Two Architectures, Two Trust Models
ION (Identity Overlay Network) was developed by the Decentralized Identity Foundation with significant engineering contribution from Microsoft. It implements the Sidetree protocol, a layer-2 protocol that batches DID operations and anchors cryptographic commitments to the Bitcoin blockchain. The Sidetree protocol specification is maintained at the DIF (identity.foundation/sidetree/spec/).
ION's design philosophy is permissionless. Anyone can run a node, anyone can anchor a DID, and the security guarantee derives from Bitcoin's proof-of-work consensus. No foundation can deactivate your DID. No governance body can deny you access to the network. The cost is throughput: Bitcoin's block time and limited throughput constrain how quickly DID operations can be confirmed. There are also real transaction fees denominated in BTC, which creates variable cost exposure.
Sovrin took a different path. The Sovrin Network is a permissioned ledger: not every node can participate. Steward nodes are vetted legal entities (corporations, universities, government agencies) that sign a stewardship agreement with the Sovrin Foundation. The Foundation sets governance rules, and stewards enforce them. DID writes are free to identity owners because stewards absorb the operational cost.
This design is more operationally predictable. Transaction finality is fast. Governance is explicit and auditable. The cost is trust: you are trusting that the Sovrin Foundation and its stewards will not collude against your interests, will not succumb to regulatory pressure to censor DIDs, and will remain solvent and operational indefinitely.
Neither model is wrong. They reflect different threat models. A political dissident needs ION's censorship resistance. A healthcare provider issuing patient credentials needs Sovrin's governance accountability and regulatory clarity. The fact that both implement the same DID Core specification is a genuine achievement of the W3C working group: the specification is abstract enough to accommodate both.
What practitioners need to recognize is that choosing a DID method is choosing a trust model. The technical surface of both systems looks similar. The social and political architecture beneath them is radically different. Interoperability at the DID resolution layer does not mean interoperability at the governance layer.
Where PDAOS Fits in the SSI Stack
The Personal Data Asset Origination System, developed through Own Your Data Inc and explored in depth in The Invisible Data, treats decentralized identifiers as necessary infrastructure rather than the complete solution.
A DID establishes cryptographic control over an identifier. It does not establish what data has been generated by that identifier, who currently holds copies of it, what consent was given at the time of collection, or what value has been derived from it by third parties. These are data asset questions, not identity questions.
PDAOS uses DIDs to anchor consent receipts: structured records of what data was shared, with whom, under what conditions and for what purpose. The consent receipt is issued as a verifiable credential, with the data subject as holder. This makes the consent record portable, verifiable and not dependent on the data broker or platform to confirm what was agreed.
The MyDataKey implementation demonstrates how this works in practice: a DID-anchored personal data vault where the individual holds verifiable credentials representing consent grants and can present them to platforms or regulators as cryptographic proof of what was authorized.
The key insight from the PDAOS architecture is that SSI solves the authentication and attestation layer. It does not solve the data economy layer. Knowing who you are cryptographically is not the same as controlling what happens to the data trail you generate. Both layers are required for genuine data sovereignty.
SSI advocates have sometimes oversold the sovereignty claim by conflating identity control with data control. They are related but distinct. A person can have a perfectly functional self-sovereign identity and still have every behavioral trace, health record and financial pattern held by entities they have no visibility into and no leverage over. The SSI stack, as currently specified, does not change that. PDAOS is designed to address the gap.
The path from DID adoption to genuine data ownership requires solving the recovery problem, standardizing revocation across ecosystems, building governance frameworks that survive regulatory pressure, and connecting identity infrastructure to consent and data asset infrastructure. The W3C specifications give practitioners the right foundation. What happens on top of that foundation is still being determined by the organizations and engineers willing to build it honestly.