Skip to content

spec(adagents): tighten revoked_publisher_domains[] semantics (closes #4507)#4536

Merged
bokelley merged 2 commits into
mainfrom
bokelley/adagents-revocation-tightening
May 14, 2026
Merged

spec(adagents): tighten revoked_publisher_domains[] semantics (closes #4507)#4536
bokelley merged 2 commits into
mainfrom
bokelley/adagents-revocation-tightening

Conversation

@bokelley

Copy link
Copy Markdown
Contributor

Summary

Closes #4507. Four semantic gaps in the revocation block identified by the PR #4504 expert review:

  1. Validator-side append-only durability (rollback resilience). Closes the gap where an attacker re-serves a stale file with revoked_publisher_domains[] removed and last_updated advanced — the existing non-monotonic-last_updated check only catches backward last_updated, not removed-then-restored shapes. Durability now lives on the validator, not the network.
  2. Un-revoke flow. Documented: re-authorize by removing the entry after the 7-day window has elapsed since revoked_at. No re-authorize-before-7-days back door — that surface would be indistinguishable from a rollback attack.
  3. compliance_violation framing. Tightened the reason enum description: operator-internal self-classification for review routing, not a public accusation. Recommended other for un-adjudicated third-party allegations.
  4. Extension-field disclaimer. additionalProperties: true stays per project policy; validators MUST ignore unknown fields on revocation entries.

Description-only changes to the schema; existing files validate unchanged.

Test plan

  • node tests/composed-schema-validation.test.cjs — 34/34 pass
  • node scripts/audit-oneof.mjs --check — ok, baseline unchanged
  • Reviewer to confirm the validator-side durability rule actually closes the rollback gap as described

🤖 Generated with Claude Code

bokelley and others added 2 commits May 14, 2026 08:22
Closes #4507 — the four semantic gaps identified in the PR #4504 expert
review for the revocation block.

1. Validator-side durability (rollback resilience). A
   (publisher_domain, revoked_at) tuple a validator has previously
   observed MUST be held as still-revoked for 7 days from first
   observation, even if the entry vanishes from a subsequent fetch.
   Closes the gap where an attacker re-serves a stale file with the
   revocation removed — the existing non-monotonic-last_updated check
   only catches backward last_updated, not "removed-then-restored"
   shapes.

2. Un-revoke flow. Documented: re-authorize by removing the entry
   after the 7-day window has elapsed since revoked_at; removing
   sooner is a no-op against validators that observed the original.
   No re-authorize-before-7-days back door — that surface would be
   indistinguishable from a rollback attack.

3. compliance_violation framing. Tightened the reason enum
   description to make clear it's operator-internal self-classification
   for review routing, not a public accusation. Recommended `other`
   for un-adjudicated third-party allegations. Compares to sellers.json
   which deliberately carries no reason field for the same exposure.

4. Extension-field disclaimer. additionalProperties:true stays per
   project policy, but validators MUST ignore unknown fields on
   revocation entries.

Description-only changes to the schema; existing files validate
unchanged. Schema audit and composed validation pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ne, persistence-across-restart SHOULD

Expert review (ad-tech-protocol-expert) on PR #4536 should-fixes.

1. Durability now keys on `publisher_domain` alone, not on the
   `(publisher_domain, revoked_at)` tuple. Tuple-keying lets an attacker
   re-emit the same domain with a slightly mutated revoked_at (one second
   earlier, say) and present a "fresh" tuple the validator has never
   observed, bypassing the hold. Use revoked_at only to set the clock
   origin (earliest observed value), not to identify the durability key.

2. New normative SHOULD bullet: validators SHOULD persist observed
   revocation entries to durable storage. An in-memory validator that
   restarts inside the 7-day window MAY accept a rolled-back file
   because it has no record of the prior observation. The 7-day window
   is measured from the validator's first observation, not from process
   start.

Tests + audit unchanged (description-only edits).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@bokelley

Copy link
Copy Markdown
Contributor Author

Expert review pass

Ran the PR through the ad-tech-protocol expert. Two should-fixes addressed in commit 188669a:

  1. Durability keys on publisher_domain alone, not (publisher_domain, revoked_at). Tuple-keying would let an attacker mutate revoked_at slightly and present a "fresh" tuple the validator has never observed, bypassing the hold. The 7-day clock now uses revoked_at only to set the origin (earliest observed value), not to identify the durability key.
  2. Persistence-across-restart SHOULD. New normative bullet: validators SHOULD persist observed revocation entries to durable storage. In-memory-only validators that restart inside the window MAY accept rolled-back files — operators SHOULD treat as a known limitation.

The protocol expert cleared both 7-day window interaction (orthogonal to the file-level cap) and compliance_violation framing as sound. No must-fixes.

@bokelley bokelley merged commit bc33de5 into main May 14, 2026
18 checks passed
@bokelley bokelley deleted the bokelley/adagents-revocation-tightening branch May 14, 2026 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tighten revoked_publisher_domains[] semantics — rollback resilience + un-revoke + compliance framing

1 participant