Evidex Receipt Format (ERF) v1.0

Status: Public (stable)

Date: 2026‑02‑22

Intended audience: implementers, auditors, and security researchers

Short spec: ERF_STANDARD.md

Abstract

The Evidex Receipt Format (ERF) defines a minimal, tamper‑evident structure for sealing and verifying content hashes. It allows anyone to generate a receipt without uploading the underlying file and enables others to verify integrity by checking the signature and optionally comparing a local file hash. ERF is designed to be open and free to implement, with privacy and security as primary goals. This document specifies version 1.0 of the format and outlines the data model, canonicalization rules, verification states, and relevant considerations.

Scope

ERF governs the structure of evidence receipts used by GetEvidex. It covers the data fields included in the receipt, how receipts are signed, and how integrity is verified. ERF does not define or confer any legal admissibility, authorship, intent, or identity of the submitter. It also does not cover anchoring to blockchains or external notarization services; such mechanisms are orthogonal and may be layered on top of ERF. A reality audit should compare the documented format with the actual implementation and highlight any gaps or deviations. Unknown or missing evidence should be explicitly marked as such.

Terminology

The key words MUST, SHOULD, and MAY in this document are to be interpreted as described in RFC 2119. An implementation MUST adhere to required fields and behaviours to be considered compliant with ERF v1.0. If evidence is missing or a field cannot be validated, the status MUST be reported as UNKNOWN with a note indicating the missing evidence.

Data Model

Each ERF receipt is a JSON object containing two top‑level fields:

• payload – REQUIRED. An object holding the receipt data.
• signature – REQUIRED. An object holding signature metadata.

The payload object MUST contain the following fields:

The signature object MUST include:

• alg – MUST be "ed25519" for v1.0.
• key_id – Identifier of the signing key.
• pubkey_b64 – Base64‑encoded public key.
• payload_b64 – Base64‑encoded canonicalized payload.
• sig_b64 – Signature over payload_b64.

Canonicalization & Signing

ERF receipts are signed to detect tampering. The canonicalization step involves producing a stable JSON representation of the payload with keys sorted and no whitespace. The resulting bytes are base64‑encoded to form payload_b64, which is signed using Ed25519 with the issuer’s private key. The signature and public key are included in the signature object. If alternative canonicalization methods or signature algorithms are used in future, they MUST be documented along with evidence. Unknown or missing signing procedures SHALL be marked UNKNOWN — Missing Evidence.

Verification Rules

Verifiers MUST perform the following steps:

1. Validate the receipt structure and ensure all required fields are present.
2. Verify the signature using the provided public key and canonical payload. If the key is unknown or the signature check fails, the status is FAILED.
3. Optionally compute the SHA‑256 hash of the local file and compare it to content_hash.value. If provided and mismatched, the status is FAILED.

The verifier’s output status MUST be one of the following:

• UNKNOWN – Structure or signature could not be validated.
• FAILED – Signature invalid or file hash mismatch.
• PARTIAL – Signature valid but no file hash provided.
• VERIFIED – Signature valid and file hash matches the receipt hash.

Receipts with anchor_status.state of pending or none remain unverifiable with respect to external anchors; verifiers MUST report these fields as UNKNOWN and SHOULD wait for an anchor proof before attributing finality.

Privacy Considerations

ERF receipts are designed to avoid storing personal information. The content hash represents only the file’s digest and not the file itself. Submitters SHOULD refrain from embedding personally identifiable information in optional fields or labels. GetEvidex does not record IP addresses or session identifiers beyond short‑term rate‑limiting; daily metrics are aggregated without user‑level tracking. Verifiers MUST exercise caution when displaying private labels and respect user privacy.

Security Considerations

ERF relies on cryptographically strong hashing (SHA‑256) and Ed25519 signatures. Implementers MUST verify signatures using constant‑time comparisons to mitigate side‑channel attacks. Receipts SHOULD be served over HTTPS to prevent tampering in transit, and the verify page MUST enforce a strict Content‑Security‑Policy (no remote scripts) as documented in the security headers specification.

Legal & Reality Audit

ERF receipts provide evidence of integrity only. They do not prove authorship, ownership, intent, or legal admissibility. There is no warranty. Users must perform their own due diligence and consult legal counsel when necessary. The reality audit compares this specification against the deployed implementation; any discrepancies or undocumented behaviours should be reported. Where information is unavailable, the state MUST be recorded as UNKNOWN — Missing Evidence.

Examples

Example receipts can be downloaded for reference (no personal data):

• Provisional example
• Final example

These examples are non‑normative; the verify link is the source of truth.

Versioning & Compatibility

ERF uses a semantic versioning scheme (major.minor). Breaking changes increment the major version; minor versions introduce backwards‑compatible extensions. Implementations MAY support multiple versions simultaneously but MUST preserve the ability to verify receipts conforming to earlier versions unless explicitly deprecated.

Changelog

2026‑02‑20, v1.0 Draft: Initial public draft of the Evidex Receipt Format specification.

Further Reading

See the Policy Lockfile and any Trust Center documentation for additional details on operational controls and privacy policies. These links are provided as informational references and may be updated independently of this specification.