Self-sovereign identity has been a recurring promise in privacy engineering circles for more than a decade. The core claim is simple: individuals should control their own identity without depending on Google, a government database, or a corporate identity provider. The W3C DID Core specification, finalized as a formal Recommendation in 2022, gave that claim a concrete technical form. Decentralized identifiers are now a real, deployable standard. The harder question is what that standard actually delivers in 2026 and where it leaves practitioners with unresolved problems.
This article walks through the architecture carefully. It identifies the genuine wins SSI provides, names the problems the community has not solved, and explains why two of the most serious DID implementations, ION and Sovrin, made opposite foundational choices that reveal a real tension inside the specification itself.
What Decentralized Identifiers Actually Are
A DID is a URI. That is the most important thing to internalize first. The W3C DID Core specification (https://www.w3.org/TR/did-core/) defines a syntax that looks like did:method:method-specific-identifier. The method determines which verifiable data registry the DID resolves against. The identifier is a method-specific string that points to a DID Document.
The DID Document is a JSON-LD structure. It contains public keys, authentication methods, service endpoints, and optional capability delegation. Nothing in the document requires a certificate authority. Nothing requires a username. The subject controls the private keys that correspond to the public keys listed in the document, and controlling those keys is what it means to control the identity.
This is architecturally different from OAuth, OpenID Connect, and SAML in a meaningful way. Those systems all require a trusted third party in the authentication flow. A DID-based interaction can be peer-to-peer. The verifier resolves the DID to its document, checks the cryptographic proof, and can establish that the presenter controls the identifier without calling home to any identity provider.
There are currently over 100 registered DID methods in the W3C DID Specification Registries. Not all of them are serious production systems. Some are experimental. Some are abandoned. The method landscape is fragmented, and that fragmentation is itself a governance problem the specification deliberately chose not to solve.
Verifiable Credentials and the Trust Triangle
DIDs are the identifier layer. Verifiable Credentials (VCs) are the claims layer. The W3C Verifiable Credentials Data Model (https://www.w3.org/TR/vc-data-model-2.0/) describes how an issuer attaches signed, machine-readable claims to a holder's DID. A credential might assert that a person holds a professional license, passed an age verification check, or owns a specific data asset.
The trust triangle has three roles. The issuer creates and signs the credential. The holder stores it, typically in a digital wallet. The verifier checks the issuer's signature and the holder's proof of possession without contacting the issuer in real time.
This offline verification property is significant. It means credential presentation does not create a surveillance trail back to the issuer. A university does not learn every time you present your degree credential to an employer. This is a genuine privacy improvement over federated identity systems where the identity provider can log every login event.
The data model supports selective disclosure when combined with the right cryptographic scheme. BBS+ signatures, standardized through the IETF Decentralized Identifier Working Group materials and the W3C VC extensions, allow a holder to prove specific attributes from a credential without revealing the full credential. You can prove you are over 21 without revealing your birthdate. You can prove organizational membership without revealing your name. That selective disclosure capability addresses one of the core privacy harms that federated identity creates, which is unnecessary data minimization failure.
What SSI Genuinely Solves
The honest accounting of SSI's wins matters. The technology community has a habit of overselling decentralization and then dismissing it entirely when early deployments struggle. The real wins are specific and worth naming clearly.
SSI eliminates pairwise correlation at the identifier level. When you use a different DID for each relationship, a data broker cannot link your interactions across contexts by observing a shared identifier. This is a structural improvement over email-based login where your email address is a global correlator.
SSI removes the dependency on a single point of failure for authentication. When an identity provider is breached or shut down, users lose access to every service that trusted it. A DID-based system has no central point with that kind of leverage.
The verifiable credential model enables consent receipts that are cryptographically anchored rather than just logged in a database the user does not control. In the PDAOS framework developed through Own Your Data Inc, this matters directly. A data origination event can be paired with a VC issued by the originator asserting the terms under which that data was created and shared. That VC travels with the data rather than living only in the platform's terms-of-service database.
SSI also enables portability at the identity layer. A holder's wallet is not locked to a platform. Credentials issued by one system can be presented to any verifier that trusts the issuer, regardless of which application the holder uses. That portability is architecturally what GDPR's right to data portability has struggled to achieve at the data content layer.
The Recovery Problem Nobody Talks About Enough
Here is where the architecture runs into real-world friction. If you control your identity through private keys, what happens when you lose your keys?
Traditional identity systems answer this with a password reset email, a customer service call, or identity verification against a government database. SSI systems, by design, have no equivalent fallback. That is the point. The absence of a central authority means there is no authority to appeal to when recovery is needed.
The solutions proposed in practice are social recovery, hardware security modules, and threshold signatures. Social recovery, popularized in Ethereum smart contract wallets and described in schemes like those using Shamir Secret Sharing (documented in IETF RFC 6979 and related threshold cryptography literature), splits the key recovery process across trusted contacts. If you lose your key, a quorum of your designated guardians can authorize regeneration.
Social recovery works on paper. In practice, it introduces a trust model that looks uncomfortable close to the federated identity trust model it was supposed to replace. Your guardians become a distributed identity provider. If they collude, they can take your identity. If they are unavailable, you cannot recover. The cryptography is sound. The human coordination problem is not solved.
Hardware security modules solve key loss for well-resourced institutional actors. They do not solve it for a person who dropped their phone in a river. The personal sovereignty claim of SSI implicitly assumes a level of operational security that most people do not maintain.
This is not a reason to abandon SSI. It is a reason to be precise about what it delivers. SSI provides cryptographic sovereignty. It does not automatically provide practical resilience against ordinary human error. Any production deployment of a DID-based system needs an explicit recovery architecture, and that architecture will always involve some tradeoff against the self-sovereign ideal.
Revocation at Scale Is Still Broken
Credential revocation is the other unsolved problem. The W3C VC data model defines a status check mechanism. The most common implementation is a Status List, where the issuer publishes a bitstring representing the revocation status of all credentials in a batch. A verifier checks whether the bit corresponding to a credential is flipped.
This approach has a privacy leak. When a verifier fetches the status list from the issuer's endpoint, the issuer can observe that someone is checking credentials in that batch at that moment. With enough traffic analysis, issuers can infer presentation patterns.
Zero-knowledge revocation schemes exist. The W3C VC working group has discussed cryptographic accumulators that allow a prover to demonstrate non-revocation without revealing which credential is being checked. RSA accumulators and more recent pairing-based schemes can provide this. They are computationally more expensive and operationally more complex to deploy.
Neither approach scales effortlessly to the credential volumes that a national identity system, a large healthcare network, or a high-frequency data marketplace would require. The revocation problem is not theoretical. In 2026, it remains one of the primary reasons that regulated industries have not fully committed to VC-based systems for high-stakes credentials.
Why ION and Sovrin Took Different Paths
ION and Sovrin are the two most significant DID infrastructure implementations developed prior to the current period, and their architectural divergence exposes the real fault line inside SSI philosophy.
ION (Identity Overlay Network) was developed by the Decentralized Identity Foundation and Microsoft. It uses the Sidetree protocol anchored to the Bitcoin blockchain. DID operations, create, update, deactivate, are batched into transactions and written to Bitcoin. Anyone can run an ION node. No one needs permission to participate. The ledger is permissionless and censorship-resistant by design. The tradeoff is that Bitcoin's throughput is limited, finality takes time, and there is no governance body to mediate disputes. ION is philosophically committed to the idea that the root of trust must not be controlled by any organization.
Sovrin took the opposite position. The Sovrin Network uses a permissioned distributed ledger built on Hyperledger Indy. Only approved Stewards can write to the ledger. Those Stewards are vetted institutions, universities, NGOs, regulated businesses. The Sovrin Foundation maintains governance documents that define who can participate and under what rules. The tradeoff is the reverse of ION's: Sovrin offers faster finality, cleaner revocation support, and accountable governance, but the root of trust is a foundation and its approved participants, not a decentralized proof-of-work chain.
The tension between these models is not resolvable through better engineering. It is a values choice. ION optimizes for censorship resistance and asks users to accept weaker operational guarantees. Sovrin optimizes for institutional reliability and asks users to trust a governance body.
For practitioners building on PDAOS architecture, this choice maps directly onto the data governance question. A permissionless DID method maximizes individual sovereignty but leaves the data marketplace without an adjudication layer when credential fraud occurs. A permissioned method provides an adjudication layer but recreates a centralized governance dependency. The right answer depends on the threat model of the specific deployment.
PDAOS and the Gap SSI Leaves Open
The Personal Data Asset Origination System addresses a problem that SSI infrastructure alone does not solve. SSI answers the question of how identity claims are asserted and verified. PDAOS addresses how data created by a person is cryptographically linked to its originator across its entire lifecycle.
A DID identifies you. A verifiable credential asserts something about you. Neither, by itself, asserts that a specific dataset was created by you, that you consented to specific uses of that dataset, or that downstream processors are bound by those consent terms. The gap between identity and data provenance is where personal data exploitation currently lives.
In The Invisible Data, Volume 6 of The Invisible Series, Dr. Fisher frames this as the origination gap. The technical infrastructure for sovereign identity has advanced substantially. The infrastructure for sovereign data provenance is still being built. MyDataKey (mydatakey.org) is one implementation effort addressing this gap by pairing DID-based identity with cryptographic data asset certificates that travel with data rather than residing only in platform-controlled consent management systems.
The W3C work on DIDs and VCs is foundational. It is not sufficient. SSI advocates who treat the DID specification as the end state of the personal data sovereignty problem are conflating identity sovereignty with data sovereignty. They are related problems with significant technical overlap, but they are not the same problem.
Recovery and revocation remain open engineering challenges. The governance tension between permissionless and permissioned ledgers remains a values disagreement with no engineering resolution. The gap between identity and data provenance remains an architectural space that the current W3C specifications do not fill.
None of that diminishes the genuine progress the DID and VC specifications represent. It means that practitioners need to deploy them with clear eyes about what they are buying and what additional architecture they need to build alongside them.