Design consideration: publisher identity vs. artifact provenance in registry verification

[Gowthaman90]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Hi MCP Registry maintainers,

I'm an independent researcher working on supply-chain security for the Model Context Protocol. I'd like to raise a design consideration about the registry's verification model and hear whether it's on your roadmap.

As I understand the current design (and as documented), the registry verifies a publisher's identity — e.g., via GitHub OIDC and DNS/HTTP challenges — but a record is not bound to a verified artifact digest / provenance attestation. As a result, a record can carry a genuinely-verified publisher identity while the artifact it resolves to is not itself provenance-verified: the "identity verified is not the same as provenance verified" gap. This same concern is raised in the recent literature on trustworthy MCP registries — e.g., Mas, Mateo et al., The Trustworthy MCP Registry (Future Internet 2026), which proposes binding records to Sigstore-backed artifact provenance.

I want to flag this respectfully as a design consideration, not a vulnerability report — the identity-only posture appears intentional and is documented. My questions:

Is provenance binding (e.g., requiring/attesting an artifact digest via Sigstore/SLSA, and binding it into the record) on the registry's roadmap?
Would you welcome input or a concrete proposal on a provenance-over-identity extension?
The natural building blocks are well established — RFC 8615 well-known discovery, Sigstore keyless signing, and a transparency-logged record that binds the artifact digest (and the attestation's subject) to the publisher. I'd be glad to help think through an approach if it's useful.

Thank you for your work on the registry.

Best regards, Gowthaman Arumugam [agowthaman90@gmail.com]
github.com/Gowthaman90

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other