Der in einem IN-OUT System für die Fahrt oder den Fahrtabschnitt beim Einstieg erhobene (anteilige) Fahrpreis, der in den Fällen erhoben werden kann, wo eine Abbuchung im Voraus aus einem ÖPV-Werteinheitenspeicher erfolgt oder direkt mittels einer elektronischen Geldbörse bezahlt wird.

Bei einem Admin-ASP handelt es sich um eine Person, die bei dem Sicherheitsdienstleister (TSI) als administrativer Ansprechpartner im KM- und PKI System für eine Organisation registriert ist. Der Admin-ASP ist eine Spezialisierung des Nutzer-ASP, da er zusätzliche administrative Rechte besitzt, d.h. er kann Nutzer-ASPs anlegen und sperren.

Die Aktivierung der ÖPV-Applikation auf dem Nutzermedium erfolgt in der Regel direkt im Zusammenhang mit der Ausgabe des Nutzermediums an den Kunden. Dazu wird mit Hilfe einer Ausgabetransaktion der Status der Applikation auf aktiv gesetzt, eine zeitliche Gültigkeit eingetragen und der Statusänderungszähler initialisiert. Die Applikation wird damit für den Kunden nutzbar.

Bereinigung des Datenbestandes des Aktionsmanagements; hiermit werden bereits ausgeführte Aktionsaufträge zur Ausgabe, Entsperrung oder Rücknahme aus dem Datenbestand der Aktionslisten im Aktionslisten System des Produktverantwortlicher entfernt, zu denen ein Kontroll- oder Sperrnachweis, nicht aber der erwartete Nachweis (der Ausgabenachweis oder Entsperrnachweis) beim Produktverantwortlichen (PV) eingetroffen ist. In dem Fall muss auch der Beauftragender Kundenvertragspartner informiert werden, der diese Aktion beauftragt hatte.

Eine Aktionsliste ist eine Liste von auszuführenden Aktionen am Akzeptanzterminal, die bei nächstem Kontakt mit einem Nutzermedium durchgeführt werden sollen. Sie wird vom System des Produktverantwortlichen zur Verfügung gestellt, von den ausführenden Kundenvertragspartnern abgerufen und dann auf deren Akzeptanzterminals verteilt.

Das Aktionsmanagement stellt eine Verwaltungseinheit in den Systemen von Beauftragender Kundenvertragspartner, Ausführender Kundenvertragspartner und Produktverantwortlicher dar. Aktionen sind bestimmte auszuführende Elemente, die meistens in Form einer Aktionsliste bereitgestellt werden müssen und einem Lebenszyklus unterliegen (daher müssen sie verwaltet werden). 

Der Aktionslistenservice wird vom System des Produktverantwortlichen angeboten. Über diesen Service laden Systeme der Ausführenden Kundenvertragspartner die Aktionslisten herunter und verteilen sie auf ihre Terminals. Auf der anderen Seite können Beauftragende Kundenvertragspartner Aktionen beim Produktverantwortlichen bestellen, wodurch sie auf dessen Aktionsliste gesetzt werden.

Gesamtheit der Gerätetechnik (Hardware und Software), die den Datenaustausch mit einem Nutzermedium ermöglicht (ISO/IEC 14443). Dies sind:

• Geräte für die Erstellung von kompletten Tickets (auf Chip oder/und Papier)
• Geräte für das Anlegen und/oder Komplettieren von Tickets
• Geräte für den Abruf von Informationen und den Druck von Tickets und Belegen/ Quittungen
• Geräte für das Laden von ÖPV-Werteinheiten
• Mobile Geräte für die Kontrolle und/oder Entwertung von Tickets
• Geräte für das Freischalten und die Personalisierung der Applikation

Es werden die Systemausprägungen System mit manueller Vorauswahl für Ticketkauf und IN-OUT System unterschieden.

Eine Applikation besteht aus Daten, Kommandos, Abläufen, Zuständen, Mechanismen, Algorithmen und Programmcode z.B. innerhalb einer Chipkarte oder eines Smartphones, um diese im Rahmen eines bestimmten Systems zu betreiben. Zu den Mechanismen zählen die Einbindung in die Sicherheitsarchitektur des jeweiligen Gesamtsystems sowie die Chipkarten Übertragungsprotokolle.

Der Applikationsherausgeber (AH) hält den Anwendungsvertrag für die Nutzung der ÖPNV-Applikation. Er autorisiert den Weiterverkauf der Applikation durch einen Kundenvertragspartner an einen Kunden. Er definiert die Anwendungsregeln und gewährt einem Produktverantwortlichen, einem Kunden-Vertragspartner und einem Dienstleister das Recht zur Teilnahme an den EFM-Systemen, stellt ihnen die erforderlichen Kennungen zur Verfügung und gewährt das Recht zur Nutzung der Schlüssel des Applikationsherausgebers. Er berechtigt Kundenvertragspartner zur Ausgabe von Applikationen im Nutzermedium. Darüber hinaus ist er verantwortlich für die Bereitstellung von Informationen über die Instanz-ID der Anwendung (identifiziert ein Nutzermedium) im Falle von Anfragen bezüglich defekter Nutzermedien. Der Applikationsherausgeber implementiert ein Lifecycle Management für alle Applikations-Instanzen.

Applikations-Kennung / Application Identifier

Kennung der Applikation, die sich auf dem Nutzermedium befindet. Da z.B. auf einer Chipkarte mehrere Applikationen existieren können, dient die Kennung dazu, die richtige (in diesem Fall die ÖPNV-) Applikation auswählen zu können.

ASM Tool

Das ASM-Tool (Applikations- und Sicherheits-Management-Tool) ist das zentrale Service- und Verwaltungssystem für das (((eTicket Deutschland. Es unterstützt die wesentlichen Aufgaben des Scheme Managers für das Applikations- und Sicherheitsmanagement im (((eTicket Deutschland wie

• Serviceportal zur Registrierung für das (((eTicket Deutschland

• Kundenservice für Verkehrsunternehmen und Hersteller

• Verwaltung von Kunden, Herstellern und Teilnehmer am (((eTicket

Deutschland

• Bereitstellung von KA-Dokumenten

• Bestellung von KA-Sicherheitskomponenten, Bestellbearbeitung und -prüfung

sowie einen Teil der Sicherheitsmonitoring-Prozesse

und es repräsentiert das KA-Referenzsystem des Applikationsherausgebers (AHS)

Das ASM-Tool ist zu erreichen über https://asmtool.eticket-deutschland.de/asm-toolextern.

Asymmetrische Kryptographie / Asymmetric Cryptography

Asymmetrische Kryptoverfahren verwenden Schlüsselpaare, die aus einem öffentlichen Schlüssel (englisch public key) und einem privaten Schlüssel (engl. private key) bestehen. Der öffentliche Schlüssel ist nicht geheim, er soll möglichst vielen anderen Benutzern bekannt sein. Mit ihm können öffentliche Operationen durchgeführt werden, also Nachrichten verschlüsselt oder digitale Unterschriften geprüft werden. Dabei ist es wichtig, dass ein öffentlicher Schlüssel eindeutig einem Benutzer zugeordnet werden kann. Dieses wird mit einem Zertifikat gewährleistet. Um einen verschlüsselten Text wieder zu entschlüsseln oder eine Nachricht zu signieren, wird der private Schlüssel benötigt. Im Gegensatz zu symmetrischen Verfahren, bei denen sich mehrere Benutzer einen Symmetrischen Schlüssel teilen, verfügt bei asymmetrischen Verfahren nur ein Benutzer über den privaten (geheimen) Schlüssel. Dieser Umstand ermöglicht es erst, eine Signatur eindeutig einem Benutzer zuzuordnen.

Ausführender Kundenvertragspartner / Executing Customer Contract Partner

Der ausführende Kundenvertragspartner (aKVP) lässt die Ausführung einer Aktion mit einem Nutzermedium an einem seiner Terminals zu. Dafür muss er über Aktionslisten an den Aktionslistenservice und Aktionsmanagement des Produktverantwortlichen angeschlossen sein. Er kann gleichzeitig Beauftragender Kundenvertragspartner (bKVP) sein.

Ausgabe der Applikation / Issuing the Application

Es kann mehrere Stellen geben, die vom Applikationsherausgeber berechtigt sind, die Applikation gemäß der vorgegebenen Spezifizierung auf einem Nutzermedium anzulegen und/oder diese für die Nutzung zu aktivieren. Die Ausgabe kann auch über den Vertrieb erfolgen. Sie wird immer über einen Kundenvertragspartner erfolgen. Die Applikation auf dem Nutzermedium wird auch als ÖPV-Applikation bezeichnet.

Autoload

Bei Werteinheitenberechtigung: Automatisches Aufladen mit einer vereinbarten Menge an ÖPV-Werteinheiten zu einem bestehenden Kundenvertrag in Abhängigkeit von der Erfüllung vertraglich vereinbarter Kriterien (z. B. Erreichung bzw. Unterschreitung eines Mindestbetrages). Dies erfolgt für im Nutzermedium gespeicherte ÖPV-Werteinheiten an jedem Akzeptanzterminal, welches das Unterschreiten des Mindestladebetrages feststellt und die Autoload-Funktion unterstützt. Alle Ladebeträge werden in das Hintergrundsystem des Kundenvertragspartners übermittelt.

Bei Prepaid-Konto (((eBezahlberechtigung: Für mit einer über ein kreditwirtschaftliches Konto des Kunden angerechnete sogenannte Prepaid-Konto-Berechtigung erfolgt das Nachladen vom Konto des Kunden gesteuert über das Hintergrundsystem des Primär-Kundenvertragspartners.

Der Primär-Kundenvertragspartner ist für die Rechnungslegung gegenüber dem Kunden zuständig und nimmt den Finanzausgleich gegenüber demjenigen, der die Aufladung realisiert hat, vor. Eine manuelle Angabe der Menge der aufzuladenden Beförderungsberechtigungsoptionen ist nicht möglich.

Im Anschluss an das Autoload erfolgt eine dem Wert der aufgeladenen Fahrberechtigungsoptionen entsprechende Forderungsbuchung auf dem zum Kundenvertrag hinterlegten Abrechnungskonto.

Automatisierte Fahrberechtigung / IN-OUT Entitlement

Die automatisierte Fahrberechtigung (AFB) berechtigt den Kunden, Leistungen des ÖPV in Anspruch zu nehmen. Sie regelt, wie der Kunde die Leistungsinanspruchnahme finanziell ausgleicht. Voraussetzung für den Einsatz der AFB ist die Existenz einer (((eBezahlberechtigung auf dem Nutzermedium. Damit ist die AFB eine Nutzungsart der (((eBezahlberechtigung. Im Verlauf der Nutzung der Berechtigung im Rahmen der Erfassung von Ein- und Ausstiegsdaten in IN-OUT Systemen entsteht ein Leistungsnachweis.

Merkmal der AFB ist, dass sie den Rahmen für die Inanspruchnahme sowie die Berechnung des Leistungsentgeltes definiert. AFB werden als kontobasierte Zahlmethode mit prepaid (PEB) oder postpaid (POB) Verfahren im Hintergrundsystem oder als nutzermediumbasierte Zahlmethode (WEB, kann anonym sein) in KA-Systemen ausgegeben.

Kennung der Applikation, die sich auf dem Nutzermedium befindet. Da z.B. auf einer Chipkarte mehrere Applikationen existieren können, dient die Kennung dazu, die richtige (in diesem Fall die ÖPNV-) Applikation auswählen zu können.

Das ASM-Tool (Applikations- und Sicherheits-Management-Tool) ist das zentrale Service- und Verwaltungssystem für das (((eTicket Deutschland. Es unterstützt die wesentlichen Aufgaben des Scheme Managers für das Applikations- und Sicherheitsmanagement im (((eTicket Deutschland wie

• Serviceportal zur Registrierung für das (((eTicket Deutschland

• Kundenservice für Verkehrsunternehmen und Hersteller

• Verwaltung von Kunden, Herstellern und Teilnehmer am (((eTicket Deutschland

• Bereitstellung von KA-Dokumenten

• Bestellung von KA-Sicherheitskomponenten, Bestellbearbeitung und -prüfung

sowie einen Teil der Sicherheitsmonitoring-Prozesse

und es repräsentiert das KA-Referenzsystem des Applikationsherausgebers (AHS). Das ASM-Tool ist zu erreichen über https://asmtool.eticket-deutschland.de/

Asymmetrische Kryptoverfahren verwenden Schlüsselpaare, die aus einem öffentlichen Schlüssel (englisch public key) und einem privaten Schlüssel (engl. private key) bestehen. Der öffentliche Schlüssel ist nicht geheim, er soll möglichst vielen anderen Benutzern bekannt sein. Mit ihm können öffentliche Operationen durchgeführt werden, also Nachrichten verschlüsselt oder digitale Unterschriften geprüft werden. Dabei ist es wichtig, dass ein öffentlicher Schlüssel eindeutig einem Benutzer zugeordnet werden kann. Dieses wird mit einem Zertifikat gewährleistet. Um einen verschlüsselten Text wieder zu entschlüsseln oder eine Nachricht zu signieren, wird der private Schlüssel benötigt. Im Gegensatz zu symmetrischen Verfahren, bei denen sich mehrere Benutzer einen Symmetrischen Schlüssel teilen, verfügt bei asymmetrischen Verfahren nur ein Benutzer über den privaten (geheimen) Schlüssel. Dieser Umstand ermöglicht es erst, eine Signatur eindeutig einem Benutzer zuzuordnen.

Der ausführende Kundenvertragspartner (aKVP) lässt die Ausführung einer Aktion mit einem Nutzermedium an einem seiner Terminals zu. Dafür muss er über Aktionslisten an den Aktionslistenservice und Aktionsmanagement des Produktverantwortlichen angeschlossen sein. Er kann gleichzeitig Beauftragender Kundenvertragspartner (bKVP) sein.

Es kann mehrere Stellen geben, die vom Applikationsherausgeber berechtigt sind, die Applikation gemäß der vorgegebenen Spezifizierung auf einem Nutzermedium anzulegen und/oder diese für die Nutzung zu aktivieren. Die Ausgabe kann auch über den Vertrieb erfolgen. Sie wird immer über einen Kundenvertragspartner erfolgen. Die Applikation auf dem Nutzermedium wird auch als ÖPV-Applikation bezeichnet.

Bei Werteinheitenberechtigung: Automatisches Aufladen mit einer vereinbarten Menge an ÖPV-Werteinheiten zu einem bestehenden Kundenvertrag in Abhängigkeit von der Erfüllung vertraglich vereinbarter Kriterien (z. B. Erreichung bzw. Unterschreitung eines Mindestbetrages). Dies erfolgt für im Nutzermedium gespeicherte ÖPV-Werteinheiten an jedem Akzeptanzterminal, welches das Unterschreiten des Mindestladebetrages feststellt und die Autoload-Funktion unterstützt. Alle Ladebeträge werden in das Hintergrundsystem des Kundenvertragspartners übermittelt.

Bei Prepaid-Konto (((eBezahlberechtigung: Für mit einer über ein kreditwirtschaftliches Konto des Kunden angerechnete sogenannte Prepaid-Konto-Berechtigung erfolgt das Nachladen vom Konto des Kunden gesteuert über das Hintergrundsystem des Primär-Kundenvertragspartners.

Der Primär-Kundenvertragspartner ist für die Rechnungslegung gegenüber dem Kunden zuständig und nimmt den Finanzausgleich gegenüber demjenigen, der die Aufladung realisiert hat, vor. Eine manuelle Angabe der Menge der aufzuladenden Beförderungsberechtigungsoptionen ist nicht möglich. Im Anschluss an das Autoload erfolgt eine dem Wert der aufgeladenen Fahrberechtigungsoptionen entsprechende Forderungsbuchung auf dem zum Kundenvertrag hinterlegten Abrechnungskonto.

Die automatisierte Fahrberechtigung (AFB) berechtigt den Kunden, Leistungen des ÖPV in Anspruch zu nehmen. Sie regelt, wie der Kunde die Leistungsinanspruchnahme finanziell ausgleicht. Voraussetzung für den Einsatz der AFB ist die Existenz einer (((eBezahlberechtigung auf dem Nutzermedium. Damit ist die AFB eine Nutzungsart der (((eBezahlberechtigung. Im Verlauf der Nutzung der Berechtigung im Rahmen der Erfassung von Ein- und Ausstiegsdaten in IN-OUT Systemen entsteht ein Leistungsnachweis.

Merkmal der AFB ist, dass sie den Rahmen für die Inanspruchnahme sowie die Berechnung des Leistungsentgeltes definiert. AFB werden als kontobasierte Zahlmethode mit prepaid (PEB) oder postpaid (POB) Verfahren im Hintergrundsystem oder als nutzermediumbasierte Zahlmethode (WEB, kann anonym sein) in KA-Systemen ausgegeben.

Eine Berechtigung basiert auf in einer Applikation hinterlegten Daten, die zur Inanspruchnahme einer ÖPV-Leistung berechtigen. Eine Berechtigung besteht unter anderem aus einer eindeutigen ID und einem Gültigkeitszeitraum. Diese in der Applikation hinterlegten Daten können in Form eines Elektronischen Fahrscheins oder einer (((eBezahlberechtigung vorliegen. Ein Elektronischer Fahrschein stellt eine Berechtigung in Sinne einer Fahrberechtigung dar.

Die (((eBezahlberechtigung verwendet auf dem Nutzermedium die gleichen Datenstrukturen, ist aber noch keine Fahrberechtigung, sondern nur die Grundlage und Voraussetzung für den Einsatz in IN-OUT Systemen (und kann dort als Automatisierte Fahrberechtigung (AFB) genutzt werden). Die eigentliche Berechtigung für die aktuelle Fahrt entsteht aber erst durch einen Check-In Vorgang zusammen mit dieser dann als AFB genutzten (((eBezahlberechtigung.

Ist die Berechtigung ein Elektronischer Fahrschein (EFS), so enthält sie weitere tarifliche Informationen (Produkt, räumliche Gültigkeit, etc.). Der EFS kann anonym oder Personengebunden sein. Anonym bedeutet, dass der Besitz des EFS ausreicht und jeder ihn verwenden darf. Personengebunden bedeutet, dass der EFS nur von einer bestimmten Person verwendet werden darf. Für einen personengebundenen EFS werden zusätzliche Identifikationsmittel bei der Kontrolle herangezogen.

Handelt es sich um eine (((eBezahlberechtigung, so wird über den Typ festgelegt, ob diese kontobasiert ist (mit prepaid- oder postpaid-Option) oder in Verbindung mit Werteinheiten auf dem Nutzermedium verwendet wird. Bei der (((eBezahlberechtigung gibt es die Unterscheidung anonym / nicht anonym. Anonyme (((eBezahlberechtigungen sind nur in der Variante der Werteinheiten auf dem Nutzermedium möglich ohne die Autoload Funktion (die ein Konto erfordert).

Kontobasierte (((eBezahlberechtigungen sind nie anonym, da die Kundenidentität im Hintergrundsystem bekannt ist.

Der beauftragende Kundenvertragspartner (bKVP) veranlasst eine Aktion (für eine spätere Interaktion mit einem Nutzermedium) für seinen Kunden, indem er einen Aktionsauftrag an den Aktionslistenservice des Produktverantwortlichen sendet.

Der Beförderungsvertrag ist im Transportwesen ein Vertrag, der die Beförderung von Personen, (ggf. zuzüglich Gepäck) zum Inhalt hat. Im ÖPV kommt fast immer der Personenbeförderungsvertrag zum Tragen. Art und Weise wie, d. h. mit welchem Zahlungsmittel, die Forderung für die Erbringung der Beförderungsleistung gegenüber dem Kunden ausgeglichen wird.

Eine Certification Authority (CA; Zertifizierungsstelle) ist eine Organisation, die digitale Zertifikate herausgibt. Ein digitales Zertifikat dient dazu, einen bestimmten öffentlichen Schlüssel einer Person oder Organisation zuzuordnen (Zertifikatsinhaber). Diese Zuordnung wird von der Zertifizierungsstelle beglaubigt, indem sie sie mit ihrer eigenen digitalen Unterschrift versieht.

Die Zertifizierungsstelle trägt dabei die Verantwortung für die Bereitstellung, Zuweisung und Integritätssicherung der von ihr ausgegebenen Zertifikate. Damit agiert die CA als vertrauenswürdige Drittpartei (Trusted Third Party) gegenüber dem Zertifikatsinhaber und der Partei, die sich auf die Echtheit des Zertifikats verlässt. Die CA bildet den Kern einer Public-Key-Infrastruktur.

Check-In nach Fahrtfortsetzung ist die Ausführung eines erneuten Check-In nach einem bereits erfolgten Check-In Check-Out infolge eines Umstiegs. Das Terminal ermittelt den Check-In nach Fahrtfortsetzung nach Vorgabe des Produktverantwortlichen, dessen Tarifberechnung der Fahrt/Fahrtenkette zugrunde liegt, z.B. durch Erkennen Check-InOrt = (vorhergehender) Check-Out-Ort + Zeitkriterium, in dem ein Umstieg akzeptiert wird).

Siehe auch IN-OUT System.

Diejenigen Mechanismen, die in der Chipkartenwelt das Senden und Empfangen von Daten zwischen Terminal und Chipkarte regeln. Sie beschreiben im Detail die benutzten OSI-Protokollschichten, den Datenaustausch im Gutfall, Fehlererkennungsmechanismen und Reaktionsmechanismen bei Fehlern.

Das (Forderungs-)Clearing schafft die Voraussetzungen zur Durchführung einer Leistungsvergütung zwischen den beteiligten Instanzen. Das Clearing kann auf der Basis der bereitgestellten komprimierten Leistungsdaten die Abrechnungsdaten für einen einzelnen Nutzer zusammenstellen, die letztlich einen Forderungsausgleich ermöglichen.

1. Sammeln und Sortieren von Daten.

2. Datenweiterleitung (Netzwerk)

3. Prüfung von Daten (Klären)

(s. ÖPV-Dienstleister / PT Service Operator)

EFM Produkte werden vom Produktverantwortlichen definiert und können jeweils ein oder mehrere Tarifprodukt(e) für die Verwendung im elektronischen Fahrgeld Management abbilden. Sie müssen für diesen Produktverantwortlichen eine eindeutige Nummer besitzen und zusammen mit der Organisations-ID des Produktverantwortlichen im gesamten EFM System eindeutig sein.

Ein EFM Produkt wird definiert hinsichtlich seiner

• Nutzungsregeln

• Preisbildung

Das EFM Produkt legt gleichzeitig als Produkt-Template fest, wie die Parameter des Produktes in Form der spezifizierten Datenelemente auf dem Nutzermedium abgelegt werden sollen. Des Weiteren wird definiert wie

• mit Hilfe dieser Parameter die Preisberechnung erfolgen muss

• mit Hilfe der Daten in der Berechtigung eine automatische Kontrolle durchgeführt wird

• mit Hilfe der Daten die Kontrolle und automatisierte Preisberechnung in IN-OUT Systemen erfolgen muss

Der elektronische Fahrschein beschreibt einen auf einem Kundenmedium abgelegten vollwertigen Fahrschein, der (nach einer ggf. erforderlichen Entwertung) in dieser Form durch einen Fahrgast unmittelbar für eine Reise im ÖPV nutzbar ist, wobei die räumliche und zeitliche Gültigkeit mit Nutzungsbeginn feststeht und im Nachhinein auch nicht mehr verändert wird.

Ein Elementarprozess bezeichnet eine fachlich zusammenhängende Menge von Transaktion(en), Aktionen, Nachrichten und Prüfungen, die auf unterschiedliche Systeme verteilt sein können und jeweils einzelnen Anwendungsfällen zugeordnet werden. Ein Elementarprozess enthält somit in der Regel mehrere Anwendungsfälle.

Applikationen und Berechtigungen können entsperrt werden und können dann im Rahmen von (((eTicket Deutschland wiederverwendet werden. Das Entsperren erfolgt aufgrund einer Statusänderung bei der Applikation oder Berechtigung auf dem Nutzermedium zurück auf den Status „aktiv“. Dadurch werden Applikation oder Berechtigung wieder nutzbar.

Ein Entsperren ist nur an autorisierten Terminals des Kundenvertragspartners möglich.

Wird die Sperrmarkierung mit Hilfe einer Entsperrung in einer Applikation wieder entfernt, so wird ein Entsperrnachweis an das Hintergrundsystem des Kundenvertragspartners gesendet. Wird die Sperrmarkierung mit Hilfe einer Entsperrung in einer Berechtigung wieder entfernt, so wird ein Entsperrnachweis an das Hintergrundsystem des Kundenvertragspartners gesendet und zusätzlich an den Produktverantwortlichen.

Entwertung im Sinne des ÖPV bedeutet das Verwenden eines Tickets, welches für eine einmalige Nutzung zu einem beliebigem, dem Tarifprodukt des Tickets entsprechenden Zeitpunkt vorgesehen war. Das Verwenden des Tickets wird durch einen Stempel (Papierticket) oder einen elektronischen Nachweis in einem Elektronischen Fahrschein attestiert, was wiederum die Entwertung bewirkt, da das Ticket dadurch nicht noch einmal verwendet werden kann. Andererseits wird das Ticket erst durch diesen Vorgang für die aktuelle Fahrt gültig.

Erfassung bedeutet das Aufzeichnen von In-Out Vorgängen (z.B. Check-In und CheckOut) in IN-OUT Systemen sowie deren Sammeln und Weiterleiten an den Produktverantwortlichen. Ein Nachweis dazu wird auf dem Nutzermedium hinterlegt. In diesem Kontext ist immer die technische Erfassung von Daten zur Leistungsberechnung gemeint, nicht z.B. eine statistische Erfassung von Fahrgastzahlen, o.ä. Für die Erfassung ist der ÖPV-Dienstleister verantwortlich. Denn dieser muss die von ihm erbrachte Leistung nachweisen können und dazu eine Erfassung durchführen. Damit erfüllt der ÖPV-Dienstleister einen Teil aus der Rolle der Erfassung und Weiterleitung (Collection and Forwarding) nach ISO 24014 und ist verantwortlich für die Leistungserfassungs- und Einnahmedaten aus der Nutzung von Berechtigungen bei Inanspruchnahme von Transportdienstleistungen der ÖPV-Unternehmen.

Hinweis: Auch Kontrollvorgänge können als Erfassung verstanden werden, sind aber ein eigener Anwendungsfall, siehe Kontrolle.

Daten, die von Erfassungsterminals erzeugt und an das Hintergrundsystem übertragen werden. 

Sammelbegriff für alle Arten von peripheren Geräten zur Erfassung der Nutzung von Beförderungsleistungen in Fahrzeugen und an Haltestellen in IN-OUT Systemen. Sie gehören zur Gruppe der Akzeptanzterminals.

Erhöhtes Beförderungsentgelt (EBE) wird fällig, wenn ein Kunde keinen gültigen Fahrausweis (Fahrschein) vorweisen kann. 

s. Berechtigung / Entitlement

Zeitpunkt der (automatischen) tariflichen Bestimmung des Wertes der ÖPV-Leistung (Preisermittlung) und der Belastung des Wertes entsprechend der hinterlegten Zahlungsmethode (Bezahlzeitpunkt). Die Prozesse für Preisermittlung und Bezahlen sind entkoppelt, auch wenn insbesondere bei der pre-priced-Preisermittlung die Bezahlung unmittelbar danach erfolgt. Je nach Tarif sind nur bestimmte Bezahlarten möglich.

Es gibt folgende Preisermittlungsvarianten:

• pre-priced: Der Fahrpreis wird vor der Fahrt oder Reise ermittelt. Normalerweise bedeutet dies, dass ein Ticket vor Fahrtantritt erworben wird. Gültige Bezahlarten sind:

o Belastung auf eine (((eBezahlberechtigung

o sofortige Bezahlung durch Bargeldmittel,

o Belastung auf eine Kreditkarte, Debitkarte, Geldkarte, etc.

• trip-priced: Der Fahrpreis wird direkt nach dem Ende einer Fahrt (i.d.R bei fälligem CheckOut) festgelegt. Gültige Bezahlart im Rahmen der Kernapplikation ist

o Belastung auf einer Werteinheitenberechtigung (WEB)

• post-priced: Der Fahrpreis wird eine bestimmte Zeit nach der Reise festgelegt, normalerweise in einem Hintergrundsystem. Somit erfolgt auch die Bezahlung einer ÖPNVLeistung erst eine Zeit nach der Inanspruchnahme der Leistung. Nur das postpriced-Verfahren ermöglicht eine Bestpreis-Berechnung für den Kunden. Gültige

Bezahlarten sind:

o Belastung auf

o Postpaid-Konto oder Prepaid-Konto des Kundenvertragspartners

Hinweis: Der Bezahlzeitpunkt hat nichts mit der Bezahlart des Kunden mit Hilfe seiner (((eBezahlberechtigung zu tun (auch dort werden die Begriffe prepaid und postpaid verwendet). Wie man beim post-priced-Verfahren erkennt, kann eine nachträglich Bezahlung über ein Prepaid-Konto und der entsprechenden Prepaid-(((eBezahlberechtigung erfolgen.

Eine Fahrt ist die Nutzung eines Verkehrsmittels vom Einstieg bis zum Verlassen.

Als Fahrtabschnitt wird ein Teil einer Fahrt bezeichnet. Er kann durch die Nennung von zwei Haltestellen gekennzeichnet werden.

Der Fehlbedienungszähler wird bei Eingabe einer falschen PIN hochgezählt. In der Regel darf die PIN dreimal falsch eingegeben werden, danach wird das PIN geschützte Objekt (hier meistens eine Chipkarte) gesperrt und muss über eine PUK wieder entsperrt werden. Wird die PIN richtig eingeben, so wird der Fehlbedienungszähler wieder auf 0 gesetzt.

Der Fremd-Kundenvertragspartner führt Transaktionen mit Applikationen oder Berechtigungen von Primär-Kundenvertragspartnern aus, für die er durch die Nutzungsbedingungen autorisiert ist. In erster Linie gilt das für den Einsatz von (((eBezahlberechtigungen, die vom Primär-Kundenvertragspartner ausgegeben wurden und beim Fremd-Kundenvertragspartner für die Inanspruchnahme von ÖPV Leistungen verwendet werden sollen (z.B. Kauf eines Tickets im Umfeld des Fremd-Kundenvertragspartner mit einer (((eBezahlberechtigung des Primär-Kundenvertragspartners.

Siehe auch Rollenmodell in der Spec-Main (für KA 1.X Spec HD BOM).

Eine Gemeinsame Servicestelle (GSS) stellt ein Hintergrund-Teilnehmersystem dar, welches rollenspezifische Aufgaben der angeschlossenen Teilnehmer an zentraler Stelle übernimmt und abarbeitet. Zusätzlich werden dort vorverarbeitete Nachrichten an KA-Teilnehmersysteme via Interoperabilitätsnetzwerk weitergeleitet (Vermittlungsfunktion).

Alle Computersysteme eines elektronischen Fahrgeldmanagements, welche die Verarbeitung und Verwaltung von Daten ab der Hierarchie der Akzeptanzterminals übernehmen.

Die Initialisierung der ÖPV-Applikation legt die für die Applikation definierte Datenstruktur auf dem Chip an und füllt Datenfelder mit vordefinierten Werten. Der Applikationsstatus erhält den Anfangswert "initialisiert". Die Applikation ist in diesem Zustand noch nicht nutzbar. Sie muss dazu auch noch aktiviert werden. Siehe dazu Aktivieren der Applikation.

Ausprägung der Akzeptanzterminals im Fahrgeldmanagementsystem eines Systembetreibers, wobei ein (Teil-) Leistungsnachweis in der Applikation bei Fahrtantritt automatisch angelegt und im Fahrtverlauf (meist Fahrtende) automatisch komplettiert bzw. ergänzt wird. Systemvertreter sind:

• Check-In-/Check-Out-Systeme (CICO),

• Be-in/Be-out-Systeme (BIBO).

• Check-In/Be-Out Systeme (CIBO)

Der bei Fahrtantritt automatisch angelegte (Teil-) Leistungsnachweis gilt dabei als Nachweis einer gültigen Fahrberechtigung. In BIBO-Systemen erfolgt die Komplettierung des Leistungsnachweises, indem bereits die jeweils nächste Haltestelle nach Abfahrt des Verkehrsmittels auf das Nutzermedium geschrieben wird.

Interoperabilität ist ein Merkmal eines Produkts oder Systems, dessen Schnittstellen vollständig bekannt sind, so dass es mit anderen gegenwärtigen oder zukünftigen Produkten oder Systemen ohne irgendwelche Einschränkungen zusammenarbeiten kann, sei es bei der Implementierung oder beim Zugriff.

Die nachfolgende Beschreibung bezieht sich auf die Definition von Interoperabilität innerhalb von (((eTicket Deutschland:

Die Gewährleistung sowohl einer durchgehenden Reise als auch punktueller Einzelfahrten für den Fahrgast unter Benutzung des selben Nutzermediums mit derselben Applikation in den Netzwerken (Fahrgeldmanagementsystemen) aller vertraglich eingebundenen Verkehrsunternehmen. Mehr über Interoperabilität lesen Sie hier.

In interoperablen Systemen müssen eine Vielzahl von Daten zwischen den unterschiedlichen Systempartnern in unterschiedlichen Einzelsystemen ausgetauscht werden. Diese Aufgabe übernimmt das Interoperabilitätsnetzwerk. Es befreit die operativen Einheiten (Applikationsherausgeber, Kontroll- und Sperrlistenservice, Produktverantwortlicher, Kundenvertragspartner und Dienstleister) davon, über Details der Datenübertragung informiert zu sein.

Das Interoperabilitätsnetzwerk (ION) selbst bezeichnet das gesamte Netzwerk welches logisch und physikalisch dazu benötigt wird, um Deutschlandweit Nachrichten zwischen Teilnehmer-Systemen zu versenden.

Der Kartenbesitzer ist diejenige Person, welche die tatsächliche Verfügungsgewalt über die Karte hat. Kommt die Karte zum Einsatz, wird der Kartenbesitzer zum Kartenbenutzer. Der Karteninhaber ist der Eigentümer der Karte. Er ist nicht zwingend der Kartenbesitzer.

Der Begriff Kartentyp wird in der KA zur Unterscheidung unterschiedlicher technischer Ausführungen einer Chipkarte benutzt (z.B. Kreditkarte, Karte mit Mifare-Emulation, etc.)

Der Name Kernapplikation (KA) steht für den deutschlandweiten Standard für elektronische Fahrgeldmanagementsysteme bei unterschiedlichen ÖPV- oder Systembetreibern in der Version 1 und 2. Der neue Name (((etiCORE bezieht sich auf Version 3. Beide Standards umfassen Sicherheit, Zertifizierung, Organisationskonzept und relevante Systemschnittstellen im E-Ticketing, das die interoperable Nutzung einer ÖPV-Applikation auf einem Nutzermedium gestattet.

Sie definiert

• die Realisierung der Spezifikation auf einem Chip in einem Nutzermedium und dessen Interface zu den notwendigen Akzeptanzterminals

• die Beschreibung der notwendigen Schnittstellen zwischen Akzeptanzterminals und Hintergrundsystemen

• die Beschreibung der notwendigen Schnittstellen zwischen den Hintergrundsystemen unterschiedlich ausgeprägter Fahrgeldmanagementsysteme und relevanter Instanzen

• den Nachweis der Standardkonformität und Sicherheit durch ein Zertifizierungsverfahren

Keymanagement betrifft den gesamten Umgang mit kryptografischen Schlüsseln, also die Erzeugung, die Verteilung, die Verwaltung, die Speicherung, die Ersetzung und die Überwachung von kryptografischen Schlüsseln (siehe auch Symmetrischer Schlüssel/Asymmetrische Kryptographie).

Die genannten Aufgaben werden in Deutschland durch den Scheme Manager (nach der aber nur einen Teilaspekt abdeckt) sichergestellt und durch eine zentrale Instanz, die Unterrolle des Sicherheitsmanagers, übernommen. In (((etiCORE entfällt die Schlüsselverwaltung für die symmetrischen Schlüssel in den Partnersystemen des Produktverantwortlichen und Kundenvertragspartners.

Die Kontrolle prüft das Vorliegen aller beim Kunden / Nutzer für die Inanspruchnahme einer ÖPV-Dienstleistung erforderlichen Voraussetzungen:

• lesbares Kundenmedium,

• gültige Applikation (inklusive Check der Sperrliste für Applikationen)

• gültige Berechtigung (inklusive Check der Sperrliste für Berechtigungen)

• gültiges Produkt (tarifliche Gültigkeit)

Sie liegt vorrangig im Interesse des ÖPV-Dienstleisters, der seine Leistungen auf der Grundlage von Leistungsnachweisen abrechnet. Wenn eine dieser Voraussetzungen nicht vorliegt, initiiert die Kontrolle das Erhöhte Beförderungsentgelt. Die Kontrolle initiiert zusätzlich eine Sperrung einer Applikation oder Berechtigung auf dem Kundenmedium, wenn entsprechende Sperreinträge auf der Sperrliste gefunden werden. Das Sperren auf dem Nutzermedium kann ab 2GSI / (((etiCORE ohne SAM durchgeführt werden.

In 1GSI / KA 1.X wird ein Kontrollnachweis zusätzlich zum Senden an den Produktverantwortlichen auf das Nutzermedium geschrieben, ab 2GSI / (((etiCORE wird der Kontrollnachweis nur noch an den Produktverantwortlichen gesendet. Damit ist ab 2GSI / (((etiCORE die Kontrolle ohne SAM möglich. Im Sinne von ISO 24014 kann die Kontrolle als Teil der Erfassung verstanden werden, ist aber ein eigenständiger Anwendungsfall.

Der Kontroll- und Sperrlistenservice (KOSE) bietet Listen mit Sperreinträgen von

• Berechtigungen

• Applikationen

• Secure Application Modules (SAMs)

• Schlüssel

• Organisationen

Einträge in den dedizierten Listen geben einen Hinweis darauf, dass die referenzierte Instanz gestohlen, kompromittiert, ungültig usw. ist. Für all diese Instanzen können neue Befehle zum Hinzufügen eines Eintrags zu diesen Hotlists oder zum Entfernen eines Eintrags aus diesen Hotlists ausgeführt werden:

• durch den Scheme Manager in Bezug auf Organisationen, SAMs und Schlüssel (in (((etiCORE nur noch Authentisierungsschlüssel)

• durch die Kundenvertragspartner in Bezug auf Applikationen und Berechtigungen

Darüber hinaus werden im Rahmen von Collecting and Forwarding (siehe ISO 24014-1) Sperrnachweise (die sich entweder auf eine Berechtigung oder eine Applikation beziehen) bearbeitet, indem sie von den Diensteanbietern gesammelt und den Produktverantwortlichen (Berechtigungen) und dem Applikationsherausgeber (Applikationen) zur Verfügung gestellt werden. Siehe Rollenmodell in Spec Main.

Träger der Applikation. Siehe auch Nutzermedium.

Kundendaten ist der Oberbegriff für die Kundenpräferenzen und das Kundenprofil.

Individuelle, wählbare Kundenangaben, die in der Applikation auf dem Kundenmedium abgelegt werden und z. B. der Beschleunigung der Abfertigung dienen können. Sie werden nicht automatisch vertragsrelevant. Dabei handelt es sich um bevorzugte Ticketausprägungen.

Gesamtheit der den Kunden beschreibenden, persönlichen Stammdaten, die in der Applikation auf dem Kundenmedium abgelegt werden. Das Kundenprofil ist aufgrund seiner spezifizierten Datenstruktur für alle Interaktionen mit der Applikation gleich interpretierbar. Die Nutzung kann aber betreiberspezifisch erfolgen.

Der Kundenservice ist definiert im ISO-Standard 24014-1 und realisiert für jeden Kunden übergreifende Information und Beschwerde-Management im Zusammenhang mit der VDV-Kernapplikation inklusive gestohlene oder beschädigte Nutzermedien. Dies umfasst Call Center-Funktionen, Internetservice und kann über regionale Servicestellen erfolgen.

Ein Kundenvertrag im Sinne von (((eTicket Deutschland stellt eine Beziehung zwischen dem Verkehrsunternehmen, das dem Kunden eine Leistung zur Verfügung stellt, und dem Kunden dar. Der Kundenvertrag beschreibt die Bedingungen, unter welchen der Kunde die vom Verkehrsbetreiber angebotenen Service-Leistungen nutzen kann. Gleichzeitig wird dem Kunden das Recht auf die Inanspruchnahme eines Service eingeräumt. Der Kundenvertrag regelt die Fahrpreisermittlung und Abrechnung zwischen einem Kundenvertragspartner und einem Kunden. Der Kundenvertrag legt die primär die zur Anwendung kommenden Nutzertarifparameter fest.

Der Kundenvertrag ist immer qualifiziert durch die Organisations-ID des Kundenvertragspartners. Der Kundenvertrag wird in elektronischer Form als Berechtigung (als (((eBezahlberechtigung oder Elektronischer Fahrschein) auf der Basis eines vom Produktverantwortlichen definierten EFM Produktes auf die ÖPV-Applikation gespeichert.

Die Rolle des Kundenvertragspartners ist eine spezielle Rolle in der Kernapplikation. Sie besteht aus mehreren in ISO 24014-1 definierten Rollen:

• Product Retailer

• Application Retailer

• Customer Service

• Identity Provider

• Account Provider

• Payment Provider

Der Kunden-Vertragspartner reguliert die Verkaufsprozesse des Kunden unter Berücksichtigung der vertraglichen Abhängigkeiten gegenüber dem Scheme Manager und dem Produktverantwortlichen der verschiedenen Mobilitätsdienste. Insbesondere ist der Kunden-Vertragspartner für die Buchhaltung, das Ticketing und die Abrechnung der verschiedenen Mobilitätsdienste gegenüber dem Kunden verantwortlich.

Damit übernimmt er dafür die Rolle des Product Retailers, Application Retailer (Instanz Issuer) und Account Provider. Als Account Provider nimmt er die Dienste von Payment Providern seiner Wahl in Anspruch, mit denen er vertraglich verbunden ist. Der Kunden-Vertragspartner kann in der Rolle Primär-Kundenvertragspartner oder in der Rolle Fremd-Kundenvertragspartner auftreten. Siehe Rollenmodell in Spec Main.

Die Kundenvertragspartner-Personalisierungseinheit kapselt die Kommunikation zwischen Nutzermedium und SAM. Sie besteht demzufolge mindestens aus einem Lese-/Schreibgerät mit SAM.

Wenn ein Nutzermedium in Form einer Chipkarte bedruckt werden soll, ist der entsprechende Drucker ebenso Bestandteil der KVP-PE. So stellt z.B. eine Lettershopmaschine bei einem Massenpersonalisierer letztendlich ebenfalls eine KVP-PE dar.

Die Kundenvertragspartner-Vertriebseinheit (KVP-VE) stellt die Software für die Auswahl von Applikationen zur Personalisierung, von Berechtigungen sowie die Kommunikation zum Referenz-Hintergrundsystem bereit und stellt die erforderlichen Ein- und Ausgabekomponenten (Monitor-/ Tastatur) zur Verfügung.

Der Leistungsnachweis stellt die auf dem Nutzermedium zur Kontrolle gespeicherten Leistungsdaten dar, die die Leistungsinanspruchnahme des Kunden im IN-OUT System beschreiben.

Erste Sicherheitsebene in der Sicherheitsarchitektur der VDV-Kernapplikation (im (((eTicket Deutschland). In Level-1 wird eine stark eingegrenzte Zahl von Organisations-IDs verwendet, die exemplarisch für sämtliche Teilnehmer in ihren Rollen für die Zertifizierung von Systemkomponenten verwendet werden. Diese speziellen Organisations-IDs sind so konstruiert, dass sie von keinem Wirksystem anerkannt werden. Für allererste Tests bei der Entwicklung von Systemkomponenten wird empfohlen, in diesem Level-1 zu arbeiten.

Zweite Sicherheitsebene in der Sicherheitsarchitektur der VDV-Kernapplikation (im (((eTicket Deutschland). In Level 2 erfolgt die Erzeugung und Nutzung aller KA-Sicherheitskomponenten (symmetrische / asymmetrische Schlüssel, SAM und Nutzermedium) mit OrganisationsIDs, die als Komplementär zu den Teilnehmern zugeteilten Wirk- bzw. Level-3-Organisations-IDs vergeben werden.

In der KA Version 1.X wird hierzu in der 2 Byte langen Organisations-ID das erste Bit esetzt. Dadurch wird auf die Level-3 Organisations-ID ein Wert 8000 hexadezimal oder 32768 dezimal hinzuaddiert. Z.B. wird aus der Organisation 5600 dezimal bzw. 15E0 hexadezimal dann in Level-2 die Organisations-ID 95E0 hexadezimal bzw. 38368 dezimal.

In (((etiCORE wird das Level nicht mehr über die Organisations-ID (die nicht auf 2 Byte           festgelegt ist) selber gesteuert, sondern über das verwendete Zertifikat. Damit sind die Organisations-IDs in Level-2 und Level-3 gleich, und nur über das Sicherheitsmanagement bzw. die Ausgabe der Zertifikate wird gesteuert, wie die aktuelle Systemumgebung verwendet werden darf.

Dritte (höchste) Sicherheitsebene in der Sicherheitsarchitektur der VDV-Kernapplikation im (((eTicket Deutschland. In Level-3 erfolgt die Erzeugung und Nutzung aller KA-Sicherheitskomponenten (symmetrische / asymmetrische Schlüssel, SAM und Nutzermedium) mit den Level-3 Organisations-IDs, die die Teilnehmer in ihren KA-Systemen zur eindeutigen Identifizierung, Authentifizierung, Verschlüsselung und Transaktionssicherung nutzen.

Hier sind alle Sicherheitskomponenten zur durchgängigen Sicherung der Teilnehmerinteressen geschützt und nicht für Dritte zugänglich. Level 3 ist dem Wirkbetrieb vorbehalten. Im Wirkbetrieb des (((eTicket Deutschland werden ausschließlich Wertobjekte (z.B. (((eBezahlberechtigungen) verwendet und anerkannt, die mit Level-3 Organisations-IDs erstellt wurden. Für den (((etiCORE Standards dürfen nur Level-3 Zertifikate verwendet werden.

Ein Nachweis protokolliert authentisch eine Transaktion auf Nutzermedium-Ebene. Dies können eine Ausgabe einer Berechtigung, Check-In oder Check-Out, Kontrollnachweis, Sperrung, Entsperrung, Entwertung, Aufladungen von Werteeinheiten, etc. sein.

Notfallversionen werden verwendet, um Ausfälle und (finanzielle) Schäden zu begrenzen, falls ein Schlüssel kompromittiert wird. Das bedeutet faktisch, dass zusätzlich zu den jeweiligen Schlüsseln auch Notschlüssel in der Applikation gespeichert werden, wenn diese personalisiert wird. Es ist möglich, während des Betriebs auf diese Notschlüssel umzuschalten.

Ab (((etiCORE entfällt die Begrifflichkeit, da für die Verwendung eines anderen Schlüssels in Folge einer Schlüssel Kompromittierung ein anderer Mechanismus verwendet wird. Siehe hierzu Symmetrischer Schlüssel.

Der Nutzer ist im Besitz des Nutzermediums und ist im Sinne von ISO 24014-1 der Reisende (Passenger). Er nimmt die ÖPV-Leistung eines bestimmten Tarifprodukts in Anspruch. Der Nutzer kann im Gegensatz zum Kunden auch anonym an (((eTicket-Deutschland teilnehmen.

s. Kundenmedium / Customer Medium.

Nutzertarifparameter können vom Applikationsnutzer an Terminals gegenüber einem gültigen Beförderungsvertrag für eine Fahrt verändert werden, für die dann die geänderten Parameter gelten (z.B. Mitnahmeregelung oder Wechsel der Serviceklasse).

Die Nutzungszähler werden verwendet, um bei einer automatisierten Fahrpreisermittlung dem Kunden Sondertarife auf Grund der von ihm in Anspruch genommenen Verkehrsleistungen zu gewähren. Bei der post-priced Fahrpreisermittlung kann ein Best-Price oder Bonusszenario auch ohne Nutzungszähler realisiert werden.

Bei trip-priced Fahrpreisermittlung in Kombination mit Einsatz einer Werteinheitenberechtigung jedoch wird der Nutzungszähler benötigt, um Sondertarife auf die in Anspruch genommenen Verkehrsleistungen zu gewähren (z.B. Berechnung eines Tagestickets ab der vierten Einzelfahrt).

s. Asymmetrische Kryptographie / Asymmetric Cryptography

Der ÖPV-Dienstleister bietet Transportdienstleistungen für einen Kunden an, der eine entsprechende Berechtigung zur Nutzung dieser Dienstleistungen erworben hat. Der Beförderungsvertrag wird zwischen dem transportierenden ÖPV Dienstleister und einem Nutzer/Fahrgast beim Einstieg in das Transportmittel abgeschlossen.

Der Dienstleister erwirbt, geregelt in einem Vertragsverhältnis ( (((eTicketTeilnahmevertrag), vom Scheme Manager das Recht zur Teilnahme am EFM-System. Der ÖPV Dienstleister schließt Verträge mit den Produktverantwortlichen für die Akzeptanz von Produkten und für die Bezahlung der erbrachten Beförderungsleistungen ab sowie mit den Kundenvertragspartnern über den Ausgleich der entstandenen Forderungen (via Forderungs-Clearing).

Siehe auch Rollenmodell in der Spec-Main (für KA 1.X Spec HD BOM).

Vom Kunden bezahlte, zweckgebundene Werteinheiten, die zur bargeldlosen Nutzung von Verkehrsleistungen dienen. Die ÖPV-Werteinheiten werden gegen gültige und akzeptierte Zahlungsmittel bei entsprechend autorisierten Stellen des ÖPV erworben, in der ÖPV-Applikation gespeichert und sukzessive entsprechend der in Anspruch genommenen (Beförderungs-)Leistungen an autorisierten ÖPV-Terminals aus dem Speicher abgebucht. Die ÖPV-Werteinheiten entsprechen in ihrer Nutzung einem Mehrfahrtenkontingent für den ÖPNV.

Die Organisations-ID kennzeichnet eine Organisation eindeutig im gesamten Geltungsbereich der Kernapplikation. Die Organisations-ID besteht aus der Organisationsnummer, die von der Registrierung des Scheme Managers (VDV ETS) über das ASM Tool beim Abschluss eines (((eTicketVertrages vergeben wird. Die mit einer ID versehenen Organisationen sind juristische Personen, typischerweise Verkehrsunternehmen und verbünde. Im Ausnahmefall können dies auch klar abgegrenzte Betriebsteile eines großen Unternehmens sein.

Eine Persönliche Identifikationsnummer (PIN) ist ein numerischer (oder weniger gebräuchlich: alphanumerischer) Passcode, der bei der Authentifizierung eines auf ein System zugreifenden Benutzers verwendet wird.

Speziell im Rahmen der Kernapplikation verwendet: Vierstellige Geheimzahl, die zum Auslesen von Kundendaten auf dem Nutzermedium verwendet werden kann. Diese Kundendaten dürfen nur entweder authentisch von zugelassenen Terminals ausgelesen werden oder vom Kunden selber mit Hilfe seiner PIN.

Personalisierung im Sinne von (((eTicket Deutschland bedeutet das Aufbringen personengebundener Daten in die Applikation des Nutzermediums. Dabei entstehen ein Kundenprofil und ggf. Kundenpräferenzen. Die technischen Vorgänge hierzu sind in der Spezifikation des Nutzermediums beschrieben.

Der Begriff „Personengebunden“ wird meistens im Zusammenhang mit Berechtigungen verwendet und bedeutet, dass eine Berechtigung nur für eine bestimmte Person gültig und nicht übertragbar ist.

Mit Public-Key-Infrastructure (PKI) bezeichnet man ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnergestützter Kommunikation verwendet. Die PKI wird im Umfeld der Asymmetrische Kryptographie eingesetzt.

Bezeichnet ein Konto, über das vom Kunden in Anspruch genommene ÖPV-Leistungen über die Prepaid Bezahl-Berechtigung (PEB) verrechnet werden. Für die Option Autoload kann bei Erreichen eines vertraglich vereinbarten Schwellwertes ein vereinbarter Geldbetrag gegen ein beim Kundenvertragspartner bekanntes Kundenkonto eines Kreditinstitutes nachgeladen werden. Die über die Berechtigung in Anspruch genommenen ÖPV-Dienstleistungen werden unabhängig von den persönlichen Kundendaten gesammelt und zeitnah über dieses Konto verrechnet. Es gibt mindestens einen Kundenvertrag zu jedem Prepaid-Konto.

Hinweis: Die Einrichtung eines anonymen Prepaid-Zahlungsverfahrens (ohne Autoload) wäre grundsätzlich möglich, ist im Rahmen der Kernapplikation zurzeit aber nicht vorgesehen.

Der primäre Kundenvertragspartner gibt eine Applikation oder Berechtigung aus. Seine Organisations-ID wird in der Applikation oder Berechtigung eingetragen, um eine Zuordnung von Applikation oder Berechtigung zum primären Kundenvertragspartner zu ermöglichen, der diese ausgegeben hat.

Bezeichnet ein Konto, über das vom Kunden in Anspruch genommene ÖPV-Leistungen über die postpaid (((eBezahlberechtigung (POB) gegen Rechnung oder durch beim Primären Kundenvertragspartner bekanntes Kundenkonto eines Kreditinstitutes ausgeglichen werden. Die über die Berechtigung in Anspruch genommenen ÖPV-Dienstleistungen werden unabhängig von den persönlichen Kundendaten gesammelt und zu einem vertraglich vereinbarten Zeitpunkt über dieses Konto verrechnet. Es gibt mindestens einen Kundenvertrag zu jedem Post-paid-Konto.

Die Einrichtung eines Postpaid-Zahlungsverfahrens ist anonym naturgemäß nicht möglich.

Der Begriff Produkt wird in der Kernapplikation im Sinne eines ÖPV-Tarifprodukts oder EFM Produkts genutzt.

Beim Produktclearing (PCL) handelt es sich um ein zentrales System, das einen deutschlandweiten Tarifserver bildet und über Tarifmodule nach PKM alle Tarife der angeschlossenen Teilnehmer kennt und berechnen kann. Das Produktclearing ermittelt die richtigen Tarife und Preise für die Reisekette des Kunden.

Für die Fahrpreisberechnung nutzt das PCL die Tarifmodule nach PKM. Dieser offene Standard zur digitalen Abbildung von Tarifdaten ist Teil der VDV-Kernapplikation und erlaubt nicht nur die Auskunft zu produktbezogenen Anfragen, sondern berechnet auf Basis der angegebenen Nutzertarifparameter das fahrtenbezogen richtige Tarifprodukt.

Alle an (((eTicket Deutschland beteiligten Produktverantwortlichen stellen ihr jeweils aktuelles Tarifmodul dem System zu Verfügung. Dadurch entsteht ein zentraler Punkt für alle Tarifdaten in Deutschland.

Der Produktverantwortliche entwickelt EFM Produkte aus seinen Tarifen für Beförderungsdienstleistungen in einem oder mehreren geographischen Gebieten, in denen verschiedene ÖPV-Dienstleister Beförderungsdienstleistungen anbieten. Der Teilnahmevertrag regelt die notwendigen Modalitäten zwischen dem Produktverantwortlichen, den Kundenvertragspartnern und den ÖPV-Dienstleistern. Der Produktverantwortliche erwirbt, geregelt in einem Vertragsverhältnis, vom Scheme Manager das Recht, an den EFM-Systemen teilzunehmen und seine Produkte dort zu registrieren. Er erhält vom Scheme Manager die notwendigen Kennungen und Informationen für die Verwaltung seiner Token, Rechte und Sicherheitsmodule.

Als Teil des Sicherheitsmanagements autorisiert der Produktverantwortliche die Kundenvertragspartner, Berechtigungen auszugeben. Der Produktverantwortliche berechtigt Kundenvertragspartner zum Verkauf seiner Produkte.

Siehe auch Rollenmodell in Spec Main (für KA 1.X Spec HD BOM)

Die Referenzberechtigung stellt eine definierte Struktur zur Verfügung, die sowohl als Automatisierte Fahrberechtigung als auch für einen Elektronischen Fahrschein genutzt werden kann. Einerseits stellt sie für eine Automatisierte Fahrberechtigung mit fest definierten produktspezifischen Strukturen zur interoperablen Nutzung eine empfohlene Vorgabe dar.

Andererseits ist die Referenz-Berechtigung für einen Elektronischen Fahrschein ein Vorschlag mit fest vordefinierten produktspezifischen Strukturen, die von den Produktverantwortlichen bei der Umsetzung von eTickets verwendet werden können. Eine etwas flexiblere und speicheroptimierte Vorgabe bietet hier alternativ der TLV-EFS

Das Referenzsystem ist ein imaginäres System, das Referenzterminal ein imaginäres Terminal, welches definierte Grundfunktionalitäten in sich vereinigt. Diese Grundfunktionalitäten finden sich im realen Einsatz in verschiedenen Systemen bzw. den systemzugehörigen Terminaltypen wieder. Die im realen System bzw. Terminal realisierten Funktionalitäten werden dort analog der Anwendungsfälle in den Systemlastenheften (ab (((etiCORE: KVP-Ref - Dienstleisterumgesetzt.

Eine Instanz innerhalb der Public Key Infrastructure, bei der Personen, Maschinen oder auch untergeordnete Zertifizierungsstellen Zertifikate beantragen können. Die RA prüft die Richtigkeit der Daten im gewünschten Zertifikat und genehmigt den Zertifikatsantrag, der dann durch die Zertifizierungsstelle (Certification Authority, CA) signiert wird.

Die Unterrolle Registrierung des Scheme Managers ist verantwortlich für die Generierung, Organisation und Verantwortung der im System für eine interoperable Nutzung notwendigen Identifikatoren, sowie für die Verwaltung der für Organisation und Betrieb erforderlichen Verträge.

Die reguläre Version eines (symmetrischen) Schlüssels kann genutzt werden, solange keine Kompromittierung des Schlüssels eintritt. Ab (((etiCORE entfällt die Begrifflichkeit, da für die Verwendung eines anderen Schlüssels in Folge einer Schlüssel-Kompromittierung ein anderer Mechanismus verwendet wird. Siehe hierzu Symmetrischer Schlüssel. Siehe auch Notfallversion.

Der Scheme Manager ist die oberste Instanz von (((eTicket Deutschland. Diese Aufgabe übernimmt VDV ETS. Der Scheme Manager kombiniert die Rollen Applikationsherausgeber, Registrierung und Sicherheitsmanager aus der ISO 24014-1.

Er erstellt die Vorschriften und überwacht sie. Er existiert einmal im System und identifiziert sich eindeutig. Weitere Informationen finden sich im Rollenmodell der Hauptspezifikation.

Das Schlüsselregister gehört zu einer Sonderfunktion der Applikation auf dem Nutzermedium. Es wird in Verbindung mit der Ausgabe von Berechtigungen (in diesem Zusammenhang wird der missverständliche Begriff der Multiberechtigung verwendet* benötigt.

Die verwendeten Schlüssel können bereits bei der Ausgabe der Applikation für den ausgebenden Kundenvertragspartner und den vorgesehenen Produktverantwortlichen geschützt eingebracht werden. Diese Schlüssel hängen von der Instanz-ID der Applikation, nicht aber einer einzelnen Berechtigungs-ID ab. Für weitere Kundenvertragspartner oder Produktverantwortliche können bei Bedarf weitere Schlüssel eingebracht werden.

Bei der Ausgabe einer Berechtigung werden dann im Schlüsselregister die benötigten Schlüsselreferenzen auf die vorhandenen Schlüssel eingetragen, passende Schlüssel zwischen Nutzermedium und Terminal für die Ausgabe einer Berechtigung eine erhebliche Beschleunigung. Die ausgegebene Berechtigung in einer Applikation mit Schlüsselregister unterscheidet sich fachlich nicht von einer Berechtigung in einer Applikation ohne Schlüsselregister.

Ab (((etiCORE ist aufgrund der schnelleren kryptographischen Prozesse die Verwendung eines Schlüsselregisters im Zusammenhang mit der Ausgabe von Berechtigungen in dieser Form nicht mehr notwendig. Allerdings gibt es ein neues, für die Authentisierung verwendetes Schlüsselregister in ähnlicher Form, in dem die Referenzen auf die Generationen der Authentisierungsschlüssel abgelegt sind, siehe auch Symmetrischer Schlüssel.

*Der Begriff Multiberechtigung suggeriert, dass es sich um Mehrfachberechtigungen handeln könnte, die für unterschiedliche Leistungen genutzt werden können. Dieser Begriff bezieht sich aber nur darauf, dass Schlüssel für mehrere Berechtigungen verwendet werden können, um Zeit für kryptografische Prozesse beim Zugriff einzusparen. Die Multiberechtigung selbst unterscheidet sich nicht von der normalen Berechtigung.

Das Secure Application Module (SAM) wird als Sicherheitsmodul für Kundenvertragspartner bzw. Dienstleister eingesetzt und führt die sicherheitsrelevanten Funktionen der Verkaufsterminals und/oder Kontrollterminals aus, die direkt mit Nutzermedien kommunizieren. Es kann auch zum Prüfen der mit dem Nutzermedium erzeugten Transaktions-Signaturen in den Hintergrundsystemen eingesetzt werden.

Die Secure Crypto Environment (SCE) ist eine logische Komponente auf dem mobilen Gerät eines Passagiers, die in der Lage ist, kryptographische Schlüssel zu empfangen (oder zu generieren) und zu verwenden und diese unveränderlich an das mobile Gerät und eine Ticketing-App zu binden.

Die SCE muss gegen das Auslesen der Schlüssel und gegen das Kopieren auf ein anderes mobiles Gerät resistent sein und kann mit dem Backend eine Echtheitsprüfung für Schlüssel durchführen. Technisch kann sie z.B. als eine Bibliothek implementiert werden, die in eine Ticketing-App integriert ist und die Sicherheitsressourcen des mobilen Geräts wie einen hardwareseitigen Schlüsselspeicher nutzt.

Die Sicherheitsarchitektur der Kernapplikation umfasst 3 unterschiedliche Sicherheitslevels für den Test- und den Wirkbetrieb, die sich auf die Nutzung der Nutzermedien, SAM, symmetrischen und asymmetrischen Schlüssel und die zugehörigen Zertifikate beziehen. Die Sicherheitslevels und die zugehörigen Produktionsumgebungen beim Sicherheitsdienstleister sind vollkommen getrennt, um keine Sicherheitsrisiken einzugehen. Entsprechend der getrennten Sicherheitsebenen erhält für KA Version 1.X ein teilnehmendes Unternehmen zwei Organisations-IDs, jeweils eine für Level-2 und Level3. Für (((etiCORE werden für die unterschiedlichen Sicherheitsebenen entsprechende Zertifikate verwendet.

Die Sperranforderung soll das Setzen eines Objektes auf die jeweilige Sperrliste durch einen verantwortlichen Dritten bewirken. Je nach Objekt gibt es unterschiedliche Beteiligte:

• An zuständigen Kundenvertragspartner gestellte Anforderung, eine Berechtigung auf die Sperrliste setzen zu lassen. Dies kann von einem anderen Kundenvertragspartner, ÖPV-Dienstleister oder Produktverantwortlichen initiiert werden.

• An zuständigen Kundenvertragspartner gestellte Anforderung, eine Applikation auf die Sperrliste setzen zu lassen. Dies kann von einem anderen Kundenvertragspartner, einem ÖPV-Dienstleister oder dem Applikationsherausgeber erfolgen.

• An Applikationsherausgeber gestellte Anforderung, ein Secure Application Module, einen Schlüssel (ab (((etiCORE nur noch Authentisierungsschlüssel) oder eine Organisation auf die jeweilige Sperrliste setzen zu lassen. Dies kann von einem anderen Kundenvertragspartner, ÖPV-Dienstleister oder Produktverantwortlichen initiiert werden.

Die Sperraufhebungsanforderung soll das Entfernen eines Objektes von der jeweiligen Sperrliste durch einen verantwortlichen Dritten bewirken. Je nach Objekt gibt es unterschiedliche Beteiligte:

• An zuständigen Kundenvertragspartner gestellte Anforderung, eine Berechtigung von der Sperrliste zu entfernen. Dies kann von einem anderen Kundenvertragspartner, ÖPV-Dienstleister oder Produktverantwortlichen initiiert werden.

• An zuständigen Kundenvertragspartner gestellte Anforderung, eine Applikation von der Sperrliste zu entfernen. Dies kann von einem anderen Kundenvertragspartner, einem ÖPV-Dienstleister oder dem Applikationsherausgeber erfolgen.

• An Applikationsherausgeber gestellte Anforderung, ein Secure Application Module, einen Schlüssel (nicht mehr ab (((etiCORE) oder eine Organisation von der jeweiligen Sperrliste zu entfernen. Dies kann von einem anderen Kundenvertragspartner, ÖPV-Dienstleister oder Produktverantwortlichen initiiert werden

Der Sperrauftrag dient dazu, ein Objekt auf die jeweilige Sperrliste zu setzen. Je nachdem, welches Objekt hinzugefügt werden soll, gibt es unterschiedliche Initiatoren:

• Der zuständige Kundenvertragspartner erteilt den Auftrag, der Sperrliste eine Berechtigung oder eine Applikation hinzuzufügen.

• Der Scheme Manager ordnet das Hinzufügen eines Secure Application Modules oder einer Organisation zur Sperrliste an.

• Der Schlüsselinhaber (Kunden-Vertragspartner, Produktverantwortliche oder Scheme Manager) ordnet das Hinzufügen eines Schlüssels (ab (((etiCORE nur noch der Scheme Manager als Schlüsselinhaber) zur jeweiligen Sperrliste an.

Der Sperrfreigabeauftrag dient dazu, ein Objekt von der jeweilige Sperrliste zu nehmen. Je nachdem, welches Objekt entfernt werden soll, gibt es unterschiedliche Initiatoren:

• Der zuständige Kundenvertragspartner erteilt den Auftrag, von der Sperrliste eine Berechtigung oder eine Applikation zu entfernen.

• Der Scheme Manager ordnet das Entfernen eines Secure Application Modules oder einer Organisation von der Sperrliste an.

• Der Schlüsselinhaber (Kunden-Vertragspartner, Produktverantwortliche oder Scheme Manager) ordnet das Entfernen eines Schlüssels (ab (((etiCORE ist ein Freigabeauftrag des Scheme Managers für Schlüssel nicht mehr möglich) von der jeweiligen Sperrliste an.

Der Sperrgrund gibt an, warum eine Sperrung erfolgt ist/erfolgen soll.

Eine Sperrliste besteht aus einer Menge von Sperrlisteneinträgen zu einem bestimmten Objekt (Berechtigung, Applikation, SAM, Schlüssel, Organisation). Sie dient (nach entsprechender Verteilung in den Systemen / Terminals) dem Auffinden einer unzulässigen Verwendung von einer zu sperrenden Applikation oder Berechtigung für die Inanspruchnahme von Verkehrsdienstleitungen.

Auf Basis der Sperrliste und deren Sperrlisteneinträgen erfolgt eine physikalische Sperre (bei Berechtigungen und Applikationen) oder eine logische Sperre, bzw. die Ablehnung einer Berechtigung oder Applikation (aufgrund von SAM, Schlüssel- oder Organisationssperreinträgen).

Ein Sperrlisteneintrag entsteht durch die Aufnahme eines zu sperrenden Objektes (Applikation, Berechtigung, Organisation, SAM, Schlüssels) in die Sperrliste.

Ein Sperrnachweis entsteht durch Prüfen von Applikation und Berechtigungen gegen die entsprechenden Sperrlisten, wenn ein relevanter Sperrlisteneintrag gefunden wird. Das dann folgende physikalische Sperren einer Applikation oder Berechtigung wird jeweils durch einen authentischen Sperrnachweis dokumentiert, der zusätzlich noch per Meldung vom Terminal an die verantwortlichen Instanzen geschickt wird.

Sperrobjekte im Kontext der KA sind Applikationen, Berechtigungen, Organisationen und Schlüssel (symmetrische/asymmetrische). Die Verwaltung der Sperrobjekte obliegt der Auftrag gebenden Instanz. Sie werden in Sperrlisten durch einen Eintrag mindestens mit ihrer ID repräsentiert.

Applikationen und Berechtigungen können gesperrt werden und können dann im Rahmen der Kernapplikation nicht mehr verwendet werden. Die Sperrung erfolgt aufgrund einer Statusänderung bei der Applikation oder Berechtigung auf dem Nutzermedium Im Zusammenhang mit einer gegenseitigen Authentifizierung zwischen Kommunikationsteilnehmern kann ein gemeinsamer Schlüssel (der Startkey) vereinbart werden, der für eine gesicherte Kommunikation beider Partner verwendet wird. Hieraus können weitere Schlüssel (Sessionkeys) durch Dynamisierung abgeleitet werden. Aus Basisschlüsseln kann durch Derivatbildung und Dynamisierung ein Schlüssel (Sessionkey) abgeleitet werden, der innerhalb eines Verschlüsselungs- oder MAC Berechnungs- bzw. Prüfkontextes verwendet wird.

Der Begriff Statische Berechtigung bezieht sich hier auf einen mit einer digitalen Signatur ausgestatteten Elektronischen Fahrschein, der als nicht veränderbarer Datensatz auf verschiedene, auch einfache Medien, ausgegeben werden kann. Es kann sich hierbei beispielsweise handeln um

• einen auf Papier gedruckten bzw. auf einem mobilen Endgerät gespeicherten 2D Barcode oder

• einen auf einem kostengünstigen Speicherchip oder NFC-Handy gespeicherten und über eine ISO 14443-Schnittstelle lesbaren Datensatz

Es wird von beiden Kommunikationspartnern derselbe (geheime) Schlüssel sowohl zum Ver- als auch zum Entschlüsseln verwendet. Symmetrische Schlüssel werden in KA 1.X sowohl für die gegenseitige Authentisierung der Komponenten (Schlüssel kommen vom Scheme Manager) als auch für authentische Nachweise von Berechtigungsausgaben oder Bezahlvorgängen (Schlüssel kommen vom Produktverantwortlichen und Kundenvertragspartner) genutzt.

Um bei Schlüssel-Kompromittierung schnell mit Schlüsselaustausch reagieren zu können und somit mit einem neuen Schlüssel arbeiten zu können, wird in KA 1.X mit Regulärversion und Notfallversion der Schlüssel gearbeitet. In (((etiCORE entfallen alle symmetrischen Schlüssel von Produktverantwortlichen und Kundenvertragspartnern. Lediglich die symmetrischen Schlüssel für die gegenseitige Authentisierung der Komponenten bleiben im Einsatz.

Anstelle von Regulär- und Notfallversionen wird dann ein Schlüsselregister mit unterschiedlichen Schlüsselgenerationen verwendet. Diese Schlüsselgenerationen sind bereits fest auf die Komponenten aufgebracht. Wird ein Authentifizierungsschlüssel auf einer Sperrliste gefunden, verhandelt das Terminal mit dem SAM und dem User Medium, welcher Authentifizierungsschlüssel verwendet werden muss.

Ein Tarif im Sinne des ÖPV ist ein Vertrag oder ein Vertragsbestandteil mit einer Aufzählung von festen Bedingungen für das Erbringen von Leistungen im Rahmen eines Beförderungsvertrages. Die Vertragsbedingungen werden Tarif genannt, wenn sie einseitig von einem Anbieter vielen möglichen Vertragspartnern (Kunden) einheitlich angeboten werden.

Ein Tarifprodukt stellt ein standardisiertes Leistungsangebot für die Nutzung des ÖPV dar und definiert sich durch folgende Eigenschaften:

• den Leistungsanspruch im Sinne der abrufbaren Leistung (zeitlich-räumliche Gültigkeit, usw.)

• die Produktart

• die beförderungsrechtlichen Bedingungen (z. B. Anspruchsberechtigungen wie Alter (Kind/Erwachsener), Status (z.B. Schüler, Rentner), etc.)

• sowie den Produktpreis (Tarif) für den konkreten Leistungsanspruch.

Ein Tarifprodukt kann durch die Gewährung eines oder mehrerer Zusatznutzen (Interservices, Intraservices) bzw. durch die Integration besonderer Serviceleistungen (z.B. Ersatz bei Verlust) erweitert werden (s. auch Kundenvertrag).

Vertrag über die Teilnahme am (((eTicket-Deutschland. Der Teilnahmevertrag regelt die (((eTicket-spezifischen Rechte und Pflichten der (((eTicket-Deutschland Teilnehmer in ihren unterschiedlichen Rollen untereinander (Produktverantwortlicher, Kundenvertragspartner und Dienstleister) und gegenüber dem Scheme Manager (VDV ETS).

Ein Ticket ist die mit einem Tarifprodukt verbundene Ausprägung einer Fahrberechtigung im Sinne des Öffentlichen Personenverkehrs (ÖPV) gemäß den geltenden Tarifbestimmungen. Jedes Ticket spiegelt einen abgeschlossenen Beförderungsvertrag wieder. Es werden sofort gültige Tickets und Tickets, die entwertet werden müssen oder die einen längeren definierten Gültigkeitszeitraum umfassen (Zeitkarten), unterschieden. Tickets werden bei als Elektronischer Fahrschein komplett auf dem Nutzermedium abgelegt.

Einen Sonderfall stellen IN-OUT Systeme dar. In dem Fall muss hierfür ein spezielles Tarifprodukt existieren, dessen Nutzungsbedingungen der Kunde im Vorfeld zugestimmt hat. Dann werden im Verlauf der Reise durch Check-In und Check-Out und Speichern die zugehörigen Informationen auf dem Nutzermedium erzeugt, die den Kunden zur jeweiligen Fahrt berechtigen. Tickets werden als EFM Produkt durch einen Produktverantwortlichen qualifiziert und als Berechtigung an den Kunden bzw. Nutzer ausgegeben.

Elektronischer Fahrschein mit in einer Anlage zur KA BOM-Spec definierten TLVDatenelementen in der Datenstruktur Statischer Produktspezifischer Teil und Transaktion Produktspezifischer Teil, die variabel zur Beschreibung von Tarifparametern benutzt werden können. In KA Release 1.x wird der Transaktion Produktspezifische Teil für den TVL-EFS nicht verwendet.

Als Transaktion wird in der Informatik eine Folge von Programmschritten bezeichnet, die als eine logische Einheit betrachtet werden, weil sie den Datenbestand nach fehlerfreier und vollständiger Ausführung in einem konsistenten Zustand hinterlassen. Daher wird für eine Transaktion insbesondere gefordert, dass sie entweder vollständig und fehlerfrei oder gar nicht ausgeführt wird.

Im Rahmen der KA/(((etiCORE finden Transaktionen im Sinne dieser Definition ausschließlich zwischen Nutzermedium (insbesondere Chipkarte) und Akzeptanzterminal statt.

Der Verspätungszeitzähler ist eine Angabe in Minuten, die eine Verspätung des Verkehrsmittels repräsentiert und die eine Beschränkung von Einzeltickets, die einer zeitlichen Begrenzung unterliegen, entsprechend korrigiert.

Wichtig ist der Verspätungszeitzähler auch bei IN-OUT Systemen, wenn bei erneutem Check-In (Check-In nach Fahrtfortsetzung) in ein anderes Verkehrsmittel dieses eine entsprechende Verspätung aufweist. Durch Berücksichtigen eines Verspätungszeitzählers kann der erneute Check-In als Fortsetzung der Reise gewertet werden.

Sammelbegriff für alle Arten personalbedienter und automatischer, peripherer Vertriebseinrichtungen zum Verkauf von Elektronischer Fahrscheinen und zum Laden von Debit-Beträgen als Werteinheiten auf das Nutzermedium oder in ein Prepaid-Konto.

s. ÖPV-Werteinheit / PT Value Units

Die Werteinheitenberechtigung (WEB) ist die Möglichkeit bzw. Erlaubnis, auf dem Nutzermedium ÖPV zweckgebundene Werteinheiten für ÖPV Leistungen zu nutzen. Die Werteinheitenberechtigung stellt einerseits eine Automatisierte Fahrberechtigung dar, in die ein Werteinheitenspeicher integriert ist. Sie hat den Vorteil, dass sie bei automatisierter Fahrpreisermittlung on-trip im Terminal den Zugriff auf ein Objekt im Nutzermedium beschränkt und die Transaktion für die Werteinheitenbuchung mit der Erfassungstransaktion (Fahrttransaktion) kombiniert abläuft.

Andererseits stellt sie auch außerhalb ihrer Nutzung in IN-OUT Systemen eine (((eBezahlberechtigung für ÖPV-Leistungen dar. In Abhängigkeit des Kundenvertrags gibt es folgende dieser beiden Nutzungsmöglichkeiten:

• WE-preload

Dieser Ausdruck definiert ein Verfahren ohne akzeptierte Überziehung der WEB. Ein negativer Saldo ist nicht möglich. Sie muss vor der Nutzung des ÖPV einen definierten, positiven Mindestsaldo aufweisen. Eine ÖPV-WE-Aufladung ist generell vor Nutzung der ÖPV-Leistung durchzuführen.

• WE-postload

Dieser Ausdruck definiert ein Verfahren, bei dem der Saldo der WEB durch die Abbuchung von ÖPV-WE vor bzw. nach Inanspruchnahme der ÖPV-Leistung ins Minus geraten darf (akzeptierte Überziehung). Bei diesem Verfahren wird eine maximale Untergrenze für den WEB-Saldo definiert, bei dessen Erreichung eine Abweisung vom System erfolgt. Durch Zubuchen des Fehlbestandes wird die WEB beim nächsten Laden automatisch wieder ausgeglichen.

Eine WEB lässt eine anonyme Teilnahme am ÖPV zu, dann in der Variante WE-preload. Für die Werteinheitenberechtigung ist eine Autoload-Funktion möglich. Die anonyme Teilnahme am ÖPV ist dann aber nicht möglich, da dafür eine Vertragsbeziehung notwendig ist.

s. Werteinheitenberechtigung / Stored Value (Unit) Payment Method

Synonym für Nutzung eines Nutzermediums in IN-OUT Systemen, die Lese/Schreiboperationen in Abständen größer 20 cm unterstützen. In der Regel im BeIn-Be-Out Kontext, z.B. mit BlueTooth LE.

Zum Interoperabilitätsnetzwerk (ION) gehörende Vermittlungsstelle, die Nachrichten eines ION-Teilnehmers auf Grundlage der als Empfänger angegebenen Organisations-ID an den Empfänger dieser Nachricht vermittelt. Der ION-Teilnehmer kann der Applikationsherausgeber, der Kontroll- und Sperrlistenservice oder ein Kundenvertragspartner, Dienstleister oder Produktverantwortlicher sein. Diese können direkt oder über Adapter an diese Vermittlungsstelle angebunden sein.

Die Instanz "Zertifizierung" des Scheme Managers hat die Verantwortung für die einheitliche Vorgabe der für die Kernapplikation notwendigen Zertifizierungsverfahren, für die Durchführung der Zertifizierung aller Systemkomponenten und für die Erteilung von Zertifikaten für die relevanten Systemkomponenten des elektronischen Fahrgeldmanagements.

Zusätzliches SAM bezogenes Zertifikat, das zur Ausgabe des VDV-Barcodes auf Grundlage der Statischen Berechtigung benötigt wird. Es wird nicht in den bestellten SAM ausgeliefert, sondern muss zusätzlich beim Trustcenter zusammen mit dem SAM bestellt werden.

Ab (((etiCORE benötigt das SAM für die Ausgabe von VDV-Barcodes kein zusätzliches Zertifikat, sondern verwendet für diese Funktionalität das Zertifikat seines Signaturschlüssels.