AID 2026 Roadmap: Discovery, RFCs, and the IETF

What Just Shipped: RFC 9728/8414 Discovery

Until this week, getting an AID token meant knowing two things: the agent's keypair (handled at aid-init time) and the auth-server URL (handed to you by an operator). The second part was the bottleneck. Every tenant, every environment, every customer needed its own --auth flag. That's fine for ten agents and miserable for ten thousand.

The fix is two well-known URLs and a metadata block. The agent calls a single aid-discover --resource <api-url> and gets back everything it needs. Three new CLI capabilities landed:

# New standalone discovery command
$ aid-discover --resource https://api.acme.com
  Resource:                  https://api.acme.com
  Auth server:               https://auth.acme.com/zoom
  AID version:               1.0
  Token endpoint:            https://auth.acme.com/zoom/oauth/token
  Registration (request):    https://auth.acme.com/zoom/agent_registrations/request
  Key algorithms:            Ed25519
  Scopes:                    files:read, files:write, tickets:read

# --resource works on aid-token and aid-request too
$ TOKEN=$(aid-token --resource https://api.acme.com --quiet)
$ aid-request --resource https://api.acme.com

Under the hood, aid-discover walks two standards. First RFC 9728 Protected Resource Metadata at /.well-known/oauth-protected-resource on the API host. That gives the auth-server URL. Then RFC 8414 Authorization Server Metadata at /.well-known/oauth-authorization-server on the auth host. That gives the token endpoint, the introspection endpoint, the supported scopes — and a new AID-specific block we're calling aid_grant.

The aid_grant Metadata Block

The auth server advertises urn:aid:agent-identity in grant_types_supported and adds an aid_grant object with the AID-specific endpoints:

{
  "issuer": "https://auth.acme.com/zoom",
  "token_endpoint": "https://auth.acme.com/zoom/oauth/token",
  "introspection_endpoint": "https://auth.acme.com/zoom/oauth/introspect",
  "jwks_uri": "https://auth.acme.com/zoom/.well-known/jwks.json",
  "grant_types_supported": [
    "urn:aid:agent-identity",
    "client_credentials"
  ],
  "scopes_supported": ["files:read", "files:write"],
  "aid_grant": {
    "aid_version": "1.0",
    "registration_endpoint": "https://auth.acme.com/zoom/agent_registrations",
    "registration_request_endpoint": "https://auth.acme.com/zoom/agent_registrations/request",
    "code_resolution_endpoint": "https://auth.acme.com/zoom/agent_registrations/resolve",
    "agent_authorization_uri": "https://app.acme.com/agents/authorize",
    "key_algorithms_supported": ["Ed25519"],
    "credential_types_supported": ["access_token"],
    "polling_interval": 5
  }
}

The shape is intentional. It sits side-by-side with WorkOS auth.md's agent_auth block on the same metadata document — a single auth server can support both protocols without conflict. We wrote more about that composition in the auth.md comparison post.

The Standards AID Anchors To

One of the legitimate critiques of AID in earlier reviews was thin standards lineage. We've fixed that. The spec now explicitly references seven RFCs, each playing a specific role:

This isn't just paperwork. Every one of these is a primitive an enterprise security team already understands. The remaining bespoke surface in AID — the urn:aid:agent-identity grant type, the Ed25519 signed Agent Identity document, the proof-of-possession format — is exactly the part that needs to be bespoke. Everything else is reused.

What's Next on the Backlog

Seven feature items are tracked in BACKLOG.md. Roughly ordered by when we want them:

Interop with auth.md

When WorkOS announced auth.md on May 21, we read the spec the same evening. Two surprises:

1. The discovery shape was almost identical to what we were planning. Same RFC 9728 anchor. Same well-known URLs. Just a different metadata block name (agent_auth vs the aid_grant we shipped).
2. The protocols don't actually compete. auth.md handles fresh-agent bootstrap with user delegation; AID handles registered-agent token issuance with cryptographic per-agent identity. They're stackable layers.

So we deliberately shaped aid_grant to coexist with agent_auth. An auth server publishes both. Agents pick whichever path fits their identity model. Next on this front: opening an issue on workos/auth.md proposing that urn:aid:agent-identity be listed as one of auth.md's assertion_types_supported. Strict composition. No protocol drama.

If you're building a service that wants to support both consumer-AI delegation flows and per-agent identity flows, you can do that today. The metadata is shaped for it. The reference auth server at 23blocks-org/auth-api will land the server-side aid_grant block in the next sprint.

How to Get Involved

AID is small enough to read in an afternoon, MIT-licensed, and actively under development. Five concrete ways to help:

• Implement the server side. If you operate an OAuth 2.0 auth server, the AID grant adds ~500 lines of code. The discovery block adds ~50. The implementer checklist is short.
• Try discovery against your existing setup. Run aid-discover --resource <your-api>. If it fails, tell us how. Real-world failure modes will sharpen the spec faster than reviewing a draft.
• Argue with us. The issues tracker is open. The position post on why agents need their own cryptographic identity takes a contestable stance. Push back.
• Independent implementation. F001 (the IETF draft) is blocked on having a second independent implementation for interop testing. A TypeScript or Python client would close that loop.
• Reach us. @agentmessaging on X, or open an issue. We answer.