Receiz / Security

Security model for deterministic verification.

This page defines the technical security posture for Receiz: what is authoritative, what verification proves, what it does not prove, and where independent auditors can validate behavior.

Record, Seal, and Verify are all offline-capable. Account access is optional and not required for core verification operations.

The file verifies itself. Verify links (/v) are optional public convenience for that same file.

File-first authorityDeterministic verificationPublic verificationOffline-capable reference verifierRecord/Seal/Verify offline operationVersioned standards + test vectorsIncident transparency

Trust Center Status Offline Verifier

Security boundary

What verification proves and what it does not

Verification proves record integrity. It does not prove external truth, intent, or identity unless signer evidence is attached.

Operator rule

Treat Receiz verification as integrity evidence for artifacts. Evaluate legal, policy, intent, and domain-specific truth using your own institutional controls.

Trusted verdict profile

Hard requirements for trusted verification

Trusted verification is fail-closed. All gates below must pass for a trusted verdict.

1. Artifact binding must match

User meaning: Only the original sealed file verifies.

Technical requirement: artifactSha256Basis must be present and match the exact artifact bytes under verification.

2. Trusted signature must verify

User meaning: Missing or unverifiable signatures are rejected.

Technical requirement: A trusted Receiz signature v4 is required and must pass payload-hash, key-policy, and cryptographic verification checks.

3. Groth16 proof must be real g16

User meaning: Legacy/placeholder proof formats are rejected.

Technical requirement: groth16Proof must be a decoded g16 envelope with digest match and valid Groth16 verification result.

4. Anchor must be present and coherent

User meaning: Record context must resolve to the same code/pulse identity.

Technical requirement: Anchor payload is required and must match proof-bundle code, pulse, and anchor identity fields.

Machine-readable contract: /standards/receiz.trusted-profile.v1.json

Control matrix

Security controls by domain

Controls are stated in implementation terms and mapped to independent validation paths.

Artifact integrity

Canonical byte-level verification

Verification decisions are computed from original file bytes and embedded proof material, not screenshots or render-only copies.

Validate: Use /verify or the offline verifier and compare deterministic outcomes.

Verification runtime

Reference parity

Offline verifier is the reference runtime. Online verification routes mirror the same decision model for convenience and automation.

Validate: Run the same artifact through online and offline paths for convergence checks.

Signer evidence

Passkey-backed ceremonies

When signer evidence is attached, WebAuthn ceremonies are bound to expected origin and RP-ID values.

Validate: Audit canonical realm values and passkey challenge behavior in standards/trust routes.

Key posture

Published signer key identity

Signer key identity is derived and published as a key ID for auditability of signing posture across trust surfaces.

Validate: Cross-check key ID on trust/security surfaces.

Contract stability

Versioned schemas and deterministic error contracts

Public standards files define canonical payloads, envelopes, and deterministic failure classes for independent runtimes.

Validate: Validate against /standards schemas and test vectors.

Network boundary

Scoped proxy-header trust

Client-IP forwarding headers are trusted only when ingress conditions are explicit (mode/allowlist or recognized edge signals). Untrusted header values are ignored.

Validate: Confirm spoofed forwarded headers are ignored outside trusted edge paths.

Administrative control plane

Service-token-first admin auth

Privileged admin actions require scoped bearer service tokens by default. Legacy admin-key mode is compatibility-only and explicitly gated.

Validate: Confirm admin requests fail without scoped bearer tokens and are rate-limited and logged.

Passkey anti-clone controls

Durable sign-count enforcement

Passkey assertions enforce monotonic sign-count progression with durable storage and clone-detection markers.

Validate: Confirm passkey clone/regression attempts are blocked and surfaced as deterministic security failures.

Reliability transparency

Public status + incident publication

Route-level health and incident state are published on the status surface.

Validate: Review live and historical status data on /status.

Published values

Technical values for independent checks

Signer key ID

de26d7eb2fb3

Current signer key identity published for trust-surface audit checks.

Canonical origin

https://receiz.com

Expected origin for passkey-bound signing ceremonies.

RP-ID

receiz.com

Relying-party identifier for WebAuthn ceremonies.

Published at

2026-03-07T08:39:43.522Z

Generated timestamp for this security surface.

Receiz Signature (v4)

Bundle signature procedure and verification policy

Signature v4 is the bundle-level signature model for Receiz proof bundles. Verification signs canonical payloads, binds signatures to payload hashes, and enforces key lifecycle policy against sealed pulse identity.

Deterministic bindings

versionalgcertsigpayloadHashSha256signedAtMs

Verification recomputes the canonical payload hash from the bundle (excluding the signature payload) and requires an exact match with payloadHashSha256 before signature verification.

Key policy checks

Verification decisions are anchored to sealed pulse identity.
Published key lifecycle policy controls when a key is valid to verify.
Pre-activation bundles fail deterministically.
Post-retirement or unavailable-key bundles fail trusted verification.

Verifier outcomes

verified

Signature, payload hash, key policy, and cryptographic verification all pass.

invalid

Hard verification error. Used for malformed payloads, hash mismatch, algorithm mismatch, pulse policy failures, or signature failure.

missing

Hard verification error in trusted mode. Bundle has no trusted signature v4 payload.

unavailable

Hard verification error in trusted mode. Required trust metadata (root keys or cert-chain material) is unavailable, retired, or incomplete for this bundle pulse.

Upgrade procedure

Legacy artifacts without signatureV4 can be upgraded in-place for supported carriers when exactly one proof bundle is detected and signing configuration is available. Trusted verification requires the upgraded artifact.

PNG proof chunkPDF embedded proof bundleTrailer carrier (media/binary)receiz.bundle.v1 envelopeJSON embedded proofSVG embedded proof

Upgraded download responses may include header: X-Receiz-Signature-V4-Upgraded: 1.
Profile-original download flow re-verifies upgraded artifacts before serving; on verification failure it serves original bytes unchanged.

Disclosure

Vulnerability reporting process

Receiz accepts responsible vulnerability reports and prioritizes fixes based on exploitability and impact.

1. Report

Send a report to support@receiz.com with subject: Security Review. Include impact, affected route(s), reproduction steps, and proof-of-concept details.

2. Triage

Reports are validated and prioritized by severity, exploitability, and user impact. We may request additional artifacts for deterministic reproduction.