Integration report: recheck revocation for delayed consumer decisions

## Integration

We integrated the hinted Nitro validator into a BasePay proof of concept that gates an x402/EIP-3009 USDC relay with an onchain enclave policy decision. The official validator stack from commit `0ea0d12366b4fa44f9e07e4755f2ad36561cb674` and the consumer are deployed on Base Sepolia:

- `P384Verifier`: [`0x8c8c555129399b65e3f4c957c5d1463ec2d191e0`](https://sepolia.basescan.org/address/0x8c8c555129399b65e3f4c957c5d1463ec2d191e0)
- `CertManager`: [`0xa0354ddc1f8cd2cd4533e074ef55b8eef6e70d97`](https://sepolia.basescan.org/address/0xa0354ddc1f8cd2cd4533e074ef55b8eef6e70d97)
- `NitroValidator`: [`0xb6373a6ae7b4a45f7f279feef0ca78d65670c671`](https://sepolia.basescan.org/address/0xb6373a6ae7b4a45f7f279feef0ca78d65670c671)
- consumer `AttestedRelayPolicy`: [`0xaa34f15970a032f8db362e6e556b25c5c94826ca`](https://sepolia.basescan.org/address/0xaa34f15970a032f8db362e6e556b25c5c94826ca)

The consumer checks the exact relay-intent hash in `user_data`, a request-bound challenge in `nonce`, attestation freshness/future skew, module ID, required non-null PCRs, an image tuple allowlist, an enclave-key allowlist, operation/token allowlists, policy version, and request/intent replay protection. The separate EIP-3009 signature remains the user’s final settlement authority.

## Integration finding

The validator correctly re-walks the cached chain and enforces revocation **when `validateAttestationWithHints` runs**. A delayed consumer introduces a second lifetime, however:

1. transaction A validates the attestation and stores an accepted authorization/intent;
2. a certificate, enclave key, image, token, operation, or policy version is revoked/rotated;
3. transaction or service B consumes the previously accepted decision.

If B checks only `accepted[intentHash]` plus expiry, a revocation after A does not invalidate the downstream cache. This is not a bug in `NitroValidator`; it is an easy consumer-integration trap.

Our consumer addresses it by retaining the root/intermediate/leaf certificate identity keys and the application-policy dimensions with each accepted intent. Every settlement-time read fails closed unless:

- the intent is unexpired and still on the active policy version;
- its enclave key, image, token, and operation remain allowlisted; and
- `CertManager.isRevoked` is false for every retained certificate identity, including the pinned-root emergency key.

Atomic consumers that validate and execute in the same transaction do not have this gap. Delayed consumers should either execute atomically or explicitly recheck revocation/policy state at use time and keep the decision lifetime short.

## Suggested upstream improvement

Add a short “downstream authorization caches” item to the README security considerations and the design document’s integrator responsibilities. It should distinguish validator certificate caching from a consumer caching the result of a successful validation, and mention atomic execution versus retaining/rechecking `(issuer, serial)` identities through `computeCertId` / `isRevoked`.

I can send the documentation patch if this framing matches the maintainers’ intended guidance.

Read the README security considerations and the design document’s integrator responsibilities section first. Add guidance distinguishing validator certificate caching from cached successful validation results, covering atomic execution and retaining/rechecking (issuer, serial) identities through computeCertId/isRevoked. Done when delayed consumers’ revocation and policy recheck responsibilities are explicit.

Written by the indexing model from the issue text.