SSO support, multiregion support, comparison to related RFCs

[samuelcolvin]

I was really excited when I saw this announcement, but now I'm wondering how credible and thought through it is?

There's no reference anywhere in the docs to:

• SSO integrations - signing with github, google etc.
• Multi-region platforms and how to support it - many applications support multiple regions (US/EU) - how is this handled?
• Existing open standards/specs in this space which I think could have covered most of what you propose
  • RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol
  • RFC 8628 - OAuth 2.0 Device Authorization Grant
  • RFC 6749 - The OAuth 2.0 Authorization Framework

You say you've partner with firecrawl and cloudflare on this, but:

• firecrawl.dev/auth.md is a messy html page with the wrong content-type, apparently nothing to do with auth.md
• cloudflare.com/auth.md is a markdown file, but has nothing to do with auth.md - it's an auto-generated markdown summary of /auth

I get that this issues is reads like "three issues in a trenchcoat" or plain criticism, but my high level question is about whether I should really build on this idea?

I'd love to hear a ballpark guess of how many of the words in this repo were written (or even reviewed) by a human.

[p5hzehxa]

Duplicate of #

[samuelcolvin]

Duplicate of #

Duplicate of ...? This is issue #1.

[m0tzy]

Hey Samuel, thanks for the feedback! We are trying to both stitch existing standards together and make it easier for agents to follow by adding breadcrumbs.

We can make it clearer in the repo, but the "display OTP" step can be gated by your existing auth strategies if you don't support magic link and want to put SSO in front of it. That's our plan for AuthKit — it also avoids introducing SSO bypass.

Can you say more about the multi-region gap? Is the authorization server in your mental model one per region or one entrypoint into a service that does its own region routing? You can include multiple authorization servers in the PRM and encode any region requirements in the auth.md document if the agent needs to decide between different authorization servers.

We're using RFC 7591 for the client_id field for agent providers in the ID-JAGs. Are there other applications of it you were expecting to see?

We looked a lot at RFC 8628, and it is a great option for agent contexts that have a user + browser, but it doesn't work as well for headless agents operating on a different machine who can receive text input from the user but can't sign in on their behalf in a browser (i.e. because they'd get blocked for automating this). You could return the device auth link, but that doesn't notify the user that action is required unless they have set up the harness to do this.

Can you say more about how you'd like to see RFC 6749 adopted here? Karl McGuiness had potentially similar feedback about splitting the "identity + credentials" endpoint into one for identity and one for the credential, and it's good feedback — it also paves the path for adopting task-specific or more granular access tokens.

Cloudflare and Firecrawl partnered with us to demonstrate the ID-JAG flow at our MCP Night on Thursday, and we're working with them to productionalize it. They aren't hosting auth.md files right now because what they've built is not yet generalized to public users. We wanted to get people excited about ID-JAG to incentivize agent providers to build support for it! Some other folks, like Resend, are adopting /auth.md as the discovery mechanism.

In terms of whether you should build on this: if you are willing to be on the bleeding edge and give us feedback about how it goes! We've gotten a lot of great responses to this, want to make some changes / add clarification, and have some early design partners who are willing to try it out and iterate on it with us.

[helmut-hoffer-von-ankershoffen]

It's awesome to tale a stab at headless agentic registration - definitely exciting!

Which agents support this already or will support it soon?

You mention "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"

Is any of those mentioned onboard?