Operator commitment

AFAuthHQ operates trust.afauth.org as the reference implementation of the AFAP-0006 trust attestor. This page is the public commitment under which we run it.

Per AFAP-0006 §10.3 the trust attestor is one of four classes of attestor a service MAY accept. Conforming services are not required to list afauth-trust in their billing.accepted_attestors, and a conforming service that ignores this attestor entirely remains conforming.

Who has operational authority

AFAuthHQ. Operational contact: [email protected]. Abuse and take-down reports: [email protected].

What we issue, what we don't

The trust attestor issues short-lived JWTs (≤15 minutes, audience-bound to one service) that signal a human-verified agent. The token carries a categorical verification value ("email", "oauth", or "payment") and no personal data.

The trust attestor takes no opinion on what access a consuming service should grant in response to any particular verification value. Policy is local to each service.

Actions we MAY take unilaterally

• Revoke bindings or disable accounts under the published take-down policy.
• Rotate signing keys per AFAP-0006 §10.3.1, with the mandated ≥900s pre-publication of new kids in the JWKS so consumer caches refresh ahead of first use.
• Infrastructure changes (hosting provider, runtime version, internal storage layout) that preserve the wire surface defined in AFAP-0006.
• Add verification methods beyond email (OAuth, payment) as documented in AFAP-0006 §10.3.1; consuming services MUST ignore unknown values per the spec.

Actions we MUST NOT take unilaterally

• Include personal data in JWT claims. AFAP-0006 §10.3.1 forbids email addresses, phone numbers, payment details, and government identifiers in any claim. We honour that limit with no exceptions.
• Disable accounts on ideological grounds. Account standing derives from the verification methods on file; legitimate humans may not be removed for opinions unrelated to the moderation policy.
• Make wire-breaking changes to the JWT shape or the JWKS endpoint. Those changes require a versioned AFAP revision in AFAuthHQ/spec and a deprecation window.
• Issue an attestation JWT for an agent without an active binding to a verified human account, or for any aud other than the one the agent requested.

Bounded blast radius

Verification is offline against the JWKs document at https://trust.afauth.org/.well-known/jwks.json. A brief trust-attestor outage does not interrupt in-flight requests at consuming services — only token reissuance is affected. The 900-second exp cap bounds revocation latency.

Governance evolution

AFAuthHQ acts as both spec editor and trust-attestor operator at v0.1. AFAP-0006 §Security explicitly acknowledges this and anticipates that, if neutrality becomes operationally relevant, a future AFAP may move the trust attestor under a distinct identifier and entity. The wire shape is unchanged by such a move; this page does not commit AFAuthHQ to a specific governance trajectory in advance of that evidence.