Portable integrity APIs
CanonicalJson, Event, ChainVerifier, BundleVerifier, CollectionVerifier, ordinary Ed25519, SHA-256 and bounded ZIP/segment revalidation.
Verification / INTERACTIVE WORKSHOP
MyProof Evidence v1.0.0Build and verify bounded evidence
Explore actual canonical JSON, closed events, ordered chains, signed TEST bundles and complete-history collections. Edit bytes and replay mutations to inspect precisely which integrity claim fails.
01 / CONFIGURE
Choose a scenario. Change the inputs or build a sequence of commands.
02 / RUN
Execute the installed package against a new fictional example.
03 / INSPECT
Follow the result, actual calls, generated output and integration code.
THE WORKBENCH
Make it your example.
Your server-side changes are temporary. External-service examples use local response fixtures. Start with sample data.
Start with a preset, or change the input and run it.
The behavior is the example.
Your result will show the values, decisions and generated output from the actual package.
Calls used by this scenario. The handbook explains setup, authorizers, storage and error recovery.
The complete response is shown as data. Wide PHP integers are transported as exact decimal strings. Values are never evaluated as PHP or JavaScript.
Run an example to inspect its response.
The last two successful run states stay in this tab’s memory. Run a changed example to compare the actual package results.
What you can exercise here.
Different claim boundaries
A local valid chain prefix differs from a signed complete bundle. Collection verification returns no partial-prefix success.
Production trust and observations
Independent live trust pins, signing adapters, authorized storage, event head locking, source authentication and factual claims remain external. Public TEST keys prove no real receipt or identity.
DemoSigner public test vector
A published reproducible test seed signs only TEST manifests; the actual DemoSigner rejects live mode. No production identity or trust is created.
UNDERSTAND THE BEHAVIOR
Canonical bytes, a valid chain and signed completeness differ.
Build canonical JSON and closed events, mutate a fixed TEST history, then verify complete bundles and multi-part collections with actual package APIs.
Canonicalization has a strict profile
CanonicalJson orders object keys and produces stable bytes. Duplicate keys, including escaped duplicates, and floating-point values are rejected by this profile. Require original canonical bytes tests the supplied serialization rather than normalizing it silently.
Closed events commit their permitted fields
The event JSON control feeds Event::fromArray and the package schema. Canonical event bytes and their SHA-256 are returned. The event builder does not observe a real delivery or establish that its submitted statements are true.
A chain prefix makes a narrower claim
ChainVerifier can accept a valid ordered prefix. BundleVerifier additionally checks signed manifest commitments and artifacts; dropping an event violates completeness. CollectionVerifier verifies the complete declared collection and refuses missing or changed parts without partial success.
Trust is pinned outside the supplied bundle
The fixture has an independently selected public TEST trust pin. Wrong-pin, signature and byte mutations exercise different rejection paths. DemoSigner uses a deliberately published TEST vector and refuses live mode; it creates no production identity or private signing service.
GO FURTHER
Try the boundary cases.
Canonicalize, then require exact bytes
Run Canonicalize a JSON object. Expected: {"b":2,"a":1} becomes {"a":1,"b":2} with stable SHA-256. Enable require_canonical on the original ordering: it is rejected. Compare escaped duplicate keys and floating-point profile presets for distinct schema refusals.
Construct an allowed event
Run Build a closed event and edit an allowed payload or timestamp. Expected: canonical bytes and event hash change. Add an unknown top-level property using the JSON control: the closed schema rejects it instead of silently committing extra claims.
Prove prefix versus complete history
Run Local chain alone accepts a valid prefix, then Signed bundle refuses that prefix. Expected: the same drop-last mutation can leave a locally valid chain but fails the signed complete bundle. Reverse, duplicate or replace an event to inspect other chain failures.
Separate artifact and trust failures
Run Tampered artifact and Wrong independently pinned key. Expected: each fails verification for its own integrity/trust boundary. Restore defaults rather than accepting a key from the mutated manifest. Manifest bytes and signature hex can be edited explicitly to inspect strict decoding failures.
Verify the whole collection and TEST signer
Run Complete three-part collection, then Missing collection part and Tampered collection ZIP. Expected: only the intact complete collection succeeds. Compare Sign and verify with the public TEST vector with DemoSigner refuses live mode: the test vector works and live signing is refused.
COMPOSE THE RESPONSIBILITIESUseful alone.
Useful alone.
Better when the boundaries fit.
The MyProof Laravel client retrieves service metadata and authorized download destinations. This independent package checks downloaded bundle bytes against a host-pinned key. HTTP success, hash-chain validity and factual truth are separate claims.