Roles & the trust model

The single most common confusion about Tenure is thinking a “verifier” is a licensed role that the protocol must vet. It isn’t. This page walks the four roles, the one-directional trust chain, and why anyone being able to verify is a feature, not a hole.

The four roles

Role	Who	What they do	Do they sign facts?	Do they hold a key?
Attester (KYB)	Tenure Inc. (or independent attesters)	Verifies a business is real and binds its public key to its legal identity	Yes — signs an Entity Attestation	Yes — the crown-jewel attester key (offline)
Employer	any company	Signs payroll batches attesting its own employees’ income and tenure	Yes — signs each batch with the company key	Yes — the company signing key (offline or automated)
Worker (holder)	the employee	Claims an invitation, holds the credential, chooses what to disclose	No	Yes — a per-employer subject key, on their device
Verifier (relying party)	landlord, lender, property manager, background check…	Checks a credential the worker shows them	No	No (an account only for billing)

Plus the registrar: it orders and records signed statements into an append-only log and serves public materials. It does not assert facts, and after mint it holds no plaintext claim values (derive-then-purge) — so it is not a data honeypot.

The one-directional trust chain

Attester (KYB)  →  "this key = Acme LLC, a real, verified business"
Employer key    →  "employee X earns $Y, employed since Z"
credential      →  held by the worker, disclosed at the worker's chosen granularity
Verifier        →  runs the pure 5-check predicate against THEIR OWN trust list

Trust flows one way. The verifier is the endpoint of the chain, not a link in it. A landlord believes the credential because:

1. it is signed by the employer’s key (the worker cannot forge it — they do not have that key), and
2. that key is bound to a real business by an attester the verifier trusts (the verdict names the attester; the verifier’s trust list is theirs to edit, like a browser’s root-certificate store).

Who signs what (and who does not)

• The worker never enters income. Their only actions are claim, hold, and share. If they could type the number, the credential would be worthless. The income comes from the employer’s signed payroll batch.
• The employer signs — one batch per pay period for the whole roster, derived from the payroll data they already have. The offline batch-signer page is the pilot-grade manual tool; in production this is automated (payroll-provider integration, a desktop Signer, or a hardware-security-module-backed managed signer). It happens off the platform because the company root key must never live in platform-served JavaScript — that is the guarantee that Tenure itself can never mint credentials on an employer’s behalf.
• The registrar signs nothing about a person. It records order and freshness (the signed head and checkpoints) and serves public materials.

Why anyone can verify — and why that’s safe

Verification is permissionless and client-side by design. There is nothing to “become” and nothing for the protocol to vet about a verifier, because a verifier asserts nothing to anyone — they are the audience.

Common worries, answered:

• “If anyone can verify, an employee will just verify their own credential.” They can — and it is harmless. Verifying your own credential only tells you that it is validly signed by your employer. It grants no power: the amount cannot be changed (it is signed by a key the worker does not hold), a new one cannot be forged, and a revoked one cannot be made to read as valid, because the revocation-set root is itself part of what the predicate checks.
• “Couldn’t they screenshot a VERIFIED card to fool a landlord?” No. A screenshot proves nothing. The landlord does not trust a picture — they paste the share link (which carries the cryptographic proof) into their own verifier, which checks the signatures itself.
• “How does the protocol know a verifier is genuine?” It does not need to, and should not. Gating verification would add zero security (the security is in the signatures) and would break the properties that matter: verification works offline, needs no account, and runs on a self-hostable page. This is the PKI/TLS model — anyone can verify a certificate; trust comes from the certificate authority, not from licensing who is allowed to check.

The worker controls disclosure, never the truth: the granularity dial lets them show less (dates only → band → threshold → exact), never a different or higher number. See Claim families and Sharing & bundles.

Where money enters (billing ≠ trust)

• Viewing and verifying is free and needs no account — anyone with a share link can check it.
• A verifier account and access credential is required only to bill (a paid verification with a receipt) and to monitor (be notified if a credential is later revoked). That is a commercial relationship, not a trust gate.

Who runs the registrar — and how it’s funded

The registrar is a paid service, not charity. In v1 Tenure Inc. runs it; the operator captures the revenue that funds the infrastructure:

• verification fees — each operator sets its own price at its infrastructure cost plus margin; the software ships a default, never a hardcoded protocol price,
• monitoring subscriptions, and employer premium tiers.

“Anyone can run a registrar” is a portability and anti-lock-in property, not a volunteer model: an employer can switch operators through a signed export and import, so their credentials outlive any single registrar, and the roadmap pairs an independently operable registrar with a hosted, SLA-backed premium tier. Whoever runs one earns from the fees. The switch itself is a signed epoch transition — see Misbehavior & switching.

What the registrar stores — and what it cannot

The registrar’s store, on the operator’s host, holds:

Data	Sensitive?	Why it’s there
employers, Entity Attestations	business identity (semi-public)	serve public verification materials — “this employer is real, KYB’d”
event log (append-only)	attest payloads are sealed (worker-encrypted)	the source-of-truth hash chain
attestations projection	no plaintext values — sealed to the worker	deliver sealed credentials to the wallet; ordering and state
epochs, delegations, checkpoints	public	chain, authority, freshness (the signed head)
revocations	commitments (hashes)	the revocation set and the signed revocation-set root
subject roster	email hash only, plus a payroll reference	minimal PII
grants, verifications, monitors, access log	sharing and billing	charge verifiers; the worker’s disclosure log

Two things follow:

• The Entity Attestation lives with the registrar, not in the attester tool — the offline attester is stateless, it only signs. The KYB record (legal name, registry reference, jurisdiction, methods, validity) is business identity meant to be public and verifiable, and is served alongside the employer’s other public verification materials.
• The registrar cannot read anyone’s salary. It stores the encrypted credential (only the worker’s key opens it), plus hashes and commitments. It monetizes the service (verification), not the data — and a breach of it leaks no income values. That is the structural inverse of a data broker. See Privacy.

One-line summary

The only party who signs facts about a person is their employer (automatable, once per roster); the only trust anchor is the KYB attester; the verifier is simply whoever the worker chooses to show the credential to — permissionless, because gating verification would add no security and break offline and self-hosted checking.