Oh crap I just realized the "it" he was referring to was probably the food, not his critical thinking.

Not that this is a 1:1 replacement, but it is one of the reasons I built Meetable.org, so communities can create their own calendars on their own domains.

🔐 Enterprise-Managed Authorization extension (aka Cross App Access) - eliminate the OAuth redirect and get tokens for an MCP server by requesting them from the enterprise IdP

Read more about what these mean for you in my full post
👉 aaronparecki.com/2025/11/25/1...

I don't know anything about the protocol but if they support the same OAuth spec as ATProto and same user ID discovery it would work

even with all the emoji? lol

👍👍

The dots that Solid OIDC connected were to specifically use the RFC7591 vocabulary in a JSON doc at the client ID URL, whereas IndieAuth originally parsed the metadata from HTML, and OpenID Federation nests the metadata inside an "Entity Statement" JSON wrapper.

I mean it was a big mix of things really. Most recently the JSON document idea came from there, but "client IDs as URLs" has been part of IndieAuth since 2015 web.archive.org/web/20150315... and OpenID Federation since 2016 openid.net/specs/openid...

Yeah I definitely went hard mode by writing everything from scratch (except the JWT signing). Partly because I wanted to see what it actually takes to implement a library, partly because I can't stand the current state of most language's package management 😅

The folks at Stytch put together a really nice explainer website about it too! cimd.dev

This could replace Dynamic Client Registration in MCP, dramatically simplifying management of clients, as well as enabling servers to limit access to specific clients if they want.

The recent surge in interest in MCP has further demonstrated the need for this to be a standardized mechanism, and was the main driver in the latest round of discussion for the document!

The mechanism of clients identifying themselves as a URL has been in use in IndieAuth for over a decade, and more recently has been adopted by BlueSky for their OAuth API.

Clients identify themselves with their own URL, and host their metadata (name, logo, redirect URL) in a JSON document at that URL. They then use that URL as the client_id to introduce themselves to an authorization server for the first time.

Yes, I helped them with it. They also use the client-id-url technique that came from IndieAuth

Thanks to everyone for your contributions and feedback so far!

And thanks to my co-authors Karl McGuinness and Brian Campbell!

While it will still be a while before it is an RFC, this is an important step in the standards process, as this is the first time the document is "official"! This signifies that the working group agrees that the problem is worth solving, and agrees on the general direction of the spec.