Trust
What this actually proves
A PPCP profile is a person's own maintained account of themselves. That is valuable and it is also limited. The distinctions on this page are the point of the whole proposal.
Four separate things
Licensing, identity matching, transport security and cryptographic provenance are distinct. Conflating them is the most common way trust claims get overstated.
| Layer | Supports | Does not support |
|---|---|---|
| Licensing | Reuse terms for the text. | Say the text is accurate, current or approved in an adaptation. |
| Identity matching | Which records the publisher claims are the same person. | Independently confirm that the person is who they say they are. |
| Transport security | The connection was not tampered with in transit. | Say anything about the content's provenance or truth. |
| Cryptographic provenance | Origin, integrity and declared authorship of a response. | Establish truth, broad authority, or permission to impersonate the subject. |
Signatures are not truth
The reference MCP implementation signs every tool call and resource read with a distinct Ed25519 key for its own origin, using RFC 8785 canonicalization and SHA-256 digests, with authorship and review metadata inside the signed scope, per Verifiable MCP v0.2.1. A valid signature tells you the bytes came from that origin unchanged, and what the origin declares about their authorship. It tells you nothing about whether the claims are correct.
Missing or malformed signing configuration must degrade visibly to unsigned responses rather than take the public corpus offline. A server must not be described as signed before verification actually passes, and a private key must never be published.
What must never be in a public profile
- private source paths;
- account or session tokens;
- family or customer identifiers that were not selected for publication;
- hidden private sections smuggled into the HTML or client bundle.
The subject decides what belongs in the public subset — including how much of family and everyday life to share. Absence is not evidence: a consuming agent should not infer private facts from gaps, and should not treat someone's stated preferences as universal commands.
No conformance claim until it is checked
This draft lists ten release checks, from representation agreement and schema validation through error handling, origin rejection, signature vectors, key degradation and independent domain checks. Until a check has actually run, nothing here claims to pass it. Selected live tool and resource signatures on the reference server were independently verified · 13 September 2026; that is one server, checked on one date, and protocol-wide or client-wide certification is not implied. No untested client compatibility, guaranteed search visibility or Wikimedia acceptance is claimed.
A separate hosting observation belongs here too: this documentation domain sits behind a Cloudflare Browser Integrity Check that, in our check, returned 403 with error code: 1010 for Python-urllib/3.11, while an empty user agent and descriptively named agents were served normally. That block sits at the hosting edge, ahead of this application, no supported Lovable exemption is exposed, and it needs escalation to Lovable support. So neither automatic discovery nor arbitrary-client compatibility is guaranteed.