Zusammenfassung

  • RFC 3506 legte Gutscheine als Tupel <Aussteller, Versprechen, Inhaber> in einer logisch verwalteten gültigen Menge fest; Übertragung bedeutete die Umschreibung des Inhabers.
  • XML, Signatur, Smartcard und API konnten Beschreibung oder Verarbeitung tragen, bewiesen allein aber weder aktuelles Eigentum noch Verbrauch oder erbrachte Leistung.

Eine Datei wird beim Senden vervielfältigt. Ein Recht soll es nicht werden. RFC 3506 löste diesen Gegensatz nicht durch ein neues Dateiformat, sondern durch eine Mengenlehre für gültige Beziehungen. Der alte Inhaber konnte eine Kopie behalten; maßgeblich war, ob sein Tupel noch zur gültigen Menge gehörte.

Das im März 2003 als informativ veröffentlichte Dokument umfasste Treuepunkte, Coupons, Geschenkgutscheine, Eintrittskarten, Telefonkarten und Lieferscheine. Sie waren keine einheitliche Währung. Gemeinsam war ihnen, dass sie einen Anspruch auf eine Ware oder Dienstleistung digital darstellten.

I bezeichnete den Aussteller, P dessen Versprechen und H den Inhaber. Ein Gutschein war <I,P,H>. Das Versprechen konnte Rabatt, einen reservierten Sitz oder zeitlich begrenzten Zugang gewähren. Natürliche Sprache oder XML konnten es beschreiben. Doch eine Beschreibung von P sagte nicht, ob eine konkrete Instanz noch gültig und wem sie zugeordnet war.

Vier Rollen begrenzten die Macht. Der Aussteller schuf den Gutschein und garantierte seinen Inhalt. Der Inhaber besaß, übertrug und löste ihn ein. Der Einlöser prüfte ihn und erfüllte das Versprechen. Der VTS-Anbieter verhinderte mehrere gleichzeitige Inhaber oder unzulässige Mehrfachnutzung.

Das VTS verwaltete logisch die Valid Voucher Set, VVS. Anfangs war sie leer. Sie konnte in einer zentralen Datenbank, auf verteilten Smartcards oder auf mehreren Servern liegen. RFC 3506 machte die logische Exklusivität verbindlich, nicht den Standort oder Betreiber einer universellen Infrastruktur.

Ausgabe fügte <I,P,H> mit Absicht des Ausstellers hinzu. Übertragung schrieb es mit Absicht des bisherigen Inhabers zu <I,P,H'> um. Alte Dateien durften weiter existieren, ohne gültige Rechte zu behalten. Der Wert bewegte sich durch einen autorisierten Zustandswechsel.

Einlösung hatte zwei Formen. Präsentation zeigte das Tupel und ließ Eigentum bestehen, etwa bei einer wiederholt vorzuzeigenden Lizenz. Konsum entfernte das Tupel, machte es ungültig oder verringerte die Restnutzungen. Eine Eintrittskarte verlangte diese zweite Semantik. Wer beides nur „eingelöst“ nennt, verliert die Antwort auf die Frage, ob das Recht fortbesteht.

Die Sicherheitsanforderungen waren Folgerungen des Modells. Nur der Aussteller sollte gültig ausgeben. Nur der aktuelle Inhaber sollte Übertragung oder Einlösung auslösen. Veränderung war nur als autorisierte Inhaberumschreibung zulässig. Verbrauchte Instanzen durften nicht wieder eingelöst und einzelne Instanzen nicht gleichzeitig mehreren Inhabern zugeordnet werden.

Eine digitale Signatur genügte nicht. Ein nicht übertragbarer Gutschein konnte als signiertes <I,P,H> funktionieren. Bei Übertragung änderte sich H, wodurch die Signatur brach. Gegen doppelte Einlösung waren zusätzlich Online-Zustandsprüfung oder manipulationsgeschützte Geräte erforderlich. Authentischer Inhalt ist nicht dasselbe wie aktuelle Exklusivität.

Auch Privatsphäre blieb eine eigene Anforderung. Spätere Besitzer sollten frühere und aktuelle Inhaber nicht zwangsläufig sehen. Zugleich musste Vertrauen in Aussteller und Echtheit handhabbar sein. Ein System durfte genügend Nachweise gegen Reproduktion besitzen, ohne daraus ein öffentliches Bewegungsregister zu machen.

RFC 3506 lehnte die Annahme eines einzigen weltweiten Brokers oder Authentifizierers als zu fragil ab. Daraus folgte keine Pflicht zu einer bestimmten dezentralen Technik. Offline-Smartcards und Online-Dienste hatten andere Anforderungen. Ein einheitliches Übertragungsprotokoll erschien damals unpraktisch.

Stattdessen wurden drei Ebenen abgegrenzt: mögliches Übertragungsprotokoll, VTS-API und Generic Voucher Language. Ein kleiner gemeinsamer Zustandskern ließ spätere Implementierungen konkurrieren, ohne den Begriff des gültigen Rechts zu verändern.

RFC 4153 lieferte 2005 die XML-Beschreibung des Voucher Component. Sie erfasste Wert, Gegenstand, Einschränkungen, Aussteller und Anbieter. Zugleich stellte sie klar: Der Component ist kein Gutschein; viele Instanzen können dieselbe Beschreibung verwenden. Kopieren erzeugt Dokumente, keine Ansprüche.

Der Component galt als Vertrauenswurzel und musste vor Veränderung geschützt werden. Sicherer Transport oder XML-Signatur schützten die Bedeutung. Instanzeigentum, Reproduktionsschutz und Doppelverbrauch lagen gewöhnlich außerhalb. Eine intakte Beschreibung war kein VVS-Auszug.

RFC 4154 schuf eine gemeinsame API. Ausgabe fügte hinzu, Übertragung verschob, Konsum entfernte, Präsentation erhielt. Der Aufruf abstrahierte die Implementierung, ersetzte aber weder Authentisierung noch Zustandsbestätigung.

Der IESG-Hinweis warnte, dass die API einem VTS-Plug-in vertraute, aber kein Verfahren zur Anwendungsauthentisierung festlegte. Eine Ergänzung war nötig. Ein syntaktisch erfolgreicher Aufruf bewies daher weder Berechtigung noch Lieferung durch den Einlöser.

Die Belegkette lautet: Versprechen beschrieben, Aussteller und Anbieter vertraut, Instanz im VVS, Inhaber authentisiert, Handlung autorisiert, Zustand bestätigt, Einlöser akzeptiert, Leistung erbracht. Zwischen jedem Schritt kann die Realität abweichen.

Spätere Geräteeinführungsprotokolle verwenden ebenfalls das Wort Voucher, gehören aber zu einer anderen Familie. Ebenso beweist ein informativer RFC keine Verbreitung, Interoperabilität oder Marktwirkung. Dafür braucht es Implementierungs- und Betriebsbelege.

RFC 3506 bewahrte eine schlichte Grenze. Dateien können kopiert werden. Rechte müssen durch einen aktuellen, autorisierten Zustand exklusiv bleiben. XML erklärt, Signaturen schützen Aussagen, APIs fordern Änderungen an. Erst das gültige Tupel und anschließend die reale Erfüllung machen aus Daten einen brauchbaren Anspruch.

Sources