Hi all, so the work I'd previously started in 2024 was all in the progress of what would eventually become myself and Aaron Parecki defining the Client ID Metadata Documents internet draft, which has since been adopted by the OAuth WG at the IETF, and used in places like AT Protocol, Model Context Protocol (MCP servers), etc.
I don't think this draft could easily be implemented in user-land, but it basically solves the unbounded client proliferation problem of Dynamic Client Registration and the "pre-registration" problem in decentralized ecosystems.
Given we now have the Client Authentication Method Registry (#1772) we can now implement in user-land or in core the private_key_jwt client authentication method, which could be lifted up to core from the existing implementation in doorkeeper-openid which @55728 maintains. That unlocks the ability to do authenticated "more trusted" clients when using CIMDs.
Essentially what the CIMD draft specification is is an ability for a relying party (client) to say to the authorization server (IdP), "hey, here's my metadata for dynamic registration at this URL, if you don't know about me, fetch that document and use that metadata for my registration" — this is a feature that I know @mastodon want for their OAuth implementation, but we've never been able to sort out funding for it.
This is an issue to track CIMDs in doorkeeper, whether implemented in core or in user-land. The other work was essentially preparatory for being able to do this amongst a few other things. (I don't have time to work on this)
Hi all, so the work I'd previously started in 2024 was all in the progress of what would eventually become myself and Aaron Parecki defining the Client ID Metadata Documents internet draft, which has since been adopted by the OAuth WG at the IETF, and used in places like AT Protocol, Model Context Protocol (MCP servers), etc.
I don't think this draft could easily be implemented in user-land, but it basically solves the unbounded client proliferation problem of Dynamic Client Registration and the "pre-registration" problem in decentralized ecosystems.
Given we now have the Client Authentication Method Registry (#1772) we can now implement in user-land or in core the
private_key_jwtclient authentication method, which could be lifted up to core from the existing implementation in doorkeeper-openid which @55728 maintains. That unlocks the ability to do authenticated "more trusted" clients when using CIMDs.Essentially what the CIMD draft specification is is an ability for a relying party (client) to say to the authorization server (IdP), "hey, here's my metadata for dynamic registration at this URL, if you don't know about me, fetch that document and use that metadata for my registration" — this is a feature that I know @mastodon want for their OAuth implementation, but we've never been able to sort out funding for it.
This is an issue to track CIMDs in doorkeeper, whether implemented in core or in user-land. The other work was essentially preparatory for being able to do this amongst a few other things. (I don't have time to work on this)