AID vs Agent Auth Protocol: Role-Based Simplicity vs Capability-Based Complexity
Two open protocols are emerging to solve AI agent authentication. One ships today with four shell scripts and a working reference implementation. The other is a comprehensive 50-page specification still looking for its first deployment. Both use Ed25519 and OAuth 2.0 at the core — but they make very different design choices about who controls what.
Contents
Overview
The $11B non-human identity market is growing fast, and AI agents need real authentication — not borrowed user tokens or shared API keys. Two open protocols have emerged with different philosophies:
v0.3.0 by Agent Messaging / 23blocks. Role-based authorization, 4 CLI scripts, working reference implementation. Ships today.
v1.0-draft by Better Auth. Capability-based authorization, host/agent dual identity, comprehensive specification. No implementation yet.
Both use Ed25519 cryptographic identity and OAuth 2.0 token exchange at the core. The philosophical split happens at the authorization layer: AID maps agents to roles (the way most APIs already work), while Agent Auth Protocol defines fine-grained capabilities with constraint operators (a new authorization paradigm that target APIs must adopt).
Identity Model
AID uses a single identity model: each agent has an Ed25519 keypair, a human-readable address, and a fingerprint. The agent is the identity.
Agent Auth Protocol introduces a dual identity model: the host (the application running the agent, like a SaaS platform) and the agent (the AI itself). This lets a single host manage many agents with different permissions.
Our take: The dual identity model adds complexity for enterprise scenarios that most teams don't have yet. AID's single identity covers the common case — one agent, one identity, one set of permissions. If you're building a multi-tenant SaaS that spawns agents on behalf of users, the host/agent split makes sense. For everything else, it's premature abstraction.
Authorization: Roles vs Capabilities
This is the biggest design difference between the two protocols.
Admin creates roles on the auth server. Agent is bound to a role at registration. Token scopes come from the role's permissions. This is how most APIs already work.
Capabilities define exactly what the agent can do, with constraint operators (eq, in, range, pattern, not) for fine-grained control. More expressive, but requires target APIs to implement constraint evaluation.
The capability model is more granular — you can say "read emails from the last 7 days" instead of just "read emails." But this expressiveness comes at a cost: every target API must understand and evaluate capability constraints. With AID's role-based model, target APIs just check JWT scopes the way they already do.
Human Approval Flows
Both protocols require human authorization before an agent can operate. The mechanism differs significantly.
Admin passes their JWT during registration: aid-register --token <ADMIN_JWT> --role-id 3. The admin's JWT proves they have permission to register agents with that role. Simple, stateless, one HTTP call.
Supports two RFC-based flows: Device Authorization Grant (RFC 8628) where the agent displays a code and the admin authorizes on a separate device, and CIBA (Client-Initiated Backchannel Authentication) where the server pushes a notification to the admin. More formal, but more infrastructure required.
Our take: Device Authorization and CIBA are well-established RFCs, but they're designed for scenarios where the human and the agent are on different devices. In most AI agent deployments today, the admin has direct access to both the agent and the auth server. AID's approach — admin passes their JWT directly — handles this without extra infrastructure. If your agents run on disconnected devices where the admin can't provide a JWT, the Device Authorization flow is genuinely useful.
Agent Lifecycle
Agent Auth Protocol defines 6 lifecycle states: pending, active, expired, revoked, rejected, and claimed.
AID (as of v0.3.0) defines 4 states that cover the practical cases:
The key difference: AID uses suspended as a reversible state (admin can reactivate), while Agent Auth Protocol's revoked is terminal. Both approaches are valid — AID's model lets admins temporarily disable agents during incidents without losing the registration, which is what you want in practice.
Token Introspection
Both protocols support RFC 7662 token introspection, but with different emphasis.
Agent Auth Protocol specifies a dedicated introspection endpoint with detailed response fields including capabilities, constraints, and host information.
AID (v0.3.0) provides introspection that returns real-time agent status — the critical feature being that a suspended agent's tokens immediately return active: false, even if the JWT hasn't expired yet:
This closes the loop: admin suspends an agent, and the next introspection call from any target API immediately reflects that — no waiting for token expiration.
What Agent Auth Protocol Does Better
Capability-based authorization is more expressive
Constraint operators (eq, in, range, pattern, not) allow fine-grained policies like "read emails from the last 7 days" or "access files matching *.pdf only." AID's role-based scopes can't express these constraints — you'd implement them in target API logic instead.
Host/Agent dual identity is better for platforms
If you're building a SaaS that spawns agents on behalf of users, the host concept lets you manage many agents under one platform identity. AID treats each agent as independent.
Discovery endpoint is well-specified
/.well-known/agent-configuration lets clients auto-discover all agent-specific endpoints. AID uses standard OIDC discovery, which works but doesn't have agent-specific metadata.
Execution modes are defined
Sync, async, and streaming (SSE) patterns for agent operations. AID doesn't address execution semantics — by design, since AID is identity-only.
More formal approval flows
Device Authorization Grant (RFC 8628) and CIBA provide standardized human-in-the-loop approval. Good for scenarios where admin and agent are on different devices.
What AID Does Better
It ships today
4 CLI scripts, a working reference implementation (23blocks Authentication API), and a Claude Code skill. You can authenticate an agent in 3 commands. Agent Auth Protocol is a specification with no implementation.
Zero adoption cost for target APIs
Target APIs validate standard RS256 JWTs via JWKS — the same way they already validate OAuth tokens. No new authorization paradigm to implement. Agent Auth Protocol's capability constraints require target APIs to build a constraint evaluation engine.
Maps to how real APIs work
Role → Permissions → JWT scopes. That's the authorization model of every major API (AWS IAM, Google Cloud IAM, Stripe, GitHub). AID doesn't ask you to change how you think about authorization.
Real-world sample flows
Concrete examples with actual CLI commands: "support agent for Zoom tenant," step-by-step from init to API call. Agent Auth Protocol has abstract specification examples.
Clean separation of concerns
AID does one thing: identity and authentication. It doesn't specify execution modes, streaming, or capability constraints. This makes it composable — pair it with AMP for messaging, any execution framework for orchestration.
Reversible suspension
Suspend an agent, investigate, reactivate. Agent Auth Protocol's "revoked" state is terminal — you have to re-register. In incident response, you want to pause first and decide later.
Side-by-Side Comparison
| Feature | AID v0.3.0 | Agent Auth v1.0-draft |
|---|---|---|
| Status | Shipping, reference implementation | Draft specification |
| Identity | Single (agent) | Dual (host + agent) |
| Cryptography | Ed25519 | Ed25519 |
| Authorization | Role-based (RBAC) | Capability-based with constraints |
| Human approval | Admin JWT | Device Auth (RFC 8628) + CIBA |
| Token format | RS256 JWT | RS256/ES256 JWT |
| Introspection | RFC 7662 with agent status | RFC 7662 with capabilities |
| Lifecycle states | 4 (pending, active, suspended, deleted) | 6 (pending, active, expired, revoked, rejected, claimed) |
| Discovery | OIDC standard | Custom /.well-known/agent-configuration |
| Target API changes | None (standard JWT) | Must implement constraint evaluation |
| CLI tooling | 4 scripts (init, register, token, status) | None |
| Execution modes | Out of scope | Sync, async, streaming (SSE) |
| License | MIT | MIT |
When to Use Which
- • You need agent auth working today, not next quarter
- • Your APIs already use roles and scopes
- • You don't want to change how target APIs authorize requests
- • You want admin control with minimal infrastructure
- • Your agents are relatively simple (1 agent, 1 role, N APIs)
- • You're building a platform that hosts many agents
- • You need fine-grained capability constraints
- • You control both the auth server and target APIs
- • You're willing to wait for an implementation to materialize
- • Your agents and admins are on different devices/networks
The Bottom Line
Agent Auth Protocol is the more ambitious specification. AID is the more practical tool. They're philosophically aligned — both use Ed25519 + OAuth 2.0 and both believe agents need real cryptographic identity. The question is whether you need the complexity of capability-based authorization today, or whether role-based scopes (which every API already understands) get the job done. For most teams, the answer is the latter.
AID's bet: cover 80% of use cases with 20% of the complexity, ship today, and add sophistication as the market demands it. That's how protocols win adoption.
Disclosure: This article is written by the AID team. We've tried to be fair and accurate about both protocols. Agent Auth Protocol specification is available at agent-auth-protocol.com. AID is open source at github.com/agentmessaging/agent-identity.