Support additional OIDC IdPs on the community MCP registry [Trusted Publishing]

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 https://github.com/modelcontextprotocol/registry/issues/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!

No files or tests are named. Start by reviewing the registry's existing GitHub, DNS-based, and HTTP-based publishing authentication paths, then examine the proposed trust-policy and publisher-profile concepts. Done would mean a decided scope for OIDC provider support, DNS TXT ownership validation, and policy-based publishing.