Zusammenfassung

  • Der individuelle Internet-Draft zum Canonical Action Identifier wurde am 28. September 2026 als Fassung -04 veröffentlicht. Für Objekte, die sowohl -03 als auch -04 akzeptieren, bleiben Suite, Digest und kanonische Form gleich.
  • Die neue Fassung verweigert einigen Objekten die Verarbeitung, obwohl sie nach -03 eine gültige CAID-Kennung hatten. Ohne dokumentierte Prüfregel lässt sich ein späterer Unterschied nicht sauber erklären.

Ein Konformitätstest findet einen unangenehmen Fall. Eine archivierte Aktion trägt eine Kennung, die ein früheres Programm erzeugt hat; das aktualisierte Programm weist das zugehörige Objekt zurück. Wer nur die Kennung kontrolliert, könnte einen Fehler im neuen Programm vermuten. Wer nur das heutige Prüfergebnis sieht, könnte die damalige Freigabe für unrechtmäßig erklären. Beides wäre voreilig. Die Fassung des Regelwerks kann darüber entscheiden, ob ein Objekt überhaupt zu einer vergleichbaren Kennung verarbeitet werden darf.

Ein neuer Ausschluss ist zunächst ein Unterschied der Prüfvoraussetzungen, kein Beleg für einen Angriff auf den Digest.

Iman Schrocks CAID-Vorschlag soll die materielle Identität einer Aktion über unterschiedlich kodierte Belege hinweg vergleichbar machen. Dazu gehören typisierte Aktionsobjekte, festgelegte Kanonisierung und Digest-Suites, kurze Kennungen und Definitionen der entscheidenden Felder. Eine Zustimmung, Delegation, Ausführung und spätere Prüfung könnten so auf dieselbe Aktion Bezug nehmen, ohne die lokalen Formate gleichzusetzen. Der Datatracker bezeichnet das Dokument aber ausdrücklich als individuellen Internet-Draft ohne formelle Stellung im IETF-Standardisierungsprozess.

Seine Veröffentlichung ist weder eine RFC-Verabschiedung noch ein Nachweis für interoperable Installationen oder einen realen Sicherheitsvorfall.

Der Änderungsabschnitt der Fassung -04 formuliert eine bemerkenswert enge Zusage. Die Verarbeitung wird als substanziell überarbeitet beschrieben. Die Suite, der Digest und die kanonische Form bleiben jedoch für jedes Objekt gleich, das beide Fassungen akzeptieren. Dieses „beide“ darf nicht verschwinden. Denn der gleiche Abschnitt nennt neu zurückgewiesene Eingaben und hält fest, dass mehrere davon unter -03 gültige CAIDs besaßen. Beispiele sind mehr als 64 Verschachtelungsebenen, eine kanonische Kodierung über 16.777.216 Oktett, Unicode-Nichtzeichen und Zeitstempel mit kleinem t oder z beziehungsweise einer Sekunde 60. Der Text behauptet nicht, dass alle Kennungen aus -03 verfallen. Er sagt aber ebenso wenig, dass jede alte Eingabe unverändert zulässig bleibt.

Man muss deshalb Gleichheit und Zulässigkeit auseinanderhalten. Der Digest beantwortet, welche kanonische Darstellung unter einer bestimmten Suite gebunden wird. Vor diesem Schritt entscheidet das Prüfmodell, ob das Objekt und seine Typdefinition den Regeln genügen. Eine unveränderte Kennung kann eine Änderung dieser Eintrittsbedingungen nicht dokumentieren. Umgekehrt löscht eine heutige Zurückweisung nicht den historischen Befund, dass eine frühere Fassung die Eingabe akzeptierte. Beide Ergebnisse sind nur sinnvoll, wenn ihre Regelversionen erhalten bleiben.

Ein Prüfbericht, der einen alten Befund mit dem aktuellen Zustand überschreibt, vernichtet gerade die Information, die er erklären sollte.

Eine weitere Neuerung betrifft die Definition des Aktionstyps. definition_sha256 bindet die für die Validierung maßgebliche Projektion der Definition. Ein Verifizierer kann einen erwarteten Definitionsdigest prüfen und bei Abweichung definition_mismatch melden. Der bloße Typname ist damit kein ausreichender Beweis dafür, dass zwei Domänen dieselben Pflichtfelder und Wertemengen zugrunde gelegt haben. Die vom Autor gepflegte Referenzregistrierung geht auf Version 5 über; die Datei der Version 4 bleibt bytegenau als Historie erhalten. Das ist nützlich für eine spätere Rekonstruktion. Die im Entwurf beantragten sieben IANA-Register sind dadurch aber nicht schon eingerichtet.

Auch die Eingabe von JSON-Text wird strenger gefasst, Zurückweisungsgründe werden in eine feste Reihenfolge gebracht und nichtkonforme Definitionen ausdrücklich behandelt. Doppelte Mitgliedsnamen im JSON-Text, einschließlich erst nach dem Entschlüsseln von Escape-Sequenzen gleicher Namen, werden zurückgewiesen. Dieses Beispiel ist relevant, aber die Meldung erschöpft sich nicht in der bekannten Mehrdeutigkeit von Parsern. Entscheidend für CAID als künftigen gemeinsamen Bezugspunkt ist das Zusammenspiel von Parser, Typdefinition, Regelversion und Kennung.

Fehlt einer dieser Teile, kann eine abweichende Entscheidung fälschlich als abweichende Aktion erscheinen.

Der Entwurf grenzt seine Wirkung selbst ein: CAID bescheinigt weder Identität noch Autorität, Berechtigung, tatsächliche Ausführung, Sicherheit oder rechtliche Verlässlichkeit. Sein Mapping-Profil kennt Gleichwertigkeit unter einem fixierten Profil, Nichtgleichwertigkeit und Unbestimmtheit. Unbestimmtheit ist kein stillschweigendes Ja. Die hier behandelte Frage liegt sogar vor der lokalen Vertrauensentscheidung: Welche Version hat das Objekt überhaupt als vergleichbar angenommen? Erst danach können Betreiber getrennt beurteilen, ob jemand handeln durfte und ob ein Ergebnis eingetreten ist.

Daniel Kade schlägt für künftige Anwendungen daher einen versionsgebundenen Prüfbeleg vor: Ursprungsobjekt oder belastbare Referenz, CAID und Suite, Parser- und Implementierungsfassung, Definitionsdigest beziehungsweise fixierter Registerstand, Annahme oder Zurückweisung mit Grund sowie eine verantwortete Migrationsentscheidung. Das ist eine redaktionelle Empfehlung für den Betrieb, kein im Draft vorgeschriebenes Übertragungsfeld. Der Beleg würde einen Regelwechsel sichtbar halten, ohne einen Identitätsvergleich zum Autorisierungsnachweis aufzublähen.

Quellen