How SSI works, in one picture
The three roles
An issuer signs a credential and gives it to you. You are the holder — it lives in your wallet. When a verifier asks, you present a proof, and they check the issuer's signature with maths rather than a phone call.
Identity is borrowed, not owned
Think about how identity works online today. Every time you want to do something — rent a flat, open a bank account, prove your age — you photocopy your documents and hand them to a stranger. They keep a copy. You keep doing it. It's slow, it's insecure, and you have no control.
- You upload your passport
- The platform stores a copy
- Every service repeats the check
- One breach exposes all of it
- You receive a signed credential
- It stays in your wallet
- You present only the fact needed
- Nobody stores a copy to leak
Three ideas that fix it
SSI rests on three simple ideas. Together, they replace the "photocopy-and-hope" model with something you actually control.
Example: proving your age at a venue. Same question, very different amount of you handed over.
Today — you show your licence
With SSI — you show one fact
| Scenario | Today | With SSI |
|---|---|---|
| Opening a bank account | Email scans of your passport and a utility bill, wait days for someone to check them by eye. | Present a verified identity credential. The bank confirms it cryptographically in seconds. |
| Proving your age at a venue | Hand over your driving licence — the door staff see your full name, address, and date of birth. | Tap your phone. It proves you're over 18 and nothing else. |
| Starting a new job | Request a reference, wait for a transcript, re-do the background check every time. | Show a credential from your previous employer and university. Verified instantly, no phone calls. |
| Logging into an app | Create an account, choose a password, receive a code by email, hope nobody reused it. | Sign in with your wallet. No password to steal, no email loop, no account to delete. |
See it happen end-to-end
Walk through a credential being issued to a wallet and then verified by someone else — five clicks, no setup.
Acme University
Issuer
Signing DID
did:prism:1c4e7a…d3f621
Offer sent: Over 18
Alice's wallet
Holder
did:prism:5f2a9c…41f83b
Empty — waiting for the offer.
The Blue Door (bar entrance)
Verifier
Not involved yet.
Step 1 · Issuer offers. Acme University signs a credential about Alice and sends her an offer. Nothing is published about her anywhere.
What it feels like
Instead of describing it, here's a morning where SSI is just… how things work. No scans, no waiting, no handing over more than you need to.
- 09:00
Rent a flat
Your estate agent requests proof of income and right-to-rent. You present two credentials from your wallet. They verify instantly — no scans, no waiting.
- 11:30
Start a job
Your new employer asks for your degree and a background check. Your university already issued you a credential; you present it. No transcript request, no phone calls.
- 14:00
Open a bank account
The bank needs KYC. Instead of uploading documents, you present a verified identity credential and a proof-of-address credential. Onboarding finishes in minutes.
- 17:15
Pick up a parcel
The courier needs to confirm it's you. You present a minimal proof — just that this phone's owner is verified — without revealing your name or address.
Upgrade what you already run
SSI isn't about throwing away the web you have. It's about replacing the fragile parts — passwords, document uploads, cold-start KYC — with something safer and faster.
Passwordless login
Let users sign in with their wallet instead of a password. No credentials to steal, no reset flows to support, no email verification loops.
Privacy-preserving checks
Age, residency, accreditation — prove the fact without revealing the document. Useful for gaming, alcohol, finance, and healthcare.
Lower breach liability
When you're not storing copies of your users' passports and licences, there's nothing to leak. A breach stops being an identity crisis.
Reusable KYC
Verify a customer once, issue them a credential. They present it to every other service that needs the same check. Compliance gets cheaper for everyone.
Where SSI and web3 meet
Blockchains are great at moving value, but they don't tell you who is on the other end. SSI fills that gap — and the two complement each other more than they compete.
- · Logins without passwords
- · KYC that gets reused
- · HR & education checks
both worlds
- · Wallet-native identity
- · DAO membership
- · Portable reputation
| Question | SSI alone | SSI + web3 |
|---|---|---|
| Needs a blockchain? | No — SSI works with any trust anchor, including none for local use. | Optional — a ledger makes a strong, shared trust anchor for DIDs. |
| Who holds the keys? | You, in a wallet you chose. | You, in the same wallet that may hold crypto. |
| Best for | Replacing logins, KYC, and document checks in everyday services. | Adding a verifiable identity layer to on-chain activity. |
| Privacy default | Selective disclosure — share the minimum. | Public-by-default unless you add selective disclosure. |
The honest version: SSI doesn't need a blockchain to work. But when you already have one, it makes a strong, shared trust anchor for resolving DIDs. They're partners, not rivals.
Prove it without showing it
We said SSI lets you prove a fact without handing over the whole document. Zero-knowledge proofs are the cryptography that makes that real — and they go further than you might expect.
A zero-knowledge proof (ZKP) is a way to prove a statement is true without revealing the information that makes it true. You prove you're old enough, or that you earn above a threshold, or that you hold a qualification — and the person checking learns only that single fact, nothing more.
The classic analogy: imagine proving two balls are different colours to a friend who can't see them. You let them shuffle the balls and tell you whether they swapped. Do this enough times and, without ever revealing which ball is which, you've proved the colours differ beyond any doubt. A ZKP does the same thing with mathematics — and in a single step.
Same question — "are you over 18?" — two ways to answer it.
What leaves your wallet
Try a real zero-knowledge proof
The console has a live prover: a Noir circuit compiled in your browser that proves you're over 18 without revealing your birth year. Generate it, verify it, then tamper with it and watch verification fail.
Open the ZK demoProve one fact
Age, income threshold, membership, or qualification — prove the statement is true without handing over the document that backs it.
Private compliance
Show a regulator or partner that you've passed KYC, are accredited, or hold a licence, without exposing the PII behind it.
Unlinkable verification
Each proof is fresh and uncorrelated — two verifiers checking the same credential can't join their logs to track you across services.
Where this fits today: The console demo is a genuine zero-knowledge proof — a Noir circuit compiled in your browser and proven with Barretenberg's UltraHonk prover, where the birth year is a private input that never leaves the page. Identus credential presentations are a separate layer: the live console in this app issues JWT-based verifiable credentials, which do selective disclosure but not zero-knowledge proofs. AnonCreds and BBS+ are the ZK-capable credential formats that let you bind a proof like the one above to an issued credential.
AI agents need identity too
Agents are starting to act on our behalf — booking, buying, negotiating with other agents. That makes two questions urgent: who is this agent, and who does it act for? and is it allowed to do this? Passwords and API keys can't answer either. DIDs and verifiable credentials can.
A2A
Agent-to-Agent
How agents discover each other and collaborate on a task.
Where SSI fits: Each agent gets its own DID, so identity and capability claims are portable and checkable — not trusted just because of a hostname.
AP2
Agent Payments Protocol
Lets an agent pay on your behalf using a signed mandate.
Where SSI fits: That mandate is a verifiable credential: a scoped, expiring, revocable delegation instead of a stored card number.
UCP
Universal Commerce Protocol
Machine-readable commerce so agents can transact with merchants.
Where SSI fits: Merchant and buyer-agent credentials (KYB, age, entitlement) get verified in-line — no account signup step.
x402
HTTP 402 pay-per-call
Machine clients pay per request instead of holding an API key.
Where SSI fits: Pair the payment proof with a credential proof so a service can price and authorise a caller in one round trip.
What an agent credential carries
Revoking one agent's credential doesn't touch any of your other credentials — you retire the delegation, not your identity.
How delegation works, step by step
Instead of handing an agent your credentials, you hand it a narrow, time-boxed permission that anyone downstream can verify. Walk the chain one hop at a time.
Alice has an identity she owns
Alice
did:prism:alice…Issues a delegation credential — scope: book travel · limit EUR 500 · expires in 30 days.
Alice's agent
did:prism:agent…Holds the credential and presents proof (plus payment) when it acts.
Airline / service
verifierChecks the issuer, the scope, the expiry, and revocation status before accepting.
What happens
Alice's wallet creates a DID — a public identifier with a private key only she holds. No sign-up form, no company account.
Why it matters
Everything later is signed with that key, so a permission can be traced back to Alice without anyone storing her personal details.
What's actually checked
All five hops, in order
- 1. Alice has an identity she owns — Alice's wallet creates a DID — a public identifier with a private key only she holds. No sign-up form, no company account.
- 2. Alice writes the permission down — She issues her agent a delegation credential that says exactly what it may do: book travel, spend up to EUR 500, valid for 30 days.
- 3. The agent holds a badge, not your keys — The agent stores the signed credential in its own wallet, under its own DID. It never receives Alice's password, card, or private key.
- 4. The agent acts and shows its proof — When it books a flight, the agent presents the delegation plus proof it controls its own DID — revealing only the fields the airline needs.
- 5. The airline verifies before it accepts — The verifier checks the signature, who issued it, the scope, the spend limit, the expiry date and the revocation status — then accepts or refuses.
Try it: issue a mandate and verify the action
Grant an agent a scope, a spend cap and an expiry, then watch a verifier accept the honest action — or reject the ones that break the rules.
Alice grants her AI agent a narrow, time-boxed mandate. The agent then tries an action and a verifier checks it, hop by hop. Signing and verification really happen in your browser with WebCrypto — the DIDs and the airline are illustrative.
1. Set the mandate
Spend cap (EUR)
Valid for
Scope book:flight — everything else stays off-limits, whatever the agent is asked to do.
2. Issue it to the agent
Alice (delegator DID)
did:prism:54a048f821a6d18a72caf418402d6f9b
Agent (subject DID)
did:prism:f64888086748b1675cf4eebe0b42c4ea
Generating a keypair…
3. Agent acts, verifier checks
The agent presents the credential to Aer Sky airline agent with a proposed action.
Issue the credential first.
- Signature is validHop 2 — Alice signed the permission
- Issuer is Alice's DIDHop 1 — Alice's identity
- Subject is this agentHop 3 — the agent holds the badge
- Scope covers the actionHop 4 — acting with proof
- Amount within spend capHop 4 — acting with proof
- Mandate not expiredHop 4 — acting with proof
- Mandate not revokedHop 5 — the verifier decides
What just happened
Alice never shared a password or a payment method. She signed one narrow statement — this agent, this scope, this cap, until this time — and the verifier could check it independently: maths on the signature, then plain rules on the claims. Every failure above is caught before the action happens, not reconciled afterwards.
Want the code behind this? The sandbox quickstart has copy-paste TypeScript for issuing a delegation credential and verifying it before an agent acts.
Use cases: where delegation fits
Four protocols, four concrete flows. Tap a card to see the steps and the exact point where a verifiable delegation is checked.
What this unlocks
Buy within a budget
Your agent books a flight and the merchant can prove the mandate was signed by you, capped and unexpired.
Prove without sharing
An agent shows you're a verified customer over 18 without revealing your account or date of birth.
Agent-to-agent trust
Two agents negotiate and each checks the other's issuer before exchanging anything of value.
None of this needs a new stack. Identus already gives you the pieces these protocols assume: DIDs for agents and humans, credential issuance and verification, and revocation when a delegation should stop working. All four protocols above run as live demos in the console — real A2A messages, real signatures, and a real testnet payment.
Delegation, disclosure & verification for agents
Short, plain-English answers to the questions that come up most when an AI agent starts acting on behalf of a person — how it proves it's allowed, what it can reveal, and how the other side checks it.
Delegation
Selective disclosure
Verification
The open-source building blocks
Hyperledger Identus is the open-source stack that makes SSI real: DIDs you can create and publish, secure connections between wallets, and verifiable credentials you can issue and check. This app lets you try all of it live — against a simulated agent first, then a real one you deploy yourself.
DIDs
Create and publish identifiers you control.
Connections
Link wallets securely over DIDComm.
Credentials
Issue, hold, and verify proofs of fact.
Frequently asked questions
Short, plain-English answers to the questions that come up most when people first meet DIDs, credentials, and verification.
DIDs
Credentials
Verification
Want the technical version? Read the primer.