Zusammenfassung

  • RFC 8259 empfiehlt eindeutige Objektnamen, weil Empfänger bei Wiederholungen auseinanderlaufen: Manche behalten das letzte Paar, andere brechen ab, wieder andere geben sämtliche Paare weiter.
  • Hat ein Parser die Wiederholungen bereits auf einen einzelnen Map-Eintrag reduziert, können Schema-Prüfung, Protokollierung oder Kanonisierung den verworfenen Wert nicht zurückholen.
  • Eine belastbare Eingangsgrenze bewahrt den Empfangsnachweis, vergleicht Namen nach der Escape-Auswertung und weist Mehrdeutigkeit vor jeder fachlichen Nutzung zurück.

Aus einer Folge wird eine Map

Auf der Leitung besteht ein JSON-Objekt aus einer Folge von Namen und Werten. Im Programm landet es meist in einer Map, in der jeder Schlüssel nur einen Wert bezeichnet. Bei eindeutigen Namen wirken beide Darstellungen gleich. Sobald ein Name wiederkehrt, braucht die Umwandlung eine Kollisionsregel: erstes Vorkommen, letztes Vorkommen, alle Vorkommen oder Fehler.

Diese Regel greift häufig vor dem Anwendungscode. Der Webserver oder ein Middleware-Stack parst den Body, das Gateway liest eine Berechtigung, der Dienst führt eine Operation aus und die Audit-Bibliothek serialisiert die bereits bereinigte Map. Verwenden diese Stationen verschiedene Regeln, können alle fehlerfrei laufen und dennoch unterschiedliche Mengen von Aussagen verarbeiten.

„Erfolgreich geparst“ beweist deshalb keine eindeutige Bedeutung. Es besagt nur, dass ein bestimmter Parser ein bestimmtes Ergebnis erzeugt hat.

Was RFC 8259 offenlässt

RFC 8259 sagt, dass die Namen innerhalb eines Objekts eindeutig sein SOLLTEN. Die Eindeutigkeit ist dort kein absolutes Verbot der Basissyntax. Ein Text mit wiederholten Namen kann also als JSON angenommen werden und trotzdem für ein Protokoll unbrauchbar sein, das eine stabile Aussage benötigt.

Die Folgen für die Interoperabilität formuliert das Dokument deutlich. Bei eindeutigen Namen stimmen Empfänger über die Zuordnung von Name und Wert überein. Andernfalls ist ihr Verhalten unvorhersehbar. Viele melden nur das letzte Paar, andere geben einen Fehler aus oder scheitern beim Parsen, manche liefern alle Paare einschließlich der Duplikate. Auch die Reihenfolge der Objektmitglieder wird den Aufrufern nicht von jeder Bibliothek gleich zugänglich gemacht.

Liest eine frühe Kontrolle das erste Vorkommen, führt der Dienst das letzte aus und protokolliert die normalisierte Map, kann das Archiv konsistent aussehen und trotzdem die Grundlage der ersten Entscheidung verbergen. Es braucht keinen erfundenen Angriff, um den Kontrollbruch zu erkennen: Die Komponenten teilen kein gemeinsames Datenmodell.

I-JSON macht aus Rat eine Zulassungsbedingung

RFC 7493 schränkt JSON im I-JSON-Profil ein. Objekte DÜRFEN KEINE Mitglieder mit doppelten Namen enthalten. Gleichheit wird nach der Verarbeitung maskierter Zeichen bestimmt. Zwei im Rohtext verschieden aussehende Namen können nach dem Dekodieren dieselbe Unicode-Zeichenfolge sein.

Ein bloßer Textfilter reicht daher nicht. Die Kontrolle muss jeden dekodierten Namen sehen, ohne dass eine gewöhnliche Map die Wiederholung vorher beseitigt. Ein Empfänger darf nichtkonforme I-JSON-Nachrichten zurückweisen oder ignorieren; ein Sicherheitsprotokoll kann vorschreiben, ihnen nicht zu vertrauen.

Der Zeitpunkt entscheidet. Erhält die Duplikatprüfung nur eine Map, auf die bereits „der letzte Wert gewinnt“ angewandt wurde, ist nichts mehr zu entdecken. Nötig ist ein Parser-Modus, der Wiederholungen meldet, oder eine Token-Schicht, die sämtliche Namen vor dem Aufbau der Map beobachtet.

Der erste Parser setzt unbemerkt Politik

Ohne ausdrückliche Regel bestimmt eine Bibliotheksvorgabe, welcher Wert Berechtigung, Preisbildung, Routing oder Speicherung erreicht. Eine als Komfort gedachte Datenstruktur übernimmt damit politische Entscheidungsmacht.

Ein robuster Eingang weist diese Macht einem Verantwortlichen zu. Er begrenzt Größe und Verschachtelung, dekodiert Namen nach einer einheitlichen Regel, erkennt Kollisionen nach der Escape-Verarbeitung und stoppt vor jeder Nebenwirkung. Empfangene Bytes oder wenigstens ihr kryptografischer Digest bleiben unter einer passenden Datenschutz- und Aufbewahrungsregel getrennt vom Anwendungsobjekt erhalten.

Eine erneute Serialisierung der Map ist kein gleichwertiger Nachweis. Sie zeigt, was der Parser übrig ließ, nicht zwingend alles, was eintraf.

Die JWS-Regel ist kein allgemeiner Freibrief

RFC 7515 verlangt eindeutige Namen für Parameter im JOSE Header. Ein JWS-Parser muss Duplikate zurückweisen oder einen JSON-Parser benutzen, der nur das lexikalisch letzte doppelte Mitglied liefert. Struktur und Verhalten sind ausdrücklich begrenzt.

Daraus folgt kein allgemeines „bei JSON gewinnt der letzte Wert“. Die Vorschrift gilt für JOSE Header Parameters, nicht automatisch für beliebige API-Bodies, Konfigurationsobjekte oder JWS-Payloads. Eine gültige JWS-Signatur weist zudem eine kryptografische Beziehung zwischen geschützten Bytes und Schlüssel nach; sie autorisiert nicht von selbst die dargestellte Handlung.

Auch eine spezifizierte Ausnahme funktioniert nur, wenn Gateway, Verifizierer, Dienst und Beobachtung dieselbe Semantik an derselben Grenze anwenden. Sonst bleiben konkurrierende Tatsachenbilder bestehen.

Kanonisierung heilt keinen verlustbehafteten Parse

RFC 8785 definiert mit JCS eine deterministische JSON-Darstellung. Vor dem Sortieren von Eigenschaften und der festgelegten Serialisierung primitiver Werte beschränkt JCS die Eingabe auf I-JSON; Objekte dürfen keine doppelten Property-Namen aufweisen.

Diese Reihenfolge ist wesentlich. JCS wählt nicht den Gewinner einer mehrdeutigen Eingabe, sondern arbeitet auf einem bereits eindeutigen Datenmodell. Entfernt ein toleranter Parser zuerst ein Vorkommen und kanonisiert JCS anschließend die Map, können die Bytes vollständig deterministisch sein. Deterministisch ist aber nur die Projektion des Parsers. Sie beweist kein einmaliges Vorkommen im Ursprung und stellt den verlorenen Wert nicht wieder her.

Für Signaturanwendungen ordnet RFC 8785 drei Schritte: JSON parsen und I-JSON-Konformität prüfen, die Regeln des jeweiligen Ökosystems validieren und dann die Signatur verifizieren. Scheitert ein Schritt, ist der Vorgang abzubrechen. Syntaktische Zulassung, fachliche Richtigkeit und kryptografische Echtheit bleiben getrennte Prüfungen.

Die gesamte Strecke muss denselben Test bestehen

Der technische Vertrag sollte fünf Zustände unterscheiden: empfangene Bytes, dekodierter Tokenstrom, zugelassenes duplikatfreies Objekt, validiertes Fachmodell sowie bei Bedarf kanonische Darstellung oder signierte Hülle. Jeder Übergang braucht einen Eigentümer, einen Fehlerausgang und eine Nachweisregel.

Testfälle sollten Wiederholungen in verschiedenen Verschachtelungstiefen sowie Namen enthalten, die erst nach Escape-Verarbeitung kollidieren. Sie müssen das echte Gateway, Middleware, Signaturpfad und Logging durchlaufen. Ein Fehlercode allein genügt nicht: Es darf keine Nebenwirkung geben, der Grund muss klassifiziert sein und der aufbewahrte Digest muss zum ursprünglichen Body passen.

Bei Wechseln von Parser, Laufzeit, Gateway oder Serialisierer laufen dieselben Konformitätsvektoren erneut. Ein unverändertes Fachschema garantiert keine unveränderte Kollisionssemantik.

Quellen