CREDAScan™

CredaScan helps create a simple, independently verifiable record that a scanned document file has not changed since the CredaScan record was made. This is useful when a specific wet-signed scan, exhibit, credentialing record, governance document, or formal submission needs to be preserved as a fixed digital evidence object.

Why this is stronger than only saving the file

• File dates, screenshots, and ordinary metadata can be changed, stripped, or disputed.
• A SHA-256 hash is a verifiable file fingerprint. Anyone can recompute it later and compare it to the CredaScan manifest.
• When future timestamp support is added, an RFC 3161 timestamp token may support that the file fingerprint existed at a recorded time without sending the file itself to a timestamp authority.

How it works

1. Select the scanned document on your device.
2. CredaScan calculates the file's SHA-256 hash locally in your browser.
3. CredaScan generates a manifest JSON record containing the file hash, evidence context, method boundary, and verification metadata.
4. Download and keep the manifest, document hash file, and verification report.
5. To verify later, upload the document and matching manifest. CredaScan recomputes the file hash and returns a clear match or mismatch result.

What it proves

• Integrity: if the document's SHA-256 hash matches the hash in the CredaScan manifest, the file is identical to the version used to create the record.
• Time, if timestamp evidence is later added: an RFC 3161 token may support that the document hash existed at the recorded time.

What it does not prove

• It does not prove authorship, ownership, possession, signer intent, signature authenticity, or legal enforceability by itself.
• It does not replace chain-of-custody documentation, notarization, or legal review.

Privacy and storage

• CredaScan processes the selected file locally in the browser.
• The document is not uploaded, transmitted, stored on a server, or retained by CredaScan after the page is closed, refreshed, or reset.
• CredaScan does not create a copy of the document. It only calculates a hash from the file bytes and generates user-downloaded proof records.
• The only persistent records are the files the user downloads and keeps.

What to keep

• The exact scanned document file you want to prove.
• The CredaScan manifest JSON file.
• The verification report, if you want a human-readable summary for sharing or filing.

This explanatory technical note assists review. It is not legal advice and does not guarantee admissibility; legal assessment depends on applicable law and case-specific circumstances.

Potential exhibit structure

1. Exhibit A — Subject File: the scanned digital file being tested.
2. Exhibit B — CredaScan Manifest JSON: the machine-readable record containing the subject file SHA-256 hash, evidence context, and optional timestamp fields.
3. Exhibit C — Verification Report: the human-readable summary. The manifest is the primary cryptographic artifact.

What these exhibits may demonstrate

1. Integrity of the subject file: if the SHA-256 hash computed from the subject file matches the SHA-256 hash recorded in the manifest, this supports that the subject file is identical to the file version for which the manifest was generated.
2. Existence-in-time, only if timestamp evidence is present: if a future CredaScan manifest contains an RFC 3161 timestamp token, that token may support that the file hash existed at the recorded time, subject to verification of the token signature and timestamp authority validation approach.
3. Scope limitation: the evidence packet does not, by itself, establish authorship, ownership, possession, chain of custody, signature authenticity, signer intent, or legal enforceability.

This section is for technical reviewers. The CredaScan manifest is designed to remain useful even if CredaScan is unavailable, because the core verification relies on standard SHA-256 hashing and, in future versions, optional RFC 3161 timestamp tokens.

Evidence objects

• Target file: the scanned document being tested.
• CredaScan manifest JSON: the source-of-truth record containing the target file's SHA-256 hash and proof metadata.
• Optional timestamp token: future versions may store an RFC 3161 TimeStampResp / TSR token in the manifest as base64.

Independent verification summary

1. File integrity: compute SHA-256 over the target file bytes and compare the result to the hash stored in the manifest.
2. Manifest consistency: review the manifest schema and required fields, including manifest version, artifact type, created time, document hash algorithm, and document hash.
3. Manifest fingerprint: if a manifest self-hash is provided, canonicalize the manifest according to the stated scope and recompute the SHA-256 to determine whether the manifest itself has been altered.
4. Timestamp token: if a future RFC 3161 token is present, decode it, verify the signature under the applicable trust policy, and confirm that the token message imprint corresponds to the document hash.

The CredaScan manifest JSON is the primary proof container. It is intended to be sufficient for independent verification without relying on CredaScan.

Minimum fields

• document.hash_algorithm: SHA-256
• document.hash: file hash in hexadecimal format
• created_at: ISO 8601 timestamp generated by the browser
• timestamp_evidence.present: false in this local-only prototype

Future timestamp fields

• timestamp_evidence.standard: RFC 3161
• timestamp_evidence.token_format: TimeStampResp / TSR
• timestamp_evidence.token_value: optional base64 timestamp token in a future version

Service-independent verification

CredaScan records remain verifiable over time because they rely on standard SHA-256 hashes and, if later included, standard RFC 3161 timestamp tokens stored inside the manifest. Verification can be performed without CredaScan using the file, the manifest, and standard tools.