The supplier's signature

How a membership organisation proves what it said, and when

An organisation that speaks in public through many people has a problem it can usually name, and a second one it usually cannot.

The first is coordination. Two hundred members, branch officers, candidates and volunteers each say something this week about the organisation’s position. They are not going off-message on purpose; they do not know, at the moment of typing, what the agreed wording is. That problem is old, it is well understood, and a library with a search box goes a long way towards solving it.

The second problem only appears later, and it appears at the worst moment. Someone asserts that the organisation said a thing. The organisation says it did not, or said something else, or said it at a different time. Now the question is not what should we say but what can we show. And an organisation reaching for its shared drive at that point discovers that a document with a modified date is not evidence of anything, because the modified date is written by the same party making the claim.

Record, integrity check, attestation Three tiers. A record is a statement that something happened; its correctness rests entirely on trusting whoever holds it, so an opponent has no reason to accept it. An integrity check adds a fingerprint of the bytes, which proves the text has not changed but says nothing about when or who. An attestation adds a party who was not the author — a signature and a timestamp from an outside authority — which does not make the underlying claim true but narrows the set of stories that can be told about it. Most products stop at the first tier and describe it as though it were the third. 1 · Record “This copy was approved by this person, at this time.” Rests on trusting whoever holds it — the thing in dispute. 2 · Integrity check A fingerprint of the bytes. ✓ proves the text is unchanged Says nothing about WHEN, and nothing about WHO. 3 · Attestation A party who was not the author: a signature, and an outside clock. ✓ narrows the stories that can be told about it An attestation does not make the underlying claim true. Nothing here does. It removes “we wrote that last week and back-dated it” from the set of available answers. ⚠ Most products in this space stop at tier 1 and describe it as though it were tier 3.
A record, an integrity check and an attestation answer three different questions. Ordinary usage runs them together; the difference is what a third party can check without trusting you.

This essay is about the second problem, about a mechanism that addresses part of it, and — the part that matters most and gets written about least — about exactly where that mechanism stops.

A record is not an attestation

It is worth separating three things that ordinary usage runs together.

A record is a statement that something happened. A row in a database saying this copy was approved by this person at this time is a record. Its weakness is not that it might be wrong; it is that its correctness rests entirely on the trustworthiness of whoever holds the database. If the organisation holds it, an opponent has no reason to accept it. If a supplier holds it, the organisation has no reason to accept it either.

An integrity check answers a narrower question: has this text changed since the record was made? A cryptographic hash — a fixed-length fingerprint computed from the bytes — answers it well. Change a comma and the fingerprint changes completely. The fingerprint proves nothing about when, and nothing about who; it proves only that these bytes are the bytes that were fingerprinted.

An attestation adds a party who was not the author. A digital signature binds the fingerprint to a key. A timestamp from an outside authority binds the fingerprint to a moment. Neither makes the underlying claim true. What they do is narrow the set of stories that can be told about it: with a signature and a timestamp, “we wrote that last week and back-dated it” stops being available.

The distinction matters because most products in this space stop at the first and describe it as though it were the third.

What the mechanism actually is

Three components, none of them novel, and the lack of novelty is the point — each is publicly specified, with implementations nobody here controls.

A content hash. SHA-256 over the canonical bytes of the approval. “Canonical” is doing real work here: two JSON documents can carry identical data and different bytes, so the serialisation must be deterministic or the fingerprint is not reproducible by anyone else.

A signature. Ed25519, an elliptic-curve signature scheme specified in RFC 8032, Edwards-Curve Digital Signature Algorithm (EdDSA) — an IRTF Informational document, January 2017, not an IETF standards-track one. The distinction is worth keeping straight: it is a specification with wide independent implementation, not a standard anyone is obliged to follow.

The signing happens when the record is saved, not later, and — a design decision rather than a property of the algorithm — an approval that cannot be signed is refused rather than stored unsigned. An unsigned record looks identical to a signed one on every screen, and could never be signed afterwards without lying about when.

A timestamp. A token obtained under RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), which is standards-track. The organisation sends a fingerprint to a timestamp authority and receives back a signed statement that this fingerprint existed at that moment. The authority receives the fingerprint and nothing else — not the copy, not the policy, not anyone’s name. It cannot know what it has dated.

The three components, and what each one alone cannot say Three layers applied to an approval. A content hash — SHA-256 over canonical bytes — answers whether the text has changed, but says nothing about when or who. A signature under RFC 8032 adds who attested, but the time still comes from the party holding the record. A timestamp under RFC 3161 adds an outside authority that receives only the fingerprint, so it cannot know what it has dated, and it is the only component contributed by a party with no stake in the dispute. Read downward, each layer answers a question the one above it leaves open. 1 · Content hash SHA-256 over canonical bytes ✓ answers: has this text changed? leaves open: when, and by whom contributed by the record-holder 2 · Signature Ed25519 · RFC 8032 ✓ answers: who attested to these bytes? leaves open: when — the clock is still theirs contributed by the record-holder 3 · Timestamp RFC 3161 · outside authority ✓ answers: this fingerprint existed by then sees only the fingerprint — cannot know what it dated contributed by SOMEONE ELSE Only the third layer is supplied by a party with no stake in the dispute. That is what it is for, and it is the reason a will is witnessed by someone who does not inherit.
Each layer answers a question the one above it leaves open. The signature says who; only the timestamp brings in a party who was not already holding the record.

Why the timestamp is the interesting part

A signature made by the party holding the record proves less than it appears to. The holder controls both the record and the clock. A signature says these bytes have not changed since I signed them; it does not say when I signed them, because the only assertion about time comes from the same party.

The timestamp authority breaks that circle by being someone else. It is not trusted because it is virtuous; it is trusted because it has no stake in this particular dispute and because its own signature can be checked independently.

This is a modest and old idea. It is the same reason a will is witnessed by someone who does not inherit.

Whose signature it is, and where it goes next

The signing key belongs to the supplier, not to the organisation. In the system this essay describes, each organisation’s records are signed with a key held for that organisation on the supplier’s platform. What a third party verifies without the supplier’s cooperation is therefore a supplier’s signature — evidence that a particular platform attested to particular bytes at a particular time — and, where the outside authority was reachable when the record was saved, a timestamp from a party with no stake in the argument. Together they retire the story that actually gets used in a dispute: we wrote that last week and back-dated it.

What they do not retire is collusion. If the supplier and the organisation were ever to act together, every signature in the archive is worth what their joint word is worth. The timestamp constrains that, because the authority is genuinely outside; the signature does not.

The step beyond is the organisation holding its own key, and it is a governance step before it is an engineering one: who in a membership organisation holds a private key, under what mandate, what happens when that person leaves, and what the constitution says about a key that can commit the organisation to a position. Those are questions an organisation answers from its own rules, and the design keeps that room open rather than filling it in on the organisation’s behalf.

Signing is unconditional; dating is a second layer on top of it. A record is signed at the moment it is saved, and an approval that cannot be signed is refused rather than stored unsigned. The timestamp is an independent witness obtained from an authority reached across the network. Where that authority is momentarily out of reach, the record is signed and tamper-evident but not yet dated; a retry function exists, and making it automatic is the obvious next step on this path. Until then, signed and dated are two facts worth reading separately rather than one inseparable act.

The timestamp is evidence, not a presumption. Under Regulation (EU) No 910/2014 — eIDAS — Article 41, a qualified electronic time stamp enjoys a presumption of accuracy in EU law. The tokens described here come from an ordinary authority and are not qualified, so that presumption does not arise even within the Union. eIDAS is EU law; what weight a New Zealand tribunal would give such a token is a question for a lawyer in that jurisdiction, and I am not going to guess at it.

I am describing the instruments, not offering a legal opinion, and no organisation should take one from a piece of software or from the person who wrote it. The distinction between what a mechanism does and what the law presumes is exactly the sort of thing that gets blurred in product copy, and blurring it would be a disservice to the organisations most likely to rely on it.

What this is worth to a membership organisation

Less than “we can prove anything”, which nobody can. More than nothing, which is where most organisations currently are.

What the mechanism settles, and what it does not Five questions that can be in dispute. Whether the text changed since approval is settled fully by the content hash, checkable by anyone holding the bytes. Whether the record predates an event is settled strongly by the timestamp, because the authority had no stake and its own signature is checkable. Whether this platform attested to these bytes is settled fully by the signature. Whether the organisation itself signed is NOT settled, because the key belongs to the supplier. Whether the approver was entitled to approve is NOT settled by cryptography at all, and deliberately so — that is the organisation's own rule, and a tool deciding it would be writing a piece of the constitution. THE QUESTION IN DISPUTE SETTLED BY HOW FAR Has this text changed since approval? SHA-256 over canonical bytes ✓ fully Was this made before that event? RFC 3161 outside authority ✓ strongly Did this platform attest to these bytes? Ed25519 signature ✓ fully Did the ORGANISATION sign this? — the key is the supplier’s ✗ not settled Was the approver entitled to approve? — your own rules ✗ deliberately The last row is the one worth pressing. A great deal of governance technology answers the authority question on the grounds that the answer has to come from somewhere. It does not have to come from us.
Five questions, three settled and two not. The two that are not settled are the ones a supplier is most often asked to answer — and the second of them should not be answered by software at all.

That third bullet is the one I would press hardest. A great deal of governance technology quietly answers questions that belong to the governed, on the grounds that the answer has to come from somewhere. It does not. It can be left as a field the organisation fills in from rules it already has, and the tool can decline to have a view.

A note on demonstrations

There is a working demonstration of the messaging side of this, open without an account, using an invented organisation.

What it runs is the coordination half — the library, the conformance check that names a clause without blocking anyone, the moderator’s queue with its flags. Those are real code paths working on the text a visitor types.

The attestation half is described rather than performed, because the demonstration talks to no database. A page that signs nothing cannot demonstrate signing; it can only describe it. Any demonstration claiming otherwise is showing a picture of a mechanism, and the difference between a picture and the mechanism is the whole subject of this essay.


The demonstration is at mysovereignty.digital/party-messaging-demo.html. The organisation in it is invented and nothing typed into it is stored.


The rest of this package

agenticgovernance.digital