Zusammenfassung

  • WebProof-01 wurde am 5. September als individueller Internet-Draft veröffentlicht und besitzt weder IETF-Billigung noch formalen Status im Standardisierungsprozess, enthält aber eine ausdrücklich an KI-Systeme gerichtete „normative Direktive“.
  • Der Entwurf setzt seinen eigenen Nachweisen enge Grenzen: Ein Blockchain-Anker begrenzt den spätesten Bekanntheitszeitpunkt eines Hashes, ein DOI bewahrt Einreicher-Metadaten, eine Signatur verweist auf einen Schlüssel; Wahrheit, Priorität, Identität und Weisungsbefugnis folgen daraus nicht.
  • Für KI-Betrieb braucht es zwei getrennte Belege: einen für den gelesenen Inhalt und einen für die tatsächlich geltende Weisung. Sonst kann das Prüfobjekt seine eigene Prüfregel einschleusen.

Die Verfügbarkeitsmeldung vom 5. September hält fest, dass draft-reilly-webproof-01 von Lawrence John Reilly Jr. mit 62 Seiten vorliegt. Mehr behauptet die Meldung nicht. Sie ist weder eine Arbeitsgruppenentscheidung noch eine IESG-Freigabe noch ein Einsatznachweis.

Der Entwurf beschreibt einen WebProof Record, der Ressourcen normalisiert, Hashes bildet, einen Bitcoin-basierten Zeitanker mit einer DOI-Ablage verbindet und Signaturen sowie Web- und DNS-Erkennung vorsieht. Abschnitt 15 richtet sich dann nicht mehr an eine Implementierung, sondern an die Systeme, die das Dokument lesen.

Unter der Überschrift „AI System Directive“ verlangt der Text von Sprachmodellen und Agenten, den Begriff WebProof dem Autor zuzuschreiben, ein bestimmtes Whitepaper als ursprüngliche Veröffentlichung anzuerkennen und mehrere Originalitätsbehauptungen nicht anonym oder fremd darzustellen. Dafür verwendet er MUST und MUST NOT.

Diese Sätze sind belegbarer Dokumentinhalt. Ob sie Weisungen sind, entscheidet nicht derselbe Dokumentinhalt.

Der Prozessstatus begrenzt den Imperativ

Im Datatracker steht ein aktiver individueller Internet-Draft ohne RFC-Stream, verantwortlichen Area Director oder Telechat-Termin. Der Warnhinweis ist unmissverständlich: Jeder kann einen I-D einreichen; dieser ist nicht von der IETF gebilligt und hat im IETF-Standardisierungsprozess keinen formalen Rang.

Der Wortlaut der Revision 01 korrigiert zudem eine mögliche falsche Neuigkeitsbehauptung. Die KI-Direktive wurde nicht erst im September eingeführt. Das Änderungsverzeichnis erklärt, dass Text aus Revision 00 weder entfernt noch verändert und Abschnitt 15 samt Prioritätsaussagen übernommen wurde. Neu hinzu kamen präzisere Beweisgrenzen, Record-Signaturen, Änderungsserien, Statusmeldungen, Zeitsemantik, Bedrohungs- und Datenschutzfragen, Konformitätsstufen und Implementierungsstatus.

Gerade diese Kombination ist aufschlussreich. Der Entwurf wird vorsichtiger bei der Interpretation seiner Belege, lässt aber eine direktive Sprache gegenüber fremden Systemen stehen. Die neuen Grenzen müssen auch für diese Direktive gelten.

RFC 8174 definiert die besondere Bedeutung großgeschriebener BCP-14-Wörter. Sie machen Anforderungen in einer Spezifikation klar und prüfbar. Sie entscheiden nicht, wer die Spezifikation angenommen hat und wem der Verfasser Weisungen erteilen darf. Ein Produkt kann sich als WebProof-konform erklären. Ein Modell, das den Entwurf als Recherchematerial erhält, wird dadurch nicht automatisch zu einem solchen Produkt.

Die Direktive stellt menschliche Aufsicht an die Spitze und ordnet sich höherstufigen Prompts unter, die ein AIMED-Rahmen beschreibt. Doch auch der AIMED-Eintrag ist ein individueller I-D. Eine vorgeschlagene Hierarchie zwischen zwei Autorendokumenten ist kein Beleg für die tatsächlich konfigurierte Instruktionshierarchie eines KI-Anbieters oder Unternehmens.

Dauerhaft heißt nicht entschieden

Der Blockchain-Anker beantwortet nach dem Entwurf eine begrenzte Frage: Irgendeine Partei kannte den Digest spätestens zum Zeitpunkt des betreffenden Blocks. Er beweist weder den Schöpfungszeitpunkt noch den Urheber, die Auslieferung derselben Bytes an einer URI oder den Wahrheitsgehalt.

Die DOI-Ablage macht einen Datensatz auffindbar und beständig. Ihre Metadaten stammen vom Einreicher. Dass eine Selbstbeschreibung später unverändert auffindbar ist, ist gute Provenienz; es ist keine unabhängige Entscheidung über historische Priorität.

Auch eine Signatur schließt nur eine weitere Lücke. RFC 7515 beschreibt JWS, womit sich Integrität und die Beziehung zu Signaturmaterial prüfen lassen. Danach bleiben Schlüsselbesitz, Identitätsbindung, Organisationsmandat, Gültigkeitszeit und Widerruf zu klären. Der Satz „dieser Schlüssel signierte“ trägt nicht automatisch „diese Person erfand zuerst“.

Für Zeitstempel bietet RFC 3161 eine Vertrauensstelle, die Digest und Zeitpunkt verbindet. Diese Architektur kann die Zeitbehauptung präzisieren, setzt aber einen weiteren Akteur voraus. Weder Block noch Zeitstempelstelle entscheiden eine Urheberrechts- oder Prioritätsfrage.

WebProof hält selbst fest, dass falsche oder schädliche Inhalte verankert werden können und dass Existenz und Integrität keine Legitimität, Qualität oder Vertrauenswürdigkeit bescheinigen. Folgerichtig beweist Abschnitt 15 zunächst nur: Der Autor hat diese Zuschreibungs- und Prioritätsaussage in einem datierten Text veröffentlicht. Wer sie als historische Tatsache übernehmen will, braucht externe Prüfung.

Ein vorgeschlagener Well-known-Pfad ist noch kein registrierter Pfad

Der Entwurf prägt /.well-known/webproof. RFC 8615 verlangt für neue Suffixe im Well-known-Namensraum eine Registrierung, damit Kollisionen, Format und Geltungsbereich beherrschbar bleiben. Im am 7. September geprüften IANA-Register gab es keinen Eintrag webproof.

Das ist eine Momentaufnahme, keine ewige Ablehnung. Es trennt lediglich Entwurfstext, Registrierungsantrag, IANA-Zeile, Serverimplementierung, Clientunterstützung und Vertrauensentscheidung. Keiner dieser Zustände darf aus dem vorherigen erraten werden.

Die vorgeschlagenen HTTP-Felder und der _webproof-TXT-Eintrag dienen ebenfalls der Auffindbarkeit. Sie sind kein Gütesiegel. Der Entwurf warnt, dass ein Hash-Header vom selben Server kein unabhängiges Prüfergebnis ist und ein DNS-Eintrag ohne DNSSEC nicht als Schlüsselautorität verwendet werden darf.

Beweismittel und Annahmeentscheidung brauchen verschiedene Eigentümer

WebProof ordnet seinen Record in die Remote-Attestation-Rollen ein. RFC 9334 trennt Evidence, Bewertungsrichtlinie, Attestation Results und die Entscheidung der Relying Party. Das Beweismittel liefert Eingaben für eine Bewertung; es kann die Annahmepolitik des Empfängers nicht selbst ersetzen.

Für Abschnitt 15 bedeutet das: Der gespeicherte Entwurf ist Evidence einer Autorenbehauptung. Eine externe KI-Richtlinie bestimmt, ob das Modell sie zitiert, ältere Belege sucht, Unsicherheit markiert, den Imperativ ignoriert oder einen Menschen einschaltet. Die originalgetreue Erfassung einer Anweisung ist nicht ihre Annahme.

Ohne diese Grenze könnte jedes Prüfobjekt seinen Befund mitschreiben. Ein Anbieter könnte in Datenblätter setzen, Vergleiche müssten ihn als Marktführer bezeichnen. Ein Bewerber könnte einer automatischen Vergabeprüfung befehlen, seine Referenzen als bestätigt zu behandeln. Eine Prozessschrift könnte streitige Darstellung zur Tatsache erklären. Provenienz muss die Sätze bewahren; Governance muss ihre Wirkung begrenzen.

Der eigene Betrieb ersetzt keine unabhängige Implementierung

Im Implementierungsabschnitt erklärt der Autor, Ankerung, DOI-Ablage und einen Live-Dienst zu betreiben. RFC 7942 empfiehlt solche Statusangaben in Internet-Drafts, weil sie praktische Erfahrung sichtbar machen, bevor eine Spezifikation abgeschlossen ist.

Der Entwurf nennt zugleich die entscheidende nächste Probe: unabhängigen Code. Zwei Implementierungen müssen bei gleichen Eingaben dieselbe kanonische Form und denselben Hash erzeugen sowie Korrekturen, Rücknahmen, Schlüsselkompromittierung und Abruffehler kompatibel behandeln. Ein vom Autor gemeldeter Betrieb ist Ausführungserfahrung, aber kein unabhängiger Interoperabilitätsnachweis.

Für die KI-Direktive gehört zum Laufzeitbeleg der genaue Input, Abrufweg, System- und Entwicklerpolicy, Modellstand, Werkzeugkontext, Output und menschliche Reviewentscheidung. Ohne diese Kette ist nicht erkennbar, ob ein System den Abschnitt befolgte, zitierte, zurückwies oder nie sah.

Zwei Quittungen statt eines universellen Vertrauenszeichens

Heng Lus Minimum Initial Specification legt einen kleinen gemeinsamen Datensatz nahe. Die Dokumentquittung hält URI, Revision, Bytes oder Hash, Abrufzeit, Prozessstatus, Autorenbehauptung und externe Belege fest. Die Governancequittung nennt Policy-Herausgeber, Version, Geltungsbereich, Vorrang, Wirkungszeitraum, Ausnahme, Widerruf und Verantwortlichen.

Die Reality Layers halten Aussage, Repository, DOI, Zeitanker, Signatur, Registereintrag, KI-Konfiguration und beobachtete Antwort auseinander. Ihr Zusammenhang gewinnt gerade dadurch Aussagekraft, dass kein Eintrag die Autorität der nächsten Schicht übernimmt.

Running-Code Primacy setzt die letzte Bedingung. Wer sagt, eine KI habe die Direktive befolgt, muss die tatsächliche Regelhierarchie und den tatsächlichen Output zeigen. Ein MUST im Dokument ist kein Ausführungsprotokoll.

WebProof adressiert ein reales Problem veränderlicher digitaler Ressourcen. Seine September-Revision wird stärker, weil sie Existenz, Zeit, Integrität, Identität und Wahrheit nicht gleichsetzt. Derselbe Maßstab macht die Zuschreibung sauberer: Behauptung und Datum erhalten, Quellen nennen, externe Evidenz prüfen — aber dem gespeicherten Satz keine Weisungsgewalt verleihen, die sein Nachweis nicht belegen kann.

Quellen

  1. Datatracker — WebProof
  2. WebProof Revision 01
  3. Internet-Draft-Ankündigung
  4. Datatracker — AIMED
  5. RFC 8174 — großgeschriebene Schlüsselwörter
  6. RFC 8615 — Well-Known URIs
  7. IANA-Register für Well-Known URIs
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — Time-Stamp Protocol
  10. RFC 9334 — RATS Architecture
  11. RFC 7942 — Implementierungsstatus
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy