Proposal: an attestation-reference field on server.json + verify-on-publish

[sns45]

The registry verifies that a publisher controls a namespace, but a resolved entry does not state, in an attestable form, what a server is or what it can do at runtime. An MCP server can place phone calls, read a filesystem, spawn subprocesses, and reach credentialed endpoints; the entry a client resolves by name states none of this in a form a policy engine can check.

The ask (two parts)

1. An attestation-reference field on registry entries. A locator plus a digest and the predicate type, pointing at a portable, signed attestation of the server's provenance and capability surface. The reference points at the attestation; it does not embed it. There is an interim _meta form that needs no schema change to pilot.
2. Verify-on-publish semantics. When an entry carries an attestation reference, the registry fetches the referenced attestation at publish time, verifies its signature, confirms the attested subject digest binds to the package the entry distributes, and records the outcome. Namespace verification proves who owns the name; verify-on-publish additionally proves the referenced attestation is authentic and bound to the artifact.

Nothing here asks the registry to become a signing authority, to mint keys, or to host attestations. The maker signs once and publishes the attestation where attestations already live (an OCI registry today); the entry carries a reference the registry can check. This composes with existing supply-chain trust infrastructure rather than replacing it.

Working demonstration

smithmark registry check fetches a real registry entry, reports that it carries no attestation-reference field today (because none exists in the schema), and then, given no pointer, falls back to a deterministic OCI reference computed from the package identity to find and verify the capability attestation anyway. That fallback is exactly the interim scheme the proposed field would retire. The referenced attestation is an agent-capability/v1 in-toto DSSE predicate, verified end to end with cosign including Rekor inclusion on two shipping MCP servers (better-call-claude@3.1.3, dear-claude@1.1.2).

Full RFC, targeted at server.json schema 2025-12-11:
https://github.com/sns45/smithmark/blob/v0.2.0/proposals/mcp-registry-provenance/RFC.md

Posting in Ideas per the contribution process; glad to take it to a SEP or a schema-change PR if there is interest.

[vladimirrott]

@sns45 this split feels right to me. One thing I would add from building a privileged server: provenance is attestable at publish time, capability is not.

A sandbox that builds and boots a server will happily list every tool it declares, because tools/list is static metadata. So a green build proves the binary starts and the schemas parse, nothing else. I had this wrong in my own docs until last week.

Which makes me think an attested capability surface only means something when the surface is finite (a server with an exec tool has an unbounded one no matter what the attestation says) and something at runtime refuses anything outside it. Ours is 189 typed actions and a daemon that rejects anything not in its catalogue: https://github.com/lacs-project/sysknife

That is also why I would keep the predicate types separate. Provenance and capability are different claims with very different verification stories.