Zusammenfassung

  • Ein individueller Entwurf vom 28. Oktober schlägt einen „verdict record“ vor: Behauptung, Ergebnis, benannte Regel und per SHA-256 referenzierte Belege in einem kanonischen JSON-Datensatz.
  • Die prüfende Stelle verwendet eigene Belegbytes, Vertrauensanker und Regeln. Ihr Bericht kennt released, held und refused, aber kein pauschales „verified“ für den gesamten Datensatz.

Wer den Maßstab hält

Der Hersteller einer Bewertung kann seine Unterlagen ordentlich heften. Er kann auch entscheiden, welche er weitergibt. Darren Wrights IETF-Vorschlag legt deshalb einen zweiten Arbeitsplatz neben die Ablage: Jemand außerhalb des Ausstellers muss die genannten Belege besitzen und die Prüfung selbst vornehmen. Der Text ist ein individueller Internet-Draft mit angestrebtem Experimental-Status.

Der Datensatz setzt auf strenges, kanonisches JSON. writer benennt den Aussteller, body enthält die Behauptung und die Werte für eine Regel, evidence nennt Format und SHA-256-Wert jedes Belegs, check Regel und Ergebnis. Eine neue Version kann den Hash der vorigen angeben. Eine Signatur und eine obere Zeitgrenze gehören zum Träger des Datensatzes. Ein signiertes Statement mit geprüftem SCITT-Beleg wäre ein möglicher Träger. Die Zeichenfolge im JSON ist für sich noch keine unabhängige Bestätigung.

Die stärkste Vorschrift betrifft die Eingaben der Prüfung. Was einen Schritt bestehen lässt, muss außerhalb der Reichweite des Ausstellers liegen. Die prüfende Stelle berechnet Hashwerte aus Bytes, die sie tatsächlich besitzt, prüft Signaturen, führt eine Regel erneut aus und bringt eigene Richtlinien und Vertrauensanker mit. Eine Behauptung des Ausstellers darf im Bericht als Behauptung erscheinen. Sie darf einen sonst offenen Prüfschritt nicht im Alleingang bestehen lassen. Der Verfasser der Antwort erhält keinen Schlüssel zum Prüfungsamt.

Fehlende Belege verschwinden nicht in einer Fußnote. Für jeden Eintrag braucht der Prüfer das ganze Dokument, den passenden Digest und einen überprüfbaren Formattyp. Fehlt eines davon, heißt der Schritt NOT RUN. Eine mechanische Regel wird erneut ausgeführt; ein abweichendes Ergebnis ist ein Fehler. Für nichtmechanisches judgement muss die eigene Richtlinie die betreffende Art von Datensatz zulassen. Behält ein Präsentierender einen unbequemen Beleg zurück, kann er den Schritt aufhalten. Ein Bestehen erschleicht er sich damit nicht.

Aus den Schritten folgen vier Zustände. Alles bestanden: released. Mindestens ein Fehler: refused. Kein Fehler, aber ein nicht ausführbarer Schritt: held. Eine ungültige eigene Prüfrichtlinie: no verdict. Der Bericht nennt die Schritte samt Gründen, die obere Zeitgrenze und Hashwerte der verwendeten Richtlinie und Vertrauensanker. Für das Gesamturteil untersagt der Entwurf Wörter wie „verified“, „valid“, „true“, „trusted“, „correct“, „proven“, „confirmed“ und „OK“. Damit trifft eine technische Regel die Stelle, an der aus einem Eintrag ein Abzeichen auf einer Benutzeroberfläche wird.

Auch released besagt genau dies: Der benannte Aussteller hat bis zur festgestellten Zeit dieses Ergebnis mit diesen Belegen und dieser Regel behauptet. Ob die ursprüngliche Aussage stimmt, bleibt eine eigene Frage. Eine nachvollziehbare Akte ist wertvoll; die Akte selbst ist kein Wahrheitsamt.

Quellen: Entwurf Wright, IETF-Status, RFC 9943, RFC 8259.