The Registry: How a Patient’s Pod Checks Who Is Asking

If you are a patient, a registry decides whether the stranger asking for your record is who they claim to be. If you run a clinic, a registry decides whether everyone else can trust your host and your software. Part 1 argued that sovereignty means the patient decides who reads her record [1]. In Part 2 I called these “shared lists” [2]. Maxwell Humanity, a nonprofit that exists to support the trust network, would keep the registry of trust networks and defer to specialized governance bodies, such as EverBetter for healthcare [11]. In Part 3 I named public registries as a known limit of the trust server [3]. This post explains what a registry holds, who governs it, how it avoids a single gatekeeper, and how the trust server uses it at the moment of consent.

Our research is producing a registry design. Here is how it works.

A registry holds three kinds of answers. The first is which hosts may hold health records. The second is which clinicians hold a current license, and which board issued it. The third is which software is authentic, and which version passed review. Each entry is a signed statement from an authority about a party. A state licensing board stating that it licensed Dr. Chen is one example.

The registry stores the authority’s statement. The license stays with the board. A query tells you whether the board stands behind the license today. Our end-to-end use case puts it plainly: a license suspended yesterday fails today [9].

The registry holds no health facts. It holds no record of which patient shared which data with which clinician. Our requirements forbid both [8]. Those relationships stay private, inside the patient’s pod.

Now the governance. A registry is only as good as the rules behind it. Those rules live in a governance framework. The framework says who may issue which statements, at what assurance level, how a listing gets suspended, and how a dispute gets heard [6], [8]. The framework comes first. The registry publishes what the framework allows.

The query protocol only reads. The Trust over IP Trust Registry Query Protocol (TRQP) describes itself as “a lightweight, read-only protocol” [4]. It leaves creating, updating, and deleting entries to the system of record [4]. I like that split. Writing the rules, keeping the list, and asking the question stay in separate hands.

Now the uncomfortable part. The obvious failure is one registry run by one company. My own company is included in that warning. Today our Sovereign Platform nodes trust each other through a single EverBetter root certificate, with delegated certificates for hospital groups [10]. That works for a pilot. A national network needs many anchors.

Our design uses four rules to prevent a single gatekeeper. First, many registries exist, and each operator must be independently identifiable and provably authorized by its governing authority [8]. Second, registries recognize each other as peers. TRQP defines a recognition query for this purpose, and the specification treats recognition as a peer referral [4]. Our requirements add that recognition never grants unlimited trust down a chain [8]. Third, the asker decides. The W3C credential model states that “verifiers trust certain issuers for certain claims and apply their own rules” [5]. Our requirements say the same: a registry answer is an input, and the relying party applies its own policy [8]. Fourth, a neutral steward holds the specification. Maxwell Humanity would fill that seat with a light touch and leave vertical rules to vertical bodies [11].

Part 2 described regional vouchers [2]. Each voucher confirms that a clinic is a real member of the healthcare network in its state or country. The voucher and the registry are two halves of one job. The voucher makes the decision. The registry publishes it in a form a machine can query.

Registries then recognize each other’s vouchers. A Kansas clinic treating a visitor from Ontario could rely on Ontario’s voucher through recognition, with no contract between the two clinics.

Read the architecture north to south.

Now the how. Here is what happens when Dr. Chen asks for Sarah’s record.

1. Dr. Chen’s request reaches Sarah’s pod. It names the data, the purpose, and the duration [3].
2. The trust server confirms that the session belongs to Dr. Chen.
3. The trust server asks the registries three questions. Does the licensing board authorize Dr. Chen as a physician today? Does the regional voucher list her clinic as a member? Is the clinic’s software the attested build?
4. Signed answers come back. The trust server applies Sarah’s own rules to them.
5. Any unknown, stale, or unavailable answer fails closed [8].
6. The registry answers are stored with the consent record. A reviewer can later prove what was true at that moment [8], [9].

This step maps to an existing duty. HIPAA requires a covered entity to verify the identity and authority of a person requesting protected health information when that person is not known to it [7]. A registry query gives a pod a way to run that check for a stranger at 2 a.m.

Two problems remain open. Registries cost money to run, and the first operator helps its competitors [2]. Registry queries also leak metadata about who asks about whom, and when. Our requirements call for a privacy threat model that covers registry queries [8]. Who pays for the first registry is the question I most want answered.

The trust server gives the patient the keys. The registry tells her pod whom to let in. If you sit on a licensing board, a hospital group, or a standards body, one of these seats is yours to fill.

References

• [1] C. O’Neil, “Three definitions of data sovereignty. Only one holds up.,” thechrisoneil.com, May 8, 2026. [Online]. Available: https://thechrisoneil.com/three-definitions-of-data-sovereignty-only-one-holds-up/
• [2] C. O’Neil, “Sovereignty takes a village,” thechrisoneil.com, Oct. 14, 2026. [Online]. Available: https://thechrisoneil.com/sovereignty-takes-a-village/
• [3] C. O’Neil, “Trust server sovereignty: Who holds the keys to your health record,” thechrisoneil.com, Oct. 15, 2026. [Online]. Available: https://thechrisoneil.com/trust-server-sovereignty/
• [4] Trust Over IP Foundation, “ToIP Trust Registry Query Protocol (TRQP) v2.0,” ToIP Approved Deliverable, 2025. [Online]. Available: https://trustoverip.github.io/tswg-trust-registry-protocol/approved/
• [5] W3C, “Verifiable Credentials Data Model v2.0,” W3C Recommendation, May 15, 2025. [Online]. Available: https://www.w3.org/TR/vc-data-model-2.0/
• [6] Trust Over IP Foundation, “ToIP Governance Metamodel Specification,” Version 1.0, Dec. 21, 2021. [Online]. Available: https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2021-12-21.pdf
• [7] Other requirements relating to uses and disclosures of protected health information, 45 C.F.R. § 164.514(h)(1). [Online]. Available: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514
• [8] EverBetter LLC, “EverBetter Consent Spectrum v0.5: Requirements gap analysis for KERI, Trust over IP, Solid, and healthcare interoperability,” internal, Sept. 3, 2026.
• [9] EverBetter LLC, “Master use case: EBSS end to end,” internal, Sept. 2026.
• [10] EverBetter LLC, “EverBetter Solid Server: Technical overview,” internal, Sept. 2026.
• [11] EverBetter LLC, “EBSS architecture discussion,” internal meeting record, Sept. 16, 2026.