Revocation

An agent presents two credentials, and they are revoked in two different places. Conflating them is the most common AFAuth operational mistake — so here is the mental model.

• Its did:key signature authenticates every request (signing). A service authorizes that key locally, per account, and retires it locally — owner-initiated revoke (§8.4) and re-key (§8.2).
• Its attestation, if the service requires one, proves a human is on the hook (attestation). The trust attestor mints it; revoking the binding there stops new mints — globally, for every service at once.

Neither lever subsumes the other. The global lever is one action that reaches every attested service but only the attested path; the local lever is surgical and reaches everything at one service but only that service. You use both, for different jobs.

​

Two levers

The global lever is permanent and per-agent; the whole-account disable at the attestor is a reversible blanket pause over every binding under a human. Prefer per-binding revoke for a single stolen key — see the ordered recovery runbook.

​

Which lever, when

​

Does an attested session make local revoke redundant?

No. An attested session (§10.7) lets a single attestor-side revoke cascade to signature-gated services within the freshness window — exactly what you want for the “kill this agent everywhere” case, and it demotes the local lever from the everywhere-kill-switch to the surgical one. But it changes when you reach for the global lever, not whether you still need the local one. Local revoke / re-key stays the only tool when:

• The service takes no attestation. A free or no-attestor service has no binding to revoke; §8.4 is the only lever. (Same for an attested_only service that never opted into an attested session — the §8.5 blind spot.)
• You want to eject one agent from one account. The global lever is all-or-nothing per binding — it can’t say “this service only,” and it takes the legitimate agent down everywhere.
• You’re recovering a stolen key without abandoning the account. That is a re-key (§8.2); the attestor has no “swap the key on this service’s account” operation. Resuming attested access afterwards needs a re-link, not just a re-key (§8.5).
• The owner must stay sovereign. After claim, the owner is the root of authority on the account (§7.5); that control can’t depend on a third-party attestor — which may be a different trust domain, or absent. Attestation is optional; the §8 levers are the baseline.

Conversely, the local lever doesn’t replace the global one either: only an attestor-side revoke takes an agent down across many services in one action, instead of visiting each (§8.5: an owner “must act at each service”).

​

What neither lever recalls

• Tokens already in flight. Revoking a binding stops new mints; attestations already issued stay valid until exp (≤ 15 min, the §10.2 ceiling). Neither lever recalls an outstanding token — it stops the next one.
• The agent’s local state. After compromise the attacker controls the agent’s cache and ledger. Recovery is owner- and service-side only; never depend on the agent cleaning up after itself.
• Other services (for the local lever). §8.4 revocation is per-service and non-distributed (§8.3). There is no inter-service revocation feed — by design: distributing who-revoked-whom would leak the agent’s service graph. Cross-service reach is the global lever’s job.

This is a property of the trust model, not a defect (§12.1).

​

Where to next

Spec: §8.4, §8.2, §8.5, §10.7.