mcp-trust-framework

The provided reference implementation of the MCP Trust Registry is explicitly stated as 'for demonstration and testing' and 'does not implement authentication, cryptographic verification, or persistent storage.' **Critical Vulnerabilities in Reference Implementation (if used in production):** - **Authentication Bypass:** The `POST /mcp/servers` endpoint has no authentication, allowing any unauthenticated client to register, update, or potentially remove registry entries. This is a severe security risk, enabling malicious actors to inject untrusted servers or alter legitimate entries. - **Data Volatility:** It uses in-memory storage (`InMemoryStorage`), meaning all data is lost upon server restart. - **Weak CORS Policy:** Wildcard CORS (`allow_origins=["*"]`) is used, which is typically too permissive for production environments. **Limitations in SDKs:** - The Python and Node.js SDKs explicitly state they 'do not implement full cryptographic verification of Verifiable Credentials.' This is a major limitation for a 'trust framework,' as it means clients cannot cryptographically verify the integrity and authenticity of the credentials received, relying only on structural and simple policy checks. Full VC proof verification is left as a 'production exercise'. While the project includes a `security-considerations.md` outlining best practices, the reference implementation itself currently lacks these critical security controls, making it highly unsuitable for anything beyond isolated local development.