Cryptografisch bewijs.
Hoe wij herroepingen juridisch waterdicht maken.

Het probleem: vertrouwen schaalt niet

Een herroeping is een juridisch bindende handeling. Wie beweert te hebben herroepen, heeft bewijs nodig. Wie beweert een herroeping te hebben ontvangen, eveneens. In de klassieke opzet leg je de invoer vast in je database, plus een logbestand, en hoop je dat niemand beweert dat je iets hebt gewijzigd.

Het probleem: de beheerder van de database, dat zijn wij, zou in theorie alles achteraf kunnen bewerken. Een advocaat die jouw bewijs in twijfel trekt, heeft een makkelijke taak. „Hoe weten we dat dit databaserecord echt van het moment van binnenkomst dateert?”

De oplossing in één zin

Elke herroeping krijgt een fingerprint. Aan het einde van de dag voegen we alle fingerprints samen tot een boom. We publiceren de root van die boom. Iedereen kan later controleren of zijn herroeping echt in de boom zat, zonder toegang te krijgen tot de andere herroepingen.

Wie de rest van dit artikel niet leest, heeft het wezenlijke al begrepen.

De fingerprint: SHA-256

SHA-256 is een cryptografische hashfunctie. Je gooit er een willekeurige hoeveelheid tekst in, je krijgt er 64 tekens uit. Deze 64 tekens zijn uniek voor de tekst. Verander je één enkele komma, dan verandert de hele hash. Het is praktisch onmogelijk om twee verschillende teksten te vinden die dezelfde hash opleveren.

Bij ons wordt elke herroeping bij binnenkomst geserialiseerd tot een vastgelegd tekstblok: naam, contact, bestelreferentie, vrije tekst, tijdstempel tot op de milliseconde, shop-ID. Dit blok gaat door SHA-256. Resultaat: een hash van 64 tekens.

De hash is als het bewijs van een verzegelde envelop. Als we later de inhoud tonen en iemand de hash herberekent, moet die weer precies kloppen. Wijkt één teken af, bijvoorbeeld omdat we de naam achteraf hebben ingekort, dan klopt de hash niet meer. Manipulatie wordt zichtbaar.

De boom: Merkle-tree

Eén hash per herroeping is goed, maar nog niet genoeg. We zouden elke hash afzonderlijk moeten publiceren om ze controleerbaar te maken. Dat zou een nachtmerrie voor de gegevensbescherming zijn, want uit de hashes plus de informatie „deze hash stond op tijdstip X op de server” zouden conclusies te trekken zijn.

Merkle-trees lossen dit elegant op. Je neemt twee hashes, combineert ze en hasht het resultaat opnieuw. Dit nieuwe hash-paar neem je weer samen met het volgende paar, tot er aan het einde één enkele hash overblijft: de root van de boom.

Herroeping A → hash_A ─┬───── hash_AB ─┬──────────┐
Herroeping B → hash_B ─┘              │             │
                                         │             Root
Herroeping C → hash_C ─┬───── hash_CD ─┘
Herroeping D → hash_D ─┘

De root is alleen exact dezelfde als elke afzonderlijke herroeping eronder ongewijzigd is. Eén gewijzigde letter in één enkele herroeping zou de bijbehorende hash doen omslaan, daarna de paar-hash erboven, daarna de volgende, tot helemaal aan de root. De root zou niet meer kloppen.

De notaris-analogie

Stel je een notaris voor. Elke dag om middernacht verzamelt hij alle herroepingen van die dag, schrijft ze in een boek, verzegelt het boek en legt het in een kluis. De volgende ochtend publiceert hij op een aanplakbord voor zijn huis een korte code die alleen bij dit boek past.

Komt er later iemand die beweert dat zijn herroeping in het boek staat, dan kan de notaris het hem tonen: „Ja, kijk, hier op pagina 47, regel 12. De code op het aanplakbord past precies bij dit boek. Had ik iets gewijzigd, dan zou de code niet meer kloppen, en dat zou iedereen op het bord zien.”

Het boek is de database. Het zegel is de SHA-256-hash. Het aanplakbord is ons publieke endpoint. De code is de Merkle-root.

De publieke root: /proof

Elke dag om middernacht berekenen we de Merkle-tree van alle die dag ontvangen herroepingen. De root schrijven we naar een publiek endpoint onder /proof/root/YYYY-MM-DD.

Elke shopbeheerder krijgt bij elke herroeping een proof_token. Dat is het volledige pad door de boom, van zijn eigen herroeping tot aan de root. Met dit token kan elke derde, ook een rechter, ook de klant zelf, de echtheid controleren.

GET /proof/{token}

Response 200:
{
  "revocationHash": "9f86d081884c7d659a2feaa0c55ad015...",
  "merkleProof": ["a3f5...", "b2e8...", "c1d4..."],
  "merkleRoot": "5d41402abc4b2a76b9719d911017c592...",
  "publishedAt": "2026-04-13T00:00:00Z",
  "verifiable": true
}

Wie de logica wil controleren, neemt de revocationHash, combineert die volgens de spelregels van Merkle-trees met de elementen uit merkleProof, en zou aan het einde precies de merkleRoot moeten krijgen. Dat is in elke programmeertaal in tien regels code na te rekenen.

Gegevensbescherming: waarom dit AVG-conform blijft

Het slimme aan de Merkle-tree is dat de root geen conclusies over afzonderlijke herroepingen toelaat. We publiceren niet de namen, niet de e-mails, zelfs niet de afzonderlijke hashes. Alleen de root en, per herroeping, het individuele pad-bewijs.

Het pad-bewijs krijgt alleen wie het proof_token kent. En dat krijgen alleen de shopbeheerder, de klant, en wie het token van een van beiden overhandigd krijgt. Er bestaat geen publieke lijst.

Daarmee voldoet de constructie tegelijk aan twee schijnbaar tegenstrijdige eisen: publieke bewijsbaarheid en AVG-conforme gegevensbescherming van de afzonderlijke handelingen.

Waarom dit standhoudt bij de rechter

Een rechter hoeft niet te begrijpen hoe SHA-256 werkt om een deskundigenrapport te accepteren dat op SHA-256 berust. De functie is sinds 2001 gestandaardiseerd, wordt wereldwijd door banken, overheden en blockchains gebruikt, en is cryptografisch niet gebroken.

Belangrijk is dat de Merkle-root is gepubliceerd op een moment waarop niemand er nog achteraf invloed op kon uitoefenen. Vandaar het schrijven om middernacht, en vandaar de onveranderlijke opslag. Wie beweert dat we achteraf een record hebben toegevoegd, zou moeten uitleggen hoe we tegelijk de root hebben gewijzigd die de volgende dag al openbaar was geworden. Die uitleg bestaat niet zolang SHA-256 niet gebroken is.

In de praktijk: wat je in het dashboard ziet

In het dashboard krijgt elke herroeping een link naar /proof/{token}. Je kunt deze link doorgeven aan een advocaat of zelf controleren. In een eventueel juridisch geschil is dit jouw technisch-neutrale verificatie, onafhankelijk van ons.

En omdat wij zelf niet in de boom kunnen ingrijpen zonder de publieke root te vernietigen, zijn ook wij aan het bewijs gebonden. Dit is geen marketingbelofte, maar een structurele grens van het systeem.

Waarom andere aanbieders dit niet hebben

De meeste aanbieders van een herroepingsknop schrijven de invoer gewoon in hun database en vertrouwen op back-ups plus een goed geweten. Dat volstaat tot het eerste geschil escaleert. Dan sta je daar met een databaseregel die een technisch deskundige in tien seconden als manipuleerbaar bestempelt.

Wij hebben gekozen voor de extra inspanning omdat de verplichting uit Richtlijn (EU) 2023/2673 (in Nederland omgezet via artikel 6:230oa van het Burgerlijk Wetboek, EU-breed van toepassing vanaf 19 juni 2026) te nieuw is om op gewoonte te vertrouwen. De eerste rechterlijke uitspraken moeten nog komen. Als ze komen, wil je aan de kant staan waar de wiskunde is.

Details over de uitvoering in onze handleiding of op de productpagina.