Repository navigation
DNS-based server name verification #85
Description
Activity
I think there's quite a few open questions here.
As I understand it, the current authentication mechanism for publishing to the MCP registry is to have the user get a GitHub OAuth token, and ensuring the
server.jsonrepository.urlmatches that user. This works for MCP servers you run locally, but not for a remote server?I think this proposal would allow for authorization for MCP servers that run on a remote server (but not locally, because there's no domain the submitter controls for a MCP server intended to run locally). Then you need to figure out a way to provide a challenge (to be set as the DNS TXT record on that domain), what properties that challenge should cover, what to do if multiple submissions use different paths on the same domain, etc.
There's a lot here - I think it might be helpful to write up a threat model, or at least some "happy path" and malicious user examples, and how the DNS flow enables the "happy path" users while preventing attacks from malicious users.
Sorry, I can tell from reading your response that we have not sufficiently documented this. Will take an action to do that better ASAP (#131).
As I understand it, the current authentication mechanism for publishing to the MCP registry is to have the user get a GitHub OAuth token, and ensuring the server.json repository.url matches that user.
This is not the case. The goal of the auth mechanism (+ optional DNS verification) is to facilitate a namespace for the
namefield, in reverse-DNS fashion. So it is unrelated to therepository.urlfield. It may make sense to cut another issue for making sure the repo atrepository.urlwants to be associated with this MCP server entry, similar to #96 forpackages. And maybe another analogous mechanism for the entries inremotes(alluded to here; need to cut another ticket to follow up).Hopefully from that starting point, the downstream considerations make more sense.
We should allow for MCP servers to be published without requiring them to be prefixed with a
io.githubname prefix (which is the default fallback).Work to be done here:
io.githubpublication approach