Verification

Membership verification is a decision over supplied evidence and an explicit policy. The calculation performs no network request, reads no local clock and consults no hidden state. Obtaining and authenticating those inputs is a separate responsibility.

Inputs

Because the freshness policy and the verifier’s key are inputs, two verifiers with different risk tolerances may return different verdicts for the same material and both be correct. A verifier must also authenticate the presenting identity before relying on a match with the membership. The decision cannot establish control of a secret merely by being handed a public identity.

Verdicts

The decision distinguishes nine outcomes. The ordered checks below determine which failure is reported:

There is no unknown, no “probably fine”, and no path where a verifier proceeds because a check could not be completed. An incomplete check is a failure with a name.

Ordered checks

The decision short-circuits on the first failure. The ordering is normative: two conforming verifiers must agree not only that material failed, but on which failure came first.

1. Evidence well-formedness. Check signatures and the bindings between the membership, creator record, schedule, history and issuance authority. The derived membership state must concern the same member. Any required supporting attestations must also be present and valid.
2. Unknown creator. Directory evidence proves the name absent.
3. Stale head. The head fails quorum or exceeds maximum lag.
4. Outside delegation. The signing host must be the delegated host, and the grant must cover the issuance’s epoch and position.
5. Grant checks, when a grant is present. A grant committing to a different membership is bad proof. A grantor that is not the bound member key, or a named verifier that is not the one checking, is wrong subject. A head past the grant’s expiry position is expired.
6. Wrong subject. No grant, and the presenter is not the bound key.
7. Revoked. The accepted event history ends the membership through revocation.
8. Tier superseded. When a content class is requested, the current schedule must contain an active tier permitting that class.
9. Expired. Standing is beyond grace.
10. Valid. Active, or in grace within policy. A valid verdict carries the standing, so a verifier can distinguish paid coverage from accepted grace.

Missing evidence lands at step 1. Material presented without proof is rejected, not treated as weaker proof — this is what stops a verifier being talked into accepting an assertion by a party that declines to prove it.

Presentation bundles

A presentation bundle carries the material needed to check a membership: the creator record and directory proof, epoch history and delegations, membership evidence, relevant events and a signed checkpoint.

The verifier first checks the directory evidence against its trusted reference. It validates and replays the supplied history, deriving membership standing from accepted events rather than from an asserted status. It then applies the ordered decision under its own policy.

This can be done offline, but the result is bounded by the evidence supplied. A self-consistent bundle may omit later events. The verifier needs an acceptable basis for freshness; a disconnected calculation cannot discover an unseen cancellation, refund or host change.

The calculation itself sends no notification to the creator or host. Software around it can still fetch evidence, log requests or collect telemetry. The privacy property belongs to the local calculation, not automatically to every application that embeds it.

Cross-implementation agreement

With the same verified inputs and policy, conforming verifiers should agree on the result and on the first failing check. Canonical representation and a defined check order make that agreement testable.

A disagreement under those conditions indicates a defect or an ambiguity in the protocol rules. Differences in policy or in the evidence supplied must be distinguished from an implementation disagreement.