Is Sovrin the most realistic decentralized identity so far?
Here’s a simple explanation of how Sovrin works:
- Identity holder generates a keypair
- Identity holder completes a verification process with a claim issuer, who generates a verifiable claim, including the identity holder’s public key, signed with the issuer’s private key
- Identity holder provides claim to identity consumer
- Identity consumer validates the claim using public key verification
- Identity consumer validates the issuer’s claims (and the rest of the chain) using public key verification
- Identity consumer checks that no claims in the chain have been revoked using the blockchain-hosted revocation list
And here’s a simple explanation of how SSL works:
- Website admin generates a keypair
- Website admin completes a verification process with an SSL certificate issuer, who generates an SSL certificate, including the website’s public key, signed by the issuer’s private key
- Website provides SSL certificate to user’s browser
- Browser validates the certificate using public key verification
- Browser validates the issuer’s certificate (and the rest of the chain) using public key verification
- Browser checks that no certificates in the chain have been revoked using certificate revocation lists (CRLs) and/or online certificate status protocol (OCSP)
In other words, Sovrin have re-invented SSL.
And that’s why Sovrin is realistic in terms of implementation: because the claims they make are false.
The reason it will actually work is because it is NOT self-sovereign, and because it is no more decentralized than SSL.
The keypair is self-sovereign, just like SSL, but the identity — the set of claims a person holds — is completely within the power of issuers to revoke, just like SSL certificates.
Thus if an identity holder’s claims are revoked by the issuer, they no longer have a usable identity.
This makes the system, like SSL, able to deal with fraudulent, hacked, spam and lost identities — because, like SSL, it forces identity holders to trust claims issuers.
It’s even the same for Certificate Authorities.
Or “Trust Anchors” in Sovrin terminology.
Sovrin uses an “interlocking peer-to-peer trust network” which, after a closer look at the actual peer-to-peer communication involved, almost exactly parallels the way CA addition/revocation is communicated within the network of browser manufacturers and users.
The list of SSL root CAs today is decentralized — browsers are free to choose which CAs they trust, users are free to choose which browsers they trust, and everyone is free to signal their choices to others. The use of WOT to manage a CA list simply formalises (and arguably improves) this communication, but does not fundamentally change it.
To be fair, Sovrin have also added a few schematic and privacy upgrades:
- Extensible claims for arbitrary attributes
- Need-to-know attribute subset proofs that allow the identity holder to only reveal required attributes to an identity consumer
- Anonymous revocations that preserve the privacy of identity owners
All great ideas — and all valid extensions for SSL.
And on the flip side, Sovrin have also introduced new problems:
- Blocktime = latency, offering a window of attack while the revocation transaction is “pending” — issuers will respond by including an endpoint in the claim itself that allows identity consumers to check status in real time (i.e. OCSP)
- This realtime status check is also vastly easier to integrate with than the blockchain, and over time the network will switch to the realtime endpoint as the preferred method of integration, making the blockchain obsolete
And eventually the point is reached where the blockchain is serving no real purpose and can simply be pulled out — leaving something that looks an awful lot like SSL.


