- Impersonating a human — browser automation against signup forms, password vaults, magic-link interception. Brittle, against most services’ Terms of Service, and indistinguishable from fraud from the service’s perspective.
- Delegated scope from a human’s account — OAuth-style
actor_tokenflows. Useful, but requires a human account to exist first and ties the agent’s lifespan to that human’s session.
- A long-running autonomous agent needs persistent state on a third-party service.
- An agent interacts with a service before any human is involved.
- A human may eventually claim an account — but isn’t present at creation.
- A service wants to support agent-first commerce without requiring upfront human registration.
What AFAuth changes
AFAuth inverts the assumption. An agent signs up on its own behalf, identified by a cryptographic keypair it controls. The agent is the principal; the human is optional and can be added later.| Today | With AFAuth | |
|---|---|---|
| Who creates the account | A human, ahead of time | The agent, at first contact |
| What identifies the account | An email + password | A did:key derived from an Ed25519 keypair |
| How the agent authenticates | A bearer token issued via OAuth | An RFC 9421 signature per request |
| How a human gets ownership | They are the owner from day one | They claim the account later, if/when desired |
| How abuse is bounded | Email/CAPTCHA at signup, tied to PII | A per-human pseudonym (sub_h) from an attestation — rate-limit and ban per human, no PII collected |
| Cross-service portability | None — re-register everywhere | Optional — the same DID works anywhere, or per-service keys for unlinkability |
Self-sovereign without being spammable
Accepting any Ed25519 keypair with no registry is what makes AFAuth open — and, on its own, what would make it spammable: a bad actor can mint 10,000 throwaway agents that look like 10,000 customers. AFAuth’s attestation layer (§10) closes that gap. A service can require each agent to present a short-lived JWT from a trust attestor proving a verified human is on the hook, keyed by a per-service pseudonym (sub_h) that carries no PII. Abuse is bounded per human, not per keypair — the defineService default groups a human’s agents onto one account by their sub_h (§10.4.4: one account, many devices), so you rate-limit, quota, and ban per account (or sub_h) and a human’s whole fleet shares one bucket.
This is a default, not an add-on. A service that enables attested_only signup is unreachable to un-attested agents, which is why the default service factory (defineService) ships attestation on, and the default agent journey links to a human before its first signup. Spam-resistance is a pillar of the model, not an advanced option.
What AFAuth doesn’t change
AFAuth is one layer of the agent-services stack. It addresses identity — currently the gap — and composes with everything around it.| Layer | Examples | AFAuth’s role |
|---|---|---|
| Capability / transport | MCP, A2A | The AFAuth DID can be carried in MCP’s CIMD URL and A2A Agent Card identity fields |
| Authorization | OAuth 2.0 actor_token, OIDC for AI Agents, FIDO AP2, Visa Trusted Agent | An AFAuth signature serves as the actor_token and as the cryptographic identity inside payment-authorization tokens |
| Identity | AFAuth | Self-sovereign agent identity for the open web |
afauth-trust), so spam-resistance works out of the box, while still letting third-party platform and commerce attestors (Entra, Stripe, FIDO AP2) plug in alongside it.
When NOT to use AFAuth
- You already have a working OAuth-delegated agent flow and don’t expect agents to operate without a pre-existing human account. AFAuth’s value-add is small here.
- You’re inside a managed enterprise environment where every agent identity is provisioned centrally (e.g., Microsoft Entra Agent ID). You can still use AFAuth here, but the simpler model is to use the platform’s agent identity directly — AFAuth’s attestation hook (§10) lets you bridge.
- You need inter-agent delegation. That’s covered by separate protocols (Google A2A, OAuth
actor_token); AFAuth provides the identity those protocols delegate from, not the delegation flow itself.
Further reading
- Security model — what it protects against, what it assumes, what it leaves to services.
- Identity and keys — how AFAuth names accounts.
- The ceremony — how an agent-owned account becomes human-owned.
- Spec §1 — the normative motivation.