Skip to content
Design documentation for a protocol at the proof-of-concept stage. Interfaces are not stable and this describes intended behaviour.

Verification

Verification is one pure function. Chain, KYB, grant, revocation set, and the current time all arrive as arguments; the function does no I/O, reads no clock, and touches no globals. The identical logic runs in the verifier portal, the worker wallet, and the dependency-free static page, and a second independent implementation reproduces it byte-for-byte.

The verify predicate takes five inputs:

Input Role
The verification bundle The employer descriptor, entity attestation, epoch chain, delegations, presented attestations, revocation set, and head
The presentation context The share grant and the audience the claims are being presented to
The verifier’s trusted-attester list The verifier’s own accepted-attester set, the way a browser owns its root store
The current time Supplied by the caller, never read from a clock inside the predicate
A freshness window How recent the head must be for this verifier’s recency policy

Because the time and the freshness window are inputs, the same bundle yields a deterministic verdict for any chosen clock and recency policy.

The predicate runs in order and returns the first failing verdict, or Verified.

0. Descriptor (prerequisite). The Employer Descriptor must be self-signed by the employer key it declares.

  1. KYB. A valid, unexpired Entity Attestation binds the employer public key to the displayed legal entity, the attester key it names matches the key that signed it, and that attester is in the verifier’s trust list. A failure here always names which attester signed — even an untrusted one — so the verifier can decide for itself.

    Attester plurality. Key↔entity binding is an inherently external fact, so confederal does not mean “no trusted attestation” — it means the verifier chooses its roots (the verifier-owned trust list), the attestation is non-equivocating (it lives in the directory), and no single attester is load-bearing. A bundle may carry additional independent entity attestations, and the predicate accepts a policy naming a minimum number of distinct trusted attesters — the N in an N-of-M requirement, where the trust list is the M — for higher-stakes verifications. The Verified verdict then names the set of trusted attesters that vouched, not one signer. The default minimum is one, which is the original single-attester behavior, unchanged. This is the TLS model: chosen roots, non-equivocating evidence, no single point of trust.

  2. Chain. The epoch chain verifies back to the employer key; each attestation is signed by the registrar key of its epoch; its log sequence number falls inside that epoch’s range; and a covering delegation allows its type at that sequence number and its “as of” time within the delegation’s time window. A mint outside every delegation is rejected here even though signed. See Log & epochs.

  3. Consent. The Share Grant is signed by the subject’s per-employer key, is unexpired, names every presented attestation, matches the presenting audience, and — for monitoring requests — carries the monitoring scope. See Sharing & bundles.

  4. Freshness. If any presented attestation’s revocation commitment — the BLAKE3 digest of its attestation identifier — is present in the bundle’s revocation set, the verdict is Revoked, regardless of head age. Otherwise, if the checkpoint’s publication time is older than the freshness window relative to the supplied current time, the verdict is Stale Head. Evidence decays by design, so a saved bundle past the window can never read Verified.

    The head is an input to this pure check, so where it comes from is an input-sourcing decision, not part of the predicate. To close the suppression gap — a single party serving a stale-but-valid head — the head is sourced from a quorum of independent witnesses, or from an externally anchored root, rather than from one party. See Directory integration and Mel integration. The predicate is unchanged; it simply verifies against the corroborated head.

  5. Resolution. Currency is resolved per claim family: a member verifies only if its family is the latest unsuperseded family for its fact. A stale variant — exact, band, or threshold — is treated as revoked. An attestation whose own expiry has passed fails here too. See Claim families.

The verdict type is explicit and never scored. Verified proves the employer signed the statements — not that they are true.

Verdict Meaning
Verified All five checks pass. Carries the employer legal name and key, the primary attester’s name, key, and methods, plus the full set of trusted attesters that vouched (at least the policy’s minimum), the resolved claims at granted granularity, and the “not revoked as of” time, head sequence number, and head age
Revoked A presented attestation, or its family, is revoked or superseded
Grant Expired The share grant’s expiry has passed
Chain Invalid Any structural failure: bad descriptor, broken epoch chain, mint outside delegation, tampered bytes, expired attestation, and so on. Carries a reason
Employer Unverified KYB failed — wrong key bound, expired, or attester not trusted. Always carries the key of the attester that signed
Stale Head The checkpoint is older than the freshness window; carries the head’s publication time and the window

The verdict card distinguishes an offline verification (against a head from, say, 13:40) from a live recency check, and renders the head age explicitly.

Verifying a presented bundle is the hot path. Importing a full log — an exit export, or a new registrar adopting an employer — is the cold path, and it is stricter. It runs once and replays everything:

  1. verify the Employer Descriptor signature,
  2. verify the Entity Attestation,
  3. verify the epoch chain back to epoch 1,
  4. verify every Delegation,
  5. replay every entry: registrar signatures per epoch, hash-chain continuity (each entry’s hash covering its own canonical bytes and its predecessor’s hash), and type and rate-cap accounting against the delegations,
  6. verify the Signed Head signature,
  7. materialize the attestation-state projection and the revocation set.

A new registrar adopting an employer runs exactly this before reporting its computed head, and the Signer cross-checks that head against the heads it witnessed. See Misbehavior & switching.