Sovereignty Takes a Village

Part 2 of the Sovereignty series.

Last time, I argued that only one kind of data sovereignty holds up: the kind built into the protocol. A reader asked me a fair question. If my data is mine, why do I need anyone else?

Here is my answer. You cannot be sovereign alone. Nobody can.

A king with no roads, no neighbors, and no one who recognizes his borders is just a man standing in a field. Sovereignty needs a network of people and services you trust. This post covers why you want sovereignty and how you get it, in plain language.

Start with why. Today your health record is in pieces. Your doctor has a piece. The hospital has a piece. The lab has a piece. You hold the smallest piece of all. Every clinic that wants to share must build a private connection to every other clinic. Five clinics need 10 connections. Twenty clinics need 190. The count grows much faster than the number of clinics, so the work never ends and records go missing when you need them most.

Sovereignty flips the picture. You hold the record. Each clinic connects to you once, with your permission. Twenty clinics need 20 connections. When you move, change doctors, or get sick far from home, your record goes with you [1].

Now the how. The trust server we are designing at EverBetter splits the answer in two: what you hold, and who you need.

You hold three things. The first is your name. You create your own digital identifier; no company issues it, so no company can take it back [2], [3]. A clinic can give you a patient relationship, and the clinic can end that relationship. The clinic cannot erase your name.

The second is your key. Your data is locked, and whoever holds the key can read it. If the company hosting your data holds the key, your sovereignty is a promise written in a contract. If you hold the key, it is a fact. Ask that question first.

The third is your permission. Every share is a recorded permission you grant and can take back. A program acting for you, such as an AI assistant, works under a permission you gave it. It never uses your password. Take the permission back and the program stops, even if it is broken or offline.

Those three things are yours. They still need a village to work. Here is who lives in it.

Witnesses keep copies of the history behind your name. If one witness goes offline, the others still have it. Think of several people signing as witnesses on an important paper [2].

Watchers have one job: notice if anyone shows two different histories for the same name. Think of a referee.

Sign in services come in more than one brand. If one breaks, people who use the others keep working. Your data stays where it is, still locked.

Shared lists answer questions everyone asks. Is this host approved to hold health records? Is this doctor licensed today? Is this software the real thing? Each list is open for anyone to check and kept by someone nobody has to trust alone.

Vouchers confirm that a clinic is a real member of the healthcare network in its state or country. There are many of them, one per region, so no single gatekeeper controls the door.

Checkers verify who you are before a clinic links you to its records. The check matches the stakes. A doctor gets a license check against the state board. A hobby account gets far less.

Now the uncomfortable part. Most of this village does not exist yet. Nobody runs the shared lists today. Nobody runs the witnesses for healthcare today. Every company needs them, no company sells them, and the first company to pay for them helps its competitors. That is why they are missing.

I see that as an invitation. Each empty seat is a job for a standards body, a licensing board, a hospital group, or a startup. We designed the trust server so those seats can be filled by many organizations, and so no single one of them, including us, sits above you.

Sovereignty is not living alone. It is choosing whom you trust, keeping the right to leave, and having enough independent neighbors that no one can hold you hostage.

References
[1] Solid Community Group, “Solid Protocol,” W3C Solid CG Report. [Online]. Available: https://solidproject.org/TR/protocol
[2] Trust over IP Foundation, “Key Event Receipt Infrastructure (KERI) Specification.” [Online]. Available: https://trustoverip.github.io/tswg-keri-specification/
[3] Trust over IP Foundation, “The did:webs DID Method Specification.” [Online]. Available: https://trustoverip.github.io/tswg-did-method-webs-specification/