Zusammenfassung

  • RFC 3505 formulierte Anforderungen an eine gemeinsame Hierarchie für E-Commerce-Felder, damit Wallets, Formulare und Backends weniger raten und übersetzen mussten.
  • Das Dokument ersetzte ausdrücklich weder TLS, SET, EMV, XML noch IOTP: Ein verstandener Feldname bewies weder Händleridentität und Einwilligung noch Zahlungsfreigabe, Abrechnung oder Lieferung.

Das frühe Kassenproblem wirkte unspektakulär. Ein Händler nannte ein Feld „surname“, ein anderer last_name, ein dritter legte dieselbe Information in einer eigenen Hierarchie ab. Menschen konnten die Beschriftung lesen und ihre Daten erneut eintippen. Ein Software-Wallet konnte die Bedeutung einer Eingabebox nicht verlässlich erraten.

RFC 3505, im März 2003 als Informational-Dokument veröffentlicht, behandelte diese Reibung als Interoperabilitätsproblem. ECML Version 2 sollte hierarchisch geordnete Payment Processing Objects für Geschäfte zwischen Verbrauchern und Händlern sowie zwischen Unternehmen bereitstellen. Die frühere Arbeit an HTML-Formularen sollte auf XML, weitere Zahlungsarten und Backend-Systeme ausgedehnt werden.

Der gewünschte Umfang reichte von Kosten, Quittung, Währung, Karte und Zahlung bis zu Bank- und Telekommunikationsdaten. Elektronische Schecks, ACH, Mobiltelefon- und PDA-Zahlungen, Einkaufskarten und B2B-Wallets gehörten ebenfalls dazu. Zugleich blieb das Gestaltungsprinzip sparsam: Funktionen von Version 1.1 erhalten, nur nötige Felder ergänzen und die weitere Webarchitektur aus URIs, Schichten und Erweiterbarkeit nutzen.

Das Ergebnis war ein Vokabularvertrag. Erkennt ein Wallet den strukturierten Namen einer Lieferstadt, kann es einen Wert anbieten, ohne eine menschliche Beschriftung zu deuten. Erkennt ein Backend dieselbe Zahlungshierarchie, kann es den Begriff in seine Abläufe übersetzen. Gemeinsame Namen senken Übersetzungskosten, machen unabhängige Systeme aber nicht zu einer gemeinsamen Vertrauensdomäne.

RFC 3505 verwechselt diesen Nutzen nicht mit Sicherheit. ECML v2 sei keine Alternative zu TLS, SET, EMV, XML oder IOTP. Diese Technologien lieferten andere Fähigkeiten: Vertraulichkeit, nicht abstreitbare Transaktionen, Wahl eines Zahlungsschemas, Smartcards oder Handelsabläufe. ECML benannte Daten; es übernahm nicht sämtliche Kontrollen um sie herum.

Die Abgrenzung war wichtig, weil viele Felder empfindliche Informationen trugen. Namen, Adressen, Kontokennungen, Kartendaten und Zugangsinformationen konnten in größerem Maßstab freigegeben werden, sobald Wallets sie automatisch verstanden. Der Schutz hing deshalb von der Übertragungsinfrastruktur und von Anwendungen ab, die Daten speicherten oder herausgaben. Das Vokabular musste keinen Sicherheitsmechanismus erfinden, aber vor einer unkontrollierten Freigabe warnen.

Auch Wohlgeformtheit blieb ein begrenzter Beleg. DTD, mögliches Schema, geprüfte XML-Beispiele und der Vergleich mit älteren Vokabularen zeigten, dass Namen und Struktur der Grammatik folgten. Sie zeigten nicht, dass eine Kartennummer dem Nutzer gehörte, ein Preis ehrlich war, die Seite vom echten Händler stammte oder der Zahlungsdienst eine Belastung genehmigt hatte.

Ein verborgenes Übersetzungsfeld machte das Migrationsproblem sichtbar. Es konnte standardisierte Felder auf bestehende Händlerfelder abbilden und ECML ohne Umschreiben alter Software einführen. Das senkte Kosten, ließ sensible Daten aber über für Nutzer unsichtbare Zuordnungen wandern. Kompatibilität beantwortete die Frage nach dem Transport, nicht nach der Einwilligung.

RFC 4112 veröffentlichte 2005 die ECML-v2-Spezifikation. Sie definierte hierarchische Feldnamen, zeigte XML als Beispielsyntax und ließ andere Codierungen und Protokolle zu. Konformität betraf Namen und Hierarchie auf der Leitung, nicht die sichtbare Beschriftung. Ein Händler konnte deutsche Oberfläche und gemeinsame Maschinensemantik verbinden.

Die MIN-Werte der Tabelle waren Kapazitätspflichten: Ein Formular musste mindestens eine bestimmte Länge aufnehmen. Sie waren keine Gültigkeitsuntergrenzen. Namen, Telefonnummern oder Adressen außerhalb erwarteter Längen können legitim sein. Wer Kapazität als Identitätsprüfung verwendet, verwandelt einen Interoperabilitätsboden in eine falsche Regel über Menschen.

Die Modi query und assert beschrieben nur die Absicht einer Nachricht. Einer fragte nach einem Wert, der andere stellte ihn bereit. Der Feldname sagte, was gefragt oder behauptet wurde; er authentisierte weder den Fragenden noch machte er die Behauptung wahr. Vor einer Antwort brauchte das Wallet weiterhin eine eigene Richtlinie für Gegenpartei, Zweck und Zeitpunkt.

Im Web kennzeichnete Ecom_SchemaVersion die verwendete Feldversion. Software konnte dadurch die richtige Interpretation wählen. Auch als Pflichtfeld jeder ECML-Webtransaktion identifizierte es keinen Händler, prüfte keine Seite und schützte keinen Kanal. Versionserkennung war keine Endpunktauthentisierung.

Mehrseitige Formulare brachten ein weiteres Risiko. Automatisches Ausfüllen konnte persönliche Daten weitergeben, obwohl die geschäftliche Interaktion praktisch beendet war. Ecom_TransactionComplete war ein Hinweis, die Automatisierung bis zu einer neuen Freigabe anzuhalten. Er begrenzte Offenlegung und war keine Zahlungsquittung; er bewies weder Autorisierung noch Erfassung, Abrechnung, Erfüllung oder Annahme.

Der Sicherheitsabschnitt hielt die äußeren Abhängigkeiten ausdrücklich fest. Empfindliche Daten brauchten Vertraulichkeit und Schutz vor Veränderung. Authentizität konnte durch Objektsicherheit wie XML-Signaturen oder CMS beziehungsweise Kanalsicherheit wie TLS oder IPsec entstehen. Die Spezifikation nannte Möglichkeiten, definierte aber keinen universellen Schutz.

Die Kontrolle des Nutzers über Freigaben blieb notwendig. Auf öffentlichen Geräten sollte das Speichern persönlicher Informationen abschaltbar sein. Gespeicherte Daten brauchten Schutzoptionen. Verborgene und voreingestellte Werte konnten vor der Rücksendung böswillig verändert werden. Standardstruktur machte Verarbeitung berechenbar, nicht die Umgebung gutartig.

Eine ehrliche Belegkette beginnt daher bei „Feldname erkannt“. Danach folgen strukturelle Gültigkeit, authentisierte Gegenpartei, autorisierte Datenfreigabe, geschützte Übertragung, Anwendungsannahme, Zahlungsautorisierung, Clearing oder Abrechnung und schließlich Lieferung. Wer von den ersten beiden Schritten zu „bezahlt“ springt, macht Maschinenlesbarkeit zur kommerziellen Behauptung.

Auch Veröffentlichung beweist keine Einführung. RFC 3505 zeichnete Anforderungen auf; RFC 4112 wurde später Standards Track. Weder Browserübernahme noch Wallet-Nutzung, Händlerinteroperabilität, Datenschutzwirkung oder erfolgreiche Transaktionen folgen daraus. Dafür sind Implementierungs- und Betriebsnachweise erforderlich.

Der enge Beitrag von ECML blieb wertvoll. Das System verringerte eine Art von Reibung, ohne die Lösung aller Schichten zu beanspruchen. Gemeinsame Namen sind eine Fähigkeit. Ob diese Fähigkeit autorisiert, geschützt und wirtschaftlich abgeschlossen wurde, entscheiden andere Akteure und belegen andere Quittungen.

Quellen