Take-down policy

This page governs revocation and account-disable decisions on trust.afauth.org. It applies only to this operator; a future operator running their own trust attestor sets their own policy.

Categories

We may revoke a binding or disable an account when:

• Bulk-registered accounts. Accounts created at a rate inconsistent with one human per account, with no evidence of a legitimate organisational use.
• Verified-method abuse. Email magic links forwarded between humans to share a single account, payment cards re-used across accounts beyond reasonable shared-card scenarios, or other patterns inconsistent with one human controlling the verification.
• Agent linked to known-malicious behaviour. Repeated reports from consuming services about a specific agent_did engaged in spam, credential stuffing, scraping past published rate limits, or generating illegal content. Reports must include enough evidence for a reasonable determination.
• Fraudulent verification claims. Email or OAuth identities asserted by an account that the upstream provider can show the account does not control.
• Illegal activity under applicable law.

Revoke vs disable

Revoke binding: invalidates the long-lived binding token for a single agent. The human's account and verifications remain; they can re-link the same or a different agent immediately. This is the default action for agent-specific issues.

Disable account: invalidates the binding tokens for every agent linked to the account and prevents new bindings. The human's verifications remain on file for audit. Reserved for category-1 (bulk) and category-4 (fraud) findings.

Either action affects only token issuance going forward. Per AFAP-0006, JWTs already issued remain valid for up to 15 minutes (the maximum exp - iat). This is the spec's revocation-latency bound and is intentional — offline verification is what makes the attestor reliable.

Account deletion (operator-initiated)

Account deletion — full removal of the humans row, verifications, and bindings — is currently a manual operator process initiated by emailing [email protected] from the account's verified email address. Self-serve deletion is on the v0.2 roadmap.

Reports

Send reports to [email protected]. Include:

• The agent_did (or verification value pattern, for systemic abuse).
• Which category above applies.
• Evidence — logs, request payloads, screenshots, links to third-party advisories — sufficient for the operator to reach a reasonable determination.

We acknowledge reports within five business days during this working-draft phase, and publish anonymised aggregate statistics annually.

Re-link after revocation

A human whose binding was revoked due to a single agent's behaviour may re-link a fresh agent identity (new did:key or rotated keypair) without contacting the operator. A revocation of binding does not signal that the human is in bad standing — it signals that the specific agent was operating outside accepted patterns.

An account that has been disabled (not just had a binding revoked) may appeal by emailing the operator with context. The verification path used to register the account is the authoritative channel — appeals from other addresses will be directed back to it.

What this policy does not commit

This policy governs the operator's discretionary action; it does not promise that consuming services will treat any particular signal a particular way. AFAP-0006 §10.3.1 makes that decision explicitly local to each service.