Comment by brianmcnulty

Long time no see! It's been a while since I've looked at MCP, but I think this does a really good job at making MCP more secure for organizations and addressing some of the weaknesses of dynamic client registration. Now that clients and approved redirect URIs can be setup directly by the IdP and organization, a lot of the attacks that were possible with DCR (confused deputy, phishing attacks, etc.) can be mitigated more broadly. It also makes it so servers don't have to implement as much authorization logic as they did before if the IdP or organization didn't support DCR, which is a pretty big advantage (especially if they combine MCP auth with existing API auth).

One major downside is consumer usage seems to still need DCR with this. I think this could potentially be addressed by existing consumer OAuth providers (Sign in with GitHub, GitLab, Google, etc.) adding support for registering static MCP clients/servers, clients shipping their static client IDs inside them, clients allowing users to sign in with GitHub/GitLab/whatever IdP, and letting the user self-manage connections on the IdP's site.

Overall, XAA/EMA seems vastly superior to DCR from a security perspective (and also usability too, since users don't have to configure as much!). The concerns I have are also much easier to address and have way less security impact than with DCR, since attackers don't get to register their own clients anymore and there are less pitfalls for MCP server developers.