Module revocation 

The write side of the revocation split.

Edge-verifiable auth (R019) keeps revocation’s two sides physically apart. This crate holds the origin half:

• RevocationWriter — the cold path, run at the origin on logout / device-revoke. Adds a token’s jti to the set.
• The hot-path reader (cheers_verify::RevocationReader) lives in cheers-verify — the verify-only edge holds it without the power to revoke anyone else’s sessions.

The set is eventually consistent by design: a revoke here propagates to edge readers asynchronously (KV replication / gossip), bounded by the access token TTL (see SessionPolicy). Full contract on cheers_verify::RevocationReader.

Revoking a session vs. a whole login

The set is keyed on jti, so RevocationWriter::revoke kills one access token immediately (edge-visible within the propagation window). The coarser flows compose it with the refresh cold path:

• Logout / single device-revoke: call RefreshStore::revoke_chain so the chain can mint no further access tokens, and revoke(jti) for the session’s current access token. Any access tokens already issued on that chain die on their own within the access TTL.
• Account-wide revoke: revoke every chain via the UserStore device list; same TTL bound applies.

SessionAuthority is where these calls are composed — it holds both the RevocationWriter and the RefreshStore.

Traits

RevocationWriter

Origin-side revocation write. Held by SessionAuthority on the cold path.