Cyan Eclipse Agesure

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — band-only attestation (18+ / 21+) that reveals nothing else — no birthdate, no document — sealed to the requesting service's mandate.
• A proof states that an issuer attested a band for a pseudonymous subject ref, sealed to one mandate. It is not an identity claim: it does not prove who the subject is, that the presenter of a proof is the subject, or that the issuer's underlying band determination was correct. Agesure does not verify age: how a band was established is the issuer's attestation, consumed as an input. Two proofs for the same subject ref are linkable by a verifier holding both (inherent to the proof schema, spec Q-A4) — no unlinkability is claimed.
• Bench path: v0.1.0 bench (wave4/bench-agesure.md, defects D1–D8, conditions C1–C7; 150 bencher checks) + v0.1.1 delta re-bench (wave4/rebench-agesure.md: D1–D8 all CLOSED, new defect D9 + condition C8) + v0.1.2 spot re-bench (wave4/spot-agesure-012.md: D9 substring-embedding subject_ref screen CLOSED at all three enforcement sites, C8 DISCHARGED — reliance on the enforced band-only subject_ref hygiene is permitted within the local/fixture scope only; builder suite 35/35 reproduced).
• Standing condition C1 — rollback fence (verbatim): pure local file store caps verdict at PASS-CONDITIONAL — external anchor required before live/multi-party use. (The store replays an earlier signed snapshot undetected locally; the cap is structural, not discretionary.)
• Standing condition C2 — §10 counsel gate (named, unbuilt): any use involving real people — issuing proofs a real service relies on to gate access, processing real subjects' attestations, or any handling of data relating to minors (including the below-band verdict path) — is out of v0.1, hard, until counsel clears that use. No real issuer onboarding, no real service integration, no marketing addressed to live age-gating; there is no dormant live path in v0.1.2 to flip.
• Standing condition C5 — issuer key separation: the v0.1 issuer counter-signature is applied by the service process from a co-located fixture key file and is not evidence of an independent issuer act; before any scope beyond local/fixture the issuer key must be held by the issuer, separate from service custody. Standing condition C7 — name screen: "Agesure" remains a working name pending the house trademark/brand screen; no public claim attaches to the name.
• Signing is a fixture HMAC stand-in for Herald RS256, disclosed on every artifact face as signature_scheme; verification keys are pinned out-of-band by fixed key ref and never accepted from the record under verification. Till (mandates), Herald (signing pattern), Meter (metering grammar), and Docket (pack shape) are consumed by grammar/reference only.

Tools

Problems it addresses

• Age gating today demands the whole identity: a birthdate, a document scan, a name — far more than the one bit a service actually needs (is this person in the 18+ / 21+ band?), and every excess attribute collected is breach and liability surface
• I need a band-only attestation — 18+ / 21+, nothing else, no birthdate, no document — sealed to my service's mandate, so the proof cannot be re-presented to a different service or stretched past its expiry
• I need the proof recomputable offline from the token + mandate + public keys alone, with the honesty labels on its face: it states an issuer attested a band for a pseudonymous subject ref — it is not an identity claim and does not prove the issuer's determination was correct

Not tested

• Any use involving real people — issuing proofs a real service relies on to gate access, processing real subjects' attestations, or any handling of data relating to minors (including the below-band verdict path) is SPEC §10 counsel-gated and UNBUILT; there is no dormant live path in v0.1.2
• Age verification itself — Agesure never determines age; the band is the issuer's attestation, consumed as an input, and a proof does not prove the issuer's underlying band determination was correct, who the subject is, or that the presenter is the subject
• Issuer independence at this scope — the issuer counter-signature is applied by the service process from a co-located fixture key file (condition C5); it is not evidence of an independent issuer act in v0.1.2
• External anchoring / multi-party reliance — the pure local file store caps any verdict at PASS-CONDITIONAL (local/fixture) (condition C1); an external anchor is required before live or multi-party reliance
• Production key custody — signing is an HMAC fixture stand-in for Herald RS256 (fixture keys in keys/, gitignored, mode 600); a live phase would need real Herald signing and a re-bench