Zusammenfassung

  • RFC 3504 reparierte drei ausführbare Flächen von IOTP v1: DTD-Grammatik, Fortführung der ursprünglichen Transaktion nach Authentisierung und die Liste identifizierbarer IOTP-Signaturtypen.
  • Die Errata anzuwenden belegte Übereinstimmung mit der korrigierten Spezifikation, nicht erfolgreiche Authentisierung, Signierbefugnis, Zahlungsfreigabe, Abrechnung, Lieferung, Einführung oder Verbreitung.

In gewöhnlicher Prosa wirkt der Austausch von „neu gestartet“ gegen „fortgesetzt“ redaktionell. In einer Transaktionszustandsmaschine entscheidet das Wort, ob der Geschäftskontext am Authentisierungstor erhalten bleibt oder der Austausch scheinbar von vorn beginnt.

RFC 3504 erschien im März 2003 als Informational-Dokument. Es sammelte Fehler, die nach den IOTP-v1-Spezifikationen gefunden worden waren, vor allem in RFC 2801. IOTP war ein vom Zahlungssystem unabhängiger Handelsrahmen; Shop, Zahlungsabwickler, Lieferdienst und Kundenbetreuung konnten getrennten Organisationen gehören.

Diese Verteilung machte gemeinsame Bedeutung wichtig. Überschritt eine Transaktion Organisationsgrenzen, mussten Nachrichten festhalten, zu welchem Geschäft und welcher Handlung sie gehörten. Unterschiedliche Grammatik oder Zustandsübergänge konnten Partner mit derselben angeblichen RFC-Unterstützung verschieden handeln lassen.

Die erste Korrektur betraf PackagedContent. In der DTD waren die Typen von Name und Content vertauscht. Die Errata machte Name zu NMTOKEN und Content zu CDATA. Der Container wurde bei Authentisierungsaufgaben, Bestellungen, Marken, Zahlungsschemadaten, Quittungen und Lieferinformationen verwendet.

Aus der alten Erklärung erzeugter Code konnte die falsche lexikalische Einschränkung anwenden. Ein Wert war lokal gültig und beim Gegenüber ungültig. „RFC-2801-Unterstützung“ verschwieg, ob die gedruckte oder korrigierte DTD lief.

Die zweite Reparatur bestand aus wenigen Zeichen. Das Element Attribute hatte ( ANY ) statt ANY. Ein Validator darf aus ungültiger Grammatik keine verbindliche liberale Absicht erraten. Ohne gemeinsame Korrektur konnten Teams verschiedene Patches, abgeschaltete Prüfung oder inkompatible Ausnahmen wählen.

Eine korrigierte DTD zu bestehen blieb ein Strukturbeleg. Es bewies Namen, Attributklassen und Anordnung, nicht Wahrheit, Gegenparteibefugnis oder Geldbewegung.

Die dritte Korrektur betraf Zustand. Beim Kombinieren einer Authentisierungstransaktion mit einer anderen IOTP-Transaktion sagte RFC 2801 ursprünglich, die ursprüngliche Transaktion werde nach Erfolg neu gestartet. RFC 3504 änderte dies zu fortgesetzt.

Damit blieb die Identität beim Durchgang durch das Tor erhalten. Authentisierung war eine Bedingung innerhalb des größeren Austauschs und erzeugte keinen zweiten Kauf. Kennung, gesammelte Komponenten, Idempotenzprotokoll und Autorisierungsumfang konnten beim ursprünglichen Kontext bleiben.

„Fortgesetzt“ meldete nicht, dass Authentisierung gelungen war. Es bestimmte nur die Folge im Erfolgsfall. Das System brauchte weiterhin eine an Akteur, Verfahren, Herausforderung, Antwort und Transaktion gebundene Entscheidung. Bestätigte Identität autorisierte weder Zahlung noch Lieferung automatisch.

Auch die Signaturtypliste war unvollständig. Neben Angebot, Zahlung, Lieferung, Authentisierung und Ping fehlten AuthenticationStatus, InquiryRequest und InquiryResponse. RFC 3504 ergänzte sie und erlaubte ihre Nutzung durch jede Rolle.

Ein strenger alter Prüfer konnte einen nun zulässigen Typ ablehnen; ein zu liberaler konnte ohne gemeinsame Verzweigung akzeptieren. Typerkennung war aber keine Signaturprüfung. Eine gültige Signatur war wiederum kein Beleg für geschäftliche Befugnis, Bankabrechnung oder Lieferung.

RFC 3504 nannte die Fehler nicht besonders sicherheitsbezogen und warnte dennoch, dass falsche Implementierungen aus unkorrigierten Spezifikationsfehlern Sicherheit gefährden könnten. Betroffen war kein neuer Kryptografiealgorithmus, sondern die Grammatik, Transition und Dispatch-Tabelle sicherheitssensibler Verarbeitung.

Errata kann deshalb ausführbare Abhängigkeit sein. Inventare müssen Basisdokument, Korrektursatz, Parser- oder Schemaartefakt und Verhaltenstests erfassen. Zwei Konformitätsbehauptungen mit derselben RFC-Nummer können sonst verschiedene Maschinen beschreiben.

Auch Metadaten zeigen die Grenze. Der Kopf von RFC 3504 nennt nicht Updates: 2801. RFC-Editor-Erratum 2947, für eine Dokumentaktualisierung zurückgehalten, meint, die Beziehung müsse wegen normativer Änderungen erscheinen. Der Korrekturtext wirkte bereits auf Ausführung, obwohl die Dokumentbeziehung seine Kraft nicht vollständig zeigte.

Die ehrliche Belegkette beginnt bei Edition und Erratasatz, gefolgt von reproduzierbarem Build, akzeptiertem Dokument, erhaltener Transaktionsidentität, Authentisierungsentscheidung, erkanntem Signaturtyp, geprüfter Signatur, autorisierter Handlung und externem Zahlungs- oder Lieferbeleg.

Grammatik beantwortet Interpretierbarkeit, Fortsetzung den überlebenden Kontext und Typmarkierung den beanspruchten Signaturgegenstand. Keiner dieser Belege bedeutet einen bezahlten und erfüllten Kauf.

Quellen