Zusammenfassung

  • Ein individueller Entwurf vom 27. Oktober sieht für jede Fassung von Geschäftsbedingungen und Richtlinien ein Siegel mit Dokumentname, Version, URL und SHA-256 des Klartexts vor. Die versiegelte Fassung muss unter dieser URL verfügbar bleiben.
  • Geschäfts- und Agentenschlüssel werden an eine Domain gebunden; ihre Geschichte bleibt sichtbar. Unabhängige Beobachter halten signierte Prüfpunkte eines Merkle-Protokolls fest. So lassen sich Urheber und Zeitpunkt einer Aussage prüfen, während ihre sachliche Richtigkeit gesondert beurteilt werden muss.

Der Link führt in die Gegenwart

Ein Kunde fragt, welche Klausel galt, als sein Auftrag ausgeführt wurde. Der Betreiber schickt den Link zu den aktuellen Bedingungen. Der Link funktioniert tadellos und beantwortet eine andere Frage. Vielleicht liegt beim Kunden ein Bildschirmfoto. Vielleicht besitzt der Dienst ein internes Archiv. Beide Parteien können über die Entstehung, Vollständigkeit und Verwahrung dieser Belege streiten. Wer die Website betreibt, besitzt einen erheblichen Vorsprung bei der Darstellung der Vergangenheit.

Furkan Yanteris Entwurf vom 27. Oktober 2026 legt in Abschnitt 4.2 eine konkrete Beweiskette fest. Jede Fassung der Bedingungen und Richtlinien eines Dienstes wird mit Dokumentname, Versionskennung, eigener URL und SHA-256 des Klartexts versiegelt. Alle versiegelten Fassungen bleiben an ihrer jeweiligen Adresse abrufbar. Die Firma darf neue Regeln schreiben. Sie kann eine alte Fassung aber nicht unbemerkt durch eine anders formulierte Datei unter derselben Adresse ersetzen: Der Hash würde nicht mehr passen.

Der Hash allein ist noch kein Archiv. Verschwindet die Datei, hat der Leser einen Fingerabdruck ohne die Worte, auf die es ankommt. Die alte Datei allein beweist auch nicht, dass sie schon zum damaligen Zeitpunkt existierte. Die URL nennt den Fundort, das Siegel bindet die genauen Bytes und das öffentliche Protokoll datiert diese Bindung. Ein hübsch gestalteter Änderungsverlauf, den der Betreiber nach Belieben pflegt, erfüllt eine andere Aufgabe.

Der IETF Datatracker führt die Vorlage als individuellen Internet-Draft mit Status I-D Exists. Sie ist kein verabschiedeter Standard und in den hier herangezogenen Originalunterlagen kein Bericht über einen benannten Streitfall. Gerade deshalb lohnt der Blick auf die vorgeschlagene Struktur: Sie legt offen, welche Belege ein Betreiber liefern müsste, bevor jemand seiner Erinnerung an alte Regeln traut.

Wer hat den Schlüssel ernannt?

Eine Signatur muss sich auf eindeutige Bytes beziehen. Abschnitt 3.1 beschreibt dafür eine eingeschränkte kanonische JSON-Form nach RFC 8785: rekursiv sortierte Schlüssel, kein entbehrlicher Leerraum und eine begrenzte Menge von Werttypen. Abschnitt 3.2 signiert die kanonische Nutzlast mit Ed25519, dessen Verfahren RFC 8032 festlegt. Zwei Prüfer können so dieselben Bytes nachvollziehen. Eine technisch korrekte Signatur macht eine falsche Behauptung nicht richtig.

Ein öffentlicher Schlüssel trägt keinen Firmennamen in sich. Der Entwurf bindet Schlüssel von Unternehmen und Agenten über einen DNS-TXT-Eintrag _humancollab an eine Domain. Bei der ersten Bindung kann eine HTTPS-Datei genügen. Für den Austausch eines bestehenden Schlüssels ist ein DNS-Nachweis erforderlich. Der frühere Schlüssel darf nicht bei einer anderen Domain wiederverwendet werden; eine öffentliche Historie hält jeden Schlüssel und den Protokollindex seiner ersten signierten Aussage fest. Ein neuer Domaininhaber kann dadurch nicht geräuschlos die alte Stimme des Hauses übernehmen.

Diese Zuordnung ist eine Kompetenzregel mit enger Reichweite. Domainkontrolle erlaubt im vorgeschlagenen System die Benennung eines Schlüssels. Sie beweist weder die Wahrheit einer Aussage noch die Vertretungsmacht eines Mitarbeiters noch die Befugnis eines Agenten für eine bestimmte Transaktion. Abschnitt 6 trennt die Schlüsse: Signatur und DNS-Bindung zeigen, welcher Domainkontrolleur sprach; ein von Beobachtern gesehener Prüfpunkt zeigt, wann die Aussage im öffentlichen Bestand auftauchte; widersprechende unabhängige Belege können eine falsche Aussage dem Sprecher zurechnen. Das ist Rechenschaft durch Attribution, kein Wahrheitsautomat.

Ein Archiv unter einer einzigen Hand

Abschnitt 4.3 sieht einen Merkle-Baum mit Hashregeln nach RFC 9162 vor. Das Protokoll liefert Aufnahme- und Konsistenznachweise, signiert Baumprüfpunkte und verankert veröffentlichte Wurzeln zeitlich mit OpenTimestamps. Beobachter vergleichen neue Prüfpunkte mit zuvor gesehenen und behalten eigene Kopien. Auch der Betreiber soll einen Beobachter außerhalb seiner Dienstinfrastruktur führen; weitere Beobachter können unabhängig hinzukommen.

Der Aufbewahrungsort ist der Machtpunkt. Wenn die Firma sowohl die Website als auch sämtliche alten Prüfpunkte besitzt, kann selbst ein formal korrektes Transparenzportal zur einzigen Erzählung des Betreibers werden. Zwei gültige Prüfpunkte mit identischer Baumgröße, aber verschiedenen Wurzeln belegen widersprüchliche Ansichten des Protokolls. Dieser Beleg entsteht nur, wenn getrennte Beobachter ihre Ansichten festhalten. Ein unabhängiger Zeuge ist kein Ehrengast bei der Einführung. Er muss noch da sein, wenn die Versionen nicht mehr zusammenpassen.

Für eine strittige Klausel gehören vier Gegenstände in die technische Akte: die frühere Klartextdatei, ihr Siegel mit URL und Hash, ein Aufnahmenachweis gegen einen extern verwahrten Prüfpunkt und die Domain-Schlüsselgeschichte zum damaligen Zeitpunkt. Damit lassen sich Text, Zeit und Sprecher bestimmen. Ob der Kunde die Klausel gesehen hat, ob ein Agent für ihn handeln durfte und welche rechtliche Wirkung sie hatte, erfordert eigene Beweise. Wenigstens muss darüber nicht mit dem falschen Text gestritten werden.

Ein Betreiber hat die Macht, seine Regeln für die Zukunft zu ändern. Er sollte daraus keinen Anspruch ableiten, die frühere Formulierung allein zu verwahren. Wer nur die Gegenwart vorzeigen kann, verlangt Vertrauen genau an der Stelle, an der ein überprüfbarer Beleg gebraucht wird.

Quellen