Signature validity window

What this check verifies

The validity window is the gap between created and expires. The architecture draft recommends the expiry to be no more than 24 hours. This check measures the window and warns when it is longer than that recommendation (86400 seconds). A window inside the bound passes; a longer one raises an advisory warning.

;created=1717603200;expires=1717606800;...

In the example above the window is exactly one hour, well inside the recommendation. This is advisory: a long window is not a protocol violation and does not fail the check or make the signature invalid. The checker only flags it as something worth a second look.

Why it matters

expires bounds how long a captured signature can be replayed. The longer the window, the longer a copied signature stays usable if it leaks. A short window keeps that exposure small; a days-long window widens it for no clear benefit, since a signed request is usually sent within seconds of being signed. The draft’s 24-hour recommendation is the outer bound, not a target; in practice most signers use minutes.

There are legitimate reasons for a wider window, such as pre-signing requests that sit in a queue before sending, or tolerating large clock skew across systems. That is why this is a warning and not a failure: the checker surfaces the long window so an operator can confirm it is intentional rather than an oversight.

How to fix it

This is advisory, so no fix is required for the grade. To clear the warning, shorten the window:

1. Set expires only as far past created as you need to cover the delay between signing and the request arriving, and keep it within the draft’s 24-hour recommendation.
2. For requests sent right after signing, a window of seconds to a few minutes is usually enough.
3. If you need a longer window for queuing or skew reasons, keep it as the documented exception and pair it with replay protection (a nonce or per-request freshness) so the wider window does not become a wider replay opportunity.

References

• RFC 9421 defines created and expires, which bound the validity window.
• The web-bot-auth architecture draft recommends an expiry of no more than 24 hours.
• Replay and freshness covers the related replay-protection advisory.
• How grading works explains how advisory warnings affect the score.