WorkOS ने इस हफ़्ते auth.md drop किया — एक open spec plus एक concrete file artifact, उस problem के लिए जिसे लगभग हर agent shop हाथ से बना रहा था: एक agent कैसे साबित करे कि वो user X की तरफ़ से act कर रहा है, credentials user-scoped, revocable, और environment variables में बैठी raw API key नहीं। Shape: एक छोटी Markdown file जो application अपने service root पर publish करता है (human developers के लिए documentation और runtime artifact दोनों जो agents programmatically पढ़ सकते हैं), plus OAuth 2.0 metadata extensions। जो agents production में deploy कर रहे हैं जिन्हें user की तरफ़ से third-party APIs call करनी हैं, यह उनके लिए सही problem को address करने वाली spec है।
Discovery दो-hops का metadata chain है। Agent `/.well-known/oauth-protected-resource` (Protected Resource Metadata) hit करता है authorization server खोजने के लिए, फिर `/.well-known/oauth-authorization-server` fetch करता है जिसमें एक नया `agent_auth` block है चार URIs के साथ: `register_uri`, `claim_uri`, `revocation_uri`, और `identity_types_supported`। नया grant type ID-JAG (Identity-scoped JSON Authorization Grant) per RFC 9728 है — agent identity providers signed JWTs से user identity attest करते हैं, authorization server assertion validate करता है, scoped credentials return करता है। Protected endpoint पर 401 response में `WWW-Authenticate: Bearer resource_metadata="..."` होता है ताकि agent को discovery chain में बिना prior configuration के bootstrap किया जा सके। OpenAI, Anthropic और Cursor potential identity providers के तौर पर cited हैं; spec कोई single vendor नहीं माँगती।
RFC 7591 Dynamic Client Registration से distinction matter करता है और spec इस पर explicit है। RFC 7591 एक client को authorization server के साथ register करने देता है — useful, पर client *अपने आप के तौर पर* authenticate करता है। auth.md अलग problem solve करता है: agent *user के तौर पर* authenticate करता है, user की तरफ़ से, authorization server इस distinction को समझता है और user-scoped revocable credentials issue करता है। यह agent-loop world के लिए सही primitive है: एक agent जो `send_email` call करता है उसे user की email permissions के साथ act करना चाहिए, global "मैं agent service हूँ" permissions के साथ नहीं, और user को उस specific agent का access revoke कर पाना चाहिए अपने credentials rotate किए बिना। आज ज़्यादातर agent products या तो user से raw API keys paste करवाते हैं (insecure, per-agent unrevocable) या सब कुछ agent vendor के अपने auth से run करते हैं (lock-in)। auth.md standardised middle है।
Monday सुबह: अगर तुम कोई agent ship कर रहे हो जो users की तरफ़ से third-party APIs call करता है, github.com/workos/auth.md पर spec पढ़ो और check करो कि तुम्हारा auth provider (Auth0, Okta, custom) ID-JAG support की तरफ़ roadmap रखता है या नहीं। Honest gap implementation status है — सिर्फ़ early access, widespread production servers नहीं, और article note करता है कि MCP servers या bare LLM API calls इस stage पर typically agent-verified flow में participate नहीं कर सकते। Existing OAuth libraries के साथ compatibility release में explicitly address नहीं की गई; rough edges की उम्मीद रखो। पर architectural call sound है: यह उसी problem का user-side है जो AWS MCP Server का IAM-OAuth bridge resource side पर solve करता है, और agent-infra stack को दोनों चाहिए। WorkOS spec पर early है; सवाल है कि OpenAI, Anthropic और cloud providers महीनों में interop ship करते हैं या quarters में।