Chapter 2: What is Self-Sovereign Identity?
What you'll learn:
- The idea behind self-sovereign identity and where it came from
- The three roles in every identity exchange: issuer, holder, and verifier
- How the "trust triangle" works — and why it does not require a central authority
- What a verifiable credential actually is
- How selective disclosure lets you share only what is needed
The physical wallet analogy
You probably carry a physical wallet. Inside it, you have a driving licence, a bank card, a library card, a loyalty card, perhaps a gym membership. Each card was issued to you by a different organisation. Each one is yours to carry. Each one proves something different about you.
When you need to prove you can drive, you show the driving licence — and only the driving licence. You do not empty your entire wallet onto the counter. The person checking it does not need to know that you go to that particular gym or have an account at that particular bank. You choose what to show, and you show only what is needed.
This is the model that self-sovereign identity (SSI) attempts to bring to the digital world.
What "self-sovereign" means
The word "sovereign" is deliberately strong. It means that you are the ultimate authority over your own identity data — not a government, not a tech company, not a platform you happen to use.
SSI is built on a simple principle: credentials should be issued to you, held by you, and presented by you. No third party sits between you and the organisation asking to verify your identity. No central database is queried. No intermediary needs to approve the transaction.
This is distinct from how most digital identity works today:
- Centralised identity: A single authority (a government, a company) holds your identity and vouches for you. Every verification goes through them. (Example: logging in "with Google.")
- Federated identity: Multiple authorities agree to trust each other. You log in via one and can access the others. (Example: "Sign in with Apple" accepted by a third-party app.) Your data still lives with the original authority.
- Self-sovereign identity: You hold the credential. You present it directly. The verifying party checks it against a public trust anchor — not against a private database they need permission to query.
The trust triangle
In every identity exchange — physical or digital — there are exactly three roles:
The Issuer creates and signs the credential. A government issues passports. A university issues degree certificates. An employer issues proof of employment. The issuer's signature is what makes the credential trustworthy.
The Holder receives the credential and stores it. You are the holder of your passport. In SSI, the holder stores credentials in a digital wallet on their own device.
The Verifier checks the credential. An airport security officer, an employer, a bank — anyone who needs to confirm something about you. The verifier does not contact the issuer to perform the check. Instead, they verify the issuer's cryptographic signature directly.
This triangle is the foundation of SSI. The issuer and the verifier do not need to communicate in real time. The holder can present the credential to any verifier, at any time, without the issuer being involved. This is what makes SSI decentralised: there is no central server that both parties need to reach.
Business significance: In traditional identity verification, the issuer is often a bottleneck. Every verification requires a live API call to the issuer's server. With SSI, the issuer's involvement ends when they sign the credential. Verification happens offline or against a publicly available trust anchor. This dramatically reduces load on central systems and removes single points of failure.
What is a verifiable credential?
A verifiable credential (VC) is a digital document that:
- States one or more facts about the holder (e.g., "date of birth: 1990-04-12")
- Is signed by an issuer using a cryptographic key
- Can be verified by anyone who can check that signature
The key word is "verifiable." Anyone who receives the credential can mathematically prove that it was signed by the stated issuer, has not been tampered with since signing, and is intended for the stated holder. This verification is done using public key cryptography — the same technology that makes HTTPS secure — and requires no contact with the issuer.
A verifiable credential might look like this in simplified form:
{
"issuer": "did:web:government.example.com",
"subject": { "id": "holder-wallet-id" },
"claims": {
"given_name": "Maria",
"family_name": "Santos",
"date_of_birth": "1990-04-12",
"nationality": "PRT"
},
"signature": "eyJhbGciOiJFUzI1NiJ9..."
}
The issuer field contains a DID — a Decentralised Identifier — which points to a publicly accessible document containing the issuer's public key. Anyone can fetch that document, get the public key, and use it to verify the signature. No registration, no API key, no permission required.
The diagram below shows what happens when a verifier receives and checks a credential:
We will go into much more detail on DIDs, signatures, and selective disclosure in later chapters. For now, the key point is this: the credential travels with the holder, and the verification is done by the verifier independently.
Selective disclosure: sharing only what is needed
One of the most powerful properties of modern verifiable credentials is selective disclosure — the ability to reveal only the claims that are needed for a particular interaction.
Imagine your passport credential contains your name, date of birth, nationality, passport number, and photo. An age verification service needs to know only one thing: are you over 18? With selective disclosure, your wallet can present a response that proves your date of birth is before a certain date — without revealing the date itself, and without revealing your name, nationality, or passport number.
This is not just convenient. It is a privacy protection mandated by modern regulation. The EU's GDPR requires data minimisation: you may only process the personal data that is strictly necessary. Credentials that support selective disclosure make GDPR compliance a technical property, not just a policy promise.
Developer note: In this book, we use SD-JWT (Selective Disclosure JWT) as the credential format. SD-JWT is the format mandated by eIDAS 2.0 for all EU digital identity credentials. Chapter 8 explains how it works technically.
What SSI is not
It is worth clearing up a few common misconceptions:
SSI does not mean anonymous. You can still be identified when you need to be. SSI gives you control over when and what you reveal — it does not remove identity from the system.
SSI does not require blockchain. This is perhaps the most common misconception. Early SSI systems were built on blockchains to store public keys in a tamper-proof way. Modern SSI standards (including the ones in this book) use simpler mechanisms — specifically, HTTPS-hosted documents called DID documents — that achieve the same result without any ledger technology.
SSI does not mean governments are irrelevant. Quite the opposite. Governments are often the most important issuers in SSI systems. eIDAS 2.0 mandates that every EU member state issue digital identity credentials to its citizens. SSI changes the distribution model — credentials go to wallets, not to private company databases — not the role of authoritative issuers.
Summary
Self-sovereign identity gives credential holders control: credentials are issued to them, held by them, and presented by them. Every identity exchange involves three roles — issuer, holder, and verifier — connected not by a central database but by cryptographic trust. Verifiable credentials travel with the holder and can be verified by anyone, without contacting the issuer. Selective disclosure means you share only what is needed.
This is the idea. Now we need to understand why turning it into a global reality requires standards — and what happened when we tried to do it without them.