Zusammenfassung

  • RFC 3354 verlangte für ein künftiges IOTP v2 frei vorschlagbare Handelsabfolgen; der Vorschlag erteilte aber weder Zahlungszustimmung noch bewies er die Ausführung eines Schritts.
  • Begrenzte Zustimmung zu künftigen Käufen, Versandmeldung, Autorisierung des Zahlungssystems, Abbuchung, Abrechnung und der Beleg für eine Reklamation blieben eigenständige Tatsachen.

Ein Lager meldet den Versand, und im Ablauf folgt als Nächstes eine Belastung. Auf einem Diagramm kann der Pfeil wie eine Anweisung wirken. Tatsächlich fehlen noch entscheidende Feststellungen: Wer hat den Versand gemeldet? Welchem Betrag und wie vielen Käufen stimmte der Kunde zu? Hat der Emittent autorisiert? Wurde das Geld eingezogen und abgerechnet? Reihenfolge beantwortet keine dieser Fragen.

RFC 3354 erschien im August 2002 als Informational-Dokument mit Anforderungen an eine geplante zweite Version des Internet Open Trading Protocol. IOTP v1 beschrieb elektronischen Handel durch Rollen, Blöcke und Nachrichten. Die nächste Stufe sollte diese Grundlage bewahren, aber das starre Muster von einer Zahlung gefolgt von einer Lieferung verlassen. Parteien sollten eine beliebige Folge von Transaktionsschritten vorschlagen können.

Das Schlüsselwort lautet „vorschlagen“. Ein Ablauf konnte mit einer Angebotsanfrage beginnen, ein externes Zahlungsprotokoll zwischen IOTP-Schritte setzen oder vor der Zahlungsanforderung auf Versand warten. Er beschrieb mögliche Abhängigkeiten. Er erteilte keinem Beteiligten allein durch seine Existenz die Befugnis, den nächsten Schritt auszuführen.

RFC 3354 war auch keine fertige IOTP-v2-Spezifikation. Das Dokument unterschied Funktionen, die enthalten sein sollten, mögliche Ergänzungen und ausgeschlossene Themen. Die Geschichte der IETF-Arbeitsgruppe TRADE verzeichnet den Abschluss des v2-Anforderungsmeilensteins. Das belegt die Fertigstellung der Anforderungen, nicht die Fertigstellung oder Verbreitung eines Protokolls.

Zu den Pflichtpunkten gehörten dynamische Handelsfolgen, ein Offer Request Block, verbesserte Problembehandlung, eine klarere Customer-Care-Rolle, nicht durch IOTP getunnelte Zahlungsprotokolle und serverbasierte Wallets. Ein Kunde sollte dem Support einen signierten Beleg vorlegen können. Der Beleg unterstützte die Reklamation, zwang aber niemanden zur Erstattung und bewies keine Abhilfebefugnis.

Auch eine Server-Wallet war ein Ort delegierter Funktionen, kein automatischer Identitätsnachweis. Ihre Existenz authentifizierte den aktuellen Benutzer nicht und erweiterte keine frühere Zustimmung. Externe Zahlungsprotokolle machten die Systemgrenze sichtbar: IOTP konnte den Vorgang koordinieren, während Authentifizierung, Autorisierung, Ablehnung und Abrechnung beim Zahlungssystem blieben.

Wiederholte oder laufende Zahlungen standen nur auf der Kann-Liste. Das Beispiel war bewusst begrenzt: Zustimmung zu einer endlichen Zahl künftiger Käufe, mit Gesamt- oder Einzelobergrenze. Eine nutzbare Erlaubnis braucht Zweck, Begünstigten, Währung, verbleibende Anzahl, Betragsgrenzen, Ablauf und Widerrufsstatus. Der Ablaufplan liefert diese Werte nicht.

Jede spätere Zahlungsanforderung muss erneut gegen die Erlaubnis geprüft werden. Ein Kauf kann innerhalb der Anzahl liegen und die Einzelgrenze überschreiten. Er kann klein sein und nach Fristablauf eintreffen oder einen anderen Händler betreffen. Die Abfolge kann die Prüfung anstoßen, aber ihr Ergebnis nicht aus der Position des Zahlungsblocks ableiten.

Das Versandbeispiel zeigt dieselbe Trennung von der Ereignisseite. Eine erweiterte Servernachricht konnte einem Delivery Handler erlauben, einem Payment Handler die Versendung der Ware mitzuteilen. Dies durfte Vorbedingung einer Kartenbelastung sein. Eine Vorbedingung ist kein Belastungsbefehl. Sie belegt nur die Behauptung eines identifizierten Akteurs im authentifizierten Umfang.

Die Meldung beweist weder physische Zustellung noch Annahme, Emittentenfreigabe, Einzug oder Abrechnung. Ein prüfbares System bewahrt die Versandbehauptung, die Regelbewertung für eine konkrete Zahlungsanforderung und die Antwort des Zahlungssystems getrennt. Nach einer Belastung erzeugen Einzug und Abrechnung weitere Belege. „Versand löste Zahlung aus“ ist eine Betriebszusammenfassung, keine Beweiskette.

Benachbarte RFCs verdeutlichen die Ebenen. RFC 2801 definierte IOTP-v1-Transaktionen, Rollen, Kennungen und idempotente Verarbeitung. Schutz vor Duplikaten ist keine Vollmacht für eine neue Abfolge. RFC 2802 ließ ein Manifest den Signaturumfang bestimmen. Eine gültige Signatur authentifiziert ausgewähltes Material, erzeugt aber keine fehlende Zustimmung.

RFC 2935 transportierte IOTP über HTTP; RFC 3106 vereinheitlichte Feldnamen für E-Commerce. Transport und gemeinsames Vokabular bestimmen keine geschäftliche Autorität. RFC 3275 definierte XML Signature, RFC 2246 schützte TLS-Kanäle. RFC 3354 stellte klar, dass IOTP selbst keine Vertraulichkeit bot und TLS oder IPsec brauchte, während Zahlungsschutz vom gewählten Zahlungssystem abhing.

Ein vertraulicher Kanal, signierter Inhalt, Kundenzustimmung und Zahlungsautorisierung sind daher verschiedene Eigenschaften. Auch zusätzliche Felder und Attribute erweiterten nur die Ausdrucksfähigkeit. Ein Feld „genehmigt“ bleibt eine Behauptung, bis Erzeuger, Signaturumfang, Entscheidungsgrundlage, Gegenstand und Gültigkeit bekannt sind.

Recht und Regulierung lagen außerhalb des Umfangs. Protokollkonformität bewies somit keine Vertragswirksamkeit, Verbraucherrechtskonformität oder Abbuchungsbefugnis in einer Rechtsordnung. Eine universelle Nachrichtengrammatik konnte lokale Institutionen nicht in technische Syntax verwandeln.

RFC 3538 ergänzte IOTP v1 um SET-Kontext. RFC 3867 definierte später eine Schnittstelle zwischen IOTP-Anwendungskern und Zahlungsmodulen. Diese Naht bestätigte, dass Koordination und Ausführung eigene Zustände, Fehler und Belege behalten konnten. Beide Dokumente liefern Kontext, aber keinen Nachweis einer ausgelieferten v2.

Der historische Wert von RFC 3354 liegt in seiner Trennschärfe. Die Abfolge war ein Plan, die Zustimmung zu künftigen Käufen eine begrenzte Erlaubnis, die Versandmeldung ein Ereignisbeleg, die Signatur eine Authentisierung bestimmter Inhalte, TLS ein Kanalschutz und das Zahlungssystem die Instanz für Autorisierung, Einzug und Abrechnung. Customer Care entschied erst danach über Abhilfe.

Dasselbe Problem erscheint heute, wenn ein Logistikstatus Geld freigibt oder ein Abo-Zeitplan eine Lastschrift startet. Je flexibler der Ablauf, desto wichtiger wird die eigene Autorität am unumkehrbaren Punkt. Das Protokoll darf den Weg vorschlagen; die Abbuchung braucht weiterhin ihren eigenen Beleg.

Sources