You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
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).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
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)
_metaform that needs no schema change to pilot.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 checkfetches 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 anagent-capability/v1in-toto DSSE predicate, verified end to end withcosignincluding Rekor inclusion on two shipping MCP servers (better-call-claude@3.1.3,dear-claude@1.1.2).Full RFC, targeted at
server.jsonschema2025-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.
All reactions