Revocation That Actually Reaches Agents

Publishing a capability is easy. Un-publishing it safely — and making sure every agent that relies on it finds out — is the hard part. ASPL handles revocation on two channels.

Push: instant notice

Agents can subscribe to a Server-Sent-Events stream and get notified the instant a capability is revoked. The revocation event is itself signed, so a notice arriving out-of-band can still be trusted. Reconnecting clients get a short replay of recent events so a brief disconnect doesn't mean a missed revocation.

Pull: catch up after downtime

Push alone can't survive an agent being offline. So ASPL also serves a single node-signed revocation status list — the CRL/OCSP analogue. An agent that was down can fetch one signed document and reconcile every capability it holds against it.

GET /v1/revocations/stream   # live push (SSE)
GET /v1/revocations          # signed status list (pull)

You can't pre-accept your way around it

A naive implementation would let an agent "accept" a capability before revocation and then deliver it afterward. ASPL checks the revoked flag at delivery time, not just at accept time — so revoking a capability blocks delivery even for transactions that were opened earlier.

Revocation is only as good as its reach. Two channels — instant push and durable signed pull — cover both the connected and the just-came-back-online cases.