Privacy

Privacy in Tenure is structural, not policy. Two mechanisms carry the load: after mint, no plaintext claim values exist registrar-side (derive-then-purge), and worker keys are per-employer, so cross-employer correlation is impossible by construction. This page describes the data split and the honest limits of each promise.

The data split

Visibility	Data
Public	Signed log heads, checkpoints, the epoch chain, the existence of delegations (type-level only), revocation commitments, and entity (KYB) attestations. Employer identity is public; workers never are.
Authorized-only	Claim payloads, the subject-to-employer mapping, and share contents — visible to the employer, the subject, grant audiences, and authorized auditors
Holder-held	Inclusion receipts — witnessing without publishing the employment graph

A revocation commitment is the BLAKE3 hash of an attestation identifier. A grant holder who already knows the identifier can check whether it is revoked; to anyone who does not, the commitment is unlinkable.

The authorized-only class is enforced with credentials, not convention. Wallet and access-log reads require a holder authentication proof — knowing a subject key is not authorization, signing with it is — and the portable export, which carries the subject roster, requires the employer’s own credentials. The public feed serves exactly the public class above: descriptor, entity attestation, epochs, delegations, revocation commitments, and a live-signed checkpoint. Nothing needs a credential in order to verify, and nothing about a worker leaks without one.

Derive-then-purge

The registrar must see exact values at mint — it derives the band and threshold variants of a claim family from the exact figure. The moment that is done, it purges the plaintext, retaining only:

1. subject-encrypted blobs — the claim payloads sealed to the worker’s key, and
2. commitments — including the registrar signature over the exact member bytes.

“Encrypted at rest with registrar-held keys” was the earlier posture and is explicitly rejected: it protects against disk theft, not against compromise or legal compulsion. Derive-then-purge means a compromised or compelled registrar has no plaintext to give up.

Recovery is commit-only. No employer-decryptable escrow is retained for any recovery mode. A policy-authorized recovery is credential rotation: the employer re-furnishes the value, the registrar re-mints it to a fresh subject key and verifies the reconstruction against the retained signature — the commitment — so recovery works without the registrar ever holding something a second party could open. One hardening remains open: having the employer derive the band and threshold variants client-side, so that the registrar never sees the exact value even at mint.

Per-employer keys

A worker has a fresh Ed25519 keypair per employer, generated silently when they claim a wallet. This is the privacy spine:

• there is no key that links a worker’s records across two employers;
• bundles are sealed to their audience;
• nothing about a worker is publicly enumerable.

Because correlation is impossible at the key layer, the system never aggregates, scores, or hints that two employers’ statements corroborate each other. No corroboration is implied anywhere — per-employer keys make triangulation impossible by design, and the design leans into that rather than working around it.

Disclosure is consented, logged, and decaying

• Consented. A disclosure happens only when the worker signs a Share Grant. The wallet shows a preview of exactly what the verifier will see before the grant is signed.
• Logged. Every fetch the registrar serves — link opens, bundle downloads, portal verifications — lands in the worker-visible access log. This is fetch-scoped: what happens after the bytes leave (screenshots, a saved bundle, a self-hosted verify page) is governed by grant terms and verifier policy — contract, not cryptography, and labeled as such in the interface. A self-hosted verify page structurally cannot feed the access log, and the protocol names which promise covers which event class rather than pretending both are absolute.
• Decaying. Revoking a grant stops future access through Tenure and makes already-saved copies fail re-verification: past the freshness window a saved bundle reports a stale head rather than a clean pass. It does not delete copies already viewed or downloaded, and the copy says exactly that.

Monitoring carries no values

A monitoring-scope grant lets a verifier receive event classes only — that employment status changed, that an attestation was superseded, that a grant was revoked — never new claim values. This is enforced at the type level: the monitoring event carries no fields at all, so a push cannot convey a value. Learning what changed requires a fresh share the worker consents to. Consent duration lives inside the grant, and the consent copy is verbatim and explicit, including that revoking “may affect your application.”