--- type: Agentic Web Standard title: "auth.md" description: "How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?" resource: "https://github.com/workos/auth.md" tags: ["permit", "document-format", "single-vendor", "delegate-user-authority", "prove-agent-identity", "discover-my-api"] status: draft generated: { by: agenticweb-builder/1.0, at: 2026-10-30T00:00:00Z } verified: { by: process:agenticweb-engine, at: 2026-10-29T00:00:00Z } stale_after: 2026-11-28T00:00:00Z sources: - id: ref-1 resource: "https://raw.githubusercontent.com/workos/auth.md/main/README.md" title: "WorkOS (workos/auth.md). README.md (auth.md reference implementation of agentic registration, checked 29 October 2026): \"A reference implementation of agentic registration — a protocol for agents to authenticate to services on behalf of users. Three roles: an agent acting for a user, an agent provider that mints identity assertions (ID-JAGs), and a service that accepts those assertions, when available, and issues credentials. If the agent is not associated with a user identity, or the agent provider does not support ID-JAGs, the service uses an RFC 8628-style claim ceremony to authenticate the agent instead.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-2 resource: "https://api.github.com/repos/workos/auth.md" title: "GitHub REST API. workos/auth.md repository metadata (created 20 May 2026, MIT License, checked 29 October 2026): \"\"full_name\": \"workos/auth.md\"\" \"\"spdx_id\": \"MIT\"\"" last_modified: 2026-10-29T00:00:00Z - id: ref-3 resource: "https://raw.githubusercontent.com/workos/auth.md/main/AUTH.md" title: "WorkOS (workos/auth.md). AUTH.md (reference procedural manifest for agentic registration, checked 29 October 2026): \"You are an agent. This service supports agentic registration: discover → register → (claim if needed) → exchange for an access_token → call API → handle revocation. Follow the steps in order; do not skip ahead.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-4 resource: "https://raw.githubusercontent.com/workos/auth.md/main/CHANGELOG.md" title: "WorkOS (workos/auth.md). CHANGELOG.md (v0.1.0 dated 21 May 2026 through v0.6.0 dated 10 June 2026): \"Separates the identity and credential surfaces. Registration now mints a service-signed identity_assertion that the agent exchanges for an access_token at a standard OAuth token endpoint, instead of having /agent/auth issue credentials directly.\" \"Gates first-time linking of an ID-JAG to an existing account behind a user-confirmation ceremony, and requires fresh auth_time on every ID-JAG. Without this confirmation gate, any trusted provider could mint an ID-JAG with email_verified: true for a victim's email and silently take over their account. Without the freshness gate, an agent could use a stale upstream session.\" \"Switches the provider-driven invalidation channel from OIDC Back-Channel Logout to RFC 8417 Security Event Token push delivery per RFC 8935. Same trust path as before (issuer JWKS, jti replay protection), with a wire format and event shape that generalizes beyond revocation.\" \"Splits the email-based registration path out from identity_assertion and into a top-level service_auth registration type, with a body modeled on OIDC CIBA's login_hint. The previous shape was honest about how it worked — the service was verifying the email, not the agent — but it was filed under identity_assertion like the agent was asserting something. CIBA's vocabulary fits: the agent is hinting at who the user is, and the service authenticates the user out-of-band.\" \"Inverts the claim ceremony and consolidates polling onto the standard /oauth2/token endpoint. Service emails have been removed in favor of the agent surfacing the verification URL and user_code to the user, who signs in through the service's own browser-based session (reusing any existing session, SSO, MFA the service applies) and confirms the code on a service-owned page. This borrows the ceremony shape from RFC 8628 device authorization (user_code, verification_uri, expires_in, interval) without overloading the IANA device_code grant.\"" last_modified: 2026-06-10T00:00:00Z - id: ref-5 resource: "https://raw.githubusercontent.com/workos/auth.md/main/package.json" title: "WorkOS (workos/auth.md). package.json (version: 0.6.0, checked 29 October 2026): \"\"version\": \"0.6.0\"\"" last_modified: 2026-10-29T00:00:00Z - id: ref-6 resource: "https://workos.com/auth-md" title: "WorkOS. auth.md — Open Protocol for Agent Registration (official landing page, checked 29 October 2026): \"WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure — it composes existing OAuth standards (Protected Resource Metadata, ID-JAG identity assertions) and any app can publish or any agent can read one with no WorkOS account required.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-7 resource: "https://workos.com/auth-md/docs" title: "WorkOS. Overview — auth.md (official documentation overview, checked 29 October 2026): \"At its core, auth.md is a small Markdown file an application hosts at its domain — typically https://service.example.com/auth.md. The file describes how agents register with that service, which flows it supports, the scopes it exposes, and what to do once registered. Because Markdown is plain text, the same file works as documentation for human integrators and as a discoverable runtime artifact for agents.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-8 resource: "https://workos.com/auth-md/docs/auth-md" title: "WorkOS. The auth.md file — auth.md (file anatomy and agent parsing contract, checked 29 October 2026): \"The structured Protected Resource Metadata (PRM) at /.well-known/oauth-protected-resource remains the authoritative source for endpoint URLs and supported flows; auth.md is the prose companion that points back at it.\" \"Agents are expected to treat auth.md as both prose and structured data: Scan headings to find sections relevant to the current step (registration vs. operation). Read the Discovery section first to learn which flows are supported before committing to one. Extract code blocks as templates for HTTP requests. Use fenced blocks with language hints (http, json) so the agent can identify request shapes without ambiguity. Treat the PRM as authoritative if anything in this file conflicts with it. The PRM is the runtime source of truth.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-9 resource: "https://workos.com/auth-md/docs/flows/verified" title: "WorkOS. Agent verified — auth.md (ID-JAG agent-verified flow documentation, checked 29 October 2026): \"The agent's provider — OpenAI, Anthropic, Cursor, or any trusted agent platform — attests to the user's identity at registration time. Your service verifies the attestation and issues credentials synchronously, no human interaction required.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-10 resource: "https://workos.com/auth-md/docs/flows/claimed" title: "WorkOS. User claimed — auth.md (anonymous and service_auth user-claimed flow documentation, checked 29 October 2026): \"The agent registers without a provider-attested identity; the user claims it by signing in to your service and confirming a code the agent shows them. No agent-provider participation — just the app and the user.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-11 resource: "https://workos.com/auth-md/docs/apps" title: "WorkOS. For apps — auth.md (service integration guide, checked 29 October 2026): \"Services that want agents to authenticate on behalf of users publish discovery metadata and implement the /agent/identity registration endpoint plus the standard OAuth /oauth2/token and /oauth2/revoke endpoints described here. There are two flows to choose from — agent verified and user claimed — and a service may support either or both.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-12 resource: "https://workos.com/auth-md/docs/agent-providers" title: "WorkOS. For agent providers — auth.md (agent identity provider guide, checked 29 October 2026): \"Trusted agent providers — companies whose agents act on behalf of users (OpenAI, Anthropic, Cursor, and similar) — power the agent verified flow by asserting a user's identity to a downstream service. The artifact is an Identity Assertion JWT Authorization Grant (ID-JAG).\"" last_modified: 2026-10-29T00:00:00Z - id: ref-13 resource: "https://workos.com/docs/authkit/agent-registration" title: "WorkOS. Agent Registration – AuthKit – WorkOS Docs (AuthKit production documentation, checked 29 October 2026): \"Agent Registration is generally available. It enables AI agents and LLM-based clients to obtain identity credentials from your AuthKit-powered service. Unlike traditional OAuth flows designed for users in a browser, Agent Registration is purpose-built for programmatic clients that need machine-readable instructions, minimal interaction, and secure credential management. Agents discover the registration surface through your service's.well-known/oauth-authorization-server metadata, register with one of several identity types, optionally bind to a user via a claim ceremony, and exchange the resulting identity assertion for an access token or API key.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-14 resource: "https://workos.com/blog/agent-registration-with-auth-md" title: "Garrett Galow (WorkOS). Agent Registration with Auth.md — WorkOS (21 May 2026): \"Today we're releasing auth.md — an open protocol that tells agents how to register for your service via a Markdown file published on your domain.\" \"A document — plain Markdown, hosted at https://yourservice.com/auth.md. Agents parse it like llms.txt or agents.md: headings to navigate, fenced code blocks to extract request shapes, prose to disambiguate. A protocol — a small set of HTTP endpoints (/agent-auth, /agent-auth/claim, /agent-auth/claim/complete) that agents use to register for services on behalf of users. Once registered agents use standard credentials to access the service.\"" last_modified: 2026-05-21T00:00:00Z - id: ref-15 resource: "https://workos.com/blog/mcp-night-4-recap-auth-md-agentic-registration" title: "Zack Proser (WorkOS). MCP Night 4 recap: agent auth, auth.md, and the rise of agentic registration — WorkOS (25 May 2026): \"WorkOS announced Auth.md, a spec for letting agents register and sign up for services, and demoed it live with Cloudflare and Firecrawl.\" \"Auth.md is a spec, not an IETF-ratified standard — please don't bring the pitchforks. It's a set of ideas that lets you expose your application to agents so they can register, sign up, and start using it. Not as spam. Not as a fake human. As an agent acting as a first-class user.\"" last_modified: 2026-05-25T00:00:00Z - id: ref-16 resource: "https://workos.com/blog/auth-md-one-week-later" title: "Zack Proser (WorkOS). auth.md — One week later: who's shipped, who's writing, what's next — WorkOS (28 May 2026): \"Spec-compliant auth.md files appeared on real domains within hours, the launch partners who helped build the demo posted their own takes, and a widening circle of agent and identity tools started converging on the same primitive.\"" last_modified: 2026-05-28T00:00:00Z - id: ref-17 resource: "https://workos.com/blog/workos-aie-worlds-fair-2026-recap" title: "Zack Proser (WorkOS). Lifestyles of the AI-Native: WorkOS at the AI Engineer World's Fair 2026 — WorkOS (7 July 2026): \"Michael re-introduced auth.md, an open protocol that lets agents register and authenticate users without sign-up forms, and shares what early implementers have learned since launch.\"" last_modified: 2026-07-07T00:00:00Z - id: ref-18 resource: "https://workos.com/blog/mcp-client-identity-dcr-cimd-auth-md" title: "Maria Paktiti (WorkOS). How an MCP client should tell your OAuth server who it is — WorkOS (12 August 2026): \"Client identity answers which piece of software is this. User delegation answers on whose authority is it acting, and what may it do. DCR and CIMD only do the first.\" \"And auth.md, the open agent-registration protocol we published in May, went live inside AuthKit as Agent Registration on August 4.\"" last_modified: 2026-08-12T00:00:00Z - id: ref-19 resource: "https://auth-md.com/" title: "Fabricio Telles (auth-md.com). AI Agent Registration Protocol for Web — auth-md (independent community hub, checked 29 October 2026): \"Protocol authored by WorkOS under MIT License. This is an independent community resource.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-20 resource: "https://auth-md.com/auth.md" title: "Fabricio Telles (auth-md.com). /auth.md on auth-md.com (checked 29 October 2026): \"auth-md.com is an independent community resource about the auth.md protocol — the open standard that lets AI agents register for web services on behalf of users.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-21 resource: "https://auth-md.com/specification/" title: "Fabricio Telles (auth-md.com). auth.md Protocol Specification — Complete Technical Reference (community technical rendering, June 2026): \"CIMD — Claim Interception Mitigation by Design The email field on anonymous /agent/identity/claim binds the registration to the intended human — only that signed-in user can complete the ceremony. Without this, a third party who intercepted the user_code could claim the agent for themselves.\"" last_modified: 2026-06-01T00:00:00Z - id: ref-22 resource: "https://ft.ia.br/insights/auth-md-como-construi/" title: "Fabricio Telles. Como construí o auth-md.com em um fim de … | Fabricio Telles (24 May 2026): \"A WorkOS lançou o protocolo auth.md e encontrei livre o domínio auth-md.com. Registrei, e no mesmo dia comecei a construir.\"" last_modified: 2026-05-24T00:00:00Z - id: ref-23 resource: "https://raw.githubusercontent.com/fabricioctelles/skills/main/skills/auth-md/SKILL.md" title: "Fabricio Telles (fabricioctelles/skills). skills/auth-md/SKILL.md (version 2.1, dated 20 September 2026, Apache-2.0): \"Generate, validate, and explain auth.md files — the open protocol for AI agent registration.\"" last_modified: 2026-09-20T00:00:00Z - id: ref-24 resource: "https://tuist.dev/auth.md" title: "Tuist. https://tuist.dev/auth.md (live auth.md manifest for the Tuist MCP server, checked 29 October 2026): \"Tuist implements the current WorkOS auth.md protocol for the Model Context Protocol server at https://tuist.dev/mcp. Follow the discovered endpoints and the sequence below. Registration returns a signed identity assertion, not an access token. Exchange that assertion at the discovered token endpoint before calling the Model Context Protocol server.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-25 resource: "https://tuist.dev/.well-known/oauth-authorization-server" title: "Tuist. /.well-known/oauth-authorization-server (live RFC 8414 metadata with agent_auth v0.6.0 block, checked 29 October 2026): \"\"identity_endpoint\":\"https://tuist.dev/agent/identity\",\"identity_types_supported\":[\"anonymous\",\"identity_assertion\",\"service_auth\"]\"" last_modified: 2026-10-29T00:00:00Z - id: ref-26 resource: "https://tuist.dev/changelog/2026.05.27-auth-md" title: "Tuist. Sign agents in with auth.md (Tuist Changelog, 27 May 2026): \"Tuist now supports auth.md, the open agent registration specification. Agents that implement the standard can connect to the Tuist MCP server directly: depending on the agent, Tuist either confirms the registration with the agent provider, or emails you a secure link with a six-digit code to read back to the agent. No browser-based OAuth round-trip required.\"" last_modified: 2026-05-27T00:00:00Z - id: ref-27 resource: "https://www.firecrawl.dev/auth.md" title: "Firecrawl. https://www.firecrawl.dev/auth.md (live auth.md manifest for WorkOS ID-JAG registration, checked 29 October 2026): \"You are an agent. Firecrawl supports agentic registration for WorkOS ID-JAG identity assertions: discover -> register -> call API. Follow the steps in order; do not skip ahead. Firecrawl currently supports one registration method: - identity_assertion with assertion_type: \"urn:ietf:params:oauth:token-type:id-jag\" - requested_credential_type: \"api_key\" - Credentials are Firecrawl API keys used as bearer tokens.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-28 resource: "https://www.firecrawl.dev/.well-known/oauth-authorization-server" title: "Firecrawl. /.well-known/oauth-authorization-server (live RFC 8414 metadata with agent_auth block, checked 29 October 2026): \"\"agent_auth\":{\"skill\":\"https://www.firecrawl.dev/auth.md\",\"register_uri\":\"https://www.firecrawl.dev/agent/auth\",\"revocation_uri\":\"https://www.firecrawl.dev/agent/auth/revoke\",\"identity_types_supported\":[\"identity_assertion\"],\"identity_assertion\":{\"assertion_types_supported\":[\"urn:ietf:params:oauth:token-type:id-jag\"],\"credential_types_supported\":[\"api_key\"]}\"" last_modified: 2026-10-29T00:00:00Z - id: ref-29 resource: "https://alpic.ai/auth.md" title: "Alpic. https://alpic.ai/auth.md (live auth.md manifest for MCP server deployment, checked 29 October 2026): \"Alpic supports agentic registration. If you are an AI agent acting on behalf of a user, you can obtain an Alpic API key without a human filling in a sign-up form, then use it to deploy and manage MCP servers (e.g. alpic deploy).\"" last_modified: 2026-10-29T00:00:00Z - id: ref-30 resource: "https://api.alpic.ai/.well-known/oauth-authorization-server" title: "Alpic. https://api.alpic.ai/.well-known/oauth-authorization-server (live agent_auth metadata, checked 29 October 2026): \"\"agent_auth\":{\"skill\":\"https://alpic.ai/auth.md\",\"register_uri\":\"https://api.alpic.ai/agent/auth\",\"identity_types_supported\":[\"identity_assertion\"],\"identity_assertion\":{\"assertion_types_supported\":[\"urn:ietf:params:oauth:token-type:id-jag\",\"urn:ietf:params:oauth:token-type:jwt\"],\"credential_types_supported\":[\"api_key\"]}}}\"" last_modified: 2026-10-29T00:00:00Z - id: ref-31 resource: "https://agents-txt.com/auth.md" title: "agents-txt.com. https://agents-txt.com/auth.md (live auth.md walkthrough advertised under Authorization: auth-md, checked 29 October 2026): \"This deployment hosts the agents.txt reference site. The agentic-registration walkthrough below is a working example of the auth.md shape advertised in /agents.txt under Authorization: auth-md. The OAuth metadata pair (/.well-known/oauth-protected-resource + /.well-known/oauth-authorization-server) is the same one used by the oauth2 protocol on this site; the additional agent_auth block on the AS metadata is what activates this flow.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-32 resource: "https://agents-txt.com/.well-known/oauth-authorization-server" title: "agents-txt.com. /.well-known/oauth-authorization-server (live agent_auth metadata, checked 29 October 2026): \"\"agent_auth\":{\"skill\":\"https://agents-txt.com/auth.md\",\"register_uri\":\"https://agents-txt.com/agent/auth\",\"claim_uri\":\"https://agents-txt.com/agent/auth/claim\",\"revocation_uri\":\"https://agents-txt.com/agent/auth/revoke\",\"identity_types_supported\":[\"anonymous\",\"identity_assertion\"]\"" last_modified: 2026-10-29T00:00:00Z - id: ref-33 resource: "https://mailbox.bot/auth.md" title: "mailbox.bot. https://mailbox.bot/auth.md (live auth.md manifest for physical postal mail API, checked 29 October 2026): \"This document describes agent registration for mailbox.bot, a live physical postal mail API at https://mailbox.bot. Protected REST resources live under https://mailbox.bot/api and agent registration lives on the same authorization server. Registration is intentionally guarded: agents can discover the service and request a human-approved claim by email, but live order placement spends prepaid mailbox.bot credits owned by the human operator and requires human-owned onboarding and scoped credentials.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-34 resource: "https://mailbox.bot/.well-known/oauth-authorization-server" title: "mailbox.bot. /.well-known/oauth-authorization-server (live agent_auth metadata with user_claimed_email_required flow, checked 29 October 2026): \"\"current_flow\":\"user_claimed_email_required\",\"identity_types_supported\":[\"identity_assertion\"],\"anonymous\":{\"enabled\":false,\"reason\":\"Anonymous registration is not enabled because mailbox.bot can place physical mail orders and spend prepaid operator credits.\"}\"" last_modified: 2026-10-29T00:00:00Z - id: ref-35 resource: "https://workos.com/auth.md" title: "WorkOS. https://workos.com/auth.md (live auth.md manifest for WorkOS one-shot environments, checked 29 October 2026): \"This document tells you how to register a credential for WorkOS one-shot environments — temporary, anonymous WorkOS environments you can provision without an account and (optionally) have the user claim later to make permanent. Follow the steps in order; do not skip ahead. This is the user claimed flow: provision anonymously, work immediately, claim when the user is available. There is no agent-verified or email-verified registration today.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-36 resource: "https://us.posthog.com/auth.md" title: "PostHog. https://us.posthog.com/auth.md (live auth.md manifest, checked 29 October 2026): \"Available on the Enterprise plan with XAA enabled, and currently in beta, so most clients should use one of the options above. With it configured, an agent presents an ID-JAG identity assertion (identity_assertion) to the token endpoint using the JWT-bearer grant\"" last_modified: 2026-10-29T00:00:00Z - id: ref-37 resource: "https://posthog.com/docs/settings/agent-discovery" title: "PostHog. Agent discovery (auth.md) - Docs - PostHog (documentation, checked 29 October 2026): \"PostHog publishes machine-readable metadata so AI agents can discover how to authenticate and create accounts, with no PostHog-specific SDK and no hardcoded endpoints.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-38 resource: "https://here.now/auth.md" title: "here.now. https://here.now/auth.md (live auth.md manifest for email-code API key provisioning, checked 29 October 2026): \"here.now supports agent-assisted API key creation with an email code. It does not currently support agent-verified ID-JAG registration, OAuth client registration, MCP auth, or third-party identity provider assertions.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-39 resource: "https://headlessdomains.com/auth.md" title: "HeadlessDomains. https://headlessdomains.com/auth.md (live auth.md manifest, checked 29 October 2026): \"HeadlessDomains supports agent-native authentication for autonomous domain registration, renewal, profile updates, and DNS-linked identity operations.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-40 resource: "https://nano-gpt.com/auth.md" title: "NanoGPT. https://nano-gpt.com/auth.md (live auth.md manifest, checked 29 October 2026): \"NanoGPT supports agent and app access through user-approved API keys. OAuth-aware clients should use authorization-code + PKCE. Agents can also use the browser-approved device login flow for CLI-style handoff.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-41 resource: "https://webclaw.io/auth.md" title: "WebClaw. https://webclaw.io/auth.md (live auth.md manifest, checked 29 October 2026): \"webclaw supports OAuth 2.0 Device Authorization for agent onboarding. Agents can request a short-lived scoped bearer token, show the user a code, and wait while the user approves the request in the browser.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-42 resource: "https://api.particle.pro/auth.md" title: "Particle Pro. https://api.particle.pro/auth.md (live auth.md manifest, checked 29 October 2026): \"There is no anonymous agent self-registration: every credential is tied to a human-owned platform account (the API is paid). The fastest path for a fully headless agent is to ask your operator for an API key from https://platform.particle.pro/tokens. An agent with no operator at all can still call the API by paying per request with x402\"" last_modified: 2026-10-29T00:00:00Z - id: ref-43 resource: "https://www.cloudflare.com/auth.md" title: "Cloudflare. https://www.cloudflare.com/auth.md (live /auth.md guidance file, checked 29 October 2026): \"Cloudflare is working toward auth.md registration support, including the ID-JAG identity_assertion flow. This file exists at https://cloudflare.com/auth.md so agents can discover what is coming soon and use supported Cloudflare authentication paths safely today. ## auth.md Registration Cloudflare does not yet advertise production auth.md registration methods, auth.md Protected Resource Metadata, or agent-auth metadata. Do not mint ID-JAGs or attempt identity_assertion, service_auth, or anonymous auth.md registration against Cloudflare until this file links to production discovery metadata.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-44 resource: "https://resend.com/auth.md" title: "Resend. https://resend.com/auth.md (live /auth.md guidance file, checked 29 October 2026): \"Resend does not support agentic registration today. Credentials are issued by the user out of band; this file tells you how to pick them up and use them without putting them at risk.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-45 resource: "https://ora.ai/auth.md" title: "Ora. https://ora.ai/auth.md (live /auth.md guidance file, checked 29 October 2026): \"This file lives at /auth.md, the conventional discovery path from the WorkOS auth.md spec (https://github.com/workos/auth.md). Ora does not implement that spec's registration machinery; this file documents what ora implements and what it deliberately does not.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-46 resource: "https://raw.githubusercontent.com/ax-platform/ax-platform-mcp/main/README.md" title: "PAX AI (ax-platform/ax-platform-mcp). README.md (Hermes and shell-agent onboarding via auth.md, checked 29 October 2026): \"Give a Hermes agent, or the next serious shell-capable agent harness, https://paxai.app/auth.md; it can learn the device-code flow, show you the approval code, store refreshable credentials, and join the aX network on a named MCP route.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-47 resource: "https://paxai.app/blog/implementing-auth-md-for-mcp-agents/" title: "PAX AI. Implementing auth.md for MCP agents: field notes from a live platform — aX blog (10 June 2026): \"We shipped an auth.md instruction file to solve the first half of that problem — how an agent finds out how to connect —\"" last_modified: 2026-06-10T00:00:00Z - id: ref-48 resource: "https://storewalk.ai/checks/TRX-009" title: "Storewalk. TRX-009 auth.md agent registration guide published — Storewalk (check documentation, checked 29 October 2026): \"We check that /auth.md exists, is a Markdown document rather than your storefront page, and opens with a heading that names auth.md.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-49 resource: "https://agentready-rho.vercel.app/methodology/usability.auth-docs" title: "AgentReady. Auth documentation — check | AgentReady (usability.auth-docs methodology, checked 29 October 2026): \"Looked for /auth.md or an authentication docs page with code examples.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-50 resource: "https://raw.githubusercontent.com/actcore/act-spec/main/spec/ACT-AUTH.md" title: "ACT Specification (actcore/act-spec). spec/ACT-AUTH.md (ACT Authentication, normative v0.4.0, checked 29 October 2026): \"This document specifies how authentication is handled in ACT. It covers two independent layers: 1. Component-to-external auth — credentials a component uses to authenticate with external services (databases, APIs). Normative; primary subject of this document. 2. Client-to-host auth — how a client (agent, CLI, browser) authenticates to the ACT host. Normative for HTTP transports; informative for stdio.\"" last_modified: 2026-10-29T00:00:00Z - id: ref-51 resource: "https://api.github.com/repos/better-auth/agent-auth-protocol" title: "GitHub REST API. better-auth/agent-auth-protocol repository metadata (checked 29 October 2026): \"\"full_name\": \"better-auth/agent-auth-protocol\"\"" last_modified: 2026-10-29T00:00:00Z - id: ref-52 resource: "https://www.rfc-editor.org/rfc/rfc9728.html" title: "Michael B. Jones, Phil Hunt, and Aaron Parecki. RFC 9728: OAuth 2.0 Protected Resource Metadata (IETF Standards Track, April 2025): \"This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.\"" last_modified: 2025-04-01T00:00:00Z - id: ref-53 resource: "https://www.rfc-editor.org/rfc/rfc8414.html" title: "Michael B. Jones, Nat Sakimura, and John Bradley. RFC 8414: OAuth 2.0 Authorization Server Metadata (IETF Standards Track, June 2018): \"This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.\"" last_modified: 2018-06-01T00:00:00Z - id: ref-54 resource: "https://www.rfc-editor.org/rfc/rfc8628.html" title: "William Denniss, John Bradley, Michael B. Jones, and Hannes Tschofenig. RFC 8628: OAuth 2.0 Device Authorization Grant (IETF Standards Track, August 2019): \"The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical.\"" last_modified: 2019-08-01T00:00:00Z - id: ref-55 resource: "https://www.rfc-editor.org/rfc/rfc7591.html" title: "Justin Richer, Michael B. Jones, John Bradley, Maciej Machulak, and Phil Hunt. RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol (IETF Standards Track, July 2015): \"This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.\"" last_modified: 2015-07-01T00:00:00Z - id: ref-56 resource: "https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html" title: "Aaron Parecki, Karl McGuinness, and Brian Campbell. Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-04, IETF OAuth Working Group Internet-Draft, 21 May 2026): \"This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA).\"" last_modified: 2026-05-21T00:00:00Z - id: ref-57 resource: "https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html" title: "Aaron Parecki and Emelia Smith. OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document-02, IETF OAuth Working Group Internet-Draft, 6 July 2026): \"This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration.\"" last_modified: 2026-07-06T00:00:00Z - id: ref-58 resource: "https://blog.cloudflare.com/temporary-accounts/" title: "Sid Chatterjee, Celso Martinho, and Brendan Irvine-Broque (Cloudflare). Temporary Cloudflare Accounts for AI agents | Cloudflare Blog (19 June 2026): \"Last month, we collaborated with WorkOS on the launch of auth.md, which anyone can adopt, to let agents provision new accounts using well-established, existing OAuth standards.\"" last_modified: 2026-06-19T00:00:00Z - id: ref-59 resource: "https://daringfireball.net/linked/2026/06/15/workos-authmd" title: "John Gruber. Daring Fireball: WorkOS Launches Auth.md -- an Open Protocol for Agent Registration (15 June 2026): \"By exposing a single, machine-readable Markdown file at your service root, AI agents can dynamically discover your OAuth Protected Resource Metadata, parse required scopes, and authenticate seamlessly.\"" last_modified: 2026-06-15T00:00:00Z - id: ref-60 resource: "https://zuplo.com/blog/auth-md-agent-signup" title: "Martyn Davies (Zuplo). How auth.md Standardises Agent Signup - Zuplo (28 May 2026): \"auth.md, a new open protocol shaped by the folks at WorkOS, attempts to start the process of removing that wall. It's a Markdown file an app hosts at its domain walking an agent through registering for a credential, claiming it against a real user, and using it against the API.\"" last_modified: 2026-05-28T00:00:00Z - id: ref-61 resource: "https://uchibeke.com/auth-md-solves-agent-registration-what-about-authorization/" title: "Uchi Uchibeke. auth.md Solves Agent Registration. What About Authorization? | Uchi Uchibeke (30 August 2026): \"auth.md solves agent registration (who gets credentials), not runtime authorization (what each action is allowed to do)\"" last_modified: 2026-08-30T00:00:00Z - id: ref-62 resource: "https://victorinollc.com/thinking/workos-auth-md-open-agent-registration" title: "Thiago Victorino. auth.md and the OAuth Lineage Move for Agent Registration | Victorino Group (28 May 2026): \"A service drops a Markdown file at service.com/auth.md, exposes two well-known endpoints, and any compliant agent can discover how to register, get credentials, and revoke them.\"" last_modified: 2026-05-28T00:00:00Z - id: ref-63 resource: "https://api.github.com/repos/workos/auth.md/pulls/20" title: "GitHub REST API. workos/auth.md Pull Request #20 (agent-services: Preserve login_hint when re-minting id_jag claim): \"\"number\": 20, \"state\": \"closed\", \"locked\": false, \"title\": \"agent-services: Preserve login_hint when re-minting id_jag claim\", \"user\": { \"login\": \"devin-ai-integration[bot]\",\"" last_modified: 2026-07-22T00:00:00Z - id: ref-64 resource: "https://api.github.com/repos/workos/auth.md/pulls/21" title: "GitHub REST API. workos/auth.md Pull Request #21 (Revoke registration and delegation on provider SET, merged 23 July 2026): \"\"number\": 21, \"state\": \"closed\", \"locked\": false, \"title\": \"Revoke registration and delegation on provider SET\", \"user\": { \"login\": \"devin-ai-integration[bot]\",\"" last_modified: 2026-07-23T00:00:00Z - id: ref-65 resource: "https://api.github.com/repos/workos/auth.md/issues/24" title: "GitHub REST API. workos/auth.md Issue #24 (Conformance report from a second implementation (id.org.ai) by nathanclevenger): \"\"number\": 24,\" \"\"title\": \"Conformance report from a second implementation (id.org.ai): two stale bits in the spec, and a question about trust-list discovery\",\" \"\"login\": \"nathanclevenger\",\"" last_modified: 2026-08-01T00:00:00Z --- # auth.md auth.md is an agentic-web standard (document format — /auth.md) at step 3, Permit, governed by WorkOS; its status is "Reference specification at v0.6.0". It answers: "How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?" Replacing or extending Self-service sign-up form, implementation status is multi-implementation (Tuist, Firecrawl, Alpic, agents-txt.com, mailbox.bot, WorkOS, PostHog, here.now, HeadlessDomains, NanoGPT, WebClaw, Particle Pro, Cloudflare, Resend, and Ora), last verified 2026-10-29. # Overview `auth.md` is an MIT-licensed open specification authored by WorkOS (`workos/auth.md` [^ref-1][^ref-2], `https://workos.com/auth-md` [^ref-6]) that defines how AI agents discover, register for, and obtain scoped credentials from a web service on a user's behalf without human sign-up forms or browser-based OAuth redirect screens (`"A reference implementation of agentic registration — a protocol for agents to authenticate to services on behalf of users. Three roles: an agent acting for a user, an agent provider that mints identity assertions (ID-JAGs), and a service that accepts those assertions, when available, and issues credentials. If the agent is not associated with a user identity, or the agent provider does not support ID-JAGs, the service uses an RFC 8628-style claim ceremony to authenticate the agent instead."`) [^ref-1][^ref-2][^ref-6][^ref-14]. On *Overview — auth.md* (`https://workos.com/auth-md/docs`), WorkOS explains that `"At its core, auth.md is a small Markdown file an application hosts at its domain — typically https://service.example.com/auth.md. The file describes how agents register with that service, which flows it supports, the scopes it exposes, and what to do once registered. Because Markdown is plain text, the same file works as documentation for human integrators and as a discoverable runtime artifact for agents."`, while *The auth.md file — auth.md* (`https://workos.com/auth-md/docs/auth-md`) specifies that `"The structured Protected Resource Metadata (PRM) at /.well-known/oauth-protected-resource remains the authoritative source for endpoint URLs and supported flows; auth.md is the prose companion that points back at it."` [^ref-7][^ref-8]. In `v0.6.0` (10 June 2026), an unauthenticated API response returns `HTTP 401 Unauthorized` with a `WWW-Authenticate: Bearer resource_metadata="..."` header pointing to `/.well-known/oauth-protected-resource` (*RFC 9728: OAuth 2.0 Protected Resource Metadata*, `"This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource."` [^ref-52]), which links to `/.well-known/oauth-authorization-server` (`RFC 8414`: `"This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities."` [^ref-53]) containing an `agent_auth` object (`skill`, `identity_endpoint`, `claim_endpoint`, `events_endpoint`, `identity_types_supported`, and `events_supported`) [^ref-3][^ref-4][^ref-8][^ref-52][^ref-53]. The `v0.6.0` specification (`AUTH.md`: `"You are an agent. This service supports agentic registration: discover → register → (claim if needed) → exchange for an access_token → call API → handle revocation. Follow the steps in order; do not skip ahead."` [^ref-3]) defines three registration types at `POST /agent/identity` (renamed from `/agent/auth` in `v0.2.0`), grouped into two high-level product flows (`Agent verified` and `User claimed`) that issue a service-signed ES256 `identity_assertion` JWT which the agent exchanges at `/oauth2/token` using the RFC 7523 JWT-bearer grant (`urn:ietf:params:oauth:grant-type:jwt-bearer`) for a short-lived `access_token` (`"Separates the identity and credential surfaces. Registration now mints a service-signed identity_assertion that the agent exchanges for an access_token at a standard OAuth token endpoint, instead of having /agent/auth issue credentials directly."`) [^ref-3][^ref-4][^ref-9][^ref-10][^ref-11]: 1. **`identity_assertion` (Agent verified flow with `ID-JAG`):** On *Agent verified — auth.md* (`https://workos.com/auth-md/docs/flows/verified`) and *For agent providers — auth.md* (`https://workos.com/auth-md/docs/agent-providers`), `"The agent's provider — OpenAI, Anthropic, Cursor, or any trusted agent platform — attests to the user's identity at registration time. Your service verifies the attestation and issues credentials synchronously, no human interaction required."` and `"Trusted agent providers — companies whose agents act on behalf of users (OpenAI, Anthropic, Cursor, and similar) — power the agent verified flow by asserting a user's identity to a downstream service. The artifact is an Identity Assertion JWT Authorization Grant (ID-JAG)."` [^ref-9][^ref-12]. The assertion uses the IETF *Identity Assertion JWT Authorization Grant* (`draft-ietf-oauth-identity-assertion-authz-grant-04`, 21 May 2026: `"This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA)."` [^ref-56]) with `assertion_type: "urn:ietf:params:oauth:token-type:id-jag"` [^ref-3][^ref-9][^ref-56]. Since `v0.5.0` (5 June 2026), `/agent/identity` enforces fresh `auth_time` (`401 login_required`) and requires a one-time RFC 8628-shaped confirmation ceremony (`401 interaction_required`, modeled on `RFC 8628` [^ref-54]) before linking a new `(iss, sub)` provider delegation to an existing user account: `"Gates first-time linking of an ID-JAG to an existing account behind a user-confirmation ceremony, and requires fresh auth_time on every ID-JAG. Without this confirmation gate, any trusted provider could mint an ID-JAG with email_verified: true for a victim's email and silently take over their account. Without the freshness gate, an agent could use a stale upstream session."` [^ref-4][^ref-54]. Provider-initiated revocation uses RFC 8417 Security Event Tokens (`application/secevent+jwt` with schema `https://schemas.workos.com/events/agent/auth/identity/assertion/revoked`) pushed to `events_endpoint` (`/agent/event/notify`) per RFC 8935 (`"Switches the provider-driven invalidation channel from OIDC Back-Channel Logout to RFC 8417 Security Event Token push delivery per RFC 8935. Same trust path as before (issuer JWKS, jti replay protection), with a wire format and event shape that generalizes beyond revocation."`) [^ref-4]. 2. **`service_auth` (User claimed flow with `login_hint`):** Separated from `identity_assertion` in `v0.6.0` (10 June 2026): `"Splits the email-based registration path out from identity_assertion and into a top-level service_auth registration type, with a body modeled on OIDC CIBA's login_hint. The previous shape was honest about how it worked — the service was verifying the email, not the agent — but it was filed under identity_assertion like the agent was asserting something. CIBA's vocabulary fits: the agent is hinting at who the user is, and the service authenticates the user out-of-band."` [^ref-4]. The agent sends `{ "type": "service_auth", "login_hint": "" }` to `/agent/identity`, receives a `claim_token` plus a `claim` block (`user_code` and `verification_uri`), displays the code and URL to the user (since `v0.4.0` on 4 June 2026: `"Inverts the claim ceremony and consolidates polling onto the standard /oauth2/token endpoint. Service emails have been removed in favor of the agent surfacing the verification URL and user_code to the user, who signs in through the service's own browser-based session (reusing any existing session, SSO, MFA the service applies) and confirms the code on a service-owned page. This borrows the ceremony shape from RFC 8628 device authorization (user_code, verification_uri, expires_in, interval) without overloading the IANA device_code grant."`), and polls `/oauth2/token` with `grant_type: "urn:workos:agent-auth:grant-type:claim"` until the user signs in on the service's page and confirms the code [^ref-3][^ref-4][^ref-10]. 3. **`anonymous` (User claimed flow with pre-claim scopes):** On *User claimed — auth.md* (`https://workos.com/auth-md/docs/flows/claimed`), `"The agent registers without a provider-attested identity; the user claims it by signing in to your service and confirming a code the agent shows them. No agent-provider participation — just the app and the user."` [^ref-10]. The agent posts `{ "type": "anonymous" }` to `/agent/identity`, immediately receives a pre-claim `identity_assertion` restricted to `pre_claim_scopes`, and can later invoke `POST /agent/identity/claim` to upgrade the registration to full user-bound scopes [^ref-3][^ref-4][^ref-10]. ### Governance and Disambiguation (`auth-md.com`, `ACT-AUTH.md`, and `CIMD`) - **WorkOS vs. `auth-md.com` (Fabricio Telles):** WorkOS authored and maintains the protocol (`"WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure — it composes existing OAuth standards (Protected Resource Metadata, ID-JAG identity assertions) and any app can publish or any agent can read one with no WorkOS account required."` [^ref-6]), whereas `https://auth-md.com/` (*AI Agent Registration Protocol for Web — auth-md*) is an independent community portal built by Brazilian engineer Fabricio Telles on 24 May 2026 (*Como construí o auth-md.com em um fim de … | Fabricio Telles*, `https://ft.ia.br/insights/auth-md-como-construi/`: `"A WorkOS lançou o protocolo auth.md e encontrei livre o domínio auth-md.com. Registrei, e no mesmo dia comecei a construir."` [^ref-22]) [^ref-6][^ref-19][^ref-20][^ref-22]. Both `https://auth-md.com/` and `https://auth-md.com/auth.md` explicitly state: `"Protocol authored by WorkOS under MIT License. This is an independent community resource."` and `"auth-md.com is an independent community resource about the auth.md protocol — the open standard that lets AI agents register for web services on behalf of users."` [^ref-19][^ref-20]. - **Unrelated `ACT-AUTH.md` (`actcore/act-spec`) and Better Auth Agent Auth:** `auth.md` is unrelated to `spec/ACT-AUTH.md` (`ACT Authentication`, `v0.4.0`) in `actcore/act-spec`, which specifies component-to-external secret injection and client-to-host bearer authentication (`"This document specifies how authentication is handled in ACT. It covers two independent layers: 1. Component-to-external auth — credentials a component uses to authenticate with external services (databases, APIs). Normative; primary subject of this document. 2. Client-to-host auth — how a client (agent, CLI, browser) authenticates to the ACT host. Normative for HTTP transports; informative for stdio."`) and forbids components from executing OAuth flows themselves [^ref-50]. It is also distinct from `better-auth/agent-auth-protocol`, which uses `/.well-known/agent-configuration` [^ref-51]. - **Two meanings of `CIMD`:** In *How an MCP client should tell your OAuth server who it is — WorkOS* (12 August 2026), Maria Paktiti contrasts `auth.md` with IETF *OAuth Client ID Metadata Document* (`draft-ietf-oauth-client-id-metadata-document-02`: `"This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration."` [^ref-57]) and `RFC 7591` Dynamic Client Registration ([^ref-55]): `"Client identity answers which piece of software is this. User delegation answers on whose authority is it acting, and what may it do. DCR and CIMD only do the first."` [^ref-18][^ref-55][^ref-57]. Separately, the community rendering *auth.md Protocol Specification — Complete Technical Reference* (`https://auth-md.com/specification/`) uses the acronym `CIMD` inside section 11 for an internal claim-binding rule (`"CIMD — Claim Interception Mitigation by Design The email field on anonymous /agent/identity/claim binds the registration to the intended human — only that signed-in user can complete the ceremony. Without this, a third party who intercepted the user_code could claim the agent for themselves."`), which is unrelated to the IETF OAuth CIMD draft [^ref-21][^ref-57]. # Examples ```http GET {origin}/auth.md # parse: A markdown document describing one or more of the three named flows (identity_assertion, service_auth, anonymous) and referencing /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server per RFC 9728/8414 # on absent: No auth.md file at the site root; the service has not published an agent self-registration convention ``` # Knowledge Graph * **Lifecycle Step**: [3 Permit](/category/permit/index.md) * **Builds on**: [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/okf/protocols/oauth-metadata-for-agents.md), [Identity Assertion JWT Authorization Grant (ID-JAG)](/okf/protocols/identity-assertion-authz-grant.md) * **Pairs with**: [Identity Assertion JWT Authorization Grant (ID-JAG)](/okf/protocols/identity-assertion-authz-grant.md), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/okf/protocols/oauth-metadata-for-agents.md), [x402](/okf/protocols/x402.md), [agents.txt](/okf/protocols/agents-txt.md), [Model Context Protocol](/okf/protocols/mcp.md) * **Related terms**: [Signed agent](/okf/terms/signed-agent.md), [Protected Resource Metadata](/okf/terms/protected-resource-metadata.md) * **Compared in**: [OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata (classic vs agentic)](/compare/oauth-vs-cimd/index.md), [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization) vs auth.md](/compare/oauth-metadata-for-agents-vs-auth-md/index.md), [agent-permissions.json vs auth.md](/compare/agent-permissions-json-vs-auth-md/index.md) [^ref-1]: WorkOS (workos/auth.md). README.md (auth.md reference implementation of agentic registration, checked 29 October 2026): "A reference implementation of agentic registration — a protocol for agents to authenticate to services on behalf of users. Three roles: an agent acting for a user, an agent provider that mints identity assertions (ID-JAGs), and a service that accepts those assertions, when available, and issues credentials. If the agent is not associated with a user identity, or the agent provider does not support ID-JAGs, the service uses an RFC 8628-style claim ceremony to authenticate the agent instead." (https://raw.githubusercontent.com/workos/auth.md/main/README.md) [^ref-2]: GitHub REST API. workos/auth.md repository metadata (created 20 May 2026, MIT License, checked 29 October 2026): ""full_name": "workos/auth.md"" ""spdx_id": "MIT"" (https://api.github.com/repos/workos/auth.md) [^ref-3]: WorkOS (workos/auth.md). AUTH.md (reference procedural manifest for agentic registration, checked 29 October 2026): "You are an agent. This service supports agentic registration: discover → register → (claim if needed) → exchange for an access_token → call API → handle revocation. Follow the steps in order; do not skip ahead." (https://raw.githubusercontent.com/workos/auth.md/main/AUTH.md) [^ref-4]: WorkOS (workos/auth.md). CHANGELOG.md (v0.1.0 dated 21 May 2026 through v0.6.0 dated 10 June 2026): "Separates the identity and credential surfaces. Registration now mints a service-signed identity_assertion that the agent exchanges for an access_token at a standard OAuth token endpoint, instead of having /agent/auth issue credentials directly." "Gates first-time linking of an ID-JAG to an existing account behind a user-confirmation ceremony, and requires fresh auth_time on every ID-JAG. Without this confirmation gate, any trusted provider could mint an ID-JAG with email_verified: true for a victim's email and silently take over their account. Without the freshness gate, an agent could use a stale upstream session." "Switches the provider-driven invalidation channel from OIDC Back-Channel Logout to RFC 8417 Security Event Token push delivery per RFC 8935. Same trust path as before (issuer JWKS, jti replay protection), with a wire format and event shape that generalizes beyond revocation." "Splits the email-based registration path out from identity_assertion and into a top-level service_auth registration type, with a body modeled on OIDC CIBA's login_hint. The previous shape was honest about how it worked — the service was verifying the email, not the agent — but it was filed under identity_assertion like the agent was asserting something. CIBA's vocabulary fits: the agent is hinting at who the user is, and the service authenticates the user out-of-band." "Inverts the claim ceremony and consolidates polling onto the standard /oauth2/token endpoint. Service emails have been removed in favor of the agent surfacing the verification URL and user_code to the user, who signs in through the service's own browser-based session (reusing any existing session, SSO, MFA the service applies) and confirms the code on a service-owned page. This borrows the ceremony shape from RFC 8628 device authorization (user_code, verification_uri, expires_in, interval) without overloading the IANA device_code grant." (https://raw.githubusercontent.com/workos/auth.md/main/CHANGELOG.md) [^ref-5]: WorkOS (workos/auth.md). package.json (version: 0.6.0, checked 29 October 2026): ""version": "0.6.0"" (https://raw.githubusercontent.com/workos/auth.md/main/package.json) [^ref-6]: WorkOS. auth.md — Open Protocol for Agent Registration (official landing page, checked 29 October 2026): "WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure — it composes existing OAuth standards (Protected Resource Metadata, ID-JAG identity assertions) and any app can publish or any agent can read one with no WorkOS account required." (https://workos.com/auth-md) [^ref-7]: WorkOS. Overview — auth.md (official documentation overview, checked 29 October 2026): "At its core, auth.md is a small Markdown file an application hosts at its domain — typically https://service.example.com/auth.md. The file describes how agents register with that service, which flows it supports, the scopes it exposes, and what to do once registered. Because Markdown is plain text, the same file works as documentation for human integrators and as a discoverable runtime artifact for agents." (https://workos.com/auth-md/docs) [^ref-8]: WorkOS. The auth.md file — auth.md (file anatomy and agent parsing contract, checked 29 October 2026): "The structured Protected Resource Metadata (PRM) at /.well-known/oauth-protected-resource remains the authoritative source for endpoint URLs and supported flows; auth.md is the prose companion that points back at it." "Agents are expected to treat auth.md as both prose and structured data: Scan headings to find sections relevant to the current step (registration vs. operation). Read the Discovery section first to learn which flows are supported before committing to one. Extract code blocks as templates for HTTP requests. Use fenced blocks with language hints (http, json) so the agent can identify request shapes without ambiguity. Treat the PRM as authoritative if anything in this file conflicts with it. The PRM is the runtime source of truth." (https://workos.com/auth-md/docs/auth-md) [^ref-9]: WorkOS. Agent verified — auth.md (ID-JAG agent-verified flow documentation, checked 29 October 2026): "The agent's provider — OpenAI, Anthropic, Cursor, or any trusted agent platform — attests to the user's identity at registration time. Your service verifies the attestation and issues credentials synchronously, no human interaction required." (https://workos.com/auth-md/docs/flows/verified) [^ref-10]: WorkOS. User claimed — auth.md (anonymous and service_auth user-claimed flow documentation, checked 29 October 2026): "The agent registers without a provider-attested identity; the user claims it by signing in to your service and confirming a code the agent shows them. No agent-provider participation — just the app and the user." (https://workos.com/auth-md/docs/flows/claimed) [^ref-11]: WorkOS. For apps — auth.md (service integration guide, checked 29 October 2026): "Services that want agents to authenticate on behalf of users publish discovery metadata and implement the /agent/identity registration endpoint plus the standard OAuth /oauth2/token and /oauth2/revoke endpoints described here. There are two flows to choose from — agent verified and user claimed — and a service may support either or both." (https://workos.com/auth-md/docs/apps) [^ref-12]: WorkOS. For agent providers — auth.md (agent identity provider guide, checked 29 October 2026): "Trusted agent providers — companies whose agents act on behalf of users (OpenAI, Anthropic, Cursor, and similar) — power the agent verified flow by asserting a user's identity to a downstream service. The artifact is an Identity Assertion JWT Authorization Grant (ID-JAG)." (https://workos.com/auth-md/docs/agent-providers) [^ref-13]: WorkOS. Agent Registration – AuthKit – WorkOS Docs (AuthKit production documentation, checked 29 October 2026): "Agent Registration is generally available. It enables AI agents and LLM-based clients to obtain identity credentials from your AuthKit-powered service. Unlike traditional OAuth flows designed for users in a browser, Agent Registration is purpose-built for programmatic clients that need machine-readable instructions, minimal interaction, and secure credential management. Agents discover the registration surface through your service's.well-known/oauth-authorization-server metadata, register with one of several identity types, optionally bind to a user via a claim ceremony, and exchange the resulting identity assertion for an access token or API key." (https://workos.com/docs/authkit/agent-registration) [^ref-14]: Garrett Galow (WorkOS). Agent Registration with Auth.md — WorkOS (21 May 2026): "Today we're releasing auth.md — an open protocol that tells agents how to register for your service via a Markdown file published on your domain." "A document — plain Markdown, hosted at https://yourservice.com/auth.md. Agents parse it like llms.txt or agents.md: headings to navigate, fenced code blocks to extract request shapes, prose to disambiguate. A protocol — a small set of HTTP endpoints (/agent-auth, /agent-auth/claim, /agent-auth/claim/complete) that agents use to register for services on behalf of users. Once registered agents use standard credentials to access the service." (https://workos.com/blog/agent-registration-with-auth-md) [^ref-15]: Zack Proser (WorkOS). MCP Night 4 recap: agent auth, auth.md, and the rise of agentic registration — WorkOS (25 May 2026): "WorkOS announced Auth.md, a spec for letting agents register and sign up for services, and demoed it live with Cloudflare and Firecrawl." "Auth.md is a spec, not an IETF-ratified standard — please don't bring the pitchforks. It's a set of ideas that lets you expose your application to agents so they can register, sign up, and start using it. Not as spam. Not as a fake human. As an agent acting as a first-class user." (https://workos.com/blog/mcp-night-4-recap-auth-md-agentic-registration) [^ref-16]: Zack Proser (WorkOS). auth.md — One week later: who's shipped, who's writing, what's next — WorkOS (28 May 2026): "Spec-compliant auth.md files appeared on real domains within hours, the launch partners who helped build the demo posted their own takes, and a widening circle of agent and identity tools started converging on the same primitive." (https://workos.com/blog/auth-md-one-week-later) [^ref-17]: Zack Proser (WorkOS). Lifestyles of the AI-Native: WorkOS at the AI Engineer World's Fair 2026 — WorkOS (7 July 2026): "Michael re-introduced auth.md, an open protocol that lets agents register and authenticate users without sign-up forms, and shares what early implementers have learned since launch." (https://workos.com/blog/workos-aie-worlds-fair-2026-recap) [^ref-18]: Maria Paktiti (WorkOS). How an MCP client should tell your OAuth server who it is — WorkOS (12 August 2026): "Client identity answers which piece of software is this. User delegation answers on whose authority is it acting, and what may it do. DCR and CIMD only do the first." "And auth.md, the open agent-registration protocol we published in May, went live inside AuthKit as Agent Registration on August 4." (https://workos.com/blog/mcp-client-identity-dcr-cimd-auth-md) [^ref-19]: Fabricio Telles (auth-md.com). AI Agent Registration Protocol for Web — auth-md (independent community hub, checked 29 October 2026): "Protocol authored by WorkOS under MIT License. This is an independent community resource." (https://auth-md.com/) [^ref-20]: Fabricio Telles (auth-md.com). /auth.md on auth-md.com (checked 29 October 2026): "auth-md.com is an independent community resource about the auth.md protocol — the open standard that lets AI agents register for web services on behalf of users." (https://auth-md.com/auth.md) [^ref-21]: Fabricio Telles (auth-md.com). auth.md Protocol Specification — Complete Technical Reference (community technical rendering, June 2026): "CIMD — Claim Interception Mitigation by Design The email field on anonymous /agent/identity/claim binds the registration to the intended human — only that signed-in user can complete the ceremony. Without this, a third party who intercepted the user_code could claim the agent for themselves." (https://auth-md.com/specification/) [^ref-22]: Fabricio Telles. Como construí o auth-md.com em um fim de … | Fabricio Telles (24 May 2026): "A WorkOS lançou o protocolo auth.md e encontrei livre o domínio auth-md.com. Registrei, e no mesmo dia comecei a construir." (https://ft.ia.br/insights/auth-md-como-construi/) [^ref-23]: Fabricio Telles (fabricioctelles/skills). skills/auth-md/SKILL.md (version 2.1, dated 20 September 2026, Apache-2.0): "Generate, validate, and explain auth.md files — the open protocol for AI agent registration." (https://raw.githubusercontent.com/fabricioctelles/skills/main/skills/auth-md/SKILL.md) [^ref-24]: Tuist. https://tuist.dev/auth.md (live auth.md manifest for the Tuist MCP server, checked 29 October 2026): "Tuist implements the current WorkOS auth.md protocol for the Model Context Protocol server at https://tuist.dev/mcp. Follow the discovered endpoints and the sequence below. Registration returns a signed identity assertion, not an access token. Exchange that assertion at the discovered token endpoint before calling the Model Context Protocol server." (https://tuist.dev/auth.md) [^ref-25]: Tuist. /.well-known/oauth-authorization-server (live RFC 8414 metadata with agent_auth v0.6.0 block, checked 29 October 2026): ""identity_endpoint":"https://tuist.dev/agent/identity","identity_types_supported":["anonymous","identity_assertion","service_auth"]" (https://tuist.dev/.well-known/oauth-authorization-server) [^ref-26]: Tuist. Sign agents in with auth.md (Tuist Changelog, 27 May 2026): "Tuist now supports auth.md, the open agent registration specification. Agents that implement the standard can connect to the Tuist MCP server directly: depending on the agent, Tuist either confirms the registration with the agent provider, or emails you a secure link with a six-digit code to read back to the agent. No browser-based OAuth round-trip required." (https://tuist.dev/changelog/2026.05.27-auth-md) [^ref-27]: Firecrawl. https://www.firecrawl.dev/auth.md (live auth.md manifest for WorkOS ID-JAG registration, checked 29 October 2026): "You are an agent. Firecrawl supports agentic registration for WorkOS ID-JAG identity assertions: discover -> register -> call API. Follow the steps in order; do not skip ahead. Firecrawl currently supports one registration method: - identity_assertion with assertion_type: "urn:ietf:params:oauth:token-type:id-jag" - requested_credential_type: "api_key" - Credentials are Firecrawl API keys used as bearer tokens." (https://www.firecrawl.dev/auth.md) [^ref-28]: Firecrawl. /.well-known/oauth-authorization-server (live RFC 8414 metadata with agent_auth block, checked 29 October 2026): ""agent_auth":{"skill":"https://www.firecrawl.dev/auth.md","register_uri":"https://www.firecrawl.dev/agent/auth","revocation_uri":"https://www.firecrawl.dev/agent/auth/revoke","identity_types_supported":["identity_assertion"],"identity_assertion":{"assertion_types_supported":["urn:ietf:params:oauth:token-type:id-jag"],"credential_types_supported":["api_key"]}" (https://www.firecrawl.dev/.well-known/oauth-authorization-server) [^ref-29]: Alpic. https://alpic.ai/auth.md (live auth.md manifest for MCP server deployment, checked 29 October 2026): "Alpic supports agentic registration. If you are an AI agent acting on behalf of a user, you can obtain an Alpic API key without a human filling in a sign-up form, then use it to deploy and manage MCP servers (e.g. alpic deploy)." (https://alpic.ai/auth.md) [^ref-30]: Alpic. https://api.alpic.ai/.well-known/oauth-authorization-server (live agent_auth metadata, checked 29 October 2026): ""agent_auth":{"skill":"https://alpic.ai/auth.md","register_uri":"https://api.alpic.ai/agent/auth","identity_types_supported":["identity_assertion"],"identity_assertion":{"assertion_types_supported":["urn:ietf:params:oauth:token-type:id-jag","urn:ietf:params:oauth:token-type:jwt"],"credential_types_supported":["api_key"]}}}" (https://api.alpic.ai/.well-known/oauth-authorization-server) [^ref-31]: agents-txt.com. https://agents-txt.com/auth.md (live auth.md walkthrough advertised under Authorization: auth-md, checked 29 October 2026): "This deployment hosts the agents.txt reference site. The agentic-registration walkthrough below is a working example of the auth.md shape advertised in /agents.txt under Authorization: auth-md. The OAuth metadata pair (/.well-known/oauth-protected-resource + /.well-known/oauth-authorization-server) is the same one used by the oauth2 protocol on this site; the additional agent_auth block on the AS metadata is what activates this flow." (https://agents-txt.com/auth.md) [^ref-32]: agents-txt.com. /.well-known/oauth-authorization-server (live agent_auth metadata, checked 29 October 2026): ""agent_auth":{"skill":"https://agents-txt.com/auth.md","register_uri":"https://agents-txt.com/agent/auth","claim_uri":"https://agents-txt.com/agent/auth/claim","revocation_uri":"https://agents-txt.com/agent/auth/revoke","identity_types_supported":["anonymous","identity_assertion"]" (https://agents-txt.com/.well-known/oauth-authorization-server) [^ref-33]: mailbox.bot. https://mailbox.bot/auth.md (live auth.md manifest for physical postal mail API, checked 29 October 2026): "This document describes agent registration for mailbox.bot, a live physical postal mail API at https://mailbox.bot. Protected REST resources live under https://mailbox.bot/api and agent registration lives on the same authorization server. Registration is intentionally guarded: agents can discover the service and request a human-approved claim by email, but live order placement spends prepaid mailbox.bot credits owned by the human operator and requires human-owned onboarding and scoped credentials." (https://mailbox.bot/auth.md) [^ref-34]: mailbox.bot. /.well-known/oauth-authorization-server (live agent_auth metadata with user_claimed_email_required flow, checked 29 October 2026): ""current_flow":"user_claimed_email_required","identity_types_supported":["identity_assertion"],"anonymous":{"enabled":false,"reason":"Anonymous registration is not enabled because mailbox.bot can place physical mail orders and spend prepaid operator credits."}" (https://mailbox.bot/.well-known/oauth-authorization-server) [^ref-35]: WorkOS. https://workos.com/auth.md (live auth.md manifest for WorkOS one-shot environments, checked 29 October 2026): "This document tells you how to register a credential for WorkOS one-shot environments — temporary, anonymous WorkOS environments you can provision without an account and (optionally) have the user claim later to make permanent. Follow the steps in order; do not skip ahead. This is the user claimed flow: provision anonymously, work immediately, claim when the user is available. There is no agent-verified or email-verified registration today." (https://workos.com/auth.md) [^ref-36]: PostHog. https://us.posthog.com/auth.md (live auth.md manifest, checked 29 October 2026): "Available on the Enterprise plan with XAA enabled, and currently in beta, so most clients should use one of the options above. With it configured, an agent presents an ID-JAG identity assertion (identity_assertion) to the token endpoint using the JWT-bearer grant" (https://us.posthog.com/auth.md) [^ref-37]: PostHog. Agent discovery (auth.md) - Docs - PostHog (documentation, checked 29 October 2026): "PostHog publishes machine-readable metadata so AI agents can discover how to authenticate and create accounts, with no PostHog-specific SDK and no hardcoded endpoints." (https://posthog.com/docs/settings/agent-discovery) [^ref-38]: here.now. https://here.now/auth.md (live auth.md manifest for email-code API key provisioning, checked 29 October 2026): "here.now supports agent-assisted API key creation with an email code. It does not currently support agent-verified ID-JAG registration, OAuth client registration, MCP auth, or third-party identity provider assertions." (https://here.now/auth.md) [^ref-39]: HeadlessDomains. https://headlessdomains.com/auth.md (live auth.md manifest, checked 29 October 2026): "HeadlessDomains supports agent-native authentication for autonomous domain registration, renewal, profile updates, and DNS-linked identity operations." (https://headlessdomains.com/auth.md) [^ref-40]: NanoGPT. https://nano-gpt.com/auth.md (live auth.md manifest, checked 29 October 2026): "NanoGPT supports agent and app access through user-approved API keys. OAuth-aware clients should use authorization-code + PKCE. Agents can also use the browser-approved device login flow for CLI-style handoff." (https://nano-gpt.com/auth.md) [^ref-41]: WebClaw. https://webclaw.io/auth.md (live auth.md manifest, checked 29 October 2026): "webclaw supports OAuth 2.0 Device Authorization for agent onboarding. Agents can request a short-lived scoped bearer token, show the user a code, and wait while the user approves the request in the browser." (https://webclaw.io/auth.md) [^ref-42]: Particle Pro. https://api.particle.pro/auth.md (live auth.md manifest, checked 29 October 2026): "There is no anonymous agent self-registration: every credential is tied to a human-owned platform account (the API is paid). The fastest path for a fully headless agent is to ask your operator for an API key from https://platform.particle.pro/tokens. An agent with no operator at all can still call the API by paying per request with x402" (https://api.particle.pro/auth.md) [^ref-43]: Cloudflare. https://www.cloudflare.com/auth.md (live /auth.md guidance file, checked 29 October 2026): "Cloudflare is working toward auth.md registration support, including the ID-JAG identity_assertion flow. This file exists at https://cloudflare.com/auth.md so agents can discover what is coming soon and use supported Cloudflare authentication paths safely today. ## auth.md Registration Cloudflare does not yet advertise production auth.md registration methods, auth.md Protected Resource Metadata, or agent-auth metadata. Do not mint ID-JAGs or attempt identity_assertion, service_auth, or anonymous auth.md registration against Cloudflare until this file links to production discovery metadata." (https://www.cloudflare.com/auth.md) [^ref-44]: Resend. https://resend.com/auth.md (live /auth.md guidance file, checked 29 October 2026): "Resend does not support agentic registration today. Credentials are issued by the user out of band; this file tells you how to pick them up and use them without putting them at risk." (https://resend.com/auth.md) [^ref-45]: Ora. https://ora.ai/auth.md (live /auth.md guidance file, checked 29 October 2026): "This file lives at /auth.md, the conventional discovery path from the WorkOS auth.md spec (https://github.com/workos/auth.md). Ora does not implement that spec's registration machinery; this file documents what ora implements and what it deliberately does not." (https://ora.ai/auth.md) [^ref-46]: PAX AI (ax-platform/ax-platform-mcp). README.md (Hermes and shell-agent onboarding via auth.md, checked 29 October 2026): "Give a Hermes agent, or the next serious shell-capable agent harness, https://paxai.app/auth.md; it can learn the device-code flow, show you the approval code, store refreshable credentials, and join the aX network on a named MCP route." (https://raw.githubusercontent.com/ax-platform/ax-platform-mcp/main/README.md) [^ref-47]: PAX AI. Implementing auth.md for MCP agents: field notes from a live platform — aX blog (10 June 2026): "We shipped an auth.md instruction file to solve the first half of that problem — how an agent finds out how to connect —" (https://paxai.app/blog/implementing-auth-md-for-mcp-agents/) [^ref-48]: Storewalk. TRX-009 auth.md agent registration guide published — Storewalk (check documentation, checked 29 October 2026): "We check that /auth.md exists, is a Markdown document rather than your storefront page, and opens with a heading that names auth.md." (https://storewalk.ai/checks/TRX-009) [^ref-49]: AgentReady. Auth documentation — check | AgentReady (usability.auth-docs methodology, checked 29 October 2026): "Looked for /auth.md or an authentication docs page with code examples." (https://agentready-rho.vercel.app/methodology/usability.auth-docs) [^ref-50]: ACT Specification (actcore/act-spec). spec/ACT-AUTH.md (ACT Authentication, normative v0.4.0, checked 29 October 2026): "This document specifies how authentication is handled in ACT. It covers two independent layers: 1. Component-to-external auth — credentials a component uses to authenticate with external services (databases, APIs). Normative; primary subject of this document. 2. Client-to-host auth — how a client (agent, CLI, browser) authenticates to the ACT host. Normative for HTTP transports; informative for stdio." (https://raw.githubusercontent.com/actcore/act-spec/main/spec/ACT-AUTH.md) [^ref-51]: GitHub REST API. better-auth/agent-auth-protocol repository metadata (checked 29 October 2026): ""full_name": "better-auth/agent-auth-protocol"" (https://api.github.com/repos/better-auth/agent-auth-protocol) [^ref-52]: Michael B. Jones, Phil Hunt, and Aaron Parecki. RFC 9728: OAuth 2.0 Protected Resource Metadata (IETF Standards Track, April 2025): "This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource." (https://www.rfc-editor.org/rfc/rfc9728.html) [^ref-53]: Michael B. Jones, Nat Sakimura, and John Bradley. RFC 8414: OAuth 2.0 Authorization Server Metadata (IETF Standards Track, June 2018): "This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities." (https://www.rfc-editor.org/rfc/rfc8414.html) [^ref-54]: William Denniss, John Bradley, Michael B. Jones, and Hannes Tschofenig. RFC 8628: OAuth 2.0 Device Authorization Grant (IETF Standards Track, August 2019): "The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical." (https://www.rfc-editor.org/rfc/rfc8628.html) [^ref-55]: Justin Richer, Michael B. Jones, John Bradley, Maciej Machulak, and Phil Hunt. RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol (IETF Standards Track, July 2015): "This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers." (https://www.rfc-editor.org/rfc/rfc7591.html) [^ref-56]: Aaron Parecki, Karl McGuinness, and Brian Campbell. Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant-04, IETF OAuth Working Group Internet-Draft, 21 May 2026): "This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA)." (https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html) [^ref-57]: Aaron Parecki and Emelia Smith. OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document-02, IETF OAuth Working Group Internet-Draft, 6 July 2026): "This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration." (https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html) [^ref-58]: Sid Chatterjee, Celso Martinho, and Brendan Irvine-Broque (Cloudflare). Temporary Cloudflare Accounts for AI agents | Cloudflare Blog (19 June 2026): "Last month, we collaborated with WorkOS on the launch of auth.md, which anyone can adopt, to let agents provision new accounts using well-established, existing OAuth standards." (https://blog.cloudflare.com/temporary-accounts/) [^ref-59]: John Gruber. Daring Fireball: WorkOS Launches Auth.md -- an Open Protocol for Agent Registration (15 June 2026): "By exposing a single, machine-readable Markdown file at your service root, AI agents can dynamically discover your OAuth Protected Resource Metadata, parse required scopes, and authenticate seamlessly." (https://daringfireball.net/linked/2026/06/15/workos-authmd) [^ref-60]: Martyn Davies (Zuplo). How auth.md Standardises Agent Signup - Zuplo (28 May 2026): "auth.md, a new open protocol shaped by the folks at WorkOS, attempts to start the process of removing that wall. It's a Markdown file an app hosts at its domain walking an agent through registering for a credential, claiming it against a real user, and using it against the API." (https://zuplo.com/blog/auth-md-agent-signup) [^ref-61]: Uchi Uchibeke. auth.md Solves Agent Registration. What About Authorization? | Uchi Uchibeke (30 August 2026): "auth.md solves agent registration (who gets credentials), not runtime authorization (what each action is allowed to do)" (https://uchibeke.com/auth-md-solves-agent-registration-what-about-authorization/) [^ref-62]: Thiago Victorino. auth.md and the OAuth Lineage Move for Agent Registration | Victorino Group (28 May 2026): "A service drops a Markdown file at service.com/auth.md, exposes two well-known endpoints, and any compliant agent can discover how to register, get credentials, and revoke them." (https://victorinollc.com/thinking/workos-auth-md-open-agent-registration) [^ref-63]: GitHub REST API. workos/auth.md Pull Request #20 (agent-services: Preserve login_hint when re-minting id_jag claim): ""number": 20, "state": "closed", "locked": false, "title": "agent-services: Preserve login_hint when re-minting id_jag claim", "user": { "login": "devin-ai-integration[bot]"," (https://api.github.com/repos/workos/auth.md/pulls/20) [^ref-64]: GitHub REST API. workos/auth.md Pull Request #21 (Revoke registration and delegation on provider SET, merged 23 July 2026): ""number": 21, "state": "closed", "locked": false, "title": "Revoke registration and delegation on provider SET", "user": { "login": "devin-ai-integration[bot]"," (https://api.github.com/repos/workos/auth.md/pulls/21) [^ref-65]: GitHub REST API. workos/auth.md Issue #24 (Conformance report from a second implementation (id.org.ai) by nathanclevenger): ""number": 24," ""title": "Conformance report from a second implementation (id.org.ai): two stale bits in the spec, and a question about trust-list discovery"," ""login": "nathanclevenger"," (https://api.github.com/repos/workos/auth.md/issues/24)