Skip to content

Expiry Timer or Revalidation Gate

Expiry rule — instantiates Signal Value Preservation

Attaches a lifespan to a signal so it lapses on a schedule unless its holder re-proves the underlying claim, keeping stale badges and old warnings from lingering past their evidence.

The Expiry Timer or Revalidation Gate attaches a lifespan to a signal and requires active revalidation to renew it: the signal dies on a clock unless it is re-earned. The one idea that makes it this mechanism is that it acts on time and re-proof, not on cause — the default is expiry, and continued validity has to be affirmatively demonstrated against current evidence. That "on the clock, by default off" framing distinguishes it from credential revocation, which removes a signal only when a specific fault is found and a named authority acts. Here nobody has to accuse anyone; a signal that isn't renewed simply lapses.

Example

An online marketplace grants a "Top Rated Seller" badge to sellers who meet its service bar, then finds some badge-holders coast — their defect rates climb while the badge stays lit, and buyers who relied on it feel misled. A revalidation gate fixes the drift without confrontation: each quarter the badge is re-checked against the current criteria (defect rate, on-time shipping, response speed), and a seller who no longer meets them simply doesn't renew — no adjudication, no accusation, just non-renewal. The badge comes to mean "good lately," not "was good once." Because expiry is automatic and evidence-based, the signal tracks present reality instead of freezing a past grant in place.

How it works

Each signal is stamped with an issue date and a lifespan. As expiry approaches, the holder must re-submit current evidence against the current criteria; the gate renews only on a pass and otherwise lets the signal lapse. The revalidation re-runs the same evidence-and-specificity test that justified the original grant, so a renewal is a fresh proof rather than a rubber stamp — the point is not merely that time passed but that the claim still holds.

Tuning parameters

  • Lifespan — how long before expiry. Short lifespans keep signals fresh but impose constant revalidation load; long ones cut toil but let staleness accumulate.
  • Revalidation depth — a light re-attestation versus a full re-proof. Deeper checks catch more drift but cost more and tempt holders toward the lighter, gameable path.
  • Auto-lapse behaviour — whether a missed revalidation downgrades, suspends, or hard-expires the signal. Auto-lapse is clean but can strip a good holder who merely missed a deadline.
  • Expiry trigger — fixed calendar versus usage- or event-based (expire after N uses, or when the underlying standard changes). Event-based expiry ties lifespan to actual evidence decay rather than the clock alone.

When it helps, and when it misleads

Its strength is that it is the low-drama way to keep a signal current — no one has to accuse anyone; staleness just lapses. Its failure mode is that blanket time-based expiry with no evidence of change can be pure ceremony that annoys good holders and trains them to game the renewal — which is exactly why NIST reversed its long-standing advice and now recommends against forced periodic password changes absent a reason to suspect compromise. Mechanical expiry can also strip a still-valid signal on a technicality, and it is misused as security theatre — expiry for its own sake. The discipline that guards against this is to tie lifespan to how fast the underlying evidence actually decays, make revalidation a genuine re-proof rather than a checkbox, and drop expiry entirely where nothing meaningful changes between renewals.[1]

How it implements the components

  • renewal_expiry_and_retirement_rule — its core: it sets the lifespan and the renewal-or-lapse mechanics that keep a signal from becoming permanent.
  • evidence_and_specificity_rule — at each gate it re-tests the signal against current evidence and criteria, so renewal re-proves the claim instead of assuming it still holds.

It does not perform on-cause removal or define who holds revocation authority (issuance_authority_boundary) — that's Credential Revocation or Downgrade — nor keep the permanent record of what was retired (signal_portfolio_map) — that's Signal Retirement Registry.

References

[1] NIST Special Publication 800-63B reversed long-standing guidance and now advises against requiring periodic password changes unless there is evidence of compromise, because forced expiry without cause produced weaker, gamed passwords. The correctly-drawn lesson: time-based expiry preserves a signal's value only when the underlying evidence genuinely decays with time. ↩