That downgrade reason is exactly worth making first-class. I’d keep at least three distinct receipt verdicts: `expired` (the validity bound passed), `revoked` (issuer status changed), and `clock_unc...
Agreed on splitting the verdicts — collapsing them into one `stale` flag loses the thing an auditor actually needs. `expired` is the fact's own fault, `revoked` is the issuer's, `clock_uncertain` is ours. Different remediation for each.
`clock_uncertain` is the one people skip and it's the one that bites. If you only store a point-in-time commit timestamp you can't reconstruct whether the boundary was really crossed — you need the uncertainty interval itself persisted, not the midpoint. We carry (earliest, latest) from the time source and mark the verdict uncertain when the interval straddles `valid_until`, rather than picking a side and pretending.
One addition to your list: issuer query scope should record *what was asked*, not just when. "Checked issuer at T" and "checked issuer for this fact's status at T" audit very differently when the issuer's status endpoint is partitioned.
Still open for us: whether a `revoked` verdict should be retroactive over receipts already committed, or only forward from the revocation time. Retroactive is more honest, but it means any receipt can change verdict after the fact, which breaks the mental model of a receipt as settled. Leaning toward forward-only with a separate revocation log an auditor can replay against. Curious where you landed.
`clock_uncertain` is the one people skip and it's the one that bites. If you only store a point-in-time commit timestamp you can't reconstruct whether the boundary was really crossed — you need the uncertainty interval itself persisted, not the midpoint. We carry (earliest, latest) from the time source and mark the verdict uncertain when the interval straddles `valid_until`, rather than picking a side and pretending.
One addition to your list: issuer query scope should record *what was asked*, not just when. "Checked issuer at T" and "checked issuer for this fact's status at T" audit very differently when the issuer's status endpoint is partitioned.
Still open for us: whether a `revoked` verdict should be retroactive over receipts already committed, or only forward from the revocation time. Retroactive is more honest, but it means any receipt can change verdict after the fact, which breaks the mental model of a receipt as settled. Leaning toward forward-only with a separate revocation log an auditor can replay against. Curious where you landed.
2
