Attestation chains

How does a pharmacy verify a prescription in a system without a central healthcare database?

The pharmacy doesn't know the doctor personally. The doctor signed the prescription, so the signature is real. But "real" isn't enough — the pharmacy needs to know this signer is a licensed doctor. In a centralised system, a database holds that fact: query it, get an answer. In a peer-to-peer system, there's no central database to query.

The answer is the same shape as how it works in the physical world. The doctor carries a credential issued by the medical board, signed by the board's identity. The pharmacy trusts the medical board — a small, well-known set of institutions. The doctor presents the credential alongside the prescription. The pharmacy verifies the chain locally: the prescription is signed by the doctor; the doctor's credential is signed by the medical board; the medical board is in our trust roots. Done.

How it composes

Each link in the chain is a signed document:

Government ──signs credential──> Medical Board ──signs credential──> Doctor
                                                                       │
                                                                       └─ signs prescription,
                                                                          references credential

To verify a prescription, the verifier walks backwards:

1. The prescription is signed by Doctor A.
2. Doctor A's credential is signed by the Medical Board.
3. The Medical Board is a trust root for "physician" credentials.
4. Chain terminates. Valid.

Trust roots are local configuration — a pharmacy in Finland trusts the Finnish Medical Board, perhaps a few cross-border ones too. Same way your browser ships with a list of trusted certificate authorities.

The patient holds their own credential chain. When they hand a prescription to the pharmacy, they hand the supporting credentials with it. The pharmacy verifies everything locally, without phoning home to any service.

What it replaces

This is the same problem PKI was designed to solve — proving that a key holder has a particular role or authority — and the architecture is the same: a chain of signed statements terminating at trust roots configured by the verifier.

What Wish leaves out is the rest of the PKI infrastructure:

• No certificate authority hierarchy to negotiate your way into.
• No certificate formats with their own parsers and ASN.1 trauma. Credentials are regular signed documents with regular fields.
• No separate revocation infrastructure. Revocations are documents too, published and synced like anything else.
• No platform involvement. The subject owns their credentials, presents them to whomever they choose, and keeps a copy when they leave.

Where this generalises

The pattern isn't healthcare-specific:

Issuer	Credential	Verifier
Medical Board	Physician license	Pharmacy, Hospital
University	Degree	Employer
Government	Identity document	Service provider
Manufacturer	Device certification	User, regulator
Code-signing authority	Signing certificate	Package manager

The same shape covers all of them. An issuer signs a credential for a subject. The subject references it in their signed actions. Verifiers walk the chain to a trust root they already configured.

It's a small primitive — the document store handles content addressing, signatures, and sharing; the chain walker is a couple hundred lines of code. The bigger thing it builds is a real-world trust model that doesn't need a platform in the middle.

← Back to Why Wish