Follow-up to #183 (RFC 9421 request signing). The signing module ships `RevocationList` as an in-memory snapshot loaded from a dict (used by vector 017 via `test_harness_state.revocation_list`). Production verifiers need to fetch the list from the operator's endpoint and honor its freshness.
What's needed
- HTTP fetcher for signed-revocation-list documents, paralleling `default_jwks_fetcher` (SSRF-validated per AdCP webhook rules).
- Freshness enforcement: verify `updated` ≤ now ≤ `next_update`; if stale, reject incoming requests with `request_signature_revocation_stale` (error code already in the taxonomy).
- Signature verification of the revocation document itself (operator signs the list; verifier trusts operator key). Design shares substrate with adcp#2316 governance JWS.
- Caching with refetch near `next_update`, not a fixed cooldown.
- `RevocationListFetcher` Protocol so callers can plug in their own transport.
Why separate
- Requires a key-trust model for operator signing keys — parallel to JWKS but with different semantics (operator-scoped, not agent-scoped).
- Couples with adcp#2316 JWS profile once that lands in the spec.
- The static `RevocationList` handles the conformance vector today; live fetching is operational.
Current state
Vector 017 (`key-revoked`) passes via `test_harness_state.revocation_list` preload. `RevocationList.from_dict` and the `RevocationChecker` Protocol are shipped. The missing piece is the network-backed implementation.
Follow-up to #183 (RFC 9421 request signing). The signing module ships `RevocationList` as an in-memory snapshot loaded from a dict (used by vector 017 via `test_harness_state.revocation_list`). Production verifiers need to fetch the list from the operator's endpoint and honor its freshness.
What's needed
Why separate
Current state
Vector 017 (`key-revoked`) passes via `test_harness_state.revocation_list` preload. `RevocationList.from_dict` and the `RevocationChecker` Protocol are shipped. The missing piece is the network-backed implementation.