SSI vs DID: what is actually different
The two terms get used as synonyms in vendor copy. They sit at different layers, and treating them as one thing makes it very hard to evaluate anything honestly.
Self sovereign identity (SSI)
A claim about who should hold identity. It says the subject, a person or an agent, should hold their own identifiers and credentials and present them selectively, rather than renting an account from a platform that can revoke it. SSI is a goal, not a file format.
Decentralized identifier (DID)
A W3C standard for writing an identifier down so it resolves to a document containing public keys and service endpoints. It is one way to name a subject. On its own it does not make a system self sovereign.
One is a goal. The rest are mechanisms.
Reading it as three layers makes the vendor claims much easier to sort.
What a DID actually is
Three parts, and only one of them is interesting.
Always did. It tells a resolver what kind of identifier follows.
The part that decides everything. It names the system that says where the record lives and how to read it.
The subject, as that method names it. Meaningless outside the method.
Two DIDs with different methods have almost nothing in common beyond the prefix. When a product says it supports DIDs, the useful follow up is which methods, and where those methods anchor.
What SSI is actually asking for
Control
The subject holds the key. Nobody revokes the identity by deleting a row, because there is no row to delete.
Portability
The identifier outlives the application that created it. If you cannot take it somewhere else, what you had was an account.
Minimal disclosure
Prove the specific thing being asked. Prove membership without handing over the whole membership record.
SSI, DID, and BAP
| SSI | DID | BAP | |
|---|---|---|---|
| What it is | A design position | An identifier syntax and resolution model | A protocol for anchoring identities and attestations on Bitcoin SV |
| Question it answers | Who should hold identity | How to name a subject and find its keys | Where the record lives and how it stays tamper evident |
| Standardized by | No single body | W3C | An open specification, not a W3C standard |
| Requires a blockchain | No | No | Yes, Bitcoin SV for the anchor |
| Sufficient on its own | No, it is a goal | No, it names but does not authenticate | Provides the anchor. Authentication and authorization sit on top |
Anchored on BSV, key held by the user
Sigma takes the self sovereign position and implements it with a Bitcoin anchored record. Users hold a key that never leaves their device. Identity entries and attestations are published through BAP, the Bitcoin Attestation Protocol, so the record is public and tamper evident without a registry operator deciding who gets to be in it. The attestation hashes live on BSV, which is the anchor chain. The key that generates the identity is a separate matter, and it can be one the user already holds on another blockchain. Authentication is a signature. Authorization can then be based on what that identity holds.
did: identifier, that is a real constraint and you should weigh it before going further.Three quick ones
- Do I need SSI to do Know Your Agent?
- No, but the two pull in the same direction. KYA needs an identity a verifier can check without the vendor's help, which is most of what SSI is asking for. The KYA explainer covers the requirement side.
- Is a DID the same as a wallet?
- No. A wallet holds keys and signs with them. A DID is a name that resolves to keys. A wallet can hold the key behind a DID, and often does, but they are different objects doing different jobs.
- Can a system use both DIDs and a chain anchored record?
- Yes, and several do. A DID method can specify a blockchain as its resolution target. The distinction that matters is not the syntax you write the identifier in, it is whether the party being verified controls the record.