I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.
"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent.
The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.
How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards.
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.