What secures a Solidus pod's identity, if not a certificate authority?
What a trust anchor is
The thing you believe without checking anything else. Every verification chain terminates somewhere; the anchor is where it stops.
On the web, that is a certificate authority. Your browser ships with a list of them, and because you trust that list, you can trust a certificate, and therefore a domain, and therefore a document served from it, which is exactly how dereferencing a WebID works (the mechanism is here).
The certificate model, credited properly
It is not a legacy compromise. It is a working system with properties ours does not have:
- Independent, audited operators. Certificate authorities are audited against published criteria, by third parties, on a schedule.
- Decades of adversarial history. It has been attacked, has failed, and has been repaired in public, including transparency mechanisms built specifically to catch misissuance.
- Universal client support. Every device already trusts it. No integration required, by anyone, ever.
That last property is the one nothing else in this field currently matches, and Solid gets it for free by using HTTPS URLs as identifiers.
Where it strains
- A domain is rented. Let it lapse, lose control of it, or have it transferred, and identifiers built on it stop meaning what they meant.
- The domain owner is unilateral. Whoever controls the domain can rewrite the document served there, and a reader who did not keep the previous copy cannot tell that it changed.
- Revocation is famously awkward. Checking whether a certificate is still good is a separate mechanism with its own failure modes.
These are strains, not disqualifications. Enormous amounts of critical infrastructure run on this model and will continue to.
What we do instead, and what it actually buys
The record lives on a chain, and the rules for changing it are enforced by consensus rather than by whoever controls a domain.
Resolving a real identifier returns a record carrying a version identifier, created and updated
timestamps, an active flag and a recovery policy, An invented identifier returns
null, so that is a real record.
Two properties follow, and they are narrow:
- No single domain owner can silently rewrite it. Changing the record requires satisfying the chain's rules.
- A reader can detect that it changed, and when, without having cached the old copy.
That is the whole of the benefit. It is real, and it is smaller than "we replaced certificate authorities."
And the cost, stated at full strength
Our chain is four validators, all operated by us. One node operator.
So the anchor is: a company you have to trust, running software nobody has audited, on a network with no production deployment. Against an audited institution with decades of public failure history and universal client support, that is not a close comparison, and we are not going to present it as one.
The honest form is: we have moved the trust from one place to another, and the place we moved it to is currently weaker on every measure except the two properties listed above. We think the direction is right. We have not earned the claim that the destination is better.
What would change the comparison
- Independent node operators, so the anchor is not one company. None exist.
- A published external security audit of the chain and its cryptography. None.
- Production operation rather than a testnet. Not yet.
All three are the same list that appears on every honest page of this estate, and none of them is done.
What this does not settle
An anchor tells you a record is authentic. It does not tell you the record is true, and it does not decide who may read what, credentials and access control are separate layers with their own status.