Problem
drs-verify is an exposed service that does expensive verification work. Without admission control, an attacker can turn Ed25519 verification, DID resolution, and JSON parsing into a cheap CPU burn.
What to do
Add rate limiting to the verifier HTTP surface:
- per-IP token bucket
- global request ceiling
- configurable limits through environment variables
429 Too Many Requests with Retry-After
Acceptance criteria
/verify is rate-limited- limits are configurable through documented env vars
- tests cover per-IP and global limiting
- overloaded requests return
429 and Retry-After
- docs describe sane defaults for pilot deployments
Out of scope
- billing controls
- semantic capability spend enforcement
Problem
drs-verifyis an exposed service that does expensive verification work. Without admission control, an attacker can turn Ed25519 verification, DID resolution, and JSON parsing into a cheap CPU burn.What to do
Add rate limiting to the verifier HTTP surface:
429 Too Many RequestswithRetry-AfterAcceptance criteria
/verifyis rate-limited429andRetry-AfterOut of scope