Read it multiple times, its definitely useful, centralizes the audit and access in one place (with IDP). The IDP can very well act as a proxy API gateway taking care of token exchange when required instead of putting the onus on Client. Thats another approach which has been adopted by some other players in this domain.
On a personal level, what I felt bit uncomfortable with is this idea of access being delegated on my behalf by IDP to client without making me aware about it. May be I am too used to the concept of user presence in the flows that happens on browser. This it evolving more towards centralizing the access for the machines.
Given in the enterprise environment the identity really belongs to the company instead of individual, its probably acceptable.
How its gets incorporated in customer identity is altogether a different challenge. Its probably not possible to have this kind of trust between IDP, client and the resource authorization server.
There's theoretically nothing really stopping this integration from working in the consumer space - you just need to establish a trust relationship (e.g., if I am logged in with GitHub, also log me in to Sentry automatically). There is more work ahead here, but as you said - the most obvious _current_ use-case is enterprises, where admins do not want individual employees clicking around picking random credentials they have.
At the end of the day its wiring the flows to serve a purpose and can be wired in multiple ways. Some combination of client, IDP and resource server can come together to form a band and may provide this for consumer identity.
Reasons why this is a bad idea for consumer identity -
1. In Enterprise, the IDP is the single owner for the identity, so it essentially can do represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity)
2. In enterprise the IDP is the single authentication factor used by the downstream resource server (application), in other words the application just trusts the assertion
3. For consumer identity, the resource server owns the identity/user explicitly. Github may be one of the authentication factors that the user can use, but it may not be the only one.
4. For consumer identity, Github cannot delete the user account in downstream application.
Regardless, this protocol is going to create friction in adoption of new AI agents and MCP servers, to sell to enterprise they have to implement this and integrate with existing IDP's and resource servers. Using any new MCP server would require full evaluation lifecycle from security perspective. Its a good thing but its going to hurt the new players pretty bad in terms of adoption and discovery.