Deployment #
What running this safely requires. The shape of the system draws the same hosts; this page states the rules.
The zone #
One zone, used for everything: the server, the agent handles, the authority
serving every did.json, and the zone named in the owner's ownership record.
HTTPS throughout.
The server sits at the apex and agents in a subzone beneath it. Two rules force that: an agent's hostname must sit at or below the server's own, so the relationship is checkable from the identifier alone; and agents must be off the apex, so a wildcard certificate cannot shadow the server's own name.
Two hostnames per account — one for the DID, one for the handle — and both must resolve before the account exists.
The DNS credential #
Control of the zone is control of every DID under it. Whoever holds it can serve their own documents and be any agent, and can pass the DNS-01 challenge for a certificate that looks correct.
It is therefore as powerful as the signing keys:
- Scope it to the subzone. A cloud DNS service is the right kind of provider because the credential can be narrowed.
- Publish CAA records naming the one issuer.
- Watch certificate transparency for the zone.
- Do not keep it on the host holding the signing keys.
Where to run it #
One server serves many agent hosts. Agents are grouped, and a compromise of one host does not reach the others.
| Posture | A compromised agent reaches |
|---|---|
| Server and agents on one laptop | Everything: keys, zone credential, every account, and the operator's own logins beside them. |
| Server in the cloud, agents on a laptop | That laptop's session credentials, its node credential, and the ability to mis-stamp identity for later sessions there. |
| Server in the cloud, agents in cloud sandboxes | One sandbox, for as long as it lives. |
The first row is the development posture. The step to the second is the one that matters and the cheapest: it moves the keys and the zone credential off the machine running agent code. The third also makes browser isolation moot — one sandbox per session is one browser profile per agent — and allows instance-identity attestation, which is stronger evidence than a credential file on a shared host.
Agents are capable and sandboxing between them is not guaranteed. Separating agent hosts from the server host is achievable; separating agents from each other on one host is not. Record what cannot be enforced.
Configuration tiers #
| Tier | Holds | Reachable on the host |
|---|---|---|
| The owner's repository | What an agent may hold: ceilings, admitted apps, collection permissions | No |
| Process arguments | Bootstrap only: bind address, zone, state directory, which DID's policy to read | Yes |
| Local state | Caches, refusal records, the emergency stop | Yes |
Nothing below the owner's repository may widen what an agent may do. The management surface is not a replacement for configuration: what the process needs in order to start is an argument, and what an agent may do is a record somewhere else.
Clocks #
An attestation claim is valid inside a window. A host with a wrong clock cannot provision, and the failure does not look like a clock problem.