How should an authorization server decide which MCP CIMD client_ids to trust?

## What the mechanism actually proves When an authorization server accepts a Client ID Metadata Document, it dereferences an HTTPS URL supplied in the authorization request and reads client metadata from it. It is worth being blunt about what that establishes: whoever published the document controls the DNS name and holds a certificate for it. Nothing else. There was no review, no contract, no identity proofing. `client_name` is whatever the publisher typed. That is not a flaw — it is the deal CIMD offers, and it is a good deal, because it makes registration-free onboarding possible for an ecosystem where users add arbitrary remote MCP servers at runtime. But it moves the entire trust decision onto the authorization server, which is why 'which client_ids do I trust' is a policy question rather than a protocol one. ## Show the identifier, not the name The first and cheapest control is presentational. A consent screen that reads 'Well-Known Product would like access to your account' where the name came from an unverified document is actively misleading. Show the `client_id` URL — the domain especially — as the primary identity, with the self-asserted name clearly secondary and labelled as provided by the client. Users are far better at judging a domain than a string. ## Tier your trust, and tier your privilege A single accept/reject decision is too blunt. Most authorization servers end up with tiers: - **Pre-registered / first-party.** Vetted out of band, full scope catalogue, longest token lifetimes. - **Allowlisted CIMD publishers.** Known URL prefixes or hosts you have reviewed, treated close to pre-registered. - **Unknown CIMD clients.** Accepted, but with a reduced scope ceiling, shorter access token lifetimes, refresh tokens withheld or tightly bounded, and prominent warning language at consent. - **Denylisted.** Publishers you have seen abuse, refused outright. The high-privilege scopes are exactly where you should be willing to say 'CIMD is not enough here — come and pre-register'. That is a legitimate policy, and it means adopting CIMD does not force you to expose everything to anyone with a domain. ## Consent must bind to the identifier and survive change Because the metadata is hosted by the client, it is mutable. A publisher can obtain a user's approval with a modest, honest-looking document and rewrite it afterwards. Two habits contain this. First, bind a recorded approval to the specific `client_id` URL, never to a display name, so a name change cannot inherit a grant. Second, record what the document said at approval time and re-prompt when material fields — the redirect URIs above all — change. Caching gives you the snapshot for free; the discipline is comparing rather than blindly refreshing. The corresponding client-side obligation is the mirror image: a materially different client should get a new metadata URL rather than silently reusing an old one. ## The fetch is itself attack surface An authorization server that accepts CIMD is, by design, making outbound HTTP requests to URLs an unauthenticated party chose. Treat that as the server-side request forgery risk it is: require HTTPS, resolve and refuse private and link-local address ranges, cap redirects and refuse cross-scheme ones, cap response size and total time, and enforce a strict content type and parse budget. Add rate limiting per URL and per source, and cache aggressively with a TTL so a burst of authorization requests cannot be turned into a burst of outbound traffic aimed at a victim. None of this is exotic, but it is easy to omit when the fetch is written as a convenience helper inside the authorization path. Availability deserves a thought too: if the document cannot be fetched, the authorization cannot be validated. Caching with a sensible TTL and a bounded stale window keeps a brief outage at the client's host from becoming a login outage for your users — while still bounding how long a revoked or rewritten document keeps working. ## Redirect URIs remain the sharp edge Whatever else the document says, `redirect_uris` is the field that decides where an authorization code goes. Match the requested callback exactly against the list in the document — no prefix matching, no wildcards, no 'same host is fine'. A permissive rule here converts every lax client into a code-exfiltration channel, and the entries came from an unvetted publisher in the first place. ## The judgment to articulate The question has no single right answer, and that is the point. What a senior reviewer wants to hear is a coherent position: CIMD is worth adopting because it removes an onboarding step that does not actually produce security, its assurance is limited to URL control, and the resulting risk is managed by making privilege proportional to what you know about the client rather than by pretending the document was vetted.