Sentiqra Receipt Verifier — receipt spec v3, RFC 8785 (JCS)

Fully offline: everything runs in this page. Paste an analysis response (or just a receipt), optionally add key material to verify the input commitment. Nothing is transmitted — so this page reports signature math and separately the key status from the last trust document you fetched; it can never claim to have checked for a compromise notice it has not seen. v3 receipts (ic3_) verify with either your API credential or its derived bk_ binding key — you can revoke the credential and keep only the binding key.

1 · Analysis response or receipt (JSON)

2 · Input commitment (optional)

Derive your binding key (optional — for your vault)

A binding key verifies receipt input commitments but cannot authenticate API requests. Derive it here — HKDF-SHA256, no salt, info sentiqra/input-binding/v3 — and store the bk_ value in your vault instead of keeping an old API credential.

3 · Trust anchors (optional — for key-status knowledge)

Paste the JSON document from GET /v1/verify/public-key — fetched by you from the service's own HTTPS origin; record when you fetched it. That document is the trust anchor: a receipt may say which key_id claims its signature, but it can never introduce a key this page will trust. The document reflects key status at the moment you fetched it — a compromise notice published after that moment is invisible to this page, and the result below says so rather than claiming freshness.

or · Debug key (untrusted — math only)

A manually entered key proves signature math only — it is never a trust anchor, and this page labels the result accordingly. Defaults to the embedded dev/test-vector key.