Whenever I explain Self-Sovereign Identity to someone new, I start with the same diagram. Three boxes: Issuer, Holder, Verifier. Arrows between them. It looks simple, almost trivial. But the simplicity is deceptive — under those three boxes is a stack of protocols, cryptographic primitives, and governance decisions that took years to standardize.
The Three Roles
Let us break them down properly.
Issuer. Any entity that can make claims about a subject. A government that issues a passport. A university that issues a degree. A bank that issues a KYC credential. The issuer cryptographically signs the credential so that anyone can verify it came from them.
Holder. The subject of the credential (or someone authorized by the subject). The holder receives the credential from the issuer, stores it in a wallet, and presents it to verifiers. Critically, the holder controls when and with whom they share their credentials.
Verifier. Any entity that needs to verify claims about the holder. A hotel that needs to see your ID. An employer that needs to verify your degree. The verifier checks the cryptographic signature, checks that the issuer is trusted, and checks that the credential has not been revoked.
The magic is that the verifier does not need to call the issuer to verify the credential. They can do it offline, using only public information (DID documents, public keys, revocation registries).
What Makes It Self-Sovereign
The "self-sovereign" part is easy to miss but it is the whole point. In the old model, your identity lived in someone else's database. The government had your passport data. Facebook had your social graph. Your bank had your financial history. You were a guest in their systems.
In the SSI model, the holder holds the credential. Not the issuer. Not a centralized registry. The holder's wallet. This means:
- The issuer cannot track when and where you present their credential
- The verifier cannot correlate presentations to build a profile on you
- You can present credentials without the issuer's involvement
This is the fundamental shift. Identity becomes something you have, not something a system has about you.
Where People Get Confused
There are two things that consistently trip people up when they are first learning this model.
First: the distinction between the issuer of a credential and the issuer of a DID. These are often conflated. A DID is an identifier. A credential is a claim about an identifier. You can have a DID that you created yourself (a "peer DID") and still receive a credential from a government. The DID is your self-administered identifier; the credential is someone else's claim about you.
Second: revocation. If the holder holds the credential, how does the issuer revoke it? This is the hardest problem in the model, and it has driven a lot of interesting cryptography. Status lists, accumulators, KERI's key event receipts — there are multiple approaches, each with tradeoffs between privacy, performance, and complexity.
What We Built at AYANWORKS
In CREDEBL, we implement the full issuer-holder-verifier stack. Our issuer service handles credential issuance at scale. Our wallet SDKs let holders store and present credentials on mobile and web. Our verification service handles presentation verification, trust registry lookups, and revocation checks.
The thing that surprised us most when we started building this? How many "SSI" solutions out there violate the model. They issue credentials but store them in a central database. They verify presentations but log every interaction. They call themselves self-sovereign but they have built a federated identity system with better marketing.
Real SSI is hard. The cryptography is complex. The UX is challenging. The governance is messy. But it is the only model that puts the user in control, and that makes it worth the effort.
Ajay Jadhav
CTO, AYANWORKS