Cryptographic payload attestation

@@ -1,65 +1,154 @@
---
schema: foundry-doc-v1
title: "Cryptographic payload attestation"
slug: crypto-attestation
category: security
type: topic
content_type: topic
quality: complete
short_description: "Mechanism by which PointSav edge nodes prove published text integrity to any viewer via client-side SHA-256 hashing, independently verifiable by any auditor."
status: active
audience: vendor-public
bcsc_class: forward-looking
last_edited: 2026-07-30
language_protocol: PROSE-TOPIC
last_edited: 2026-08-03
editor: pointsav-engineering
cites: []
short_description: "Cryptographic payload attestation lets a reader recompute a hash of published content and compare it against a published value. Unwired, cosmetic prototypes exist in a few release templates; the knowledge wiki does not offer it."
paired_with: crypto-attestation.es.md
---

**Correction — rehedged to planned/intended (2026-07-30):** this article originally
described a live client-side hash-attestation feature in unhedged present tense. No
such code exists: confirmed via both a single-crate check (`app-mediakit-knowledge`'s
`static/app.js` and `src/ui/layout.rs` — no hashing logic anywhere; the real sidebar
renders only nav/categories/TOC) and a broader cross-archive sweep for
`crypto.subtle.digest`/`SHA-256` (the only match anywhere in the fleet is an unrelated
save-integrity hash in `app-workplace-proforma`'s spreadsheet tool, not a wiki
attestation feature). Per operator direction, the body below is rewritten to present
this as planned/intended design, not current behavior.

> Cryptographic payload attestation is a mechanism by which PointSav intends its edge nodes to dynamically prove the integrity of their published text content to any viewer, using client-side SHA-256 hashing so that any auditor could independently verify a disclosure has not been altered in transit. This is a planned feature, not yet implemented.

**Cryptographic payload attestation**, once implemented, would be the process by which [[pointsav-overview|PointSav]] public-facing edge nodes prove the integrity of their textual content to any viewer without requiring trust in the server delivering the content. The design intent, per the platform's DARP (Direct, Auditable, Reproducible, Plain-text) requirements, is for public-facing edge nodes to dynamically compute and display a SHA-256 hash of their visible language content, so any institutional investor, auditor, or counterparty could independently copy the text, compute the hash locally, and confirm the displayed hash matches. **No such mechanism exists in the wiki engine (`app-mediakit-knowledge`) or anywhere else in the monorepo today.** See also [[cryptographic-ledgers|cryptographic ledgers]] and [[zero-execution-routing|zero-execution routing]].

## How it is intended to work

The design calls for the native browser `crypto.subtle.digest('SHA-256')` API to:

1. **Extraction:** read the current visible text of the language block (English or Spanish).
2. **Encoding:** encode the text into a `Uint8Array` using UTF-8.
3. **Hashing:** process the encoded array through SHA-256.
4. **Display:** inject the resulting hash live into a metadata block beside the content it attests.

None of this is implemented today — the wiki engine's static assets carry no hashing logic, and its real sidebar renders only navigation, categories, and the table of contents.

## Intended security posture

Once built, the attestation would be zero-execution-server for the hash computation — the server would deliver the JavaScript and content, but the hash would be computed by the browser using only local data. The intended effect: a man-in-the-middle attacker modifying content in transit would produce a detectable hash mismatch, and any viewer with a SHA-256 calculator could independently verify the attestation.

## Intended applications

Once implemented, cryptographic payload attestation is intended to apply to:

- Public regulatory disclosures displayed on [[pointsav-overview|PointSav]]-operated edge nodes.
- Content wiki articles served at `documentation.pointsav.com`.
- Any content surface where a reader needs to confirm they are reading the published version.

## Intended limitations

Even once built, the attestation would only prove integrity at the moment of viewing — it would not prove the content was published at a specific time or that it has not been legitimately updated since a prior version. Time-stamped proof of prior content states already exists independently of this planned feature, via the [[worm-ledger-architecture|WORM ledger architecture]] ([[service-fs-architecture|service-fs]]) and monthly Rekor anchoring — both real, verified mechanisms.
**Cryptographic payload attestation** is the practice of publishing a cryptographic digest of a
document alongside the document itself, so that any reader can recompute the digest from what
they actually received and detect a discrepancy without trusting the server that sent it. The
guarantee is narrow and worth stating precisely: a matching digest shows that the bytes rendered
in the reader's browser correspond to a value the publisher committed to. It does not by itself
prove *when* that commitment was made, nor who made it, unless the digest is separately signed or
anchored in a timestamped log.

The technique is attractive for published corporate and technical material because it is
inspectable by the reader without special tooling. A browser can compute a SHA-256 digest of a
text block using the Web Crypto API in a few lines of script, and the reader can compare the
result against a value printed on the page or held elsewhere.

## What exists today

No shipped PointSav surface offers reader-verifiable attestation. What exists instead is a small,
unwired, cosmetic pattern that recurs in a handful of files without ever being load-bearing.

Four files in the canonical source tree contain a client-side SHA-256 computation of the same
shape: `service-content/templates/pointsav-monolith.html` and its sibling
`woodfine-brutalist.html`, plus two proposed public-site mockups under `proposed/pointsav.com/`
and `proposed/woodfinegroup.com/`. Each renders a "SHA-256 Checksum" field in a metadata sidebar,
computes a digest of the currently-rendered page text via `crypto.subtle.digest('SHA-256', ...)`,
and writes the result into that field — a live display of "here is a hash of what you're looking
at," not a value the publisher fixed at build time. Each is paired with a `navigator.sendBeacon`
telemetry call fired on page unload, unrelated to the hash itself. A direct search of the
canonical tree found no Rust code, configuration, or build wiring that references any of the four
files by name — none of them is currently served by anything. This is the same code already
flagged elsewhere in this wiki ([[zero-execution-routing]]) for contradicting a separate "zero
client-side JavaScript" claim; here the relevant point is narrower: it is a page-integrity display
of the kind a reader might mistake for attestation, not an audit-trail or authorship mechanism, and
it has never been wired to serve any live page.

A fifth, unrelated implementation exists in the workplace spreadsheet application, which computes
a SHA-256 digest of its own canonicalised document state and stores it in a save-integrity audit
field — a different purpose (detecting accidental local corruption) from anything a reader of a
published page would use.

## What the knowledge wiki actually offers

The knowledge wiki engine, `app-mediakit-knowledge`, exposes no attestation affordance to a
reader. This was checked by reading its client script and its layout code in full and by
searching the whole of that component for hashing, signature, checkpoint, and verification terms.

Its client-side script implements a theme toggle, a mobile navigation drawer, code-block copy
buttons, table wrapping, and two explicitly labelled stubs for a future phase. There is no digest
computation of any kind. Its sidebar renders a main-page link, a category list, a conditional
guides section, and a table of contents built from the article's own headings — no hash, no
signature link, and no verify control.

Two "hash"-shaped things do appear in that component and neither is an attestation feature. One is
an HTTP `ETag` derived from a static asset's digest, used for cache validation of stylesheets and
fonts. The other is a footer provenance line stating that each revision is content-addressed by
its commit hash, which refers to the article's Git commit identifier.

That provenance line points at the mechanism the wiki genuinely relies on. The content mount is
itself a Git repository, and the engine's history module walks the repository log to produce a
per-article revision list — commit identifier, author, ISO date, and message. A reader therefore
has a tamper-evident *revision history* in the ordinary Git sense, which is a meaningful record
but is not a published digest they can independently recompute against the page they are reading.

## The relationship to the append-only ledger

The platform does operate a real, independently verifiable transparency mechanism, described in
[[cryptographic-ledgers]]: an append-only hash-chained log with Ed25519-signed checkpoints, whose
checkpoint digest is submitted monthly to the public Sigstore Rekor transparency log. That
mechanism delivers exactly what naive client-side hashing cannot — third-party evidence that a
given state existed at a given time.

The important qualification is that **wiki article content does not flow into that ledger**. The
knowledge engine contains no client for the file service and makes no append call; the ledger's
writers are the ingest console, the network administration fleet watcher, the email service, the
people service, and the anchoring emitter itself. Presenting the ledger's timestamping property as
though it covered published wiki articles would be inaccurate.

## Verifying an attestation by hand

Spelling out what an independent check would look like, once such a feature exists, clarifies why
the design is credible in principle even though nothing implements it today. A reader would select
and copy the visible text of a language block exactly as rendered, compute a SHA-256 digest of
that text on their own machine using any standard tool, and compare the result against the hash
displayed on the page — an exact string comparison, where any difference in any hex digit means
the content differs from what produced the displayed value.

Two properties of SHA-256 would carry the guarantee. Preimage resistance means an attacker cannot
construct alternative text that matches a given hash, so tampered content cannot keep the original
hash and remain consistent. The avalanche property means even a one-character alteration changes
the digest completely, so tampering would never be *nearly* undetectable — it would be conspicuous
or absent. A working version of this feature would need to be strict about what gets hashed —
which block, which whitespace normalisation, which encoding — because a verifier who cannot
reproduce the exact input bytes cannot reproduce the hash. None of the four prototype files above
solve this: each recomputes from whatever the page currently renders, which means a
man-in-the-middle who alters the text before it reaches the browser also alters the hash the
script displays, defeating the guarantee this technique is meant to provide.

## What a complete implementation would require

A reader-verifiable attestation for published articles would need, at minimum: a canonicalisation
rule fixing exactly which bytes are hashed and how whitespace and markup are normalised, so
publisher and reader compute over the same input; a publication path that records the digest at
build time rather than recomputing it in the browser from whatever was served; a signature over
that digest under a key the reader can obtain independently; and, for timestamping, submission of
the signed digest to the existing anchoring path described above. None of these four steps is
implemented for wiki content, or for any of the four prototype files, today.

## What this is not

**This is not a feature the knowledge wiki currently provides.** No article page computes,
displays, or verifies a content digest. A reader visiting the wiki today has no attestation
control available to them.

**A self-computed page hash is not tamper protection on its own.** In the prototype files, the
digest is computed by script served from the same page as the content. An attacker able to alter
the content is generally able to alter the script. Such a display is at most a cosmetic integrity
aid against accidental corruption, not a defence against a compromised publication path, unless
the expected value is obtained from an independent source.

**Attestation is not authentication of authorship.** An unsigned digest says nothing about who
published the content. Nothing in the prototypes described above signs the digest with a
publisher key.

**Attestation is not a timestamp.** Only the separate anchoring path establishes that a state
existed at a point in time, and it does not currently cover wiki articles or any of the prototype
files.

**Git revision history is not the same guarantee.** It records what the repository holds and who
committed it, which is valuable provenance, but it is verified by trusting the repository rather
than by recomputing a digest of the delivered page.

## See also

- [[worm-ledger-architecture]]
- [[cryptographic-ledgers]]
- [[machine-based-auth]]
- [[compounding-substrate]]
- [[sovereign-ai-routing]]
- [[cryptographic-ledgers]] — the append-only hash-chained log and its signed checkpoints
- [[doctrine-invention-7-rekor-anchoring]] — the monthly submission of checkpoints to a public transparency log
- [[verify-worm-ledger]] — the operator procedure for checking ledger integrity directly
- [[merkle-proofs-as-substrate-primitive]] — the proof structure a future upgrade would adopt
- [[app-mediakit-knowledge]] — the wiki engine whose current capabilities are described above
- [[zero-execution-routing]] — the pattern article where this same prototype code is separately flagged for an unrelated overclaim