-
Notifications
You must be signed in to change notification settings - Fork 382
Description
Is your feature request related to a problem? Please describe.
From what I can tell, there are 3 auth mechanisms supported by the community instance today:
- GitHub -> for only
io.github.<name>/*
names - DNS based key pair for arbitrary DNS names.
- HTTP based key pair for arbitrary DNS names.
It would be awesome if the community instance supported more OIDC identity providers for DNS based names.
Describe the solution you'd like
This could come in the form of Trusted Publishing which is supported on other community registries like npm, PyPI, RubyGems, and NuGet.org.
To prove ownership of the DNS name, a pointer or identifier could be included in the TXT record referring to a trust policy entity.
For example, you could create a "trust policy" entity on the MCP registry with a new CRUD API expressing that GitHub repo X, owner Y, and branch Z is acceptable. This trust policy would yield a UUID that is put in the TXT record.
The trust policy entity could be of any number of types:
- GitHub Actions repo scoping (somewhat redundant with GH auth, but could provide more secure scoping)
- BitBucket repo scoping
- Entra ID service principal
- Arbitrary OIDC issuer and sub claim
Describe alternatives you've considered
Just use the DNS key pair. Unfortunately this is hard for my team since it cannot integrate with an HSM or other security key storage mechanism, per #482.
Additional context
Trusted Publishing is well adopted in the broader package management ecosystem and I think it has a place on the community MCP registry.
The main challenge is that there is no publisher profile entity to "hold" the trust policy.
Thank you to @Novaes for the great conversation internally, comparing npm package publishing to MCP Registry publishing!