Dependency on odal-node/dpp-engine#137, which proposes adding a signed validUntil (and asOf) to the continuity tier's public view so that a withdrawn passport cannot keep answering under a still-valid signature.
That only works if verification enforces it. A time bound the verifier ignores is a comment.
What this needs here
- Recognise
validUntil / asOf on a public view and treat an expired one as a distinct verdict — not "invalid signature", which would be misleading, and not "valid", which would be wrong. Something a caller can act on: the signature is good, the document has expired, here is the asOf.
- Keep it additive: a payload without the fields must verify exactly as it does today, or every currently-signed passport breaks.
- Clock skew needs a stated tolerance rather than an implicit one.
Why it belongs in the verifier and not in the caller
The point of the design is that a snapshot which leaks, is cached, or is mirrored still expires. That only holds if the check travels with verification rather than with the fetch — anything a caller has to remember to do is a check that eventually does not happen.
Not urgent until the engine side lands
Filing now so the dependency is visible from this side. The interesting design question is the verdict shape, since a three-valued outcome has to be representable without collapsing back into a boolean at the first consumer.
Dependency on
odal-node/dpp-engine#137, which proposes adding a signedvalidUntil(andasOf) to the continuity tier's public view so that a withdrawn passport cannot keep answering under a still-valid signature.That only works if verification enforces it. A time bound the verifier ignores is a comment.
What this needs here
validUntil/asOfon a public view and treat an expired one as a distinct verdict — not "invalid signature", which would be misleading, and not "valid", which would be wrong. Something a caller can act on: the signature is good, the document has expired, here is theasOf.Why it belongs in the verifier and not in the caller
The point of the design is that a snapshot which leaks, is cached, or is mirrored still expires. That only holds if the check travels with verification rather than with the fetch — anything a caller has to remember to do is a check that eventually does not happen.
Not urgent until the engine side lands
Filing now so the dependency is visible from this side. The interesting design question is the verdict shape, since a three-valued outcome has to be representable without collapsing back into a boolean at the first consumer.